From nobody Mon Oct 1 00:19:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D4130DC3; Mon, 1 Oct 2018 00:19:13 -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, 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 FF8EB_RRZOY8; Mon, 1 Oct 2018 00:19:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 892CE130DD5; Mon, 1 Oct 2018 00:19:11 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 920771AE03DD; Mon, 1 Oct 2018 09:19:10 +0200 (CEST) Date: Mon, 01 Oct 2018 09:19:10 +0200 (CEST) Message-Id: <20181001.091910.1896030373672380031.mbj@tail-f.com> To: netmod-chairs@ietf.org, netmod-ads@ietf.org, netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] YANG module security considerations template - TLS reference X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 07:19:13 -0000 Hi, In their review of draft-ietf-netconf-nmda-restconf, the IESG suggested we update the reference to TLS from RFC 5246 to RFC 8446 (which obsoletes 5246). This update needs to be done to the template available at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines (it is not quite clear who is repsonsible for this template; maybe that should be clarified on the page) /martin From nobody Mon Oct 1 04:46:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2444130DEB for ; Mon, 1 Oct 2018 04:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.197 X-Spam-Level: *** X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, 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 (1024-bit key) header.d=btconnect.onmicrosoft.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 WFzhMUAsTt1b for ; Mon, 1 Oct 2018 04:46:47 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40129.outbound.protection.outlook.com [40.107.4.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A148A120072 for ; Mon, 1 Oct 2018 04:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bJZJmmQdIzKxEAlIODnPPQVYmavhOC+1UG8GUyzq9To=; b=ejEirdOZye2NZaT1tHHwI9I+eOt4vtI76+39z6uwIgQ5T8Tu7CDxTV7CLjPyQqC3wj7pmdiOkj7YLN33NFeaYyCMDXXiq4NpxE2owjq2te4mXwWri8DkmDE3pP4jks/uwyYrRZao8LhuZI1bASQvARFE6W5+sqKv3vHKUNLbi8M= Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB4831.eurprd07.prod.outlook.com (20.178.8.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.11; Mon, 1 Oct 2018 11:46:42 +0000 Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1207.014; Mon, 1 Oct 2018 11:46:42 +0000 From: tom petch To: "adrian@olddog.co.uk" , 'Kent Watsen' CC: "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt Thread-Index: AQHUUaLhqK0+eVIcY0e09cIrm611dw== Date: Mon, 1 Oct 2018 11:46:42 +0000 Message-ID: <031501d4597c$5538f580$4001a8c0@gateway.2wire.net> References: <056001d451a2$d3412240$4001a8c0@gateway.2wire.net> <1A7EF333-2DA0-4D51-B44C-63AF3D6D628B@juniper.net> <034a01d454b4$caf3aa80$4001a8c0@gateway.2wire.net> <045c01d45723$d2f17b60$4001a8c0@gateway.2wire.net> <906263FB-874E-427B-9119-3936B987C42B@juniper.net> <065301d45786$3b9b88b0$b2d29a10$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: MR2P264CA0023.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::35) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.131.229.47] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4831; 6:sGprSVpaILB3a7UAmhcpSIs69BF5HfKOgK+IdIhIXDDljrlMxP2pzzt+N6zo3JN5J1IsRtEX491OG2enVgJ5FXrYW9R88sSqcWQM7Ffp+QopIJ4hnfExgxXCZccfx/DxJKfoKLWST1cujlwE+T/UAupTYz7cXdHFpVgnhPjhGm5Kze8AHxr/gQPEiMMq4dbV0+0h8Ci9oKpVTBWhU0dxfFPO1GU2U4cIPo6PWAHr+2HeKF7x1JIt9S038V7aJoI9/YPclYNo7HaWwpfjHpFUZWSUarE3brWW5FBEH9pIDh5gYcT/vWsLWBr/xkykAyCyJB/X3xpBQKSKbWIztUnZUAyHNquxw1qYHYRo2RQOb+tid61na3rZOzppJGoOmWGyqzzhFKvPP4y5qQB7LYeOv6hiHGdKB/jA3WuTGZ1VcMF2sV1Obecw2rHLfG72+gV7EidaPtVi6mngSeaC9SbfgA==; 5:hZDxCJOO8YNzXgc6TTURDJjZAqfhBvHRs8n1l+WvdeKlDdLCvz6XdGkd8DMXta7Od9D47iomDWo4zXHybQuW1z9tRYkVtmEIfReDbr4gHqgxVN5KofBImomevwy48uZ+sKZzRvLwcUdXTv3nh2ZLnEQP/Ux7v7p22DotJddnsRc=; 7:MBIqPV77ipllm3Sq5CBthEnfjveyjl+WBAYk+n6gUQuGpZ1LFJ7o6xe9Eb3/tBrXhSpKjROOg4tVnzboFoRYkaSts/EktqWzhFuwmP3vrSWQeFyyGjVvqDzZhYmor2UuFicIQ7HSdoUgzJyD6s14+fgeF6rrnsh0bqr+w9V+veRkOejiO9z6OYCOYLMnxVaBClBIgANbA3zP64S19C2BUWN0LmuP54CXsACC3ZmzNayiKxOba830MCK8wQLTuCdH x-ms-office365-filtering-correlation-id: d7663944-a87c-4c75-880d-08d627938e02 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4831; x-ms-traffictypediagnostic: VI1PR07MB4831: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:VI1PR07MB4831; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4831; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(396003)(136003)(189003)(13464003)(199004)(51444003)(8676002)(1556002)(2501003)(476003)(4326008)(68736007)(6486002)(97736004)(105586002)(15650500001)(102836004)(6436002)(1941001)(44736005)(316002)(386003)(8936002)(6306002)(6506007)(53546011)(9686003)(6512007)(2906002)(305945005)(7736002)(86152003)(84392002)(110136005)(53936002)(99286004)(106356001)(81156014)(81166006)(229853002)(14496001)(5250100002)(93886005)(71190400001)(446003)(33896004)(256004)(14444005)(71200400001)(14454004)(25786009)(2900100001)(6246003)(86362001)(966005)(5660300001)(186003)(76176011)(3846002)(486006)(34290500001)(26005)(52116002)(66066001)(6116002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4831; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RwQTcdtsIz7oazFOaN6PEktmDWH6f0zbG/nt+DK1Z+vIc2vNf4sJzDW3xrGezAW6UwXj1u/id9rFf5Y8mxxAt3ZT0MX7enussWkifpwSQisXZO6abu8HbauuxT+Ts2ReNuiNbyWzebrBJAUUGu+d6HS3QiH90URM535Rj1EDVB3nU6vXA7mzAi0MTGxWfB5o6n8jpSPhneVw4kG7D3iM9HOmyiy9utl9IRaQ7HfNC5s/muXVh1Fz5oI2W8Dcx6c3OC6f7gAXwz++BskcTp1Fu7aWG2vUXdR0yJ/thOciXbrRmflddBCpIsvEqxJlVC4FTB0WCO7UT99o/JDA1xDXLEVF4XVcpx0Sukym/vM0dGs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7663944-a87c-4c75-880d-08d627938e02 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 11:46:42.6298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4831 Archived-At: Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:46:50 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkFkcmlhbiBGYXJyZWwiIDxhZHJp YW5Ab2xkZG9nLmNvLnVrPg0KU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyOSwgMjAxOCAxMjo1 MSBBTQ0KDQpBbGwsIHRoZSBzY29wZSBoYXMgYmVjb21lIGVsYXN0aWMgb3ZlciB0aW1lLg0KDQpX aGVuIHdlIGZpcnN0IHdyb3RlIGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlv bnMgd2Ugd2VyZQ0KYWRkcmVzc2luZyBhIHZlcnkgc3BlY2lmaWMgcHJvYmxlbTogZHJhZnRzIGFu ZCBSRkNzIGNvbnRhaW4gZnJhZ21lbnRzDQooZXhhbXBsZXMpIG9mIFlBTkcgKG5vdCB0aGUgWUFO RyBtb2R1bGVzIHRoZW1zZWx2ZXMsIGJ1dCBleGFtcGxlcyB3aXRoDQphY3R1YWwgdmFsdWVzKS4g VGhvc2UgZnJhZ21lbnRzIG9mdGVuIGV4dGVuZCBvdmVyIDczIGNvbHVtbnMgYW5kIHNvIGhhdmUN CnRvIGJlIHdyYXBwZWQgZnJvbSBwcmVzZW50YXRpb24gaW4gdGhlIGRyYWZ0L1JGQywgYnV0IHRo aXMgY3JlYXRlcw0KaW52YWxpZCBZQU5HLiBTbyBzb21lIGZvcm0gb2YgZG9jdW1lbnRhdGlvbiBj b252ZW50aW9uIGlzIG5lZWRlZCB0bw0KaW5kaWNhdGUgdGhhdCB0aGUgZXhhbXBsZXMgc2hvdWxk IG5vdCBiZSB0cmVhdGVkIGFzIHZhbGlkIFlBTkcgYW5kIHRvDQpoZWxwIHNvbWVvbmUgbWFwIHRo ZW0gdG8gdmFsaWQgWUFORy4NCg0KTW9zdCBkb2N1bWVudHMgdGhhdCBlbmNvdW50ZXJlZCB0aGlz IHByb2JsZW0gZWl0aGVyIGRvZGdlZCBpdCAoaG9waW5nIGENCnJldmlld2VyIHdvdWxkIG5vdCBj b21wbGFpbikgb3IgZGVmaW5lZCB0aGVpciBvd24gbGluZSB3cmFwcGluZyBydWxlcy4NCldlIHRo b3VnaHQgaXQgd291bGQgYmUgaGVscGZ1bCB0byBoYXZlIGEgY29tbW9uIGFwcHJvYWNoIGFuZCB0 aGF0IHdhcw0Kd2hhdCB3ZSBmb2N1c2VkIG9uLg0KDQpXZSBhbHNvIG5vdGljZWQgdGhhdCAocHJv YmFibHkgZm9yIGZvcm1hdHRpbmcgcmVhc29ucykgdGhlIGV4YW1wbGVzIHdlcmUNCm9mdGVuIGJl aW5nIHByb2R1Y2VkIHVzaW5nIHRoZSA8YXJ0d29yaz4gY29uc3RydWN0IGluIHRoZSBzb3VyY2Ug WE1MLiBTbw0KaXQgc2VlbWVkIHRoYXQgdGhlcmUgd291bGQgYmUgdmFsdWUgaW4gZGVmaW5pbmcg aG93IHRoYXQgYXJ0d29yayBjb3VsZA0KYmUgYXV0b21hdGljYWxseSB3cmFwcGVkIGFsbG93aW5n IHRoZSBhdXRob3JzIHRvIG5vdCB3b3JyeSBhYm91dCBsaW5lDQp3cmFwcGluZy4NCg0KV2UgcmVj b2duaXNlZCB0aGF0IHdyYXBwaW5nIGZpZ3VyZXMgd291bGQgcHJvYmFibHkgYmUgY29uZnVzaW5n IGFuZA0KY291bnRlci1wcm9kdWN0aXZlIHNvIHdlIHJlY29tbWVuZCBhZ2FpbnN0IGl0LiBBbmQg d2UgbWFkZSBpdCBhbg0KZXhwbGljaXQgdGhpbmcgbm90IGEgZGVmYXVsdC4NCg0KQ29udmVyc2Vs eSwgd2Ugbm90ZWQgdGhhdCBvdGhlciAic2FtcGxlIGNvZGUiIG1pZ2h0IGJlbmVmaXQgZnJvbQ0K d3JhcHBpbmcsIHNvIHdlIHRob3VnaHQgdGhhdCBzaG91bGQgYmUgaW4gc2NvcGUuDQoNClRoZW4g d2UgbWVyZ2VkIG91ciBlZmZvcnRzIHdpdGggS2VudCdzLg0KDQpUaGF0J3MgaG93IHdlIGdvdCBo ZXJlLg0KDQoNCk5vdywgdG8gdGFrZSBpdCBmb3J3YXJkLCBJIHdvdWxkIGxpa2UgdG8gY29uc3Ry YWluIG91ciBlZmZvcnRzIHRvDQpzb2x2aW5nIHRoZSBwcm9ibGVtIGF0IGhhbmQuIElmIG91ciBz b2x1dGlvbiBoYXMgd2lkZXIgYXBwbGljYWJpbGl0eSwNCnRoYXQncyBncmVhdC4gQnV0IGNhbiB3 ZSByZWNvZ25pc2UgdGhhdCB0aGUgb3ZlcndoZWxtaW5nIGJ1bGsgb2YgY2FzZSB3ZQ0Kc2VlIHRv ZGF5IGFyZSBpbiBZQU5HIGRvY3VtZW50cyBhbmQgdGhhdCdzIHVwIHRvIHVzIHRvIHNvbHZlLg0K DQo8dHA+DQoNCkFkcmlhbg0KDQpUaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCB3YXkgZm9yd2FyZDsg aXQgY2FsbHMgZm9yIGEgbnVtYmVyIG9mIGNoYW5nZXMsDQp0aWdodGVuaW5nIHRoZSBhcHBsaWNh YmlsaXR5IGluIHNlY3Rpb25zIDEsIDIsIDMgYW5kIDQgSU1PLg0KDQpUb20gUGV0Y2gNCg0KVGhh bmtzLA0KQWRyaWFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0 bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdh dHNlbg0KPiBTZW50OiAyOCBTZXB0ZW1iZXIgMjAxOCAyMzowNQ0KPiBUbzogdG9tIHBldGNoDQo+ IENjOiBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LWt3YXRzZW4tbmV0bW9kLQ0KPiBhcnR3b3JrLWZvbGRp bmctMDcudHh0DQo+DQo+DQo+IEhpIFRvbSwNCj4NCj4gQXMgY29udHJpYnV0b3IsIEkgYWdyZWUg d2l0aCB5b3UuICBUaGUgb25seSByZWFzb24gdGhhdCBpdCBpcyBoZXJlDQo+IG5vdyBpcyBiZWNh dXNlIGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVudGlvbnMgZGlkLg0KPg0KPiBB cyBjaGFpciwgbGV0IG1lIGRpc2N1c3Mgd2l0aCBteSBjby1jaGFpcnMuICBNZWFud2hpbGUsIHdv dWxkIGxvdmUNCj4gdG8gaGVhciBvdGhlcnMgb3BpbmlvbnMuDQo+DQo+IEtlbnQNCj4NCj4NCj4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPg0KPiDvu79LZW50DQo+DQo+IFN0ZXBwaW5n IGJhY2ssIEkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW0gb2YgYXBwbGljYWJpbGl0eS4N Cj4NCj4gWW91IGhhdmUgbGFiZWxsZWQgdGhpcyBJLUQgZHJhZnQuLm5ldG1vZC4uIGFuZCBhcmUg ZGlzY3Vzc2luZyBpdCBvbg0KdGhlDQo+IG5ldG1vZCBXRyBsaXN0LiAgVGhlcmVmb3JlIEkgYXBw bHkgaXQgdG8gWUFORyBJLUQgLSB0byBtZSwgdGhhdCBpcyB0aGUNCj4gb2J2aW91cyBjb25uZWN0 aW9uIC0gYW5kIHRoZSBwcm9ibGVtIEkga2VlcCBzZWVpbmcgd2l0aCBZQU5HIEktRCBpcw0KPiBs aW5lcyB0b28gbG9uZyAtIGNvbW1lbnQsIGRlc2NyaXB0aW9uIC0gaW4gdGhlIFlBTkcgbW9kdWxl IHNvIHRoYXQgaXMNCj4gdGhlIHByb2JsZW0gZm9yIHdoaWNoIEkgd2FudCBhIHNvbHV0aW9uIChJ IHNlZSBubyBwcm9ibGVtIHdpdGggY29kZQ0KPiBzbmlwcGV0cykuICBUaGlzIGhhcyBzb21ldGhp bmcgdG8gZG8gd2l0aCwgSSBrbm93IG5vdCB3aGF0LCB0aGUNCj4gcHJvY2Vzc2luZyBjeWNsZSBv ZiBZQU5HIG1vZHVsZXMsIG9mIHRoZSBtb2R1bGUgYmVpbmcgZ2VuZXJhdGVkDQpvdXRzaWRlDQo+ IHRoZSBJLUQvUkZDIHByb2Nlc3MgYW5kIHRoZW4gYmVpbmcgaW5zZXJ0ZWQgd2l0aG91dCB0aGUg Y29uc3RyYWludHMNCnRoYXQNCj4gdGhlIEktRC9SRkMgcHJvY2VzcyBub3JtYWxseSBhcHBseTsg SSByZWNhbGwgQmVub2l0IGdpdmluZyBhbg0KPiBleHBsYW5hdGlvbi4NCj4NCj4gSG93ZXZlciwg d2hlbiBJIGlnbm9yZSB0aGUgSS1EIG5hbWUgYW5kIHRoZSBsaXN0IHdlIGFyZSBvbiwgYW5kIHRh a2UNCnRoZQ0KPiB0ZXh0IGluIGlzb2xhdGlvbiwgdGhlbiBJIHdvbmRlciB3aGF0IGFyZSB3ZSBk b2luZyBoZXJlLiAgVGhpcyBzaG91bGQNCmJlDQo+IG9uIGEgZGlmZmVyZW50IGxpc3QsIGFydCBw ZXJoYXBzIG9yIHRoZSBtYWluIGlldGYgbGlzdCwgc2luY2Ugd2hhdCB5b3UNCj4gYXJlIHByb3Bv c2luZyBoYXMgbm90aGluZyB0byBkbyB3aXRoIG5ldG1vZCwgWUFORyBvciBhbnkgb2YgdGhlIHRv cGljcw0KPiB0aGF0IHRoaXMgbGlzdCBkaXNjdXNzZXM7IHJhdGhlciBpdCBzZWVrcyB0byBjaGFu Z2UgdGhlIHdob2xlIG9mIHRoZQ0KPiBJRVRGLg0KPg0KPiBTbywgcHV0IHRoaXMgdXAgZm9yIGFk b3B0aW9uIGFuZCBJIHdpbGwgb3Bwb3NlOyB0aGlzIGlzIG91dHNpZGUgb3VyDQo+IHJlbWl0Lg0K Pg0KPiBUb20gUGV0Y2gNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Mon Oct 1 04:58:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614DD130E4C; Mon, 1 Oct 2018 04:58:08 -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, 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 og50iLqBUNTi; Mon, 1 Oct 2018 04:58:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0542A120072; Mon, 1 Oct 2018 04:58:06 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 935E11AE03DD; Mon, 1 Oct 2018 13:58:04 +0200 (CEST) Date: Mon, 01 Oct 2018 13:58:03 +0200 (CEST) Message-Id: <20181001.135803.1710253729017224743.mbj@tail-f.com> To: netmod-chairs@ietf.org Cc: draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <99C61F4F-6826-4FB5-87A1-77BED624B53D@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 11:58:09 -0000 Hi, Andy Bierman wrote: > On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli wrote: > > > This is start of a two week poll on making > > draft-ietf-netmod-module-tags-02 a NetMod working group > > document. > > > > > I think we did this step already. > https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html > > Otherwise how would the draft be named draft-ietf-netmod? > Maybe you mean to start a WGLC, which I also support. Chairs, can we get a clarification on this? Did you mean to start a WGLC? /martin > > > Andy > > > > You may review at: > > https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 > > > > Please send email to the list indicating "yes/support" or "no/do not > > support". If indicating no, please state your reservations with the > > document. If yes, please also feel free to provide comments you'd like > > to see addressed once the document is a WG document. > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Mon Oct 1 07:25:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24C130E72; Mon, 1 Oct 2018 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 TtrePoXqL2WQ; Mon, 1 Oct 2018 07:25:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DA7130DFA; Mon, 1 Oct 2018 07:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1538403927; x=1539613527; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Yj2yxNN2ONQodvkSXHn3UfKQV+14l1lyaOjM4ADD2uI=; b=M61fEQ+8tVnx1hw746s9vhYrjeHabYTs3Ba1Rk7FOrSuVcptyyGdIAxq N7xzVHmclQuV/Ny48/u/3iP818sr9zh7pU+kcXBKeKTzpOKY7oC94bENJ UAkKa+P2Sz+4BQFCkn0LoB16hQck8JT7SCJAWoEIihMr5koVZsfc2PnPn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AAABLbJb/4wNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUYIOZn8oCoNqiBWMGYVKkx2BegsYC4QDRgIXg3khNBgBAwE?= =?us-ascii?q?BAgEBAm0cDIU5AgEDAQEhETobAgEIDgwCJgICAiULFRACBAESgyEBggEPpDW?= =?us-ascii?q?BLooFBYELiXcXggCBEicfgkyDGwEBgWGDATGCJgKdKQkChkOJbxeBR44Igli?= =?us-ascii?q?GIYMTiH4CERSBJR04gVVwFTsqAYJBixaFPm8Mi1uBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,327,1534809600"; d="scan'208";a="179292148" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 14:25:25 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w91EPPls003933 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2018 14:25:26 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 10:25:24 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Mon, 1 Oct 2018 10:25:24 -0400 From: "Acee Lindem (acee)" To: Martin Bjorklund , "netmod-chairs@ietf.org" , "netmod-ads@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] YANG module security considerations template - TLS reference Thread-Index: AQHUWVcibcIX1/iYHk+KxriwIydA+qUKcn+A Date: Mon, 1 Oct 2018 14:25:24 +0000 Message-ID: <43AB5D62-FCB5-4B84-841E-30F14235A147@cisco.com> References: <20181001.091910.1896030373672380031.mbj@tail-f.com> In-Reply-To: <20181001.091910.1896030373672380031.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.9.101] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netmod] YANG module security considerations template - TLS reference X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 14:25:37 -0000 QWdyZWVkIC0gYWx0aG91Z2ggSSdtIG5vdCBzdXJlIHdobyBoYXMgY29udHJvbCBvdmVyIHRoZSB0 ZW1wbGF0ZSBlaXRoZXIuIA0KDQpGb3IgZHJhZnRzIHRoYXQgYXJlIGluLXByb2dyZXNzLCBJRE5J VHMgd2lsbCBmbGFnIHRoaXMgb2Jzb2xldGUgcmVmZXJlbmNlIGFuZCwgZm9yIGF0IGxlYXN0IG9u ZSBvZiB0aGUgZHJhZnRzIEknbSBhbiBlZGl0b3IsIEkndmUgYWxyZWFkeSBtYWRlIHRoZSB1cGRh dGUuDQoNClRoYW5rcywNCkFjZWUgDQoNCu+7v09uIDEwLzEvMTgsIDM6MTkgQU0sICJuZXRtb2Qg b24gYmVoYWxmIG9mIE1hcnRpbiBCam9ya2x1bmQiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAg SW4gdGhlaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLCB0aGUg SUVTRw0KICAgIHN1Z2dlc3RlZCB3ZSB1cGRhdGUgdGhlIHJlZmVyZW5jZSB0byBUTFMgZnJvbSBS RkMgNTI0NiB0byBSRkMgODQ0Ng0KICAgICh3aGljaCBvYnNvbGV0ZXMgNTI0NikuDQogICAgDQog ICAgVGhpcyB1cGRhdGUgbmVlZHMgdG8gYmUgZG9uZSB0byB0aGUgdGVtcGxhdGUgYXZhaWxhYmxl IGF0DQogICAgaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvb3BzL3dpa2kveWFuZy1zZWN1cml0 eS1ndWlkZWxpbmVzDQogICAgDQogICAgKGl0IGlzIG5vdCBxdWl0ZSBjbGVhciB3aG8gaXMgcmVw c29uc2libGUgZm9yIHRoaXMgdGVtcGxhdGU7IG1heWJlDQogICAgdGhhdCBzaG91bGQgYmUgY2xh cmlmaWVkIG9uIHRoZSBwYWdlKQ0KICAgIA0KICAgIA0KICAgIC9tYXJ0aW4NCiAgICANCiAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1v ZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo= From nobody Mon Oct 1 11:25:17 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEEF128C65 for ; Mon, 1 Oct 2018 11:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP94TveOFUiE for ; Mon, 1 Oct 2018 11:25:13 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 DDB481252B7 for ; Mon, 1 Oct 2018 11:25:13 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91IOTal011664; Mon, 1 Oct 2018 11:25:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=JnzbWKZsqhXGGxpVJDnQdFY9f0Dk1UbTNzhoky0MD08=; b=jXVgeBE+S4NxAo0M1UAWF+DNXQGRNZhRnGLqN2hut5r8FTHG2qPjdBdp6udKWiLnanSI 8qd1gMzD7tuMbSb74wgT/d7fkDGntJZClacrXGx4eWsgEmVboOeETmPOBH0DKKIscGtM gOO9R6Rk0fXLPbZlbmrv7CyO5JHrjlq3oYBCgUy1kPwC9pfUY9IQDNdExsJYQgzjM9HR X+JxzvYGt/MIk2JgjCuqSC+IVYUmpeG/LBRKWmAy9L/BmxlLlCMDf8UsojPpx+bq/a/E aEDTIsEH6TBJK53BWun9Wd3/xknm/uSYA1c94o8F94z7nefxEiWMrxKn5c80reBi8mjp Zg== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0022.outbound.protection.outlook.com [207.46.163.22]) by mx0a-00273201.pphosted.com with ESMTP id 2mupqug9gr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Oct 2018 11:25:09 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4652.namprd05.prod.outlook.com (20.176.109.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.13; Mon, 1 Oct 2018 18:25:07 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Mon, 1 Oct 2018 18:25:07 +0000 From: Kent Watsen To: tom petch , "adrian@olddog.co.uk" CC: "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt Thread-Index: AQHUUaLhqK0+eVIcY0e09cIrm611d6UKgdgA Date: Mon, 1 Oct 2018 18:25:07 +0000 Message-ID: References: <056001d451a2$d3412240$4001a8c0@gateway.2wire.net> <1A7EF333-2DA0-4D51-B44C-63AF3D6D628B@juniper.net> <034a01d454b4$caf3aa80$4001a8c0@gateway.2wire.net> <045c01d45723$d2f17b60$4001a8c0@gateway.2wire.net> <906263FB-874E-427B-9119-3936B987C42B@juniper.net> <065301d45786$3b9b88b0$b2d29a10$@olddog.co.uk> <031501d4597c$5538f580$4001a8c0@gateway.2wire.net> In-Reply-To: <031501d4597c$5538f580$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4652; 6:l+fdIUfDuFiutCamQQjwbmvELV1yUQPd5N+2JF8VdW2lxFT4mO/HfbNmZIBWcouyquJ11rzhJB8+ug4etm/GFJmv7wLbnPxCDD4JjORUbh95RNsSMKoDG3J0BJ3l2T7XHERWw/Xv02EfQBUJNCIG5Jw8fE3LFewz671vssSZX3PXgrdTRctawEFsc04IgRyq5JC0BZJz18Ajw/cynaDffZixXNuLSDbwMH9VIu8MZUhz7M2oGCRLmiTa9k46aTHRCHt6+fN8zlpRdJXb/dO22MEhOsKCRE/Xo8TT2O/xg5fBJc7/EhDqPEfIb21ZI1SkM1Ijpfzf7zxbzENX12jrhLZeQdBiIaNdZPmWqDTTVKu/XUTL/kjSNF4QfmM9nSpuPROZYjIM0Xb905KsqtndBT8+5x3P+IyZT6e1ZbVhAQuWtcb0a5Gtot3725CGth+PnUeXSLG5bWTWpIqYdyGbSA==; 5:Uc27WPSR5UEbqaWmapeU+N7SogEt+1Evsid8YHnJqCNrOVFOXLlbf9uI4ipRg7vaZ9eoc5Jndcv88EX0rvslxIrNPo0pqhINXECf47MptPH0xQGpYEfABDJ9MoBY+UWECoSYp81+afYY+R8SbtnoVW/rWyYWQ39C/x1i9htKuPg=; 7:Z0tSuG3F5WRWkJ0fzrYcmRDyLsLQbC/laSsCnjc6coDMFBJnFy39SqDZ7UdjIZPcOPWIAu61/zEe/xuNUcaSmmJAbVvgNWyoT4CG8t2Lop6hmMPMB85y0z6ySuDdCT1A5fKwMk4RvELtd9HWEi24OgB+pvO71+D3y3Wc243pHMu9008lWT93kdxbHuyjUoMaAFnemQ3EbC7Lkqw8KE/hSL4Abtj55OSodhQ4IkFYE8SdWfbIvDWTW/Qxdcm5Sl2J x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c1235326-d46c-414a-d2ae-08d627cb371d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4652; x-ms-traffictypediagnostic: DM6PR05MB4652: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4652; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4652; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(396003)(346002)(376002)(189003)(199004)(11346002)(82746002)(6512007)(478600001)(36756003)(186003)(25786009)(97736004)(66066001)(5660300001)(4326008)(58126008)(305945005)(26005)(229853002)(6486002)(33656002)(6116002)(3846002)(6436002)(102836004)(256004)(86362001)(14454004)(6246003)(2906002)(2900100001)(8936002)(486006)(105586002)(106356001)(81166006)(83716004)(81156014)(2501003)(8676002)(110136005)(5250100002)(99286004)(6506007)(68736007)(76176011)(53936002)(296002)(446003)(476003)(71200400001)(7736002)(71190400001)(93886005)(316002)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4652; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: qMkNYHuDNBA3um/GtvcsOvqbaGJfnoM/UTskrKBaq6tdr37YKB3WLo1yLEYfnxf69cmhFBiDENjPy+9N7yiC4rwX+JeW+Bgck2p+iojhIlf1MVcU6sS5Zb0c/nvXEexpWrD/L1tuNuQ/DBN+rECnVbwePSlDXsgAbT+wUCLk4xpVdR5M56/TwKE/r8p5XJyp5awB1M9Z9/SIi1UWCB0i1eXYmj+y7FeVvK4joXoeGCrWR1Pl+7E9h24x9aVAroghpkvgyfx/jsd2vWJ0KbA4jzqoDLpozhrFB28ann9CLjQqCiPpzTjM0K8viZGZR8Z7JyQaOUdlM/nlXI3nXNCqXV4BJlK82wJZRvuKI9vncqY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <945FFC563A3B224E87BB301BF5238FBB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c1235326-d46c-414a-d2ae-08d627cb371d X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 18:25:07.5749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4652 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010176 Archived-At: Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:25:16 -0000 DQo+PiBOb3csIHRvIHRha2UgaXQgZm9yd2FyZCwgSSB3b3VsZCBsaWtlIHRvIGNvbnN0cmFpbiBv dXIgZWZmb3J0cyB0bw0KPj4gc29sdmluZyB0aGUgcHJvYmxlbSBhdCBoYW5kLiBJZiBvdXIgc29s dXRpb24gaGFzIHdpZGVyIGFwcGxpY2FiaWxpdHksDQo+PiB0aGF0J3MgZ3JlYXQuIEJ1dCBjYW4g d2UgcmVjb2duaXNlIHRoYXQgdGhlIG92ZXJ3aGVsbWluZyBidWxrIG9mIGNhc2UNCj4+IHdlIHNl ZSB0b2RheSBhcmUgaW4gWUFORyBkb2N1bWVudHMgYW5kIHRoYXQncyB1cCB0byB1cyB0byBzb2x2 ZS4NCj4NCj5UaGF0IHNvdW5kcyBsaWtlIGEgZ29vZCB3YXkgZm9yd2FyZDsgaXQgY2FsbHMgZm9y IGEgbnVtYmVyIG9mIGNoYW5nZXMsDQo+IHRpZ2h0ZW5pbmcgdGhlIGFwcGxpY2FiaWxpdHkgaW4g c2VjdGlvbnMgMSwgMiwgMyBhbmQgNCBJTU8uDQoNCkknbSB1bnN1cmUgd2hhdCB0aGUgcHJvYmxl bSBhdCBoYW5kIGlzLCBidXQgdGhlcmUgaXMgbm90aGluZyBORVRNT0QNCnNwZWNpZmljIGFib3V0 IHRoaXMsIGFuZCB3ZSAodGhlIElFVEYpIHdvdWxkbid0IHdhbnQgZWFjaCBXRyByb2xsaW5nDQp0 aGVpciBvd24gc29sdXRpb24uICBBbHNvLCBub3RlIE1hcnRpbidzIHN0cm9uZyBvYmplY3Rpb24g dG8gc2VlaW5nDQp0aGlzIGJlaW5nIHVzZWQgZm9yIHRyZWUtZGlhZ3JhbXMgYW5kIHlhbmcgbW9k dWxlcywgc28gZXZlbiBsZXNzIA0KTkVUTU9EIHNwZWNpZmljLi4uDQoNCkFkcmlhbiBwcmV2aW91 c2x5IHdyb3RlICJTbyBpdCBzZWVtZWQgdGhhdCB0aGVyZSB3b3VsZCBiZSB2YWx1ZSBpbiANCmRl ZmluaW5nIGhvdyB0aGF0IGFydHdvcmsgY291bGQgYmUgYXV0b21hdGljYWxseSB3cmFwcGVkIGFs bG93aW5nIHRoZQ0KYXV0aG9ycyB0byBub3Qgd29ycnkgYWJvdXQgbGluZSB3cmFwcGluZy4iICBJ IGFncmVlLCB0aGUgdWx0aW1hdGUNCmdvYWwgd291bGQgYmUgdG8gaW50ZWdyYXRlIHRoaXMgd2l0 aCBgeG1sMnJmY2AsIGJ1dCBpdCBzaG91bGQgYmUgZnJlZQ0KdG8gZG8gc28gd2l0aG91dCByZWdh cmQgZm9yIHdoYXQga2luZCBvZiBhcnR3b3JrIGl0IGlzLCBvciBmcm9tIHdoaWNoDQpXRyBpdCBj YW1lIGZyb20uDQoNCldoZXJlIGluIG91ciByYXRoZXIgbGliZXJhbCBORVRNT0QgY2hhcnRlciBz YW5jdGlvbnMgdGhpcyB3b3JrPw0KDQpLZW50IC8vIHBpY2sgYSBoYXQNCg0KDQoNCg== From nobody Mon Oct 1 11:32:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7154130E6B; Mon, 1 Oct 2018 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmhieeWC9Kiz; Mon, 1 Oct 2018 11:31:56 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0773F127598; Mon, 1 Oct 2018 11:31:55 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91IT17U015259; Mon, 1 Oct 2018 11:31:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=lPz2ouSi0H01S+5gGJdlXiSdtqSdemIg/idQl5mD0as=; b=qGIs8egLcVfsLGgJ4crvPAhG+QMZobiNcuiuUWwlCfmhkQLp6GJnKsTmkQ57wGdxaukD kKX42MB1tcBZrTNq73j7fz3CIuQkV02fk42Pd0TkVQw9XmyBgZP1NmaI7Fvq13tscP2a lEZsF1IfabLkcpBzHxn3VN/0ASPdJizsuzDNzEYiKpQ3QdZ45isIbCLH/SEpQG+fXO+t BVQ6AYv/3aSoFL6mLcheFtXdYtLh8YI42Xc5w8H/FAGmI4cPTWFM2bnW0chlQvaPnOYA Q7CWXI0PMFjthoi5vx5fGN779gPL9O9hw4n4RAqIJxaCqWxr74pZGlfDXx/urJGPc9/o jg== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0120.outbound.protection.outlook.com [216.32.181.120]) by mx0b-00273201.pphosted.com with ESMTP id 2mun3jghfr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Oct 2018 11:31:54 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4761.namprd05.prod.outlook.com (20.176.110.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Mon, 1 Oct 2018 18:31:51 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Mon, 1 Oct 2018 18:31:51 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Martin Bjorklund , "netmod-chairs@ietf.org" , "netmod-ads@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] YANG module security considerations template - TLS reference Thread-Index: AQHUWVcThVBzOGZb3U6r7WxKf3RM96UKcoAAgAAB0QA= Date: Mon, 1 Oct 2018 18:31:51 +0000 Message-ID: <4BF93030-3371-417B-A897-61A44464834C@juniper.net> References: <20181001.091910.1896030373672380031.mbj@tail-f.com> <43AB5D62-FCB5-4B84-841E-30F14235A147@cisco.com> In-Reply-To: <43AB5D62-FCB5-4B84-841E-30F14235A147@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4761; 6:GBw64n95CA1hDG+QVm/OaAHgwGpNPzrA1NrkfL/F8tssR4AQ0Sa6m48x5871MIayMHwE6nvdj25l6o1PQ7sMOqIXJVCkRmLp18VRk3DdRzrg3pGWP61Ujc9Qu19leEB0WT5eoEr5OhZR1C6hrjKu2w/5lHB+GGbmof2zE1bj3AXqisSOa+bLiTyNtO2R/FeJ1RBZl3DdsDTytnCUxbFxMOHPmtoVUwc1T3JRiwH6hjMQaSvJ1ZA83rKXtnHpoET7x7aCswGQreWqHySoOUF5T8LS7YyfLbXelJtr5J3oPLuA5/1MJv809XWTP0tXhffCtmjQmdKn8Be0HC1V8SUCYUtl6wBSXv2YlnQLXN2ReJpyq94bVux+35MmkJvjNI1Sk+/iE8Rp06U9cYJjmFgFivANcjuQ1lg7EE5bfFevSTEgdDUG/dNzoDqbs2nx4pDFU3tbf7Omo7lbAB82auhgsg==; 5:2I5JSsn5HvNfO0gdGQUXmEA3CPxi0oeKRKnJaBOUTt0kfWJo5gOEpy43NMoWksdQY7zRc27H33To//dVAsc26k+Jgj3OqCk81pRvfcwzbwexz79Um6ANi0SjKOLHfnqtLm2skakYar37sw9CHBov5pqTDJRltqj8l0hCh/+/BAg=; 7:oNvXkZ2OUWdFTuMX3H99O1S+t07iBGyMQv35DFZtN3GrhAAwdih6plcixG01X9mdYgkqTr87Cxa881xvQ1iwX8BtHy9AjlDtV1p2DZ/F2fJoXfiC3s6gC4h8A5ycl1+RNxV7AbcqusjXSgHb4niG3NXv6Z1vqWujWwiBqhJbrCKiE09rjYvO9iCM0ymyoMTGMnzIVgkCSRIY/ixONJCDEIMWCeON1vN0nWNVkulRlUwLy0Y5lBEp4cuzIw+jAELw x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b367d7a0-58b1-47c5-608d-08d627cc280d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4761; x-ms-traffictypediagnostic: DM6PR05MB4761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(10436049006162)(95692535739014)(50582790962513)(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(10201501046)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051); SRVR:DM6PR05MB4761; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4761; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(396003)(376002)(136003)(189003)(199004)(13464003)(86362001)(2906002)(14444005)(6506007)(53936002)(575784001)(256004)(53546011)(6246003)(2201001)(6306002)(5660300001)(8676002)(6512007)(81156014)(81166006)(2501003)(7736002)(106356001)(11346002)(58126008)(76176011)(8936002)(33656002)(110136005)(2900100001)(316002)(99286004)(5250100002)(25786009)(83716004)(486006)(6486002)(102836004)(966005)(36756003)(71200400001)(6436002)(71190400001)(478600001)(186003)(97736004)(14454004)(15650500001)(2616005)(82746002)(305945005)(3846002)(446003)(68736007)(476003)(26005)(66066001)(229853002)(105586002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4761; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: rEbDrkxHDfZCB3Qik0zVpkURoJai9Ozi4dTm7xll/2DnGAsrR4JDYgS+Kp9fQToOjT0MWAw3p/1sdIh1/UvlsSZafdeXau1vPN/6vAQ+6KFHzLbxnft7ybWMFgU1E4wvDud1TSe4v0kHToKHX3qqJGM0ZKHiHnD/9WhgMZ8WG/Mwe6bCu72EAXv36+ULgV+czMbBFduCubghyeOA7axFqo9uxzAo2QtBM41qEptH41m/b/VDiS03UKyHCNqoGvlK4MLgtwBs9uDyoImhz4lVEonrpsP3sIkSiPHAI0SN/YXDyDT1kXZ3zRZkdA1C18B7d0zzrMyPRoK6Qm9SUFELuzy8n88KDjcmeX083uRP5WE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <395241A673FAF348BB0558CE9A27FC4F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: b367d7a0-58b1-47c5-608d-08d627cc280d X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 18:31:51.7830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4761 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010177 Archived-At: Subject: Re: [netmod] YANG module security considerations template - TLS reference X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:31:59 -0000 QmVub2l0IGlzIHRoZSBwcm9nZW5pdG9yIG9mIHRoZSB0ZW1wbGF0ZS4gIEkgdG9vayBpdCB0byBi ZSBhbiAiQUQgdGhpbmciDQpoYXMgc2luY2UgcGFzc2VkIHRvIElnbmFzLg0KDQpLZW50DQoNCg0K DQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIkFjZWUgTGluZGVtIChhY2Vl KSIgPGFjZWVAY2lzY28uY29tPg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDEsIDIwMTggYXQgMTA6 MjUgQU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4sICJuZXRtb2QtY2hh aXJzQGlldGYub3JnIiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4sICJuZXRtb2QtYWRzQGlldGYu b3JnIiA8bmV0bW9kLWFkc0BpZXRmLm9yZz4sICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2R1bGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgdGVtcGxhdGUgLSBUTFMgcmVmZXJlbmNlDQpSZXNlbnQtRnJvbTogPGFsaWFzLWJv dW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IDxqb2VsamFAYm9ndXMuY29tPiwgPHdhbmd6aXRh b0BodWF3ZWkuY29tPiwgPGxiZXJnZXJAbGFibi5uZXQ+LCA8a3dhdHNlbkBqdW5pcGVyLm5ldD4N ClJlc2VudC1EYXRlOiBNb25kYXksIE9jdG9iZXIgMSwgMjAxOCBhdCAxMDoyNSBBTQ0KDQpBZ3Jl ZWQgLSBhbHRob3VnaCBJJ20gbm90IHN1cmUgd2hvIGhhcyBjb250cm9sIG92ZXIgdGhlIHRlbXBs YXRlIGVpdGhlci4gDQoNCkZvciBkcmFmdHMgdGhhdCBhcmUgaW4tcHJvZ3Jlc3MsIElETklUcyB3 aWxsIGZsYWcgdGhpcyBvYnNvbGV0ZSByZWZlcmVuY2UgYW5kLCBmb3IgYXQgbGVhc3Qgb25lIG9m IHRoZSBkcmFmdHMgSSdtIGFuIGVkaXRvciwgSSd2ZSBhbHJlYWR5IG1hZGUgdGhlIHVwZGF0ZS4N Cg0KVGhhbmtzLA0KQWNlZSANCg0KT24gMTAvMS8xOCwgMzoxOSBBTSwgIm5ldG1vZCBvbiBiZWhh bGYgb2YgTWFydGluIEJqb3JrbHVuZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICANCiAgICBJbiB0aGVp ciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYsIHRoZSBJRVNHDQog ICAgc3VnZ2VzdGVkIHdlIHVwZGF0ZSB0aGUgcmVmZXJlbmNlIHRvIFRMUyBmcm9tIFJGQyA1MjQ2 IHRvIFJGQyA4NDQ2DQogICAgKHdoaWNoIG9ic29sZXRlcyA1MjQ2KS4NCiAgICANCiAgICBUaGlz IHVwZGF0ZSBuZWVkcyB0byBiZSBkb25lIHRvIHRoZSB0ZW1wbGF0ZSBhdmFpbGFibGUgYXQNCiAg ICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Ry YWMuaWV0Zi5vcmdfdHJhY19vcHNfd2lraV95YW5nLTJEc2VjdXJpdHktMkRndWlkZWxpbmVzJmQ9 RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6 a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT01NGx0MF9yQ0pUdlhF SVdtRlhzZFVORGJ6Sklrcko4NkstSXZlTDFRb0c0JnM9OXVaV05KTjZ3ZU5LS2s3QUJuWi15RlZr d2RaeFp6UU9TbTliU1h3VDFTUSZlPQ0KICAgIA0KICAgIChpdCBpcyBub3QgcXVpdGUgY2xlYXIg d2hvIGlzIHJlcHNvbnNpYmxlIGZvciB0aGlzIHRlbXBsYXRlOyBtYXliZQ0KICAgIHRoYXQgc2hv dWxkIGJlIGNsYXJpZmllZCBvbiB0aGUgcGFnZSkNCiAgICANCiAgICANCiAgICAvbWFydGluDQog ICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZo MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTbGFKZGNabyZtPTU0bHQwX3JDSlR2WEVJV21GWHNkVU5EYnpKSWtySjg2Sy1JdmVMMVFv RzQmcz1RaFpHWlBWc0docjMtdVBRWlJQeUhGY0JZejU5SzJRWnhlbmJiN0x5N0w4JmU9DQogICAg DQoNCg0K From nobody Mon Oct 1 11:48:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC797130E37 for ; Mon, 1 Oct 2018 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jGW5VHgnGxU for ; Mon, 1 Oct 2018 11:48:24 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30F41252B7 for ; Mon, 1 Oct 2018 11:48:24 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91IdGX0001248 for ; Mon, 1 Oct 2018 11:48:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=zV9pgTg/sHu0xdc7/P3hnEATIoaTvygTLIcnOHYo4jQ=; b=gAo24ADfd/rw4nxQb1tzw1EVw1059cKkLglguE8pjhCOOKTv77uBk7F4u2SIvww6jW9X KvVNA4xRHpzoJNAQK2do/AZ+iHg/ov2r+psXrMaXPnrPW5jg3CF+Zskcak4lrkyu6rdu PGrGcFZwcxesZRtWLjwBwcCl7ZzKZb5RZUbQJKvpNtLVEIloiWBC99sBmxs7c8Ey3xJb 46fgpAAHNhLeJOYRk3gdnCblK4J97G0bXH256soKg3yVbiTFTjsRuq2eKPlOfVpbfZsY ipDQJkE415FugzfY1WDNronlijwTKmMo7QLuRC8OsbeV078Tua/5nuKA+gV4xsYkbf6V aw== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0023.outbound.protection.outlook.com [216.32.181.23]) by mx0b-00273201.pphosted.com with ESMTP id 2mun220jmu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 01 Oct 2018 11:48:23 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4747.namprd05.prod.outlook.com (20.176.109.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Mon, 1 Oct 2018 18:48:21 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Mon, 1 Oct 2018 18:48:21 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdTI2nNckn+1ky1f4oa9l5TQA== Date: Mon, 1 Oct 2018 18:48:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4747; 6:qBUj6ZElE6TqCS+d5L0DMUapDzFWD53YltrXYW5NiJX0GmSKijDSo2lnXLUQjsofZ93ewFEtTtKpftVggJXtzSeqcViUGgD7KUt5aXyrNONrozA++y30hKdayayISi+XwN15kHdSIEktY3dAvDYyv5mn2cgg45fhacXbHnNk/YDD9fngoTg44hF0T3jJwlBL3iquf3aDiInYh6C3sN2WSZ1Hybjkd9EDmBN92fawDAb4l5Lw//s3NpFVhB6wBplrMN/qcQH8dXh+xnuaUnuqu8kuVumZuyzSPM+Wnu9sBCMh+wneXJ7c4TwwMuvQni56MXvUtLZ2j59yHQgbCH8nuw0JAC4HYkdGnIU0/Yl+0GTCZWgzneyNdR93K1qB8NF+VzsiThngyhQWyAIx7lXB8wyNrEYIpKiywb+FseCRHRH8cIMlVx8VHOG9Sw/Fo+Tl2R2/1tRgOBiY/qX1Xivh+g==; 5:SYkOPuUOBfgMkO+oG99dVZ+RW+8GNhXbmRNV+dd8iVwLfZZRJ3yR+VwNymZp8d4LnPAQmPYlA3j4RWOpuigVKRTQGy66dEpFDPT9FJQbaau+smWQWY2fbGhF6GPuaHzgD+9FLabrrkhT0DW8eNdtnEx00+drRMA8aL7YCHukKZY=; 7:eNFXKR4h+f95+5BduQLsPJuv6VHdCDIJG2IpczoW7aleoUIvp2nn6DM9RmLdcigJQPF+hwWh3+JroYWWrMZM6apTynEQpeHaS289CsO7ZOgnzpk9f2CVS9/ACXr1Q0NwM6vfk73UiNwT4HTuuuyOZby8Mi5H7wdcvo4NBq1+Wa2WuMLmWRUZvhxTGAxAlmhcCoElLeWTHrEHsBNjxylbjT2xN4IrYIkCmdSLnAjJ+t88/ABd5BRGmbvLeEqZv1Vd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 738e39d6-bf4a-4262-838f-08d627ce7601 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4747; x-ms-traffictypediagnostic: DM6PR05MB4747: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4747; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4747; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(39860400002)(366004)(189003)(199004)(966005)(82746002)(105586002)(14454004)(106356001)(6916009)(5660300001)(36756003)(2900100001)(6506007)(2351001)(83716004)(71190400001)(33656002)(97736004)(58126008)(71200400001)(99286004)(186003)(26005)(6346003)(2906002)(476003)(2616005)(486006)(5250100002)(8936002)(7736002)(2501003)(25786009)(305945005)(316002)(81166006)(81156014)(1730700003)(102836004)(8676002)(6486002)(68736007)(66066001)(5640700003)(256004)(6436002)(53936002)(86362001)(6116002)(3846002)(6512007)(478600001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4747; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: uReR+tjb/jkS4TSe2pwho5gmgXcW5TQAImhgoX/nkOYVoT1eYzNkCIRyHEBHcAgcDaEOhqGE4PJm98l0oiekI27/EErr/EQ3r8qCjwJ9I0X+ZmrnLlkhFz++pv4VBm2oW0UBuuxxngShum8QLuDPC1vpGGwJzvSxMIPbpcKZqH6N7o3QZeNjouHMz6rHxcEuCY50ROvaVDYIdzMBJDTuChEScFRE1SVHFTME4IJOrtwBZPAO3GRTT8hVqEzOF2gZRqJKZlbahg/nzIwFE009IZx6yMOHLV6R/2iyUmzJP8I2khNxxe/lc+uzgFH2eoDo2lKswDNxDGFNMkJ7745iRdIu5Zh++xOY5HU98fUKy7o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7CA531ABFDC17D4AAAFE266AF4519875@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 738e39d6-bf4a-4262-838f-08d627ce7601 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 18:48:21.4739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4747 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010179 Archived-At: Subject: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:48:27 -0000 VGhlIElFVEYgMTAyIGluLXJvb20gcG9sbCBzaG91bGQgcmVhbGx5IGdvb2Qgc3VwcG9ydCB0byBh ZG9wdA0KdGhpcyBkcmFmdCwgYW5kIG5vIG9iamVjdGlvbnMuDQoNClRoaXMgZW1haWwgc3RhcnRz IGFuIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQoNClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1 cHBvcnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBhZG9wdGlvbiBwb2xsLiANCklmIG9iamVjdGluZywg cGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBvbiB0aGlzIHRocmVhZC4NCg0KS2VudCAoYW5kIExv dSBhbmQgSm9lbCkNCg0K From nobody Mon Oct 1 11:48:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1C130EA8 for ; Mon, 1 Oct 2018 11:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdaQkpiOrb4y for ; Mon, 1 Oct 2018 11:48:28 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBAE130E37 for ; Mon, 1 Oct 2018 11:48:28 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91Id5wa001122 for ; Mon, 1 Oct 2018 11:48:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=aTUi2BE0OZEQt9CWBR/v0Ag7trIFnEYeJY5OytRE1yA=; b=da9SKnjNlpDuS33FCZ6BAcprLxbGSNd/GJh6j1CYJ2nRyjbtGrV0oyJnsO8j/qhSVSEk 8moaSQ0KYyLSXO75pg5MMR5QH2Z8m9ZrnFLepSdzPLjmmcuNPxYiUbvWiGwt4Hpkgkca 1/xOMUiMKJy8pmE8y5N/6mIeJIwobsJCxQFy5AynSld+1Ou1a43rbkzMPcZdtEhA3Grh Y8KrkZPS1M0lhGmPAaoYU8enVJyXTOcYV/PFWbuqMG+et4FF9V8geUI9mcC8XwOTDFxd gzIiWtUSyjqYyCE+qDEAa1RdwAinyyPlA5wYiVi3RsLfmdcJUxXsqmtkBhcdssB/orrv Aw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0021.outbound.protection.outlook.com [216.32.180.21]) by mx0b-00273201.pphosted.com with ESMTP id 2mun220jn0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 01 Oct 2018 11:48:27 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5065.namprd05.prod.outlook.com (20.177.223.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.18; Mon, 1 Oct 2018 18:48:25 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Mon, 1 Oct 2018 18:48:25 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: IPR poll on draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdVa1uJLAzfC0+Ye50AARhnBw== Date: Mon, 1 Oct 2018 18:48:25 +0000 Message-ID: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB5065; 6:OV4Rj40/sIB5iqwnc0CzKYuT5vJDBBG84E+wjftxvp4y1tziDHGSNv77HETJK1EP8vJb4r1rtvXGs7wlqti4eVwvUc0tTpsWMm6Eg47ZutdYpMJtrYwbmk82tTojzbAHtNpqh1djV2BiHG+YKCzYg7mYTBHQGpJkH3RMmjRu8IcJeCC4NHEN9Pgukby8k/tPvc05fXRKcicnazL+1tjJMw2ZOOBKmho2ewKok7ym6qSM0k9pAzNej23jYL3twcbskdTdKgL/NKP4G9EwVSztJHTCxzKBp8mrDki6t62WNt6iee2mNJjlCdLYVy4Ff7SIO5s7Y87lJXGOLJowocK5mPN79afPOKAYAhMKebOOrMfNFnIm1A+9Lvt7+NiTAotNk2+1xV6Q6OYqbIeNPASF3NuNBk1Tpr479tmFaq5cKe2xgV4cjP0q4h8SNSytUnybRJkUK+pqSLszbsnGES8ENA==; 5:K5H9tdGyCnJPhpVc9C7lSUDb6a528ahaJK6aAc7BI5/kak49+0si6zSPIX675D0ebhtwoZXQ3LEISfesh/HLjMAVmISy0AtOY0W6j/1bDHCQCaQmPTp5fMYXLFByohOzxm7xmCEypVjMx6Vb7gJuUm8WV+kOCuhcVA77TFi3+pk=; 7:yFMfxpnlL5J04CtvjuztT6DOVtuxGs+YFOeog4ftgWFPTiJX8OGlmULirdq2cvjDi/LnHC7dMTsH2CYzjwA03eKSMv+uqhMuEwduFhPbXt7CX1Y78Jt6aVMA9gso2VUXpDcscLc6T2bVEi2V2S8/bJqZBYyaDkiIy+kCKMr9vhIaoPM7/Bs3Lwab2zvH4JU32GwUUMuAcQpJ90RKs/uRiomnHMoeu/KblglD57YAtL+AReOypkEwJbM6U4Tr4waQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3aaebb92-fba3-466a-0532-08d627ce788a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5065; x-ms-traffictypediagnostic: DM6PR05MB5065: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:DM6PR05MB5065; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5065; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(346002)(366004)(199004)(189003)(1730700003)(71200400001)(86362001)(58126008)(106356001)(6916009)(2351001)(6486002)(316002)(33656002)(53936002)(186003)(2900100001)(71190400001)(102836004)(6506007)(81166006)(3846002)(82746002)(6116002)(105586002)(81156014)(68736007)(8936002)(6436002)(5640700003)(2906002)(6512007)(36756003)(97736004)(2616005)(305945005)(26005)(25786009)(476003)(8676002)(256004)(486006)(14444005)(5660300001)(14454004)(99286004)(478600001)(7736002)(2501003)(83716004)(66066001)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5065; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: NyDF1LFnnwg0MdyIuscIiSmLEyhJLo0Ln/3JMziHiloczpgmB7f06KVY6rU1mktLlbKWFry6Ui8Nv7SwzJQoqUoV90gz8f37T77XBzPc/ToeCHEYuoCM9rGtndwesYq5kBRnfZlgmhtkbqFF6omBhTKH1u9XO39xwOz7WY0aAA9gF9mZU/zE4korCH1i9WBFi/WT348WD5U/MXtgCkclFafTZ11c3rQK52FQeMNcHOjT6TVWLmpbcUPoLh3GcjuisgXvFPnTKVkXu+FgQFq+5LGV7JIo0S4DzHbt4ntBRH99p+26Hz8Ss5+pnMlmwyfWVajjq5BnaV5B3ayx8PKufc4fTjalThPB17q2LuLw240= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <10EE4BA978575149BDC08CE78B56E13C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3aaebb92-fba3-466a-0532-08d627ce788a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 18:48:25.7240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5065 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=902 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010179 Archived-At: Subject: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:48:37 -0000 VGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRh LWRpZmYtMDAuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdD8gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXM/IE5vdGUsIHlvdSBkbyBub3QgaGF2ZSB0byBiZSBhbiBhdXRo b3Igb3IgYSBjb250cmlidXRvciB0byBtYWtlIGV2ZXJ5b25lIGF3YXJlIG9mIGFuIElQUi4gU2Vl IFJGQyAzNjY5LCAzOTc5LCA0ODc5IGFuZCA1Mzc4IGZvciBkZXRhaWxzLg0KDQpJZiB5b3UgYXJl IGxpc3RlZCBhcyBhbiBhdXRob3Igb24gdGhlIGRvY3VtZW50LCBvciBhcyBhIGNvbnRyaWJ1dG9y LCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGUtbWFpbCwgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5v dCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFJzLiBUaGUgcmVzcG9uc2UgbmVlZHMg dG8gYmUgc2VuZCB0byB0aGUgTkVUTU9EIG1haWxpbmcgbGlzdC4gVGhlIGRvY3VtZW50IHdpbGwg bm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiBy ZWNlaXZlZCBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgYW55IGNvbnRyaWJ1dG9ycy4NCg0KS2Vu dCAoYW5kIExvdSBhbmQgSm9lbCkNCg0KDQo= From nobody Mon Oct 1 11:52:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C170130E0E for ; Mon, 1 Oct 2018 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8hqdvoidb63 for ; Mon, 1 Oct 2018 11:52:17 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 0BCA91252B7 for ; Mon, 1 Oct 2018 11:52:17 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 4EDB540E10 for ; Mon, 1 Oct 2018 12:50:44 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 73HIg5xbKxGUV73HIgEOmM; Mon, 01 Oct 2018 12:50:44 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cBb7feAbH43bqjq1Apt2E63B4oyGhGVo9aqiB6gRgVY=; b=FY6KK9cDcN3TH/WZHa0bLXuPxT pfW5TafBNOQhGwfzzytoDKjAV+NLs060ahboGj/WWoi/w/c6374OFyk1kjrNYZb8Mmid3uQFueaO1 c19OZNtJWKijCYvJOyo3KdQgJ; Received: from [172.58.185.146] (port=19760 helo=[IPV6:2607:fb90:64bf:85af:0:4a:a606:c201]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g73HH-002d1T-P8; Mon, 01 Oct 2018 12:50:43 -0600 From: Lou Berger To: Kent Watsen , "Acee Lindem (acee)" , Martin Bjorklund , , , Date: Mon, 01 Oct 2018 14:50:39 -0400 Message-ID: <16630f7d018.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <4BF93030-3371-417B-A897-61A44464834C@juniper.net> References: <20181001.091910.1896030373672380031.mbj@tail-f.com> <43AB5D62-FCB5-4B84-841E-30F14235A147@cisco.com> <4BF93030-3371-417B-A897-61A44464834C@juniper.net> User-Agent: AquaMail/1.16.0-1193 (build: 101600006) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.185.146 X-Source-L: No X-Exim-ID: 1g73HH-002d1T-P8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:64bf:85af:0:4a:a606:c201]) [172.58.185.146]:19760 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [netmod] YANG module security considerations template - TLS reference X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:52:18 -0000 At this point I think it's mature enough to be a yang DR or NETMOD wg thing? Thoughts, objections? Lou ---------- On October 1, 2018 2:32:34 PM Kent Watsen wrote: > Benoit is the progenitor of the template. I took it to be an "AD thing" > has since passed to Ignas. > > Kent > > > > ?-----Original Message----- > From: "Acee Lindem (acee)" > Date: Monday, October 1, 2018 at 10:25 AM > To: Martin Bjorklund , "netmod-chairs@ietf.org" > , "netmod-ads@ietf.org" , > "netmod@ietf.org" > Subject: Re: [netmod] YANG module security considerations template - TLS > reference > Resent-From: > Resent-To: , , , > > Resent-Date: Monday, October 1, 2018 at 10:25 AM > > Agreed - although I'm not sure who has control over the template either. > > For drafts that are in-progress, IDNITs will flag this obsolete reference > and, for at least one of the drafts I'm an editor, I've already made the > update. > > Thanks, > Acee > > On 10/1/18, 3:19 AM, "netmod on behalf of Martin Bjorklund" > wrote: > > Hi, > > In their review of draft-ietf-netconf-nmda-restconf, the IESG > suggested we update the reference to TLS from RFC 5246 to RFC 8446 > (which obsoletes 5246). > > This update needs to be done to the template available at > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_ops_wiki_yang-2Dsecurity-2Dguidelines&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=54lt0_rCJTvXEIWmFXsdUNDbzJIkrJ86K-IveL1QoG4&s=9uZWNJN6weNKKk7ABnZ-yFVkwdZxZzQOSm9bSXwT1SQ&e= > > (it is not quite clear who is repsonsible for this template; maybe > that should be clarified on the page) > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=54lt0_rCJTvXEIWmFXsdUNDbzJIkrJ86K-IveL1QoG4&s=QhZGZPVsGhr3-uPQZRPyHFcBYz59K2QZxenbb7Ly7L8&e= > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 1 11:58:17 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F736130E0E; Mon, 1 Oct 2018 11:58:16 -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, DKIMWL_WL_MED=-0.001, 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 w1lfOI6x2TBH; Mon, 1 Oct 2018 11:58:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950231252B7; Mon, 1 Oct 2018 11:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4364; q=dns/txt; s=iport; t=1538420293; x=1539629893; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=t7G3l3h9drzaGEokrPB8BQO+Z0SXuY9DFHiBgefsi00=; b=QWzvuce048Q+yp0qwh7maomjE8OhVjlFq6tqDDRlG37NOH/drjtqy22X a/HzVJhi06lMba9OGoCHqzthKks1Y+/KejvTKJVSNCX2lgabPV6nPYU7O B9rSXFTbxBlL7j4RwTuLXB5zJM9eFs6+/M5305r6ICY3PoUq7/+aLRwEm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAAD3bLJb/4gNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCoNqiBWMGYINgz2THYF6CxgLhANGAheDeSE?= =?us-ascii?q?0GAEDAQECAQECbRwMhTgBAQEBAgEBASERNwMXBAIBCA4DAwECAQICJgICAiU?= =?us-ascii?q?LFQgIAgQBEoMhAYF5CA+lQoEuhAEBhhOBC4l3F4IAgRInH4JMgxsBAYFhF4J?= =?us-ascii?q?qMYImAohPlAtPCQKGQ4lvF4FHS409gliGIYwRAhEUgSUdOIFVcBU7KgGCQQm?= =?us-ascii?q?FeYUUhQgBNW+LXoEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,328,1534809600"; d="scan'208";a="449604255" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 18:58:12 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w91IwCTA024802 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2018 18:58:12 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 14:58:11 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Mon, 1 Oct 2018 14:58:11 -0400 From: "Acee Lindem (acee)" To: Lou Berger , Kent Watsen , "Martin Bjorklund" , "netmod-chairs@ietf.org" , "netmod-ads@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] YANG module security considerations template - TLS reference Thread-Index: AQHUWVcibcIX1/iYHk+KxriwIydA+qUKcn+AgACH64CAAAVAgP//vwwA Date: Mon, 1 Oct 2018 18:58:11 +0000 Message-ID: <18ADC199-B3DB-4B69-AA6D-A16467F4FBFC@cisco.com> References: <20181001.091910.1896030373672380031.mbj@tail-f.com> <43AB5D62-FCB5-4B84-841E-30F14235A147@cisco.com> <4BF93030-3371-417B-A897-61A44464834C@juniper.net> <16630f7d018.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <16630f7d018.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <436AAA34E248044D9BA4165F9ECAC831@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] YANG module security considerations template - TLS reference X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 18:58:16 -0000 QWdyZWVkLiBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgY291cGxlIGRlc2lnbmF0ZWQgZXhwZXJ0 cyAoc2ltaWxhciB0byB3aGF0IHdlIGhhdmUgd2l0aCBJQU5BIHJlZ2lzdHJpZXMpIHRoYXQgd291 bGQgaGF2ZSBlZGl0b3JpYWwgYXV0aG9yaXR5IGFuZCBjb3VsZCBmaWVsZCBzdWdnZXN0aW9ucyBm b3IgdXBkYXRlcyAoZS5nLiwgZm9yIGV4YW1wbGUgZnJvbSB0aGUgU2VjdXJpdHkgQURzKS4NCg0K VGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAxMC8xLzE4LCAyOjUwIFBNLCAiTG91IEJlcmdlciIgPGxi ZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KDQogICAgQXQgdGhpcyBwb2ludCBJIHRoaW5rIGl0J3Mg bWF0dXJlIGVub3VnaCB0byBiZSBhIHlhbmcgRFIgb3IgTkVUTU9EIHdnIHRoaW5nPw0KICAgIA0K ICAgIFRob3VnaHRzLCBvYmplY3Rpb25zPw0KICAgIA0KICAgIExvdQ0KICAgIA0KICAgIA0KICAg IC0tLS0tLS0tLS0NCiAgICBPbiBPY3RvYmVyIDEsIDIwMTggMjozMjozNCBQTSBLZW50IFdhdHNl biA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQogICAgDQogICAgPiBCZW5vaXQgaXMgdGhl IHByb2dlbml0b3Igb2YgdGhlIHRlbXBsYXRlLiAgSSB0b29rIGl0IHRvIGJlIGFuICJBRCB0aGlu ZyINCiAgICA+IGhhcyBzaW5jZSBwYXNzZWQgdG8gSWduYXMuDQogICAgPg0KICAgID4gS2VudA0K ICAgID4NCiAgICA+DQogICAgPg0KICAgID4gPy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog ICAgPiBGcm9tOiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+DQogICAgPiBE YXRlOiBNb25kYXksIE9jdG9iZXIgMSwgMjAxOCBhdCAxMDoyNSBBTQ0KICAgID4gVG86IE1hcnRp biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiwgIm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciIA0K ICAgID4gPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+LCAibmV0bW9kLWFkc0BpZXRmLm9yZyIgPG5l dG1vZC1hZHNAaWV0Zi5vcmc+LCANCiAgICA+ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0 Zi5vcmc+DQogICAgPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2R1bGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgdGVtcGxhdGUgLSBUTFMgDQogICAgPiByZWZlcmVuY2UNCiAgICA+IFJl c2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NCiAgICA+IFJlc2VudC1UbzogPGpv ZWxqYUBib2d1cy5jb20+LCA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+LCA8bGJlcmdlckBsYWJuLm5l dD4sIA0KICAgID4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQogICAgPiBSZXNlbnQtRGF0ZTogTW9u ZGF5LCBPY3RvYmVyIDEsIDIwMTggYXQgMTA6MjUgQU0NCiAgICA+DQogICAgPiBBZ3JlZWQgLSBh bHRob3VnaCBJJ20gbm90IHN1cmUgd2hvIGhhcyBjb250cm9sIG92ZXIgdGhlIHRlbXBsYXRlIGVp dGhlci4NCiAgICA+DQogICAgPiBGb3IgZHJhZnRzIHRoYXQgYXJlIGluLXByb2dyZXNzLCBJRE5J VHMgd2lsbCBmbGFnIHRoaXMgb2Jzb2xldGUgcmVmZXJlbmNlIA0KICAgID4gYW5kLCBmb3IgYXQg bGVhc3Qgb25lIG9mIHRoZSBkcmFmdHMgSSdtIGFuIGVkaXRvciwgSSd2ZSBhbHJlYWR5IG1hZGUg dGhlIA0KICAgID4gdXBkYXRlLg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+IEFjZWUNCiAg ICA+DQogICAgPiBPbiAxMC8xLzE4LCAzOjE5IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBNYXJ0 aW4gQmpvcmtsdW5kIiANCiAgICA+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgbWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KICAgID4NCiAgICA+ICAgICBIaSwNCiAgICA+DQog ICAgPiAgICAgSW4gdGhlaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rj b25mLCB0aGUgSUVTRw0KICAgID4gICAgIHN1Z2dlc3RlZCB3ZSB1cGRhdGUgdGhlIHJlZmVyZW5j ZSB0byBUTFMgZnJvbSBSRkMgNTI0NiB0byBSRkMgODQ0Ng0KICAgID4gICAgICh3aGljaCBvYnNv bGV0ZXMgNTI0NikuDQogICAgPg0KICAgID4gICAgIFRoaXMgdXBkYXRlIG5lZWRzIHRvIGJlIGRv bmUgdG8gdGhlIHRlbXBsYXRlIGF2YWlsYWJsZSBhdA0KICAgID4gICAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdHJhYy5pZXRmLm9yZ190cmFj X29wc193aWtpX3lhbmctMkRzZWN1cml0eS0yRGd1aWRlbGluZXMmZD1Ed0lHYVEmYz1IQWtZdWg2 M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9P SDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTU0bHQwX3JDSlR2WEVJV21GWHNkVU5EYnpKSWty Sjg2Sy1JdmVMMVFvRzQmcz05dVpXTkpONndlTktLazdBQm5aLXlGVmt3ZFp4WnpRT1NtOWJTWHdU MVNRJmU9DQogICAgPg0KICAgID4gICAgIChpdCBpcyBub3QgcXVpdGUgY2xlYXIgd2hvIGlzIHJl cHNvbnNpYmxlIGZvciB0aGlzIHRlbXBsYXRlOyBtYXliZQ0KICAgID4gICAgIHRoYXQgc2hvdWxk IGJlIGNsYXJpZmllZCBvbiB0aGUgcGFnZSkNCiAgICA+DQogICAgPg0KICAgID4gICAgIC9tYXJ0 aW4NCiAgICA+DQogICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiAgICAgbmV0 bW9kQGlldGYub3JnDQogICAgPiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2Qm ZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9 OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTU0bHQwX3JDSlR2 WEVJV21GWHNkVU5EYnpKSWtySjg2Sy1JdmVMMVFvRzQmcz1RaFpHWlBWc0docjMtdVBRWlJQeUhG Y0JZejU5SzJRWnhlbmJiN0x5N0w4JmU9DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbmV0bW9k IG1haWxpbmcgbGlzdA0KICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Mon Oct 1 12:23:52 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA35E130E85; Mon, 1 Oct 2018 12:23:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <153842182483.22191.5941427593143149950@ietfa.amsl.com> Date: Mon, 01 Oct 2018 12:23:44 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-20.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:23:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Mahesh Jethanandani Sonal Agarwal Lisa Huang Dana Blair Filename : draft-ietf-netmod-acl-model-20.txt Pages : 60 Date : 2018-10-01 Abstract: This document defines a data model for Access Control List (ACL). An ACL is a user-ordered set of rules, used to configure the forwarding behavior in device. Each rule is used to find a match on a packet, and define actions that will be performed on the packet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-20 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 1 13:11:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526F5130F01 for ; Mon, 1 Oct 2018 13:11:01 -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 7-A8DeQr2bGk for ; Mon, 1 Oct 2018 13:10:58 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4D3FE130EE1 for ; Mon, 1 Oct 2018 13:10:53 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id s5-v6so10034533pfj.7 for ; Mon, 01 Oct 2018 13:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=U8vI419m0b0dx8U1OewOMHmoJulTs/UR9fLaQBwnzaM=; b=OoaEiaNpBwlj9gZRVXep3iolePuC3Wk7WDM9C7tJY1sUzRXkZJR3TvB2UM5SLubnWj XUe711AD/BL/mUTiri9OGYSsA2Je3Wm0OE06GqQ5CpnxId0ZQeEo677RD1a9WsJnZInC OxBx184k9wJ8WAqaPBamW0v74/i3bpnSNr34l/cPFl2XoAeKufW84Lx0JqCUwFcQli60 xr87ucfEpF15k1J/zPteKPvG+eXv2MHmti/Z+cEjSRo64E92QuIoDy6+aFbJDqwj25L9 ySmHlopXm30MCTNvRvhbD+N8DMCnCmU3smvdEkKwKsEGJBXlwxSaJVCcM6GPz+UeWnOn gokg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=U8vI419m0b0dx8U1OewOMHmoJulTs/UR9fLaQBwnzaM=; b=iqQRiiLeGa2RA4XnWs2MBeJRt6C5gF5uDEJpyn3AKxJ8fGrm375MmkRYbGp3FRxXYd BdryNETq+TCS0MWF+RWSBTrYtC8FdWR4hSX4YcmGl2WZkr7QJOxe9DoiZQw7n3lJ5D15 20vK+07G318BO0wJY6ybPKnFGXQ7rgY4PEDzFCbUfHSY8NePkXUzKwG3qNtF38nZjmXW IGVrtD9tODIFhJSmCTdBNVNs5X5dU03/ktWknPHgx39KceRy9E5oke/f1ujhq/3+S6rh hrh2eByfV8Wa45YbYsAH2CbfkCsYcX8RYaE1MwIfsRJnkxgowwJDpqgPaio1e0DWLgSz OAQw== X-Gm-Message-State: ABuFfohBIFrSePO4CLym5NmruPLg0A4CMiHdpeSe27Jaeyn3thicGU+v hWqVXanaeRvlc8GEavxSE7RZ2Cr2 X-Google-Smtp-Source: ACcGV62RYZhL0cEaHx9nHjh1rlzDWQPTswhWPFIiDlZ54xRi1Q/XD3aZYHAjXJ4a6Lvz8+xJ+umIMw== X-Received: by 2002:a63:6f45:: with SMTP id k66-v6mr11365066pgc.360.1538424652332; Mon, 01 Oct 2018 13:10:52 -0700 (PDT) Received: from [192.168.1.42] ([12.12.156.34]) by smtp.gmail.com with ESMTPSA id q23-v6sm21539365pfd.44.2018.10.01.13.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 13:10:51 -0700 (PDT) Date: Mon, 1 Oct 2018 13:07:06 -0700 From: Jeff Tantsura To: "=?utf-8?Q?netmod=40ietf.org?=" , Kent Watsen Message-ID: <16175bff-d6f0-41ad-92c2-2051815758db@Spark> In-Reply-To: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> References: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> X-Readdle-Message-ID: 16175bff-d6f0-41ad-92c2-2051815758db@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5bb27f4a_441f3428_605" Archived-At: Subject: Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:11:10 -0000 --5bb27f4a_441f3428_605 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Kent, I=E2=80=99m not aware of any IPR that has not been disclosed. Thanks=21 Cheers, Jeff On Oct 1, 2018, 11:48 AM -0700, Kent Watsen , wrot= e: > This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00. > > Are you aware of any IPR that applies to this draft=3F If so, has this = IPR been disclosed in compliance with IET=46 IPR rules=3F Note, you do no= t have to be an author or a contributor to make everyone aware of an IPR.= See R=46C 3669, 3979, 4879 and 5378 for details. > > If you are listed as an author on the document, or as a contributor, pl= ease respond to this e-mail, indicating whether or not you are aware of a= ny relevant IPRs. The response needs to be send to the NETMOD mailing lis= t. The document will not advance to the next stage until a response has b= een received from all the authors and any contributors. > > Kent (and Lou and Joel) > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > netmod mailing list > netmod=40ietf.org > https://www.ietf.org/mailman/listinfo/netmod --5bb27f4a_441f3428_605 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Kent,

I=E2=80=99m not aware of any IPR that has not been disclosed.
Thanks=21&=23160;

Cheers,
Jeff
On Oct 1, 2018,= 11:48 AM -0700, Kent Watsen <kwatsen=40juniper.net>, wrote:
This mail starts the IPR poll = for draft-clemm-netmod-nmda-diff-00.

Are you aware of any IPR that applies to this draft=3F If so, has this IP= R been disclosed in compliance with IET=46 IPR rules=3F Note, you do not = have to be an author or a contributor to make everyone aware of an IPR. S= ee R=46C 3669, 3979, 4879 and 5378 for details.

If you are listed as an author on the document, or as a contributor, plea= se respond to this e-mail, indicating whether or not you are aware of any= relevant IPRs. The response needs to be send to the NETMOD mailing list.= The document will not advance to the next stage until a response has bee= n received from all the authors and any contributors.

Kent (and Lou and Joel)


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netmod mailing list
netmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--5bb27f4a_441f3428_605-- From nobody Mon Oct 1 13:11:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A48130EC7 for ; Mon, 1 Oct 2018 13:11:02 -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 SiGnh7G9tgN2 for ; Mon, 1 Oct 2018 13:10:59 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 CC148130F19 for ; Mon, 1 Oct 2018 13:10:54 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id r77-v6so10237939pgr.5 for ; Mon, 01 Oct 2018 13:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=nrgUntkc7NFrf5BJvmH5IJeJAjsm6QNdj1xHohqa6E0=; b=W1A6rv9jZeaZHhbdBLg8fDYGIMZI3vihNdTehO4bOv1Ne+GQkzfERr2otX50QYWYlv F8PcrMScu/fy5P7VUWrcVzSoF/ud2QcOp3uJpnX4iuzpg3OJeqzedO9TvpyO1qDE9Id9 kHZbe9XTd6BbWJPV7h9z08tiGwwlCprQ/HctAcUbaKjEBlVcpRij0Ycz2rWwr5gE0AtG 7jXhJhJMIXo/MnB283V2+U0i1jrk5fUJJluTlI5x2AIw9WtgtYVyE9FjVcCejncb6SUL 7lEvCzEEygDchuvt13TAT2xmuF651Wxeamf+9vZafP4MlG1Igb0NP+yiaJ7Tf816gfNO 3G/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=nrgUntkc7NFrf5BJvmH5IJeJAjsm6QNdj1xHohqa6E0=; b=VAH/UV626MH6e81rFldQ+Xp+knIaNJvaekqTIvkGq1ge++Zpvl/CCFIFXL0xXVGO02 Af4ni5/7IWsw/tQcmi5bnqybeMAkrYueOqNwyXWZfqSvuIGMFkIFDgEKRLTJI85tn3uW NXyW20oXXNqsVjlQUI5J74/hYnAZhcDQH//fUz1BGuvZRjdXr30kuhloIW8ad7p2uyAb u/qi0hMc6P2AeFSBCep4Co/UyvWfQKrbw48ldxZs5ziuUXK9p4Lvjf9FzlpVI+wfo1uL p8Ysh9VzlzvUF1YacDa4GH3BAWhLrNPXvtoD6DS2zQPFhpkiNz9YXM4MmyfyshBh0Zt7 apAw== X-Gm-Message-State: ABuFfoidJpvIolRG9a7Fy9QomblMSrGQBw1KbZZadbsleew1oT8I1A1Y 0E20REOpaSD1QwDE3HCWvkZcNAAx X-Google-Smtp-Source: ACcGV63F9g7RL5dicadgV61zWiDW/biVfs4pKRpS+H1Hq6iCEelAdYLuMo3Sh2lOUAPDKAENEoIKvw== X-Received: by 2002:a17:902:9302:: with SMTP id bc2-v6mr13615204plb.280.1538424654147; Mon, 01 Oct 2018 13:10:54 -0700 (PDT) Received: from [192.168.1.42] ([12.12.156.34]) by smtp.gmail.com with ESMTPSA id g17-v6sm10493693pfe.37.2018.10.01.13.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 13:10:53 -0700 (PDT) Date: Mon, 1 Oct 2018 13:07:38 -0700 From: Jeff Tantsura To: "=?utf-8?Q?netmod=40ietf.org?=" , Kent Watsen Message-ID: In-Reply-To: References: X-Readdle-Message-ID: dde3c7b4-814b-40d8-9cac-3c1c78d580c2@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5bb27f4c_42d2de69_605" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:11:11 -0000 --5bb27f4c_42d2de69_605 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Support as co-author Cheers, Jeff On Oct 1, 2018, 11:48 AM -0700, Kent Watsen , wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --5bb27f4c_42d2de69_605 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Support as co-au= thor

Cheers,
Jeff
On Oct 1, 2018,= 11:48 AM -0700, Kent Watsen <kwatsen=40juniper.net>, wrote:
The IET=46 102 in-room poll sh= ould really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

Please indicate your support or objection to the adoption poll.
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netmod mailing list
netmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--5bb27f4c_42d2de69_605-- From nobody Mon Oct 1 13:15:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A551252B7 for ; Mon, 1 Oct 2018 13:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfMBHihgFAJR for ; Mon, 1 Oct 2018 13:15:49 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E60B128D0C for ; Mon, 1 Oct 2018 13:15:48 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w91KDfC0009878; Mon, 1 Oct 2018 13:15:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=qJb+uh7orD0O2MxTBAvCgjbvvIMyezEQiUobc0ClpvU=; b=KkBwtza1Q/xXcKUCWlXuFOKNpPMenvi5LwWtCHTwkLPX0CLsX36dtLI/QGXKgScf330A 9iG5vTGkY9DiB3ndd+lTFc1dwStGNDULf8fbeHI/Ef2rzLYKI9I4lNu2dR9wWxFH7WMc oZa3ZIj+kX2JdnBWipM4Rx1i19CzeJ62Ml7wVL9wmtM+/++I7izVu6nnFC0NSk2gy4py XaLaIGox0w208JeSEfM4bMyz7uUwLyYJZ81Fzm1vh8LW3Ah0efWgOslUBdcr5n3mQgSH YQrWfDE0oRYsw5R7pJiVNzQj2UI4SX8D9QmWcbCpTpvvbrJ1h3aI9+06J8S/K9wMaBXV Qw== Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0117.outbound.protection.outlook.com [216.32.180.117]) by mx0b-00273201.pphosted.com with ESMTP id 2mun220q4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Oct 2018 13:15:37 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB3962.namprd05.prod.outlook.com (20.176.66.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.11; Mon, 1 Oct 2018 20:15:36 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Mon, 1 Oct 2018 20:15:36 +0000 From: Kent Watsen To: Martin Bjorklund CC: "ietfc@btconnect.com" , "netmod@ietf.org" Thread-Topic: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt Thread-Index: AQHUUaLhqK0+eVIcY0e09cIrm611d6UCwxEAgABNpoCAB4//gA== Date: Mon, 1 Oct 2018 20:15:36 +0000 Message-ID: <0EEAE4DC-7B93-4BCD-AA1C-751A0895180B@juniper.net> References: <1A7EF333-2DA0-4D51-B44C-63AF3D6D628B@juniper.net> <034a01d454b4$caf3aa80$4001a8c0@gateway.2wire.net> <20180926.224627.87057059275619124.mbj@tail-f.com> In-Reply-To: <20180926.224627.87057059275619124.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB3962; 6:5RKnHVgTeM6senLUdJS/40Wo0sA4vDj5zP8lLEJLRZXeeg4FjIYrNDbjx4GWrUB+sthP39QZ/pkH1bUp1HI3v1KcypvdhYQhzpBBe5SR/5Wuo+oZilTsmegMma0SgzccctB2OHZduTQ46GjLf8VfUwnnPGJyZvwNkppTtt0iXZM9pmqGurJ//6zc6OJmVxZYRUaK8Pa8LSyz6p5qWV8LVPzqxR4GJYP0pECHGsIiKJrCwH4WgM1n09sLi6SWnk6rctOZhRnOPLsAkut3h/Crlk0jm8XABJ2ImlbzATqBOhOexmK8BcI+tFAM7GWaKKW3rT/tfXjVLLMTY2/BVVwDjqCuddxPtGOE2PfVMIikwVBhFAew1lDM4v+5ap6OfyHwgmKN/EK6FIJqTWCG65Fk/qhS5eRmVefPZCCUB/+7KXav3w8CoyzBfrMs6Yr1+674LeRQCyRt9QfLF/CnUQog/A==; 5:5uSy5AjzlZuSYOjxsxdA4oin+Txb3Dt2ds1mjl8ftxihsNmmW0fgbqF9Ox68NogcpXSmiFIDSD1jH3Hr/E3OwL1+S5hvedc+bS+cURBnAhlhfyFL/Ay5CccK/N2JudEtRJsb91LTYLxPkss5zfAMMP1PXRyIPm7kABvxw7bQF/4=; 7:69Lw6faRKOFOjtvI5NcxhK1opQXXk9q4r+WfSWEpQFqmsooLF7eudaGcEGcNpFEmqlIGQnOf2dVtHDOHfjNGZgn8mJBFhdUvlc//qgFfD+aLRBfZzjTjxC4JrCcykcAolWIWuZptVW04xPyKPKZ0DxrpR6uaG9CA61q0IhFMy//1166vNApBhIfYB0NIa24RezxCqJU6oEXGJ5skoxOJeu5OMG+vM/4qXIGudIYff2IOZ5yHAXYDDGCsLBHe6+vY x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 86aef4f9-c0c3-402b-f936-08d627daa64c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB3962; x-ms-traffictypediagnostic: DM6PR05MB3962: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB3962; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB3962; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39860400002)(136003)(346002)(376002)(189003)(199004)(33656002)(6512007)(82746002)(14454004)(6486002)(6436002)(316002)(5660300001)(36756003)(7736002)(305945005)(66066001)(229853002)(53936002)(478600001)(186003)(6116002)(71200400001)(102836004)(71190400001)(3846002)(26005)(83716004)(86362001)(93886005)(6916009)(2906002)(476003)(58126008)(256004)(54906003)(81166006)(106356001)(8676002)(81156014)(105586002)(25786009)(76176011)(6506007)(2616005)(6246003)(97736004)(11346002)(486006)(8936002)(2900100001)(4326008)(68736007)(99286004)(446003)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB3962; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: VTVYQyzPMXwKq9S5rXRsY/QK197fjHHSWLglVDG5TtjRxNpvlvv5m23JRSbCFNnSTiBq9KezI1jBFPrWOVaLBZJgQDCfLKJT5uQfTgf9R7mTKHuBcuvgBON5+vUx/fSNe3bZtKnRlb5a4VRnaFgIr0I+fbHG9/hqVh8FNzuRnto0pQe2aeKk1FsuHX2vSIySGcm89jeQaNeAmgwYpjJR3lt2enkxXQFB874DO+BrPSWKElgBpiRRTnXRlzjD7hqrNTgUMPrZ6jj52b3q9dt09qjARdR01Q4qoS36ErsnblZiWe+7A7EPaUvfmP0nVceUobVsDgppLJ9GEhAWEOimVZ6xuFAl5IiqOcG/o6x7E+s= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <92E1DD3039675449A34824BA91AD7FF5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 86aef4f9-c0c3-402b-f936-08d627daa64c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2018 20:15:36.4328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB3962 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=797 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810010193 Archived-At: Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:15:52 -0000 PiBBdCBsZWFzdCByZW1vdmUgWUFORyBmcm9tIHRoZSBleGFtcGxlLCBhbmQgSSBhbHNvIHRoaW5r IHRoYXQNCj4gYXV0by1mb2xkaW5nIG9mIHRyZWUgZGlhZ3JhbXMgc2hvdWxkIGJlIHN0cm9uZ2x5 IGRpc2NvdXJhZ2VkLCBzbyBmaW5kDQo+IGEgYmV0dGVyIGV4YW1wbGUgZm9yIChiKS4NCg0KUmVt b3ZlZCAiWUFORyIgYW5kIHMvKGUuZy4sIHRyZWUgZGlhZ3JhbXMpLywgdXNpbmcgYSB0b29sIHRo YXQgZG9lc24ndA0Kb2JzZXJ2ZSBsaW5lIGxlbmd0aHMuICBGV0lXLCBweWFuZydzIC0tdHJlZS1s aW5lLWxlbmd0aCBzb21ldGltZXMgDQpwcm9kdWNlcyByZXN1bHRzIHdvcnNlIHRoYW4gZm9sZGVk IGFydHdvcmsuDQoNCg0KPiBBbHNvIHJlbW92ZSBZQU5HIGZyb20gNC4xDQoNCkRvbmUuDQoNCg0K PiBUbyBmdXJ0aGVyIGVtcGhhc2l6ZSB0aGlzLCBJIHRoaW5rIHlvdSBzaG91bGQgYWRkIFlBTkcg YW5kIHRyZWUNCmRpYWdyYW1zIGFzIGV4YW1wbGVzIGluIHNlY3Rpb24gNC4yLg0KDQpZb3UgbWVh biwgYXMgYW50aS1leGFtcGxlcz8NCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yIA0KDQo= From nobody Mon Oct 1 13:19:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA171252B7 for ; Mon, 1 Oct 2018 13:19:40 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 aOErgah_Ckws for ; Mon, 1 Oct 2018 13:19:38 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 C3E94128D0C for ; Mon, 1 Oct 2018 13:19:37 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id t22-v6so10862540lfb.7 for ; Mon, 01 Oct 2018 13:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U2cgyvknul3kBb77/0FSk/JVyeJoYfpZy9CsuS99mTo=; b=NOpEfCholulYTv/Tv8gN9TZYMX9YanA6G3+38fxbY4IxiDseLs+A30iRLDQTX7fzo9 2WvuhXq3zl+KhXOKsEM7YPCDIBqqT4sx7dsLrIaiGICayB0zomZwk82vQ1UhXXN3eJjb 9qREN34MvCrCKeuBMQDXDLLCPX3Vk86cTomF5t0iH8isVnIfKpBsYjqN7LMXeivHp94d UHv3zjzyvL+sw8YlF75lgIyMMFZ7UnRGe9hXqtnxKGbdm8082f7Niod8IYD9Ctqi6D/P yCWrZUZgZPJFboS8UdkRqOyxXWk7XzhtDBhq8kuscezK+PJZWJH49Em09/QxBl0rsYTW 5Xug== 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=U2cgyvknul3kBb77/0FSk/JVyeJoYfpZy9CsuS99mTo=; b=Udt8OEMSKnducJ067uA4BxEQZ2UTnRHVGE/o1Oe+qErrYTWEY/EtptzlYONhmAXqry N6cZecFtqtKnh4xx0LRMLArUwkXVHRaxE5Sx8YRMlNJ+atn8wAbtIdhMApSPy/FOd6cY j2584kOqwrhXImpaadGwaabW7qJEoCJdDp9ziD996zcUTco+aTDhOdTZv6PSPkW0Vk3g CFDsFGbcvxfTPPEPefaYvsWCMnMxhMo7rZOJXu5fVrcjiVFgjHafTmTOwHhqAsYNGl5N yTSqJ3wturpUsXTwv0uxqApBoStuN+mnOiJaSeK29IB9Xhso+R2d0zz3ZbfTIv8dBXbC Ysmg== X-Gm-Message-State: ABuFfohj60keOV5LM2HtFepM8K4hNk8ILe/WWYe5q05dx43JHSqg2v7P fdWQX2bZPjtcpIXfEiY7FWdA/Tt3+hQu994w5c/6S/XB6ZA= X-Google-Smtp-Source: ACcGV63yNJsNAvAPC+o9tBbkN9xk7plUAJr7zXSTcYxmPD63LIEYL45CDic2JqppqmpnDpFEvQvsNMWX2fd6XWxuOto= X-Received: by 2002:a19:2102:: with SMTP id h2-v6mr6193945lfh.119.1538425175726; Mon, 01 Oct 2018 13:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 13:19:34 -0700 (PDT) In-Reply-To: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> References: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> From: Andy Bierman Date: Mon, 1 Oct 2018 13:19:34 -0700 Message-ID: To: Kent Watsen Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001d225d05773086d3" Archived-At: Subject: Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 20:19:40 -0000 --0000000000001d225d05773086d3 Content-Type: text/plain; charset="UTF-8" Hi, I am not aware of any IPR related to draft-clemm-netmod-nmda-diff-00. Andy On Mon, Oct 1, 2018 at 11:48 AM, Kent Watsen wrote: > This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00. > > Are you aware of any IPR that applies to this draft? If so, has this IPR > been disclosed in compliance with IETF IPR rules? Note, you do not have to > be an author or a contributor to make everyone aware of an IPR. See RFC > 3669, 3979, 4879 and 5378 for details. > > If you are listed as an author on the document, or as a contributor, > please respond to this e-mail, indicating whether or not you are aware of > any relevant IPRs. The response needs to be send to the NETMOD mailing > list. The document will not advance to the next stage until a response has > been received from all the authors and any contributors. > > Kent (and Lou and Joel) > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000001d225d05773086d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am not aware of = any IPR related to=C2=A0draft-clemm-netmod= -nmda-diff-00.

Andy


On Mon, Oct 1, 2018 at 11:48 AM, Kent Wat= sen <kwatsen@juniper.net> wrote:
This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00.

Are you aware of any IPR that applies to this draft? If so, has this IPR be= en disclosed in compliance with IETF IPR rules? Note, you do not have to be= an author or a contributor to make everyone aware of an IPR. See RFC 3669,= 3979, 4879 and 5378 for details.

If you are listed as an author on the document, or as a contributor, please= respond to this e-mail, indicating whether or not you are aware of any rel= evant IPRs. The response needs to be send to the NETMOD mailing list. The d= ocument will not advance to the next stage until a response has been receiv= ed from all the authors and any contributors.

Kent (and Lou and Joel)


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

--0000000000001d225d05773086d3-- From nobody Mon Oct 1 15:13:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F43130E16 for ; Mon, 1 Oct 2018 15:13:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 y2CUB-gZ7a31 for ; Mon, 1 Oct 2018 15:13:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6861212008A for ; Mon, 1 Oct 2018 15:13:20 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 15418A594D3DE for ; Mon, 1 Oct 2018 23:13:15 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 1 Oct 2018 23:13:16 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML703-CHM.china.huawei.com ([169.254.5.166]) with mapi id 14.03.0415.000; Mon, 1 Oct 2018 15:13:10 -0700 From: Alexander Clemm To: Jeff Tantsura , "netmod@ietf.org" , Kent Watsen Thread-Topic: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdVa1uJLAzfC0+Ye50AARhnB6ULRpEA//+seJA= Date: Mon, 1 Oct 2018 22:13:10 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9E@sjceml521-mbx.china.huawei.com> References: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> <16175bff-d6f0-41ad-92c2-2051815758db@Spark> In-Reply-To: <16175bff-d6f0-41ad-92c2-2051815758db@Spark> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.77] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9Esjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 22:13:22 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9Esjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VudCwNCnNhbWUgaGVyZS4gIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90 IGJlZW4gZGlzY2xvc2VkLiAgKEkgYW0gYXdhcmUgb2YgdGhlIElQUiB0aGF0IHdhcyBkaXNjbG9z ZWQgYSB5ZWFyIGFnbyBhbmQgdGhhdCBpcyBvbiBkYXRhdHJhY2tlci4pDQotLS0gQWxleA0KDQpG cm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEplZmYgVGFudHN1cmENClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMSwgMjAxOCA0OjA3IFBNDQpU bzogbmV0bW9kQGlldGYub3JnOyBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NClN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBJUFIgcG9sbCBvbiBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1k aWZmLTAwDQoNCktlbnQsDQoNCknigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5v dCBiZWVuIGRpc2Nsb3NlZC4NClRoYW5rcyENCg0KQ2hlZXJzLA0KSmVmZg0KT24gT2N0IDEsIDIw MTgsIDExOjQ4IEFNIC0wNzAwLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWls dG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+LCB3cm90ZToNCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGUg SVBSIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAuDQoNCkFyZSB5b3Ug YXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdD8gSWYgc28sIGhhcyB0 aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM/ IE5vdGUsIHlvdSBkbyBub3QgaGF2ZSB0byBiZSBhbiBhdXRob3Igb3IgYSBjb250cmlidXRvciB0 byBtYWtlIGV2ZXJ5b25lIGF3YXJlIG9mIGFuIElQUi4gU2VlIFJGQyAzNjY5LCAzOTc5LCA0ODc5 IGFuZCA1Mzc4IGZvciBkZXRhaWxzLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBhdXRob3Ig b24gdGhlIGRvY3VtZW50LCBvciBhcyBhIGNvbnRyaWJ1dG9yLCBwbGVhc2UgcmVzcG9uZCB0byB0 aGlzIGUtbWFpbCwgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFu eSByZWxldmFudCBJUFJzLiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VuZCB0byB0aGUgTkVU TU9EIG1haWxpbmcgbGlzdC4gVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGFsbCB0aGUg YXV0aG9ycyBhbmQgYW55IGNvbnRyaWJ1dG9ycy4NCg0KS2VudCAoYW5kIExvdSBhbmQgSm9lbCkN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0 bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9Esjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5LZW50LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnNhbWUgaGVy ZS4mbmJzcDsgSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgYmVlbiBkaXNj bG9zZWQuJm5ic3A7IChJIGFtIGF3YXJlIG9mIHRoZSBJUFIgdGhhdCB3YXMgZGlzY2xvc2VkIGEg eWVhciBhZ28gYW5kIHRoYXQgaXMgb24gZGF0YXRyYWNrZXIuKQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkplZmYgVGFudHN1cmE8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBPY3RvYmVyIDAxLCAyMDE4IDQ6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IG5ldG1vZEBp ZXRmLm9yZzsgS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBJUFIgcG9sbCBvbiBkcmFmdC1jbGVtbS1uZXRtb2Qt bm1kYS1kaWZmLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBuYW1lPSJtZXNzYWdl Qm9keVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+S2VudCwN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5J4oCZbSBub3QgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGhhcyBub3QgYmVlbiBkaXNjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtz ISZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IG5hbWU9 Im1lc3NhZ2VTaWduYXR1cmVTZWN0aW9uIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCkNoZWVycywgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkplZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBuYW1lPSJtZXNzYWdlUmVwbHlTZWN0aW9uIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE9jdCAxLCAyMDE4LCAxMTo0OCBBTSAt MDcwMCwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0 Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDssIHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjMUFCQzlDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gOC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1yaWdodDozLjc1cHQ7bWFyZ2luLWJv dHRvbTozLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBt YWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYt MDAuPGJyPg0KPGJyPg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0PyBJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFu Y2Ugd2l0aCBJRVRGIElQUiBydWxlcz8gTm90ZSwgeW91IGRvIG5vdCBoYXZlIHRvIGJlIGFuIGF1 dGhvciBvciBhIGNvbnRyaWJ1dG9yIHRvIG1ha2UgZXZlcnlvbmUgYXdhcmUgb2YgYW4gSVBSLiBT ZWUgUkZDIDM2NjksIDM5NzksIDQ4NzkgYW5kIDUzNzggZm9yIGRldGFpbHMuPGJyPg0KPGJyPg0K SWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9uIHRoZSBkb2N1bWVudCwgb3IgYXMgYSBj b250cmlidXRvciwgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlLW1haWwsIGluZGljYXRpbmcgd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBScy4gVGhlIHJlc3Bv bnNlIG5lZWRzIHRvIGJlIHNlbmQgdG8gdGhlIE5FVE1PRCBtYWlsaW5nIGxpc3QuIFRoZSBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZQ0KIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgYW55IGNvbnRyaWJ1 dG9ycy48YnI+DQo8YnI+DQpLZW50IChhbmQgTG91IGFuZCBKb2VsKTxicj4NCjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0 bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5l dG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2Q8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9Esjceml521mbxchi_-- From nobody Mon Oct 1 15:21:37 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4B5130E6F for ; Mon, 1 Oct 2018 15:21:36 -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, 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 ru8xncvsLEcG for ; Mon, 1 Oct 2018 15:21:34 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C1C6A12008A for ; Mon, 1 Oct 2018 15:21:34 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9069A4F29230D for ; Mon, 1 Oct 2018 23:21:31 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 1 Oct 2018 23:21:33 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML703-CHM.china.huawei.com ([169.254.5.166]) with mapi id 14.03.0415.000; Mon, 1 Oct 2018 15:21:28 -0700 From: Alexander Clemm To: Kent Watsen , "netmod@ietf.org" Thread-Topic: WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdTI2nNckn+1ky1f4oa9l5TQKUK9rig Date: Mon, 1 Oct 2018 22:21:27 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BBBB@sjceml521-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 22:21:36 -0000 Support as coauthor --- Alex > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Monday, October 01, 2018 2:48 PM > To: netmod@ietf.org > Subject: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 >=20 > The IETF 102 in-room poll should really good support to adopt this draft,= and no > objections. >=20 > This email starts an adoption poll for: >=20 > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 >=20 > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. >=20 > Kent (and Lou and Joel) >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 1 19:42:15 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D74F7127148; Mon, 1 Oct 2018 19:42:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-netmod-acl-model@ietf.org, Kent Watsen , netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153844813387.22172.11772944817215218880.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2018 19:42:13 -0700 Archived-At: Subject: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-acl-model-20: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 02:42:14 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-acl-model-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point. From nobody Mon Oct 1 23:18:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6B130E14 for ; Mon, 1 Oct 2018 23:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.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 GM0LbOOIm8Ag for ; Mon, 1 Oct 2018 23:18:21 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 1C062128A6E for ; Mon, 1 Oct 2018 23:18:21 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id u21-v6so655329lja.8 for ; Mon, 01 Oct 2018 23:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j28b/v69qPqPq9ZBto4ujUTfxLMtKc1Kqdl3NbxUzTU=; b=lMADYnTs6VUlDZt/vDXtGbopHXRp8ErvV33J5Vw9TjAgiEeyfqeZGoR7RqsqMkX7AG HO7Xu94/ZBS1+kQeVr/VEcMnmd9eRZdrm6gIO5YmGk+SABFEnNbbmf0irqmMsrdeBnF9 L/oB83jvLFrsVb768xnCBWYBB2vtWuRn8ES8cXLhZeWZpNB3+lCTN3Of8pwDWoN41yvy /XsYhXEP2QDi6Lqc7KN0MmISUooxglqluXxQBMYgz0YOPPiJncqquCDnfYOW7zy629aA B/5V2b+QfmAuNRktgJKkQSABJs7n8s3/5yzHYV8ki53EzNO8e2NtQMJw08eecHd2qsGZ IBpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j28b/v69qPqPq9ZBto4ujUTfxLMtKc1Kqdl3NbxUzTU=; b=S35tB68hWQwFi/Hh1M3iFtasRiWz25f3fgnXQWe1yo7dp03d3WqfA2iBSMEzrcqF2b pmpViiyLaafbEx9vIGV88e+OIerKdw1OJ7fb7AsuGtbWWaIeDjzeZcYhb6H3HdcXuAUf 6AqnhaOiyWnOKBRvKb0HkSwMaKmyn0TSKtfYzU6KyA7YeAo3CUsb8UqaNRiQM8IE04G1 56M4rHZeIntlGxthoZyfMdntgBK0G1HMkzB9e9XGwvtnK0av3+eMey/6hf6W/CDeupTB G/Mg+7vKsRUOimOlug/nwxrCQ28NdOjN/v7aSr5AKHUM+FGvgOtnsbQfAYFHyuT8dx1E AOpg== X-Gm-Message-State: ABuFfogXgAuYt0bnBs1u+3um2w5fG6qMg/IodZXKcZwzYzN9C7VWE97I 9Ggf8lzB1uTUxU4qCrqbAHwWPA== X-Google-Smtp-Source: ACcGV62vne6hcwPuTqDPWWhMABWV9okSpPTOoxvCZd6uvTnvt9/hRVDUtc+rjVzEecpc88GlnsWL8A== X-Received: by 2002:a2e:2e18:: with SMTP id u24-v6mr8571046lju.3.1538461099207; Mon, 01 Oct 2018 23:18:19 -0700 (PDT) Received: from [192.168.72.11] (h95-155-237-105.cust.se.alltele.net. [95.155.237.105]) by smtp.gmail.com with ESMTPSA id p80-v6sm3136579ljb.19.2018.10.01.23.18.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Oct 2018 23:18:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: stefan vallin In-Reply-To: Date: Tue, 2 Oct 2018 08:18:17 +0200 Cc: Martin Bjorklund , "ccamp@ietf.org" , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <06297C39-B42A-492C-ABB5-3EB3C094F35D@wallan.se> References: <20180920.103107.750560007019896412.mbj@tail-f.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] draft-ietf-ccamp-alarm-module-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 06:18:25 -0000 Hi Karen! See inline br Stefan and Martin >=20 > I hope that you can accept the follow up right below: >=20 > * Would it not be relevant in the draft to outline the relation to the = alarm-state in RFC8348 ? >=20 > ** Possibly even in the substance of the document rather then in an = appendix - assuming that the two are seen as complementary mechanisms = potentially based on the same underlying alarm framework (that you = define in this draft) We can add a short description on the relationship between the Alarm = Module and RFC8348. As Martin stated they serve different purposes: "The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is just a summary of the alarms that may be active on the specific hardware component. It doesn't say anything about how alarms are reported, and it doesn't provide any details of the alarms; it is just a bitmask. The alarm-module draft, specifies how alarms are reported, generically. It also provides a list of all active alarms." The mapping between the data-models are outlined below. Alarm YANG. RFC 8348 alarm list * resource corresponds to = /hardware/component/ * is-cleared no bit set in = /hardware/component/state/alarm-state * perceived-severity corresponding bit set in = /hardware/component/state/alarm-state * operator-state-change/state. if the alarm is acked by the = operator it could correspond to under-repair >=20 > ** In the draft you have "closed" state of an alarm. Wouldn't it be = relevant, in your opinion. with this alarm framework in mind, also to = have the closed state in the alarm-state object of RFC8348 ? >=20 > * The same question (should be included in alarm-state of RFC8348) for = the shelved alarms ? This would be an update to RFC 8348, and is out of scope for this work >=20 > Something else: >=20 > * Assuming that one has an alarm which have no clear (see next = question below) or where clear may not always come. > Would an operator close of this alarm make it disappear from the = active alarms summary ? Can that be an implementation decision - = possibly depending on the alarm type, possibly configurable ? The general answer is no, as stated in the document, there is no = automatic purge/deletion of an alarm on clear from the resource or close = from the operator. This is by design, from an ops perspective it makes sense to be able to = view the alarm even after it is cleared/closed.=20 You might want to study the root cause afterwards to perform proactive = actions for it not to appear again for example. But as you say, you can make it an implementation decision, "purge on = clear", "purge on close". If it is hard-coded per alarm-type, describe it in the alarm inventory You can also make it configurable per alarm type by augmenting the alarm = profile with a purge-policy: "purge on clear", "purge on close" >=20 > * RFC3877 has the following statement: "Alarms SHOULD be modelled so = Notifications are sent on alarm Clear." =20 > I did not find this statement in the substance of the draft nor in = Appendix F (But it may have escaped me). =20 > Is this also the mindset of this draft ? According to this alarm module an alarm-notification will be sent with = perceived-severity set to cleared. >=20 > * It is correctly understood that the Alarm Summary and the Alarm list = contains the alarms which are presently in the system - i.e. which have = not been purged ? Correct > * Would it be relevant for the Alarm Summary list to tell when alarms = was last purged due to administrative action ? We do not want to load the alarm module with more features at this = point, this could be done in the management application/client.=20 >=20 > * Are you considering to implement support for statistics ? What do you mean with statistics? a) Statistics on alarms or do you mean a b) performance monitoring = module? It a, no, that is up to the management application If b, that is a separate module not within this one >=20 >=20 > BR, Karen >=20 > -----Original Message----- > From: Martin Bjorklund =20 > Sent: 20. september 2018 10:31 > To: Karen Elisabeth Egede Nielsen > Cc: ccamp@ietf.org; stefan@wallan.se; netmod@ietf.org > Subject: Re: draft-ietf-ccamp-alarm-module-02 >=20 > Hi, >=20 > Karen Elisabeth Egede Nielsen wrote: >> Hi, >>=20 >> This draft is new to me and modelling of alarm management also=20 >> somewhat.... >>=20 >> Could you enlighten me on the relationship, if any, in between the=20 >> alarm module of this draft and the Device/resource alarm state within=20= >> RFC8348 (equivalently the EntityAlarmStatus of RFC4268) ? >=20 > The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is = just a summary of the alarms that may be active on the specific hardware = component. It doesn't say anything about how alarms are reported, and = it doesn't provide any details of the alarms; it is just a bitmask. >=20 > The alarm-module draft OTOH, specifies how alarms are reported, = generically. It also provides a list of all active alarms. >=20 >> E.g. are the two they considered complementary mechanisms (modules),=20= >> just different view glasses, or are they non-compatible or redundant=20= >> ..? >=20 > So if both modules are implemented (they don't have to be), the = information can be viewed as redundant or just different views. >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Many Thanks in advance ! >>=20 >>=20 >> BR, Karen Nielsen >>=20 From nobody Tue Oct 2 00:27:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421DD130DCA; Tue, 2 Oct 2018 00:27:26 -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 3LUXzQViWK9R; Tue, 2 Oct 2018 00:27:23 -0700 (PDT) Received: from mail.kamstrup.com (mail.kamstrup.com [185.181.20.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104BF130DC3; Tue, 2 Oct 2018 00:27:22 -0700 (PDT) Received: from EXCHANGE2010.kamstrup.dk ([::1]) by Exchange2010.kamstrup.dk ([::1]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 09:27:20 +0200 From: Karen Elisabeth Egede Nielsen To: stefan vallin CC: Martin Bjorklund , "ccamp@ietf.org" , "netmod@ietf.org" Thread-Topic: draft-ietf-ccamp-alarm-module-02 Thread-Index: AdRQCodrkWYiLZVDQVapWZ9icZtUKAAoPuyAAA5MvzACSI7fgAAFRodw Date: Tue, 2 Oct 2018 07:27:20 +0000 Message-ID: References: <20180920.103107.750560007019896412.mbj@tail-f.com> <06297C39-B42A-492C-ABB5-3EB3C094F35D@wallan.se> In-Reply-To: <06297C39-B42A-492C-ABB5-3EB3C094F35D@wallan.se> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.19.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] draft-ietf-ccamp-alarm-module-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 07:27:27 -0000 HI Stefan, Martin, Thanks a lot. Pls see inline below. BR, Karen > > > > I hope that you can accept the follow up right below: > > > > * Would it not be relevant in the draft to outline the relation to the = alarm- > state in RFC8348 ? > > > > ** Possibly even in the substance of the document rather then in an > > appendix - assuming that the two are seen as complementary > mechanisms > > potentially based on the same underlying alarm framework (that you > > define in this draft) > We can add a short description on the relationship between the Alarm > Module and RFC8348. > As Martin stated they serve different purposes: > "The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is jus= t > a summary of the alarms that may be active on the specific hardware > component. It doesn't say anything about how alarms are reported, and it > doesn't provide any details of the alarms; it is just a bitmask. The alar= m- > module draft, specifies how alarms are reported, generically. It also > provides a list of all active alarms." >=20 > The mapping between the data-models are outlined below. > Alarm YANG. RFC 8348 > alarm list > * resource corresponds to /hardware= /component/ > * is-cleared no bit set in > /hardware/component/state/alarm-state > * perceived-severity corresponding bit set in > /hardware/component/state/alarm-state > * operator-state-change/state. if the alarm is acked by the operator= it > could correspond to under-repair >=20 [Keen] I would appreciate that very much. Thanks ! > > > > ** In the draft you have "closed" state of an alarm. Wouldn't it be > relevant, in your opinion. with this alarm framework in mind, also to hav= e > the closed state in the alarm-state object of RFC8348 ? > > > > * The same question (should be included in alarm-state of RFC8348) for > the shelved alarms ? > This would be an update to RFC 8348, and is out of scope for this work [Keen] Yes. However the IETF makes comprehensive standards.=20 The present gap in between this work (which I support) and RFC8348 is actua= lly also one of the reasons why I think that it is important to=20 explicitly relate to RFC8348 in this work (draft in subject). For our usecase (IoT) I think that it will be relevant to implement a solut= ion inline with this draft. However I also believe that we would like to im= plement support for alarm-state object of RFC8348, in this case then for us= efulness extended with the "closed" state. > > > > Something else: > > > > * Assuming that one has an alarm which have no clear (see next questio= n > below) or where clear may not always come. > > Would an operator close of this alarm make it disappear from the acti= ve > alarms summary ? Can that be an implementation decision - possibly > depending on the alarm type, possibly configurable ? > The general answer is no, as stated in the document, there is no automati= c > purge/deletion of an alarm on clear from the resource or close from the > operator. > This is by design, from an ops perspective it makes sense to be able to v= iew > the alarm even after it is cleared/closed. > You might want to study the root cause afterwards to perform proactive > actions for it not to appear again for example. >=20 [Keen] Yes that makes good sense. > But as you say, you can make it an implementation decision, "purge on > clear", "purge on close". > If it is hard-coded per alarm-type, describe it in the alarm inventory Yo= u can > also make it configurable per alarm type by augmenting the alarm profile > with a purge-policy: "purge on clear", "purge on close" > > [Keen] Thanks. > > * RFC3877 has the following statement: "Alarms SHOULD be modelled so > Notifications are sent on alarm Clear." > > I did not find this statement in the substance of the draft nor in Appe= ndix > F (But it may have escaped me). > > Is this also the mindset of this draft ? > According to this alarm module an alarm-notification will be sent with > perceived-severity set to cleared [Keen] Is that stated explicitly in the draft ? Will you associate a keyword with this statement ? > > > > * It is correctly understood that the Alarm Summary and the Alarm list > contains the alarms which are presently in the system - i.e. which have n= ot > been purged ? > Correct > > * Would it be relevant for the Alarm Summary list to tell when alarms = was > last purged due to administrative action ? > We do not want to load the alarm module with more features at this point, > this could be done in the management application/client. > > [Keen] It might be prudent to have this state in the server as well (?) > > * Are you considering to implement support for statistics ? > What do you mean with statistics? > a) Statistics on alarms or do you mean a b) performance monitoring > module? > It a, no, that is up to the management application If b, that is a separa= te > module not within this one [Keen] I was referring to the first. Here first and foremost statistics on = received alarms divided on severity level. Yes it can be done in the management application, but I am not sure why it = is necessarily "up to the management application" to do this ? Would some global statistics in the server not make sense - or do you have = specific reasons for placing all statistics in the management application l= ayer ? BR, Karen >=20 > > > > > > BR, Karen > > > > -----Original Message----- > > From: Martin Bjorklund > > Sent: 20. september 2018 10:31 > > To: Karen Elisabeth Egede Nielsen > > Cc: ccamp@ietf.org; stefan@wallan.se; netmod@ietf.org > > Subject: Re: draft-ietf-ccamp-alarm-module-02 > > > > Hi, > > > > Karen Elisabeth Egede Nielsen wrote: > >> Hi, > >> > >> This draft is new to me and modelling of alarm management also > >> somewhat.... > >> > >> Could you enlighten me on the relationship, if any, in between the > >> alarm module of this draft and the Device/resource alarm state within > >> RFC8348 (equivalently the EntityAlarmStatus of RFC4268) ? > > > > The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is ju= st > a summary of the alarms that may be active on the specific hardware > component. It doesn't say anything about how alarms are reported, and it > doesn't provide any details of the alarms; it is just a bitmask. > > > > The alarm-module draft OTOH, specifies how alarms are reported, > generically. It also provides a list of all active alarms. > > > >> E.g. are the two they considered complementary mechanisms > (modules), > >> just different view glasses, or are they non-compatible or redundant > >> ..? > > > > So if both modules are implemented (they don't have to be), the > information can be viewed as redundant or just different views. > > > > > > /martin > > > > > > > >> > >> Many Thanks in advance ! > >> > >> > >> BR, Karen Nielsen > >> From nobody Tue Oct 2 00:45:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD43130DD1 for ; Tue, 2 Oct 2018 00:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 qUWSZpMksBJ5 for ; Tue, 2 Oct 2018 00:45:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4C12D130DCA for ; Tue, 2 Oct 2018 00:45:26 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 6AA2A60BE1 for ; Tue, 2 Oct 2018 09:45:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1538466324; bh=KZJU/0id0ZS38Y1ZVSc0AnT1xyvTEBz13TGi8h6KQIY=; h=From:To:Date; b=csCtd+P5/n0t4w06zUCXanFDL78V2YTg9/DGTiC4WZA6Ve+O7JRkbaIx7cKf8P3Bq LAYWyU6viYpROqZf8PFbuHXwBfxjrpIQcyLfG4k1qBwSZvIhQMI+Dw6IJxYxHb6xOB 6le3Csyp5WVN8gsMpX6lSzArmnfiYx+NSoRrcOdw= Message-ID: From: Ladislav Lhotka To: netmod@ietf.org Date: Tue, 02 Oct 2018 09:45:24 +0200 In-Reply-To: References: Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 07:45:30 -0000 Support. Lada On Mon, 2018-10-01 at 18:48 +0000, Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 2 01:55:07 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5FD130DD2 for ; Tue, 2 Oct 2018 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Lb8WFrlEu7Ck for ; Tue, 2 Oct 2018 01:55:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 322A512F1AB for ; Tue, 2 Oct 2018 01:55:03 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B6A9D18242616 for ; Tue, 2 Oct 2018 09:54:58 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 2 Oct 2018 09:55:00 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Tue, 2 Oct 2018 16:54:55 +0800 From: Qin Wu To: "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AdRaLWq+czCxli+FR/2Yvlqsl5dsMA== Date: Tue, 2 Oct 2018 08:54:55 +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.45.94.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 08:55:06 -0000 Support to adopt this draft. -Qin On Mon, 2018-10-01 at 18:48 +0000, Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt this=20 > draft, and no objections. >=20 > This email starts an adoption poll for: >=20 > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 >=20 > Please indicate your support or objection to the adoption poll.=20 > If objecting, please state your reasons on this thread. >=20 > Kent (and Lou and Joel) >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Oct 2 05:21:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E821130DFC for ; Tue, 2 Oct 2018 05:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 rRdEL8MXXmh3 for ; Tue, 2 Oct 2018 05:21:37 -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 71F57130DF6 for ; Tue, 2 Oct 2018 05:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1162; q=dns/txt; s=iport; t=1538482897; x=1539692497; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VpP8pdtp5r+7OgeUGY0EokG6Zre18wcwQCRBoXmqFAY=; b=FQWhzDT2/Pl0ngAlN7ijy1CQLXf3kVohVFcimsfSyUYSJFNz69iElQfn wRi0uj7WGLM36JLiZRv/67KyRy+O0YJdFeAP1xXFWqKyPD8VG93FIw9oI pgHAgzkIzAMFxwdg/+QagoyNDsWBp4Ff+QBL2RWS4vUeB3ObEH2/LPKe0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAACvYbNb/5BdJa1aGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUYIOZn8oCoNqiBWMG4Fog2KTHxSBZgsYC4QDRhmDdiE0GAEDAQE?= =?us-ascii?q?CAQECbRwMhTkGAQEhETodAQgODAImAgQlCxUSBAESgyEBggEPpR2BLoR3hSA?= =?us-ascii?q?FgQuJeBeBQT+BOQwTgkyDGwEBA4ErARIBNoJqMYImAp08CQKGRolwF4FJhF+?= =?us-ascii?q?JMowQiQkCERSBJR04ZHFwFTsqAYJBixaFPm+MEoEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,331,1534809600"; d="scan'208";a="180021984" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 12:21:36 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w92CLa4O018765 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Oct 2018 12:21:36 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Oct 2018 07:21:35 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Tue, 2 Oct 2018 07:21:35 -0500 From: "Reshad Rahman (rrahman)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWkp2I2nNckn+1ky1f4oa9l5TQA== Date: Tue, 2 Oct 2018 12:21:35 +0000 Message-ID: <2586B82B-1703-4579-B85F-82F158954ED0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.139] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 12:21:39 -0000 S2VudCwgSSBtYXkgaGF2ZSBhc2tlZCB0aGlzIHF1ZXN0aW9uIGluIE1vbnRyZWFsIGJ1dCBJIGRv bid0IHJlbWVtYmVyIHRoZSBhbnN3ZXI6IHdoeSBpcyB0aGlzIGRvY3VtZW50IGluIE5FVE1PRCBh bmQgbm90IGluIE5FVENPTkY/DQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCu+7v09uIDIwMTgtMTAt MDEsIDI6NDggUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0K DQogICAgVGhlIElFVEYgMTAyIGluLXJvb20gcG9sbCBzaG91bGQgcmVhbGx5IGdvb2Qgc3VwcG9y dCB0byBhZG9wdA0KICAgIHRoaXMgZHJhZnQsIGFuZCBubyBvYmplY3Rpb25zLg0KICAgIA0KICAg IFRoaXMgZW1haWwgc3RhcnRzIGFuIGFkb3B0aW9uIHBvbGwgZm9yOg0KICAgIA0KICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAN CiAgICANCiAgICBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiB0byB0 aGUgYWRvcHRpb24gcG9sbC4gDQogICAgSWYgb2JqZWN0aW5nLCBwbGVhc2Ugc3RhdGUgeW91ciBy ZWFzb25zIG9uIHRoaXMgdGhyZWFkLg0KICAgIA0KICAgIEtlbnQgKGFuZCBMb3UgYW5kIEpvZWwp DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K From nobody Tue Oct 2 06:51:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA75130DE1 for ; Tue, 2 Oct 2018 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ4RvZY3nhvQ for ; Tue, 2 Oct 2018 06:51:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2A313130DC9 for ; Tue, 2 Oct 2018 06:51:37 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 647EFDA953B65 for ; Tue, 2 Oct 2018 14:51:30 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 2 Oct 2018 14:51:31 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML702-CHM.china.huawei.com ([169.254.4.49]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 06:51:20 -0700 From: Yingzhen Qu To: Alexander Clemm , Jeff Tantsura , "netmod@ietf.org" , Kent Watsen Thread-Topic: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdVa1uJLAzfC0+Ye50AARhnB6ULRpEA//+seJCAAQeGSA== Date: Tue, 2 Oct 2018 13:51:19 +0000 Message-ID: 47807E19-8BA6-4251-B81E-9A9200C10DF3 References: <251AA816-2FA5-4EB3-8C15-BCD62DC45D94@juniper.net> <16175bff-d6f0-41ad-92c2-2051815758db@Spark>, <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9E@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6BB9E@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47807E198BA64251B81E9A9200C10DF3_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 13:51:41 -0000 --_000_47807E198BA64251B81E9A9200C10DF3_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgd2FzIG5vdCBkaXNjbG9zZWQu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGFua3MsDQpZaW5nemhlbg0K5Y+R5Lu25Lq677yaQWxleGFuZGVyIENsZW1tDQrmlLbku7bkurrv vJpKZWZmIFRhbnRzdXJhLG5ldG1vZEBpZXRmLm9yZyxLZW50IFdhdHNlbiwNCuaXtumXtO+8mjIw MTgtMTAtMDEgMTg6MTM6NDcNCuS4u+KAg+mimO+8mlJlOiBbbmV0bW9kXSBJUFIgcG9sbCBvbiBk cmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQoNCktlbnQsDQpzYW1lIGhlcmUuICBJIGFt IG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCBiZWVuIGRpc2Nsb3NlZC4gIChJIGFt IGF3YXJlIG9mIHRoZSBJUFIgdGhhdCB3YXMgZGlzY2xvc2VkIGEgeWVhciBhZ28gYW5kIHRoYXQg aXMgb24gZGF0YXRyYWNrZXIuKQ0KLS0tIEFsZXgNCg0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKZWZmIFRhbnRzdXJhDQpTZW50OiBN b25kYXksIE9jdG9iZXIgMDEsIDIwMTggNDowNyBQTQ0KVG86IG5ldG1vZEBpZXRmLm9yZzsgS2Vu dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gSVBS IHBvbGwgb24gZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0KDQpLZW50LA0KDQpJ4oCZ bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgYmVlbiBkaXNjbG9zZWQuDQpUaGFu a3MhDQoNCkNoZWVycywNCkplZmYNCk9uIE9jdCAxLCAyMDE4LCAxMTo0OCBBTSAtMDcwMCwgS2Vu dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+ Piwgd3JvdGU6DQoNClRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsIGZvciBkcmFmdC1jbGVt bS1uZXRtb2Qtbm1kYS1kaWZmLTAwLg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQ/IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQg aW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzPyBOb3RlLCB5b3UgZG8gbm90IGhhdmUg dG8gYmUgYW4gYXV0aG9yIG9yIGEgY29udHJpYnV0b3IgdG8gbWFrZSBldmVyeW9uZSBhd2FyZSBv ZiBhbiBJUFIuIFNlZSBSRkMgMzY2OSwgMzk3OSwgNDg3OSBhbmQgNTM3OCBmb3IgZGV0YWlscy4N Cg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9uIHRoZSBkb2N1bWVudCwgb3IgYXMg YSBjb250cmlidXRvciwgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlLW1haWwsIGluZGljYXRpbmcg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBScy4gVGhlIHJl c3BvbnNlIG5lZWRzIHRvIGJlIHNlbmQgdG8gdGhlIE5FVE1PRCBtYWlsaW5nIGxpc3QuIFRoZSBk b2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBhbGwgdGhlIGF1dGhvcnMgYW5kIGFueSBjb250cmli dXRvcnMuDQoNCktlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_47807E198BA64251B81E9A9200C10DF3_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCJ9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicml9DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWZ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe2NvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjojOTU0RjcyOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmV9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEfQ0KLk1zb0NocERlZmF1bHQNCgl7 Zm9udC1zaXplOjEwLjBwdH0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW59DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCi0tPg0KPC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0KKg0KCXt9DQpib2R5DQoJe2ZvbnQtZmFt aWx5OkNhbGlicml9DQotLT4NCjwvc3R5bGU+DQo8ZGl2Pjxicj4NCkhpLDxicj4NCjxicj4NCkkn bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IHdhcyBub3QgZGlzY2xvc2VkLjxicj4NCjxicj4N CjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGFua3MsPGJyPg0KWWluZ3poZW48L2Rpdj4NCjxk aXYgbmFtZT0iQW55T2ZmaWNlLUJhY2tncm91bmQtSW1hZ2UiIHN0eWxlPSJib3JkZXItdG9wOjFw eCBzb2xpZCAjQjVDNERGOyBwYWRkaW5nOjhweCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJy ZWFrLWFsbCI+PGI+5Y+R5Lu25Lq677yaPC9iPkFsZXhhbmRlciBDbGVtbTwvZGl2Pg0KPGRpdiBz dHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuaUtuS7tuS6uu+8mjwvYj5KZWZmIFRhbnRz dXJhLG5ldG1vZEBpZXRmLm9yZyxLZW50IFdhdHNlbiw8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQt YnJlYWs6YnJlYWstYWxsIj48Yj7ml7bpl7TvvJo8L2I+MjAxOC0xMC0wMSAxODoxMzo0NzwvZGl2 Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuS4u+KAg+mimO+8mjwvYj5S ZTogW25ldG1vZF0gSVBSIHBvbGwgb24gZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjoj MUY0OTdEIj5LZW50LA0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPnNhbWUgaGVyZS4mbmJzcDsgSSBhbSBub3QgYXdhcmUg b2YgYW55IElQUiB0aGF0IGhhcyBub3QgYmVlbiBkaXNjbG9zZWQuJm5ic3A7IChJIGFtIGF3YXJl IG9mIHRoZSBJUFIgdGhhdCB3YXMgZGlzY2xvc2VkIGEgeWVhciBhZ28gYW5kIHRoYXQgaXMgb24g ZGF0YXRyYWNrZXIuKQ0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPi0tLSBBbGV4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDsgcGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7IGJvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDsgcGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KZWZmIFRhbnRzdXJhPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAwMSwgMjAxOCA0OjA3IFBNPGJyPg0KPGI+VG86PC9i PiBuZXRtb2RAaWV0Zi5vcmc7IEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gSVBSIHBvbGwgb24gZHJhZnQtY2xl bW0tbmV0bW9kLW5tZGEtZGlmZi0wMDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPGRpdiBuYW1lPSJtZXNzYWdlQm9keVNlY3Rpb24i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPktlbnQsDQo8L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPknigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCBiZWVuIGRpc2Nsb3Nl ZC48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPlRoYW5rcyEmbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg bmFtZT0ibWVzc2FnZVNpZ25hdHVyZVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjxicj4NCkNoZWVycywgPC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SmVmZjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBuYW1lPSJtZXNzYWdlUmVwbHlTZWN0aW9uIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5PbiBPY3QgMSwgMjAxOCwgMTE6NDggQU0gLTA3MDAsIEtlbnQgV2F0 c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5p cGVyLm5ldDwvYT4mZ3Q7LCB3cm90ZTo8YnI+DQo8YnI+DQo8L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItbGVmdDpzb2xpZCAjMUFCQzlDIDEuMHB0OyBw YWRkaW5nOjBpbiAwaW4gMGluIDguMHB0OyBtYXJnaW4tbGVmdDozLjc1cHQ7IG1hcmdpbi10b3A6 My43NXB0OyBtYXJnaW4tcmlnaHQ6My43NXB0OyBtYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBS IHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAuPGJyPg0KPGJyPg0KQXJl IHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0PyBJZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcz8gTm90ZSwgeW91IGRvIG5vdCBoYXZlIHRvIGJlIGFuIGF1dGhvciBvciBhIGNvbnRyaWJ1 dG9yIHRvIG1ha2UgZXZlcnlvbmUgYXdhcmUgb2YgYW4gSVBSLiBTZWUgUkZDIDM2NjksIDM5Nzks IDQ4NzkgYW5kIDUzNzggZm9yIGRldGFpbHMuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBsaXN0ZWQg YXMgYW4gYXV0aG9yIG9uIHRoZSBkb2N1bWVudCwgb3IgYXMgYSBjb250cmlidXRvciwgcGxlYXNl IHJlc3BvbmQgdG8gdGhpcyBlLW1haWwsIGluZGljYXRpbmcgd2hldGhlciBvciBub3QgeW91IGFy ZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBScy4gVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNl bmQgdG8gdGhlIE5FVE1PRCBtYWlsaW5nIGxpc3QuIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZh bmNlIHRvIHRoZQ0KIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZl ZCBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgYW55IGNvbnRyaWJ1dG9ycy48YnI+DQo8YnI+DQpL ZW50IChhbmQgTG91IGFuZCBKb2VsKTxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_47807E198BA64251B81E9A9200C10DF3_-- From nobody Tue Oct 2 06:52:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B1130E01 for ; Tue, 2 Oct 2018 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6lPbbcWM7Jf for ; Tue, 2 Oct 2018 06:52:48 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5672130DC9 for ; Tue, 2 Oct 2018 06:52:47 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w92Do8Nv005631; Tue, 2 Oct 2018 06:52:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=kc25p0niNx8hFvJoxM0f8pa3wWFHOd/2jE0Sv2fRzhc=; b=Q2NJYS7GWpjipVEg/hpxAr18I9agLQ2TBXkBEDCDPXQe0vuXrKMPaIyTV6y0HCJp+eim 4sVQI908FGiJnFmmOA/1hIvO3MeDJB44GSimHbhskR38xjLRcYwGeCjC/r7vbemZn8Cg zhZIkYvs0URGV258Cs5RcNNspx2OhJ831yEULWbPTSUcWUvtOKTR/hsNeFcqFn1t3VdJ gPvxDWXb0z4/DaDjsfWmVbqkO5MRGJ96zavzwBAkai/ExK93Kw+rZYF+m4S/xGin3dtw VoY6/qV/4ehPNJ2a/XPE4PqEAPrzGl4x/K4TOw5/7w3Z7MbuQ4U7Bqvlr0HPDv59kkEd mw== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0053.outbound.protection.outlook.com [216.32.180.53]) by mx0b-00273201.pphosted.com with ESMTP id 2mv05q164y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Oct 2018 06:52:46 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4043.namprd05.prod.outlook.com (20.176.71.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.17; Tue, 2 Oct 2018 13:52:43 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Tue, 2 Oct 2018 13:52:43 +0000 From: Kent Watsen To: "Reshad Rahman (rrahman)" , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWkp2I2nNckn+1ky1f4oa9l5TQKULtr8A Date: Tue, 2 Oct 2018 13:52:43 +0000 Message-ID: <0FEFF2C8-306D-4811-80B1-A075C73D1E33@juniper.net> References: <2586B82B-1703-4579-B85F-82F158954ED0@cisco.com> In-Reply-To: <2586B82B-1703-4579-B85F-82F158954ED0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4043; 6:H/fbVLVOZ4nj9WXn+QJkMRdpYER+WBZaiKYWYxNoxKfuWR4V/aFqIyJZtFov53CYpqFO0KhKsP0kF9WZd2VdM+DOkOttWIJNKYkcf/dteWgA9pZA1WPd8AnTFUhAjoFxme0s5LSokRzN94r1ISKX6sY5ycqwMt8saIhBpd9Hf8pGfoNqHQColBvTbI/twuzvvdk3GwJNkI3rkQDdv9jrvP1RsLDFzi/vYPnBXu4djWNsHmuHJSqOsrom+AwyQ2aX9qebtVATFndYY8y8w+ElJiQx725LiMVoON0zaLKfu79vQQ+2yxutg2z//0/xgfC1YmvWcN1T+X1p5CmYNXo0zvXxAtDjaloKsCrCUdYtwsUxtrNlT/8IMzuT8S34uKs67RVX+QmAqRPCYl0BbvRwj9KtREXbFLwY38c77T8ppVbon5zsPYdTq6PGWI/7OCBL2QNXYbZCWl8+MrHi0OKCLQ==; 5:j3BtPJmEuKz+j1tHv67yrLI6rOPiLO9olUoAcp3PK0y/rfgtHxhoAme+0ZKL0J0hcVkYwWbAUmqx6+XI35lHtB0wMttsSnqdXdF0NI8izOP04t/eRvs2tfRUSqCmCZr2EJZ071iEOEPZ2e4SRJBid911Ap+nCbHJOtQJW8pkzus=; 7:CpgczNDkwsCuyZk3e0XIRpEPQCwF4nwNc/YZEipdAQ983rqRwUM8VexnqEFTEkLK5ax7DDXmMQXCi0DdaOCiJzVffIRq5nO1V9+cGwdMFwebMBMM89Qr9wOxZzQyu3TXp+3bpwjM8MRMNvjzAQtJIiareerDL24f4duaVR76iGLhUNRtlyK5oqLS/O+FzklYNnHCuPJe79FhOFronXdahmVV+/pU5dy4UZ/DyOW7yIEPar6VZcfJeJoeLsQONz/H x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6610bf5f-c800-4c47-074b-08d6286e53af x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4043; x-ms-traffictypediagnostic: DM6PR05MB4043: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(95692535739014)(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991041); SRVR:DM6PR05MB4043; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4043; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(39860400002)(396003)(376002)(13464003)(189003)(199004)(105586002)(316002)(25786009)(6512007)(53936002)(256004)(14444005)(2906002)(446003)(14454004)(66066001)(6436002)(106356001)(476003)(305945005)(229853002)(3846002)(966005)(6116002)(8676002)(81166006)(81156014)(6306002)(486006)(478600001)(86362001)(71200400001)(6506007)(83716004)(71190400001)(53546011)(26005)(5660300001)(97736004)(186003)(58126008)(33656002)(110136005)(2900100001)(7736002)(575784001)(8936002)(2616005)(76176011)(2501003)(36756003)(68736007)(5250100002)(99286004)(11346002)(6246003)(6486002)(102836004)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4043; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: +Lp050kOcnUBzfvvIBnBu4396SCbHlc1IaK1kROrHXOClTsDNBminqLpg3sqDRqXlrhg2SEArZM0M4aVfBMrZ+RyH7hkcMRUI607LMin29bSEPZlHZn9psug9ZOWYzvg91PHn7vNQg1whO1XxUBYUuSmzMq3n0ALsTe18WB9JS86iPdajRQ5qdfIhxx+EpSHRYSYPnxU4ycJHyCM9YfiQxu4nDCXT4PVRX6So4rqiPNDESe9OJJjwAcsWjZ0oCs2UNxdH71kJbwESwEo6rbslGTRd/jzoAb35iy87eD4c7WRolTNUpy7jJFh8H7vrz9WB7IunwavNcNc4bAN/vStDpMMRhLV3dr4PdXkepKXZQU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3A9F9432717F6843A741A0D306292393@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6610bf5f-c800-4c47-074b-08d6286e53af X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2018 13:52:43.3405 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4043 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810020137 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 13:52:52 -0000 SGkgUmVzaGFkLCB0aGFua3MgZm9yIGFza2luZy4NCg0KSXQncyBhIGdyZXkgYXJlYS4gIEl0IGNv dWxkIGdvIGVpdGhlciB3YXkuICBCb3RoIGNoYXJ0ZXJzIHN1cHBvcnQgdGhlIHdvcmsuICBUaGUg Y2hhaXJzIGFyZSBhbGwgNTAvNTAgYXMgZm9yIGJlc3QgZml0LiAgU3F1aW50aW5nLCBpdCBzZWVt cyBtb3JlIGFuIE5NREEtdGhpbmcgdGhhbiBhIHRyYW5zcG9ydC10aGluZyAoaS5lLiwgbm90IE5D IG9yIFJDIHNwZWNpZmljKSwgYW5kIE5FVE1PRCBpcyBtb3JlIHRoZSAiTk1EQSBncm91cCIgdGhh biBORVRDT05GLCBhdCBsZWFzdCB0aGUgZmlyc3Qtb3JkZXIgb2YgaXQgc2VlbXMgdG8gYmUgdGhh dCB3YXkuDQoNClRoYXQgc2FpZCwgTkVUQ09ORiBpcyBvdmVybG9hZGVkIGFuZCBORVRNT0QgaXMg bm90ICgxNCB2cyA0IGRyYWZ0cykuICBPZiBjb3Vyc2UsIHNpbWlsYXIgcGVvcGxlIGFyZSBpbiBi b3RoIHdvcmtpbmcgZ3JvdXBzLCBidXQgaXQgd291bGQgYmUgZ29vZCB0byBvZmZsb2FkIHNvbWUg ZGlzY3Vzc2lvbiBmcm9tIHRoZSBORVRDT05GIGxpc3QgYW5kIGdpdmUgdGhpcyBXRyBzb21ldGhp bmcgbW9yZSB0byB3b3JrIG9uLiAgSSBob3BlIHRoaXMgaXMgb2theSB3aXRoIGV2ZXJ5b25lLg0K DQpXaXRoIHJlc3BlY3QgdG8gdGhlIGFkb3B0aW9uIHBvbGwuICBUaGUgaW1wb3J0YW50IHRoaW5n IGhlcmUgaXMgaWYgYW55b25lIG9iamVjdHMuICBEbyB5b3Ugb3IgYW55b25lIGVsc2Ugb2JqZWN0 Pw0KDQpLZW50IC8vIGNoYWlyDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KRGF0ZTog VHVlc2RheSwgT2N0b2JlciAyLCAyMDE4IGF0IDg6MjEgQU0NClRvOiBLZW50IFdhdHNlbiA8a3dh dHNlbkBqdW5pcGVyLm5ldD4sICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0 bW9kLW5tZGEtZGlmZi0wMA0KDQpLZW50LCBJIG1heSBoYXZlIGFza2VkIHRoaXMgcXVlc3Rpb24g aW4gTW9udHJlYWwgYnV0IEkgZG9uJ3QgcmVtZW1iZXIgdGhlIGFuc3dlcjogd2h5IGlzIHRoaXMg ZG9jdW1lbnQgaW4gTkVUTU9EIGFuZCBub3QgaW4gTkVUQ09ORj8NCg0KUmVnYXJkcywNClJlc2hh ZC4NCg0KT24gMjAxOC0xMC0wMSwgMjo0OCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgS2VudCBX YXRzZW4iIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5p cGVyLm5ldD4gd3JvdGU6DQoNCiAgICBUaGUgSUVURiAxMDIgaW4tcm9vbSBwb2xsIHNob3VsZCBy ZWFsbHkgZ29vZCBzdXBwb3J0IHRvIGFkb3B0DQogICAgdGhpcyBkcmFmdCwgYW5kIG5vIG9iamVj dGlvbnMuDQogICAgDQogICAgVGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gcG9sbCBmb3I6 DQogICAgDQogICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRjbGVtbS0yRG5ldG1vZC0yRG5t ZGEtMkRkaWZmLTJEMDAmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRi M3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa byZtPWNNQTlHT2pYYkVXS3NMOUlDaWFrS1N0TVpTdVBmTk9ybGJMT09rSXJkcVUmcz1CS0E2Zkkt UVkydHRfTlRPdmE5STYxNDgyTEdHWmR6RE1GQnFWRjFPXzBzJmU9DQogICAgDQogICAgUGxlYXNl IGluZGljYXRlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24gdG8gdGhlIGFkb3B0aW9uIHBvbGwu IA0KICAgIElmIG9iamVjdGluZywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBvbiB0aGlzIHRo cmVhZC4NCiAgICANCiAgICBLZW50IChhbmQgTG91IGFuZCBKb2VsKQ0KICAgIA0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1h aWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fbmV0bW9kJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2 b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8m bT1jTUE5R09qWGJFV0tzTDlJQ2lha0tTdE1aU3VQZk5PcmxiTE9Pa0lyZHFVJnM9VkNsUUw5TTd0 LWZ6My1kSnFNR2k4dEstX2l5UGZieWl6cVBBX3g4Vk1IbyZlPQ0KICAgIA0KDQoNCg== From nobody Tue Oct 2 07:07:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E1130E7F for ; Tue, 2 Oct 2018 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 D3VFbPfiSlre for ; Tue, 2 Oct 2018 07:07: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 0C17A130E59 for ; Tue, 2 Oct 2018 07:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=580; q=dns/txt; s=iport; t=1538489268; x=1539698868; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=mjPOU1W55ntKOsUo8BW5gzACUKKkrVXJwmJmIqWtchc=; b=WTB+Vx5eoh9pBa9+1fDr6JWd2Hesl9Orv3ldAAK6cVdzxuljhqNCaebP QGjr967HZblVeYsnF8O/h0M8oO4vt/2ZNiHg2B5JBAmsNZ4Edyy58xQa/ dAw/Y5VT5OjQyibxBi5fQNV8UUVs18TwkEP6zvLz5gWMwow80jC0u0W9D 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAABPe7Nb/xbLJq1aGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBU4JybRIog3SIdI1JllwUgWYLGAuEA0YChC82FgEDAQECAQE?= =?us-ascii?q?CbRwMhTkBAQEDAQEhFTYbCw4KAgImAgInMAYBDAYCAQGDHQGCAQ+lT4EuhHe?= =?us-ascii?q?FIAWBC4oPgUE/gTmCa4MbAQEDgSsBEgGDIIJXAo5ShSmJQQmGSIlqBheBOg+?= =?us-ascii?q?EX4Jlhk2MEIMRhh+BSQcqZHEzGggbFTuCbIsWhT8+MIwSgj4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,332,1534809600"; d="scan'208";a="6946828" 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; 02 Oct 2018 14:07:30 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w92E7TBv018173; Tue, 2 Oct 2018 14:07:29 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <166b3bb1-270c-bc9b-3dbd-9bea5c3199fb@cisco.com> Date: Tue, 2 Oct 2018 15:07:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:07:55 -0000 Support. On 01/10/2018 19:48, Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Oct 2 07:10:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD8130EB1 for ; Tue, 2 Oct 2018 07:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 DEW6dfYoc8u3 for ; Tue, 2 Oct 2018 07:10:55 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95821130EB0 for ; Tue, 2 Oct 2018 07:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=962; q=dns/txt; s=iport; t=1538489455; x=1539699055; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NfaOnrPQDB58JrNeP70gB7XNpUubLlX7usSnHo4tkjw=; b=eOPbkEGrtbitip0hBQb1bQ7INPU9ky1uReyNnJQAY0PpNlur+BhrYWNq tGGnxPvwlcbGtuHU6msfB5TPySUbMzJH0ejIW2Hd3/TMug2GLftJXuVTS cchtr6SVUN5X/dGwvO8mwzRLhbA/f+0QfVgVkoXR9ymjCI56MMG+vhHbw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAABPe7Nb/4ENJK1aGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUYIOZn8oCoNqiBWMG4VKkx8UgWYLGAuEA1+DdyE0GAEDAQECAQE?= =?us-ascii?q?CbRwMhTkGAQEhETodAQgODAImAgQlCxUSBAESgyEBggEPpU+BLoR3hSAFgQu?= =?us-ascii?q?JeBeCAIE5H4JMgxsBAQOBKwESAYMgMYImAp08CQKGRolwF4E6D4RfiTKMEIk?= =?us-ascii?q?JAhEUgSUdOGRxcBU7KgGCQYsWhT5vjBKBH4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,332,1534809600"; d="scan'208";a="179831541" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 14:10:54 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w92EAsmi028953 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Oct 2018 14:10:54 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Oct 2018 10:10:53 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 2 Oct 2018 10:10:53 -0400 From: "Acee Lindem (acee)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWlm6I2nNckn+1ky1f4oa9l5TQA== Date: Tue, 2 Oct 2018 14:10:53 +0000 Message-ID: <4D88A46F-A84F-4B9A-B986-B86876044D90@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <81BACA74C0112649A198CF8F395EAEF4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:10:57 -0000 U3VwcG9ydC4gDQoNCu+7v09uIDEwLzEvMTgsIDI6NDggUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9m IEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRz ZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgVGhlIElFVEYgMTAyIGluLXJvb20gcG9sbCBz aG91bGQgcmVhbGx5IGdvb2Qgc3VwcG9ydCB0byBhZG9wdA0KICAgIHRoaXMgZHJhZnQsIGFuZCBu byBvYmplY3Rpb25zLg0KICAgIA0KICAgIFRoaXMgZW1haWwgc3RhcnRzIGFuIGFkb3B0aW9uIHBv bGwgZm9yOg0KICAgIA0KICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNs ZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDANCiAgICANCiAgICBQbGVhc2UgaW5kaWNhdGUgeW91ciBz dXBwb3J0IG9yIG9iamVjdGlvbiB0byB0aGUgYWRvcHRpb24gcG9sbC4gDQogICAgSWYgb2JqZWN0 aW5nLCBwbGVhc2Ugc3RhdGUgeW91ciByZWFzb25zIG9uIHRoaXMgdGhyZWFkLg0KICAgIA0KICAg IEtlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAg bmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCiAgICANCg0K From nobody Tue Oct 2 07:19:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C65130F81 for ; Tue, 2 Oct 2018 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4OPXIpbGD-r for ; Tue, 2 Oct 2018 07:18:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D15D130F72 for ; Tue, 2 Oct 2018 07:18:54 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C95081AE0442; Tue, 2 Oct 2018 16:18:52 +0200 (CEST) Date: Tue, 02 Oct 2018 16:18:52 +0200 (CEST) Message-Id: <20181002.161852.1447537350173076687.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:19:03 -0000 Hi, I support the adoption of this document. /martin Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Oct 2 07:22:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197FA130E89 for ; Tue, 2 Oct 2018 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdxAFXAK8KLG for ; Tue, 2 Oct 2018 07:22:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 85F0F130E83 for ; Tue, 2 Oct 2018 07:22:00 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A66F78A1456A7 for ; Tue, 2 Oct 2018 15:21:55 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 2 Oct 2018 15:21:57 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML702-CHM.china.huawei.com ([169.254.4.49]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 07:21:51 -0700 From: Yingzhen Qu To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWltCCiUnJCouu0GoCtKr03T1rA== Date: Tue, 2 Oct 2018 14:21:51 +0000 Message-ID: 563EF701-D67A-449A-BD67-B175CB297E1B References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_563EF701D67A449ABD67B175CB297E1B_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:22:02 -0000 --_000_563EF701D67A449ABD67B175CB297E1B_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBBcyBjb2F1dGhvci4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRoYW5rcywNCllpbmd6aGVuDQrlj5Hku7bkurrvvJpLZW50IFdh dHNlbg0K5pS25Lu25Lq677yabmV0bW9kQGlldGYub3JnLA0K5pe26Ze077yaMjAxOC0xMC0wMSAx NDo0ODo1NQ0K5Li74oCD6aKY77yaW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQt Y2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0KDQpUaGUgSUVURiAxMDIgaW4tcm9vbSBwb2xsIHNo b3VsZCByZWFsbHkgZ29vZCBzdXBwb3J0IHRvIGFkb3B0DQp0aGlzIGRyYWZ0LCBhbmQgbm8gb2Jq ZWN0aW9ucy4NCg0KVGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gcG9sbCBmb3I6DQoNCiAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYt MDANCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24gdG8gdGhlIGFk b3B0aW9uIHBvbGwuDQpJZiBvYmplY3RpbmcsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgb24g dGhpcyB0aHJlYWQuDQoNCktlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpu ZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kDQo= --_000_563EF701D67A449ABD67B175CB297E1B_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8IS0tDQotLT4NCjwvc3R5 bGU+DQo8ZGl2Pg0KPGRpdj5TdXBwb3J0IEFzIGNvYXV0aG9yLjxicj4NCjxicj4NCjwvZGl2Pg0K PGRpdj48L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQpUaGFua3MsPGJyPg0KWWluZ3poZW48L2Rpdj4NCjxkaXYgbmFtZT0i eF9BbnlPZmZpY2UtQmFja2dyb3VuZC1JbWFnZSIgc3R5bGU9ImJvcmRlci10b3A6MXB4IHNvbGlk ICNCNUM0REY7IHBhZGRpbmc6OHB4Ij4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxs Ij48Yj7lj5Hku7bkurrvvJo8L2I+S2VudCBXYXRzZW48L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQt YnJlYWs6YnJlYWstYWxsIj48Yj7mlLbku7bkurrvvJo8L2I+bmV0bW9kQGlldGYub3JnLDwvZGl2 Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuaXtumXtO+8mjwvYj4yMDE4 LTEwLTAxIDE0OjQ4OjU1PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+ PGI+5Li74oCD6aKY77yaPC9iPltuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNs ZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDA8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8 ZGl2IGNsYXNzPSJQbGFpblRleHQiPlRoZSBJRVRGIDEwMiBpbi1yb29tIHBvbGwgc2hvdWxkIHJl YWxseSBnb29kIHN1cHBvcnQgdG8gYWRvcHQ8YnI+DQp0aGlzIGRyYWZ0LCBhbmQgbm8gb2JqZWN0 aW9ucy48YnI+DQo8YnI+DQpUaGlzIGVtYWlsIHN0YXJ0cyBhbiBhZG9wdGlvbiBwb2xsIGZvcjo8 YnI+DQo8YnI+DQombmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwPC9hPjxicj4NCjxicj4NClBsZWFzZSBp bmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBhZG9wdGlvbiBwb2xsLiA8 YnI+DQpJZiBvYmplY3RpbmcsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgb24gdGhpcyB0aHJl YWQuPGJyPg0KPGJyPg0KS2VudCAoYW5kIExvdSBhbmQgSm9lbCk8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWls aW5nIGxpc3Q8YnI+DQpuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_563EF701D67A449ABD67B175CB297E1B_-- From nobody Tue Oct 2 07:26:13 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C306130E89 for ; Tue, 2 Oct 2018 07:26:11 -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 6UE-gYt6TKL5 for ; Tue, 2 Oct 2018 07:26:08 -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 A9F46130E78 for ; Tue, 2 Oct 2018 07:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3716; q=dns/txt; s=iport; t=1538490368; x=1539699968; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gqeBi6OHzPpFNlr2l+uoxUF223mWvPLfpnYgvMBSoPU=; b=milXKsGDJJkl3XDL4oVhD4Cwn83Eqv6uvl5WTUxiGAJArEPvP1/vdzM7 sOqsLO57JJPkp+Wg+uxd6aFRbYWEckfSLyD3FkwDmJoexj7VBnkAtt5Gp S7vvODIdpSLCNuXFIpWvnqhQtFHnTK1n9DVYwaBCWZ0WnP3MjrxXgK2IT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAACCf7Nb/4gNJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCoNqiBWMG4FoJYM9kx8UgWYLHw2EQAIXg3c?= =?us-ascii?q?hNBgBAwEBAgEBAm0cDIU4AQEBAQMjEToXBAIBCA4DAwECAwImAgICMBUICAI?= =?us-ascii?q?EARKDIQGCAaYDgS6Ed4UlgQuJeBeBQT+BEicME4JMhEsBEgEfF4JqMYImAp0?= =?us-ascii?q?8CQKGRoMNhmMXgUlLhBSJMpUZAhEUgSUdOGRxcBU7KgGCQQmCHBeDRopSb4E?= =?us-ascii?q?WinyBHwGBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,332,1534809600"; d="scan'208";a="460348030" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2018 14:26:07 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w92EQ79h008120 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Oct 2018 14:26:07 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Oct 2018 09:26:06 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Tue, 2 Oct 2018 09:26:06 -0500 From: "Reshad Rahman (rrahman)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWkp2I2nNckn+1ky1f4oa9l5TQKULtr8AgABcxQA= Date: Tue, 2 Oct 2018 14:26:06 +0000 Message-ID: References: <2586B82B-1703-4579-B85F-82F158954ED0@cisco.com> <0FEFF2C8-306D-4811-80B1-A075C73D1E33@juniper.net> In-Reply-To: <0FEFF2C8-306D-4811-80B1-A075C73D1E33@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.215] Content-Type: text/plain; charset="utf-8" Content-ID: <88958E1D9C4B0347A7C7D900E8FC66D2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:26:11 -0000 Tm8gb2JqZWN0aW9uLCBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KUmVn YXJkcywNClJlc2hhZC4NCg0KDQrvu79PbiAyMDE4LTEwLTAyLCA5OjUyIEFNLCAiS2VudCBXYXRz ZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KICAgIEhpIFJlc2hhZCwgdGhhbmtz IGZvciBhc2tpbmcuDQogICAgDQogICAgSXQncyBhIGdyZXkgYXJlYS4gIEl0IGNvdWxkIGdvIGVp dGhlciB3YXkuICBCb3RoIGNoYXJ0ZXJzIHN1cHBvcnQgdGhlIHdvcmsuICBUaGUgY2hhaXJzIGFy ZSBhbGwgNTAvNTAgYXMgZm9yIGJlc3QgZml0LiAgU3F1aW50aW5nLCBpdCBzZWVtcyBtb3JlIGFu IE5NREEtdGhpbmcgdGhhbiBhIHRyYW5zcG9ydC10aGluZyAoaS5lLiwgbm90IE5DIG9yIFJDIHNw ZWNpZmljKSwgYW5kIE5FVE1PRCBpcyBtb3JlIHRoZSAiTk1EQSBncm91cCIgdGhhbiBORVRDT05G LCBhdCBsZWFzdCB0aGUgZmlyc3Qtb3JkZXIgb2YgaXQgc2VlbXMgdG8gYmUgdGhhdCB3YXkuDQog ICAgDQogICAgVGhhdCBzYWlkLCBORVRDT05GIGlzIG92ZXJsb2FkZWQgYW5kIE5FVE1PRCBpcyBu b3QgKDE0IHZzIDQgZHJhZnRzKS4gIE9mIGNvdXJzZSwgc2ltaWxhciBwZW9wbGUgYXJlIGluIGJv dGggd29ya2luZyBncm91cHMsIGJ1dCBpdCB3b3VsZCBiZSBnb29kIHRvIG9mZmxvYWQgc29tZSBk aXNjdXNzaW9uIGZyb20gdGhlIE5FVENPTkYgbGlzdCBhbmQgZ2l2ZSB0aGlzIFdHIHNvbWV0aGlu ZyBtb3JlIHRvIHdvcmsgb24uICBJIGhvcGUgdGhpcyBpcyBva2F5IHdpdGggZXZlcnlvbmUuDQog ICAgDQogICAgV2l0aCByZXNwZWN0IHRvIHRoZSBhZG9wdGlvbiBwb2xsLiAgVGhlIGltcG9ydGFu dCB0aGluZyBoZXJlIGlzIGlmIGFueW9uZSBvYmplY3RzLiAgRG8geW91IG9yIGFueW9uZSBlbHNl IG9iamVjdD8NCiAgICANCiAgICBLZW50IC8vIGNoYWlyDQogICAgDQogICAgDQogICAgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbiki IDxycmFobWFuQGNpc2NvLmNvbT4NCiAgICBEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDIsIDIwMTgg YXQgODoyMSBBTQ0KICAgIFRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sICJu ZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgU3ViamVjdDogUmU6IFtuZXRt b2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAN CiAgICANCiAgICBLZW50LCBJIG1heSBoYXZlIGFza2VkIHRoaXMgcXVlc3Rpb24gaW4gTW9udHJl YWwgYnV0IEkgZG9uJ3QgcmVtZW1iZXIgdGhlIGFuc3dlcjogd2h5IGlzIHRoaXMgZG9jdW1lbnQg aW4gTkVUTU9EIGFuZCBub3QgaW4gTkVUQ09ORj8NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIFJl c2hhZC4NCiAgICANCiAgICBPbiAyMDE4LTEwLTAxLCAyOjQ4IFBNLCAibmV0bW9kIG9uIGJlaGFs ZiBvZiBLZW50IFdhdHNlbiIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBr d2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCiAgICANCiAgICAgICAgVGhlIElFVEYgMTAyIGlu LXJvb20gcG9sbCBzaG91bGQgcmVhbGx5IGdvb2Qgc3VwcG9ydCB0byBhZG9wdA0KICAgICAgICB0 aGlzIGRyYWZ0LCBhbmQgbm8gb2JqZWN0aW9ucy4NCiAgICAgICAgDQogICAgICAgIFRoaXMgZW1h aWwgc3RhcnRzIGFuIGFkb3B0aW9uIHBvbGwgZm9yOg0KICAgICAgICANCiAgICAgICAgICBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfZHJhZnQtMkRjbGVtbS0yRG5ldG1vZC0yRG5tZGEtMkRkaWZmLTJEMDAmZD1E d0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXpr UDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWNNQTlHT2pYYkVXS3NM OUlDaWFrS1N0TVpTdVBmTk9ybGJMT09rSXJkcVUmcz1CS0E2ZkktUVkydHRfTlRPdmE5STYxNDgy TEdHWmR6RE1GQnFWRjFPXzBzJmU9DQogICAgICAgIA0KICAgICAgICBQbGVhc2UgaW5kaWNhdGUg eW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiB0byB0aGUgYWRvcHRpb24gcG9sbC4gDQogICAgICAg IElmIG9iamVjdGluZywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBvbiB0aGlzIHRocmVhZC4N CiAgICAgICAgDQogICAgICAgIEtlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQogICAgICAgIA0KICAg ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgICAg ICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y01BOUdPalhiRVdLc0w5SUNpYWtLU3RNWlN1UGZOT3Js YkxPT2tJcmRxVSZzPVZDbFFMOU03dC1mejMtZEpxTUdpOHRLLV9peVBmYnlpenFQQV94OFZNSG8m ZT0NCiAgICAgICAgDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Tue Oct 2 10:07:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BB21311CB for ; Tue, 2 Oct 2018 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY0Mtvvlu1gG for ; Tue, 2 Oct 2018 10:07:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E48491311C2 for ; Tue, 2 Oct 2018 10:02:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.230.7.161; From: "Susan Hares" To: , "'Kent Watsen'" References: In-Reply-To: Date: Tue, 2 Oct 2018 13:02:52 -0400 Message-ID: <012001d45a71$c249ae80$46dd0b80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01D45A50.3B391FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZONRQ72AyjTA3JbPTW+QTuRVB8AFKn6WUpHgctlA= Content-Language: en-us X-Antivirus: AVG (VPS 181002-4, 10/02/2018), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 17:07:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0121_01D45A50.3B391FF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Support! Important work! Susan Hares From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, October 1, 2018 4:08 PM To: netmod@ietf.org; Kent Watsen Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Support as co-author Cheers, Jeff On Oct 1, 2018, 11:48 AM -0700, Kent Watsen , wrote: The IETF 102 in-room poll should really good support to adopt this draft, and no objections. This email starts an adoption poll for: https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 Please indicate your support or objection to the adoption poll. If objecting, please state your reasons on this thread. Kent (and Lou and Joel) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0121_01D45A50.3B391FF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Support!=C2=A0 Important work!

 

Susan Hares

 

From:= = netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Jeff = Tantsura
Sent: Monday, October 1, 2018 4:08 PM
To: = netmod@ietf.org; Kent Watsen
Subject: Re: [netmod] WG adoption = poll for = draft-clemm-netmod-nmda-diff-00

 

Support as = co-author


Cheers, =

Jeff

On Oct 1, = 2018, 11:48 AM -0700, Kent Watsen <kwatsen@juniper.net>, = wrote:

The IETF 102 = in-room poll should really good support to adopt
this draft, and no = objections.

This email starts an adoption poll = for:

https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00
Please indicate your support or objection to the adoption = poll.
If objecting, please state your reasons on this = thread.

Kent (and Lou and = Joel)

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

------=_NextPart_000_0121_01D45A50.3B391FF0-- From nobody Tue Oct 2 13:04:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6A1310AB; Tue, 2 Oct 2018 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 0oGZiiD4BVCs; Tue, 2 Oct 2018 13:04:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 DCFF6131067; Tue, 2 Oct 2018 13:04:53 -0700 (PDT) Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id w92K4qht023151; Tue, 2 Oct 2018 20:04:52 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local To: joel jaeggli , netmod@ietf.org, draft-ietf-netmod-module-tags@ietf.org References: <99C61F4F-6826-4FB5-87A1-77BED624B53D@gmail.com> From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: <11733205-c70f-9005-accd-635ce04d0da6@bogus.com> Date: Tue, 2 Oct 2018 13:04:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <99C61F4F-6826-4FB5-87A1-77BED624B53D@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C1IjLZ4ho0ZdwWS9mPbXsTqozOflYjRJ4" Archived-At: Subject: [netmod] Mulligan - Re: WG adoption poll draft-ietf-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 20:04:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C1IjLZ4ho0ZdwWS9mPbXsTqozOflYjRJ4 Content-Type: multipart/mixed; boundary="dvycP3NKoigU85e3tzBuNlpUQcx7DtkpZ"; protected-headers="v1" From: joel jaeggli To: joel jaeggli , netmod@ietf.org, draft-ietf-netmod-module-tags@ietf.org Message-ID: <11733205-c70f-9005-accd-635ce04d0da6@bogus.com> Subject: Mulligan - Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02 References: <99C61F4F-6826-4FB5-87A1-77BED624B53D@gmail.com> In-Reply-To: <99C61F4F-6826-4FB5-87A1-77BED624B53D@gmail.com> --dvycP3NKoigU85e3tzBuNlpUQcx7DtkpZ Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Folks, This call is a mistake on my part. I meant to start a two week last call and sent this message instead. There are important issues that have been teased out in this thread and we ned to address them but we should be doing that in guise of a working group last call. Joel On 9/26/18 07:40, joel jaeggli wrote: > This is start of a two week poll on making > draft-ietf-netmod-module-tags-02 a NetMod working group > document. >=20 > You may review at: > https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 >=20 > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like= > to see addressed once the document is a WG document. >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --dvycP3NKoigU85e3tzBuNlpUQcx7DtkpZ-- --C1IjLZ4ho0ZdwWS9mPbXsTqozOflYjRJ4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCW7PPXgAKCRDwADWrtn9W srZWAJ93YwjEAQtmxYEVIno6od/mNLZrswCfbwG0cGYGi4/OJ/4vHcv4HZJMmVU= =h6dN -----END PGP SIGNATURE----- --C1IjLZ4ho0ZdwWS9mPbXsTqozOflYjRJ4-- From nobody Tue Oct 2 13:21:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2387131113 for ; Tue, 2 Oct 2018 13:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 MGdf09ljwu2L for ; Tue, 2 Oct 2018 13:21:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 565BD130FF0 for ; Tue, 2 Oct 2018 13:21:11 -0700 (PDT) Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id w92KLAjY023278 for ; Tue, 2 Oct 2018 20:21:10 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local To: NETMOD Working Group From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: Date: Tue, 2 Oct 2018 13:21:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8ZusylwryfC6h2sdCwjS1H999aC5pWAaX" Archived-At: Subject: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 20:21:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8ZusylwryfC6h2sdCwjS1H999aC5pWAaX Content-Type: multipart/mixed; boundary="42PQrvBdjLuUSBI7nhZATluTPAXiMYg5l"; protected-headers="v1" From: joel jaeggli To: NETMOD Working Group Message-ID: Subject: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18 --42PQrvBdjLuUSBI7nhZATluTPAXiMYg5l Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable This is start of a two week working group last-call for draft-ietf-netmod-module-tags-02 a current netmod working group document. You may review at: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The prior discussion of my mistaken WG adoption call is here commences here: https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html In particular Andy's concerns expressed in that thread here: https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html are probably important to tease out in considering this for last call. so that we are clear on dates. This last call timing resets and runs from 10/2/18 - 10/16/18 Joel --42PQrvBdjLuUSBI7nhZATluTPAXiMYg5l-- --8ZusylwryfC6h2sdCwjS1H999aC5pWAaX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCW7PTMAAKCRDwADWrtn9W ssmFAJ983Kb3UzYDTQSXGn2a0FSfUa0qcwCfXu+yGjyrr7O9NRvSMLIKZtAIN+s= =XBLz -----END PGP SIGNATURE----- --8ZusylwryfC6h2sdCwjS1H999aC5pWAaX-- From nobody Tue Oct 2 13:30:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD257131113 for ; Tue, 2 Oct 2018 13:30:37 -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 bze4fMSqaWSD for ; Tue, 2 Oct 2018 13:30:35 -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 C9FEE131160 for ; Tue, 2 Oct 2018 13:30:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 72E4EB31; Tue, 2 Oct 2018 22:30:33 +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 aDz5Mz3GyVDL; Tue, 2 Oct 2018 22:30:33 +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, 2 Oct 2018 22:30:33 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33D2D20036; Tue, 2 Oct 2018 22:30:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pMgkGxlCMYVG; Tue, 2 Oct 2018 22:30:32 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id E192F20035; Tue, 2 Oct 2018 22:30:32 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 2 Oct 2018 22:30:32 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 1E2783000C7AFA; Tue, 2 Oct 2018 22:30:31 +0200 (CEST) Date: Tue, 2 Oct 2018 22:30:31 +0200 From: Juergen Schoenwaelder To: joel jaeggli CC: NETMOD Working Group Message-ID: <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: joel jaeggli , NETMOD Working Group References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 20:30:38 -0000 On Tue, Oct 02, 2018 at 01:21:04PM -0700, joel jaeggli wrote: > This is start of a two week working group last-call for > draft-ietf-netmod-module-tags-02 a current netmod working group > document. > > You may review at: > https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. Not ready, comments posted earlier here: https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg /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 2 13:55:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E71131165 for ; Tue, 2 Oct 2018 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjJ5sEM9Ye7e for ; Tue, 2 Oct 2018 13:55:23 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 F33EB131113 for ; Tue, 2 Oct 2018 13:55:22 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w92Ksc63014857 for ; Tue, 2 Oct 2018 13:55:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=8enwVfVPf9teFeZ64DIJIwOQznqc2AuQvhCztKAUZsk=; b=PgGxfXObVkvbKoKY76+GXzdZjY/kP4Xx0hfkPEKUzCIfVHkmEkaL0pErGgGfBzlNkN// fZkT3T01iKwy3sNNV4RAaxQyf6QoRWF2KO3l/3zyDslf1YtWUSfV3Jfisr0pvx8L/dKa oUVQRA3xX/k51zyc+F1ZQPfVJa0MRn7OrFQ2pRDejsO5mESK9039bs0BR/puptRm0yC6 alDMY9YYaEkB/cP+ImTMB29sX3WPwjckwFmIAMSFgWA5RECNSEi6aqzmCwnzWUpA1iUk t2tnoFraDAEfmZ1DF7vPaaVaG0cEMedV9h3aOwXqcXg1BIzbhANmuhLet26Pow5oaSQp hA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) by mx0a-00273201.pphosted.com with ESMTP id 2mv0hja275-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 02 Oct 2018 13:55:22 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4011.namprd05.prod.outlook.com (20.176.71.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.8; Tue, 2 Oct 2018 20:55:20 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.018; Tue, 2 Oct 2018 20:55:20 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdTI2nNckn+1ky1f4oa9l5TQKUMLf0A Date: Tue, 2 Oct 2018 20:55:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4011; 6:XI9VhH3eMXHCnu83HMxxTmSa3InylWiBUx7UqOyG4wsuR59F67xgd8uIuyMBXdV3YyV/YHdw4jhQOTjBd6jCnLUGUb3MmisZmyT1nKyM73ArgSC4IqtWc/TQIYY68zm5TOuuEbobkevGZt4gZKiKxZROlSsfupeS977BP0SEpBjkulO+gV9p/ZLnlMySONd2IogJT3pqhs0l85So6tIiQ+VBdgHISO8QK7fDiBM0RryD4PmwGoIJSuNyqWydxQhlyYF/5Nn0AHy98FcOKLiQFhAZgnoLmo7JVxr9rq0rMcA5U71ZM5b1yQg5Btlt7ndS77Z5PkVTWqu+KMjCR69mZj4DWnoVnw/yGG/wPKmAjtItUDPXUZDtcj8f4w4x6N6R3cH7oWyjjlqJ2/BQEosxrJTIxGSr2SyPufwehydFSzvtjUK4o1Z//xUjpXXNvWN8WVH7/G53wrVgfSRadGtlVw==; 5:XXzY1S9UIQJPflRZqsyK8TZHPTQExLJ3NyM6f0l1P2oToPm8Q+C5UveNW74REx7ouNxRJ0FlQGSFHy6mYL4DZFIZhkOxWbSo69YAuWHSWmyGg8oOpGyDSvaTDqq6PofVPo8Oyxfc51U0Gg65LRkU6ZX3e/DZJkbjJ68QfaPO9dM=; 7:d/FTwvBt5/826d1M4KFEJa8bKQytMHbPZ7tqJMCVKcQiZqfN+7vJNhH7kyE+ZaYwMmXMzUeidYS7y0BAt6XlJMUqBSRq1fvlJHl/qa91laM0GLVz43nG5/4kuWke2YzBAqwidCUpaKHAE36C0dp8cfb+Vc3oVZEroISLbimYqmO1oWSJoVEVkpC+HUXKJ3RF+2GulzhG3UKnB5e6Op/JusCLmxRLiFNBSqBCzg3/Eo8PCYTQDWm/udMQza8CsHbC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 74e0d7b3-697b-48ae-0d7c-08d628a95d90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4011; x-ms-traffictypediagnostic: DM6PR05MB4011: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:DM6PR05MB4011; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4011; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(136003)(396003)(13464003)(189003)(199004)(68736007)(106356001)(6436002)(76176011)(105586002)(8676002)(305945005)(82746002)(97736004)(6486002)(83716004)(446003)(486006)(86362001)(476003)(11346002)(6246003)(2900100001)(229853002)(2906002)(256004)(71200400001)(71190400001)(2616005)(26005)(3846002)(6116002)(14454004)(33656002)(5640700003)(53936002)(1730700003)(186003)(6506007)(102836004)(53546011)(8936002)(81156014)(6306002)(66066001)(966005)(478600001)(6512007)(81166006)(58126008)(5660300001)(316002)(7736002)(6916009)(2351001)(99286004)(5250100002)(36756003)(25786009)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4011; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: I6EK0MQYfOpqoQFYAZGVVMhzNoa6ZtMAaadoMcFWrHoRQohoNwuIRfUf3tUXQ1gwSX8xD5gPcyVbsjoxVu+a+ZNajEZ/ctz6FP22BvoWB2vcQxmGt8sdPOb4MGoJxOygUA8L4ZAxDtO5RAj1dZWI2d1wsH40Z9g0QQpSjYq9NSojBSI6j4owlf6xOQb2sQX+qZrk87MP+NYkmFOG2x1aO1lDBdQSG3OmRwdp+QEsG1oerL3R0Ty3WtF5CIEU8ON5xh2V2p592d0dXQz6V4YpkZ7CM7GF2T/DRQNiIxdGEXt3fiVccz+s6xuTA6VbLRmYE+HJxpkrF5Cq3yKnEF8qYacfLdcfzUNlKZufcDjjI7M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <01A1F3E3D049C84E83FDBE8A56BCFB37@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 74e0d7b3-697b-48ae-0d7c-08d628a95d90 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2018 20:55:20.2818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810020196 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 20:55:26 -0000 U3VwcG9ydC4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkRhdGU6 IE1vbmRheSwgT2N0b2JlciAxLCAyMDE4IGF0IDI6NDggUE0NClRvOiAibmV0bW9kQGlldGYub3Jn IiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQt Y2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0KDQpUaGUgSUVURiAxMDIgaW4tcm9vbSBwb2xsIHNo b3dlZCByZWFsbHkgZ29vZCBzdXBwb3J0IHRvIGFkb3B0DQp0aGlzIGRyYWZ0LCBhbmQgbm8gb2Jq ZWN0aW9ucy4NCg0KVGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gcG9sbCBmb3I6DQoNCiAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYt MDANCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24gdG8gdGhlIGFk b3B0aW9uIHBvbGwuIA0KSWYgb2JqZWN0aW5nLCBwbGVhc2Ugc3RhdGUgeW91ciByZWFzb25zIG9u IHRoaXMgdGhyZWFkLg0KDQpLZW50IChhbmQgTG91IGFuZCBKb2VsKQ0KDQoNCg== From nobody Wed Oct 3 01:57:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E913121B for ; Wed, 3 Oct 2018 01:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=HrZAjVsG; dkim=pass (1024-bit key) header.d=ericsson.com header.b=F5Jk1m6v 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 OD2NSPRlPVFA for ; Wed, 3 Oct 2018 01:57:19 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A27213118E for ; Wed, 3 Oct 2018 01:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538557036; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kplSoRtqGlIRIOrg9xiTwHsiRdAEf0qrvoOCjf1O6iw=; b=HrZAjVsGpa9gvazIesCtYwjMUgKMmDm9ZE9h2wG2nc8z7C6UJ5xBBPHWKqXFfCdi 0cZ2zgwE+9252isp7F3N/xCDxnO++MyvuQ8u/Xx5JR0p+ZwFcts38rtdzlfYyu1x 1nA1B+i0cqq98IKRa51aHQj50becD2XCwSLN/qsD038=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-4e-5bb4846cbf4f Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.B3.22015.C6484BB5; Wed, 3 Oct 2018 10:57:16 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 3 Oct 2018 10:57:16 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 3 Oct 2018 10:57:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9tkiG+Oa3zBiIJDAbg3lrtFJwsDv1S6KXoHj/zSRTOU=; b=F5Jk1m6v/4sfcBvzy99W75pQmZH8g5YHfT0d8qpOye4+O7QaeVaEU0wP1zS2QXzmn1zz5o1pDVETwxQfKknahdI4czkbUU+5gUokq+IDcjapsAW8D1JkaZTWNqJ6nmToVUs1NLCpgdwPNE/gAfabDB3RIfjPOeLamVRZp5nhwEs= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2573.eurprd07.prod.outlook.com (10.173.85.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.13; Wed, 3 Oct 2018 08:57:15 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::3d6c:4f4c:93f7:cd98]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::3d6c:4f4c:93f7:cd98%12]) with mapi id 15.20.1207.014; Wed, 3 Oct 2018 08:57:15 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWvcUylE2VdSJNUympgDSHJOARA== Date: Wed, 3 Oct 2018 08:57:15 +0000 Message-ID: <59348f7a-4bfa-e7aa-fc24-d12f2e49e47f@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 x-clientproxiedby: VI1PR08CA0222.eurprd08.prod.outlook.com (2603:10a6:802:15::31) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2573; 6:krf+pxTKLnCUJtxDXYQZmxWXxeHATT3pM884de26hxdNfzIyVJXklh4sbl4Jm06imDcNuc5OaF95LgfvqLqNvLQ4rXHzIMBciLEBCy6SxtfJcI8rBwYgivWPE/MSihnYdyLVSGS6OS5gR5Q4uwXRzRlP1+IaBdrPpChHc1zs2mKI+JLXo3NTScQ6frVAVW4P1OuxSg0kjjP86d/vddWYCF5w6oiwUbODj6XdWKfQw8GGHj+7H14dceRy2hXmfxkjjM6oITjlI8XnnCG73K4pRAUBPXtFyGxqYMTUhatssRJtjwwRcrBhE1UlLSxDn603kOZNe9CCnm/jWkDm/jnHysLNI4Mn+//di5zwdVXEp3XbR5O5P0kWC3LZh9fhv4K5iGSppipt/hsOWLbIIvhpbBi3RYO3TyPfxdRoH5ypWsVtYvVzvPeRPU5O3qxg1pzDTHburajK8GCLDM4gZJdxKQ==; 5:wwPSFR5pKGfEJPJEOgv7cONPf3pQKw6VQqLXWU7eehywt93pMIZcuy0RC99GNYktYm52McdZ/H/aKLePC0QXgJvNDW0JsTGhaNVagYLlcwxetRb1hiUWI7aCzfCpmwN47WU+913Pytsr0/kI+Ytxl/6SaybopKCtX54iU1tPYEs=; 7:VSKy69Yyo8bneKnPPlSPpuLg5Znmx0oHOmpH4De+nQjmubOsVFc2dEY86ywjtdq5cn7Mdo9oL/q8ZQFrPRUH1QWjRmIGwjbTs7MxbyE8X7z2sN/Myp+yIbH8TCbpByiBgWiSAQ5IOoOvv7VenRWlpY35mJUT2n/xZVlE3clGqKn9AbUpqQSf+YHttzOynk8jwExwXVvCRKITnKlkD0y2MTz3EKnj9e921nFIff28qOrJ8tWgLlXF4zmmTEuzwgT2 x-ms-office365-filtering-correlation-id: ee9b517a-6be5-4add-798e-08d6290e3649 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2573; x-ms-traffictypediagnostic: VI1PR0701MB2573: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991041); SRVR:VI1PR0701MB2573; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2573; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(136003)(39860400002)(252514010)(189003)(199004)(2900100001)(305945005)(1941001)(966005)(97736004)(476003)(71190400001)(31696002)(7736002)(86362001)(105586002)(85182001)(316002)(486006)(25786009)(256004)(11346002)(71200400001)(2501003)(6436002)(2616005)(6246003)(3260700006)(446003)(478600001)(53936002)(64126003)(6512007)(6306002)(26005)(6486002)(186003)(36756003)(2906002)(5660300001)(68736007)(65826007)(81156014)(81166006)(99286004)(386003)(14454004)(5250100002)(229853002)(8936002)(31686004)(6506007)(76176011)(53546011)(65956001)(58126008)(106356001)(99936001)(110136005)(66066001)(52116002)(65806001)(102836004)(85202003)(6116002)(8676002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2573; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8p1dcEAp0KGT3kxxf1I0Nco4ypUNGNuK95OOEPATtIWFSKVBmkpwKa4zDaLQTbeFAZtRt/7VOtDqvJzGKUhZ8jLIaZn17zfkXXlqW+I2zLh1metXo02ODcRALdnyoccF5Wi23nKxLuLwD/5tc+DRNfn0Fmk6KSuKYhBv3TIwcQW6PD7Ep+WPAljrYxpko3bbUw1th/FvLYYE5u7S+derCagy5z9IwNSpINsLFMp6lvnXq/xRMLBgH3/6K2sXtD2uYPNoyQ4cZUx+Bg2Al2hPFZyuVKk3Z0bRb2bol8uZbjzOoJXWR60JwhoYglVxxlHku3Sll+Jpm1JUofMkJDnW1ppoPtofuH+yQd8jNrFWQ5A= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040501020000040403050205" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ee9b517a-6be5-4add-798e-08d6290e3649 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 08:57:15.2493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2573 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTcRTH+9173a6jxW1qHgwrhxCUTk0zIdEE/5AsDEsQR9rQm1q6ya5K an/4qHyFSmlOWWr4KrXysZaa+Bj6xxY9lqQ4JPOBlZZMzNLstbs7of77nHO+53vO+fEjcZHJ zoVMlqfTSrksRcwTEDXRTzM8U65ppN6VWteAYTU/oN6YZ3cCC2tq2sTCJvPf8s9gMYLABDol OZNWegVdECRtFJxNK/O/8mqyGctFbb4lyJ4Eyg9mVkr5JUhAiqgxBNquPzgXrCOo6f6KuKAR g62bMxgbEFQFDurqWxhXqcJgfajfZrCIwKwq4bHOPCoUCleGMJYdqZPQ+WQNsexgYXPxMs7l w8FcXk1wLIFFU6+1l6Dc4bFGb9UIqWB4YDZYmLQMCAL1h1Q2bW9Jt+dvWCWI2gPfDR3WUTjl DKaFeow7zhFmjc95HDvBp/nfdhyLQbVksrITJYUbVWvWY4BSIZhcY49hRR7wYnIBcewKb+pL ESca5sP6fK3N9TS8V+faCuMIVAWj2Hb3qnEK49aLhYF3RbYGBSz1DNo4HPLy9HgF8qn9Z/Na ixdOFSNo0E3gtdYX2A36mgWCE/lDXc8szvFhaLm3jP/fzPJxUP0Y4XHsBpWls3yOj8Ly2Cri 2BdaHv3iNSBBG3JiaIZJTTziK6GVyfEMo5BL5HR6N7L8shHNlmcval8O0SGKROKdwp8KjVRk J8tkslJ1yN3iM9fZ/hq5EHKFnBY7CstkPVKRMEGWlU0rFXHKjBSa0aG9JCF2FkraBmJEVKIs nb5M02m0cruKkfYuuShOfWl/b1/vt+muWOLYy+brE5EOEbepUP/Gq9IiwbgvJhyZKh9tvWMA j2fOwVEH67Jjd/VpTYuZ+i+pm/3a+wVZHY6ROYa1lc9U2A4/48WP8Sut/hGt1erzp+YgUBQS G+3m1T24z1VknO7xFuS4RR0Y100X5hWfK72b8RAq+IligkmS+RzClYzsLyJHS8JtAwAA Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 08:57:22 -0000 --------------ms040501020000040403050205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Support. Balazs On 10/1/2018 8:48 PM, Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms040501020000040403050205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwMzA4NTcxMlow LwYJKoZIhvcNAQkEMSIEIPoZ4AGeUxzc/i/ZiYoN7Uyik6VaoD2IQbjtSyoIZdfoMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBALUBd0jlP0olL0CwwYtMXoMxcVCdqFJPhWrS5iXoDIIAnR/9 q90S/Z35mUS6THHzAxqmCUHblliOeLxznjaZw8Fd736oxk8Gs+Jau3RaHOEmtL48LwsMZXtV H1NIl+UBDsU22PV2u8fwX7RkXRZlsownyDmjStNOmXg5FxW7hN7Jq4M+c3sy0uTwMlMmYtor FCISCdEZtl1M2xgB06zHtei72Kd2vNrd89CQMNPNwIvPd4I2LiyWJX2/nTQ4Z2SPqQ7bKzaV NQ6V2CB777E24nZTP55oiKA07IJoxcf1uAgCYKUqbIJ5g71afv+eBf83eLyEuvv0cczzWciN KFZj6lAAAAAAAAA= --------------ms040501020000040403050205-- From nobody Wed Oct 3 02:44:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E772513122C; Wed, 3 Oct 2018 02:44:48 -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, DKIMWL_WL_MED=-0.001, 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 cp0rRKYNVk6w; Wed, 3 Oct 2018 02:44:47 -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 A6E08131211; Wed, 3 Oct 2018 02:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5620; q=dns/txt; s=iport; t=1538559886; x=1539769486; h=to:from:subject:cc:message-id:date:mime-version; bh=3b6id0Y0LqmCQOa1an+vFhRw2PWpXvM9wEOLfETStQY=; b=ZM+f9sZ3daTILwsjJEdYYEaypLqVU6YQa0XbRDfCg3eg4rOiK6ttx/F4 TGattv93mTeVlbCPQBwCQ65Ngp0egE7EWm4CPWHiK7HUwuYFojAEX6192 5/Mfu83Myoqnhj+7FJjyiqnhjtankgKB7vLdmRSpwufL5xUaqheo7H6mC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAACWjrRb/xbLJq0XAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFUgRSCShKEHIh0jSGRSYc6C4RshD03FQEDAQECAQE?= =?us-ascii?q?CbSiFYlZdAl8BDAgBAReDBoICiAGcZYEuH4RYhReLNoFBP4ESJ4pqglcCnUk?= =?us-ascii?q?JkDcGF4kRhlGPKoYjgVgigVUzGggbFYMokFQ+jw0BAQ?= X-IronPort-AV: E=Sophos;i="5.54,335,1534809600"; d="scan'208,217";a="6965620" 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 2018 09:44:44 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w939iisQ013492; Wed, 3 Oct 2018 09:44:44 GMT To: Vladimir Vassilev , "netmod@ietf.org" From: Robert Wilton Cc: "netmod-ver-dt@ietf.org" Message-ID: Date: Wed, 3 Oct 2018 10:44:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------18CD32F5A77F83DA44B42D38" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [netmod] YANG versioning requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 09:44:49 -0000 This is a multi-part message in MIME format. --------------18CD32F5A77F83DA44B42D38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Vladimir, At IETF 102, when I was presenting on the YANG versioning requirements (draft-verdt-netmod-yang-versioning-reqs-00), I think you raised a concern about requirement 2.2: 2.2 A mechanism SHOULD be defined to determine whether data nodes between two arbitrary YANG module revisions have (i) not changed, (ii) changed in a backward compatible way, (iii) changed in a non-backward compatible way. IIRC, I think that your specific concern is that this leads to a complex solution, which I understand, but I still think that this requirement should remain for several reasons: (1) It is only marked as a SHOULD rather than a MUST.  I.e. it is desirable that a solution is able to achieve this but is not strictly required. (2) Some tooling for this already exists.  RFC 7950 section 11 already defines what constitutes a backwards compatible change, and pyang is already capable of comparing two module revisions to partially determine what non backwards compatible changes exist between two module revisions (3) Having considered all the various potential solutions to the versioning problem, my opinion is that there is only one solution that is generically capable of accurately telling a client of what the impact is when updating between two releases.  That solution is to compare the complete schema for both releases (considering module versions, deviations, and features), potentially filtering the comparison output by the subset of the schema actually used by the client. So, whilst I still think a simpler solution may be helpful to communicate what sort of changes are contained in a module, I still think that the full complex solution will eventually be required to truly solve this problem in a robust way. Hence, are you OK with this requirement text remaining as is, or do you still want to see it changed? Thanks, Rob --------------18CD32F5A77F83DA44B42D38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Vladimir,

At IETF 102, when I was presenting on the YANG versioning requirements (draft-verdt-netmod-yang-versioning-reqs-00), I think you raised a concern about requirement 2.2:

       2.2  A mechanism SHOULD be defined to determine whether data
            nodes between two arbitrary YANG module revisions have (i)
            not changed, (ii) changed in a backward compatible way,
            (iii) changed in a non-backward compatible way.

IIRC, I think that your specific concern is that this leads to a complex solution, which I understand, but I still think that this requirement should remain for several reasons:

(1) It is only marked as a SHOULD rather than a MUST.  I.e. it is desirable that a solution is able to achieve this but is not strictly required.

(2) Some tooling for this already exists.  RFC 7950 section 11 already defines what constitutes a backwards compatible change, and pyang is already capable of comparing two module revisions to partially determine what non backwards compatible changes exist between two module revisions

(3) Having considered all the various potential solutions to the versioning problem, my opinion is that there is only one solution that is generically capable of accurately telling a client of what the impact is when updating between two releases.  That solution is to compare the complete schema for both releases (considering module versions, deviations, and features), potentially filtering the comparison output by the subset of the schema actually used by the client.

So, whilst I still think a simpler solution may be helpful to communicate what sort of changes are contained in a module, I still think that the full complex solution will eventually be required to truly solve this problem in a robust way.

Hence, are you OK with this requirement text remaining as is, or do you still want to see it changed?

Thanks,
Rob
--------------18CD32F5A77F83DA44B42D38-- From nobody Wed Oct 3 07:18:34 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477521312AC for ; Wed, 3 Oct 2018 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDYxv6692N_6 for ; Wed, 3 Oct 2018 07:18:30 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3A513129E for ; Wed, 3 Oct 2018 07:18:30 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w93EFHEn006438; Wed, 3 Oct 2018 07:18:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=message-id : from : to : cc : subject : mime-version : content-type : content-id : date; s=PPS1017; bh=pHCtF8lq45WdmV2R0RwveE/3jWyggm/X6yw6i9F+rtc=; b=fpi9WOidUAGcESJyPKqr+c5C11W7yL5dh5qlvgRdzIUypiqDOXD/lxRSS9SV/+RD4xJC a1u/8TCGX9vbRNdBpE2vZrgEG8Pqi2yHR4xSbskPBeLRQkiXptUcUkFeW0YHkVY4+/HF oe5XKwDGTK/PyCViTvoqosVELnJiN+1oV3zk/6acUnAgG5/To8BuALxHY34Pqi9rk2qP LjnyRjmtU8o1WBtftZKmm6/w3COAlSLWqiNXgc2AcpUeOfVl8nmwJ6qhXAGASOz5UVew hNCJZJ8xAfBqlDTqoJ5abifr7JT8TVnn3/np52FDP7/FR4soOngSxBNXftvOmKmRvYRa Dg== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0184.outbound.protection.outlook.com [216.32.181.184]) by mx0b-00273201.pphosted.com with ESMTP id 2mvts98hxs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Oct 2018 07:18:27 -0700 Received: from SN4PR0501CA0094.namprd05.prod.outlook.com (2603:10b6:803:22::32) by CY4PR05MB3144.namprd05.prod.outlook.com (2603:10b6:903:f2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.15; Wed, 3 Oct 2018 14:18:25 +0000 Received: from BY2NAM05FT024.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by SN4PR0501CA0094.outlook.office365.com (2603:10b6:803:22::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1207.11 via Frontend Transport; Wed, 3 Oct 2018 14:18:25 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by BY2NAM05FT024.mail.protection.outlook.com (10.152.100.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1207.13 via Frontend Transport; Wed, 3 Oct 2018 14:18:25 +0000 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 3 Oct 2018 07:18:25 -0700 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 3 Oct 2018 07:18:24 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 3 Oct 2018 07:18:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w93EIMqr031480; Wed, 3 Oct 2018 07:18:23 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id w93EJNpn040188; Wed, 3 Oct 2018 10:19:23 -0400 (EDT) (envelope-from phil@juniper.net) Message-ID: <201810031419.w93EJNpn040188@idle.juniper.net> From: Phil Shafer To: Bal?zs Lengyel CC: Kent Watsen , "netmod@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40186.1538576362.1@idle.juniper.net> Date: Wed, 3 Oct 2018 10:19:22 -0400 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(39860400002)(2980300002)(189003)(199004)(126002)(7126003)(54906003)(46406003)(186003)(69596002)(77096007)(26005)(6306002)(7696005)(8676002)(81156014)(97756001)(97736004)(478600001)(16586007)(229853002)(8936002)(81166006)(53936002)(68736007)(6246003)(2810700001)(6916009)(76506005)(50466002)(106466001)(105596002)(53416004)(1076002)(23726003)(316002)(336012)(426003)(2906002)(4326008)(476003)(486006)(305945005)(8276002)(356003)(86362001)(5660300001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3144; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT024; 1:tXlC0opRqyKMB7ZHSwCxywR3VaBrbu5LhDCdxusW2Grl6i4Lqs5Nbe0yt9JDxWr4+s17n/j9/EsaxaGV0nnBPED4Bq/Dr0kTxGwRtylVcSPbxUm9s/qoTE9dKFsTDqo0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c4de7af-539b-4747-8f70-08d6293b151d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060); SRVR:CY4PR05MB3144; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3144; 3:1TTuza9r/MzmzFFMiqwf027QTMhnyOjfw2AGx+xa6rk453xDNvxOkwvQ/F0GObkKUdaT47IfLHhJiT5o+ZzAUvUpMeWFa0pCpPWGFWcC6F116gOxZwsB0nEdF0EAsqtDwMAyP7Dos+FoyYtPT5v+t1kVrvBPQG3T4PG2cVbCgTV+mcCdu/gzwtP6nhxml6PdJqubNaW1F5BDdno3TA4oISLNdxFEraYmqKy/5IeZSsOeNaVo8xfqH6tXLsl963KayqS7W8XuAhqMf9+wHLx75goA8SnMP6FmRo6VY9vt1mJ8bs31spQsFS+iKvNIomB+zC8BiL5JlkGlQUcdS0S1xuY/M/pmW1RPQJnobuKUQ+Y=; 25:bp/ZqLg5JxA/00li/Mouwvyto40czLSUV8GfwzjAFy/PwvaWW6+4gVuNq53pW6UaMJkAS5hhZimSh9JFHIBXntOeIc2NQK9G+opC6ZVPBLXsk2Jc40VHZTj/Xn+fEmmDONz5IuFu3Yc7Q1B2coYz5YKJMrvWy/YxSBBbsRDdsSeFpXS5Pi59D1Bf9g+o4QSg0rKsfKppEIH339UaoaI89KqtjJa+Di+H7vay8ce5DYa8uRvMqlwl1dqfs5evGDbfCrKo3F3ex5kBh7icP/G5e82kJOgKvTdWM5eaDB3U3XKhL+NjCsdGve6cxDhAt3qBLuctbpI2PVz+e5IssnbO9A== X-MS-TrafficTypeDiagnostic: CY4PR05MB3144: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3144; 31:4lxl431mMPOtYsvgpIUonIsPdVEW/BMLQtVLGViAB7LLw4HtkY4O2aosSV7bxAM58+8UpQAm1cZ7/4bMOzQxea5LOqMluIb4TbGuUNKarvQtEsYpJaTT1tDWqaDJbTdT0ZFOaOtro2fNx4udlosvBTuhew0nvZZcHQYKafo7KqLvM0ASOvoI4q5MZDYFK5ND5md4iYeXkn1rQZTK/ui3INExp/0tP11y4AXOQgr9Yps=; 20:V7Rsm6aaL9MsOqoFb922DZcw5Ovf0CgliWevZR2a/lWyd6US4TfurmngIrea2C3EcQWQou7n7rTlbztGamWWUwcNP/o60UFhUMy2KakXw2tQGI3/WFJPSrOuVPrLoNVPDMDODyY821G78NiSO9XzhKLcRe0uTGhEZKlqUbc50PA/zThxn+nrBywjIZZtT6gSOz4Dgpew2S9wGvCk6ylSguXphfFSF8SwBQVUyW+a6E65/PmXxHpJAwFJ90/SqnJzy/TFxkMLuA2uHCtDthcGLcTSf5u1oGUYBxnU6huzQsKXwOb+Mv08QttNbWW5FPaEbkJ7VOXOZ6MzYjnDvu13anHiIHJ+xyEor8X/dS1JW/kYNwt6gvrHZMs5YmMAILTdcH2xRBqeid51HSu1GwQJIs055VqXFgh0LJDe8YTSTWes5BOHLs9e5cFbj/kBlKwnHlfK6N1CA2N+UEmLFIgdaDLF6mWIevir+4O0HzWgm9aoiYUee822Vuinrra6wE1K X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93003095)(10201501046)(3002001)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:CY4PR05MB3144; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3144; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3144; 4:u/34rzkHFPmS5xKkdIOLPWprseeIJ5+zZeEfp3ABhlIiVLfLGysNcoXPxRKo/9ucev9LSqkFu7SrxsIM96uUnPSznOCEQK6sZWLV6GDSF17Y5MBHtxHELpE7r96EGfmddjYJthH/6tBQLfsYawMIUaDXdMW2ipVOK4q2EDi0AUXaWda5p4ioVHRTQpFBvW+rWbXOohavwheM4z20rFAYqLDn40a80x810C1IiYCVdVkfnWdeVNUPGiT0PXbOOr2Q55CIunthM7Re+fKrw4XXlg== X-Forefront-PRVS: 0814A2C7A3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3144; 23:MuesYVAHe4XKIBkoL0LwoaWWmB5S8ccZAY9tB5/0u?= =?us-ascii?Q?MSMwRgDlO/b4MUbY5f074JX6Hd75Cqr5eTsHsQwx0lzcl2s4ybQbzFjIq4hY?= =?us-ascii?Q?O7mHXsjq7xonZ7ulHGD4/U8Z4Ek8lElf2uNtPJwLoZkWOoxl7QCUe31JsOdo?= =?us-ascii?Q?pBcceUti1zY3YZa4DKXTXNT91NQ2EEObo7kyDuSKuFC4Czn/3MRZZZDGW9Vu?= =?us-ascii?Q?onmUz2zRkboeVyMlxu/SLCo1yXWxjDHoyGg6TNlZ3p4OW65zoVzp0FiMQ6p1?= =?us-ascii?Q?fmEooDGLGG16BJx7Sk7BMj1BWnJ1iGVg9cwe/sktekM0V296rRAnDadD3aND?= =?us-ascii?Q?dSbb76FM9ZQoHy0USWujApzaw17TgDetd27g/heb82nhyOw0lWNvmMO+MGOO?= =?us-ascii?Q?Y9N+/6O/O3x/GRkB8BtbU6KCHy6LUExPpSpmmceibIlPFZZdEwvHmo1vCZoi?= =?us-ascii?Q?l67mlkbTwgch3CW4bOG9YhlpmDyMj0ajZniEqwsOYNazq/qamjEsNjUt03fw?= =?us-ascii?Q?arA8F8Bquj0M3qt3InnsSJUejgAFWdMtlBpmyW3eYqI4h97713082yiaNh4K?= =?us-ascii?Q?2E8GZN7dld5i8l1KJhnENV3VFruT9/6kADdGW/P54S7druOvVuYQRXqY/LCL?= =?us-ascii?Q?pdFIv1J5sxf9BiAULHbo22IS0ElYwViWx8tThcSl+1zKrxIO3nmBqSWcxmYc?= =?us-ascii?Q?5VBuB300LtNqCTpFnEVnCTzJo2EaoZp3N7oUe9p4EqpZnMUR204tpkd9eFCD?= =?us-ascii?Q?2fR+tE5LvS4//EYaRbLgeEPk1ACcY5qIdctHCrfHacVMJa3JiRT5TCCvppN7?= =?us-ascii?Q?L5IC0OsU/gTE1XxfmSwUci1VncYkcq/5QAGeIlbzFaJ18enh9EiK4V6s0KFx?= =?us-ascii?Q?u2uj0dCE8uscdWZtQcudiJa+PJYz7NegHa6zBZbdASSEj/QuXtMKgMtPTLGO?= =?us-ascii?Q?MUiw785Bovuoxq8HY7eoWv4j39XQfJMmkzAar7wue2Ord1vTkjRcipnCRE4z?= =?us-ascii?Q?qejVAh4dzTThX0SGyQIQMYcmp0dYx3ox4LtcwBfg2LtEqxNQQR1USJVJkx6j?= =?us-ascii?Q?h116+IMozCDRVVHoZYj5K2UKZilb0X17um4CXaF/RanpTf1FV2noidnUGD6m?= =?us-ascii?Q?q52h+SNx6nTSiFYn0BpmIll4IJbs8FU3VzEXc/SIbWv3JOenMkKjw=3D=3D?= X-Microsoft-Antispam-Message-Info: qyGsPxB2u+YoxRJVIUkXojRvuVrHPx+v3t2ZOEx4+qmz0pdNviXsg0zh2ZMdOAds6XymhaoPD0jb6n3SfFvrOz7EAyU7GZGN0hENCVsxqjw2tMxU2D+wdegvkzLFndmHdRvWYfOsBo2tscqVKT8My0Fy1rImyC8Z17CgaxRRyylbx0VKvzApQH3fM5iB7PMjk/qY++Q3yDvmg41twr3ycHW5aUMmshHq9H+BWvOoauEBJiIs4Ls0vgSzxebCmeZkeTstXKSfmQeefNPuq/sGQ6XKCsZW33RfJsj0eP1n8LaQyuBXQ7rZ/mybvp+gbQQnisaT0ZJIoHIYnsUG6hUk5jTkw/OjfWXXVc18IxAa1nY= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3144; 6:ikJtVxQZcgCHXb5T9VowbstHFCBWZOopr/ZvpHCOODw3rxtFVV/Lt3sr5g4dSP1HBeCdhfPjMmkurrgoC4gz2q8BdU9qUQZeWpNgdSEEOgPenrKQPf7iqvqNKGDvCF4fllvxFITEGHppAayRYTVaTTCNJOj6Vj3+9N0rbyqin5jktI7WvdzEkD5U/IGX7yfXP9RG2nL9kdTResSXZ9ZLzZrcEMy/siJKcIiciBzvJgvUqatkFQ2SY5EkjHDb5i4Xs7bxFTlHU6MD5VJqsYbC+7TvVub+MmlRFPAqupsOzFp112WfktbjouX4/CVz4SUv6p14tq9O9TlCxqlObSUQjLz9U7+OpM0UQcF8r25lovp6351IuLfIypcQFZ1RgNNpMUWjWP0gIIrskRmx31I3Nm/wc1CBke64oexJV8Gh5JuWC5KdHmZ7VFPTpciVZ0jiT2eKscl9OE/5KPeCckx3Vg==; 5:3TvV1d3xp/fPhcBNSZByMrL+xi51iZgD9VQl4Jhv4OWPfbSLRkxh1WUXIbvr+idxdmFT9eJiT/zk7TwfzCwMDo0rDyXzwVrlX9r4+zPaLeY+AFXo+TmK7ROhH3IrDVuR5h/VsRCV4GRx3w2O61fMXayGm+SuONOr851RZnsY7Dk=; 7:II5/RkxERfb5iV3+qaKejFBegroMYNHPxVTtrdx0e1OBFx0I4WCdMioKa75HfLqHNgu+eT3ZS5qRBUVv120Eolsfvnwni7DkD5jZ0RW413Bo0xHl/6pPagBoHd/nzW6TYZCpVzKGWOrYeg8LaMRPMfPgQxlPxm/pueWIWvAyhDqApCU5v2ZqOcp9hxAoZgoMhDxEaFZj2QwCQIxIkK1yl50V9Nh+c5p8TKOeDpMN4cSEPk0fOIwYA94b/oG55PPl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2018 14:18:25.3103 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4de7af-539b-4747-8f70-08d6293b151d X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030139 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 14:18:32 -0000 Bal?zs Lengyel writes: >https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 [I've moved to a "deep lurker" role here, but ...] Can we ensure this model contains a "format" leaf in the RPC's input so that future (and proprietary) formats can be supported? That leaf can be an identityref that defaults to yang-patch. Thanks, Phil From nobody Wed Oct 3 07:43:07 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AF131280; Wed, 3 Oct 2018 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84nPoWZAb4Ai; Wed, 3 Oct 2018 07:43:02 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFA413118E; Wed, 3 Oct 2018 07:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2DA132A41045; Wed, 3 Oct 2018 16:43:00 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HdbTy0Y1nWx7; Wed, 3 Oct 2018 16:43:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F0DC82A41049; Wed, 3 Oct 2018 16:42:59 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eI1icLiJ5g3h; Wed, 3 Oct 2018 16:42:59 +0200 (CEST) Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id BD23E2A41045; Wed, 3 Oct 2018 16:42:59 +0200 (CEST) To: Robert Wilton , "netmod@ietf.org" Cc: "netmod-ver-dt@ietf.org" References: From: Vladimir Vassilev Message-ID: Date: Wed, 3 Oct 2018 16:42:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] YANG versioning requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 14:43:05 -0000 Hi Robert, On 10/3/18 11:44 AM, Robert Wilton wrote: > > Hi Vladimir, > > At IETF 102, when I was presenting on the YANG versioning requirements=20 > (draft-verdt-netmod-yang-versioning-reqs-00), I think you raised a=20 > concern about requirement 2.2: > > 2.2 A mechanism SHOULD be defined to determine whether data nodes=20 > between two arbitrary YANG module revisions have (i) not changed, (ii)=20 > changed in a backward compatible way, (iii) changed in a non-backward=20 > compatible way. > > IIRC, I think that your specific concern is that this leads to a=20 > complex solution, which I understand, but I still think that this=20 > requirement should remain for several reasons: > > (1) It is only marked as a SHOULD rather than a MUST. I.e. it is=20 > desirable that a solution is able to achieve this but is not strictly=20 > required. I agree with your point in (1). As long as 2.2 is optional there is no=20 problem. > > > (2) Some tooling for this already exists.=C2=A0 RFC 7950 section 11 alr= eady=20 > defines what constitutes a backwards compatible change, and pyang is=20 > already capable of comparing two module revisions to partially=20 > determine what non backwards compatible changes exist between two=20 > module revisions > > > (3) Having considered all the various potential solutions to the=20 > versioning problem, my opinion is that there is only one solution that=20 > is generically capable of accurately telling a client of what the=20 > impact is when updating between two releases.=C2=A0 That solution is to= =20 > compare the complete schema for both releases (considering module=20 > versions, deviations, and features), potentially filtering the=20 > comparison output by the subset of the schema actually used by the clie= nt. > > So, whilst I still think a simpler solution may be helpful to=20 > communicate what sort of changes are contained in a module, I still=20 > think that the full complex solution will eventually be required to=20 > truly solve this problem in a robust way. My point was that the need of complete schema comparison as described in=20 (3) is needed for 2.2 but not for 2.1 and thus it will probably make=20 sense to decouple the solutions. I am looking forward to see what your=20 solution ideas are. > > =C2=A0Hence, are you OK with this requirement text remaining as is, or = do=20 > you still want to see it changed? Yes I am OK with the text. Regards, Vladimir > > > Thanks, > Rob > > > > > > From nobody Wed Oct 3 07:48:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875881312BE; Wed, 3 Oct 2018 07:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 Wiyt-H1dwhPl; Wed, 3 Oct 2018 07:48:09 -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 6ABD513118E; Wed, 3 Oct 2018 07:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1538578088; x=1539787688; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vOmXemdUXTDEb84mMqJUG6xeWLfbI83i8295WuQrImc=; b=BzjP2HyxXukoXl7xHsEzkLP28H5FGSEFWri2ZN6YLe8rpupa6KTlCoLT pI3FZNlsrg7y7XBha0E9jnPfg96WVBppoH3JcQZ58B+LhN3eSmtjpcVPw qqJTVe4golRqYihOlMecBAddx7Zxmjg2GSgWYNzXitM/QMev7TRKMeApz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAABI1rRb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVINeEoQciHSNIS2YVguEbAKEQTcVAQMBAQIBAQJtKIU?= =?us-ascii?q?4AQEBAQIBIw8BBUEQCxgCAiYCAlcGAQwIAQEXgwaBegilPoEuhHeFGoELii2?= =?us-ascii?q?BQT+BEieCa4d/glcCnU0JkDgGF4kRhlGPLoYjgVgigVUzGggbFYMokFQ+jkU?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.54,336,1534809600"; d="scan'208";a="6972261" 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; 03 Oct 2018 14:47:57 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w93EltS0027908; Wed, 3 Oct 2018 14:47:57 GMT To: Vladimir Vassilev , "netmod@ietf.org" Cc: "netmod-ver-dt@ietf.org" References: From: Robert Wilton Message-ID: Date: Wed, 3 Oct 2018 15:47:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] YANG versioning requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 14:48:11 -0000 On 03/10/2018 15:42, Vladimir Vassilev wrote: > Hi Robert, > > On 10/3/18 11:44 AM, Robert Wilton wrote: >> >> Hi Vladimir, >> >> At IETF 102, when I was presenting on the YANG versioning >> requirements (draft-verdt-netmod-yang-versioning-reqs-00), I think >> you raised a concern about requirement 2.2: >> >> 2.2 A mechanism SHOULD be defined to determine whether data nodes >> between two arbitrary YANG module revisions have (i) not changed, >> (ii) changed in a backward compatible way, (iii) changed in a >> non-backward compatible way. >> >> IIRC, I think that your specific concern is that this leads to a >> complex solution, which I understand, but I still think that this >> requirement should remain for several reasons: >> >> (1) It is only marked as a SHOULD rather than a MUST. I.e. it is >> desirable that a solution is able to achieve this but is not strictly >> required. > > I agree with your point in (1). As long as 2.2 is optional there is no > problem. > >> >> >> (2) Some tooling for this already exists.  RFC 7950 section 11 >> already defines what constitutes a backwards compatible change, and >> pyang is already capable of comparing two module revisions to >> partially determine what non backwards compatible changes exist >> between two module revisions >> >> >> (3) Having considered all the various potential solutions to the >> versioning problem, my opinion is that there is only one solution >> that is generically capable of accurately telling a client of what >> the impact is when updating between two releases.  That solution is >> to compare the complete schema for both releases (considering module >> versions, deviations, and features), potentially filtering the >> comparison output by the subset of the schema actually used by the >> client. >> >> So, whilst I still think a simpler solution may be helpful to >> communicate what sort of changes are contained in a module, I still >> think that the full complex solution will eventually be required to >> truly solve this problem in a robust way. > > My point was that the need of complete schema comparison as described > in (3) is needed for 2.2 but not for 2.1 and thus it will probably > make sense to decouple the solutions. I am looking forward to see what > your solution ideas are. > >> >>  Hence, are you OK with this requirement text remaining as is, or do >> you still want to see it changed? > Yes I am OK with the text. Thanks for confirming. Rob > > > Regards, > > Vladimir > >> >> >> Thanks, >> Rob >> >> >> >> >> >> > . > From nobody Wed Oct 3 09:11:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC70130FEB for ; Wed, 3 Oct 2018 09:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.197 X-Spam-Level: *** X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, 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 (1024-bit key) header.d=btconnect.onmicrosoft.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 puZVCby0gCla for ; Wed, 3 Oct 2018 09:11:17 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27141312D2 for ; Wed, 3 Oct 2018 09:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fn7I5s/ZXgI6EcMlQ/OGWB9LsXlKjEOkKEbgmJqA6ws=; b=BBBKTC0arvlZEBd7PMy4mdnxjve8hy7ZXOspVf4TRN4c64npixb53uArNxLucI0yOO9TYHMkHBDCtB+GW+6veD3DmhFHRCvv5ziiGzdVLaCFu03cYOCV1Ur+jHaDQVDHnbLwy+UNNq0pEP1ox+jiV5ETar3MvBhgngk4RpdLBrs= Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB1662.eurprd07.prod.outlook.com (10.166.142.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.11; Wed, 3 Oct 2018 16:11:14 +0000 Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1207.018; Wed, 3 Oct 2018 16:11:13 +0000 From: tom petch To: "netmod@ietf.org" Thread-Topic: Quirky YANG Thread-Index: AQHUWzOsol/7t5B5P0eLl3TYYanwGA== Date: Wed, 3 Oct 2018 16:11:13 +0000 Message-ID: <008701d45b33$942501e0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR0701CA0082.eurprd07.prod.outlook.com (2603:10a6:3:64::26) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.131.229.47] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1662; 6:CrjWTrPriwupBCk97WXfx/S6P5ZRqcy+SQsE4VV3SgP1YoQn9tbRHYkJYyFda6gKKy1+tyNV4Pkqz37NNVqgkyKtGYuN31JG2PD5xhntUfhohlnevwhwMKBYANDxvwZb2fjXUsSTomGp8EUBsf25lclXWuptjNLNPYIS63So5rtBtAQH9Q0x8WUsb+0VgU27TOKSzoIPgov0UK0nT2FvEHBRGoEBivaSFROI5etWWXzP4DxLw2ir9tzSjezq7UaCvT/RnhOn8VP5aQINtYMWqv22hLGnIYaogNkoobhMvLWVh9mEJC2ZOrHaRjxWgw2qPUYHyhhcCTbofRmxBJQJ8YLyWMG9MK+weAKG1P7deFaa+VRfu52/XnqXdTzE2ppttRxWy7Syl0gaPisGP6uxGAfMn5gR4HqUM7lQhFRkOjtuybi7cvi7p62iEfETyrbn/WhPQCKikhbYY46nsLniXw==; 5:ezIjQcmB+jhc9rYf6DWBiqcPiJC0Cg+pPY9TmaBtG9TBjGxCunHyf6OnPeVlLaJRq3qsmBpLKG8Ww9GAlNFa13D7lVOfVLpupjK1YCEGcFm7yDYLauCR9TKxT+v2v47CJiK7W52yMzuGgUzBMDHpWosH/t/NtsRn8UR7Jk1yTx8=; 7:coYSqKITpWxtrfoUUyHhCznbxaHjCaWJMBVjY7HAvbsK9SR0Td4udILh/m4IEGlJAvJ64F3lDJ4Fuwv+x1dxelETbHoHcQYj1DeEMrDG0UaQyxNk+DSlcFaKSKZmx8nlvG6S5wNDbBEPMsqlr98cPbRP3+kFHPtbPVFvebNFbPyOsT+le58flMG8XJvqZYVfJxYPA1CLdXJJYcTrSgIbUG8k5fmLqBLrHuZfRLvZAxk2jFAUIL353duZdoiXinwc x-ms-office365-filtering-correlation-id: 3b5e58d1-a7b8-4008-4300-08d6294acf07 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB1662; x-ms-traffictypediagnostic: VI1PR07MB1662: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991048); SRVR:VI1PR07MB1662; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1662; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(376002)(346002)(366004)(54094003)(189003)(199004)(84392002)(1556002)(221733001)(14454004)(52116002)(7116003)(33896004)(25786009)(7736002)(305945005)(966005)(386003)(102836004)(6506007)(478600001)(71190400001)(14496001)(97736004)(71200400001)(256004)(99286004)(86362001)(6916009)(6116002)(3846002)(2501003)(5250100002)(2351001)(26005)(105586002)(186003)(106356001)(2906002)(81166006)(81156014)(3480700004)(476003)(6436002)(486006)(8936002)(68736007)(66066001)(5640700003)(86152003)(1730700003)(8676002)(316002)(44736005)(53936002)(9686003)(5660300001)(6512007)(6306002)(2900100001)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1662; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PbKn/5psi8/Rj9vxdDFogE+7vRCWNIbS+W5xJ7UfhQfiZrbBJ8UfZWTfuuh948+8hPDSOLvEolry1rWkD+uEleaOPARBoHx6fwSHUZtfwu/jTi8iL3HqeY37J8YHApCTXjaipezAh4CzoDEDkeNXjQUZwB4nzOOiLVVb2GoOzAGK8sZ+9SK7PCHBl6WOgiNI/nHPJY2Izquo49gG0SZ0F58imxzL4CFWnkLTd5n9RHpGgYnvW0cWZ89MOreeQtxudYYmWo6agk/B+imviXS928982/EDS4iKsaHHgVUosV6B0AnvxUNy09cP5oNE4gPRRRXQLyOQYPgkD05dKKJ3iwRDKQFKABNsYfNVOKA0frY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5AB6BB2BF6660D4984F573A99416AC7D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b5e58d1-a7b8-4008-4300-08d6294acf07 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 16:11:13.1955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1662 Archived-At: Subject: [netmod] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:11:20 -0000 I wonder if anyone else on this list has looked at https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ currently in IETF Last Call. It provides management for three tunnel types, Lw4o6, MAP-E and MAP-T betweeen CPE and Border Relay. It defines a CPE module, a BR module and a module of common definitions. It does not provide identities for the three tunnel types; rather, where it augments "/if:interfaces/if:interface" it specifies when "if:type =3D 'ianaift:tunnel'"; which to me says that a MAP-E (e.g.) specific object will get added to each and every tunnel of whatever type, which seems excessive. Second, it defines four features, softwire-ce:algorithm (i.e. MAP-E/MAP-T) and softwire-ce:binding (i.e. Lw4o6) in the CPE module and then again softwire-br:algorithm and softwire-br:binding in the BR module. It is unclear to me, from the I-D, whether support is for MAP-T and MAP-E; or either MAP-T or MAP-E - I find the I-D ambiguous on that point - but I would have expected there to be either two - Lw4o6 and MAP-ET - or three - Lw4o6, MAP-E and MAP-T features, not four; and for the features to be defined, along with tunnel identities, in the common module. Odd, IMHO. Tom Petch From nobody Wed Oct 3 09:33:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12B130FEB; Wed, 3 Oct 2018 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.218 X-Spam-Level: **** X-Spam-Status: No, score=4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, 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 (1024-bit key) header.d=btconnect.onmicrosoft.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 0thgxFAqE9_n; Wed, 3 Oct 2018 09:33:20 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C921312FF; Wed, 3 Oct 2018 09:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=daYsVjji1mtAR0MNocNjWIwP0A6LnE9cfoOe0KQjkQs=; b=TqnpY7lfVf+kLXYjg6J+hhhyzSC4SeA7yau3z1ZPXkdgansQZOSAliY3zzqt0gTfJdkR45xx46iHiG/G/0YaaBdDoCuCSjgq9ECea8HJBmJ+qQ5anPB+rixDLl6eCJkyQkiShb1mEXL38vLsYEWJqk/Er/PlXWyVdYWZJw2FUSk= Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB1423.eurprd07.prod.outlook.com (10.165.238.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.8; Wed, 3 Oct 2018 16:33:17 +0000 Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1207.018; Wed, 3 Oct 2018 16:33:17 +0000 From: tom petch CC: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] Last Call: (Network Access Control List (ACL) YANG Data Model) to Proposed Standard Thread-Index: AQHUWzbJo2Ip+ami2keOnRVRT4nxLQ== Date: Wed, 3 Oct 2018 16:33:16 +0000 Message-ID: <010501d45b36$b0ca5a40$4001a8c0@gateway.2wire.net> References: <152993564680.6249.16618999238081481807.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR0701CA0073.eurprd07.prod.outlook.com (2603:10a6:3:64::17) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.131.229.47] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1423; 6:wZsjEIJR8gqIDIS3ko5rRBE+y3BwhEI+nvWWzvGVnJ8UrVYDfV2iwVHf46R7RI6nlinU1mmVZLQrOJ7IOhl38oBSynb+WEHQcZaXg0umW+O/dkeyPaZzTKMqGWltWSdeP4XHzFslcHR/VFuyXhE4R1JUm34wyaP5y1NentFiKJZ4dpOo/8wcuq3SGGbxNdR1STkbSjX79v1FAkjGclP/RRt8AK7zZfea15By+0pqPvMc0FjV7T/WZW13aya46f5fjOTKePy42za8jteJQjTZQwDiWo9c7WqWMZnO35nBEiRLjM6V5YppGx1cje+NYWuTTIHUpj0u+mHcDAS0CYf9VXL/RBXcJW840f94poHoEqEld7s/z/hD8OrAOmSJYdlBRMsEQlUTTrcOS43AV3PNGGjmXYokOo9js9Lt9A/Af3a1JzL22m9ISUprYQ/EZRt0UG0HjnsT46edT+0LrAdRTQ==; 5:0sWKyBxwS38v8RppOR25OSWVaClNMfpPcZzu8miAW/aPINxG9qB9EvnTzT7sOrUrmj5S5nsyyvJBslNiKylqK0bteNtQKJEamZUe0nFxej7TjzV7h5B/M5WqUsscn3IGpOA/baSFCPjWOal9qufJxbs3pP5k6YxGpoppcVao9HE=; 7:PzHNSmzxn+auliswMyJDA255iun7aXc+qnXuSkzRBKlhAorbvP2M4X61H7EB3pl0mhExnuu8TbLZOcmdrX5j76Qa+Zw5B3ZGmGWaOdtIsTTguxEkBAB/rdQlgVKpZNP0hVMdmjeBdiv3ljPyu6QNlT2JXIQE/OEG/Qx23A7J6ymmRYQXrX4AVuK3i589U9Nhfn92HHgox7LSXBidVrA8OzbaL+XNJw8lIpU33KI2HAR/SjcDXV5WFMWfF64B1Xri x-ms-office365-filtering-correlation-id: e79d678d-73f0-4cf9-eee3-08d6294debb4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB1423; x-ms-traffictypediagnostic: VI1PR07MB1423: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991048); SRVR:VI1PR07MB1423; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1423; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(396003)(366004)(136003)(13464003)(199004)(189003)(8936002)(6436002)(66066001)(105586002)(44736005)(6486002)(229853002)(1671002)(106356001)(86152003)(53936002)(81166006)(5660300001)(81156014)(9686003)(6306002)(6512007)(8676002)(4326008)(109986005)(478600001)(6246003)(25786009)(450100002)(2900100001)(59246006)(14496001)(97736004)(5250100002)(2906002)(6116002)(3846002)(71200400001)(71190400001)(84392002)(7736002)(305945005)(68736007)(14454004)(966005)(316002)(486006)(102836004)(476003)(86362001)(52116002)(76176011)(6506007)(386003)(14444005)(256004)(1556002)(186003)(99286004)(26005)(446003)(33896004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1423; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9LWbjKtQS15LmnFP66jIi4u99klJDXg07pgw+sFfHeNui9L3dmPLyn5LuToC/Y3Xp0ZyUwnqzli0pTitQRhDN81Q8HUdilxasWHOGi0ljQa+GLtrBo3oNRAiZzzWbFv2Q357mYpJ5qfUeRooJPh5HdPGHb/Avate0h/j6yiSkwig49VJAw0kbg7/8BewOkTS/yl0qRIIaWwRcVvcifir+t8NA8sJGL97/EzcopKLhPoRgPkgOAwDKcgiv2Q/2Zup+qq5kSDCENwamU22Au9cfJqMGHHLKvOLseNmpp6DGq+HhU56FjjOh1RT771BHQzihm2QYjWfl4fPaF2IyndBwJIe9ESggveFbY3m/OwgYVk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: e79d678d-73f0-4cf9-eee3-08d6294debb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 16:33:16.7200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1423 Archived-At: Subject: Re: [netmod] Last Call: (Network Access Control List (ACL) YANG Data Model) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:33:22 -0000 I thought that I had asked this before but perhaps I forgot. enum cobranet { value 34841; description "CobraNet. Hex value of 0x"; Where can I find out abut CobraNet? and I cannot reconcile value 34841; with Hex value of 0x"; Tom Petch ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: ; ; ; Sent: Monday, June 25, 2018 3:07 PM Subject: [netmod] Last Call: (Network Access Control List (ACL) YANG Data Model) to Proposed Standard > > The IESG has received a request from the Network Modeling WG (netmod) to > consider the following document: - 'Network Access Control List (ACL) YANG > Data Model' > 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 2018-07-09. 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 document defines a data model for Access Control List (ACL). An > ACL is a user-ordered set of rules, used to configure the forwarding > behavior in device. Each rule is used to find a match on a packet, > and define actions that will be performed on the packet. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Oct 3 09:43:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05C131307 for ; Wed, 3 Oct 2018 09:43:35 -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 zPaQwObKaaXB for ; Wed, 3 Oct 2018 09:43:33 -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 DA41E1312FF for ; Wed, 3 Oct 2018 09:43:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6D5F6B48; Wed, 3 Oct 2018 18:43:31 +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 qWVd-XkDr9he; Wed, 3 Oct 2018 18:43:30 +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, 3 Oct 2018 18:43:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58CE220035; Wed, 3 Oct 2018 18:43:31 +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 d3RDhlERD6wP; Wed, 3 Oct 2018 18:43:30 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id EAB1820037; Wed, 3 Oct 2018 18:43:30 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 3 Oct 2018 18:43:30 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 422E03000CC077; Wed, 3 Oct 2018 18:43:29 +0200 (CEST) Date: Wed, 3 Oct 2018 18:43:29 +0200 From: Juergen Schoenwaelder To: tom petch CC: "netmod@ietf.org" Message-ID: <20181003164329.uutqv3gbzhomc5hh@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , "netmod@ietf.org" References: <008701d45b33$942501e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <008701d45b33$942501e0$4001a8c0@gateway.2wire.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:43:35 -0000 Well, make sure you send your comments to softwire since they have to sort this out. /js On Wed, Oct 03, 2018 at 04:11:13PM +0000, tom petch wrote: > I wonder if anyone else on this list has looked at > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ > currently in IETF Last Call. > > It provides management for three tunnel types, Lw4o6, MAP-E and MAP-T > betweeen CPE and Border Relay. It defines a CPE module, a BR module and > a module of common definitions. > > It does not provide identities for the three tunnel types; rather, where > it augments "/if:interfaces/if:interface" it specifies > when "if:type = 'ianaift:tunnel'"; > which to me says that a MAP-E (e.g.) specific object will get added to > each and every tunnel of whatever type, which seems excessive. > > Second, it defines four features, softwire-ce:algorithm (i.e. > MAP-E/MAP-T) and softwire-ce:binding (i.e. Lw4o6) in the CPE module and > then again softwire-br:algorithm and softwire-br:binding in the BR > module. It is unclear to me, from the I-D, whether support is for MAP-T > and MAP-E; or either MAP-T or MAP-E - I find the I-D ambiguous on that > point - but I would have expected there to be either two - Lw4o6 and > MAP-ET - or three - Lw4o6, MAP-E and MAP-T features, not four; and for > the features to be defined, along with tunnel identities, in the common > module. > > Odd, IMHO. > > Tom Petch > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 3 10:12:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695B91252B7; Wed, 3 Oct 2018 10:12:44 -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 PEBibhZ57tOv; Wed, 3 Oct 2018 10:12:42 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 41FFC127133; Wed, 3 Oct 2018 10:12:42 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id a23-v6so1973702pfi.12; Wed, 03 Oct 2018 10:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=V0wTkEBItNg86bgN6Qiis6UbLGEsu+b1LZWTwqFzrOo=; b=Q/cr/rGISsOKCOv38P/iJbT6Mo8W194zAmqb5xpoJM7+C9Vk9UWRJzjuQs5J1xogrZ acLjCKrgUsbyVNev3GIktJv6fz2fxK0ECOyI8+r8zz0qzWwg2ZL8qB/YkcuD5/D4Is6N WkyouDLxfn5fSQZLIfCvQbwDmPp25lycMgn1LVgUwF+aQ+xYo6U4mlz4WFCmupKNL1+5 Pxzi4q1+L8ODUdwH3aqVxXYpgTDKDmZAEkovfcj5WZKs8WKpUI2jYgc7dEVJNgp9HHE6 ScWBvgBAwkyyrdILedqijbNu1KUStoQ2mXKDGzKr9pcYLvxv+XSmG6EByPB7ub0qQMqI pU/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=V0wTkEBItNg86bgN6Qiis6UbLGEsu+b1LZWTwqFzrOo=; b=TakgSDdGnhXTGecTf+i59jhGsK5jPPcAeI/OexIu2gEt/fOCq6DnEAHBBU1aH9UKeL +99PwuFN0WQ618XnMzjUSlFlFmMwHWr2mkM4p6Eu1voJacvApGxnJibMP61Guwpcjzsr JiX9ChexYecx9Vs20CXLo0faw4Pr1RhD+I/WO7J4WowvJHhqU0yxQUwVyBUVqoWeb/eW g/vAePj20fcFI8Gw9w8x0ZJan0i1/0om/Cork3uUeUpkMGwkUJbOyBYLNIKg6xUo+fQS 1qXCcA7vgnBtJyyLJoCIlyKaZFirNlz23zygSt33eSczN7CNBVNoFR/2qY5lRJ7qs7OL i6xw== X-Gm-Message-State: ABuFfogUNiwaBxpCQcS04iZ/Z4zt4e5pDODB/LTHGtd56x/3anuEGyof sP2LPxGdiqFtMot3ZW+ll/1iaiPi X-Google-Smtp-Source: ACcGV62xbqKfMDG1ejGecQk5H99OPVxYYzRKKvZQwQFGR4RpHsqPrMSu4h5VMcf9hQODxzbHyKjTMA== X-Received: by 2002:a65:4103:: with SMTP id w3-v6mr2268641pgp.284.1538586761689; Wed, 03 Oct 2018 10:12:41 -0700 (PDT) Received: from [10.52.174.170] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id x13-v6sm2357783pgl.87.2018.10.03.10.12.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 10:12:40 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C5F7E3D3-7535-4BCB-B27C-8D73E115939E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Oct 2018 10:12:39 -0700 In-Reply-To: <010501d45b36$b0ca5a40$4001a8c0@gateway.2wire.net> Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" To: tom petch References: <152993564680.6249.16618999238081481807.idtracker@ietfa.amsl.com> <010501d45b36$b0ca5a40$4001a8c0@gateway.2wire.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netmod] Last Call: (Network Access Control List (ACL) YANG Data Model) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 17:12:44 -0000 --Apple-Mail=_C5F7E3D3-7535-4BCB-B27C-8D73E115939E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, Here is information on Cobranet. https://en.wikipedia.org/wiki/CobraNet = > On Oct 3, 2018, at 9:33 AM, tom petch wrote: >=20 > I thought that I had asked this before but perhaps I forgot. >=20 > enum cobranet { > value 34841; > description > "CobraNet. Hex value of 0x"; >=20 > Where can I find out abut CobraNet? and I cannot reconcile > value 34841; > with > Hex value of 0x=E2=80=9D; It should say =E2=80=9CHex value of 0x8819=E2=80=9D. >=20 >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: ; ; > ; > Sent: Monday, June 25, 2018 3:07 PM > Subject: [netmod] Last Call: > (Network Access Control List (ACL) YANG Data Model) to Proposed = Standard >=20 >=20 >>=20 >> The IESG has received a request from the Network Modeling WG (netmod) > to >> consider the following document: - 'Network Access Control List (ACL) > YANG >> Data Model' >> as Proposed Standard >>=20 >> 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 2018-07-09. 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. >>=20 >> Abstract >>=20 >>=20 >> This document defines a data model for Access Control List (ACL). > An >> ACL is a user-ordered set of rules, used to configure the > forwarding >> behavior in device. Each rule is used to find a match on a packet, >> and define actions that will be performed on the packet. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >>=20 >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ballot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_C5F7E3D3-7535-4BCB-B27C-8D73E115939E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom,

Here = is information on Cobranet.

https://en.wikipedia.org/wiki/CobraNet


On Oct = 3, 2018, at 9:33 AM, tom petch <ietfc@btconnect.com> wrote:

I = thought that I had asked this before but perhaps I forgot.

=           enum = cobranet {
=             va= lue 34841;
=             de= scription
=             &n= bsp; "CobraNet. Hex value of 0x";

Where = can I find out abut CobraNet?  and I cannot reconcile
=             va= lue 34841;
with
=          Hex value of = 0x=E2=80=9D;

It should say =E2=80=9CHex value of = 0x8819=E2=80=9D.



Tom Petch

----- Original Message = -----
From: "The IESG" <iesg-secretary@ietf.org>
To: = "IETF-Announce" <ietf-announce@ietf.org>
Cc: <ibagdona@gmail.com>; = <netmod-chairs@ietf.org>;
<draft-ietf-netmod-acl-model@ietf.org>; <netmod@ietf.org>
Sent: Monday, June 25, 2018 3:07 PM
Subject: = [netmod] Last Call: <draft-ietf-netmod-acl-model-19.txt>
(Network Access Control List (ACL) YANG Data Model) to = Proposed Standard



The IESG has received a request = from the Network Modeling WG (netmod)
to
consider the following = document: - 'Network Access Control List (ACL)
YANG
Data Model'
=  <draft-ietf-netmod-acl-model-19.txt> 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 2018-07-09. 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 document defines a data model for Access = Control List (ACL).
An
  ACL is a = user-ordered set of rules, used to configure the
forwarding
  behavior in device.  Each rule is used to = find a match on a packet,
  and define actions = that will be performed on the packet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ba= llot/


No IPR declarations = have been submitted directly on this I-D.



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


Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_C5F7E3D3-7535-4BCB-B27C-8D73E115939E-- From nobody Wed Oct 3 14:41:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000AF129385; Wed, 3 Oct 2018 14:41: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, DKIMWL_WL_MED=-0.001, 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 gU6iT3Jy2Cju; Wed, 3 Oct 2018 14:41:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B12128CB7; Wed, 3 Oct 2018 14:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2346; q=dns/txt; s=iport; t=1538602883; x=1539812483; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fFhjE9X3eZCFj30byg/HUnRgAcBCW++rkz9ZnM9/OTw=; b=PrgumScZBwtVjfRZURDnhqRolerAKmnu/IjW0A4XeDNCywrOnm/M/lgn c7/tcdRSFJ3gHi6DV2jv6cjDn9cqmLVFUDBTdagD1j7bxTVUDtc53I421 rE/f6UsZ/1bpiGRcAHPhKPiRrTOInEG64Rj6NaKUpf6WHLkDw3pDMwYXm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAAAPN7Vb/40NJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBU4IMZn8oCoNqlhaDYpMfgXoLGAsJg3pGGYQJITYWAQMBAQI?= =?us-ascii?q?BAQJtHAyFOQIBAwEBIRE6CxIBCBoCJgIEJQsVEgQBDQWDIQGCAQ+lRYEuhDM?= =?us-ascii?q?HPYUZBYELihYXgUE/gREBJwwTgkyDGwEBAwGBXReCajGCJgKdTQkChkeJdRe?= =?us-ascii?q?PYowXiRMCERSBJSMBMYFVcBU7KgGCQYsWhT5vgRaLYAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.54,337,1534809600"; d="scan'208";a="180594842" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 21:41:23 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w93LfNuu017289 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 21:41:23 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 16:41:22 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 16:41:22 -0500 From: "Reshad Rahman (rrahman)" To: tom petch , "netmod@ietf.org" CC: YANG Doctors Thread-Topic: [netmod] Quirky YANG Thread-Index: AQHUW2HTol/7t5B5P0eLl3TYYanwGA== Date: Wed, 3 Oct 2018 21:41:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.48] Content-Type: text/plain; charset="utf-8" Content-ID: <8D325B13405DAA44B794CEF07492F577@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 21:41:26 -0000 QXJlIFlEIHJldmlld3Mgb3B0aW9uYWwgZm9yIElFVEYgWUFORyBtb2R1bGVzPyBJIGFzc3VtZWQg aXQgd2FzIG1hbmRhdG9yeS4NCg0K77u/T24gMjAxOC0xMC0wMywgMTI6MTEgUE0sICJuZXRtb2Qg b24gYmVoYWxmIG9mIHRvbSBwZXRjaCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBpZXRmY0BidGNvbm5lY3QuY29tPiB3cm90ZToNCg0KICAgIEkgd29uZGVyIGlmIGFueW9u ZSBlbHNlIG9uIHRoaXMgbGlzdCBoYXMgbG9va2VkIGF0DQogICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc29mdHdpcmUteWFuZy8NCiAgICBjdXJyZW50bHkg aW4gSUVURiBMYXN0IENhbGwuDQogICAgDQogICAgSXQgcHJvdmlkZXMgbWFuYWdlbWVudCBmb3Ig dGhyZWUgdHVubmVsIHR5cGVzLCBMdzRvNiwgTUFQLUUgYW5kIE1BUC1UDQogICAgYmV0d2VlZW4g Q1BFIGFuZCBCb3JkZXIgUmVsYXkuICBJdCBkZWZpbmVzIGEgQ1BFIG1vZHVsZSwgYSBCUiBtb2R1 bGUgYW5kDQogICAgYSBtb2R1bGUgb2YgY29tbW9uIGRlZmluaXRpb25zLg0KICAgIA0KICAgIEl0 IGRvZXMgbm90IHByb3ZpZGUgaWRlbnRpdGllcyBmb3IgdGhlIHRocmVlIHR1bm5lbCB0eXBlczsg cmF0aGVyLCB3aGVyZQ0KICAgIGl0IGF1Z21lbnRzICIvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZh Y2UiIGl0IHNwZWNpZmllcw0KICAgICAgICB3aGVuICJpZjp0eXBlID0gJ2lhbmFpZnQ6dHVubmVs JyI7DQogICAgd2hpY2ggdG8gbWUgc2F5cyB0aGF0IGEgTUFQLUUgKGUuZy4pIHNwZWNpZmljIG9i amVjdCB3aWxsIGdldCBhZGRlZCB0bw0KICAgIGVhY2ggYW5kIGV2ZXJ5IHR1bm5lbCBvZiB3aGF0 ZXZlciB0eXBlLCB3aGljaCBzZWVtcyBleGNlc3NpdmUuDQogICAgDQogICAgU2Vjb25kLCBpdCBk ZWZpbmVzIGZvdXIgZmVhdHVyZXMsIHNvZnR3aXJlLWNlOmFsZ29yaXRobSAoaS5lLg0KICAgIE1B UC1FL01BUC1UKSBhbmQgc29mdHdpcmUtY2U6YmluZGluZyAoaS5lLiBMdzRvNikgaW4gdGhlIENQ RSBtb2R1bGUgYW5kDQogICAgdGhlbiBhZ2FpbiBzb2Z0d2lyZS1icjphbGdvcml0aG0gYW5kIHNv ZnR3aXJlLWJyOmJpbmRpbmcgaW4gdGhlIEJSDQogICAgbW9kdWxlLiAgSXQgaXMgdW5jbGVhciB0 byBtZSwgZnJvbSB0aGUgSS1ELCB3aGV0aGVyIHN1cHBvcnQgaXMgZm9yIE1BUC1UDQogICAgYW5k IE1BUC1FOyBvciBlaXRoZXIgTUFQLVQgb3IgTUFQLUUgLSBJIGZpbmQgdGhlIEktRCBhbWJpZ3Vv dXMgb24gdGhhdA0KICAgIHBvaW50IC0gYnV0IEkgd291bGQgaGF2ZSBleHBlY3RlZCB0aGVyZSB0 byBiZSBlaXRoZXIgdHdvIC0gTHc0bzYgYW5kDQogICAgTUFQLUVUIC0gb3IgdGhyZWUgLSBMdzRv NiwgTUFQLUUgYW5kIE1BUC1UIGZlYXR1cmVzLCBub3QgZm91cjsgYW5kIGZvcg0KICAgIHRoZSBm ZWF0dXJlcyB0byBiZSBkZWZpbmVkLCBhbG9uZyB3aXRoIHR1bm5lbCBpZGVudGl0aWVzLCBpbiB0 aGUgY29tbW9uDQogICAgbW9kdWxlLg0KICAgIA0KICAgIE9kZCwgSU1ITy4NCiAgICANCiAgICBU b20gUGV0Y2gNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0K DQo= From nobody Wed Oct 3 16:38:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DDE130DBE; Wed, 3 Oct 2018 16:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iZ1Jd-D36WPw; Wed, 3 Oct 2018 16:38:20 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 AD9CE12F295; Wed, 3 Oct 2018 16:38:20 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id k19-v6so2433518pfi.1; Wed, 03 Oct 2018 16:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zSyQo8mfwoR8QHjfxREaZk4mB8tSlTRYiXougbsi/DQ=; b=scgKBycltVzpP79pN/SZ5gguikQvMPRTKFoCheLbW9VP75JY6EuFvVDW6DCjh+pehn FL7neh676pgqQywh+QbZljaCg2gVEcDKakujTKVy+S9VQZS7qMUqnOI266d69zhm1PN1 zVEvkfu7m9iI/B47gkN+UwJofOR6SVda7xZo5eSdJDWrDQTEXT+rLrDqdGPv75pOF1TE ICVgpymCwMntuwSn4cnA4HjuMEnAtYtnSFE1IjESLLQIPt+PRJ+tYUgNOt8+xbiUEUdy yxS6IVHTr8lu9AU6W/FwiVyg9PEdB1ov6oxIJL/L6fvBzThH1CoLKobfdQbkfJdAhlRP 6gLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zSyQo8mfwoR8QHjfxREaZk4mB8tSlTRYiXougbsi/DQ=; b=JRjZIiQ5kfEtPkrMy50Qiu0xi5qRsNQZxNvykxmOxXzQ42A0fDsN2eND+MQJkYXK4a pFJ7ziohPZvWta1gCFYQCm8PhiaTRboBfmiu54Q0vpt3qhsH5LvAW+LcHtzseo49NxXn BYhIgUKyt0K3PbENLH8dL4TPx5ZbKVrjg0jMHmViO/2qlmPqmcuJ5CY/Rbvai2jQvXJQ u2bKIF8Wq1Cy6Uv7St98i5J0UXC9WZ8ScP8O4KwpNPMmnwZdzUMF0AGsYiM1m6BY3ZeH FfR5fbnyQMv2diagqhidioLgVsPdHv70rZi0UdRCgLrG3RHXZDN90BVVtSrQH0JHa1Rn y9BA== X-Gm-Message-State: ABuFfoiFwUfqnJC/HKwRDO8O44hQM/AppNM2CW3cvmptO4m4Y1qOL1eS A9DpXAPMzRRObq277qwZQBo= X-Google-Smtp-Source: ACcGV63SIcEcmplQ9nEoiay41Qee7gSFMAlFRnX9hWXwvmvNoSftv9Z/z1ep52ntdcQD7bV57zeL7w== X-Received: by 2002:a63:ad44:: with SMTP id y4-v6mr3332507pgo.138.1538609900174; Wed, 03 Oct 2018 16:38:20 -0700 (PDT) Received: from [10.52.174.170] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id l85-v6sm7161551pfk.34.2018.10.03.16.38.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 16:38:19 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E342CB6F-49B3-4A36-B3B2-20F3BB8CB105" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Oct 2018 16:38:18 -0700 In-Reply-To: Cc: tom petch , "netmod@ietf.org" , YANG Doctors To: Reshad Rehman References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netmod] [yang-doctors] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:38:23 -0000 --Apple-Mail=_E342CB6F-49B3-4A36-B3B2-20F3BB8CB105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman) = wrote: >=20 > Are YD reviews optional for IETF YANG modules? I assumed it was = mandatory. Here is what it says on the YD page: All YANG documents will be passed by a YANG doctor reviewer before they = will be approved by the IESG. The YANG doctor review must be done after = the Working Group Last Call and before the IETF Last Call. ADs and WG = chairs responsible on I-Ds that include YANG documents should ask the = OPS ADs for a review as soon as the document completed WGLC. Failing = that request, the review will be conducted during the IETF Last Call. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E342CB6F-49B3-4A36-B3B2-20F3BB8CB105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> = wrote:

Are YD reviews optional for IETF = YANG modules? I assumed it was mandatory.

Here is what it says on the YD page:

All YANG = documents will be passed by a YANG doctor reviewer before they will be = approved by the IESG. The YANG doctor review must be done after the = Working Group Last Call and before the IETF Last Call. ADs and WG chairs = responsible on I-Ds that include YANG documents should ask the OPS ADs = for a review as soon as the document completed WGLC. Failing that = request, the review will be conducted during the IETF Last = Call.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E342CB6F-49B3-4A36-B3B2-20F3BB8CB105-- From nobody Wed Oct 3 16:51:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B10130DC3; Wed, 3 Oct 2018 16:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.955 X-Spam-Level: X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 Dxmfbj6TCuX5; Wed, 3 Oct 2018 16:51:37 -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 790CB12F295; Wed, 3 Oct 2018 16:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10162; q=dns/txt; s=iport; t=1538610697; x=1539820297; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OTNYnLyvEGFhiQJyZOgKURJ4oy6mgWHBDZ8uERl6xrU=; b=JcKwRDgFX1wFeyvv9PeTUMdgfeffZ47ZAhw5fA4etPXIvxZ7cYypgSBt 49h3wUbnhRM7FOqRQjhbFsQUIgtI4WJ6pQza55ewIDtIZaOH3kx039FvQ w7UXerx+xeYr4U/2U6IQUQ1SZ+vQy3UXAAT5AHLUobpKcfeBKWnJwbZjf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAD0VLVb/4UNJK1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYEXd2Z/KAqDaogVjieIY4g6hUCBeguEbAIXhAkhNBg?= =?us-ascii?q?BAwEBAgEBAm0ohTgBAQEBAyMKTBACAQgOAwMBAigDAgICHxEUCQgCBA4FgyE?= =?us-ascii?q?BgR1MAxWlJIEuhzkNglGLIReBQT+BEicfgkyCVoJIFoJLMYIEIgKJSoQ8jxs?= =?us-ascii?q?sCQKNH4MdF49ijQiIIgIRFIElHTiBVXAVZQGCQQmQS2+MSIEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,338,1534809600"; d="scan'208,217";a="464338183" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 23:51:36 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w93Npack024844 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 23:51:36 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 18:51:35 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 18:51:35 -0500 From: "Reshad Rahman (rrahman)" To: Mahesh Jethanandani CC: tom petch , "netmod@ietf.org" , "YANG Doctors" Thread-Topic: [yang-doctors] [netmod] Quirky YANG Thread-Index: AQHUW2HTol/7t5B5P0eLl3TYYanwGKUOgWAA///AMAA= Date: Wed, 3 Oct 2018 23:51:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.72] Content-Type: multipart/alternative; boundary="_000_C0D31E514EAA4FFABFC6FE2DE900047Bciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [netmod] [yang-doctors] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 23:51:41 -0000 --_000_C0D31E514EAA4FFABFC6FE2DE900047Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1haGVzaC4gU28gdGhlIElFU0cgaXMgc3VwcG9zZWQgdG8gYXNrIGZvciBZRCByZXZp ZXcgYXQgdGhpcyBwb2ludCBmb3IgZHJhZnQtaWV0Zi1zb2Z0d2lyZS15YW5nPw0KDQpGcm9tOiBN YWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5l c2RheSwgT2N0b2JlciAzLCAyMDE4IGF0IDc6MzggUE0NClRvOiAiUmVzaGFkIFJhaG1hbiAocnJh aG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCkNjOiB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVj dC5jb20+LCAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPiwgWUFORyBEb2N0b3Jz IDx5YW5nLWRvY3RvcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3lhbmctZG9jdG9yc10gW25l dG1vZF0gUXVpcmt5IFlBTkcNCg0KDQoNCg0KT24gT2N0IDMsIDIwMTgsIGF0IDI6NDEgUE0sIFJl c2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBj aXNjby5jb20+PiB3cm90ZToNCg0KQXJlIFlEIHJldmlld3Mgb3B0aW9uYWwgZm9yIElFVEYgWUFO RyBtb2R1bGVzPyBJIGFzc3VtZWQgaXQgd2FzIG1hbmRhdG9yeS4NCg0KSGVyZSBpcyB3aGF0IGl0 IHNheXMgb24gdGhlIFlEIHBhZ2U6DQoNCkFsbCBZQU5HIGRvY3VtZW50cyB3aWxsIGJlIHBhc3Nl ZCBieSBhIFlBTkcgZG9jdG9yIHJldmlld2VyIGJlZm9yZSB0aGV5IHdpbGwgYmUgYXBwcm92ZWQg YnkgdGhlIElFU0cuIFRoZSBZQU5HIGRvY3RvciByZXZpZXcgbXVzdCBiZSBkb25lIGFmdGVyIHRo ZSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBhbmQgYmVmb3JlIHRoZSBJRVRGIExhc3QgQ2FsbC4g QURzIGFuZCBXRyBjaGFpcnMgcmVzcG9uc2libGUgb24gSS1EcyB0aGF0IGluY2x1ZGUgWUFORyBk b2N1bWVudHMgc2hvdWxkIGFzayB0aGUgT1BTIEFEcyBmb3IgYSByZXZpZXcgYXMgc29vbiBhcyB0 aGUgZG9jdW1lbnQgY29tcGxldGVkIFdHTEMuIEZhaWxpbmcgdGhhdCByZXF1ZXN0LCB0aGUgcmV2 aWV3IHdpbGwgYmUgY29uZHVjdGVkIGR1cmluZyB0aGUgSUVURiBMYXN0IENhbGwuDQoNCk1haGVz aCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0K --_000_C0D31E514EAA4FFABFC6FE2DE900047Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <96DD0CBE05684243B22C90F87D73DD4F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiUFQgU2VyaWYiOw0KCXBhbm9zZS0xOjIgMTAgNiAzIDQg NSA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGFua3MgTWFoZXNoLiBTbyB0aGUgSUVTRyBpcyBzdXBwb3NlZCB0byBhc2sgZm9yIFlEIHJl dmlldyBhdCB0aGlzIHBvaW50IGZvciBkcmFmdC1pZXRmLXNvZnR3aXJlLXlhbmc/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5NYWhlc2ggSmV0aGFuYW5kYW5pICZsdDttamV0aGFuYW5kYW5pQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBPY3RvYmVyIDMsIDIwMTggYXQgNzoz OCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmVzaGFkIFJhaG1hbiAocnJhaG1hbikmcXVvdDsg Jmx0O3JyYWhtYW5AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+dG9tIHBldGNoICZsdDtp ZXRmY0BidGNvbm5lY3QuY29tJmd0OywgJnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtu ZXRtb2RAaWV0Zi5vcmcmZ3Q7LCBZQU5HIERvY3RvcnMgJmx0O3lhbmctZG9jdG9yc0BpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFt5YW5nLWRvY3RvcnNdIFtuZXRtb2RdIFF1 aXJreSBZQU5HPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvYT48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+T24gT2N0IDMsIDIwMTgsIGF0IDI6NDEgUE0sIFJlc2hhZCBSYWht YW4gKHJyYWhtYW4pICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJyYWhtYW5AY2lzY28uY29t Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5ycmFobWFuQGNp c2NvLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+QXJlIFlEIHJldmlld3Mgb3B0 aW9uYWwgZm9yIElFVEYgWUFORyBtb2R1bGVzPyBJIGFzc3VtZWQgaXQgd2FzIG1hbmRhdG9yeS48 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SGVy ZSBpcyB3aGF0IGl0IHNheXMgb24gdGhlIFlEIHBhZ2U6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7UFQgU2VyaWYmcXVvdDssc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5k OndoaXRlIj5BbGwgWUFORyBkb2N1bWVudHMgd2lsbCBiZSBwYXNzZWQgYnkgYSBZQU5HIGRvY3Rv ciByZXZpZXdlciBiZWZvcmUgdGhleSB3aWxsIGJlIGFwcHJvdmVkIGJ5IHRoZSBJRVNHLg0KIFRo ZSBZQU5HIGRvY3RvciByZXZpZXcgbXVzdCBiZSBkb25lIGFmdGVyIHRoZSBXb3JraW5nIEdyb3Vw IExhc3QgQ2FsbCBhbmQgYmVmb3JlIHRoZSBJRVRGIExhc3QgQ2FsbC4gQURzIGFuZCBXRyBjaGFp cnMgcmVzcG9uc2libGUgb24gSS1EcyB0aGF0IGluY2x1ZGUgWUFORyBkb2N1bWVudHMgc2hvdWxk IGFzayB0aGUgT1BTIEFEcyBmb3IgYSByZXZpZXcgYXMgc29vbiBhcyB0aGUgZG9jdW1lbnQgY29t cGxldGVkIFdHTEMuIEZhaWxpbmcgdGhhdA0KIHJlcXVlc3QsIHRoZSByZXZpZXcgd2lsbCBiZSBj b25kdWN0ZWQgZHVyaW5nIHRoZSBJRVRGIExhc3QgQ2FsbC48L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptamV0aGFu YW5kYW5pQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0K PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C0D31E514EAA4FFABFC6FE2DE900047Bciscocom_-- From nobody Wed Oct 3 17:22:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB8130DD4 for ; Wed, 3 Oct 2018 17:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 Zm-1tp5JzpD5 for ; Wed, 3 Oct 2018 17:22:16 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0078.outbound.protection.outlook.com [104.47.36.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 24B7C130DD0 for ; Wed, 3 Oct 2018 17:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ztm8JKBK/aBzRDbCVXconAkBVmdNgCekjk8d2qYypxM=; b=UH1z/KcQdo4c+yKiMHa7uH5tI7Bz1M4lpauW8OuV7CBYqOSKs4Dbk1g1v1B8rnlsJQfp5vrduoiGWRiOJu+IfneVdWXngu+rEgT7wI8F6WzvnJFoigNtGVzQ1n3QmS90+aIJ0I2+JcSMq6ndjDhK49bAE4rXLlROsJN4YI41UbU= Received: from MWHPR22CA0010.namprd22.prod.outlook.com (2603:10b6:300:ef::20) by CY4PR2201MB1111.namprd22.prod.outlook.com (2603:10b6:910:46::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.25; Thu, 4 Oct 2018 00:22:14 +0000 Received: from CO1NAM03FT044.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::208) by MWHPR22CA0010.outlook.office365.com (2603:10b6:300:ef::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1207.18 via Frontend Transport; Thu, 4 Oct 2018 00:22:14 +0000 Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=bestguesspass action=none header.from=Aviatnet.com; Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.54; helo=mail-send.aviatnet.com; Received: from mail-send.aviatnet.com (192.147.115.54) by CO1NAM03FT044.mail.protection.outlook.com (10.152.81.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1207.19 via Frontend Transport; Thu, 4 Oct 2018 00:22:13 +0000 From: Alex Campbell To: joel jaeggli , NETMOD Working Group Thread-Topic: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18 Thread-Index: AQHUW3hJl4/5OB+QZUW/ckT+h/Snuw== Date: Thu, 4 Oct 2018 00:22:08 +0000 Message-ID: <1538612528590.11321@Aviatnet.com> References: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39850400004)(396003)(2980300002)(438002)(189003)(199004)(2616005)(486006)(476003)(478600001)(246002)(446003)(11346002)(26005)(47776003)(186003)(356003)(6306002)(316002)(126002)(102836004)(36736006)(97876018)(117636001)(336012)(8746002)(106002)(8936002)(956004)(2906002)(7696005)(72206003)(110136005)(118246002)(53546011)(5660300001)(966005)(36756003)(8676002)(50466002)(76176011)(86362001)(53416004)(6246003)(23756003)(6666003)(25786009)(14444005)(6486002)(305945005)(229853002)(7636002)(106466001)(7596002)(6116002)(7736002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR2201MB1111; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT044; 1:fm9e8eHq9/FvnoS7VRSe0MQB/0zcOptx/gu0/V8XjJfrdXsceMYy6JbMEHfilVHaz/JnsioLCLR1sEpFttt277mJ9wFhNrlQYtuqXvdpEEXdzUuTN6iL1yzTmafWH+ho X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1e89aefc-9b87-4de2-cee7-08d6298f6ed2 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:CY4PR2201MB1111; X-Microsoft-Exchange-Diagnostics: 1; CY4PR2201MB1111; 3:uRQPb+De7rsLNyK/wAAMbEzkogdsbwxoU2KJIgzfrwolYTAfZO/Cuwrcejc5WtQv/XxXyiN+kx69e0ut2KCk/dAj+e8XF8BsJS6Yz999RcpNKNQYf8KliYWLYkwCfOAzKjwWV7MbLHioyUDiYpStsN66WycDCm+7od5BqswlPRUl2b4zt/JdNCwcUGsKT4C33Y/E3EWMqkWfG4oHT3fAVKXTIYL3IHtSVVSlLd07peUGs9eEG6VcOeFHXgXu0ZTPADrn2156MJzzf0CSKZkWI20+UTr/UlezjD92LsIa6y/EJCRV2assb+llW7KwWVnMzeArEMGsi1cvOqOuL6JCtrYMbtb4FPiG6EO7iPWNO1o=; 25:yCN5elUu32wqeMydLaih9OdTsajsQN2KIzCXdDmOSOh+7ziCbdq6ty6h6n4U5TfUQnZJqIruD3waWhnuv3kO7Kgp8xla8dSDX4x1gcTheg8OMfPCEOvXHlyKq5KAgIh65xiz/wMji7G0aA2Dwow97BX+xy1FaJ4BUznSfWZ+MtbsdzvQo09+VZV0mK8bip3vxUdIdqwi0/azHDf8OVTEDCu/YlxSKvUqzAhWR1Y7eeG7/PiamMGnKtLJO0HmKh+wXzPYimA9uBTNY1+kNQR+4Hdlp0kPep+zfUS+NO0QKUP8LvHRDES5qDOyhoH+Ig835jeUidtVcXycecX1oRhv4w== X-MS-TrafficTypeDiagnostic: CY4PR2201MB1111: X-Microsoft-Exchange-Diagnostics: 1; CY4PR2201MB1111; 31:4h81vKeH5S7xHIwPFydrXFnZr6kRa9mVIQVd3fphAqozghvB+wwyWoICBzErbawPk3cnKmTgOcBCL4RU74aIESljbmaDpG1834OXn5F+BJ+3nTOXZ0m3igKjZipZcp7ebRJCLMeHIT7aTp1codbDyvDVfnvqnrH1lr3DuGcAcLxSDr4psNj4wygUtZ/ozQrHzzVsjSPBxKsyq5yDaDSnWA6NhjwpjRmXaqDdZ6gfXOo=; 20:DlInLMdXMUlnObrEJS8XqJKF/4HSB81xs53OJNShfmoBblFFk414NPVTRASj+SIL2pw/dWejpFUhMN4WPhHevwX40LxBh7iRM0guO/iuIErTO4iIMD2hzRcK/2LFvF6HCYtPIC8s3w232uZL2egWITZyMnzbYc2ynIspuv47JJXAwVD/o18o+KDYYazfrmKU7bYFemOweKhccR7JZ9DebZcxV8mBKcHcnlbIy9DOTMKy6UJAjgi/a/S61ppBFaNcsfQXCwNlImSdaB6nRV8SX41k+KljUTD8H2k262xaq8C/yXPNIzvJpgXx5Ut0sW7dPchrTFbwGRQH/A9RPLMhU6UY22KrXoZKuHhuz1ob0a2SNei8YWMhsHSZNXFpaUFCaCPom24Sr5NYK5XFtXf7936JT6hJiF4JpTua732WSb30tTNSefDrW6JOtkHKDqpxr3zYpTAEneLNOVgQoMkXJcBcbOKEc7o/CEfn3v2MUHWLe5/It5T5rFBFFqqnfsaZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(155532106045638)(158342451672863); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93004095)(3002001)(3231355)(944501410)(52105095)(10201501046)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051); SRVR:CY4PR2201MB1111; BCL:0; PCL:0; RULEID:; SRVR:CY4PR2201MB1111; X-Microsoft-Exchange-Diagnostics: 1; CY4PR2201MB1111; 4:CThkUld3W5QUQPCvwGDmvWOL/1Vz0DV/jrdgApGfppVgoMXNLH8XtXR6bdRIWABrmmbSMwZFe28hlt5Qmt26DrUJeFWt15tl5yLYFvzmE8cnO+ZN/H/r5KWIWacki4WTGxRwJtMyp/JihfrRC1Zx2xhuLuKqG1aOQCxaA/aY7G0xLbIHGdULNJFxyVNgT88ZsLMsjGmhsoCRUWlGNUN4NISFpGqOHQVnvsKT15bkK7wCd2oFfYbpvW+OhN7i/4iJblvx4RRJ7fUz/x2DOwHcx7GYbLKBHJ4DWlnHkfrA8j9FBhHUsYhtS0Afx4Wj8ln6hKpB9+IQaUrer17r16wGAT4NGDW3aI18FAxzUNtrDTw= X-Forefront-PRVS: 0815F8251E X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CY4PR2201MB1111; 23:ToX0A1r96sza1l4p4BrxCYmmvMKiIdyxIlo4N?= =?iso-8859-1?Q?1hLAV04rYQa/QuL65Iw1/RFuNqsqAzgYl/aRltkm//kQJoWrGLKkLKX5SZ?= =?iso-8859-1?Q?B44AnhuiKNijRJtLsXoFlytMHTYobywJ3ZOeWzvsRKiWyvH6+8olLUweme?= =?iso-8859-1?Q?OWvKprO92aoCsmWv7nODQctWPO99AKDytCP3UH/+BjokUCkgIavWX62+3H?= =?iso-8859-1?Q?NNXp0vzY4xOE+VGTvrVpwbpqdQYBT6geHR/79zbQ4qtc+E9oiwFxvOCFp/?= =?iso-8859-1?Q?b9lu9wb66yrTDbZL9pMbop/F/c2USVEv11t8mHiP/Uwbe8/f61HzkZE3gQ?= =?iso-8859-1?Q?9bZm69vY6ECnsCD1tG1QiOKSm+DtQWmTKBMONnWbkBew7EEo8lB0hDHV9i?= =?iso-8859-1?Q?XQ0eWeXjsUzpMj+KBeuq9iU+qlAkfYBPP2QKDFtKQyhsxKBt52RS3UdOZm?= =?iso-8859-1?Q?+taIMXjSbhzSu1ZiHqZDC12xrA4xnJkqRpHI5SNJwqSH+OVe8UBftHThIl?= =?iso-8859-1?Q?pwVjhTg6Ye9bOV6O6sj956CCDrcwmPZw6+epmFSDg33Wo2ciLpmlxy+6BQ?= =?iso-8859-1?Q?VP5A3A4bEi+8yyHBrDBjUSLpY+WUch3gNQ8/VVaXTfq1c3+ZQzEjf0zxZ2?= =?iso-8859-1?Q?mm4nVSXqblihNjEazcF9gkkzsnX8KvfwsDmYHbCgkrbwzOz0eIPDNvwvng?= =?iso-8859-1?Q?Zqlrz1awztCFaevnI23dvdfO1f1K7fO7TTA3jNIVbe0dfulS2k74g2ZvQF?= =?iso-8859-1?Q?cLwgq0h8pzDOCB/l85SiZk2BIaTGA+1oOco0oqouShOW4mMKJVoWTdu2Ft?= =?iso-8859-1?Q?WZc5fJkBFwu1brXbmKusp7q4fNdv38tCyxqoESlFxTR8vcpoI3IL+PCS8M?= =?iso-8859-1?Q?h8rG29nA/4dyZC1M1840eK7uj3u9z39ErxcAz0hnQiJ5kUHhsOGWiDGaxe?= =?iso-8859-1?Q?sSvtCwwWG8w1VX/KrgWjYLdCw+Ct0F3d9IiKAKLZhhMJUs7CtJSIIXdKlT?= =?iso-8859-1?Q?zudssdu3cqCPruSq0ze83pe8+7blz1z1M1u+2q4zu4cgaaaB6BXR3yjapK?= =?iso-8859-1?Q?NlE7Bo0Hnassk1FKIPOVZY+W6CW66/hyQeTH0r2R/QBJpbpG6AE/8omxud?= =?iso-8859-1?Q?W1BM9Drv91Env0rn92esf8p0cwRn3M1LUW7wqFRv7Im2jUx9OjPs98eOca?= =?iso-8859-1?Q?KpgK11+2nyNJUBuzfu+EzRjm40U+4gAby45CiHop4Ww5oVItkSb5cW7o7N?= =?iso-8859-1?Q?ihWQHutgqM6nRPN3fq2cWbsQlLR6yp8Q5OrFbsh1U06QfZRnBJSyyGGzzW?= =?iso-8859-1?Q?Wr1jP4L0JlXSnkIcXu0fdMRlIJ6BjFFoiys3II+M08B+wOw=3D=3D?= X-Microsoft-Antispam-Message-Info: wLjHKI6BnrZ8z3wE4BtGicDIonyZRVJy8Iz9biSazNAmH71v42C95LZ1QBxbqo+uwwOGXG/UZWqgNQcLf5vLL2wtputylyv3miJTJ7LPiNVDx/9bXQ/MJcNG9LDSJfpqNaRvJG9705gDheGLJpJGOB5K3GTRu1msAx77HdWPkSsvCbggSBpoK1CtxyJGBeODyXL/TpvgVA3NuW+kBXWr6o8BB4wNuN783ZLgwi1xp3JjwiFRxqsq/Qv0rlI1tgsWUFmJC5WlmAyIkFnq/K+68fxZkIEGsrDFgGoBmxZcNO2C/pNKCpOoV88FvXRcm/EmCtHy70U8/VfmLiazQubV1omlY9IHQwCgY7BSbzNO4V0= X-Microsoft-Exchange-Diagnostics: 1; CY4PR2201MB1111; 6:24YV/B5eeYzHb9MPiDKJjsXrBm7PYtD8aX+Ipq+OmE1MRwHeKarm8nzbHZ9ksQyQJIiQG/B9UvHWC7RsNw765ehRGBALD63Q00Bq6zqLClDneqwyOUGZh3M0kzKYtQOCJ8ALU5/iARgSMOl99FTd8gbaiAz9RXOUPjFLiCWjTjHKZ5e+OPRROo/r7IGISdLS+QVk9QXBXo8HuHATiDY29pAAv60gPqFSzTFfSEfEDx8CqkbaX5VJ8xkNjeBYKf+RG/psq0VACg8wiG4zjHXaKTo7ja7HSms6wPGVu7q4lxWlTCKca9pkfG8yUoykfRrGYXPCbRupVQ3k2XqblVbGGRh98ob+czYOYC39g21OKNPJCvjN9d2NoSuODhTqMktXtLvW1I1rDfI56KbLt2xmfNW96Iwey27vAxbGQCYQ9RXMHD86KMC1aYKA0z44T2Hq4zd32wU2Ffh2DfLOwYzUMg==; 5:gmSEKynuTa4NRTplhlR+SSaqA9onq/sBJhCd4Ls8mk1LOBUbDkv22LgswcWmL4ZXbfk854kZ1kr+JNgqCGGtexENur+Zx2K/Uv9fgiJZTdieVw9aN8mQIrH0YHRltaBEBWwj3ODoMWDeIAUxgIiHQEeJTCFLgbuYa0RDUHFLr0c=; 7:OywHp4AIEamk7ENZdvv79rFYlrm7vrmsgZOVUiDn19C6yzCEWw2r//ZjB2InlidoOcPQv4rjFoS20ud+KP+Z+VMd0xGYow9Ubp6MpxV+xYxUuo3IbExPLQAoUKFtm8zpHAhxEy1AdNhZsM5r90AeGwWvzeM/xKPMCPRZ5/Oju9EG2hAUxk2HiqiSDhwojyYigI5XodFXLM1ZI/C6AOL5jzBKpGSvihTwvlZZcgaoYfAIhk2OD57+0jDcj4tNaPL4 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aviatnet.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2018 00:22:13.4781 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1e89aefc-9b87-4de2-cee7-08d6298f6ed2 X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54]; Helo=[mail-send.aviatnet.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR2201MB1111 Archived-At: Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 00:22:19 -0000 Do not support.=0A= =0A= This document does not make a good case for why tags should exist.=0A= The introduction does not explain what they are useful for, it just makes a= comparison to #hashtags (which is something I would expect to see in an Ap= ril 1st RFC).=0A= The initial registry values, section 8.2, also provide no insight as to the= value of any of these tags. At best these values could be used to categori= se modules for human browsing.=0A= =0A= In short, I see no evidence that the standard this document attempts to def= ine is actually useful.=0A= =0A= =0A= =0A= Additional major concerns:=0A= - the draft does not indicate who should implement the included YANG module= .=0A= - there is no automatic mechanism specified (such as an extension statement= ) by which the server can read the tags from the module (as 4.1 specifies m= ust happen), therefore the implementer will have to do this manually and is= likely to forget.=0A= - I do not believe servers should be concerned with classifying their imple= mented YANG modules, unless there is a good reason. This seems like a clien= t responsibility. How will the system work in a large network with one clie= nt reading data from 500 servers, each of which could have different tag da= ta? Or maybe two clients with different tag data, both trying to update the= network to hold the "correct" data.=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: netmod on behalf of joel jaeggli =0A= Sent: Wednesday, 3 October 2018 9:21 a.m.=0A= To: NETMOD Working Group=0A= Subject: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/= 18=0A= =0A= This is start of a two week working group last-call for=0A= draft-ietf-netmod-module-tags-02 a current netmod working group=0A= document.=0A= =0A= You may review at:=0A= https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02=0A= =0A= Please send email to the list indicating "yes/support" or "no/do not=0A= support". If indicating no, please state your reservations with the=0A= document. If yes, please also feel free to provide comments you'd like=0A= to see addressed once the document is a WG document.=0A= =0A= The prior discussion of my mistaken WG adoption call is here=0A= =0A= commences here:=0A= =0A= https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html=0A= =0A= In particular Andy's concerns expressed in that thread here:=0A= =0A= https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html=0A= =0A= are probably important to tease out in considering this for last call.=0A= =0A= so that we are clear on dates. This last call timing resets and runs=0A= from 10/2/18 - 10/16/18=0A= =0A= Joel=0A= =0A= From nobody Wed Oct 3 19:43:34 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42577130DDA; Wed, 3 Oct 2018 19:43:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153862099823.8954.12813773940704626148@ietfa.amsl.com> Date: Wed, 03 Oct 2018 19:43:18 -0700 Archived-At: Subject: [netmod] Genart telechat review of draft-ietf-netmod-schema-mount-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 02:43:19 -0000 Reviewer: Joel Halpern Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-netmod-schema-mount-?? Reviewer: Joel Halpern Review Date: 2018-10-03 IETF LC End Date: 2018-06-29 IESG Telechat date: 2018-10-11 Summary: This document seems to meet the specific requirements for publication as a proposed standard. Major issues: It is still this reviewer's opinion that for a reader who has not been involved in the discussion in the working group, the document is quite unclear and confusing. For somewhat more details, please see my previous review at https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/ Minor issues: N/A Nits/editorial comments: N/A From nobody Thu Oct 4 02:36:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768C130E05 for ; Thu, 4 Oct 2018 02:36: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, DKIMWL_WL_MED=-0.001, 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 ky_MRe77lXkO for ; Thu, 4 Oct 2018 02:36:02 -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 302BA130E0C for ; Thu, 4 Oct 2018 02:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3848; q=dns/txt; s=iport; t=1538645762; x=1539855362; h=to:from:subject:message-id:date:mime-version; bh=J73KW76ctcMUqv8lrX2dFzpzv5TWrl6q+41SvrAp034=; b=KgZsjlH56VYTwkrKoUYNQOuqI8qgE2iGq8gjEypRyvTjdHdrV6WqbKRv 6pY30HDhH0lnpHvd1yVSVgbKwQN9DXNUSpD3h7jtw5ey7j9qLm6ANtv+d oJi2CnPQOnvLkz1QKdfmCBU2dMz7wqzrnVoT7hzOtQldSxm11BatQuosF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AADI3bVb/xbLJq0YAUIaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoENSIIUhByIdI0mkUKHOw2JMTgWAQMBAQIBAQJtKIV?= =?us-ascii?q?jdQo0Al8BDAgBAReDBoIChwecaIEuH4RYhSGLO4FBP4ESJwyKXoJXAo5ajnw?= =?us-ascii?q?JkDoGF4FMh0iGVYkBhjOGKoFZIYFVMxoIGxWDKJBUPo1HAQE?= X-IronPort-AV: E=Sophos;i="5.54,338,1534809600"; d="scan'208,217";a="6990802" 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; 04 Oct 2018 09:35:59 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w949ZxtX010492; Thu, 4 Oct 2018 09:35:59 GMT To: Christian Hopps , "netmod@ietf.org" From: Robert Wilton Message-ID: <31e2a1f6-93f3-14bb-3457-30601e43c30f@cisco.com> Date: Thu, 4 Oct 2018 10:35:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------66AF86CDC08F1CD1D5BADBD1" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [netmod] draft-verdt-netmod-yang-versioning-reqs-00, requirement 1.2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 09:36:04 -0000 This is a multi-part message in MIME format. --------------66AF86CDC08F1CD1D5BADBD1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, At IETF 102 you had an objecting to requirement 1.2 in draft-verdt-netmod-yang-versioning-reqs-00, I think because you saw that it was either leading towards a particular solution, or that it ruled out other potential solutions. To that end, I would like to ask whether the following text would be more acceptable and address your original concerns? Old: 1.2 A mechanism is REQUIRED to update a module in a non-backward compatible way without forcing all clients/servers to access data nodes in the model on new paths, or in a new module namespace. Specifically, if a particular data node is updated in a non-backward compatible way then it may be desirable for it to be available on the same path and in the same module namespace. New: 1.2 Non-backward compatible updates of a module MUST not impact clients that only access data nodes of the module that have either not been updated or have been updated in a backwards compatible way. Thanks, Rob --------------66AF86CDC08F1CD1D5BADBD1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Chris,

At IETF 102 you had an objecting to requirement 1.2 in draft-verdt-netmod-yang-versioning-reqs-00, I think because you saw that it was either leading towards a particular solution, or that it ruled out other potential solutions.

To that end, I would like to ask whether the following text would be more acceptable and address your original concerns?

Old:

       1.2  A mechanism is REQUIRED to update a module in a non-backward
            compatible way without forcing all clients/servers to access
            data nodes in the model on new paths, or in a new module
            namespace.  Specifically, if a particular data node is
            updated in a non-backward compatible way then it may be
            desirable for it to be available on the same path and in the
            same module namespace.

New:

1.2   Non-backward compatible updates of a module MUST not impact
      clients that only access data nodes of the module that have
      either not been updated or have been updated in a backwards
      compatible way.
Thanks,
Rob


--------------66AF86CDC08F1CD1D5BADBD1-- From nobody Thu Oct 4 03:06:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A4130E0C; Thu, 4 Oct 2018 03:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyg3tzKzwQk0; Thu, 4 Oct 2018 03:06:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07A55130DFB; Thu, 4 Oct 2018 03:06:05 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D87171AE0331; Thu, 4 Oct 2018 12:06:02 +0200 (CEST) Date: Thu, 04 Oct 2018 12:06:01 +0200 (CEST) Message-Id: <20181004.120601.2031947201933436857.mbj@tail-f.com> To: jmh@joelhalpern.com Cc: gen-art@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org, ietf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <153862099823.8954.12813773940704626148@ietfa.amsl.com> References: <153862099823.8954.12813773940704626148@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Genart telechat review of draft-ietf-netmod-schema-mount-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:06:10 -0000 Hi, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-netmod-schema-mount-?? > Reviewer: Joel Halpern > Review Date: 2018-10-03 > IETF LC End Date: 2018-06-29 > IESG Telechat date: 2018-10-11 > > Summary: This document seems to meet the specific requirements for publication > as a proposed standard. > > Major issues: > It is still this reviewer's opinion that for a reader who has not been > involved in the discussion in the working group, the document is quite > unclear and confusing. For somewhat more details, please see my previous > review at > https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/ I'm sorry to hear that you find it confusing. I was under the impression that the edits that we made after your previous review were sufficient. /martin > > Minor issues: > N/A > > Nits/editorial comments: > N/A > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Oct 4 03:14:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49136130E14 for ; Thu, 4 Oct 2018 03:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R76-K1Ywlm5r for ; Thu, 4 Oct 2018 03:14:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99A68130DFB for ; Thu, 4 Oct 2018 03:14:18 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EDE41AE0331; Thu, 4 Oct 2018 12:14:17 +0200 (CEST) Date: Thu, 04 Oct 2018 12:14:17 +0200 (CEST) Message-Id: <20181004.121417.2190375850946168105.mbj@tail-f.com> To: phil@juniper.net Cc: balazs.lengyel@ericsson.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <201810031419.w93EJNpn040188@idle.juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 10:14:20 -0000 Phil Shafer wrote: > Bal?zs Lengyel writes: > >https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > [I've moved to a "deep lurker" role here, but ...] > > Can we ensure this model contains a "format" leaf in the RPC's input > so that future (and proprietary) formats can be supported? That > leaf can be an identityref that defaults to yang-patch. I think this is a good idea. I would prefer the edit-config format over YANG patch for describing a diff. The edit-config format is more suited for this purpose imo. /martin From nobody Thu Oct 4 05:20:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D37130E50 for ; Thu, 4 Oct 2018 05:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ehl0WRoV; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CHCeCG4r 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 t576aNL3FKu7 for ; Thu, 4 Oct 2018 05:19:58 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E186A130E21 for ; Thu, 4 Oct 2018 05:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538655595; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qBuujQL5euW7Ux5+/++mvYlKCsPSfeZvupF8sB8E6Rc=; b=Ehl0WRoVIL9jJ+8Mh2XMv3JWPZ97VfD43Uq6YuzIINU93wAPomJdYi2+DrB9F5u2 uQUfBdWcwC7U2IyYu/PQfmhxMFYqmTLGeG1ArWsoYx6sHy+xgnpQmWLq3HjdEfTw e5BRqUTute3dHgYUemLLfx33v4t0Frt94BwmT4yrR3I=; X-AuditID: c1b4fb2d-223ff700000055ff-26-5bb6056b7a39 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.B7.22015.B6506BB5; Thu, 4 Oct 2018 14:19:55 +0200 (CEST) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Oct 2018 14:19:55 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 4 Oct 2018 14:19:55 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 4 Oct 2018 14:19:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D7TSqTpM0Nz+Lgohx6AvA8CuLZUjxiYSNy3D0HMTaw4=; b=CHCeCG4rjA9J35Z7waskkGo5F6MgpDUcH1/FHFOt4PRt0mZaos4HUAnzH+ii/STwTtem9ZLomVLG9TGKgki+9xqeNnihal9NziV/c2E1uqIuYog55iAnVuYqt3iRkSTeFEvrpvdBDNrmi+FP2aPPtTGnMfw/Dg1lL2FSEVOOqBw= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2864.eurprd07.prod.outlook.com (10.173.71.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.10; Thu, 4 Oct 2018 12:19:54 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::3d6c:4f4c:93f7:cd98]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::3d6c:4f4c:93f7:cd98%12]) with mapi id 15.20.1207.022; Thu, 4 Oct 2018 12:19:54 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-lengyel-netmod-yang-instance-data-04.txt Thread-Index: AQHUW9yO0BGqOpjvKkeM17pszd/0Ng== Date: Thu, 4 Oct 2018 12:19:54 +0000 Message-ID: <8e529beb-a998-1c6c-d9a5-8b81fea12c77@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 x-clientproxiedby: AM0PR02CA0004.eurprd02.prod.outlook.com (2603:10a6:208:3e::17) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2864; 6:wAHOHCqooQzFOu27s9E/OF64HDGdYk1Cz3XPTMa+6AAP8Wn7lA/d5o++aWJp9rvupxMer/aWASYKwhzqwvMc7yC+Y5QeEGeJIGDegwn5rVNgBmiDS46SGSl0okRwTtNxFxOxba+iR9eChDHTYAP9VF4aarsOW4DnBDF5wcxGRoDwx/KOo5DFMrT3unTXvGA6HfEb+VADJjgrsChlL/qmtsMxN2HiQxDQklaRrpZou+e3NajUGKO1SIqSM05gAIGFX21XocArlVvMOS02EEkdUbyyvT2dnFQjUV1nA2jYHUe5DjxLI7irWjmd29k1QemvM7bmWlcsJzya3e09YMeXTrAc4LstzyKx3hlj7D0ii0VA1JL0lDOijXpWaoSNgK/yrbosHVSbr0xLL4yNkFsdNCtxYEeztov4xVlw9jYCh2OVRmdWXFS2YJEBS9y23+206ehtleuW2AghGg3I1p59oA==; 5:PfwegEJE9Z0ke2DQ25MRnMhcM53HL7puTLVSytcvgNdqjlKj2gftH+p7JSKuh8DCzXaTHhKQbkf5Cn5YDy6gVgWdDUZxy77Fkli5nfXDDsz4/Qv90V+mBZMRdGNmw2GNtH0NzomS8SOPEd9Ocnk4Tpudr1PeBgZVTYP6ixFn4/4=; 7:I+nBwoNICp4Dt3F+pkSP+156vH5uMyZrIfD9v2zEiDPxjJlfrnToghbHbN7m2UK5AI/UTAKCuEQI0u7Dw7XCSv2x5jw4SJeTnATBMJ1ip6UBhwNzvgUDgU/qgsMKI5yZy4n0OlwOyZussow3YXm3qgVWTXhGqhqyg9mZuzFByKTCoRFBMDnecB0tf2Q3L12nDdB6mfR5P1837PktDJAsY2OdJwO5d84U+dxEJBOQxbZAmfPHznwXAW/QOU0fVPld x-ms-office365-filtering-correlation-id: 73bb86dc-8915-427f-46eb-08d629f3b03c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2864; x-ms-traffictypediagnostic: VI1PR0701MB2864: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(201708071742011)(7699051); SRVR:VI1PR0701MB2864; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2864; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(136003)(376002)(54534003)(199004)(189003)(5660300001)(7736002)(26005)(14444005)(31686004)(65826007)(256004)(99936001)(36756003)(6436002)(6486002)(186003)(97736004)(316002)(52116002)(2900100001)(8936002)(478600001)(81166006)(81156014)(1730700003)(8676002)(2906002)(15650500001)(6116002)(3846002)(2351001)(606006)(5250100002)(2501003)(85202003)(106356001)(105586002)(102836004)(5640700003)(65956001)(65806001)(14454004)(966005)(3260700006)(25786009)(386003)(6506007)(2616005)(476003)(486006)(85182001)(6916009)(64126003)(54896002)(6306002)(6512007)(53936002)(66066001)(58126008)(99286004)(86362001)(71200400001)(236005)(31696002)(71190400001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2864; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +Lxo2+oLdJpY+RXMGLvkJZ4/OnmBDhdjCqqNug3AhPuS7iS1K16CgONlr+ztjUEuFOB0yIfsd4tLPy/W6kywE1gHNk6QNv/g2UyMPLFD1evQSWpR21Mv+VcKRqx8029R256DwaY7SjW2Mhd9Bh3L1si0XPm4fjrKMD0+K/DYpY3WRgRXgUY+aRRw/oBIUhC7nblMtdHPng9yIUw/Y7TFJY/udvTAzNKvHFRsS6fxkgHlYvpERGRiaHVZw6ZF8uql/VYT6+UM9MV2GKRJIcobZq4GSkIoJYebY+puZRVro/8tLHa+gwBRE2erjTMlQ0PshmBdjpy4pHzMxN1yd8b6umb3xsq6XH7zd42qSu2FaOM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050402000205030303020501" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 73bb86dc-8915-427f-46eb-08d629f3b03c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 12:19:54.2466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2864 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/febdfh5DY1f0wSXGWQuXwUCZY90DDIkogQJW3pzfeUXR2a RJMwn4Whhi7KR6axqZk207B8xMRHlg+otJI0U3SlhahZZG07BvXf53e+3+/vnC8cmhS/4Eno GEUyq1TI46V8IVUa/CjdLY7XHOre0eHpXTaUwTuIAqqqVokgFCLcF8nGx6hY5S7fs8Lo7sUT STcDUie0akqNag7nIisamN3Qo3tP5CIhLWYMCFYfTwvwsISgqVnLM7ssQ91yOBbuENBWnEGa B4opIOFe+yDCyg0CDG8G+DgyjeD5go+Z+YwfZM23E2a2Y7ZDaet9k4embZnT0PXUGx+Hwtxs 97pFBmMPRkkzU8xWWP1cbHmFiDkAw/oaiwcxm2Clr9bCJOMAY1NlBO5jBxND/XzM9jD7cY2H WQolc2MWtjfddaV40dIZmBIEby83CPDSMGgbz14P74SB11MI82YYLstDONAhAN0r/boQCAvd n0gsjCC4PVhlaWZO/x73x55EeDaauf66Y6DuNJKYnUB7dYIqQO6af0poTKtIJgdBfuUcobG0 3gi9pVOUxrSWZFygOlP6v9/MrlBdYSQx+0DJj04+ZmcoypsQYN4DRsM3hNkLqut/8cuRUIvs OZbjEqI8vWSsMiaC4xIVMgWb3IhMP6vz4U+3FqQzHupCDI2k1iLDvD5UzJOruLSELrTVtGey QTeIJJQiUcFK7USGNZMsipSnXWCVieHKlHiW60KONCV1EMm0bSFiJkqezMaxbBKr/KsStJVE jTTdNUMt8U6TQeoMl9rgsKVzdS8dvwamdzZmBR9vAmNjeX6E4cgHG33BXfvQd8zM3hxR4Hm/ bK+VEe9kXoWjZqG18ExK//WZnhSX7Es+SXGqL6f6eqf3p8beSl8++V1ia+0x7CupV9nkq/wv CjZsqXRddX5ytLDCOXabtcM1orYoQUpx0XKPHaSSk/8BMflB4mEDAAA= Archived-At: Subject: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 12:20:01 -0000 --------------ms050402000205030303020501 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

I posted a new version (-04) of our draft about Yang Instance Data.

The change from -03 is only that I updated the changelog for the 02 to 03 change. I clarified that I included all comments from IETF 102 (and some minor editorial comments received on the list since then).

IMO the draft is ready for WG adoption.

regards Balazs

------------------------------------------------------------------= --------------------------

A new version of I-D, draft-lengyel-netmod-yang-instance-data-04.txt<= br> has been successfully submitted by Balazs Lengyel and posted to the IETF repository.

Name: draft-lengyel-netmod-yang-instance-data
Revision: 04
Title: YANG Instance Data Files and their use for Documenting Server Capabilities
Group: Individual Submission
URL: https://www.ietf.org/internet-drafts/draft-lengyel-ne= tmod-yang-instance-data-04.txt
Status: https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-inst= ance-data/
Htmlized: https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-dat= a-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-= yang-instance-data
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lengyel-netmod-yang-instance-da= ta-04

Abstract:
This document specifies a standard file format for YANG instance
data, that is data that could be stored in a datastore and whose
syntax and semantics is defined by YANG models. Instance data files can be used to provide information that is defined in design time. There is a need to document Server capabilities (which are often
specified in design time). Defining server capabilities is foreseen as the most important use of YANG instance data files.



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.<= br>
The IETF Secretariat



--------------ms050402000205030303020501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwNDEyMTg0Nlow LwYJKoZIhvcNAQkEMSIEIO98i+Hg+NuQa51FDmquxJDKnswNVcb5EiHe+BNZ/DZaMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAGUHACLFNLjQyIPVSfoZTQbELlTmRMXnut3J1ssxPDe27AnH HxCxeV3Ce2eiMk4eKdx4FOsjatdkZBdZbLmD2zrWIaOJbYudq1f1lzw3BKzPsJqyDFcPysEe 1penYhrozDzneTj3qeAq8VZzKfiy01IRtO5oaCRKAobW4T3LjlClwdrH0fCrgjSTKH8Dll/3 2TkQrf8VSTZCWMASz6GFVNuSArnsJM2L2HzkuFqs5A0XHlZnKY5Zi9lNacwnwJbUYXb58RR6 TLa1Nzhrh2Uf4IZ8a0n7FJlwrzySBAsj9Kiw0dQVfIKcaqxTzp9F05fKaoEtVZak4EHXSJDn jyVBSwEAAAAAAAA= --------------ms050402000205030303020501-- From nobody Thu Oct 4 05:36:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C51130E93; Thu, 4 Oct 2018 05:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 0JosqyHPdbE4; Thu, 4 Oct 2018 05:35:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 301CB130E6C; Thu, 4 Oct 2018 05:35:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E54293250A1; Thu, 4 Oct 2018 05:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1538656542; bh=lDKDwceMpMtL6y3NIAmt3fSuCgNQOoQt66P6Ne6qu/4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=K6x6tTvASRObugLQ5PbS/8C/b/HcP1KkHyF9qM7syRVDGwHZ3TT4e0ozJaF0eUdIP ZyPcxSUC1lxsvdfvbuzNUm/2CFjfPx3OXE/eDfU8JcCBKMFJmSy1Qg9OKHjPhFPc5W itmP68XeawecavMWyVwqDbYm0cGiB1EdyFNu4hi0= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1D823323E8B; Thu, 4 Oct 2018 05:35:42 -0700 (PDT) To: Martin Bjorklund Cc: gen-art@ietf.org, draft-ietf-netmod-schema-mount.all@ietf.org, ietf@ietf.org, netmod@ietf.org References: <153862099823.8954.12813773940704626148@ietfa.amsl.com> <20181004.120601.2031947201933436857.mbj@tail-f.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 4 Oct 2018 08:35:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181004.120601.2031947201933436857.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Genart telechat review of draft-ietf-netmod-schema-mount-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 12:35:52 -0000 I had thought we had discussed sufficient edits. When I looked at the diff, what I saw helped some, but still left me concerned. Yours, Joel On 10/4/18 6:06 AM, Martin Bjorklund wrote: > Hi, > > Joel Halpern wrote: >> Reviewer: Joel Halpern >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-netmod-schema-mount-?? >> Reviewer: Joel Halpern >> Review Date: 2018-10-03 >> IETF LC End Date: 2018-06-29 >> IESG Telechat date: 2018-10-11 >> >> Summary: This document seems to meet the specific requirements for publication >> as a proposed standard. >> >> Major issues: >> It is still this reviewer's opinion that for a reader who has not been >> involved in the discussion in the working group, the document is quite >> unclear and confusing. For somewhat more details, please see my previous >> review at >> https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/ > > I'm sorry to hear that you find it confusing. I was under the > impression that the edits that we made after your previous review were > sufficient. > > > /martin > > > >> >> Minor issues: >> N/A >> >> Nits/editorial comments: >> N/A >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From nobody Thu Oct 4 05:36:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEA8130EBB for ; Thu, 4 Oct 2018 05:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 D3M6Hoy902FP for ; Thu, 4 Oct 2018 05:36:16 -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 206AC130E95 for ; Thu, 4 Oct 2018 05:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=903; q=dns/txt; s=iport; t=1538656576; x=1539866176; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hEVkW0jyLaEwdz1BZJe4kLZFt3N0XiITH60m6IqyTK8=; b=mnKSLMLd3p79PkvY9vjvO+TI0Fbh8TIlySXbs7i+Ug7BjUr8bNbb/BRS +zlfk+C5gO0rzcO7P5esVBG5cLuWNWW2Fp5QIEz7iaMeXXhsWcfxclhC4 iAF4tGo9DrCrIzarwdGDvjoBVy7fHtqABRuTlGZ75RIq5Nd8mS3ezk+AS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAAASCLZb/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCa38og3SIdI1LmFgNGAuEA0YChEY3Cg0BAwE?= =?us-ascii?q?BAgEBAm0cDIU6AQEBAwEBIRU2CxALDgoCAiYCAicwBg0GAgEBgx0BggEPo1W?= =?us-ascii?q?BLoR3hRgFgQuKMIFBP4E5gmuDGwEBA4RfglcCjlqOfAmGSolwBheJFIZVjBm?= =?us-ascii?q?DG4YqgVgigVUzGggbFTuCbIsWhT8+MI0XAQE?= X-IronPort-AV: E=Sophos;i="5.54,338,1534809600"; d="scan'208";a="6992299" 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; 04 Oct 2018 12:36:14 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w94CaDQo008703; Thu, 4 Oct 2018 12:36:13 GMT To: Martin Bjorklund Cc: phil@juniper.net, netmod@ietf.org References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> From: Robert Wilton Message-ID: <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> Date: Thu, 4 Oct 2018 13:36:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181004.121417.2190375850946168105.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 12:36:23 -0000 On 04/10/2018 11:14, Martin Bjorklund wrote: > Phil Shafer wrote: >> Bal?zs Lengyel writes: >>> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 >> [I've moved to a "deep lurker" role here, but ...] >> >> Can we ensure this model contains a "format" leaf in the RPC's input >> so that future (and proprietary) formats can be supported? That >> leaf can be an identityref that defaults to yang-patch. > I think this is a good idea. I would prefer the edit-config format > over YANG patch for describing a diff. The edit-config format is more > suited for this purpose imo. +1 I would like something closer to edit-config to be available via RESTCONF as well. Thanks, Rob > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Oct 4 05:51:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154D130E4F for ; Thu, 4 Oct 2018 05:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 hCWDId-0W7lh for ; Thu, 4 Oct 2018 05:51:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 194A8130E0C for ; Thu, 4 Oct 2018 05:51:51 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 51F9C626CF for ; Thu, 4 Oct 2018 14:51:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1538657508; bh=TirAHeIQ53du5LOhQTwpejeW41Uz+Ki8jdV/wxLde1o=; h=From:To:Date; b=CyOJ2RXNulcGOJrFPSG1vc1oMKbldIlfDcaEOwr7Jd87rHqaE633/ypU+wln26GPc CNAlM5i7YTqG9NnjPJpFv4SqQWq8K429jAG+qiu/JbAEZfssPsmu1KgXbLcYh3vzLb drq0Au2ETYmWQvafc055wVFo6llLUOThLjqt5b+k= Message-ID: <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Thu, 04 Oct 2018 14:51:48 +0200 In-Reply-To: <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 12:51:55 -0000 On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > Phil Shafer wrote: > > > Bal?zs Lengyel writes: > > > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > > [I've moved to a "deep lurker" role here, but ...] > > > > > > Can we ensure this model contains a "format" leaf in the RPC's input > > > so that future (and proprietary) formats can be supported? That > > > leaf can be an identityref that defaults to yang-patch. > > I think this is a good idea. I would prefer the edit-config format > > over YANG patch for describing a diff. The edit-config format is more > > suited for this purpose imo. > +1 > > I would like something closer to edit-config to be available via > RESTCONF as well. YANG Patch is IMO better because it clearly separates the target for the edits from the new content. In edit-config these two are mixed together. That being said, I support specifying format/media-type and having potentially multiple options. Lada > > Thanks, > Rob > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Oct 4 06:18:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C796C130E5A for ; Thu, 4 Oct 2018 06:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 9XXL4LlPS6tu for ; Thu, 4 Oct 2018 06:17:59 -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 6B58B130E4F for ; Thu, 4 Oct 2018 06:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1538659078; x=1539868678; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QtKewJQ+ioNlO2FTFaS+dElfW4m7KTM+1LrWFfG+PBc=; b=YwsnhV5CKtLgOHlxcMkEYUK9UsTjCverZ09UmaLsiIlC4rwkZXotRX9r 6V8monP5GxLA0ZixDw0KEUlhOuxepY5m7Rpf2EBD2ZMDV4yWU4iL6X6gd NUvwcVT9U7uiFT7ejwUooVKhGhZ4Q8e3MicRss+osWqolY2b00NMLp735 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAADWErZb/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJsfyiDdIh0jSAtmFcNGAuEA0YChEY4FgEDAQECAQE?= =?us-ascii?q?CbRwMhTkBAQEBAgEBASEPAQU2EAsLGAICJgICJzAGAQwGAgEBgx0BgXkID6N?= =?us-ascii?q?kgS6Ed4UYBYELijiBQT+BOYI2NYMbAQEDhF+CVwKdVwmGSolwBheJFIZXjBy?= =?us-ascii?q?DHIYngVkhgVUzGggbFTuCbIIlF4hahT8+MI1kAQE?= X-IronPort-AV: E=Sophos;i="5.54,338,1534809600"; d="scan'208";a="6995976" 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; 04 Oct 2018 13:17:45 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w94DHjfn014423; Thu, 4 Oct 2018 13:17:45 GMT To: Ladislav Lhotka , netmod@ietf.org References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> From: Robert Wilton Message-ID: Date: Thu, 4 Oct 2018 14:17:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:18:01 -0000 On 04/10/2018 13:51, Ladislav Lhotka wrote: > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: >> On 04/10/2018 11:14, Martin Bjorklund wrote: >>> Phil Shafer wrote: >>>> Bal?zs Lengyel writes: >>>>> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 >>>> [I've moved to a "deep lurker" role here, but ...] >>>> >>>> Can we ensure this model contains a "format" leaf in the RPC's input >>>> so that future (and proprietary) formats can be supported? That >>>> leaf can be an identityref that defaults to yang-patch. >>> I think this is a good idea. I would prefer the edit-config format >>> over YANG patch for describing a diff. The edit-config format is more >>> suited for this purpose imo. >> +1 >> >> I would like something closer to edit-config to be available via >> RESTCONF as well. > YANG Patch is IMO better because it clearly separates the target for the edits > from the new content. > In edit-config these two are mixed together. Yes, that is primarily why I prefer the edit-config.  I perceive that it is a denser and more efficient format.  I think that it is both easier to construct (when diffing two trees) and also more efficient to apply when generating an updated tree. Thanks, Rob > > That being said, I support specifying format/media-type and having potentially > multiple options. > > Lada > >> Thanks, >> Rob >> >> >>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 4 06:44:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B882130E4B for ; Thu, 4 Oct 2018 06:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ7qMmGmy40F for ; Thu, 4 Oct 2018 06:44:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C78E9130E03 for ; Thu, 4 Oct 2018 06:44:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 09B2E1AE0442; Thu, 4 Oct 2018 15:44:48 +0200 (CEST) Date: Thu, 04 Oct 2018 15:44:48 +0200 (CEST) Message-Id: <20181004.154448.1934765954209842070.mbj@tail-f.com> To: rwilton@cisco.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 13:44:54 -0000 Robert Wilton wrote: > = > = > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > >> On 04/10/2018 11:14, Martin Bjorklund wrote: > >>> Phil Shafer wrote: > >>>> Bal?zs Lengyel writes: > >>>>> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > >>>> [I've moved to a "deep lurker" role here, but ...] > >>>> > >>>> Can we ensure this model contains a "format" leaf in the RPC's i= nput > >>>> so that future (and proprietary) formats can be supported? Tha= t > >>>> leaf can be an identityref that defaults to yang-patch. > >>> I think this is a good idea. I would prefer the edit-config form= at > >>> over YANG patch for describing a diff. The edit-config format is= more > >>> suited for this purpose imo. > >> +1 > >> > >> I would like something closer to edit-config to be available via > >> RESTCONF as well. > > YANG Patch is IMO better because it clearly separates the target fo= r > > the edits > > from the new content. > = > > In edit-config these two are mixed together. > Yes, that is primarily why I prefer the edit-config.=A0 I perceive th= at > it is a denser and more efficient format.=A0 I think that it is both > easier to construct (when diffing two trees) and also more efficient > to apply when generating an updated tree. I agree, this is why I prefer this format for general diffs. /martin > = > Thanks, > Rob > = > = > > > > That being said, I support specifying format/media-type and having > > potentially > > multiple options. > > > > Lada > > > >> Thanks, > >> Rob > >> > >> > >>> /martin > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> . > >>> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 4 08:04:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9B3130E67 for ; Thu, 4 Oct 2018 08:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 Vu6Vu2PTweoz for ; Thu, 4 Oct 2018 08:04:52 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 E7569130E63 for ; Thu, 4 Oct 2018 08:04:47 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id r8-v6so8663810ljc.10 for ; Thu, 04 Oct 2018 08:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tfe5bQexYU7NVdZel50pijECyLia6Kt4AmW6NBQu7dQ=; b=lc0L855L7Lc/MxjzJAMpbRAfjdUpfrV3wWXCxVcMMEjni0Y4F9Edql2XYf8NsYl6hj 3wqizo1HLufYuxleaGP87r7PKhZzNhWcIkCQKpNT/gTUCFkNBicz9GUcGI4f/i1BzwC1 Psy8n5brDFXSxpCLIviu/J/UDgEymjw5AC6XLuFkVY6Us1c6yKs0eA0i307eqFiSgTK7 UrFGyaYNFpISXeuJ4gF/omEmlzJ4O/GogY1n85SvVDoQG5AT5mgOt3moXKeFX+e2OFrl mcwalY0rPzij3WIRo1h06BDEYUNu5RcNaCejt+j0EIts0tWQXK/vFcqlQdLHnXiZ+GHd jD6A== 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=tfe5bQexYU7NVdZel50pijECyLia6Kt4AmW6NBQu7dQ=; b=e+8fqKoEAYNmealqTRCq4uphy/IICHSpE1Jh2sZVy/duBBR7JhoOjGo9ohxeIQvef1 ELFezS3iNhgtUsWgVv1H6fxD4VliW0IjpGB7KgTh4pNAHcOrDbbeTzrYocrbdvEtK0B3 dOzUWkePpLOPtct3EKoWyOI1DpxpHGk+eCOXTS5mdFG4MySnYStUm0ffKOyTdEZ8glar iNfOVZgndeo6e3E+qoVheKx/JfrKLQKL1aig9ZkcvxbX59Xg+uuRgmLHWvP5ZDk+ha5G FfyRfbmVGZqGS/l7ZMKkO7buAn1RlQaI1gt8ub4UnTKf5XDNJu4Oc/UR/iEHjHWHC2W4 p2Fw== X-Gm-Message-State: ABuFfog0PvXR+FaWPQeGTNQxqcxcegbI5JWpDr/kN8EVzNu+wQ04iT4Z 17UXiCKqQ9KA7QQ3aWslejxTw+1uuLuhhDHmTV+Dng== X-Google-Smtp-Source: ACcGV63Pu0rKRb8eJEmtJbQR5N0n1tsFOabBlsiJCRAItkRDiRMQNgCzWgskUJexO6emPLDvcSB1gxQQ6Kc1AQQiJIE= X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr4863029lja.21.1538665485651; Thu, 04 Oct 2018 08:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 4 Oct 2018 08:04:44 -0700 (PDT) In-Reply-To: <20181004.154448.1934765954209842070.mbj@tail-f.com> References: <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <20181004.154448.1934765954209842070.mbj@tail-f.com> From: Andy Bierman Date: Thu, 4 Oct 2018 08:04:44 -0700 Message-ID: To: Martin Bjorklund Cc: Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="000000000000b384410577687992" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:04:57 -0000 --000000000000b384410577687992 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 4, 2018 at 6:44 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > > > > > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > >> On 04/10/2018 11:14, Martin Bjorklund wrote: > > >>> Phil Shafer wrote: > > >>>> Bal?zs Lengyel writes: > > >>>>> https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > >>>> [I've moved to a "deep lurker" role here, but ...] > > >>>> > > >>>> Can we ensure this model contains a "format" leaf in the RPC's input > > >>>> so that future (and proprietary) formats can be supported? That > > >>>> leaf can be an identityref that defaults to yang-patch. > > >>> I think this is a good idea. I would prefer the edit-config format > > >>> over YANG patch for describing a diff. The edit-config format is > more > > >>> suited for this purpose imo. > > >> +1 > > >> > > >> I would like something closer to edit-config to be available via > > >> RESTCONF as well. > > > YANG Patch is IMO better because it clearly separates the target for > > > the edits > > > from the new content. > > > > > In edit-config these two are mixed together. > > Yes, that is primarily why I prefer the edit-config. I perceive that > > it is a denser and more efficient format. I think that it is both > > easier to construct (when diffing two trees) and also more efficient > > to apply when generating an updated tree. > > I agree, this is why I prefer this format for general diffs. > > If the filter input is a complex XPath expression, the result could be a node-set that has data from all over the tree. Reproducing the "path from root" is an implementation detail that is probably complex whether it is a reconstructed XPath expression or a reconstructed subtree. I don't like using identityrefs because the conformance for them is so poorly defined in YANG. e.g. identity compare-format; identity yang-patch { base compare-format; } identity my-yang-patch1 { base compare-format; } identity my-yang-patch2 { base yang-patch; } ... leaf filter-format { type identityref { base compare-format; } } It is IMPOSSIBLE in machine-readable YANG to say that identity "yang-patch" is mandatory to support for leaf "filter-format". In plain YANG any of these identities is valid. It is IMPOSSIBLE to say in machine-readable YANG that a client that understands "yang-patch" will work with a server that supports only "my-yang-patch2". Of course there is no way to discover which identities are supported on a server for a given identityref leaf. > /martin > Andy > > > > > Thanks, > > Rob > > > > > > > > > > That being said, I support specifying format/media-type and having > > > potentially > > > multiple options. > > > > > > Lada > > > > > >> Thanks, > > >> Rob > > >> > > >> > > >>> /martin > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> . > > >>> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000b384410577687992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 4, 2018 at 6:44 AM, Marti= n Bjorklund <mbj@tail-f.com> wrote:
Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 04/10/2018 13:51, Ladislav Lhotka wrote:
> > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote:
> >> On 04/10/2018 11:14, Martin Bjorklund wrote:
> >>> Phil Shafer <phil@= juniper.net> wrote:
> >>>> Bal?zs Lengyel writes:
> >>>>> https://tools.i= etf.org/html/draft-clemm-netmod-nmda-diff-00
> >>>> [I've moved to a "deep lurker" role her= e, but ...]
> >>>>
> >>>> Can we ensure this model contains a "format"= ; leaf in the RPC's input
> >>>> so that future (and proprietary) formats can be suppo= rted?=C2=A0 =C2=A0That
> >>>> leaf can be an identityref that defaults to yang-patc= h.
> >>> I think this is a good idea.=C2=A0 I would prefer the edi= t-config format
> >>> over YANG patch for describing a diff.=C2=A0 The edit-con= fig format is more
> >>> suited for this purpose imo.
> >> +1
> >>
> >> I would like something closer to edit-config to be available = via
> >> RESTCONF as well.
> > YANG Patch is IMO better because it clearly separates the target = for
> > the edits
> > from the new content.
>
> > In edit-config these two are mixed together.
> Yes, that is primarily why I prefer the edit-config.=C2=A0 I perceive = that
> it is a denser and more efficient format.=C2=A0 I think that it is bot= h
> easier to construct (when diffing two trees) and also more efficient > to apply when generating an updated tree.

I agree, this is why I prefer this format for general diffs.



If the filter input is = a complex XPath expression, the result could be a node-set that has
data from all over the tree.=C2=A0 Reproducing the "path from root&= quot; is an implementation
detail that is probably complex whethe= r it is a reconstructed XPath expression
or a reconstructed subtr= ee.

<tangent>
I don't like usi= ng identityrefs because the conformance for them is so poorly defined in YA= NG.

e.g.


i= dentity compare-format;

identity yang-patch {
=C2=A0 base compare-format;
}

identity my-yang-patch1 {
=C2=A0 base compare-format;
= }

identity my-yang-patch2 {
<= div>=C2=A0 base yang-patch;
}

...

leaf filter-format {
=C2=A0 type i= dentityref {
=C2=A0 =C2=A0 =C2=A0base compare-format;
= =C2=A0 }
}

It is IMPOSSIBLE in machine-r= eadable YANG to say that identity "yang-patch"
is manda= tory to support for leaf "filter-format". In plain YANG any of th= ese
identities is valid.

It is IMPOSSIBL= E to say in =C2=A0machine-readable YANG that a client that understands &quo= t;yang-patch"
will work with a server that supports only &qu= ot;my-yang-patch2".

Of course there is no way= to discover which identities are supported on a server for
a giv= en identityref leaf.
</tangent>




/martin


Andy
= =C2=A0

>
> Thanks,
> Rob
>
>
> >
> > That being said, I support specifying format/media-type and havin= g
> > potentially
> > multiple options.
> >
> > Lada
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >>> /martin
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/list= info/netmod
> >>> .
> >>>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinf= o/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--000000000000b384410577687992-- From nobody Thu Oct 4 10:10:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1005130E78 for ; Thu, 4 Oct 2018 10:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 foDfuLYBB1rE for ; Thu, 4 Oct 2018 10:10:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 9BA31130DD3 for ; Thu, 4 Oct 2018 10:10:44 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id E4E97629F5; Thu, 4 Oct 2018 19:10:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1538673042; bh=ucPvufI8EUWPms5VoK7axhYAQRHv8QpitfBYeV0qetg=; h=From:To:Date; b=AZ/tO+DQqWBirJB2k7SHesl87VQY+XmV0lHDom31PbxUZ8CQ5deV7dLYbebjvlWZe hzo3m3GOtYQBfGHHNrmn5Ri+7O8+/TJuxehvXXAc/tFOY8goID3Z53VEjvSYHiLP8P sLNiAvcv98hNajhceM0xjMAMFx0Yvbwz6ZcS2V+w= Message-ID: <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , netmod@ietf.org Date: Thu, 04 Oct 2018 19:10:41 +0200 In-Reply-To: References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:10:48 -0000 On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > > > Phil Shafer wrote: > > > > > Bal?zs Lengyel writes: > > > > > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > > > > [I've moved to a "deep lurker" role here, but ...] > > > > > > > > > > Can we ensure this model contains a "format" leaf in the RPC's input > > > > > so that future (and proprietary) formats can be supported? That > > > > > leaf can be an identityref that defaults to yang-patch. > > > > I think this is a good idea. I would prefer the edit-config format > > > > over YANG patch for describing a diff. The edit-config format is more > > > > suited for this purpose imo. > > > +1 > > > > > > I would like something closer to edit-config to be available via > > > RESTCONF as well. > > YANG Patch is IMO better because it clearly separates the target for the > > edits > > from the new content. > > In edit-config these two are mixed together. > Yes, that is primarily why I prefer the edit-config. I perceive that it > is a denser and more efficient format. I think that it is both easier > to construct (when diffing two trees) and also more efficient to apply > when generating an updated tree. Except for certain corner cases, for example if two trees differ only in the value of a single leaf but this leaf happens to be a list key. Lada > > Thanks, > Rob > > > > That being said, I support specifying format/media-type and having > > potentially > > multiple options. > > > > Lada > > > > > Thanks, > > > Rob > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > . > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Oct 4 10:26:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5152130D7A for ; Thu, 4 Oct 2018 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.196 X-Spam-Level: *** X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 xe6PupUIvqJn for ; Thu, 4 Oct 2018 10:26:21 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40138.outbound.protection.outlook.com [40.107.4.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5793130E78 for ; Thu, 4 Oct 2018 10:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hpFJs7tMp7oogBkQPkQAorrzEqAPXqbpWVFLKg8byA0=; b=fTIBsdQpkz6Wv2gnjM4b0HauSAbxcuWQpy+q4XlskrDmsNiM84ZCj1edtPRjK0r5n3qn3S44zxUhspZlL7MmOdXt6P1A5X84TKGsFJgaJ0Fn5MXfRoJoKWVkN5R3fSjylupobDH0DtlccQaGL5PFYQP8vnC3Fy0TAbval67Vhlc= Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB1614.eurprd07.prod.outlook.com (10.166.142.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.13; Thu, 4 Oct 2018 17:26:18 +0000 Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1207.022; Thu, 4 Oct 2018 17:26:18 +0000 From: tom petch To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Quirky YANG Thread-Index: AQHUWzOsol/7t5B5P0eLl3TYYanwGA== Date: Thu, 4 Oct 2018 17:26:17 +0000 Message-ID: <016f01d45c07$428c3b80$4001a8c0@gateway.2wire.net> References: <008701d45b33$942501e0$4001a8c0@gateway.2wire.net> <20181003164329.uutqv3gbzhomc5hh@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0077.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::17) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.131.229.47] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1614; 6:DjEf4IunGIOoc1uxT8mWo472MWURuliyEFZWM04Z1pyKDJtstQderEekYciovLdnjRMWzCsHy0uPkbTzf4nXPzzp4r8wR8jooHugAQjrXuNiPozMSxcB/Wh0bXQdlu6Ktcq1poCMYigrHZwsaFIqt3Zur3MSP/Nh3q/EYgAFYd0aL8GWpH87F5csUxy5hjfM9TYZE1egKszZT/d/bpWrWTAMoWUE+Zn1OthZkMI1GupPXoyp59Ey1g2psLJWtFgHfKf9N9I2HQkwbnB7g/ZB/2SiBfbJXYco/sTB7bAL9EaWJEFfS2+BqWn/JSYKXgabx4VzCOOpx4kyUnBiu+2trNivoLI0HA/HRSkBySvYh2zyNF897D5APxqEhO6IkI/m1s1dwcxvUnazoDkYmt3cF81f9EGdQuNVmz3xEEPXNmyK2Wjx3AA8Nq0zJY9cePMhat/2HkdUR7na0tdcjFrXlw==; 5:uy5zJ9EDdzBQbownEtCHoHCpjzCmdlekcw5PFyERQ7TAGC5/+mQI1lP1sMgobxBwdiLXNUzX2CDb7M2kSzRUBSA7zdgdwastBGr41f31k17aku0JDUHkGn/apXFLC3bfwY7wYuLN577/AlvU/ecCPPhZj2jrxJdtY9zzYO1nBlI=; 7:WhPmL6XUtr3JcgnXBckzO7mIoa8zLXxGlDk3gqWiHZySjEXfCuD9Vt0RPfgJj7T7HiHLw/jRwsWKv76XCj0T4swtHCa7U/rHmRWBL1PBxX9pfoQG0Uwv9t6Tp6V6ieik1vGUj+jO4T1vVtJaXKwHIIbqC34uSpGgKXQ6bxpgLIOsqf2KJ8MVsjBJTc0sWFw2dg2UOPPLT6NbNEe5dHUDKq/qvsl8+ioJjCQmu5ODjvqRNrtXe3Inczx7EJTZFn1n x-ms-office365-filtering-correlation-id: 9a4fe1dc-1883-4572-39b9-08d62a1e7e32 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB1614; x-ms-traffictypediagnostic: VI1PR07MB1614: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(201708071742011)(7699051); SRVR:VI1PR07MB1614; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1614; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(136003)(376002)(39860400002)(189003)(199004)(54094003)(13464003)(5250100002)(229853002)(6486002)(6306002)(478600001)(6246003)(6512007)(86152003)(84392002)(9686003)(386003)(102836004)(53936002)(6506007)(44736005)(966005)(76176011)(256004)(5660300001)(97736004)(52116002)(33896004)(6436002)(6916009)(105586002)(14496001)(106356001)(8936002)(2906002)(68736007)(3846002)(8676002)(26005)(86362001)(316002)(66066001)(446003)(99286004)(476003)(486006)(4326008)(71200400001)(71190400001)(81166006)(186003)(1556002)(2900100001)(81156014)(7736002)(14454004)(6116002)(305945005)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1614; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tbOl4h0cbMwHAVU80OF884fs/jibK2EpgYRSt9cfEYuPjENlMFfjnUHs+8qp9ma3EBi4KcVeB/56obavG+omEYdbyjYP7Wf2l7/lm64Cl6uwhT2D/lwvSa6gc7Cb29jQViCZoWZUQahOI8S2AGD1fL3FTPt2YnZKiL6UZTWB5XcypVWrW7pwaH9lm3lmyVz3/t6uZM2RHgjYv/mZFWauEaWHURfPHiaNEB/xm3MyH+8vmxjI9TzRlrBe4V2bcJWCfzu3fb3S0bpIE7kBFTq1yd5sFLbmIixq++d9QairRj3lmTBGKiK3HO1BwrCF5u2clv2uNXiMjPx8BStWiYr789zqN8FA0VRgwKYvyvlH5wY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0150D799885EEF4198E23A943E3B97DD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a4fe1dc-1883-4572-39b9-08d62a1e7e32 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 17:26:17.9524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1614 Archived-At: Subject: Re: [netmod] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:26:24 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Wednesday, October 03, 2018 5:43 PM > Well, make sure you send your comments to softwire since they have to > sort this out. Indeed. The subtext to my query was that if this had had aYANG doctor review, which I assumed it would have had by now, then there was something I was misunderstanding about YANG identities and features, but perhaps it is my understanding of when YANG doctor reviews take place that I was missing:-) Tom Petch > > /js > > On Wed, Oct 03, 2018 at 04:11:13PM +0000, tom petch wrote: > > I wonder if anyone else on this list has looked at > > https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/ > > currently in IETF Last Call. > > > > It provides management for three tunnel types, Lw4o6, MAP-E and MAP-T > > betweeen CPE and Border Relay. It defines a CPE module, a BR module and > > a module of common definitions. > > > > It does not provide identities for the three tunnel types; rather, where > > it augments "/if:interfaces/if:interface" it specifies > > when "if:type =3D 'ianaift:tunnel'"; > > which to me says that a MAP-E (e.g.) specific object will get added to > > each and every tunnel of whatever type, which seems excessive. > > > > Second, it defines four features, softwire-ce:algorithm (i.e. > > MAP-E/MAP-T) and softwire-ce:binding (i.e. Lw4o6) in the CPE module and > > then again softwire-br:algorithm and softwire-br:binding in the BR > > module. It is unclear to me, from the I-D, whether support is for MAP-T > > and MAP-E; or either MAP-T or MAP-E - I find the I-D ambiguous on that > > point - but I would have expected there to be either two - Lw4o6 and > > MAP-ET - or three - Lw4o6, MAP-E and MAP-T features, not four; and for > > the features to be defined, along with tunnel identities, in the common > > module. > > > > Odd, IMHO. > > > > Tom Petch > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu Oct 4 10:41:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76EC130D7A for ; Thu, 4 Oct 2018 10:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NWFBW2aYMCo for ; Thu, 4 Oct 2018 10:41:27 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5A712F1A2 for ; Thu, 4 Oct 2018 10:41:26 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w94HYI7X017074; Thu, 4 Oct 2018 10:41:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Bk7bwmynBcL0cip2UO2eRnVLP++QTRvi1KLblS0j6Zg=; b=pk1FmhnjT6LTaSGJv6HHJaCmFwZwmx5ARXtbKwNrfbBiavZcOqy8Ap2Wxqd6uO8QIgau v4Z2iIuzn12PtEiEysPvwMC8xyeEOyTbliJp0eDncGXxMJd1eU/UIWvkKhw3KAp4bSlp JJwbYpkfDudSz8m1RWfNzcBnt5viEFphPibMs2BqjCb3zbx9zWkK3qdkygKdC9eJefYT 3yrz2/bIBK0OV3ueYyDQ9nfE4ggOVxVX1MsKsJiU2EEBzm4E89G55Y2rc1hXO+Plg+0/ djzxur/bjj1hJDKBmGCilcNGovaot6xG9YHZLlTwlo9Es3mQIoiTVUD4W1LPOSovgG9H Eg== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0056.outbound.protection.outlook.com [216.32.181.56]) by mx0b-00273201.pphosted.com with ESMTP id 2mwnhwr6x7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Oct 2018 10:41:24 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4411.namprd05.prod.outlook.com (20.176.78.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.11; Thu, 4 Oct 2018 17:41:22 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.022; Thu, 4 Oct 2018 17:41:23 +0000 From: Kent Watsen To: Ladislav Lhotka , Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyPz6FAZXxCAuEeMxCal0HeWUaUO37yAgAAnp4CAAARbAIAABz8AgABBFoD//8WNgA== Date: Thu, 4 Oct 2018 17:41:22 +0000 Message-ID: <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> In-Reply-To: <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4411; 6:9hAaHqMV7pZ45CA5elGCdRQdJWI2mvbiDKf+lbvjqzLGw/ueJbqNRg29H01KWeluw5Stn6JUTqFdZ0kC+/BwamFIIIBCiJLsVQqb0muzlDSikOQ95fAAV2BKD9PNF5UJBdvPDDRzA5MbXuQg3wKcv5oxc7pPXbx+bd7t0az94qzx1bTTXhASqW60Me4r8agU08WnRlCYk3uQsZgKEwoIAdMAjfHtGRvpIWkwnGeahptyV3OH5ntVJ3kSeQHTniSKKkn+dQuUXgQxCCBbc2mxDHNKvqMfffF8vwc3fi9PatJuzgFtdzoas14Xqd6U2+mRqRoepYC4tPXFMo5q3Bimmd15zJB63NKo2k4zyILWdwHaWLqNpgjNDI0vrKty/x1pwxsb63EPLDK8YyuuW1uWvyMfXg2Sy/7DkCs+dNbMwRU3dtViduCxBmD6cGI5uePxwne72T11mITnGhJjPgGgoA==; 5:n4G5IVV6Y+FB+PpleMJv9qOqd5/PCYptY739HyLL0yaU00YHuVdKRKwsvAABescpsDtZC5SVs8PxEIbkOHKBY8/obuZJuJihQjjUB7RkHhsCcaAuC9r3vtWA0vT7J0q8B4UWgomodfjoag8Z46yyj0KlguZfmUPLHaTSbsbK3TI=; 7:3j+CgdJiSh9R458+mjVpeGyuHMD7pWE0aVGaK9aFqfklR5h2ORAgkVdFOCy7rU+TTrKmxwEHOVjv7mt4ljSS/vOCnucbULN3g6x+AZbWy6Ztrl8ZCHFyOa0SxWNlCVX1LKzps2bZKAxmuRQNru3NpDpWjB7Xp0n8oN1BaPzt9e+Vv6Kd+BBxWd7YcCdUH1291FDvVnRQuKUqfrw8KFqq5U+SNu+9mbkVZK+e4Yha5Jcjlt7QnWclC5mkwedeaSwD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 284ec2e2-8759-4dc7-3c60-08d62a209a00 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4411; x-ms-traffictypediagnostic: DM6PR05MB4411: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(95692535739014)(138986009662008); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:DM6PR05MB4411; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4411; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(396003)(39860400002)(346002)(366004)(13464003)(51444003)(189003)(199004)(6512007)(6306002)(106356001)(110136005)(8676002)(8936002)(6246003)(256004)(66066001)(105586002)(36756003)(99286004)(229853002)(5250100002)(68736007)(53936002)(58126008)(97736004)(966005)(2900100001)(81166006)(3846002)(81156014)(6116002)(316002)(76176011)(53546011)(575784001)(2501003)(476003)(5660300001)(486006)(186003)(102836004)(478600001)(82746002)(114624004)(6506007)(71190400001)(25786009)(7736002)(6486002)(2906002)(14454004)(446003)(86362001)(26005)(83716004)(71200400001)(305945005)(2616005)(6436002)(93886005)(11346002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4411; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: Wrf3dsadTw00MEIS7e+9K9mkjxyqDC0BUxF7XGatxhHG9QJGuHCuYCw4Oi6GvR8SzKNYhsGBd9IdtwnC3RoZ6Dsye6KHFy+xhsyx4cWsDx7wfs8GsHRx6EZUtEP/zFdtosSA0RWBHK+GRaVRDmpMEfEA1PtetnA+ywjgbKMlSn8j1E7SvHgqwK//oiUgbbf47DIsdsiSuL3YvPiFTy9XnLMaaeGf0XxS5Z6WTVguWwhb16prBwXGJ7lcpscFCaIR/pdG3TRJrQuifFRE5PR5PIOa0+ZtHjnLt4gKvXF5FGNYxKCB3848xSvmi2vVvmP1uFj8lAE+1qGH7FPhGdNUmNfo6ieiU27GEZriq2jWK6Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2A109B3CEDAD0B499AC425A500D2F017@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 284ec2e2-8759-4dc7-3c60-08d62a209a00 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 17:41:22.9279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4411 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810040162 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:41:30 -0000 V2UgYWdyZWUgdGhhdCB0aGUgZGlmZi1mb3JtYXQgc2hvdWxkIGJlIGNsaWVudC1zZWxlY3RhYmxl LCBtb2R1bG8gd2hhdCB0aGUgc2VydmVyIHN1cHBvcnRzLiAgeWFuZy1wYXRjaCBhbmQgZWRpdC1j b25maWcgYm90aCBhcmUgdmlhYmxlLiAgU2hvdWxkIHdlIGRvY3VtZW50IHRoZW0gYm90aD8NCg0K VGhhdCBzYWlkLCBzaW5jZSBuZWl0aGVyIGVkaXQtY29uZmlnIG5vciB5YW5nLXBhdGNoIGFyZSBk aWZmaW5nIGZvcm1hdHMsIHNvIG11Y2ggYXMgZm9ybWF0cyBmb3IgY29udmVydGluZyBvbmUgZGF0 YSB0cmVlIHRvIGFub3RoZXIsIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gZGVmaW5lIGFuIGFjdHVh bCBkaWZmaW5nIGZvcm1hdD8gIEkgd291bGQgdGhpbmsgdGhhdCBhIGRpZmYgd291bGQgcHJvdmlk ZSBib3RoIHZhbHVlcywgbm90IGp1c3QgYSBuZXcgdmFsdWUuDQoNCktlbnQgLy8gY29udHJpYnV0 b3INCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4NCk9yZ2FuaXphdGlvbjogQ1ouTklDDQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciA0 LCAyMDE4IGF0IDE6MTEgUE0NClRvOiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4s ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1v ZF0gV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0K DQpPbiBUaHUsIDIwMTgtMTAtMDQgYXQgMTQ6MTcgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6 DQo+IA0KPiBPbiAwNC8xMC8yMDE4IDEzOjUxLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4g T24gVGh1LCAyMDE4LTEwLTA0IGF0IDEzOjM2ICswMTAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0K PiA+ID4gT24gMDQvMTAvMjAxOCAxMToxNCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiA+ ID4gUGhpbCBTaGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ID4gPiA+IEJhbD96 cyBMZW5neWVsIHdyaXRlczoNCj4gPiA+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGNs ZW1tLTJEbmV0bW9kLTJEbm1kYS0yRGRpZmYtMkQwMCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2 U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y Z3NCWWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0ky S0RFTjk3YyZzPWdRV0p0amNfMkVGM1FnUnZBQmdaS3NqcXp1SXc5eVVxX3hlZTZhRkpPY3cmZT0N Cj4gPiA+ID4gPiBbSSd2ZSBtb3ZlZCB0byBhICJkZWVwIGx1cmtlciIgcm9sZSBoZXJlLCBidXQg Li4uXQ0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IENhbiB3ZSBlbnN1cmUgdGhpcyBtb2RlbCBjb250 YWlucyBhICJmb3JtYXQiIGxlYWYgaW4gdGhlIFJQQydzIGlucHV0DQo+ID4gPiA+ID4gc28gdGhh dCBmdXR1cmUgKGFuZCBwcm9wcmlldGFyeSkgZm9ybWF0cyBjYW4gYmUgc3VwcG9ydGVkPyAgIFRo YXQNCj4gPiA+ID4gPiBsZWFmIGNhbiBiZSBhbiBpZGVudGl0eXJlZiB0aGF0IGRlZmF1bHRzIHRv IHlhbmctcGF0Y2guDQo+ID4gPiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYS4gIEkgd291 bGQgcHJlZmVyIHRoZSBlZGl0LWNvbmZpZyBmb3JtYXQNCj4gPiA+ID4gb3ZlciBZQU5HIHBhdGNo IGZvciBkZXNjcmliaW5nIGEgZGlmZi4gIFRoZSBlZGl0LWNvbmZpZyBmb3JtYXQgaXMgbW9yZQ0K PiA+ID4gPiBzdWl0ZWQgZm9yIHRoaXMgcHVycG9zZSBpbW8uDQo+ID4gPiArMQ0KPiA+ID4gDQo+ ID4gPiBJIHdvdWxkIGxpa2Ugc29tZXRoaW5nIGNsb3NlciB0byBlZGl0LWNvbmZpZyB0byBiZSBh dmFpbGFibGUgdmlhDQo+ID4gPiBSRVNUQ09ORiBhcyB3ZWxsLg0KPiA+IFlBTkcgUGF0Y2ggaXMg SU1PIGJldHRlciBiZWNhdXNlIGl0IGNsZWFybHkgc2VwYXJhdGVzIHRoZSB0YXJnZXQgZm9yIHRo ZQ0KPiA+IGVkaXRzDQo+ID4gZnJvbSB0aGUgbmV3IGNvbnRlbnQuDQo+ID4gSW4gZWRpdC1jb25m aWcgdGhlc2UgdHdvIGFyZSBtaXhlZCB0b2dldGhlci4NCj4gWWVzLCB0aGF0IGlzIHByaW1hcmls eSB3aHkgSSBwcmVmZXIgdGhlIGVkaXQtY29uZmlnLiAgSSBwZXJjZWl2ZSB0aGF0IGl0IA0KPiBp cyBhIGRlbnNlciBhbmQgbW9yZSBlZmZpY2llbnQgZm9ybWF0LiAgSSB0aGluayB0aGF0IGl0IGlz IGJvdGggZWFzaWVyIA0KPiB0byBjb25zdHJ1Y3QgKHdoZW4gZGlmZmluZyB0d28gdHJlZXMpIGFu ZCBhbHNvIG1vcmUgZWZmaWNpZW50IHRvIGFwcGx5IA0KPiB3aGVuIGdlbmVyYXRpbmcgYW4gdXBk YXRlZCB0cmVlLg0KDQpFeGNlcHQgZm9yIGNlcnRhaW4gY29ybmVyIGNhc2VzLCBmb3IgZXhhbXBs ZSBpZiB0d28gdHJlZXMgZGlmZmVyIG9ubHkgaW4gdGhlDQp2YWx1ZSBvZiBhIHNpbmdsZSBsZWFm IGJ1dCB0aGlzIGxlYWYgaGFwcGVucyB0byBiZSBhIGxpc3Qga2V5Lg0KDQpMYWRhDQoNCj4gDQo+ IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4gPiBUaGF0IGJlaW5nIHNhaWQsIEkgc3VwcG9ydCBz cGVjaWZ5aW5nIGZvcm1hdC9tZWRpYS10eXBlIGFuZCBoYXZpbmcNCj4gPiBwb3RlbnRpYWxseQ0K PiA+IG11bHRpcGxlIG9wdGlvbnMuDQo+ID4gDQo+ID4gTGFkYQ0KPiA+IA0KPiA+ID4gVGhhbmtz LA0KPiA+ID4gUm9iDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gPiAvbWFydGluDQo+ID4gPiA+IA0K PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZU dDhrX0kyS0RFTjk3YyZzPVJWSmNnNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I5bl9B UFEmZT0NCj4gPiA+ID4gLg0KPiA+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4g PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9k JmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03czZWZHp6SDlP bDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9UlZKY2c1cHpIVy16aTFPYm9DTDRT WDJodVc5ZXVIaVZSU0NvcjluX0FQUSZlPQ0KLS0gDQpMYWRpc2xhdiBMaG90a2ENCkhlYWQsIENa Lk5JQyBMYWJzDQpQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QN Cm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lD QWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4 bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTdzNlZkenpIOU9sM0JPQ2JW TEJhckJyUTVmRDB2VHQ4a19JMktERU45N2Mmcz1SVkpjZzVwekhXLXppMU9ib0NMNFNYMmh1Vzll dUhpVlJTQ29yOW5fQVBRJmU9DQoNCg== From nobody Thu Oct 4 12:03:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA176128CF3 for ; Thu, 4 Oct 2018 12:03:56 -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 XesEPzwVRQmK for ; Thu, 4 Oct 2018 12:03:54 -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 F11DC1274D0 for ; Thu, 4 Oct 2018 12:03:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C33413D; Thu, 4 Oct 2018 21:03:50 +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 4lE4Y_THUfKL; Thu, 4 Oct 2018 21:03:49 +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; Thu, 4 Oct 2018 21:03:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 853972003B; Thu, 4 Oct 2018 21:03:50 +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 BwFb85BKA_5Q; Thu, 4 Oct 2018 21:03:50 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 37DF32003A; Thu, 4 Oct 2018 21:03:50 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Thu, 4 Oct 2018 21:03:49 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 915443000CFB71; Thu, 4 Oct 2018 21:03:49 +0200 (CEST) Date: Thu, 4 Oct 2018 21:03:49 +0200 From: Juergen Schoenwaelder To: tom petch CC: "netmod@ietf.org" Message-ID: <20181004190349.qayudrxn274ycipy@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , "netmod@ietf.org" References: <008701d45b33$942501e0$4001a8c0@gateway.2wire.net> <20181003164329.uutqv3gbzhomc5hh@anna.jacobs.jacobs-university.de> <016f01d45c07$428c3b80$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <016f01d45c07$428c3b80$4001a8c0@gateway.2wire.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:03:57 -0000 On Thu, Oct 04, 2018 at 05:26:17PM +0000, tom petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > Sent: Wednesday, October 03, 2018 5:43 PM > > > Well, make sure you send your comments to softwire since they have to > > sort this out. > > Indeed. > > The subtext to my query was that if this had had aYANG doctor review, > which I assumed it would have had by now, then there was something I was > misunderstanding about YANG identities and features, but perhaps it is > my understanding of when YANG doctor reviews take place that I was > missing:-) > Just to be clear: YANG doctors won't catch everything and hence YANG doctor reviews complement other reviews, they do not replace the need for other people's reviews. In particular, YANG doctors usually do not understand what is being modeled. Getting the semantics of lets say identities right remains the job of the working group. And the working group is ultimately responsible for what it produces. /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 Thu Oct 4 12:08:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A5127B92 for ; Thu, 4 Oct 2018 12:08:01 -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 PRItK6JCjHg0 for ; Thu, 4 Oct 2018 12:07:58 -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 80A42127AC2 for ; Thu, 4 Oct 2018 12:07:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 027D6B31; Thu, 4 Oct 2018 21:07:57 +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 MhPxL1d-4A4m; Thu, 4 Oct 2018 21:07:55 +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; Thu, 4 Oct 2018 21:07:56 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B983D20037; Thu, 4 Oct 2018 21:07:56 +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 w2qpV0InVFoW; Thu, 4 Oct 2018 21:07:56 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F1CAD20036; Thu, 4 Oct 2018 21:07:55 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Thu, 4 Oct 2018 21:07:55 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 5ACA23000CFC21; Thu, 4 Oct 2018 21:07:54 +0200 (CEST) Date: Thu, 4 Oct 2018 21:07:54 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: "netmod@ietf.org" Message-ID: <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> 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: <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:08:01 -0000 Folks, the more formats there are, the less interoperability we get. If there are multiple formats, is there a mandatory to implement format? Does the mandatory to implement format depend on the protocol that is being used? I prefer one format or if necessary I am fine with one mandatory to implement format. An open ended collection of implementation specific formats is super flexible but defeats the purpose of a standard, namely interoperability. /js On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: > We agree that the diff-format should be client-selectable, modulo what the server supports. yang-patch and edit-config both are viable. Should we document them both? > > That said, since neither edit-config nor yang-patch are diffing formats, so much as formats for converting one data tree to another, would it make sense to define an actual diffing format? I would think that a diff would provide both values, not just a new value. > > Kent // contributor > > > -----Original Message----- > From: netmod on behalf of Ladislav Lhotka > Organization: CZ.NIC > Date: Thursday, October 4, 2018 at 1:11 PM > To: Robert Wilton , "netmod@ietf.org" > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 > > On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > > > > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > > > > Phil Shafer wrote: > > > > > > Bal?zs Lengyel writes: > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e= > > > > > > [I've moved to a "deep lurker" role here, but ...] > > > > > > > > > > > > Can we ensure this model contains a "format" leaf in the RPC's input > > > > > > so that future (and proprietary) formats can be supported? That > > > > > > leaf can be an identityref that defaults to yang-patch. > > > > > I think this is a good idea. I would prefer the edit-config format > > > > > over YANG patch for describing a diff. The edit-config format is more > > > > > suited for this purpose imo. > > > > +1 > > > > > > > > I would like something closer to edit-config to be available via > > > > RESTCONF as well. > > > YANG Patch is IMO better because it clearly separates the target for the > > > edits > > > from the new content. > > > In edit-config these two are mixed together. > > Yes, that is primarily why I prefer the edit-config. I perceive that it > > is a denser and more efficient format. I think that it is both easier > > to construct (when diffing two trees) and also more efficient to apply > > when generating an updated tree. > > Except for certain corner cases, for example if two trees differ only in the > value of a single leaf but this leaf happens to be a list key. > > Lada > > > > > Thanks, > > Rob > > > > > > > That being said, I support specifying format/media-type and having > > > potentially > > > multiple options. > > > > > > Lada > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= > > > > > . > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Oct 4 12:27:32 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1EF128CF3 for ; Thu, 4 Oct 2018 12:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 VJ5h_fzba7uE for ; Thu, 4 Oct 2018 12:27:28 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 189761277BB for ; Thu, 4 Oct 2018 12:27:28 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id u21-v6so9425995lja.8 for ; Thu, 04 Oct 2018 12:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rvx/fvV8RLPlSVUnjW3R9dYNSL1FrqnN6q/8o2MLE7I=; b=rVcDZMSjVJnhPl85vYrS2WzOJzbL9UYrr9BpBjY8v1AUOrjD5Vs1C5vp0snLUVt9fk 4Z20i1PODYZTrdjJwlTuCeXrDK1f7px+efngdBFYyPU6qmgD6IGi23/tE/qRe4HNEaJf 2kO/+S+S9ankdByxzURw2BUBpplmFs8+ZjSqUHj1VzfrdGf2AZGS/l8HnVkR7TzS2Ix3 7A9SAC3mhNeatjQQ92qsSp9/IhN7hO2ZGswLU+WSsCTyiAk5dflwnjDV6SStT2Yvtyyj Gy3HcN51isqz9zW4rQGD9mrprV/FDJluWsD9xf4QpvQ0Uw0NZAJwiVh/+Pr+L4XHDg46 a/eA== 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=rvx/fvV8RLPlSVUnjW3R9dYNSL1FrqnN6q/8o2MLE7I=; b=VcW1SZTIc1taCDm2bPzb/URZAcNmdYijm9lENpos/xWoArt8VuO6HCcmPfNT2pAb8K /IxjGIwtlYADiIHp0R3eLn+306Yv1gaue3ct7A7hfHEm28MYvC5hfkTpr5pahtfF2izZ NRyRxOCIdfEVI8LuMSnJU4T33hB66LO+aC1d2xbJHb46m8IKN3npwRFAOdUamg+M9KtA bzNKsBci8N7cd+/wiCCrGTmsTuPKv6AXK+NrDQ2fFMGC33Da0TVCKoQLcDqvnL4iwONc P4chLtEBzQ86LGq/ds2akA1YpiqiK8j7tJNuHnBzQuanrwZZ2nflIKZXAxx7cnQLLyYt dwag== X-Gm-Message-State: ABuFfoiRWZReHbh82Zl435fUGG5eSb/nsCS5Vain4ju0dHGBJIXDzvEa 0kpJrH9Pn8/ZEEQLO6zBkO6mIZ7MDB/ZrB78cbLw1rWQ X-Google-Smtp-Source: ACcGV61SCF0WT9pG1vCfJ6UyKlK90PA+rkbDpBTljX5W2bRw6jJoGRKfOXYzR0bZBamJv2gFUc4LIudQoCORuIBUGRM= X-Received: by 2002:a2e:810e:: with SMTP id d14-v6mr5067147ljg.170.1538681246048; Thu, 04 Oct 2018 12:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 4 Oct 2018 12:27:25 -0700 (PDT) In-Reply-To: <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Thu, 4 Oct 2018 12:27:25 -0700 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000017f77005776c25f4" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 19:27:32 -0000 --00000000000017f77005776c25f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Folks, the more formats there are, the less interoperability we > get. If there are multiple formats, is there a mandatory to implement > format? Does the mandatory to implement format depend on the protocol > that is being used? > > I prefer one format or if necessary I am fine with one mandatory to > implement format. An open ended collection of implementation specific > formats is super flexible but defeats the purpose of a standard, > namely interoperability. > > I agree there needs to be 1 mandatory-to-implement format. IMO this needs to be YANG Patch because it is more precise then constructing an XML tree with operation attributes in it (e.g., how else do you represent a delete or a move?) Also, YANG Push is using YANG Patch format and common code for push and diff would be possible. I think other formats should be allowed. This is very tool-specific. I could see how somebody might want a textual patch of the XML representation to produce the new XML representation. > /js > Andy > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: > > We agree that the diff-format should be client-selectable, modulo what > the server supports. yang-patch and edit-config both are viable. Should > we document them both? > > > > That said, since neither edit-config nor yang-patch are diffing formats= , > so much as formats for converting one data tree to another, would it make > sense to define an actual diffing format? I would think that a diff woul= d > provide both values, not just a new value. > > > > Kent // contributor > > > > > > =EF=BB=BF-----Original Message----- > > From: netmod on behalf of Ladislav Lhotka < > lhotka@nic.cz> > > Organization: CZ.NIC > > Date: Thursday, October 4, 2018 at 1:11 PM > > To: Robert Wilton , "netmod@ietf.org" < > netmod@ietf.org> > > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff= -0 > 0 > > > > On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > > > > > > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > > > > > Phil Shafer wrote: > > > > > > > Bal?zs Lengyel writes: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tool= s.i > etf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwI > CAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJ > UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarB > rQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e= =3D > > > > > > > [I've moved to a "deep lurker" role here, but ...] > > > > > > > > > > > > > > Can we ensure this model contains a "format" leaf in the RPC'= s > input > > > > > > > so that future (and proprietary) formats can be supported? > That > > > > > > > leaf can be an identityref that defaults to yang-patch. > > > > > > I think this is a good idea. I would prefer the edit-config > format > > > > > > over YANG patch for describing a diff. The edit-config format > is more > > > > > > suited for this purpose imo. > > > > > +1 > > > > > > > > > > I would like something closer to edit-config to be available via > > > > > RESTCONF as well. > > > > YANG Patch is IMO better because it clearly separates the target fo= r > the > > > > edits > > > > from the new content. > > > > In edit-config these two are mixed together. > > > Yes, that is primarily why I prefer the edit-config. I perceive that > it > > > is a denser and more efficient format. I think that it is both easie= r > > > to construct (when diffing two trees) and also more efficient to appl= y > > > when generating an updated tree. > > > > Except for certain corner cases, for example if two trees differ only i= n > the > > value of a single leaf but this leaf happens to be a list key. > > > > Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > > > That being said, I support specifying format/media-type and having > > > > potentially > > > > multiple options. > > > > > > > > Lada > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet > f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh > 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv > jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D > RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > > > > . > > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet > f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh > 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv > jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D > RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet > f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh > 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv > jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D > RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000017f77005776c25f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Folks, the more formats there are, the less int= eroperability we
get. If there are multiple formats, is there a mandatory to implement
format? Does the mandatory to implement format depend on the protocol
that is being used?

I prefer one format or if necessary I am fine with one mandatory to
implement format. An open ended collection of implementation specific
formats is super flexible but defeats the purpose of a standard,
namely interoperability.


I agree there needs to be 1 mandatory-= to-implement format.

IMO this needs to be YANG Pat= ch because it is more precise then constructing an XML tree with
= operation attributes in it (e.g., how else do you represent a delete or a m= ove?)
Also, YANG Push is using YANG Patch format and common code = for push and diff would be
possible.

I t= hink other formats should be allowed.
This is very tool-specific.= I could see how somebody might want
a textual patch of the XML r= epresentation to produce the new XML representation.

=C2=A0
/js

Andy
=C2=A0

On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote:
> We agree that the diff-format should be client-selectable, modulo what= the server supports.=C2=A0 yang-patch and edit-config both are viable.=C2= =A0 Should we document them both?
>
> That said, since neither edit-config nor yang-patch are diffing format= s, so much as formats for converting one data tree to another, would it mak= e sense to define an actual diffing format?=C2=A0 I would think that a diff= would provide both values, not just a new value.
>
> Kent // contributor
>
>
> =EF=BB=BF-----Original Message-----
> From: netmod <netmod-bounces@ietf.org> on behalf of Ladislav Lhotka <lhotka@nic.cz>
> Organization: CZ.NIC
> Date: Thursday, October 4, 2018 at 1:11 PM
> To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-dif= f-00
>
> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote:
> >
> > On 04/10/2018 13:51, Ladislav Lhotka wrote:
> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote:
> > > > On 04/10/2018 11:14, Martin Bjorklund wrote:
> > > > > Phil Shafer <phil@juniper.net> wrote:
> > > > > > Bal?zs Lengyel writes:
> > > > > > > https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2= Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwICAg&c=3DHAkYuh6= 3rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7= Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k= _I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&am= p;e=3D
> > > > > > [I've moved to a "deep lurker" = role here, but ...]
> > > > > >
> > > > > > Can we ensure this model contains a "for= mat" leaf in the RPC's input
> > > > > > so that future (and proprietary) formats can = be supported?=C2=A0 =C2=A0That
> > > > > > leaf can be an identityref that defaults to y= ang-patch.
> > > > > I think this is a good idea.=C2=A0 I would prefer = the edit-config format
> > > > > over YANG patch for describing a diff.=C2=A0 The e= dit-config format is more
> > > > > suited for this purpose imo.
> > > > +1
> > > >
> > > > I would like something closer to edit-config to be avai= lable via
> > > > RESTCONF as well.
> > > YANG Patch is IMO better because it clearly separates the ta= rget for the
> > > edits
> > > from the new content.
> > > In edit-config these two are mixed together.
> > Yes, that is primarily why I prefer the edit-config.=C2=A0 I perc= eive that it
> > is a denser and more efficient format.=C2=A0 I think that it is b= oth easier
> > to construct (when diffing two trees) and also more efficient to = apply
> > when generating an updated tree.
>
> Except for certain corner cases, for example if two trees differ only = in the
> value of a single leaf but this leaf happens to be a list key.
>
> Lada
>
> >
> > Thanks,
> > Rob
> >
> >
> > > That being said, I support specifying format/media-type and = having
> > > potentially
> > > multiple options.
> > >
> > > Lada
> > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > > /martin
> > > > >
> > > > > _____________________________________________= __
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&= ;c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJ= UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBar= BrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRS= Cor9n_APQ&e=3D
> > > > > .
> > > > >
> > > > _______________________________________________ > > > > netmod mailing list
> > > > ne= tmod@ietf.org
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps= -3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3D= HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ= 9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5f= D0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n= _APQ&e=3D
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb= fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa= GTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c= &s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D=
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

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

--00000000000017f77005776c25f4-- From nobody Thu Oct 4 13:10:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE691130DE3 for ; Thu, 4 Oct 2018 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egpWOSvXU_yW for ; Thu, 4 Oct 2018 13:09:58 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 4438412426A for ; Thu, 4 Oct 2018 13:09:58 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w94K8kd4003507; Thu, 4 Oct 2018 13:09:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=t828ZD6PEHpnwHq9Q2nBtet4+qLpd//f/VVe6jGmORI=; b=O2UZG4+mSLxpen0iSUuNvKcFig5r/FZ+T82e5vB5wJqeHTlE9w3gPjfRJqJNf6NUQb2V uXhVPEHjpcdfhC2dVksG7MRrs+qzuz0WZvA2o+nZgg07onCK1Izy3QalKh7DuqGL6Uy4 99aWUOAfUaCXBT+F3y5Rh++z1pBusQbR81IyWTbj40gd7hIeyM5DyfLALb8tfD/zdqd2 Q8pjA+Bdlkc9kg4M4qbUomquSZrvKs8WRxomAmqGz0poN4ll9BK1aVWkCayaGobz2qGr 3UWjl768K+kcxQFjujSFriuTyQHG5KJXFGpsxtO8paMAXyvi2kYwB3gaan9tPSkasBNH BQ== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0118.outbound.protection.outlook.com [216.32.181.118]) by mx0a-00273201.pphosted.com with ESMTP id 2mwsa7812g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Oct 2018 13:09:57 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4169.namprd05.prod.outlook.com (20.176.72.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Thu, 4 Oct 2018 20:09:55 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.022; Thu, 4 Oct 2018 20:09:55 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyPz6FAZXxCAuEeMxCal0HeWUaUO37yAgAAnp4CAAARbAIAABz8AgABBFoD//8WNgIAAWzMAgAAFdID//8jaAA== Date: Thu, 4 Oct 2018 20:09:55 +0000 Message-ID: <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4169; 6:knhhw+tgi1G6ygaLRH8wqSJhbQrmJYWNBndrwwOG3pqvFahfY8/9cCABQODVIoxy7T9nIGgK4kX8Uaz+WyLdgFsl1HaTyfV+WKUjT2nj/Akf1LZnps4kEpM4c3MtbE/OwzNKaLRQzfpbWJGDO+ilRGc1ouqThdFjCUunYqh4v/fcrFNYwYDRqfOYjFj21aCw+1/SXCF3MWj3IC0pt5Kpg8MpWCV887jQQF2++7Kn/bskkxfCpd1sW+zGF9zYuCb0MrwGqF7aG9qCOmImqPEynbl6k7zRCKDlOH3olXezyFamqbEJzfdSboJD0OQ+EmeZucEvNvrMcGZIU+CHbvl8ebxtYNIgJ2zEnv59z3drLHcBVwsWufokCJiUnMrpsgWAK2Cyp+5szcNTBSon7MiICRKAVnDCATaqfU0RAu44thDoZ57s9Z7g/TBh4Vpolu0qxBnAeWz8nTp9uaTuyj2UUg==; 5:VTou2xqxRubsAFVSj5UohZx0junL0hogoBnPwebEOFPfIHMsz/9oGodZ3Iwv1cLYt4Bse/RxIipkABx/lTcGc7dzCmIOEtKfgceaqkbkQyIi1OVxLqRBtrW4gbQzUSAM0MyiyBujsKjEjzNhYTmTULfK9cAMSZJCrxBDT1EK++A=; 7:6FPjMGlo7YRDbaRrTHFwTiTyckpCKAH23dDbhUNJuV0u2HLCQht33fYE/AeU9IQiXKt3hN8mFNczbswz74kmFWhleDuEfCFziwH4i3uE1Og3uDMl//Lv4OLE3AU1l3Av59BQwUg7LZBjfrus9CS3YmUXXbWGNzewzW6nf6UVgFHcECm6flnF+xyNPxHNMWAWfEtzs2BmcEo7E4OCskynvN/Pnd5dgsGU0/x6g7JcIyFirjG2HTp45DbCLzv+TUtS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 02efa483-810c-42bf-551b-08d62a355a09 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4169; x-ms-traffictypediagnostic: DM6PR05MB4169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(138986009662008)(10436049006162)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(163750095850); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051); SRVR:DM6PR05MB4169; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4169; x-forefront-prvs: 0815F8251E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(396003)(39860400002)(136003)(51444003)(13464003)(189003)(199004)(58126008)(478600001)(81166006)(5250100002)(316002)(2501003)(114624004)(83716004)(81156014)(3846002)(110136005)(14454004)(71190400001)(6116002)(71200400001)(36756003)(606006)(93886005)(106356001)(97736004)(105586002)(33656002)(7736002)(5660300001)(6436002)(6486002)(8936002)(66066001)(236005)(53546011)(229853002)(8676002)(6512007)(256004)(2906002)(6506007)(476003)(486006)(446003)(11346002)(2616005)(14444005)(102836004)(53936002)(26005)(186003)(99286004)(575784001)(6246003)(86362001)(2900100001)(82746002)(76176011)(966005)(68736007)(54896002)(25786009)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4169; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: +VVdCQ3A+Ck8cQtKqJMvyxNcCP0ki37+Jg+Lt4uxRBhFOzbt84ZrYoYFLtqxeUz8HTV89IbmiXZP4nOOhfSukIAs7HnddGXpGuY9WfMUpE3hYtbt1UyrYJDzVDhPqCslIEC9NNH8EquB/k+Y9U6c/j0UcPpD4lGCFtWwE3KmtSEvjTBXpgc2je9ROHv8fMImQsK32CNYVG9WdS0Hi3hk0LjhS+spMzOqIjnvhLGeboGDeVHy5vLUBX3mpPdjxXCst3X5Pk6Hazz0EzaekDth+YosZTtocjbWeTk1rXEEOcB1G44Psd9BtstCq3+EC1rgJ39s0RKpaeNlVUp05+qv2ssqERTLJcwzcMaAm/WbYtk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8704A29DEBAB4AA0B5A33CAC74403360junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 02efa483-810c-42bf-551b-08d62a355a09 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 20:09:55.0797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810040181 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 20:10:02 -0000 --_000_8704A29DEBAB4AA0B5A33CAC74403360junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZSwgb25lIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgZm9ybWF0LCBvdGhlcnMgbmljZSB0byBo YXZlLg0KSW50ZXJvcGVyYWJpbGl0eSBnb29kLiAgQWdyZWVkLg0KDQpCdXQgd2h5IFlBTkctcGF0 Y2ggYW5kIG5vdCBzb21ldGhpbmcgYnVpbHQgZm9yIHRoZSBwdXJwb3NlDQooZS5nLiwgWUFORy1k aWZmKSB0aGF0LCBpbiBwYXJ0aWN1bGFyLCBwcm92aWRlcyBhbiBhY3R1YWwgZGlmZiBhcw0Kb3Bw b3NlZCB0byBhIGRhdGEtdHJlZSBvcGVyYXRpb24gdGhhdCBvbmx5IHNob3dzIG9uZSBvZiB0aGUN CnR3byB2YWx1ZXM/DQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQpPbiAxMC80LzE4LCAzOjI3 IFBNLCAiQW5keSBCaWVybWFuIiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20+PiB3cm90ZToNCg0KT24gVGh1LCBPY3QgNCwgMjAxOCBhdCAxMjowNyBQTSwgSnVl cmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8 bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3RlOg0KRm9s a3MsIHRoZSBtb3JlIGZvcm1hdHMgdGhlcmUgYXJlLCB0aGUgbGVzcyBpbnRlcm9wZXJhYmlsaXR5 IHdlDQpnZXQuIElmIHRoZXJlIGFyZSBtdWx0aXBsZSBmb3JtYXRzLCBpcyB0aGVyZSBhIG1hbmRh dG9yeSB0byBpbXBsZW1lbnQNCmZvcm1hdD8gRG9lcyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVu dCBmb3JtYXQgZGVwZW5kIG9uIHRoZSBwcm90b2NvbA0KdGhhdCBpcyBiZWluZyB1c2VkPw0KDQpJ IHByZWZlciBvbmUgZm9ybWF0IG9yIGlmIG5lY2Vzc2FyeSBJIGFtIGZpbmUgd2l0aCBvbmUgbWFu ZGF0b3J5IHRvDQppbXBsZW1lbnQgZm9ybWF0LiBBbiBvcGVuIGVuZGVkIGNvbGxlY3Rpb24gb2Yg aW1wbGVtZW50YXRpb24gc3BlY2lmaWMNCmZvcm1hdHMgaXMgc3VwZXIgZmxleGlibGUgYnV0IGRl ZmVhdHMgdGhlIHB1cnBvc2Ugb2YgYSBzdGFuZGFyZCwNCm5hbWVseSBpbnRlcm9wZXJhYmlsaXR5 Lg0KDQpJIGFncmVlIHRoZXJlIG5lZWRzIHRvIGJlIDEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBm b3JtYXQuDQoNCklNTyB0aGlzIG5lZWRzIHRvIGJlIFlBTkcgUGF0Y2ggYmVjYXVzZSBpdCBpcyBt b3JlIHByZWNpc2UgdGhlbiBjb25zdHJ1Y3RpbmcgYW4gWE1MIHRyZWUgd2l0aA0Kb3BlcmF0aW9u IGF0dHJpYnV0ZXMgaW4gaXQgKGUuZy4sIGhvdyBlbHNlIGRvIHlvdSByZXByZXNlbnQgYSBkZWxl dGUgb3IgYSBtb3ZlPykNCkFsc28sIFlBTkcgUHVzaCBpcyB1c2luZyBZQU5HIFBhdGNoIGZvcm1h dCBhbmQgY29tbW9uIGNvZGUgZm9yIHB1c2ggYW5kIGRpZmYgd291bGQgYmUNCnBvc3NpYmxlLg0K DQpJIHRoaW5rIG90aGVyIGZvcm1hdHMgc2hvdWxkIGJlIGFsbG93ZWQuDQpUaGlzIGlzIHZlcnkg dG9vbC1zcGVjaWZpYy4gSSBjb3VsZCBzZWUgaG93IHNvbWVib2R5IG1pZ2h0IHdhbnQNCmEgdGV4 dHVhbCBwYXRjaCBvZiB0aGUgWE1MIHJlcHJlc2VudGF0aW9uIHRvIHByb2R1Y2UgdGhlIG5ldyBY TUwgcmVwcmVzZW50YXRpb24uDQoNCg0KL2pzDQoNCkFuZHkNCg0KDQpPbiBUaHUsIE9jdCAwNCwg MjAxOCBhdCAwNTo0MToyMlBNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gV2UgYWdyZWUg dGhhdCB0aGUgZGlmZi1mb3JtYXQgc2hvdWxkIGJlIGNsaWVudC1zZWxlY3RhYmxlLCBtb2R1bG8g d2hhdCB0aGUgc2VydmVyIHN1cHBvcnRzLiAgeWFuZy1wYXRjaCBhbmQgZWRpdC1jb25maWcgYm90 aCBhcmUgdmlhYmxlLiAgU2hvdWxkIHdlIGRvY3VtZW50IHRoZW0gYm90aD8NCj4NCj4gVGhhdCBz YWlkLCBzaW5jZSBuZWl0aGVyIGVkaXQtY29uZmlnIG5vciB5YW5nLXBhdGNoIGFyZSBkaWZmaW5n IGZvcm1hdHMsIHNvIG11Y2ggYXMgZm9ybWF0cyBmb3IgY29udmVydGluZyBvbmUgZGF0YSB0cmVl IHRvIGFub3RoZXIsIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gZGVmaW5lIGFuIGFjdHVhbCBkaWZm aW5nIGZvcm1hdD8gIEkgd291bGQgdGhpbmsgdGhhdCBhIGRpZmYgd291bGQgcHJvdmlkZSBib3Ro IHZhbHVlcywgbm90IGp1c3QgYSBuZXcgdmFsdWUuDQo+DQo+IEtlbnQgLy8gY29udHJpYnV0b3IN Cj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmlj LmN6Pj4NCj4gT3JnYW5pemF0aW9uOiBDWi5OSUMNCj4gRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIg NCwgMjAxOCBhdCAxOjExIFBNDQo+IFRvOiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNv bTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4N Cj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1t LW5ldG1vZC1ubWRhLWRpZmYtMDANCj4NCj4gT24gVGh1LCAyMDE4LTEwLTA0IGF0IDE0OjE3ICsw MTAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPiA+DQo+ID4gT24gMDQvMTAvMjAxOCAxMzo1MSwg TGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+ID4gT24gVGh1LCAyMDE4LTEwLTA0IGF0IDEzOjM2 ICswMTAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPiA+ID4gPiBPbiAwNC8xMC8yMDE4IDExOjE0 LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+ID4gPiA+IFBoaWwgU2hhZmVyIDxwaGlsQGp1 bmlwZXIubmV0PG1haWx0bzpwaGlsQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQo+ID4gPiA+ID4gPiBC YWw/enMgTGVuZ3llbCB3cml0ZXM6DQo+ID4gPiA+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFm dC0yRGNsZW1tLTJEbmV0bW9kLTJEbm1kYS0yRGRpZmYtMkQwMCZkPUR3SUNBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZU dDhrX0kyS0RFTjk3YyZzPWdRV0p0amNfMkVGM1FnUnZBQmdaS3NqcXp1SXc5eVVxX3hlZTZhRkpP Y3cmZT0NCj4gPiA+ID4gPiA+IFtJJ3ZlIG1vdmVkIHRvIGEgImRlZXAgbHVya2VyIiByb2xlIGhl cmUsIGJ1dCAuLi5dDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ2FuIHdlIGVuc3VyZSB0aGlz IG1vZGVsIGNvbnRhaW5zIGEgImZvcm1hdCIgbGVhZiBpbiB0aGUgUlBDJ3MgaW5wdXQNCj4gPiA+ ID4gPiA+IHNvIHRoYXQgZnV0dXJlIChhbmQgcHJvcHJpZXRhcnkpIGZvcm1hdHMgY2FuIGJlIHN1 cHBvcnRlZD8gICBUaGF0DQo+ID4gPiA+ID4gPiBsZWFmIGNhbiBiZSBhbiBpZGVudGl0eXJlZiB0 aGF0IGRlZmF1bHRzIHRvIHlhbmctcGF0Y2guDQo+ID4gPiA+ID4gSSB0aGluayB0aGlzIGlzIGEg Z29vZCBpZGVhLiAgSSB3b3VsZCBwcmVmZXIgdGhlIGVkaXQtY29uZmlnIGZvcm1hdA0KPiA+ID4g PiA+IG92ZXIgWUFORyBwYXRjaCBmb3IgZGVzY3JpYmluZyBhIGRpZmYuICBUaGUgZWRpdC1jb25m aWcgZm9ybWF0IGlzIG1vcmUNCj4gPiA+ID4gPiBzdWl0ZWQgZm9yIHRoaXMgcHVycG9zZSBpbW8u DQo+ID4gPiA+ICsxDQo+ID4gPiA+DQo+ID4gPiA+IEkgd291bGQgbGlrZSBzb21ldGhpbmcgY2xv c2VyIHRvIGVkaXQtY29uZmlnIHRvIGJlIGF2YWlsYWJsZSB2aWENCj4gPiA+ID4gUkVTVENPTkYg YXMgd2VsbC4NCj4gPiA+IFlBTkcgUGF0Y2ggaXMgSU1PIGJldHRlciBiZWNhdXNlIGl0IGNsZWFy bHkgc2VwYXJhdGVzIHRoZSB0YXJnZXQgZm9yIHRoZQ0KPiA+ID4gZWRpdHMNCj4gPiA+IGZyb20g dGhlIG5ldyBjb250ZW50Lg0KPiA+ID4gSW4gZWRpdC1jb25maWcgdGhlc2UgdHdvIGFyZSBtaXhl ZCB0b2dldGhlci4NCj4gPiBZZXMsIHRoYXQgaXMgcHJpbWFyaWx5IHdoeSBJIHByZWZlciB0aGUg ZWRpdC1jb25maWcuICBJIHBlcmNlaXZlIHRoYXQgaXQNCj4gPiBpcyBhIGRlbnNlciBhbmQgbW9y ZSBlZmZpY2llbnQgZm9ybWF0LiAgSSB0aGluayB0aGF0IGl0IGlzIGJvdGggZWFzaWVyDQo+ID4g dG8gY29uc3RydWN0ICh3aGVuIGRpZmZpbmcgdHdvIHRyZWVzKSBhbmQgYWxzbyBtb3JlIGVmZmlj aWVudCB0byBhcHBseQ0KPiA+IHdoZW4gZ2VuZXJhdGluZyBhbiB1cGRhdGVkIHRyZWUuDQo+DQo+ IEV4Y2VwdCBmb3IgY2VydGFpbiBjb3JuZXIgY2FzZXMsIGZvciBleGFtcGxlIGlmIHR3byB0cmVl cyBkaWZmZXIgb25seSBpbiB0aGUNCj4gdmFsdWUgb2YgYSBzaW5nbGUgbGVhZiBidXQgdGhpcyBs ZWFmIGhhcHBlbnMgdG8gYmUgYSBsaXN0IGtleS4NCj4NCj4gTGFkYQ0KPg0KPiA+DQo+ID4gVGhh bmtzLA0KPiA+IFJvYg0KPiA+DQo+ID4NCj4gPiA+IFRoYXQgYmVpbmcgc2FpZCwgSSBzdXBwb3J0 IHNwZWNpZnlpbmcgZm9ybWF0L21lZGlhLXR5cGUgYW5kIGhhdmluZw0KPiA+ID4gcG90ZW50aWFs bHkNCj4gPiA+IG11bHRpcGxlIG9wdGlvbnMuDQo+ID4gPg0KPiA+ID4gTGFkYQ0KPiA+ID4NCj4g PiA+ID4gVGhhbmtzLA0KPiA+ID4gPiBSb2INCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiAv bWFydGluDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+ID4gPiBo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2 U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y Z3NCWWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0ky S0RFTjk3YyZzPVJWSmNnNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I5bl9BUFEmZT0N Cj4gPiA+ID4gPiAuDQo+ID4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+ID4gaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNj YmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz QllhR1R2aklTbGFKZGNabyZtPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktE RU45N2Mmcz1SVkpjZzVwekhXLXppMU9ib0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmU9DQo+ IC0tDQo+IExhZGlzbGF2IExob3RrYQ0KPiBIZWFkLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElE OiAweEI4RjkyQjA4QTlGNzZDNjcNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6 b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTdzNlZk enpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2Mmcz1SVkpjZzVwekhXLXppMU9i b0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmU9DQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0 bW9kJmQ9RHdNRmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9D SSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1PN2QtYjln eVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxvOF9XNlczcXQ0JnM9NUxIaGJmUVplb3FZbEM0MFQz bW0tQUV6NHJTc3lSV1lqcVRLN0x1V1RQdyZlPT4NCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQy MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55 DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5p dmVyc2l0eS5kZS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8mZD1Ed01GYVEmYz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPU83ZC1iOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdR TG84X1c2VzNxdDQmcz16aDdxRVBTbXd2aWFTcVpCcUcxR2NxSXRYd0k5cHd5cUlGVlc2eEM4cks4 JmU9Pj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZo MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTbGFKZGNabyZtPU83ZC1iOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2VzNx dDQmcz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJXWWpxVEs3THVXVFB3JmU9Pg0KDQo= --_000_8704A29DEBAB4AA0B5A33CAC74403360junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <4F99B7466D879146B821085DFAC8F7D2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5t NDI2NzYxMzg3NTkyODA4OTk5MmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXzQyNjc2MTM4NzU5 MjgwODk5OTJob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC12 YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFu c2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWdu OmJhc2VsaW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlN1cmUsIG9uZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCwgb3RoZXJzIG5p Y2UgdG8gaGF2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SW50ZXJvcGVyYWJpbGl0eSBnb29kLiZuYnNw OyBBZ3JlZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5CdXQg d2h5IFlBTkctcGF0Y2ggYW5kIG5vdCBzb21ldGhpbmcgYnVpbHQgZm9yIHRoZSBwdXJwb3NlDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+KGUuZy4sIFlBTkctZGlmZikgdGhhdCwgaW4gcGFydGljdWxhciwg cHJvdmlkZXMgYW4gYWN0dWFsIGRpZmYgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+b3Bwb3NlZCB0byBh IGRhdGEtdHJlZSBvcGVyYXRpb24gdGhhdCBvbmx5IHNob3dzIG9uZSBvZiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+dHdvIHZhbHVlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvNC8xOCwgMzoyNyBQTSwgJnF1b3Q7QW5keSBCaWVy bWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1 bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDQsIDIwMTggYXQgMTI6 MDcgUE0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Rm9sa3MsIHRoZSBtb3JlIGZvcm1hdHMgdGhlcmUgYXJlLCB0aGUgbGVzcyBpbnRlcm9w ZXJhYmlsaXR5IHdlPGJyPg0KZ2V0LiBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgZm9ybWF0cywgaXMg dGhlcmUgYSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50PGJyPg0KZm9ybWF0PyBEb2VzIHRoZSBtYW5k YXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCBkZXBlbmQgb24gdGhlIHByb3RvY29sPGJyPg0KdGhh dCBpcyBiZWluZyB1c2VkPzxicj4NCjxicj4NCkkgcHJlZmVyIG9uZSBmb3JtYXQgb3IgaWYgbmVj ZXNzYXJ5IEkgYW0gZmluZSB3aXRoIG9uZSBtYW5kYXRvcnkgdG88YnI+DQppbXBsZW1lbnQgZm9y bWF0LiBBbiBvcGVuIGVuZGVkIGNvbGxlY3Rpb24gb2YgaW1wbGVtZW50YXRpb24gc3BlY2lmaWM8 YnI+DQpmb3JtYXRzIGlzIHN1cGVyIGZsZXhpYmxlIGJ1dCBkZWZlYXRzIHRoZSBwdXJwb3NlIG9m IGEgc3RhbmRhcmQsPGJyPg0KbmFtZWx5IGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRo ZXJlIG5lZWRzIHRvIGJlIDEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBmb3JtYXQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyB0aGlzIG5l ZWRzIHRvIGJlIFlBTkcgUGF0Y2ggYmVjYXVzZSBpdCBpcyBtb3JlIHByZWNpc2UgdGhlbiBjb25z dHJ1Y3RpbmcgYW4gWE1MIHRyZWUgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+b3BlcmF0aW9uIGF0dHJpYnV0ZXMgaW4gaXQgKGUuZy4sIGhv dyBlbHNlIGRvIHlvdSByZXByZXNlbnQgYSBkZWxldGUgb3IgYSBtb3ZlPyk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIFlBTkcgUHVzaCBp cyB1c2luZyBZQU5HIFBhdGNoIGZvcm1hdCBhbmQgY29tbW9uIGNvZGUgZm9yIHB1c2ggYW5kIGRp ZmYgd291bGQgYmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRoaW5rIG90aGVyIGZvcm1hdHMgc2hvdWxkIGJlIGFsbG93ZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlz IHZlcnkgdG9vbC1zcGVjaWZpYy4gSSBjb3VsZCBzZWUgaG93IHNvbWVib2R5IG1pZ2h0IHdhbnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgdGV4 dHVhbCBwYXRjaCBvZiB0aGUgWE1MIHJlcHJlc2VudGF0aW9uIHRvIHByb2R1Y2UgdGhlIG5ldyBY TUwgcmVwcmVzZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L2pzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIFRodSwgT2N0 IDA0LCAyMDE4IGF0IDA1OjQxOjIyUE0gJiM0MzswMDAwLCBLZW50IFdhdHNlbiB3cm90ZTo8YnI+ DQomZ3Q7IFdlIGFncmVlIHRoYXQgdGhlIGRpZmYtZm9ybWF0IHNob3VsZCBiZSBjbGllbnQtc2Vs ZWN0YWJsZSwgbW9kdWxvIHdoYXQgdGhlIHNlcnZlciBzdXBwb3J0cy4mbmJzcDsgeWFuZy1wYXRj aCBhbmQgZWRpdC1jb25maWcgYm90aCBhcmUgdmlhYmxlLiZuYnNwOyBTaG91bGQgd2UgZG9jdW1l bnQgdGhlbSBib3RoPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IHNhaWQsIHNpbmNlIG5laXRo ZXIgZWRpdC1jb25maWcgbm9yIHlhbmctcGF0Y2ggYXJlIGRpZmZpbmcgZm9ybWF0cywgc28gbXVj aCBhcyBmb3JtYXRzIGZvciBjb252ZXJ0aW5nIG9uZSBkYXRhIHRyZWUgdG8gYW5vdGhlciwgd291 bGQgaXQgbWFrZSBzZW5zZSB0byBkZWZpbmUgYW4gYWN0dWFsIGRpZmZpbmcgZm9ybWF0PyZuYnNw OyBJIHdvdWxkIHRoaW5rIHRoYXQgYSBkaWZmIHdvdWxkIHByb3ZpZGUgYm90aCB2YWx1ZXMsIG5v dCBqdXN0IGEgbmV3DQogdmFsdWUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEtlbnQgLy8gY29udHJp YnV0b3I8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCiZndDsgRnJvbTogbmV0bW9kICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0 bzpsaG90a2FAbmljLmN6IiB0YXJnZXQ9Il9ibGFuayI+bGhvdGthQG5pYy5jejwvYT4mZ3Q7PGJy Pg0KJmd0OyBPcmdhbml6YXRpb246IENaLk5JQzxicj4NCiZndDsgRGF0ZTogVGh1cnNkYXksIE9j dG9iZXIgNCwgMjAxOCBhdCAxOjExIFBNPGJyPg0KJmd0OyBUbzogUm9iZXJ0IFdpbHRvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRv bkBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwg Zm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDA8YnI+DQomZ3Q7IDxicj4NCiZndDsg T24gVGh1LCAyMDE4LTEwLTA0IGF0IDE0OjE3ICYjNDM7MDEwMCwgUm9iZXJ0IFdpbHRvbiB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIDA0LzEwLzIwMTggMTM6NTEsIExh ZGlzbGF2IExob3RrYSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBUaHUsIDIwMTgtMTAt MDQgYXQgMTM6MzYgJiM0MzswMTAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgT24gMDQvMTAvMjAxOCAxMToxNCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZTo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUGhpbCBTaGFmZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cGhpbEBqdW5pcGVyLm5ldDwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJhbD96cyBM ZW5neWVsIHdyaXRlczo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGNsZW1tLTJEbmV0bW9kLTJEbm1kYS0yRGRp ZmYtMkQwMCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k YjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNs YUpkY1pvJmFtcDttPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2Mm YW1wO3M9Z1FXSnRqY18yRUYzUWdSdkFCZ1pLc2pxenVJdzl5VXFfeGVlNmFGSk9jdyZhbXA7ZT0i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGNsZW1tLTJEbmV0bW9k LTJEbm1kYS0yRGRpZmYtMkQwMCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2Jm aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y Z3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4 a19JMktERU45N2MmYW1wO3M9Z1FXSnRqY18yRUYzUWdSdkFCZ1pLc2pxenVJdzl5VXFfeGVlNmFG Sk9jdyZhbXA7ZT08L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgW0kndmUg bW92ZWQgdG8gYSAmcXVvdDtkZWVwIGx1cmtlciZxdW90OyByb2xlIGhlcmUsIGJ1dCAuLi5dPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgQ2FuIHdlIGVuc3VyZSB0aGlzIG1vZGVsIGNvbnRhaW5zIGEgJnF1b3Q7Zm9y bWF0JnF1b3Q7IGxlYWYgaW4gdGhlIFJQQydzIGlucHV0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgc28gdGhhdCBmdXR1cmUgKGFuZCBwcm9wcmlldGFyeSkgZm9ybWF0cyBjYW4g YmUgc3VwcG9ydGVkPyZuYnNwOyAmbmJzcDtUaGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgbGVhZiBjYW4gYmUgYW4gaWRlbnRpdHlyZWYgdGhhdCBkZWZhdWx0cyB0byB5YW5n LXBhdGNoLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoaXMgaXMgYSBn b29kIGlkZWEuJm5ic3A7IEkgd291bGQgcHJlZmVyIHRoZSBlZGl0LWNvbmZpZyBmb3JtYXQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb3ZlciBZQU5HIHBhdGNoIGZvciBkZXNjcmliaW5n IGEgZGlmZi4mbmJzcDsgVGhlIGVkaXQtY29uZmlnIGZvcm1hdCBpcyBtb3JlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7IHN1aXRlZCBmb3IgdGhpcyBwdXJwb3NlIGltby48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICYjNDM7MTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIGxpa2Ugc29tZXRoaW5nIGNsb3NlciB0byBlZGl0LWNv bmZpZyB0byBiZSBhdmFpbGFibGUgdmlhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSRVNUQ09O RiBhcyB3ZWxsLjxicj4NCiZndDsgJmd0OyAmZ3Q7IFlBTkcgUGF0Y2ggaXMgSU1PIGJldHRlciBi ZWNhdXNlIGl0IGNsZWFybHkgc2VwYXJhdGVzIHRoZSB0YXJnZXQgZm9yIHRoZTxicj4NCiZndDsg Jmd0OyAmZ3Q7IGVkaXRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZnJvbSB0aGUgbmV3IGNvbnRlbnQu PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSW4gZWRpdC1jb25maWcgdGhlc2UgdHdvIGFyZSBtaXhlZCB0 b2dldGhlci48YnI+DQomZ3Q7ICZndDsgWWVzLCB0aGF0IGlzIHByaW1hcmlseSB3aHkgSSBwcmVm ZXIgdGhlIGVkaXQtY29uZmlnLiZuYnNwOyBJIHBlcmNlaXZlIHRoYXQgaXQgPGJyPg0KJmd0OyAm Z3Q7IGlzIGEgZGVuc2VyIGFuZCBtb3JlIGVmZmljaWVudCBmb3JtYXQuJm5ic3A7IEkgdGhpbmsg dGhhdCBpdCBpcyBib3RoIGVhc2llciA8YnI+DQomZ3Q7ICZndDsgdG8gY29uc3RydWN0ICh3aGVu IGRpZmZpbmcgdHdvIHRyZWVzKSBhbmQgYWxzbyBtb3JlIGVmZmljaWVudCB0byBhcHBseSA8YnI+ DQomZ3Q7ICZndDsgd2hlbiBnZW5lcmF0aW5nIGFuIHVwZGF0ZWQgdHJlZS48YnI+DQomZ3Q7IDxi cj4NCiZndDsgRXhjZXB0IGZvciBjZXJ0YWluIGNvcm5lciBjYXNlcywgZm9yIGV4YW1wbGUgaWYg dHdvIHRyZWVzIGRpZmZlciBvbmx5IGluIHRoZTxicj4NCiZndDsgdmFsdWUgb2YgYSBzaW5nbGUg bGVhZiBidXQgdGhpcyBsZWFmIGhhcHBlbnMgdG8gYmUgYSBsaXN0IGtleS48YnI+DQomZ3Q7IDxi cj4NCiZndDsgTGFkYTxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBU aGFua3MsPGJyPg0KJmd0OyAmZ3Q7IFJvYjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhdCBiZWluZyBzYWlkLCBJIHN1cHBvcnQgc3BlY2lmeWlu ZyBmb3JtYXQvbWVkaWEtdHlwZSBhbmQgaGF2aW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcG90ZW50 aWFsbHk8YnI+DQomZ3Q7ICZndDsgJmd0OyBtdWx0aXBsZSBvcHRpb25zLjxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IExhZGE8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJv Yjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgL21hcnRpbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBo cmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYu b3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZT Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1lo cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2 VHQ4a19JMktERU45N2MmYW1wO3M9UlZKY2c1cHpIVy16aTFPYm9DTDRTWDJodVc5ZXVIaVZSU0Nv cjluX0FQUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fbmV0bW9kJmFtcDtkPUR3SUNBZyZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst bmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJ U2xhSmRjWm8mYW1wO209N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0kyS0RFTjk3 YyZhbXA7cz1SVkpjZzVwekhXLXppMU9ib0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmFtcDtl PTwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLjxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZXRt b2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86 bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmYW1wO2Q9RHdJQ0FnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK ZGNabyZhbXA7bT03czZWZHp6SDlPbDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJmFt cDtzPVJWSmNnNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I5bl9BUFEmYW1wO2U9IiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1E d0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZh bXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPTdz NlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2MmYW1wO3M9UlZKY2c1cHpI Vy16aTFPYm9DTDRTWDJodVc5ZXVIaVZSU0NvcjluX0FQUSZhbXA7ZT08L2E+PGJyPg0KJmd0OyAt LSA8YnI+DQomZ3Q7IExhZGlzbGF2IExob3RrYTxicj4NCiZndDsgSGVhZCwgQ1ouTklDIExhYnM8 YnI+DQomZ3Q7IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nzxicj4NCiZndDsgPGJyPg0K Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3SUNBZyZh bXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6 a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209N3M2VmR6ekg5 T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0kyS0RFTjk3YyZhbXA7cz1SVkpjZzVwekhXLXppMU9i b0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJQ0FnJmFtcDtjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlF UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT03czZWZHp6SDlPbDNCT0NiVkxCYXJC clE1ZkQwdlR0OGtfSTJLREVOOTdjJmFtcDtzPVJWSmNnNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1 SGlWUlNDb3I5bl9BUFEmYW1wO2U9PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBv T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209TzdkLWI5Z3lQdnNhc0pvMXVlS2szZG9E SDdmNVM1V1FMbzhfVzZXM3F0NCZhbXA7cz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJX WWpxVEs3THVXVFB3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJtNDI2NzYxMzg3NTkyODA4OTk5MmhvZW56YiI+LS0g PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtNDI2NzYxMzg3NTkyODA4OTk5MmhvZW56YiI+SnVl cmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 Im00MjY3NjEzODc1OTI4MDg5OTkyaG9lbnpiIj5QaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnk8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im00MjY3NjEzODc1OTI4MDg5 OTkyaG9lbnpiIj5GYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5qYWNvYnMtMkR1bml2ZXJzaXR5 LmRlXyZhbXA7ZD1Ed01GYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2 b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk Y1pvJmFtcDttPU83ZC1iOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2VzNxdDQmYW1w O3M9emg3cUVQU213dmlhU3FaQnFHMUdjcUl0WHdJOXB3eXFJRlZXNnhDOHJLOCZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2E+Jmd0Ozwv c3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0ibTQyNjc2MTM4NzU5MjgwODk5OTJob2VuemIi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJtNDI2NzYxMzg3NTkyODA4OTk5MmhvZW56YiI+bmV0bW9kIG1haWxp bmcgbGlzdDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibTQyNjc2MTM4NzU5MjgwODk5OTJob2Vu emIiPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRt b2RAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtNDI2NzYxMzg3NTkyODA4 OTk5MmhvZW56YiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1w O2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pv Q0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7 bT1PN2QtYjlneVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxvOF9XNlczcXQ0JmFtcDtzPTVMSGhi ZlFaZW9xWWxDNDBUM21tLUFFejRyU3N5UldZanFUSzdMdVdUUHcmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8704A29DEBAB4AA0B5A33CAC74403360junipernet_-- From nobody Thu Oct 4 13:21:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C42130E9C for ; Thu, 4 Oct 2018 13:21:55 -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 5ZQh8Ksv3TQo for ; Thu, 4 Oct 2018 13:21:53 -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 0D6AD12426A for ; Thu, 4 Oct 2018 13:21:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A1EE9B7C; Thu, 4 Oct 2018 22:21:51 +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 O39d5fmt0tZW; Thu, 4 Oct 2018 22:21:50 +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; Thu, 4 Oct 2018 22:21:51 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 645DC20037; Thu, 4 Oct 2018 22:21:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id thwnVAfCACju; Thu, 4 Oct 2018 22:21:51 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 243DA20036; Thu, 4 Oct 2018 22:21:51 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Thu, 4 Oct 2018 22:21:50 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 7CDFD3000CFED9; Thu, 4 Oct 2018 22:21:49 +0200 (CEST) Date: Thu, 4 Oct 2018 22:21:49 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: Andy Bierman , "netmod@ietf.org" Message-ID: <20181004202149.xwvf2zlilid6yxrv@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 20:21:55 -0000 On Thu, Oct 04, 2018 at 08:09:55PM +0000, Kent Watsen wrote: > Sure, one mandatory to implement format, others nice to have. > Interoperability good. Agreed. > > But why YANG-patch and not something built for the purpose > (e.g., YANG-diff) that, in particular, provides an actual diff as > opposed to a data-tree operation that only shows one of the > two values? Because this is yet a third format. There is a certain benefit if a diff format can also be used to patch. If we create a new diff format, guess what will come up next... /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 Thu Oct 4 13:59:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B10130E94 for ; Thu, 4 Oct 2018 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 WD8_0pi6LaS4 for ; Thu, 4 Oct 2018 13:59:17 -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 7A9B312F1A5 for ; Thu, 4 Oct 2018 13:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1538686757; x=1539896357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N0Trm9zipkvoZj4sje+zlYxJIxmuqWtRdiaxF9WC9y8=; b=eIPIsH4clMDxceli5GOvVl7lbiSAzkqFjTJfYSB+jTaZb9f+NprKXbX2 kyy3dGPg0NmDprgbls7vO5MEzHv+yG88MW4s25rZLKt55hV4cGRnj7+Yx OPpdXvRi7BgKosq2En1oJeVWO9iUnZDaFoZSK5JOGzzUdw0DkH/skTT48 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAADLfbZb/4UNJK1YAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCBmZ/KAqDapQ0gWglmFcLAQEYC4QDRgIXhA4hOBY?= =?us-ascii?q?BAwEBAgEBAm0cDIU6AQEBAwEBIRE6Cw4CAgEIDgIIAgImAgICGQwLFRACBAE?= =?us-ascii?q?NBYMhAYIBD6UFgS6KDAUFgQaKIReBQT+BOQwTgkyDGwEBgXgKGQ2COjGCJgK?= =?us-ascii?q?dVwkCkD4Xj2uVOAIRFIElNCGBVXAVOyoBgkGGNYRhhT5vjCyBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,341,1534809600"; d="scan'208";a="464854768" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 20:59:16 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w94KxG2J011593 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Oct 2018 20:59:16 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 15:59:16 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 15:59:16 -0500 From: "Reshad Rahman (rrahman)" To: Juergen Schoenwaelder , Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyQUI2nNckn+1ky1f4oa9l5TQKUPM42AgAAnqICAAARaAIAABz8AgABBFoCAAAiTAIAAGC0AgAAFdICAAAvggIAAA1OA///G8IA= Date: Thu, 4 Oct 2018 20:59:15 +0000 Message-ID: <1911A5D5-41A7-4777-A2A2-E31B3EAB0C23@cisco.com> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <20181004202149.xwvf2zlilid6yxrv@anna.jacobs.jacobs-university.de> In-Reply-To: <20181004202149.xwvf2zlilid6yxrv@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.72] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 20:59:20 -0000 T24gMjAxOC0xMC0wNCwgNDoyMiBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hv ZW53YWVsZGVyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCiAgICBPbiBUaHUsIE9jdCAw NCwgMjAxOCBhdCAwODowOTo1NVBNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCiAgICA+IFN1 cmUsIG9uZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCwgb3RoZXJzIG5pY2UgdG8gaGF2 ZS4NCiAgICA+IEludGVyb3BlcmFiaWxpdHkgZ29vZC4gIEFncmVlZC4NCiAgICA+IA0KICAgID4g QnV0IHdoeSBZQU5HLXBhdGNoIGFuZCBub3Qgc29tZXRoaW5nIGJ1aWx0IGZvciB0aGUgcHVycG9z ZQ0KICAgID4gKGUuZy4sIFlBTkctZGlmZikgdGhhdCwgaW4gcGFydGljdWxhciwgcHJvdmlkZXMg YW4gYWN0dWFsIGRpZmYgYXMNCiAgICA+IG9wcG9zZWQgdG8gYSBkYXRhLXRyZWUgb3BlcmF0aW9u IHRoYXQgb25seSBzaG93cyBvbmUgb2YgdGhlDQogICAgPiB0d28gdmFsdWVzPw0KICAgIA0KICAg IEJlY2F1c2UgdGhpcyBpcyB5ZXQgYSB0aGlyZCBmb3JtYXQuIFRoZXJlIGlzIGEgY2VydGFpbiBi ZW5lZml0IGlmIGENCiAgICBkaWZmIGZvcm1hdCBjYW4gYWxzbyBiZSB1c2VkIHRvIHBhdGNoLiBJ ZiB3ZSBjcmVhdGUgYSBuZXcgZGlmZiBmb3JtYXQsDQogICAgZ3Vlc3Mgd2hhdCB3aWxsIGNvbWUg dXAgbmV4dC4uLg0KPFJSPiBBbmQgdGhlcmUgYXJlIHdheXMgdG8gZ2V0IHRoZSBtaXNzaW5nIHZh bHVlcyAoZnJvbSBzb3VyY2UgZGF0YXN0b3JlKS4NCiAgICANCiAgICAvanMNCiAgICANCiAgICAt LSANCiAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5 IEJyZW1lbiBnR21iSA0KICAgIFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz IFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCiAgICBGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBu ZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K From nobody Thu Oct 4 14:05:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC9B12F1A6 for ; Thu, 4 Oct 2018 14:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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=yumaworks-com.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 K6VkO_af_QGF for ; Thu, 4 Oct 2018 14:05:00 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 AAEFC12F1A5 for ; Thu, 4 Oct 2018 14:04:59 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id m18-v6so7834521lfl.11 for ; Thu, 04 Oct 2018 14:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FEIq3P/XaKyGotG4cS6EB9eKpEp4gaIHlJ77tG5F3aA=; b=dSY2PlAj6qGiIyxgy62iy5leDuKUGqZ8IobFPXXJjQCd3ncKqgzYdXaByDkE7SoJU2 TEpQcxp/C6377yksDPh8X33l4ItzkshlIyUuii4nQoibts9+9lqeWarqlN0jz8dkv1Rw dE9O4z5x/YwJ5GSmfiWkNnrz3ReY04hZVpvegje3dMW89z68jiOo4jFb2fiCSrzpaOZS rXxwD0i6IGWF+hb48kycJpUDEWXwEapC6jL9xOKi9EOSHigEo5AIjjANPIanY5xeT/ND qgnE9CKeLnBXvIvlb7fKrY1a4y/NBsmongcRCJK/+iM6AQLuJpaZ7luJg+K+s1CbJdXR u6Eg== 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=FEIq3P/XaKyGotG4cS6EB9eKpEp4gaIHlJ77tG5F3aA=; b=o3HjmiRhZM2SdTU3OdqtV2FSVHKXtwZi2hUnT9tTmZCbAlAadImb2K0UVaqbYucbT1 YgYVZDvT89unWqfU8qsWgNxI1OfVSayIx9Xo+fZBLhLYxqOZ+gHt1wfek6hS9sfmSKOn yx1yD1Mj3xPMNxa54TGDkb5+YhSjG/sRTxRYw9jqD0cFkr8i7mZ/Hd+BcjZkg0yTfg2q MAN+k7ZstjrIw8qKDBGLbPJCasTx9xRaIbdRqQ8JMQeWif+ohWIb3OHz9+G/0qkVIg+P f/su+wKpW6CgBLNyjar6RPJX7CLptZzFWTU2yVqJx6AD87zkOC2ymkbWBDsNB0PCw/QO 7/mw== X-Gm-Message-State: ABuFfohceUzyuA+9DEJEWex2WWCtbDmj8NAhzRgYO2oO/58sXAXYPOjh yNoZZ+srw7nbtanQcLxDfDPW8oIDGT55YVLJvqSARw== X-Google-Smtp-Source: ACcGV614EHFs+YGZ1r5LpyB6zSgYtQlRZONdySyH6nmucWgGnHj3fSw6PmE8nt+MQOgSG73EUxfNDN8PVEbhbOYkiGg= X-Received: by 2002:a19:3bcf:: with SMTP id d76-v6mr4713039lfl.126.1538687097690; Thu, 04 Oct 2018 14:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 4 Oct 2018 14:04:56 -0700 (PDT) In-Reply-To: <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> From: Andy Bierman Date: Thu, 4 Oct 2018 14:04:56 -0700 Message-ID: To: Kent Watsen Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0eec505776d8155" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 21:05:03 -0000 --000000000000e0eec505776d8155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 4, 2018 at 1:09 PM, Kent Watsen wrote: > Sure, one mandatory to implement format, others nice to have. > > Interoperability good. Agreed. > > > > But why YANG-patch and not something built for the purpose > > (e.g., YANG-diff) that, in particular, provides an actual diff as > > opposed to a data-tree operation that only shows one of the > > two values? > > > The yang-patch edit list could be augmented with an 'old-value' node. This seems reasonable to provide for leafs. > Kent // contributor > > > Andy > > > On 10/4/18, 3:27 PM, "Andy Bierman" wrote: > > > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Folks, the more formats there are, the less interoperability we > get. If there are multiple formats, is there a mandatory to implement > format? Does the mandatory to implement format depend on the protocol > that is being used? > > I prefer one format or if necessary I am fine with one mandatory to > implement format. An open ended collection of implementation specific > formats is super flexible but defeats the purpose of a standard, > namely interoperability. > > > > I agree there needs to be 1 mandatory-to-implement format. > > > > IMO this needs to be YANG Patch because it is more precise then > constructing an XML tree with > > operation attributes in it (e.g., how else do you represent a delete or a > move?) > > Also, YANG Push is using YANG Patch format and common code for push and > diff would be > > possible. > > > > I think other formats should be allowed. > > This is very tool-specific. I could see how somebody might want > > a textual patch of the XML representation to produce the new XML > representation. > > > > > > /js > > > > Andy > > > > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: > > We agree that the diff-format should be client-selectable, modulo what > the server supports. yang-patch and edit-config both are viable. Should > we document them both? > > > > That said, since neither edit-config nor yang-patch are diffing formats= , > so much as formats for converting one data tree to another, would it make > sense to define an actual diffing format? I would think that a diff woul= d > provide both values, not just a new value. > > > > Kent // contributor > > > > > > -----Original Message----- > > From: netmod on behalf of Ladislav Lhotka < > lhotka@nic.cz> > > Organization: CZ.NIC > > Date: Thursday, October 4, 2018 at 1:11 PM > > To: Robert Wilton , "netmod@ietf.org" < > netmod@ietf.org> > > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff= - > 00 > > > > On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > > > > > > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > > > > > Phil Shafer wrote: > > > > > > > Bal?zs Lengyel writes: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tool= s. > ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwICAg&c=3D > HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D > 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D > 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_ > 2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e=3D > > > > > > > [I've moved to a "deep lurker" role here, but ...] > > > > > > > > > > > > > > Can we ensure this model contains a "format" leaf in the RPC'= s > input > > > > > > > so that future (and proprietary) formats can be supported? > That > > > > > > > leaf can be an identityref that defaults to yang-patch. > > > > > > I think this is a good idea. I would prefer the edit-config > format > > > > > > over YANG patch for describing a diff. The edit-config format > is more > > > > > > suited for this purpose imo. > > > > > +1 > > > > > > > > > > I would like something closer to edit-config to be available via > > > > > RESTCONF as well. > > > > YANG Patch is IMO better because it clearly separates the target fo= r > the > > > > edits > > > > from the new content. > > > > In edit-config these two are mixed together. > > > Yes, that is primarily why I prefer the edit-config. I perceive that > it > > > is a denser and more efficient format. I think that it is both easie= r > > > to construct (when diffing two trees) and also more efficient to appl= y > > > when generating an updated tree. > > > > Except for certain corner cases, for example if two trees differ only i= n > the > > value of a single leaf but this leaf happens to be a list key. > > > > Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > > > That being said, I support specifying format/media-type and having > > > > potentially > > > > multiple options. > > > > > > > > Lada > > > > > > > > > Thanks, > > > > > Rob > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe= MK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D > 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > > > > . > > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe= MK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D > 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe= MK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D > 7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > --000000000000e0eec505776d8155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 4, 2018 at 1:09 PM, Kent Watsen <kwatsen@juniper.net= > wrote:

Sure, one mandatory= to implement format, others nice to have.

Interoperability go= od.=C2=A0 Agreed.

=C2=A0

But why YANG-patch = and not something built for the purpose

(e.g., YANG-diff) t= hat, in particular, provides an actual diff as

opposed to a data-t= ree operation that only shows one of the

two values?<= u>

=C2=A0


The yang-patch edit list = could be augmented with an 'old-value' node.
This seems r= easonable to provide for leafs.

=C2=A0

Kent // contributor=

=C2=A0



Andy
=
=C2=A0

=C2=A0

On 10/4/18, 3:27 PM, "Andy Bierman" <andy@yumaworks.com> wrote:

=C2=A0

On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de> wrote:

Folks, the more forma= ts there are, the less interoperability we
get. If there are multiple formats, is there a mandatory to implement
format? Does the mandatory to implement format depend on the protocol
that is being used?

I prefer one format or if necessary I am fine with one mandatory to
implement format. An open ended collection of implementation specific
formats is super flexible but defeats the purpose of a standard,
namely interoperability.

=C2=A0

I agree there needs to be 1 mandatory-to-implement f= ormat.

=C2=A0

IMO this needs to be YANG Patch because it is more p= recise then constructing an XML tree with

operation attributes in it (e.g., how else do you re= present a delete or a move?)

Also, YANG Push is using YANG Patch format and commo= n code for push and diff would be

possible.

=C2=A0

I think other formats should be allowed.

This is very tool-specific. I could see how somebody= might want

a textual patch of the XML representation to produce= the new XML representation.

=C2=A0

=C2=A0

/js

=C2=A0

Andy

=C2=A0


On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote:
> We agree that the diff-format should be client-selectable, modulo what= the server supports.=C2=A0 yang-patch and edit-config both are viable.=C2= =A0 Should we document them both?
>
> That said, since neither edit-config nor yang-patch are diffing format= s, so much as formats for converting one data tree to another, would it mak= e sense to define an actual diffing format?=C2=A0 I would think that a diff= would provide both values, not just a new value.
>
> Kent // contributor
>
>
> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> on behalf of Ladislav Lhotka <lhotka@nic.cz>
> Organization: CZ.NIC
> Date: Thursday, October 4, 2018 at 1:11 PM
> To: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-dif= f-00
>
> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote:
> >
> > On 04/10/2018 13:51, Ladislav Lhotka wrote:
> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote:
> > > > On 04/10/2018 11:14, Martin Bjorklund wrote:
> > > > > Phil Shafer <phil@juniper.net> wrote:
> > > > > > Bal?zs Lengyel writes:
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf= .org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwICA= g&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol= 3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZKsjq= zuIw9yUq_xee6aFJOcw&e=3D
> > > > > > [I've moved to a "deep lurker" = role here, but ...]
> > > > > >
> > > > > > Can we ensure this model contains a "for= mat" leaf in the RPC's input
> > > > > > so that future (and proprietary) formats can = be supported?=C2=A0 =C2=A0That
> > > > > > leaf can be an identityref that defaults to y= ang-patch.
> > > > > I think this is a good idea.=C2=A0 I would prefer = the edit-config format
> > > > > over YANG patch for describing a diff.=C2=A0 The e= dit-config format is more
> > > > > suited for this purpose imo.
> > > > +1
> > > >
> > > > I would like something closer to edit-config to be avai= lable via
> > > > RESTCONF as well.
> > > YANG Patch is IMO better because it clearly separates the ta= rget for the
> > > edits
> > > from the new content.
> > > In edit-config these two are mixed together.
> > Yes, that is primarily why I prefer the edit-config.=C2=A0 I perc= eive that it
> > is a denser and more efficient format.=C2=A0 I think that it is b= oth easier
> > to construct (when diffing two trees) and also more efficient to = apply
> > when generating an updated tree.
>
> Except for certain corner cases, for example if two trees differ only = in the
> value of a single leaf but this leaf happens to be a list key.
>
> Lada
>
> >
> > Thanks,
> > Rob
> >
> >
> > > That being said, I support specifying format/media-type and = having
> > > potentially
> > > multiple options.
> > >
> > > Lada
> > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > > /martin
> > > > >
> > > > > _____________________________________________= __
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6S= cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsB= YaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2= KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= =3D
> > > > > .
> > > > >
> > > > _______________________________________________ > > > > netmod mailing list
> > > > ne= tmod@ietf.org
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6S= cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsB= YaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2= KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= =3D
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6S= cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsB= YaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2= KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= =3D
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- Juergen Scho= enwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen = gGmbH
Phone: +49 4= 21 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 = =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>= ;

____________= ___________________________________
netmod maili= ng list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

=C2=A0


--000000000000e0eec505776d8155-- From nobody Fri Oct 5 00:44:43 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F42130DE0 for ; Fri, 5 Oct 2018 00:44:41 -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, 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 nQcuw9jc2h2W for ; Fri, 5 Oct 2018 00:44:37 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14404130DC6 for ; Fri, 5 Oct 2018 00:44:37 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 082591821139; Fri, 5 Oct 2018 09:51:22 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 2CDA71820059; Fri, 5 Oct 2018 09:51:20 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Kent Watsen , "netmod\@ietf.org" In-Reply-To: References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> Mail-Followup-To: Andy Bierman , Juergen Schoenwaelder , Kent Watsen , "netmod\@ietf.org" Date: Fri, 05 Oct 2018 09:44:33 +0200 Message-ID: <87va6gdehq.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 07:44:41 -0000 Andy Bierman writes: > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Folks, the more formats there are, the less interoperability we >> get. If there are multiple formats, is there a mandatory to implement >> format? Does the mandatory to implement format depend on the protocol >> that is being used? >> >> I prefer one format or if necessary I am fine with one mandatory to >> implement format. An open ended collection of implementation specific >> formats is super flexible but defeats the purpose of a standard, >> namely interoperability. >> >> > I agree there needs to be 1 mandatory-to-implement format. > > IMO this needs to be YANG Patch because it is more precise then > constructing an XML tree with > operation attributes in it (e.g., how else do you represent a delete or a > move?) > Also, YANG Push is using YANG Patch format and common code for push and > diff would be > possible. +1 Lada > > I think other formats should be allowed. > This is very tool-specific. I could see how somebody might want > a textual patch of the XML representation to produce the new XML > representation. > > > >> /js >> > > Andy > > >> >> On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: >> > We agree that the diff-format should be client-selectable, modulo what >> the server supports. yang-patch and edit-config both are viable. Should >> we document them both? >> > >> > That said, since neither edit-config nor yang-patch are diffing format= s, >> so much as formats for converting one data tree to another, would it make >> sense to define an actual diffing format? I would think that a diff wou= ld >> provide both values, not just a new value. >> > >> > Kent // contributor >> > >> > >> > =EF=BB=BF-----Original Message----- >> > From: netmod on behalf of Ladislav Lhotka < >> lhotka@nic.cz> >> > Organization: CZ.NIC >> > Date: Thursday, October 4, 2018 at 1:11 PM >> > To: Robert Wilton , "netmod@ietf.org" < >> netmod@ietf.org> >> > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-dif= f-0 >> 0 >> > >> > On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: >> > > >> > > On 04/10/2018 13:51, Ladislav Lhotka wrote: >> > > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: >> > > > > On 04/10/2018 11:14, Martin Bjorklund wrote: >> > > > > > Phil Shafer wrote: >> > > > > > > Bal?zs Lengyel writes: >> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__too= ls.i >> etf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwI >> CAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJ >> UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarB >> rQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e= =3D >> > > > > > > [I've moved to a "deep lurker" role here, but ...] >> > > > > > > >> > > > > > > Can we ensure this model contains a "format" leaf in the RPC= 's >> input >> > > > > > > so that future (and proprietary) formats can be supported? >> That >> > > > > > > leaf can be an identityref that defaults to yang-patch. >> > > > > > I think this is a good idea. I would prefer the edit-config >> format >> > > > > > over YANG patch for describing a diff. The edit-config format >> is more >> > > > > > suited for this purpose imo. >> > > > > +1 >> > > > > >> > > > > I would like something closer to edit-config to be available via >> > > > > RESTCONF as well. >> > > > YANG Patch is IMO better because it clearly separates the target f= or >> the >> > > > edits >> > > > from the new content. >> > > > In edit-config these two are mixed together. >> > > Yes, that is primarily why I prefer the edit-config. I perceive that >> it >> > > is a denser and more efficient format. I think that it is both easi= er >> > > to construct (when diffing two trees) and also more efficient to app= ly >> > > when generating an updated tree. >> > >> > Except for certain corner cases, for example if two trees differ only = in >> the >> > value of a single leaf but this leaf happens to be a list key. >> > >> > Lada >> > >> > > >> > > Thanks, >> > > Rob >> > > >> > > >> > > > That being said, I support specifying format/media-type and having >> > > > potentially >> > > > multiple options. >> > > > >> > > > Lada >> > > > >> > > > > Thanks, >> > > > > Rob >> > > > > >> > > > > >> > > > > > /martin >> > > > > > >> > > > > > _______________________________________________ >> > > > > > netmod mailing list >> > > > > > netmod@ietf.org >> > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh >> 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >> jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D >> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D >> > > > > > . >> > > > > > >> > > > > _______________________________________________ >> > > > > netmod mailing list >> > > > > netmod@ietf.org >> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh >> 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >> jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D >> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D >> > -- >> > Ladislav Lhotka >> > Head, CZ.NIC Labs >> > PGP Key ID: 0xB8F92B08A9F76C67 >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh >> 0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >> jISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3D >> RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Oct 5 00:50:37 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04989130DE0 for ; Fri, 5 Oct 2018 00:50:35 -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, 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 0axHYDbTRyW6 for ; Fri, 5 Oct 2018 00:50:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B0130DC6 for ; Fri, 5 Oct 2018 00:50:31 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 483711821139; Fri, 5 Oct 2018 09:57:17 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BFB161820059; Fri, 5 Oct 2018 09:57:15 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> Mail-Followup-To: Kent Watsen , Andy Bierman , Juergen Schoenwaelder , "netmod\@ietf.org" Date: Fri, 05 Oct 2018 09:50:29 +0200 Message-ID: <87sh1kde7u.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 07:50:35 -0000 Kent Watsen writes: > Sure, one mandatory to implement format, others nice to have. > Interoperability good. Agreed. > > But why YANG-patch and not something built for the purpose > (e.g., YANG-diff) that, in particular, provides an actual diff as > opposed to a data-tree operation that only shows one of the > two values? Such a format can be developed independently, I would support it. Lada > > Kent // contributor > > > On 10/4/18, 3:27 PM, "Andy Bierman" > wrote: > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder > wrote: > Folks, the more formats there are, the less interoperability we > get. If there are multiple formats, is there a mandatory to implement > format? Does the mandatory to implement format depend on the protocol > that is being used? > > I prefer one format or if necessary I am fine with one mandatory to > implement format. An open ended collection of implementation specific > formats is super flexible but defeats the purpose of a standard, > namely interoperability. > > I agree there needs to be 1 mandatory-to-implement format. > > IMO this needs to be YANG Patch because it is more precise then constructing an XML tree with > operation attributes in it (e.g., how else do you represent a delete or a move?) > Also, YANG Push is using YANG Patch format and common code for push and diff would be > possible. > > I think other formats should be allowed. > This is very tool-specific. I could see how somebody might want > a textual patch of the XML representation to produce the new XML representation. > > > /js > > Andy > > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: >> We agree that the diff-format should be client-selectable, modulo what the server supports. yang-patch and edit-config both are viable. Should we document them both? >> >> That said, since neither edit-config nor yang-patch are diffing formats, so much as formats for converting one data tree to another, would it make sense to define an actual diffing format? I would think that a diff would provide both values, not just a new value. >> >> Kent // contributor >> >> >> -----Original Message----- >> From: netmod > on behalf of Ladislav Lhotka > >> Organization: CZ.NIC >> Date: Thursday, October 4, 2018 at 1:11 PM >> To: Robert Wilton >, "netmod@ietf.org" > >> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 >> >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: >> > >> > On 04/10/2018 13:51, Ladislav Lhotka wrote: >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: >> > > > On 04/10/2018 11:14, Martin Bjorklund wrote: >> > > > > Phil Shafer > wrote: >> > > > > > Bal?zs Lengyel writes: >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=gQWJtjc_2EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e= >> > > > > > [I've moved to a "deep lurker" role here, but ...] >> > > > > > >> > > > > > Can we ensure this model contains a "format" leaf in the RPC's input >> > > > > > so that future (and proprietary) formats can be supported? That >> > > > > > leaf can be an identityref that defaults to yang-patch. >> > > > > I think this is a good idea. I would prefer the edit-config format >> > > > > over YANG patch for describing a diff. The edit-config format is more >> > > > > suited for this purpose imo. >> > > > +1 >> > > > >> > > > I would like something closer to edit-config to be available via >> > > > RESTCONF as well. >> > > YANG Patch is IMO better because it clearly separates the target for the >> > > edits >> > > from the new content. >> > > In edit-config these two are mixed together. >> > Yes, that is primarily why I prefer the edit-config. I perceive that it >> > is a denser and more efficient format. I think that it is both easier >> > to construct (when diffing two trees) and also more efficient to apply >> > when generating an updated tree. >> >> Except for certain corner cases, for example if two trees differ only in the >> value of a single leaf but this leaf happens to be a list key. >> >> Lada >> >> > >> > Thanks, >> > Rob >> > >> > >> > > That being said, I support specifying format/media-type and having >> > > potentially >> > > multiple options. >> > > >> > > Lada >> > > >> > > > Thanks, >> > > > Rob >> > > > >> > > > >> > > > > /martin >> > > > > >> > > > > _______________________________________________ >> > > > > netmod mailing list >> > > > > netmod@ietf.org >> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= >> > > > > . >> > > > > >> > > > _______________________________________________ >> > > > netmod mailing list >> > > > netmod@ietf.org >> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=RVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Oct 5 01:14:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67EE130DE8 for ; Fri, 5 Oct 2018 01:14:00 -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, 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 sv55wSTyu9xt for ; Fri, 5 Oct 2018 01:13:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 32E96130DC6 for ; Fri, 5 Oct 2018 01:13:58 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 65698182113A; Fri, 5 Oct 2018 10:20:43 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 0A99E1820059; Fri, 5 Oct 2018 10:20:42 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Kent Watsen Cc: "netmod\@ietf.org" In-Reply-To: <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> Mail-Followup-To: Juergen Schoenwaelder , Kent Watsen , "netmod\@ietf.org" Date: Fri, 05 Oct 2018 10:13:55 +0200 Message-ID: <87pnwodd4s.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 08:14:01 -0000 Juergen Schoenwaelder writes: > Folks, the more formats there are, the less interoperability we > get. If there are multiple formats, is there a mandatory to implement > format? Does the mandatory to implement format depend on the protocol > that is being used? This looks nice in theory but let me remind you about the case of choosing a mandatory-to-implement encoding for RESTCONF. The protocols are intended to work with devices of vastly differing capabilities and quite often there is no one-size-fits-all choice. If a device based on a restricted platform cannot implement YANG Patch but does JSON Patch [RFC 6902] instead, it is perfectly fine with me - and certainly more useful than providing no diff at all. Lada > > I prefer one format or if necessary I am fine with one mandatory to > implement format. An open ended collection of implementation specific > formats is super flexible but defeats the purpose of a standard, > namely interoperability. > > /js > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: >> We agree that the diff-format should be client-selectable, modulo what t= he server supports. yang-patch and edit-config both are viable. Should we= document them both? >>=20 >> That said, since neither edit-config nor yang-patch are diffing formats,= so much as formats for converting one data tree to another, would it make = sense to define an actual diffing format? I would think that a diff would = provide both values, not just a new value. >>=20 >> Kent // contributor >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: netmod on behalf of Ladislav Lhotka >> Organization: CZ.NIC >> Date: Thursday, October 4, 2018 at 1:11 PM >> To: Robert Wilton , "netmod@ietf.org" >> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-= 00 >>=20 >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: >> >=20 >> > On 04/10/2018 13:51, Ladislav Lhotka wrote: >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: >> > > > On 04/10/2018 11:14, Martin Bjorklund wrote: >> > > > > Phil Shafer wrote: >> > > > > > Bal?zs Lengyel writes: >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools= .ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00&d=3DDwICAg&c=3DHAk= Yuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa= GTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2= EF3QgRvABgZKsjqzuIw9yUq_xee6aFJOcw&e=3D >> > > > > > [I've moved to a "deep lurker" role here, but ...] >> > > > > >=20 >> > > > > > Can we ensure this model contains a "format" leaf in the RPC's= input >> > > > > > so that future (and proprietary) formats can be supported? T= hat >> > > > > > leaf can be an identityref that defaults to yang-patch. >> > > > > I think this is a good idea. I would prefer the edit-config for= mat >> > > > > over YANG patch for describing a diff. The edit-config format i= s more >> > > > > suited for this purpose imo. >> > > > +1 >> > > >=20 >> > > > I would like something closer to edit-config to be available via >> > > > RESTCONF as well. >> > > YANG Patch is IMO better because it clearly separates the target for= the >> > > edits >> > > from the new content. >> > > In edit-config these two are mixed together. >> > Yes, that is primarily why I prefer the edit-config. I perceive that = it=20 >> > is a denser and more efficient format. I think that it is both easier= =20 >> > to construct (when diffing two trees) and also more efficient to apply= =20 >> > when generating an updated tree. >>=20 >> Except for certain corner cases, for example if two trees differ only in= the >> value of a single leaf but this leaf happens to be a list key. >>=20 >> Lada >>=20 >> >=20 >> > Thanks, >> > Rob >> >=20 >> >=20 >> > > That being said, I support specifying format/media-type and having >> > > potentially >> > > multiple options. >> > >=20 >> > > Lada >> > >=20 >> > > > Thanks, >> > > > Rob >> > > >=20 >> > > >=20 >> > > > > /martin >> > > > >=20 >> > > > > _______________________________________________ >> > > > > netmod mailing list >> > > > > netmod@ietf.org >> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3= voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol= 3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9= n_APQ&e=3D >> > > > > . >> > > > >=20 >> > > > _______________________________________________ >> > > > netmod mailing list >> > > > netmod@ietf.org >> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3vo= DTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3B= OCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_= APQ&e=3D >> --=20 >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWz= oCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3BOCbVLB= arBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e= =3D >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Oct 5 05:11:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674DE130DD0; Wed, 3 Oct 2018 17:14:51 -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 kH19_O7bXYnL; Wed, 3 Oct 2018 17:14:49 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 68F81130DCD; Wed, 3 Oct 2018 17:14:49 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id r64-v6so2431489pfb.13; Wed, 03 Oct 2018 17:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=nBNNrJjwS88RP3pBB1ViUoxbUjt61kHJzSEIbXa5+7M=; b=TjVWjpcVnFHWrvtPaVNAQpTWNZMnnBZkZZx2L06Do7Q+4ZlstACL3BXWbHGWWVF6TS NwymLik0kTF2yf7Jc8V27R37s1L9wmEMEP0yJgGc+xPTq4ghDBdx3BOfqeyhFhx+dUYx rvliwFFQka/EnSeMhmdf+xb8i1B/v12iJTjeiMC4Egx5uZ9+dP5gvUMgGhzqTxOMqEcz yCrjRkvSYlU3aUMwYeHO/EgXR8+5SKGh91CzFdgo6f6q5hRf1N1YPBta4zQMWitwC+y0 D5dhLkDFHD8ISGRnK6+VdlRDIlipkM4b7vZgXHiNnP86lTYK/mpwYrJ5RLE1okqO1Ed2 e8aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nBNNrJjwS88RP3pBB1ViUoxbUjt61kHJzSEIbXa5+7M=; b=PE7OiMuwhW6pOWtj+K3G8oYpytbrHuY1mRj4LZc5AiQIxX7yvybut/JAdesQh7WLTT xgg+cskQ4m9m8TyQZowTXjSB8LMnOal0KvH5jAdOMgWvKGMDTB2JI6E0AuSmBt7llknI l6/LlBZe4llqQQ8y5GJS0+e5eCVJxNNGeUhGjffOxqMprj9BKTqKELpOt5s8IfFOonBe Q5yHVb9GJ8cbbo+RZWYuAx0dIUq1TP04OwPO5Tjd+GOjTlAEv16+DzWFofAYjLv0lOZU op0ys7XFtAy6clyCWJ7QTFk8dOI5pkg1sNlvM4ogpDe8Rf2ym236152jrSsvzk90OXpW hPwQ== X-Gm-Message-State: ABuFfohA8+ixtEOtA52bYbfiIKUL+PI2GC2ofGFdQfdT9CVsovcduKTk pwusaSlBDz6r01EibZ4dJy0= X-Google-Smtp-Source: ACcGV611egdFaB4eSbx3b0/OOPGCTerwP+t9a6jWvO86prxPpuikGMlVL1pFHnxR35oEbsbF3wBIeA== X-Received: by 2002:a63:e05:: with SMTP id d5-v6mr3418254pgl.272.1538612087490; Wed, 03 Oct 2018 17:14:47 -0700 (PDT) Received: from [10.52.174.170] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id w127-v6sm3769783pfd.112.2018.10.03.17.14.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 17:14:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_24434DE6-BE08-4EAD-AA75-F0D839959347" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 3 Oct 2018 17:14:45 -0700 Cc: tom petch , YANG Doctors , Ian Farrer , Yong Cui , terry.manderson@icann.org, Sheng Jiang Message-Id: References: To: Reshad Rehman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 05:11:15 -0700 Subject: Re: [netmod] [yang-doctors] Quirky YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 00:14:52 -0000 --Apple-Mail=_24434DE6-BE08-4EAD-AA75-F0D839959347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Adding softwire chairs, document shepherd, and AD, and moving netmod to = Bcc] Yes. > On Oct 3, 2018, at 4:51 PM, Reshad Rahman (rrahman) = wrote: >=20 > Thanks Mahesh. So the IESG is supposed to ask for YD review at this = point for draft-ietf-softwire-yang? > =20 > From: Mahesh Jethanandani > Date: Wednesday, October 3, 2018 at 7:38 PM > To: "Reshad Rahman (rrahman)" > Cc: tom petch , "netmod@ietf.org" = , YANG Doctors > Subject: Re: [yang-doctors] [netmod] Quirky YANG > =20 > =C2=A0 <> >=20 >=20 >> On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman) = > wrote: >> =20 >> Are YD reviews optional for IETF YANG modules? I assumed it was = mandatory. > =20 > Here is what it says on the YD page: > =20 > All YANG documents will be passed by a YANG doctor reviewer before = they will be approved by the IESG. The YANG doctor review must be done = after the Working Group Last Call and before the IETF Last Call. ADs and = WG chairs responsible on I-Ds that include YANG documents should ask the = OPS ADs for a review as soon as the document completed WGLC. Failing = that request, the review will be conducted during the IETF Last Call. > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_24434DE6-BE08-4EAD-AA75-F0D839959347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Adding softwire chairs, document shepherd, and AD, and = moving netmod to Bcc]

Yes.

On Oct 3, 2018, at 4:51 PM, = Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Thanks Mahesh. So the IESG is supposed to ask = for YD review at this point for draft-ietf-softwire-yang?
 
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Wednesday, October 3, = 2018 at 7:38 PM
To: "Reshad Rahman = (rrahman)" <rrahman@cisco.com>
Cc: tom petch <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>, YANG = Doctors <yang-doctors@ietf.org>
Subject: Re: [yang-doctors] = [netmod] Quirky YANG
 


On Oct 3, 2018, at = 2:41 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:
 
Are YD reviews optional for IETF YANG modules? I = assumed it was mandatory.
 
Here is what it says = on the YD page:
 
All = YANG documents will be passed by a YANG doctor reviewer before they will = be approved by the IESG. The YANG doctor review must be done after the = Working Group Last Call and before the IETF Last Call. ADs and WG chairs = responsible on I-Ds that include YANG documents should ask the OPS ADs = for a review as soon as the document completed WGLC. Failing that = request, the review will be conducted during the IETF Last = Call.
 
Mahesh Jethanandani

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_24434DE6-BE08-4EAD-AA75-F0D839959347-- From nobody Fri Oct 5 05:11:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF76130DE9 for ; Fri, 5 Oct 2018 02:48:21 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcsLUtQiXY35 for ; Fri, 5 Oct 2018 02:48:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D4A130DD8 for ; Fri, 5 Oct 2018 02:48:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A049EB800AE; Fri, 5 Oct 2018 02:48:08 -0700 (PDT) To: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rohitrranade@huawei.com, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181005094808.A049EB800AE@rfc-editor.org> Date: Fri, 5 Oct 2018 02:48:08 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 05:11:16 -0700 Subject: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 09:48:21 -0000 The following errata report has been submitted for RFC8342, "Network Management Datastore Architecture (NMDA)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5514 -------------------------------------- Type: Technical Reported by: Rohit R Ranade Section: C.1 Original Text ------------- bar.example.com eth0 true 1000 100
2001:db8::10 64
2001:db8::1:100 64
lo0
::1 128
Corrected Text -------------- bar.example.com eth0 true 1000 100
2001:db8::10 64
2001:db8::1:100 64
lo0
::1 128
Notes ----- There was no "origin" attribute to the "system" top-level container, though it is a configuration node. As per the extension definition "The origin for any top-level configuration data nodes must be specified." To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". This has already been discussed in the mail chain, but also mentioned here to help readers in future. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8342 (draft-ietf-netmod-revised-datastores-10) -------------------------------------- Title : Network Management Datastore Architecture (NMDA) Publication Date : March 2018 Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Oct 5 05:11:32 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BC0130E0C for ; Fri, 5 Oct 2018 03:14:33 -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 KAJoZYAIdKsd for ; Fri, 5 Oct 2018 03:14:31 -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 2A34C130E02 for ; Fri, 5 Oct 2018 03:14:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B2882C1A; Fri, 5 Oct 2018 12:14:29 +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 otkRO4jdwbP1; Fri, 5 Oct 2018 12:14: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; Fri, 5 Oct 2018 12:14:29 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DB4820037; Fri, 5 Oct 2018 12:14:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YJgr_rVVzG38; Fri, 5 Oct 2018 12:14:28 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 31BA520036; Fri, 5 Oct 2018 12:14:28 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Fri, 5 Oct 2018 12:14:27 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 3F89E3000D0FEE; Fri, 5 Oct 2018 12:14:27 +0200 (CEST) Date: Fri, 5 Oct 2018 12:14:27 +0200 From: Juergen Schoenwaelder To: RFC Errata System CC: , , , , , , , , , Message-ID: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org References: <20181005094808.A049EB800AE@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20181005094808.A049EB800AE@rfc-editor.org> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 05:11:15 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 10:14:34 -0000 Hi, the authors have been discussing whether the top-level requirement is too strict but there has not been a clear conclusion yet I think. In the example, all nodes to have a defined origin and hence the origin at the root will have zero effect. /js On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8342, > "Network Management Datastore Architecture (NMDA)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5514 > > -------------------------------------- > Type: Technical > Reported by: Rohit R Ranade > > Section: C.1 > > Original Text > ------------- > xmlns="urn:example:system" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > bar.example.com > > > eth0 > > true > 1000 > > 100 >
> 2001:db8::10 > 64 >
>
> 2001:db8::1:100 > 64 >
> > > > lo0 >
> ::1 > 128 >
> > > > > Corrected Text > -------------- > xmlns="urn:example:system" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:intended"> > > bar.example.com > > > eth0 > > true > 1000 > > 100 >
> 2001:db8::10 > 64 >
>
> 2001:db8::1:100 > 64 >
> > > > lo0 >
> ::1 > 128 >
> > > > > Notes > ----- > There was no "origin" attribute to the "system" top-level container, though it is a configuration node. > As per the extension definition "The origin for any top-level configuration data nodes must be specified." > > To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". > > This has already been discussed in the mail chain, but also mentioned here to help readers in future. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8342 (draft-ietf-netmod-revised-datastores-10) > -------------------------------------- > Title : Network Management Datastore Architecture (NMDA) > Publication Date : March 2018 > Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton > Category : PROPOSED STANDARD > Source : Network Modeling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 5 05:11:37 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42024130E44 for ; Fri, 5 Oct 2018 03:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 rCnGBf80gLoG for ; Fri, 5 Oct 2018 03:39:33 -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 CFA8A130E02 for ; Fri, 5 Oct 2018 03:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4449; q=dns/txt; s=iport; t=1538735973; x=1539945573; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=MZJ/q8gHDryDMuhgTKKK8AenfYGaXGhK6yONPY+nr5Q=; b=DHrMdUOHB0JbgoBNFtEBknd/6qjhG6+pUFHRN0JydBNnj/BVZO4uQRmS sAtHT1CKm8vXytdq6CDREqVLAumLfeJ6+Hkcpsb9Eu0JvgS9DAqjyikZp 2PBhSGcII9bl1x//UowRZh1yAh+Th6rRZTiHa63hJ3Ue14QKX5fySuspV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAACHPrdb/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgmt/KIN0iHSNKyWWXoF6DSOESQKESzU?= =?us-ascii?q?MDQEDAQECAQECbRwMhToBBSMVUQsSBgICJgICSQ4GAQwGAgEBgx0BggEPo3y?= =?us-ascii?q?BLoQAAXaFG4ELijmBQT+BEicMgl+BQYEdggABAYMfglcCiFckhSJAfI4JCYZ?= =?us-ascii?q?MiXQGF4FMhGWCZ4ZcjzyGKoFEAjSBVTMaCBsVGoMNCYIpg1GFFIUINz4wjA2?= =?us-ascii?q?CPgEB?= X-IronPort-AV: E=Sophos;i="5.54,344,1534809600"; d="scan'208";a="7013945" 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 2018 10:39:30 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w95AdUQW000389; Fri, 5 Oct 2018 10:39:30 GMT To: RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> From: Robert Wilton Message-ID: Date: Fri, 5 Oct 2018 11:39:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 05:11:15 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 10:39:36 -0000 I agree that we need to reach a conclusion on the discussion before we can know what to do with this errata. Thanks, Rob On 05/10/2018 11:14, Juergen Schoenwaelder wrote: > Hi, > > the authors have been discussing whether the top-level requirement is > too strict but there has not been a clear conclusion yet I think. In > the example, all nodes to have a defined origin and hence the origin > at the root will have zero effect. > > /js > > On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: >> The following errata report has been submitted for RFC8342, >> "Network Management Datastore Architecture (NMDA)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5514 >> >> -------------------------------------- >> Type: Technical >> Reported by: Rohit R Ranade >> >> Section: C.1 >> >> Original Text >> ------------- >> > xmlns="urn:example:system" >> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> >> >> bar.example.com >> >> >> eth0 >> >> true >> 1000 >> >> 100 >>
>> 2001:db8::10 >> 64 >>
>>
>> 2001:db8::1:100 >> 64 >>
>> >> >> >> lo0 >>
>> ::1 >> 128 >>
>> >> >> >> >> Corrected Text >> -------------- >> > xmlns="urn:example:system" >> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" >> or:origin="or:intended"> >> >> bar.example.com >> >> >> eth0 >> >> true >> 1000 >> >> 100 >>
>> 2001:db8::10 >> 64 >>
>>
>> 2001:db8::1:100 >> 64 >>
>> >> >> >> lo0 >>
>> ::1 >> 128 >>
>> >> >> >> >> Notes >> ----- >> There was no "origin" attribute to the "system" top-level container, though it is a configuration node. >> As per the extension definition "The origin for any top-level configuration data nodes must be specified." >> >> To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". >> >> This has already been discussed in the mail chain, but also mentioned here to help readers in future. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8342 (draft-ietf-netmod-revised-datastores-10) >> -------------------------------------- >> Title : Network Management Datastore Architecture (NMDA) >> Publication Date : March 2018 >> Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton >> Category : PROPOSED STANDARD >> Source : Network Modeling >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From nobody Fri Oct 5 06:54:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E6130DF6 for ; Fri, 5 Oct 2018 05:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhG7hQo4y6x3 for ; Fri, 5 Oct 2018 05:33:33 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 AB35F130E66 for ; Fri, 5 Oct 2018 05:33:33 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 0AB0F418C9 for ; Fri, 5 Oct 2018 06:14:36 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 8P07gfk71vdTu8P07g2Sag; Fri, 05 Oct 2018 06:14:36 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=be1L/Ms/lDT3Kt8ZzRDLy2GWqEudRK6K7AcSkkuRtwc=; b=I4P1ZKgrKoNGWgCRFFcmIYfOU9 HaVjbmPdscKhiLBirzyPX8tY3YWVn2VQSuFc/5fo8Mmml19jSxh4XFKOlFRf8jrg7vF4KSjcuHLpO PzfyYSmh/avaYWvW7a6uV1cD5; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:57682 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g8P07-0047yk-Jc; Fri, 05 Oct 2018 06:14:35 -0600 To: RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, rohitrranade@huawei.com, netmod@ietf.org References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> From: Lou Berger Message-ID: <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> Date: Fri, 5 Oct 2018 08:14:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g8P07-0047yk-Jc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:57682 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 06:54:36 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 12:33:36 -0000 Juergen,     The document says what it says, i.e., "The origin for any top-level configuration data nodes must be specified."  Changes to this would require a BIS or an RFC that updates this document. Lou On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote: > Hi, > > the authors have been discussing whether the top-level requirement is > too strict but there has not been a clear conclusion yet I think. In > the example, all nodes to have a defined origin and hence the origin > at the root will have zero effect. > > /js > > On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: >> The following errata report has been submitted for RFC8342, >> "Network Management Datastore Architecture (NMDA)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5514 >> >> -------------------------------------- >> Type: Technical >> Reported by: Rohit R Ranade >> >> Section: C.1 >> >> Original Text >> ------------- >> > xmlns="urn:example:system" >> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> >> >> bar.example.com >> >> >> eth0 >> >> true >> 1000 >> >> 100 >>
>> 2001:db8::10 >> 64 >>
>>
>> 2001:db8::1:100 >> 64 >>
>> >> >> >> lo0 >>
>> ::1 >> 128 >>
>> >> >> >> >> Corrected Text >> -------------- >> > xmlns="urn:example:system" >> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" >> or:origin="or:intended"> >> >> bar.example.com >> >> >> eth0 >> >> true >> 1000 >> >> 100 >>
>> 2001:db8::10 >> 64 >>
>>
>> 2001:db8::1:100 >> 64 >>
>> >> >> >> lo0 >>
>> ::1 >> 128 >>
>> >> >> >> >> Notes >> ----- >> There was no "origin" attribute to the "system" top-level container, though it is a configuration node. >> As per the extension definition "The origin for any top-level configuration data nodes must be specified." >> >> To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". >> >> This has already been discussed in the mail chain, but also mentioned here to help readers in future. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8342 (draft-ietf-netmod-revised-datastores-10) >> -------------------------------------- >> Title : Network Management Datastore Architecture (NMDA) >> Publication Date : March 2018 >> Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton >> Category : PROPOSED STANDARD >> Source : Network Modeling >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From nobody Fri Oct 5 09:48:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D31292AD for ; Fri, 5 Oct 2018 07:28:24 -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 NoN2KwIP3hTE for ; Fri, 5 Oct 2018 07:28:21 -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 8DD2D124C04 for ; Fri, 5 Oct 2018 07:28:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3551476; Fri, 5 Oct 2018 16:28:20 +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 rOLsS78kKz-K; Fri, 5 Oct 2018 16:28:18 +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; Fri, 5 Oct 2018 16:28:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A78020037; Fri, 5 Oct 2018 16:28:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SXO2JxT7ngGp; Fri, 5 Oct 2018 16:28:19 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 63F9920036; Fri, 5 Oct 2018 16:28:18 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Fri, 5 Oct 2018 16:28:17 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 6FF303000D1764; Fri, 5 Oct 2018 16:28:17 +0200 (CEST) Date: Fri, 5 Oct 2018 16:28:16 +0200 From: Juergen Schoenwaelder To: Lou Berger CC: RFC Errata System , , , , , , , , , Message-ID: <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, rohitrranade@huawei.com, netmod@ietf.org References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> 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: <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 09:48:17 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 14:28:24 -0000 Well, if you think an errata does not work, we can file a one page document with N pages of boilerplate around it. /js On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote: > Juergen, > >     The document says what it says, i.e., "The origin for any top-level > configuration data nodes must be specified."  Changes to this would require > a BIS or an RFC that updates this document. > > Lou > > > On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote: > > Hi, > > > > the authors have been discussing whether the top-level requirement is > > too strict but there has not been a clear conclusion yet I think. In > > the example, all nodes to have a defined origin and hence the origin > > at the root will have zero effect. > > > > /js > > > > On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: > > > The following errata report has been submitted for RFC8342, > > > "Network Management Datastore Architecture (NMDA)". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata/eid5514 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Rohit R Ranade > > > > > > Section: C.1 > > > > > > Original Text > > > ------------- > > > > > xmlns="urn:example:system" > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > > > > bar.example.com > > > > > > > > > eth0 > > > > > > true > > > 1000 > > > > > > 100 > > >
> > > 2001:db8::10 > > > 64 > > >
> > >
> > > 2001:db8::1:100 > > > 64 > > >
> > > > > > > > > > > > lo0 > > >
> > > ::1 > > > 128 > > >
> > > > > > > > > > > > > > > Corrected Text > > > -------------- > > > > > xmlns="urn:example:system" > > > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > > or:origin="or:intended"> > > > > > > bar.example.com > > > > > > > > > eth0 > > > > > > true > > > 1000 > > > > > > 100 > > >
> > > 2001:db8::10 > > > 64 > > >
> > >
> > > 2001:db8::1:100 > > > 64 > > >
> > > > > > > > > > > > lo0 > > >
> > > ::1 > > > 128 > > >
> > > > > > > > > > > > > > > Notes > > > ----- > > > There was no "origin" attribute to the "system" top-level container, though it is a configuration node. > > > As per the extension definition "The origin for any top-level configuration data nodes must be specified." > > > > > > To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". > > > > > > This has already been discussed in the mail chain, but also mentioned here to help readers in future. > > > > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached, the verifying party > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC8342 (draft-ietf-netmod-revised-datastores-10) > > > -------------------------------------- > > > Title : Network Management Datastore Architecture (NMDA) > > > Publication Date : March 2018 > > > Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton > > > Category : PROPOSED STANDARD > > > Source : Network Modeling > > > Area : Operations and Management > > > Stream : IETF > > > Verifying Party : IESG > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Oct 5 09:48:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B8E130E29 for ; Fri, 5 Oct 2018 09:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg9P98dAg0p6 for ; Fri, 5 Oct 2018 09:13:41 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 97626130E17 for ; Fri, 5 Oct 2018 09:13:41 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 006171E0DCE for ; Fri, 5 Oct 2018 10:13:40 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 8Siog5r5Wo6eD8Sj9gVzYn; Fri, 05 Oct 2018 10:13:37 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=01LWgARdhlFfFzX2gEnMmFdLsmoWP9HF3dghDu4U0mU=; b=RXUTOTVMJyqkZMl5aPkrcOYZMX CT59mJiy39n9XRjU9AI8OBEkNss73lsktE8KiQXJztaupJi3DGP1w7svIKWaJ5PE+BE4chlUPsEeo NkWLugtIQMxoWNFifnnjpyrqQ; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:49432 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g8Sio-000q7V-By; Fri, 05 Oct 2018 10:12:58 -0600 To: RFC Errata System , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, rohitrranade@huawei.com, netmod@ietf.org References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> From: Lou Berger Message-ID: <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> Date: Fri, 5 Oct 2018 12:12:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g8Sio-000q7V-By X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:49432 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 09:48:17 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 16:13:46 -0000 My personal opinion (with any hat on) is that it isn't appropriate to make a technical change that impacts implementation in an errata.  Clarifications of original intent, corrections of inconsistencies and editorial corrections are perfectly appropriate.  I'm happy to learn that this intended use/scope of errata is wrong. Lou On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote: > Well, if you think an errata does not work, we can file a one page > document with N pages of boilerplate around it. > > /js > > On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote: >> Juergen, >> >>     The document says what it says, i.e., "The origin for any top-level >> configuration data nodes must be specified."  Changes to this would require >> a BIS or an RFC that updates this document. >> >> Lou >> >> >> On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote: >>> Hi, >>> >>> the authors have been discussing whether the top-level requirement is >>> too strict but there has not been a clear conclusion yet I think. In >>> the example, all nodes to have a defined origin and hence the origin >>> at the root will have zero effect. >>> >>> /js >>> >>> On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC8342, >>>> "Network Management Datastore Architecture (NMDA)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata/eid5514 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Rohit R Ranade >>>> >>>> Section: C.1 >>>> >>>> Original Text >>>> ------------- >>>> >>> xmlns="urn:example:system" >>>> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> >>>> >>>> bar.example.com >>>> >>>> >>>> eth0 >>>> >>>> true >>>> 1000 >>>> >>>> 100 >>>>
>>>> 2001:db8::10 >>>> 64 >>>>
>>>>
>>>> 2001:db8::1:100 >>>> 64 >>>>
>>>> >>>> >>>> >>>> lo0 >>>>
>>>> ::1 >>>> 128 >>>>
>>>> >>>> >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> >>> xmlns="urn:example:system" >>>> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" >>>> or:origin="or:intended"> >>>> >>>> bar.example.com >>>> >>>> >>>> eth0 >>>> >>>> true >>>> 1000 >>>> >>>> 100 >>>>
>>>> 2001:db8::10 >>>> 64 >>>>
>>>>
>>>> 2001:db8::1:100 >>>> 64 >>>>
>>>> >>>> >>>> >>>> lo0 >>>>
>>>> ::1 >>>> 128 >>>>
>>>> >>>> >>>> >>>> >>>> Notes >>>> ----- >>>> There was no "origin" attribute to the "system" top-level container, though it is a configuration node. >>>> As per the extension definition "The origin for any top-level configuration data nodes must be specified." >>>> >>>> To choose an extension for top-level container in such cases, I would prefer one of the origin of its children and used "intended". , instead of "unknown". >>>> >>>> This has already been discussed in the mail chain, but also mentioned here to help readers in future. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC8342 (draft-ietf-netmod-revised-datastores-10) >>>> -------------------------------------- >>>> Title : Network Management Datastore Architecture (NMDA) >>>> Publication Date : March 2018 >>>> Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton >>>> Category : PROPOSED STANDARD >>>> Source : Network Modeling >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Oct 5 10:05:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0FA130E29 for ; Fri, 5 Oct 2018 09:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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=yumaworks-com.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 mLpnZSy_zDZw for ; Fri, 5 Oct 2018 09:53:35 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 07783130DC1 for ; Fri, 5 Oct 2018 09:53:35 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id a82-v6so9834874lfa.4 for ; Fri, 05 Oct 2018 09:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lYQYKYShP+OBYnC+EK90dX3FNfKQnxq4bfvj1LRzrgk=; b=eQBd0QnSEG+OUDw0LdgFsZavmCPUX3SfMFImSDoiU9auC5IMCNTwHITDin+xNApyMI +eimqWzZnaAQ/E44hTY3kfD/vJCUl9TZAtRUJ3QjVM7kEZp8wB054LEqkLjgokkWjt5l 7nN/JBeBs+w5VwqWqYD5142pa+9E2tHwRqhT789Hc8t4wxA8hkpf3Gi/y8flX19MJ0Pw jXegzXY79bH9p0180bw0Jfxhw93V70fGutlfB5pVdgnUs2wQz5z7ergLNt26jSTBsc5u R+Mto9CtTx7ZbuIOtyxDBov3YLaVDob78OGAiucWVbBwIvB7CyfLq2+TXG7VNzURH/02 wyYg== 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=lYQYKYShP+OBYnC+EK90dX3FNfKQnxq4bfvj1LRzrgk=; b=JM4Wl4lrUKpCeI9FluzfUOXfI5eYA6U5dcxjv+7pqTTSYd4zUB1btJusFK20hUAuJj BbUfmPvauAvIPlsdabyph6ud9J2DMGtRPkFL52SpDjq7PuLe/qhPm4F4qP8A5IgL7Cam yAqqtlbKey87fsoaUCelYi3uarHJF4nbS3anKcYO5k4MQ7CO0CF6cBfVFQV+DamPxnOg +ObF3Xs+p5fKtgw9ZDl74GcQSP/scq4CxkGP0h42xaz+CGCsLs7XEAoikoTx7UbMbamf ul/eHwdDE3zt/4Cx6/VSgcq4ewObUKxjPaLQErnkZGs7pePL5LbZfF4qknrhaFuqqlre XoAQ== X-Gm-Message-State: ABuFfoidXbXr4ZUNjNJpOW+nIYlp6UmeX1HwMpqeUuccxyUqXaIYgyQv x4KlR44qvwmuTN9ZmmiMFc1jn0XmY+DbGyYsc00h+Q== X-Google-Smtp-Source: ACcGV60Ztcf3qg6aoiiD9qBReSYVCRfXVHQ98GRTDy1kK/aw8QQkqE5REw+7O6g4K3hh1bVgsCiNsTDf/sPyQFAUA+o= X-Received: by 2002:a19:f00a:: with SMTP id p10-v6mr7053617lfc.43.1538758413078; Fri, 05 Oct 2018 09:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Fri, 5 Oct 2018 09:53:32 -0700 (PDT) In-Reply-To: <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> From: Andy Bierman Date: Fri, 5 Oct 2018 09:53:32 -0700 Message-ID: To: Lou Berger Cc: RFC Errata System , Martin Bjorklund , Phil Shafer , Kent Watsen , Robert Wilton , Ignas Bagdonas , Warren Kumari , Joel Jaeggli , Rohit R Ranade , NetMod WG Content-Type: multipart/alternative; boundary="0000000000009b6b0d05777e1c7f" Archived-At: X-Mailman-Approved-At: Fri, 05 Oct 2018 10:05:15 -0700 Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 16:53:39 -0000 --0000000000009b6b0d05777e1c7f Content-Type: text/plain; charset="UTF-8" On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger wrote: > My personal opinion (with any hat on) is that it isn't appropriate to make > a technical change that impacts implementation in an errata. > Clarifications of original intent, corrections of inconsistencies and > editorial corrections are perfectly appropriate. I'm happy to learn that > this intended use/scope of errata is wrong. > > Strongly agree. Errata cannot be used to change technical decisions. It can only be used to correct text that is incorrect. > Lou > Andy > > > On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote: > >> Well, if you think an errata does not work, we can file a one page >> document with N pages of boilerplate around it. >> >> /js >> >> On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote: >> >>> Juergen, >>> >>> The document says what it says, i.e., "The origin for any top-level >>> configuration data nodes must be specified." Changes to this would >>> require >>> a BIS or an RFC that updates this document. >>> >>> Lou >>> >>> >>> On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote: >>> >>>> Hi, >>>> >>>> the authors have been discussing whether the top-level requirement is >>>> too strict but there has not been a clear conclusion yet I think. In >>>> the example, all nodes to have a defined origin and hence the origin >>>> at the root will have zero effect. >>>> >>>> /js >>>> >>>> On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC8342, >>>>> "Network Management Datastore Architecture (NMDA)". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata/eid5514 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Rohit R Ranade >>>>> >>>>> Section: C.1 >>>>> >>>>> Original Text >>>>> ------------- >>>>> >>>> xmlns="urn:example:system" >>>>> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> >>>>> >>>>> bar.example.com >>>>> >>>>> >>>>> eth0 >>>>> >>>>> true >>>>> 1000 >>>>> >>>>> 100 >>>>>
>>>>> 2001:db8::10 >>>>> 64 >>>>>
>>>>>
>>>>> 2001:db8::1:100 >>>>> 64 >>>>>
>>>>> >>>>> >>>>> >>>>> lo0 >>>>>
>>>>> ::1 >>>>> 128 >>>>>
>>>>> >>>>> >>>>> >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> >>>> xmlns="urn:example:system" >>>>> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" >>>>> or:origin="or:intended"> >>>>> >>>>> bar.example.com >>>>> >>>>> >>>>> eth0 >>>>> >>>>> true >>>>> 1000 >>>>> >>>>> 100 >>>>>
>>>>> 2001:db8::10 >>>>> 64 >>>>>
>>>>>
>>>>> 2001:db8::1:100 >>>>> 64 >>>>>
>>>>> >>>>> >>>>> >>>>> lo0 >>>>>
>>>>> ::1 >>>>> 128 >>>>>
>>>>> >>>>> >>>>> >>>>> >>>>> Notes >>>>> ----- >>>>> There was no "origin" attribute to the "system" top-level container, >>>>> though it is a configuration node. >>>>> As per the extension definition "The origin for any top-level >>>>> configuration data nodes must be specified." >>>>> >>>>> To choose an extension for top-level container in such cases, I would >>>>> prefer one of the origin of its children and used "intended". , instead of >>>>> "unknown". >>>>> >>>>> This has already been discussed in the mail chain, but also mentioned >>>>> here to help readers in future. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party >>>>> can log in to change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC8342 (draft-ietf-netmod-revised-datastores-10) >>>>> -------------------------------------- >>>>> Title : Network Management Datastore Architecture (NMDA) >>>>> Publication Date : March 2018 >>>>> Author(s) : M. Bjorklund, J. Schoenwaelder, P. Shafer, K. >>>>> Watsen, R. Wilton >>>>> Category : PROPOSED STANDARD >>>>> Source : Network Modeling >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> >>>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000009b6b0d05777e1c7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <lberger@labn.net> wrote:
My personal opinion (with any= hat on) is that it isn't appropriate to make a technical change that i= mpacts implementation in an errata.=C2=A0 Clarifications of original intent= , corrections of inconsistencies and editorial corrections are perfectly ap= propriate.=C2=A0 I'm happy to learn that this intended use/scope of err= ata is wrong.


Strongly agree.
Errata canno= t be used to change technical decisions.
It can only be used to c= orrect text that is incorrect.
=C2=A0
Lou

Andy
=C2=A0


On 10/5/2018 10:28 AM, Juergen Schoenwaelder wrote:
Well, if you think an errata does not work, we can file a one page
document with N pages of boilerplate around it.

/js

On Fri, Oct 05, 2018 at 08:14:33AM -0400, Lou Berger wrote:
Juergen,

=C2=A0=C2=A0=C2=A0=C2=A0 The document says what it says, i.e., "The or= igin for any top-level
configuration data nodes must be specified."=C2=A0 Changes to this wou= ld require
a BIS or an RFC that updates this document.

Lou


On 10/5/2018 6:14 AM, Juergen Schoenwaelder wrote:
Hi,

the authors have been discussing whether the top-level requirement is
too strict but there has not been a clear conclusion yet I think. In
the example, all nodes to have a defined origin and hence the origin
at the root will have zero effect.

/js

On Fri, Oct 05, 2018 at 02:48:08AM -0700, RFC Errata System wrote:
The following errata report has been submitted for RFC8342,
"Network Management Datastore Architecture (NMDA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5514

--------------------------------------
Type: Technical
Reported by: Rohit R Ranade <rohitrranade@huawei.com>

Section: C.1

Original Text
-------------
=C2=A0 =C2=A0 =C2=A0<system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:example:system" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:or=3D"urn:ietf:params:xml= :ns:yang:ietf-origin">

=C2=A0 =C2=A0 =C2=A0 =C2=A0<hostname or:origin=3D"or:learned"&= gt;= bar.example.com</hostname>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface or:origin=3D"or:intended"= ;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<auto-negotiation>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled or:origin=3D"or:d= efault">true</enabled>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<speed>1000</speed> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</auto-negotiation>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<speed>100</speed>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>2001:db8::10</ip><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>64</prefix= -length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address or:origin=3D"or:learned&= quot;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>2001:db8::1:100</ip&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>64</prefix= -length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface or:origin=3D"or:system"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>lo0</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>::1</ip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>128</prefi= x-length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>

=C2=A0 =C2=A0 =C2=A0</system>

Corrected Text
--------------
=C2=A0 =C2=A0 =C2=A0<system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:example:system" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:or=3D"urn:ietf:params:xml= :ns:yang:ietf-origin"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or:origin=3D"or:intended">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<hostname or:origin=3D"or:learned"&= gt;= bar.example.com</hostname>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface or:origin=3D"or:intended"= ;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<auto-negotiation>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled or:origin=3D"or:d= efault">true</enabled>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<speed>1000</speed> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</auto-negotiation>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<speed>100</speed>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>2001:db8::10</ip><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>64</prefix= -length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address or:origin=3D"or:learned&= quot;>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>2001:db8::1:100</ip&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>64</prefix= -length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface or:origin=3D"or:system"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>lo0</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ip>::1</ip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<prefix-length>128</prefi= x-length>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</address>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>

=C2=A0 =C2=A0 =C2=A0</system>

Notes
-----
There was no "origin" attribute to the "system" top-lev= el container, though it is a configuration node.
As per the extension definition "The origin for any top-level configur= ation data nodes must be specified."

To choose an extension for top-level container in such cases, I would prefe= r one of the origin of its children and used "intended". , instea= d of "unknown".

This has already been discussed in the mail chain, but also mentioned here = to help readers in future.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8342 (draft-ietf-netmod-revised-datastores-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Network Manag= ement Datastore Architecture (NMDA)
Publication Date=C2=A0 =C2=A0 : March 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund, J. Schoen= waelder, P. Shafer, K. Watsen, R. Wilton
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Modeling Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

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

--0000000000009b6b0d05777e1c7f-- From nobody Fri Oct 5 10:58:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC36130E6E for ; Fri, 5 Oct 2018 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFz1JEuMMzZT for ; Fri, 5 Oct 2018 10:58:25 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 26537130DF6 for ; Fri, 5 Oct 2018 10:58:25 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 1AD55140534 for ; Fri, 5 Oct 2018 11:58:24 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 8UMpgB3LAj0so8UMpgofQO; Fri, 05 Oct 2018 11:58:24 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gudoOtOrCAtiVE+ic6F/TU3/Ua1b132AH5v7ZqN71hE=; b=x/ETBdsfIhqklDSlzNYfn5R2dN G0ghY8RfGYOBR8NXFu04wZCovN5SfyXe5Gg8Ja9qU9dnf7VmzjgMY2RzflZXKrJnGOH2q0T9EB6V9 uPYT0y4D3XmQ419J2wzE7EO13; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:34460 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g8UMp-001LxO-JD; Fri, 05 Oct 2018 11:58:23 -0600 From: Lou Berger To: Balazs Lengyel , Benoit Claise Cc: NetMod WG Chairs , NetMod WG Message-ID: <44adc67a-6e29-423e-6155-0a9db4797500@labn.net> Date: Fri, 5 Oct 2018 13:58:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g8UMp-001LxO-JD X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:34460 X-Source-Auth: lberger@labn.net X-Email-Count: 15 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] Regarding IPR on draft-lengyel-netmod-yang-instance-data-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 17:58:28 -0000 Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NetMod WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Fri Oct 5 21:35:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E8E130E44; Fri, 5 Oct 2018 21:35:45 -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 UjBvjKBGJz7A; Fri, 5 Oct 2018 21:35: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 8364A130DC5; Fri, 5 Oct 2018 21:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1796; q=dns/txt; s=iport; t=1538800542; x=1540010142; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9HgSQA4AE/6Dt824P/wkMjEyM/Hy7dP1+oLxzkdZjwo=; b=GWhr0exZQqTB6b98n9XvhK2wx3tyirQcBkj/JDtdu9Efc3vd/OT6QmDV CYM3WMhf9qLVYQxyvVy1YZy+Z36YuS8uqY0Dolnq7AUQ7IYqJcJSezpFP MKkKu19khcGFWcnjl20xDrb6bWGJ6l8R+UbGeIdqnuk0HM1877N/Hv9Ku I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAADPOrhb/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCa20SKASDcIh0pEqBZg0jhEkChFA3Cg0BAwE?= =?us-ascii?q?BAgEBAm0cDIU6BiMVPAUQCw4MAiYCAlcGAQwIAQGDHQGCAQ+kJoEuhHeFIYE?= =?us-ascii?q?Lij6BQT+BEieCa4MQCwKBLgESAYMgglcCiEeGHY8FCYZMiXQGF4FNS4Qagme?= =?us-ascii?q?GXIwkgx+GKoFYImRxMxoIGxU7gm0Iiw6FQD0xiwiCPgEB?= X-IronPort-AV: E=Sophos;i="5.54,347,1534809600"; d="scan'208";a="6977816" 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; 06 Oct 2018 04:35:40 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w964ZdUc026355; Sat, 6 Oct 2018 04:35:40 GMT To: Lou Berger , Balazs Lengyel Cc: NetMod WG Chairs , NetMod WG References: <44adc67a-6e29-423e-6155-0a9db4797500@labn.net> From: Benoit Claise Message-ID: Date: Sat, 6 Oct 2018 06:35:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <44adc67a-6e29-423e-6155-0a9db4797500@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Outbound-SMTP-Client: 10.55.221.36, ams-bclaise-nitro3.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] Regarding IPR on draft-lengyel-netmod-yang-instance-data-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2018 04:35:46 -0000 "No, I'm not aware of any IPR that applies to this draft" Regards, B. > Authors, Contributors, WG, > > As part of preparation for WG Adoption > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NetMod WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > . > From nobody Sat Oct 6 23:47:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60A41292F1 for ; Sat, 6 Oct 2018 23:47:28 -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 IG9qu7qxsaxd for ; Sat, 6 Oct 2018 23:47:26 -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 1CBF3128D0C for ; Sat, 6 Oct 2018 23:47:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 22BAE9A; Sun, 7 Oct 2018 08:47:24 +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 07So4klB7eif; Sun, 7 Oct 2018 08:47:21 +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; Sun, 7 Oct 2018 08:47:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00E7020037; Sun, 7 Oct 2018 08:47:24 +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 szdU-_l51B-Y; Sun, 7 Oct 2018 08:47:23 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 306D120036; Sun, 7 Oct 2018 08:47:23 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Sun, 7 Oct 2018 08:47:22 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 54E933000D5D0B; Sun, 7 Oct 2018 08:47:21 +0200 (CEST) Date: Sun, 7 Oct 2018 08:47:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman CC: Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System Message-ID: <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 06:47:29 -0000 On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote: > On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger wrote: > > > My personal opinion (with any hat on) is that it isn't appropriate to make > > a technical change that impacts implementation in an errata. > > Clarifications of original intent, corrections of inconsistencies and > > editorial corrections are perfectly appropriate. I'm happy to learn that > > this intended use/scope of errata is wrong. > > > > > Strongly agree. > Errata cannot be used to change technical decisions. > It can only be used to correct text that is incorrect. > So far so good but we all know that at the end its a judgement call. The intention of the text was to ensure that there is always a defined origin value. One way to achieve that is to have an origin defined at the root. But there are obviously other possibilities to achieve the intended goal, as the example demonstrates. While we can for sure add an origin at the root in the example, it serves no purpose. In other words, the example demonstrates that we failed to reinforce this by saying "every config data node needs to have a defined origin value and one way to achieve that is to define origin's are the roots of the subtrees" but instead we created the rule "all roots of the subtrees must have a defined origin value", which in certain approaches to maintain origin metadata and generate origin attributes is more a CLR. But sure, if people want to close this discussion on formal grounds, so be it. We will just have introduced a CLR. /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 Sun Oct 7 09:50:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0712DD85 for ; Sun, 7 Oct 2018 09:50:03 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 6rj-Q8GKWCvq for ; Sun, 7 Oct 2018 09:50:01 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 CF8C5127333 for ; Sun, 7 Oct 2018 09:50:00 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id u21-v6so15701476lja.8 for ; Sun, 07 Oct 2018 09:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=h6p3h1abnE25ADD1navDvpqIS1XZ0e2YUSl7Qo3wlOc=; b=qGaeLovnJ4GBh9RwSqyVpORenpt00iVggcT27PNGEF04d7FuIAlhJdXG4g5EephP+O p1FNDuU4LbuJ0ytNw/bXyDbOC7SFCke2bk30awvCV1cT2mTgJzo+txfOmpO56xcxZ5GM Nyt0jZbVp61hpRsgDvfMUrgRQOTjlmBT74vE2uXzFrnruFK1G4jycOTDocnL9gRnYTWY VRSNAQMI4hKZpC3NcdDeX7RBrzATyP6lmemoI9kqFr8rwuaWTI1LfCR4cFbO5FGI3a1s Yb4tR3Q1JJymPiJtlpla8nvs0aPLgqLph3Q5AnxuFlx2oF80KfveRzwCLt8XvCpp3Dzt mhHA== 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=h6p3h1abnE25ADD1navDvpqIS1XZ0e2YUSl7Qo3wlOc=; b=HXMIH0Egrn4QhFrvm+4ML5dvi1BEqogfHFEUE54Vhfj7K7SZNsRj1mOKc+aTznjGPh U/TU2ycQDmMvbWLxO1z1kgbzy3B8HN3pjX8m6QNDozEWCs6Im8xPfkEhWsk6/w7+Zrvi koxIdIRf9gTVpBGQKmWHRDfhf/u/UMvaRpiY/V2VwPJ5akOn1N6LPFwtbc+Ms4K8SZ6/ sxmfNpCp6S1gqtxCR4hZCGeifeQL4sfLIpLAWLFOVnPS2wDoikoKhTbe30mYGQEZFwU+ 2RpM8CBQjiNgkLXWoI6Fr3IEqBaf5ssk+Mmu6upcwg/4WMoF0Pf7ZG6KwZoQsQHaiQ4i bduA== X-Gm-Message-State: ABuFfogkOVfhhdgK6qfxIFBACAxpM77yFN9v7Gnh8UdW14VGZZdx9prc LkoBhjG63b9MoXUqRrOTm/MlMQUsr/izlOr9OooeTg== X-Google-Smtp-Source: ACcGV627BENu2JcVeH5KnI1pQKRwJ6qfXxgNfkmSOVA7PcNWydVASVZS0eUcVdcQhdSZtTntojSzrYb76Ph/uuwznbU= X-Received: by 2002:a2e:9047:: with SMTP id n7-v6mr10856813ljg.10.1538930998772; Sun, 07 Oct 2018 09:49:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Sun, 7 Oct 2018 09:49:57 -0700 (PDT) In-Reply-To: <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Sun, 7 Oct 2018 09:49:57 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System Content-Type: multipart/alternative; boundary="0000000000008419120577a64b8d" Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 16:50:04 -0000 --0000000000008419120577a64b8d Content-Type: text/plain; charset="UTF-8" On Sat, Oct 6, 2018 at 11:47 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote: > > On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger wrote: > > > > > My personal opinion (with any hat on) is that it isn't appropriate to > make > > > a technical change that impacts implementation in an errata. > > > Clarifications of original intent, corrections of inconsistencies and > > > editorial corrections are perfectly appropriate. I'm happy to learn > that > > > this intended use/scope of errata is wrong. > > > > > > > > Strongly agree. > > Errata cannot be used to change technical decisions. > > It can only be used to correct text that is incorrect. > > > > So far so good but we all know that at the end its a judgement call. > > The intention of the text was to ensure that there is always a defined > origin value. One way to achieve that is to have an origin defined at > the root. But there are obviously other possibilities to achieve the > intended goal, as the example demonstrates. While we can for sure add > an origin at the root in the example, it serves no purpose. In other > words, the example demonstrates that we failed to reinforce this by > saying "every config data node needs to have a defined origin value > and one way to achieve that is to define origin's are the roots of the > subtrees" but instead we created the rule "all roots of the subtrees > must have a defined origin value", which in certain approaches to > maintain origin metadata and generate origin attributes is more a CLR. > > But sure, if people want to close this discussion on formal grounds, > so be it. We will just have introduced a CLR. > > 5.3.4 . Origin Metadata Annotation As configuration flows into , it is conceptually marked with a metadata annotation [RFC7952 ] that indicates its origin.* The origin applies to all configuration nodes except non-presence containers. * md:annotation origin { type origin-ref; description "The 'origin' annotation can be present on any configuration data node in the operational state datastore. It specifies from where the node originated. If not specified for a given configuration data node, then the origin is the same as the origin of its parent node in the data tree. * The origin for any top-level configuration data nodes must be specified.*"; } Can somebody explain the rationale for the highlighted text from 5.3.4? There are many top-level configuration NP-containers defined already. It is clearly more efficient to have 1 origin attribute in the top-level container than in each of the child nodes. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000008419120577a64b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 6, 2018 at 11:47 PM, Juer= gen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Fri, Oct 05, 2018 at 09:53:32AM -0700, Andy Bierman wrote:
> On Fri, Oct 5, 2018 at 9:12 AM, Lou Berger <lberger@labn.net> wrote:
>
> > My personal opinion (with any hat on) is that it isn't approp= riate to make
> > a technical change that impacts implementation in an errata.
> > Clarifications of original intent, corrections of inconsistencies= and
> > editorial corrections are perfectly appropriate.=C2=A0 I'm ha= ppy to learn that
> > this intended use/scope of errata is wrong.
> >
> >
> Strongly agree.
> Errata cannot be used to change technical decisions.
> It can only be used to correct text that is incorrect.
>

So far so good but we all know that at the end its a judgement call.

The intention of the text was to ensure that there is always a defined
origin value. One way to achieve that is to have an origin defined at
the root. But there are obviously other possibilities to achieve the
intended goal, as the example demonstrates. While we can for sure add
an origin at the root in the example, it serves no purpose. In other
words, the example demonstrates that we failed to reinforce this by
saying "every config data node needs to have a defined origin value and one way to achieve that is to define origin's are the roots of the<= br> subtrees" but instead we created the rule "all roots of the subtr= ees
must have a defined origin value", which in certain approaches to
maintain origin metadata and generate origin attributes is more a CLR.

But sure, if people want to close this discussion on formal grounds,
so be it. We will just have introduced a CLR.


5.3.4.  Origin Metadata Annotation


   As configuration flows into <operational>, it is conceptually mark=
ed
   with a metadata annotation [RFC7952=
] that indicates its origin.  The
   origin applies to all configuration nodes except non-presence
   containers.
=C2=A0

    md:annotation origin {
       type origin-ref;
       description
         "The 'origin' annotation can be present on any config=
uration
          data node in the operational state datastore.  It specifies
          from where the node originated.  If not specified for a given
          configuration data node, then the origin is the same as the
          origin of its parent node in the data tree.  The origin for
          any top-level configuration data nodes must be specified.&quo=
t;;
     }

<= br>Can somebody explain the rationale for the highlighted text from 5.3.4?<= br>There are many top-level configuration NP-containers defined already.
It is clearly more efficient to have 1 origin attribute in the top-= level container
than in each of the child nodes.



=

/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

--0000000000008419120577a64b8d-- From nobody Sun Oct 7 10:09:17 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526E5130DE9 for ; Sun, 7 Oct 2018 10:09:15 -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 ufP3ylU06ITO for ; Sun, 7 Oct 2018 10:09:13 -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 99D05127333 for ; Sun, 7 Oct 2018 10:09:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 22DBC3D; Sun, 7 Oct 2018 19:09:10 +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 VSD4pdteyHn2; Sun, 7 Oct 2018 19:09:07 +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; Sun, 7 Oct 2018 19:09:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01CDB20037; Sun, 7 Oct 2018 19:09:10 +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 8CiuSTfFI0k5; Sun, 7 Oct 2018 19:09:09 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6DA1120036; Sun, 7 Oct 2018 19:09:08 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Sun, 7 Oct 2018 19:09:07 +0200 Received: by anna.localdomain (Postfix, from userid 501) id ADFE53000D6B97; Sun, 7 Oct 2018 19:09:07 +0200 (CEST) Date: Sun, 7 Oct 2018 19:09:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman CC: Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System Message-ID: <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 17:09:15 -0000 On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote: > > Can somebody explain the rationale for the highlighted text from 5.3.4? Note the difference between "applies to" and "carries". A non-presence container has no relevance for configuration and hence an origin value does not *apply* to a non-presence container. Still, a non-presence container can *carry* an origin attribute. > There are many top-level configuration NP-containers defined already. > It is clearly more efficient to have 1 origin attribute in the top-level > container than in each of the child nodes. There is no requirement to produce efficient encodings. This is up to implementations, the cost of calculating a minimal encodings may be high for systems that like to stream information. That said, even toplevel origin attributes are not sufficient to guarantee an efficient encoding. If most child nodes have an origin different than what is stated in the toplevel container, you gain little. The requirement really is that an origin must be defined for all configuration data nodes (except np-containers). The way how this is done is up to implementations. If implementations want to set default origins at the toplevel, so be it. /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 Mon Oct 8 00:13:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23D2128B14 for ; Mon, 8 Oct 2018 00:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nP88wEEADKIN for ; Mon, 8 Oct 2018 00:13:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A598412008A for ; Mon, 8 Oct 2018 00:13:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C97CCB8155F; Mon, 8 Oct 2018 00:12:50 -0700 (PDT) To: mbj@tail-f.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rohitrranade@huawei.com, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181008071250.C97CCB8155F@rfc-editor.org> Date: Mon, 8 Oct 2018 00:12:50 -0700 (PDT) Archived-At: Subject: [netmod] [Technical Errata Reported] RFC7950 (5517) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 07:13:07 -0000 The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5517 -------------------------------------- Type: Technical Reported by: Rohit R Ranade Section: 10.4.2 Original Text ------------- The derived-from-or-self() function returns "true" if any node in the argument "nodes" is a node of type "identityref" and its value is an identity that is equal to or derived from (see Section 7.18.2) the identity "identity"; otherwise, it returns "false". Corrected Text -------------- The derived-from-or-self() function returns "true" if any node in the argument "nodes" is a node of type equal to or derived from "identityref" and its value is an identity that is equal to or derived from (see Section 7.18.2) the identity "identity"; otherwise, it returns "false". Notes ----- The node-set can have node which are of types that may be derived from an identityref. Typical example is in ietf-netconf-nmda, where "when 'derived-from-or-self(datastore, "ds:operational")';" is used, but the "datastore" node is of type "datastore-ref" defined in ietf-datastores module, which is in-turn derived from "identityref" Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7950 (draft-ietf-netmod-rfc6020bis-14) -------------------------------------- Title : The YANG 1.1 Data Modeling Language Publication Date : August 2016 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : Network Modeling Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Oct 8 01:47:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECBC12F295 for ; Mon, 8 Oct 2018 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.778 X-Spam-Level: X-Spam-Status: No, score=-3.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=VuYG7OQj; dkim=pass (1024-bit key) header.d=ericsson.com header.b=NFGvElmR 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 8uSBjuzdcJu1 for ; Mon, 8 Oct 2018 01:47:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9B61D129C6B for ; Mon, 8 Oct 2018 01:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538988438; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qzAcaa5pyUV+0ypnmoxpXElw1zOs1D9by+bMFckk70g=; b=VuYG7OQjuh3UVgb536BJ88tN4nQfjGPdHH3mIrU20rGBSN2ZfsTxbAMdC9zpPZFJ fvCh6pwzmv8DQFDmByvODEqv7nC4bmUZ4i56+BiJrLxTismd0nJ30hSb9q1g1JUe 2zj5rHpowzcrOYPVkQIrG1km+/QU39qZxLgHFfqc+M8=; X-AuditID: c1b4fb25-cd2929c0000013ad-90-5bbb1996a6f1 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B2.51.05037.6991BBB5; Mon, 8 Oct 2018 10:47:18 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 8 Oct 2018 10:47:14 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 8 Oct 2018 10:47:14 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hVI5q2LSrV3qskJsXsXtjBhrM9Q2Xph8rCvWyeq+IzM=; b=NFGvElmR1ajamwIRhhi10Gwy7pVYc9FAbHODFjtp6MGn6Ff4sFMFM4jvULEQWIpLDr3UQK58WaqQAhfKFiJ/zqHAvzSH8SEqiKHMUpP/LmbsDPb0Eqv/4jQ4AYoSi97frGl7ryt//ch4FFQgwmNds9yRWovvNECEERKTl2TPYCY= Received: from HE1PR0701MB2731.eurprd07.prod.outlook.com (10.168.188.137) by HE1PR0701MB2555.eurprd07.prod.outlook.com (10.168.187.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.10; Mon, 8 Oct 2018 08:47:13 +0000 Received: from HE1PR0701MB2731.eurprd07.prod.outlook.com ([fe80::c8e8:a9a8:81c6:f9cf]) by HE1PR0701MB2731.eurprd07.prod.outlook.com ([fe80::c8e8:a9a8:81c6:f9cf%9]) with mapi id 15.20.1228.011; Mon, 8 Oct 2018 08:47:13 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Lou Berger , Benoit Claise CC: NetMod WG Chairs , NetMod WG Thread-Topic: Regarding IPR on draft-lengyel-netmod-yang-instance-data-04 Thread-Index: AQHUXuOBAMgMDZvLr0CFJ/3LWImIQg== Date: Mon, 8 Oct 2018 08:47:13 +0000 Message-ID: References: <44adc67a-6e29-423e-6155-0a9db4797500@labn.net> In-Reply-To: <44adc67a-6e29-423e-6155-0a9db4797500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: HE1PR0301CA0002.eurprd03.prod.outlook.com (2603:10a6:3:76::12) To HE1PR0701MB2731.eurprd07.prod.outlook.com (2603:10a6:3:99::9) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2555; 6:85y0n0Zke+lB7cIVcgoQRmEhr9Yzs65V4EtBsaKeNli/5j+58VxQn1F1h67zhL/fDEV/ud/cj8T3Mopxzh9T08kMytWzO4BPZGOoQbZr4+/wreOSowT14ZOrhkNmzvmUXp68uvXhyc3UAZp0nhr5fvrOCjhdkWO2/DUlNuFyRfdD52TiTywFqUaua72RRhgtibdFMlAqBytWurdheGKcx/W+OuMvb0rxW6+zAfYUcYAtK5SqlPJBbtEZD/Oeq2P8noYiopIk7OXR8ZvImhAnlP5ljm9OAfBSk0R4QyM/pIjVSi3gNQz48YIIo34QpQe07YNc59POfBXsQsop/bYkhOrSN0CCAsvZial5TVMwQ43d9WkD7MynrWpYqcaTpcLRnoFkqG6TIds8BKC0xKRHHQxyX6b7cUx2Ig1Xasm5tPZEe/gul+4Oa/kmHLtS9POuxA4kjmr7tuZ+8k/bfrE02g==; 5:MFK40zepX6P1AG9ZkyqiCVMcsCoscgzJH1ZeTTuSdYfnVdnJeQpIM8tCLroGmS4jSHpjcsBNL0DfNwd1XRGw/LrIax5PZPUJTz4dmfV4YJ+xoLr75Ym18bycqLhZBhAvOn+G9J1hjDE/jePP5dZenq0OuVbgyPJ9eZowim6yV84=; 7:Lzz4y8r8Fvz6ZewtuC91AQOutADfbAAm+ZPED6a36UbV8nRDH7KJujdfQSUVylmHix2uaNHn34kdgxNX+LmQRJsLTYLaFRhc2Mf438qKvph+JRqv4sI9Q1EX+/4sNQEtRdVVxRysEAbHYHrpW5fZLT1gkYdzzy1zT1MDfQRh1cWaHYHiAAOCwfWVpX0KWYfsvRPr8cGrcYGgxxflA5s8EdGKUtN2ay0tSqzNjtERpCEejvI1/7gsEdGaQLzm7zU+ x-ms-office365-filtering-correlation-id: fa8e1b09-46e0-41e8-8d26-08d62cfaa330 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR0701MB2555; x-ms-traffictypediagnostic: HE1PR0701MB2555: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(4983020)(4982022)(52105095)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051); SRVR:HE1PR0701MB2555; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2555; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(366004)(136003)(189003)(252514010)(199004)(65806001)(4326008)(316002)(71200400001)(71190400001)(99286004)(2900100001)(476003)(58126008)(26005)(8676002)(25786009)(64126003)(3260700006)(256004)(2616005)(446003)(11346002)(68736007)(85182001)(5660300001)(65826007)(97736004)(31696002)(86362001)(386003)(6506007)(65956001)(66066001)(966005)(8936002)(102836004)(76176011)(478600001)(2906002)(14454004)(36756003)(99936001)(486006)(81166006)(81156014)(5250100002)(52116002)(7736002)(305945005)(53936002)(229853002)(110136005)(6306002)(31686004)(105586002)(6436002)(6116002)(85202003)(106356001)(54906003)(6512007)(3846002)(6486002)(186003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2555; H:HE1PR0701MB2731.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4NJi4D8U/12hItjVYD+EuZStqoFPHAHWeDALsmY/lVzKkOy9NA75DJmhbfWciGHbUXlkmBD/ly+azJ52K2ptxr00lnX2ufjgD6yGaBM/lCJ3kyHyOl22V23+CoGON/gGScFRoQI2FFE/cQw+t1yac8Tz6HAJ2VTEdLEBDSn2qjCo2OuAKZDbQU6islZxz+xtrhfrdG04CtcLUpkF+ENRFPj8tq9nVAmv+gD3myq5ejhyMgn3Bd3dEgT2a6t85yzGr7NUA5601QkUO/6OoOoCXrT+EccysU3oxnmeUZ+C/daNwXbf90WkmMoSYpdaC5eiXXT0kZ08U1R+39aNEl+oRln64uV6kFmLgMqWJFfUKgU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080904040907040107080709" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa8e1b09-46e0-41e8-8d26-08d62cfaa330 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 08:47:13.1995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2555 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1XSe0hTURwH8M7u3b13o9Fpav5SJBz2IJs9NPOFFkWsIiooiCxttUtatsmm llE0M2rTBCszt5w2Cv9oUZaW5oOpMcqiyAR7SbBpRlqmlOWz2vUsqP8+v3vO93vOgctR8j5x EJeuzeL1WnWGgpHSlp112crSuY3Jy7oeRcW4eiDGlP+FjnEULYip7MgTr6ZVJRN3xKrr18dE qqG7+cxWapc0QcNnpOfw+qWJe6Vp3bZJOnMs6ejksFtsRP1xBUjCAY4Cy5V8VICknBy7ELy5 b/UNIwhsjaUMGa6JoLDrHisMNC6mwFVeTgl5Ob4sghGbhvgDgg8VywQzeB2cHXSKBPt73Vzx hBFM4Y1QeLsTCfbDKmi/aabJng3QV9DtcwRMudun+2kcBldvGL1ZjpPhJKgbOkKOiof+59bp eglOgFH7wHQlwnPg55ObInJUILztrRSRZ/qDu+MpQxwAn3p+iYkVUNb/dtoBeA+cbreKhTcC LkXw21XAktIUaHpv8oWXwLNXvYg4BF5WFiISaGHh9OA7Wrgo4M3gMMWR750Ielq+U3/DRRMW n3VQ0lzCFqMV1n8ua/VmKGxGUHWmiREWZHg2tFt6abIpGipq3BRxOFTZB6j/w4LjoWy8lSEO hZJCN0u8EgZcw4g4EqpuTTFXkfQGCjDwhn2HD6yIjOD16fsNBp02Qstn3UXeP661dmJ+Per8 vKYNYQ4pZspqZzQmy8XqHEPu4TYU5u3xVDteoCBaq9PyCn9ZQF1DslymUece4/W6VH12Bm9o Q8EcrQiUuVfV7JLjA+os/hDPZ/L6v6siThJkRNs2ib7pasK39CVkPWPlOnufpD7KFiJNPVXr kYxf+GoLue08vr3roFLZlpg3Xtaj8qS446tHFz18vdmct9zzKbjhwcdHoeeHnIEmx3pmdaz5 0kDrEfbcRedjS2fkubHqHZq1Er8fsZmuWZ+V6e66jywX7TLS3XBy4W77onk7tCcUtCFNvXwx pTeo/wDOSisdeQMAAA== Archived-At: Subject: Re: [netmod] Regarding IPR on draft-lengyel-netmod-yang-instance-data-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 08:47:25 -0000 --------------ms080904040907040107080709 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US "No, I'm not aware of any IPR that applies to this draft" Balazs On 2018. 10. 05. 19:58, Lou Berger wrote: > Authors, Contributors, WG, > > As part of preparation for WG Adoption > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the= > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not liste= d > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above= > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NetMod WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > > --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms080904040907040107080709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwODA4NDY1OFow LwYJKoZIhvcNAQkEMSIEIEQE1xRtbzBXpaXwPppS8PLa5Lw3KcLvvkMpZUSUCAnuMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBALgj2dOQeQbxFWodKBJtOH2CUEhtjNFIxI9IeaDle8NQHGlK 5UUj4Bg5/tu9NNlPES1taZPupvUF7IqlklNuDogTTSMVwat3ow+EwlYFGQSWKaAzuPiO2HBg b8ne2nNzX8czm2qtD2yWJApI0hn7ByiC4t39Z+3ygU/w7NH6eOxVl/1grVqDxpTS595ef9Ck DVMTCy0SqkdwFJ5UBMnwvmeevxX26zao56LUtK/Yi0Gd4MK3Ckbjev+Q/l0syzO3FY6D5egw z5SJZEDewzjCKQoAlWZ8gLvwxHyQSr7Uz2LFxX0ezHjZWG0BObxlpYO1pufhXy+sioHfvLxh Wnxsx1gAAAAAAAA= --------------ms080904040907040107080709-- From nobody Mon Oct 8 03:01:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C550130DC4 for ; Mon, 8 Oct 2018 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 OSExx2ytP6vJ for ; Mon, 8 Oct 2018 03:01:26 -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 7C36B130D7A for ; Mon, 8 Oct 2018 03:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2629; q=dns/txt; s=iport; t=1538992886; x=1540202486; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uYePRCY7LKlV9mbSNIdo9iTqKG919zQgZ4CvZUEbGlg=; b=JSNvH/lrO6Z9yCEhPCFzsA8C6nrCXYiNBOETJO12LZU5/2UA7OjGFlMO uVe+0EmVYl9o8qo2jNJhXQr+2auryrq2zj85h4DrdbZOw5C/O5aYPFXOR B21hJZinMFyvCNdZAC7XU9SqQ1Z8A7GhZuZZF/OI8Vqm+ASv6kWnnlNcF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAACVKrtb/xbLJq1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBg1gShB2IdI1elmmBeg2EbAKEWDUMDQE?= =?us-ascii?q?DAQECAQECbSiFOgEFIw8BBS8FChMLGAICJgICVwYBDAgBAReDBoICozOBLoQ?= =?us-ascii?q?BAXWFFIELikWBQT+BEieCa4FBgyeDF4JXAp1uCZBDBheJGoZdj0eGK4FEATW?= =?us-ascii?q?BVTMaCBsVgyiCJQwLjWIBNj6PewEB?= X-IronPort-AV: E=Sophos;i="5.54,356,1534809600"; d="scan'208";a="7017895" 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; 08 Oct 2018 10:01:24 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w98A1OGD004098; Mon, 8 Oct 2018 10:01:24 GMT To: Andy Bierman , Lou Berger , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> From: Robert Wilton Message-ID: <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> Date: Mon, 8 Oct 2018 11:01:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 10:01:29 -0000 So there seem to be two available solutions here: (i) The server MUST provide an origin value for the top level datanode, but for NP containers it can use whatever origin value it likes - since the origin value imparts no direct meaning other than the default origin that descendants acquire if they haven't provided an explicit origin.  In this case we would probably add a line of text to clarify this behavior of choosing a suitable origin value for top level NP containers. (ii) The requirement is weakened as Juergen has described previously. Solution (i) minimizes the impact of the change to the RFC, but probably constrains server implementations slightly more than is strictly required. Solution (ii) gives a bit more flexibility to server implementations but in theory could break client implementation that rely on a top level origin always being provided.  Although, in reality I would expect a robust client implementation to either not care, or choose a suitable default origin (e.g. "unknown") if an explicit origin hasn't been provided. If solution (ii) is beyond the scope of what is allowed in an errata then it would seem that we should go with solution (i) instead.  But how do we get to a final decision? Thanks, Rob On 07/10/2018 18:09, Juergen Schoenwaelder wrote: > On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote: >> Can somebody explain the rationale for the highlighted text from 5.3.4? > Note the difference between "applies to" and "carries". A non-presence > container has no relevance for configuration and hence an origin value > does not *apply* to a non-presence container. Still, a non-presence > container can *carry* an origin attribute. > >> There are many top-level configuration NP-containers defined already. >> It is clearly more efficient to have 1 origin attribute in the top-level >> container than in each of the child nodes. > There is no requirement to produce efficient encodings. This is up to > implementations, the cost of calculating a minimal encodings may be > high for systems that like to stream information. That said, even > toplevel origin attributes are not sufficient to guarantee an > efficient encoding. If most child nodes have an origin different than > what is stated in the toplevel container, you gain little. > > The requirement really is that an origin must be defined for all > configuration data nodes (except np-containers). The way how this > is done is up to implementations. If implementations want to set > default origins at the toplevel, so be it. > > /js > From nobody Mon Oct 8 04:38:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AAC130DC5 for ; Mon, 8 Oct 2018 04:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E9H7GoKMiUH for ; Mon, 8 Oct 2018 04:38:51 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 DCB5912F1A5 for ; Mon, 8 Oct 2018 04:38:50 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 6FA2F1E070B for ; Mon, 8 Oct 2018 05:38:43 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9Ts3gvG7VE0jM9Ts3gNMpb; Mon, 08 Oct 2018 05:38:43 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZOsA9RFmVww9fOOX3El1ANWTB6EAOU9aRqg8zJIK9IM=; b=RZr6d45MLSwOAmXG01OGFEglzI pzpzRxWUinVUhOj7wsPUqOBjDhqAzEfAeIfYi7FpunacLlU+N7FJPOJbVccyKCEX/fU+V87wUhq7O 80nmM6josbrYCSzOCyo+mx61Y; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:52332 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g9Ts3-004JGW-12; Mon, 08 Oct 2018 05:38:43 -0600 To: NetMod WG Cc: NetMod WG Chairs From: Lou Berger Message-ID: Date: Mon, 8 Oct 2018 07:38:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g9Ts3-004JGW-12 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:52332 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:38:53 -0000 All, This is start of a two week poll on making draft-lengyel-netmod-yang-instance-data-04 a working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends Oct 22. Thanks, Lou (and co-chairs) From nobody Mon Oct 8 04:42:31 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EBC130DDC; Mon, 8 Oct 2018 04:42:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153899894979.31635.8786174621364669178.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2018 04:42:29 -0700 Archived-At: Subject: [netmod] The NETMOD WG has placed draft-lengyel-netmod-yang-instance-data in state "Call For Adoption By WG Issued" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:42:30 -0000 The NETMOD WG has placed draft-lengyel-netmod-yang-instance-data in state Call For Adoption By WG Issued (entered by Lou Berger) The document is available at https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ Comment: Adoption poll: https://mailarchive.ietf.org/arch/msg/netmod/C6yfulJH8lQyo8mSz-8NK1X0GpM IPR: [netmod] Regarding IPR on draft-lengyel-netmod-... Lou Berger https://mailarchive.ietf.org/arch/msg/netmod/IElDuTiB0dzMOoJTq7PLVbUPmgM Re: [netmod] Regarding IPR on draft-lengyel-net... Benoit Claise https://mailarchive.ietf.org/arch/msg/netmod/KHS8Dw3-iF_375S2gWfYPXHk5cY Re: [netmod] Regarding IPR on draft-lengyel-net... Balázs Lengyel https://mailarchive.ietf.org/arch/msg/netmod/P_mHUoKp3fFosm3w5g1aGhlhJtc From nobody Mon Oct 8 04:56:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFD512F1A5 for ; Mon, 8 Oct 2018 04:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO530aoOI_QZ for ; Mon, 8 Oct 2018 04:56:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 57B12130DC5 for ; Mon, 8 Oct 2018 04:56:23 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C20711AE0332; Mon, 8 Oct 2018 13:56:21 +0200 (CEST) Date: Mon, 08 Oct 2018 13:56:21 +0200 (CEST) Message-Id: <20181008.135621.2235985294350825585.mbj@tail-f.com> To: rfc-editor@rfc-editor.org Cc: ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kwatsen@juniper.net, lberger@labn.net, rohitrranade@huawei.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20181008071250.C97CCB8155F@rfc-editor.org> References: <20181008071250.C97CCB8155F@rfc-editor.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5517) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 11:56:27 -0000 Hi, I agree that the text needs clarification. However, I propose this text instead: The derived-from-or-self() function returns "true" if any node in the argument "nodes" is a node of type "identityref" or a type derived from "identityref", and its value is an identity that is equal to or derived from (see Section 7.18.2) the identity "identity"; otherwise, it returns "false". /martin RFC Errata System wrote: > The following errata report has been submitted for RFC7950, > "The YANG 1.1 Data Modeling Language". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5517 > > -------------------------------------- > Type: Technical > Reported by: Rohit R Ranade > > Section: 10.4.2 > > Original Text > ------------- > The derived-from-or-self() function returns "true" if any node in the > argument "nodes" is a node of type "identityref" and its value is an > identity that is equal to or derived from (see Section 7.18.2) the > identity "identity"; otherwise, it returns "false". > > > Corrected Text > -------------- > The derived-from-or-self() function returns "true" if any node in the > argument "nodes" is a node of type equal to or derived > from "identityref" and its value is an identity that is equal to or > derived from (see Section 7.18.2) the identity "identity"; > otherwise, it returns "false". > > > Notes > ----- > The node-set can have node which are of types that may be derived from an identityref. Typical example is in ietf-netconf-nmda, where "when 'derived-from-or-self(datastore, "ds:operational")';" is used, but the "datastore" node is of type "datastore-ref" defined in ietf-datastores module, which is in-turn derived from "identityref" > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > -------------------------------------- > Title : The YANG 1.1 Data Modeling Language > Publication Date : August 2016 > Author(s) : M. Bjorklund, Ed. > Category : PROPOSED STANDARD > Source : Network Modeling > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From nobody Mon Oct 8 05:21:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3C126DBF for ; Mon, 8 Oct 2018 05:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 tQl7I4e1sy0n for ; Mon, 8 Oct 2018 05:21:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 781D112F1A5 for ; Mon, 8 Oct 2018 05:21:11 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::404]) by mail.nic.cz (Postfix) with ESMTPSA id D37D660D92 for ; Mon, 8 Oct 2018 14:21:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539001268; bh=a6iLPvZl2VW0AwpbxeFemoK9jfnQlZyKEhigyJaOHl0=; h=From:To:Date; b=abeuGEBqYUc8LnXtd6GF84QEXXvkQoyyQ8G3cbfa9lU44XVtZeCjQqz6gOspdwKK8 rgKIBSQvOXzzGsEqCIF5D1dv+BDAVWpj3FMFh9ZmiyIufAmRWRoPA5a1S4ZRjamDR8 I9MBaA3qe7ooFmhV9FfWdrx2WGvdiPORnX7raq3U= Message-ID: <9f95bb8a9a0a4689dd306fed0442097f719d2d88.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Mon, 08 Oct 2018 14:21:08 +0200 In-Reply-To: <20181008.135621.2235985294350825585.mbj@tail-f.com> References: <20181008071250.C97CCB8155F@rfc-editor.org> <20181008.135621.2235985294350825585.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5517) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:21:16 -0000 On Mon, 2018-10-08 at 13:56 +0200, Martin Bjorklund wrote: > Hi, > > I agree that the text needs clarification. However, I propose this > text instead: > > The derived-from-or-self() function returns "true" if any node in the > argument "nodes" is a node of type "identityref" or a type derived > from "identityref", and its value is an identity that is equal to or > derived from (see Section 7.18.2) the identity "identity"; > otherwise, it returns "false". > This formulation is better. It is somewhat confusing that "derived from" has two unrelated meanings in the same sentence. Lada > > /martin > > > RFC Errata System wrote: > > The following errata report has been submitted for RFC7950, > > "The YANG 1.1 Data Modeling Language". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5517 > > > > -------------------------------------- > > Type: Technical > > Reported by: Rohit R Ranade > > > > Section: 10.4.2 > > > > Original Text > > ------------- > > The derived-from-or-self() function returns "true" if any node in the > > argument "nodes" is a node of type "identityref" and its value is an > > identity that is equal to or derived from (see Section 7.18.2) the > > identity "identity"; otherwise, it returns "false". > > > > > > Corrected Text > > -------------- > > The derived-from-or-self() function returns "true" if any node in the > > argument "nodes" is a node of type equal to or derived > > from "identityref" and its value is an identity that is equal to or > > derived from (see Section 7.18.2) the identity "identity"; > > otherwise, it returns "false". > > > > > > Notes > > ----- > > The node-set can have node which are of types that may be derived from an > > identityref. Typical example is in ietf-netconf-nmda, where "when 'derived- > > from-or-self(datastore, "ds:operational")';" is used, but the "datastore" > > node is of type "datastore-ref" defined in ietf-datastores module, which is > > in-turn derived from "identityref" > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > > -------------------------------------- > > Title : The YANG 1.1 Data Modeling Language > > Publication Date : August 2016 > > Author(s) : M. Bjorklund, Ed. > > Category : PROPOSED STANDARD > > Source : Network Modeling > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Oct 8 05:37:57 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8995712F1A5 for ; Mon, 8 Oct 2018 05:37:54 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y3f5v9e7; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=WFEYdmL6 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 oFpuzx6xYUaZ for ; Mon, 8 Oct 2018 05:37:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 89F62126DBF for ; Mon, 8 Oct 2018 05:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539002270; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DpS0I3q/8LHSzvzbdIp3OcWdFsCqKvobkDj2oJBqF3w=; b=Y3f5v9e7jXMxzDMQuPo/e9tNN5q3oGFNFsut4bD+dWjGnzinA+13SWipRVM1YARe 48cAJw3BWHSXTuNAtUuDPCXj0tGBZg7uFcuABcst3LLameXDlCTQ8Sm4YczAIywP wBhmDgcZRjxlmtjXkLkOnikNhHaBfjCLH8MwIvA9kg4=; X-AuditID: c1b4fb3a-99fff70000002fc1-19-5bbb4f9e0031 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.C5.12225.E9F4BBB5; Mon, 8 Oct 2018 14:37:50 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 8 Oct 2018 14:37:50 +0200 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 8 Oct 2018 14:37:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wmMn13vugbTUS5CIArjI/n9G0nb9ZYi695/fQoNjulU=; b=WFEYdmL6+QF2nuw23yA918YRyH0CU6ojVPDbdBXyb7M4vid6cIhBSUrYwuFoRsScaD11K326lY8uDZHr9Fh9Dm9dQqaqxV9nBuknrSOzQrtdvMRyWzvIqNMsFTijwRhhNnEg5O9Nm5O6VuhRnJir/OWSpBoekX1d3Yu0zcV+FTg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.196.213] (89.135.192.225) by AM5PR0701MB2723.eurprd07.prod.outlook.com (2603:10a6:203:76::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.19; Mon, 8 Oct 2018 12:37:49 +0000 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: Date: Mon, 8 Oct 2018 14:37:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010806000800070109080508" X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: LO2P265CA0002.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::14) To AM5PR0701MB2723.eurprd07.prod.outlook.com (2603:10a6:203:76::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5b8a1423-77c6-4dd2-e1c2-08d62d1adb67 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2723; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2723; 3:8foIqpYS80c4bN+5pcG5BrX9JY/kL33un7hcuQzSoNMvAJ0eSRVhfPa/oFgR5pIPc//sktejtKavJg15kBLzUOi5bHNo+SS2xHuZ3qrDR/Hyy2JOq1E4lZL5v2hrKkXRTD7644MbD35p7A8A7bwGtqxyfR60TFnWomaUaF2X6ryhPo0UBXHC5V5onRkngSVGOGCheEoAWbSX+aKnVcH5z76hb4B7aKeT0kdHa8zC1yWEn9FRBn/7CV2f/d1OzeiY; 25:M+U5HDgPcyhHbSBxXyWELACwYaBg3SlRljZBt9iWP4PSZjq2rXH6GYDpByRTs2IIZ4xjxMhMFFFyrxQwOipUsCjGSNXhNr1TnBP5tkgTtE9VTuKlThwPZqnEMe+0sQVqvg671VMohJqKymI1jwiLlBA0wV5ANrvSWw7vHZ89tdrSGWbS5mfeP0PjY+7S8BorY60Cl3eNoApPbj2RyzALwZEYXtV7l0Vt3yhI50kBzY0anPgcSJ7qVSTD8TJSOGTVVObJZC54ViyCzr3QbEDRVOdQ0tGNbfFoaxciyNcE2nC86x4Ef7yDVoKpyFHwedo4PpZooLJ/Oi0Tir4Xdc+1Yw==; 31:roLZyHiv+2p8w+I0PusQju7BBvYYMa8JlmBBEUTyVZL2bpvj8mSU2ERnx/BtUkOpK0iWUmawBtCBjb5bMg4tldDSq7bl42Vt3rdkUQMMNEI3UA70hOuvDGmX/T4q2hyOEQlqFkYK4F0M9RznzhQdnak89E3V0eGjHQG4/uz1T+EKPvmWIjRaH9SvDcpSJ3jqiwHGttGkSCzvbAmWZl1iTfzehTrNURlVc8FLve7NuPI= X-MS-TrafficTypeDiagnostic: AM5PR0701MB2723: X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2723; 20:uZu605ViKOxSIDM6kkVL2Up2ikxKcHZuIlROBs8zdb+hzZIcwPdYl00XF4vv86WSrthzMx+pMUQ+s7JC8CE8fWudofLdB0KDHVqhvbDlpDRCC1wbkeLiNlc+xyp3EN8JrV+yGNuVgffRunVOlTosgAS1cumKi2vcg8ixx4+vRhspe8ARcscZBG+NzLOY3WhytJW4c99LCwxaaMfII+5uTDgKbCmjOAddc87nMOG1Mp1exnc814ZhxzYxlCv/lFSsptoB2NxJ/JlCHfRO9KPG5dHRLCx3jlr3Uhi2nC3awoCBt2YpXSQHYjSj8lxTRXH1S0LoaG7ws9mzFPUn5K1ixeCqh14xkbyLObP0hllfDg1TIXy9x1UnS12BQrmNjoxJUvFhMZTWLD12Xbtmc4KANo6ZKpn+u/eZFv9MWoN6J/tY5DJpYTeiwMZWadHoDxdY4/YfK2WgGoZMrlGQY0Ufgf+N/DRjJqqQ4suG4rg1HHSa3bOwJVil2e6idDabTu6n; 4:utxfbzGtS5XWmWRqfR1mIEOv8TUIt7un8NafAr/UGIej4nxwCJI7+Q4o2MI2A5y054eXQhortAbbhHjpaqe0gymxH8sVlKCRxIArVJEXW3XHMaxMqidiM/NRc4lZoVi84aMoOXmjWGEhwWRhQ38Ff88MrJKwT4O82tDzDoBJEVizsGRbqpukIJrc6WWutxbTYnzJUUKdWwgClgkYUxFak4brih//DNezEWPmbRfoxpDrRAI9M5S4+W2NqUm6gigXen6PGABHYF/pB5QXJcdI0HwGzpfjoBp4CQC6YmyM59MMcg95pc94Xo+AsBvQ/vo2n4Tz9Fhh2bwWLxlGVluhOK6NBG2jN7oIucJAkGgvfl8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(248295561703944)(37575265505322); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:AM5PR0701MB2723; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2723; X-Forefront-PRVS: 081904387B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(376002)(346002)(396003)(136003)(39860400002)(252514010)(199004)(189003)(6916009)(44832011)(106356001)(49976009)(33964004)(84326002)(31686004)(53936002)(105586002)(52116002)(7736002)(5660300001)(3846002)(6486002)(6116002)(64126003)(5640700003)(58126008)(2351001)(6666003)(186003)(81166006)(476003)(305945005)(16586007)(16526019)(16576012)(31696002)(65826007)(2616005)(956004)(2906002)(86362001)(25786009)(3260700006)(81156014)(68736007)(36756003)(316002)(8676002)(2501003)(5024004)(8936002)(71190400001)(1730700003)(5000100001)(65956001)(478600001)(97736004)(386003)(26005)(486006)(66066001)(65806001)(568964002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2723; H:[159.107.196.213]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0701MB2723; 23:Wc7wKeP/Itiex/OWMEGrarJYHMHx7DVmNcSWZM2?= =?us-ascii?Q?rleB8ci1x6XKCus3Vd/IBg7TdgVMWof2O64tNeY/NfzVenzjTrtIPJA/Fi/u?= =?us-ascii?Q?B8TDSCLiVgXlXzAWeTgRv0gCkSlS8wxPWkxtxd6hMv9k76TVpUkUcz3DS1Yn?= =?us-ascii?Q?dQ7QViwDzi7/RE+xBcHtV0ln7RmPmFnXdUic0vAhkipD3ohwEkvwa9GOi1Ya?= =?us-ascii?Q?sPzwzq0fc8ytIeb/1oPMU1hcIwc3VkVqvYdVJzzvv6vGzRzuITDjT+hramOW?= =?us-ascii?Q?oxNbnO5PGOR2WoVz/wPIcXYRc0YWPURf/M9TYAADsP0x3LDM4bqJ+OV83Ng1?= =?us-ascii?Q?OUO4KB1TrfsaU0ikvrJgfdASrBA0xfRbcLbqjpSkBGbsiKGi3K1fjzLmwcns?= =?us-ascii?Q?Sne+JTR4KmN0bnV3Xo/jqXA8D6A8H1kY4k7ku65t/pFftdae2bVJ0t5VCAiK?= =?us-ascii?Q?rznBvjf/8rBr8a2vHmTuaC/6Qdu0XxGzeJ9Oc3dhM5EF6fKmysk+NINFTjqa?= =?us-ascii?Q?VGgwPehcItP1hPTIorN1ks8Lc4ufRm5PlSR8GVHfBVDhQWh3LIdJuNICq5zE?= =?us-ascii?Q?krEfKto2e5wcvsanffEz5QVDFq9YYl2QvrnUkHtbAv+NF36SDfiRaXddQTfz?= =?us-ascii?Q?TwehmZ4oBAFfsys/cGfwoOo5pmjLiXrpxCVa4qccdXPZMZjLPYokjLGt9H1e?= =?us-ascii?Q?+XYf+JOKihXeHM15D3ArCf2sib5kwKaDn48dFnrF2+9Okr+hbTMn0RxuWfA2?= =?us-ascii?Q?Ozcjwqk7wvs7/Q3snL3GW1OT1Wcx6gK+9nNMa55VCsrQXLgxIzaDXJThukUL?= =?us-ascii?Q?ogt5855RXz6Dn38mhGAfe0VfJ9Ko5jC6HOmy3sZJdUo+EEc1ENMnjvwRC4g+?= =?us-ascii?Q?bqDQCM2aerTIzq44ccpHJQiPNWgMQOuaNGiesoZ7RKrM57NLWl9jVSW/RYIF?= =?us-ascii?Q?AZl1ApvxQ1iNnwDILPJwpcy8p9o60R3lEcIR6bWVhcJbHVxO2w8/rSWeMtMu?= =?us-ascii?Q?Y8/xfkHDT7rkUQUaOm+fM6Q+I4ZNP6tw549CI5Or/gGjk89MOi6jtU+yXymI?= =?us-ascii?Q?TFEsbTOQaazafObDPknPY/civd53POrB4hnaNMDwYsMeQeWyZRcqQB7Wf9oS?= =?us-ascii?Q?dg/TR/zaGSyIDioLkvh58O6fI5VgRmvAZV1EERxG9u03vZPPEJCEjSMd1IZN?= =?us-ascii?Q?D4j9EWQnqSD2xKCndt/zrPMN2F7F4G6TZ7RuEUs6GD8VKqhUNdy9cWpsdEPC?= =?us-ascii?Q?Cfw+Puqg/CNnEiyH0j6MRUJcVmaz4bplOUVoE8+rvjJECckIkA2mKgLG9i93?= =?us-ascii?Q?+UA+hw95TM9UR4Stg8aZl5aPa04/5XPWyqLHI2dYgwKhBz9D1AzIB1cycUsx?= =?us-ascii?Q?o+d+hrIv0eDNW+VY0aG7fA4Hm9EircdlGk9IAORZMkgXoGyo+rvNLp50M88L?= =?us-ascii?Q?QEDXXpvw1F+Ni3M3dYV5Cq58HfkZ7av1wGqdVNnj2KjLBOvdXGjZXJdyENuR?= =?us-ascii?Q?CUpOhVlRQlXZjpA=3D=3D?= X-Microsoft-Antispam-Message-Info: JhoKxsf+KIdUp30tiwQtSqF0hJbreX6pmSl6VVPpSyE4YNVtwV1hv6D1SInSaawfGMmNVrMgAiMfbu1AEvYh0jpJh6ZIztXnspZ/+lPtRyLnmQl+DJAYh9epgtstzW68VnUug7msTcQdJUsWDoQot3zQLEhmZbGovAiwFbHm8vApkRb+8s9fDPdOk+PwtS7heKiQNO9ikuMHCOgCVUeLYyI64THih5SOKPSjgpsFkhNMbQBvLlza1PpMvoKSgYFdZcrM3xuim8LnT5iG0Np24mNy5yQXQMrDdPliArn5BMQWzgButEnCdiPtMdnkjPRfak0ONCMu8ftRXWAqka7UN4tlRj/AoTM4KFt24GA6a/k= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2723; 6:FQid17m58/kdItQikuOx9KlTrLyYCrlDZIr2OFDLUOrUDtcT5fgmDkM1fZhgUapQs7uK4vniEvjrJQKLs3/J+NAxnM3yMIcDLrB6KZx0UrC7R4haXNUkc3Jw3Km1JIxuCUuydMYGD0JfbgPeOQCuNlolDRw6shSiZC1nZyeIrpDucuzKy4UXUrhQF1khY9iF5n8E9bvjMEE17YGCh+v/NjAHY7uIj9z0FnnZdc7FrvLaYl4TXHFHRD9kUZC7vDajt9oZxY4F5WCHaiRgbe+o7xZCmlzth8VNezNfrdb1039KDUN8OOJtHPyhaAf5ZVflBWjIIcYj6Bum930TENwCA8hP3GVbIBwZnpAvTxF+mcZBWh4nUBAgpJTaal8IHRSK4hWkb83aZFku1ojf6C6EJvbg1YQksudDgtEVf6jTez5cXuVZ5+F7LVtymiEccjwu6KVCEvpTMbXrq1D0usPPbQ==; 5:MZYrEXZjJjoVDLBe0nWA4O+wKFjx6KmGvlQhbZrCkrKWSVeDVhBsuGF4jPXQLNGayfCld6PK0H2pfrBs5u/HV09INvnxGaF2NkiyeE2lkJb6evDzL9PbNsgTpogfO9pmk10JhqFQJ0u2vBwe4KWyroxztQukhfR2Ljwq+247EuY=; 7:TtfaRJUhUPpgPQRtQYW1dC1AeQ9Z3tgkxobteCYF6SBmESjyvWPcKZipG7EBSlmjnJfLFcv9j43JPDBVetfOoS59RAp5uKbKgn8kFpIo/pXkibM5hMEZpQ9D84jqpNJGQKIc/tbKIMD8eT7LTF8v2B69F3NJHKAn8imnmYIf3JxoUFMpYD3vwy3XqaH7ll5vmfYLfW1senfaY7rYkHhFJgtQt8D85DnZkp40fbT9Kg++bbBGBZtfucp1DPvwDtBy SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2018 12:37:49.1480 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5b8a1423-77c6-4dd2-e1c2-08d62d1adb67 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2723 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XbOzuZodZyKb2qmQ8qsvCwTK1GLiMKuEBRKl9mOt+YmO2bZ X5aaZIqa9wu6eRmY13Q0p0VqCJmalxTFKFSEIO2P6YapGbl9C/zv937P8z48L3x8QvSR68KP VyQzKoVULqYEZPlNPXu0+kpPlH/Z66DgmvEn3HB0vr5+nXMVRQpCZIw8PoVR+YXeFcR9mMsg k8yBj/IL14g0VCXJRnZ8oAPB/LORzEYCvogeQKDPbCLwYEbQ3jlpU+o48HVogWsZSDqfAPPK Ks+yj+jbYGjWcC0sorM4MNUfZmFH+iCUG9ooC1O0BIrzRkkLO2zz4Lra6hfSYTBd22l9J2kv KNU2WP1O9C1YmawjsMceBssXrS0I+jmCzJL3XFxcDBOmEqsAdCmCoZw5Dm7hDfNjWzbTPhgY qSIxX4LixikCLwwiyHnzFuHhKQ86fjVwsOsIlLUVU5i1PGj5G4lZCZvFOltqBMxkfLOlusOn 3M8cHGQgYLpyi8CCG2iMCzzMDRS0rp3F9RjQzWRQeGFxDxQ9m+XlI5+KHcdW7DzWIhB0EFR3 zhOYD4NWs2RjZ5hdrOFgPgVlG30UZk8oejHPw3wclgaMCPMx0LZuUWpk9wo5sQzLJsZKJL6M Kv4eyyoVvgomuQNt/6k+3ebJLtT343Q/ovlIvEvY7NcTJeJKU9jUxH7ktZ2z0N40hlxIhVLB iB2FTvruKJFQJk19zKiUd1QP5Azbj1z5pNhZeCYmOFJEx0qTmfsMk8So/qscvp1LGooI/zId mjdTaUw/cNk8pR9xnfWsEPzuusBU7C74sz+6ZXrUYyJblhMQE12gFHi08wp798qSvUPSy7/f GNG8PFQ7r+5+ZxrrlF33W5ocr5N75fs3e2adcJa2jRtXtRnnqki5k0PCclON23DLsItJnaty LLI36ZbNht5rGw8vJriLSTZOGuBDqFjpPztVRvpbAwAA Archived-At: Subject: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:37:55 -0000 --------------ms010806000800070109080508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello, What is the best way to download standard Yang Modules? I know the=20 official answer is to download all the standards then extract the=20 modules, however this is a "bit" cumbersome. Is there any better way? We = had a git earlier. How up to date is that? It would be wonderful if this could be described in the Netmod WG wiki. (And sorry, no but I am not volunteering :-(=C2=A0=C2=A0 ) regards Balazs --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms010806000800070109080508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwODEyMzc0NFow LwYJKoZIhvcNAQkEMSIEIBrj4yNVbZPwyxx454nC4N3gFA8pOH0yngW0qTzIoemuMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAHDnYZNxR0DDCJFRQR4jx4GexzkoK8v4ujD7phFJpw2HUS7W DJhoi6bynHMO3d11kGgoWBhjzvmmYaUZYeV4Q4yp14bvy5Tsg2q7PsGPalDGUeE4tcvldknw 0pGrfKl7BoE8V92U65IXRwulmA1mdMjEjFSf/4LcOOV61wQYoGpVhOvn/zl7eai5WsEFCYc5 WYK+vteyRnnii726JAPUoX65//ZAaB2CdOYHZQ3VZH8RbPaXAIPodBXpUR9kZUJ8ePh9asKG bKEmyPIa5oNg80XHtGrd8o6o/TboreZQQZIY0XIwamxKkNVtMb/ghhTXf2I8j9wni5vr+xuh fNiQTmYAAAAAAAA= --------------ms010806000800070109080508-- From nobody Mon Oct 8 05:53:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE77C130EA8 for ; Mon, 8 Oct 2018 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXN2v2lHfW0G for ; Mon, 8 Oct 2018 05:53:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E717130EA6 for ; Mon, 8 Oct 2018 05:53:16 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 190141AE0332; Mon, 8 Oct 2018 14:53:14 +0200 (CEST) Date: Mon, 08 Oct 2018 14:53:13 +0200 (CEST) Message-Id: <20181008.145313.1979034555219874418.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 12:53:19 -0000 Hi, Balazs Lengyel wrote: > Hello, > = > What is the best way to download standard Yang Modules? I know the > official answer is to download all the standards then extract the > modules, however this is a "bit" cumbersome. Is there any better way?= > We had a git earlier. How up to date is that? You can download them from IANA: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml But there are two problems: 1) you have to download one at the time 2) some of them have lost all indentation (e.g. https://www.iana.org/assignments/yang-parameters/ietf-voucher= @2018-04-06.yang) [on 2), I have it on my list to talk to them] Or you can get them from some 3rd party place like yang-catalog, or pyang. /martin > = > It would be wonderful if this could be described in the Netmod WG > wiki. > = > (And sorry, no but I am not volunteering :-(=A0=A0 ) > = > regards Balazs > = > -- = > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > = > = From nobody Mon Oct 8 06:02:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0AF130DDC for ; Mon, 8 Oct 2018 06:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_wcEgNqvQwb for ; Mon, 8 Oct 2018 06:02:01 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 2FEC2130DD4 for ; Mon, 8 Oct 2018 06:02:01 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 5203A43340 for ; Mon, 8 Oct 2018 06:57:36 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9V6OgnCDso6eD9V6OgCtxy; Mon, 08 Oct 2018 06:57:36 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fVzdKljpW6xgTbVO9VRqKm++bWkIM9tWm6Ib26qzK8I=; b=sCdOmFeDYJoWKQ5n/roiwazIuK /l0UaMGxs0N//80/7l2eEPpSeUegzGyMiP/v0T+cX4bUchJASnZhjvKL0eCzSYRnmuPYv/CmZkxhf Y3uzHHO/qN0LadVjyN9M2aFYa; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:60808 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g9V6N-000DyS-Pm; Mon, 08 Oct 2018 06:57:35 -0600 To: Robert Wilton , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> From: Lou Berger Message-ID: <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> Date: Mon, 8 Oct 2018 08:57:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g9V6N-000DyS-Pm X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:60808 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:02:04 -0000 Hi Rob/All, Keep in mind that the document says what it says and that to change text really requires a new version. On 10/8/2018 6:01 AM, Robert Wilton wrote: > So there seem to be two available solutions here: > > (i) The server MUST provide an origin value for the top level datanode, This is pretty close to what Andy previously quoted: md:annotation origin { type origin-ref; description "The 'origin' annotation can be present on any configuration data node in the operational state datastore. It specifies from where the node originated. If not specified for a given configuration data node, then the origin is the same as the origin of its parent node in the data tree. The origin for any top-level configuration data nodes must be specified."; } I think it's clear that the reviewers, notably myself as shepherd, missed that this is a lowercase "must" and should have asked for clarification during the review process. Having an errata saying this "must" really is a "MUST" is quite reasonable from my perspective. > but for NP containers it can use whatever origin value it likes - since > the origin value imparts no direct meaning other than the default origin > that descendants acquire if they haven't provided an explicit origin. > In this case we would probably add a line of text to clarify this > behavior of choosing a suitable origin value for top level NP containers. I guess I'd need to see that specific language to understand if a new requirement or recommended behavior is being prescribed.  If it is, we need a new document to do so. > (ii) The requirement is weakened as Juergen has described previously. > > > Solution (i) minimizes the impact of the change to the RFC, but probably > constrains server implementations slightly more than is strictly required. > > Solution (ii) gives a bit more flexibility to server implementations but > in theory could break client implementation that rely on a top level > origin always being provided.  Although, in reality I would expect a > robust client implementation to either not care, or choose a suitable > default origin (e.g. "unknown") if an explicit origin hasn't been provided. > > If solution (ii) is beyond the scope of what is allowed in an errata > then it would seem that we should go with solution (i) instead.  But how > do we get to a final decision? Either we agree that s/must/MUST in an errata or start a new (update or bis) draft  to update the behavior.  It would also be fine to flag the issue in the errata without specific resolution, with the understanding that the issue would need to be resolved, in an update or bis, at some point in the future. Lou > > Thanks, > Rob > > > On 07/10/2018 18:09, Juergen Schoenwaelder wrote: >> On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote: >>> Can somebody explain the rationale for the highlighted text from 5.3.4? >> Note the difference between "applies to" and "carries". A non-presence >> container has no relevance for configuration and hence an origin value >> does not *apply* to a non-presence container. Still, a non-presence >> container can *carry* an origin attribute. >> >>> There are many top-level configuration NP-containers defined already. >>> It is clearly more efficient to have 1 origin attribute in the top-level >>> container than in each of the child nodes. >> There is no requirement to produce efficient encodings. This is up to >> implementations, the cost of calculating a minimal encodings may be >> high for systems that like to stream information. That said, even >> toplevel origin attributes are not sufficient to guarantee an >> efficient encoding. If most child nodes have an origin different than >> what is stated in the toplevel container, you gain little. >> >> The requirement really is that an origin must be defined for all >> configuration data nodes (except np-containers). The way how this >> is done is up to implementations. If implementations want to set >> default origins at the toplevel, so be it. >> >> /js >> > From nobody Mon Oct 8 06:24:32 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5E130E5A for ; Mon, 8 Oct 2018 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=YgbMTCff; dkim=pass (1024-bit key) header.d=ericsson.com header.b=c9GPVPED 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 0Cg7CfuSsMuY for ; Mon, 8 Oct 2018 06:24:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 96FD4130E79 for ; Mon, 8 Oct 2018 06:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539005057; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cnOshzxmn3F8DOF30i9n9p2yP4aGuYQ5S4MNpHso410=; b=YgbMTCffQlRreccNEOkLPW4STxXjaiS+nWQ03yxrd1Oxv1bLghCowCsPtYZrVkLb 6Oczg9+I2MihTGr4698U/9LROEh/dCyRNc9GhEeE4GGdBhHEvEGIQ3R4xjYJj0Bj a6UqxD88/wC7Sb+5bwZuJiKIatcxyPkC3rKT+mPw+LQ=; X-AuditID: c1b4fb30-3cd869c0000055da-ab-5bbb5a810735 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.0E.21978.18A5BBB5; Mon, 8 Oct 2018 15:24:17 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 8 Oct 2018 15:23:47 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 8 Oct 2018 15:23:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wTVMRlfKhcV1qyyLue1DybjQESuiuqXlrs6WZy4td84=; b=c9GPVPEDK1UpntjzOMtV+ufpkGxd38oUyip4nFAQ/rnsmdauqli7mf2a/FbzpNTiGnF40q9sNQGgmTYuyUDrncE21MJGavoogUIdpcIjBmyeOONZOB4GfeE4LeNZ71s/Jx8XigIGsv3OZrwS7Sv87qUkRRCyM1NJ+6kIJ0tApUk= Received: from HE1PR0701MB2731.eurprd07.prod.outlook.com (10.168.188.137) by HE1PR0701MB2716.eurprd07.prod.outlook.com (10.168.188.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.19; Mon, 8 Oct 2018 13:23:45 +0000 Received: from HE1PR0701MB2731.eurprd07.prod.outlook.com ([fe80::c8e8:a9a8:81c6:f9cf]) by HE1PR0701MB2731.eurprd07.prod.outlook.com ([fe80::c8e8:a9a8:81c6:f9cf%9]) with mapi id 15.20.1228.011; Mon, 8 Oct 2018 13:23:45 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] Place to download Standard YANG Modules ? Thread-Index: AQHUXwPNxSBNWMXsz06OGatC9N6OC6UVTbeAgAAIg4A= Date: Mon, 8 Oct 2018 13:23:45 +0000 Message-ID: <4bcdc8d6-f776-3ae3-b452-29c64e92b131@ericsson.com> References: <20181008.145313.1979034555219874418.mbj@tail-f.com> In-Reply-To: <20181008.145313.1979034555219874418.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: AM3PR07CA0120.eurprd07.prod.outlook.com (2603:10a6:207:7::30) To HE1PR0701MB2731.eurprd07.prod.outlook.com (2603:10a6:3:99::9) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2716; 6:E/3NTY0oBNQPeJWtS0Et0X6SuCeUILbiu3y7BIhMzU0FxMXQpBGRSbWvSrjlZ8nab9844K5UPgBc7l7J4DbS5vMz4OESM2mHV4ugfujFHaTvy5A1bTVmlpZbwhTNj4Dh6iGqy4rtyIFH0SJz6B/mIeDN1lrBJhVKn076ECraw9w1TEelqkNT/nwbqgvUyE4zHJNt8zLrswaa1ylLHGX5721W4rqmC8wXmhagOUn8dV6n02oztjc4jYOTnN71dkxJciO262dy2/kFNBukrvhr+gwxoGWJBLWz3VQO92pJYKCzvOlwZK7a7SsEbhLcW9NfZ+DYEgFRdz5jHqtGVl4jlyhro5jNQB0o4n75ooFRI002FXIy5S8MmMLnmznFKe49SwAz7JAmV27vyKGqU3c+am1Z36kz+bwJ9epGcD17hOYPHfAkWuozVvIJYajCqN4QTR+UNUSybMRGZ2fKwnRx9g==; 5:FXSiL5BQ/gWRHhTJPvyiluYAXL40RrNeX8GBMBlz/llGtvB0y+af0pK3vCZmp+JwhoCcD2lQmlX+AiG8oUpwV9uIrwgOkJ+g16cBMbGhz/LiQyf2sFQT4kvZAMAFcjSbkvRYibdiSXe9HqOyoOSvf2ofzkI10fz7zhKJt+Z5+SI=; 7:KyaQH3fz4DzO4Ozp5ES/fb21aeAZCqwvV40/AiHuLTOJEL0Pps3y86VeAUUbdYqsNGCo2uC+q8OQX3X5iJFM09qINebM9fyCD9TPrRmapa9UNVpIOMSmmWE4P272wctNQZ+ktgnrueRh2Ku2ja8L6rgDXUf6445ykm9gopNuMa6nstD8613mZsSLWmOASkEQ9zge/scuyaIdOyrZ9DFg9Ud8s6miIeVi/3TRwv1EZwlBXevp/wDaBlUWwe6SqiiG x-ms-office365-filtering-correlation-id: 5767cc4b-8db4-4c89-2934-08d62d2144d7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR0701MB2716; x-ms-traffictypediagnostic: HE1PR0701MB2716: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(1591387915157)(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(4983020)(52105095)(10201501046)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(201708071742011)(7699051); SRVR:HE1PR0701MB2716; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2716; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(39860400002)(366004)(252514010)(51914003)(189003)(199004)(71190400001)(71200400001)(316002)(186003)(81156014)(81166006)(8676002)(68736007)(86362001)(478600001)(6512007)(6306002)(102836004)(8936002)(256004)(99936001)(25786009)(3260700006)(229853002)(53936002)(26005)(31686004)(446003)(476003)(11346002)(486006)(85182001)(14454004)(2616005)(105586002)(6436002)(64126003)(6116002)(106356001)(31696002)(4326008)(85202003)(3846002)(58126008)(5660300001)(36756003)(52116002)(2900100001)(65826007)(6246003)(97736004)(305945005)(7736002)(966005)(5250100002)(99286004)(65956001)(65806001)(6486002)(66066001)(76176011)(6916009)(386003)(6506007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2716; H:HE1PR0701MB2731.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IU1xGux+oiMXg29bKWxZZ2go2/febwx9HP75W3Ua+KSfMutlDv+Q6Mc/K4p2mJ8DBeCXhATIYJBRjefdfqxFyKLEocRjAXbTsgj7xN9TNoETMieQEV8VkzLqtycnmgXxkdgSrho1FOE2g0sB9Dc+vpkVKnSNTRoZ8y5B03wfeHfEQLPxjeX34ncirpikWKhx0udjRrJsKHaKA3EXe4CGEQdxxdxlgbUe8lh8df1ryNK0h9npNNUnOAqQvNb9E74ZLianHUezao1w0EhnjTrK90MKXjdwp5thlx2/kX0LXgQI586xZtxgU9ocY3Hz6bqGRBlUxRzRrdxLATrRuJCz1hSEC8kjAD401cQfIjVgzBM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000007040608030700070204" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5767cc4b-8db4-4c89-2934-08d62d2144d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 13:23:45.7177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2716 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTURjHOffezetqcVyaD2ZByyh6UdMMMyutCAmL+pKh+LL0ppJutatT +2BqljbLLLR0ZVouw3whp+R7qSGlZfgSWSnKciW6kPoQ4YaSd0ehvv2e5/n//+c5h8PSshGR CxuvTOLUSkWCXCxhSk43pezIDG0L88xa8PPNy/tu51s2mCkKoIL0+jkqqN5SwZygQiX+MVxC vIZTe+yPksRlW+PPz+xLbRm9zmSgm3u0yJ4FvAuKe6tEWiRhZbgHQbP5OkWK3wgMfUWIFBUU PB57a5swuICG6WwLTSZ3Kbja8NKOFN8QDN9/SQnJYnwYcmYJO+JNYGqpZQSm8WYY65sUaxHL rsYHwPDIg0gCoNRQg4S2I/aD+x/ThTaD3aC9dlgssHRRXXL7FSNIZFgDc81nhbY9DoQPXfki gRFeA3/6aihykDN8MZVR5JqOYBx8KybsBNOTCyLCciie+WJjJxwO2b0621MALkJgbrLSJDQC 2sdzl8zboX/EhAivg6GyvCXutINZfbiwG+Bj8GYqleQMI2ismhIte7V1hiVWQXWlkSpAXrp/ dtUtemh8DcGPab1YZ7uzA/SWmBgi2g0PGow04W1Q+dBM/28WeC8UW7rEhDdAYZ7RjrAPmHt+ IcLeUFk3Ly5HkqfIief4M4mxXl7unDo+mudVSncll2RAi1+sq9Hq2YympwK7EWaRfKU04WRb mEyk0PBpid3IbTHn67PqAeTCKFVKTu4odWpqDZNJYxRpFzm1KlKdnMDx3Wgty8idpb7HG0Jl OFaRxJ3juPOcenlKsfYuGeiS5nNdRc1m7xeXO9r63QP9099V5zq8Lr9xxdfsGjtunS89ujMu 49bA0IX6yi0tJit/aNM5i09j0Z33lhsavZ/HQOtE/puUiYPBo2lZ/uGF9T+PpKaUPlHdy0mO UkzQj4ZXhRg+jUR0PmuNOVsVWXRqhT5k2/rWwCCVNLqjwbUz+PlGOcPHKXZupdW84i/jDxRP agMAAA== Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:24:24 -0000 --------------ms000007040608030700070204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Martin, Thanks for the info. Yang-Catalog does not allow the download of modules. AFAIK it only gives = you metadata about the modules. You mentioned download from pyang. How does that work? I used https://github.com/YangModels/yang for some time, but I don't=20 know how up to date that is. regards On 2018. 10. 08. 14:53, Martin Bjorklund wrote: > Hi, > > > Balazs Lengyel wrote: >> Hello, >> >> What is the best way to download standard Yang Modules? I know the >> official answer is to download all the standards then extract the >> modules, however this is a "bit" cumbersome. Is there any better way? >> We had a git earlier. How up to date is that? > You can download them from IANA: > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml > > But there are two problems: > > 1) you have to download one at the time > 2) some of them have lost all indentation > (e.g. https://www.iana.org/assignments/yang-parameters/ietf-vouche= r@2018-04-06.yang) > > > [on 2), I have it on my list to talk to them] > > > Or you can get them from some 3rd party place like yang-catalog, or > pyang. > > > > /martin > > >> It would be wonderful if this could be described in the Netmod WG >> wiki. >> >> (And sorry, no but I am not volunteering :-(=C2=A0=C2=A0 ) >> >> regards Balazs >> >> --=20 >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms000007040608030700070204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwODEzMjM0MVow LwYJKoZIhvcNAQkEMSIEIICRWutwC+nwRHiV+Bz/NFK0lEZyyn+MW4MkCXfXIRXpMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAKVUR6/XBfXcLOd2hQPHZPcaiub3pvQJI8Lg7X3+yzumbb1G 0NPsvsHeNd+aL9JehYoeW9mMlBJQe2KjYl264Sm7w6ysausTmpM5uO+ptAYcbJBuGb1NqYSA M/VKfUswJ2COKL8ZJ1UfrjvvOJOtK82bE3paOUHq7lOpA0eGqXYSTiyppumi2Fbh+jOLApj4 ubeg5X1pGr05RlRyqgaeRC+5j83ec5l3BrKUzG10mrSasEnvjmruyrjxGtICrqTQLPmfrAfH Drks7Sr65JJ7BtcZ6Iaz6Uq7XGr3s7yXI70nzZxCjkjZKaHhv5Vvcjkii9IzzzzjHXw7J/0v OwlYMfsAAAAAAAA= --------------ms000007040608030700070204-- From nobody Mon Oct 8 06:51:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51266130DC0 for ; Mon, 8 Oct 2018 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 WesVxkNvLfA2 for ; Mon, 8 Oct 2018 06:51:30 -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 E6C4C12F1A5 for ; Mon, 8 Oct 2018 06:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5221; q=dns/txt; s=iport; t=1539006689; x=1540216289; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QSRasHdx0I8Ne2J10TqMWXlwouV9kcynLabNvG/MzYU=; b=CxCdm+p0cdnf7TMTajCIn5eT8O2mPbd4Zntk0wP4ijMd7xmUpUZfJnsU 7ESPTz/ejbMfgNKVN+7CMxqqr7l9X0Vblt7WecGtq3BAJl7OIoiUojbr1 oAI5r+HXmV/uEKFeZNAWUmnm3mcKMswMngRaQanfO6GEni+hA7DS0XHVZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AABgX7tb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYNZEoQdiHSNXphjDYRsAoRbOBYBAwEBAgEBAm0ohTk?= =?us-ascii?q?BAQEBAgEjDwEFLwUKEwkCDgoCAiYCAlcGAQwIAQEXgwaBegiIHptNgS6EAQF?= =?us-ascii?q?1hRWBC4pFgUE/gRIngmuBQYMngxeCVwKdbgmQQwYXgU6HTIZdiQ6GOYYrgVk?= =?us-ascii?q?hgVUzGggbFYMogiUMC41iATY+jwMBAQ?= X-IronPort-AV: E=Sophos;i="5.54,357,1534809600"; d="scan'208";a="7084078" 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; 08 Oct 2018 13:51:26 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w98DpQGG026383; Mon, 8 Oct 2018 13:51:27 GMT To: Lou Berger , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> From: Robert Wilton Message-ID: Date: Mon, 8 Oct 2018 14:51:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:51:32 -0000 Hi Lou, On 08/10/2018 13:57, Lou Berger wrote: > Hi Rob/All, > > Keep in mind that the document says what it says and that to change > text really requires a new version. > > On 10/8/2018 6:01 AM, Robert Wilton wrote: >> So there seem to be two available solutions here: >> >> (i) The server MUST provide an origin value for the top level datanode, > This is pretty close to what Andy previously quoted: > >      md:annotation origin { >        type origin-ref; >        description >          "The 'origin' annotation can be present on any configuration >           data node in the operational state datastore.  It specifies >           from where the node originated.  If not specified for a given >           configuration data node, then the origin is the same as the >           origin of its parent node in the data tree.  The origin for >           any top-level configuration data nodes must be specified."; >      } > > > I think it's clear that the reviewers, notably myself as shepherd, > missed that this is a lowercase "must" and should have asked for > clarification during the review process. So I think that the logic for it being must rather than MUST is that it is in a YANG module, and we didn't want to tie the YANG module to RFC 2119 language. > > Having an errata saying this "must" really is a "MUST" is quite > reasonable from my perspective. I'm not convinced that this has to change. > >> but for NP containers it can use whatever origin value it likes - since >> the origin value imparts no direct meaning other than the default origin >> that descendants acquire if they haven't provided an explicit origin. > >> In this case we would probably add a line of text to clarify this >> behavior of choosing a suitable origin value for top level NP >> containers. > I guess I'd need to see that specific language to understand if a new > requirement or recommended behavior is being prescribed.  If it is, we > need a new document to do so. The additional sentence (added at the paragraph above) could be something along the lines of: "For top level nodes that are non-presence containers, where the origin has no direct meaning other than as a hierarchical default origin, the server may choose any convenient origin value". But equally, perhaps the existing test is sufficient without requiring any changes at all.  Then the errata that is required is the one that Rohit submitted. Thanks, Rob > >> (ii) The requirement is weakened as Juergen has described previously. >> >> >> Solution (i) minimizes the impact of the change to the RFC, but probably >> constrains server implementations slightly more than is strictly >> required. >> >> Solution (ii) gives a bit more flexibility to server implementations but >> in theory could break client implementation that rely on a top level >> origin always being provided.  Although, in reality I would expect a >> robust client implementation to either not care, or choose a suitable >> default origin (e.g. "unknown") if an explicit origin hasn't been >> provided. >> >> If solution (ii) is beyond the scope of what is allowed in an errata >> then it would seem that we should go with solution (i) instead. But how >> do we get to a final decision? > > Either we agree that s/must/MUST in an errata or start a new (update > or bis) draft  to update the behavior.  It would also be fine to flag > the issue in the errata without specific resolution, with the > understanding that the issue would need to be resolved, in an update > or bis, at some point in the future. > > Lou > >> >> Thanks, >> Rob >> >> >> On 07/10/2018 18:09, Juergen Schoenwaelder wrote: >>> On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote: >>>> Can somebody explain the rationale for the highlighted text from >>>> 5.3.4? >>> Note the difference between "applies to" and "carries". A non-presence >>> container has no relevance for configuration and hence an origin value >>> does not *apply* to a non-presence container. Still, a non-presence >>> container can *carry* an origin attribute. >>> >>>> There are many top-level configuration NP-containers defined already. >>>> It is clearly more efficient to have 1 origin attribute in the >>>> top-level >>>> container than in each of the child nodes. >>> There is no requirement to produce efficient encodings. This is up to >>> implementations, the cost of calculating a minimal encodings may be >>> high for systems that like to stream information. That said, even >>> toplevel origin attributes are not sufficient to guarantee an >>> efficient encoding. If most child nodes have an origin different than >>> what is stated in the toplevel container, you gain little. >>> >>> The requirement really is that an origin must be defined for all >>> configuration data nodes (except np-containers). The way how this >>> is done    is up to implementations. If implementations want to set >>> default    origins    at the toplevel, so be it. >>> >>> /js >>> >> > > . > From nobody Mon Oct 8 07:14:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8BD130DCB for ; Mon, 8 Oct 2018 07:14:09 -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 9MCr7QLOvV-2 for ; Mon, 8 Oct 2018 07:14:07 -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 9D41B130DC0 for ; Mon, 8 Oct 2018 07:14:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5BB96DB8; Mon, 8 Oct 2018 16:14:00 +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 5EKtIHq1H1vp; Mon, 8 Oct 2018 16:13:57 +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; Mon, 8 Oct 2018 16:14:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4023A20038; Mon, 8 Oct 2018 16:14:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17P29GHGWDDc; Mon, 8 Oct 2018 16:14:00 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id CA0FC20036; Mon, 8 Oct 2018 16:13:58 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Mon, 8 Oct 2018 16:13:58 +0200 Received: by anna.localdomain (Postfix, from userid 501) id A2D7C3000D90E7; Mon, 8 Oct 2018 16:13:57 +0200 (CEST) Date: Mon, 8 Oct 2018 16:13:57 +0200 From: Juergen Schoenwaelder To: Lou Berger CC: Robert Wilton , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System Message-ID: <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Robert Wilton , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:14:09 -0000 On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote: > > I think it's clear that the reviewers, notably myself as shepherd, missed > that this is a lowercase "must" and should have asked for clarification > during the review process. > > Having an errata saying this "must" really is a "MUST" is quite reasonable > from my perspective. As explained, technically speaking, the "must" is pointless in certain situations. Making it a MUST does not make things any better. /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 Mon Oct 8 07:22:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA321130DE3 for ; Mon, 8 Oct 2018 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAMyYApwKODQ for ; Mon, 8 Oct 2018 07:22:06 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 CAC4F130DCB for ; Mon, 8 Oct 2018 07:22:06 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id EDBE9409D4 for ; Mon, 8 Oct 2018 07:55:05 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9W01gTCzcvdTu9W01gpU6s; Mon, 08 Oct 2018 07:55:05 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WiBSA8dvEiJT1RMj081HvDsT6UoVPYaqkLwGfg/iL1M=; b=iTAz0L37WtOKZk+pjNd/rB+a8E awYxxFfM5nQrvPJCuMQ1qZFg2pi+BQJwinfnVKJcIFox4TqrEeVdlxC6q76kRycY7LA7vQ5CUHCCi KJhoIJY8j//DyAS8EAnxawyVa; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:36136 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g9W01-000Tmw-JE; Mon, 08 Oct 2018 07:55:05 -0600 To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Martin Bjorklund Cc: "netmod@ietf.org" References: <20181008.145313.1979034555219874418.mbj@tail-f.com> <4bcdc8d6-f776-3ae3-b452-29c64e92b131@ericsson.com> From: Lou Berger Message-ID: <28fe460c-f450-f910-caff-17b145cd6805@labn.net> Date: Mon, 8 Oct 2018 09:55:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4bcdc8d6-f776-3ae3-b452-29c64e92b131@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g9W01-000Tmw-JE X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:36136 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 14:22:09 -0000 On 10/8/2018 9:23 AM, Balázs Lengyel wrote: > Hello Martin, > > Thanks for the info. > > Yang-Catalog does not allow the download of modules. AFAIK it only gives > you metadata about the modules. > You mentioned download from pyang. How does that work? > > I used https://github.com/YangModels/yang for some time, but I don't > know how up to date that is. It's not too bad.  just checked an it's just missing one RFC'ed model (standard/ietf/RFC/ietf-i2rs-rib@2018-09-13.yang) and I just put in a PR for it. (I have a cron job that auto generates branches to be merged, but do the PRs manually, see https://github.com/louberger/yang if interested.) Lou > > regards > > On 2018. 10. 08. 14:53, Martin Bjorklund wrote: >> Hi, >> >> >> Balazs Lengyel wrote: >>> Hello, >>> >>> What is the best way to download standard Yang Modules? I know the >>> official answer is to download all the standards then extract the >>> modules, however this is a "bit" cumbersome. Is there any better way? >>> We had a git earlier. How up to date is that? >> You can download them from IANA: >> >> https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml >> >> But there are two problems: >> >> 1) you have to download one at the time >> 2) some of them have lost all indentation >> (e.g. https://www.iana.org/assignments/yang-parameters/ietf-voucher@2018-04-06.yang) >> >> >> [on 2), I have it on my list to talk to them] >> >> >> Or you can get them from some 3rd party place like yang-catalog, or >> pyang. >> >> >> >> /martin >> >> >>> It would be wonderful if this could be described in the Netmod WG >>> wiki. >>> >>> (And sorry, no but I am not volunteering :-(   ) >>> >>> regards Balazs >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 8 09:05:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76575130E28 for ; Mon, 8 Oct 2018 09:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUijBowDPh6m for ; Mon, 8 Oct 2018 09:05:23 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 3992A130DE1 for ; Mon, 8 Oct 2018 09:05:23 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id AD18C1E0FAC for ; Mon, 8 Oct 2018 10:05:21 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9Y0IgqK5wo6eD9Y1ZgG0K3; Mon, 08 Oct 2018 10:05:20 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2HtEjcF9zT2akSA6jCrExcw/Ox4ObSHaH86szNmqQnM=; b=guKLR1V1Z6rfUBh/slwMfT6IDu eMvvHZFPZmVlg7ZrT9uyFkqkRJL1kKYFtzkXc8p0XREtMdggQJg9YUlASLJnMkXUJdoryKo3gDFCm Q2G2Xt6Y/H4ymTmsYFd0b21SS; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:51836 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g9Y07-0014P3-RI; Mon, 08 Oct 2018 10:03:19 -0600 To: Robert Wilton , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> From: Lou Berger Message-ID: <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net> Date: Mon, 8 Oct 2018 12:03:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g9Y07-0014P3-RI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:51836 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:05:24 -0000 On 10/8/2018 10:13 AM, Juergen Schoenwaelder wrote: > On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote: >> I think it's clear that the reviewers, notably myself as shepherd, missed >> that this is a lowercase "must" and should have asked for clarification >> during the review process. >> >> Having an errata saying this "must" really is a "MUST" is quite reasonable >> from my perspective. > As explained, technically speaking, the "must" is pointless in certain > situations. Making it a MUST does not make things any better. Okay - then all that needs to be done is clarify the errata and decide if you want to author a new draft on the behavior/text you'd like to change. Thanks, Lou > > /js > From nobody Mon Oct 8 09:34:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454BC130E28 for ; Mon, 8 Oct 2018 09:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf5IverL0m5c for ; Mon, 8 Oct 2018 09:34:05 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 EC9B0130E8F for ; Mon, 8 Oct 2018 09:34:04 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id F0CFF176E75 for ; Mon, 8 Oct 2018 10:04:48 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 9XzOgqIdRo6eD9Y0NgFysk; Mon, 08 Oct 2018 10:04:44 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7RXJ/M9GZ11GoB/UR+ganZTOp0XHKGLfmChFumcT5qg=; b=1uo+Uop2AQK4Imz1vAPspxuvlY RGoZPDIbEZr7speJPPloo9dRrstCLnqy1PpvmLldyBQ+hWtPw7gbz9JtJug/L7RkH2zTyGt+kM2i7 vOju5YsNVnihNbNQIOSPirpPt; Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:51736 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1g9Xz6-00148R-2O; Mon, 08 Oct 2018 10:02:16 -0600 To: Robert Wilton , Andy Bierman , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System References: <20181005094808.A049EB800AE@rfc-editor.org> <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> From: Lou Berger Message-ID: <3234b791-81c3-2bfc-43b8-c5a56bfd33f3@labn.net> Date: Mon, 8 Oct 2018 12:02:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.106.211 X-Source-L: No X-Exim-ID: 1g9Xz6-00148R-2O X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:51736 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 16:34:14 -0000 Hi Rob, On 10/8/2018 9:51 AM, Robert Wilton wrote: > Hi Lou, > > > On 08/10/2018 13:57, Lou Berger wrote: >> Hi Rob/All, >> >> Keep in mind that the document says what it says and that to change >> text really requires a new version. >> >> On 10/8/2018 6:01 AM, Robert Wilton wrote: >>> So there seem to be two available solutions here: >>> >>> (i) The server MUST provide an origin value for the top level datanode, >> This is pretty close to what Andy previously quoted: >> >>      md:annotation origin { >>        type origin-ref; >>        description >>          "The 'origin' annotation can be present on any configuration >>           data node in the operational state datastore.  It specifies >>           from where the node originated.  If not specified for a given >>           configuration data node, then the origin is the same as the >>           origin of its parent node in the data tree.  The origin for >>           any top-level configuration data nodes must be specified."; >>      } >> >> >> I think it's clear that the reviewers, notably myself as shepherd, >> missed that this is a lowercase "must" and should have asked for >> clarification during the review process. > So I think that the logic for it being must rather than MUST is that it > is in a YANG module, and we didn't want to tie the YANG module to RFC > 2119 language. I'm not sure this is a great argument.  Using conformance language in such cases maybe exactly what is needed - but this is a different discussion. > >> Having an errata saying this "must" really is a "MUST" is quite >> reasonable from my perspective. > I'm not convinced that this has to change. > >>> but for NP containers it can use whatever origin value it likes - since >>> the origin value imparts no direct meaning other than the default origin >>> that descendants acquire if they haven't provided an explicit origin. >>> In this case we would probably add a line of text to clarify this >>> behavior of choosing a suitable origin value for top level NP >>> containers. >> I guess I'd need to see that specific language to understand if a new >> requirement or recommended behavior is being prescribed.  If it is, we >> need a new document to do so. > The additional sentence (added at the paragraph above) could be > something along the lines of: > > "For top level nodes that are non-presence containers, where the origin > has no direct meaning other than as a hierarchical default origin, the > server may choose any convenient origin value". > > But equally, perhaps the existing test is sufficient without requiring > any changes at all. I agree, it's not clear that this change is need as it is *already* what is allowed. > Then the errata that is required is the one that > Rohit submitted. so the errata should be corrected Lou > > Thanks, > Rob > > >>> (ii) The requirement is weakened as Juergen has described previously. >>> >>> >>> Solution (i) minimizes the impact of the change to the RFC, but probably >>> constrains server implementations slightly more than is strictly >>> required. >>> >>> Solution (ii) gives a bit more flexibility to server implementations but >>> in theory could break client implementation that rely on a top level >>> origin always being provided.  Although, in reality I would expect a >>> robust client implementation to either not care, or choose a suitable >>> default origin (e.g. "unknown") if an explicit origin hasn't been >>> provided. >>> >>> If solution (ii) is beyond the scope of what is allowed in an errata >>> then it would seem that we should go with solution (i) instead. But how >>> do we get to a final decision? >> Either we agree that s/must/MUST in an errata or start a new (update >> or bis) draft  to update the behavior.  It would also be fine to flag >> the issue in the errata without specific resolution, with the >> understanding that the issue would need to be resolved, in an update >> or bis, at some point in the future. >> >> Lou >> >>> Thanks, >>> Rob >>> >>> >>> On 07/10/2018 18:09, Juergen Schoenwaelder wrote: >>>> On Sun, Oct 07, 2018 at 09:49:57AM -0700, Andy Bierman wrote: >>>>> Can somebody explain the rationale for the highlighted text from >>>>> 5.3.4? >>>> Note the difference between "applies to" and "carries". A non-presence >>>> container has no relevance for configuration and hence an origin value >>>> does not *apply* to a non-presence container. Still, a non-presence >>>> container can *carry* an origin attribute. >>>> >>>>> There are many top-level configuration NP-containers defined already. >>>>> It is clearly more efficient to have 1 origin attribute in the >>>>> top-level >>>>> container than in each of the child nodes. >>>> There is no requirement to produce efficient encodings. This is up to >>>> implementations, the cost of calculating a minimal encodings may be >>>> high for systems that like to stream information. That said, even >>>> toplevel origin attributes are not sufficient to guarantee an >>>> efficient encoding. If most child nodes have an origin different than >>>> what is stated in the toplevel container, you gain little. >>>> >>>> The requirement really is that an origin must be defined for all >>>> configuration data nodes (except np-containers). The way how this >>>> is done    is up to implementations. If implementations want to set >>>> default    origins    at the toplevel, so be it. >>>> >>>> /js >>>> >> . >> > From nobody Mon Oct 8 10:17:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84A130E55 for ; Mon, 8 Oct 2018 10:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 OX7NJDoPQWyu for ; Mon, 8 Oct 2018 10:17:14 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2E8130E01 for ; Mon, 8 Oct 2018 10:16:21 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id u21-v6so18548217lja.8 for ; Mon, 08 Oct 2018 10:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gk8eBgkGBmGvmKm/lVES/iyFc81WWjfSQfBPMNL4Dqk=; b=Ru/chmwrk8mQPOBvy0kiIlYiX7zR1VEWAt4UV+4kCeu0Zx5vNJP6okU5fX5oZHedbB QiFFFpFIvoeSozBKum2Z63TUy24UQ/ceCD1bIkRV1W7S7KvGs0Yr7wRKpmh2iiLazaGx Co+3GuSNN1BVzQIl95GXoq0118QxTDp6WqL69LC+sCYXuF1vH2C71m0vPIOuTAZeOwwG WpUqhIlQhIf9PEMo3364iLp+ICh54pTezPXFly3GtjsuXdizvFXp3w596DKolDkKVlev WaETpj6+mZJ9fqZ4Bu0HzGQsAYHlx1v2nxyW4+zoe6PmmgTKzWzI9+75+6MD7PIBtqA7 kKVA== 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=gk8eBgkGBmGvmKm/lVES/iyFc81WWjfSQfBPMNL4Dqk=; b=qhLVY8ZNucqhRMqNKm+RpaseI1ISQrR5VfQlD+2/AapkH4O5vp4LVb9qkGTgPnG+RZ fUNDlHQTXLwQJoVb8BU2PKCEVUlRPMCfFVoxznRZrBc0kTw+QKUixQ6ft/NX/EPyIsj4 b67FIn+S4xtkYTKVLJOujfx1ZtGRSzRC9nSaBlgWeXWrfY+UiIuEcaGpARnQ3EwIpO0b TC7cYXPLlIE4JXBCAaFHtV4nW7+8yjS48SqXlEdveBuALkj0O3pXJVhwHpsn10bCHFPP kyXnfld9EKbhEEps6UGaMUs/26r2en3odP8f/8QDLKdqkeNodT050S8Ds3BmlmKa8Vm2 Xokw== X-Gm-Message-State: ABuFfohI9owuCvhjToyAAPc9k52BdIpINjRQnRGKlhP4LORmnQbAEi/u WcZ11SvFWsmRAmFzN2ey3kpCAkMdhnGgeZS/ZY6cHQ== X-Google-Smtp-Source: ACcGV63b/vi1+yVTO0aLwCFP1j8kNvk7BxJzTa0KuO/yQgsUDQ7Z6ALBFVMKX9ZP+XyWN3de5INfxqXiGcXF6RNfDiE= X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr16679945lja.21.1539018979611; Mon, 08 Oct 2018 10:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Mon, 8 Oct 2018 10:16:18 -0700 (PDT) In-Reply-To: <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net> References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net> From: Andy Bierman Date: Mon, 8 Oct 2018 10:16:18 -0700 Message-ID: To: Lou Berger Cc: Robert Wilton , Ignas Bagdonas , NetMod WG , Warren Kumari , RFC Errata System Content-Type: multipart/alternative; boundary="000000000000952fa90577bac795" Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:17:17 -0000 --000000000000952fa90577bac795 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 8, 2018 at 9:03 AM, Lou Berger wrote: > > > On 10/8/2018 10:13 AM, Juergen Schoenwaelder wrote: > >> On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote: >> >>> I think it's clear that the reviewers, notably myself as shepherd, missed >>> that this is a lowercase "must" and should have asked for clarification >>> during the review process. >>> >>> Having an errata saying this "must" really is a "MUST" is quite >>> reasonable >>> from my perspective. >>> >> As explained, technically speaking, the "must" is pointless in certain >> situations. Making it a MUST does not make things any better. >> > Okay - then all that needs to be done is clarify the errata and decide if > you want to author a new draft on the behavior/text you'd like to change. > > After reading the RFC details, it seems that the example is intentional based on the text about NP-containers. I think an errata could be used because the sentence about a top-level origin must be defined could be interpreted to define "top-level" as the topmost level for which the origin property is applicable. It appears the intent was to exclude NP-containers from this requirement. Thanks, > Lou > Andy > > >> /js >> >> > --000000000000952fa90577bac795 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 8, 2018 at 9:03 AM, Lou Berger <lberger@labn.net> wrote:


On 10/8/2018 10:13 AM, Juergen Schoenwaelder wrote:
On Mon, Oct 08, 2018 at 08:57:33AM -0400, Lou Berger wrote:
I think it's clear that the reviewers, notably myself as shepherd, miss= ed
that this is a lowercase "must" and should have asked for clarifi= cation
during the review process.

Having an errata saying this "must" really is a "MUST" = is quite reasonable
from my perspective.
As explained, technically speaking, the "must" is pointless in ce= rtain
situations. Making it a MUST does not make things any better.
Okay - then all that needs to be done is clarify the errata and decide if y= ou want to author a new draft on the behavior/text you'd like to change= .



After reading the RFC d= etails, it seems that the example is intentional based on
the tex= t about NP-containers.=C2=A0

I think an errata cou= ld be used because the sentence about a top-level origin must be defined
could be interpreted to define "top-level" as the topmost= level for which the origin property
is applicable.=C2=A0 It appe= ars the intent was to exclude NP-containers from this requirement.


Thanks,
Lou

Andy
=C2=A0


/js



--000000000000952fa90577bac795-- From nobody Mon Oct 8 10:34:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9B131225 for ; Mon, 8 Oct 2018 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPOEXOrHDu8I for ; Mon, 8 Oct 2018 10:34:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8E206130FA2 for ; Mon, 8 Oct 2018 10:29:09 -0700 (PDT) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 5E5C21AE0332; Mon, 8 Oct 2018 19:29:08 +0200 (CEST) Date: Mon, 08 Oct 2018 19:29:08 +0200 (CEST) Message-Id: <20181008.192908.2132329492705733862.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <4bcdc8d6-f776-3ae3-b452-29c64e92b131@ericsson.com> References: <20181008.145313.1979034555219874418.mbj@tail-f.com> <4bcdc8d6-f776-3ae3-b452-29c64e92b131@ericsson.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:34:04 -0000 Bal=E1zs Lengyel wrote: > Hello Martin, > = > Thanks for the info. > = > Yang-Catalog does not allow the download of modules. AFAIK it only > gives you metadata about the modules. > You mentioned download from pyang. How does that work? I just meant that the pyang github repo contains the published IETF YANG models. /martin > = > I used https://github.com/YangModels/yang for some time, but I don't > know how up to date that is. > = > regards > = > On 2018. 10. 08. 14:53, Martin Bjorklund wrote: > > Hi, > > > > > > Balazs Lengyel wrote: > >> Hello, > >> > >> What is the best way to download standard Yang Modules? I know the= > >> official answer is to download all the standards then extract the > >> modules, however this is a "bit" cumbersome. Is there any better w= ay? > >> We had a git earlier. How up to date is that? > > You can download them from IANA: > > > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xh= tml > > > > But there are two problems: > > > > 1) you have to download one at the time > > 2) some of them have lost all indentation > > (e.g. https://www.iana.org/assignments/yang-parameters/ietf-vo= ucher@2018-04-06.yang) > > > > > > [on 2), I have it on my list to talk to them] > > > > > > Or you can get them from some 3rd party place like yang-catalog, or= > > pyang. > > > > > > > > /martin > > > > > >> It would be wonderful if this could be described in the Netmod WG > >> wiki. > >> > >> (And sorry, no but I am not volunteering :-(=A0=A0 ) > >> > >> regards Balazs > >> > >> -- = > >> Balazs Lengyel Ericsson Hungary Ltd. > >> Senior Specialist > >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > >> > >> > -- = > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > = > = From nobody Mon Oct 8 10:55:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D61129C6A for ; Mon, 8 Oct 2018 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8z4f6YUx93N for ; Mon, 8 Oct 2018 10:55:06 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 2E9E0130EBB for ; Mon, 8 Oct 2018 10:54:40 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w98Hs8jj026316; Mon, 8 Oct 2018 10:54:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=97KvqrkOPVV87PkUnb01jowHvbK584M1QkxtaoVJyfg=; b=r4Zr/s6/PsT6N5ZbrBmgsPvA9Wb8Nx6Zd+AyU2P8aaor3a7Lz9BcvIHDB1ldvTWHG6ZI vXGKEO6rvEnq2oxyVRU13wr6uPN0Pwz68iDL0mTembMXCwALydzlIAreWFn20hHbQ6J0 ETLJqwEilRCuK3tcvNXG0Ml1zS1erSaDGoUPZO7ndx7MQEp56o1GhDfSYO4C0Xdihq2V L92vmImcoeEz7hE0CHmBHrNXDSSP1v21+KY721o7WVoT6Jx2W9x+/BctDARJ06vSHDc6 ya6zrEfbuz7VyDOhdGOxZhwRHkuIyC5fLR90Y8LRAjJL+ZcQ88AoFP9xkFg/DhCjyRNK xw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0015.outbound.protection.outlook.com [207.46.163.15]) by mx0a-00273201.pphosted.com with ESMTP id 2n040ygttt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Oct 2018 10:54:38 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4778.namprd05.prod.outlook.com (20.176.110.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.16; Mon, 8 Oct 2018 17:54:36 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.024; Mon, 8 Oct 2018 17:54:36 +0000 From: Kent Watsen To: Andy Bierman , Lou Berger CC: Ignas Bagdonas , Warren Kumari , NetMod WG , RFC Errata System Thread-Topic: [netmod] [Technical Errata Reported] RFC8342 (5514) Thread-Index: AQHUXJCRbKQ2UOiYQk2nB4o6EpbXyqUQb0OAgAAhjoCAACVcAIAAHT8AgAALWACAAntMgIAAqF2AgAAFW4CAARrTgIAAMTiAgAAVWYCAAB6NAIAAFGYA///HtgA= Date: Mon, 8 Oct 2018 17:54:35 +0000 Message-ID: <8385F653-C23A-4101-BE30-11670D4DD4FA@juniper.net> References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4778; 6:Sy/O/KloVJF0Fn9GApBrT+Nqpir9obnPxaC1pgKRLB7BZRNAzWSbB3I4BugaImfD5yPEJDM6auPg/08WJjCsSXm8MdUEKQqWmk+JbdctZyT8W99XmCOqzXuQbXrcn7XhqnzIwWCVhkdC14snbWUrSHcdplDXYp96P8KCyaIus86RMgGw2sDMhKvzwfPLBSv/0XZa/VEKzXVyR5+Yb4qrMBuxwdNG09cI/ScwSCUXSyEDsHkInahEW4OefC3QOvIKnYPabvVi7R4Y8DBPvE9tX5ZXPyE6D4WeyfnFqG9BYG1ZlgXVyPAUehW9VMaRsYHvEgsxXGGVD6Euris2qC2Ki2ueaQ3p9CRrfeqNsjx+fQD9esMO1LdBldu/hLtabVn7qejHGcRFwGvYxycfNmAk4ciJkhgAL0fjlVPapqgt+07+tq2pMDx4gDtIjg7sJ1q9E5NoiIqxknL6tG5ItOgFgw==; 5:XwJcOsPAgGvtbcqzKOltOWtXpzTsRgzJ0ovnUH8IwNzF9bXNgHzlf8ZjGRiduJtvcA2Fe8/UykBV9w7Kvd9uGt8pJPRqfeZUkOlRIMfvaO3/Fc17+1toG82Tom6TGPVlk3ktCWWAHTBq9C0xApd/NrvC/zlJSkJNX3ZNKszYH7A=; 7:vAS3c5YEcfLA8NCaF5Eqi/pKOtl/yuMgqnHGIAW+Z2/kCQBelMsnM3LcpaaQMuMcKFuuqJmgKNkCZ3WBQoA8oR265CZeu9OSsLctUdXvMmRvU7A7bY+8nZ5o+WtHmceJCjG2u2/Gk9ILNsshqReq+ymo4+h+iJbUEPiS3AXD0lWN/fhgCZFEM7Ijl8sdTbww1IvAPnzNAfhUd+zr/S1Is//bVfPHdjimhV//13tlfkXxz3kZdsZWM7zO1/1dbVok x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2dce838a-5936-42a9-0cb5-08d62d471c5a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4778; x-ms-traffictypediagnostic: DM6PR05MB4778: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991055); SRVR:DM6PR05MB4778; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4778; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(396003)(376002)(39860400002)(136003)(199004)(189003)(39060400002)(83716004)(102836004)(66066001)(478600001)(7736002)(25786009)(71190400001)(33656002)(97736004)(71200400001)(4326008)(68736007)(86362001)(3846002)(6116002)(256004)(476003)(2616005)(26005)(76176011)(99286004)(105586002)(6346003)(58126008)(6506007)(54906003)(110136005)(316002)(106356001)(2900100001)(53936002)(36756003)(6246003)(93886005)(8676002)(2906002)(486006)(186003)(14454004)(82746002)(446003)(11346002)(6486002)(6436002)(54896002)(6306002)(8936002)(229853002)(5660300001)(81166006)(81156014)(6512007)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4778; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9etPosCgKDWb1bWcYLRfZGsY+apupyu+vcanMGX7T/ePctsCvoOHG1gPGLJPscBs2XUx1CtZgLOJxNJdek8PTeYbR/nAQHIq0Wy8cmv9gzl/SIngCZ7ztXEWlXNAeL/insEnCWnXNDmxqkZaTbn4nTS2AE7x3KfsVVOCrzlRlEyv7rUN7dSruSFUk2WAK8zxJj+PA5awETqs1Meb1ia3YEcZ+OIONFRkwbo6qgIgvF5EjBUxfer3FU9GaEZNFDVhHIrZFtZ3xSJT7AE0LkPlIFIKJjWj3giL7dP0M8IqUIPJZ9iABE6jfeo3zARY6CKD7TsaXU555KpNV0o4eTiv6UitnOy3tisPnB9b4Z3w27U= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8385F653C23A4101BE3011670D4DD4FAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 2dce838a-5936-42a9-0cb5-08d62d471c5a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 17:54:35.9864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4778 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810080168 Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 17:55:10 -0000 --_000_8385F653C23A4101BE3011670D4DD4FAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEFmdGVyIHJlYWRpbmcgdGhlIFJGQyBkZXRhaWxzLCBpdCBzZWVtcyB0aGF0IHRoZSBleGFt cGxlIGlzIGludGVudGlvbmFsIGJhc2VkIG9uDQo+IHRoZSB0ZXh0IGFib3V0IE5QLWNvbnRhaW5l cnMuDQo+DQo+IEkgdGhpbmsgYW4gZXJyYXRhIGNvdWxkIGJlIHVzZWQgYmVjYXVzZSB0aGUgc2Vu dGVuY2UgYWJvdXQgYSB0b3AtbGV2ZWwgb3JpZ2luIG11c3QgYmUgZGVmaW5lZA0KPiBjb3VsZCBi ZSBpbnRlcnByZXRlZCB0byBkZWZpbmUgInRvcC1sZXZlbCIgYXMgdGhlIHRvcG1vc3QgbGV2ZWwg Zm9yIHdoaWNoIHRoZSBvcmlnaW4gcHJvcGVydHkNCj4gaXMgYXBwbGljYWJsZS4gIEl0IGFwcGVh cnMgdGhlIGludGVudCB3YXMgdG8gZXhjbHVkZSBOUC1jb250YWluZXJzIGZyb20gdGhpcyByZXF1 aXJlbWVudC4NCg0KWWVzLCBpdCB3YXMgaW50ZW50aW9uYWwgdG8gZXhjbHVkZSBucC1jb250YWlu ZXJzLCBJIHZpZXcgc29tZXRoaW5nIGxpa2U6DQoNCk9MRDoNCiAgICBUaGUgb3JpZ2luIGZvciBh bnkgdG9wLWxldmVsIGNvbmZpZ3VyYXRpb24gZGF0YSBub2RlcyBtdXN0IGJlIHNwZWNpZmllZC4N Ck5FVzoNCiAgICBUaGUgb3JpZ2luIGZvciBhbnkgdG9wLWxldmVsIGNvbmZpZ3VyYXRpb24gZGF0 YSBub2RlcywgZXhjZXB0DQogICAgbm9uLXByZXNlbmNlIGNvbnRhaW5lcnMsIG11c3QgYmUgc3Bl Y2lmaWVkLg0KDQp0byBiZSBhbG1vc3QgZWRpdG9yaWFsIGluIG5hdHVyZS4gIFRoYXQgc2FpZCwg SSBhbHNvIGRvIG5vdCB0aGluayB0aGF0IGl04oCZcyBuZWVkZWQsIGluIHRoYXQgSSB0aGluaw0K b25lIGNvdWxkIGFyZ3VlIHRoYXQgYW4gbnAtY29udGFpbmVyIGlzbuKAmXQgYWN0dWFsbHkg4oCc Y29uZmlndXJhdGlvbuKAnSBhdCBhbGwsIGl04oCZcyBqdXN0IGltcGxpY2l0bHkNCnRoZXJlIHBy b3ZpZGluZyBhIHNrZWxldG9uIHRvIGhhbmcgc3R1ZmYgb2ZmIG9mLg0KDQpSRkMgODM0MiBzYXlz Og0KDQogICBvICBjb25maWd1cmF0aW9uOiBEYXRhIHRoYXQgaXMgcmVxdWlyZWQgdG8gZ2V0IGEg ZGV2aWNlIGZyb20gaXRzDQogICAgICBpbml0aWFsIGRlZmF1bHQgc3RhdGUgaW50byBhIGRlc2ly ZWQgb3BlcmF0aW9uYWwgc3RhdGUuDQoNCkFuIG5wLWNvbnRhaW5lciBkb2VzbuKAmXQgYWN0dWFs bHkgZG8gdGhpcy4gICBSRkMgNzk1MCBzYXlzOg0KDQogICBvICBub24tcHJlc2VuY2UgY29udGFp bmVyOiBBIGNvbnRhaW5lciB0aGF0IGhhcyBubyBtZWFuaW5nIG9mIGl0cw0KICAgICAgb3duLCBl eGlzdGluZyBvbmx5IHRvIGNvbnRhaW4gY2hpbGQgbm9kZXMuDQoNCkJpbmdvLiAgUkZDIDc5NTAg YWxzbyBzYXlzOg0KDQogICBvICBkYXRhIG5vZGU6IEEgbm9kZSBpbiB0aGUgc2NoZW1hIHRyZWUg dGhhdCBjYW4gYmUgaW5zdGFudGlhdGVkIGluIGENCiAgICAgICBkYXRhIHRyZWUuICBPbmUgb2Yg Y29udGFpbmVyLCBsZWFmLCBsZWFmLWxpc3QsIGxpc3QsICBhbnlkYXRhLCBhbmQgYW55eG1sLg0K DQpOb3RlIHRoYXQgaXQgc2F5cyDigJxjb250YWluZXLigJ0gd2l0aG91dCBjbGFyaWZpY2F0aW9u LiAgQ2xlYXJseSBhbiBucC1jb250YWluZXIgaXNu4oCZdCDigJxkYXRh4oCdDQpzbywgaWYgdGhl cmUgaXMgdG8gYmUgYW4gZXJyYXRhLCBwZXJoYXBzIGl0IHNob3VsZCBiZSBhZ2FpbnN0ICBSRkMg Nzk1MCwgZm9yIGluc3RhbmNlOg0KDQpORVcNCiAgIG8gIGRhdGEgbm9kZTogQSBub2RlIGluIHRo ZSBzY2hlbWEgdHJlZSB0aGF0IGNhbiBiZSBpbnN0YW50aWF0ZWQgaW4gYQ0KICAgICAgIGRhdGEg dHJlZS4gIE9uZSBvZiBwcmVzZW5jZSBjb250YWluZXIsIGxlYWYsIGxlYWYtbGlzdCwgbGlzdCwg IGFueWRhdGEsIGFuZCBhbnl4bWwuDQoNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQo= --_000_8385F653C23A4101BE3011670D4DD4FAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <841E54918164124AA397828B6C061996@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFy aWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNm b3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgQWZ0ZXIgcmVh ZGluZyB0aGUgUkZDIGRldGFpbHMsIGl0IHNlZW1zIHRoYXQgdGhlIGV4YW1wbGUgaXMgaW50ZW50 aW9uYWwgYmFzZWQgb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyB0aGUgdGV4dCBhYm91dCBOUC1j b250YWluZXJzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jmd0OyBJIHRoaW5rIGFuIGVycmF0YSBjb3VsZCBiZSB1c2VkIGJlY2F1c2UgdGhlIHNlbnRl bmNlIGFib3V0IGEgdG9wLWxldmVsIG9yaWdpbiBtdXN0IGJlIGRlZmluZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jmd0OyBjb3VsZCBiZSBpbnRlcnByZXRlZCB0byBkZWZpbmUgJnF1b3Q7dG9wLWxldmVs JnF1b3Q7IGFzIHRoZSB0b3Btb3N0IGxldmVsIGZvciB3aGljaCB0aGUgb3JpZ2luIHByb3BlcnR5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgaXMgYXBwbGljYWJsZS4mbmJzcDsgSXQgYXBwZWFycyB0 aGUgaW50ZW50IHdhcyB0byBleGNsdWRlIE5QLWNvbnRhaW5lcnMgZnJvbSB0aGlzIHJlcXVpcmVt ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+WWVzLCBpdCB3 YXMgaW50ZW50aW9uYWwgdG8gZXhjbHVkZSBucC1jb250YWluZXJzLCBJIHZpZXcgc29tZXRoaW5n IGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PTEQ6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgb3JpZ2luIGZvciBhbnkgdG9w LWxldmVsIGNvbmZpZ3VyYXRpb24gZGF0YSBub2RlcyBtdXN0IGJlIHNwZWNpZmllZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhl IG9yaWdpbiBmb3IgYW55IHRvcC1sZXZlbCBjb25maWd1cmF0aW9uIGRhdGEgbm9kZXMsIGV4Y2Vw dA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO25vbi1wcmVzZW5j ZSBjb250YWluZXJzLCBtdXN0IGJlIHNwZWNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPnRvIGJlIGFsbW9zdCBlZGl0b3JpYWwgaW4gbmF0dXJlLiZuYnNw OyBUaGF0IHNhaWQsIEkgYWxzbyBkbyBub3QgdGhpbmsgdGhhdCBpdOKAmXMgbmVlZGVkLCBpbiB0 aGF0IEkgdGhpbms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+b25lIGNvdWxkIGFyZ3VlIHRoYXQgYW4gbnAt Y29udGFpbmVyIGlzbuKAmXQgYWN0dWFsbHkg4oCcY29uZmlndXJhdGlvbuKAnSBhdCBhbGwsIGl0 4oCZcyBqdXN0IGltcGxpY2l0bHkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50aGVyZSBwcm92aWRpbmcg YSBza2VsZXRvbiB0byBoYW5nIHN0dWZmIG9mZiBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPlJGQyA4MzQyIHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBjb25maWd1cmF0aW9uOiBE YXRhIHRoYXQgaXMgcmVxdWlyZWQgdG8gZ2V0IGEgZGV2aWNlIGZyb20gaXRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbml0aWFsIGRlZmF1bHQgc3Rh dGUgaW50byBhIGRlc2lyZWQgb3BlcmF0aW9uYWwgc3RhdGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbiBucC1jb250YWluZXIgZG9lc27igJl0IGFjdHVhbGx5 IGRvIHRoaXMuJm5ic3A7Jm5ic3A7IFJGQyA3OTUwIHNheXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBub24tcHJlc2VuY2Ug Y29udGFpbmVyOiBBIGNvbnRhaW5lciB0aGF0IGhhcyBubyBtZWFuaW5nIG9mIGl0czxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3duLCBleGlzdGluZyBv bmx5IHRvIGNvbnRhaW4gY2hpbGQgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5CaW5nby4mbmJzcDsgUkZDIDc5NTAgYWxzbyBzYXlzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgZGF0 YSBub2RlOiBBIG5vZGUgaW4gdGhlIHNjaGVtYSB0cmVlIHRoYXQgY2FuIGJlIGluc3RhbnRpYXRl ZCBpbiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkYXRhIHRyZWUuJm5ic3A7IE9uZSBvZiBjb250YWluZXIsIGxlYWYsIGxlYWYtbGlzdCwg bGlzdCwmbmJzcDsgYW55ZGF0YSwgYW5kIGFueXhtbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPk5vdGUgdGhhdCBpdCBzYXlzIOKAnGNvbnRhaW5lcuKAnSB3aXRo b3V0IGNsYXJpZmljYXRpb24uJm5ic3A7IENsZWFybHkgYW4gbnAtY29udGFpbmVyIGlzbuKAmXQg 4oCcZGF0YeKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5zbywgaWYgdGhlcmUgaXMgdG8gYmUgYW4gZXJy YXRhLCBwZXJoYXBzIGl0IHNob3VsZCBiZSBhZ2FpbnN0ICZuYnNwO1JGQyA3OTUwLCBmb3IgaW5z dGFuY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5ORVc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgZGF0YSBub2RlOiBBIG5vZGUgaW4g dGhlIHNjaGVtYSB0cmVlIHRoYXQgY2FuIGJlIGluc3RhbnRpYXRlZCBpbiBhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhIHRyZWUuJm5i c3A7IE9uZSBvZiBwcmVzZW5jZSBjb250YWluZXIsIGxlYWYsIGxlYWYtbGlzdCwgbGlzdCwmbmJz cDsgYW55ZGF0YSwgYW5kIGFueXhtbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5LZW50IC8vIGNvbnRyaWJ1dG9yPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_8385F653C23A4101BE3011670D4DD4FAjunipernet_-- From nobody Mon Oct 8 11:14:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F930129C6A; Mon, 8 Oct 2018 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szq-_YEURzHi; Mon, 8 Oct 2018 11:13:57 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332F3130DDF; Mon, 8 Oct 2018 11:13:57 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w98IDuBC005777; Mon, 8 Oct 2018 11:13:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=AURUR5Z7TptRnHydwcL6JOiUNCX+vYa0+iDQveb/ZfU=; b=qqVPjhvY+rKHDqiTCaDny/nmrvG9xmAXBc3y1mUm3KRYf1XT+Hk+XKAH2HVLIT568lv1 w+SCgqJUmC1STmEBZmNf32RwdjxmazwgwtbGsWbPgO0vaasvP/50I5EAdubQkqtthM/V VuNoaFELLxmaqHUETGj7cKcyqf8cG2+pJJwD6XN+p1GrZk3XdfMgrhZgQBpa0gmnjRGs 0OMNrdCiQg50P+k6NgK9YMXjqyCzUVeWLQtQB7u5COuglaTZLAz7XeYIbEzBo0Xa/Kc0 wwCc7z6LndtGtUgc6dLM428EUUnaP9UmnQQpZPzOuWndvaPCd+bdbjw3owH6UeOS5BQE zg== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0085.outbound.protection.outlook.com [216.32.181.85]) by mx0b-00273201.pphosted.com with ESMTP id 2n099j0ayc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Oct 2018 11:13:56 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5308.namprd05.prod.outlook.com (20.176.119.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.13; Mon, 8 Oct 2018 18:13:53 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1207.024; Mon, 8 Oct 2018 18:13:53 +0000 From: Kent Watsen To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: IETF 103 presentation requests Thread-Index: AQHUXzKrmmX1hyn0302py/pUt7+ztw== Date: Mon, 8 Oct 2018 18:13:53 +0000 Message-ID: <95A6EEE5-5CC2-4A07-AB58-829CA74FE7DE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB5308; 6:dCpyoW6AvU/Lp3wCHiheKatOWvqwMMnNKb5lv+M3A7Qu5lQHN4yHqmDYOg4FMX6NPGg78xP2nZKXPDrx+z+AFKDaxT0vg7val+lDrryM+ypu9Nny9tLmOzRwhWYPhaoTXBGSJq6sSpWZfcL+W5LDAXh2EYrwitJ+FNgZCiCwgow8CebAD1qKjNMe56n6pe0KIfg6W0Z3q4nJIoXVGIIXaCG3QfodVlIoHqVmeaGfB22QwMim7/MFzfdrNgGnY+B70ymhcuCmnGF7KApVx3FKJwwqmIibTtetSAbNHGpfzpb2ZVWdf7qnIRopT+Gt7N+RmZjWIeynufHoAxtceR3O+QNk/NM7fsWZD2HH2NNxFuxAm1Emb+PCeC4c5YdDeRnXmXd59ykGTt+xA4LgdwmtxsDUO77J/1WZu8BrsCVdpkzVvq350Ow+RZFAgk+7/hEtwl0Pycs2pGxwFpH/5juLew==; 5:uXySRiVUYKzwp3Q7E1C0pOJJ2liTgwosQIVsUDOzXjgca9X+VIlp3S9jHXJ0EPeU6ByixZ8WW9h5wbDB4fTyWqQ+mhDV/K53Bm0Z4RkjRyqZq2OZTlQY5Wxlvtf5vJABhSpO/K25AhQuTyx47O6u5PwA+XUiZMYmhvGZnWaWAsU=; 7:0IjygSeIgM/sA0L3YodTS9GzWisWgp6AeQ1pGuJaK1t+ixuwUvV2nRo+qwiIMyCfcmsYYHX27A/H9i9S9FjeTQHUHOCFpu/E1joHm6g+biadlGtq+CY3ZmW0TTUeMzIJu3He9gSKtiw3JqASwQMDndz8tMAxaEvc1rHxxQQFaC9bRO4yi77TByrUpUewxuhjgiBWWQ8nZCPAQ8et1t/yAV4LAadb09McELOGvwbtw+/udt5Y5qa8/VYvKPpIqc3K x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8fe57eef-9c5c-497d-3bd7-08d62d49ce55 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5308; x-ms-traffictypediagnostic: DM6PR05MB5308: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231355)(944501410)(52105095)(3002001)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:DM6PR05MB5308; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5308; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(39860400002)(136003)(376002)(199004)(189003)(102836004)(7736002)(6306002)(86362001)(305945005)(66066001)(316002)(476003)(2616005)(6116002)(6512007)(3846002)(6506007)(2906002)(53936002)(106356001)(2900100001)(105586002)(58126008)(6486002)(2351001)(6436002)(486006)(6916009)(14444005)(68736007)(97736004)(82746002)(83716004)(5640700003)(7116003)(966005)(413944005)(5660300001)(5250100002)(33656002)(2501003)(4326008)(450100002)(25786009)(36756003)(14454004)(1730700003)(99286004)(81166006)(26005)(71190400001)(71200400001)(8936002)(186003)(8676002)(81156014)(256004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5308; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4sIbi//65TxRhFSc/7HitIayurL00Px/CZXRKB7RUfMMYc5cel8FMB3hewgUMsVonkmPd6+a6NZSVD3N9um+HTtDOfEGoeeMe345m5w1T7zzDw65hrMIi9+xENFZD9uHoZw6NHi0E3ks7w/iWCI+JFBjNyA1j1TguMv46hrxJKDPmxTaqJr/mMZvX2TU7Uw10ldQ6jgyi7f+zdXLyRB/7dt967CHZMA1tyTXvd3YpcQ/01xFVeq/U369VAu34N7zmtpXlw0U+sagOnLGIBe618K+5ATmyAA5MkjILpR8HpW908W9xcPQ2TX08a3Gq+EKfKozzi5+sDiixnpvXfXaOCOHM7MTTajQbz+51sg6qsw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8fe57eef-9c5c-497d-3bd7-08d62d49ce55 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 18:13:53.6078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5308 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810080171 Archived-At: Subject: [netmod] IETF 103 presentation requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 18:14:00 -0000 RGVhciBXRywNCg0KVGhlIHByZWxpbWluYXJ5IElFVEYgMTAzIEFnZW5kYSBoYXMgYmVlbiBwb3N0 ZWQgWzFdLiAgTkVUTU9EIGlzIHNjaGVkdWxlZCB0byBtZWV0IGluIHRoZSBmaXJzdCBzbG90IFR1 ZXNkYXkgKE5vdmVtYmVyIDZ0aCkgbW9ybmluZyBmb3IgdHdvIGhvdXJzIGFuZCBhZ2FpbiBpbiB0 aGUgbGFzdCBzbG90IFRodXJzZGF5IChOb3ZlbWJlciA4dGgpIGFmdGVybm9vbiBmb3IgYW5vdGhl ciB0d28gaG91cnMuDQoNCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBwcmVzZW50aW5nIHRvIHRo ZSBXRywgcGxlYXNlIHNlbmQgeW91ciBwcmVzZW50YXRpb24gcmVxdWVzdHMgdG8gdGhlICJuZXRt b2QtY2hhaXJzIiBhbGlhcyAoQ0MtZWQpIHdpdGggdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiwg Zm9yIGVhY2ggcHJlc2VudGF0aW9uIHJlcXVlc3QsIGlmIG1vcmUgdGhhbiBvbmU6DQoNCiAgLSBu YW1lIG9mIHRoZSBkcmFmdHMgKGlmIGFueSkNCiAgLSBuYW1lIG9mIHByZXNlbnRhdGlvbiAodXN1 YWxseSBzYW1lIGFzIHRoZSBuYW1lIG9mIHRoZSBkcmFmdCkNCiAgLSBuYW1lIG9mIHRoZSBwcmVz ZW50ZXJzDQogIC0gZGVzaXJlZCB0aW1lIHJlcXVlc3QgaW4gbWludXRlcy4NCg0KWzFdIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDMvYWdlbmRhLmh0bWwNCg0KVGhhbmtz IQ0KS2VudCAoYW5kIExvdSBhbmQgSm9lbCkNCg0K From nobody Mon Oct 8 13:41:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412AC13106A; Mon, 8 Oct 2018 13:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRnSX0GzaX8I; Mon, 8 Oct 2018 13:41:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 65C0513101B; Mon, 8 Oct 2018 13:41:15 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 318C9C50A0F11; Mon, 8 Oct 2018 21:41:11 +0100 (IST) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 8 Oct 2018 21:41:12 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML702-CHM.china.huawei.com ([169.254.4.49]) with mapi id 14.03.0415.000; Mon, 8 Oct 2018 13:41:08 -0700 From: Alexander Clemm To: Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG adoption poll Thread-Index: AQHUXvuNOlQBVVtRFUOLpQsUdihIzaUV0HUQ Date: Mon, 8 Oct 2018 20:41:07 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D49E@sjceml521-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:41:17 -0000 Support --- Alex > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, October 08, 2018 4:39 AM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG adoption poll >=20 > All, >=20 > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group document. Plea= se > send email to the list indicating "yes/support" or "no/do not support". = If > indicating no, please state your reservations with the document. If yes,= please > also feel free to provide comments you'd like to see addressed once the > document is a WG document. >=20 > The poll ends Oct 22. >=20 > Thanks, >=20 > Lou (and co-chairs) >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 8 14:05:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351CE130E96 for ; Mon, 8 Oct 2018 14:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dIllUibCUgD for ; Mon, 8 Oct 2018 14:05:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 730D4130F49 for ; Mon, 8 Oct 2018 14:05:19 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6C18C11C108D; Mon, 8 Oct 2018 22:05:15 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 8 Oct 2018 22:05:16 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML701-CHM.china.huawei.com ([169.254.3.60]) with mapi id 14.03.0415.000; Mon, 8 Oct 2018 14:05:10 -0700 From: Alexander Clemm To: Ladislav Lhotka , Kent Watsen , "Andy Bierman" , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyQUI2nNckn+1ky1f4oa9l5TQKUPVRSAgAAnqICAAARaAIAABz8AgABBFoCAAAiTAIAAGC0AgAAFdICAAAvggIAAw7yAgAUeeMA= Date: Mon, 8 Oct 2018 21:05:09 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> In-Reply-To: <87sh1kde7u.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 21:05:24 -0000 I would second the request for one format (which is mandatory to support), = which must be specified. YANG-Patch is the logical candidate IMHO. =20 To allow selection of other formats using an input parameter makes sense, b= ut adds some complexity from there: How to know which formats are supporte= d? (Add a list of supported formats somewhere?) Or simply rely on augmen= tation for those implementations that want it? =20 --- Alex > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotk= a > Sent: Friday, October 05, 2018 12:50 AM > To: Kent Watsen ; Andy Bierman > ; Juergen Schoenwaelder university.de>; netmod@ietf.org > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-0= 0 >=20 > Kent Watsen writes: >=20 > > Sure, one mandatory to implement format, others nice to have. > > Interoperability good. Agreed. > > > > But why YANG-patch and not something built for the purpose (e.g., > > YANG-diff) that, in particular, provides an actual diff as opposed to > > a data-tree operation that only shows one of the two values? >=20 > Such a format can be developed independently, I would support it. >=20 > Lada >=20 > > > > Kent // contributor > > > > > > On 10/4/18, 3:27 PM, "Andy Bierman" > > wrote: > > > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder > university.de>> wrote: > > Folks, the more formats there are, the less interoperability we get. > > If there are multiple formats, is there a mandatory to implement > > format? Does the mandatory to implement format depend on the protocol > > that is being used? > > > > I prefer one format or if necessary I am fine with one mandatory to > > implement format. An open ended collection of implementation specific > > formats is super flexible but defeats the purpose of a standard, > > namely interoperability. > > > > I agree there needs to be 1 mandatory-to-implement format. > > > > IMO this needs to be YANG Patch because it is more precise then > > constructing an XML tree with operation attributes in it (e.g., how > > else do you represent a delete or a move?) Also, YANG Push is using > > YANG Patch format and common code for push and diff would be possible. > > > > I think other formats should be allowed. > > This is very tool-specific. I could see how somebody might want a > > textual patch of the XML representation to produce the new XML > representation. > > > > > > /js > > > > Andy > > > > > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: > >> We agree that the diff-format should be client-selectable, modulo what= the > server supports. yang-patch and edit-config both are viable. Should we > document them both? > >> > >> That said, since neither edit-config nor yang-patch are diffing format= s, so > much as formats for converting one data tree to another, would it make se= nse > to define an actual diffing format? I would think that a diff would prov= ide both > values, not just a new value. > >> > >> Kent // contributor > >> > >> > >> -----Original Message----- > >> From: netmod > >> > on behalf > >> of Ladislav Lhotka > > >> Organization: CZ.NIC > >> Date: Thursday, October 4, 2018 at 1:11 PM > >> To: Robert Wilton >, > >> "netmod@ietf.org" > >> > > >> Subject: Re: [netmod] WG adoption poll for > >> draft-clemm-netmod-nmda-diff-00 > >> > >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > >> > > >> > On 04/10/2018 13:51, Ladislav Lhotka wrote: > >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > >> > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > >> > > > > Phil Shafer > wrote: > >> > > > > > Bal?zs Lengyel writes: > >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__too= l > >> > > > > > > s.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00 > >> > > > > > > &d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r > >> > > > > > > > =3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9O > >> > > > > > > > l3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZK > >> > > > > > > sjqzuIw9yUq_xee6aFJOcw&e=3D > >> > > > > > [I've moved to a "deep lurker" role here, but ...] > >> > > > > > > >> > > > > > Can we ensure this model contains a "format" leaf in the RPC= 's input > >> > > > > > so that future (and proprietary) formats can be supported? = That > >> > > > > > leaf can be an identityref that defaults to yang-patch. > >> > > > > I think this is a good idea. I would prefer the edit-config > >> > > > > format over YANG patch for describing a diff. The > >> > > > > edit-config format is more suited for this purpose imo. > >> > > > +1 > >> > > > > >> > > > I would like something closer to edit-config to be available > >> > > > via RESTCONF as well. > >> > > YANG Patch is IMO better because it clearly separates the target > >> > > for the edits from the new content. > >> > > In edit-config these two are mixed together. > >> > Yes, that is primarily why I prefer the edit-config. I perceive > >> > that it is a denser and more efficient format. I think that it is > >> > both easier to construct (when diffing two trees) and also more > >> > efficient to apply when generating an updated tree. > >> > >> Except for certain corner cases, for example if two trees differ only > >> in the value of a single leaf but this leaf happens to be a list key. > >> > >> Lada > >> > >> > > >> > Thanks, > >> > Rob > >> > > >> > > >> > > That being said, I support specifying format/media-type and > >> > > having potentially multiple options. > >> > > > >> > > Lada > >> > > > >> > > > Thanks, > >> > > > Rob > >> > > > > >> > > > > >> > > > > /martin > >> > > > > > >> > > > > _______________________________________________ > >> > > > > netmod mailing list > >> > > > > netmod@ietf.org > >> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet= f > >> > > > > > .org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0U > >> > > > > jBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS > >> > > > > > laJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg > >> > > > > 5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > >> > > > > . > >> > > > > > >> > > > _______________________________________________ > >> > > > netmod mailing list > >> > > > netmod@ietf.org > >> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= o > >> > > > > rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe > >> > > > MK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZ > >> > > > > o&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi > >> > > > 1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > >> -- > >> Ladislav Lhotka > >> Head, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= i > >> lman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTX > >> > cWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3 > BO > >> CbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > zi1OboCL4SX2huW9euHiVRSCor > >> 9n_APQ&e=3D > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod >> point.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DD > >> wMFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9E > >> PoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d- > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6 > >> W3qt4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=3D> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 university.de/ 3A__www.jacobs- > 2Duniversity.de_&d=3DDwMFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO > 7d- > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=3Dzh7qEPSmwviaSqZBqG1Gc > qItXwI9pwyqIFVW6xC8rK8&e=3D>> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > oint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwM > > FaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoO > > H7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d- > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt > > 4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=3D> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 8 17:45:26 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6F1310F4; Mon, 8 Oct 2018 17:45:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Andy Bierman To: Cc: ntp@ietf.org, netmod@ietf.org, draft-ietf-ntp-yang-data-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153904592430.18394.3630036782970324198@ietfa.amsl.com> Date: Mon, 08 Oct 2018 17:45:24 -0700 Archived-At: Subject: [netmod] Yangdoctors early review of draft-ietf-ntp-yang-data-model-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 00:45:24 -0000 Reviewer: Andy Bierman Review result: Almost Ready Overall: - no compiler warnings; passes --ietf check as well Normative Sections: sec 1: - YANG version cited should be RFC 7950, not 6020. YANG 1.1 is used in this document.\ sec 4: Relationship with RFC 7317 - this section should say how overlapping configuration objects interact. Does setting 1 field (e.g., /system/ntp/enabled) change the other field at the same time (e.g., /ntp/enabled) It seems the intent is to ignore and deprecate /system/ntp if /ntp is implemented. This section should explain. sec 5: - this section is supposed to have citations for every imported YANG module used in the ietf-ntp YANG module YANG Module Issues: 1 - Indexing used in /ntp/associations list key "address local-mode isConfigured"; a) will there really be multiple instances per address for different association-modes? The list description-stmt should explain. b) There can be configured values (isConfigured key) and learned entries for the same address and association-modes? Why isn't NMDA used instead? (i.e. intended and operational datastores used instead of the isConfigured list key?) 2 - Purpose of /ntp/access-rules There is no explanation for what it means to configure an entry here that points at an ACL entry in /acls/acl; The description statement needs to specify the details. Doesn't the ACL module just work? How does the /ntp/access-rules/access-rule list change behavior? 3 - Reinvent Key Management It does not seem like a good idea for every protocol to duplicate key management functionality. The draft should explain why other YANG modules related to this work are not relevant here 4 - Reference statements There are no reference statements used in any objects or typedes Definitions which are intended to match a definition in NTP should include a reference-stmt Minor Issues: - typedef names should be singular - access-mode not access-modes - association-mode not association-modes - grouping comman-attributes should be common-attributes - mixed-case naming should not be used (isConfigured) - indentation used in module needs a lot of corrections - some descriptions have incorrect tense (e.g., "NTP is enable") - port definition should be based on inet:port-number, not uint16 OLD: type uint16 { range "123 | 1025..max"; } NEW: type inet:port-number { range "123 | 1025..max"; } - /ntp/authentication/trusted-keys Why is this list needed? Seems a leaf (e.g., trusted-key (true/false) added to the authentication-keys list is sufficient - /ntp/clock-state : some leafs should have a units-stmt instead of specifying the units in the description-stmt (could also apply elsewhere) - Examples should use line continuation convention e.g.: OLD: 10-10-2017 07:33:55.300 Z+05:30 NEW: 10-10-2017 07:33:55.300 Z+05:30\ - a spell checker should be used; There are many description-stmts with spelling errors From nobody Mon Oct 8 18:38:46 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC361310D6; Mon, 8 Oct 2018 18:38:44 -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 EUUOvkCDtodM; Mon, 8 Oct 2018 18:38:42 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 DB1861310C4; Mon, 8 Oct 2018 18:38:41 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id e74-v6so367336ita.2; Mon, 08 Oct 2018 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lgtRcm4w/sOb4s8xv0FFS4ovpKEEbCoIsI1nVgdPwEM=; b=JckEzQz3HjB0YXV0AOoHS/qbzFM0CN+Pbym5g5GKniyjX6Bu5kLhLrsvkSUoCPtsoJ mNp70P4B5EF2mAsVj+/kRf5UtGpY0DRjbM5FRvgx07mJo0qisbNAvL36/9OCNZuhnLdf Ez73zVmsQ+ZArvY9VBD2+r55zo8D5a3wnIfoVMHAse5ZLq+FrvMnjkCbdBt7E5uJPDjl 1lmNAJEVJM9dVWQmk1T7vsxa4k0zgdMql3PWzh4uokJidFoRQJZUtjPGvk52RuxnPdt+ MMxN7SX5zUoGLnk8BWnSHjnr6mbsszUKZH0jeYOA18Jp2pn9rJYu0JGmQEHpNwA1ooyc mPyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lgtRcm4w/sOb4s8xv0FFS4ovpKEEbCoIsI1nVgdPwEM=; b=KePXUFSBQACwBZ63tCGxduIgE+hHf/LNcEJUzYKtBVUjNvrnkJwNQ3AJdvYYE7gosy T6aopxvyE5U1nZPakhREa8v5EA5MuK72q1WbpT8oe24BKz1pmm67VnfIYz3kedS+SuU8 sGo7IcZeEvkWIjmlbTQf52D13ZeL5Tol1P92/dyojzQnM916ROSGNtwB7P98ekrOakmg fZZtZmAWLzhrLEAB7jcF/LJ5I2Vro7/opHvIfjtTwisPKa835m83gZ2sWOXtUYTQxTJd gpSyoHidxC5cRSyzmfkadqUI4h6c3vsP1DeCdU58TSRpqItUvXN4tLGThgN2IQFTOjVM AOpg== X-Gm-Message-State: ABuFfogqG2cCRio5oStnVundJhYt4OMSGZL7+QM6p5HkB4UgtekcWwSw +5fYshq+Td+A42Fc4bEwwJWF9MxWUdOtkT1XEbLPXDbr X-Google-Smtp-Source: ACcGV629/xxPBuTEVl3dr78Vy+L+/e8cvDas1Z9r1f+k96JgksaxxYtxerA+ZhG8aA2+mXLPkll2KJGuhjH1IgD1D2U= X-Received: by 2002:a24:d30d:: with SMTP id n13-v6mr305805itg.97.1539049121047; Mon, 08 Oct 2018 18:38:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Xufeng Liu Date: Mon, 8 Oct 2018 21:38:29 -0400 Message-ID: To: Lou Berger Cc: NETMOD WG , NetMod WG Chairs Content-Type: multipart/alternative; boundary="00000000000026e7190577c1cc04" Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 01:38:44 -0000 --00000000000026e7190577c1cc04 Content-Type: text/plain; charset="UTF-8" yes/support. Thanks, - Xufeng On Mon, Oct 8, 2018 at 7:39 AM Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group > document. Please send email to the list indicating "yes/support" or > "no/do not support". If indicating no, please state your reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends Oct 22. > > Thanks, > > Lou (and co-chairs) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000026e7190577c1cc04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes/support.

Thanks,
- Xufeng

= On Mon, Oct 8, 2018 at 7:39 AM Lou Berger <lberger@labn.net> wrote:
All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" = or
"no/do not support".=C2=A0 If indicating no, please state your re= servations
with the document.=C2=A0 If yes, please also feel free to provide comments<= br> you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000026e7190577c1cc04-- From nobody Mon Oct 8 18:40:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114461310F0 for ; Mon, 8 Oct 2018 18:40:06 -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 tGSz_gvslaE0 for ; Mon, 8 Oct 2018 18:40:03 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 65BF1131235 for ; Mon, 8 Oct 2018 18:40:00 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id e74-v6so370487ita.2 for ; Mon, 08 Oct 2018 18:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RHctqpeZdyK54aStTr5YRngjAldn3Wsa4cgHjJeSB+w=; b=K1gvLLfPiQ6IkYXZ6Ykg7DnGrVV42ERCAC4rjJIUxNaC2cf4stpbmxowFaHRIAMeRl c/KwZkkiTa4K4hwbpskWnw1spTLbJPLwUm4IkcZ/shzUyC6ixAgwUGe4l5Ke9AgitJav fMkC7MmZxUxMSag724LX8T1C3kwx6lfTFnEfs1W2y0X89I2oYAn/cFCKpiJw295TBF8H vFvD3/3kCN9HB9MjgnrxdOWBEh+grgYsrkYIIlUvLgBowYvbIbA8DNn3NYKpEZXqCxZK z4ZsRuCeYnZ0cHJKfVodZhZliz3F2OPB7CuW6jyA+8WmddUu4JcH/gnyOGEbk+Sqg6XN QlLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RHctqpeZdyK54aStTr5YRngjAldn3Wsa4cgHjJeSB+w=; b=e5+kwx6t5WkXJPnNu38NiOj4+C9/x0Q96RurYgc7bxx/UEYWv22P8UqF6hWHyCagUV XbzdSDF4flX7PoRMxS4eb9qE0dZKslNZ6RHpeylcsFhEJbfIcLfe8tOufzzVryV1JBkO 1ZxdfMAj2Hbt9HFga3cwgN9HQolb0GO5G1Rrt+qXW6RVZjrQMC/8SwelUVQ8srRSqJxW aAIZE4y6FzHYH74rBQ9WCjBNN7+BX+1Fl/Pw4q7oAdvDA1TMNgLmI3D2TZ4OgXbnuRU7 2LlOgfvfm/U52XIL6lVN+LgsJ2y7h/jQFwhPf6Ngd/CxPudgHXb/75PUyEGvpoh7phJe Jb+g== X-Gm-Message-State: ABuFfoi3aC7oTsr3W91CfoTmzVkCDoutkE+ZJ+Gn+U1NOlvhXky70uHF mxD+hcI8npu854bKh03kM5XeGbgRjuy44Ufuut7yH2PN X-Google-Smtp-Source: ACcGV61Dld+E8SiTJG4+UFCqAXBLl7nzM531wzZs0BSkNUzJXF2kCsr7VQALjIWy79PN3KPJ20gweYuVP0Yd50jlzDQ= X-Received: by 2002:a02:b56c:: with SMTP id z41-v6mr20648668jaj.133.1539049199578; Mon, 08 Oct 2018 18:39:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Xufeng Liu Date: Mon, 8 Oct 2018 21:39:47 -0400 Message-ID: To: Kent Watsen Cc: NETMOD WG Content-Type: multipart/alternative; boundary="000000000000d5346f0577c1d068" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 01:40:14 -0000 --000000000000d5346f0577c1d068 Content-Type: text/plain; charset="UTF-8" support. Thanks, - Xufeng On Mon, Oct 1, 2018 at 2:48 PM Kent Watsen wrote: > The IETF 102 in-room poll should really good support to adopt > this draft, and no objections. > > This email starts an adoption poll for: > > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 > > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. > > Kent (and Lou and Joel) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000d5346f0577c1d068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
support.

Thanks,
-= Xufeng

On M= on, Oct 1, 2018 at 2:48 PM Kent Watsen <kwatsen@juniper.net> wrote:
The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

=C2=A0 https://tools.ietf.org/html/draft-= clemm-netmod-nmda-diff-00

Please indicate your support or objection to the adoption poll.
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000d5346f0577c1d068-- From nobody Mon Oct 8 23:04:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163C2131182; Mon, 8 Oct 2018 23:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 oi6gVs0ihuw9; Mon, 8 Oct 2018 23:03:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 4D6A2131170; Mon, 8 Oct 2018 23:03:45 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0CB0235F900A7; Tue, 9 Oct 2018 07:03:42 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 07:03:43 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Tue, 9 Oct 2018 14:03:38 +0800 From: Tianran Zhou To: Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG adoption poll Thread-Index: AQHUXvuMVuk7gBtHOkmxQgPB/Np126UWbYxw Date: Tue, 9 Oct 2018 06:03:38 +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 Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 06:03:47 -0000 yes/support. Cheers, Tianran > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, October 08, 2018 7:39 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG adoption poll >=20 > All, >=20 > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group document. > Please send email to the list indicating "yes/support" or "no/do not supp= ort". > If indicating no, please state your reservations with the document. If y= es, > please also feel free to provide comments you'd like to see addressed onc= e > the document is a WG document. >=20 > The poll ends Oct 22. >=20 > Thanks, >=20 > Lou (and co-chairs) >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 8 23:07:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73DF131155 for ; Mon, 8 Oct 2018 23:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 i0_TZEGRu18F for ; Mon, 8 Oct 2018 23:07:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2F681131011 for ; Mon, 8 Oct 2018 23:07:08 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CA33CE89F648D for ; Tue, 9 Oct 2018 07:07:04 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 07:07:06 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Tue, 9 Oct 2018 14:07:00 +0800 From: Tianran Zhou To: Kent Watsen , "netmod@ietf.org" Thread-Topic: WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWbdTI2nNckn+1ky1f4oa9l5TQKUWeO0Q Date: Tue, 9 Oct 2018 06:07:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 06:07:10 -0000 Support. Cheers, Tianran > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Tuesday, October 02, 2018 2:48 AM > To: netmod@ietf.org > Subject: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 >=20 > The IETF 102 in-room poll should really good support to adopt this draft, > and no objections. >=20 > This email starts an adoption poll for: >=20 > https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 >=20 > Please indicate your support or objection to the adoption poll. > If objecting, please state your reasons on this thread. >=20 > Kent (and Lou and Joel) >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 8 23:28:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0A113118E; Mon, 8 Oct 2018 23:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YoHK-8K80cNU; Mon, 8 Oct 2018 23:28:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E0FA4131182; Mon, 8 Oct 2018 23:28:18 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 842177E8B50BF; Tue, 9 Oct 2018 07:28:15 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 07:28:17 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Tue, 9 Oct 2018 14:28:11 +0800 From: Qin Wu To: Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG adoption poll Thread-Index: AQHUXvuM8WyuPeMdx0Op1BtzAOO3WqUWcKWg Date: Tue, 9 Oct 2018 06:28:10 +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.138.33.244] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 06:28:22 -0000 U3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LCANClR3byBxdWljayBjb21tZW50cyBvbiB0 aGlzIGRyYWZ0DQoxLiBzZWN0aW9uIDIuNSBmYWN0b3J5IGRlZmF1bHQgc2V0dGluZw0KSSB3b3Vs ZCBzdWdnZXN0IHRvIHJlZmVyZW5jZSB0byBkcmFmdC13dS1uZXRjb25mLXJlc3Rjb25mLWZhY3Rv cnktcmVzdG9yZSBpbiBzZWN0aW9uIDIuNS4NCkkgdGhpbmsgdGhpcyBkcmFmdCBpcyBjb21wbGVt ZW50YXJ5IHRvIGRyYWZ0LXd1LW5ldGNvbmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlLTAyLCBm YWN0b3J5IGRhdGFzdG9yZSBjYW4gcmVseSBvbiB5YW5nIGluc3RhbmNlIGRhdGEgZmlsZSB0byBz cGVjaWZ5IHRoZSBjb250ZW50IG9mIGZhY3RvcnkgZGF0YXN0b3JlLg0KMi4gc2VjdGlvbiAyLjMg c2VydmVyIGNhcGFiaWxpdHkNClNlcnZlciBjYXBhYmlsaXR5IGluIHRoZSBjb250ZXh0IG9mIHRo aXMgZHJhZnQgaXMgcmVmZXJyZWQgdG8gYSBzZXQgb2YgbW9kZWxzIGFuZCBmZWF0dXJlcyB3aGlj aCBjYW4gYmUgcmV0cmlldmVkIGZyb20geWFuZyBsaWJyYXJ5LCBJIHNlZSBzZXJ2ZXIgY2FwYWJp bGl0eSBhcyBORVRDT05GIGNhcGFiaWxpdHkuIA0KSSBhbSB3b25kZXJpbmcgd2hldGhlciB5YW5n IGRhdGEgaW5zdGFuY2UgZmlsZSBjYW4gYWxzbyBiZSB1c2VkIHRvIHNwZWNpZnkgY2FwYWJpbGl0 eSBpZGVudGlmaWVycy4gU29tZSB0aW1lIEkgaGF2ZSB0cm91YmxlIHRvIHVuZGVyc3RhbmQgd2hl cmUgdGhlIHNlcnZlciB0byBnZXQgY2FwYWJpbGl0eSANCmlkZW50aWZpZXIgYW5kIGV4Y2hhbmdl IGl0IGluIHRoZSBoZWxsbyBtZXNzYWdlLg0KSSB1bmRlcnN0YW5kIFJGQzY0NzAgY2FuIGFkdmVy dGlzZSB0aGUgY2FwYWJpbGl0eSBjaGFuZ2UuDQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0K t6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb3Ug QmVyZ2VyDQq3osvNyrG85DogMjAxOMTqMTDUwjjI1SAxOTozOQ0KytW8/sjLOiBOZXRNb2QgV0cN CrOty806IE5ldE1vZCBXRyBDaGFpcnMNCtb3zOI6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwN Cg0KQWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCmRy YWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS0wNCBhIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQuIFBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9z dXBwb3J0IiBvciAibm8vZG8gbm90IHN1cHBvcnQiLiAgSWYgaW5kaWNhdGluZyBubywgcGxlYXNl IHN0YXRlIHlvdXIgcmVzZXJ2YXRpb25zIHdpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVh c2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cyB5b3UnZCBsaWtlIHRvIHNlZSBh ZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCg0KVGhlIHBvbGwg ZW5kcyBPY3QgMjIuDQoNClRoYW5rcywNCg0KTG91IChhbmQgY28tY2hhaXJzKQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0K From nobody Tue Oct 9 01:45:13 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8971311AA; Tue, 9 Oct 2018 01:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.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 nJDm1rtUCWiU; Tue, 9 Oct 2018 01:45:04 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720129.outbound.protection.outlook.com [40.107.72.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A479D131215; Tue, 9 Oct 2018 01:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ea2hAvDXYtASkZMgU0WyHg6mFmKyyvdJUW4RXxrsTV8=; b=eep//WmMbUkwDqUM7uArOPCx2Yaf+B/ZRkUwoA456B458CTargTdciTKnsYgFbckErmfAP7RO+3n+YbbPzNvhM+qbJR0wF4+AgoukWCsUO4blU5jPRwySFt4E+8Wadalwxdb9PydKU1nA30lK/zlULoOgly567efNv2aaPSmtGs= Received: from DM5PR06MB2777.namprd06.prod.outlook.com (10.175.107.139) by DM5PR06MB2505.namprd06.prod.outlook.com (10.168.179.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.26; Tue, 9 Oct 2018 08:44:55 +0000 Received: from DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::548:763e:a1d1:af95]) by DM5PR06MB2777.namprd06.prod.outlook.com ([fe80::548:763e:a1d1:af95%5]) with mapi id 15.20.1207.024; Tue, 9 Oct 2018 08:44:55 +0000 From: Michel Veillette To: "yot@ietf.org" CC: Core , "netmod@ietf.org" Thread-Topic: Proposed update to draft-ietf-core-comi Thread-Index: AdRfqhUAbiDYLn2mQeKsCqQMhtfStw== Date: Tue, 9 Oct 2018 08:44:54 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [62.74.242.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR06MB2505; 6:+o8aWPHGm6Cta2Thlgtqd6XgX2lKMwQse3YY1y0rqaxztNhqYALoSL+kGlK2732BU7lWt8XIwpJHzb8xPbpFJBpr7hyswGHXl0biCiQl/ZYQNtvj2Qh18JipOrzwFOWulFMrgIpBBtWwwrzrPP74CmjJbd9HAfkIq35mbGWKb++Ge+d5mfCJDypFxQ9uZ7wW6MWJXVDoLquRdhEczKBlCYClkZgIHTnpAKlIy5WFwOq4C/8WipZjxgonfxZUS4rGA263epGMBi0oP+GW5SNHe8EiR4Wqw6pGZTyLkKPOiFDmJnGjY1FiHcdSSixr/VYgZ2Tbe5uzN27LitSLhGYmz9449fZu4dXJq6WeQIanaBO6Sh17fu0EwRIqPAqKSHB+5RNLjg9VqmtpKWZQHzSh/8cv8jnmAE1f5IuiVovMfm/uEdO9Y2/+2TFOdaVL3WF9A33SCyICKwfseMdlN1a6YA==; 5:hFBw84EZE0MSyfAUWc9MymSVYaXtoVO/QwFOkO9pMJg2nbZn8uXZd+I6d0xQEN88RlLb1P5+vyTFe5y+I/g//023/ClQ5f/dQvekrSGcgcmOV/SyS+yJ6s82sv8TVv+O/4NUuWev2my0tGbvgkYxWzBvjctE6cCfxa+tJ3cdnlU=; 7:UxL+c/OsxbYpAHMRk8KcBgl+PytIzRUjmHzZhDmFrkrtpLFRxrPDD5W84NUn2w1cJbJ7VlkVdE6KIiqgncPXbtpqZq31SsY8enlSpLD53W8/xnTEnrEF3TQnUYy1d1aTCgziN8US6aFdSXvVBWaJX2toRr4EzDXw8JBAMgRWid6jwb3dEG7RYQVZlv41stjemsswT+km57wIlQhUPnDEzfSNFh+QYBs5vvnu8oqFGUVMc0ZP7czJbabCXgu1Rj8p x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e2aa30db-3755-4656-f0d0-08d62dc37c80 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DM5PR06MB2505; x-ms-traffictypediagnostic: DM5PR06MB2505: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:DM5PR06MB2505; BCL:0; PCL:0; RULEID:; SRVR:DM5PR06MB2505; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39850400004)(396003)(136003)(376002)(366004)(199004)(189003)(790700001)(5630700001)(6436002)(5640700003)(606006)(72206003)(316002)(2900100001)(6116002)(97736004)(2420400007)(68736007)(3846002)(105586002)(6916009)(106356001)(6306002)(6506007)(8936002)(53936002)(7110500001)(10710500007)(186003)(55016002)(54896002)(15650500001)(1730700003)(81156014)(2906002)(966005)(8676002)(14454004)(25786009)(5660300001)(450100002)(26005)(4326008)(33656002)(71190400001)(2501003)(71200400001)(478600001)(102836004)(2351001)(54906003)(9686003)(7696005)(81166006)(86362001)(99286004)(14444005)(476003)(256004)(74316002)(486006)(5250100002)(236005)(66066001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR06MB2505; H:DM5PR06MB2777.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: EJvyjvJ8+PZM9lnkNQReSfdo3VkVzAAu22OrzsFO40WIeRgIz96vxM7P0+A+0ijEhuvitUXQGlhelLesOSaViw6heFYMIQKplIV6646fRuA3TCrMHAkYF5cqoGucaIxr21IA4TEjWdOue6UrR+6DUFkggvSyEDF0UwMOCYJLpNXv993jPcnm7oUn4QMXNDrsVlAdjRiNFZgkrE+Nn/peqD/eBGk+KjkS5Y3FRYkXjavc3WJHpMhyP3quAWfxiAgXsC6lp6hn5KDlVf391BhAmDXabQ7Kt7pVS+d+yQ1Sqvv1S9CgnBbos8AY7yBTRDg4Ycm06vkThh9ol2vXGVR3N7OCB4H0MltOldpk6DMU/ok= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR06MB2777A475CB380C5E7C8201EC9AE70DM5PR06MB2777namp_" MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2aa30db-3755-4656-f0d0-08d62dc37c80 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 08:44:54.9250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2505 Archived-At: Subject: [netmod] Proposed update to draft-ietf-core-comi X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 08:45:11 -0000 --_000_DM5PR06MB2777A475CB380C5E7C8201EC9AE70DM5PR06MB2777namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The propose update to CoMI is available on github at: https://core-wg.githu= b.io/comi/draft-ietf-core-comi.txt. A diff can be generated using the following URI. https://tools.ietf.org/rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-co= re-comi-03.txt&url2=3Dhttps://core-wg.github.io/comi/draft-ietf-core-comi.t= xt This update address the following: * Reference SID added to payloads (Requested during IETF 102) * Reduction of the number and complexity of the Content-Formats. (Reque= sted during IETF 102) * Unified datastore defined for implementation by CoMI * Datastore identity added to the Application discovery section * Error payload defined using a YANG template instead of a container We plan to update the draft by the end of the month. Please send your comments to yot@ietf.org Regards, Michel --_000_DM5PR06MB2777A475CB380C5E7C8201EC9AE70DM5PR06MB2777namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The propose update to CoMI is a= vailable on github at: https:/= /core-wg.github.io/comi/draft-ietf-core-comi.txt.

 

A diff can be generated using t= he following URI.

https://tool= s.ietf.org/rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-core-comi-03.t= xt&url2=3Dhttps://core-wg.github.io/comi/draft-ietf-core-comi.txt

 

This update address the followi= ng:

  • Reference SID added to payloads (Requested during IETF 102)<= /span>
  • Reduction of the number and complexity of the Content-Format= s. (Requested during IETF 102)
  • Unified datastore = defined for implementation by CoMI
  • Datastore iden= tity added to the Application discovery section
  • E= rror payload defined using a YANG template instead of a container

 

We plan to update the draft by = the end of the month.

Please send your comments to yo= t@ietf.org

 

Regards,

Michel

 

--_000_DM5PR06MB2777A475CB380C5E7C8201EC9AE70DM5PR06MB2777namp_-- From nobody Tue Oct 9 02:00:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2F513126C for ; Tue, 9 Oct 2018 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MhII3mu1; dkim=pass (1024-bit key) header.d=ericsson.com header.b=SK/XRxvP 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 HDbn838UCaxD for ; Tue, 9 Oct 2018 02:00:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1F59A13124A for ; Tue, 9 Oct 2018 01:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539075598; x=1541667598; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aThNCtmENNl9WAFchfyOXy7vXTX39gYcAlgvoymmED8=; b=MhII3mu1i2kd8BtInPUa4ovXR7gbyJovTxbKmR1QxyAUf05VcxN1Nn6LJnczCF3G e9kWmzZgGU71IQ0ksMmhDjU2JW5WNUHnjFHpkVfPb2KqZkoCqS9xBaS0nscfaEgy HV9ClOkJXEWCsh/YV/v5RnGgoW749jXwQ9WZfWiA4ys=; X-AuditID: c1b4fb3a-159ff700000012ff-2d-5bbc6e0ec391 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.0B.04863.E0E6CBB5; Tue, 9 Oct 2018 10:59:58 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 10:59:58 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 10:59:58 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2e2gNfZreR17X3MoznXFMX/7ls/GxYxSHoQBIlmi/S8=; b=SK/XRxvPNrkELkg6/wYvf3OhPmTy7L+rz4Zl0n9KFAZMPlxQrR8VZiIEwMajyZ3YqnLQKlnFk2zhk//j9R5Q2OWm5ao5foEdhtVa9QyYuLLGoTapEypCb+pxHaQS15/Wg3OuL2aq9NjxbAmTmDlF0TpPpVZWoOh/RFlGhuOhw0k= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2912.eurprd07.prod.outlook.com (10.173.72.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.8; Tue, 9 Oct 2018 08:59:57 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 08:59:57 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: Whitespace in XML encoding - allowed ? Thread-Index: AQHUX65zMY3LKhsc8UeIQzNDxdo7xQ== Date: Tue, 9 Oct 2018 08:59:56 +0000 Message-ID: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: VI1PR0902CA0035.eurprd09.prod.outlook.com (2603:10a6:802:1::24) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2912; 6:C5ko85rA3tdxAyLt3oiH/YWNILw7R7Gup+luaa98PZPRaTEAkhSBAbpYzjw/B8ErLyGVWUYR0ZDxa8shQoI5r2Ka/pc95y1QiXq7820ShQGftrENDMioKhF3OYqH9gZxEU9P3KbPm9IhMtumB4tFSHYO40bE8vjqadyAvCjAxDSreoKbCLvF8QK+YXej1KDmA2Oc+3PGOy35lhmn8KHYj9VPaJfTFJHKGABELGzVVOiVrYLJs0fvZK1aVFx29gDe6C2kuUe9N+cBxqDt/lRmwhbQiI+kDwESfMKdg1+DzkFDGRjcDqX6PR+MUorm/z3KR4Raap/ecQq0G7UqvH4ml4Lj11NRapb6W3XUgJMAcuhen9RL5xgykrzHt+ce/JVVJbqPubqhFKqEnkGhQ4Gm6wbudJ4Lt0sD5RFOxqppMXgbFE267qm2Mvde6ndWGwF3hwrayW4alYdrd3ARqcJtxg==; 5:Xvegrt+umb7UM1/Ew6a5StUTEg6tqxkP0oZQNn6PMWvDnFEH6QPnidefoizForP26mLPcRRmKjg5sxVU9FDHOt7Ed/s2xZoV3Y8/heOlFZx8qGzAlqpJ/CFLRw0EhZV1+goiJfU5PP7ichFBy7ULEtDgsF0lH6BPQJ6pB+yyRLM=; 7:yuJ6TaTQNn5srw4rIcjcIEwm52xLe1MBZjzZx0F+jHpXyh7pghvH3hLXwv2dX7ME/+eBLIJD8p6J3pKqL9MWvoBorLd508TZuatbFs7eGNnyvJRKk+wR3nRhiaWHBs1K5wiMzbpQ/EIIF5w6YpNWX9GpZtrN2tpSR+QfCNT+i7fOjP1mV39INtN2p0+5G4Q0QEe+Shyq7UpP/VIijGR2oWRTWKakX49YQJukOOSe8jpik0Lr8yvK/HyskCDsbROU x-ms-office365-filtering-correlation-id: ebd38e47-0a97-4092-41d3-08d62dc59505 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2912; x-ms-traffictypediagnostic: VI1PR0701MB2912: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231355)(944501410)(4982022)(4983020)(52105095)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991055); SRVR:VI1PR0701MB2912; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2912; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(366004)(376002)(136003)(189003)(199004)(252514010)(486006)(66066001)(65826007)(5640700003)(99286004)(97736004)(65806001)(65956001)(606006)(256004)(36756003)(6306002)(54896002)(6512007)(476003)(2616005)(6506007)(6486002)(14454004)(99936001)(386003)(64126003)(68736007)(6436002)(52116002)(6916009)(2501003)(31686004)(58126008)(71200400001)(5660300001)(478600001)(966005)(71190400001)(316002)(2900100001)(5250100002)(2906002)(8936002)(8676002)(186003)(1730700003)(81166006)(53376002)(6346003)(6116002)(85182001)(102836004)(26005)(2351001)(3846002)(105586002)(25786009)(3260700006)(31696002)(236005)(7736002)(106356001)(53936002)(81156014)(86362001)(85202003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2912; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-message-info: jpOJ2+gKacyY+HlVNNXYj2DAznJOwKp8XmZbsatTFUqxiqtUKSi9WRVC2rrHChZyks9W644i7hQXR1g5aheN89R4v0K/3Bf/BKIBHjEI0ztNPACyD2sPaL6mw+DEG0T8FMzx3sBf8u3rdYGjlaAeMiqvovzFBkTgw1Q5hPSAFw71/LdPOgMmcNx9V8im4SHFGXbp/hyxrbfegCSh8pb0Rx2qHJqEqMWAXf/V1WQeI+5PfUsb5ZvoHwp1Q5Aub29qBWUUM0zwlRasfM70lNRYB1VnQ1O+omoTETx1IHHTFrazMaIDGcUhhDU6+XTB/RSS3xSWcV1KBdVWv1UjubhB0LS3SqoN7VTLINOWHS2XHQU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030608060505010608070500" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ebd38e47-0a97-4092-41d3-08d62dc59505 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 08:59:56.9429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2912 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGc2em07FavRRqT1BMHFESVHBBg0vcwoMJ0RhfRIiRKiMidMAO EGsM2kiD0CIQi9JqBBRqggaXuCuB1qJWowGVRR+IxSLBRiIPqCgubS8k+vad//z/uffcXI5W dcgiuSwxX9CL2hyeVTC2lDuFi6eLD9OWnP0TlljbaZRtQJsbGsaobShVsTZDyMkqFPTx69IV +7+/saI8e/KhivoadAyZksrQFA5wAthLvsjLkIJT4XYE42cuTRSjCHpPuylSXKTA5x4LFQyu pKGpe5gK5lXYSsFjq4a4+hG89N9ggw0WJ0HJcGvIFIFjwHbvakgPx/HQeL2KJnoCfL5VHmAu wHHQ3hkVlBkcDc/OtcqCrMTrofrSKAoywjPh27MroZE01sA7Xy1FdogAb+dzlrAahj78lhHm oebTuxCr8S4o9thlwXsCtiGoqnnKENMieNHjQ4Sj4FWtGRFTmxxGS7wTk7aAqe49RRqvETS3 n6Am08MjFfLgBoBzobJ6D5GTwWj00ITnQFO5lyHZ9zS8dV2eyM4GY3UpW4ni7f9sZA/4aFyK oLi7i7WHniAMPDYfYw+cQeMF4DDx//uDvBAc9X6a8Bqo+eFkCc8Fq9krJ7wC/O0jiPBycDT/ YuuQogmpJUGSdJnLlsUJ+qy9kpQrxolC/g0U+FvOmz9X30XOwY0uhDnET1Mez3iYppJpCyWD zoWiA3P6r13uQJGMmCsKfIRSfed+mkqZoTUcFvS5u/UFOYLkQrM4htcoN+1LTFXhTG2+kC0I eYJ+sktxUyKPoSzLZkOK13G35YW5dy/fmF2FJXfBkvMWSpHgn3Fkpee0bsBiaIms+yr2PW17 8iW9ruhU12CMb+sDKlbXV6ZcqkmePzBVPV6w/WhP/I7mpAOlYRcOup3syx+uR1azXbdxlbPI 9PX7yeuZ4UMfXcM7+zL5ceO8Rgtz3N3r3hO75TbPSPu1S2NpvaT9C1gnhTdjAwAA Archived-At: Subject: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 09:00:09 -0000 --------------ms030608060505010608070500 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

Recently we came up against a problem where a certain implementation did not accept the following:

<with-defaults=
 xmlns=3D"...">
    report-all
</with-defaults>

while it did accept 

<with-defaults=
 xmlns=3D"...">report-all</with-defaults>

I am unsure whether YANG's XML encoding allows whitespace before and after a leaf's value? In RFC7950 it does not say yes or no. I have found the following examples that seem to allow preceding/following whitespace:

https://tools.ietf.org/html/rfc7950#section-4= =2E2.9

       <status=
 xmlns=3D"http://example.com/system">
         The image example-fw-2.3 is being installed.
       </status>

https://tools.ietf.org/html/rfc7950#section-= 7.16.3

         <repo=
rting-entity>
           /ex:interface[ex:name=3D'Ethernet0']
         </reporting-entity>

https://tools.ietf.org/html/rfc6243#appendix= -A.3.1

        <with-=
defaults
         xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-with=
-defaults">
          report-all
        </with-defaults>

It is problematic that this is not clarified. IMHO this should be clarified in an errata to rfc7950. Chose one:

  1. It is not allowed to add preceding or following whitespace after the value of a leaf/leaf-list.
    Note that some text documents may add whitespace to Netconf examples to avoid long lines,
    however this extra whitespace MUST NOT be present in the actual Netconf encoding.
  2. It is not allowed to add preceding or following whitespace after the value of a leaf/leaf-list.
  3. It is allowed to add preceding or following whitespace after the value of a leaf/leaf-list except
    for string based types, where the whitespace could be part of the leaf's value itself..

What do you think?

regards Balazs

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms030608060505010608070500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwOTA4NTk1M1ow LwYJKoZIhvcNAQkEMSIEIHnLWK8vLMUrmXaT9orkah+5D4daSTjl3omqhbQvOH9IMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAK8d5BbOf3L81LqPRaCosvinerlOBa+ktZwB1SW8bzNrNrjl 0cFrNTxb7Bl741Ggq/rJDm24fXaRF8Rpspau9NAj8oMNEWPQX22mesmHMO9SstavLZab+mJX WJctsmOdjeC9oya9dMCmqDsB7EVzjXRgGz2o4RCIRJezJSE/w8ZalivTul8+gO+SVMM8QbJn MEAg+7zK0X7hafnAgY44KQWhXd3jaUs5+PvL5ccfT5rVYLEqpETEZT0URbRnUUm7Jw2JLFOQ 1fZwHdjO9xQ6FkLXPoANasrQOoT2OEdvpJzPk3S1KGYeHIDqJej3dJyMqydlFkjDC+20EeBv HIiCmnMAAAAAAAA= --------------ms030608060505010608070500-- From nobody Tue Oct 9 02:24:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244B013122B for ; Tue, 9 Oct 2018 02:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMbOlnGWm2Ev for ; Tue, 9 Oct 2018 02:24:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D917C1311AA for ; Tue, 9 Oct 2018 02:24:00 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ABBC581A1C339; Tue, 9 Oct 2018 10:23:56 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 10:23:57 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Tue, 9 Oct 2018 17:23:53 +0800 From: Qin Wu To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" Thread-Topic: Whitespace in XML encoding - allowed ? Thread-Index: AQHUX65zMY3LKhsc8UeIQzNDxdo7xaUWoQpA Date: Tue, 9 Oct 2018 09:23:52 +0000 Message-ID: References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> In-Reply-To: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.244] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B05FD49nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 09:24:04 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9B05FD49nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpc3N1ZSBoYXMgYmVlbiB0b3VjaGVkIGJ5IGVhcmxpZXIgdmVyc2lvbiBvZiBkcmFmdC1r d2F0c2VuLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDcuDQpSRkM3OTUwIGhhcyBwcm92aWRlIFhN TCBlbmNvZGluZyBydWxlIGFzIGZvbGxvd3M6DQoiDQpBbnkgd2hpdGVzcGFjZSBiZXR3ZWVuIHRo ZSBzdWJlbGVtZW50cyB0byB0aGUgbGlzdCBlbnRyeSBpcw0KICAgaW5zaWduaWZpY2FudCwgaS5l LiwgYW4gaW1wbGVtZW50YXRpb24gTUFZIGluc2VydCB3aGl0ZXNwYWNlDQogICBjaGFyYWN0ZXJz IGJldHdlZW4gc3ViZWxlbWVudHMuDQoiDQpTaW1pbGFyIHJ1bGUgaXMgYXBwbGllZCB0byBsZWFm LWxpc3QuDQoNCi1RaW4NCuWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNA aWV0Zi5vcmddIOS7o+ihqCBCYWzDoXpzIExlbmd5ZWwNCuWPkemAgeaXtumXtDogMjAxOOW5tDEw 5pyIOeaXpSAxNzowMA0K5pS25Lu25Lq6OiBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDogW25ldG1v ZF0gV2hpdGVzcGFjZSBpbiBYTUwgZW5jb2RpbmcgLSBhbGxvd2VkID8NCg0KDQpIZWxsbywNCg0K UmVjZW50bHkgd2UgY2FtZSB1cCBhZ2FpbnN0IGEgcHJvYmxlbSB3aGVyZSBhIGNlcnRhaW4gaW1w bGVtZW50YXRpb24gZGlkIG5vdCBhY2NlcHQgdGhlIGZvbGxvd2luZzoNCg0KPHdpdGgtZGVmYXVs dHMgeG1sbnM9Ii4uLiI+DQoNCiAgICByZXBvcnQtYWxsDQoNCjwvd2l0aC1kZWZhdWx0cz4NCg0K d2hpbGUgaXQgZGlkIGFjY2VwdA0KDQo8d2l0aC1kZWZhdWx0cyB4bWxucz0iLi4uIj5yZXBvcnQt YWxsPC93aXRoLWRlZmF1bHRzPg0KDQpJIGFtIHVuc3VyZSB3aGV0aGVyIFlBTkcncyBYTUwgZW5j b2RpbmcgYWxsb3dzIHdoaXRlc3BhY2UgYmVmb3JlIGFuZCBhZnRlciBhIGxlYWYncyB2YWx1ZT8g SW4gUkZDNzk1MCBpdCBkb2VzIG5vdCBzYXkgeWVzIG9yIG5vLiBJIGhhdmUgZm91bmQgdGhlIGZv bGxvd2luZyBleGFtcGxlcyB0aGF0IHNlZW0gdG8gYWxsb3cgcHJlY2VkaW5nL2ZvbGxvd2luZyB3 aGl0ZXNwYWNlOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9u LTQuMi45DQoNCiAgICAgICA8c3RhdHVzIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc3lzdGVt IjxodHRwOi8vZXhhbXBsZS5jb20vc3lzdGVtPj4NCg0KICAgICAgICAgVGhlIGltYWdlIGV4YW1w bGUtZnctMi4zIGlzIGJlaW5nIGluc3RhbGxlZC4NCg0KICAgICAgIDwvc3RhdHVzPg0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMTYuMw0KDQogICAgICAg ICA8cmVwb3J0aW5nLWVudGl0eT4NCg0KICAgICAgICAgICAvZXg6aW50ZXJmYWNlW2V4Om5hbWU9 J0V0aGVybmV0MCddDQoNCiAgICAgICAgIDwvcmVwb3J0aW5nLWVudGl0eT4NCg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDMjYXBwZW5kaXgtQS4zLjENCg0KICAgICAgICA8d2l0 aC1kZWZhdWx0cw0KDQogICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5n OmlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzIj4NCg0KICAgICAgICAgIHJlcG9ydC1hbGwNCg0K ICAgICAgICA8L3dpdGgtZGVmYXVsdHM+DQoNCkl0IGlzIHByb2JsZW1hdGljIHRoYXQgdGhpcyBp cyBub3QgY2xhcmlmaWVkLiBJTUhPIHRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCBpbiBhbiBlcnJh dGEgdG8gcmZjNzk1MC4gQ2hvc2Ugb25lOg0KDQogIDEuICBJdCBpcyBub3QgYWxsb3dlZCB0byBh ZGQgcHJlY2VkaW5nIG9yIGZvbGxvd2luZyB3aGl0ZXNwYWNlIGFmdGVyIHRoZSB2YWx1ZSBvZiBh IGxlYWYvbGVhZi1saXN0Lg0KTm90ZSB0aGF0IHNvbWUgdGV4dCBkb2N1bWVudHMgbWF5IGFkZCB3 aGl0ZXNwYWNlIHRvIE5ldGNvbmYgZXhhbXBsZXMgdG8gYXZvaWQgbG9uZyBsaW5lcywNCmhvd2V2 ZXIgdGhpcyBleHRyYSB3aGl0ZXNwYWNlIE1VU1QgTk9UIGJlIHByZXNlbnQgaW4gdGhlIGFjdHVh bCBOZXRjb25mIGVuY29kaW5nLg0KICAyLiAgSXQgaXMgbm90IGFsbG93ZWQgdG8gYWRkIHByZWNl ZGluZyBvciBmb2xsb3dpbmcgd2hpdGVzcGFjZSBhZnRlciB0aGUgdmFsdWUgb2YgYSBsZWFmL2xl YWYtbGlzdC4NCiAgMy4gIEl0IGlzIGFsbG93ZWQgdG8gYWRkIHByZWNlZGluZyBvciBmb2xsb3dp bmcgd2hpdGVzcGFjZSBhZnRlciB0aGUgdmFsdWUgb2YgYSBsZWFmL2xlYWYtbGlzdCBleGNlcHQN CmZvciBzdHJpbmcgYmFzZWQgdHlwZXMsIHdoZXJlIHRoZSB3aGl0ZXNwYWNlIGNvdWxkIGJlIHBh cnQgb2YgdGhlIGxlYWYncyB2YWx1ZSBpdHNlbGYuLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0K cmVnYXJkcyBCYWxhenMNCg0KLS0NCg0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAg ICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KDQpTZW5pb3IgU3BlY2lhbGlzdA0KDQpNb2JpbGU6 ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNz c29uLmNvbTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPg0K --_000_B8F9A780D330094D99AF023C5877DABA9B05FD49nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc4MTI5MzQ0MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTk3MTI1NTY4NDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04i IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpc3N1ZSBoYXMgYmVlbiB0b3VjaGVkIGJ5IGVhcmxp ZXIgdmVyc2lvbiBvZiBkcmFmdC1rd2F0c2VuLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRkM3OTUwIGhhcyBwcm92 aWRlIFhNTCBlbmNvZGluZyBydWxlIGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFueSB3aGl0ZXNwYWNlIGJldHdlZW4gdGhlIHN1YmVsZW1lbnRzIHRvIHRo ZSBsaXN0IGVudHJ5IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgaW5zaWduaWZpY2FudCwgaS5lLiwgYW4gaW1wbGVtZW50YXRpb24gTUFZ IGluc2VydCB3aGl0ZXNwYWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsgY2hhcmFjdGVycyBiZXR3ZWVuIHN1YmVsZW1lbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW1pbGFyIHJ1bGUgaXMgYXBwbGllZCB0byBs ZWFmLWxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1RaW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2lu ZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4 dCI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuS7o+ihqCA8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij5CYWw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 d2luZG93dGV4dCI+w6E8c3BhbiBsYW5nPSJFTi1VUyI+enMgTGVuZ3llbDxicj4NCjwvc3Bhbj48 Yj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiAyMDE4PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3Bh biBsYW5nPSJFTi1VUyI+OTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE3OjAwPGJyPg0K PC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbbmV0bW9kXSBXaGl0 ZXNwYWNlIGluIFhNTCBlbmNvZGluZyAtIGFsbG93ZWQgPzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+UmVj ZW50bHkgd2UgY2FtZSB1cCBhZ2FpbnN0IGEgcHJvYmxlbSB3aGVyZSBhIGNlcnRhaW4gaW1wbGVt ZW50YXRpb24gZGlkIG5vdCBhY2NlcHQgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZsdDt3aXRoLWRlZmF1bHRzIHhtbG5zPSZxdW90Oy4uLiZxdW90OyZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlcG9ydC1hbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmx0Oy93aXRo LWRlZmF1bHRzJmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+d2hpbGUgaXQgZGlkIGFjY2VwdCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZsdDt3aXRoLWRlZmF1bHRzIHhtbG5zPSZxdW90 Oy4uLiZxdW90OyZndDtyZXBvcnQtYWxsJmx0Oy93aXRoLWRlZmF1bHRzJmd0Ozwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+SSBhbSB1bnN1cmUgd2hldGhlciBZQU5HJ3MgWE1MIGVuY29kaW5nIGFsbG93cyB3aGl0 ZXNwYWNlIGJlZm9yZSBhbmQgYWZ0ZXIgYSBsZWFmJ3MgdmFsdWU/IEluIFJGQzc5NTAgaXQgZG9l cyBub3Qgc2F5IHllcyBvciBuby4gSSBoYXZlIGZvdW5kIHRoZSBmb2xsb3dpbmcgZXhhbXBsZXMg dGhhdCBzZWVtIHRvIGFsbG93IHByZWNlZGluZy9mb2xsb3dpbmcgd2hpdGVzcGFjZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi00LjIuOSI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi00LjIuOTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 c3RhdHVzIHhtbG5zPTxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9zeXN0ZW0iPiZxdW90O2h0 dHA6Ly9leGFtcGxlLmNvbS9zeXN0ZW0mcXVvdDs8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVGhlIGltYWdlIGV4YW1wbGUtZnctMi4zIGlzIGJlaW5nIGluc3RhbGxlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZsdDsvc3RhdHVzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHA+ PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3OTUwI3NlY3Rpb24tNy4xNi4zIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1 MCNzZWN0aW9uLTcuMTYuMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cmVwb3J0 aW5nLWVudGl0eSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9l eDppbnRlcmZhY2VbZXg6bmFtZT0nRXRoZXJuZXQwJ108bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDsvcmVwb3J0aW5nLWVudGl0eSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjI0MyNhcHBlbmRpeC1BLjMuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYy NDMjYXBwZW5kaXgtQS4zLjE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3dpdGgtZGVmYXVs dHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFt czo8YSBocmVmPSJ4bWw6bnM6eWFuZzppZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cyI+eG1sOm5z Onlhbmc6aWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHM8L2E+JnF1b3Q7Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwb3J0LWFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0Oy93aXRoLWRlZmF1bHRzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiPkl0IGlzIHByb2JsZW1hdGljIHRoYXQgdGhpcyBpcyBub3QgY2xhcmlmaWVk LiBJTUhPIHRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCBpbiBhbiBlcnJhdGEgdG8gcmZjNzk1MC4g Q2hvc2Ugb25lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj5JdCBpcyBub3QgYWxsb3dlZCB0byBhZGQgcHJlY2VkaW5nIG9yIGZvbGxv d2luZyB3aGl0ZXNwYWNlIGFmdGVyIHRoZSB2YWx1ZSBvZiBhIGxlYWYvbGVhZi1saXN0Lg0KPGJy Pg0KTm90ZSB0aGF0IHNvbWUgdGV4dCBkb2N1bWVudHMgbWF5IGFkZCB3aGl0ZXNwYWNlIHRvIE5l dGNvbmYgZXhhbXBsZXMgdG8gYXZvaWQgbG9uZyBsaW5lcywNCjxicj4NCmhvd2V2ZXIgdGhpcyBl eHRyYSB3aGl0ZXNwYWNlIE1VU1QgTk9UIGJlIHByZXNlbnQgaW4gdGhlIGFjdHVhbCBOZXRjb25m IGVuY29kaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SXQgaXMgbm90IGFs bG93ZWQgdG8gYWRkIHByZWNlZGluZyBvciBmb2xsb3dpbmcgd2hpdGVzcGFjZSBhZnRlciB0aGUg dmFsdWUgb2YgYSBsZWFmL2xlYWYtbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPkl0IGlzIGFsbG93ZWQgdG8gYWRkIHByZWNlZGluZyBvciBmb2xsb3dpbmcgd2hpdGVzcGFj ZSBhZnRlciB0aGUgdmFsdWUgb2YgYSBsZWFmL2xlYWYtbGlzdCBleGNlcHQNCjxicj4NCmZvciBz dHJpbmcgYmFzZWQgdHlwZXMsIHdoZXJlIHRoZSB3aGl0ZXNwYWNlIGNvdWxkIGJlIHBhcnQgb2Yg dGhlIGxlYWYncyB2YWx1ZSBpdHNlbGYuLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyBCYWxhenM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJhbGF6cyBMZW5neWVsJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEVyaWNzc29uIEh1bmdhcnkgTHRkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk1vYmlsZTogJiM0MzszNi03MC0zMzAtNzkwOSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOkJhbGF6cy5MZW5neWVs QGVyaWNzc29uLmNvbSI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA9B05FD49nkgeml513mbxchi_-- From nobody Tue Oct 9 03:02:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3265131252 for ; Tue, 9 Oct 2018 03:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=enPUVTDf; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lISYjUhV 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 cZo2X_RRKbH4 for ; Tue, 9 Oct 2018 03:02:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7FE82131254 for ; Tue, 9 Oct 2018 03:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539079368; x=1541671368; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HZvs5FcpGE2hrAMWi7U0cjkA8Ecpf1pNPoRZhtfUeCo=; b=enPUVTDfskN1rrkC4HFyI2oNhltK1SNcLfoTS9pxHpgooB8aLr5C4Yeg9E02iP09 RYqyb27QVrKcDQ4iPelTPhQQzINyUt//XJnTQrJ1Xg5xw96p/fpqbpG5BVkZ5OFP i0lHzQTmX3/A+mcntF8iffEIti3nL5NCqkJyh8gyej0=; X-AuditID: c1b4fb25-573ff700000018b4-22-5bbc7cc8a629 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.9D.06324.8CC7CBB5; Tue, 9 Oct 2018 12:02:48 +0200 (CEST) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESBMB504.ericsson.se (153.88.183.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 12:02:48 +0200 Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 12:02:48 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 12:02:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JNhuZIKaWZmThfw3DyYpHH/brRY36bgJCTQVszh+Lg8=; b=lISYjUhVZKp5Um/8nxau7ZFDpKUq6nSwY0gtsk2CUtReoOk4pvdDjjOjT1axGN3uinonxHCtsgzJDkjXblbEnUA24CSh3GsbCxVgRkVXvOY4XoRuivW1YiNK92xS+BM336oSOu0Dcpm4Lornhgb1saLWH6Sh5aLE7zcUtaNRriQ= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.10; Tue, 9 Oct 2018 10:02:47 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 10:02:47 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Qin Wu , "netmod@ietf.org" Thread-Topic: Whitespace in XML encoding - allowed ? Thread-Index: AQHUX65zMY3LKhsc8UeIQzNDxdo7xaUWoQpAgAAN+YA= Date: Tue, 9 Oct 2018 10:02:47 +0000 Message-ID: <737c9830-67d3-2e18-aa3f-35b40559d47d@ericsson.com> References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: KL1PR0601CA0015.apcprd06.prod.outlook.com (2603:1096:802:1::25) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2126; 6:rvvO0bI6DpCAWJReh3eZSdFvwtPIhpL2w7ismI1xscZYmt7Ia7p6QaDgQ3eTvGXoP2pAV4o1vfkeRucYZ4N6ELD7H04+4ApdecrSHGwLz5r7n/pJHlbcv051+V/JoKVKIfQD3eg99Ga+Ner0M/kzxyT8BQbYUfMScuoBI5SzT+R43oOz9nUBz6NyBDpjCKh+eVEiPfAl42pXPhu1OC0cdZThpt8CwpZlTI+yrkylRGcaKSfa2AIk1QFBzA1zvQMEStogu6TaoHWByMbJ/hMJTN+7+E21e6HLrdrD1t5/Po9YaCMhtJpEGzeexYMAPEDMOVGpJHmmba0Sbyw4u3QhyPsjaDvhi14cb20alfAlN98t9W2Sd+GRg3gssRMN2tuxIVfbolpX6Vc1oXldCKg4UEc7911Aa0oo3LQ9Z+C/W0KMECJfKx9qXhbW5aXqYof9FHOoXp1qoH9yZWKSc+7S6Q==; 5:NVJctP8IW0oUUjEZ6bmJv/yZecBNSVbijFdud/bH6TASRdyZiOwEE14jtx499dWdiLCj5ke4N9ZawaYO5SAer8cjme5GbnLyj4Xw5s6h8dNMVrlr8zAL2BJq8fi7Bc9pGMentHwbIqZoXcQPMRMJyghua35uIY2F0SAbgJv4yQw=; 7:kSTxbMuh+TxYuGeyEXG78NKCF+p7td4ZClGpXmu1RhbbLPoM0547VfGtD0Vze7anvMG1a65byFtA3cLCvbMYpALykHbYE/HsOdWyhOKCbzXxMkDoot0osWzYaIqVpF16fAHCoFQ8Bsnf8m/JwmXEv9FfmsMr6/b2SwV2zZJF0368k9l/u2iLQcFyTo7HCo4vC/1RPvXKmigCIcMAF3Ocxl2pum0cKE4Pmh2InP2UiWwDkmOiIJIEM/PLxS1EOw6o x-ms-office365-filtering-correlation-id: 31d8a128-2732-4226-a43b-08d62dce5bd7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2126; x-ms-traffictypediagnostic: VI1PR0701MB2126: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944)(50582790962513); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(4982022)(52105095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051); SRVR:VI1PR0701MB2126; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2126; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(39860400002)(366004)(199004)(252514010)(189003)(606006)(476003)(2616005)(14454004)(2906002)(68736007)(76176011)(8676002)(81156014)(81166006)(7736002)(6436002)(6486002)(71200400001)(71190400001)(85202003)(106356001)(105586002)(102836004)(65806001)(256004)(446003)(31696002)(3260700006)(64126003)(11346002)(25786009)(65956001)(66066001)(86362001)(8936002)(966005)(486006)(36756003)(85182001)(478600001)(66574009)(58126008)(186003)(97736004)(386003)(6506007)(5660300001)(110136005)(99286004)(65826007)(52116002)(316002)(5250100002)(6246003)(53376002)(2501003)(236005)(6512007)(54896002)(6306002)(6116002)(790700001)(53936002)(99936001)(3846002)(26005)(2900100001)(31686004)(229853002)(18717965001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2126; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: r5GI34/Fsh5HNaOgucwQk2mnc2tLRSyV6SWGvyerjKhtpFdtCM4ijMTTtzK9WA1+v1WxTqkjl1uMZ8J/yCFcwQXe6gJI/GU7+LwM8M7YVfepXRBEVcMAdoABwOhTMTjLTI1fT5/uFYOwkvAzxRdBJGxMK+F0l9W5x9DmPGZ4osJSt158vgmQPy6h7t5bnBrFGAV29U5NA3FygH7BRi3MGP+QJXtp5hjsDOedIea+BLgAn+tG7n70r58bML0/1DNTRJd9vF0DCXbJNZvgNekvnlCfFg5tahYzKERszPEg5GjP9yrvgLJ5KCwY/P9arcgSoOOXTwRqXndIOA/Bd63ktyIvjSglMfzAe+iM2wq6x+s= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060408050305040505060107" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 31d8a128-2732-4226-a43b-08d62dce5bd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 10:02:47.0313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2126 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0iTURjHO3v3bq+jxXG6fNL2oaFSVpqXyOxOwQzphhHh6DLzRcW5yaai 5ocFmtORWBluU9FIBqmUecmQhSkpmoXaIkFCmxuZl6VBS1PMtr0z6tvvf/7P/3mewzkUIZgg A6l0RTatUsjkYg6PbbjcmbN3oNAs3bdSFRFrq60nY+tGb5HHWfFFrx1kfEPDL9Z5VhLvcAot T8+lVRFHr/PSVqzlZJa9GuXpG301aKkYlSGKAhwDgxMFZYhHCXAfArvhGWKEE4FpxsL5K5bn uliMeMSCWY2FcAs2riBg/VMnl3EesKDJ+YPNiCkEI90LLseH4uBTUPKtm+VmfxcPTGpJN/vh aKiZq+Yw5zHg6LhDMBwHpfpR5GY2Dob7j2s8zMfHQD9f6d1Dh6Bket0T8MGXQN867RmA8FZY etPsYQIHwLi9zsOA/cE6OsRhWAgztt8kw2LQz457WIivQNGgkXQPAGxAsDZ8z9v0KpgntN7w Hng3ZkcMi+B9nQ4xgVdc0LVpCcY4A4tNNi5jWBAYWszcjfR8e7O3SAmOMS2nAkUZ/9nW6MoQ uBRBxdsurtFzb18YNNjZRteLETgUTMXi/+vdvBtMD+cIhg+BfqWHw/AOqNRZuQzvh7m+74jh aDA9WePUI14jEqppdXJmalR0OK1Kv6FWKxXhCjq7Fbl+Wk/7asgLZJk/0YswhcSb+X60WSog Zbnq/MxeFOzqM9XSNIIC2Qqlghb784WdXVIBP0WWX0CrlNdUOXJa3YuCKLY4gG890JYkwKmy bDqDprNo1YbLonwCNSiuMWtn+AdlZIadt+yMz3tJP99VNTMTuv65MOzpF0lCeT5KFt1OkYzX /tQeUcZsOp26RXpWXq2LmzQPlS0uhCSclOQ6p3jlBy3bRxejKNytRAEXhi466G2i1aJ2YX9Q jEiTssmh7f8o+SoZGEiq6ahNHEs8d9OWZ3UkpQ2P3RWz1WmyyDBCpZb9Ad0SlMdxAwAA Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:02:54 -0000 --------------ms060408050305040505060107 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

That does not answer my question about whitespace around individual leaf/leaf-list values. The question about all these examples is also open.

regards Balazs

On 2018. 10. 09. 11:23, Qin Wu wrote:<= br>

This issue has been touched by earlier version= of draft-kwatsen-netmod-artwork-folding-07.=

RFC7950 has provide XML encoding rule as follows:

"

Any whitespace between the subelements to the list entry is

=C2=A0=C2=A0 insignificant, i.e., an implement= ation MAY insert whitespace

=C2=A0=C2=A0 characters between subelements.

"

Similar rule is applied to leaf-list.

=C2=A0

-Qin

=E5=8F=91=E4= =BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Bal=C3=A1zs Lengyel
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B410=E6=9C=889=E6=97=A5 1= 7:00
=E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org
=E4=B8=BB=E9=A2=98:= [netmod] Whitespace in XML encoding - allowed ?

=C2=A0

Hello,

Recently we came up against a problem where a certain implementation did not accept the following:<= o:p>

<with-defaults xmlns=3D"...">
=C2=A0=C2=A0=C2=A0 report-all
</with-defaults>

while it did accept 

<with-defaults xmlns=3D"...">report-all</with-defaults>=
;

I am unsure whether YANG's XML encoding allows whitespace before and after a leaf's value? In RFC7950 it does not say yes or no. I have found the following examples that seem to allow preceding/following whitespace:

https://tools.ietf.org/html/rfc795= 0#section-4.2.9

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <status xmlns=3D"http://example.com/=
system">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The image example=
-fw-2.3 is being installed.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </status>

https://tools.ietf.org/html/rfc795= 0#section-7.16.3

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <reporting-ent=
ity>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /ex:i=
nterface[ex:name=3D'Ethernet0']
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </reporting-en=
tity>

https://tools.ietf.org/html/rfc624= 3#appendix-A.3.1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <with-defaults<=
/o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns=3D"urn:ietf=
:params:xml:ns:yang:ietf-netconf-with-defaults">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 report-all<=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </with-defaults><=
o:p>

It is problematic that this is not clarified. IMHO this should be clarified in an errata to rfc7950. Chose one:

  1. It is not allowed to add preceding or following whitespace after the value of a leaf/leaf-list.
    Note that some text documents may add whitespace to Netconf examples to avoid long lines,
    however this extra whitespace MUST NOT be present in the actual Netconf encoding.
  2. It is not allowed to add preceding or following whitespace after the value of a leaf/leaf-list.
  3. It is allowed to add preceding or following whitespace after the value of a leaf/leaf-list except
    for string based types, where the whitespace could be part of the leaf's value itself..

What do you think?

regards Balazs

-- 
Balazs Lengyel=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ericsson Hungary Ltd.
        
Senior Specialist
        
Mobile: +36-70-330-7909=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 email: Balazs=
=2ELengyel@ericsson.com 

      
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms060408050305040505060107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwOTEwMDIyOVow LwYJKoZIhvcNAQkEMSIEID+74i0J7Db1jkEfyc0lGlxP55k82dZ8T9HLYAOpBMP0MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAHIULIbc5P4iTPv9yZcUwAxftyLloGB3gJ2maGRIDGJyF9yf xEH5QTug3AZnlv3r1ZWIZIWfNslHJQrXINE7c2wmbSFfd2jj7mglS5j/GQXPc9J42kDjp1zc KSVpNsNDosFLrJLC9JRGXh19NEnDDzoelsuCM2NqLUlm42j4sYxpmUlimgRRW5nXvQ4i3OFH 4AHrdCq1CEtX0oaO5g4/jgaD4mq4aeip6DQCeVzUx2MgR9lNcpAElGGw08zHRkFwJAQFnbSv O1F9c0WSu82tAj/VT6nJWogT5DrORjdXbwqAWv8HeLHVcjM8AWfMkT0su+qi2oJkxB0FJnQB N6mv7dMAAAAAAAA= --------------ms060408050305040505060107-- From nobody Tue Oct 9 03:07:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EEC13123D for ; Tue, 9 Oct 2018 03:07:10 -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, 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 O_7mBYOc0KjB for ; Tue, 9 Oct 2018 03:07:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78BE51311AD for ; Tue, 9 Oct 2018 03:07:07 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id CEA391AE0187; Tue, 9 Oct 2018 12:07:05 +0200 (CEST) Date: Tue, 09 Oct 2018 12:07:05 +0200 (CEST) Message-Id: <20181009.120705.20836607492685594.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:07:10 -0000 Bal=E1zs Lengyel wrote: > Hello, > = > Recently we came up against a problem where a certain implementation > did not accept the following: > = > > report-all > > = > while it did accept > = > report-all > = > I am unsure whether YANG's XML encoding allows whitespace before and > after a leaf's value? In RFC7950 it does not say yes or no. For example, RFC 7950 says about integers in 9.2.1: An integer value is lexically represented as an optional sign ("+" o= r "-"), followed by a sequence of decimal digits. If no sign is specified, "+" is assumed. So, space characters (and other characters) are not allowed. In XML, whitespace has meaning, so: 42 is not the same as 42 Since the string " 42 " is not a legal integer lexical representation according to 9.2.1, 42 is not a valid XML representation for the integer foo. > I have > found the following examples that seem to allow preceding/following > whitespace: > = > https://tools.ietf.org/html/rfc7950#section-4.2.9 > = > > The image example-fw-2.3 is being installed. > > > https://tools.ietf.org/html/rfc7950#section-7.16.3 > = > > /ex:interface[ex:name=3D'Ethernet0'] > > = > https://tools.ietf.org/html/rfc6243#appendix-A.3.1 > = > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-with-defau= lts"> > report-all > Yes, to be strict, these examples should have had some text that explained that whitespace was added for readability. New documents will hopefully use the new artwork draft's rules instead. /martin > It is problematic that this is not clarified. IMHO this should be > clarified in an errata to rfc7950. Chose one: > = > 1 It is not allowed to add preceding or following whitespace after th= e > value of a leaf/leaf-list. > Note that some text documents may add whitespace to Netconf example= s > to avoid long lines, > however this extra whitespace MUST NOT be present in the actual > Netconf encoding. > = > 2 It is not allowed to add preceding or following whitespace after th= e > value of a leaf/leaf-list. > 3 It is allowed to add preceding or following whitespace after the > value of a leaf/leaf-list except > for string based types, where the whitespace could be part of the > leaf's value itself.. > = > What do you think? > = > regards Balazs > = > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.c= om From nobody Tue Oct 9 03:17:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA352131250 for ; Tue, 9 Oct 2018 03:17:56 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 7K9AHDhDrkeE for ; Tue, 9 Oct 2018 03:17:54 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 E50D613123D for ; Tue, 9 Oct 2018 03:17:53 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w99AHnJW003852; Tue, 9 Oct 2018 11:17:49 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F09482203C; Tue, 9 Oct 2018 11:17:48 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS id E4C3522044; Tue, 9 Oct 2018 11:17:48 +0100 (BST) Received: from 950129200 ([12.208.209.2]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w99AHkod005591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2018 11:17:47 +0100 Reply-To: From: "Adrian Farrel" To: "'Martin Bjorklund'" , Cc: References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> <20181009.120705.20836607492685594.mbj@tail-f.com> In-Reply-To: <20181009.120705.20836607492685594.mbj@tail-f.com> Date: Tue, 9 Oct 2018 11:17:45 +0100 Message-ID: <034601d45fb9$53c73660$fb55a320$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJPOwHnoc3cs7ewtfatWZq/1xPcNwHFiAiFpBLQNjA= X-Originating-IP: 12.208.209.2 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24144.006 X-TM-AS-Result: No--18.217-10.0-31-10 X-imss-scan-details: No--18.217-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24144.006 X-TMASE-Result: 10--18.216600-10.000000 X-TMASE-MatchedRID: 6lay9u8oTUO0F82n+3va/3FPUrVDm6jt8GRhP/nTHNYrg7c3DY6jHcLm p4jPUF8trZqX9okZ7jD+w331TsHWuyqDVw6LinnHJrUxoq6hvw9+Mk6ACsw4JqN0vJETjYT21IS 0AS8acjt966XoOdpv0N0s4NX/eh4Ied6FhOj8IzpjBolet/YhdA0FwM3hFTalWSMW3+mJJ3Xqzk hCUQRGl9TfG5hYf1XwPYfQ1OxjITiY+BJXPkRKFkdAWPMBu8kQDvJ43UwBMxTb6Y+fnTZUL6tlt 7GxwXI+as3bPG6MbcqKlO3LpEVWHxvgHIDSxZX6ztFnzYQp41wxmbT6wQT2a0JqedX9vt/ZNst7 Vux2Zs6en249c8P4sVnXkQR++JUZkVF44oU3/QjCtSG/SQAC8XWT6A/Vdqa0myiLZetSf8nkA/7 Kqi9JmRre5nbuJbxORjjVhf+j/wqLZAVphLW/bSq2rl3dzGQ1SPqUqJpSCRvDjgcY22FUY8DZ03 dQrq1aDQvRn1Ed3q6cd8zfOACHzA== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:17:57 -0000 Hence why we go through so many hoops in the line-wrapping draft. Adrian > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin = Bjorklund > Sent: 09 October 2018 11:07 > To: balazs.lengyel@ericsson.com > Cc: netmod@ietf.org > Subject: Re: [netmod] Whitespace in XML encoding - allowed ? >=20 > Bal=E1zs Lengyel wrote: > > Hello, > > > > Recently we came up against a problem where a certain implementation > > did not accept the following: > > > > > > report-all > > > > > > while it did accept > > > > report-all > > > > I am unsure whether YANG's XML encoding allows whitespace before and > > after a leaf's value? In RFC7950 it does not say yes or no. >=20 > For example, RFC 7950 says about integers in 9.2.1: >=20 > An integer value is lexically represented as an optional sign ("+" = or > "-"), followed by a sequence of decimal digits. If no sign is > specified, "+" is assumed. >=20 > So, space characters (and other characters) are not allowed. In XML, > whitespace has meaning, so: >=20 > 42 >=20 > is not the same as >=20 > 42 >=20 > Since the string " 42 " is not a legal integer lexical representation > according to 9.2.1, 42 is not a valid XML representation > for the integer foo. >=20 > > I have > > found the following examples that seem to allow preceding/following > > whitespace: > > > > https://tools.ietf.org/html/rfc7950#section-4.2.9 > > > > > > The image example-fw-2.3 is being installed. > > > > > > https://tools.ietf.org/html/rfc7950#section-7.16.3 > > > > > > /ex:interface[ex:name=3D'Ethernet0'] > > > > > > https://tools.ietf.org/html/rfc6243#appendix-A.3.1 > > > > > = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> > > report-all > > >=20 > Yes, to be strict, these examples should have had some text that > explained that whitespace was added for readability. New documents > will hopefully use the new artwork draft's rules instead. >=20 >=20 >=20 > /martin >=20 >=20 > > It is problematic that this is not clarified. IMHO this should be > > clarified in an errata to rfc7950. Chose one: > > > > 1 It is not allowed to add preceding or following whitespace after = the > > value of a leaf/leaf-list. > > Note that some text documents may add whitespace to Netconf = examples > > to avoid long lines, > > however this extra whitespace MUST NOT be present in the actual > > Netconf encoding. > > > > 2 It is not allowed to add preceding or following whitespace after = the > > value of a leaf/leaf-list. > > 3 It is allowed to add preceding or following whitespace after the > > value of a leaf/leaf-list except > > for string based types, where the whitespace could be part of the > > leaf's value itself.. > > > > What do you think? > > > > regards Balazs > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Oct 9 03:38:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29913125E for ; Tue, 9 Oct 2018 03:37:59 -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, 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 mxog1y-Eoofm for ; Tue, 9 Oct 2018 03:37:56 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6BE131250 for ; Tue, 9 Oct 2018 03:37:55 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 554CE1821139; Tue, 9 Oct 2018 12:45:42 +0200 (CEST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id D7D161821137; Tue, 9 Oct 2018 12:45:26 +0200 (CEST) From: Ladislav Lhotka To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod\@ietf.org" In-Reply-To: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod\@ietf.org" Date: Tue, 09 Oct 2018 12:37:37 +0200 Message-ID: <871s8zh0cu.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:38:00 -0000 Bal=C3=A1zs Lengyel writes: > Hello, > > Recently we came up against a problem where a certain implementation did = not accept the > following: > > > report-all > > > while it did accept=20 > > report-all The "with-defaults" leaf is modelled as an enumeration in RFC 6243 (sec. 5), so the lexical representation is the assigned name, i.e. "report-all". So the behaviour above is correct according to the spec. On the other hand, this looks like a good place for applying the Postel principle because enum names must not have any leading or trailing whitespace, so no confusion can ever arise if this whitespace is stripped. Lada > > I am unsure whether YANG's XML encoding allows whitespace before and afte= r a leaf's value? In > RFC7950 it does not say yes or no. I have found the following examples th= at seem to allow > preceding/following whitespace: > > https://tools.ietf.org/html/rfc7950#section-4.2.9 > > > The image example-fw-2.3 is being installed. > > > https://tools.ietf.org/html/rfc7950#section-7.16.3 > > > /ex:interface[ex:name=3D'Ethernet0'] > > > https://tools.ietf.org/html/rfc6243#appendix-A.3.1 > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> > report-all > > > It is problematic that this is not clarified. IMHO this should be clarifi= ed in an errata to rfc7950. > Chose one: > > 1 It is not allowed to add preceding or following whitespace after the va= lue of a leaf/leaf-list.=20 > Note that some text documents may add whitespace to Netconf examples to = avoid long > lines,=20 > however this extra whitespace MUST NOT be present in the actual Netconf = encoding. > 2 It is not allowed to add preceding or following whitespace after the va= lue of a leaf/leaf-list. > 3 It is allowed to add preceding or following whitespace after the value = of a leaf/leaf-list except > for string based types, where the whitespace could be part of the leaf's= value itself.. > > What do you think? > > regards Balazs > > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 9 03:40:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22FA131269 for ; Tue, 9 Oct 2018 03:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=fo15mX/3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jDrpSN6y 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 stPJYr7qa7yQ for ; Tue, 9 Oct 2018 03:40:49 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 123C5131260 for ; Tue, 9 Oct 2018 03:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539081644; x=1541673644; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dvuCQoAoE82nku+dDbFFdydFfQv3bpj14/GWfgN2Gf0=; b=fo15mX/3oB5xqC0yweKocMZWbpB+ulF0ciEuCPaXGxyqZMXtPNuyWImh0gOWOPoM TyCqTSW6WCsM3nkGoM9EaOIqO0xNB0OsljECpWzed8qGuvi69OTV73stP0IE/X+9 Psi0Aa0JSQU+S5ZOrLy5pM/edl0UUPhjqXSx0ErGGGA=; X-AuditID: c1b4fb30-2d3ff700000047d2-c6-5bbc85ac003a Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.A9.18386.CA58CBB5; Tue, 9 Oct 2018 12:40:44 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 12:40:43 +0200 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 12:40:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T+wUhGsBtS99wTd/C/tZTuKDE0drUN8l9snw8JmBfxA=; b=jDrpSN6yxRFVTj1eIvvWlnD0u8V7I3rtEiQtqbO6lGDFpYdmOfX3Aj5k7WaD0Aya122awOSGNJjABZ2nBtO6tjAzo7wAQwqWHghSaJo1vZSkcLQBzqLHLn+8u06Vtoh7Paw/DjAnJaMN3ebPlmBFxY7FZJ/e6tHjwbs72fVAzi4= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB1822.eurprd07.prod.outlook.com (10.167.196.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.9; Tue, 9 Oct 2018 10:40:42 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 10:40:42 +0000 From: =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= To: Qin Wu , Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG adoption poll - draft-lengyel-netmod-yang-instance-data-04 Thread-Index: AQHUX7yGUFLVaMiBUk6dApLYhFnozw== Date: Tue, 9 Oct 2018 10:40:42 +0000 Message-ID: <6b3bbb83-2350-6ea8-2358-121cac17147b@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: VI1PR07CA0147.eurprd07.prod.outlook.com (2603:10a6:802:16::34) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1822; 6:O9ypQIaORuG0vEOZ9eERwb4oIDUyy1Ge2DRFjW3bD8BUj1nN5z1cmzJySNd7kiL5Z4AwOjHiZcK4DIU5LmmRfEvcQOojRLNshxIvTs513o4/6koDJScJ/9zL+JNdbUK/sB3gHZlKv0IUfgDgl6mobBHGNf2d+viorYHN4Oia0Kjyq6p44ki2rct1OV6hEput8MdigtZNNnkHn31bMVNpYoW1EDMRAx5GNR8BUgtOYGNMOGCr6VeRRn1RVK8bPnPOeeomfv8S8S2N2KIu/mp8/KI3XKMK2HefXvMAMYpJghMK54yDxB00avDaasYK4FydK8/6nZt5D34LWWoUc5MLpzraCAkohrI1wIgrNFvKNJnvH1kijZa9028qHrzwJL46HY1N5020LiVWsirJDqSW6EevrQA3EJE1zaCqtBpwFYFfLStLMahFORqNZZxCxlyysA8q6Gb03rSZxKerEbg3Fg==; 5:g5bPgPA9K6j+kS9zuwybRqkI5RTFRPgHi4fkzQEAleuk61R5IjovM35k02QmvR3Zg5A2shTIFJ8nttV9NaKL1VkvWsRwyHSwY8TrsWwoTjN5pfGZOHkypQahvs+H+u0trUXmlQ4Yn5YN5GZ8TQM4+ETL9biHaHoXyKo3vxXit4Y=; 7:Nm6Mi14FJ8q99SkKPcdNdWpG9CPjPgfaIDP4ASfh2h4yo17+qJ+QFC7azZsy3p5zBKFiLHdiTWEsRQ07dhYRZqEsuIiV5uTEhgZ7hADL8c5AWsfeEgqg5SPC1Z71O9Kyym5Xvx6zywbgNkdBKV/bwImqvdrohkLba8BG3ztytnq5GJ1sELM8T+Yc450UlUvveo+mLMySjohFk9hg3STUySiuWVv+UCUzkSqW8nFMj/TWOlUWoTaE8TQ4DHuAZEhx x-ms-office365-filtering-correlation-id: f4772182-c670-4245-486c-08d62dd3a948 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB1822; x-ms-traffictypediagnostic: VI1PR0701MB1822: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231355)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051); SRVR:VI1PR0701MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1822; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(396003)(346002)(376002)(252514010)(189003)(199004)(68736007)(5250100002)(6512007)(5660300001)(316002)(6306002)(478600001)(229853002)(99936001)(14454004)(3260700006)(85202003)(106356001)(31696002)(966005)(25786009)(4326008)(86362001)(8936002)(2906002)(53936002)(85182001)(81166006)(3846002)(6246003)(58126008)(8676002)(6436002)(6486002)(65826007)(31686004)(6116002)(81156014)(66066001)(65806001)(65956001)(64126003)(52116002)(99286004)(97736004)(186003)(110136005)(26005)(14444005)(386003)(6506007)(76176011)(102836004)(256004)(305945005)(7736002)(105586002)(2900100001)(11346002)(2616005)(71200400001)(71190400001)(446003)(476003)(36756003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB1822; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TzZmA2zLVNIBPIgCJFwZRPE0k+t14DUe+lqRHntvlsEjM4BYz9InJbP2E5RqCZHviar2PUjZZ6B//iTpj54YRxJCB6Jqh5bEyZ6kgJ7Vc33QdL9UbtG3aOyriQEJa97z0Biu7jFAR7JuFadFAdxkq8saFSChcJr9TvqJMz20LgUpWybZGRQhC0MI44rbqkTQIbyJeoMNOxi5Kq9Jsb7y+zjknZ+qGqKFRkw4YWsyyFmW0/hlJ/kiN86Fv/1xVQ3R9krR0zkws8VyTax58Tnlcg1JdIFeUZp1iW1jigwXgIKvv0MRVxifj9hAf/dwf5DiscnyIT2lP5DhtGHoKEdO00YDyOWsnUGQDczHiDggNUs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050601030207060103030307" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f4772182-c670-4245-486c-08d62dd3a948 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 10:40:42.3283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1822 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSaUhUYRSG+eYuc50cuo5LB8XAQQKtzExpoMUWCv3R9iMxl2rUW5o6yr1T VBa45palKTqKjVpmlGal5S6UKTiJ4oKJUpk6FaOJC5mkWc3Mp1D/nvO9533POfAxhGySsmci VGqOVymj5LSELPSvV2+tSmkJdM8bslZM3C2lFGlJ06SiMmuToqQvgdpH+iS3T1M+5eU/RT6z NUn0cSJAsjuMi4q4xPHb9p6VhA89TCRj5w5cfjOYQ8ejX3sykAUDrCd0Fk9QJpaxHQjGPxzL QBIjLyDo7tWRuLgvguT8JspUkGw2AR2pBWKs5IsgpbKBwsU4glvDn8WmMJo9BDM/ls1swwbD jDbZPIRgt0LvXI/IxNbsSRgZrBLhHj+obTbQmN3g0WKL+Z1knaGvbtCYwzBS1hs6da54Vqpx Vn2rucfC6E15soxMjFg7WHyLMwl2A4zoS0T4UBsY6+uiMduCYeI3hVkOmskRM9sa90zWFZmP AVaDoDenToRDT0PLx7RV8xboHtIjzI7QX5KJsOGVGKZytWIsHIFv8wliLAwgmK1sJNbcmtGR VXcMpH9JILKRR9E/2xYZPQSbjqB4qZEwCVLWCnSFehI3eULxvWwC82aoKJsi/jebeBdoll7T mJ0gL3NMjNkLpjrmEOYdUFG9QpciyWNkK3BCSPR5Dw83jo8IFYQYlZuKU9cg4697/WLZvQEZ vu5vQyyD5JbSnddbAmWU8pJwJboNORtzxp9V9iJ7UhWj4uQ2Utv6pkCZNEx55SrHx5zhL0Zx QhtyYEj5BqniaG2AjD2vVHORHBfL8WuqiLGwj0fewxnvXAKj4/rT7Az6jtxPozMHterIoHK9 4UFw8OHixefnbjhMbvQfTey64Cusn7BozyrTqJ11U02SU47211LdLZ+dWHjpG7fOKs+z9el7 Px7RIdJ6xmnFxTBdcHOmeSgCgnyrQ79rV5rRpx7qtuu8l/YPH9010C/Ol9/Jd+6Xk0K4crsr wQvKv1wzDWR9AwAA Archived-At: Subject: Re: [netmod] WG adoption poll - draft-lengyel-netmod-yang-instance-data-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:40:52 -0000 --------------ms050601030207060103030307 Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Qin, I will add the referemce. Netconf server capabilities can be read from ietf-netconf-monitoring=20 /ncm:netconf-state/ncm:capabilities/ncm:capability regards Balazs On 2018. 10. 09. 8:28, Qin Wu wrote: > Support adoption of this draft, > Two quick comments on this draft > 1. section 2.5 factory default setting > I would suggest to reference to draft-wu-netconf-restconf-factory-resto= re in section 2.5. > I think this draft is complementary to draft-wu-netconf-restconf-factor= y-restore-02, factory datastore can rely on yang instance data file to sp= ecify the content of factory datastore. > 2. section 2.3 server capability > Server capability in the context of this draft is referred to a set of = models and features which can be retrieved from yang library, I see serve= r capability as NETCONF capability. > I am wondering whether yang data instance file can also be used to spec= ify capability identifiers. Some time I have trouble to understand where = the server to get capability > identifier and exchange it in the hello message. > I understand RFC6470 can advertise the capability change. > > -Qin > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: netmod [mailto:netmod-bounces@ietf.org] =B4=FA=B1=ED= Lou Berger > =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA10=D4=C28=C8=D5 19:39 > =CA=D5=BC=FE=C8=CB: NetMod WG > =B3=AD=CB=CD: NetMod WG Chairs > =D6=F7=CC=E2: [netmod] WG adoption poll > > All, > > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group document. Pl= ease send email to the list indicating "yes/support" or "no/do not suppor= t". If indicating no, please state your reservations with the document. = If yes, please also feel free to provide comments you'd like to see addr= essed once the document is a WG document. > > The poll ends Oct 22. > > Thanks, > > Lou (and co-chairs) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms050601030207060103030307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwOTEwNDA0MVow LwYJKoZIhvcNAQkEMSIEIDESs79Y+yq3Lw09JFZSA576cSTZyQKyh7nCI/0GejwHMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAHUhYE3ePrpViBvph4eQi+OB0OdbuqGQZ+3JFUOrXfXI/dwN lFCd/NwWyjGCvV3vMXbWQynhguZ8QzbfUqQVf+dO9Q7Rb+/NxcfTM6jTGdpEl5uyqH8K9aqD CXbAHPxuwwnFlibAvXLTYtw5T5LtQTFD5PH3ayh6UN+Fc3htZEi8iQ90nDrsWhPcWAgNLfpc V4fvdTEp7sGfCht/d5XhBg+TtnKME1BLCmvhLIMmS73C7RmBZNLHLMwRSmi22AMzVtRY+gXK uQ/EJl6Ijnhm3zUCwOK/QUva4+dRvlDZqb0mAB2a/gRF0s9lYYr+ocaL8yQyj3G3M/qFN/Hi CgDyYaUAAAAAAAA= --------------ms050601030207060103030307-- From nobody Tue Oct 9 03:44:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62789131250; Tue, 9 Oct 2018 03:44:48 -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, 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 aQ4rHS95G30r; Tue, 9 Oct 2018 03:44:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AFDC913123D; Tue, 9 Oct 2018 03:44:46 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id BF7AF1821139; Tue, 9 Oct 2018 12:52:34 +0200 (CEST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id CBC3D1821137; Tue, 9 Oct 2018 12:52:33 +0200 (CEST) From: Ladislav Lhotka To: Lou Berger , NetMod WG Cc: NetMod WG Chairs In-Reply-To: References: Mail-Followup-To: Lou Berger , NetMod WG , NetMod WG Chairs Date: Tue, 09 Oct 2018 12:44:44 +0200 Message-ID: <87woqrflgj.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:44:49 -0000 I support the adoption. Lada Lou Berger writes: > All, > > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group > document. Please send email to the list indicating "yes/support" or > "no/do not support". If indicating no, please state your reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends Oct 22. > > Thanks, > > Lou (and co-chairs) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 9 03:58:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220CB131280; Tue, 9 Oct 2018 03:58:27 -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, 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 XiATsrW4DzPT; Tue, 9 Oct 2018 03:58:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D21F013127B; Tue, 9 Oct 2018 03:58:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id AD1A81AE0428; Tue, 9 Oct 2018 12:58:23 +0200 (CEST) Date: Tue, 09 Oct 2018 12:58:22 +0200 (CEST) Message-Id: <20181009.125822.1764836266889190398.mbj@tail-f.com> To: lberger@labn.net Cc: netmod@ietf.org, netmod-chairs@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:58:27 -0000 Hi, I still think that this draft should either be split into two, one for specifiying the generic file format (ok with examples), and one for "Documenting Server Capabilities", or the document should just be about the file format (+ *examples*). [The current document mixes the two; it's a bit as if we had "The YANG language and a model for interfaces" as one doc...] It is clear that the document specifies a file format for YANG instance data, which is good. But it is not clear if the document intends to specify how a server should document its capabilities. The Introduction mainly talks about why it is important to document server capabilities. But then AFAICT there is no normative specification of how a server would document its capabilities. /martin Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group > document. Please send email to the list indicating "yes/support" or > "no/do not support". If indicating no, please state your reservations > with the document. If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. > > The poll ends Oct 22. > > Thanks, > > Lou (and co-chairs) > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Oct 9 04:19:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDBD1312D3; Tue, 9 Oct 2018 04:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 aKUmrHmumnYA; Tue, 9 Oct 2018 04:19:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFFD1312BB; Tue, 9 Oct 2018 04:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2821; q=dns/txt; s=iport; t=1539083994; x=1540293594; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=90BvInPbtdtZGWZoTtZqRiwvvxFEQp+CLmShYjgsjqI=; b=AG+LGZEROkOgIfYI4q2D/C3Py8I/w8anbY2VZCdXDg9mBA1yw5w1mHVd Bqk8IvdAEf5wdPL/E5P7JnFmazlIPsEXPrG5TiutDQpVPhH2aYe+UOeY6 0ydx+dwRGvnWa2NpktDMDFxPSDc4ulkmSab8xWSLMJY0OVMbLHRQZRida A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AABhjbxb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJsfyiDdYh0jWCXA4FmDRgLhANGAoRpOBYBAwEBAgE?= =?us-ascii?q?BAm0cDIU6AQEBAwEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBgx0BggEPo3+?= =?us-ascii?q?BLoR3hR4FgQuKRYFBP4ESJ4JrgxsBAYEuARIBCYMXglcCnXYJiSeHHQYXgU6?= =?us-ascii?q?EZ4JoJoY8j0mGLoFZIWRxMxoIGxU7gmyLF4U/PjCKFII+AQE?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208";a="7047681" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 11:19:51 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w99BJpoY026452; Tue, 9 Oct 2018 11:19:51 GMT To: Martin Bjorklund , lberger@labn.net Cc: netmod-chairs@ietf.org, netmod@ietf.org References: <20181009.125822.1764836266889190398.mbj@tail-f.com> From: Robert Wilton Message-ID: <5b4af910-5bdd-2cb6-64fb-d19977004ab1@cisco.com> Date: Tue, 9 Oct 2018 12:19:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181009.125822.1764836266889190398.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:19:56 -0000 +1 to Martin's comments.  I think that I made similar comments at the mic at IETF 102. I strongly support the idea of documenting YANG instance data. If the WG timing works out I would like this to cover CBOR as well. I also strongly support the idea of documenting server capabilities.  But I'm opposed to conflating these two separate concerns in the same draft. I also think that that there should be a optional mechanism to embed the list of module revisions (and perhaps features) that are required to correctly decode the instance data. E.g., the example in section 3 contains YANG library data, but I don't know which version or YANG library I need to read in the instance data.  It might have been constructed assuming the format from RFC 7895, or it might have been constructed using the format from YANG library bis, which could easily fail if my tool attempts to interpret the instance data against the schema in RFC 7895.  So I think that this information is critical for tools to be able to interpret the instance data in a reliable fashion. Thanks, Rob On 09/10/2018 11:58, Martin Bjorklund wrote: > Hi, > > I still think that this draft should either be split into two, one for > specifiying the generic file format (ok with examples), and one for > "Documenting Server Capabilities", or the document should just be > about the file format (+ *examples*). > > [The current document mixes the two; it's a bit as if we had "The > YANG language and a model for interfaces" as one doc...] > > It is clear that the document specifies a file format for YANG > instance data, which is good. But it is not clear if the document > intends to specify how a server should document its capabilities. > > The Introduction mainly talks about why it is important to document > server capabilities. But then AFAICT there is no normative > specification of how a server would document its capabilities. > > > /martin > > > Lou Berger wrote: >> All, >> >> This is start of a two week poll on making >> draft-lengyel-netmod-yang-instance-data-04 a working group >> document. Please send email to the list indicating "yes/support" or >> "no/do not support". If indicating no, please state your reservations >> with the document. If yes, please also feel free to provide comments >> you'd like to see addressed once the document is a WG document. >> >> The poll ends Oct 22. >> >> Thanks, >> >> Lou (and co-chairs) >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Oct 9 04:25:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE71312D2; Tue, 9 Oct 2018 04:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 n43wsWciXZoW; Tue, 9 Oct 2018 04:25:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 A85261312BB; Tue, 9 Oct 2018 04:25:43 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 8E452600DE; Tue, 9 Oct 2018 13:25:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539084341; bh=l56cEZ70W1zAFT+D8bTpcrSch5UgeqpcabS7eZy9sFI=; h=From:To:Date; b=mlypukBB2+9Gg59RwwJoaSSudJ/qZ9lJlNdM3TI4yXrOK71FMNwVp/jzmuCAUC1iZ 7Udcy+iv4M/PZFS35lLwclYxzhfcnLzfwLuaut1KBOPbVoBhpWSaWu0+MuVtk06EN4 onEVH2Av4vK3sWHB3csprR1H0cfJ24fbQRdQwJAc= Message-ID: <4833b37026acc670bc616128946045051e2f4a87.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , Martin Bjorklund , lberger@labn.net Cc: netmod-chairs@ietf.org, netmod@ietf.org Date: Tue, 09 Oct 2018 13:25:41 +0200 In-Reply-To: <5b4af910-5bdd-2cb6-64fb-d19977004ab1@cisco.com> References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <5b4af910-5bdd-2cb6-64fb-d19977004ab1@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 11:25:47 -0000 On Tue, 2018-10-09 at 12:19 +0100, Robert Wilton wrote: > +1 to Martin's comments. I think that I made similar comments at the > mic at IETF 102. Me too, it is also recoreded in the minutes. I thought this could be addressed after this draft becomes a WG item. Lada > > I strongly support the idea of documenting YANG instance data. If the WG > timing works out I would like this to cover CBOR as well. > > I also strongly support the idea of documenting server capabilities. > But I'm opposed to conflating these two separate concerns in the same draft. > > I also think that that there should be a optional mechanism to embed the > list of module revisions (and perhaps features) that are required to > correctly decode the instance data. > > E.g., the example in section 3 contains YANG library data, but I don't > know which version or YANG library I need to read in the instance data. > It might have been constructed assuming the format from RFC 7895, or it > might have been constructed using the format from YANG library bis, > which could easily fail if my tool attempts to interpret the instance > data against the schema in RFC 7895. So I think that this information > is critical for tools to be able to interpret the instance data in a > reliable fashion. > > Thanks, > Rob > > > On 09/10/2018 11:58, Martin Bjorklund wrote: > > Hi, > > > > I still think that this draft should either be split into two, one for > > specifiying the generic file format (ok with examples), and one for > > "Documenting Server Capabilities", or the document should just be > > about the file format (+ *examples*). > > > > [The current document mixes the two; it's a bit as if we had "The > > YANG language and a model for interfaces" as one doc...] > > > > It is clear that the document specifies a file format for YANG > > instance data, which is good. But it is not clear if the document > > intends to specify how a server should document its capabilities. > > > > The Introduction mainly talks about why it is important to document > > server capabilities. But then AFAICT there is no normative > > specification of how a server would document its capabilities. > > > > > > /martin > > > > > > Lou Berger wrote: > > > All, > > > > > > This is start of a two week poll on making > > > draft-lengyel-netmod-yang-instance-data-04 a working group > > > document. Please send email to the list indicating "yes/support" or > > > "no/do not support". If indicating no, please state your reservations > > > with the document. If yes, please also feel free to provide comments > > > you'd like to see addressed once the document is a WG document. > > > > > > The poll ends Oct 22. > > > > > > Thanks, > > > > > > Lou (and co-chairs) > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Oct 9 05:15:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304DE1312FF for ; Tue, 9 Oct 2018 05:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Bd7psBuk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Z/768Mkz 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 IzOtwjJqK467 for ; Tue, 9 Oct 2018 05:15:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB571312FC for ; Tue, 9 Oct 2018 05:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539087331; x=1541679331; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bfjrjUKHBQ8YsuEZ/8lOg6VD+sedPVXYAa0kW4X1V8Y=; b=Bd7psBukLOs9HlNQ+l5DhnpxmDZ4iwBGLA4ipM9JxOP7R7Ui9rheH7gk1Oh5dMLc jYzL9maMQPUUHShFyWiD9g20wX7nZAc44fX131kgYs5eyusT7sxqoo4p07/wR+dD 3wVNvZvjyILMvAZnCXT0+O/ObK7aSst3effjlUjuc/8=; X-AuditID: c1b4fb2d-b37ff70000003a27-90-5bbc9be39349 Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.98.14887.3EB9CBB5; Tue, 9 Oct 2018 14:15:31 +0200 (CEST) Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 14:15:30 +0200 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 14:15:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oLY+cRXPt/dVFn9YB30F1J91QugSEiJx7E1NKbV3584=; b=Z/768Mkz1hoPm74K11g0b8vaRoz00pPpe7ZXmWMOrpqL238/tBUgdsPEHmzkWPhwrIvLVm+kzlUDwWp+BpBuo7IZwxwwvzJ69/1lrx0NcqX9xQ1Ghu5faRZgrXj95YghUkA5+KAzJNo3P0/R7IAoDbSZ+eLzw7Iox8HoaJFojrA= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2174.eurprd07.prod.outlook.com (10.169.137.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.9; Tue, 9 Oct 2018 12:15:29 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 12:15:29 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund , "lberger@labn.net" CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll - instance-data Thread-Index: AQHUX8nE73dp3VpHWUiGmD0UGzMU6g== Date: Tue, 9 Oct 2018 12:15:29 +0000 Message-ID: <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> References: <20181009.125822.1764836266889190398.mbj@tail-f.com> In-Reply-To: <20181009.125822.1764836266889190398.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: DB6PR06CA0010.eurprd06.prod.outlook.com (2603:10a6:6:1::23) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2174; 6:AbkTKE36L+Ck1VeVFzsDDYhu9Y3yNP8CxPLTCkl4PeXre7VxKDvWiNcrZBRN/ZLDkS0Vk6zURiVZH3zCuDlWdhJQXoVcKA8o5YZ+qZ9xFuSTzE0lxlGQ8D1YOza2NewNWt1fJY66ucoHYd8wH+4GMQyqJAhDJ5aY/FbDj1G5cZ53t72pzaeYMD/YTQf1L/1HzIXZHN6Yrm1xuOwfIKKQNEnA6p9bQcwcnnAon2HRCf6w7xPEKce0loWKtpMa8grYOC2xx0X5wDx2ICVHIDcXwkG6mV2jWVE54sAj7z4XibcpVuqO2uLkk80VuuSEVfv5xJwhzaPgwWZjL/vja4P1DM5CsNeqmmjygwhSQDLjIhZnPY91k9a5zOO70J8D1L4rJHTi9kyy2IlCfy4ZgunFp37EoOJ0SApM07KPKUibvMpIPwgPQ3kxXAPoEIPrMCfsmgDmDdU5hes4oU+YtnRLbQ==; 5:Na5zG+Q3i8VRnxPMwLOJnTNQbabtavn7fX+ZNm4O2tCgpTEekPYD03igfS2yvdAPt7nG/L9c666Kv7HFcUCTPQ4SiGtWcrvML2wJWENZY5L6oUKQltajFGoJRDdU1GWEvyX1wlowYUsBDZJ/l0IxuJkR1IkhNr6rz1D6buhh0Is=; 7:Qbrm8PpV18amZiD5kSCiDyEhHLz5yvWEUxKZxONLjuWJuLXrnfRXKqo6NoLTqP87wsGkSfHxFU0wwJxluyO0k26u9FFdNq22vsyBxH6Ck0f1GxAwhgrOGj/rDEwM6G9nOnnDhCWEwo/F+OVv+rLNY7rbd5MmwpfTF0PrtvTtWI+CsaCIfbAl4ppWA8TrGM2vxUN+7uR+HDbyMthYc/ihcCYEeYCWcLVGUVV9XnIX2VnqhNp8KgbOxeI3IOy0Dby4 x-ms-office365-filtering-correlation-id: 2a1367a8-8652-4e37-5860-08d62de0e66b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2174; x-ms-traffictypediagnostic: VI1PR0701MB2174: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(248295561703944)(37575265505322); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:VI1PR0701MB2174; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2174; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(39860400002)(136003)(396003)(189003)(252514010)(199004)(68736007)(476003)(58126008)(36756003)(54906003)(110136005)(316002)(6436002)(486006)(2616005)(446003)(11346002)(478600001)(99936001)(31686004)(66066001)(65956001)(65806001)(71190400001)(6506007)(386003)(71200400001)(14444005)(256004)(65826007)(5660300001)(81156014)(102836004)(81166006)(6486002)(26005)(229853002)(8676002)(2900100001)(6512007)(76176011)(85182001)(3260700006)(25786009)(53936002)(6246003)(14454004)(105586002)(64126003)(3846002)(86362001)(99286004)(6116002)(31696002)(186003)(52116002)(6306002)(85202003)(305945005)(966005)(8936002)(7736002)(106356001)(2906002)(2501003)(5250100002)(4326008)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2174; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: s6lS2Mi9a4VVXu2EbH9+obM0dCx13JsWvYWCKARbIyMiPmAoWEgyrqPty//sC0SpsemnNV748H5yns6lZS0KPxIIesjoLJARf3h6jnjwKC1Oe/Sq4LFAGbfLqO92bG8PCKHmpJAg8xmPNVRjNMPH+m740XW/ARvCWTGRtlLc7hzrY/6gLEkwH/AeGYn379kGgvUl6aexVdTs5G7+15Jjcl3o+pOLk+lJAQX0O6gZhW7livE06C10RxG+AUXa8MQUmhkNuN1+fvj1wf10uynszXa8Zqop26d9xH6k0gIs4LR+y/qyeL+3o7YdgA0l89j3VAZFAOEtGQRsDbA/rDr/juefsmdouHdv72dQJK86BVk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040003050606000908010300" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2a1367a8-8652-4e37-5860-08d62de0e66b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 12:15:29.8097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2174 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1XSe0hTcRQH8H67d9vdcvBzzTzZgxpaaGmlZQvTChKESuyfDK1s6U2lPeTe WRlETkXNZRim+Qgf+QKtKHuYMfGVryTTRQ8sRzqNykdJWmoZud0J9d/n9/ud77nnwKUI6Se+ CxWr0dGMRqmSC8Rk/pE6nael0Bi+5WW7uyI9eZxUGAwfhYqazPWK4j49fw8ZVF4+ywv6Vpss CLo3V0aGEGHiXVG0KvYMzWwOOCGOMTcPkHFPA89N3i4nE9H73RlIRAHeBlOdr8gMJKakuA3B RGYVwR2mEVR/1vOtVVJcxoPRARfrA4mzCHgym8XnqnJ4MJ07YI8MIaifn7VFBHgfpE008qyW 4QMwc2PSZgIfhY6GCtLqZdgXyi0dfK5mB0y1JxGcvaCoJ1VgNYldoaqy0XYvwbsh90OVkBuJ gfbvZmS1CO+Fy0k5tv4IL4efz27Zv+UM/cPFPG5RGQz2dQs4O8Fnyx8+Zznkfem32Qkfg5Su AttmgLMR6DO7CK7pcTCa0+3hTfD8zTDivBpMxQa7m4TQYVZnIGrBB0FvEnJ9XiKoMjcQi9mS r3P2gbTQkD2CspB3wT+zFixkCHwJQXfPDFFgW9oRuvKHSa7IF4ruDxKcN0Jl6Sjxf9hqP8ib axZwXgfXDINCztthtG0ScfaByjvzghIkrkZOLM2y6mhvHy+aiY1kWa3GS0PratHCP9f84Jfn Y1QzurcFYQrJHSQhF43hUr7yDJugbkGuC32G7tb0IhdSo9XQcpnEqe5JuFQSpUw4TzPaCCZe RbMtaCVFyp0lXtXGMCmOVuro0zQdRzOLrzxK5JKIHDfob1quvvVVj4VKVnzEARE6be1MncPa 5qWi/Dfr/Aw/tl8wvitMchvzX+LuHyqKeJE4Yqke70xP2fk6vrsosKK1MS0qmOfhGt+637Tq KnWl6bBMYTIlnkq6LnWLiEx99LDmtzs5Mb+RLVXPBCtks3EVqzPHzp48lLtGVd/LUCo5ycYo t3oQDKv8C1WmMJl7AwAA Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 12:15:38 -0000 --------------ms040003050606000908010300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello Martin, I agree that this document shall be about defining the file format, and server capabilities shall only be a use-case.) I already took out a lot of text, that explicitly recommended using instance data for documenting capabilities. Server capabilities are only = mentioned in the introduction chapter. As you wrote: There is no _normative_=C2=A0 specification of how a server= =20 would document its capabilities, because this is what the WG requested, so I removed it. I see that I forgot to change the title and the introduction can be=20 reworded to make it more clear that documenting server capabilities is just a use-case. (I still see it as the primary use-case for instance data.) =C2=A0If I promise to change the title and clarify the introduction can = you=20 support adoption? regards Balazs On 2018. 10. 09. 12:58, Martin Bjorklund wrote: > Hi, > > I still think that this draft should either be split into two, one for > specifiying the generic file format (ok with examples), and one for > "Documenting Server Capabilities", or the document should just be > about the file format (+ *examples*). > > [The current document mixes the two; it's a bit as if we had "The > YANG language and a model for interfaces" as one doc...] > > It is clear that the document specifies a file format for YANG > instance data, which is good. But it is not clear if the document > intends to specify how a server should document its capabilities. > > The Introduction mainly talks about why it is important to document > server capabilities. But then AFAICT there is no normative > specification of how a server would document its capabilities. > > > /martin > > > Lou Berger wrote: >> All, >> >> This is start of a two week poll on making >> draft-lengyel-netmod-yang-instance-data-04 a working group >> document. Please send email to the list indicating "yes/support" or >> "no/do not support". If indicating no, please state your reservations= >> with the document. If yes, please also feel free to provide comments >> you'd like to see addressed once the document is a WG document. >> >> The poll ends Oct 22. >> >> Thanks, >> >> Lou (and co-chairs) >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms040003050606000908010300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwOTEyMTUyNVow LwYJKoZIhvcNAQkEMSIEILJlAyYE+JeRj/ALxF4W4i+ZUvXRldqudiUu5D4hHF3+MGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAL485hbf7x2J8TZC8SdJZhv+aidHc31AR36C7njH0VCF8hGQ 38l8Uf7JA/7JfH64fX7NjkJZh9FiXgIFCYayNFiaaxNiDghhgEZVjdDsIG65Xq2SwPlWGXMi z15Q+O8p9Z9hly03hEcYCtusMKQUYKBfXk6iBMpVembrWRm2IQyj1dvh047pQCseJZsu6K1a 8JzLQffRDh1650u7AKUcw6egMNxF2V6pt3vgEP1RW3Zy4yM86Z8eHxkGSPK/m+1PPI57+aI9 BrFEgjoDc7d5PMmBo4E2M4ZWWOpvPkl5n6ujGH9W7H4ZkXy8z1qrvkJBEGRLYhDpE4mD2i+6 qNFs9PAAAAAAAAA= --------------ms040003050606000908010300-- From nobody Tue Oct 9 05:17:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FB4131300; Tue, 9 Oct 2018 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 SLAJ07yU6xBc; Tue, 9 Oct 2018 05:17:17 -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 56B3B1312FF; Tue, 9 Oct 2018 05:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=673; q=dns/txt; s=iport; t=1539087437; x=1540297037; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8fKu43if3EPmBTox0jLa/ZqsiDN1wp5JbjRgT4ROKbQ=; b=k5+1x0IJBVaUpBBA/czDgjcQeaLFb6qkIWBwQ89/DYguhgqNsizfwI2S sILqgz9a1K+JxnuVtQdU79vNPftb03L4YbZDs91efTv37SW4AOiXQWACQ 18ar0ouqZqVnIoAuWfRdfUTfTATQz6KIP+KqC4heYgWxsuUpHVnL1Xwl7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAADIm7xb/51dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIGgWWEHZRHgg2XA4FmDYRsAoRJITgWAQMBAQIBAQJ?= =?us-ascii?q?tKIU6AQUjDwFGEAsOCgICJgICVwYBDAgBAYMdggKkD4EuihuBC4ouF4FBP4E?= =?us-ascii?q?5gmuESwESAYMgglcCnXYJkEQGF4E/D4RngmiGYpV3gVkhZHFNIxU7gm2QcCO?= =?us-ascii?q?KRII+AQE?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208";a="467036499" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 12:17:16 +0000 Received: from [10.229.13.61] ([10.229.13.61]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w99CHFjg005652; Tue, 9 Oct 2018 12:17:15 GMT To: Lou Berger , NetMod WG Cc: NetMod WG Chairs References: From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo= Organization: Cisco Message-ID: Date: Tue, 9 Oct 2018 08:17:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.229.13.61, [10.229.13.61] X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 12:17:19 -0000 On 10/8/18 07:38, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-lengyel-netmod-yang-instance-data-04 a working group > document. Please send email to the list indicating "yes/support" or > "no/do not support".  If indicating no, please state your reservations > with the document.  If yes, please also feel free to provide comments > you'd like to see addressed once the document is a WG document. I support adoption. The biggest concern I have with this is how one will extend the metadata. This is more about how one augments YANG data, but I feel it will need to be solved to make instance data truly useful. Joe From nobody Tue Oct 9 05:25:13 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA557131308; Tue, 9 Oct 2018 05:25:11 -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, 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 UDSrNrxy7wSI; Tue, 9 Oct 2018 05:25:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 76CB5131303; Tue, 9 Oct 2018 05:25:09 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id CF1A01AE0428; Tue, 9 Oct 2018 14:25:07 +0200 (CEST) Date: Tue, 09 Oct 2018 14:25:06 +0200 (CEST) Message-Id: <20181009.142506.637283350958767455.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: lberger@labn.net, netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 12:25:12 -0000 Hi, Bal=E1zs Lengyel wrote: > Hello Martin, > = > I agree that this document shall be about defining the file format, > and server capabilities shall only be a use-case.) > = > I already took out a lot of text, that explicitly recommended using > instance data for documenting capabilities. Server capabilities are > only mentioned in the introduction chapter. > As you wrote: There is no _normative_=A0 specification of how a serve= r > would document its capabilities, because this is > what the WG requested, so I removed it. Hmm. Ok, if this is what the WG wants, then it is fine to just have server capabilities as an example use case. (I thought that the WG wanted a normative description of server capabilities...) > I see that I forgot to change the title and the introduction can be > reworded to make > it more clear that documenting server capabilities is just a use-case= .= > (I still see it as the primary use-case for instance data.) I think all text in 2 Introduction (except the last para) in this case should be moved to section 2.1, and new text should be written in 2. (*if* there will be a separate doc for server capabilities, the text in 2 should be moved to that doc instead.) > =A0If I promise to change the title and clarify the introduction can = you > support adoption? First of all I'd like to ensure that the WG in fact just wants to do the file format. Since people have expressed support for adopting the draft with the current title, I'm not so sure that this is the case. I think you should make those changes, and I support the adoption of the modified document. I don't see any reason not to make these chanegs before posting as a WG doc. /martin > = > regards Balazs > = > On 2018. 10. 09. 12:58, Martin Bjorklund wrote: > > Hi, > > > > I still think that this draft should either be split into two, one = for > > specifiying the generic file format (ok with examples), and one for= > > "Documenting Server Capabilities", or the document should just be > > about the file format (+ *examples*). > > > > [The current document mixes the two; it's a bit as if we had "The > > YANG language and a model for interfaces" as one doc...] > > > > It is clear that the document specifies a file format for YANG > > instance data, which is good. But it is not clear if the document > > intends to specify how a server should document its capabilities. > > > > The Introduction mainly talks about why it is important to document= > > server capabilities. But then AFAICT there is no normative > > specification of how a server would document its capabilities. > > > > > > /martin > > > > > > Lou Berger wrote: > >> All, > >> > >> This is start of a two week poll on making > >> draft-lengyel-netmod-yang-instance-data-04 a working group > >> document. Please send email to the list indicating "yes/support" o= r > >> "no/do not support". If indicating no, please state your reservat= ions > >> with the document. If yes, please also feel free to provide comme= nts > >> you'd like to see addressed once the document is a WG document. > >> > >> The poll ends Oct 22. > >> > >> Thanks, > >> > >> Lou (and co-chairs) > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- = > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > = > = From nobody Tue Oct 9 08:06:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CCC13133B for ; Tue, 9 Oct 2018 08:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=C0MfF4Pv; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WIGTK5+Z 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 su3GTcXbtM06 for ; Tue, 9 Oct 2018 08:06:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B1FA9131338 for ; Tue, 9 Oct 2018 08:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539097584; x=1541689584; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YsmW2HQFIQfy3Ox14kz4EhWVUrs9vNbz0+LKurixhfk=; b=C0MfF4PvAb3IKJcuQljVLv0BeuNRpV5dTV8tmIDvwgi21NkJk8H8wcQ+J+QBGiGn nxbZ7J4yvrZFYrykgVBltFNs4ewD+lRO6T0yj4rh0sqPKWLFp1RtD1Kn8kUP8T46 OitZhHudE4hAWRDCySf9z9OMsS2iCkgp75pfBRGFgXQ=; X-AuditID: c1b4fb30-776849e0000047d2-2d-5bbcc3f0ca8a Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.DB.18386.0F3CCBB5; Tue, 9 Oct 2018 17:06:24 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 9 Oct 2018 17:06:24 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 9 Oct 2018 17:06:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IDXsTq5LRqiw1g8V4XAL+1GmIMp+pScQWlfdbtUu5Y4=; b=WIGTK5+ZPjEqRoldApK+5seepZjyN+ExjmPwrvrqZSZ0J/HJWcJRvaGEUR5cFFjrKAd7z/7SYKyt7cZ1h05MTLg8w44K5HNOA6F6WHsQcKVo9RJcecTebvtuHRQz+nDexGtumi50Bpk86qVcRbnW6SbdcQSUMkd0t5h0E04B59g= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB1822.eurprd07.prod.outlook.com (10.167.196.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.9; Tue, 9 Oct 2018 15:06:23 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 15:06:23 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Martin Bjorklund CC: "lberger@labn.net" , "netmod-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll - instance-data Thread-Index: AQHUX8nE73dp3VpHWUiGmD0UGzMU6qUW1qUAgAAtC4A= Date: Tue, 9 Oct 2018 15:06:22 +0000 Message-ID: <9e389747-74ed-0f62-24ce-813ce3cdc870@ericsson.com> References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> <20181009.142506.637283350958767455.mbj@tail-f.com> In-Reply-To: <20181009.142506.637283350958767455.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: VI1PR07CA0134.eurprd07.prod.outlook.com (2603:10a6:802:16::21) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1822; 6:GbTyVjVnmjwfZDVsEe3SsvZlomGrb+wLo7wN3M/LDAoFAhVL/f74xekbyiZnAmdxXuEhn2wTBoV1MLtHv3/7c5PTi1J4OrWyWXi+2lvd4dO+fwl8/6PcETa93oHyXkBCCWoiVPmZ+5zZnl1LKCNP5AslB0uk3eeCMOUPI6cPekaVTwv1Yc6iDKQpWWgZvsGf1CFXQ23PV5mCXGaW9WMWtmxVidLTB6+enUx9gtnA7NSyaH7seFd/pGdFxnZZETNh+FdIlUDuna20N42ePWVaAA2juUtT97NS3gNBk0/VTMEEz97FzzDLIPqTKbiG4JJYG3UwOqQBzAhuIKVIY+d8Tjdh6EXO37CHQCq8GUnF0kQP4AFCQZcF6ghlAFWLNPzXnop+dYe3TEW9wzkXOM/QNWHuHmruzqZuRlIW2JdSwdJeNHSLKqx4n21v8Wo9WDPZ7vSTSBLqizFptaEBIFcwWg==; 5:7WzIw/Xy2Ro/m7Ko+ICYaKmU+qc3dWCuKXOSVBMbxH6h0YyQdWgBtZ9rmh2dFhBkSyUOJcwV7ewLPggOZbPFqCOSXk9PY4/6mNhDL1TcDkjRHVKDv19nWpufgU8eEdBskmRV1VtdrXtB58aJpUtBZUwBWEqmwpdKvBQ0Jac9Fa8=; 7:TJXOH6lAkfZm3pKJqDDzjV+scfcr97vyiOtC4vKAJrqqFjbY612P1BqHCBkQK9WlITybx4h3GmWZN8lM1SsgqkjmcuX/slKR0NYQYV0ek+kxJuz74O0qHil5zjKmYZ2TeunO5PFEjZROHNUWEn33ky/AgFy81tA2VIFBMfcsiEwdqeAtjHE5aW7CuXvEry5RPIU97hbZ59nvrDEr+XM+tn3l9rirmCxcYYe96BFAvz+8nzbibJcPSZu0dh5PH8zU x-ms-office365-filtering-correlation-id: 728c5767-cd86-4410-ecb0-08d62df8c5a9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB1822; x-ms-traffictypediagnostic: VI1PR0701MB1822: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231355)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051); SRVR:VI1PR0701MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1822; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(136003)(396003)(39860400002)(199004)(189003)(252514010)(186003)(97736004)(52116002)(99286004)(256004)(102836004)(76176011)(386003)(6506007)(14444005)(66066001)(64126003)(65806001)(65956001)(446003)(71200400001)(71190400001)(11346002)(2900100001)(2616005)(486006)(476003)(36756003)(26005)(305945005)(7736002)(105586002)(85202003)(106356001)(31696002)(966005)(25786009)(229853002)(3260700006)(14454004)(99936001)(6916009)(8936002)(4326008)(86362001)(478600001)(5250100002)(6512007)(68736007)(6306002)(93886005)(316002)(66574009)(5660300001)(65826007)(6436002)(6486002)(81166006)(31686004)(54906003)(2906002)(3846002)(85182001)(53936002)(8676002)(58126008)(6246003)(81156014)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB1822; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6lQNmW4UaHCeb4Y8yksWFffZ/cEty23i1MuhU+hv4MpQwqWg9jixFSvgC+x2HllM4zaM/ZccGdu8S23Wjfmxslc7vXX2+UnqsVy9gLMP+EejA5uwA3mWkJFwPUj8O58rMmKGajEqeu3JQquo0+nToT/DCudTbp0pB0QNxEF9HVCzha2YYQe+fzypH6LMsdGoLZZVv7TCkTM0eNhE6S4FVIqZ8V/847dCWMSPkqQdmE7J3qlfE+F8ZncsMeM2W1keW6/mZsZm7+uLeoQT9T7qK+1P+OntTGxKCzIHuL4hSWw+RxlkorFLogX2wPVKXTodVbpk2qcYViTgnbrgtFC4/OomJZ9KKQPOGTtiuoxM5qw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080801030907060204000504" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 728c5767-cd86-4410-ecb0-08d62df8c5a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 15:06:22.9328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1822 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTYRTHed733escjd7WzINd0KEReck0dVikQh/2pVDwg2mpS19v6Wab ecPQnJZzlBKRF8yZmpFW1IxsYXnJCxqSZiLem1phok7LJLPLtkch6Nvv/5zz/59z4OGSgnmO HTdelsIqZNJEEc2jykKa0lyNr5vD3HubPMUFqgVKrNF8shI3XNsv1g5c5vhTktraH4TEqFPR kifrNVQgGco7Fs0mxqeyikPHI3lxQy8NRLIqKF2fO0HnoHFJIbLmAnMEKowtqBDxuAKmE0HX n480FqsI2sZqOFjUEKBtW7IyC4opJkE/PLDZdouAQu06gcU0AsN4JW1OppkTcHWxhTCzkHGC Wf1DytxEMioEuvUbyFzYyXhD7Uw3Bzf5wLeuXBKzL1Tef0+ZmWIcYepZnaWfz/hBftkKiadN ItDfe2UxWzP+MDTSamHE7IK13geWySRjC6OzWgLfKgTDwBsasw3MzfzmYBZB6ZdRC9swZyGv p9xyNTClCIwzVzZDw6F5smDT7AJ9w7MI8154p9UgbGi1grdFd01rc03iJAwUZ+P3QVNQg57c MpdOjW6a5dCxskEXI4/yf5bFrEag6fMrt1y9A3rKZin87g2VjQYSszPU3Zkn//cehdL1Nhqz A9zUGKwwe8F85zLC7Al1j37RVYhXj2yUrPJcUqyHhxuriI9SKuUyNxmbokOmb9f29Kf7czT3 OaAdMVwk2sb3aWwOE3CkqcqMpHbkaMqZftzQj+womVzGioR8m6YXYQJ+tDQjk1XIIxQXE1ll O9rNpUS2fPGpxlABEytNYc+zbDKr2KoSXGu7HBSs7k72Xc2vrjbmZTqlR2QtSOqX0ucW0nMX Gjwdg+kK+QH+V8nYbVlnkGD+dJSuKNY+YdF+mV/w3eFDim94+fUda/Xdkdsn9rkOe5WUrKh4 MXqXS06+kytEd6NwxLPGOSvmQmBUghCp0zpCqtRnppICdQHqjbT+Qfc949kjGwEiShknPXyQ VCilfwG8WKdzfgMAAA== Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:06:30 -0000 --------------ms080801030907060204000504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US OK, If the chairs are happy with that, I can update the document before=20 I store it as an official netmod document. regards Balazs On 2018. 10. 09. 14:25, Martin Bjorklund wrote: > Hi, > > Bal=C3=A1zs Lengyel wrote: >> Hello Martin, >> >> I agree that this document shall be about defining the file format, >> and server capabilities shall only be a use-case.) >> >> I already took out a lot of text, that explicitly recommended using >> instance data for documenting capabilities. Server capabilities are >> only mentioned in the introduction chapter. >> As you wrote: There is no _normative_=C2=A0 specification of how a ser= ver >> would document its capabilities, because this is >> what the WG requested, so I removed it. > Hmm. Ok, if this is what the WG wants, then it is fine to just have > server capabilities as an example use case. (I thought that the WG > wanted a normative description of server capabilities...) > >> I see that I forgot to change the title and the introduction can be >> reworded to make >> it more clear that documenting server capabilities is just a use-case.= >> (I still see it as the primary use-case for instance data.) > I think all text in 2 Introduction (except the last para) in this case > should be moved to section 2.1, and new text should be written in 2. > > (*if* there will be a separate doc for server capabilities, the text > in 2 should be moved to that doc instead.) > >> =C2=A0If I promise to change the title and clarify the introduction c= an you >> support adoption? > First of all I'd like to ensure that the WG in fact just wants to do > the file format. Since people have expressed support for adopting the > draft with the current title, I'm not so sure that this is the case. > > I think you should make those changes, and I support the adoption of > the modified document. I don't see any reason not to make these > chanegs before posting as a WG doc. > > > /martin > > > >> regards Balazs >> >> On 2018. 10. 09. 12:58, Martin Bjorklund wrote: >>> Hi, >>> >>> I still think that this draft should either be split into two, one fo= r >>> specifiying the generic file format (ok with examples), and one for >>> "Documenting Server Capabilities", or the document should just be >>> about the file format (+ *examples*). >>> >>> [The current document mixes the two; it's a bit as if we had "The >>> YANG language and a model for interfaces" as one doc...] >>> >>> It is clear that the document specifies a file format for YANG >>> instance data, which is good. But it is not clear if the document >>> intends to specify how a server should document its capabilities. >>> >>> The Introduction mainly talks about why it is important to document >>> server capabilities. But then AFAICT there is no normative >>> specification of how a server would document its capabilities. >>> >>> >>> /martin >>> >>> >>> Lou Berger wrote: >>>> All, >>>> >>>> This is start of a two week poll on making >>>> draft-lengyel-netmod-yang-instance-data-04 a working group >>>> document. Please send email to the list indicating "yes/support" or >>>> "no/do not support". If indicating no, please state your reservatio= ns >>>> with the document. If yes, please also feel free to provide comment= s >>>> you'd like to see addressed once the document is a WG document. >>>> >>>> The poll ends Oct 22. >>>> >>>> Thanks, >>>> >>>> Lou (and co-chairs) >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> --=20 >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> --=20 Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------ms080801030907060204000504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAwOTE1MDYxOVow LwYJKoZIhvcNAQkEMSIEIA1jq8kARUxi0NYaX5RzAvMdtS4b0l3NWo9fe5Ka418QMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAMdW7i/HlIoGLyY19b6jByRH0bvF9z5/zqeYGuNQF7M7IBMl n1UpBmdzsek92RGeadjA1clCWhWS3xTchZ6ixi0aVRF+iBal9OKmYVw7bRxtiywMY7r3+S1F a58iYlnvIdDUMnvfpxAz6Oio5SsFhxtg5GXYpfHNKDL0EW/I6mH9KEJbRFAT0oDlQ8w1YaWQ 6L7dob03xEJh9DIbAJTpb1JxUjgaVBoz+Xgl1PGix/KOdsaZrsY+N8Xxhd5AhLkzT8nqqor6 SKl+5zw/cVDGkrfmUWnXFqtHmkAcc2e5nSVc1dE6oeJsKGYj+UVwde7YHHjz4SWZ7vVgPqJR i+4gYakAAAAAAAA= --------------ms080801030907060204000504-- From nobody Tue Oct 9 08:23:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ECC13133D; Tue, 9 Oct 2018 08:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.955 X-Spam-Level: X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 ipxRSollIoCn; Tue, 9 Oct 2018 08:23:44 -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 60E26131338; Tue, 9 Oct 2018 08:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9807; q=dns/txt; s=iport; t=1539098623; x=1540308223; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+cyQxDETG2RCydWPMnQpaeAzNMZ5jtHlBNh4WajO6ew=; b=PolHXvNza/3zCdCoGjB+mJ22L0MtWEPzVI7N4cNEkds+b/RhUBJcZOc9 dTudEPnPvJfW32/AvQCzke3qq3e4fYGwFjCYXNO5US7XXPsaFtm54iucf 3cHKQRg9ZarOLuqxpfr4Y859ZsOPx5IZFmQ4Aj5RaUdJggNrVndXOGaS9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAABHx7xb/xbLJq0YAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoJqfyiDdYh0jWORL4VUgWYNGAEKhANGAoRaOBYBAwE?= =?us-ascii?q?BAgEBAm0cDIU6AQEBAwEBIUQHCxALGCoCAicwBgEMBgIBAReDBgGCAQ+Hcpx?= =?us-ascii?q?3gS4fhFiFHgWLUIFBP4E5gmuDGwEBgS4BEgEHAoMXglcClBiJXgmJJ4cdBhe?= =?us-ascii?q?BToRngmiGYoJejGuGLoFZISc9cTMaCBsVGiGCbIsXhT8+MIoUgj4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208,217";a="7112902" 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; 09 Oct 2018 15:23:40 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w99FNe2b012732; Tue, 9 Oct 2018 15:23:40 GMT To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Martin Bjorklund , "lberger@labn.net" Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> From: Robert Wilton Message-ID: Date: Tue, 9 Oct 2018 16:23:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> Content-Type: multipart/alternative; boundary="------------36F44BB1CAAFD6DD6A86A673" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:23:46 -0000 This is a multi-part message in MIME format. --------------36F44BB1CAAFD6DD6A86A673 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I would expect that there are many other alternative uses of YANG instance data. Some possible alternatives that I can think of: - Storing the configuration of a device at some point in time to a file, e.g. for archive or audit purposes. - Storing diagnostics data, if the format of the data was defined as YANG data models.  Here I could imagine the data potentially being stored in a compressed tar file that could be taken off the device. - Allowing YANG instance data to potentially be carried within other IPC message formats. - Perhaps file based default instance data used as part of a templating solution. - File based factory defaults. Thanks, Rob On 09/10/2018 13:15, Balázs Lengyel wrote: > Hello Martin, > > I agree that this document shall be about defining the file format, > and server capabilities shall only be a use-case.) > > I already took out a lot of text, that explicitly recommended using > instance data for documenting capabilities. Server capabilities are > only mentioned in the introduction chapter. > As you wrote: There is no _normative_  specification of how a server > would document its capabilities, because this is > what the WG requested, so I removed it. > > I see that I forgot to change the title and the introduction can be > reworded to make > it more clear that documenting server capabilities is just a use-case. > (I still see it as the primary use-case for instance data.) > >  If I promise to change the title and clarify the introduction can you > support adoption? > > regards Balazs > > On 2018. 10. 09. 12:58, Martin Bjorklund wrote: >> Hi, >> >> I still think that this draft should either be split into two, one for >> specifiying the generic file format (ok with examples), and one for >> "Documenting Server Capabilities", or the document should just be >> about the file format (+ *examples*). >> >> [The current document mixes the two; it's a bit as if we had "The >> YANG language and a model for interfaces" as one doc...] >> >> It is clear that the document specifies a file format for YANG >> instance data, which is good.  But it is not clear if the document >> intends to specify how a server should document its capabilities. >> >> The Introduction mainly talks about why it is important to document >> server capabilities.  But then AFAICT there is no normative >> specification of how a server would document its capabilities. >> >> >> /martin >> >> >> Lou Berger wrote: >>> All, >>> >>> This is start of a two week poll on making >>> draft-lengyel-netmod-yang-instance-data-04 a working group >>> document. Please send email to the list indicating "yes/support" or >>> "no/do not support".  If indicating no, please state your reservations >>> with the document.  If yes, please also feel free to provide comments >>> you'd like to see addressed once the document is a WG document. >>> >>> The poll ends Oct 22. >>> >>> Thanks, >>> >>> Lou (and co-chairs) >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --------------36F44BB1CAAFD6DD6A86A673 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I would expect that there are many other alternative uses of YANG instance data.

Some possible alternatives that I can think of:
- Storing the configuration of a device at some point in time to a file, e.g. for archive or audit purposes.
- Storing diagnostics data, if the format of the data was defined as YANG data models.  Here I could imagine the data potentially being stored in a compressed tar file that could be taken off the device.
- Allowing YANG instance data to potentially be carried within other IPC message formats.
- Perhaps file based default instance data used as part of a templating solution.
- File based factory defaults.

Thanks,
Rob


On 09/10/2018 13:15, Balázs Lengyel wrote:
Hello Martin,

I agree that this document shall be about defining the file format,
and server capabilities shall only be a use-case.)

I already took out a lot of text, that explicitly recommended using
instance data for documenting capabilities. Server capabilities are only mentioned in the introduction chapter.
As you wrote: There is no _normative_  specification of how a server would document its capabilities, because this is
what the WG requested, so I removed it.

I see that I forgot to change the title and the introduction can be reworded to make
it more clear that documenting server capabilities is just a use-case.
(I still see it as the primary use-case for instance data.)

 If I promise to change the title and clarify the introduction can you support adoption?

regards Balazs

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:
Hi,

I still think that this draft should either be split into two, one for
specifiying the generic file format (ok with examples), and one for
"Documenting Server Capabilities", or the document should just be
about the file format (+ *examples*).

[The current document mixes the two; it's a bit as if we had "The
YANG language and a model for interfaces" as one doc...]

It is clear that the document specifies a file format for YANG
instance data, which is good.  But it is not clear if the document
intends to specify how a server should document its capabilities.

The Introduction mainly talks about why it is important to document
server capabilities.  But then AFAICT there is no normative
specification of how a server would document its capabilities.


/martin


Lou Berger <lberger@labn.net> wrote:
All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

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

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



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

--------------36F44BB1CAAFD6DD6A86A673-- From nobody Tue Oct 9 09:26:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EAD13135B; Tue, 9 Oct 2018 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 XvsJX88S_16d; Tue, 9 Oct 2018 09:26:37 -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 92BB0131343; Tue, 9 Oct 2018 09:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1106; q=dns/txt; s=iport; t=1539102397; x=1540311997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7vUlYY4nl/q2sdsQz1cIl0/ekn5GsAAmGqTgVxqs7zU=; b=hStwjJtS1Lws2DCA+oQmmctfoQzu0jxFYhnj3GgcvfDZFb5hOpuVBez3 I2P+xqygDYiY1st8TWT+69p3PFEVoNVcK8ZW34JWhuiecsIn90/bmovUr CUVbsvLsbujfzAnP7x3pq+wSnuICSEnxPZRTFyOk1yRcr9ZaF8tzKNkCg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAv1rxb/4MNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCBWZ/KAqDa4gVjDWBaJcUFIFmCwEBGAsJg3p?= =?us-ascii?q?GAheEIyE0DQ0BAwEBAgEBAm0cDIU6AgEDAQEhEToLEAIBCA4MAiYCAgIlCxU?= =?us-ascii?q?QAgQBDQWDIQGCAQ+kaIEuhHeFHwWBC4ouF4FBP4E5DBOCTIMbAQGBLgESAR8?= =?us-ascii?q?XgmoxgiYClBiJXgkCkEgXgU6EZ4lKlVACERSBJR04ZHFwFTsqAYJBixeFPm+?= =?us-ascii?q?BFoh+gR8BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,360,1534809600"; d="scan'208";a="182922665" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 16:26:36 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w99GQa4I021221 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Oct 2018 16:26:36 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Oct 2018 11:26:35 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Tue, 9 Oct 2018 11:26:35 -0500 From: "Reshad Rahman (rrahman)" To: Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG adoption poll Thread-Index: AQHUXvuF5QLcZLxZykGwV+cBylvTrKUXLH2A Date: Tue, 9 Oct 2018 16:26:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.212] Content-Type: text/plain; charset="utf-8" Content-ID: <564E1A928A4E4D4FA7367F6E628D952B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:26:39 -0000 U3VwcG9ydC4NCg0K77u/T24gMjAxOC0xMC0wOCwgNzozOSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgTG91IEJlcmdlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVy Z2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KICAgIEFsbCwNCiAgICANCiAgICBUaGlzIGlzIHN0YXJ0 IG9mIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCiAgICBkcmFmdC1sZW5neWVsLW5ldG1vZC15 YW5nLWluc3RhbmNlLWRhdGEtMDQgYSB3b3JraW5nIGdyb3VwDQogICAgZG9jdW1lbnQuIFBsZWFz ZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9zdXBwb3J0IiBvcg0KICAg ICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91 ciByZXNlcnZhdGlvbnMNCiAgICB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFs c28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMNCiAgICB5b3UnZCBsaWtlIHRvIHNlZSBh ZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCiAgICANCiAgICBU aGUgcG9sbCBlbmRzIE9jdCAyMi4NCiAgICANCiAgICBUaGFua3MsDQogICAgDQogICAgTG91IChh bmQgY28tY2hhaXJzKQ0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQog ICAgDQoNCg== From nobody Tue Oct 9 09:36:59 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DEB131343; Tue, 9 Oct 2018 09:36:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-netmod-schema-mount@ietf.org, Joel Jaeggli , Lou Berger , Kent Watsen , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2018 09:36:43 -0700 Archived-At: Subject: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:36:44 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-schema-mount-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Whenever we introduce a new namespace "sub-hierarchy" there is some level of risk about surpirses with respect to the security properties of the combined system. I appreciate that the mounted schemas are "jailed" into their own subtree except for the specific exceptions for XPath access, which helps a lot. But there may still be potential for surprise with respect to, e.g., access control on mounted schemas, if an administrator previously assumed that such controls would only be needed at the top-level. The document itself doesn't give me a great picture of to what extent these risks and the possible consequences of the new nested structure have been considered; I'd be happy to hear if they've been thought about a lot already and the conclusion was that the situation is so boring that nothing needs to be mentioned in the document. Section 3.3 If multiple mount points with the same name are defined in the same module - either directly or because the mount point is defined in a grouping and the grouping is used multiple times - then the corresponding "mount-point" entry applies equally to all such mount points. Does this mean that the multiple mount points must serve the same data/contents, or just that they must use the same schema? (Is this related to "inline" vs. "shared-schema"?) Section 3.4 So this means that there can be multiple ietf-yang-schema-mount:schema-mounts:mount-point nodes at different locations in the hierarchy? When I was first reading the document, the design seemed fairly clean with just a single list of mount-points at the "top-level" that tracks everything, but this kind of recursion seems like it would make implementation potentially quite complex. What kind of implementation experience do we have that can replace my half-informed suppositions about complexity? Section 4 Therefore, schema mount also allows for such references. For every mount point in the "shared-schema" case, it is possible to specify a leaf-list named "parent-reference" that contains zero or more XPath 1.0 expressions. [...] editorial: """the "shared-schema" case""" reads oddly to me; it might be clearer to refer to schemas mounted using "shared-schema" instead. As in, """For every mount point under "shared-schema", [...]""" Can we get a reference added for XPath? It's still a little unclear to me exactly how a node in the mounted tree constructs an XPath expression to refer to the parent-reference nodes, but I did not read very far down the reference chain and maybe this is going to be clear to a practitioner without any more text in the document. Basically, do I need to know where I am mounted in order to construct references to nodes in the parent? Section 7 NACM "can be used" to control access to mounted nodes. Is there a risk that administrators will be "unpleasantly surprised" by mounted nodes by default not receiving access control, in cases when access control is already configured at the top level? Section 9 Should the top-level module description be using the RFC 8174 boilerplate instead of thet 2119 boilerplate? Should the requirement for servers that mount any schema to also mount ietf-yang-library under the mountpoint be mentioned somewhere other than the description for the 'inline' and 'shared-schema' containers (i.e., in the discussion text)? Section 11 We should probably also have some bland statement about how "the security considerations for mounted schemas continue to apply to the nodes in the mounted tree". From nobody Tue Oct 9 09:42:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBEE131367; Tue, 9 Oct 2018 09:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-fUgkf6U3Lo; Tue, 9 Oct 2018 09:42:15 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 1CD3713135B; Tue, 9 Oct 2018 09:42:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.230.22.90; From: "Susan Hares" To: "'Lou Berger'" , "'NetMod WG'" Cc: "'NetMod WG Chairs'" References: In-Reply-To: Date: Tue, 9 Oct 2018 12:42:10 -0400 Message-ID: <019b01d45fef$0696de00$13c49a00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD0oMzPOk/zZEUFMYtbUXhnC0NNIabWnGfg Content-Language: en-us X-Antivirus: AVG (VPS 181009-4, 10/09/2018), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] WG adoption poll X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:42:17 -0000 Yes - support for this document. Susan Hares -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, October 8, 2018 7:39 AM To: NetMod WG Cc: NetMod WG Chairs Subject: [netmod] WG adoption poll All, This is start of a two week poll on making draft-lengyel-netmod-yang-instance-data-04 a working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. The poll ends Oct 22. Thanks, Lou (and co-chairs) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Oct 9 09:53:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE48D131372 for ; Tue, 9 Oct 2018 09:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ5GVui6xL59 for ; Tue, 9 Oct 2018 09:52:58 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3E517131332 for ; Tue, 9 Oct 2018 09:52:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.90; From: "Susan Hares" To: "'NETMOD WG'" , "'Kent Watsen'" References: In-Reply-To: Date: Tue, 9 Oct 2018 12:52:54 -0400 Message-ID: <01c401d45ff0$86682930$93387b90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01D45FCE.FF57E8C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZONRQ72AyjTA3JbPTW+QTuRVB8AIG1qy8pH04e/A= Content-Language: en-us X-Antivirus: AVG (VPS 181009-4, 10/09/2018), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 16:53:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C5_01D45FCE.FF57E8C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Support =E2=80=93=20 I=E2=80=99m not sure I saw this on the list.=20 =20 Cheerily, Sue Hares=20 =20 -------- On Mon, Oct 1, 2018 at 2:48 PM Kent Watsen wrote: The IETF 102 in-room poll should really good support to adopt this draft, and no objections. This email starts an adoption poll for: https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00 Please indicate your support or objection to the adoption poll.=20 If objecting, please state your reasons on this thread. Kent (and Lou and Joel) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_01C5_01D45FCE.FF57E8C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Support =E2=80=93

I=E2=80=99m not sure I saw this on the list. =

 

Cheerily, Sue Hares

 

--------

On Mon, = Oct 1, 2018 at 2:48 PM Kent Watsen <kwatsen@juniper.net> = wrote:

The IETF = 102 in-room poll should really good support to adopt
this draft, and = no objections.

This email starts an adoption poll = for:

  https://tools.ietf.org/html/draft-clemm-netmod-nmda-dif= f-00

Please indicate your support or objection to the = adoption poll.
If objecting, please state your reasons on this = thread.

Kent (and Lou and = Joel)

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

------=_NextPart_000_01C5_01D45FCE.FF57E8C0-- From nobody Tue Oct 9 10:07:17 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5113136B; Tue, 9 Oct 2018 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDHOS1vABNo9; Tue, 9 Oct 2018 10:07:13 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D34B13135D; Tue, 9 Oct 2018 10:07:13 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w99H3wnJ031273; Tue, 9 Oct 2018 10:07:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=DAf1LHmfTCy0Q2BrQYQcNKAksH6BTpMkSyAIWODSFWo=; b=J5fpjd8T9KWZvnCfPPWhEtKUZqGwaE1XGyx7n49s/5E1CBRPs3vimXdV7b6I9w94D0Fp m3/fO8eUWPMGstqH34U9ibZzQ6ijNzF830kcUppK5YcxqevE39KRiwM5L+KZ5lqekWhA 0XFh7sZfBPRxBBkCqzQqvdKhYRvKMOhT50qKizTitB2etIx2e+LQ8Qh47wUog5rbfNFe 7MIdVHzm3EdEHMZ99zuO0n9fqiAFeKzvM/DF5f7cGa58n9jYmM6hF3hJ9SUkJIoLiuxl J4jWb6d3ns9uUcCE+lwjfzqd2ghBH6KQMc4RV64ps6eTzb1FVDCeRJP8S7S3E5eqCuWw 9Q== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) by mx0b-00273201.pphosted.com with ESMTP id 2n0s0pgxa7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 Oct 2018 10:07:09 -0700 Received: from BYAPR05MB4664.namprd05.prod.outlook.com (52.135.233.78) by BYAPR05MB3944.namprd05.prod.outlook.com (52.135.195.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Tue, 9 Oct 2018 17:07:06 +0000 Received: from BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f]) by BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f%3]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 17:07:06 +0000 From: Kent Watsen To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Martin Bjorklund CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll - instance-data Thread-Index: AQHUX8nMLYBabqUYMUGHSNnOTu5UwaUW1qUAgAAtDgD//97AgA== Date: Tue, 9 Oct 2018 17:07:06 +0000 Message-ID: <652D49CE-6469-412F-B708-D8496DFC0F16@juniper.net> References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> <20181009.142506.637283350958767455.mbj@tail-f.com> <9e389747-74ed-0f62-24ce-813ce3cdc870@ericsson.com> In-Reply-To: <9e389747-74ed-0f62-24ce-813ce3cdc870@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB3944; 6:vChS/Cb0HnQgKjHLxDz488ip134uQM0Ji+EicGqLU5VBrdroICN4DNFOWNa4/0kHFZhYjW8Ngnyvixfm8Kt7FoistKuZAYzbAfM/OgLtISCuwneMDcWtLWJvCF7bGP4nc5Yfl6F3eyJmriuZ9d5/TWkNAU85H+Ufk/gXzPElhZwekmakJC9qIBJFprmV1ZtHSX0QueLieIxshkUAp320JIv6rdy9iiuv5WZiBhq058hnbtIqL4i0gj/mXLzPt+CpZMmrIRY7FtpPCEGC1jvQshpXKe7hrUVz4PAl7ep/N25mSN8oagzoThpLYPyykvo5NEPCXOm2IxQ2p3DIzzHDcVlZ7rORTSxBYtCE5O9xq6ZhQOH3QXhguq3/o0benXgFerQXTXX8PhrGWws8j3QcBqWFk1WLJ9+YyeLJxm1JA0A6uAdsct4dGT17v1U0YKoVSLvyRUv2oQon622HmnsEgQ==; 5:MFd4K3GAIQkm5XBusAjAcEtrk6hzA7rmOoVRZ8GJhSmgIBGXQmHpWG/7aNBQUGSI/1xT797/4+y+Or1Rp7dstBZNwEYPq0xDO6LUGSYWa6BNGsPRB/X7hVJS/4kE9zVpPnIPWHsrN0dPvNaM71PUNx68PgFqDs5Qjz2U0OehQao=; 7:guVHgQ13ntlProaDTRDoXalfhaTN5FuZmCW9owHNeP+dsZIf8tJcWcMNe88YJH0jXHbGyJNgZidWfGV2muAts0+N0SXIT6BJxzEMgVlKnQrgx35GuMGGGch3wztkQf7AXC8Kl9W6UbP5kvN1MpgPYKTEhfMy/rIoZwl4AO/j5SoaYgf2lyqNed2X8GpSO9XoWKVcC7Ysezarf+X42Fb/rBUfA8wzV3JgcRF9gqZhqNly67b/2Oa75VWms/+ZLObI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ff6fee22-0f89-4a99-dffa-08d62e09a43c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB3944; x-ms-traffictypediagnostic: BYAPR05MB3944: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991055); SRVR:BYAPR05MB3944; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB3944; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(39860400002)(136003)(376002)(199004)(189003)(13464003)(252514010)(102836004)(6486002)(4326008)(8936002)(66574009)(81156014)(33656002)(229853002)(53546011)(6506007)(6512007)(6306002)(11346002)(68736007)(5250100002)(446003)(6436002)(26005)(2900100001)(53936002)(36756003)(66066001)(8676002)(93886005)(83716004)(2906002)(99286004)(81166006)(71190400001)(71200400001)(76176011)(86362001)(3846002)(5660300001)(6116002)(54906003)(110136005)(58126008)(105586002)(186003)(106356001)(6246003)(25786009)(486006)(14444005)(82746002)(97736004)(966005)(478600001)(256004)(14454004)(2616005)(7736002)(476003)(316002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB3944; H:BYAPR05MB4664.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: xeVENQRRGiJaZAnC3KmeHd6dnOBTsXByxjoKZ9xS8GPh9msKojj0t+2ObEXnZfe3UALnYs3w/ZTJNxxSgCZ/vUmudI9nJcQ/zDnv7f7DmCrn748kNa+ARPGs/CqSPqoaQC4aP3mQ2/G8EODBhZ1fZCdjSpTbI34z/BSM+wwjgm+S2mmOLNgwSSppfHs/6HTrdRzMljcGUaVENKHJ8iHN+Fm2iVujAxP6RglKE41B3vVevlknFdVM8xc1PjcHNNZyYBhGdA3FEfj/cxbj2XbNeReFtQMcgWLHkadXIqwqSYfqgqmiWw4/mUdO/eph2DHGOHfGggLTawcv3Z/dqAUnAytSbKiQPrRCM74Vcl6tDEc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3A32D1CF90289A4FB35DC19CBB5F932F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ff6fee22-0f89-4a99-dffa-08d62e09a43c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 17:07:06.2658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB3944 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-09_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810090165 Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:07:16 -0000 DQpBcyBjby1jaGFpciwgSSBoYXZlIHR3byBtaW5kczoNCg0KICAxKSByZXF1ZXN0cyBhIGZpeCBh bmQgcmVkbyB0aGUgYWRvcHRpb24gcG9sbA0KICAyKSByZWFsaXplIHRoYXQgaXQncyBhIGxpdmlu ZyBkb2MgYW5kIHJlZ2FyZGxlc3MNCiAgICAgaG93IGl0IGJlZ2lucywgdGhlIFdHIGNhbiBzb3J0 IGl0IG91dCBpbiB0aW1lLg0KICAgICBpLmUuLCB3ZSdyZSBhZG9wdGluZyB0byB3b3JrIG9uIHRo ZSBwcm9ibGVtLA0KICAgICBub3QgbmVjZXNzYXJpbHkgdGhlIHNwZWNpZmljIHNvbHV0aW9uLg0K DQpXaGlsZSAoMSkgc2VlbXMgbW9yZSBwcm9wZXIsIGdpdmVuIHRoZSB0aW1pbmcgb2YgDQp0aGlu Z3MsIEknbSB3aWxsaW5nIHRvIGdvIGZvciAoMikuICAgVG8gdGhpcyBleHRlbnQsDQp0aGUgY29t bWVudHMgYmVpbmcgbWFkZSBub3cgYmUgdGhvdWdodCB0byBjYXJyeQ0KdGhlIHNhbWUgd2VpZ2h0 IGFzIExhc3QgQ2FsbCBjb21tZW50cy4gIFRoZSBjaGFpcnMNCndpbGwgZGlzY3VzcyB0aGlzIGFn YWluIHdoZW4gbWFraW5nIGEgZGV0ZXJtaW5hdGlvbg0Kb24gdGhlIGFkb3B0aW9uIHBvbGwuDQoN CkFzIGNvbnRyaWJ1dG9yLCBjYW4gd2UgcGxlYXNlIG5vdCBjYWxsIHRoaXMgIllBTkcNCmluc3Rh bmNlIGRhdGEiPyAgLSB0aGF0IG1lYW5zIHNvbWV0aGluZyBlbHNlIHRvIA0KbWUuICBUaGlzIHNl ZW1zIHRvIGJlIG1vcmUgYWJvdXQgY2FwdHVyaW5nIGRhdGENCmFib3V0IGEgc2VydmVyIGluc3Rh bmNlcy4gIFNvIG1heWJlICJZQU5HLWJhc2VkDQpTZXJ2ZXIgSW5zdGFuY2UgRGF0YSI/ICAob3Bl biB0byBzdWdnZXN0aW9ucyEpDQoNCktlbnQNCg0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+DQpEYXRlOiBU dWVzZGF5LCBPY3RvYmVyIDksIDIwMTggYXQgMTE6MDYgQU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5k IDxtYmpAdGFpbC1mLmNvbT4NCkNjOiAibmV0bW9kLWNoYWlyc0BpZXRmLm9yZyIgPG5ldG1vZC1j aGFpcnNAaWV0Zi5vcmc+LCAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgLSBpbnN0YW5jZS1kYXRhDQoNCk9L LCBJZiB0aGUgY2hhaXJzIGFyZSBoYXBweSB3aXRoIHRoYXQsIEkgY2FuIHVwZGF0ZSB0aGUgZG9j dW1lbnQgYmVmb3JlIA0KSSBzdG9yZSBpdCBhcyBhbiBvZmZpY2lhbCBuZXRtb2QgZG9jdW1lbnQu DQoNCnJlZ2FyZHMgQmFsYXpzDQoNCk9uIDIwMTguIDEwLiAwOS4gMTQ6MjUsIE1hcnRpbiBCam9y a2x1bmQgd3JvdGU6DQo+IEhpLA0KPg0KPiBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVs QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiBIZWxsbyBNYXJ0aW4sDQo+Pg0KPj4gSSBhZ3JlZSB0 aGF0IHRoaXMgZG9jdW1lbnQgc2hhbGwgYmUgYWJvdXQgZGVmaW5pbmcgdGhlIGZpbGUgZm9ybWF0 LA0KPj4gYW5kIHNlcnZlciBjYXBhYmlsaXRpZXMgc2hhbGwgb25seSBiZSBhIHVzZS1jYXNlLikN Cj4+DQo+PiBJIGFscmVhZHkgdG9vayBvdXQgYSBsb3Qgb2YgdGV4dCwgdGhhdCBleHBsaWNpdGx5 IHJlY29tbWVuZGVkIHVzaW5nDQo+PiBpbnN0YW5jZSBkYXRhIGZvciBkb2N1bWVudGluZyBjYXBh YmlsaXRpZXMuIFNlcnZlciBjYXBhYmlsaXRpZXMgYXJlDQo+PiBvbmx5IG1lbnRpb25lZCBpbiB0 aGUgaW50cm9kdWN0aW9uIGNoYXB0ZXIuDQo+PiBBcyB5b3Ugd3JvdGU6IFRoZXJlIGlzIG5vIF9u b3JtYXRpdmVfICBzcGVjaWZpY2F0aW9uIG9mIGhvdyBhIHNlcnZlcg0KPj4gd291bGQgZG9jdW1l bnQgaXRzIGNhcGFiaWxpdGllcywgYmVjYXVzZSB0aGlzIGlzDQo+PiB3aGF0IHRoZSBXRyByZXF1 ZXN0ZWQsIHNvIEkgcmVtb3ZlZCBpdC4NCj4gSG1tLiAgT2ssIGlmIHRoaXMgaXMgd2hhdCB0aGUg V0cgd2FudHMsIHRoZW4gaXQgaXMgZmluZSB0byBqdXN0IGhhdmUNCj4gc2VydmVyIGNhcGFiaWxp dGllcyBhcyBhbiBleGFtcGxlIHVzZSBjYXNlLiAgKEkgdGhvdWdodCB0aGF0IHRoZSBXRw0KPiB3 YW50ZWQgYSBub3JtYXRpdmUgZGVzY3JpcHRpb24gb2Ygc2VydmVyIGNhcGFiaWxpdGllcy4uLikN Cj4NCj4+IEkgc2VlIHRoYXQgSSBmb3Jnb3QgdG8gY2hhbmdlIHRoZSB0aXRsZSBhbmQgdGhlIGlu dHJvZHVjdGlvbiBjYW4gYmUNCj4+IHJld29yZGVkIHRvIG1ha2UNCj4+IGl0IG1vcmUgY2xlYXIg dGhhdCBkb2N1bWVudGluZyBzZXJ2ZXIgY2FwYWJpbGl0aWVzIGlzIGp1c3QgYSB1c2UtY2FzZS4N Cj4+IChJIHN0aWxsIHNlZSBpdCBhcyB0aGUgcHJpbWFyeSB1c2UtY2FzZSBmb3IgaW5zdGFuY2Ug ZGF0YS4pDQo+IEkgdGhpbmsgYWxsIHRleHQgaW4gMiBJbnRyb2R1Y3Rpb24gKGV4Y2VwdCB0aGUg bGFzdCBwYXJhKSBpbiB0aGlzIGNhc2UNCj4gc2hvdWxkIGJlIG1vdmVkIHRvIHNlY3Rpb24gMi4x LCBhbmQgbmV3IHRleHQgc2hvdWxkIGJlIHdyaXR0ZW4gaW4gMi4NCj4NCj4gKCppZiogdGhlcmUg d2lsbCBiZSBhIHNlcGFyYXRlIGRvYyBmb3Igc2VydmVyIGNhcGFiaWxpdGllcywgdGhlIHRleHQN Cj4gaW4gMiBzaG91bGQgYmUgbW92ZWQgdG8gdGhhdCBkb2MgaW5zdGVhZC4pDQo+DQo+PiAgIElm IEkgcHJvbWlzZSB0byBjaGFuZ2UgdGhlIHRpdGxlIGFuZCBjbGFyaWZ5IHRoZSBpbnRyb2R1Y3Rp b24gY2FuIHlvdQ0KPj4gc3VwcG9ydCBhZG9wdGlvbj8NCj4gRmlyc3Qgb2YgYWxsIEknZCBsaWtl IHRvIGVuc3VyZSB0aGF0IHRoZSBXRyBpbiBmYWN0IGp1c3Qgd2FudHMgdG8gZG8NCj4gdGhlIGZp bGUgZm9ybWF0LiAgU2luY2UgcGVvcGxlIGhhdmUgZXhwcmVzc2VkIHN1cHBvcnQgZm9yIGFkb3B0 aW5nIHRoZQ0KPiBkcmFmdCB3aXRoIHRoZSBjdXJyZW50IHRpdGxlLCBJJ20gbm90IHNvIHN1cmUg dGhhdCB0aGlzIGlzIHRoZSBjYXNlLg0KPg0KPiBJIHRoaW5rIHlvdSBzaG91bGQgbWFrZSB0aG9z ZSBjaGFuZ2VzLCBhbmQgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZg0KPiB0aGUgbW9kaWZpZWQg ZG9jdW1lbnQuICBJIGRvbid0IHNlZSBhbnkgcmVhc29uIG5vdCB0byBtYWtlIHRoZXNlDQo+IGNo YW5lZ3MgYmVmb3JlIHBvc3RpbmcgYXMgYSBXRyBkb2MuDQo+DQo+DQo+IC9tYXJ0aW4NCj4NCj4N Cj4NCj4+IHJlZ2FyZHMgQmFsYXpzDQo+Pg0KPj4gT24gMjAxOC4gMTAuIDA5LiAxMjo1OCwgTWFy dGluIEJqb3JrbHVuZCB3cm90ZToNCj4+PiBIaSwNCj4+Pg0KPj4+IEkgc3RpbGwgdGhpbmsgdGhh dCB0aGlzIGRyYWZ0IHNob3VsZCBlaXRoZXIgYmUgc3BsaXQgaW50byB0d28sIG9uZSBmb3INCj4+ PiBzcGVjaWZpeWluZyB0aGUgZ2VuZXJpYyBmaWxlIGZvcm1hdCAob2sgd2l0aCBleGFtcGxlcyks IGFuZCBvbmUgZm9yDQo+Pj4gIkRvY3VtZW50aW5nIFNlcnZlciBDYXBhYmlsaXRpZXMiLCBvciB0 aGUgZG9jdW1lbnQgc2hvdWxkIGp1c3QgYmUNCj4+PiBhYm91dCB0aGUgZmlsZSBmb3JtYXQgKCsg KmV4YW1wbGVzKikuDQo+Pj4NCj4+PiBbVGhlIGN1cnJlbnQgZG9jdW1lbnQgbWl4ZXMgdGhlIHR3 bzsgaXQncyBhIGJpdCBhcyBpZiB3ZSBoYWQgIlRoZQ0KPj4+IFlBTkcgbGFuZ3VhZ2UgYW5kIGEg bW9kZWwgZm9yIGludGVyZmFjZXMiIGFzIG9uZSBkb2MuLi5dDQo+Pj4NCj4+PiBJdCBpcyBjbGVh ciB0aGF0IHRoZSBkb2N1bWVudCBzcGVjaWZpZXMgYSBmaWxlIGZvcm1hdCBmb3IgWUFORw0KPj4+ IGluc3RhbmNlIGRhdGEsIHdoaWNoIGlzIGdvb2QuICBCdXQgaXQgaXMgbm90IGNsZWFyIGlmIHRo ZSBkb2N1bWVudA0KPj4+IGludGVuZHMgdG8gc3BlY2lmeSBob3cgYSBzZXJ2ZXIgc2hvdWxkIGRv Y3VtZW50IGl0cyBjYXBhYmlsaXRpZXMuDQo+Pj4NCj4+PiBUaGUgSW50cm9kdWN0aW9uIG1haW5s eSB0YWxrcyBhYm91dCB3aHkgaXQgaXMgaW1wb3J0YW50IHRvIGRvY3VtZW50DQo+Pj4gc2VydmVy IGNhcGFiaWxpdGllcy4gIEJ1dCB0aGVuIEFGQUlDVCB0aGVyZSBpcyBubyBub3JtYXRpdmUNCj4+ PiBzcGVjaWZpY2F0aW9uIG9mIGhvdyBhIHNlcnZlciB3b3VsZCBkb2N1bWVudCBpdHMgY2FwYWJp bGl0aWVzLg0KPj4+DQo+Pj4NCj4+PiAvbWFydGluDQo+Pj4NCj4+Pg0KPj4+IExvdSBCZXJnZXIg PGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+PiBBbGwsDQo+Pj4+DQo+Pj4+IFRoaXMgaXMg c3RhcnQgb2YgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZw0KPj4+PiBkcmFmdC1sZW5neWVsLW5l dG1vZC15YW5nLWluc3RhbmNlLWRhdGEtMDQgYSB3b3JraW5nIGdyb3VwDQo+Pj4+IGRvY3VtZW50 LiBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIg b3INCj4+Pj4gIm5vL2RvIG5vdCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBz dGF0ZSB5b3VyIHJlc2VydmF0aW9ucw0KPj4+PiB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywg cGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMNCj4+Pj4geW91J2QgbGlr ZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQo+ Pj4+DQo+Pj4+IFRoZSBwb2xsIGVuZHMgT2N0IDIyLg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+ DQo+Pj4+IExvdSAoYW5kIGNvLWNoYWlycykNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K Pj4+DQo+PiAtLSANCj4+IEJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBFcmlj c3NvbiBIdW5nYXJ5IEx0ZC4NCj4+IFNlbmlvciBTcGVjaWFsaXN0DQo+PiBNb2JpbGU6ICszNi03 MC0zMzAtNzkwOSBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+Pg0KPj4NCi0t IA0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkg THRkLg0KU2VuaW9yIFNwZWNpYWxpc3QNCk1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAg ICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQoNCg0KDQo= From nobody Tue Oct 9 10:17:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829B913136C for ; Tue, 9 Oct 2018 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2fHCTpo9pRZ for ; Tue, 9 Oct 2018 10:17:19 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A35E13136B for ; Tue, 9 Oct 2018 10:17:19 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w99HG4wB004740; Tue, 9 Oct 2018 10:17:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=r7oZ9WVnLiJ5953O6bT2CZ6DbtcPaOf7DK+ThMdgqbg=; b=euaXydvOhpWx0ffCF9dda0GYq2Y2/BpKphvWupQfWuubKfz47TsRC59zSWCQIhYuM+tH ZJ0MAM/qQNt/PG1NK26EtpD5eUBDYYjAwDMQFJKmGtYJVU+RFsjXCRnNkZa/iIemOoG5 EOcn/H8ibVmWW747sZn8X2TdlFdpc1XC/BPKo9gR+M8Nlr2S5FocF4AV9Gpcygia5nbK kgS2b+8XwowUcK/R6biqcuSU3VE/GRF4wYR+83rARNt4x9cj0DTNXGi2ueKp7PtOFazH 9lGHEIeBgajRYy12RSXyU/knX0wMcmBZer0hONWhIxxRL0qZobNdz902EDCAwc+oFC62 rw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0017.outbound.protection.outlook.com [207.46.163.17]) by mx0b-00273201.pphosted.com with ESMTP id 2n0y2ar85p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 Oct 2018 10:17:13 -0700 Received: from BYAPR05MB4664.namprd05.prod.outlook.com (52.135.233.78) by BYAPR05MB5223.namprd05.prod.outlook.com (20.177.231.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Tue, 9 Oct 2018 17:17:10 +0000 Received: from BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f]) by BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f%3]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 17:17:10 +0000 From: Kent Watsen To: Alexander Clemm , Ladislav Lhotka , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyPz6FAZXxCAuEeMxCal0HeWUaUO37yAgAAnp4CAAARbAIAABz8AgABBFoD//8WNgIAAWzMAgAAFdID//8jaAIABBsKAgAWVBYCAAQ+mgA== Date: Tue, 9 Oct 2018 17:17:10 +0000 Message-ID: References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5223; 6:4YroWty0a5zctmmRfEYAWSy/U+s8FE94YakDFQE4e0PCdUw7ikdKjAr7XamvArB/B4I5WbYx7OX8HJVxfVMo4prIP/1YZyKtZg0Y3RG6rfY/mf9EsKITD+AwhKXAQFgRLigPvefft8q/r9/SfQj7zabA5hTZgU1JJtbeGnqlZyra6f/yPPQ/INhDWKoxaM6IdIRkSyw4Eq9/jImyxVEQXs/MNJ5QiV0qVlQSzX7xrJR6v9EmAp/on6TEilY2N2/JhZMDp/mpFri1ze2eJY9dVIxh3JxhErAHgTXiWy/ylQHDM8e52qvvFseHCeUUmIe7SwoaHVXB0LO1IwrB/pJnBTmP7fPqGmHGbeECq2nPTgU89ywObJWWGrebB4rzA3WkpnvfE4s31tiTaA+kqwT+caEDz/aBAErNl/wbbj67HybixQF6NajgfnzO7vZmyHQ5RxcMrxBD+Y1fngF3d/5C+w==; 5:ArOTiTNbnRLHKWmPJcg8tc4nhK8AqpJ7KYcUOC0CI7yD4fHLyBaMoFQd+OYv9d8z8Mim9VEl5kKFn1qGNtFeCSBLbfu8YLrL26P8OA3arobQkB5ROpzc4WVAw94gCxzCMNFvZZLJFW3KEQsLSn/qN3vIKl9tzqDkf/LgM7jlMkI=; 7:gKDK6ubqG5mbIgUKNe+z97VQvSzSIL3AlckkPCL1WW6zaBgv3xdIHF/GJ9/6CA1OU80ZrlOJv9qbhjHSZmEs5DbIoPdbxPNwwKFNO5AXuRZ8QwoAB+2/4/5/XoOn1eo5MgqOM6LFcpy3iTzeNcXxVpyUOJs/eAa3lk2ni6B5q0IyQCSnoYQwKjVVDJ766bEE49fwFH8M5RFi2C/37ILeUS0hJqX10E4Ur7Qoi0wWqqEp7ZdkR6hxJLlVgM+pIklt x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5c747ad0-82c0-43ef-a5b4-08d62e0b0c30 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5223; x-ms-traffictypediagnostic: BYAPR05MB5223: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(50582790962513)(138986009662008)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991055); SRVR:BYAPR05MB5223; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5223; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(366004)(396003)(346002)(189003)(199004)(51444003)(13464003)(966005)(97736004)(66066001)(6436002)(5250100002)(2616005)(476003)(7736002)(478600001)(53936002)(36756003)(446003)(102836004)(4744004)(11346002)(2501003)(81156014)(6246003)(86362001)(19627235002)(25786009)(6116002)(71200400001)(99286004)(83716004)(71190400001)(81166006)(58126008)(3846002)(575784001)(229853002)(305945005)(8676002)(256004)(2900100001)(14444005)(105586002)(106356001)(93886005)(6512007)(76176011)(316002)(33656002)(82746002)(5660300001)(6306002)(114624004)(6346003)(8936002)(486006)(68736007)(2906002)(14454004)(53546011)(186003)(110136005)(6486002)(6506007)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5223; H:BYAPR05MB4664.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: bhtaFNHpYZD8dhglkcJ0Gq6gUYfQBxfvIt4uVjtgKZ8XOmRRiLtzonVQyz5In1pYIKNDgasL/F9ga/aR3mSxapR7ybGfaG75y0wzZzPJqoY1upeWx9fmI8lMRuyzL3wkmjFutkuy2rZ5yuXd3Ci1Jut6zUwd6/5lfimI4dUPD0s/xWcnk47+xfYAtW6rIP2n5gvGB+TkwZsKrgFoZkcpTjX49Ct4SfhISpYUtwtMHaRXn3W2f6kEJhiBRez1Q1aG+9XMsJLPRYDOSjIPhCLujVA6wMuMgWD4xlxhKclo6mouUc3psdUVBdgG0N1ZugcHtX732qsYUAWCwAY3rHonCflkrypkkcXerZlEk8SMqlM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <86F0DFF2A595704CA5874E5A4680EDEB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5c747ad0-82c0-43ef-a5b4-08d62e0b0c30 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 17:17:10.2415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5223 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-09_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810090167 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:17:24 -0000 SSBhZ3JlZSB0aGF0IGEgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3JtYXQgaXMgZGVzaXJhYmxl Lg0KDQpJIGRpc2FncmVlIHRoYXQgWUFORy1QYXRjaCBpcyB0aGUgcmlnaHQgZm9ybWF0LCBmb3Ig cmVhc29ucw0Kc3RhdGVkIGJlZm9yZS4gIEkgZmVlbCB0aGF0IGEgY29tcHJvbWlzZSBvZiB0aGlz IHNvcnQgZm9yDQphIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgaXMgd3JvbmcuDQoNCklmIHRoaXMg aXMgd2hhdCB0aGUgV0cgd2FudHMsIEkgd2l0aGRyYXcgbXkgc3VwcG9ydC4NCg0KS2VudCAvLyBj b250cmlidXRvcg0KDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFs ZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+DQpEYXRlOiBNb25kYXks IE9jdG9iZXIgOCwgMjAxOCBhdCA1OjA1IFBNDQpUbzogTGFkaXNsYXYgTGhvdGthIDxsaG90a2FA bmljLmN6PiwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+LCBBbmR5IEJpZXJtYW4g PGFuZHlAeXVtYXdvcmtzLmNvbT4sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiwgIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBbbmV0bW9kXSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1j bGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQoNCkkgd291bGQgc2Vjb25kIHRoZSByZXF1ZXN0IGZv ciBvbmUgZm9ybWF0ICh3aGljaCBpcyBtYW5kYXRvcnkgdG8gc3VwcG9ydCksIHdoaWNoIG11c3Qg YmUgc3BlY2lmaWVkLiAgWUFORy1QYXRjaCBpcyB0aGUgbG9naWNhbCBjYW5kaWRhdGUgSU1ITy4g IA0KDQpUbyBhbGxvdyBzZWxlY3Rpb24gb2Ygb3RoZXIgZm9ybWF0cyB1c2luZyBhbiBpbnB1dCBw YXJhbWV0ZXIgbWFrZXMgc2Vuc2UsIGJ1dCBhZGRzIHNvbWUgY29tcGxleGl0eSBmcm9tIHRoZXJl OiAgSG93IHRvIGtub3cgd2hpY2ggZm9ybWF0cyBhcmUgc3VwcG9ydGVkPyAgKEFkZCBhIGxpc3Qg b2Ygc3VwcG9ydGVkIGZvcm1hdHMgc29tZXdoZXJlPykgICBPciBzaW1wbHkgcmVseSBvbiBhdWdt ZW50YXRpb24gZm9yIHRob3NlIGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgaXQ/ICANCg0KLS0t IEFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhZGlzbGF2IExob3Rr YQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDUsIDIwMTggMTI6NTAgQU0NCj4gVG86IEtlbnQg V2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PjsgQW5keSBCaWVybWFuDQo+IDxhbmR5QHl1bWF3 b3Jrcy5jb20+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt DQo+IHVuaXZlcnNpdHkuZGU+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRt b2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDAN Cj4gDQo+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cml0ZXM6DQo+IA0KPiA+ IFN1cmUsIG9uZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCwgb3RoZXJzIG5pY2UgdG8g aGF2ZS4NCj4gPiBJbnRlcm9wZXJhYmlsaXR5IGdvb2QuICBBZ3JlZWQuDQo+ID4NCj4gPiBCdXQg d2h5IFlBTkctcGF0Y2ggYW5kIG5vdCBzb21ldGhpbmcgYnVpbHQgZm9yIHRoZSBwdXJwb3NlIChl LmcuLA0KPiA+IFlBTkctZGlmZikgdGhhdCwgaW4gcGFydGljdWxhciwgcHJvdmlkZXMgYW4gYWN0 dWFsIGRpZmYgYXMgb3Bwb3NlZCB0bw0KPiA+IGEgZGF0YS10cmVlIG9wZXJhdGlvbiB0aGF0IG9u bHkgc2hvd3Mgb25lIG9mIHRoZSB0d28gdmFsdWVzPw0KPiANCj4gU3VjaCBhIGZvcm1hdCBjYW4g YmUgZGV2ZWxvcGVkIGluZGVwZW5kZW50bHksIEkgd291bGQgc3VwcG9ydCBpdC4NCj4gDQo+IExh ZGENCj4gDQo+ID4NCj4gPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+ID4NCj4gPg0KPiA+IE9uIDEw LzQvMTgsIDM6MjcgUE0sICJBbmR5IEJpZXJtYW4iDQo+IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gT24gVGh1LCBPY3QgNCwg MjAxOCBhdCAxMjowNyBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+IDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtDQo+ IHVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCj4gPiBGb2xrcywgdGhlIG1vcmUgZm9ybWF0cyB0aGVy ZSBhcmUsIHRoZSBsZXNzIGludGVyb3BlcmFiaWxpdHkgd2UgZ2V0Lg0KPiA+IElmIHRoZXJlIGFy ZSBtdWx0aXBsZSBmb3JtYXRzLCBpcyB0aGVyZSBhIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQNCj4g PiBmb3JtYXQ/IERvZXMgdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgZm9ybWF0IGRlcGVuZCBv biB0aGUgcHJvdG9jb2wNCj4gPiB0aGF0IGlzIGJlaW5nIHVzZWQ/DQo+ID4NCj4gPiBJIHByZWZl ciBvbmUgZm9ybWF0IG9yIGlmIG5lY2Vzc2FyeSBJIGFtIGZpbmUgd2l0aCBvbmUgbWFuZGF0b3J5 IHRvDQo+ID4gaW1wbGVtZW50IGZvcm1hdC4gQW4gb3BlbiBlbmRlZCBjb2xsZWN0aW9uIG9mIGlt cGxlbWVudGF0aW9uIHNwZWNpZmljDQo+ID4gZm9ybWF0cyBpcyBzdXBlciBmbGV4aWJsZSBidXQg ZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBhIHN0YW5kYXJkLA0KPiA+IG5hbWVseSBpbnRlcm9wZXJh YmlsaXR5Lg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGVyZSBuZWVkcyB0byBiZSAxIG1hbmRhdG9yeS10 by1pbXBsZW1lbnQgZm9ybWF0Lg0KPiA+DQo+ID4gSU1PIHRoaXMgbmVlZHMgdG8gYmUgWUFORyBQ YXRjaCBiZWNhdXNlIGl0IGlzIG1vcmUgcHJlY2lzZSB0aGVuDQo+ID4gY29uc3RydWN0aW5nIGFu IFhNTCB0cmVlIHdpdGggb3BlcmF0aW9uIGF0dHJpYnV0ZXMgaW4gaXQgKGUuZy4sIGhvdw0KPiA+ IGVsc2UgZG8geW91IHJlcHJlc2VudCBhIGRlbGV0ZSBvciBhIG1vdmU/KSBBbHNvLCBZQU5HIFB1 c2ggaXMgdXNpbmcNCj4gPiBZQU5HIFBhdGNoIGZvcm1hdCBhbmQgY29tbW9uIGNvZGUgZm9yIHB1 c2ggYW5kIGRpZmYgd291bGQgYmUgcG9zc2libGUuDQo+ID4NCj4gPiBJIHRoaW5rIG90aGVyIGZv cm1hdHMgc2hvdWxkIGJlIGFsbG93ZWQuDQo+ID4gVGhpcyBpcyB2ZXJ5IHRvb2wtc3BlY2lmaWMu IEkgY291bGQgc2VlIGhvdyBzb21lYm9keSBtaWdodCB3YW50IGENCj4gPiB0ZXh0dWFsIHBhdGNo IG9mIHRoZSBYTUwgcmVwcmVzZW50YXRpb24gdG8gcHJvZHVjZSB0aGUgbmV3IFhNTA0KPiByZXBy ZXNlbnRhdGlvbi4NCj4gPg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gPiBBbmR5DQo+ID4NCj4gPg0K PiA+IE9uIFRodSwgT2N0IDA0LCAyMDE4IGF0IDA1OjQxOjIyUE0gKzAwMDAsIEtlbnQgV2F0c2Vu IHdyb3RlOg0KPiA+PiBXZSBhZ3JlZSB0aGF0IHRoZSBkaWZmLWZvcm1hdCBzaG91bGQgYmUgY2xp ZW50LXNlbGVjdGFibGUsIG1vZHVsbyB3aGF0IHRoZQ0KPiBzZXJ2ZXIgc3VwcG9ydHMuICB5YW5n LXBhdGNoIGFuZCBlZGl0LWNvbmZpZyBib3RoIGFyZSB2aWFibGUuICBTaG91bGQgd2UNCj4gZG9j dW1lbnQgdGhlbSBib3RoPw0KPiA+Pg0KPiA+PiBUaGF0IHNhaWQsIHNpbmNlIG5laXRoZXIgZWRp dC1jb25maWcgbm9yIHlhbmctcGF0Y2ggYXJlIGRpZmZpbmcgZm9ybWF0cywgc28NCj4gbXVjaCBh cyBmb3JtYXRzIGZvciBjb252ZXJ0aW5nIG9uZSBkYXRhIHRyZWUgdG8gYW5vdGhlciwgd291bGQg aXQgbWFrZSBzZW5zZQ0KPiB0byBkZWZpbmUgYW4gYWN0dWFsIGRpZmZpbmcgZm9ybWF0PyAgSSB3 b3VsZCB0aGluayB0aGF0IGEgZGlmZiB3b3VsZCBwcm92aWRlIGJvdGgNCj4gdmFsdWVzLCBub3Qg anVzdCBhIG5ldyB2YWx1ZS4NCj4gPj4NCj4gPj4gS2VudCAvLyBjb250cmlidXRvcg0KPiA+Pg0K PiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBuZXRtb2QN Cj4gPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZz4+IG9uIGJlaGFsZg0KPiA+PiBvZiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8 bWFpbHRvOmxob3RrYUBuaWMuY3o+Pg0KPiA+PiBPcmdhbml6YXRpb246IENaLk5JQw0KPiA+PiBE YXRlOiBUaHVyc2RheSwgT2N0b2JlciA0LCAyMDE4IGF0IDE6MTEgUE0NCj4gPj4gVG86IFJvYmVy dCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+LA0K PiA+PiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Ig0KPiA+PiA8bmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KPiA+PiBTdWJqZWN0OiBSZTog W25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4gPj4gZHJhZnQtY2xlbW0tbmV0bW9kLW5t ZGEtZGlmZi0wMA0KPiA+Pg0KPiA+PiBPbiBUaHUsIDIwMTgtMTAtMDQgYXQgMTQ6MTcgKzAxMDAs IFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4+ID4NCj4gPj4gPiBPbiAwNC8xMC8yMDE4IDEzOjUx LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+ID4gPiBPbiBUaHUsIDIwMTgtMTAtMDQgYXQg MTM6MzYgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4+ID4gPiA+IE9uIDA0LzEwLzIw MTggMTE6MTQsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4+ID4gPiA+ID4gUGhpbCBTaGFm ZXIgPHBoaWxAanVuaXBlci5uZXQ8bWFpbHRvOnBoaWxAanVuaXBlci5uZXQ+PiB3cm90ZToNCj4g Pj4gPiA+ID4gPiA+IEJhbD96cyBMZW5neWVsIHdyaXRlczoNCj4gPj4gPiA+ID4gPiA+ID4gaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29sDQo+ ID4+ID4gPiA+ID4gPiA+IHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGNsZW1tLTJEbmV0bW9kLTJE bm1kYS0yRGRpZmYtMkQwMA0KPiA+PiA+ID4gPiA+ID4gPiAmZD1Ed0lDQWcmYz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyDQo+ID4+ID4gPiA+ID4gPiA+ DQo+ID05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6 ekg5Tw0KPiA+PiA+ID4gPiA+ID4gPg0KPiBsM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45 N2Mmcz1nUVdKdGpjXzJFRjNRZ1J2QUJnWksNCj4gPj4gPiA+ID4gPiA+ID4gc2pxenVJdzl5VXFf eGVlNmFGSk9jdyZlPQ0KPiA+PiA+ID4gPiA+ID4gW0kndmUgbW92ZWQgdG8gYSAiZGVlcCBsdXJr ZXIiIHJvbGUgaGVyZSwgYnV0IC4uLl0NCj4gPj4gPiA+ID4gPiA+DQo+ID4+ID4gPiA+ID4gPiBD YW4gd2UgZW5zdXJlIHRoaXMgbW9kZWwgY29udGFpbnMgYSAiZm9ybWF0IiBsZWFmIGluIHRoZSBS UEMncyBpbnB1dA0KPiA+PiA+ID4gPiA+ID4gc28gdGhhdCBmdXR1cmUgKGFuZCBwcm9wcmlldGFy eSkgZm9ybWF0cyBjYW4gYmUgc3VwcG9ydGVkPyAgIFRoYXQNCj4gPj4gPiA+ID4gPiA+IGxlYWYg Y2FuIGJlIGFuIGlkZW50aXR5cmVmIHRoYXQgZGVmYXVsdHMgdG8geWFuZy1wYXRjaC4NCj4gPj4g PiA+ID4gPiBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGlkZWEuICBJIHdvdWxkIHByZWZlciB0aGUg ZWRpdC1jb25maWcNCj4gPj4gPiA+ID4gPiBmb3JtYXQgb3ZlciBZQU5HIHBhdGNoIGZvciBkZXNj cmliaW5nIGEgZGlmZi4gIFRoZQ0KPiA+PiA+ID4gPiA+IGVkaXQtY29uZmlnIGZvcm1hdCBpcyBt b3JlIHN1aXRlZCBmb3IgdGhpcyBwdXJwb3NlIGltby4NCj4gPj4gPiA+ID4gKzENCj4gPj4gPiA+ ID4NCj4gPj4gPiA+ID4gSSB3b3VsZCBsaWtlIHNvbWV0aGluZyBjbG9zZXIgdG8gZWRpdC1jb25m aWcgdG8gYmUgYXZhaWxhYmxlDQo+ID4+ID4gPiA+IHZpYSBSRVNUQ09ORiBhcyB3ZWxsLg0KPiA+ PiA+ID4gWUFORyBQYXRjaCBpcyBJTU8gYmV0dGVyIGJlY2F1c2UgaXQgY2xlYXJseSBzZXBhcmF0 ZXMgdGhlIHRhcmdldA0KPiA+PiA+ID4gZm9yIHRoZSBlZGl0cyBmcm9tIHRoZSBuZXcgY29udGVu dC4NCj4gPj4gPiA+IEluIGVkaXQtY29uZmlnIHRoZXNlIHR3byBhcmUgbWl4ZWQgdG9nZXRoZXIu DQo+ID4+ID4gWWVzLCB0aGF0IGlzIHByaW1hcmlseSB3aHkgSSBwcmVmZXIgdGhlIGVkaXQtY29u ZmlnLiAgSSBwZXJjZWl2ZQ0KPiA+PiA+IHRoYXQgaXQgaXMgYSBkZW5zZXIgYW5kIG1vcmUgZWZm aWNpZW50IGZvcm1hdC4gIEkgdGhpbmsgdGhhdCBpdCBpcw0KPiA+PiA+IGJvdGggZWFzaWVyIHRv IGNvbnN0cnVjdCAod2hlbiBkaWZmaW5nIHR3byB0cmVlcykgYW5kIGFsc28gbW9yZQ0KPiA+PiA+ IGVmZmljaWVudCB0byBhcHBseSB3aGVuIGdlbmVyYXRpbmcgYW4gdXBkYXRlZCB0cmVlLg0KPiA+ Pg0KPiA+PiBFeGNlcHQgZm9yIGNlcnRhaW4gY29ybmVyIGNhc2VzLCBmb3IgZXhhbXBsZSBpZiB0 d28gdHJlZXMgZGlmZmVyIG9ubHkNCj4gPj4gaW4gdGhlIHZhbHVlIG9mIGEgc2luZ2xlIGxlYWYg YnV0IHRoaXMgbGVhZiBoYXBwZW5zIHRvIGJlIGEgbGlzdCBrZXkuDQo+ID4+DQo+ID4+IExhZGEN Cj4gPj4NCj4gPj4gPg0KPiA+PiA+IFRoYW5rcywNCj4gPj4gPiBSb2INCj4gPj4gPg0KPiA+PiA+ DQo+ID4+ID4gPiBUaGF0IGJlaW5nIHNhaWQsIEkgc3VwcG9ydCBzcGVjaWZ5aW5nIGZvcm1hdC9t ZWRpYS10eXBlIGFuZA0KPiA+PiA+ID4gaGF2aW5nIHBvdGVudGlhbGx5IG11bHRpcGxlIG9wdGlv bnMuDQo+ID4+ID4gPg0KPiA+PiA+ID4gTGFkYQ0KPiA+PiA+ID4NCj4gPj4gPiA+ID4gVGhhbmtz LA0KPiA+PiA+ID4gPiBSb2INCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gPiAv bWFydGluDQo+ID4+ID4gPiA+ID4NCj4gPj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4gPj4gPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4N Cj4gPj4gPiA+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmDQo+ID4+ID4gPiA+ID4NCj4gLm9yZ19tYWlsbWFuX2xpc3RpbmZv X25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVQ0KPiA+PiA+ID4gPiA+IGpC WGVNSy0NCj4gbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTDQo+ID4+ID4gPiA+ID4NCj4gbGFKZGNabyZtPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJy UTVmRDB2VHQ4a19JMktERU45N2Mmcz1SVkpjZw0KPiA+PiA+ID4gPiA+IDVwekhXLXppMU9ib0NM NFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmU9DQo+ID4+ID4gPiA+ID4gLg0KPiA+PiA+ID4gPiA+ DQo+ID4+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4gPiA+ID4gbmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4+ID4gPiA+IGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYubw0KPiA+PiA+ ID4gPg0KPiByZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGUNCj4gPj4gPiA+ID4gTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1Aw eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWg0KPiA+PiA+ID4gPg0KPiBvJm09 N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0kyS0RFTjk3YyZzPVJWSmNnNXB6SFct emkNCj4gPj4gPiA+ID4gMU9ib0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmU9DQo+ID4+IC0t DQo+ID4+IExhZGlzbGF2IExob3RrYQ0KPiA+PiBIZWFkLCBDWi5OSUMgTGFicw0KPiA+PiBQR1Ag S2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K PiA+PiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpDQo+ID4+IGxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3Vo cjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFgNCj4gPj4NCj4gY1d6b0NJJnI9OXprUDB4bkpV dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTdzNlZkenpIOU9sMw0KPiBCTw0K PiA+PiBDYlZMQmFyQnJRNWZEMHZUdDhrX0kyS0RFTjk3YyZzPVJWSmNnNXB6SFctDQo+IHppMU9i b0NMNFNYMmh1VzlldUhpVlJTQ29yDQo+ID4+IDluX0FQUSZlPQ0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K PiA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk00OEd3ZEk0dGV6LUp0ZjJ1YTJqdnRM WlZLZml3a2J3YklyVSZzPWcweF9CLVhlejd0RDloTFg3MUQ1dmxjSGRab2huVGtpTVZJS0poQUhp dmsmZT08aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X191cmxkZWZlbnNlLnByb29mJmQ9RHdJRkFnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh SmRjWm8mbT1ETTFqc3duTTQ4R3dkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9YnpM YUxvQkNKODhsYXZldXBMcWFwWU40YnRqRUJCdk5FTk55MDlUc29vYyZlPQ0KPiA+PiBwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmZD1EDQo+ID4+IHdNRmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBu ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUUNCj4gPj4gUG9PSDdZaHFuMmdzQllhR1R2 aklTbGFKZGNabyZtPU83ZC0NCj4gYjlneVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxvOF9XNg0K PiA+PiBXM3F0NCZzPTVMSGhiZlFaZW9xWWxDNDBUM21tLUFFejRyU3N5UldZanFUSzdMdVdUUHcm ZT0+DQo+ID4NCj4gPiAtLQ0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+IEZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmphY29icy0yRCZkPUR3SUZBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk00OEd3ZEk0dGV6LUp0ZjJ1YTJqdnRM WlZLZml3a2J3YklyVSZzPTVSRDk2LVRqeW1VMVpobWZaRnRXRW00YWJra2RheHFya0NLenV2NFBa UlEmZT0NCj4gdW5pdmVyc2l0eS5kZS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmphY29icy0NCj4gMkR1bml2ZXJzaXR5LmRlXyZk PUR3TUZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6b0NJ JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPU8NCj4gN2Qt DQo+IGI5Z3lQdnNhc0pvMXVlS2szZG9ESDdmNVM1V1FMbzhfVzZXM3F0NCZzPXpoN3FFUFNtd3Zp YVNxWkJxRzFHYw0KPiBxSXRYd0k5cHd5cUlGVlc2eEM4cks4JmU9Pj4NCj4gPg0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1h aWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJRkFnJmM9SEFrWXVoNjNy c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3 WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1ETTFqc3duTTQ4R3dkSTR0ZXotSnRmMnVhMmp2dExa VktmaXdrYndiSXJVJnM9ZzB4X0ItWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNVklLSmhBSGl2 ayZlPTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3VybGRlZmVuc2UucHJvb2ZwJmQ9RHdJRkFnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh SmRjWm8mbT1ETTFqc3duTTQ4R3dkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9aWQ1 a2RYREViNGFmbm9iV1QtZlVxM1lmc0lrSG9vejVSdFhZc29RUnQxbyZlPQ0KPiA+IG9pbnQuY29t L3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0 bW9kJmQ9RHdNDQo+ID4gRmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIz dm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb08NCj4gPiBIN1locW4yZ3NCWWFHVHZqSVNs YUpkY1pvJm09TzdkLQ0KPiBiOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2VzNxdA0K PiA+IDQmcz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJXWWpxVEs3THVXVFB3JmU9Pg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTbGFKZGNabyZtPURNMWpzd25NNDhHd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJ clUmcz1nMHhfQi1YZXo3dEQ5aExYNzFENXZsY0hkWm9oblRraU1WSUtKaEFIaXZrJmU9DQo+IA0K PiAtLQ0KPiBMYWRpc2xhdiBMaG90a2ENCj4gSGVhZCwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJ RDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRm Lm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1 aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk00OEd3ZEk0dGV6LUp0ZjJ1YTJq dnRMWlZLZml3a2J3YklyVSZzPWcweF9CLVhlejd0RDloTFg3MUQ1dmxjSGRab2huVGtpTVZJS0po QUhpdmsmZT0NCg0K From nobody Tue Oct 9 10:24:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9699A127332 for ; Tue, 9 Oct 2018 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXuxFOaxVNL4 for ; Tue, 9 Oct 2018 10:24:20 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE34126CB6 for ; Tue, 9 Oct 2018 10:24:20 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w99HO37m015311; Tue, 9 Oct 2018 10:24:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=Q6FeRT2T23M0e+uwK3jRLgAmwtZvnf1i+8llU+/BvKY=; b=UuwhVm2oV1lSEQzOU1/xYxcQ6gnnnNbx+1KRTjqx16kmRo8NNSd8HJw45A74MKwjh/lA NkF08ctpgG9+eYbXOQPh1vMKq7KY9bxEjgnksGI/2Axhg0VzRAfue4xpTKpTHNcpzSKs VoH+AAxnPcuZDF5kBfgBz4GCqedOanG6Mwbz63lbqyXe/gnazXUGKMFn/uWxg+bi6mHx jJbIaG5a/SX2P2v8o7Wa7xjyvRCVMcov1y9XrbQpn3lMdyLH6HdmdEcTdvEw5IdHDtyM 0eiJ5bSP0r5SxTjCKmZr0oE87kPkQjXyjR2IrOaPpcMaVuF05nQX4k7HFlg4yhabVtXO Tw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0023.outbound.protection.outlook.com [207.46.163.23]) by mx0b-00273201.pphosted.com with ESMTP id 2n0s0pgykw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 Oct 2018 10:24:18 -0700 Received: from BYAPR05MB4664.namprd05.prod.outlook.com (52.135.233.78) by BYAPR05MB4933.namprd05.prod.outlook.com (52.135.235.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.19; Tue, 9 Oct 2018 17:24:15 +0000 Received: from BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f]) by BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::d45d:b92d:3e87:ef9f%3]) with mapi id 15.20.1228.020; Tue, 9 Oct 2018 17:24:15 +0000 From: Kent Watsen To: Ladislav Lhotka , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" Thread-Topic: [netmod] Whitespace in XML encoding - allowed ? Thread-Index: AQHUX65zMY3LKhsc8UeIQzNDxdo7xaUWuNSAgAAuoYA= Date: Tue, 9 Oct 2018 17:24:15 +0000 Message-ID: References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> <871s8zh0cu.fsf@nic.cz> In-Reply-To: <871s8zh0cu.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB4933; 6:p0UB1/vV22Af+dIuueHYZ9MsIvzOr1WavfihqjmS9kOIKLu/AR4e9kRZdcfvMNClML4mfh5xXbqePMB+L1G+LHmGZNsWVj+ps9lCnWXncgN4Gl54p7h2EDUONjvoN+pmbcgYdEZ/NxqQWNWYBJmkvSp30Pntqei5cBV2clscMMH9xRyv4RD+yIy2TUwXOeFtKS4bKp3hEM97R7vFx8RIFnzfEbLDHhcQ+UQjIM/mxtNGEgWwQPmVN2USWxEvjf+36NZP6FNtZutZR+G2XaHvunCiAiyp77jqsPtPMB5bNy3DTe1TsfHZ7toBqi2IJJZ7CrkD43v2t2vsRWZZNhY8f9P14FDf3B1VA+Jej3ycaeuCVmXnAxnEu6RB7AOnIzk3UQnDNM48VVRWsH+tRfGkiN8T0kARU3uMnEU1rng6V/2MnNZgDNkjS05xXWPy37qhsI7bOhbizUirU16GsAziGQ==; 5:lWKDUWsvbsQeBPHvrrvalXikHJRj/ZnNoWCGqF6mbWQy8pMjctimJ0adX/PpRINcGGoDpTPB4DpNmMWXzsDgwpQRysRIP6iWet5ssqBfZICW2KGdhhZSBlfdKKMAfRgb3LcA8vW+hYgm/O6xSNDETMxGssp+0BS93HeFq3zoFa8=; 7:wddzFnkC7aAW6SHqUtv8spAvIMAcunNMv7P+GsdX/3ME+vIzKXHQ6tMdHkj8vVk+w0wZEXBaFjbp/Ra5DnBDvgsqVRDx9q3yu0cqfODZVkolC3FzKDk4swTghiZ6Iaa567hf5ezzJbzlCrewe2N9RXipe695p51S1MZQ4bQrcSDX5rHSNePJJaZJGImfbeQA1/HN7d8K4EfcV8vH3dnliRKkotmodBU/hK2Zt3YMS4z9ONVgv7DovMEH3zplFgWI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6faa535c-f01c-4263-cea8-08d62e0c09a2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4933; x-ms-traffictypediagnostic: BYAPR05MB4933: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:BYAPR05MB4933; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4933; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(396003)(376002)(39860400002)(199004)(189003)(2906002)(110136005)(305945005)(478600001)(58126008)(316002)(229853002)(6436002)(8936002)(6246003)(86362001)(26005)(486006)(558084003)(7736002)(11346002)(2616005)(476003)(446003)(186003)(6506007)(14454004)(76176011)(2900100001)(3846002)(6116002)(33656002)(102836004)(53936002)(6512007)(106356001)(99286004)(82746002)(36756003)(5660300001)(105586002)(5250100002)(66066001)(2501003)(68736007)(25786009)(8676002)(81156014)(6486002)(81166006)(97736004)(256004)(71200400001)(71190400001)(83716004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4933; H:BYAPR05MB4664.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: tDWLh9sFk+h0B0Bl7RCiuk+8cBCSwwQvGcVM5vPGLGQrrUZxnma60pM4aNB0zbD09lNqibFm2J0G7VlsNgP/wux5F8WSakqzgVC0Al2OknpdANIcxtkPcjKHg/KKCCMINR1bDQP6TW0D0xV6sSdpRvoS0TLdrSXBLqS/MuLWrv++K51ClLEiurXDt/tgo7G6bFpn8JQa3p4Q/HlBkNznv/1Q1TRxsajnhtRDLEeuxL9BSiLDcCSF1ciqJOTr5jWSCdm6Yfn+RgnUhK/+ezN0zLF0GF7Dayrh4oiIaxpnVLmHhI8W08cw4KX7HTNkMliuuJLe3kQnAn5Cecd+Z5pQahmWA2x2bqKUPXFv1uYmTwA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7E9098C5DC810141920AC2405F924AAC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6faa535c-f01c-4263-cea8-08d62e0c09a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 17:24:15.4172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4933 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-09_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=919 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810090168 Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:24:23 -0000 QXMgTWFydGluIHBvaW50cyBvdXQsIHRoaXMgaXMgaG93IFhNTCB3b3Jrcy4NCg0KQXMgYSByZXN1 bHQsIFhNTCBpbnN0YW5jZSBkb2N1bWVudHMgYXJlIHBvc3Rlci1jaGlsZCBleGFtcGxlcyBmb3Ig d2h5IGxvbmcgbGluZXMgb2NjdXIgc29tZXRpbWVzLCBhbmQgd2hlcmUgdGhlIGFydHdvcmstZm9s ZGluZyBkcmFmdCBzaGluZXMgd2hlbiBwbGFjaW5nIHNhaWQgZXhhbXBsZXMgaW50byBkcmFmdHMu DQoNCkxhZGEsIGdvb2QgcG9pbnQsIGJ1dCB3b3VsZCB0aGVyZSBiZSBhIGxheWVyIHZpb2xhdGlv bj8NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg0KDQo= From nobody Tue Oct 9 10:51:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65D130E89 for ; Tue, 9 Oct 2018 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 vBzLawClFPl3 for ; Tue, 9 Oct 2018 10:51:27 -0700 (PDT) Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E15130E83 for ; Tue, 9 Oct 2018 10:51:26 -0700 (PDT) Received: from unknown (HELO ILHFDAGDRFE4.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 09 Oct 2018 20:51:23 +0300 Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE4.corp.amdocs.com (10.237.241.95) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 9 Oct 2018 20:51:23 +0300 Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Tue, 9 Oct 2018 20:51:22 +0300 Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Tue, 9 Oct 2018 20:51:22 +0300 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Tue, 9 Oct 2018 20:51:22 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uhdhXe9hGch1O28a5nY1zUIm0gUETjh3LSwVh5xm2Gw=; b=rKIjHWLAG23CU/4m6wG4L/IOIWd0IRCNaHAs8RY9CQUFagQiR01jYthyVdUwRzBz4xtCdjqE0ILIFGrKLjo9LTncB4gTXK8fo/24ALj1+02rGtvLtumyKtOjJY3/F3KY1sYAWz8Roh1hBK8/sXZ7wtHuxQJ+tdn55dx+A+WGKyc= Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4385.eurprd06.prod.outlook.com (20.176.214.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.26; Tue, 9 Oct 2018 17:51:20 +0000 Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%3]) with mapi id 15.20.1207.024; Tue, 9 Oct 2018 17:51:20 +0000 From: Michael Rehder To: "netmod@ietf.org" Thread-Topic: WHEN statement within mandatory objects doesn't ensure presence of the mandatory object Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSA== Date: Tue, 9 Oct 2018 17:51:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; x-originating-ip: [192.95.160.116] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR06MB4385; 6:BF0igHsq5jGv6Mm3i+fKzQ6nF/X6H2LLE9XkhQnrUuOhFzBmOw8Gt0pd8TVWCW3ZkqssHnns0Wq0Jhqrzr8YJv5HN1OGKhXva0VYwj4PFzzSNlc9ptnmkvD9L8KHjsAg/grgqX6XkwMFhWRu64Z4tdteTfW6VKPfPoIvC8oBW25FMXSK0Sw5qc1hVmRUdxYgAsJRjLlEqqbLoqR/jcdQMgMB51F2I8hKnlA437wgayk/PkHP2/xLEOEbuV/l+w2snBJg0RbmenEOk+a8E8G7vhx9xFDSqus7A4zJeJ7Yuk0Zj6r6O5dmEyvh9RO98gX8uwWQ//OU2ogWW2jJlpnl6AIEbljsDGXncrMhLRKj47eC24E+/jWKeId0A9BW/KG6TvcAwj483kbAm+p8ymp7j0UVg9j3weYkEjjEo5b2NK1ccZpX8lLnHgL4rhieGerYpXxwyjp/PZYPUfICDLiDSg==; 5:/73ytvj6IMQone78sI13X8clEv8QzdQnFlcOLUHmVdoNbQS2JKM3+ViI5VQmZon+lufUdPC+d6hOT70aKIqfKVOC3RjY8jLvdCEbG5CQsFiLdxMWvAOKE+LCAIBXj/F6+WX25DSf/suhx4TjHkNLu0gOpU8rAVFpkAhNa9VUWDw=; 7:haE1XcmtsE9GnGmicFWOk8C5SqgHoahy7+VIOb1+dDYGixFBh2J50MCgTzGT96wd5gMRP9avvRIQu/yCupu9c1GtSa+J0G7yVOjobJcN8lOEli2mr3nufRiYd4cOnOXB6SNFobHol+FU7BFV6gVsDjR6IffSbn2BE+5+Qs/ejimQmdhWwfKJnO9mye+89zqushlIyQ1DhWrqxZ/Kj8IydSHadQl9nphPJpwrvR3V8rKUoQtj4eY7X8bBq/UkH5Nl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 30b7794b-0540-42d6-af64-08d62e0fd259 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4385; x-ms-traffictypediagnostic: AM0PR06MB4385: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991055); SRVR:AM0PR06MB4385; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4385; x-forefront-prvs: 08200063E9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(376002)(39860400002)(136003)(189003)(199004)(51444003)(53936002)(55016002)(33656002)(86362001)(6306002)(54896002)(9686003)(99286004)(6436002)(316002)(5640700003)(2900100001)(6506007)(5250100002)(7736002)(2501003)(7696005)(6916009)(256004)(74316002)(71190400001)(5660300001)(5630700001)(71200400001)(68736007)(3846002)(66066001)(8936002)(8676002)(6116002)(790700001)(486006)(1730700003)(97736004)(81156014)(25786009)(81166006)(14454004)(105586002)(106356001)(2351001)(2906002)(478600001)(476003)(72206003)(26005)(186003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4385; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: i8GTSZBs/4ZxWF085GHTlCV1RIXiUlK3oO00MDYFD65pZJYpjljbEUCsLZEXRgytbtog7igHOKgEFQKEaeR/5TNcEdK2XTT1avBdMLmhwtD6SfGgjkgjYOh8WYq93UNBWvtcOfKExHDE18bXsrlEphDFz0Q8zo8gZs9sNGkJ9eZfsaBzq+pTZFI7uZgO0ekjGwIadK5V/vFJby3SETa1L9QD9WhOLvGKg0tFAMz892a34qYF7HPtqvwn1SqDApKIzNRg3mcXubnEmjKubIjDSwUAlhz44w+tA5fTdTW3eR5njAMdYQt3qrXcrfg2PFnUe2+lfvssnzTaihZr55a/ifpQv97d5CquuwFvdWXSchQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70AM0PR06MB4083eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 30b7794b-0540-42d6-af64-08d62e0fd259 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2018 17:51:20.6577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4385 X-OriginatorOrg: amdocs.com Archived-At: Subject: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:51:29 -0000 --_000_AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70AM0PR06MB4083eurp_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQg4oCcd2hlbuKAnSBhbmQgbWFuZGF0b3J5IG9iamVjdHMu DQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGltcGxlbWVudGVkIHNlbWFudGljcyBvZiDigJx3 aGVu4oCdIGFyZSByZWFsbHkg4oCcb3B0aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5jbG9z aW5nIG9iamVjdCBjYW4gYmUgYWJzZW50IGV2ZW4gdGhvdWdoIGl0IGlzIG1hbmRhdG9yeSBhbmQg dGhlIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUuDQpUaGUgUkZDIGNvdWxkIGJlIGNsZWFy ZXIgYWJvdXQgdGhpcy4NCg0KRXhhbXBsZQ0KDQogICBsZWFmIGNvbG9yIHsNCiAgICAgZW51bWVy YXRpb24gIHsNCiAgICAgICAgZW51bSDigJxibHVl4oCdOw0KICAgICAgICBlbnVtIOKAnGJsYWNr 4oCdOw0KICAgICB9DQogICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgfQ0KICAgY29udGFpbmVyIGZv byB7DQogICAgICB3aGVuIC4uL2NvbG9yID0g4oCYYmx1ZeKAmTsNCiAgICAgIGV0Yy4NCiAgIH0N Cg0K4oCcZm9v4oCdIGlzIG9wdGlvbmFsIGR1ZSB0byB0aGUgcHJlc2VuY2Ugb2YgdGhlIOKAnHdo ZW7igJ0gc3RhdGVtZW50IGV2ZW4gdGhvdWdoIHRoZSBvYmplY3QgaXMgbWFuZGF0b3J5IChzYW1l IGlzIHRydWUgZm9yIG1hbmRhdG9yeSBsZWFmLCBtaW4tZWxlbWVudHM9MSBsaXN0IGV0Yy4pLg0K VGhpcyBpcyBjb25zaWRlcmVkIHZhbGlkIFhNTCBmb3IgdGhlIGFib3ZlDQogICAgPGNvbG9yPmJs dWU8L2NvbG9yPg0KDQpJbiBteSB2aWV3IHRoaXMgbWFrZXMgY29uZGl0aW9uYWxseSB2YXJpYW50 IHNjaGVtYXMg4oCcbG9vc2XigJ0gaW4gdGhlaXIgZW5mb3JjZW1lbnQgKHNvbWUgc2NlbmFyaW9z IGNhbiB1c2UgY2hvaWNlIGJ1dCBpdCBkb2VzbuKAmXQgY292ZXIgZXZlcnl0aGluZykuDQoNCkkg dGhpbmsgdGhhdCBtYW5kYXRvcnkgc2hvdWxkIGJlIHJlc3BlY3RlZCBmb3IgdGhlIGVuY2xvc2lu ZyBvYmplY3RzIG9mIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQuDQpUaGF0IGlzLCBhIG1hbmRhdG9y eSBvYmplY3QgbXVzdCBiZSBwcmVzZW50IHdoZW4gaXRzIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRz IHRydWUgYW5kIGEgU2NoZW1hdHJvbiBzdGF0ZW1lbnQgc2hvdWxkIGVuZm9yY2UgdGhhdC4NCg0K V2hhdCBpcyB0aGUgcmF0aW9uYWxlIGJlaGluZCB0aGUgY3VycmVudCBZQU5HIHJ1bGVzIGJlaGF2 aW9yLCB0aGF0IHRoZSDigJx3aGVu4oCdIFNjaGVtYXRyb24gbWFwcGluZyBkb2VzbuKAmXQgY2hl Y2sgZm9yIHByZXNlbmNlIG9mIHRoZSBlbmNsb3NpbmcgbWFuZGF0b3J5IG9iamVjdD8NCg0KdGhh bmtzDQpNaWtlIFJlaGRlcg0KDQrigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQg b24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFp bHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNo IHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1 Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBB bWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFu ZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS4K --_000_AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70AM0PR06MB4083eurp_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IOKAnHdoZW7igJ0gYW5kIG1hbmRhdG9y eSBvYmplY3RzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0aGF0IHRo ZSBpbXBsZW1lbnRlZCBzZW1hbnRpY3Mgb2Yg4oCcd2hlbuKAnSBhcmUgcmVhbGx5IOKAnG9wdGlv bmFsIHdoZW7igJ0sIGluIHRoYXQgdGhlIGVuY2xvc2luZyBvYmplY3QgY2FuIGJlIGFic2VudCBl dmVuIHRob3VnaCBpdCBpcyBtYW5kYXRvcnkgYW5kIHRoZSDigJx3aGVu4oCdIGNsYXVzZSBob2xk cyB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFJGQyBjb3Vs ZCBiZSBjbGVhcmVyIGFib3V0IHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4YW1wbGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGxlYWYgY29sb3IgezxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVu dW1lcmF0aW9uJm5ic3A7IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnVtIOKAnGJsdWXigJ07 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSDigJxibGFja+KAnTs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFu ZGF0b3J5IHRydWU7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IGNvbnRhaW5lciBmb28gezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZW4gLi4vY29sb3IgPSDigJhibHVl4oCZOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnGZvb+KAnSBpcyBvcHRpb25hbCBk dWUgdG8gdGhlIHByZXNlbmNlIG9mIHRoZSDigJx3aGVu4oCdIHN0YXRlbWVudCBldmVuIHRob3Vn aCB0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSAoc2FtZSBpcyB0cnVlIGZvciBtYW5kYXRvcnkgbGVh ZiwgbWluLWVsZW1lbnRzPTEgbGlzdCBldGMuKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgaXMgY29uc2lkZXJlZCB2YWxpZCBYTUwgZm9yIHRoZSBhYm92ZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtj b2xvciZndDtibHVlJmx0Oy9jb2xvciZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbXkg dmlldyB0aGlzIG1ha2VzIGNvbmRpdGlvbmFsbHkgdmFyaWFudCBzY2hlbWFzIOKAnGxvb3Nl4oCd IGluIHRoZWlyIGVuZm9yY2VtZW50IChzb21lIHNjZW5hcmlvcyBjYW4gdXNlIGNob2ljZSBidXQg aXQgZG9lc27igJl0IGNvdmVyIGV2ZXJ5dGhpbmcpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHRoYXQgbWFuZGF0b3J5IHNob3VsZCBiZSByZXNwZWN0ZWQgZm9yIHRoZSBlbmNsb3Np bmcgb2JqZWN0cyBvZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcywgYSBtYW5kYXRvcnkgb2JqZWN0IG11c3QgYmUgcHJl c2VudCB3aGVuIGl0cyDigJx3aGVu4oCdIGNsYXVzZSBob2xkcyB0cnVlIGFuZCBhIFNjaGVtYXRy b24gc3RhdGVtZW50IHNob3VsZCBlbmZvcmNlIHRoYXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGN1cnJlbnQgWUFORyBydWxlcyBiZWhh dmlvciwgdGhhdCB0aGUg4oCcd2hlbuKAnSBTY2hlbWF0cm9uIG1hcHBpbmcgZG9lc27igJl0IGNo ZWNrIGZvciBwcmVzZW5jZSBvZiB0aGUgZW5jbG9zaW5nIG1hbmRhdG9yeSBvYmplY3Q/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TWlrZSBSZWhkZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBw dCAwLjVpbjsiPjxlbT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGZvbnQgZmFjZT0iQ2Fs aWJyaSIgc2l6ZT0iMyI+4oCcQW1kb2Nz4oCZIGVtYWlsDQpwbGF0Zm9ybSBpcyBiYXNlZCBvbiBh IHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55DQplbWFpbHMg c2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5 c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUNCmJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNo IHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZg0KZW1haWxzIHRvIEFt ZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5k IHN1Y2gNCnByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48L2ZvbnQ+PC9zcGFuPjwv ZW0+PC9wPg0KDQo8Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR06MB4083426FA0F1D3F6515F2ECFE7E70AM0PR06MB4083eurp_-- From nobody Tue Oct 9 13:54:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534A129BBF; Tue, 9 Oct 2018 13:54:55 -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 wgvLe69J0S8g; Tue, 9 Oct 2018 13:54:52 -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 6167B130DD5; Tue, 9 Oct 2018 13:54:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DA74E27; Tue, 9 Oct 2018 22:54:49 +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 8ohiOnxu2qkP; Tue, 9 Oct 2018 22:54:49 +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, 9 Oct 2018 22:54:49 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 977C820037; Tue, 9 Oct 2018 22:54:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mqf83SPrAqiP; Tue, 9 Oct 2018 22:54:49 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id BC78820036; Tue, 9 Oct 2018 22:54:48 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 9 Oct 2018 22:54:48 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 0DE193000DDBD2; Tue, 9 Oct 2018 22:54:47 +0200 (CEST) Date: Tue, 9 Oct 2018 22:54:47 +0200 From: Juergen Schoenwaelder To: Kent Watsen CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Martin Bjorklund , "netmod-chairs@ietf.org" , "netmod@ietf.org" Message-ID: <20181009205447.qyhitak6djatmvrs@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Martin Bjorklund , "netmod-chairs@ietf.org" , "netmod@ietf.org" References: <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> <20181009.142506.637283350958767455.mbj@tail-f.com> <9e389747-74ed-0f62-24ce-813ce3cdc870@ericsson.com> <652D49CE-6469-412F-B708-D8496DFC0F16@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <652D49CE-6469-412F-B708-D8496DFC0F16@juniper.net> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] WG adoption poll - instance-data X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 20:54:55 -0000 On Tue, Oct 09, 2018 at 05:07:06PM +0000, Kent Watsen wrote: > > As co-chair, I have two minds: > > 1) requests a fix and redo the adoption poll > 2) realize that it's a living doc and regardless > how it begins, the WG can sort it out in time. > i.e., we're adopting to work on the problem, > not necessarily the specific solution. > > While (1) seems more proper, given the timing of > things, I'm willing to go for (2). To this extent, > the comments being made now be thought to carry > the same weight as Last Call comments. The chairs > will discuss this again when making a determination > on the adoption poll. It seems there are questions about the scope of this document and ideally there would be some agreement about the scope of the work covered by the document at adoption time. > As contributor, can we please not call this "YANG > instance data"? - that means something else to > me. This seems to be more about capturing data > about a server instances. So maybe "YANG-based > Server Instance Data"? (open to suggestions!) What does 'YANG instance data' mean to you? Why does adding 'sever' make things better? Why can't I use this format outside a 'server'? I think we do use phrases such as 'instantiated YANG data tree' in other documents, so 'instance data' (which is perhaps a shorthand) does not seem surprising to me. /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 9 20:10:53 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC847130E67; Tue, 9 Oct 2018 20:10:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger , Joel Jaeggli X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2018 20:10:51 -0700 Archived-At: Subject: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 03:10:52 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-netmod-schema-mount-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3506 DETAIL S 4. > > It is worth emphasizing that the nodes specified in > "parent-reference" leaf-list are available in the mounted schema only > for XPath evaluations. In particular, they cannot be accessed there > via network management protocols such as NETCONF [RFC6241] or > RESTCONF [RFC8040]. What are the security implications of this XPath reference outside the mount jail? Specifically, how does it interact with the access control for the enclosing module. From nobody Tue Oct 9 23:53:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C800A130E91 for ; Tue, 9 Oct 2018 23:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 QfoXgdf0dPht for ; Tue, 9 Oct 2018 23:53:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 7DA13130E89 for ; Tue, 9 Oct 2018 23:53:52 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id B98EA6082A; Wed, 10 Oct 2018 08:53:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539154430; bh=CXcdtW4x9f246YqUEMLVINiH8dwYJ4VkgN24z0csWn4=; h=From:To:Date; b=u5q3kX39P1G5xjitpIgvCkbDr+rm4yT8QVA6Sp7XlCCkUj0+3XpqPSx9tRFr7bdHx XjwxfmbMKt/eFhOvd/vc09VE9CAell8bxUTdVb7OtKOdJ20GIZeVa6Ut3uUgFuRu+K kriF4yjASQdKV5HJZMC1GqOFq24caeWSTtZRXONg= Message-ID: <522f0552fb49a4eee7931fde98004f3ed2e58a9c.camel@nic.cz> From: Ladislav Lhotka To: Kent Watsen , =?ISO-8859-1?Q?Bal=E1zs?= Lengyel , "netmod@ietf.org" Date: Wed, 10 Oct 2018 08:53:50 +0200 In-Reply-To: References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com> <871s8zh0cu.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Whitespace in XML encoding - allowed ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 06:53:55 -0000 On Tue, 2018-10-09 at 17:24 +0000, Kent Watsen wrote: > As Martin points out, this is how XML works. > > As a result, XML instance documents are poster-child examples for why long > lines occur sometimes, and where the artwork-folding draft shines when placing > said examples into drafts. > > Lada, good point, but would there be a layer violation? Which layers do you mean? XML and YANG parser on top of it? An XML processor is expected to pass the whitespace unchanged to the application (except for EOL normalization), and it is up to the YANG parser how the data is interpreted. Lada > > Kent // contributor > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 00:53:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA92130DC4 for ; Wed, 10 Oct 2018 00:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si 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 n3BTxkP8f4uX for ; Wed, 10 Oct 2018 00:53:00 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9753B1293FB for ; Wed, 10 Oct 2018 00:53:00 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 8CDE6C417623; Wed, 10 Oct 2018 09:52:56 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 8CDE6C417623 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1539157976; bh=9zLK6Tglau1fx/ckqZIZjuDC5NfUTddUc+KBzC5rChA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tWOQfe9f9T6GYcvE04DLD9Tuapw6eGSNljslBp/KKNq2OLql2IYHjyonnX9osVjbV atqJO7u+vQM6Du4Nsva6qi9IErI5YbdIeTwzavtw2PoOFocrEJKNPQ8OEgyIZtEB7O 3CeYulWI4KIH4fmGquYRE51lrX6gGret8csI+nHgX+Ni1wlZYEOF+HuNhk9Bs1uCSk gIAcLVUV+u8+Njb4eZ9l2lTPM/YYWSZXEZr1MzTo/q2h3w2xjscmSFQLF5nPSFFvLX YDJh2IG+VRGW0GOOQ8ET/1hv9ZDnpXZHr1PRNNFC+dJ+pzID4B2j8xBX0HRT0aXQ+a p6zwnW2qtPeTQ== To: Martin Bjorklund , balazs.lengyel@ericsson.com Cc: netmod@ietf.org References: <20181008.145313.1979034555219874418.mbj@tail-f.com> From: Jernej Tuljak Message-ID: Date: Wed, 10 Oct 2018 09:52:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181008.145313.1979034555219874418.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 07:53:03 -0000 Martin Bjorklund je 10/8/2018 ob 2:53 PM napisal: > Hi, > > > Balazs Lengyel wrote: >> Hello, >> >> What is the best way to download standard Yang Modules? I know the >> official answer is to download all the standards then extract the >> modules, however this is a "bit" cumbersome. Is there any better way? >> We had a git earlier. How up to date is that? > You can download them from IANA: > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml > > But there are two problems: > > 1) you have to download one at the time > 2) some of them have lost all indentation > (e.g. https://www.iana.org/assignments/yang-parameters/ietf-voucher@2018-04-06.yang) > > > [on 2), I have it on my list to talk to them] > If you do talk to them, also mention that "ietf-network-topology-state@2018-02-26.yang" in their list is actually just "ietf-network-topology@2018-02-26.yang" renamed, and that "ietf-voucher@2018-04-06.yang" does not have the same revision as the module that is part of RFC8366 (2018-05-09). Also, in at least two instances, I managed to somehow download a blank module file, which then magically downloaded properly after a retry. Benoit went through the trouble of gathering modules from different sources and his blog entry includes standard modules [1]. I dare say that this blog entry is a much more reliable source compared to the IANA site. [1] - https://www.claise.be/2018/06/ietf-yang-modules-statistiques/ > Or you can get them from some 3rd party place like yang-catalog, or > pyang. > Pyang git repo has the files without revisions in their name, which is somewhat awkward. Jernej > > /martin > > >> It would be wonderful if this could be described in the Netmod WG >> wiki. >> >> (And sorry, no but I am not volunteering :-(   ) >> >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Oct 10 04:16:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC780130ED3 for ; Wed, 10 Oct 2018 04:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCMb7hXyihOB for ; Wed, 10 Oct 2018 04:16:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 665F9130ED9 for ; Wed, 10 Oct 2018 04:16:13 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D57011B03A00 for ; Wed, 10 Oct 2018 13:16:10 +0200 (CEST) Date: Wed, 10 Oct 2018 13:16:10 +0200 (CEST) Message-Id: <20181010.131610.1510095762179710072.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 11:16:18 -0000 Hi, While reviewing restconf-notif, I saw this example: { "ietf-subscribed-notifications:input": { "stream": "NETCONF", "stream-xpath-filter": "/ds:foo/", "dscp": "10" } } Note the "stream-xpath-filter". It has a prefix in the XPath string. How are prefixes declared when JSON is used? The leaf "stream-xpath-filter" says: o The set of namespace declarations are those in scope on the 'stream-xpath-filter' leaf element. (I think I provided that text...) This assumes that the encoding is XML, or at leas that the encoding can somehow transfer namespace declarations. How is this supposed to work with JSON? /martin From nobody Wed Oct 10 05:33:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CC9130EF6; Wed, 10 Oct 2018 05:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVAq534HvQ8x; Wed, 10 Oct 2018 05:33:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6C130EEB; Wed, 10 Oct 2018 05:33:01 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A60B1B039FA; Wed, 10 Oct 2018 14:32:58 +0200 (CEST) Date: Wed, 10 Oct 2018 14:32:57 +0200 (CEST) Message-Id: <20181010.143257.2013021260712498361.mbj@tail-f.com> To: ekr@rtfm.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net From: Martin Bjorklund In-Reply-To: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> References: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 12:33:07 -0000 Hi, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-netmod-schema-mount-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3506 > > > > DETAIL > S 4. > > > > It is worth emphasizing that the nodes specified in > > "parent-reference" leaf-list are available in the mounted schema only > > for XPath evaluations. In particular, they cannot be accessed there > > via network management protocols such as NETCONF [RFC6241] or > > RESTCONF [RFC8040]. > > What are the security implications of this XPath reference outside the > mount jail? Specifically, how does it interact with the access control > for the enclosing module. There is no such interaction, since access control comes into play when some external entity accesses the data through some management protocol, and the nodes from the "parent-reference" expressions cannot be accessed via management protocols. The last sentence of the quoted paragraph was supposed to make this clear, but it seems we might need some additional explanation? /martin From nobody Wed Oct 10 05:40:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0883130EFC for ; Wed, 10 Oct 2018 05:40:45 -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] 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 4r6U43kTCKlB for ; Wed, 10 Oct 2018 05:40:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBD5130EF9 for ; Wed, 10 Oct 2018 05:40:42 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 156EB1821137; Wed, 10 Oct 2018 14:48:23 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id C93221821137; Wed, 10 Oct 2018 14:48:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20181010.131610.1510095762179710072.mbj@tail-f.com> References: <20181010.131610.1510095762179710072.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Wed, 10 Oct 2018 14:40:37 +0200 Message-ID: <8736tevut6.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 12:40:46 -0000 Martin Bjorklund writes: > Hi, > > While reviewing restconf-notif, I saw this example: > > { > "ietf-subscribed-notifications:input": { > "stream": "NETCONF", > "stream-xpath-filter": "/ds:foo/", > "dscp": "10" > } > } > > Note the "stream-xpath-filter". It has a prefix in the XPath string. > How are prefixes declared when JSON is used? > > The leaf "stream-xpath-filter" says: > > o The set of namespace declarations are those in scope on > the 'stream-xpath-filter' leaf element. > > (I think I provided that text...) > > This assumes that the encoding is XML, or at leas that the encoding > can somehow transfer namespace declarations. It can't. There are two options: 1. have different representations of this value in XML and JSON, analogically to instance indentifiers (sec. 6.11 in RFC 7951). 2. use a module name rather than a prefix in XML, too. I would suggest #2. Lada > > How is this supposed to work with JSON? > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 06:34:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8AF130F08 for ; Wed, 10 Oct 2018 06:34:13 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.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 qm7d5If-mQKQ for ; Wed, 10 Oct 2018 06:34:11 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 DE91D130F05 for ; Wed, 10 Oct 2018 06:34:06 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id j4-v6so4886020ljc.12 for ; Wed, 10 Oct 2018 06:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c2snOwmX9es8qS2OmWIkdO059cHoAdhCrggrEUFPAzs=; b=sc2m4rxcdYlN+S928SrnCuKzbzMSJOmloTXQMoQoGQHF3Zt0cTBbZ9xZ4TJv3JMOvr yvRuPgPYTDsFAViU6/L1NKE3V6S5mIZKVCHjyTQuuCkaLQpH4vw8sMFkZTOYNS8LQf3h CwcWA0YUwUmK17LCNTpOd3S0s/W3gK3PzquILzXeko+pPaJufdWxjuGuS/ntMVzhWSOV Ot4YgvoqlHd81NbpjGNNmRj/uGjFnkplEBD/J0cB4LOxb6lQGLjswopMf5NrQFF7JSyI IaQi2TouD2xdVBCjupXiSHXtj5hC/mGdcYg1ohxbKtxTXAxuudS2vKD1e8VnrQ71kN+T 7HnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c2snOwmX9es8qS2OmWIkdO059cHoAdhCrggrEUFPAzs=; b=q1D/j3mwkRgJFVzT8W19JRiAoy3KfnDZpYPAf4JIDw2bczX0CJxzINe+SUoqkBSjmQ qgVyoTSoBtx/rUDVMSKhOE0O1g9fg0Kj+cgDB2EJ47p0ObMH6W3+LdKhqQMBYuiwzs2f Pk5X1RVeKAdkQNFpSP82OFwm2FJ+rRiPuyMiPl9aVj6yq/EEe8QwXFv8m1DW/Auaurmi yN0YzvnaZn9gLJZxJFQHTiSjQJn8OZFDpMOrUs5tOs0QNSTqRL/o9K82PvWOo1ghAg6g PFsHiA+/a8xMDNdYfOrBZUCdXmOBpDuxu3bA6kHbjCG4tPtuBFUYn6FP8m2NT/OgpYhX 2ZTA== X-Gm-Message-State: ABuFfogRCockbT8eHd8A40Y4Y4Ljz2shdrShVO9kn9rZoXSyNIqtTYBU p9PVXX5XxdqFDHcrNC8qj456zpuEo51Cf+l9uMTWog== X-Google-Smtp-Source: ACcGV63YyLmz1dDygu7nDUzvMd8dHy7fyypB2KBBDlVtL+zME9mrIM83RLYoiSDylt5198RWESm6qHty4dNB/HpNw7k= X-Received: by 2002:a2e:7017:: with SMTP id l23-v6mr20501297ljc.160.1539178444840; Wed, 10 Oct 2018 06:34:04 -0700 (PDT) MIME-Version: 1.0 References: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> <20181010.143257.2013021260712498361.mbj@tail-f.com> In-Reply-To: <20181010.143257.2013021260712498361.mbj@tail-f.com> From: Eric Rescorla Date: Wed, 10 Oct 2018 06:33:27 -0700 Message-ID: To: mbj@tail-f.com Cc: IESG , NetMod WG Chairs , NetMod WG , joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger Content-Type: multipart/alternative; boundary="000000000000737fab0577dfe8b2" Archived-At: Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:34:14 -0000 --000000000000737fab0577dfe8b2 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund wrote: > Hi, > > Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-netmod-schema-mount-11: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506 > > > > > > > > DETAIL > > S 4. > > > > > > It is worth emphasizing that the nodes specified in > > > "parent-reference" leaf-list are available in the mounted schema > only > > > for XPath evaluations. In particular, they cannot be accessed > there > > > via network management protocols such as NETCONF [RFC6241] or > > > RESTCONF [RFC8040]. > > > > What are the security implications of this XPath reference outside the > > mount jail? Specifically, how does it interact with the access control > > for the enclosing module. > > There is no such interaction, since access control comes into play > when some external entity accesses the data through some management > protocol, and the nodes from the "parent-reference" expressions cannot > be accessed via management protocols. > > The last sentence of the quoted paragraph was supposed to make this > clear, but it seems we might need some additional explanation? > Yes, I think so. I guess I'm not clear on what the XPath expressions are for if they can't be accessed via the management protocols. How can they be used? -Ekr > > > /martin > --000000000000737fab0577dfe8b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Oct 10, 2018 at 5:32 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Eric Rescorla <ekr@rtf= m.com> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-11: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-netmod-schema-mount/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3506<= /a>
>
>
>
> DETAIL
> S 4.
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 It is worth emphasizing that the nodes specif= ied in
> >=C2=A0 =C2=A0 =C2=A0 "parent-reference" leaf-list are av= ailable in the mounted schema only
> >=C2=A0 =C2=A0 =C2=A0 for XPath evaluations.=C2=A0 In particular, t= hey cannot be accessed there
> >=C2=A0 =C2=A0 =C2=A0 via network management protocols such as NETC= ONF [RFC6241] or
> >=C2=A0 =C2=A0 =C2=A0 RESTCONF [RFC8040].
>
> What are the security implications of this XPath reference outside the=
> mount jail? Specifically, how does it interact with the access control=
> for the enclosing module.

There is no such interaction, since access control comes into play
when some external entity accesses the data through some management
protocol, and the nodes from the "parent-reference" expressions c= annot
be accessed via management protocols.

The last sentence of the quoted paragraph was supposed to make this
clear, but it seems we might need some additional explanation?

Yes, I think so. I guess I'm not clear on what = the XPath expressions are for if they
can't be accessed via t= he management protocols. How can they be used?

-Ek= r




/martin
--000000000000737fab0577dfe8b2-- From nobody Wed Oct 10 06:35:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C1C130F02; Wed, 10 Oct 2018 06:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz7nvf86uVUM; Wed, 10 Oct 2018 06:35:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1DD5130EFB; Wed, 10 Oct 2018 06:35:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id A0B0B1B039FA; Wed, 10 Oct 2018 15:35:29 +0200 (CEST) Date: Wed, 10 Oct 2018 15:35:28 +0200 (CEST) Message-Id: <20181010.153528.100217893480849067.mbj@tail-f.com> To: kaduk@mit.edu Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com, lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> References: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:35:34 -0000 Hi, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-netmod-schema-mount-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Whenever we introduce a new namespace "sub-hierarchy" there is some level > of risk about surpirses with respect to the security properties of the > combined system. I appreciate that the mounted schemas are "jailed" into > their own subtree except for the specific exceptions for XPath access, > which helps a lot. But there may still be potential for surprise with > respect to, e.g., access control on mounted schemas, if an administrator > previously assumed that such controls would only be needed at the > top-level. The document itself doesn't give me a great picture of to what > extent these risks and the possible consequences of the new nested > structure have been considered; I'd be happy to hear if they've been > thought about a lot already and the conclusion was that the situation is so > boring that nothing needs to be mentioned in the document. The intention was that this is covered in Section 7, Interaction with the Network Configuration Access Control Model (NACM). But it is probably a good idea to explicitly mention this in the Security Considerations section as well (together with your last point below). So maybe add a paragraph at the end of Section 11: It is important to take the security considerations for all nodes in the mounted schemas into account, and control access to these nodes by using the mechanism described in Section 7. > Section 3.3 > > If multiple mount points with the same name are defined in the same > module - either directly or because the mount point is defined in a > grouping and the grouping is used multiple times - then the > corresponding "mount-point" entry applies equally to all such mount > points. > > Does this mean that the multiple mount points must serve the same > data/contents, or just that they must use the same schema? > (Is this related to "inline" vs. "shared-schema"?) No, this document intentionally doesn't assume anything about the source of the instance data (as explained in section 1). So the answer is that they just use the same schema. > Section 3.4 > > So this means that there can be multiple > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different > locations in the hierarchy? When I was first reading the document, the > design seemed fairly clean with just a single list of mount-points at the > "top-level" that tracks everything, but this kind of recursion seems like > it would make implementation potentially quite complex. What kind of > implementation experience do we have that can replace my half-informed > suppositions about complexity? I agree with you that multiple levels of mounting probably can be complex. But there is nothing in the design of schema mount that prohibits this. In fact, it "falls out for free" from the design. A 2-level example is a physical device with LNEs (draft-ietf-rtgwg-lne-model) which has NIs (draft-ietf-rtgwg-ni-model). > Section 4 > > Therefore, schema mount also allows for such references. For every > mount point in the "shared-schema" case, it is possible to specify a > leaf-list named "parent-reference" that contains zero or more XPath > 1.0 expressions. [...] > > editorial: """the "shared-schema" case""" reads oddly to me; it might be > clearer to refer to schemas mounted using "shared-schema" instead. As in, > """For every mount point under "shared-schema", [...]""" We use the wording "in the 'shared-schema' case" in a couple of places. I don't think "mount point under 'shared-schema'" is correct. > Can we get a reference added for XPath? Sure, I will add this. > It's still a little unclear to me exactly how a node in the mounted tree > constructs an XPath expression to refer to the parent-reference > nodes It's rather the other way around. If a node in the mounted schema has an XPath expression that refers to a node that is not part of the jailed mounted schema, that node can be brought in by the parent-reference expressions. An example of this is given in A.3 where an "outgoing-interface" (which is a reference to /if:interfaces/if:interface/if:name) works thanks to the parent-reference. >, but > I did not read very far down the reference chain and maybe this is going to > be clear to a practitioner without any more text in the document. > Basically, do I need to know where I am mounted in order to construct > references to nodes in the parent? > > Section 7 > > NACM "can be used" to control access to mounted nodes. Is there a risk > that administrators will be "unpleasantly surprised" by mounted nodes by > default not receiving access control, in cases when access control is > already configured at the top level? Mounted nodes are no different that normal nodes in this regard; i.e., if NACM is configured to provide read access by default, this read access is applied to all nodes, mounted or not. Maybe we should do: OLD: If NACM [RFC8341] is implemented on a server, it can be used to control access NEW: If NACM [RFC8341] is implemented on a server, it is used to control access to emphasize that no additional steps need to be taken by the administrator if NACM is used in the first place. > Section 9 > > Should the top-level module description be using the RFC 8174 boilerplate > instead of thet 2119 boilerplate? Yes, I will fix. > Should the requirement for servers that mount any schema to also mount > ietf-yang-library under the mountpoint be mentioned somewhere other than > the description for the 'inline' and 'shared-schema' containers (i.e., in > the discussion text)? Section 3.3 says: The mounted schema is determined at run time: every instance of the mount point that exists in the operational state MUST contain a copy of YANG library data that defines the mounted schema exactly as for a top-level schema. > Section 11 > > We should probably also have some bland statement about how "the security > considerations for mounted schemas continue to apply to the nodes in the > mounted tree". Yes, see my proposed text above. /martin From nobody Wed Oct 10 06:38:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656A8130F08; Wed, 10 Oct 2018 06:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrx9a4zjEuDV; Wed, 10 Oct 2018 06:38:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE0130EFC; Wed, 10 Oct 2018 06:38:33 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id B30AE1B039FA; Wed, 10 Oct 2018 15:38:31 +0200 (CEST) Date: Wed, 10 Oct 2018 15:38:31 +0200 (CEST) Message-Id: <20181010.153831.1958991667250114039.mbj@tail-f.com> To: ekr@rtfm.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net From: Martin Bjorklund In-Reply-To: References: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> <20181010.143257.2013021260712498361.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:38:35 -0000 Eric Rescorla wrote: > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund wrote: > > > Hi, > > > > Eric Rescorla wrote: > > > Eric Rescorla has entered the following ballot position for > > > draft-ietf-netmod-schema-mount-11: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Rich version of this review at: > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506 > > > > > > > > > > > > DETAIL > > > S 4. > > > > > > > > It is worth emphasizing that the nodes specified in > > > > "parent-reference" leaf-list are available in the mounted schema > > only > > > > for XPath evaluations. In particular, they cannot be accessed > > there > > > > via network management protocols such as NETCONF [RFC6241] or > > > > RESTCONF [RFC8040]. > > > > > > What are the security implications of this XPath reference outside the > > > mount jail? Specifically, how does it interact with the access control > > > for the enclosing module. > > > > There is no such interaction, since access control comes into play > > when some external entity accesses the data through some management > > protocol, and the nodes from the "parent-reference" expressions cannot > > be accessed via management protocols. > > > > The last sentence of the quoted paragraph was supposed to make this > > clear, but it seems we might need some additional explanation? > > > > Yes, I think so. I guess I'm not clear on what the XPath expressions are > for if they > can't be accessed via the management protocols. How can they be used? These are XPath expressions defined in the YANG models themselves, such as "must" expressions or "leafrefs". The description of "parent-reference" refer to them as: [...] XPath expressions whose context nodes are defined in the mounted schema /martin From nobody Wed Oct 10 06:49:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3D130F05 for ; Wed, 10 Oct 2018 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 DKb-sPyR9IF4 for ; Wed, 10 Oct 2018 06:49:16 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40097.outbound.protection.outlook.com [40.107.4.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 C2114130ED8 for ; Wed, 10 Oct 2018 06:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TTOmGeHwWhd61d58zNCTVXGHmtxOs1sQRDIw2fIyaqQ=; b=KSRL3wGOcY4kw52iVpZf4FsozwBvSsY9SB50KyHYcdCwFN5FxWIILn37PIgIS1lLyqExS0nyE+gk+un9Jv8hr/NZzkTmwN8m7ZHR0zU+eX/ea5tVc/rnPweiIa7WHxihB00PT4vPgkCJ4ATm/ZkezPOSINewx6iNGgjAV/Gz8TQ= Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB1038.eurprd07.prod.outlook.com (10.161.111.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.19; Wed, 10 Oct 2018 13:49:08 +0000 Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::a8a1:3ccb:986d:dad3]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::a8a1:3ccb:986d:dad3%5]) with mapi id 15.20.1228.020; Wed, 10 Oct 2018 13:49:08 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Michael Rehder , "netmod@ietf.org" Thread-Topic: WHEN statement within mandatory objects doesn't ensure presence of the mandatory object Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAApogGQ Date: Wed, 10 Oct 2018 13:49:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1038; 6:+ql9oZZRiG/7DWbny+AmUPw3npqlAOJpiqEjRxqrdEgylqx1n4jeg1ZhzebhWXelQIS7t+T8w0ScSoe7vWwWNAgsyGK6e5SbpDWIAdiviOaTP8YyC5jiPFO1k/U9CD4f1yGj9M7hXfskZqQAswXt2ZT5iGXALGS3Sdt7LumH5jhKkEJDosrK+kvEgfUJNkU0lDWfmCIzgqELh70YU84H4VrJA42MZ5owiPOWC3OQs7WrEh0GCO/gUjm1OvsLnmAE+B3V8vWnhlpeKXr2NXEAczk6+g7maj7qv3ehHzRRrxAgHw/cPtdARTlS0meRe7ZHyslGckYO6KKlr6wZGLEaJgARJWT+igfpOzHtbkwcDUttuQb/FIzUXYIeC9cOVtT0jt0LJyl9Tjlctzm8BZrC0fzLlYT/Bdxm3X4YHnds6MwCHD6XeHZpfio3rWLytEX9zCeX1MT0PAeAYuzSNR33MQ==; 5:eDBxfiw9LEt93YjZcs1EY1HZn3SpJ5oQ0++JpAdvQKqUJ9ddnuqwTAn+HeSHsdZOOeMNu1R6W75j5ER+6oThlFK/AYl1Ai+IJhagyd7PHrim9EpBkSmN4gM3rM1OIB5nx29NHve3mIUgkg4ZZNk0QTLRpFPgCyc7pokTerYw8Z0=; 7:jWrvlQs8YdD4kEb9x2y7vCONERkCS+THDPCkob00Gq6VjHapZC3FxdhLE65TTBeKqhmuKvXpFyAIRabI/dQ4HljphNVl5NZurqSTLqTO1aRfjLdz1RnJET1o6o21RbSQKqX2QzA4bWWKIRug865GDL+1TaaFXX2repaXM8T2/M+5lVUuL135SPeZoVwyBjv3Pf/+vomUVMr4fINKmQdJy1YYXnhA80cwSNvGge1RyiyMX+eyDMQ/RBdOe8D9swH4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5922e087-4579-458c-e700-08d62eb72691 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:VI1PR07MB1038; x-ms-traffictypediagnostic: VI1PR07MB1038: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991055); SRVR:VI1PR07MB1038; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1038; x-forefront-prvs: 08213D42D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(366004)(136003)(51444003)(189003)(199004)(6246003)(86362001)(53936002)(476003)(6306002)(54896002)(9686003)(55016002)(6436002)(229853002)(11346002)(33656002)(25786009)(99286004)(6116002)(3846002)(790700001)(102836004)(110136005)(6346003)(486006)(446003)(7696005)(76176011)(66066001)(8936002)(2900100001)(74316002)(71190400001)(71200400001)(5660300001)(256004)(478600001)(6506007)(53546011)(81156014)(9326002)(81166006)(26005)(2906002)(8676002)(186003)(14454004)(68736007)(106356001)(7736002)(105586002)(97736004)(2501003)(316002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1038; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; x-microsoft-antispam-message-info: cisucTIk4HD5h2rVdEI5Iq8uXe6fJ2lY0RoqWoNrE58jehJ+oQsnx1KxiCzSOqDafGwhiqAs6evHrAYAUKctIbbwCBa1YwC2DrGs/x272T5sQAHLeqGaO3r6biSkFqLBcDGLlTUOn7WHEQ9IDGfsgBpGrac3DJ5LB8WY8UgZ5plbBQJ4onUoeFYDPcCpTx94/4MT/cj/jfn0ttIcTTlcpX4CtKAyLN/+CTWS5yIJdJFGRz+tnzL6gJ2wgk4Nu87a2XOgjm9JyszTcHLnNgrjQWOUWJT7QYS8+JQcZetqdUum9MRdxmIKwvN3qcEPDkEXF+ZSoUuB63YVbvLh0agc84P1+2Tp7/c318p4LO90HIrYTGYxlVO9IJysNDP/BjqR0XY4Wx8jBE2BX+as63KvgQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB39811849476E3C09CDE8516C9BE00VI1PR07MB3981eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5922e087-4579-458c-e700-08d62eb72691 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2018 13:49:07.9822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1038 Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:49:19 -0000 --_000_VI1PR07MB39811849476E3C09CDE8516C9BE00VI1PR07MB3981eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlrZSwNClBsZWFzZSBzZWUgYmVsb3cuDQpKYXNvbg0KDQpGcm9tOiBuZXRtb2QgPG5ldG1v ZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSZWhkZXINClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgOSwgMjAxOCAxOjUxIFBNDQpUbzogbmV0bW9kQGlldGYub3JnDQpTdWJq ZWN0OiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9l c24ndCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3QNCg0KSSBoYXZlIGEg cXVlc3Rpb24gYWJvdXQg4oCcd2hlbuKAnSBhbmQgbWFuZGF0b3J5IG9iamVjdHMuDQoNCkl0IHNl ZW1zIHRvIG1lIHRoYXQgdGhlIGltcGxlbWVudGVkIHNlbWFudGljcyBvZiDigJx3aGVu4oCdIGFy ZSByZWFsbHkg4oCcb3B0aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5jbG9zaW5nIG9iamVj dCBjYW4gYmUgYWJzZW50IGV2ZW4gdGhvdWdoIGl0IGlzIG1hbmRhdG9yeSBhbmQgdGhlIOKAnHdo ZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUuDQpUaGUgUkZDIGNvdWxkIGJlIGNsZWFyZXIgYWJvdXQg dGhpcy4NCg0KRXhhbXBsZQ0KDQogICBsZWFmIGNvbG9yIHsNCiAgICAgZW51bWVyYXRpb24gIHsN CiAgICAgICAgZW51bSDigJxibHVl4oCdOw0KICAgICAgICBlbnVtIOKAnGJsYWNr4oCdOw0KICAg ICB9DQogICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgfQ0KICAgY29udGFpbmVyIGZvbyB7DQogICAg ICB3aGVuIC4uL2NvbG9yID0g4oCYYmx1ZeKAmTsNCiAgICAgIGV0Yy4NCiAgIH0NCg0K4oCcZm9v 4oCdIGlzIG9wdGlvbmFsIGR1ZSB0byB0aGUgcHJlc2VuY2Ugb2YgdGhlIOKAnHdoZW7igJ0gc3Rh dGVtZW50IGV2ZW4gdGhvdWdoIHRoZSBvYmplY3QgaXMgbWFuZGF0b3J5IChzYW1lIGlzIHRydWUg Zm9yIG1hbmRhdG9yeSBsZWFmLCBtaW4tZWxlbWVudHM9MSBsaXN0IGV0Yy4pLg0KWz4+SlRTOiBd ICBXaGF0IGRvIHlvdSBtZWFuIGJ5ICJ0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSIgPyAgSSBzZWUg dGhhdCBsZWFmIGNvbG9yIGlzIG1hbmRhdG9yeSAoc28gaXQgbXVzdCBoYXZlIGEgdmFsdWUgb2Yg ZWl0aGVyIGJsYWNrIG9yIGJsdWUpLiAgQnV0IHRoZSBjb250YWluZXIgZm9vIGlzIG5vdCBtYW5k YXRvcnkuDQoNClRoaXMgaXMgY29uc2lkZXJlZCB2YWxpZCBYTUwgZm9yIHRoZSBhYm92ZQ0KICAg IDxjb2xvcj5ibHVlPC9jb2xvcj4NCg0KSW4gbXkgdmlldyB0aGlzIG1ha2VzIGNvbmRpdGlvbmFs bHkgdmFyaWFudCBzY2hlbWFzIOKAnGxvb3Nl4oCdIGluIHRoZWlyIGVuZm9yY2VtZW50IChzb21l IHNjZW5hcmlvcyBjYW4gdXNlIGNob2ljZSBidXQgaXQgZG9lc27igJl0IGNvdmVyIGV2ZXJ5dGhp bmcpLg0KDQpJIHRoaW5rIHRoYXQgbWFuZGF0b3J5IHNob3VsZCBiZSByZXNwZWN0ZWQgZm9yIHRo ZSBlbmNsb3Npbmcgb2JqZWN0cyBvZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50Lg0KVGhhdCBpcywg YSBtYW5kYXRvcnkgb2JqZWN0IG11c3QgYmUgcHJlc2VudCB3aGVuIGl0cyDigJx3aGVu4oCdIGNs YXVzZSBob2xkcyB0cnVlIGFuZCBhIFNjaGVtYXRyb24gc3RhdGVtZW50IHNob3VsZCBlbmZvcmNl IHRoYXQuDQpbPj5KVFM6IF0gV2UgY2FuJ3QgY2hhbmdlIHRoYXQgZGVmaW5pdGlvbiBub3cuIEkg ZG9uJ3Qga25vdyBhbGwgdGhlIGRldGFpbHMgb2YgdGhlIHJhdGlvbmFsZSBidXQgIndoZW4iIGlz IGRlZmluZWQgc3VjaCB0aGF0IGl0cyBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVudCBp cyBvbmx5IHZhbGlkIHdoZW4gdGhlIGNvbmRpdGlvbiBpbiB0aGUgIndoZW4iIGlzIHRydWUuIEJ1 dCB0aGF0IGRvZXNuJ3QgbWVhbiB0aGF0IHBhcmVudCBub2RlIGlzIG1hbmRhdG9yeS4gSW4gb3Ro ZXIgd29yZHMgLT4gYSAid2hlbiIgY2FuIG9ubHkgcmVtb3ZlIGEgbm9kZSAoZnJvbSB0aGUgc2No ZW1hKSwgaXQgY2FuJ3QgZW5mb3JjZSB0aGF0IGEgbm9kZSBleGlzdHMgKGluIGluc3RhbmNlIGRh dGEpLg0KDQpXaGF0IGlzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBjdXJyZW50IFlBTkcgcnVs ZXMgYmVoYXZpb3IsIHRoYXQgdGhlIOKAnHdoZW7igJ0gU2NoZW1hdHJvbiBtYXBwaW5nIGRvZXNu 4oCZdCBjaGVjayBmb3IgcHJlc2VuY2Ugb2YgdGhlIGVuY2xvc2luZyBtYW5kYXRvcnkgb2JqZWN0 Pw0KDQp0aGFua3MNCk1pa2UgUmVoZGVyDQoNCg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3Jt IGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVt LiBBbnkgZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQg dXNpbmcgc3VjaCBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3Zp ZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBl bWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNo IHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQo= --_000_VI1PR07MB39811849476E3C09CDE8516C9BE00VI1PR07MB3981eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBNaWtlLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+UGxlYXNlIHNlZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkph c29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGll dGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWNoYWVsIFJlaGRlcjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDksIDIwMTggMTo1MSBQTTxicj4NCjxiPlRvOjwvYj4g bmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRtb2RdIFdIRU4gc3RhdGVt ZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0 aGUgbWFuZGF0b3J5IG9iamVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCDigJx3 aGVu4oCdIGFuZCBtYW5kYXRvcnkgb2JqZWN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IHNlZW1z IHRvIG1lIHRoYXQgdGhlIGltcGxlbWVudGVkIHNlbWFudGljcyBvZiDigJx3aGVu4oCdIGFyZSBy ZWFsbHkg4oCcb3B0aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5jbG9zaW5nIG9iamVjdCBj YW4gYmUgYWJzZW50IGV2ZW4gdGhvdWdoIGl0IGlzIG1hbmRhdG9yeSBhbmQgdGhlIOKAnHdoZW7i gJ0gY2xhdXNlIGhvbGRzIHRydWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBSRkMgY291bGQgYmUgY2xlYXJlciBhYm91 dCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RXhhbXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7IGxlYWYgY29sb3IgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51 bWVyYXRpb24mbmJzcDsgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZW51bSDigJxibHVl4oCdOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZW51bSDigJxibGFja+KAnTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVl OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgY29udGFpbmVyIGZvbyB7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuIC4uL2NvbG9yID0g4oCY Ymx1ZeKAmTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV0Yy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPuKAnGZvb+KAnSBpcyBvcHRpb25hbCBkdWUgdG8gdGhlIHByZXNlbmNlIG9mIHRoZSDigJx3 aGVu4oCdIHN0YXRlbWVudCBldmVuIHRob3VnaCB0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSAoc2Ft ZSBpcyB0cnVlIGZvciBtYW5kYXRvcnkgbGVhZiwgbWluLWVsZW1lbnRzPTEgbGlzdCBldGMuKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBs YW5nPSJFTi1VUyI+WyZndDsmZ3Q7SlRTOiBdICZuYnNwO1doYXQgZG8geW91IG1lYW4gYnkgJnF1 b3Q7dGhlIG9iamVjdCBpcyBtYW5kYXRvcnkmcXVvdDsgPyZuYnNwOyBJIHNlZSB0aGF0IGxlYWYg Y29sb3IgaXMgbWFuZGF0b3J5IChzbyBpdCBtdXN0IGhhdmUgYSB2YWx1ZSBvZiBlaXRoZXIgYmxh Y2sgb3IgYmx1ZSkuJm5ic3A7IEJ1dCB0aGUgY29udGFpbmVyIGZvbyBpcyBub3QgbWFuZGF0b3J5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGlzIGNvbnNpZGVyZWQgdmFsaWQgWE1M IGZvciB0aGUgYWJvdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtjb2xvciZndDtibHVl Jmx0Oy9jb2xvciZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIG15IHZpZXcgdGhpcyBtYWtlcyBj b25kaXRpb25hbGx5IHZhcmlhbnQgc2NoZW1hcyDigJxsb29zZeKAnSBpbiB0aGVpciBlbmZvcmNl bWVudCAoc29tZSBzY2VuYXJpb3MgY2FuIHVzZSBjaG9pY2UgYnV0IGl0IGRvZXNu4oCZdCBjb3Zl ciBldmVyeXRoaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhhdCBtYW5kYXRvcnkg c2hvdWxkIGJlIHJlc3BlY3RlZCBmb3IgdGhlIGVuY2xvc2luZyBvYmplY3RzIG9mIGEg4oCcd2hl buKAnSBzdGF0ZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYXQgaXMsIGEgbWFuZGF0b3J5IG9iamVjdCBtdXN0IGJl IHByZXNlbnQgd2hlbiBpdHMg4oCcd2hlbuKAnSBjbGF1c2UgaG9sZHMgdHJ1ZSBhbmQgYSBTY2hl bWF0cm9uIHN0YXRlbWVudCBzaG91bGQgZW5mb3JjZSB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5bJmd0OyZn dDtKVFM6IF0gV2UgY2FuJ3QgY2hhbmdlIHRoYXQgZGVmaW5pdGlvbiBub3cuIEkgZG9uJ3Qga25v dyBhbGwgdGhlIGRldGFpbHMgb2YgdGhlIHJhdGlvbmFsZSBidXQgJnF1b3Q7d2hlbiZxdW90OyBp cyBkZWZpbmVkIHN1Y2ggdGhhdCBpdHMgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQg aXMgb25seSB2YWxpZCB3aGVuIHRoZSBjb25kaXRpb24gaW4gdGhlICZxdW90O3doZW4mcXVvdDsg aXMNCiB0cnVlLiBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gdGhhdCBwYXJlbnQgbm9kZSBpcyBtYW5k YXRvcnkuIEluIG90aGVyIHdvcmRzIC0mZ3Q7IGEgJnF1b3Q7d2hlbiZxdW90OyBjYW4gb25seSBy ZW1vdmUgYSBub2RlIChmcm9tIHRoZSBzY2hlbWEpLCBpdCBjYW4ndCBlbmZvcmNlIHRoYXQgYSBu b2RlIGV4aXN0cyAoaW4gaW5zdGFuY2UgZGF0YSkuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBpcyB0aGUgcmF0aW9uYWxlIGJlaGluZCB0 aGUgY3VycmVudCBZQU5HIHJ1bGVzIGJlaGF2aW9yLCB0aGF0IHRoZSDigJx3aGVu4oCdIFNjaGVt YXRyb24gbWFwcGluZyBkb2VzbuKAmXQgY2hlY2sgZm9yIHByZXNlbmNlIG9mIHRoZSBlbmNsb3Np bmcgbWFuZGF0b3J5IG9iamVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW5rczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NaWtl IFJlaGRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21h cmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPGVtPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRm b3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lz dGVtLiBBbnkgZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9y ZWQgdXNpbmcgc3VjaCBzeXN0ZW0gYW5kIGFyZQ0KIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkg cHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5kaW5n IG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9m IHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48 L3NwYW4+PC9lbT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR07MB39811849476E3C09CDE8516C9BE00VI1PR07MB3981eurp_-- From nobody Wed Oct 10 06:59:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8534A130F0A for ; Wed, 10 Oct 2018 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO2pREZLOdTV for ; Wed, 10 Oct 2018 06:59:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47695130F05 for ; Wed, 10 Oct 2018 06:59:17 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 713F71B039FB; Wed, 10 Oct 2018 15:59:16 +0200 (CEST) Date: Wed, 10 Oct 2018 15:59:15 +0200 (CEST) Message-Id: <20181010.155915.278994099457235212.mbj@tail-f.com> To: lhotka@nic.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <8736tevut6.fsf@nic.cz> References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 13:59:20 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > While reviewing restconf-notif, I saw this example: > > > > { > > "ietf-subscribed-notifications:input": { > > "stream": "NETCONF", > > "stream-xpath-filter": "/ds:foo/", > > "dscp": "10" > > } > > } > > > > Note the "stream-xpath-filter". It has a prefix in the XPath string. > > How are prefixes declared when JSON is used? > > > > The leaf "stream-xpath-filter" says: > > > > o The set of namespace declarations are those in scope on > > the 'stream-xpath-filter' leaf element. > > > > (I think I provided that text...) > > > > This assumes that the encoding is XML, or at leas that the encoding > > can somehow transfer namespace declarations. > > It can't. There are two options: > > 1. have different representations of this value in XML and JSON, > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > 2. use a module name rather than a prefix in XML, too. > > I would suggest #2. Hmm, so you mean change the leaf "stream-xpath-filter" to say: o The set of namespace declarations has one member for each YANG module supported by the server. This member maps from the YANG module name to the YANG module namespace. This means that in the XPath expression, the module name serves as the prefix. ... and then also give an example of this. This is probably what we need to do in all places where yang:xpath1.0 is used, going forward. Maybe even define a new type yang:xpath1.0-2 (name?) with the set of namespace declarations built-in. /martin > > Lada > > > > > How is this supposed to work with JSON? > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Wed Oct 10 07:28:24 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED217130E7D for ; Wed, 10 Oct 2018 07:28:21 -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] 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 etD6Zf_vlnXt for ; Wed, 10 Oct 2018 07:28:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 183BD130DD9 for ; Wed, 10 Oct 2018 07:28:19 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id BD7521821139; Wed, 10 Oct 2018 16:35:59 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 33C6D1821137; Wed, 10 Oct 2018 16:35:58 +0200 (CEST) From: Ladislav Lhotka To: Michael Rehder , "netmod\@ietf.org" In-Reply-To: References: Mail-Followup-To: Michael Rehder , "netmod\@ietf.org" Date: Wed, 10 Oct 2018 16:28:15 +0200 Message-ID: <87zhvlvpts.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 14:28:22 -0000 Michael Rehder writes: > I have a question about =E2=80=9Cwhen=E2=80=9D and mandatory objects. > > It seems to me that the implemented semantics of =E2=80=9Cwhen=E2=80=9D a= re really =E2=80=9Coptional when=E2=80=9D, in that the enclosing object can= be absent even though it is mandatory and the =E2=80=9Cwhen=E2=80=9D claus= e holds true. > The RFC could be clearer about this. > > Example > > leaf color { > enumeration { > enum =E2=80=9Cblue=E2=80=9D; > enum =E2=80=9Cblack=E2=80=9D; > } > mandatory true; > } > container foo { > when ../color =3D =E2=80=98blue=E2=80=99; > etc. > } > > =E2=80=9Cfoo=E2=80=9D is optional due to the presence of the =E2=80=9Cwhe= n=E2=80=9D statement even > though the object is mandatory (same is true for mandatory leaf, > min-elements=3D1 list etc.). Maybe you intended to have, e.g., a "mandatory true" leaf inside "container foo"? > This is considered valid XML for the above > blue Yes, it is, under current YANG rules, no matter what "etc." stands for. Note that evaluation of the XPath expression in this case (with "foo" missing) requires the peculiar procedure of sec. 7.21.5 in RFC 7950. > > In my view this makes conditionally variant schemas =E2=80=9Cloose=E2=80= =9D in their > enforcement (some scenarios can use choice but it doesn=E2=80=99t cover > everything). > > I think that mandatory should be respected for the enclosing objects > of a =E2=80=9Cwhen=E2=80=9D statement. That is, a mandatory object must = be present > when its =E2=80=9Cwhen=E2=80=9D clause holds true and a Schematron statem= ent should > enforce that. In fact, this is one case where the DSDL mapping (RFC 6110) deviates from YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG pattern, and are then required no matter what any "when" statements say (because RELAX NG validation comes before Schematron).=20=20 > > What is the rationale behind the current YANG rules behavior, that the > =E2=80=9Cwhen=E2=80=9D Schematron mapping doesn=E2=80=99t check for prese= nce of the enclosing > mandatory object? FWIW, I have been repeatedly protesting against this behaviour but without much luck. See for example https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html As a result, "when" is the trickiest feature in YANG by far. Lada > > thanks > Mike Rehder --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 08:23:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87534130F47 for ; Wed, 10 Oct 2018 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 OUyz9LqmcYds for ; Wed, 10 Oct 2018 08:23:37 -0700 (PDT) Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A09130E9A for ; Wed, 10 Oct 2018 08:23:35 -0700 (PDT) Received: from unknown (HELO ILHFDAGDRFE2.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 10 Oct 2018 18:23:31 +0300 Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE2 (10.237.240.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 18:23:31 +0300 Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 18:23:30 +0300 Received: from ILRNAEXCHEDGE01.corp.amdocs.com (10.233.34.167) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Wed, 10 Oct 2018 18:23:30 +0300 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 18:23:29 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5rWWCehGD4iMVEGCq42j59OoSJ1VqfbP5dMjAvuZ5UE=; b=HkpsxyTsMAvZZe5Ux2RfhTrejYVvfliEzLS9+DhS48Eh1pz7amZFcvxWoEH3845lxFA3VRTzkeUxjFVgLNikEGy5KtjPUOjSgxEBsfi922yY08nkZSGv2/Dlj5+ybaGaxi06/Hx1ugb79SwXCyWM/7imQr0wp/A79cpDmcYNeMA= Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4434.eurprd06.prod.outlook.com (20.176.214.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.28; Wed, 10 Oct 2018 15:23:27 +0000 Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%3]) with mapi id 15.20.1207.024; Wed, 10 Oct 2018 15:23:27 +0000 From: Michael Rehder To: Ladislav Lhotka , "netmod@ietf.org" CC: "Walker, Jason (Jason_Walker2@comcast.com)" Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDA= Date: Wed, 10 Oct 2018 15:23:27 +0000 Message-ID: References: <87zhvlvpts.fsf@nic.cz> In-Reply-To: <87zhvlvpts.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; x-originating-ip: [185.139.140.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR06MB4434; 6:8Tmk5lszjh7ucp4CQJ+1lXZViFHKIE3jiVBxwi06pUT0d6qF3czHkZQ5Pq8kXAFd36mRto9Ta1FUO880ODmzEA9qHgU4nqhH83H/uRT4LWWxIuHAOoqhBmBYLEdKfGGRW9CBgQzB6pnu+P7C9uU4DHneQp/zox2/NtfO6k9HxrwDoYz1/LyjVp74H+PvWoIH8wvoP8a/wYQNXMhm5oIp5qrj1aLUsJO9zWFg0SOrzkfDDaY4hdvE2G2JUeT6/5nuKn2pV7iWHUfUF2jhefcpNcGlqmAlCGyEyDNiHiwHuNrsZc16QCkoFr3Ysmnzur1/S7EgGt5TgrwcMTv/SpRLcVGct8wq3CdnJmZUz7nLvWycYdsJQxH35Yy3hmE6IA3nGk6o02oiHi2AtOvblKpbQG345abI7MT/RzpKengodMaGBxXf6VnbtjXtrN8t3WlcHNxkzYBrSPw2osAq41X7GQ==; 5:5/LdoQtKmyec9pDPt3eIgAiO8t+ldioSVcOcOH1Iw/YnO0Udluzv+vfIL8+W3OiReetfPefdCz5n15JK7S8mhfEJleu9Z/UtPqYMkmeqlFzazQZSBPUaHIhyz7ISG9NIIpyCdlMxy1QYTszeOYd3AG5Hm3UUEaPhY7P6Eed14PE=; 7:k4i44bnrYc9VRW4KE8qdXNO3Q3VyZXH9/aMCWlPklP1NY3K/MnC56SlnIWxNqEvZq0ieatvduZY7yDxX7sQd+ahPV2fFpICuktPjCM0yyMxAxi4REW3DbV4Q5b04oX4wbD0aqrbwL/NiF/I0zyJbJJKRHnl/qsvn4jaJfyda/BT0mikggFW7k5mIWX9NQk547CA4XW0IvPd/zKJZqtQnCDPo6ozvgWw5kklJ8pwePmxBvvl+Hhkd5S0Pr7zaG0dS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 89bf1bb8-118b-47c7-719a-08d62ec45419 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4434; x-ms-traffictypediagnostic: AM0PR06MB4434: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(17755550239193)(166566539817055); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991055); SRVR:AM0PR06MB4434; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4434; x-forefront-prvs: 08213D42D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(136003)(346002)(396003)(189003)(199004)(51444003)(13464003)(53936002)(6306002)(9686003)(76176011)(2906002)(7696005)(305945005)(53546011)(6506007)(110136005)(102836004)(66066001)(99286004)(8676002)(3846002)(229853002)(55016002)(6116002)(71190400001)(68736007)(74316002)(71200400001)(7736002)(11346002)(478600001)(446003)(476003)(86362001)(8936002)(316002)(6436002)(81156014)(81166006)(186003)(72206003)(33656002)(966005)(2501003)(6246003)(5660300001)(2900100001)(4326008)(25786009)(114624004)(97736004)(486006)(26005)(105586002)(14454004)(106356001)(256004)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4434; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DsF1TF0jqza4BvsAKpg4yP2/aK5dtDUjeTIXoHnHSf0RzGdFHXWoxma5y97x976eMaZ8NSq8hlXmI+og6gewyKwZiM99GCpXY+/r2CXGbv/LXI7i1TMKnRhypFPHBvpxmqrnICW+Odc1vGVIJ40zETITuyKuee9bs/YxtaIo5ydoliKLvxbebXDFqIzPIds6dUkThkYAqbpLdNMzLWSLZNxGsbRM+Ha1KIeXFpemoXmvgkWqgeLw3C5aSwmCiSGv6C+Ql6SML5b2BY4o5M3mH/0Xj0hBmcPblVLK8qKQ7NQdI4HhmYbw+daNaASDCPzJ+IZuMeI79siLFxdcRCRj6NOpXMMPxKF4nDGRHu7Nz3k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 89bf1bb8-118b-47c7-719a-08d62ec45419 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2018 15:23:27.8456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4434 X-OriginatorOrg: amdocs.com Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:23:40 -0000 Q29udGFpbmVyICJmb28iIHdvdWxkIGJlIG1hbmRhdG9yeSBpZiBub3QgZm9yIHRoZSAid2hlbiIg Y2hpbGQgZWxlbWVudC4gIA0KV2l0aCB0aGUgIndoZW4iIGNoaWxkIGVsZW1lbnQsIHRoZSBsb2dp YyBiZWNvbWVzICJpbnZlcnRlZCIgYW5kIHRoZSBjb25zdHJhaW50IGlzIGEgbmVnYXRpdmUgb25l IG9mICJkaXNhbGxvd2VkIHVuZGVyIGNlcnRhaW4gY29uZGl0aW9uIi4NCg0KVGhlIFVDIGlzIGZv ciBlbmZvcmNlbWVudCBpbiBSRVNUIEFQSSBwYXlsb2Fkcy4gDQpGb3IgYSBwcmFjdGljYWwgZXhh bXBsZToNCg0KICAgICAgICAgbGVhZiBBc3NpZ25tZW50TWVjaGFuaXNtIHsNCiAgICAgICAgICAg IHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICAgICAgICBlbnVtICJESENQIjsNCiAgICAgICAg ICAgICAgZW51bSAiU3RhdGljIjsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIG1hbmRhdG9y eSB0cnVlOw0KICAgICAgICAgICAgZGVzY3JpcHRpb24gIlRoZSBhZGRyZXNzIGFzc2lnbm1lbnQg bWVjaGFuaXNtLiI7DQogICAgICAgICAgfQ0KICAgICAgICAgIGxpc3QgSVBBZGRyZXNzZXMgew0K ICAgICAgICAgICAgd2hlbiAiLi4vQXNzaWdubWVudE1lY2hhbmlzbSA9ICdTdGF0aWMnIjsNCiAg ICAgICAgICAgIGtleSBBZGRyZXNzOw0KICAgICAgICAgICAgbWluLWVsZW1lbnRzIDE7DQogICAg ICAgICAgICANCiAgICAgICAgICAgIGxlYWYgQWRkcmVzcyB7DQogICAgICAgICAgICAgIHR5cGUg Y2FwaXQ6SVB2NEFkZHJlc3M7DQogICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJBbiBpcHY0IGFk ZHJlc3MuIjsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgfQ0KDQpUaGVyZSBpcyBubyB3YXkg aW4gdGhlIElQQWRkcmVzc2VzIGxpc3QgdG8gZW5mb3JjZSB0aGF0IHRoZXJlIGlzIGF0IGxlYXN0 IG9uZSBJUCBBZGRyZXNzIHdoZW4gdGhlIGFzc2lnbm1lbnQgbWV0aG9kIGlzICJTdGF0aWMiLg0K T25lIGNvdWxkIHB1dCBhICJtdXN0IiBvbiAiQXNzaWdubWVudE1lY2hhbmlzbSIgdG8gZW5zdXJl IGF0IGxlYXN0IG9uZSBlbGVtZW50IG9mIHRoZSBJUEFkZHJlc3NlcyBsaXN0IHdoZW4gIlN0YXRp YyIsIGJ1dCBJIGRvbid0IHNlZSB0aGlzIGFzIGEgZ29vZCBzY2hlbWEgZGVzaWduLCB0byBoYXZl IHRoZSBjb250cm9sbGluZyBhdHRyaWJ1dGUgY2hlY2sgY29udHJvbGxlZCBhdHRyaWJ1dGVzLg0K DQpJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIHNlbWFudGljIGNhbid0IGJlIGNoYW5nZWQgaW4gWUFO RyBhdCB0aGlzIHBvaW50Lg0KQ291bGQgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaGF2ZSBhIG1vZGlm eWluZyBjaGlsZCBlbGVtZW50IHRvIHN0YXRlIHRoYXQgdGhlIG1hbmRhdG9yeSBzdGF0dXMgb2Yg dGhlIGVsZW1lbnQgaXMgdG8gYmUgZW5mb3JjZWQ/DQpMaWtlDQogICAgY29udGFpbmVyIGZvbyB7 DQogICAgICB3aGVuICJjb25kaXRpb24iIHsNCiAgICAgICAgICBlbmZvcmNlLW1hbmRhdG9yeS1z dGF0dXM7DQogICAgICB9DQoNClRoZXJlIGlzIGFscmVhZHkgYmFjay1lbmQgZm9yIGV4aXN0ZW50 aWFsIGNoZWNrcyBmb3IgbWFuZGF0b3J5IGNob2ljZSBzbyB0aGlzIHNlZW1zIHJlYXNvbmFibHkg Y29uc2lzdGVudCB0byBtZS4NCkkgYXBwcmVjaWF0ZSB0aGVyZSBhcmUgZXhpc3RpbmcgaXNzdWVz IGZvciAid2hlbiIgYnV0IEkgZG9uJ3Qgc2VlIHdoeSB0aGlzIHdvdWxkIG1ha2UgdGhpbmdzIGFu eSB3b3JzZS4NCkluIGZhY3QgYnkgcHJvbW90aW5nIGEgYmV0dGVyIGRlcGVuZGVuY3kgImRpcmVj dGlvbiIgYmV0d2VlbiBzY2hlbWEgZWxlbWVudHMsICB0aGluayBpdCBjb3VsZCBzaW1wbGlmeSB0 aGluZ3MgKHNvIEkgbmFpdmVseSB0aGluayA6KSApLg0KDQpUaGFua3MNCk1pa2UNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGFkaXNsYXYgTGhvdGthIFttYWlsdG86bGhv dGthQG5pYy5jel0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDEwOjI4IEFN DQo+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT47IG5ldG1v ZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGlu IG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QNCj4gZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5k YXRvcnkgb2JqZWN0DQo+IA0KPiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2Nz LmNvbT4gd3JpdGVzOg0KPiANCj4gPiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCDigJx3aGVu4oCd IGFuZCBtYW5kYXRvcnkgb2JqZWN0cy4NCj4gPg0KPiA+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl IGltcGxlbWVudGVkIHNlbWFudGljcyBvZiDigJx3aGVu4oCdIGFyZSByZWFsbHkNCj4g4oCcb3B0 aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5jbG9zaW5nIG9iamVjdCBjYW4gYmUgYWJzZW50 IGV2ZW4gdGhvdWdoIGl0IGlzDQo+IG1hbmRhdG9yeSBhbmQgdGhlIOKAnHdoZW7igJ0gY2xhdXNl IGhvbGRzIHRydWUuDQo+ID4gVGhlIFJGQyBjb3VsZCBiZSBjbGVhcmVyIGFib3V0IHRoaXMuDQo+ ID4NCj4gPiBFeGFtcGxlDQo+ID4NCj4gPiAgICBsZWFmIGNvbG9yIHsNCj4gPiAgICAgIGVudW1l cmF0aW9uICB7DQo+ID4gICAgICAgICBlbnVtIOKAnGJsdWXigJ07DQo+ID4gICAgICAgICBlbnVt IOKAnGJsYWNr4oCdOw0KPiA+ICAgICAgfQ0KPiA+ICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ID4g ICAgfQ0KPiA+ICAgIGNvbnRhaW5lciBmb28gew0KPiA+ICAgICAgIHdoZW4gLi4vY29sb3IgPSDi gJhibHVl4oCZOw0KPiA+ICAgICAgIGV0Yy4NCj4gPiAgICB9DQo+ID4NCj4gPiDigJxmb2/igJ0g aXMgb3B0aW9uYWwgZHVlIHRvIHRoZSBwcmVzZW5jZSBvZiB0aGUg4oCcd2hlbuKAnSBzdGF0ZW1l bnQgZXZlbg0KPiA+IHRob3VnaCB0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSAoc2FtZSBpcyB0cnVl IGZvciBtYW5kYXRvcnkgbGVhZiwNCj4gPiBtaW4tZWxlbWVudHM9MSBsaXN0IGV0Yy4pLg0KPiAN Cj4gTWF5YmUgeW91IGludGVuZGVkIHRvIGhhdmUsIGUuZy4sIGEgIm1hbmRhdG9yeSB0cnVlIiBs ZWFmIGluc2lkZSAiY29udGFpbmVyDQo+IGZvbyI/DQo+IA0KPiA+IFRoaXMgaXMgY29uc2lkZXJl ZCB2YWxpZCBYTUwgZm9yIHRoZSBhYm92ZQ0KPiA+ICAgICA8Y29sb3I+Ymx1ZTwvY29sb3I+DQo+ IA0KPiBZZXMsIGl0IGlzLCB1bmRlciBjdXJyZW50IFlBTkcgcnVsZXMsIG5vIG1hdHRlciB3aGF0 ICJldGMuIiBzdGFuZHMgZm9yLiBOb3RlIHRoYXQNCj4gZXZhbHVhdGlvbiBvZiB0aGUgWFBhdGgg ZXhwcmVzc2lvbiBpbiB0aGlzIGNhc2UgKHdpdGggImZvbyIgbWlzc2luZykgcmVxdWlyZXMgdGhl DQo+IHBlY3VsaWFyIHByb2NlZHVyZSBvZiBzZWMuIDcuMjEuNSBpbiBSRkMgNzk1MC4NCj4gDQo+ ID4NCj4gPiBJbiBteSB2aWV3IHRoaXMgbWFrZXMgY29uZGl0aW9uYWxseSB2YXJpYW50IHNjaGVt YXMg4oCcbG9vc2XigJ0gaW4gdGhlaXINCj4gPiBlbmZvcmNlbWVudCAoc29tZSBzY2VuYXJpb3Mg Y2FuIHVzZSBjaG9pY2UgYnV0IGl0IGRvZXNu4oCZdCBjb3Zlcg0KPiA+IGV2ZXJ5dGhpbmcpLg0K PiA+DQo+ID4gSSB0aGluayB0aGF0IG1hbmRhdG9yeSBzaG91bGQgYmUgcmVzcGVjdGVkIGZvciB0 aGUgZW5jbG9zaW5nIG9iamVjdHMNCj4gPiBvZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50LiAgVGhh dCBpcywgYSBtYW5kYXRvcnkgb2JqZWN0IG11c3QgYmUgcHJlc2VudA0KPiA+IHdoZW4gaXRzIOKA nHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUgYW5kIGEgU2NoZW1hdHJvbiBzdGF0ZW1lbnQgc2hv dWxkDQo+ID4gZW5mb3JjZSB0aGF0Lg0KPiANCj4gSW4gZmFjdCwgdGhpcyBpcyBvbmUgY2FzZSB3 aGVyZSB0aGUgRFNETCBtYXBwaW5nIChSRkMgNjExMCkgZGV2aWF0ZXMgZnJvbQ0KPiBZQU5HIDEu MC4gTm9kZXMgdGhhdCBtYW5kYXRvcnkgYXJlbid0IGVuY2xvc2VkIGluIHRoZSBSRUxBWCBORyA8 b3B0aW9uYWw+DQo+IHBhdHRlcm4sIGFuZCBhcmUgdGhlbiByZXF1aXJlZCBubyBtYXR0ZXIgd2hh dCBhbnkgIndoZW4iDQo+IHN0YXRlbWVudHMgc2F5IChiZWNhdXNlIFJFTEFYIE5HIHZhbGlkYXRp b24gY29tZXMgYmVmb3JlIFNjaGVtYXRyb24pLg0KPiANCj4gPg0KPiA+IFdoYXQgaXMgdGhlIHJh dGlvbmFsZSBiZWhpbmQgdGhlIGN1cnJlbnQgWUFORyBydWxlcyBiZWhhdmlvciwgdGhhdCB0aGUN Cj4gPiDigJx3aGVu4oCdIFNjaGVtYXRyb24gbWFwcGluZyBkb2VzbuKAmXQgY2hlY2sgZm9yIHBy ZXNlbmNlIG9mIHRoZSBlbmNsb3NpbmcNCj4gPiBtYW5kYXRvcnkgb2JqZWN0Pw0KPiANCj4gRldJ VywgSSBoYXZlIGJlZW4gcmVwZWF0ZWRseSBwcm90ZXN0aW5nIGFnYWluc3QgdGhpcyBiZWhhdmlv dXIgYnV0IHdpdGhvdXQNCj4gbXVjaCBsdWNrLiBTZWUgZm9yIGV4YW1wbGUNCj4gDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQwMTIu aHRtbA0KPiANCj4gQXMgYSByZXN1bHQsICJ3aGVuIiBpcyB0aGUgdHJpY2tpZXN0IGZlYXR1cmUg aW4gWUFORyBieSBmYXIuDQo+IA0KPiBMYWRhDQo+IA0KPiA+DQo+ID4gdGhhbmtzDQo+ID4gTWlr ZSBSZWhkZXINCj4gDQo+IC0tDQo+IExhZGlzbGF2IExob3RrYQ0KPiBIZWFkLCBDWi5OSUMgTGFi cw0KPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCuKAnEFtZG9jc+KAmSBlbWFpbCBw bGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2Vk IHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQg c3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0 eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRp bmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ug b2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCd Lgo= From nobody Wed Oct 10 08:33:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8B130E9A for ; Wed, 10 Oct 2018 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.957 X-Spam-Level: X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 NYSZoSBtwIsE for ; Wed, 10 Oct 2018 08:33:04 -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 00732130DD9 for ; Wed, 10 Oct 2018 08:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5761; q=dns/txt; s=iport; t=1539185584; x=1540395184; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=eJVed1uNSE5HGIH0owAju+Eggi+iEC48Od3pVGd6n5A=; b=mPU4o7XGjRzVHAf7k7EsKRqlRXnIgBKLI7ks1aKYv241PTylRTzvadfX Sqp/kR3Qj84EM+7uvSLySrTRUzweJnZZ5GhT0J8L/6KNHGudnM5LTpz// xuY9Vjq4Jw9qA7Pa6rGdC7PiZ6LcVEk/pjy56n7p4Zy11OOEESU0KvRa8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAAiG75b/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJsbRIog3WIdIsmghgllxKBZg0YC4QDRgKEcTgWAQM?= =?us-ascii?q?BAQIBAQJtHAyFOQEBAQEDAQEhDwEFNgsMBAsRBAEBAQICHwQDAgInHwkIBgE?= =?us-ascii?q?MBgIBAYMdAYIBD6R9gS6Ed4UYBYELikeBQT+BEicMgl+CNmUBAQGBLQELBgI?= =?us-ascii?q?Bgx+CVwKdNFIJkEsGF4kihmmPWIY0gVkhZHEzGggbFTuCbIJOiEmFPz4wAYo?= =?us-ascii?q?QAiQHgiABAQ?= X-IronPort-AV: E=Sophos;i="5.54,364,1534809600"; d="scan'208";a="7138284" 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; 10 Oct 2018 15:33:02 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w9AFX1Yk004076; Wed, 10 Oct 2018 15:33:01 GMT To: Michael Rehder , Ladislav Lhotka , "netmod@ietf.org" Cc: "Walker, Jason (Jason_Walker2@comcast.com)" References: <87zhvlvpts.fsf@nic.cz> From: Robert Wilton Message-ID: Date: Wed, 10 Oct 2018 16:33:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:33:07 -0000 Hi Mike, I think that the YANG below already enforces what you want, or otherwise I don't follow your issue. The YANG below is valid in two cases: (1) AssignmentMechanism = DHCP, and IPAddresses is not present in the config (due to the when statement). (2) AssignmentMechanism = Static, IPAddresses exists and has at least one element (due to min-elements 1). Thanks, Rob On 10/10/2018 16:23, Michael Rehder wrote: > Container "foo" would be mandatory if not for the "when" child element. > With the "when" child element, the logic becomes "inverted" and the constraint is a negative one of "disallowed under certain condition". > > The UC is for enforcement in REST API payloads. > For a practical example: > > leaf AssignmentMechanism { > type enumeration { > enum "DHCP"; > enum "Static"; > } > mandatory true; > description "The address assignment mechanism."; > } > list IPAddresses { > when "../AssignmentMechanism = 'Static'"; > key Address; > min-elements 1; > > leaf Address { > type capit:IPv4Address; > description "An ipv4 address."; > } > } > > There is no way in the IPAddresses list to enforce that there is at least one IP Address when the assignment method is "Static". > One could put a "must" on "AssignmentMechanism" to ensure at least one element of the IPAddresses list when "Static", but I don't see this as a good schema design, to have the controlling attribute check controlled attributes. > > I appreciate that this semantic can't be changed in YANG at this point. > Could the "when" statement have a modifying child element to state that the mandatory status of the element is to be enforced? > Like > container foo { > when "condition" { > enforce-mandatory-status; > } > > There is already back-end for existential checks for mandatory choice so this seems reasonably consistent to me. > I appreciate there are existing issues for "when" but I don't see why this would make things any worse. > In fact by promoting a better dependency "direction" between schema elements, think it could simplify things (so I naively think :) ). > > Thanks > Mike >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Wednesday, October 10, 2018 10:28 AM >> To: Michael Rehder ; netmod@ietf.org >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't >> ensure presence of the mandatory object >> >> Michael Rehder writes: >> >>> I have a question about “when†and mandatory objects. >>> >>> It seems to me that the implemented semantics of “when†are really >> “optional whenâ€, in that the enclosing object can be absent even though it is >> mandatory and the “when†clause holds true. >>> The RFC could be clearer about this. >>> >>> Example >>> >>> leaf color { >>> enumeration { >>> enum “blueâ€; >>> enum “blackâ€; >>> } >>> mandatory true; >>> } >>> container foo { >>> when ../color = ‘blue’; >>> etc. >>> } >>> >>> “foo†is optional due to the presence of the “when†statement even >>> though the object is mandatory (same is true for mandatory leaf, >>> min-elements=1 list etc.). >> Maybe you intended to have, e.g., a "mandatory true" leaf inside "container >> foo"? >> >>> This is considered valid XML for the above >>> blue >> Yes, it is, under current YANG rules, no matter what "etc." stands for. Note that >> evaluation of the XPath expression in this case (with "foo" missing) requires the >> peculiar procedure of sec. 7.21.5 in RFC 7950. >> >>> In my view this makes conditionally variant schemas “loose†in their >>> enforcement (some scenarios can use choice but it doesn’t cover >>> everything). >>> >>> I think that mandatory should be respected for the enclosing objects >>> of a “when†statement. That is, a mandatory object must be present >>> when its “when†clause holds true and a Schematron statement should >>> enforce that. >> In fact, this is one case where the DSDL mapping (RFC 6110) deviates from >> YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG >> pattern, and are then required no matter what any "when" >> statements say (because RELAX NG validation comes before Schematron). >> >>> What is the rationale behind the current YANG rules behavior, that the >>> “when†Schematron mapping doesn’t check for presence of the enclosing >>> mandatory object? >> FWIW, I have been repeatedly protesting against this behaviour but without >> much luck. See for example >> >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html >> >> As a result, "when" is the trickiest feature in YANG by far. >> >> Lada >> >>> thanks >>> Mike Rehder >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Oct 10 08:35:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28F7130F47; Wed, 10 Oct 2018 08:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=cooperw.in header.b=z+kRPirP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dXzt7P2I 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 eT1dRMHQRJCc; Wed, 10 Oct 2018 08:35:45 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB823130E96; Wed, 10 Oct 2018 08:35:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7977622148; Wed, 10 Oct 2018 11:35:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Oct 2018 11:35:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=+ hGLTZWuYvDHLesMN9BRzRi4QrKdzPaoVxUqlR5scVk=; b=z+kRPirPXBjYRzMBb Cac1J8M83dPcfH3Q4vDNd7ZhCjAI2LxZ7DyJMv1YeJafUTQlNubkXY4nEdJmwCXa LOfdXmB7LoGoWqqNxR7Jz/6gZl6VqJ8JhIl3oLrTHtgZArWVIk0sfZ3LNMvY2m5R 92Cihuz3wL2cUMPw4kkLhT+52HNn22y7b4iuhZqqvvg0IXTZOJq1vxMZC1zqrShf /xgtWLnxmASv51o9O3I05tx4djis26Hi/dQlbdIX9DzE9XDwZdLckny56I5BSldL ugRQNWQxB2jHUFiJjpjqz7s21Eib9M0wTxgqjQWz0KDH6e73662MFpAXflMacEuD R8ZTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+hGLTZWuYvDHLesMN9BRzRi4QrKdzPaoVxUqlR5sc Vk=; b=dXzt7P2I75HOrn+mLfIPxIUw2yi4n84DpMYhrFhKQM1j15lKvHf9xcPcJ n5Zik+ujGnIvWtppJsK6KF19imsG+/OXdtSTXEI9z9LLbYe09NgfR/XmaJtK7Gpy BNkGBs+J7l0qAc+b+glE0DS94GHPFLUM4ce7q3vvUMZv5uUwSMlnLAcXv2uhmT9I Hot850D8gEH60dl7Kbdr3IgHDD0lDV8rtEYq/ZwoiVfGclU/wbfcXzpxV7XbWHHH 8ZCdCOKnpwIQLC681LtshjxjOGuEL841AfnkNgqTr264C5rzK8XC7D7bK0cNSjIp kxv8OT8apj+eQ2Mb9B0DDXSsTRxjw== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DF62E4532; Wed, 10 Oct 2018 11:35:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Wed, 10 Oct 2018 11:35:41 -0400 Cc: Martin Bjorklund , NetMod WG , General Area Review Team , draft-ietf-netmod-schema-mount.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153862099823.8954.12813773940704626148@ietfa.amsl.com> <20181004.120601.2031947201933436857.mbj@tail-f.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netmod] [Gen-art] Genart telechat review of draft-ietf-netmod-schema-mount-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:35:48 -0000 Joel, thanks for your reviews. Martin, thanks for your responses. I = entered a No Objection ballot. I do think the new text in Section 1 helps clarify the scope of the = server=E2=80=99s responsibility (for me, at least). Alissa > On Oct 4, 2018, at 8:35 AM, Joel M. Halpern = wrote: >=20 > I had thought we had discussed sufficient edits. When I looked at the = diff, what I saw helped some, but still left me concerned. > Yours, > Joel >=20 > On 10/4/18 6:06 AM, Martin Bjorklund wrote: >> Hi, >> Joel Halpern wrote: >>> Reviewer: Joel Halpern >>> Review result: Ready with Issues >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please wait for direction from your >>> document shepherd or AD before posting a new version of the draft. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-netmod-schema-mount-?? >>> Reviewer: Joel Halpern >>> Review Date: 2018-10-03 >>> IETF LC End Date: 2018-06-29 >>> IESG Telechat date: 2018-10-11 >>>=20 >>> Summary: This document seems to meet the specific requirements for = publication >>> as a proposed standard. >>>=20 >>> Major issues: >>> It is still this reviewer's opinion that for a reader who has = not been >>> involved in the discussion in the working group, the document is = quite >>> unclear and confusing. For somewhat more details, please see = my previous >>> review at >>> = https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart= -lc-halpern-2018-06-28/ >> I'm sorry to hear that you find it confusing. I was under the >> impression that the edits that we made after your previous review = were >> sufficient. >> /martin >>>=20 >>> Minor issues: >>> N/A >>>=20 >>> Nits/editorial comments: >>> N/A >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 10 08:43:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEC8130F47 for ; Wed, 10 Oct 2018 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 Za-ioyLSMG0R for ; Wed, 10 Oct 2018 08:43:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 9803F130DD9 for ; Wed, 10 Oct 2018 08:43:14 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 6A15D620AD; Wed, 10 Oct 2018 17:43:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539186192; bh=l7dYXOeW63wwhPSqDDZk/083PgCNqjG5KZQ+E9C1nmk=; h=From:To:Date; b=D5T/Bkrn5LGWy3ph+9Qicio22eNW+fwZawcLIm58f8qbQv0hn166VKkW1fKVKqhZ2 AV9Lk6AINLOzGY6Qrey2PPaOYSAdV+lG5a0fvyINPZK8YUiA5sXp+/mxH+KgfPQqzE M5KCW/Mlg+mNDazL2HMS3fUMtX6RqRhdGuF4tH/8= Message-ID: From: Ladislav Lhotka To: Michael Rehder , "netmod@ietf.org" Cc: "Walker, Jason (Jason_Walker2@comcast.com)" Date: Wed, 10 Oct 2018 17:43:12 +0200 In-Reply-To: References: <87zhvlvpts.fsf@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 15:43:18 -0000 On Wed, 2018-10-10 at 15:23 +0000, Michael Rehder wrote: > Container "foo" would be mandatory if not for the "when" child element. > With the "when" child element, the logic becomes "inverted" and the constraint > is a negative one of "disallowed under certain condition". > > The UC is for enforcement in REST API payloads. > For a practical example: > > leaf AssignmentMechanism { > type enumeration { > enum "DHCP"; > enum "Static"; > } > mandatory true; > description "The address assignment mechanism."; > } > list IPAddresses { > when "../AssignmentMechanism = 'Static'"; > key Address; > min-elements 1; > > leaf Address { > type capit:IPv4Address; > description "An ipv4 address."; > } > } > > There is no way in the IPAddresses list to enforce that there is at least one > IP Address when the assignment method is "Static". Why do you think there is no way? For example, according to sec. 10.28 of RFC 6110, then "min-elements 1" statement is mapped to the RELAX NG pattern which enforces the presence of at least one entry of IPAddresses. >From the DSDL point of view, the problem is rather the opposite: at least one entry will be required during RELAX NG validation even if AssignmentMechanism is "DHCP". Lada > One could put a "must" on "AssignmentMechanism" to ensure at least one element > of the IPAddresses list when "Static", but I don't see this as a good schema > design, to have the controlling attribute check controlled attributes. > > I appreciate that this semantic can't be changed in YANG at this point. > Could the "when" statement have a modifying child element to state that the > mandatory status of the element is to be enforced? > Like > container foo { > when "condition" { > enforce-mandatory-status; > } > > There is already back-end for existential checks for mandatory choice so this > seems reasonably consistent to me. > I appreciate there are existing issues for "when" but I don't see why this > would make things any worse. > In fact by promoting a better dependency "direction" between schema > elements, think it could simplify things (so I naively think :) ). > > Thanks > Mike > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Wednesday, October 10, 2018 10:28 AM > > To: Michael Rehder ; netmod@ietf.org > > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't > > ensure presence of the mandatory object > > > > Michael Rehder writes: > > > > > I have a question about “when†and mandatory objects. > > > > > > It seems to me that the implemented semantics of “when†are really > > “optional whenâ€, in that the enclosing object can be absent even though it > > is > > mandatory and the “when†clause holds true. > > > The RFC could be clearer about this. > > > > > > Example > > > > > > leaf color { > > > enumeration { > > > enum “blueâ€; > > > enum “blackâ€; > > > } > > > mandatory true; > > > } > > > container foo { > > > when ../color = ‘blue’; > > > etc. > > > } > > > > > > “foo†is optional due to the presence of the “when†statement even > > > though the object is mandatory (same is true for mandatory leaf, > > > min-elements=1 list etc.). > > > > Maybe you intended to have, e.g., a "mandatory true" leaf inside "container > > foo"? > > > > > This is considered valid XML for the above > > > blue > > > > Yes, it is, under current YANG rules, no matter what "etc." stands for. Note > > that > > evaluation of the XPath expression in this case (with "foo" missing) > > requires the > > peculiar procedure of sec. 7.21.5 in RFC 7950. > > > > > In my view this makes conditionally variant schemas “loose†in their > > > enforcement (some scenarios can use choice but it doesn’t cover > > > everything). > > > > > > I think that mandatory should be respected for the enclosing objects > > > of a “when†statement. That is, a mandatory object must be present > > > when its “when†clause holds true and a Schematron statement should > > > enforce that. > > > > In fact, this is one case where the DSDL mapping (RFC 6110) deviates from > > YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG > > pattern, and are then required no matter what any "when" > > statements say (because RELAX NG validation comes before Schematron). > > > > > What is the rationale behind the current YANG rules behavior, that the > > > “when†Schematron mapping doesn’t check for presence of the enclosing > > > mandatory object? > > > > FWIW, I have been repeatedly protesting against this behaviour but without > > much luck. See for example > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html > > > > As a result, "when" is the trickiest feature in YANG by far. > > > > Lada > > > > > thanks > > > Mike Rehder > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based > system. Any emails sent to Amdocs will be processed and stored using such > system and are accessible by third party providers of such system on a limited > basis. Your sending of emails to Amdocs evidences your consent to the use of > such system and such processing, storing and accessâ€. -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 09:30:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D084130F7B for ; Wed, 10 Oct 2018 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.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 NTLlGy3ETPz7 for ; Wed, 10 Oct 2018 09:30:18 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 191AC130F0D for ; Wed, 10 Oct 2018 09:30:12 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id d4-v6so4464557lfa.3 for ; Wed, 10 Oct 2018 09:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k3Xx79iKvHFKAShr4ZNm68xaDhMYU/v7QwFs/nA8LkM=; b=tM5N0YEbOweFPPRo3u8YtfIej+Gsr2PJEMD3ZjJRMsxpLvTwUGkqvsoJLpO9DLjeN0 TOqyA2Vzi+hrwX/Qp5BA4Wbl/qE4dBnXsnLsI4mUchcmzA+CpfEkfxeIB+D/ZqdlisF2 EL8VkwOlkrYv+p/O/RloVCHoI0wANkhVLZ78eUGH4PIdttzkcvIh9SbojJFZ+0WX1yRu 6A+awuhCglJ2xWytegYa6CWcKCB6YkQEweABx0PDLav2F2BHWi+pZfpOyeHrqB1vnFxf 1dyIbWaysXBu/TmnqLI4uDizCqvuFmN9afD9fqnQ4NuMrdVfDqAWtAjg60WwRbufH7go jplg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k3Xx79iKvHFKAShr4ZNm68xaDhMYU/v7QwFs/nA8LkM=; b=uN6IU0CvtwL2rq0n9c0mqh2sfdAvJ01mePSXk6z0aq3IZ8e9hDGMe+DbMUUG6e9AtG XuLZmGK5R4P4e6o7eZlK6YKtNhbJJs6oix527z7nXe406UgUSlvSKA2DZ1LwIJeDpx+c QeB7nfSMCZozKcZJwThUjqwZlatORKWIIeIHGj9+MS2zv9dVdRDNukoJN+Z9KXHyJBzf uHqZ/v0JxEtymZtHuxEhoBsSYMYh3jmnww9iyRHq9EP9rUCPhEIUBSo2s+bjGNSBbG7H IvogUmkpQPg+GD2HkoDbrJH8ZhAUldSWdrNJnXgVw755+zkmN8HbsXn+TuRpsQ0T+JZ5 edgA== X-Gm-Message-State: ABuFfoj9GZevVOfGcLgR5WON+X+Ta+7ObBXpJ/ilLAIJirQwdikbiK9p nzWMYefQt559bbdLSc4Hur+T6RZXyxRC/rDnp/RZnPQR X-Google-Smtp-Source: ACcGV61n6AkXzTX/ssJQPwqkH6Te0+hqE7w4ZWnwLzt9KantjkKloju5GYlRsjK3Oi5bJ4QAuW1bJSYGrs/IVM0YKH8= X-Received: by 2002:a19:1188:: with SMTP id 8-v6mr19674312lfr.32.1539189010069; Wed, 10 Oct 2018 09:30:10 -0700 (PDT) MIME-Version: 1.0 References: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com> <20181010.143257.2013021260712498361.mbj@tail-f.com> <20181010.153831.1958991667250114039.mbj@tail-f.com> In-Reply-To: <20181010.153831.1958991667250114039.mbj@tail-f.com> From: Eric Rescorla Date: Wed, 10 Oct 2018 09:29:35 -0700 Message-ID: To: mbj@tail-f.com Cc: IESG , NetMod WG Chairs , NetMod WG , joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger Content-Type: multipart/alternative; boundary="0000000000003017f20577e25e99" Archived-At: Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 16:30:20 -0000 --0000000000003017f20577e25e99 Content-Type: text/plain; charset="UTF-8" I'm sorry but I don't understand this. Does the externally visible behavior of any mounted module depend in any way on these XPATH references -Ekr On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund wrote: > Eric Rescorla wrote: > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund wrote: > > > > > Hi, > > > > > > Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > > > draft-ietf-netmod-schema-mount-11: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > > ---------------------------------------------------------------------- > > > > > > > > Rich version of this review at: > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506 > > > > > > > > > > > > > > > > DETAIL > > > > S 4. > > > > > > > > > > It is worth emphasizing that the nodes specified in > > > > > "parent-reference" leaf-list are available in the mounted > schema > > > only > > > > > for XPath evaluations. In particular, they cannot be accessed > > > there > > > > > via network management protocols such as NETCONF [RFC6241] or > > > > > RESTCONF [RFC8040]. > > > > > > > > What are the security implications of this XPath reference outside > the > > > > mount jail? Specifically, how does it interact with the access > control > > > > for the enclosing module. > > > > > > There is no such interaction, since access control comes into play > > > when some external entity accesses the data through some management > > > protocol, and the nodes from the "parent-reference" expressions cannot > > > be accessed via management protocols. > > > > > > The last sentence of the quoted paragraph was supposed to make this > > > clear, but it seems we might need some additional explanation? > > > > > > > Yes, I think so. I guess I'm not clear on what the XPath expressions are > > for if they > > can't be accessed via the management protocols. How can they be used? > > These are XPath expressions defined in the YANG models themselves, > such as "must" expressions or "leafrefs". The description of > "parent-reference" refer to them as: > > [...] XPath > expressions whose context nodes are defined in the > mounted schema > > > > /martin > --0000000000003017f20577e25e99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry but I don't understand this.
<= div>
Does the externally visible behavior of any mounted modu= le depend in any way on these XPATH references

-Ek= r




Eric Rescorla <ekr@rtfm.com> wrote:
> On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > Eric Rescorla <ekr@rtfm.com> wrote:
> > > Eric Rescorla has entered the following ballot position for<= br> > > > draft-ietf-netmod-schema-mount-11: Discuss
> > >
> > > When responding, please keep the subject line intact and rep= ly to all
> > > email addresses included in the To and CC lines. (Feel free = to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT position= s.
> > >
> > >
> > > The document, along with other ballot positions, can be foun= d here:
> > > https://datatracker.i= etf.org/doc/draft-ietf-netmod-schema-mount/
> > >
> > >
> > >
> > > ------------------------------------------------------------= ----------
> > > DISCUSS:
> > > ------------------------------------------------------------= ----------
> > >
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.= net/D3506
> > >
> > >
> > >
> > > DETAIL
> > > S 4.
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 It is worth emphasizing that the no= des specified in
> > > >=C2=A0 =C2=A0 =C2=A0 "parent-reference" leaf-l= ist are available in the mounted schema
> > only
> > > >=C2=A0 =C2=A0 =C2=A0 for XPath evaluations.=C2=A0 In par= ticular, they cannot be accessed
> > there
> > > >=C2=A0 =C2=A0 =C2=A0 via network management protocols su= ch as NETCONF [RFC6241] or
> > > >=C2=A0 =C2=A0 =C2=A0 RESTCONF [RFC8040].
> > >
> > > What are the security implications of this XPath reference o= utside the
> > > mount jail? Specifically, how does it interact with the acce= ss control
> > > for the enclosing module.
> >
> > There is no such interaction, since access control comes into pla= y
> > when some external entity accesses the data through some manageme= nt
> > protocol, and the nodes from the "parent-reference" exp= ressions cannot
> > be accessed via management protocols.
> >
> > The last sentence of the quoted paragraph was supposed to make th= is
> > clear, but it seems we might need some additional explanation? > >
>
> Yes, I think so. I guess I'm not clear on what the XPath expressio= ns are
> for if they
> can't be accessed via the management protocols. How can they be us= ed?

These are XPath expressions defined in the YANG models themselves,
such as "must" expressions or "leafrefs".=C2=A0 =C2=A0T= he description of
"parent-reference" refer to them as:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] XPath
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expressions whose co= ntext nodes are defined in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mounted schema



/martin
--0000000000003017f20577e25e99-- From nobody Wed Oct 10 11:17:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AEB1252B7 for ; Wed, 10 Oct 2018 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 AL_9gZEyVrn1 for ; Wed, 10 Oct 2018 11:17:36 -0700 (PDT) Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125C7126DBF for ; Wed, 10 Oct 2018 11:17:34 -0700 (PDT) Received: from unknown (HELO ILHFDAGDRFE2.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 10 Oct 2018 21:17:29 +0300 Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE2 (10.237.240.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 21:17:29 +0300 Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 21:17:28 +0300 Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Wed, 10 Oct 2018 21:17:28 +0300 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 21:17:28 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Wr5lemq1ulBiIEfXVH8pOlWwS7bS7aKE+N5f6PgaDk=; b=iXkLNHBW3xQiK4EQnmvDzKEVE2MpmYOjBSujq32RZDizoI/JTJNyVVydLJtK+lGsDwDB3ENN9Nd4e3pb7uOrLx3+xFn7uyWhN2Zn9HV2oCUKiIBfXQH/chjCij5AgibcXnhK0wCYJVVTyIPrNUwUWO7NIglFdt6Gjgfto2tvrC0= Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4641.eurprd06.prod.outlook.com (20.178.18.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.23; Wed, 10 Oct 2018 18:17:26 +0000 Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%3]) with mapi id 15.20.1207.024; Wed, 10 Oct 2018 18:17:26 +0000 From: Michael Rehder To: Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" CC: "Walker, Jason (Jason_Walker2@comcast.com)" Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIg Date: Wed, 10 Oct 2018 18:17:26 +0000 Message-ID: References: <87zhvlvpts.fsf@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [185.139.140.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR06MB4641; 6:apAsIsxXSObKFeNDZgGUcYhnlf2xK/LazDceieN6DNJhbYVG1U8fhezgvv8pdQhNczbsxNhOPCCSOM0xMaJJQYmXDsPAS9BC3/w0jb67Q3xTZtP43wuSraF2kr49Y8rH6JSsZFlUSPxM2lAvQjSH7Fz7rmOCchbFA09wqkgvZpWe4IJq0BuHIf+tQgvmT50EAO0KAPcr5qG39NwxE+TIxcxwCHkC7B+CElmMlLECBNXX2kp14hgTbVKmzlGWvdymoc82rK3D74NZCBlpBtU6+9g4zwBA/IKEPFBdoCFWrU57HcKXKD1AyJqAu8lrJsNEn/rnb0Kizjo6arJGUaP3amf+iA+GtaljSoW9AItCts1hJqVfUmSD6eRoadZFtNDW5WJLm6Eowk8TK93CjauY+T2Ah5atWaoYChOurHsJ3Dfo8+95XF9LWEyjSwjzrz0vQE7TFU+qbx7K/Xacu4orCg==; 5:Y24DppRdRuWHnv24dGODaBWCi75G6bcByX+UQ3xzO6dIywSSXizBcPc5jVorG0gvtOXVXP0Qsq15H5NGBhv1u0YAm1cfQxD32SeHJ09mRsHg9XE0GTBZ18WS25c5/aO7Mh6CWPbFj0MrV5jINekmXntudHzrTrWBL3Tkw3G+NSo=; 7:k3m4WgTcWxmQupBBgE7bO5Z38bc9cYMyKWVyGy8XDkdv6VUZ8rq6JKHNbM67YOAVahfBa6iFViJP2n9aEcgyx+8LTccKCKKERshFj0xH7DwdK8rUQXqCjmfTYSxUN0XWKkl59MT2BhYHcl79DCmK2w/OWYicp5wsJX6/skURJE6shMKmEDS7I3gMvR/ohbAQ3s6AKxzqc29X08lzPB9eZR6tzoG17Y9BL0xqrv/6CPTEyk5R75rKnp/MxGF3fAT2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 03fa783b-9535-4bb8-b233-08d62edca229 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4641; x-ms-traffictypediagnostic: AM0PR06MB4641: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(62221491112393)(131327999870524)(17755550239193)(166566539817055); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991055); SRVR:AM0PR06MB4641; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4641; x-forefront-prvs: 08213D42D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(376002)(346002)(51444003)(13464003)(199004)(189003)(486006)(68736007)(256004)(2501003)(106356001)(5250100002)(105586002)(74316002)(8936002)(97736004)(81166006)(81156014)(8676002)(4326008)(25786009)(6246003)(446003)(6116002)(3846002)(5660300001)(86362001)(2900100001)(71190400001)(71200400001)(476003)(11346002)(66066001)(26005)(966005)(2906002)(33656002)(72206003)(6436002)(93886005)(316002)(102836004)(229853002)(9686003)(186003)(53936002)(6506007)(114624004)(7736002)(99286004)(55016002)(53546011)(7696005)(305945005)(6306002)(110136005)(14454004)(478600001)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4641; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kr1KtrM6PzOyZBkh5JB+SEDzizBw/G/OrXXz7K8RuM3gATPk28JSyRxmRcykT5/24Qbztw/V964zUXRBRZWe+asA8BP59EH0gm8ubjr/7rHG3TL+K/HiHpzkO9aUWOjv+sf/LSMDNJGlVp8Vnc5PoWC64NYT4MlejYR2nycKFXFeJyvcNAMKLiZH/rFxDjooVCFgAdXjXdKAPrJBpE+wrkgyiXNTwA2D0R36z6vbIJhz1dViDhS8WfT0R01Vw0qiWA0uh8sypYSj37QjVt4HrdTy67o9MCWq0R9zp/1YFQ70KQIpeGVVs8vcrdmO1hW0+l7gnCSD6Y7Xrrzns+no0RYTfiYQZUXYb8cu3eQlfPs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 03fa783b-9535-4bb8-b233-08d62edca229 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2018 18:17:26.7359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4641 X-OriginatorOrg: amdocs.com Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:17:38 -0000 SWYgdGhlIGxpc3QgaGFzIGEgIndoZW4iIGNsYXVzZSB0aGUgUk5HIGZpbGUgYWN0dWFsbHkgcHJv ZHVjZXMgYSAiT25lT3JNb3JlIiB3aGljaCBoYXMgYSBjaG9pY2Ugb2YgPGVtcHR5PiBvciB0aGUg bGlzdCBzbyBpdCBhY3R1YWxseSBkb2Vzbid0IGVuZm9yY2UgdGhlIHByZXNlbmNlIGF0IGxlYXN0 IG9uZSByb3cgb2YgdGhlIGxpc3QgKHVubGVzcyBJJ20gbWlzdGFrZW4gaW4gbXkgcmVhZGluZyku DQogICAgICAgICAgICAgIDxvbmVPck1vcmU+DQogICAgICAgICAgICAgICAgPGNob2ljZT4NCiAg ICAgICAgICAgICAgICAgIDxlbXB0eS8+DQogICAgICAgICAgICAgICAgICA8ZWxlbWVudCBuYW1l PSJJUEFkZHJlc3NlcyI+DQogICAgICAgICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9IkFkZHJl c3MiPg0KICAgICAgICAgICAgICAgICAgICAgIDxyZWYgbmFtZT0idHlwZXNfX0lQdjRBZGRyZXNz Ii8+DQogICAgICAgICAgICAgICAgICAgIDwvZWxlbWVudD4NCiAgICAgICAgICAgICAgICAgICAg PGVtcHR5Lz4NCiAgICAgICAgICAgICAgICAgIDwvZWxlbWVudD4NCiAgICAgICAgICAgICAgICA8 L2Nob2ljZT4NCiAgICAgICAgICAgICAgPC9vbmVPck1vcmU+DQoNCkEgbGVhZi9jb250YWluZXIg d291bGQgYmUgYSBzaW1wbGVyIGV4YW1wbGUgYnV0IHdvdWxkIHJlc3VsdCBpbiB0aGUgc2FtZSBs YWNrIG9mIGVuZm9yY2VtZW50IG9mIHRoZSBtYW5kYXRvcnkgc3RhdHVzIG9mIGFuIGVsZW1lbnQg d2l0aCBhICJ3aGVuIiBjbGF1c2UuDQoNClRoaXMgUk5HIHNlZW1zIGNvbnNpc3RlbnQgd2l0aCB0 aGUgU2NoZW1hdHJvbiBydWxlcyB0aGF0ICJ3aGVuIiBtYWtlcyBzb21ldGhpbmcgb3B0aW9uYWwu DQoNCg0KSSB0aGluayBhIHdvcmthcm91bmQgd291bGQgYmUgY2hvaWNlIHdpdGggbWFuZGF0b3J5 IHRydWUgYW5kIGEgd2hlbiBjbGF1c2Ugb24gdGhlIGNhc2VzLiBUaGlzIHdvdWxkIGVuc3VyZSB0 aGF0IGF0IGxlYXN0IG9uZSBjYXNlIGlzIHByZXNlbnQgc2luY2UgdGhlIG1hbmRhdG9yeSBjbGF1 c2UgaW1wbGVtZW50cyBhIFNjaGVtYXRyb24gZXhpc3RlbmNlIGNvbnN0cmFpbnQuDQoNClRoYW5r cw0KTWlrZQ0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2JlcnQgV2ls dG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2Jl ciAxMCwgMjAxOCAxMTozMyBBTQ0KPiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVy QEFtZG9jcy5jb20+OyBMYWRpc2xhdiBMaG90a2ENCj4gPGxob3RrYUBuaWMuY3o+OyBuZXRtb2RA aWV0Zi5vcmcNCj4gQ2M6IFdhbGtlciwgSmFzb24gKEphc29uX1dhbGtlcjJAY29tY2FzdC5jb20p DQo+IDxKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPg0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0g V0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QNCj4gZW5zdXJl IHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+IA0KPiBIaSBNaWtlLA0KPiANCj4g SSB0aGluayB0aGF0IHRoZSBZQU5HIGJlbG93IGFscmVhZHkgZW5mb3JjZXMgd2hhdCB5b3Ugd2Fu dCwgb3Igb3RoZXJ3aXNlIEkNCj4gZG9uJ3QgZm9sbG93IHlvdXIgaXNzdWUuDQo+IA0KPiBUaGUg WUFORyBiZWxvdyBpcyB2YWxpZCBpbiB0d28gY2FzZXM6DQo+IA0KPiAoMSkgQXNzaWdubWVudE1l Y2hhbmlzbSA9IERIQ1AsIGFuZCBJUEFkZHJlc3NlcyBpcyBub3QgcHJlc2VudCBpbiB0aGUgY29u ZmlnDQo+IChkdWUgdG8gdGhlIHdoZW4gc3RhdGVtZW50KS4NCj4gKDIpIEFzc2lnbm1lbnRNZWNo YW5pc20gPSBTdGF0aWMsIElQQWRkcmVzc2VzIGV4aXN0cyBhbmQgaGFzIGF0IGxlYXN0IG9uZQ0K PiBlbGVtZW50IChkdWUgdG8gbWluLWVsZW1lbnRzIDEpLg0KPiANCj4gVGhhbmtzLA0KPiBSb2IN Cj4gDQo+IA0KPiBPbiAxMC8xMC8yMDE4IDE2OjIzLCBNaWNoYWVsIFJlaGRlciB3cm90ZToNCj4g PiBDb250YWluZXIgImZvbyIgd291bGQgYmUgbWFuZGF0b3J5IGlmIG5vdCBmb3IgdGhlICJ3aGVu IiBjaGlsZCBlbGVtZW50Lg0KPiA+IFdpdGggdGhlICJ3aGVuIiBjaGlsZCBlbGVtZW50LCB0aGUg bG9naWMgYmVjb21lcyAiaW52ZXJ0ZWQiIGFuZCB0aGUNCj4gY29uc3RyYWludCBpcyBhIG5lZ2F0 aXZlIG9uZSBvZiAiZGlzYWxsb3dlZCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbiIuDQo+ID4NCj4g PiBUaGUgVUMgaXMgZm9yIGVuZm9yY2VtZW50IGluIFJFU1QgQVBJIHBheWxvYWRzLg0KPiA+IEZv ciBhIHByYWN0aWNhbCBleGFtcGxlOg0KPiA+DQo+ID4gICAgICAgICAgIGxlYWYgQXNzaWdubWVu dE1lY2hhbmlzbSB7DQo+ID4gICAgICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiA+ICAg ICAgICAgICAgICAgIGVudW0gIkRIQ1AiOw0KPiA+ICAgICAgICAgICAgICAgIGVudW0gIlN0YXRp YyI7DQo+ID4gICAgICAgICAgICAgIH0NCj4gPiAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7 DQo+ID4gICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUaGUgYWRkcmVzcyBhc3NpZ25tZW50IG1l Y2hhbmlzbS4iOw0KPiA+ICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICAgbGlzdCBJUEFkZHJl c3NlcyB7DQo+ID4gICAgICAgICAgICAgIHdoZW4gIi4uL0Fzc2lnbm1lbnRNZWNoYW5pc20gPSAn U3RhdGljJyI7DQo+ID4gICAgICAgICAgICAgIGtleSBBZGRyZXNzOw0KPiA+ICAgICAgICAgICAg ICBtaW4tZWxlbWVudHMgMTsNCj4gPg0KPiA+ICAgICAgICAgICAgICBsZWFmIEFkZHJlc3Mgew0K PiA+ICAgICAgICAgICAgICAgIHR5cGUgY2FwaXQ6SVB2NEFkZHJlc3M7DQo+ID4gICAgICAgICAg ICAgICAgZGVzY3JpcHRpb24gIkFuIGlwdjQgYWRkcmVzcy4iOw0KPiA+ICAgICAgICAgICAgICB9 DQo+ID4gICAgICAgICAgICAgfQ0KPiA+DQo+ID4gVGhlcmUgaXMgbm8gd2F5IGluIHRoZSBJUEFk ZHJlc3NlcyBsaXN0IHRvIGVuZm9yY2UgdGhhdCB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgSVANCj4g QWRkcmVzcyB3aGVuIHRoZSBhc3NpZ25tZW50IG1ldGhvZCBpcyAiU3RhdGljIi4NCj4gPiBPbmUg Y291bGQgcHV0IGEgIm11c3QiIG9uICJBc3NpZ25tZW50TWVjaGFuaXNtIiB0byBlbnN1cmUgYXQg bGVhc3Qgb25lDQo+IGVsZW1lbnQgb2YgdGhlIElQQWRkcmVzc2VzIGxpc3Qgd2hlbiAiU3RhdGlj IiwgYnV0IEkgZG9uJ3Qgc2VlIHRoaXMgYXMgYSBnb29kDQo+IHNjaGVtYSBkZXNpZ24sIHRvIGhh dmUgdGhlIGNvbnRyb2xsaW5nIGF0dHJpYnV0ZSBjaGVjayBjb250cm9sbGVkIGF0dHJpYnV0ZXMu DQo+ID4NCj4gPiBJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIHNlbWFudGljIGNhbid0IGJlIGNoYW5n ZWQgaW4gWUFORyBhdCB0aGlzIHBvaW50Lg0KPiA+IENvdWxkIHRoZSAid2hlbiIgc3RhdGVtZW50 IGhhdmUgYSBtb2RpZnlpbmcgY2hpbGQgZWxlbWVudCB0byBzdGF0ZSB0aGF0IHRoZQ0KPiBtYW5k YXRvcnkgc3RhdHVzIG9mIHRoZSBlbGVtZW50IGlzIHRvIGJlIGVuZm9yY2VkPw0KPiA+IExpa2UN Cj4gPiAgICAgIGNvbnRhaW5lciBmb28gew0KPiA+ICAgICAgICB3aGVuICJjb25kaXRpb24iIHsN Cj4gPiAgICAgICAgICAgIGVuZm9yY2UtbWFuZGF0b3J5LXN0YXR1czsNCj4gPiAgICAgICAgfQ0K PiA+DQo+ID4gVGhlcmUgaXMgYWxyZWFkeSBiYWNrLWVuZCBmb3IgZXhpc3RlbnRpYWwgY2hlY2tz IGZvciBtYW5kYXRvcnkgY2hvaWNlIHNvIHRoaXMNCj4gc2VlbXMgcmVhc29uYWJseSBjb25zaXN0 ZW50IHRvIG1lLg0KPiA+IEkgYXBwcmVjaWF0ZSB0aGVyZSBhcmUgZXhpc3RpbmcgaXNzdWVzIGZv ciAid2hlbiIgYnV0IEkgZG9uJ3Qgc2VlIHdoeSB0aGlzDQo+IHdvdWxkIG1ha2UgdGhpbmdzIGFu eSB3b3JzZS4NCj4gPiBJbiBmYWN0IGJ5IHByb21vdGluZyBhIGJldHRlciBkZXBlbmRlbmN5ICJk aXJlY3Rpb24iIGJldHdlZW4gc2NoZW1hDQo+IGVsZW1lbnRzLCAgdGhpbmsgaXQgY291bGQgc2lt cGxpZnkgdGhpbmdzIChzbyBJIG5haXZlbHkgdGhpbmsgOikgKS4NCj4gPg0KPiA+IFRoYW5rcw0K PiA+IE1pa2UNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTGFk aXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQG5pYy5jel0NCj4gPj4gU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDEwLCAyMDE4IDEwOjI4IEFNDQo+ID4+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWlj aGFlbC5SZWhkZXJAQW1kb2NzLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBS ZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNu J3QNCj4gPj4gZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4+DQo+ ID4+IE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPiB3cml0ZXM6DQo+ ID4+DQo+ID4+PiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCDigJx3aGVu4oCdIGFuZCBtYW5kYXRv cnkgb2JqZWN0cy4NCj4gPj4+DQo+ID4+PiBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBpbXBsZW1l bnRlZCBzZW1hbnRpY3Mgb2Yg4oCcd2hlbuKAnSBhcmUgcmVhbGx5DQo+ID4+IOKAnG9wdGlvbmFs IHdoZW7igJ0sIGluIHRoYXQgdGhlIGVuY2xvc2luZyBvYmplY3QgY2FuIGJlIGFic2VudCBldmVu DQo+ID4+IHRob3VnaCBpdCBpcyBtYW5kYXRvcnkgYW5kIHRoZSDigJx3aGVu4oCdIGNsYXVzZSBo b2xkcyB0cnVlLg0KPiA+Pj4gVGhlIFJGQyBjb3VsZCBiZSBjbGVhcmVyIGFib3V0IHRoaXMuDQo+ ID4+Pg0KPiA+Pj4gRXhhbXBsZQ0KPiA+Pj4NCj4gPj4+ICAgICBsZWFmIGNvbG9yIHsNCj4gPj4+ ICAgICAgIGVudW1lcmF0aW9uICB7DQo+ID4+PiAgICAgICAgICBlbnVtIOKAnGJsdWXigJ07DQo+ ID4+PiAgICAgICAgICBlbnVtIOKAnGJsYWNr4oCdOw0KPiA+Pj4gICAgICAgfQ0KPiA+Pj4gICAg ICAgbWFuZGF0b3J5IHRydWU7DQo+ID4+PiAgICAgfQ0KPiA+Pj4gICAgIGNvbnRhaW5lciBmb28g ew0KPiA+Pj4gICAgICAgIHdoZW4gLi4vY29sb3IgPSDigJhibHVl4oCZOw0KPiA+Pj4gICAgICAg IGV0Yy4NCj4gPj4+ICAgICB9DQo+ID4+Pg0KPiA+Pj4g4oCcZm9v4oCdIGlzIG9wdGlvbmFsIGR1 ZSB0byB0aGUgcHJlc2VuY2Ugb2YgdGhlIOKAnHdoZW7igJ0gc3RhdGVtZW50IGV2ZW4NCj4gPj4+ IHRob3VnaCB0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSAoc2FtZSBpcyB0cnVlIGZvciBtYW5kYXRv cnkgbGVhZiwNCj4gPj4+IG1pbi1lbGVtZW50cz0xIGxpc3QgZXRjLikuDQo+ID4+IE1heWJlIHlv dSBpbnRlbmRlZCB0byBoYXZlLCBlLmcuLCBhICJtYW5kYXRvcnkgdHJ1ZSIgbGVhZiBpbnNpZGUN Cj4gPj4gImNvbnRhaW5lciBmb28iPw0KPiA+Pg0KPiA+Pj4gVGhpcyBpcyBjb25zaWRlcmVkIHZh bGlkIFhNTCBmb3IgdGhlIGFib3ZlDQo+ID4+PiAgICAgIDxjb2xvcj5ibHVlPC9jb2xvcj4NCj4g Pj4gWWVzLCBpdCBpcywgdW5kZXIgY3VycmVudCBZQU5HIHJ1bGVzLCBubyBtYXR0ZXIgd2hhdCAi ZXRjLiIgc3RhbmRzDQo+ID4+IGZvci4gTm90ZSB0aGF0IGV2YWx1YXRpb24gb2YgdGhlIFhQYXRo IGV4cHJlc3Npb24gaW4gdGhpcyBjYXNlICh3aXRoDQo+ID4+ICJmb28iIG1pc3NpbmcpIHJlcXVp cmVzIHRoZSBwZWN1bGlhciBwcm9jZWR1cmUgb2Ygc2VjLiA3LjIxLjUgaW4gUkZDIDc5NTAuDQo+ ID4+DQo+ID4+PiBJbiBteSB2aWV3IHRoaXMgbWFrZXMgY29uZGl0aW9uYWxseSB2YXJpYW50IHNj aGVtYXMg4oCcbG9vc2XigJ0gaW4gdGhlaXINCj4gPj4+IGVuZm9yY2VtZW50IChzb21lIHNjZW5h cmlvcyBjYW4gdXNlIGNob2ljZSBidXQgaXQgZG9lc27igJl0IGNvdmVyDQo+ID4+PiBldmVyeXRo aW5nKS4NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIHRoYXQgbWFuZGF0b3J5IHNob3VsZCBiZSByZXNw ZWN0ZWQgZm9yIHRoZSBlbmNsb3Npbmcgb2JqZWN0cw0KPiA+Pj4gb2YgYSDigJx3aGVu4oCdIHN0 YXRlbWVudC4gIFRoYXQgaXMsIGEgbWFuZGF0b3J5IG9iamVjdCBtdXN0IGJlIHByZXNlbnQNCj4g Pj4+IHdoZW4gaXRzIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUgYW5kIGEgU2NoZW1hdHJv biBzdGF0ZW1lbnQgc2hvdWxkDQo+ID4+PiBlbmZvcmNlIHRoYXQuDQo+ID4+IEluIGZhY3QsIHRo aXMgaXMgb25lIGNhc2Ugd2hlcmUgdGhlIERTREwgbWFwcGluZyAoUkZDIDYxMTApIGRldmlhdGVz DQo+ID4+IGZyb20gWUFORyAxLjAuIE5vZGVzIHRoYXQgbWFuZGF0b3J5IGFyZW4ndCBlbmNsb3Nl ZCBpbiB0aGUgUkVMQVggTkcNCj4gPj4gPG9wdGlvbmFsPiBwYXR0ZXJuLCBhbmQgYXJlIHRoZW4g cmVxdWlyZWQgbm8gbWF0dGVyIHdoYXQgYW55ICJ3aGVuIg0KPiA+PiBzdGF0ZW1lbnRzIHNheSAo YmVjYXVzZSBSRUxBWCBORyB2YWxpZGF0aW9uIGNvbWVzIGJlZm9yZSBTY2hlbWF0cm9uKS4NCj4g Pj4NCj4gPj4+IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGN1cnJlbnQgWUFORyBy dWxlcyBiZWhhdmlvciwgdGhhdA0KPiA+Pj4gdGhlIOKAnHdoZW7igJ0gU2NoZW1hdHJvbiBtYXBw aW5nIGRvZXNu4oCZdCBjaGVjayBmb3IgcHJlc2VuY2Ugb2YgdGhlDQo+ID4+PiBlbmNsb3Npbmcg bWFuZGF0b3J5IG9iamVjdD8NCj4gPj4gRldJVywgSSBoYXZlIGJlZW4gcmVwZWF0ZWRseSBwcm90 ZXN0aW5nIGFnYWluc3QgdGhpcyBiZWhhdmlvdXIgYnV0DQo+ID4+IHdpdGhvdXQgbXVjaCBsdWNr LiBTZWUgZm9yIGV4YW1wbGUNCj4gPj4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNDAxMi5odG1sDQo+ID4+DQo+ID4+IEFzIGEg cmVzdWx0LCAid2hlbiIgaXMgdGhlIHRyaWNraWVzdCBmZWF0dXJlIGluIFlBTkcgYnkgZmFyLg0K PiA+Pg0KPiA+PiBMYWRhDQo+ID4+DQo+ID4+PiB0aGFua3MNCj4gPj4+IE1pa2UgUmVoZGVyDQo+ ID4+IC0tDQo+ID4+IExhZGlzbGF2IExob3RrYQ0KPiA+PiBIZWFkLCBDWi5OSUMgTGFicw0KPiA+ PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiDigJxBbWRvY3PigJkgZW1haWwg cGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNl ZA0KPiBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQg YW5kIHN0b3JlZCB1c2luZyBzdWNoDQo+IHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhp cmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZA0KPiBiYXNpcy4g WW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0 byB0aGUgdXNlIG9mDQo+IHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3Jpbmcg YW5kIGFjY2Vzc+KAnS4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQrigJxB bWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3 aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBi ZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2li bGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBi YXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29u c2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3Jp bmcgYW5kIGFjY2Vzc+KAnS4K From nobody Wed Oct 10 11:25:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46910130DDC for ; Wed, 10 Oct 2018 11:25:40 -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 wkjd_RgLqcOh for ; Wed, 10 Oct 2018 11:25:36 -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 67DED12DD85 for ; Wed, 10 Oct 2018 11:25:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 94CE2B32; Wed, 10 Oct 2018 20:25:32 +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 cUyRjZvbJc9p; Wed, 10 Oct 2018 20:25:31 +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, 10 Oct 2018 20:25:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5231520036; Wed, 10 Oct 2018 20:25:32 +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 zgT_1Yo_dK-i; Wed, 10 Oct 2018 20:25:31 +0200 (CEST) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id D763020038; Wed, 10 Oct 2018 20:25:30 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 10 Oct 2018 20:25:30 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 19E123000E05FD; Wed, 10 Oct 2018 20:25:29 +0200 (CEST) Date: Wed, 10 Oct 2018 20:25:29 +0200 From: Juergen Schoenwaelder To: Michael Rehder CC: Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" , "Walker, Jason (Jason_Walker2@comcast.com)" Message-ID: <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Rehder , Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" , "Walker, Jason (Jason_Walker2@comcast.com)" References: <87zhvlvpts.fsf@nic.cz> 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: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:25:40 -0000 Michael, what matters here is what the YANG specification (RFC 7950) says. Is there a reason to believe the IPAddresses list in your example can be absent or have no elements based on what RFC 7950 says? Or do we talk about a shortcoming of RFC 6110? /js On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote: > If the list has a "when" clause the RNG file actually produces a "OneOrMore" which has a choice of or the list so it actually doesn't enforce the presence at least one row of the list (unless I'm mistaken in my reading). > > > > > > > > > > > > > A leaf/container would be a simpler example but would result in the same lack of enforcement of the mandatory status of an element with a "when" clause. > > This RNG seems consistent with the Schematron rules that "when" makes something optional. > > > I think a workaround would be choice with mandatory true and a when clause on the cases. This would ensure that at least one case is present since the mandatory clause implements a Schematron existence constraint. > > Thanks > Mike > > -----Original Message----- > > From: Robert Wilton [mailto:rwilton@cisco.com] > > Sent: Wednesday, October 10, 2018 11:33 AM > > To: Michael Rehder ; Ladislav Lhotka > > ; netmod@ietf.org > > Cc: Walker, Jason (Jason_Walker2@comcast.com) > > > > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't > > ensure presence of the mandatory object > > > > Hi Mike, > > > > I think that the YANG below already enforces what you want, or otherwise I > > don't follow your issue. > > > > The YANG below is valid in two cases: > > > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in the config > > (due to the when statement). > > (2) AssignmentMechanism = Static, IPAddresses exists and has at least one > > element (due to min-elements 1). > > > > Thanks, > > Rob > > > > > > On 10/10/2018 16:23, Michael Rehder wrote: > > > Container "foo" would be mandatory if not for the "when" child element. > > > With the "when" child element, the logic becomes "inverted" and the > > constraint is a negative one of "disallowed under certain condition". > > > > > > The UC is for enforcement in REST API payloads. > > > For a practical example: > > > > > > leaf AssignmentMechanism { > > > type enumeration { > > > enum "DHCP"; > > > enum "Static"; > > > } > > > mandatory true; > > > description "The address assignment mechanism."; > > > } > > > list IPAddresses { > > > when "../AssignmentMechanism = 'Static'"; > > > key Address; > > > min-elements 1; > > > > > > leaf Address { > > > type capit:IPv4Address; > > > description "An ipv4 address."; > > > } > > > } > > > > > > There is no way in the IPAddresses list to enforce that there is at least one IP > > Address when the assignment method is "Static". > > > One could put a "must" on "AssignmentMechanism" to ensure at least one > > element of the IPAddresses list when "Static", but I don't see this as a good > > schema design, to have the controlling attribute check controlled attributes. > > > > > > I appreciate that this semantic can't be changed in YANG at this point. > > > Could the "when" statement have a modifying child element to state that the > > mandatory status of the element is to be enforced? > > > Like > > > container foo { > > > when "condition" { > > > enforce-mandatory-status; > > > } > > > > > > There is already back-end for existential checks for mandatory choice so this > > seems reasonably consistent to me. > > > I appreciate there are existing issues for "when" but I don't see why this > > would make things any worse. > > > In fact by promoting a better dependency "direction" between schema > > elements, think it could simplify things (so I naively think :) ). > > > > > > Thanks > > > Mike > > >> -----Original Message----- > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > >> Sent: Wednesday, October 10, 2018 10:28 AM > > >> To: Michael Rehder ; netmod@ietf.org > > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't > > >> ensure presence of the mandatory object > > >> > > >> Michael Rehder writes: > > >> > > >>> I have a question about “when†and mandatory objects. > > >>> > > >>> It seems to me that the implemented semantics of “when†are really > > >> “optional whenâ€, in that the enclosing object can be absent even > > >> though it is mandatory and the “when†clause holds true. > > >>> The RFC could be clearer about this. > > >>> > > >>> Example > > >>> > > >>> leaf color { > > >>> enumeration { > > >>> enum “blueâ€; > > >>> enum “blackâ€; > > >>> } > > >>> mandatory true; > > >>> } > > >>> container foo { > > >>> when ../color = ‘blue’; > > >>> etc. > > >>> } > > >>> > > >>> “foo†is optional due to the presence of the “when†statement even > > >>> though the object is mandatory (same is true for mandatory leaf, > > >>> min-elements=1 list etc.). > > >> Maybe you intended to have, e.g., a "mandatory true" leaf inside > > >> "container foo"? > > >> > > >>> This is considered valid XML for the above > > >>> blue > > >> Yes, it is, under current YANG rules, no matter what "etc." stands > > >> for. Note that evaluation of the XPath expression in this case (with > > >> "foo" missing) requires the peculiar procedure of sec. 7.21.5 in RFC 7950. > > >> > > >>> In my view this makes conditionally variant schemas “loose†in their > > >>> enforcement (some scenarios can use choice but it doesn’t cover > > >>> everything). > > >>> > > >>> I think that mandatory should be respected for the enclosing objects > > >>> of a “when†statement. That is, a mandatory object must be present > > >>> when its “when†clause holds true and a Schematron statement should > > >>> enforce that. > > >> In fact, this is one case where the DSDL mapping (RFC 6110) deviates > > >> from YANG 1.0. Nodes that mandatory aren't enclosed in the RELAX NG > > >> pattern, and are then required no matter what any "when" > > >> statements say (because RELAX NG validation comes before Schematron). > > >> > > >>> What is the rationale behind the current YANG rules behavior, that > > >>> the “when†Schematron mapping doesn’t check for presence of the > > >>> enclosing mandatory object? > > >> FWIW, I have been repeatedly protesting against this behaviour but > > >> without much luck. See for example > > >> > > >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.html > > >> > > >> As a result, "when" is the trickiest feature in YANG by far. > > >> > > >> Lada > > >> > > >>> thanks > > >>> Mike Rehder > > >> -- > > >> Ladislav Lhotka > > >> Head, CZ.NIC Labs > > >> PGP Key ID: 0xB8F92B08A9F76C67 > > > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based > > system. Any emails sent to Amdocs will be processed and stored using such > > system and are accessible by third party providers of such system on a limited > > basis. Your sending of emails to Amdocs evidences your consent to the use of > > such system and such processing, storing and accessâ€. > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 10 11:44:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60F41274D0 for ; Wed, 10 Oct 2018 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 5ja40Em8aJ7N for ; Wed, 10 Oct 2018 11:44:25 -0700 (PDT) Received: from mx1.amdocs.com (ramail1.amdocs.com [193.43.244.133]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D052126F72 for ; Wed, 10 Oct 2018 11:44:23 -0700 (PDT) Received: from unknown (HELO ILHFDAGDRFE2.corp.amdocs.com) ([10.224.0.130]) by ilmail01.corp.amdocs.com with ESMTP; 10 Oct 2018 21:44:21 +0300 Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE2 (10.237.240.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 21:44:21 +0300 Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 21:44:21 +0300 Received: from ILRNAEXCHEDGE01.corp.amdocs.com (10.233.34.167) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Wed, 10 Oct 2018 21:44:21 +0300 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 10 Oct 2018 21:44:20 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=usRIkjggs+qWQe6J6tGdnyqllDRD5uJcxzBM3xNUFQ0=; b=eEBSlXNsfeoTFxlY3VTBsc26ehV54R0aEsca7XSKs1csXR7/AkdXUQQotvZp74Ha0AWIW4YQjLqjaFRRv73Pu3VzMqessCk3NaS4kuUVlJep9LNhPItmgRcNID+U2tMeDHugOCZHlZvY1mNOD6B7EP6Xhn+kojKFjTE4+EwxvT8= Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4225.eurprd06.prod.outlook.com (52.135.150.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.28; Wed, 10 Oct 2018 18:44:18 +0000 Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%3]) with mapi id 15.20.1207.024; Wed, 10 Oct 2018 18:44:18 +0000 From: Michael Rehder To: Juergen Schoenwaelder CC: Robert Wilton , Ladislav Lhotka , "netmod@ietf.org" , "Walker, Jason (Jason_Walker2@comcast.com)" Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwA== Date: Wed, 10 Oct 2018 18:44:18 +0000 Message-ID: References: <87zhvlvpts.fsf@nic.cz> <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> In-Reply-To: <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; x-originating-ip: [69.150.27.28] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR06MB4225; 6:U0sOWQ+K7cYMADvAfkmGirKPpjcABmruTy5JvWC1baQwWvdhbN/nEvwzgDk2bsmD0ATESC16NNdBc4wumLquT+7LzUaBKnvUEExt+mmwB1LKaehgpN3cRTM90WLtug5cVN/XWQKm/V8kSQBkCTBq4JOStxUPfh6GYoB/E1x1qy9ajl/vjiartM+QKD17SjlLRsJWksbRz2vJP3fgDqV1jCqG1bw97iXfU1SnPz4RHMdh2ZK27tRLtcw0ZR2/VXRBz8+UHj4cVjBnjr19rStHu26L4bX1bYvRayDNt3t45nSMh8C3PMZr9A0N0JtX6jUmuqFDdyOWxbCjbYk7pHMYOiAg1cvXWmRt4Nr1ihrH//WqdWiEnuhqSYdcuwduzw0M1rNeRKS+Jz1GuN4hZ4TKNEXxsbwKld+kFENbWOc3HFuTReCelmgLg+WYQqD7rZJJJTFZWuI9NMt3hhOrez0TPQ==; 5:1DBKFPXxsD1zv561PUCcQcEsdEwvAhfM+NVtJ2BSPbvtnSCVdhmy5FVDT3Xezq4hoIrvKCLXBIi+woBuUFJ7ldokVyi5cO3Ml9uojv9nLzc2o3xENLXjb7WZjY4ONAdNqeG2PZNhzx6J5vWvKW8qrOv7ydsNCv2INgijhmcapxA=; 7:vWRahU5eLHekclfymcIIIAfH3MuscMM+cknKV5WmooaPEhYogAkK9Omdn//eKrBPjVcMpzxwSlCTJJ370cKmG2AEqC82686KuK5U9LkfC5xjXvukDUEG7GmwWpYFI5jMjwZpd+mTP0+AWHUY292zRfjo4TMWGhzyrWW9SUGqCLYHkcSXJno7QcEBu8MfGmDE78zTbPj8MSqgqW1wZGgtnMzgiRRV2sLxKtbok6uynRnkiRR5ElCzvL6heM6kEKRD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d3aa7664-5ec2-4387-22fd-08d62ee06309 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4225; x-ms-traffictypediagnostic: AM0PR06MB4225: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(62221491112393)(131327999870524)(95692535739014)(17755550239193)(166566539817055); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231355)(944501410)(52105095)(10201501046)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051); SRVR:AM0PR06MB4225; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4225; x-forefront-prvs: 08213D42D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(346002)(376002)(13464003)(51444003)(189003)(199004)(316002)(11346002)(478600001)(186003)(72206003)(2906002)(33656002)(476003)(446003)(81156014)(76176011)(8676002)(53546011)(966005)(6306002)(8936002)(5250100002)(7696005)(55016002)(229853002)(256004)(53936002)(99286004)(6506007)(93886005)(486006)(14444005)(9686003)(14454004)(81166006)(66066001)(4326008)(97736004)(86362001)(5660300001)(26005)(6246003)(71200400001)(74316002)(305945005)(106356001)(102836004)(3846002)(6116002)(25786009)(6916009)(6436002)(114624004)(68736007)(54906003)(7736002)(105586002)(71190400001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4225; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ExoFTQK/yKSmSKlf0pB7SlQ/mCsCgboLaHlL/KtctVDen97mCHuW9rq/pxQByXfTlkMQrlXEhjsOQKha3/k58GN75HIZYMiKTC36dwnYtAiBhvuRyyhr85IAHvZA2aBl7VcgS1rra5Tpd6ndC7xXrsct8WuRGE1lEJQJ7JV1STPA24u8tPKfBkq6nEAQSDF59NKAFWp+AkcQS0932wDRh8GtTIQPERKnW3sq5xYUdoxSAPHWFIyqYngthiQDq2x0MT0sUcO4dxoTF4akTFWoYnNkfGiFmcAVpTCwzpqCASr1ohWn7o3bMUiKoS6Fq2lJYjKfm+SI4SIMSLjsZM5Rv/0CR6fhSdq1AETYTLHlSTU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d3aa7664-5ec2-4387-22fd-08d62ee06309 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2018 18:44:18.7661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4225 X-OriginatorOrg: amdocs.com Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:44:28 -0000 U3VyZS4NCg0KSSB0aGluayB0aGUgUkZDIGlzIHVuY2xlYXIgc2luY2UgaXQgc2VlbXMgdGhhdCB0 aGUgc2VtYW50aWNzIGFyZSBjb25zaXN0ZW50IGluIHRoZSBiYWNrLWVuZCBjaGVja3MuDQpPbmUg Y2FuIHJlYWQgdGhlIFJGQyBhbmQgbm90IG5vdGljZSBieSBpdHMgYWJzZW5jZSB0aGF0IHRoZSB3 aGVuIGNsYXVzZSBkb2Vzbid0IHJlcXVpcmUgYW55dGhpbmcgdG8gYmUgcHJlc2VudC4NCg0KICAg ICBUaGUgIndoZW4iIHN0YXRlbWVudCBtYWtlcyBpdHMgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBz dGF0ZW1lbnQgY29uZGl0aW9uYWwuDQpTaG91bGQgYmUNCiAgICBUaGUgIndoZW4iIHN0YXRlbWVu dCBtYWtlcyBpdHMgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQgY29uZGl0aW9uYWwg YW5kIG9wdGlvbmFsLg0KDQpJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIG1vcmUgZGVmaW5pdGUg c3RhdGVtZW50IGFib3V0IHRoaXMgb3ZlcnJpZGluZyBhbnkgbWFuZGF0b3J5IHN0YXR1cyBvZiB0 aGUgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQuDQpMaWtlDQogICAgICJBbnkgbWFu ZGF0b3J5IHN0YXR1cyBvZiB0aGUgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQgKG1h bmRhdG9yeSBzdGF0ZW1lbnQsIG1pbi1lbGVtZW50IHN0YXRlbWVudCBldGMuKSBpcyBvdmVycmlk ZGVuIGJ5IHRoaXMgc3RhdGVtZW50IGFuZCBtYWRlIG5vbi1tYW5kYXRvcnkuIg0KDQpUaGF0IHdv dWxkIGhhdmUgbWFkZSB0aGUgc2lkZS1lZmZlY3Qgb2YgIndoZW4iIG9uIG90aGVyIGRlY2xhcmF0 aW9ucyBjbGVhcmVyLg0KDQpUaGFua3MNCm1pa2UNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlXQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIw MTggMjoyNSBQTQ0KPiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5j b20+DQo+IENjOiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT47IExhZGlzbGF2IExo b3RrYSA8bGhvdGthQG5pYy5jej47DQo+IG5ldG1vZEBpZXRmLm9yZzsgV2Fsa2VyLCBKYXNvbiAo SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSkNCj4gPEphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+ DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5 IG9iamVjdHMgZG9lc24ndA0KPiBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmpl Y3QNCj4gDQo+IE1pY2hhZWwsDQo+IA0KPiB3aGF0IG1hdHRlcnMgaGVyZSBpcyB3aGF0IHRoZSBZ QU5HIHNwZWNpZmljYXRpb24gKFJGQyA3OTUwKSBzYXlzLiBJcyB0aGVyZSBhDQo+IHJlYXNvbiB0 byBiZWxpZXZlIHRoZSBJUEFkZHJlc3NlcyBsaXN0IGluIHlvdXIgZXhhbXBsZSBjYW4gYmUgYWJz ZW50IG9yIGhhdmUgbm8NCj4gZWxlbWVudHMgYmFzZWQgb24gd2hhdCBSRkMgNzk1MCBzYXlzPyBP ciBkbyB3ZSB0YWxrIGFib3V0IGEgc2hvcnRjb21pbmcgb2YNCj4gUkZDIDYxMTA/DQo+IA0KPiAv anMNCj4gDQo+IE9uIFdlZCwgT2N0IDEwLCAyMDE4IGF0IDA2OjE3OjI2UE0gKzAwMDAsIE1pY2hh ZWwgUmVoZGVyIHdyb3RlOg0KPiA+IElmIHRoZSBsaXN0IGhhcyBhICJ3aGVuIiBjbGF1c2UgdGhl IFJORyBmaWxlIGFjdHVhbGx5IHByb2R1Y2VzIGEgIk9uZU9yTW9yZSINCj4gd2hpY2ggaGFzIGEg Y2hvaWNlIG9mIDxlbXB0eT4gb3IgdGhlIGxpc3Qgc28gaXQgYWN0dWFsbHkgZG9lc24ndCBlbmZv cmNlIHRoZQ0KPiBwcmVzZW5jZSBhdCBsZWFzdCBvbmUgcm93IG9mIHRoZSBsaXN0ICh1bmxlc3Mg SSdtIG1pc3Rha2VuIGluIG15IHJlYWRpbmcpLg0KPiA+ICAgICAgICAgICAgICAgPG9uZU9yTW9y ZT4NCj4gPiAgICAgICAgICAgICAgICAgPGNob2ljZT4NCj4gPiAgICAgICAgICAgICAgICAgICA8 ZW1wdHkvPg0KPiA+ICAgICAgICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9IklQQWRkcmVzc2Vz Ij4NCj4gPiAgICAgICAgICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9IkFkZHJlc3MiPg0KPiA+ ICAgICAgICAgICAgICAgICAgICAgICA8cmVmIG5hbWU9InR5cGVzX19JUHY0QWRkcmVzcyIvPg0K PiA+ICAgICAgICAgICAgICAgICAgICAgPC9lbGVtZW50Pg0KPiA+ICAgICAgICAgICAgICAgICAg ICAgPGVtcHR5Lz4NCj4gPiAgICAgICAgICAgICAgICAgICA8L2VsZW1lbnQ+DQo+ID4gICAgICAg ICAgICAgICAgIDwvY2hvaWNlPg0KPiA+ICAgICAgICAgICAgICAgPC9vbmVPck1vcmU+DQo+ID4N Cj4gPiBBIGxlYWYvY29udGFpbmVyIHdvdWxkIGJlIGEgc2ltcGxlciBleGFtcGxlIGJ1dCB3b3Vs ZCByZXN1bHQgaW4gdGhlIHNhbWUNCj4gbGFjayBvZiBlbmZvcmNlbWVudCBvZiB0aGUgbWFuZGF0 b3J5IHN0YXR1cyBvZiBhbiBlbGVtZW50IHdpdGggYSAid2hlbiINCj4gY2xhdXNlLg0KPiA+DQo+ ID4gVGhpcyBSTkcgc2VlbXMgY29uc2lzdGVudCB3aXRoIHRoZSBTY2hlbWF0cm9uIHJ1bGVzIHRo YXQgIndoZW4iIG1ha2VzDQo+IHNvbWV0aGluZyBvcHRpb25hbC4NCj4gPg0KPiA+DQo+ID4gSSB0 aGluayBhIHdvcmthcm91bmQgd291bGQgYmUgY2hvaWNlIHdpdGggbWFuZGF0b3J5IHRydWUgYW5k IGEgd2hlbiBjbGF1c2UNCj4gb24gdGhlIGNhc2VzLiBUaGlzIHdvdWxkIGVuc3VyZSB0aGF0IGF0 IGxlYXN0IG9uZSBjYXNlIGlzIHByZXNlbnQgc2luY2UgdGhlDQo+IG1hbmRhdG9yeSBjbGF1c2Ug aW1wbGVtZW50cyBhIFNjaGVtYXRyb24gZXhpc3RlbmNlIGNvbnN0cmFpbnQuDQo+ID4NCj4gPiBU aGFua3MNCj4gPiBNaWtlDQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPiA+ID4gU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDExOjMzIEFNDQo+ID4gPiBUbzogTWljaGFl bCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+OyBMYWRpc2xhdiBMaG90a2ENCj4g PiA+IDxsaG90a2FAbmljLmN6PjsgbmV0bW9kQGlldGYub3JnDQo+ID4gPiBDYzogV2Fsa2VyLCBK YXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSkNCj4gPiA+IDxKYXNvbl9XYWxrZXIyQGNv bWNhc3QuY29tPg0KPiA+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdp dGhpbiBtYW5kYXRvcnkgb2JqZWN0cw0KPiA+ID4gZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ugb2Yg dGhlIG1hbmRhdG9yeSBvYmplY3QNCj4gPiA+DQo+ID4gPiBIaSBNaWtlLA0KPiA+ID4NCj4gPiA+ IEkgdGhpbmsgdGhhdCB0aGUgWUFORyBiZWxvdyBhbHJlYWR5IGVuZm9yY2VzIHdoYXQgeW91IHdh bnQsIG9yDQo+ID4gPiBvdGhlcndpc2UgSSBkb24ndCBmb2xsb3cgeW91ciBpc3N1ZS4NCj4gPiA+ DQo+ID4gPiBUaGUgWUFORyBiZWxvdyBpcyB2YWxpZCBpbiB0d28gY2FzZXM6DQo+ID4gPg0KPiA+ ID4gKDEpIEFzc2lnbm1lbnRNZWNoYW5pc20gPSBESENQLCBhbmQgSVBBZGRyZXNzZXMgaXMgbm90 IHByZXNlbnQgaW4NCj4gPiA+IHRoZSBjb25maWcgKGR1ZSB0byB0aGUgd2hlbiBzdGF0ZW1lbnQp Lg0KPiA+ID4gKDIpIEFzc2lnbm1lbnRNZWNoYW5pc20gPSBTdGF0aWMsIElQQWRkcmVzc2VzIGV4 aXN0cyBhbmQgaGFzIGF0DQo+ID4gPiBsZWFzdCBvbmUgZWxlbWVudCAoZHVlIHRvIG1pbi1lbGVt ZW50cyAxKS4NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBSb2INCj4gPiA+DQo+ID4gPg0K PiA+ID4gT24gMTAvMTAvMjAxOCAxNjoyMywgTWljaGFlbCBSZWhkZXIgd3JvdGU6DQo+ID4gPiA+ IENvbnRhaW5lciAiZm9vIiB3b3VsZCBiZSBtYW5kYXRvcnkgaWYgbm90IGZvciB0aGUgIndoZW4i IGNoaWxkIGVsZW1lbnQuDQo+ID4gPiA+IFdpdGggdGhlICJ3aGVuIiBjaGlsZCBlbGVtZW50LCB0 aGUgbG9naWMgYmVjb21lcyAiaW52ZXJ0ZWQiIGFuZA0KPiA+ID4gPiB0aGUNCj4gPiA+IGNvbnN0 cmFpbnQgaXMgYSBuZWdhdGl2ZSBvbmUgb2YgImRpc2FsbG93ZWQgdW5kZXIgY2VydGFpbiBjb25k aXRpb24iLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgVUMgaXMgZm9yIGVuZm9yY2VtZW50IGluIFJF U1QgQVBJIHBheWxvYWRzLg0KPiA+ID4gPiBGb3IgYSBwcmFjdGljYWwgZXhhbXBsZToNCj4gPiA+ ID4NCj4gPiA+ID4gICAgICAgICAgIGxlYWYgQXNzaWdubWVudE1lY2hhbmlzbSB7DQo+ID4gPiA+ ICAgICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gPiA+ID4gICAgICAgICAgICAgICAg ZW51bSAiREhDUCI7DQo+ID4gPiA+ICAgICAgICAgICAgICAgIGVudW0gIlN0YXRpYyI7DQo+ID4g PiA+ICAgICAgICAgICAgICB9DQo+ID4gPiA+ICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsN Cj4gPiA+ID4gICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUaGUgYWRkcmVzcyBhc3NpZ25tZW50 IG1lY2hhbmlzbS4iOw0KPiA+ID4gPiAgICAgICAgICAgIH0NCj4gPiA+ID4gICAgICAgICAgICBs aXN0IElQQWRkcmVzc2VzIHsNCj4gPiA+ID4gICAgICAgICAgICAgIHdoZW4gIi4uL0Fzc2lnbm1l bnRNZWNoYW5pc20gPSAnU3RhdGljJyI7DQo+ID4gPiA+ICAgICAgICAgICAgICBrZXkgQWRkcmVz czsNCj4gPiA+ID4gICAgICAgICAgICAgIG1pbi1lbGVtZW50cyAxOw0KPiA+ID4gPg0KPiA+ID4g PiAgICAgICAgICAgICAgbGVhZiBBZGRyZXNzIHsNCj4gPiA+ID4gICAgICAgICAgICAgICAgdHlw ZSBjYXBpdDpJUHY0QWRkcmVzczsNCj4gPiA+ID4gICAgICAgICAgICAgICAgZGVzY3JpcHRpb24g IkFuIGlwdjQgYWRkcmVzcy4iOw0KPiA+ID4gPiAgICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAg ICAgICAgICB9DQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlIGlzIG5vIHdheSBpbiB0aGUgSVBBZGRy ZXNzZXMgbGlzdCB0byBlbmZvcmNlIHRoYXQgdGhlcmUgaXMNCj4gPiA+ID4gYXQgbGVhc3Qgb25l IElQDQo+ID4gPiBBZGRyZXNzIHdoZW4gdGhlIGFzc2lnbm1lbnQgbWV0aG9kIGlzICJTdGF0aWMi Lg0KPiA+ID4gPiBPbmUgY291bGQgcHV0IGEgIm11c3QiIG9uICJBc3NpZ25tZW50TWVjaGFuaXNt IiB0byBlbnN1cmUgYXQgbGVhc3QNCj4gPiA+ID4gb25lDQo+ID4gPiBlbGVtZW50IG9mIHRoZSBJ UEFkZHJlc3NlcyBsaXN0IHdoZW4gIlN0YXRpYyIsIGJ1dCBJIGRvbid0IHNlZSB0aGlzDQo+ID4g PiBhcyBhIGdvb2Qgc2NoZW1hIGRlc2lnbiwgdG8gaGF2ZSB0aGUgY29udHJvbGxpbmcgYXR0cmli dXRlIGNoZWNrIGNvbnRyb2xsZWQNCj4gYXR0cmlidXRlcy4NCj4gPiA+ID4NCj4gPiA+ID4gSSBh cHByZWNpYXRlIHRoYXQgdGhpcyBzZW1hbnRpYyBjYW4ndCBiZSBjaGFuZ2VkIGluIFlBTkcgYXQg dGhpcyBwb2ludC4NCj4gPiA+ID4gQ291bGQgdGhlICJ3aGVuIiBzdGF0ZW1lbnQgaGF2ZSBhIG1v ZGlmeWluZyBjaGlsZCBlbGVtZW50IHRvIHN0YXRlDQo+ID4gPiA+IHRoYXQgdGhlDQo+ID4gPiBt YW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBlbGVtZW50IGlzIHRvIGJlIGVuZm9yY2VkPw0KPiA+ID4g PiBMaWtlDQo+ID4gPiA+ICAgICAgY29udGFpbmVyIGZvbyB7DQo+ID4gPiA+ICAgICAgICB3aGVu ICJjb25kaXRpb24iIHsNCj4gPiA+ID4gICAgICAgICAgICBlbmZvcmNlLW1hbmRhdG9yeS1zdGF0 dXM7DQo+ID4gPiA+ICAgICAgICB9DQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlIGlzIGFscmVhZHkg YmFjay1lbmQgZm9yIGV4aXN0ZW50aWFsIGNoZWNrcyBmb3IgbWFuZGF0b3J5DQo+ID4gPiA+IGNo b2ljZSBzbyB0aGlzDQo+ID4gPiBzZWVtcyByZWFzb25hYmx5IGNvbnNpc3RlbnQgdG8gbWUuDQo+ ID4gPiA+IEkgYXBwcmVjaWF0ZSB0aGVyZSBhcmUgZXhpc3RpbmcgaXNzdWVzIGZvciAid2hlbiIg YnV0IEkgZG9uJ3Qgc2VlDQo+ID4gPiA+IHdoeSB0aGlzDQo+ID4gPiB3b3VsZCBtYWtlIHRoaW5n cyBhbnkgd29yc2UuDQo+ID4gPiA+IEluIGZhY3QgYnkgcHJvbW90aW5nIGEgYmV0dGVyIGRlcGVu ZGVuY3kgImRpcmVjdGlvbiIgYmV0d2Vlbg0KPiA+ID4gPiBzY2hlbWENCj4gPiA+IGVsZW1lbnRz LCAgdGhpbmsgaXQgY291bGQgc2ltcGxpZnkgdGhpbmdzIChzbyBJIG5haXZlbHkgdGhpbmsgOikg KS4NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzDQo+ID4gPiA+IE1pa2UNCj4gPiA+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+PiBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21h aWx0bzpsaG90a2FAbmljLmN6XQ0KPiA+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEw LCAyMDE4IDEwOjI4IEFNDQo+ID4gPiA+PiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVo ZGVyQEFtZG9jcy5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMNCj4gPiA+ID4+ IGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4gPiA+ Pg0KPiA+ID4gPj4gTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+IHdy aXRlczoNCj4gPiA+ID4+DQo+ID4gPiA+Pj4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQg4oCcd2hl buKAnSBhbmQgbWFuZGF0b3J5IG9iamVjdHMuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJdCBzZWVt cyB0byBtZSB0aGF0IHRoZSBpbXBsZW1lbnRlZCBzZW1hbnRpY3Mgb2Yg4oCcd2hlbuKAnSBhcmUN Cj4gPiA+ID4+PiByZWFsbHkNCj4gPiA+ID4+IOKAnG9wdGlvbmFsIHdoZW7igJ0sIGluIHRoYXQg dGhlIGVuY2xvc2luZyBvYmplY3QgY2FuIGJlIGFic2VudCBldmVuDQo+ID4gPiA+PiB0aG91Z2gg aXQgaXMgbWFuZGF0b3J5IGFuZCB0aGUg4oCcd2hlbuKAnSBjbGF1c2UgaG9sZHMgdHJ1ZS4NCj4g PiA+ID4+PiBUaGUgUkZDIGNvdWxkIGJlIGNsZWFyZXIgYWJvdXQgdGhpcy4NCj4gPiA+ID4+Pg0K PiA+ID4gPj4+IEV4YW1wbGUNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICAgICBsZWFmIGNvbG9yIHsN Cj4gPiA+ID4+PiAgICAgICBlbnVtZXJhdGlvbiAgew0KPiA+ID4gPj4+ICAgICAgICAgIGVudW0g 4oCcYmx1ZeKAnTsNCj4gPiA+ID4+PiAgICAgICAgICBlbnVtIOKAnGJsYWNr4oCdOw0KPiA+ID4g Pj4+ICAgICAgIH0NCj4gPiA+ID4+PiAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gPiA+ID4+PiAg ICAgfQ0KPiA+ID4gPj4+ICAgICBjb250YWluZXIgZm9vIHsNCj4gPiA+ID4+PiAgICAgICAgd2hl biAuLi9jb2xvciA9IOKAmGJsdWXigJk7DQo+ID4gPiA+Pj4gICAgICAgIGV0Yy4NCj4gPiA+ID4+ PiAgICAgfQ0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4g4oCcZm9v4oCdIGlzIG9wdGlvbmFsIGR1ZSB0 byB0aGUgcHJlc2VuY2Ugb2YgdGhlIOKAnHdoZW7igJ0gc3RhdGVtZW50DQo+ID4gPiA+Pj4gZXZl biB0aG91Z2ggdGhlIG9iamVjdCBpcyBtYW5kYXRvcnkgKHNhbWUgaXMgdHJ1ZSBmb3IgbWFuZGF0 b3J5DQo+ID4gPiA+Pj4gbGVhZiwNCj4gPiA+ID4+PiBtaW4tZWxlbWVudHM9MSBsaXN0IGV0Yy4p Lg0KPiA+ID4gPj4gTWF5YmUgeW91IGludGVuZGVkIHRvIGhhdmUsIGUuZy4sIGEgIm1hbmRhdG9y eSB0cnVlIiBsZWFmIGluc2lkZQ0KPiA+ID4gPj4gImNvbnRhaW5lciBmb28iPw0KPiA+ID4gPj4N Cj4gPiA+ID4+PiBUaGlzIGlzIGNvbnNpZGVyZWQgdmFsaWQgWE1MIGZvciB0aGUgYWJvdmUNCj4g PiA+ID4+PiAgICAgIDxjb2xvcj5ibHVlPC9jb2xvcj4NCj4gPiA+ID4+IFllcywgaXQgaXMsIHVu ZGVyIGN1cnJlbnQgWUFORyBydWxlcywgbm8gbWF0dGVyIHdoYXQgImV0Yy4iDQo+ID4gPiA+PiBz dGFuZHMgZm9yLiBOb3RlIHRoYXQgZXZhbHVhdGlvbiBvZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBp biB0aGlzDQo+ID4gPiA+PiBjYXNlICh3aXRoICJmb28iIG1pc3NpbmcpIHJlcXVpcmVzIHRoZSBw ZWN1bGlhciBwcm9jZWR1cmUgb2Ygc2VjLiA3LjIxLjUNCj4gaW4gUkZDIDc5NTAuDQo+ID4gPiA+ Pg0KPiA+ID4gPj4+IEluIG15IHZpZXcgdGhpcyBtYWtlcyBjb25kaXRpb25hbGx5IHZhcmlhbnQg c2NoZW1hcyDigJxsb29zZeKAnSBpbg0KPiA+ID4gPj4+IHRoZWlyIGVuZm9yY2VtZW50IChzb21l IHNjZW5hcmlvcyBjYW4gdXNlIGNob2ljZSBidXQgaXQgZG9lc27igJl0DQo+ID4gPiA+Pj4gY292 ZXIgZXZlcnl0aGluZykuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJIHRoaW5rIHRoYXQgbWFuZGF0 b3J5IHNob3VsZCBiZSByZXNwZWN0ZWQgZm9yIHRoZSBlbmNsb3NpbmcNCj4gPiA+ID4+PiBvYmpl Y3RzIG9mIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQuICBUaGF0IGlzLCBhIG1hbmRhdG9yeSBvYmpl Y3QgbXVzdA0KPiA+ID4gPj4+IGJlIHByZXNlbnQgd2hlbiBpdHMg4oCcd2hlbuKAnSBjbGF1c2Ug aG9sZHMgdHJ1ZSBhbmQgYSBTY2hlbWF0cm9uDQo+ID4gPiA+Pj4gc3RhdGVtZW50IHNob3VsZCBl bmZvcmNlIHRoYXQuDQo+ID4gPiA+PiBJbiBmYWN0LCB0aGlzIGlzIG9uZSBjYXNlIHdoZXJlIHRo ZSBEU0RMIG1hcHBpbmcgKFJGQyA2MTEwKQ0KPiA+ID4gPj4gZGV2aWF0ZXMgZnJvbSBZQU5HIDEu MC4gTm9kZXMgdGhhdCBtYW5kYXRvcnkgYXJlbid0IGVuY2xvc2VkIGluDQo+ID4gPiA+PiB0aGUg UkVMQVggTkcgPG9wdGlvbmFsPiBwYXR0ZXJuLCBhbmQgYXJlIHRoZW4gcmVxdWlyZWQgbm8gbWF0 dGVyIHdoYXQNCj4gYW55ICJ3aGVuIg0KPiA+ID4gPj4gc3RhdGVtZW50cyBzYXkgKGJlY2F1c2Ug UkVMQVggTkcgdmFsaWRhdGlvbiBjb21lcyBiZWZvcmUNCj4gU2NoZW1hdHJvbikuDQo+ID4gPiA+ Pg0KPiA+ID4gPj4+IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGN1cnJlbnQgWUFO RyBydWxlcyBiZWhhdmlvciwNCj4gPiA+ID4+PiB0aGF0IHRoZSDigJx3aGVu4oCdIFNjaGVtYXRy b24gbWFwcGluZyBkb2VzbuKAmXQgY2hlY2sgZm9yIHByZXNlbmNlIG9mDQo+ID4gPiA+Pj4gdGhl IGVuY2xvc2luZyBtYW5kYXRvcnkgb2JqZWN0Pw0KPiA+ID4gPj4gRldJVywgSSBoYXZlIGJlZW4g cmVwZWF0ZWRseSBwcm90ZXN0aW5nIGFnYWluc3QgdGhpcyBiZWhhdmlvdXINCj4gPiA+ID4+IGJ1 dCB3aXRob3V0IG11Y2ggbHVjay4gU2VlIGZvciBleGFtcGxlDQo+ID4gPiA+Pg0KPiA+ID4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cx NDAxMi5odG0NCj4gPiA+ID4+IGwNCj4gPiA+ID4+DQo+ID4gPiA+PiBBcyBhIHJlc3VsdCwgIndo ZW4iIGlzIHRoZSB0cmlja2llc3QgZmVhdHVyZSBpbiBZQU5HIGJ5IGZhci4NCj4gPiA+ID4+DQo+ ID4gPiA+PiBMYWRhDQo+ID4gPiA+Pg0KPiA+ID4gPj4+IHRoYW5rcw0KPiA+ID4gPj4+IE1pa2Ug UmVoZGVyDQo+ID4gPiA+PiAtLQ0KPiA+ID4gPj4gTGFkaXNsYXYgTGhvdGthDQo+ID4gPiA+PiBI ZWFkLCBDWi5OSUMgTGFicw0KPiA+ID4gPj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3 DQo+ID4gPiA+IOKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJk LXBhcnR5LCB3b3JsZHdpZGUsDQo+ID4gPiA+IGNsb3VkLWJhc2VkDQo+ID4gPiBzeXN0ZW0uIEFu eSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2lu Zw0KPiA+ID4gc3VjaCBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHBy b3ZpZGVycyBvZiBzdWNoDQo+ID4gPiBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNl bmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcw0KPiA+ID4gZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0 byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsDQo+IHN0b3Jpbmcg YW5kIGFjY2Vzc+KAnS4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBuZXRt b2RAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4gPg0KPiA+IOKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBv biBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkDQo+IHN5c3RlbS4gQW55IGVt YWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1 Y2gNCj4gc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMg b2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkDQo+IGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1h aWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2YNCj4gc3Vj aCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9u ZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBi YXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55 IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5n IHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMg b2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxz IHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0 ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLgo= From nobody Wed Oct 10 11:51:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8367126BED for ; Wed, 10 Oct 2018 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 ReKU1WqEZDpB for ; Wed, 10 Oct 2018 11:51:43 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 E3C78124BE5 for ; Wed, 10 Oct 2018 11:51:42 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id p89-v6so5891892ljb.3 for ; Wed, 10 Oct 2018 11:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=58CX7wF4BxwpPrz6XUkXaYoZ+I+zpxWGQRdVr2RkYIw=; b=GuhaGo8nyZxu7XnOM4MYlVtVLnL6tWn8a9YZt8+JR+stF5+5md3mxzadX0jw3AEbg6 O4SFSXqvBEY+nUm02zS8q+P4gwIttn7q8C00CcerfrHrM6WdAGP5SPVlg2bfZPuTpnJ8 m/REGZRvPLfQiBY6BoI+QeGs9Li8u97KEqarKuVB6GwsBPQ1S3WnAB7+R5fg+TElCJLU kOiZA69AiKOVeHSlV/EIH8Hi3MlUj0iDaY9Q+ysiW300Xw2GRe7uZVynnsc74Y3xpB+5 7Ic3yyI+a9mTd6z13SwrxNzLDeCfYgXMLipfLK23KKKdf1LXJP17bt3w68GX53NY3rRR 4R+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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=58CX7wF4BxwpPrz6XUkXaYoZ+I+zpxWGQRdVr2RkYIw=; b=iwOhR3NKucQ41UhcCcEZH7Tzxso+VQDZLP8cMKsEujixGRKGWR+AWAWt25msja4aNB HxdlqSih0jkKu8FGYXnDNPDe0Bleuv2dqIev+lIuMPQf9znArAWHNDYZ+/QOxCyQbcts VnNKnOqyBxF/6QAqohyiBq/Vdzi3lZ0nyEtCQnqVSF5ksS3iPOlCk6FRMf+CahFA08VK GpGqZSjCujQeQ+A9punvmhkqKCIZ4lgUCN+8bGSC9k/+u0mfc5KaG55KyFtu7H7UUSqJ rmXQj1TgpG4Uk/Gl7MoOrXULO5rD6XqF8bat8XYVxqr/VEQ7kv9rqpl4yWbnwCP3/qFV waGQ== X-Gm-Message-State: ABuFfohRAGxss8jr+XpTC3u8QtLi1BYI2o7Y4gyntv3oy0p2GBjZiaeN cJpB37CDS3NG90t+83Ederc9Qs5Wj41zdhWB0BzSKRP8 X-Google-Smtp-Source: ACcGV60HEiRd2jFMwYE5Msdyix6UOpRQ0V0RbWuEsvN4TN5Syjw6BkjYEPi9Sto830v/tfOWMDbp0EYiKag4o2CbSvY= X-Received: by 2002:a2e:1456:: with SMTP id 22-v6mr10451061lju.116.1539197500890; Wed, 10 Oct 2018 11:51:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Wed, 10 Oct 2018 11:51:39 -0700 (PDT) In-Reply-To: References: <87zhvlvpts.fsf@nic.cz> <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Wed, 10 Oct 2018 11:51:39 -0700 Message-ID: To: Michael Rehder Cc: Juergen Schoenwaelder , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047b56e0577e458ca" Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:51:48 -0000 --00000000000047b56e0577e458ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder wrote: > Sure. > > I think the RFC is unclear since it seems that the semantics are > consistent in the back-end checks. > One can read the RFC and not notice by its absence that the when clause > doesn't require anything to be present. > > The "when" statement makes its parent data definition statement > conditional. > Should be > The "when" statement makes its parent data definition statement > conditional and optional. > > This is not correct. Step 1) if-feature makes the schema node conditional Step 2) when-stmt makes instances of the schema-node conditional Step 3) YANG validation applies to instances of data nodes (or the YANG default value if applicable) Step 2 is only relevant if Step 1 is true or non-existent Step 3 is only relevant if Step 2 is true or non-existent Andy > I think there should be a more definite statement about this overriding > any mandatory status of the parent data definition statement. > Like > "Any mandatory status of the parent data definition statement > (mandatory statement, min-element statement etc.) is overridden by this > statement and made non-mandatory." > > That would have made the side-effect of "when" on other declarations > clearer. > > Thanks > mike > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e > ] > > Sent: Wednesday, October 10, 2018 2:25 PM > > To: Michael Rehder > > Cc: Robert Wilton ; Ladislav Lhotka ; > > netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com) > > > > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't > > ensure presence of the mandatory object > > > > Michael, > > > > what matters here is what the YANG specification (RFC 7950) says. Is > there a > > reason to believe the IPAddresses list in your example can be absent or > have no > > elements based on what RFC 7950 says? Or do we talk about a shortcoming > of > > RFC 6110? > > > > /js > > > > On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote: > > > If the list has a "when" clause the RNG file actually produces a > "OneOrMore" > > which has a choice of or the list so it actually doesn't enforc= e > the > > presence at least one row of the list (unless I'm mistaken in my > reading). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A leaf/container would be a simpler example but would result in the > same > > lack of enforcement of the mandatory status of an element with a "when" > > clause. > > > > > > This RNG seems consistent with the Schematron rules that "when" makes > > something optional. > > > > > > > > > I think a workaround would be choice with mandatory true and a when > clause > > on the cases. This would ensure that at least one case is present since > the > > mandatory clause implements a Schematron existence constraint. > > > > > > Thanks > > > Mike > > > > -----Original Message----- > > > > From: Robert Wilton [mailto:rwilton@cisco.com] > > > > Sent: Wednesday, October 10, 2018 11:33 AM > > > > To: Michael Rehder ; Ladislav Lhotka > > > > ; netmod@ietf.org > > > > Cc: Walker, Jason (Jason_Walker2@comcast.com) > > > > > > > > Subject: Re: [netmod] WHEN statement within mandatory objects > > > > doesn't ensure presence of the mandatory object > > > > > > > > Hi Mike, > > > > > > > > I think that the YANG below already enforces what you want, or > > > > otherwise I don't follow your issue. > > > > > > > > The YANG below is valid in two cases: > > > > > > > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not present in > > > > the config (due to the when statement). > > > > (2) AssignmentMechanism =3D Static, IPAddresses exists and has at > > > > least one element (due to min-elements 1). > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 10/10/2018 16:23, Michael Rehder wrote: > > > > > Container "foo" would be mandatory if not for the "when" child > element. > > > > > With the "when" child element, the logic becomes "inverted" and > > > > > the > > > > constraint is a negative one of "disallowed under certain condition= ". > > > > > > > > > > The UC is for enforcement in REST API payloads. > > > > > For a practical example: > > > > > > > > > > leaf AssignmentMechanism { > > > > > type enumeration { > > > > > enum "DHCP"; > > > > > enum "Static"; > > > > > } > > > > > mandatory true; > > > > > description "The address assignment mechanism."; > > > > > } > > > > > list IPAddresses { > > > > > when "../AssignmentMechanism =3D 'Static'"; > > > > > key Address; > > > > > min-elements 1; > > > > > > > > > > leaf Address { > > > > > type capit:IPv4Address; > > > > > description "An ipv4 address."; > > > > > } > > > > > } > > > > > > > > > > There is no way in the IPAddresses list to enforce that there is > > > > > at least one IP > > > > Address when the assignment method is "Static". > > > > > One could put a "must" on "AssignmentMechanism" to ensure at leas= t > > > > > one > > > > element of the IPAddresses list when "Static", but I don't see this > > > > as a good schema design, to have the controlling attribute check > controlled > > attributes. > > > > > > > > > > I appreciate that this semantic can't be changed in YANG at this > point. > > > > > Could the "when" statement have a modifying child element to stat= e > > > > > that the > > > > mandatory status of the element is to be enforced? > > > > > Like > > > > > container foo { > > > > > when "condition" { > > > > > enforce-mandatory-status; > > > > > } > > > > > > > > > > There is already back-end for existential checks for mandatory > > > > > choice so this > > > > seems reasonably consistent to me. > > > > > I appreciate there are existing issues for "when" but I don't see > > > > > why this > > > > would make things any worse. > > > > > In fact by promoting a better dependency "direction" between > > > > > schema > > > > elements, think it could simplify things (so I naively think :) ). > > > > > > > > > > Thanks > > > > > Mike > > > > >> -----Original Message----- > > > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > > > >> Sent: Wednesday, October 10, 2018 10:28 AM > > > > >> To: Michael Rehder ; netmod@ietf.org > > > > >> Subject: Re: [netmod] WHEN statement within mandatory objects > > > > >> doesn't ensure presence of the mandatory object > > > > >> > > > > >> Michael Rehder writes: > > > > >> > > > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D and mandatory ob= jects. > > > > >>> > > > > >>> It seems to me that the implemented semantics of =E2=80=9Cwhen= =E2=80=9D are > > > > >>> really > > > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclosing object ca= n be absent even > > > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80=9D clause hol= ds true. > > > > >>> The RFC could be clearer about this. > > > > >>> > > > > >>> Example > > > > >>> > > > > >>> leaf color { > > > > >>> enumeration { > > > > >>> enum =E2=80=9Cblue=E2=80=9D; > > > > >>> enum =E2=80=9Cblack=E2=80=9D; > > > > >>> } > > > > >>> mandatory true; > > > > >>> } > > > > >>> container foo { > > > > >>> when ../color =3D =E2=80=98blue=E2=80=99; > > > > >>> etc. > > > > >>> } > > > > >>> > > > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the presence of the = =E2=80=9Cwhen=E2=80=9D statement > > > > >>> even though the object is mandatory (same is true for mandatory > > > > >>> leaf, > > > > >>> min-elements=3D1 list etc.). > > > > >> Maybe you intended to have, e.g., a "mandatory true" leaf inside > > > > >> "container foo"? > > > > >> > > > > >>> This is considered valid XML for the above > > > > >>> blue > > > > >> Yes, it is, under current YANG rules, no matter what "etc." > > > > >> stands for. Note that evaluation of the XPath expression in this > > > > >> case (with "foo" missing) requires the peculiar procedure of sec= . > 7.21.5 > > in RFC 7950. > > > > >> > > > > >>> In my view this makes conditionally variant schemas =E2=80=9Clo= ose=E2=80=9D in > > > > >>> their enforcement (some scenarios can use choice but it doesn= =E2=80=99t > > > > >>> cover everything). > > > > >>> > > > > >>> I think that mandatory should be respected for the enclosing > > > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement. That is, a mand= atory object must > > > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clause holds true an= d a Schematron > > > > >>> statement should enforce that. > > > > >> In fact, this is one case where the DSDL mapping (RFC 6110) > > > > >> deviates from YANG 1.0. Nodes that mandatory aren't enclosed in > > > > >> the RELAX NG pattern, and are then required no matter > what > > any "when" > > > > >> statements say (because RELAX NG validation comes before > > Schematron). > > > > >> > > > > >>> What is the rationale behind the current YANG rules behavior, > > > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapping doesn=E2=80= =99t check for presence of > > > > >>> the enclosing mandatory object? > > > > >> FWIW, I have been repeatedly protesting against this behaviour > > > > >> but without much luck. See for example > > > > >> > > > > >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.ht= m > > > > >> l > > > > >> > > > > >> As a result, "when" is the trickiest feature in YANG by far. > > > > >> > > > > >> Lada > > > > >> > > > > >>> thanks > > > > >>> Mike Rehder > > > > >> -- > > > > >> Ladislav Lhotka > > > > >> Head, CZ.NIC Labs > > > > >> PGP Key ID: 0xB8F92B08A9F76C67 > > > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party= , worldwide, > > > > > cloud-based > > > > system. Any emails sent to Amdocs will be processed and stored usin= g > > > > such system and are accessible by third party providers of such > > > > system on a limited basis. Your sending of emails to Amdocs > > > > evidences your consent to the use of such system and such processin= g, > > storing and access=E2=80=9D. > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, wo= rldwide, > cloud-based > > system. Any emails sent to Amdocs will be processed and stored using su= ch > > system and are accessible by third party providers of such system on a > limited > > basis. Your sending of emails to Amdocs evidences your consent to the > use of > > such system and such processing, storing and access=E2=80=9D. > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw= ide, cloud-based > system. Any emails sent to Amdocs will be processed and stored using such > system and are accessible by third party providers of such system on a > limited basis. Your sending of emails to Amdocs evidences your consent to > the use of such system and such processing, storing and access=E2=80=9D. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000047b56e0577e458ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <= Michael.Rehd= er@amdocs.com> wrote:
Sure.=

I think the RFC is unclear since it seems that the semantics are consistent= in the back-end checks.
One can read the RFC and not notice by its absence that the when clause doe= sn't require anything to be present.

=C2=A0 =C2=A0 =C2=A0The "when" statement makes its parent data de= finition statement conditional.
Should be
=C2=A0 =C2=A0 The "when" statement makes its parent data definiti= on statement conditional and optional.


This is not correct.

Step 1) if-feature makes the schema node conditional

=
Step 2) when-stmt makes instances of the schema-node conditional=

Step 3) YANG validation applies to instances of d= ata nodes (or the YANG default value if applicable)

Step 2 is only relevant if Step 1 is true or non-existent
Step = 3 is only relevant if Step 2 is true or non-existent

Andy

=C2=A0
I think there should be a more definite statement about this overriding any= mandatory status of the parent data definition statement.
Like
=C2=A0 =C2=A0 =C2=A0"Any mandatory status of the parent data definitio= n statement (mandatory statement, min-element statement etc.) is overridden= by this statement and made non-mandatory."

That would have made the side-effect of "when" on other declarati= ons clearer.

Thanks
mike
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Wednesday, October 10, 2018 2:25 PM
> To: Michael Rehder <Michael.Rehder@Amdocs.com>
> Cc: Robert Wilton <rwilton@cis= co.com>; Ladislav Lhotka <lhotka= @nic.cz>;
> netmod@ietf.org; Walker, Jason = (Jason_Walker2@comcast.com= )
> <Jason_Walker2@comcast= .com>
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn= 9;t
> ensure presence of the mandatory object
>
> Michael,
>
> what matters here is what the YANG specification (RFC 7950) says. Is t= here a
> reason to believe the IPAddresses list in your example can be absent o= r have no
> elements based on what RFC 7950 says? Or do we talk about a shortcomin= g of
> RFC 6110?
>
> /js
>
> On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:
> > If the list has a "when" clause the RNG file actually p= roduces a "OneOrMore"
> which has a choice of <empty> or the list so it actually doesn&#= 39;t enforce the
> presence at least one row of the list (unless I'm mistaken in my r= eading).
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<oneOrMo= re>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= choice>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<empty/>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<element name=3D"IPAddresses">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<element name=3D"Address">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<ref name=3D"types__IPv4Address"/>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0</element>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<empty/>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0</element>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= /choice>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</oneOrM= ore>
> >
> > A leaf/container would be a simpler example but would result in t= he same
> lack of enforcement of the mandatory status of an element with a "= ;when"
> clause.
> >
> > This RNG seems consistent with the Schematron rules that "wh= en" makes
> something optional.
> >
> >
> > I think a workaround would be choice with mandatory true and a wh= en clause
> on the cases. This would ensure that at least one case is present sinc= e the
> mandatory clause implements a Schematron existence constraint.
> >
> > Thanks
> > Mike
> > > -----Original Message-----
> > > From: Robert Wilton [mailto:rwilton@cisco.com]
> > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > To: Michael Rehder <Michael.Rehder@Amdocs.com>; Ladisl= av Lhotka
> > > <lhotka@nic.cz>; = netmod@ietf.org
> > > Cc: Walker, Jason (Jason_Walker2@comcast.com)
> > > <Jason_Walke= r2@comcast.com>
> > > Subject: Re: [netmod] WHEN statement within mandatory object= s
> > > doesn't ensure presence of the mandatory object
> > >
> > > Hi Mike,
> > >
> > > I think that the YANG below already enforces what you want, = or
> > > otherwise I don't follow your issue.
> > >
> > > The YANG below is valid in two cases:
> > >
> > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not pre= sent in
> > > the config (due to the when statement).
> > > (2) AssignmentMechanism =3D Static, IPAddresses exists and h= as at
> > > least one element (due to min-elements 1).
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > Container "foo" would be mandatory if not for= the "when" child element.
> > > > With the "when" child element, the logic beco= mes "inverted" and
> > > > the
> > > constraint is a negative one of "disallowed under certa= in condition".
> > > >
> > > > The UC is for enforcement in REST API payloads.
> > > > For a practical example:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf Assignment= Mechanism {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type en= umeration {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = enum "DHCP";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = enum "Static";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandato= ry true;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descrip= tion "The address assignment mechanism.";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list IPAddress= es {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when &q= uot;../AssignmentMechanism =3D 'Static'";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key Add= ress;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 min-ele= ments 1;
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf Ad= dress {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = type capit:IPv4Address;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = description "An ipv4 address.";
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >
> > > > There is no way in the IPAddresses list to enforce that= there is
> > > > at least one IP
> > > Address when the assignment method is "Static". > > > > One could put a "must" on "AssignmentMec= hanism" to ensure at least
> > > > one
> > > element of the IPAddresses list when "Static", but= I don't see this
> > > as a good schema design, to have the controlling attribute c= heck controlled
> attributes.
> > > >
> > > > I appreciate that this semantic can't be changed in= YANG at this point.
> > > > Could the "when" statement have a modifying c= hild element to state
> > > > that the
> > > mandatory status of the element is to be enforced?
> > > > Like
> > > >=C2=A0 =C2=A0 =C2=A0 container foo {
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "condition" {=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce-mandat= ory-status;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >
> > > > There is already back-end for existential checks for ma= ndatory
> > > > choice so this
> > > seems reasonably consistent to me.
> > > > I appreciate there are existing issues for "when&q= uot; but I don't see
> > > > why this
> > > would make things any worse.
> > > > In fact by promoting a better dependency "directio= n" between
> > > > schema
> > > elements,=C2=A0 think it could simplify things (so I naively= think :) ).
> > > >
> > > > Thanks
> > > > Mike
> > > >> -----Original Message-----
> > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > > >> Sent: Wednesday, October 10, 2018 10:28 AM
> > > >> To: Michael Rehder <Michael.Rehder@Amdocs.com>= ;; netmod@ietf.org
> > > >> Subject: Re: [netmod] WHEN statement within mandato= ry objects
> > > >> doesn't ensure presence of the mandatory object=
> > > >>
> > > >> Michael Rehder <Michael.Rehder@Amdocs.com> wr= ites:
> > > >>
> > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D = and mandatory objects.
> > > >>>
> > > >>> It seems to me that the implemented semantics o= f =E2=80=9Cwhen=E2=80=9D are
> > > >>> really
> > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclos= ing object can be absent even
> > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80= =9D clause holds true.
> > > >>> The RFC could be clearer about this.
> > > >>>
> > > >>> Example
> > > >>>
> > > >>>=C2=A0 =C2=A0 =C2=A0leaf color {
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration=C2=A0 { > > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80= =9Cblue=E2=80=9D;
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80= =9Cblack=E2=80=9D;
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> > > >>>=C2=A0 =C2=A0 =C2=A0}
> > > >>>=C2=A0 =C2=A0 =C2=A0container foo {
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 when ../color =3D = =E2=80=98blue=E2=80=99;
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 etc.
> > > >>>=C2=A0 =C2=A0 =C2=A0}
> > > >>>
> > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the pr= esence of the =E2=80=9Cwhen=E2=80=9D statement
> > > >>> even though the object is mandatory (same is tr= ue for mandatory
> > > >>> leaf,
> > > >>> min-elements=3D1 list etc.).
> > > >> Maybe you intended to have, e.g., a "mandatory= true" leaf inside
> > > >> "container foo"?
> > > >>
> > > >>> This is considered valid XML for the above
> > > >>>=C2=A0 =C2=A0 =C2=A0 <color>blue</color= >
> > > >> Yes, it is, under current YANG rules, no matter wha= t "etc."
> > > >> stands for. Note that evaluation of the XPath expre= ssion in this
> > > >> case (with "foo" missing) requires the pe= culiar procedure of sec. 7.21.5
> in RFC 7950.
> > > >>
> > > >>> In my view this makes conditionally variant sch= emas =E2=80=9Cloose=E2=80=9D in
> > > >>> their enforcement (some scenarios can use choic= e but it doesn=E2=80=99t
> > > >>> cover everything).
> > > >>>
> > > >>> I think that mandatory should be respected for = the enclosing
> > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement.= =C2=A0 That is, a mandatory object must
> > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clau= se holds true and a Schematron
> > > >>> statement should enforce that.
> > > >> In fact, this is one case where the DSDL mapping (R= FC 6110)
> > > >> deviates from YANG 1.0. Nodes that mandatory aren&#= 39;t enclosed in
> > > >> the RELAX NG <optional> pattern, and are then= required no matter what
> any "when"
> > > >> statements say (because RELAX NG validation comes b= efore
> Schematron).
> > > >>
> > > >>> What is the rationale behind the current YANG r= ules behavior,
> > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapp= ing doesn=E2=80=99t check for presence of
> > > >>> the enclosing mandatory object?
> > > >> FWIW, I have been repeatedly protesting against thi= s behaviour
> > > >> but without much luck. See for example
> > > >>
> > > >> https://www= .ietf.org/mail-archive/web/netmod/current/msg14012.htm
> > > >> l
> > > >>
> > > >> As a result, "when" is the trickiest feat= ure in YANG by far.
> > > >>
> > > >> Lada
> > > >>
> > > >>> thanks
> > > >>> Mike Rehder
> > > >> --
> > > >> Ladislav Lhotka
> > > >> Head, CZ.NIC Labs
> > > >> PGP Key ID: 0xB8F92B08A9F76C67
> > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a t= hird-party, worldwide,
> > > > cloud-based
> > > system. Any emails sent to Amdocs will be processed and stor= ed using
> > > such system and are accessible by third party providers of s= uch
> > > system on a limited basis. Your sending of emails to Amdocs<= br> > > > evidences your consent to the use of such system and such pr= ocessing,
> storing and access=E2=80=9D.
> > > > _______________________________________________ > > > > netmod mailing list
> > > > netmod@ietf.org<= br> > > > > https://www.ietf.org/mailman/li= stinfo/netmod
> >
> > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party= , worldwide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using s= uch
> system and are accessible by third party providers of such system on a= limited
> basis. Your sending of emails to Amdocs evidences your consent to the = use of
> such system and such processing, storing and access=E2=80=9D.
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldwid= e, cloud-based system. Any emails sent to Amdocs will be processed and stor= ed using such system and are accessible by third party providers of such sy= stem on a limited basis. Your sending of emails to Amdocs evidences your co= nsent to the use of such system and such processing, storing and access=E2= =80=9D.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--00000000000047b56e0577e458ca-- From nobody Wed Oct 10 12:46:14 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C86126F72; Wed, 10 Oct 2018 12:46:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-netmod-schema-mount@ietf.org, Joel Jaeggli , Lou Berger , Kent Watsen , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153920076529.5791.8718186118017388016.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2018 12:46:05 -0700 Archived-At: Subject: [netmod] Spencer Dawkins' Yes on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 19:46:06 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-netmod-schema-mount-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I really like that you've provided this capability. It might be that I've spent too much time doing Unix, but I wonder if "Yang Schema Mount Point" would be a clearer title? From nobody Wed Oct 10 13:30:13 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4721277BB; Wed, 10 Oct 2018 13:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-netmod-schema-mount@ietf.org, Joel Jaeggli , Lou Berger , Kent Watsen , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153920340311.5891.2170334410096287507.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2018 13:30:03 -0700 Archived-At: Subject: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 20:30:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-netmod-schema-mount-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: §3.3, 4th paragraph: The MUST NOT seems like a statement of fact -- if no schema is mounted, it doesn't seem possible for it to include anything. §5, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever make sense to violate this? §9: The model includes RFC 2119 boilerplate, but the document itself uses the newer RFC 8174 boilerplate. Is it normal to include the normative keyword boilerplate in the model? If so, it should probably match that of the containing document. Editorial: §1, list item 2: "... and is stable as YANG library information of the server." Assuming you mean specific YANG library information rather than the general concept, there is a missing article before "YANG". (This pattern repeats a few time throughout the document.) From nobody Wed Oct 10 15:06:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B165128CFD for ; Wed, 10 Oct 2018 15:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzO6Ru48SR6i for ; Wed, 10 Oct 2018 15:06:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C1965128D68 for ; Wed, 10 Oct 2018 15:06:49 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 35604392F72D6; Wed, 10 Oct 2018 23:06:44 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 10 Oct 2018 23:06:46 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.47]) by SJCEML703-CHM.china.huawei.com ([169.254.5.166]) with mapi id 14.03.0415.000; Wed, 10 Oct 2018 15:06:41 -0700 From: Alexander Clemm To: Kent Watsen , Ladislav Lhotka , "Andy Bierman" , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyQUI2nNckn+1ky1f4oa9l5TQKUPVRSAgAAnqICAAARaAIAABz8AgABBFoCAAAiTAIAAGC0AgAAFdICAAAvggIAAw7yAgAUeeMCAAckwAIABa8oQ Date: Wed, 10 Oct 2018 22:06:41 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 22:06:52 -0000 V2hpY2ggZm9ybWF0IHRvIG1ha2UgbWFuZGF0b3J5IHNvdW5kcyBsaWtlIHNvbWV0aGluZyB3ZSBj YW4gZGlzY3VzcyBpbiBCYW5na29rLiAgVGhlIHJlYXNvbiBZQU5HLXBhdGNoIHdhcyBjaG9zZW4g aXMgcmV1c2UsIGFsdGhvdWdoIGl0IGlzIGNlcnRhaW5seSBjb25jZWl2YWJsZSB0byBkZXZlbG9w IGFub3RoZXIgZm9ybWF0LiAgKFBlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHdlIHdpbGwgcHV0 IHRoZSBob29rcyBpbiBwbGFjZSB0byBhbGxvdyBmb3Igb3RoZXIgb3B0aW9ucy4pICBFaXRoZXIg d2F5LCB0aGlzIHNlZW1zIHRvIGJlIG9uZSBvZiB0aGUgdGVjaG5pY2FsIGRldGFpbHMgdGhhdCBu ZWVkIHRvIGJlIGRlY2lkZWQsIG5vdCBzb21ldGhpbmcgdGhhdCB3b3VsZCBtYWtlIG9yIGJyZWFr IHN1cHBvcnQgYXMgYSB3aG9sZT8gIA0KLS0tIEFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRd DQo+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDksIDIwMTggMTA6MTcgQU0NCj4gVG86IEFsZXhh bmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBMYWRpc2xhdiBMaG90a2EN Cj4gPGxob3RrYUBuaWMuY3o+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IEp1 ZXJnZW4NCj4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPjsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBhZG9wdGlv biBwb2xsIGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+IA0KPiBJIGFncmVl IHRoYXQgYSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCBpcyBkZXNpcmFibGUuDQo+IA0K PiBJIGRpc2FncmVlIHRoYXQgWUFORy1QYXRjaCBpcyB0aGUgcmlnaHQgZm9ybWF0LCBmb3IgcmVh c29ucyBzdGF0ZWQgYmVmb3JlLiAgSSBmZWVsDQo+IHRoYXQgYSBjb21wcm9taXNlIG9mIHRoaXMg c29ydCBmb3IgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlzIHdyb25nLg0KPiANCj4gSWYgdGhp cyBpcyB3aGF0IHRoZSBXRyB3YW50cywgSSB3aXRoZHJhdyBteSBzdXBwb3J0Lg0KPiANCj4gS2Vu dCAvLyBjb250cmlidXRvcg0KPiANCj4gDQo+IA0KPiDvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t Pg0KPiBEYXRlOiBNb25kYXksIE9jdG9iZXIgOCwgMjAxOCBhdCA1OjA1IFBNDQo+IFRvOiBMYWRp c2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVy Lm5ldD4sDQo+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiwgSnVlcmdlbiBTY2hv ZW53YWVsZGVyDQo+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCAibmV0 bW9kQGlldGYub3JnIg0KPiA8bmV0bW9kQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW25ldG1v ZF0gV0cgYWRvcHRpb24gcG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0K PiANCj4gSSB3b3VsZCBzZWNvbmQgdGhlIHJlcXVlc3QgZm9yIG9uZSBmb3JtYXQgKHdoaWNoIGlz IG1hbmRhdG9yeSB0byBzdXBwb3J0KSwNCj4gd2hpY2ggbXVzdCBiZSBzcGVjaWZpZWQuICBZQU5H LVBhdGNoIGlzIHRoZSBsb2dpY2FsIGNhbmRpZGF0ZSBJTUhPLg0KPiANCj4gVG8gYWxsb3cgc2Vs ZWN0aW9uIG9mIG90aGVyIGZvcm1hdHMgdXNpbmcgYW4gaW5wdXQgcGFyYW1ldGVyIG1ha2VzIHNl bnNlLCBidXQNCj4gYWRkcyBzb21lIGNvbXBsZXhpdHkgZnJvbSB0aGVyZTogIEhvdyB0byBrbm93 IHdoaWNoIGZvcm1hdHMgYXJlIHN1cHBvcnRlZD8NCj4gKEFkZCBhIGxpc3Qgb2Ygc3VwcG9ydGVk IGZvcm1hdHMgc29tZXdoZXJlPykgICBPciBzaW1wbHkgcmVseSBvbiBhdWdtZW50YXRpb24NCj4g Zm9yIHRob3NlIGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgaXQ/DQo+IA0KPiAtLS0gQWxleA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG5ldG1vZCBbbWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFkaXNsYXYNCj4gPiBM aG90a2ENCj4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDUsIDIwMTggMTI6NTAgQU0NCj4gPiBU bzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBBbmR5IEJpZXJtYW4NCj4gPiA8 YW5keUB5dW1hd29ya3MuY29tPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLQ0KPiA+IHVuaXZlcnNpdHkuZGU+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4gPiBkcmFmdC1jbGVtbS1u ZXRtb2Qtbm1kYS1kaWZmLTAwDQo+ID4NCj4gPiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVy Lm5ldD4gd3JpdGVzOg0KPiA+DQo+ID4gPiBTdXJlLCBvbmUgbWFuZGF0b3J5IHRvIGltcGxlbWVu dCBmb3JtYXQsIG90aGVycyBuaWNlIHRvIGhhdmUuDQo+ID4gPiBJbnRlcm9wZXJhYmlsaXR5IGdv b2QuICBBZ3JlZWQuDQo+ID4gPg0KPiA+ID4gQnV0IHdoeSBZQU5HLXBhdGNoIGFuZCBub3Qgc29t ZXRoaW5nIGJ1aWx0IGZvciB0aGUgcHVycG9zZSAoZS5nLiwNCj4gPiA+IFlBTkctZGlmZikgdGhh dCwgaW4gcGFydGljdWxhciwgcHJvdmlkZXMgYW4gYWN0dWFsIGRpZmYgYXMgb3Bwb3NlZA0KPiA+ ID4gdG8gYSBkYXRhLXRyZWUgb3BlcmF0aW9uIHRoYXQgb25seSBzaG93cyBvbmUgb2YgdGhlIHR3 byB2YWx1ZXM/DQo+ID4NCj4gPiBTdWNoIGEgZm9ybWF0IGNhbiBiZSBkZXZlbG9wZWQgaW5kZXBl bmRlbnRseSwgSSB3b3VsZCBzdXBwb3J0IGl0Lg0KPiA+DQo+ID4gTGFkYQ0KPiA+DQo+ID4gPg0K PiA+ID4gS2VudCAvLyBjb250cmlidXRvcg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAxMC80LzE4 LCAzOjI3IFBNLCAiQW5keSBCaWVybWFuIg0KPiA+IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IE9uIFRodSwgT2N0IDQs IDIwMTggYXQgMTI6MDcgUE0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiA+IDxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt DQo+ID4gdW5pdmVyc2l0eS5kZT4+IHdyb3RlOg0KPiA+ID4gRm9sa3MsIHRoZSBtb3JlIGZvcm1h dHMgdGhlcmUgYXJlLCB0aGUgbGVzcyBpbnRlcm9wZXJhYmlsaXR5IHdlIGdldC4NCj4gPiA+IElm IHRoZXJlIGFyZSBtdWx0aXBsZSBmb3JtYXRzLCBpcyB0aGVyZSBhIG1hbmRhdG9yeSB0byBpbXBs ZW1lbnQNCj4gPiA+IGZvcm1hdD8gRG9lcyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3Jt YXQgZGVwZW5kIG9uIHRoZQ0KPiA+ID4gcHJvdG9jb2wgdGhhdCBpcyBiZWluZyB1c2VkPw0KPiA+ ID4NCj4gPiA+IEkgcHJlZmVyIG9uZSBmb3JtYXQgb3IgaWYgbmVjZXNzYXJ5IEkgYW0gZmluZSB3 aXRoIG9uZSBtYW5kYXRvcnkgdG8NCj4gPiA+IGltcGxlbWVudCBmb3JtYXQuIEFuIG9wZW4gZW5k ZWQgY29sbGVjdGlvbiBvZiBpbXBsZW1lbnRhdGlvbg0KPiA+ID4gc3BlY2lmaWMgZm9ybWF0cyBp cyBzdXBlciBmbGV4aWJsZSBidXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBhDQo+ID4gPiBzdGFu ZGFyZCwgbmFtZWx5IGludGVyb3BlcmFiaWxpdHkuDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB0aGVy ZSBuZWVkcyB0byBiZSAxIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgZm9ybWF0Lg0KPiA+ID4NCj4g PiA+IElNTyB0aGlzIG5lZWRzIHRvIGJlIFlBTkcgUGF0Y2ggYmVjYXVzZSBpdCBpcyBtb3JlIHBy ZWNpc2UgdGhlbg0KPiA+ID4gY29uc3RydWN0aW5nIGFuIFhNTCB0cmVlIHdpdGggb3BlcmF0aW9u IGF0dHJpYnV0ZXMgaW4gaXQgKGUuZy4sIGhvdw0KPiA+ID4gZWxzZSBkbyB5b3UgcmVwcmVzZW50 IGEgZGVsZXRlIG9yIGEgbW92ZT8pIEFsc28sIFlBTkcgUHVzaCBpcyB1c2luZw0KPiA+ID4gWUFO RyBQYXRjaCBmb3JtYXQgYW5kIGNvbW1vbiBjb2RlIGZvciBwdXNoIGFuZCBkaWZmIHdvdWxkIGJl IHBvc3NpYmxlLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgb3RoZXIgZm9ybWF0cyBzaG91bGQgYmUg YWxsb3dlZC4NCj4gPiA+IFRoaXMgaXMgdmVyeSB0b29sLXNwZWNpZmljLiBJIGNvdWxkIHNlZSBo b3cgc29tZWJvZHkgbWlnaHQgd2FudCBhDQo+ID4gPiB0ZXh0dWFsIHBhdGNoIG9mIHRoZSBYTUwg cmVwcmVzZW50YXRpb24gdG8gcHJvZHVjZSB0aGUgbmV3IFhNTA0KPiA+IHJlcHJlc2VudGF0aW9u Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAvanMNCj4gPiA+DQo+ID4gPiBBbmR5DQo+ID4gPg0KPiA+ ID4NCj4gPiA+IE9uIFRodSwgT2N0IDA0LCAyMDE4IGF0IDA1OjQxOjIyUE0gKzAwMDAsIEtlbnQg V2F0c2VuIHdyb3RlOg0KPiA+ID4+IFdlIGFncmVlIHRoYXQgdGhlIGRpZmYtZm9ybWF0IHNob3Vs ZCBiZSBjbGllbnQtc2VsZWN0YWJsZSwgbW9kdWxvDQo+ID4gPj4gd2hhdCB0aGUNCj4gPiBzZXJ2 ZXIgc3VwcG9ydHMuICB5YW5nLXBhdGNoIGFuZCBlZGl0LWNvbmZpZyBib3RoIGFyZSB2aWFibGUu ICBTaG91bGQNCj4gPiB3ZSBkb2N1bWVudCB0aGVtIGJvdGg/DQo+ID4gPj4NCj4gPiA+PiBUaGF0 IHNhaWQsIHNpbmNlIG5laXRoZXIgZWRpdC1jb25maWcgbm9yIHlhbmctcGF0Y2ggYXJlIGRpZmZp bmcNCj4gPiA+PiBmb3JtYXRzLCBzbw0KPiA+IG11Y2ggYXMgZm9ybWF0cyBmb3IgY29udmVydGlu ZyBvbmUgZGF0YSB0cmVlIHRvIGFub3RoZXIsIHdvdWxkIGl0IG1ha2UNCj4gPiBzZW5zZSB0byBk ZWZpbmUgYW4gYWN0dWFsIGRpZmZpbmcgZm9ybWF0PyAgSSB3b3VsZCB0aGluayB0aGF0IGEgZGlm Zg0KPiA+IHdvdWxkIHByb3ZpZGUgYm90aCB2YWx1ZXMsIG5vdCBqdXN0IGEgbmV3IHZhbHVlLg0K PiA+ID4+DQo+ID4gPj4gS2VudCAvLyBjb250cmlidXRvcg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IG5ldG1vZA0KPiA+ID4+ IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYNCj4gPiA+PiBvZiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFp bHRvOmxob3RrYUBuaWMuY3o+Pg0KPiA+ID4+IE9yZ2FuaXphdGlvbjogQ1ouTklDDQo+ID4gPj4g RGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgNCwgMjAxOCBhdCAxOjExIFBNDQo+ID4gPj4gVG86IFJv YmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+ LA0KPiA+ID4+ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iDQo+ID4g Pj4gPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPiA+PiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4gPiA+PiBkcmFmdC1jbGVt bS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+ID4gPj4NCj4gPiA+PiBPbiBUaHUsIDIwMTgtMTAtMDQg YXQgMTQ6MTcgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4gPj4gPg0KPiA+ID4+ID4g T24gMDQvMTAvMjAxOCAxMzo1MSwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+ID4+ID4gPiBP biBUaHUsIDIwMTgtMTAtMDQgYXQgMTM6MzYgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ ID4gPj4gPiA+ID4gT24gMDQvMTAvMjAxOCAxMToxNCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN Cj4gPiA+PiA+ID4gPiA+IFBoaWwgU2hhZmVyIDxwaGlsQGp1bmlwZXIubmV0PG1haWx0bzpwaGls QGp1bmlwZXIubmV0Pj4gd3JvdGU6DQo+ID4gPj4gPiA+ID4gPiA+IEJhbD96cyBMZW5neWVsIHdy aXRlczoNCj4gPiA+PiA+ID4gPiA+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3RvDQo+ID4gPj4gPiA+ID4gPiA+ID4gb2wNCj4gPiA+PiA+ ID4gPiA+ID4gPiBzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRjbGVtbS0yRG5ldG1vZC0yRG5tZGEt MkRkaWZmLTJEDQo+ID4gPj4gPiA+ID4gPiA+ID4gMDANCj4gPiA+PiA+ID4gPiA+ID4gPiAmZD1E d0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJ JnINCj4gPiA+PiA+ID4gPiA+ID4gPg0KPiA+ID05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC WWFHVHZqSVNsYUpkY1pvJm09N3M2VmR6ekg5Tw0KPiA+ID4+ID4gPiA+ID4gPiA+DQo+ID4gbDNC T0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9Z1FXSnRqY18yRUYzUWdSdkFCZ1pLDQo+ ID4gPj4gPiA+ID4gPiA+ID4gc2pxenVJdzl5VXFfeGVlNmFGSk9jdyZlPQ0KPiA+ID4+ID4gPiA+ ID4gPiBbSSd2ZSBtb3ZlZCB0byBhICJkZWVwIGx1cmtlciIgcm9sZSBoZXJlLCBidXQgLi4uXQ0K PiA+ID4+ID4gPiA+ID4gPg0KPiA+ID4+ID4gPiA+ID4gPiBDYW4gd2UgZW5zdXJlIHRoaXMgbW9k ZWwgY29udGFpbnMgYSAiZm9ybWF0IiBsZWFmIGluIHRoZSBSUEMncw0KPiBpbnB1dA0KPiA+ID4+ ID4gPiA+ID4gPiBzbyB0aGF0IGZ1dHVyZSAoYW5kIHByb3ByaWV0YXJ5KSBmb3JtYXRzIGNhbiBi ZSBzdXBwb3J0ZWQ/ICAgVGhhdA0KPiA+ID4+ID4gPiA+ID4gPiBsZWFmIGNhbiBiZSBhbiBpZGVu dGl0eXJlZiB0aGF0IGRlZmF1bHRzIHRvIHlhbmctcGF0Y2guDQo+ID4gPj4gPiA+ID4gPiBJIHRo aW5rIHRoaXMgaXMgYSBnb29kIGlkZWEuICBJIHdvdWxkIHByZWZlciB0aGUNCj4gPiA+PiA+ID4g PiA+IGVkaXQtY29uZmlnIGZvcm1hdCBvdmVyIFlBTkcgcGF0Y2ggZm9yIGRlc2NyaWJpbmcgYSBk aWZmLg0KPiA+ID4+ID4gPiA+ID4gVGhlIGVkaXQtY29uZmlnIGZvcm1hdCBpcyBtb3JlIHN1aXRl ZCBmb3IgdGhpcyBwdXJwb3NlIGltby4NCj4gPiA+PiA+ID4gPiArMQ0KPiA+ID4+ID4gPiA+DQo+ ID4gPj4gPiA+ID4gSSB3b3VsZCBsaWtlIHNvbWV0aGluZyBjbG9zZXIgdG8gZWRpdC1jb25maWcg dG8gYmUgYXZhaWxhYmxlDQo+ID4gPj4gPiA+ID4gdmlhIFJFU1RDT05GIGFzIHdlbGwuDQo+ID4g Pj4gPiA+IFlBTkcgUGF0Y2ggaXMgSU1PIGJldHRlciBiZWNhdXNlIGl0IGNsZWFybHkgc2VwYXJh dGVzIHRoZQ0KPiA+ID4+ID4gPiB0YXJnZXQgZm9yIHRoZSBlZGl0cyBmcm9tIHRoZSBuZXcgY29u dGVudC4NCj4gPiA+PiA+ID4gSW4gZWRpdC1jb25maWcgdGhlc2UgdHdvIGFyZSBtaXhlZCB0b2dl dGhlci4NCj4gPiA+PiA+IFllcywgdGhhdCBpcyBwcmltYXJpbHkgd2h5IEkgcHJlZmVyIHRoZSBl ZGl0LWNvbmZpZy4gIEkgcGVyY2VpdmUNCj4gPiA+PiA+IHRoYXQgaXQgaXMgYSBkZW5zZXIgYW5k IG1vcmUgZWZmaWNpZW50IGZvcm1hdC4gIEkgdGhpbmsgdGhhdCBpdA0KPiA+ID4+ID4gaXMgYm90 aCBlYXNpZXIgdG8gY29uc3RydWN0ICh3aGVuIGRpZmZpbmcgdHdvIHRyZWVzKSBhbmQgYWxzbw0K PiA+ID4+ID4gbW9yZSBlZmZpY2llbnQgdG8gYXBwbHkgd2hlbiBnZW5lcmF0aW5nIGFuIHVwZGF0 ZWQgdHJlZS4NCj4gPiA+Pg0KPiA+ID4+IEV4Y2VwdCBmb3IgY2VydGFpbiBjb3JuZXIgY2FzZXMs IGZvciBleGFtcGxlIGlmIHR3byB0cmVlcyBkaWZmZXINCj4gPiA+PiBvbmx5IGluIHRoZSB2YWx1 ZSBvZiBhIHNpbmdsZSBsZWFmIGJ1dCB0aGlzIGxlYWYgaGFwcGVucyB0byBiZSBhIGxpc3Qga2V5 Lg0KPiA+ID4+DQo+ID4gPj4gTGFkYQ0KPiA+ID4+DQo+ID4gPj4gPg0KPiA+ID4+ID4gVGhhbmtz LA0KPiA+ID4+ID4gUm9iDQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+ID4gVGhhdCBiZWlu ZyBzYWlkLCBJIHN1cHBvcnQgc3BlY2lmeWluZyBmb3JtYXQvbWVkaWEtdHlwZSBhbmQNCj4gPiA+ PiA+ID4gaGF2aW5nIHBvdGVudGlhbGx5IG11bHRpcGxlIG9wdGlvbnMuDQo+ID4gPj4gPiA+DQo+ ID4gPj4gPiA+IExhZGENCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gPiBUaGFua3MsDQo+ID4gPj4g PiA+ID4gUm9iDQo+ID4gPj4gPiA+ID4NCj4gPiA+PiA+ID4gPg0KPiA+ID4+ID4gPiA+ID4gL21h cnRpbg0KPiA+ID4+ID4gPiA+ID4NCj4gPiA+PiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gPiA+ID4gPiBuZXRtb2QgbWFpbGlu ZyBsaXN0DQo+ID4gPj4gPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NCj4gPiA+PiA+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmllDQo+ID4gPj4gPiA+ID4gPiB0Zg0KPiA+ID4+ID4gPiA+ ID4NCj4gPiAub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNy c3VocjZTY2JmaDBVDQo+ID4gPj4gPiA+ID4gPiBqQlhlTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJ JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTDQo+ID4gPj4gPiA+ID4gPg0K PiA+IGxhSmRjWm8mbT03czZWZHp6SDlPbDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdj JnM9UlZKY2cNCj4gPiA+PiA+ID4gPiA+IDVwekhXLXppMU9ib0NMNFNYMmh1VzlldUhpVlJTQ29y OW5fQVBRJmU9DQo+ID4gPj4gPiA+ID4gPiAuDQo+ID4gPj4gPiA+ID4gPg0KPiA+ID4+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4g PiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZzxt YWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+ID4+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYNCj4gPiA+PiA+ID4gPiAu bw0KPiA+ID4+ID4gPiA+DQo+ID4gcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcm Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlDQo+ID4gPj4gPiA+ID4gTUstDQo+ID4gbmRiM3Zv RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNaDQo+ ID4gPj4gPiA+ID4NCj4gPiBvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0ky S0RFTjk3YyZzPVJWSmNnNXB6SFctemkNCj4gPiA+PiA+ID4gPiAxT2JvQ0w0U1gyaHVXOWV1SGlW UlNDb3I5bl9BUFEmZT0NCj4gPiA+PiAtLQ0KPiA+ID4+IExhZGlzbGF2IExob3RrYQ0KPiA+ID4+ IEhlYWQsIENaLk5JQyBMYWJzDQo+ID4gPj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3 DQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+PiBuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+PiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tDQo+ID4gPj4gYWkN Cj4gPiA+PiBsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2Ni ZmgwVWpCWGVNSy0NCj4gPiBuZGIzdm9EVFgNCj4gPiA+Pg0KPiA+DQo+IGNXem9DSSZyPTl6a1Aw eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03czZWZHp6SDlPbDMNCj4g PiBCTw0KPiA+ID4+IENiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9UlZKY2c1cHpIVy0N Cj4gPiB6aTFPYm9DTDRTWDJodVc5ZXVIaVZSU0Nvcg0KPiA+ID4+IDluX0FQUSZlPQ0KPiA+ID4+ DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPj4gbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbQ0KPiA+ID4+IGFpbG1hbl9saXN0 aW5mb19uZXRtb2QmZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5k YjN2DQo+ID4gPj4NCj4gb0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ YUdUdmpJU2xhSmRjWm8mbT1ETTFqc3cNCj4gbk0NCj4gPiA+PiA0OEd3ZEk0dGV6LUp0ZjJ1YTJq dnRMWlZLZml3a2J3YklyVSZzPWcweF9CLQ0KPiBYZXo3dEQ5aExYNzFENXZsY0hkWm9obg0KPiA+ ID4+IFRraU1WSUtKaEFIaXZrJmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0NCj4gPiA+PiAzQV9fdXJsZGVmZW5zZS5wcm9vZiZkPUR3SUZBZyZjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRA0KPiA+ID4+DQo+IFRYY1d6b0NJ JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpzd25N DQo+IDQ4DQo+ID4gPj4gR3dkSTR0ZXotDQo+IEp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZzPWJ6 TGFMb0JDSjg4bGF2ZXVwTHFhcFlONGJ0akVCQnYNCj4gPiA+PiBORU5OeTA5VHNvb2MmZT0NCj4g PiA+PiBwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ID4gM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX25ldG1vZCZkPUQNCj4gPiA+PiB3TUZhUSZjPUhBa1l1aDYzcnN1aHI2U2Ni ZmgwVWpCWGVNSy0NCj4gPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUUNCj4gPiA+ PiBQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09TzdkLQ0KPiA+IGI5Z3lQdnNhc0pvMXVl S2szZG9ESDdmNVM1V1FMbzhfVzYNCj4gPiA+PiBXM3F0NCZzPTVMSGhiZlFaZW9xWWxDNDBUM21t LUFFejRyU3N5UldZanFUSzdMdVdUUHcmZT0+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IEp1ZXJn ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI DQo+ID4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAy ODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+ID4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMw0KPiA8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu amFjb2JzLQ0KPiAyRCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4g bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK ZGNabyZtPUQNCj4gTTFqc3duTTQ4R3dkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9 NVJEOTYtDQo+IFRqeW1VMVpobWZaRnRXRW00YWJra2RheHFya0NLenV2NFBaUlEmZT0NCj4gPiB1 bml2ZXJzaXR5LmRlLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtDQo+ID4gM0FfX3d3dy5qYWNvYnMtDQo+ID4gMkR1bml2ZXJzaXR5LmRlXyZkPUR3TUZh USZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gPg0KPiBuZGIzdm9EVFhjV3pvQ0km cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Tw0KPiA+IDdk LQ0KPiA+DQo+IGI5Z3lQdnNhc0pvMXVlS2szZG9ESDdmNVM1V1FMbzhfVzZXM3F0NCZzPXpoN3FF UFNtd3ZpYVNxWkJxRzFHYw0KPiA+IHFJdFh3STlwd3lxSUZWVzZ4QzhySzgmZT0+Pg0KPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbG1hbl9saXN0aW5mb19u ZXRtb2QmZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0QN Cj4gPiA+DQo+IFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklT bGFKZGNabyZtPURNMWpzd25NDQo+IDQ4Rw0KPiA+ID4gd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zp d2tid2JJclUmcz1nMHhfQi0NCj4gWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNDQo+ID4gPiBW SUtKaEFIaXZrJmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fdQ0KPiA+ID4gcmxkZWZlbnNlLnByb29mcCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6DQo+ID4gPg0KPiBvQ0kmcj05emtQMHhu SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk00OEd3ZA0KPiBJ NHQNCj4gPiA+IGV6LUp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZzPWlkNWtkWERFYjRhZm5vYldU LQ0KPiBmVXEzWWZzSWtIb296NVJ0WFlzbw0KPiA+ID4gUVJ0MW8mZT0NCj4gPiA+IG9pbnQuY29t L3YyL3VybD91PWh0dHBzLQ0KPiA+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmZD1Ed00NCj4gPiA+IEZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4g PiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb08NCj4gPiA+IEg3WWhxbjJnc0JZ YUdUdmpJU2xhSmRjWm8mbT1PN2QtDQo+ID4gYjlneVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxv OF9XNlczcXQNCj4gPiA+IDQmcz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJXWWpxVEs3 THVXVFB3JmU9Pg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbG1hbl9saXN0aW5mb19uZXRtb2Qm ZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0QNCj4gPiA+ DQo+IFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa byZtPURNMWpzd25NDQo+IDQ4Rw0KPiA+ID4gd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJ clUmcz1nMHhfQi0NCj4gWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNDQo+ID4gPiBWSUtKaEFI aXZrJmU9DQo+ID4NCj4gPiAtLQ0KPiA+IExhZGlzbGF2IExob3RrYQ0KPiA+IEhlYWQsIENaLk5J QyBMYWJzDQo+ID4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+ID4NCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+ID4g bWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN Sy0NCj4gbmRiM3ZvRFRYY1cNCj4gPg0KPiB6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFu MmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpzd25NNDhHdw0KPiBkSTR0ZQ0KPiA+IHotSnRmMnVh Mmp2dExaVktmaXdrYndiSXJVJnM9ZzB4X0ItDQo+IFhlejd0RDloTFg3MUQ1dmxjSGRab2huVGtp TVZJS0poQUhpDQo+ID4gdmsmZT0NCg0K From nobody Wed Oct 10 18:39:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372C1130DF2 for ; Wed, 10 Oct 2018 18:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onzdQMzhDFt2 for ; Wed, 10 Oct 2018 18:39:45 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AAD130DF6 for ; Wed, 10 Oct 2018 18:39:45 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9B1dALZ008559; Wed, 10 Oct 2018 18:39:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=tNtUO89q5jUmmvMriin89BiKEVnKAI7QB/vUCfW+XN8=; b=jP/Eg6wk9xbhOoXbnW95KeKBKBGOKacgDMMmU2Weczs5aIW9NgQvHKlyJ6kuOxlrncrr UmW5RdhdW0wMP+VcKSfg8vshUZ1cy8frre0X5HaJOP15Oh4FM3yMCSRqc094WAicEqpX sNHW5sd2bapKs/9VLLBh/BxSvKt1I/dpJGuNitez3t5KmSuTHVJSNK1kTHmhj8ljYXNO 4wH809FZvW9t6XEgFREUUVwACgyoj9kaaraTKVR3Q87IdgqvUv72ff6LZgILN8rsLTqG 846BYJNRS/9m+IS0boZBvoYMG1/81sJZh7InEr9SMk2ob4R48ty2nkyKEPYm2ysWlkyA uw== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0184.outbound.protection.outlook.com [216.32.180.184]) by mx0b-00273201.pphosted.com with ESMTP id 2n1rs90ehw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Oct 2018 18:39:40 -0700 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4603.namprd05.prod.outlook.com (20.176.109.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Thu, 11 Oct 2018 01:39:39 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 01:39:39 +0000 From: Kent Watsen To: Alexander Clemm , Ladislav Lhotka , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 Thread-Index: AQHUWyPz6FAZXxCAuEeMxCal0HeWUaUO37yAgAAnp4CAAARbAIAABz8AgABBFoD//8WNgIAAWzMAgAAFdID//8jaAIABBsKAgAWVBYCAAQ+mgIACJjWA///4hoA= Date: Thu, 11 Oct 2018 01:39:39 +0000 Message-ID: <8E17601A-EE48-4750-B11F-63BC6068C530@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.2.180910 x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4603; 6:ropRmk7DsTW4oJSliLRKhpzOU1wjQGPCJ5tO3QKEDn5RyLpwJha2j0/UVqKusDAb8An541AxXgnSj9glVBpZS1U6bLwfSZMOavdMqv+Sbw/GoNp7Jl3GbWEDceHlVku29oobqx2uHn1ScP37V0FaI85I/kyvE5JmfoajjlSnFCFeYyFRVh5zbmOi1AY+hKj7PBPMXcHd7UgEA0rtwil+0CZ+ExKjKAWgDSRkjp7ruFO4/zjoFOAwZfPIIfz5sOyvJnvwO2dRxeoo0KY9OI4+PktbCC++x3kGlyhCVI9uOLpug0dBk74OHK3Qul9sNNOR/P2fyr9I6HKA+CUwodtZGV+fesh8tdZ2jVpKtQWd92n4O1iCy6CUAp8KOAKwdMf59HMf/CwQQFyjhsXPzi34V3JeeM7BQ+wV0ZuAIqA6gGxJLVB603f9Y0CrzL6hm2kAcbj+wzuLm+g8axo0rprzCA==; 5:7T9fuEvvg04k4vZD2ZUlXDsg76kqbcbiz04epa0tI8fwdARfvTrK7egpoSN/LasorphZacb1cRxFRbEqXfxFDCQTE0tg9ak7D4IlXLhg1yMluEfKjFeYhY/9pQMyQrkd44Gvav5sGnFPkT5jv8X1i6cJTF2FdLsac5W1CtIkRWY=; 7:qOASjjC7o2tjGR5BpmfauincFvfjLQIY9LMaD4SCwjdFeDVXtFdd5cM/XRch8x/J1hTI/LvEIvhyI+MYZzAtC3yfCkuczVHW9cAiE1evYXeKIm9fN8dAGRjF5dDpK1Z/zYFeLJdKjTO0VbMGWeAGEgB0LlUnqOhhtWrkHivnMV/0etMK6l2FdXlvRdA6ViF0P0OyfNReA+fJEZiOKyVfdSv4H5D75ErImZX3aZZufmx8RfhA/snJevtIAyJRaCko x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ce61afc9-c46f-4174-206d-08d62f1a68cd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4603; x-ms-traffictypediagnostic: DM6PR05MB4603: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(158342451672863)(10436049006162)(50582790962513)(95692535739014); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:DM6PR05MB4603; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4603; x-forefront-prvs: 08220FA8D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(51444003)(13464003)(189003)(199004)(486006)(5250100002)(81166006)(97736004)(305945005)(6246003)(93886005)(33656002)(7736002)(316002)(25786009)(105586002)(14454004)(36756003)(106356001)(2900100001)(66066001)(114624004)(2501003)(966005)(6436002)(229853002)(53546011)(6306002)(6486002)(6506007)(53936002)(478600001)(102836004)(6512007)(6116002)(3846002)(110136005)(99286004)(186003)(11346002)(68736007)(82746002)(446003)(2616005)(71190400001)(26005)(2906002)(8936002)(14444005)(4744004)(5660300001)(19627235002)(86362001)(256004)(58126008)(76176011)(476003)(8676002)(71200400001)(83716004)(575784001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4603; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: lKoh+WBNN6wo3tvd/N0dUF/Dkxby8d+VgAxbQe6V4nwZ6mYT+n7Kj4muP8v+dpY4vX4DCWodgOu+DViKx8z62xD3rp5/fpw6L5j8lZL0+VHWImjP7Zz2tQlpeTcGhcoc/P/GdCm36Bo3/Ii34FSi6UTkipMuFGobN7821kXIvV+NZAGBdu2sIdNtD/IM6dORF0L5DA1fUVOZXyE+d4mMjSYqh7TEXFZyDOWNaPUTU/Z2YZe1Gh3gC48d6hsXwX5DHPttREjakXgAtxNWexWY7cez3nyB5lP73PdweXYbwG4LE5LzJJxI4LpVY7wmpnO4E8k+X4kLv533Qi+q/34o8Z1pkntm+hEStvfVUwoFyss= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ce61afc9-c46f-4174-206d-08d62f1a68cd X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 01:39:39.2692 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4603 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-10_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810110015 Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 01:39:50 -0000 SGkgQWxleCwgbm8gb2JqZWN0aW9uLg0KDQpNeSBzdXBwb3J0IHdpdGhkcmF3IGFwcGVhcnMgdG8g cHV0IG1lIGluIHRoZSByb3VnaCwgd2hpY2ggaXMgZmluZSBmcm9tIGEgcHJvY2VzcyBwZXJzcGVj dGl2ZS4gIEJ1dCBtYWtlIG5vIG1pc3Rha2UsIEkgdGhpbmsgdGhhdCBpdCdzIGJpemFhciBmb3Ig YSAiZGlmZiIgdG8gbm90IHNob3cgYm90aCB2YWx1ZXMuICBBbmR5J3MgaWRlYSB0byBhdWdtZW50 IGluIGFuICdvbGQtdmFsdWUnIG5vZGUgc2VlbXMgbGlrZSBhIHN0ZXAgaW4gdGhlIHJpZ2h0IGRp cmVjdGlvbi4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWku Y29tPg0KRGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IGF0IDY6MDYgUE0NClRvOiBL ZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sIExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiwgSnVlcmdlbiBTY2hv ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCAibmV0bW9k QGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtuZXRtb2RdIFdHIGFk b3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDANCg0KV2hpY2gg Zm9ybWF0IHRvIG1ha2UgbWFuZGF0b3J5IHNvdW5kcyBsaWtlIHNvbWV0aGluZyB3ZSBjYW4gZGlz Y3VzcyBpbiBCYW5na29rLiAgVGhlIHJlYXNvbiBZQU5HLXBhdGNoIHdhcyBjaG9zZW4gaXMgcmV1 c2UsIGFsdGhvdWdoIGl0IGlzIGNlcnRhaW5seSBjb25jZWl2YWJsZSB0byBkZXZlbG9wIGFub3Ro ZXIgZm9ybWF0LiAgKFBlciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHdlIHdpbGwgcHV0IHRoZSBo b29rcyBpbiBwbGFjZSB0byBhbGxvdyBmb3Igb3RoZXIgb3B0aW9ucy4pICBFaXRoZXIgd2F5LCB0 aGlzIHNlZW1zIHRvIGJlIG9uZSBvZiB0aGUgdGVjaG5pY2FsIGRldGFpbHMgdGhhdCBuZWVkIHRv IGJlIGRlY2lkZWQsIG5vdCBzb21ldGhpbmcgdGhhdCB3b3VsZCBtYWtlIG9yIGJyZWFrIHN1cHBv cnQgYXMgYSB3aG9sZT8gIA0KLS0tIEFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQo+IFNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDksIDIwMTggMTA6MTcgQU0NCj4gVG86IEFsZXhhbmRlciBD bGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBMYWRpc2xhdiBMaG90a2ENCj4gPGxo b3RrYUBuaWMuY3o+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IEp1ZXJnZW4N Cj4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsg bmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBhZG9wdGlvbiBwb2xs IGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+IA0KPiBJIGFncmVlIHRoYXQg YSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCBpcyBkZXNpcmFibGUuDQo+IA0KPiBJIGRp c2FncmVlIHRoYXQgWUFORy1QYXRjaCBpcyB0aGUgcmlnaHQgZm9ybWF0LCBmb3IgcmVhc29ucyBz dGF0ZWQgYmVmb3JlLiAgSSBmZWVsDQo+IHRoYXQgYSBjb21wcm9taXNlIG9mIHRoaXMgc29ydCBm b3IgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlzIHdyb25nLg0KPiANCj4gSWYgdGhpcyBpcyB3 aGF0IHRoZSBXRyB3YW50cywgSSB3aXRoZHJhdyBteSBzdXBwb3J0Lg0KPiANCj4gS2VudCAvLyBj b250cmlidXRvcg0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPg0KPiBEYXRl OiBNb25kYXksIE9jdG9iZXIgOCwgMjAxOCBhdCA1OjA1IFBNDQo+IFRvOiBMYWRpc2xhdiBMaG90 a2EgPGxob3RrYUBuaWMuY3o+LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sDQo+ IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiwgSnVlcmdlbiBTY2hvZW53YWVsZGVy DQo+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCAibmV0bW9kQGlldGYu b3JnIg0KPiA8bmV0bW9kQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW25ldG1vZF0gV0cgYWRv cHRpb24gcG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMA0KPiANCj4gSSB3 b3VsZCBzZWNvbmQgdGhlIHJlcXVlc3QgZm9yIG9uZSBmb3JtYXQgKHdoaWNoIGlzIG1hbmRhdG9y eSB0byBzdXBwb3J0KSwNCj4gd2hpY2ggbXVzdCBiZSBzcGVjaWZpZWQuICBZQU5HLVBhdGNoIGlz IHRoZSBsb2dpY2FsIGNhbmRpZGF0ZSBJTUhPLg0KPiANCj4gVG8gYWxsb3cgc2VsZWN0aW9uIG9m IG90aGVyIGZvcm1hdHMgdXNpbmcgYW4gaW5wdXQgcGFyYW1ldGVyIG1ha2VzIHNlbnNlLCBidXQN Cj4gYWRkcyBzb21lIGNvbXBsZXhpdHkgZnJvbSB0aGVyZTogIEhvdyB0byBrbm93IHdoaWNoIGZv cm1hdHMgYXJlIHN1cHBvcnRlZD8NCj4gKEFkZCBhIGxpc3Qgb2Ygc3VwcG9ydGVkIGZvcm1hdHMg c29tZXdoZXJlPykgICBPciBzaW1wbHkgcmVseSBvbiBhdWdtZW50YXRpb24NCj4gZm9yIHRob3Nl IGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgaXQ/DQo+IA0KPiAtLS0gQWxleA0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFkaXNsYXYNCj4gPiBMaG90a2ENCj4g PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDUsIDIwMTggMTI6NTAgQU0NCj4gPiBUbzogS2VudCBX YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+OyBBbmR5IEJpZXJtYW4NCj4gPiA8YW5keUB5dW1h d29ya3MuY29tPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LQ0KPiA+IHVuaXZlcnNpdHkuZGU+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTog W25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4gPiBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1k YS1kaWZmLTAwDQo+ID4NCj4gPiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jp dGVzOg0KPiA+DQo+ID4gPiBTdXJlLCBvbmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3JtYXQs IG90aGVycyBuaWNlIHRvIGhhdmUuDQo+ID4gPiBJbnRlcm9wZXJhYmlsaXR5IGdvb2QuICBBZ3Jl ZWQuDQo+ID4gPg0KPiA+ID4gQnV0IHdoeSBZQU5HLXBhdGNoIGFuZCBub3Qgc29tZXRoaW5nIGJ1 aWx0IGZvciB0aGUgcHVycG9zZSAoZS5nLiwNCj4gPiA+IFlBTkctZGlmZikgdGhhdCwgaW4gcGFy dGljdWxhciwgcHJvdmlkZXMgYW4gYWN0dWFsIGRpZmYgYXMgb3Bwb3NlZA0KPiA+ID4gdG8gYSBk YXRhLXRyZWUgb3BlcmF0aW9uIHRoYXQgb25seSBzaG93cyBvbmUgb2YgdGhlIHR3byB2YWx1ZXM/ DQo+ID4NCj4gPiBTdWNoIGEgZm9ybWF0IGNhbiBiZSBkZXZlbG9wZWQgaW5kZXBlbmRlbnRseSwg SSB3b3VsZCBzdXBwb3J0IGl0Lg0KPiA+DQo+ID4gTGFkYQ0KPiA+DQo+ID4gPg0KPiA+ID4gS2Vu dCAvLyBjb250cmlidXRvcg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAxMC80LzE4LCAzOjI3IFBN LCAiQW5keSBCaWVybWFuIg0KPiA+IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVt YXdvcmtzLmNvbT4+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IE9uIFRodSwgT2N0IDQsIDIwMTggYXQg MTI6MDcgUE0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiA+IDxqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtDQo+ID4gdW5p dmVyc2l0eS5kZT4+IHdyb3RlOg0KPiA+ID4gRm9sa3MsIHRoZSBtb3JlIGZvcm1hdHMgdGhlcmUg YXJlLCB0aGUgbGVzcyBpbnRlcm9wZXJhYmlsaXR5IHdlIGdldC4NCj4gPiA+IElmIHRoZXJlIGFy ZSBtdWx0aXBsZSBmb3JtYXRzLCBpcyB0aGVyZSBhIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQNCj4g PiA+IGZvcm1hdD8gRG9lcyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBmb3JtYXQgZGVwZW5k IG9uIHRoZQ0KPiA+ID4gcHJvdG9jb2wgdGhhdCBpcyBiZWluZyB1c2VkPw0KPiA+ID4NCj4gPiA+ IEkgcHJlZmVyIG9uZSBmb3JtYXQgb3IgaWYgbmVjZXNzYXJ5IEkgYW0gZmluZSB3aXRoIG9uZSBt YW5kYXRvcnkgdG8NCj4gPiA+IGltcGxlbWVudCBmb3JtYXQuIEFuIG9wZW4gZW5kZWQgY29sbGVj dGlvbiBvZiBpbXBsZW1lbnRhdGlvbg0KPiA+ID4gc3BlY2lmaWMgZm9ybWF0cyBpcyBzdXBlciBm bGV4aWJsZSBidXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBhDQo+ID4gPiBzdGFuZGFyZCwgbmFt ZWx5IGludGVyb3BlcmFiaWxpdHkuDQo+ID4gPg0KPiA+ID4gSSBhZ3JlZSB0aGVyZSBuZWVkcyB0 byBiZSAxIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgZm9ybWF0Lg0KPiA+ID4NCj4gPiA+IElNTyB0 aGlzIG5lZWRzIHRvIGJlIFlBTkcgUGF0Y2ggYmVjYXVzZSBpdCBpcyBtb3JlIHByZWNpc2UgdGhl bg0KPiA+ID4gY29uc3RydWN0aW5nIGFuIFhNTCB0cmVlIHdpdGggb3BlcmF0aW9uIGF0dHJpYnV0 ZXMgaW4gaXQgKGUuZy4sIGhvdw0KPiA+ID4gZWxzZSBkbyB5b3UgcmVwcmVzZW50IGEgZGVsZXRl IG9yIGEgbW92ZT8pIEFsc28sIFlBTkcgUHVzaCBpcyB1c2luZw0KPiA+ID4gWUFORyBQYXRjaCBm b3JtYXQgYW5kIGNvbW1vbiBjb2RlIGZvciBwdXNoIGFuZCBkaWZmIHdvdWxkIGJlIHBvc3NpYmxl Lg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgb3RoZXIgZm9ybWF0cyBzaG91bGQgYmUgYWxsb3dlZC4N Cj4gPiA+IFRoaXMgaXMgdmVyeSB0b29sLXNwZWNpZmljLiBJIGNvdWxkIHNlZSBob3cgc29tZWJv ZHkgbWlnaHQgd2FudCBhDQo+ID4gPiB0ZXh0dWFsIHBhdGNoIG9mIHRoZSBYTUwgcmVwcmVzZW50 YXRpb24gdG8gcHJvZHVjZSB0aGUgbmV3IFhNTA0KPiA+IHJlcHJlc2VudGF0aW9uLg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiAvanMNCj4gPiA+DQo+ID4gPiBBbmR5DQo+ID4gPg0KPiA+ID4NCj4gPiA+ IE9uIFRodSwgT2N0IDA0LCAyMDE4IGF0IDA1OjQxOjIyUE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdy b3RlOg0KPiA+ID4+IFdlIGFncmVlIHRoYXQgdGhlIGRpZmYtZm9ybWF0IHNob3VsZCBiZSBjbGll bnQtc2VsZWN0YWJsZSwgbW9kdWxvDQo+ID4gPj4gd2hhdCB0aGUNCj4gPiBzZXJ2ZXIgc3VwcG9y dHMuICB5YW5nLXBhdGNoIGFuZCBlZGl0LWNvbmZpZyBib3RoIGFyZSB2aWFibGUuICBTaG91bGQN Cj4gPiB3ZSBkb2N1bWVudCB0aGVtIGJvdGg/DQo+ID4gPj4NCj4gPiA+PiBUaGF0IHNhaWQsIHNp bmNlIG5laXRoZXIgZWRpdC1jb25maWcgbm9yIHlhbmctcGF0Y2ggYXJlIGRpZmZpbmcNCj4gPiA+ PiBmb3JtYXRzLCBzbw0KPiA+IG11Y2ggYXMgZm9ybWF0cyBmb3IgY29udmVydGluZyBvbmUgZGF0 YSB0cmVlIHRvIGFub3RoZXIsIHdvdWxkIGl0IG1ha2UNCj4gPiBzZW5zZSB0byBkZWZpbmUgYW4g YWN0dWFsIGRpZmZpbmcgZm9ybWF0PyAgSSB3b3VsZCB0aGluayB0aGF0IGEgZGlmZg0KPiA+IHdv dWxkIHByb3ZpZGUgYm90aCB2YWx1ZXMsIG5vdCBqdXN0IGEgbmV3IHZhbHVlLg0KPiA+ID4+DQo+ ID4gPj4gS2VudCAvLyBjb250cmlidXRvcg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IG5ldG1vZA0KPiA+ID4+IDxuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYNCj4gPiA+PiBvZiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3Rr YUBuaWMuY3o+Pg0KPiA+ID4+IE9yZ2FuaXphdGlvbjogQ1ouTklDDQo+ID4gPj4gRGF0ZTogVGh1 cnNkYXksIE9jdG9iZXIgNCwgMjAxOCBhdCAxOjExIFBNDQo+ID4gPj4gVG86IFJvYmVydCBXaWx0 b24gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+LA0KPiA+ID4+ ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iDQo+ID4gPj4gPG5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPiA+PiBTdWJqZWN0OiBSZTog W25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4gPiA+PiBkcmFmdC1jbGVtbS1uZXRtb2Qt bm1kYS1kaWZmLTAwDQo+ID4gPj4NCj4gPiA+PiBPbiBUaHUsIDIwMTgtMTAtMDQgYXQgMTQ6MTcg KzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4gPj4gPg0KPiA+ID4+ID4gT24gMDQvMTAv MjAxOCAxMzo1MSwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+ID4+ID4gPiBPbiBUaHUsIDIw MTgtMTAtMDQgYXQgMTM6MzYgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4gPj4gPiA+ ID4gT24gMDQvMTAvMjAxOCAxMToxNCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiA+PiA+ ID4gPiA+IFBoaWwgU2hhZmVyIDxwaGlsQGp1bmlwZXIubmV0PG1haWx0bzpwaGlsQGp1bmlwZXIu bmV0Pj4gd3JvdGU6DQo+ID4gPj4gPiA+ID4gPiA+IEJhbD96cyBMZW5neWVsIHdyaXRlczoNCj4g PiA+PiA+ID4gPiA+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3RvDQo+ID4gPj4gPiA+ID4gPiA+ID4gb2wNCj4gPiA+PiA+ID4gPiA+ID4g PiBzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRjbGVtbS0yRG5ldG1vZC0yRG5tZGEtMkRkaWZmLTJE DQo+ID4gPj4gPiA+ID4gPiA+ID4gMDANCj4gPiA+PiA+ID4gPiA+ID4gPiAmZD1Ed0lDQWcmYz1I QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJJnINCj4gPiA+ PiA+ID4gPiA+ID4gPg0KPiA+ID05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNs YUpkY1pvJm09N3M2VmR6ekg5Tw0KPiA+ID4+ID4gPiA+ID4gPiA+DQo+ID4gbDNCT0NiVkxCYXJC clE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9Z1FXSnRqY18yRUYzUWdSdkFCZ1pLDQo+ID4gPj4gPiA+ ID4gPiA+ID4gc2pxenVJdzl5VXFfeGVlNmFGSk9jdyZlPQ0KPiA+ID4+ID4gPiA+ID4gPiBbSSd2 ZSBtb3ZlZCB0byBhICJkZWVwIGx1cmtlciIgcm9sZSBoZXJlLCBidXQgLi4uXQ0KPiA+ID4+ID4g PiA+ID4gPg0KPiA+ID4+ID4gPiA+ID4gPiBDYW4gd2UgZW5zdXJlIHRoaXMgbW9kZWwgY29udGFp bnMgYSAiZm9ybWF0IiBsZWFmIGluIHRoZSBSUEMncw0KPiBpbnB1dA0KPiA+ID4+ID4gPiA+ID4g PiBzbyB0aGF0IGZ1dHVyZSAoYW5kIHByb3ByaWV0YXJ5KSBmb3JtYXRzIGNhbiBiZSBzdXBwb3J0 ZWQ/ICAgVGhhdA0KPiA+ID4+ID4gPiA+ID4gPiBsZWFmIGNhbiBiZSBhbiBpZGVudGl0eXJlZiB0 aGF0IGRlZmF1bHRzIHRvIHlhbmctcGF0Y2guDQo+ID4gPj4gPiA+ID4gPiBJIHRoaW5rIHRoaXMg aXMgYSBnb29kIGlkZWEuICBJIHdvdWxkIHByZWZlciB0aGUNCj4gPiA+PiA+ID4gPiA+IGVkaXQt Y29uZmlnIGZvcm1hdCBvdmVyIFlBTkcgcGF0Y2ggZm9yIGRlc2NyaWJpbmcgYSBkaWZmLg0KPiA+ ID4+ID4gPiA+ID4gVGhlIGVkaXQtY29uZmlnIGZvcm1hdCBpcyBtb3JlIHN1aXRlZCBmb3IgdGhp cyBwdXJwb3NlIGltby4NCj4gPiA+PiA+ID4gPiArMQ0KPiA+ID4+ID4gPiA+DQo+ID4gPj4gPiA+ ID4gSSB3b3VsZCBsaWtlIHNvbWV0aGluZyBjbG9zZXIgdG8gZWRpdC1jb25maWcgdG8gYmUgYXZh aWxhYmxlDQo+ID4gPj4gPiA+ID4gdmlhIFJFU1RDT05GIGFzIHdlbGwuDQo+ID4gPj4gPiA+IFlB TkcgUGF0Y2ggaXMgSU1PIGJldHRlciBiZWNhdXNlIGl0IGNsZWFybHkgc2VwYXJhdGVzIHRoZQ0K PiA+ID4+ID4gPiB0YXJnZXQgZm9yIHRoZSBlZGl0cyBmcm9tIHRoZSBuZXcgY29udGVudC4NCj4g PiA+PiA+ID4gSW4gZWRpdC1jb25maWcgdGhlc2UgdHdvIGFyZSBtaXhlZCB0b2dldGhlci4NCj4g PiA+PiA+IFllcywgdGhhdCBpcyBwcmltYXJpbHkgd2h5IEkgcHJlZmVyIHRoZSBlZGl0LWNvbmZp Zy4gIEkgcGVyY2VpdmUNCj4gPiA+PiA+IHRoYXQgaXQgaXMgYSBkZW5zZXIgYW5kIG1vcmUgZWZm aWNpZW50IGZvcm1hdC4gIEkgdGhpbmsgdGhhdCBpdA0KPiA+ID4+ID4gaXMgYm90aCBlYXNpZXIg dG8gY29uc3RydWN0ICh3aGVuIGRpZmZpbmcgdHdvIHRyZWVzKSBhbmQgYWxzbw0KPiA+ID4+ID4g bW9yZSBlZmZpY2llbnQgdG8gYXBwbHkgd2hlbiBnZW5lcmF0aW5nIGFuIHVwZGF0ZWQgdHJlZS4N Cj4gPiA+Pg0KPiA+ID4+IEV4Y2VwdCBmb3IgY2VydGFpbiBjb3JuZXIgY2FzZXMsIGZvciBleGFt cGxlIGlmIHR3byB0cmVlcyBkaWZmZXINCj4gPiA+PiBvbmx5IGluIHRoZSB2YWx1ZSBvZiBhIHNp bmdsZSBsZWFmIGJ1dCB0aGlzIGxlYWYgaGFwcGVucyB0byBiZSBhIGxpc3Qga2V5Lg0KPiA+ID4+ DQo+ID4gPj4gTGFkYQ0KPiA+ID4+DQo+ID4gPj4gPg0KPiA+ID4+ID4gVGhhbmtzLA0KPiA+ID4+ ID4gUm9iDQo+ID4gPj4gPg0KPiA+ID4+ID4NCj4gPiA+PiA+ID4gVGhhdCBiZWluZyBzYWlkLCBJ IHN1cHBvcnQgc3BlY2lmeWluZyBmb3JtYXQvbWVkaWEtdHlwZSBhbmQNCj4gPiA+PiA+ID4gaGF2 aW5nIHBvdGVudGlhbGx5IG11bHRpcGxlIG9wdGlvbnMuDQo+ID4gPj4gPiA+DQo+ID4gPj4gPiA+ IExhZGENCj4gPiA+PiA+ID4NCj4gPiA+PiA+ID4gPiBUaGFua3MsDQo+ID4gPj4gPiA+ID4gUm9i DQo+ID4gPj4gPiA+ID4NCj4gPiA+PiA+ID4gPg0KPiA+ID4+ID4gPiA+ID4gL21hcnRpbg0KPiA+ ID4+ID4gPiA+ID4NCj4gPiA+PiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPj4gPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ ID4gPj4gPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4g PiA+PiA+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmllDQo+ID4gPj4gPiA+ID4gPiB0Zg0KPiA+ID4+ID4gPiA+ID4NCj4gPiAu b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2Jm aDBVDQo+ID4gPj4gPiA+ID4gPiBqQlhlTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4 bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTDQo+ID4gPj4gPiA+ID4gPg0KPiA+IGxhSmRj Wm8mbT03czZWZHp6SDlPbDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9UlZKY2cN Cj4gPiA+PiA+ID4gPiA+IDVwekhXLXppMU9ib0NMNFNYMmh1VzlldUhpVlJTQ29yOW5fQVBRJmU9 DQo+ID4gPj4gPiA+ID4gPiAuDQo+ID4gPj4gPiA+ID4gPg0KPiA+ID4+ID4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gPiA+ID4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KPiA+ID4+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYNCj4gPiA+PiA+ID4gPiAubw0KPiA+ID4+ ID4gPiA+DQo+ID4gcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2 M3JzdWhyNlNjYmZoMFVqQlhlDQo+ID4gPj4gPiA+ID4gTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJ JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNaDQo+ID4gPj4gPiA+ ID4NCj4gPiBvJm09N3M2VmR6ekg5T2wzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0kyS0RFTjk3YyZz PVJWSmNnNXB6SFctemkNCj4gPiA+PiA+ID4gPiAxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I5bl9B UFEmZT0NCj4gPiA+PiAtLQ0KPiA+ID4+IExhZGlzbGF2IExob3RrYQ0KPiA+ID4+IEhlYWQsIENa Lk5JQyBMYWJzDQo+ID4gPj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+ID4gPj4N Cj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+PiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tDQo+ID4gPj4gYWkNCj4gPiA+PiBs bWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN Sy0NCj4gPiBuZGIzdm9EVFgNCj4gPiA+Pg0KPiA+DQo+IGNXem9DSSZyPTl6a1AweG5KVXZaR0o5 RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03czZWZHp6SDlPbDMNCj4gPiBCTw0KPiA+ ID4+IENiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9UlZKY2c1cHpIVy0NCj4gPiB6aTFP Ym9DTDRTWDJodVc5ZXVIaVZSU0Nvcg0KPiA+ID4+IDluX0FQUSZlPQ0KPiA+ID4+DQo+ID4gPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc+DQo+ID4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbQ0KPiA+ID4+IGFpbG1hbl9saXN0aW5mb19uZXRt b2QmZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2DQo+ID4g Pj4NCj4gb0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh SmRjWm8mbT1ETTFqc3cNCj4gbk0NCj4gPiA+PiA0OEd3ZEk0dGV6LUp0ZjJ1YTJqdnRMWlZLZml3 a2J3YklyVSZzPWcweF9CLQ0KPiBYZXo3dEQ5aExYNzFENXZsY0hkWm9obg0KPiA+ID4+IFRraU1W SUtKaEFIaXZrJmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0NCj4gPiA+PiAzQV9fdXJsZGVmZW5zZS5wcm9vZiZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRA0KPiA+ID4+DQo+IFRYY1d6b0NJJnI9OXprUDB4 bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpzd25NDQo+IDQ4DQo+ ID4gPj4gR3dkSTR0ZXotDQo+IEp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZzPWJ6TGFMb0JDSjg4 bGF2ZXVwTHFhcFlONGJ0akVCQnYNCj4gPiA+PiBORU5OeTA5VHNvb2MmZT0NCj4gPiA+PiBwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ID4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX25ldG1vZCZkPUQNCj4gPiA+PiB3TUZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN Sy0NCj4gPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUUNCj4gPiA+PiBQb09IN1lo cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09TzdkLQ0KPiA+IGI5Z3lQdnNhc0pvMXVlS2szZG9ESDdm NVM1V1FMbzhfVzYNCj4gPiA+PiBXM3F0NCZzPTVMSGhiZlFaZW9xWWxDNDBUM21tLUFFejRyU3N5 UldZanFUSzdMdVdUUHcmZT0+DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gPiBQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQo+ID4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMw0KPiA8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuamFjb2JzLQ0K PiAyRCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRY Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUQN Cj4gTTFqc3duTTQ4R3dkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9NVJEOTYtDQo+ IFRqeW1VMVpobWZaRnRXRW00YWJra2RheHFya0NLenV2NFBaUlEmZT0NCj4gPiB1bml2ZXJzaXR5 LmRlLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ ID4gM0FfX3d3dy5qYWNvYnMtDQo+ID4gMkR1bml2ZXJzaXR5LmRlXyZkPUR3TUZhUSZjPUhBa1l1 aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gPg0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Tw0KPiA+IDdkLQ0KPiA+DQo+ IGI5Z3lQdnNhc0pvMXVlS2szZG9ESDdmNVM1V1FMbzhfVzZXM3F0NCZzPXpoN3FFUFNtd3ZpYVNx WkJxRzFHYw0KPiA+IHFJdFh3STlwd3lxSUZWVzZ4QzhySzgmZT0+Pg0KPiA+ID4NCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBuZXRt b2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1E d0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0QNCj4gPiA+DQo+ IFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt PURNMWpzd25NDQo+IDQ4Rw0KPiA+ID4gd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJclUm cz1nMHhfQi0NCj4gWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNDQo+ID4gPiBWSUtKaEFIaXZr JmU9PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f dQ0KPiA+ID4gcmxkZWZlbnNlLnByb29mcCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgw VWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6DQo+ID4gPg0KPiBvQ0kmcj05emtQMHhuSlV2WkdKOUVQ b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk00OEd3ZA0KPiBJNHQNCj4gPiA+ IGV6LUp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZzPWlkNWtkWERFYjRhZm5vYldULQ0KPiBmVXEz WWZzSWtIb296NVJ0WFlzbw0KPiA+ID4gUVJ0MW8mZT0NCj4gPiA+IG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLQ0KPiA+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1E d00NCj4gPiA+IEZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gPiBuZGIzdm9E VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb08NCj4gPiA+IEg3WWhxbjJnc0JZYUdUdmpJU2xh SmRjWm8mbT1PN2QtDQo+ID4gYjlneVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxvOF9XNlczcXQN Cj4gPiA+IDQmcz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJXWWpxVEs3THVXVFB3JmU9 Pg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmcN Cj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lGQWcm Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0QNCj4gPiA+DQo+IFRYY1d6 b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpz d25NDQo+IDQ4Rw0KPiA+ID4gd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJclUmcz1nMHhf Qi0NCj4gWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNDQo+ID4gPiBWSUtKaEFIaXZrJmU9DQo+ ID4NCj4gPiAtLQ0KPiA+IExhZGlzbGF2IExob3RrYQ0KPiA+IEhlYWQsIENaLk5JQyBMYWJzDQo+ ID4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxp c3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+ID4gbWFuX2xpc3Rp bmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRi M3ZvRFRYY1cNCj4gPg0KPiB6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2 aklTbGFKZGNabyZtPURNMWpzd25NNDhHdw0KPiBkSTR0ZQ0KPiA+IHotSnRmMnVhMmp2dExaVktm aXdrYndiSXJVJnM9ZzB4X0ItDQo+IFhlejd0RDloTFg3MUQ1dmxjSGRab2huVGtpTVZJS0poQUhp DQo+ID4gdmsmZT0NCg0KDQo= From nobody Wed Oct 10 19:00:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5796130DFE for ; Wed, 10 Oct 2018 19:00: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 ePNoVPfi5ngB for ; Wed, 10 Oct 2018 18:59:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC92130DFB for ; Wed, 10 Oct 2018 18:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3926; q=dns/txt; s=iport; t=1539223199; x=1540432799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bRWtGx/ehDuctyYaOgnn1MurEaJWK/spw78Nf7/LN1s=; b=KPavBZdm1YfWliQAgyy+fLl8ylvZdW2DoLWFSI03yp1RFG+n/+WB6bx8 p18LDFGT4RW+P7U6X/mO3rRFsXucSyWc0txbVAzls2ZZycVpiirX61tRU 6e5K4oA9FfdMFvEjziwS1OGw1KEAocCxp83E+nNOLKTdawJQOmXabjnYf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAAC/rb5b/4YNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggNmfygKg2uUTYFoJZh5CwEBGAuEA0Y?= =?us-ascii?q?CF4Q5ITcKDQEDAQECAQECbRwMhTkBAQEDAQEBIRE6CxACAQgOCgICJgICAiU?= =?us-ascii?q?LFRACBAEJBAWDIQGBeQgPph+BLoR3hGUFgQuKMBeBQT+BOQwTgkyDGwEBgUs?= =?us-ascii?q?WFyOCRzGCJgKOMY9YCQKQUBeBT44+iROMVAIRFIElMyKBVXAVOyoBgkGLF4U?= =?us-ascii?q?+b4xEgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,366,1534809600"; d="scan'208";a="246597327" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 01:59:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9B1xwTH013425 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2018 01:59:58 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Oct 2018 20:59:58 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 10 Oct 2018 20:59:58 -0500 From: "Reshad Rahman (rrahman)" To: Martin Bjorklund , "lhotka@nic.cz" CC: "netmod@ietf.org" Thread-Topic: [netmod] xpath expressions in JSON Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgA== Date: Thu, 11 Oct 2018 01:59:57 +0000 Message-ID: <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> <20181010.155915.278994099457235212.mbj@tail-f.com> In-Reply-To: <20181010.155915.278994099457235212.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.62] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 02:00:02 -0000 T24gMjAxOC0xMC0xMCwgOTo1OSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTWFydGluIEJqb3Jr bHVuZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNv bT4gd3JvdGU6DQoNCiAgICBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0K ICAgID4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCiAgICA+IA0K ICAgID4gPiBIaSwNCiAgICA+ID4NCiAgICA+ID4gV2hpbGUgcmV2aWV3aW5nIHJlc3Rjb25mLW5v dGlmLCBJIHNhdyB0aGlzIGV4YW1wbGU6DQogICAgPiA+DQogICAgPiA+ICAgIHsNCiAgICA+ID4g ICAgICAgImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOmlucHV0Ijogew0KICAgID4gPiAg ICAgICAgICAic3RyZWFtIjogIk5FVENPTkYiLA0KICAgID4gPiAgICAgICAgICAic3RyZWFtLXhw YXRoLWZpbHRlciI6ICIvZHM6Zm9vLyIsDQogICAgPiA+ICAgICAgICAgICJkc2NwIjogIjEwIg0K ICAgID4gPiAgICAgICB9DQogICAgPiA+ICAgIH0NCiAgICA+ID4NCiAgICA+ID4gTm90ZSB0aGUg InN0cmVhbS14cGF0aC1maWx0ZXIiLiAgSXQgaGFzIGEgcHJlZml4IGluIHRoZSBYUGF0aCBzdHJp bmcuDQogICAgPiA+IEhvdyBhcmUgcHJlZml4ZXMgZGVjbGFyZWQgd2hlbiBKU09OIGlzIHVzZWQ/ DQogICAgPiA+DQogICAgPiA+IFRoZSBsZWFmICJzdHJlYW0teHBhdGgtZmlsdGVyIiBzYXlzOg0K ICAgID4gPg0KICAgID4gPiAgICAgICAgICAgICAgIG8gIFRoZSBzZXQgb2YgbmFtZXNwYWNlIGRl Y2xhcmF0aW9ucyBhcmUgdGhvc2UgaW4gc2NvcGUgb24NCiAgICA+ID4gICAgICAgICAgICAgICAg ICB0aGUgJ3N0cmVhbS14cGF0aC1maWx0ZXInIGxlYWYgZWxlbWVudC4NCiAgICA+ID4NCiAgICA+ ID4gKEkgdGhpbmsgSSBwcm92aWRlZCB0aGF0IHRleHQuLi4pDQogICAgPiA+DQogICAgPiA+IFRo aXMgYXNzdW1lcyB0aGF0IHRoZSBlbmNvZGluZyBpcyBYTUwsIG9yIGF0IGxlYXMgdGhhdCB0aGUg ZW5jb2RpbmcNCiAgICA+ID4gY2FuIHNvbWVob3cgdHJhbnNmZXIgbmFtZXNwYWNlIGRlY2xhcmF0 aW9ucy4NCiAgICA+IA0KICAgID4gSXQgY2FuJ3QuIFRoZXJlIGFyZSB0d28gb3B0aW9uczoNCiAg ICA+IA0KICAgID4gMS4gaGF2ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIG9mIHRoaXMgdmFs dWUgaW4gWE1MIGFuZCBKU09OLA0KICAgID4gICAgYW5hbG9naWNhbGx5IHRvIGluc3RhbmNlIGlu ZGVudGlmaWVycyAoc2VjLiA2LjExIGluIFJGQyA3OTUxKS4NCiAgICA+IA0KICAgID4gMi4gdXNl IGEgbW9kdWxlIG5hbWUgcmF0aGVyIHRoYW4gYSBwcmVmaXggaW4gWE1MLCB0b28uDQogICAgPiAN CiAgICA+IEkgd291bGQgc3VnZ2VzdCAjMi4NCjxSUj4gQnV0IHRoYXQgbWVhbnMgbWFraW5nIG5v bi1iYWNrd2FyZHMgY29tcGF0aWJsZSBjaGFuZ2UgdG8gdGhlIFhNTCByZXByZXNlbnRhdGlvbj8N CiAgICANCiAgICBIbW0sIHNvIHlvdSBtZWFuIGNoYW5nZSB0aGUgbGVhZiAic3RyZWFtLXhwYXRo LWZpbHRlciIgdG8gc2F5Og0KICAgIA0KICAgICAgICAgICAgIG8gIFRoZSBzZXQgb2YgbmFtZXNw YWNlIGRlY2xhcmF0aW9ucyBoYXMgb25lIG1lbWJlciBmb3IgZWFjaA0KICAgICAgICAgICAgICAg IFlBTkcgbW9kdWxlIHN1cHBvcnRlZCBieSB0aGUgc2VydmVyLiAgVGhpcyBtZW1iZXIgbWFwcw0K ICAgICAgICAgICAgICAgIGZyb20gdGhlIFlBTkcgbW9kdWxlIG5hbWUgdG8gdGhlIFlBTkcgbW9k dWxlIG5hbWVzcGFjZS4NCiAgICANCiAgICAgICAgICAgICAgICBUaGlzIG1lYW5zIHRoYXQgaW4g dGhlIFhQYXRoIGV4cHJlc3Npb24sIHRoZSBtb2R1bGUgbmFtZQ0KICAgICAgICAgICAgICAgIHNl cnZlcyBhcyB0aGUgcHJlZml4Lg0KICAgIA0KICAgIC4uLi4gYW5kIHRoZW4gYWxzbyBnaXZlIGFu IGV4YW1wbGUgb2YgdGhpcy4NCiAgICANCiAgICBUaGlzIGlzIHByb2JhYmx5IHdoYXQgd2UgbmVl ZCB0byBkbyBpbiBhbGwgcGxhY2VzIHdoZXJlIHlhbmc6eHBhdGgxLjANCiAgICBpcyB1c2VkLCBn b2luZyBmb3J3YXJkLiAgTWF5YmUgZXZlbiBkZWZpbmUgYSBuZXcgdHlwZQ0KICAgIHlhbmc6eHBh dGgxLjAtMiAobmFtZT8pIHdpdGggdGhlIHNldCBvZiBuYW1lc3BhY2UgZGVjbGFyYXRpb25zDQog ICAgYnVpbHQtaW4uDQo8UlI+IFNvIHdlIG5lZWQgYW4gdXBkYXRlIHRvIFJGQzc5NTE/DQoNClJl Z2FyZHMsDQpSZXNoYWQuDQogICAgDQogICAgDQogICAgL21hcnRpbg0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIA0KICAgID4gDQogICAgPiBMYWRhDQogICAgPiANCiAgICA+ID4NCiAgICA+ ID4gSG93IGlzIHRoaXMgc3VwcG9zZWQgdG8gd29yayB3aXRoIEpTT04/DQogICAgPiA+DQogICAg PiA+DQogICAgPiA+IC9tYXJ0aW4NCiAgICA+ID4NCiAgICA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ID4gbmV0bW9kIG1haWxpbmcgbGlz dA0KICAgID4gPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+IA0KICAgID4gLS0gDQogICAgPiBMYWRpc2xh diBMaG90a2ENCiAgICA+IEhlYWQsIENaLk5JQyBMYWJzDQogICAgPiBQR1AgS2V5IElEOiAweEI4 RjkyQjA4QTlGNzZDNjcNCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5l dG1vZEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kDQogICAgDQoNCg== From nobody Wed Oct 10 19:20:13 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2796E130DFF for ; Wed, 10 Oct 2018 19:20:12 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 PvkNUUtK-YWe for ; Wed, 10 Oct 2018 19:20:05 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 3B545130DF2 for ; Wed, 10 Oct 2018 19:20:04 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id w21-v6so5468702lff.6 for ; Wed, 10 Oct 2018 19:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xhvjRvHSKMuzCPxmyGoUKEDjzT5L9QE3v4UmTkmcXdU=; b=2J0ImJRryMJT+w9jeo8dxYtCPlUvITjDr/x4AVPIPxr7nIcVzHWgQioDus35qKNohX oF7Dt+uO+o9AZsuq/Ewy6u6LWa//HMhrD2ak9vjKhd83OR5n2fVIJ/IqsqrKO97h15EB SB0DH7iUQu98l6Xrid/aZdJZJ5Os2rEykM/4nfdwlPQJ83s5fSixVwQmucEG8X9wQZ1f avGnwz1s6uxXZBLpqcclBMT7iygl5pHdQRhRaAtUVWr1AO8Z9AnQwGOO1zt8g9VXbqtk 5xitbWF3fuP4BJckzMOZAaDcT6OriulnG379o6o2m0RO4DzpQbi2JrnR3RZ1aqV+HBuU uktA== 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=xhvjRvHSKMuzCPxmyGoUKEDjzT5L9QE3v4UmTkmcXdU=; b=OhXHDHTbWCDuLWk2Kkdan9MqYfolypEd8EqfPqseG/iAboFaSrFcwzNLxFzxW8SFCW 1RdeaywDKZGWhefYXj5tz8IwjFVxI722Dc60nC530JJqI8uPjiwyyuFGCbfmviQgu3bk +XZyiYb/CVz517jUfeR0o/dIQhchy8enTVxy0GyZrkMOscnds+uKzd1uw4i2g+AhaVJz SKntJGBZKNFLjK0WA6yuUF9JjxwNjHOCNH4zB28JfhTG4ZYIaV/iQjmNTq9bIKeqf83h V1WcKCsgghT09m8qtkwlsNKC5rE7LUAgKWs4XnADz/1zc0ba+PWdm9rFZVz4R4YWmNGW 3TnQ== X-Gm-Message-State: ABuFfogAN31KZSnOGC5jQp4UjLFA4lyJRoSfXlDAZi5VrWeYfgb03DaD hdgldQo5lVRtXULcCyCpcRpwhQRpvGURb2At2Q13Zg== X-Google-Smtp-Source: ACcGV605pYhDT2rBnfLZ0oHCmvkxXpC3pfwpJ5Ox2iRaYMM9gwbCKzxZry74jedD6aE/MHGm+DfWpv7yOmxuorKMLMM= X-Received: by 2002:a19:7709:: with SMTP id s9-v6mr15583747lfc.84.1539224402158; Wed, 10 Oct 2018 19:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Wed, 10 Oct 2018 19:20:00 -0700 (PDT) In-Reply-To: <8E17601A-EE48-4750-B11F-63BC6068C530@juniper.net> References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz> <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de> <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com> <8E17601A-EE48-4750-B11F-63BC6068C530@juniper.net> From: Andy Bierman Date: Wed, 10 Oct 2018 19:20:00 -0700 Message-ID: To: Kent Watsen Cc: Alexander Clemm , Ladislav Lhotka , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b87c250577ea9b23" Archived-At: Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 02:20:12 -0000 --000000000000b87c250577ea9b23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen wrote: > Hi Alex, no objection. > > My support withdraw appears to put me in the rough, which is fine from a > process perspective. But make no mistake, I think that it's bizaar for a > "diff" to not show both values. Andy's idea to augment in an 'old-value' > node seems like a step in the right direction. > > The requirements and use-cases have not really been discussed first. If the use-case is for humans to compare the datastores (e.g., a side-by-side diff like an I-D) then the format would be very different than if the use-case was more programmatic (e.g., look for no diffs, look for an edit completed, patch a local copy). > Kent // contributor > Andy > > > =EF=BB=BF-----Original Message----- > From: Alexander Clemm > Date: Wednesday, October 10, 2018 at 6:06 PM > To: Kent Watsen , Ladislav Lhotka , > Andy Bierman , Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" > Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-0= 0 > > Which format to make mandatory sounds like something we can discuss in > Bangkok. The reason YANG-patch was chosen is reuse, although it is > certainly conceivable to develop another format. (Per discussion on the > list we will put the hooks in place to allow for other options.) Either > way, this seems to be one of the technical details that need to be decide= d, > not something that would make or break support as a whole? > --- Alex > > > -----Original Message----- > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > Sent: Tuesday, October 09, 2018 10:17 AM > > To: Alexander Clemm ; Ladislav Lhotka > > ; Andy Bierman ; Juergen > > Schoenwaelder ; netmod@ietf.org > > Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff= - > 00 > > > > I agree that a mandatory to implement format is desirable. > > > > I disagree that YANG-Patch is the right format, for reasons stated > before. I feel > > that a compromise of this sort for a mandatory-to-implement is wrong. > > > > If this is what the WG wants, I withdraw my support. > > > > Kent // contributor > > > > > > > > -----Original Message----- > > From: Alexander Clemm > > Date: Monday, October 8, 2018 at 5:05 PM > > To: Ladislav Lhotka , Kent Watsen , > > Andy Bierman , Juergen Schoenwaelder > > , "netmod@ietf.org" > > > > Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff= - > 00 > > > > I would second the request for one format (which is mandatory to > support), > > which must be specified. YANG-Patch is the logical candidate IMHO. > > > > To allow selection of other formats using an input parameter makes > sense, but > > adds some complexity from there: How to know which formats are > supported? > > (Add a list of supported formats somewhere?) Or simply rely on > augmentation > > for those implementations that want it? > > > > --- Alex > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > > > Lhotka > > > Sent: Friday, October 05, 2018 12:50 AM > > > To: Kent Watsen ; Andy Bierman > > > ; Juergen Schoenwaelder > > university.de>; netmod@ietf.org > > > Subject: Re: [netmod] WG adoption poll for > > > draft-clemm-netmod-nmda-diff-00 > > > > > > Kent Watsen writes: > > > > > > > Sure, one mandatory to implement format, others nice to have. > > > > Interoperability good. Agreed. > > > > > > > > But why YANG-patch and not something built for the purpose (e.g., > > > > YANG-diff) that, in particular, provides an actual diff as opposed > > > > to a data-tree operation that only shows one of the two values? > > > > > > Such a format can be developed independently, I would support it. > > > > > > Lada > > > > > > > > > > > Kent // contributor > > > > > > > > > > > > On 10/4/18, 3:27 PM, "Andy Bierman" > > > > wrote: > > > > > > > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder > > > > > university.de>> wrote: > > > > Folks, the more formats there are, the less interoperability we get= . > > > > If there are multiple formats, is there a mandatory to implement > > > > format? Does the mandatory to implement format depend on the > > > > protocol that is being used? > > > > > > > > I prefer one format or if necessary I am fine with one mandatory to > > > > implement format. An open ended collection of implementation > > > > specific formats is super flexible but defeats the purpose of a > > > > standard, namely interoperability. > > > > > > > > I agree there needs to be 1 mandatory-to-implement format. > > > > > > > > IMO this needs to be YANG Patch because it is more precise then > > > > constructing an XML tree with operation attributes in it (e.g., how > > > > else do you represent a delete or a move?) Also, YANG Push is using > > > > YANG Patch format and common code for push and diff would be > possible. > > > > > > > > I think other formats should be allowed. > > > > This is very tool-specific. I could see how somebody might want a > > > > textual patch of the XML representation to produce the new XML > > > representation. > > > > > > > > > > > > /js > > > > > > > > Andy > > > > > > > > > > > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote: > > > >> We agree that the diff-format should be client-selectable, modulo > > > >> what the > > > server supports. yang-patch and edit-config both are viable. Should > > > we document them both? > > > >> > > > >> That said, since neither edit-config nor yang-patch are diffing > > > >> formats, so > > > much as formats for converting one data tree to another, would it mak= e > > > sense to define an actual diffing format? I would think that a diff > > > would provide both values, not just a new value. > > > >> > > > >> Kent // contributor > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: netmod > > > >> > on behal= f > > > >> of Ladislav Lhotka > > > > >> Organization: CZ.NIC > > > >> Date: Thursday, October 4, 2018 at 1:11 PM > > > >> To: Robert Wilton >, > > > >> "netmod@ietf.org" > > > >> > > > > >> Subject: Re: [netmod] WG adoption poll for > > > >> draft-clemm-netmod-nmda-diff-00 > > > >> > > > >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote: > > > >> > > > > >> > On 04/10/2018 13:51, Ladislav Lhotka wrote: > > > >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilton wrote: > > > >> > > > On 04/10/2018 11:14, Martin Bjorklund wrote: > > > >> > > > > Phil Shafer > > wrote: > > > >> > > > > > Bal?zs Lengyel writes: > > > >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A_= _to > > > >> > > > > > > ol > > > >> > > > > > > s.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2= D > > > >> > > > > > > 00 > > > >> > > > > > > &d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > > ndb3voDTXcWzoCI&r > > > >> > > > > > > > > > =3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9O > > > >> > > > > > > > > > l3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3QgRvABgZK > > > >> > > > > > > sjqzuIw9yUq_xee6aFJOcw&e=3D > > > >> > > > > > [I've moved to a "deep lurker" role here, but ...] > > > >> > > > > > > > > >> > > > > > Can we ensure this model contains a "format" leaf in the > RPC's > > input > > > >> > > > > > so that future (and proprietary) formats can be > supported? That > > > >> > > > > > leaf can be an identityref that defaults to yang-patch. > > > >> > > > > I think this is a good idea. I would prefer the > > > >> > > > > edit-config format over YANG patch for describing a diff. > > > >> > > > > The edit-config format is more suited for this purpose imo= . > > > >> > > > +1 > > > >> > > > > > > >> > > > I would like something closer to edit-config to be available > > > >> > > > via RESTCONF as well. > > > >> > > YANG Patch is IMO better because it clearly separates the > > > >> > > target for the edits from the new content. > > > >> > > In edit-config these two are mixed together. > > > >> > Yes, that is primarily why I prefer the edit-config. I perceive > > > >> > that it is a denser and more efficient format. I think that it > > > >> > is both easier to construct (when diffing two trees) and also > > > >> > more efficient to apply when generating an updated tree. > > > >> > > > >> Except for certain corner cases, for example if two trees differ > > > >> only in the value of a single leaf but this leaf happens to be a > list key. > > > >> > > > >> Lada > > > >> > > > >> > > > > >> > Thanks, > > > >> > Rob > > > >> > > > > >> > > > > >> > > That being said, I support specifying format/media-type and > > > >> > > having potentially multiple options. > > > >> > > > > > >> > > Lada > > > >> > > > > > >> > > > Thanks, > > > >> > > > Rob > > > >> > > > > > > >> > > > > > > >> > > > > /martin > > > >> > > > > > > > >> > > > > _______________________________________________ > > > >> > > > > netmod mailing list > > > >> > > > > netmod@ietf.org > > > >> > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ie > > > >> > > > > tf > > > >> > > > > > > > .org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0U > > > >> > > > > jBXeMK- > > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS > > > >> > > > > > > > laJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg > > > >> > > > > 5pzHW-zi1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > >> > > > > . > > > >> > > > > > > > >> > > > _______________________________________________ > > > >> > > > netmod mailing list > > > >> > > > netmod@ietf.org > > > >> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.i= etf > > > >> > > > .o > > > >> > > > > > > rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe > > > >> > > > MK- > > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZ > > > >> > > > > > > o&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW-zi > > > >> > > > 1OboCL4SX2huW9euHiVRSCor9n_APQ&e=3D > > > >> -- > > > >> Ladislav Lhotka > > > >> Head, CZ.NIC Labs > > > >> PGP Key ID: 0xB8F92B08A9F76C67 > > > >> > > > >> _______________________________________________ > > > >> netmod mailing list > > > >> netmod@ietf.org > > > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_m > > > >> ai > > > >> lman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > > ndb3voDTX > > > >> > > > > > cWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7s6VdzzH9Ol3 > > > BO > > > >> CbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > > > zi1OboCL4SX2huW9euHiVRSCor > > > >> 9n_APQ&e=3D > > > >> > > > >> _______________________________________________ > > > >> netmod mailing list > > > >> netmod@ietf.org > > > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.or= g_m > > > >> ailman_listinfo_netmod&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3v > > > >> > > oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jsw > > nM > > > >> 48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > > Xez7tD9hLX71D5vlcHdZohn > > > >> TkiMVIKJhAHivk&e=3D > > >> 3A__urldefense.proof&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voD > > > >> > > TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jswnM > > 48 > > > >> GwdI4tez- > > Jtf2ua2jvtLZVKfiwkbwbIrU&s=3DbzLaLoBCJ88laveupLqapYN4btjEBBv > > > >> NENNy09Tsooc&e=3D > > > >> point.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DD > > > >> wMFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9E > > > >> PoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d- > > > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6 > > > >> W3qt4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=3D> > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 > > > 2D&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DD > > M1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3D5RD96- > > TjymU1ZhmfZFtWEm4abkkdaxqrkCKzuv4PZRQ&e=3D > > > university.de/ > > 3A__www.jacobs- > > > 2Duniversity.de_&d=3DDwMFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > > > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO > > > 7d- > > > > > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=3Dzh7qEPSmwviaSqZBqG1Gc > > > qItXwI9pwyqIFVW6xC8rK8&e=3D>> > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _ma > > > > ilman_listinfo_netmod&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voD > > > > > > TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jswnM > > 48G > > > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > > Xez7tD9hLX71D5vlcHdZohnTkiM > > > > VIKJhAHivk&e=3D > > > rldefense.proofp&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voDTXcWz > > > > > > oCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jswnM48Gwd > > I4t > > > > ez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Did5kdXDEb4afnobWT- > > fUq3YfsIkHooz5RtXYso > > > > QRt1o&e=3D > > > > oint.com/v2/url?u=3Dhttps- > > > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwM > > > > FaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoO > > > > H7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d- > > > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt > > > > 4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&e=3D> > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _ma > > > > ilman_listinfo_netmod&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voD > > > > > > TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jswnM > > 48G > > > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > > Xez7tD9hLX71D5vlcHdZohnTkiM > > > > VIKJhAHivk&e=3D > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ail > > > man_listinfo_netmod&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > > ndb3voDTXcW > > > > > zoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DDM1jswnM48Gw > > dI4te > > > z-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > > Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHi > > > vk&e=3D > > > --000000000000b87c250577ea9b23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 10, 2018 at 6:39 PM, Kent Watsen <kwatsen@juniper.net> wrote:
Hi Alex, no objection= .

My support withdraw appears to put me in the rough, which is fine from a pr= ocess perspective.=C2=A0 But make no mistake, I think that it's bizaar = for a "diff" to not show both values.=C2=A0 Andy's idea to au= gment in an 'old-value' node seems like a step in the right directi= on.


The requirements and use-cases have no= t really been discussed first.
If the use-case is for humans to c= ompare the datastores (e.g., a side-by-side diff like an I-D)
the= n the format would be very different than if the use-case was more programm= atic
(e.g., look for no diffs, look for an edit completed, patch = a local copy).
=C2=A0
Kent // contributor

Andy
=C2= =A0


=EF=BB=BF-----Original Message-----
From: Alexander Clemm <ale= xander.clemm@huawei.com>
Date: Wednesday, October 10, 2018 at 6:06 PM
To: Kent Watsen <kwatsen@juniper.= net>, Ladislav Lhotka <lhotka@ni= c.cz>, Andy Bierman <andy@y= umaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt;, "netmod@ietf.org" <= ;netmod@ietf.org>
Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Which format to make mandatory sounds like something we can discuss in Bang= kok.=C2=A0 The reason YANG-patch was chosen is reuse, although it is certai= nly conceivable to develop another format.=C2=A0 (Per discussion on the lis= t we will put the hooks in place to allow for other options.)=C2=A0 Either = way, this seems to be one of the technical details that need to be decided,= not something that would make or break support as a whole?=C2=A0
--- Alex

> -----Original Message-----
> From: Kent Watsen [mailto:kwats= en@juniper.net]
> Sent: Tuesday, October 09, 2018 10:17 AM
> To: Alexander Clemm <= alexander.clemm@huawei.com>; Ladislav Lhotka
> <lhotka@nic.cz>; Andy Bierm= an <andy@yumaworks.com>; Ju= ergen
> Schoenwaelder <j.schoenwaelder@jacobs-university.de>; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-dif= f-00
>
> I agree that a mandatory to implement format is desirable.
>
> I disagree that YANG-Patch is the right format, for reasons stated bef= ore.=C2=A0 I feel
> that a compromise of this sort for a mandatory-to-implement is wrong.<= br> >
> If this is what the WG wants, I withdraw my support.
>
> Kent // contributor
>
>
>
> -----Original Message-----
> From: Alexander Clemm <alexander.clemm@huawei.com>
> Date: Monday, October 8, 2018 at 5:05 PM
> To: Ladislav Lhotka <lhotka@nic.cz= >, Kent Watsen <kwatsen@ju= niper.net>,
> Andy Bierman <andy@yumaworks.= com>, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de>, "netmod@ietf.org"
> <netmod@ietf.org>
> Subject: RE: [netmod] WG adoption poll for draft-clemm-netmod-nmda-dif= f-00
>
> I would second the request for one format (which is mandatory to suppo= rt),
> which must be specified.=C2=A0 YANG-Patch is the logical candidate IMH= O.
>
> To allow selection of other formats using an input parameter makes sen= se, but
> adds some complexity from there:=C2=A0 How to know which formats are s= upported?
> (Add a list of supported formats somewhere?)=C2=A0 =C2=A0Or simply rel= y on augmentation
> for those implementations that want it?
>
> --- Alex
>
> > -----Original Message-----
> > From: netmod [mailto:n= etmod-bounces@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > Sent: Friday, October 05, 2018 12:50 AM
> > To: Kent Watsen <kwatse= n@juniper.net>; Andy Bierman
> > <andy@yumaworks.com&= gt;; Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> > university.de>; netmod@ietf.= org
> > Subject: Re: [netmod] WG adoption poll for
> > draft-clemm-netmod-nmda-diff-00
> >
> > Kent Watsen <kwatsen@ju= niper.net> writes:
> >
> > > Sure, one mandatory to implement format, others nice to have= .
> > > Interoperability good.=C2=A0 Agreed.
> > >
> > > But why YANG-patch and not something built for the purpose (= e.g.,
> > > YANG-diff) that, in particular, provides an actual diff as o= pposed
> > > to a data-tree operation that only shows one of the two valu= es?
> >
> > Such a format can be developed independently, I would support it.=
> >
> > Lada
> >
> > >
> > > Kent // contributor
> > >
> > >
> > > On 10/4/18, 3:27 PM, "Andy Bierman"
> > <andy@yumaworks.com&= lt;mailto:andy@yumaworks.com= >> wrote:
> > >
> > > On Thu, Oct 4, 2018 at 12:07 PM, Juergen Schoenwaelder
> > <j.sch= oenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-
> > university.de>> wrote:
> > > Folks, the more formats there are, the less interoperability= we get.
> > > If there are multiple formats, is there a mandatory to imple= ment
> > > format? Does the mandatory to implement format depend on the=
> > > protocol that is being used?
> > >
> > > I prefer one format or if necessary I am fine with one manda= tory to
> > > implement format. An open ended collection of implementation=
> > > specific formats is super flexible but defeats the purpose o= f a
> > > standard, namely interoperability.
> > >
> > > I agree there needs to be 1 mandatory-to-implement format. > > >
> > > IMO this needs to be YANG Patch because it is more precise t= hen
> > > constructing an XML tree with operation attributes in it (e.= g., how
> > > else do you represent a delete or a move?) Also, YANG Push i= s using
> > > YANG Patch format and common code for push and diff would be= possible.
> > >
> > > I think other formats should be allowed.
> > > This is very tool-specific. I could see how somebody might w= ant a
> > > textual patch of the XML representation to produce the new X= ML
> > representation.
> > >
> > >
> > > /js
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 04, 2018 at 05:41:22PM +0000, Kent Watsen wrote:=
> > >> We agree that the diff-format should be client-selectabl= e, modulo
> > >> what the
> > server supports.=C2=A0 yang-patch and edit-config both are viable= .=C2=A0 Should
> > we document them both?
> > >>
> > >> That said, since neither edit-config nor yang-patch are = diffing
> > >> formats, so
> > much as formats for converting one data tree to another, would it= make
> > sense to define an actual diffing format?=C2=A0 I would think tha= t a diff
> > would provide both values, not just a new value.
> > >>
> > >> Kent // contributor
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: netmod
> > >> <netmod-bo= unces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf
> > >> of Ladislav Lhotka <= lhotka@nic.cz<mailto:lhotka@ni= c.cz>>
> > >> Organization: CZ.NIC
> > >> Date: Thursday, October 4, 2018 at 1:11 PM
> > >> To: Robert Wilton <rwilton@cisco.com<mailto:rwi= lton@cisco.com>>,
> > >> "netmod@ietf.org= <mailto:netmod@ietf.org&= gt;"
> > >> <netmod@ietf.org<mailto:netmod@ietf.org>= ;>
> > >> Subject: Re: [netmod] WG adoption poll for
> > >> draft-clemm-netmod-nmda-diff-00
> > >>
> > >> On Thu, 2018-10-04 at 14:17 +0100, Robert Wilton wrote:<= br> > > >> >
> > >> > On 04/10/2018 13:51, Ladislav Lhotka wrote:
> > >> > > On Thu, 2018-10-04 at 13:36 +0100, Robert Wilt= on wrote:
> > >> > > > On 04/10/2018 11:14, Martin Bjorklund wro= te:
> > >> > > > > Phil Shafer <phil@juniper.net<mailto:phil@juniper.net>> wrote:
> > >> > > > > > Bal?zs Lengyel writes:
> > >> > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__to > > >> > > > > > > ol
> > >> > > > > > > s.ietf.org_html_draft-2Dcl= emm-2Dnetmod-2Dnmda-2Ddiff-2D
> > >> > > > > > > 00
> > >> > > > > > > &d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r
> > >> > > > > > >
> > =3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D= 7s6VdzzH9O
> > >> > > > > > >
> > l3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DgQWJtjc_2EF3Q= gRvABgZK
> > >> > > > > > > sjqzuIw9yUq_xee6aFJOcw&= ;e=3D
> > >> > > > > > [I've moved to a "deep= lurker" role here, but ...]
> > >> > > > > >
> > >> > > > > > Can we ensure this model contai= ns a "format" leaf in the RPC's
> input
> > >> > > > > > so that future (and proprietary= ) formats can be supported?=C2=A0 =C2=A0That
> > >> > > > > > leaf can be an identityref that= defaults to yang-patch.
> > >> > > > > I think this is a good idea.=C2=A0 I= would prefer the
> > >> > > > > edit-config format over YANG patch f= or describing a diff.
> > >> > > > > The edit-config format is more suite= d for this purpose imo.
> > >> > > > +1
> > >> > > >
> > >> > > > I would like something closer to edit-con= fig to be available
> > >> > > > via RESTCONF as well.
> > >> > > YANG Patch is IMO better because it clearly se= parates the
> > >> > > target for the edits from the new content.
> > >> > > In edit-config these two are mixed together. > > >> > Yes, that is primarily why I prefer the edit-config= .=C2=A0 I perceive
> > >> > that it is a denser and more efficient format.=C2= =A0 I think that it
> > >> > is both easier to construct (when diffing two trees= ) and also
> > >> > more efficient to apply when generating an updated = tree.
> > >>
> > >> Except for certain corner cases, for example if two tree= s differ
> > >> only in the value of a single leaf but this leaf happens= to be a list key.
> > >>
> > >> Lada
> > >>
> > >> >
> > >> > Thanks,
> > >> > Rob
> > >> >
> > >> >
> > >> > > That being said, I support specifying format/m= edia-type and
> > >> > > having potentially multiple options.
> > >> > >
> > >> > > Lada
> > >> > >
> > >> > > > Thanks,
> > >> > > > Rob
> > >> > > >
> > >> > > >
> > >> > > > > /martin
> > >> > > > >
> > >> > > > > _______________________________= ________________
> > >> > > > > netmod mailing list
> > >> > > > > n= etmod@ietf.org<mailto:netmod@ietf.org>
> > >> > > > > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ie
> > >> > > > > tf
> > >> > > > >
> > .org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAk= Yuh63rsuhr6Scbfh0U
> > >> > > > > jBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaG= TvjIS
> > >> > > > >
> > laJdcZo&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDE= N97c&s=3DRVJcg
> > >> > > > > 5pzHW-zi1OboCL4SX2huW9euHiVRSCo= r9n_APQ&e=3D
> > >> > > > > .
> > >> > > > >
> > >> > > > ____________________________________= ___________
> > >> > > > netmod mailing list
> > >> > > > netmod= @ietf.org<mailto:netmod@ietf= .org>
> > >> > > > htt= ps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf<= br> > > >> > > > .o
> > >> > > >
> > rg_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYu= h63rsuhr6Scbfh0UjBXe
> > >> > > > MK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaG= TvjISlaJdcZ
> > >> > > >
> > o&m=3D7s6VdzzH9Ol3BOCbVLBarBrQ5fD0vTt8k_I2KDEN97c&a= mp;s=3DRVJcg5pzHW-zi
> > >> > > > 1OboCL4SX2huW9euHiVRSCor9n_APQ&e= =3D
> > >> --
> > >> Ladislav Lhotka
> > >> Head, CZ.NIC Labs
> > >> PGP Key ID: 0xB8F92B08A9F76C67
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org&l= t;mailto:netmod@ietf.org> > > >> https://urld= efense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m
> > >> ai
> > >> lman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh6= 3rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTX
> > >>
> >
> cWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&a= mp;m=3D7s6VdzzH9Ol3
> > BO
> > >> CbVLBarBrQ5fD0vTt8k_I2KDEN97c&s=3DRVJcg5pzHW- > > zi1OboCL4SX2huW9euHiVRSCor
> > >> 9n_APQ&e=3D
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org&l= t;mailto:netmod@ietf.org> > > >> https://urld= efense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m
> > >> ailman_listinfo_netmod&d=3DDwIFAg&c=3D= HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3v
> > >>
> oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdc= Zo&m=3DDM1jsw
> nM
> > >> 48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0= x_B-
> Xez7tD9hLX71D5vlcHdZohn
> > >> TkiMVIKJhAHivk&e=3D<htt= ps://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > >> 3A__urldefense.proof&d=3DDwIFAg&c=3DHAkYuh6= 3rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >>
> TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo= &m=3DDM1jswnM
> 48
> > >> GwdI4tez-
> Jtf2ua2jvtLZVKfiwkbwbIrU&s=3DbzLaLoBCJ88laveupLqapYN4btjEBBv
> > >> NENNy09Tsooc&e=3D
> > >> point.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DD
> > >> wMFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9E
> > >> PoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d-
> > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6
> > >> W3qt4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7= LuWTPw&e=3D>
> > >
> > > --
> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cam= pus Ring 1 | 28759 Bremen | Germany
> > > Fax:=C2=A0 =C2=A0+49 421 200 3103
> <https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__www.jacobs-
> 2D&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS= laJdcZo&m=3DD
> M1jswnM48GwdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3D5RD96- > TjymU1ZhmfZFtWEm4abkkdaxqrkCKzuv4PZRQ&e=3D
> > university.de/<https://urldefen= se.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.jacobs-
> > 2Duniversity.de_&d=3DDwMFaQ&c=3DHAkYuh63rsuhr6Scbfh0= UjBXeMK-
> >
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS= laJdcZo&m=3DO
> > 7d-
> >
> b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt4&s=3Dzh7qEPSmwvia= SqZBqG1Gc
> > qItXwI9pwyqIFVW6xC8rK8&e=3D>>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org<ma= ilto:netmod@ietf.org>
> > > https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma
> > > ilman_listinfo_netmod&d=3DDwIFAg&c=3DHAkYu= h63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >
> TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo= &m=3DDM1jswnM
> 48G
> > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > Xez7tD9hLX71D5vlcHdZohnTkiM
> > > VIKJhAHivk&e=3D<https:= //urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__u
> > > rldefense.proofp&d=3DDwIFAg&c=3DHAkYuh63rsuhr6S= cbfh0UjBXeMK-
> ndb3voDTXcWz
> > >
> oCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&= m=3DDM1jswnM48Gwd
> I4t
> > > ez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Did5kdXDEb4afnobWT-<= br> > fUq3YfsIkHooz5RtXYso
> > > QRt1o&e=3D
> > > oint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwM
> > > FaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoO
> > > H7Yhqn2gsBYaGTvjISlaJdcZo&m=3DO7d-
> > b9gyPvsasJo1ueKk3doDH7f5S5WQLo8_W6W3qt
> > > 4&s=3D5LHhbfQZeoqYlC40T3mm-AEz4rSsyRWYjqTK7LuWTPw&a= mp;e=3D>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma
> > > ilman_listinfo_netmod&d=3DDwIFAg&c=3DHAkYu= h63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > >
> TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo= &m=3DDM1jswnM
> 48G
> > > wdI4tez-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B- > Xez7tD9hLX71D5vlcHdZohnTkiM
> > > VIKJhAHivk&e=3D
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense= .proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
> > man_listinfo_netmod&d=3DDwIFAg&c=3DHAkYuh63rsuhr6Scb= fh0UjBXeMK-
> ndb3voDTXcW
> >
> zoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&= ;m=3DDM1jswnM48Gw
> dI4te
> > z-Jtf2ua2jvtLZVKfiwkbwbIrU&s=3Dg0x_B-
> Xez7tD9hLX71D5vlcHdZohnTkiMVIKJhAHi
> > vk&e=3D



--000000000000b87c250577ea9b23-- From nobody Wed Oct 10 19:23:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995CA130E90 for ; Wed, 10 Oct 2018 19:23:42 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 DpMDx1fiMR7y for ; Wed, 10 Oct 2018 19:23:39 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 45450130E83 for ; Wed, 10 Oct 2018 19:23:39 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id z144-v6so5472665lff.13 for ; Wed, 10 Oct 2018 19:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d8jVqr2xV+AavpVVpww6gYG4oLyCYfgyfDjSHH49gtk=; b=hqA2inJUI3vNqOVdo9eJajrR8OQDs/p3ZalG/f2/raSiHsVgSAbD96gGv4deq+biy4 UKOBZH1S2EYx8IhjkH7wnBA7EgX6Poo5qeRipiYKudJlQhnSYnXvKBid7hnP8jejfgfp UfuOQQB2FVVXYVeNDDCfZh64DuveYJjvRFNMJZt69L2zSMlyfzLPHm2NF8eQcNr+YZvX /O06KhvTCEhAtl8p50O4cKRwA4ZqtHc3ej/61mMT0pDDcHJ7zy+dkkkzb86ctcdm+bvg wCOEVCzE+U0uuJDzuKX+4XhAUSX3fAvwPm586j+dOo0VFFl9V+KX6fZJkYpI3k8X8LPu 4sbg== 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=d8jVqr2xV+AavpVVpww6gYG4oLyCYfgyfDjSHH49gtk=; b=A/sEvMDqRxCTB/d5D4g0jGj/qSZCWp2FyIcFWzhVCQIMvg4URvN1MZbQfUUkEvVTZS PluQPWq+hCegjWpJpLhTjDX1l8YEDtsD/5llBZmpnqGd5AI5Qblt/6cWreIA3vgVnFaC r2h/VCBlLfCHCcteXc34Nd7GfJD9zb388nrYWMTWLA4ceTbjUf3H1GiMpW7h05u7RDwg ZWQnDXkmrIiepxRJ59Hw9Vci4tzMjQddfNDwK1ECT6Gv4zatQJvYhVy5+LG2FU5/wL4i a8eJh1OQzC9e7kTZJb1FFQs7ONvFcuYCbdN7CzxrviUTFcvHDhSVBwApbUv03+D7j7bJ cdfg== X-Gm-Message-State: ABuFfoj6InN026puhTLumpbrWkS8BhQX/sbJ58/GanhZuZvGV8AUD8PP yH8pHnTiOWoVZg1D4G/pM8SA8bLPxIP+DoVQ7Tee1g== X-Google-Smtp-Source: ACcGV61a17vgYQhF4TzuYsFu/aA0K4R5NF6Ylj3FB50AopqE3pWDqnM8LY/TI032wClBCYvo7frWpqZPIpue2LrNqJw= X-Received: by 2002:a19:1643:: with SMTP id m64-v6mr2253825lfi.82.1539224617287; Wed, 10 Oct 2018 19:23:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Wed, 10 Oct 2018 19:23:36 -0700 (PDT) In-Reply-To: <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> From: Andy Bierman Date: Wed, 10 Oct 2018 19:23:36 -0700 Message-ID: To: "Reshad Rahman (rrahman)" Cc: Martin Bjorklund , "lhotka@nic.cz" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008b15dc0577eaa899" Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 02:23:50 -0000 --0000000000008b15dc0577eaa899 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) wrote: > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > { > > > "ietf-subscribed-notifications:input": { > > > "stream": "NETCONF", > > > "stream-xpath-filter": "/ds:foo/", > > > "dscp": "10" > > > } > > > } > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > string. > > > How are prefixes declared when JSON is used? > > > > > > The leaf "stream-xpath-filter" says: > > > > > > o The set of namespace declarations are those in > scope on > > > the 'stream-xpath-filter' leaf element. > > > > > > (I think I provided that text...) > > > > > > This assumes that the encoding is XML, or at leas that the encoding > > > can somehow transfer namespace declarations. > > > > It can't. There are two options: > > > > 1. have different representations of this value in XML and JSON, > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > 2. use a module name rather than a prefix in XML, too. > > > > I would suggest #2. > But that means making non-backwards compatible change to the XML > representation? > Not really. It means NETMOD WG would be creating its own special variant of XPath. > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > o The set of namespace declarations has one member for each > YANG module supported by the server. This member maps > from the YANG module name to the YANG module namespace. > > This means that in the XPath expression, the module name > serves as the prefix. > > .... and then also give an example of this. > > This is probably what we need to do in all places where yang:xpath1.0 > is used, going forward. Maybe even define a new type > yang:xpath1.0-2 (name?) with the set of namespace declarations > built-in. > We should avoid making off-the-shelf implementations of standards like XPath unusable. At the very least this should be only available if the server supports it (with a capability URI) > So we need an update to RFC7951? > > Regards, > Reshad. > > Andy > > /martin > > > > > > > > > Lada > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000008b15dc0577eaa899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <rrahman@cisc= o.com> wrote:
On 2018-10-10= , 9:59 AM, "netmod on behalf of Martin Bjorklund" <netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:

=C2=A0 =C2=A0 Ladislav Lhotka <lhotka@n= ic.cz> wrote:
=C2=A0 =C2=A0 > Martin Bjorklund <m= bj@tail-f.com> writes:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > Hi,
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > While reviewing restconf-notif, I saw this example:=
=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-subscribed-notifications:input": {
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "stream"= ;: "NETCONF",
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "stream-xpat= h-filter": "/ds:foo/",
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "dscp":= "10"
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Note the "stream-xpath-filter".=C2=A0 It = has a prefix in the XPath string.
=C2=A0 =C2=A0 > > How are prefixes declared when JSON is used?
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > The leaf "stream-xpath-filter" says:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0o=C2=A0 The set of namespace declarations are those in scope on
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the 'stream-xpath-filter' leaf element.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > (I think I provided that text...)
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > This assumes that the encoding is XML, or at leas t= hat the encoding
=C2=A0 =C2=A0 > > can somehow transfer namespace declarations.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It can't. There are two options:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > 1. have different representations of this value in XML a= nd JSON,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 analogically to instance indentifiers (sec.= 6.11 in RFC 7951).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > 2. use a module name rather than a prefix in XML, too. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I would suggest #2.
<RR> But that means making non-backwards compatible change to the XML= representation?

Not really. It means N= ETMOD WG would be creating its own special variant of XPath.

=

=C2=A0 =C2=A0 Hmm, so you mean change the leaf "stream-xpath-filter&qu= ot; to say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of namespac= e declarations has one member for each
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG module support= ed by the server.=C2=A0 This member maps
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from the YANG modul= e name to the YANG module namespace.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This means that in = the XPath expression, the module name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 serves as the prefi= x.

=C2=A0 =C2=A0 .... and then also give an example of this.

=C2=A0 =C2=A0 This is probably what we need to do in all places where yang:= xpath1.0
=C2=A0 =C2=A0 is used, going forward.=C2=A0 Maybe even define a new type =C2=A0 =C2=A0 yang:xpath1.0-2 (name?) with the set of namespace declaration= s
=C2=A0 =C2=A0 built-in.


= We should avoid making off-the-shelf implementations of standards like XPat= h unusable.
At the very least this should be only available if th= e server supports it (with a capability URI)

=C2= =A0
<RR> So we need an update to RFC7951?

Regards,
Reshad.



Andy
=C2=A0

=C2=A0 =C2=A0 /martin





=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lada
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > How is this supposed to work with JSON?
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > /martin
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > ______________________________________________= _
=C2=A0 =C2=A0 > > netmod mailing list
=C2=A0 =C2=A0 > > netmod@ietf.org<= /a>
=C2=A0 =C2=A0 > > https://www.ietf.org/mailman/listinfo/netmod
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > Ladislav Lhotka
=C2=A0 =C2=A0 > Head, CZ.NIC Labs
=C2=A0 =C2=A0 > PGP Key ID: 0xB8F92B08A9F76C67
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 netmod mailing list
=C2=A0 =C2=A0 netmod@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/netmod


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

--0000000000008b15dc0577eaa899-- From nobody Wed Oct 10 19:46:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14152130DFB for ; Wed, 10 Oct 2018 19:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 2kZ5xsO4QMTn for ; Wed, 10 Oct 2018 19:46:22 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 113AC130DF2 for ; Wed, 10 Oct 2018 19:46:22 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3D1C74723D4CF; Thu, 11 Oct 2018 03:46:17 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 11 Oct 2018 03:46:18 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.200]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0399.000; Thu, 11 Oct 2018 10:46:16 +0800 From: Qin Wu To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] xpath expressions in JSON Thread-Index: AQHUYIq7R7zgxnWZykmBF8fDuM0qB6UX5bGAgAFx2HA= Date: Thu, 11 Oct 2018 02:46:14 +0000 Message-ID: References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> In-Reply-To: <8736tevut6.fsf@nic.cz> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.244] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 02:46:24 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIExhZGlzbGF2IExob3RrYQ0Kt6LLzcqxvOQ6IDIwMTjE6jEw1MIxMMjV IDIwOjQxDQrK1bz+yMs6IE1hcnRpbiBCam9ya2x1bmQ7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jog UmU6IFtuZXRtb2RdIHhwYXRoIGV4cHJlc3Npb25zIGluIEpTT04NCg0KTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCg0KPiBIaSwNCj4NCj4gV2hpbGUgcmV2aWV3aW5n IHJlc3Rjb25mLW5vdGlmLCBJIHNhdyB0aGlzIGV4YW1wbGU6DQo+DQo+ICAgIHsNCj4gICAgICAg ImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOmlucHV0Ijogew0KPiAgICAgICAgICAic3Ry ZWFtIjogIk5FVENPTkYiLA0KPiAgICAgICAgICAic3RyZWFtLXhwYXRoLWZpbHRlciI6ICIvZHM6 Zm9vLyIsDQo+ICAgICAgICAgICJkc2NwIjogIjEwIg0KPiAgICAgICB9DQo+ICAgIH0NCj4NCj4g Tm90ZSB0aGUgInN0cmVhbS14cGF0aC1maWx0ZXIiLiAgSXQgaGFzIGEgcHJlZml4IGluIHRoZSBY UGF0aCBzdHJpbmcuDQo+IEhvdyBhcmUgcHJlZml4ZXMgZGVjbGFyZWQgd2hlbiBKU09OIGlzIHVz ZWQ/DQo+DQo+IFRoZSBsZWFmICJzdHJlYW0teHBhdGgtZmlsdGVyIiBzYXlzOg0KPg0KPiAgICAg ICAgICAgICAgIG8gIFRoZSBzZXQgb2YgbmFtZXNwYWNlIGRlY2xhcmF0aW9ucyBhcmUgdGhvc2Ug aW4gc2NvcGUgb24NCj4gICAgICAgICAgICAgICAgICB0aGUgJ3N0cmVhbS14cGF0aC1maWx0ZXIn IGxlYWYgZWxlbWVudC4NCj4NCj4gKEkgdGhpbmsgSSBwcm92aWRlZCB0aGF0IHRleHQuLi4pDQo+ DQo+IFRoaXMgYXNzdW1lcyB0aGF0IHRoZSBlbmNvZGluZyBpcyBYTUwsIG9yIGF0IGxlYXMgdGhh dCB0aGUgZW5jb2RpbmcgDQo+IGNhbiBzb21laG93IHRyYW5zZmVyIG5hbWVzcGFjZSBkZWNsYXJh dGlvbnMuDQoNCkl0IGNhbid0LiBUaGVyZSBhcmUgdHdvIG9wdGlvbnM6DQoNCjEuIGhhdmUgZGlm ZmVyZW50IHJlcHJlc2VudGF0aW9ucyBvZiB0aGlzIHZhbHVlIGluIFhNTCBhbmQgSlNPTiwNCiAg IGFuYWxvZ2ljYWxseSB0byBpbnN0YW5jZSBpbmRlbnRpZmllcnMgKHNlYy4gNi4xMSBpbiBSRkMg Nzk1MSkuDQoNCltRaW5dOiBUaGlzIGhhcyBiZWVuIGJyb3VnaHQgdXAgYmVmb3JlOg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMTU1MDEu aHRtbA0KDQoyLiB1c2UgYSBtb2R1bGUgbmFtZSByYXRoZXIgdGhhbiBhIHByZWZpeCBpbiBYTUws IHRvby4NCg0KSSB3b3VsZCBzdWdnZXN0ICMyLg0KDQpMYWRhDQoNCj4NCj4gSG93IGlzIHRoaXMg c3VwcG9zZWQgdG8gd29yayB3aXRoIEpTT04/DQo+DQo+DQo+IC9tYXJ0aW4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg0KLS0NCkxhZGlzbGF2IExob3RrYQ0KSGVhZCwgQ1ouTklDIExh YnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9k QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Oct 10 20:25:01 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 138C1130E09; Wed, 10 Oct 2018 20:24:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-netmod-schema-mount@ietf.org, Joel Jaeggli , Lou Berger , Kent Watsen , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153922828107.5944.1683916629739613438.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2018 20:24:41 -0700 Archived-At: Subject: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 03:24:41 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-netmod-schema-mount-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.3. I think it would be nice to have some examples to illustrate the differences between inline and shared-schema and some guidance to pick between the two. From nobody Wed Oct 10 22:58:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D86130E2B for ; Wed, 10 Oct 2018 22:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 k5aSkEotUAuC for ; Wed, 10 Oct 2018 22:58:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9133E130E04 for ; Wed, 10 Oct 2018 22:58:49 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 6CF0A600DA; Thu, 11 Oct 2018 07:58:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539237526; bh=rGQnaj6LANmSenacISTViGsFOTcL+kfcBy+FpPedVOQ=; h=From:To:Date; b=G6EgTCCoHK5KFxFkVBGYbaneYim1oFVeefqzYZJMy892fx+TzwsY46dN8AeGmzbm2 p7JXbeaTswKvhb1NfxCNpRyYcw85bJwDYuua6uCvfVh7TDBnxU0/b/jquM5wCI97Uz YWNHTa+lrq/tc2RuPXRFEImAOnNI8vwI9i/9tQRA= Message-ID: <0eddc4f5aa4a719d4fec39041696e05f00a7829d.camel@nic.cz> From: Ladislav Lhotka To: Michael Rehder , Juergen Schoenwaelder Cc: Robert Wilton , "netmod@ietf.org" , "Walker, Jason (Jason_Walker2@comcast.com)" Date: Thu, 11 Oct 2018 07:58:46 +0200 In-Reply-To: References: <87zhvlvpts.fsf@nic.cz> <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 05:58:54 -0000 On Wed, 2018-10-10 at 18:44 +0000, Michael Rehder wrote: > Sure. > > I think the RFC is unclear since it seems that the semantics are consistent in > the back-end checks. > One can read the RFC and not notice by its absence that the when clause > doesn't require anything to be present. > > The "when" statement makes its parent data definition statement > conditional. > Should be > The "when" statement makes its parent data definition statement > conditional and optional. Data nodes in YANG are optional by default and become mandatory only in certain cases (in RFC 6020 these cases were specified in section 3.1). In contrast, RELAX NG patterns are mandatory by default and is used to make them optional. Lada > > I think there should be a more definite statement about this overriding any > mandatory status of the parent data definition statement. > Like > "Any mandatory status of the parent data definition statement (mandatory > statement, min-element statement etc.) is overridden by this statement and > made non-mandatory." > > That would have made the side-effect of "when" on other declarations clearer. > > Thanks > mike > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, October 10, 2018 2:25 PM > > To: Michael Rehder > > Cc: Robert Wilton ; Ladislav Lhotka ; > > netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com) > > > > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't > > ensure presence of the mandatory object > > > > Michael, > > > > what matters here is what the YANG specification (RFC 7950) says. Is there a > > reason to believe the IPAddresses list in your example can be absent or have > > no > > elements based on what RFC 7950 says? Or do we talk about a shortcoming of > > RFC 6110? > > > > /js > > > > On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote: > > > If the list has a "when" clause the RNG file actually produces a > > > "OneOrMore" > > which has a choice of or the list so it actually doesn't enforce the > > presence at least one row of the list (unless I'm mistaken in my reading). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A leaf/container would be a simpler example but would result in the same > > lack of enforcement of the mandatory status of an element with a "when" > > clause. > > > This RNG seems consistent with the Schematron rules that "when" makes > > something optional. > > > > > > I think a workaround would be choice with mandatory true and a when clause > > on the cases. This would ensure that at least one case is present since the > > mandatory clause implements a Schematron existence constraint. > > > Thanks > > > Mike > > > > -----Original Message----- > > > > From: Robert Wilton [mailto:rwilton@cisco.com] > > > > Sent: Wednesday, October 10, 2018 11:33 AM > > > > To: Michael Rehder ; Ladislav Lhotka > > > > ; netmod@ietf.org > > > > Cc: Walker, Jason (Jason_Walker2@comcast.com) > > > > > > > > Subject: Re: [netmod] WHEN statement within mandatory objects > > > > doesn't ensure presence of the mandatory object > > > > > > > > Hi Mike, > > > > > > > > I think that the YANG below already enforces what you want, or > > > > otherwise I don't follow your issue. > > > > > > > > The YANG below is valid in two cases: > > > > > > > > (1) AssignmentMechanism = DHCP, and IPAddresses is not present in > > > > the config (due to the when statement). > > > > (2) AssignmentMechanism = Static, IPAddresses exists and has at > > > > least one element (due to min-elements 1). > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 10/10/2018 16:23, Michael Rehder wrote: > > > > > Container "foo" would be mandatory if not for the "when" child > > > > > element. > > > > > With the "when" child element, the logic becomes "inverted" and > > > > > the > > > > constraint is a negative one of "disallowed under certain condition". > > > > > The UC is for enforcement in REST API payloads. > > > > > For a practical example: > > > > > > > > > > leaf AssignmentMechanism { > > > > > type enumeration { > > > > > enum "DHCP"; > > > > > enum "Static"; > > > > > } > > > > > mandatory true; > > > > > description "The address assignment mechanism."; > > > > > } > > > > > list IPAddresses { > > > > > when "../AssignmentMechanism = 'Static'"; > > > > > key Address; > > > > > min-elements 1; > > > > > > > > > > leaf Address { > > > > > type capit:IPv4Address; > > > > > description "An ipv4 address."; > > > > > } > > > > > } > > > > > > > > > > There is no way in the IPAddresses list to enforce that there is > > > > > at least one IP > > > > Address when the assignment method is "Static". > > > > > One could put a "must" on "AssignmentMechanism" to ensure at least > > > > > one > > > > element of the IPAddresses list when "Static", but I don't see this > > > > as a good schema design, to have the controlling attribute check > > > > controlled > > attributes. > > > > > I appreciate that this semantic can't be changed in YANG at this > > > > > point. > > > > > Could the "when" statement have a modifying child element to state > > > > > that the > > > > mandatory status of the element is to be enforced? > > > > > Like > > > > > container foo { > > > > > when "condition" { > > > > > enforce-mandatory-status; > > > > > } > > > > > > > > > > There is already back-end for existential checks for mandatory > > > > > choice so this > > > > seems reasonably consistent to me. > > > > > I appreciate there are existing issues for "when" but I don't see > > > > > why this > > > > would make things any worse. > > > > > In fact by promoting a better dependency "direction" between > > > > > schema > > > > elements, think it could simplify things (so I naively think :) ). > > > > > Thanks > > > > > Mike > > > > > > -----Original Message----- > > > > > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > > > > > Sent: Wednesday, October 10, 2018 10:28 AM > > > > > > To: Michael Rehder ; netmod@ietf.org > > > > > > Subject: Re: [netmod] WHEN statement within mandatory objects > > > > > > doesn't ensure presence of the mandatory object > > > > > > > > > > > > Michael Rehder writes: > > > > > > > > > > > > > I have a question about “when†and mandatory objects. > > > > > > > > > > > > > > It seems to me that the implemented semantics of “when†are > > > > > > > really > > > > > > “optional whenâ€, in that the enclosing object can be absent even > > > > > > though it is mandatory and the “when†clause holds true. > > > > > > > The RFC could be clearer about this. > > > > > > > > > > > > > > Example > > > > > > > > > > > > > > leaf color { > > > > > > > enumeration { > > > > > > > enum “blueâ€; > > > > > > > enum “blackâ€; > > > > > > > } > > > > > > > mandatory true; > > > > > > > } > > > > > > > container foo { > > > > > > > when ../color = ‘blue’; > > > > > > > etc. > > > > > > > } > > > > > > > > > > > > > > “foo†is optional due to the presence of the “when†statement > > > > > > > even though the object is mandatory (same is true for mandatory > > > > > > > leaf, > > > > > > > min-elements=1 list etc.). > > > > > > Maybe you intended to have, e.g., a "mandatory true" leaf inside > > > > > > "container foo"? > > > > > > > > > > > > > This is considered valid XML for the above > > > > > > > blue > > > > > > Yes, it is, under current YANG rules, no matter what "etc." > > > > > > stands for. Note that evaluation of the XPath expression in this > > > > > > case (with "foo" missing) requires the peculiar procedure of sec. > > > > > > 7.21.5 > > in RFC 7950. > > > > > > > In my view this makes conditionally variant schemas “loose†in > > > > > > > their enforcement (some scenarios can use choice but it doesn’t > > > > > > > cover everything). > > > > > > > > > > > > > > I think that mandatory should be respected for the enclosing > > > > > > > objects of a “when†statement. That is, a mandatory object must > > > > > > > be present when its “when†clause holds true and a Schematron > > > > > > > statement should enforce that. > > > > > > In fact, this is one case where the DSDL mapping (RFC 6110) > > > > > > deviates from YANG 1.0. Nodes that mandatory aren't enclosed in > > > > > > the RELAX NG pattern, and are then required no matter > > > > > > what > > any "when" > > > > > > statements say (because RELAX NG validation comes before > > Schematron). > > > > > > > What is the rationale behind the current YANG rules behavior, > > > > > > > that the “when†Schematron mapping doesn’t check for presence of > > > > > > > the enclosing mandatory object? > > > > > > FWIW, I have been repeatedly protesting against this behaviour > > > > > > but without much luck. See for example > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg14012.htm > > > > > > l > > > > > > > > > > > > As a result, "when" is the trickiest feature in YANG by far. > > > > > > > > > > > > Lada > > > > > > > > > > > > > thanks > > > > > > > Mike Rehder > > > > > > -- > > > > > > Ladislav Lhotka > > > > > > Head, CZ.NIC Labs > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > “Amdocs’ email platform is based on a third-party, worldwide, > > > > > cloud-based > > > > system. Any emails sent to Amdocs will be processed and stored using > > > > such system and are accessible by third party providers of such > > > > system on a limited basis. Your sending of emails to Amdocs > > > > evidences your consent to the use of such system and such processing, > > storing and accessâ€. > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based > > system. Any emails sent to Amdocs will be processed and stored using such > > system and are accessible by third party providers of such system on a > > limited > > basis. Your sending of emails to Amdocs evidences your consent to the use of > > such system and such processing, storing and accessâ€. > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based > system. Any emails sent to Amdocs will be processed and stored using such > system and are accessible by third party providers of such system on a limited > basis. Your sending of emails to Amdocs evidences your consent to the use of > such system and such processing, storing and accessâ€. -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 23:08:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83A21292F1 for ; Wed, 10 Oct 2018 23:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 v9vd6vyLcTay for ; Wed, 10 Oct 2018 23:08:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 3E23B130E04 for ; Wed, 10 Oct 2018 23:08:46 -0700 (PDT) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id C2C2660134; Thu, 11 Oct 2018 08:08:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539238124; bh=nEpzZnb9J8rh5eSrYmt/t3+1YUsnqXtLWCronqMKm3w=; h=From:To:Date; b=W7hd2TJXmiteL6eEVvJMWjrcVeN+3opfNOPfrMvJuK9zNQ6X2VuFT4m1XxjofNkaD WxdPyjqplwNafGod06TIq8QEUlyBOf+xFaiywP0jqjvcb4MOlCxj//hnzNxMKQi774 Am2XFxTZ6Q0t70I921ZNz/VWqE+PIrzD/2Un51bU= Message-ID: <74ab4ac248f1933ba7a3a095eb7bb1865325588e.camel@nic.cz> From: Ladislav Lhotka To: Andy Bierman , "Reshad Rahman (rrahman)" Cc: Martin Bjorklund , "netmod@ietf.org" Date: Thu, 11 Oct 2018 08:08:44 +0200 In-Reply-To: References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:08:49 -0000 On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote: > > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) > wrote: > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Hi, > > > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > > > { > > > > "ietf-subscribed-notifications:input": { > > > > "stream": "NETCONF", > > > > "stream-xpath-filter": "/ds:foo/", > > > > "dscp": "10" > > > > } > > > > } > > > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > > string. > > > > How are prefixes declared when JSON is used? > > > > > > > > The leaf "stream-xpath-filter" says: > > > > > > > > o The set of namespace declarations are those in > > scope on > > > > the 'stream-xpath-filter' leaf element. > > > > > > > > (I think I provided that text...) > > > > > > > > This assumes that the encoding is XML, or at leas that the encoding > > > > can somehow transfer namespace declarations. > > > > > > It can't. There are two options: > > > > > > 1. have different representations of this value in XML and JSON, > > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > > > 2. use a module name rather than a prefix in XML, too. > > > > > > I would suggest #2. > > But that means making non-backwards compatible change to the XML > > representation? > > Not really. It means NETMOD WG would be creating its own special variant of > XPath. The thing is that XPath is "XML Path Language", so using it outside XML is problematic. Lada > > > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > o The set of namespace declarations has one member for each > > YANG module supported by the server. This member maps > > from the YANG module name to the YANG module namespace. > > > > This means that in the XPath expression, the module name > > serves as the prefix. > > > > .... and then also give an example of this. > > > > This is probably what we need to do in all places where yang:xpath1.0 > > is used, going forward. Maybe even define a new type > > yang:xpath1.0-2 (name?) with the set of namespace declarations > > built-in. > > > We should avoid making off-the-shelf implementations of standards like XPath > unusable. > At the very least this should be only available if the server supports it > (with a capability URI) > > > > So we need an update to RFC7951? > > > > Regards, > > Reshad. > > > > > Andy > > > /martin > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Oct 10 23:39:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94B130E39 for ; Wed, 10 Oct 2018 23:39:09 -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, 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 u43j7fEarZYW for ; Wed, 10 Oct 2018 23:39:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEAE6130E2E for ; Wed, 10 Oct 2018 23:39:07 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 286041AE0310; Thu, 11 Oct 2018 08:39:05 +0200 (CEST) Date: Thu, 11 Oct 2018 08:39:04 +0200 (CEST) Message-Id: <20181011.083904.763170181197608903.mbj@tail-f.com> To: andy@yumaworks.com Cc: rrahman@cisco.com, lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:39:10 -0000 Andy Bierman wrote: > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) > wrote: > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Hi, > > > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > > > { > > > > "ietf-subscribed-notifications:input": { > > > > "stream": "NETCONF", > > > > "stream-xpath-filter": "/ds:foo/", > > > > "dscp": "10" > > > > } > > > > } > > > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > > string. > > > > How are prefixes declared when JSON is used? > > > > > > > > The leaf "stream-xpath-filter" says: > > > > > > > > o The set of namespace declarations are those in > > scope on > > > > the 'stream-xpath-filter' leaf element. > > > > > > > > (I think I provided that text...) > > > > > > > > This assumes that the encoding is XML, or at leas that the encoding > > > > can somehow transfer namespace declarations. > > > > > > It can't. There are two options: > > > > > > 1. have different representations of this value in XML and JSON, > > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > > > 2. use a module name rather than a prefix in XML, too. > > > > > > I would suggest #2. > > But that means making non-backwards compatible change to the XML > > representation? > > > > Not really. It means NETMOD WG would be creating its own special variant of > XPath. Not at all. What I propose is perfectly fine, legal XPath 1.0. XPath 1.0 says that an XPath expression is evaluated in a context. One item in the context is a set of mappings from to , where is used to lookup prefixes used in the XPath expression, e.g. in "/foo:interfaces" "foo" is the prefix. It is perfectly fine to say that the prefix mapping set is this: "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" and use that to evaluate the expression /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 /martin > > > > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > o The set of namespace declarations has one member for each > > YANG module supported by the server. This member maps > > from the YANG module name to the YANG module namespace. > > > > This means that in the XPath expression, the module name > > serves as the prefix. > > > > .... and then also give an example of this. > > > > This is probably what we need to do in all places where yang:xpath1.0 > > is used, going forward. Maybe even define a new type > > yang:xpath1.0-2 (name?) with the set of namespace declarations > > built-in. > > > > > We should avoid making off-the-shelf implementations of standards like > XPath unusable. > At the very least this should be only available if the server supports it > (with a capability URI) > > > > > So we need an update to RFC7951? > > > > Regards, > > Reshad. > > > > > > Andy > > > > > > /martin > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Oct 10 23:42:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E200A130E3C for ; Wed, 10 Oct 2018 23:42:45 -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, 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 0WzID_1oCMeC for ; Wed, 10 Oct 2018 23:42:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A453F130E3B for ; Wed, 10 Oct 2018 23:42:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id AD4861AE0310; Thu, 11 Oct 2018 08:42:42 +0200 (CEST) Date: Thu, 11 Oct 2018 08:42:42 +0200 (CEST) Message-Id: <20181011.084242.2147348417024315805.mbj@tail-f.com> To: lhotka@nic.cz Cc: andy@yumaworks.com, rrahman@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <74ab4ac248f1933ba7a3a095eb7bb1865325588e.camel@nic.cz> References: <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <74ab4ac248f1933ba7a3a095eb7bb1865325588e.camel@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:42:46 -0000 Ladislav Lhotka wrote: > On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote: > > > > > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) > > wrote: > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund writes: > > > > > > > > > Hi, > > > > > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > > > > > { > > > > > "ietf-subscribed-notifications:input": { > > > > > "stream": "NETCONF", > > > > > "stream-xpath-filter": "/ds:foo/", > > > > > "dscp": "10" > > > > > } > > > > > } > > > > > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > > > string. > > > > > How are prefixes declared when JSON is used? > > > > > > > > > > The leaf "stream-xpath-filter" says: > > > > > > > > > > o The set of namespace declarations are those in > > > scope on > > > > > the 'stream-xpath-filter' leaf element. > > > > > > > > > > (I think I provided that text...) > > > > > > > > > > This assumes that the encoding is XML, or at leas that the encoding > > > > > can somehow transfer namespace declarations. > > > > > > > > It can't. There are two options: > > > > > > > > 1. have different representations of this value in XML and JSON, > > > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > > > > > 2. use a module name rather than a prefix in XML, too. > > > > > > > > I would suggest #2. > > > But that means making non-backwards compatible change to the XML > > > representation? > > > > Not really. It means NETMOD WG would be creating its own special variant of > > XPath. > > The thing is that XPath is "XML Path Language", so using it outside XML is > problematic. Not necessarily. Section 5 of the XPath 1.0 spec defins the "data model" where an XPath expression is applied. We could make a formal specification of how a YANG data tree maps to this data model (pretty straightforward...). I think experience from implementations over the last 8 years show that this in fact works quite well. /martin > > Lada > > > > > > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > > > o The set of namespace declarations has one member for each > > > YANG module supported by the server. This member maps > > > from the YANG module name to the YANG module namespace. > > > > > > This means that in the XPath expression, the module name > > > serves as the prefix. > > > > > > .... and then also give an example of this. > > > > > > This is probably what we need to do in all places where yang:xpath1.0 > > > is used, going forward. Maybe even define a new type > > > yang:xpath1.0-2 (name?) with the set of namespace declarations > > > built-in. > > > > > > We should avoid making off-the-shelf implementations of standards like XPath > > unusable. > > At the very least this should be only available if the server supports it > > (with a capability URI) > > > > > > > So we need an update to RFC7951? > > > > > > Regards, > > > Reshad. > > > > > > > > > Andy > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > From nobody Wed Oct 10 23:45:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371F5130E3E for ; Wed, 10 Oct 2018 23:45:01 -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, 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 emYuXfcdvQTd for ; Wed, 10 Oct 2018 23:44:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2445130E3C for ; Wed, 10 Oct 2018 23:44:57 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 07D0A1AE0310; Thu, 11 Oct 2018 08:44:56 +0200 (CEST) Date: Thu, 11 Oct 2018 08:44:56 +0200 (CEST) Message-Id: <20181011.084456.1638593949717812080.mbj@tail-f.com> To: bill.wu@huawei.com Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20181010.131610.1510095762179710072.mbj@tail-f.com> <8736tevut6.fsf@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:45:01 -0000 UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiAtLS0tLemCruS7tuWOn+S7ti0t LS0tDQo+IOWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd IOS7o+ihqCBMYWRpc2xhdiBMaG90a2ENCj4g5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDmnIgxMOaX pSAyMDo0MQ0KPiDmlLbku7bkuro6IE1hcnRpbiBCam9ya2x1bmQ7IG5ldG1vZEBpZXRmLm9yZw0K PiDkuLvpopg6IFJlOiBbbmV0bW9kXSB4cGF0aCBleHByZXNzaW9ucyBpbiBKU09ODQo+IA0KPiBN YXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0KPiANCj4gPiBIaSwNCj4g Pg0KPiA+IFdoaWxlIHJldmlld2luZyByZXN0Y29uZi1ub3RpZiwgSSBzYXcgdGhpcyBleGFtcGxl Og0KPiA+DQo+ID4gICAgew0KPiA+ICAgICAgICJpZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9u czppbnB1dCI6IHsNCj4gPiAgICAgICAgICAic3RyZWFtIjogIk5FVENPTkYiLA0KPiA+ICAgICAg ICAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjogIi9kczpmb28vIiwNCj4gPiAgICAgICAgICAiZHNj cCI6ICIxMCINCj4gPiAgICAgICB9DQo+ID4gICAgfQ0KPiA+DQo+ID4gTm90ZSB0aGUgInN0cmVh bS14cGF0aC1maWx0ZXIiLiAgSXQgaGFzIGEgcHJlZml4IGluIHRoZSBYUGF0aCBzdHJpbmcuDQo+ ID4gSG93IGFyZSBwcmVmaXhlcyBkZWNsYXJlZCB3aGVuIEpTT04gaXMgdXNlZD8NCj4gPg0KPiA+ IFRoZSBsZWFmICJzdHJlYW0teHBhdGgtZmlsdGVyIiBzYXlzOg0KPiA+DQo+ID4gICAgICAgICAg ICAgICBvICBUaGUgc2V0IG9mIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluIHNj b3BlIG9uDQo+ID4gICAgICAgICAgICAgICAgICB0aGUgJ3N0cmVhbS14cGF0aC1maWx0ZXInIGxl YWYgZWxlbWVudC4NCj4gPg0KPiA+IChJIHRoaW5rIEkgcHJvdmlkZWQgdGhhdCB0ZXh0Li4uKQ0K PiA+DQo+ID4gVGhpcyBhc3N1bWVzIHRoYXQgdGhlIGVuY29kaW5nIGlzIFhNTCwgb3IgYXQgbGVh cyB0aGF0IHRoZSBlbmNvZGluZyANCj4gPiBjYW4gc29tZWhvdyB0cmFuc2ZlciBuYW1lc3BhY2Ug ZGVjbGFyYXRpb25zLg0KPiANCj4gSXQgY2FuJ3QuIFRoZXJlIGFyZSB0d28gb3B0aW9uczoNCj4g DQo+IDEuIGhhdmUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucyBvZiB0aGlzIHZhbHVlIGluIFhN TCBhbmQgSlNPTiwNCj4gICAgYW5hbG9naWNhbGx5IHRvIGluc3RhbmNlIGluZGVudGlmaWVycyAo c2VjLiA2LjExIGluIFJGQyA3OTUxKS4NCj4gDQo+IFtRaW5dOiBUaGlzIGhhcyBiZWVuIGJyb3Vn aHQgdXAgYmVmb3JlOg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25l dGNvbmYvY3VycmVudC9tc2cxNTUwMS5odG1sDQoNClRoYXQgaXMgYSBzbGlnaHRseSBkaWZmZXJl bnQgcHJvYmxlbTsgaG93IHRvIHJlcHJlc2VudCBhbg0KKmluc3RhbmNlLWlkZW50aWZpZXIqIGlu IGEgUkVTVENPTkYgVVJMLg0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiAyLiB1c2UgYSBtb2R1bGUg bmFtZSByYXRoZXIgdGhhbiBhIHByZWZpeCBpbiBYTUwsIHRvby4NCj4gDQo+IEkgd291bGQgc3Vn Z2VzdCAjMi4NCj4gDQo+IExhZGENCj4gDQo+ID4NCj4gPiBIb3cgaXMgdGhpcyBzdXBwb3NlZCB0 byB3b3JrIHdpdGggSlNPTj8NCj4gPg0KPiA+DQo+ID4gL21hcnRpbg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tDQo+IExhZGlzbGF2IExob3RrYQ0KPiBI ZWFkLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Wed Oct 10 23:51:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEE2130E44 for ; Wed, 10 Oct 2018 23:51:34 -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, 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 Urx0Eh64mcXo for ; Wed, 10 Oct 2018 23:51:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E2130E3A for ; Wed, 10 Oct 2018 23:51:32 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F9531AE0310; Thu, 11 Oct 2018 08:51:31 +0200 (CEST) Date: Thu, 11 Oct 2018 08:51:31 +0200 (CEST) Message-Id: <20181011.085131.1823310178537216646.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si Cc: balazs.lengyel@ericsson.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20181008.145313.1979034555219874418.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Place to download Standard YANG Modules ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:51:34 -0000 Jernej Tuljak wrote: > Martin Bjorklund je 10/8/2018 ob 2:53 PM=A0napisal: > > Hi, > > > > > > Balazs Lengyel wrote: > >> Hello, > >> > >> What is the best way to download standard Yang Modules? I know the= > >> official answer is to download all the standards then extract the > >> modules, however this is a "bit" cumbersome. Is there any better w= ay? > >> We had a git earlier. How up to date is that? > > You can download them from IANA: > > > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xh= tml > > > > But there are two problems: > > > > 1) you have to download one at the time > > 2) some of them have lost all indentation > > (e.g. https://www.iana.org/assignments/yang-parameters/ietf-vo= ucher@2018-04-06.yang) > > > > > > [on 2), I have it on my list to talk to them] > > > = > If you do talk to them, also mention that > "ietf-network-topology-state@2018-02-26.yang" in their list is > actually just "ietf-network-topology@2018-02-26.yang" renamed, and > that "ietf-voucher@2018-04-06.yang" does not have the same revision a= s > the module that is part of RFC8366 (2018-05-09). Done, and they have now fixed all these issues. > Also, in at least two > instances, I managed to somehow download a blank module file, which > then magically downloaded properly after a retry. > = > Benoit went through the trouble of gathering modules from different > sources and his blog entry includes standard modules [1]. I dare say > that this blog entry is a much more reliable source compared to the > IANA site. The IANA site is getting better. The new process is that the RFC editor sends the YANG module to IANA as it is before it is put into the text format in the RFC, i.e., before indentation and page breaks and all that. I just which there was a one-click way (or better some repo) to get all files. /martin > [1] - https://www.claise.be/2018/06/ietf-yang-modules-statistiques/ > = > > Or you can get them from some 3rd party place like yang-catalog, or= > > pyang. > > > = > Pyang git repo has the files without revisions in their name, which i= s > somewhat awkward. > = > Jernej > = > > > > /martin > > > > > >> It would be wonderful if this could be described in the Netmod WG > >> wiki. > >> > >> (And sorry, no but I am not volunteering :-(=A0=A0 ) > >> > >> regards Balazs > >> > >> -- = > >> Balazs Lengyel Ericsson Hungary Ltd. > >> Senior Specialist > >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Thu Oct 11 00:18:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335DA130E53; Thu, 11 Oct 2018 00:18:24 -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, 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 C8uvmuryPJmv; Thu, 11 Oct 2018 00:18:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 836DA130E45; Thu, 11 Oct 2018 00:18:21 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 62C6C1AE0310; Thu, 11 Oct 2018 09:18:18 +0200 (CEST) Date: Thu, 11 Oct 2018 09:18:17 +0200 (CEST) Message-Id: <20181011.091817.1727547509052700274.mbj@tail-f.com> To: ekr@rtfm.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net From: Martin Bjorklund In-Reply-To: References: <20181010.153831.1958991667250114039.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 07:18:27 -0000 Eric Rescorla wrote: > I'm sorry but I don't understand this. > > Does the externally visible behavior of any mounted module depend in any > way on these XPATH references Yes, but note that these XPath expressions ("parent-reference") are read-only (config false in the YANG model). Thus they are set by the implementation, and used to inform the operator about the environment in which other XPath expressions are evaluated. /martin > > -Ekr > > > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund wrote: > > > Eric Rescorla wrote: > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund wrote: > > > > > > > Hi, > > > > > > > > Eric Rescorla wrote: > > > > > Eric Rescorla has entered the following ballot position for > > > > > draft-ietf-netmod-schema-mount-11: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > > email addresses included in the To and CC lines. (Feel free to cut > > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Rich version of this review at: > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506 > > > > > > > > > > > > > > > > > > > > DETAIL > > > > > S 4. > > > > > > > > > > > > It is worth emphasizing that the nodes specified in > > > > > > "parent-reference" leaf-list are available in the mounted > > schema > > > > only > > > > > > for XPath evaluations. In particular, they cannot be accessed > > > > there > > > > > > via network management protocols such as NETCONF [RFC6241] or > > > > > > RESTCONF [RFC8040]. > > > > > > > > > > What are the security implications of this XPath reference outside > > the > > > > > mount jail? Specifically, how does it interact with the access > > control > > > > > for the enclosing module. > > > > > > > > There is no such interaction, since access control comes into play > > > > when some external entity accesses the data through some management > > > > protocol, and the nodes from the "parent-reference" expressions cannot > > > > be accessed via management protocols. > > > > > > > > The last sentence of the quoted paragraph was supposed to make this > > > > clear, but it seems we might need some additional explanation? > > > > > > > > > > Yes, I think so. I guess I'm not clear on what the XPath expressions are > > > for if they > > > can't be accessed via the management protocols. How can they be used? > > > > These are XPath expressions defined in the YANG models themselves, > > such as "must" expressions or "leafrefs". The description of > > "parent-reference" refer to them as: > > > > [...] XPath > > expressions whose context nodes are defined in the > > mounted schema > > > > > > > > /martin > > From nobody Thu Oct 11 00:50:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017D4130E45; Thu, 11 Oct 2018 00:50:33 -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, 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 sCm2ZXiHESF5; Thu, 11 Oct 2018 00:50:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47F35130E07; Thu, 11 Oct 2018 00:50:31 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 7010B1AE0310; Thu, 11 Oct 2018 09:50:25 +0200 (CEST) Date: Thu, 11 Oct 2018 09:50:24 +0200 (CEST) Message-Id: <20181011.095024.1623439215808427976.mbj@tail-f.com> To: spencerdawkins.ietf@gmail.com Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org From: Martin Bjorklund In-Reply-To: <153920076529.5791.8718186118017388016.idtracker@ietfa.amsl.com> References: <153920076529.5791.8718186118017388016.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Spencer Dawkins' Yes on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 07:50:33 -0000 Hi, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-netmod-schema-mount-11: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I really like that you've provided this capability. > > It might be that I've spent too much time doing Unix, but I wonder if > "Yang > Schema Mount Point" would be a clearer title? The WG had a couple of discussions about the title, even though this particular proposal hasn't come up. I think the document is about more than just the mount point, so I think we should keep the current title. /martin From nobody Thu Oct 11 01:23:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35C5127148; Thu, 11 Oct 2018 01:23:42 -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, 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 5yhiEzb85MbZ; Thu, 11 Oct 2018 01:23:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 823C5130E4B; Thu, 11 Oct 2018 01:23:40 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id DA1741AE0310; Thu, 11 Oct 2018 10:23:36 +0200 (CEST) Date: Thu, 11 Oct 2018 10:23:36 +0200 (CEST) Message-Id: <20181011.102336.1101712961765874974.mbj@tail-f.com> To: ben@nostrum.com Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com, lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <153920340311.5891.2170334410096287507.idtracker@ietfa.amsl.com> References: <153920340311.5891.2170334410096287507.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 08:23:43 -0000 Hi, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-netmod-schema-mount-11: No Objection > = > When responding, please keep the subject line intact and reply to all= > email addresses included in the To and CC lines. (Feel free to cut th= is > introductory paragraph, however.) > = > = > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html > for more information about IESG DISCUSS and COMMENT positions. > = > = > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > = > = > = > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > = > Substantive: > = > =A73.3, 4th paragraph: The MUST NOT seems like a statement of fact --= if no > schema is mounted, it doesn't seem possible for it to include anythin= g. Right, so this MUST NOT is directed to an implementor. If you think it is stating the obvious, I'd be happy to modify this to maybe "does not". = > =A75, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it = ever make > sense to violate this? Probably not, but it could depend on how the mount point is supposed to be used. Maybe it is used in such a way that mounted rpcs are not applicable. > =A79: The model includes RFC 2119 boilerplate, but the document itsel= f uses the > newer RFC 8174 boilerplate. Is it normal to include the normative key= word > boilerplate in the model? No, but in some cases models use 2119 language w/o the boilerplate and since models have a life on their own outside the RFC, we thought that it would be a good idea to clarify the intention by including the boilerplate. > If so, it should probably match that of the > containing document. Yes, fixed. > Editorial: > = > =A71, list item 2: "... and is stable as YANG library information of = the server." > Assuming you mean specific YANG library information rather than the g= eneral > concept, there is a missing article before "YANG". (This pattern repe= ats a few > time throughout the document.) Yes, fixed. /martin From nobody Thu Oct 11 01:37:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC37130DF5; Thu, 11 Oct 2018 01:36:55 -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, 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 44BWBe65TFAi; Thu, 11 Oct 2018 01:36:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21868130DDB; Thu, 11 Oct 2018 01:36:53 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id DF68C1AE0310; Thu, 11 Oct 2018 10:36:51 +0200 (CEST) Date: Thu, 11 Oct 2018 10:36:51 +0200 (CEST) Message-Id: <20181011.103651.947203788475378121.mbj@tail-f.com> To: suresh@kaloom.com Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com, lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <153922828107.5944.1683916629739613438.idtracker@ietfa.amsl.com> References: <153922828107.5944.1683916629739613438.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Suresh Krishnan's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 08:36:55 -0000 Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-netmod-schema-mount-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3.3. > > I think it would be nice to have some examples to illustrate the differences > between inline and shared-schema and some guidance to pick between the two. Some examples and a bit of reasoning is provided in A.2 and A.3. Maybe add a reference in 3.3: Examples of "inline" and "shared-schema" can be found in Appendix A.2 and Appendix A.3, respectively. /martin From nobody Thu Oct 11 02:04:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C6130DCB; Thu, 11 Oct 2018 02:04:08 -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 6Cg9obWoLM7J; Thu, 11 Oct 2018 02:04:06 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 27E831293FB; Thu, 11 Oct 2018 02:04:06 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id o63-v6so3329080yba.2; Thu, 11 Oct 2018 02:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/HVnCWiOtHET2GfCfTwkKW7ZKWGoyFiil4pyVMlVF4I=; b=kJL5cJ083qgsIyeZBw+0ezSyiSZ7AfcEwg+x+kUrWc57HyYS7EM28vySSfdJqElbPk Vx55MZFVSOnqH6Uiwt71UOxRaY6LkjsFKO2hvJgmMfOF3+KWEnv1prektQ0PVxZK5lyL v0965hkaKxGyrZezRii9ejBUz5ZpG9q//BGv6uv+KTdr5NJgBRXv9dZw33Ke8b7IkGY6 DD6vLlj5w3DjW2SGJUmEly9QfBV9EUU0pwvrqxhOr6vfsD7Ym/CL1TAWer9N44CX4nEb eGTAYkbFsOTBs0cpawW3P0QvXQaS48+bBrOGm21B0/M1uySfmsV5icLnvmCWLzrGNwkl 2fxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/HVnCWiOtHET2GfCfTwkKW7ZKWGoyFiil4pyVMlVF4I=; b=F8pLTKFNHDxPlP5Uys/5trr8064z9alfdQ/d5wGa2dv3vc80MPQtjhn1+N7NF8h8OQ ac9TOfTj9CDwRfgmzYka1KE5iqIMJQqGWYDzzqG1yvOz5d2Sr6cSERcYMuD7JrSK0smx Pl7WzXvfVnk+Tc3sZ913qytiFJaA7Zw6ZVZG8LO7QDJ9uRjI7D8ehztQJq0cV9xzgTCW bBA4hvtLik5BIiGoSI/LZQju221M9E0TIWAOXG72eqEPE6ZzmzNlZIhdCEsfC3PfrwUE X2fG3ioaqQKUS2Cy5lSpNED91vRRikHgbIkbB5ZohKgmi7eLXkMHc5Oev/UxCoRFm86t c9xw== X-Gm-Message-State: ABuFfojOr6ikbQqnHpPJu8EnEKmF5bSaVEorqjlpl9BtIPMuO90iuu3f k0IY6wS1aR1g5HifTn4GTFOJXqAkkgOzSFsk1/Ze/w== X-Google-Smtp-Source: ACcGV62iBQoev+P0+gsu9Jy1aTkxCUeecBKqsYlvHceFero1xxK8DoW03WBZcUPm8AGI9WhrGzUfe1kOMfQl0h1jt8A= X-Received: by 2002:a25:dacc:: with SMTP id n195-v6mr299815ybf.428.1539248645160; Thu, 11 Oct 2018 02:04:05 -0700 (PDT) MIME-Version: 1.0 References: <153920076529.5791.8718186118017388016.idtracker@ietfa.amsl.com> <20181011.095024.1623439215808427976.mbj@tail-f.com> In-Reply-To: <20181011.095024.1623439215808427976.mbj@tail-f.com> From: Spencer Dawkins at IETF Date: Thu, 11 Oct 2018 04:03:51 -0500 Message-ID: To: mbj@tail-f.com Cc: IESG , netmod-chairs@ietf.org, netmod@ietf.org, joel jaeggli , draft-ietf-netmod-schema-mount@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7455e0577f04090" Archived-At: Subject: Re: [netmod] Spencer Dawkins' Yes on draft-ietf-netmod-schema-mount-11: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 09:04:08 -0000 --000000000000b7455e0577f04090 Content-Type: text/plain; charset="UTF-8" Hi, Martin, On Thu, Oct 11, 2018 at 2:50 AM Martin Bjorklund wrote: > Hi, > > Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-netmod-schema-mount-11: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this > > introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I really like that you've provided this capability. > > > > It might be that I've spent too much time doing Unix, but I wonder if > > "Yang > > Schema Mount Point" would be a clearer title? > > The WG had a couple of discussions about the title, even though this > particular proposal hasn't come up. Excellent - at least it wasn't a completely stupid question. In addition to the term's meaning in Unix, "Mount" is probably used as a verb more often in English than as a noun, so this is one of the cases where not speaking English as my first language would have made this LESS jarring. And that's a win for readers with other backgrounds ;-) > I think the document is about > more than just the mount point, so I think we should keep the current > title. > Sure, and thank you for the feedback. Spencer --000000000000b7455e0577f04090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Martin,=C2=A0

On Thu, Oct 11, 2018 at 2:50 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-netmod-schema-mount-11: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/statement/di= scuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-netmod-schema-mount/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I really like that you've provided this capability.
>
> It might be that I've spent too much time doing Unix, but I wonder= if
> "Yang
> Schema Mount Point" would be a clearer title?

The WG had a couple of discussions about the title, even though this
particular proposal hasn't come up.=C2=A0

<= div>Excellent - at least it wasn't a completely stupid question.
<= div>
In addition to the term's meaning in Unix, "Mou= nt" is probably used as a verb more often in English than as a noun, s= o this is one of the cases where not speaking English as my first language = would have made this LESS jarring. And that's a win for readers with ot= her backgrounds ;-)
=C2=A0
I = think the document is about
more than just the mount point, so I think we should keep the current
title.

Sure, and thank you for the feed= back.=C2=A0

Spencer=C2=A0
--000000000000b7455e0577f04090-- From nobody Thu Oct 11 02:21:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AB3130DC1 for ; Thu, 11 Oct 2018 02:21:36 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 9bV2H4j_zRBX for ; Thu, 11 Oct 2018 02:21:33 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 47B76129BBF for ; Thu, 11 Oct 2018 02:21:33 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id j4-v6so7526079ljc.12 for ; Thu, 11 Oct 2018 02:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M8rFsXK9HE3fK9IfFN65Sq0xX7/jIHKAT3tr2ipThPA=; b=jqNmMBGqZC0cuxgWNpYzrvipob7462kTWfFMR/Uk6GHjFJULtVhPF3fjG1A4RA0qtA 5wZjCjUiZMoc8pFhhltJvPyDcG5Jfslx4yDScmvGlvOeIvLwApRfahw47/XZdY2Q9NNu CmvwXssNSf4LUBu9hyWlgHDSaMlbFdxecMr+U7IYJn+DZcRfXofZ7TZLQm1h8XsYsIOo vwxcHnEKnfVYgBLBTDQIKuSlwmg1NfjAoY85XVusKncAsigqkqEuvfBpxctf+0e75OGg e+whQP5Z0+CEBZyjzWXSHqeBraSpN3HAIFrN6BbtPHTasxftSUvGqW95DLMT20MpFnR5 GBGQ== 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=M8rFsXK9HE3fK9IfFN65Sq0xX7/jIHKAT3tr2ipThPA=; b=s9R5yY7kJoY0kc3DGkvQRgaHUcPxvfg8W85U1H78aLPUbpE9E6s9u2LJ7qUJtwE86/ ZbgT5iwgdSYVsTLCWYY8FYfm3uOac1J84yKCMU1xAANOIzNZ6U4TVxz4s2hSMAgLHyE+ pMc1QjDdXzfxoCp7s76pDgab0B0t83sojIe0r5UcZHx1KBPBJ18KvCoWbodA+dF19IL4 byHGh/mbXXgZuQ27l4/5CdOJJ9V6ffIYFJHU2tMoAH8ZSwF7j2mSyMraX+va9N3s6LFH 3yS6Gm/OXVfJ+NKnhc2dHGKFKGd8Eq/cR0LMxwMe92Av/DCoA7jfgZE5I9alHtrIl5x5 khjw== X-Gm-Message-State: ABuFfojCPAf4hkm8vrWK7zZEKWOfPpuhrzBOdRKIlCcEnDtdZUE8Usga x5gHuW1YXZH6KgCRfoFnOyWWHfMaRDx+K6sZ/csq7Q== X-Google-Smtp-Source: ACcGV60VnfrmpTiB7pazQSVqFHDht6N00p1pcrkYq11MwSkZzDs/nA0s5LgguiNbDY6vJFd5VCNC0+XvPT6r5vo3J+c= X-Received: by 2002:a2e:9047:: with SMTP id n7-v6mr564475ljg.10.1539249691048; Thu, 11 Oct 2018 02:21:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 11 Oct 2018 02:21:29 -0700 (PDT) In-Reply-To: <20181011.083904.763170181197608903.mbj@tail-f.com> References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <20181011.083904.763170181197608903.mbj@tail-f.com> From: Andy Bierman Date: Thu, 11 Oct 2018 02:21:29 -0700 Message-ID: To: Martin Bjorklund Cc: "Reshad Rahman (rrahman)" , Ladislav Lhotka , NetMod WG Content-Type: multipart/alternative; boundary="0000000000000e4e780577f07f50" Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 09:21:37 -0000 --0000000000000e4e780577f07f50 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < > rrahman@cisco.com> > > wrote: > > > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund writes: > > > > > > > > > Hi, > > > > > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > > > > > { > > > > > "ietf-subscribed-notifications:input": { > > > > > "stream": "NETCONF", > > > > > "stream-xpath-filter": "/ds:foo/", > > > > > "dscp": "10" > > > > > } > > > > > } > > > > > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > > > string. > > > > > How are prefixes declared when JSON is used? > > > > > > > > > > The leaf "stream-xpath-filter" says: > > > > > > > > > > o The set of namespace declarations are those in > > > scope on > > > > > the 'stream-xpath-filter' leaf element. > > > > > > > > > > (I think I provided that text...) > > > > > > > > > > This assumes that the encoding is XML, or at leas that the > encoding > > > > > can somehow transfer namespace declarations. > > > > > > > > It can't. There are two options: > > > > > > > > 1. have different representations of this value in XML and JSON, > > > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > > > > > 2. use a module name rather than a prefix in XML, too. > > > > > > > > I would suggest #2. > > > But that means making non-backwards compatible change to the XML > > > representation? > > > > > > > Not really. It means NETMOD WG would be creating its own special variant > of > > XPath. > > Not at all. What I propose is perfectly fine, legal XPath 1.0. > > XPath 1.0 says that an XPath expression is evaluated in a context. > One item in the context is a set of mappings from to , > where is used to lookup prefixes used in the XPath > expression, e.g. in "/foo:interfaces" "foo" is the prefix. > > It is perfectly fine to say that the prefix mapping set is this: > > "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" > "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > > and use that to evaluate the expression > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 > > > The XPath expression is normally parsed within an XML instance document. There are "xmlns" attributes present that map the prefix to a namespace URI. These mappings will not be present in the JSON at all. A custom XPath implementation is required to magically identify the prefix as a module name and magically find the namespace URI for the module name. A normal XPath implementation will not find any namespace mapping for the prefixes. An XPath expression has no concept of the "current module" inherited from the parent like the JSON encoding. This is problematic for predicates /ietf-interfaces:interfaces/interface[name='eth0'] XPath says the missing prefixes for 'interface' and 'name' are simply missing (no namespace). The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and 'interface'. There is no specification for the 'name' node inside a predicate. So you must mean the full module name will be used at every node: /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0'] > > /martin > > Andy > > > > > > > > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > > > o The set of namespace declarations has one member for > each > > > YANG module supported by the server. This member maps > > > from the YANG module name to the YANG module namespace. > > > > > > This means that in the XPath expression, the module > name > > > serves as the prefix. > > > > > > .... and then also give an example of this. > > > > > > This is probably what we need to do in all places where > yang:xpath1.0 > > > is used, going forward. Maybe even define a new type > > > yang:xpath1.0-2 (name?) with the set of namespace declarations > > > built-in. > > > > > > > > > We should avoid making off-the-shelf implementations of standards like > > XPath unusable. > > At the very least this should be only available if the server supports it > > (with a capability URI) > > > > > > > > > So we need an update to RFC7951? > > > > > > Regards, > > > Reshad. > > > > > > > > > > Andy > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > > > > > > > /martin > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > --0000000000000e4e780577f07f50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <mbj@= tail-f.com> wrote:
Andy Bierman <andy@yuma= works.com> wrote:
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <rrahman@cisco.com>
> wrote:
>
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklun= d" <
> > netmod-bounces@ietf.or= g on behalf of mbj@tail-f.com>= wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0Ladislav Lhotka <lhotka@nic.cz> wrote:
> >=C2=A0 =C2=A0 =C2=A0> Martin Bjorklund <mbj@tail-f.com> writes:
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> > Hi,
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > While reviewing restconf-notif, I sa= w this example:
> >=C2=A0 =C2=A0 =C2=A0> >
> >=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= -subscribed-notifications:input": {
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;stream": "NETCONF",
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;stream-xpath-filter": "/ds:foo/",
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q= uot;dscp": "10"
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > Note the "stream-xpath-filter&q= uot;.=C2=A0 It has a prefix in the XPath
> > string.
> >=C2=A0 =C2=A0 =C2=A0> > How are prefixes declared when JSON = is used?
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > The leaf "stream-xpath-filter&q= uot; says:
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of namespace declarations are those in<= br> > > scope on
> >=C2=A0 =C2=A0 =C2=A0> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 the 'stream-xpath-filter' leaf element.=
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > (I think I provided that text...) > >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > This assumes that the encoding is XM= L, or at leas that the encoding
> >=C2=A0 =C2=A0 =C2=A0> > can somehow transfer namespace decla= rations.
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> It can't. There are two options:
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> 1. have different representations of this= value in XML and JSON,
> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 analogically to instance ind= entifiers (sec. 6.11 in RFC 7951).
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> 2. use a module name rather than a prefix= in XML, too.
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> I would suggest #2.
> > <RR> But that means making non-backwards compatible change = to the XML
> > representation?
> >
>
> Not really. It means NETMOD WG would be creating its own special varia= nt of
> XPath.

Not at all.=C2=A0 What I propose is perfectly fine, legal XPath 1.0.

XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from <prefix> to <uri= >,
where <prefix> is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the pref= ix.

It is perfectly fine to say that the prefix mapping set is this:

=C2=A0 =C2=A0"ietf-interfaces" -> "urn:ietf:params:xml:ns= :yang:ietf-interfaces"
=C2=A0 =C2=A0"ietf-ip"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> &qu= ot;urn:ietf:params:xml:ns:yang:ietf-ip"

and use that to evaluate the expression

=C2=A0 /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf= -ip/ipv4




The XPath expression is= normally parsed within an XML instance document.
There are "= ;xmlns" attributes present that map the prefix to a namespace URI.
These mappings will not be present in the JSON at all.
A custom XPath implementation is required to magically identify= the prefix
as a module name and magically find the namespace URI= for the module name.
A normal XPath implementation will not find= any namespace mapping for the prefixes.

An XPath = expression has no concept of the "current module" inherited from = the parent
like the JSON encoding. This is problematic for predic= ates

=C2=A0 =C2=A0/ietf-interfaces:interfaces/inte= rface[name=3D'eth0']

XPath says the missin= g prefixes for 'interface' and 'name' are simply missing (n= o namespace).
The JSON encoding says "ietf-interfaces" = is used for 'interfaces'. and 'interface'.
There = is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at eve= ry node:

=C2=A0/ietf-interfaces:interfaces/ietf-in= terfaces:interface[ietf-interfaces:name=3D'eth0']



/martin


Andy
=C2=A0

>
>
> >=C2=A0 =C2=A0 =C2=A0Hmm, so you mean change the leaf "stream-= xpath-filter" to say:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 The set o= f namespace declarations has one member for each
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0YANG= module supported by the server.=C2=A0 This member maps
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from= the YANG module name to the YANG module namespace.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This= means that in the XPath expression, the module name
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0serv= es as the prefix.
> >
> >=C2=A0 =C2=A0 =C2=A0.... and then also give an example of this. > >
> >=C2=A0 =C2=A0 =C2=A0This is probably what we need to do in all pla= ces where yang:xpath1.0
> >=C2=A0 =C2=A0 =C2=A0is used, going forward.=C2=A0 Maybe even defin= e a new type
> >=C2=A0 =C2=A0 =C2=A0yang:xpath1.0-2 (name?) with the set of namesp= ace declarations
> >=C2=A0 =C2=A0 =C2=A0built-in.
> >
>
>
> We should avoid making off-the-shelf implementations of standards like=
> XPath unusable.
> At the very least this should be only available if the server supports= it
> (with a capability URI)
>
>
>
> > <RR> So we need an update to RFC7951?
> >
> > Regards,
> > Reshad.
> >
> >
>
> Andy
>
>
> >
> >=C2=A0 =C2=A0 =C2=A0/martin
> >
> >
> >
> >
> >
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> Lada
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > How is this supposed to work with JS= ON?
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > /martin
> >=C2=A0 =C2=A0 =C2=A0> >
> >=C2=A0 =C2=A0 =C2=A0> > _______________________________= ________________
> >=C2=A0 =C2=A0 =C2=A0> > netmod mailing list
> >=C2=A0 =C2=A0 =C2=A0> > n= etmod@ietf.org
> >=C2=A0 =C2=A0 =C2=A0> > https://www.ietf.= org/mailman/listinfo/netmod
> >=C2=A0 =C2=A0 =C2=A0>
> >=C2=A0 =C2=A0 =C2=A0> --
> >=C2=A0 =C2=A0 =C2=A0> Ladislav Lhotka
> >=C2=A0 =C2=A0 =C2=A0> Head, CZ.NIC Labs
> >=C2=A0 =C2=A0 =C2=A0> PGP Key ID: 0xB8F92B08A9F76C67
> >=C2=A0 =C2=A0 =C2=A0>
> >
> >=C2=A0 =C2=A0 =C2=A0_________________________________________= ______
> >=C2=A0 =C2=A0 =C2=A0netmod mailing list
> >=C2=A0 =C2=A0 =C2=A0netmod@ietf= .org
> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailma= n/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> >

--0000000000000e4e780577f07f50-- From nobody Thu Oct 11 02:43:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE270130E2A for ; Thu, 11 Oct 2018 02:43:45 -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, 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 ezNOYi1fsq0t for ; Thu, 11 Oct 2018 02:43:42 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23778130DD0 for ; Thu, 11 Oct 2018 02:43:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C378F14448BE; Thu, 11 Oct 2018 11:43:39 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QnAiKDyEnolu; Thu, 11 Oct 2018 11:43:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9BDC414448C0; Thu, 11 Oct 2018 11:43:39 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I3o0DNPdKCfJ; Thu, 11 Oct 2018 11:43:39 +0200 (CEST) Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 7DCAC14448BE; Thu, 11 Oct 2018 11:43:39 +0200 (CEST) To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <20181011.083904.763170181197608903.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: Date: Thu, 11 Oct 2018 11:43:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181011.083904.763170181197608903.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 09:43:46 -0000 On 10/11/18 8:39 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) >> wrote: >> >>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < >>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: >>> >>> Ladislav Lhotka wrote: >>> > Martin Bjorklund writes: >>> > >>> > > Hi, >>> > > >>> > > While reviewing restconf-notif, I saw this example: >>> > > >>> > > { >>> > > "ietf-subscribed-notifications:input": { >>> > > "stream": "NETCONF", >>> > > "stream-xpath-filter": "/ds:foo/", >>> > > "dscp": "10" >>> > > } >>> > > } >>> > > >>> > > Note the "stream-xpath-filter". It has a prefix in the XPat= h >>> string. >>> > > How are prefixes declared when JSON is used? >>> > > >>> > > The leaf "stream-xpath-filter" says: >>> > > >>> > > o The set of namespace declarations are those= in >>> scope on >>> > > the 'stream-xpath-filter' leaf element. >>> > > >>> > > (I think I provided that text...) >>> > > >>> > > This assumes that the encoding is XML, or at leas that the e= ncoding >>> > > can somehow transfer namespace declarations. >>> > >>> > It can't. There are two options: >>> > >>> > 1. have different representations of this value in XML and JSO= N, >>> > analogically to instance indentifiers (sec. 6.11 in RFC 795= 1). >>> > >>> > 2. use a module name rather than a prefix in XML, too. >>> > >>> > I would suggest #2. >>> But that means making non-backwards compatible change to the XML >>> representation? >>> >> Not really. It means NETMOD WG would be creating its own special varia= nt of >> XPath. > Not at all. What I propose is perfectly fine, legal XPath 1.0. > > XPath 1.0 says that an XPath expression is evaluated in a context. > One item in the context is a set of mappings from to , > where is used to lookup prefixes used in the XPath > expression, e.g. in "/foo:interfaces" "foo" is the prefix. > > It is perfectly fine to say that the prefix mapping set is this: > > "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" > "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > > and use that to evaluate the expression > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 +1. This is one of the two necessary changes to make the=20 instance-identifier type canonical. Proposed changes RFC 7950: OLD: 9.13.2.=C2=A0 Lexical Representation =C2=A0=C2=A0 An instance-identifier value is lexically represented as a = string. =C2=A0=C2=A0 All node names in an instance-identifier value MUST be qual= ified with =C2=A0=C2=A0 explicit namespace prefixes, and these prefixes MUST be dec= lared in =C2=A0=C2=A0 the XML namespace scope in the instance-identifier's XML el= ement. =C2=A0=C2=A0 Any prefixes used in the encoding are local to each instanc= e =C2=A0=C2=A0 encoding.=C2=A0 This means that the same instance-identifie= r may be =C2=A0=C2=A0 encoded differently by different implementations. 9.13.3.=C2=A0 Canonical Form =C2=A0=C2=A0 Since the lexical form depends on the XML context in which = the value =C2=A0=C2=A0 occurs, this type does not have a canonical form. NEW: 9.13.2.=C2=A0 Lexical Representation =C2=A0=C2=A0 An instance-identifier value is lexically represented as a = string. =C2=A0=C2=A0 All node names in an instance-identifier value MUST be qual= ified with =C2=A0=C2=A0 explicit namespace prefixes where the module name is used a= s prefix. =C2=A0=C2=A0 All predicates must appear in alphabetical order. 9.13.3.=C2=A0 Canonical Form =C2=A0=C2=A0 Since the lexical form is encoding independent and tere is = prescribed =C2=A0=C2=A0 alphabetical order of the predicates the type has a canonic= al form. Vladimir > > > > > /martin > > >> >>> Hmm, so you mean change the leaf "stream-xpath-filter" to say: >>> >>> o The set of namespace declarations has one member for= each >>> YANG module supported by the server. This member ma= ps >>> from the YANG module name to the YANG module namespa= ce. >>> >>> This means that in the XPath expression, the module = name >>> serves as the prefix. >>> >>> .... and then also give an example of this. >>> >>> This is probably what we need to do in all places where yang:xpa= th1.0 >>> is used, going forward. Maybe even define a new type >>> yang:xpath1.0-2 (name?) with the set of namespace declarations >>> built-in. >>> >> >> We should avoid making off-the-shelf implementations of standards like >> XPath unusable. >> At the very least this should be only available if the server supports= it >> (with a capability URI) >> >> >> >>> So we need an update to RFC7951? >>> >>> Regards, >>> Reshad. >>> >>> >> Andy >> >> >>> /martin >>> >>> >>> >>> >>> >>> > >>> > Lada >>> > >>> > > >>> > > How is this supposed to work with JSON? >>> > > >>> > > >>> > > /martin >>> > > >>> > > _______________________________________________ >>> > > netmod mailing list >>> > > netmod@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/netmod >>> > >>> > -- >>> > Ladislav Lhotka >>> > Head, CZ.NIC Labs >>> > PGP Key ID: 0xB8F92B08A9F76C67 >>> > >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 11 02:46:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B23130DD0 for ; Thu, 11 Oct 2018 02:46:19 -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, DKIMWL_WL_MED=-0.001, 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 on46jkPZqqeE for ; Thu, 11 Oct 2018 02:46:14 -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 04554130E1C for ; Thu, 11 Oct 2018 02:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24568; q=dns/txt; s=iport; t=1539251174; x=1540460774; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jTrVnBnal4XyAVI2DW65oQJAkhqnNqfpC4CqtjbdHwc=; b=ZNFDNWEUSZcw4vCzN+kw9APe2NeiuHPXgTmj9oU4eKZgnn+lI1fJuR4U c7HbWS2SLoLfDv5EfGH9AO7yczT454OYKKUUM1bB0nyBXOJpbs0DYdkUk pyUov+KL1MvS4TVZ9aOQnXq36H1VtjDKwcOl5gMMtMTnOZnRzpcDUsRwC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAACBGr9b/xbLJq0YAUAKGQEBAQE?= =?us-ascii?q?BAQEBAQEBAQcBAQEBAQGBZQKCaH8og3WIdY0/JZh6DRgBCoQDRgKEdTgWAQM?= =?us-ascii?q?BAQIBAQJtHAyFOgEBAQMBASEERwsQCQIYIAcDAgInHxEGAQkDBgIBAReDBQG?= =?us-ascii?q?CAQ+IboFCm017Mx+EWIRfBYtcgUE/gTkMgl+DGwEBgTYVgxeCVwKIPYV2j10?= =?us-ascii?q?JkE4GF4FPh1aGbIkUhkqGNIFZIYFVMxoIGxU7gmyBdokhhT8+MIxhAQE?= X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208,217";a="7098672" 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; 11 Oct 2018 09:46:11 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w9B9kBkq029336; Thu, 11 Oct 2018 09:46:11 GMT To: Andy Bierman , Martin Bjorklund Cc: NetMod WG References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <20181011.083904.763170181197608903.mbj@tail-f.com> From: Robert Wilton Message-ID: <7fe38670-7275-b99c-5e80-cb0243f1dd43@cisco.com> Date: Thu, 11 Oct 2018 10:46:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------13133C8EBC547982A0C6732D" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 09:46:20 -0000 This is a multi-part message in MIME format. --------------13133C8EBC547982A0C6732D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2018 10:21, Andy Bierman wrote: > > > On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund > wrote: > > Andy Bierman > wrote: > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) > > > > wrote: > > > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > > netmod-bounces@ietf.org on > behalf of mbj@tail-f.com > wrote: > > > > > >     Ladislav Lhotka > wrote: > > >     > Martin Bjorklund > writes: > > >     > > > >     > > Hi, > > >     > > > > >     > > While reviewing restconf-notif, I saw this example: > > >     > > > > >     > >    { > > >     > >       "ietf-subscribed-notifications:input": { > > >     > >          "stream": "NETCONF", > > >     > >          "stream-xpath-filter": "/ds:foo/", > > >     > >          "dscp": "10" > > >     > >       } > > >     > >    } > > >     > > > > >     > > Note the "stream-xpath-filter". It has a prefix in the > XPath > > > string. > > >     > > How are prefixes declared when JSON is used? > > >     > > > > >     > > The leaf "stream-xpath-filter" says: > > >     > > > > >     > >               o  The set of namespace declarations are > those in > > > scope on > > >     > >                  the 'stream-xpath-filter' leaf element. > > >     > > > > >     > > (I think I provided that text...) > > >     > > > > >     > > This assumes that the encoding is XML, or at leas that > the encoding > > >     > > can somehow transfer namespace declarations. > > >     > > > >     > It can't. There are two options: > > >     > > > >     > 1. have different representations of this value in XML > and JSON, > > >     >    analogically to instance indentifiers (sec. 6.11 in > RFC 7951). > > >     > > > >     > 2. use a module name rather than a prefix in XML, too. > > >     > > > >     > I would suggest #2. > > > But that means making non-backwards compatible change to > the XML > > > representation? > > > > > > > Not really. It means NETMOD WG would be creating its own special > variant of > > XPath. > > Not at all.  What I propose is perfectly fine, legal XPath 1.0. > > XPath 1.0 says that an XPath expression is evaluated in a context. > One item in the context is a set of mappings from to , > where is used to lookup prefixes used in the XPath > expression, e.g. in "/foo:interfaces" "foo" is the prefix. > > It is perfectly fine to say that the prefix mapping set is this: > >    "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" >    "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip" > > and use that to evaluate the expression > >   /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 > > > > > The XPath expression is normally parsed within an XML instance document. > There are "xmlns" attributes present that map the prefix to a > namespace URI. > These mappings will not be present in the JSON at all. > > A custom XPath implementation is required to magically identify the prefix > as a module name and magically find the namespace URI for the module name. > A normal XPath implementation will not find any namespace mapping for > the prefixes. > > An XPath expression has no concept of the "current module" inherited > from the parent > like the JSON encoding. This is problematic for predicates > >    /ietf-interfaces:interfaces/interface[name='eth0'] > > XPath says the missing prefixes for 'interface' and 'name' are simply > missing (no namespace). > The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and > 'interface'. > There is no specification for the 'name' node inside a predicate. > > So you must mean the full module name will be used at every node: > >  /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0'] Hum, that is going to make these expressions very long, and not particularly human readable. The XPath 1.0 spec that YANG using is effectively obsoleted by newer (much more complex) versions.  I doubt that this will be liked, but my view is that the longer term solution here is for a bespoke "YANG Path" language to be specified, closely based on XPath 1.0, but fixing some of the issues that we have using XPath for YANG constraints (e.g. it is easy to get them wrong), and removing some of stuff that isn't helpful (e.g. node tests, processing instructions, etc). Thanks, Rob > > > > > /martin > > > Andy > > > > > > > > >     Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > > >              o  The set of namespace declarations has one > member for each > > >                 YANG module supported by the server.  This > member maps > > >                 from the YANG module name to the YANG module > namespace. > > > > > >                 This means that in the XPath expression, the > module name > > >                 serves as the prefix. > > > > > >     .... and then also give an example of this. > > > > > >     This is probably what we need to do in all places where > yang:xpath1.0 > > >     is used, going forward.  Maybe even define a new type > > >     yang:xpath1.0-2 (name?) with the set of namespace declarations > > >     built-in. > > > > > > > > > We should avoid making off-the-shelf implementations of > standards like > > XPath unusable. > > At the very least this should be only available if the server > supports it > > (with a capability URI) > > > > > > > > > So we need an update to RFC7951? > > > > > > Regards, > > > Reshad. > > > > > > > > > > Andy > > > > > > > > > >     /martin > > > > > > > > > > > > > > > > > >     > > > >     > Lada > > >     > > > >     > > > > >     > > How is this supposed to work with JSON? > > >     > > > > >     > > > > >     > > /martin > > >     > > > > >     > > _______________________________________________ > > >     > > netmod mailing list > > >     > > netmod@ietf.org > > >     > > https://www.ietf.org/mailman/listinfo/netmod > > > >     > > > >     > -- > > >     > Ladislav Lhotka > > >     > Head, CZ.NIC Labs > > >     > PGP Key ID: 0xB8F92B08A9F76C67 > > >     > > > > > > >     _______________________________________________ > > >     netmod mailing list > > > netmod@ietf..org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------13133C8EBC547982A0C6732D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/10/2018 10:21, Andy Bierman wrote:


On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <rrahman@cisco.com>
> wrote:
>
> > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
> >
> >     Ladislav Lhotka <lhotka@nic.cz> wrote:
> >     > Martin Bjorklund <mbj@tail-f.com> writes:
> >     >
> >     > > Hi,
> >     > >
> >     > > While reviewing restconf-notif, I saw this example:
> >     > >
> >     > >    {
> >     > >       "ietf-subscribed-notifications:input": {
> >     > >          "stream": "NETCONF",
> >     > >          "stream-xpath-filter": "/ds:foo/",
> >     > >          "dscp": "10"
> >     > >       }
> >     > >    }
> >     > >
> >     > > Note the "stream-xpath-filter".  It has a prefix in the XPath
> > string.
> >     > > How are prefixes declared when JSON is used?
> >     > >
> >     > > The leaf "stream-xpath-filter" says:
> >     > >
> >     > >               o  The set of namespace declarations are those in
> > scope on
> >     > >                  the 'stream-xpath-filter' leaf element.
> >     > >
> >     > > (I think I provided that text...)
> >     > >
> >     > > This assumes that the encoding is XML, or at leas that the encoding
> >     > > can somehow transfer namespace declarations.
> >     >
> >     > It can't. There are two options:
> >     >
> >     > 1. have different representations of this value in XML and JSON,
> >     >    analogically to instance indentifiers (sec. 6.11 in RFC 7951).
> >     >
> >     > 2. use a module name rather than a prefix in XML, too.
> >     >
> >     > I would suggest #2.
> > <RR> But that means making non-backwards compatible change to the XML
> > representation?
> >
>
> Not really. It means NETMOD WG would be creating its own special variant of
> XPath.

Not at all.  What I propose is perfectly fine, legal XPath 1.0.

XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from <prefix> to <uri>,
where <prefix> is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the prefix.

It is perfectly fine to say that the prefix mapping set is this:

   "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
   "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"

and use that to evaluate the expression

  /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4




The XPath expression is normally parsed within an XML instance document.
There are "xmlns" attributes present that map the prefix to a namespace URI.
These mappings will not be present in the JSON at all.

A custom XPath implementation is required to magically identify the prefix
as a module name and magically find the namespace URI for the module name.
A normal XPath implementation will not find any namespace mapping for the prefixes.

An XPath expression has no concept of the "current module" inherited from the parent
like the JSON encoding. This is problematic for predicates

   /ietf-interfaces:interfaces/interface[name='eth0']

XPath says the missing prefixes for 'interface' and 'name' are simply missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and 'interface'.
There is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at every node:

 /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']
Hum, that is going to make these expressions very long, and not particularly human readable.

The XPath 1.0 spec that YANG using is effectively obsoleted by newer (much more complex) versions.  I doubt that this will be liked, but my view is that the longer term solution here is for a bespoke "YANG Path" language to be specified, closely based on XPath 1.0, but fixing some of the issues that we have using XPath for YANG constraints (e.g. it is easy to get them wrong), and removing some of stuff that isn't helpful (e.g. node tests, processing instructions, etc).

Thanks,
Rob






/martin


Andy
 

>
>
> >     Hmm, so you mean change the leaf "stream-xpath-filter" to say:
> >
> >              o  The set of namespace declarations has one member for each
> >                 YANG module supported by the server.  This member maps
> >                 from the YANG module name to the YANG module namespace.
> >
> >                 This means that in the XPath expression, the module name
> >                 serves as the prefix.
> >
> >     .... and then also give an example of this.
> >
> >     This is probably what we need to do in all places where yang:xpath1.0
> >     is used, going forward.  Maybe even define a new type
> >     yang:xpath1.0-2 (name?) with the set of namespace declarations
> >     built-in.
> >
>
>
> We should avoid making off-the-shelf implementations of standards like
> XPath unusable.
> At the very least this should be only available if the server supports it
> (with a capability URI)
>
>
>
> > <RR> So we need an update to RFC7951?
> >
> > Regards,
> > Reshad.
> >
> >
>
> Andy
>
>
> >
> >     /martin
> >
> >
> >
> >
> >
> >     >
> >     > Lada
> >     >
> >     > >
> >     > > How is this supposed to work with JSON?
> >     > >
> >     > >
> >     > > /martin
> >     > >
> >     > > _______________________________________________
> >     > > netmod mailing list
> >     > > netmod@ietf.org
> >     > > https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >     > --
> >     > Ladislav Lhotka
> >     > Head, CZ.NIC Labs
> >     > PGP Key ID: 0xB8F92B08A9F76C67
> >     >
> >
> >     _______________________________________________
> >     netmod mailing list
> >     netmod@ietf..org
> >     https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >



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

--------------13133C8EBC547982A0C6732D-- From nobody Thu Oct 11 03:21:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA91130DD6 for ; Thu, 11 Oct 2018 03:21:42 -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, 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 vIZ1Z3z31hsA for ; Thu, 11 Oct 2018 03:21:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 282A8130DD5 for ; Thu, 11 Oct 2018 03:21:40 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id F17B11AE0310; Thu, 11 Oct 2018 12:21:37 +0200 (CEST) Date: Thu, 11 Oct 2018 12:21:37 +0200 (CEST) Message-Id: <20181011.122137.1647095802972927089.mbj@tail-f.com> To: andy@yumaworks.com Cc: rrahman@cisco.com, lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20181011.083904.763170181197608903.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 10:21:43 -0000 Andy Bierman wrote: > On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < > > rrahman@cisco.com> > > > wrote: > > > > > > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < > > > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > > > > > > > > Ladislav Lhotka wrote: > > > > > Martin Bjorklund writes: > > > > > > > > > > > Hi, > > > > > > > > > > > > While reviewing restconf-notif, I saw this example: > > > > > > > > > > > > { > > > > > > "ietf-subscribed-notifications:input": { > > > > > > "stream": "NETCONF", > > > > > > "stream-xpath-filter": "/ds:foo/", > > > > > > "dscp": "10" > > > > > > } > > > > > > } > > > > > > > > > > > > Note the "stream-xpath-filter". It has a prefix in the XPath > > > > string. > > > > > > How are prefixes declared when JSON is used? > > > > > > > > > > > > The leaf "stream-xpath-filter" says: > > > > > > > > > > > > o The set of namespace declarations are those in > > > > scope on > > > > > > the 'stream-xpath-filter' leaf element. > > > > > > > > > > > > (I think I provided that text...) > > > > > > > > > > > > This assumes that the encoding is XML, or at leas that the > > encoding > > > > > > can somehow transfer namespace declarations. > > > > > > > > > > It can't. There are two options: > > > > > > > > > > 1. have different representations of this value in XML and JSON, > > > > > analogically to instance indentifiers (sec. 6.11 in RFC 7951). > > > > > > > > > > 2. use a module name rather than a prefix in XML, too. > > > > > > > > > > I would suggest #2. > > > > But that means making non-backwards compatible change to the XML > > > > representation? > > > > > > > > > > Not really. It means NETMOD WG would be creating its own special variant > > of > > > XPath. > > > > Not at all. What I propose is perfectly fine, legal XPath 1.0. > > > > XPath 1.0 says that an XPath expression is evaluated in a context. > > One item in the context is a set of mappings from to , > > where is used to lookup prefixes used in the XPath > > expression, e.g. in "/foo:interfaces" "foo" is the prefix. > > > > It is perfectly fine to say that the prefix mapping set is this: > > > > "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" > > "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > > > > and use that to evaluate the expression > > > > /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 > > > > > > > > The XPath expression is normally parsed within an XML instance document. > There are "xmlns" attributes present that map the prefix to a namespace URI. > These mappings will not be present in the JSON at all. > > A custom XPath implementation is required to magically identify the prefix > as a module name and magically find the namespace URI for the module > name. I disagree. You need an XPath implementation + custom code to set up the environment. There is no standard XPath implementation that can just take an XML instance document + YANG module and figure out what to do. Custom code is needed to connect things together. This proposal doesn't change this. /martin > A normal XPath implementation will not find any namespace mapping for the > prefixes. > > An XPath expression has no concept of the "current module" inherited from > the parent > like the JSON encoding. This is problematic for predicates > > /ietf-interfaces:interfaces/interface[name='eth0'] > > XPath says the missing prefixes for 'interface' and 'name' are simply > missing (no namespace). > The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and > 'interface'. > There is no specification for the 'name' node inside a predicate. > > So you must mean the full module name will be used at every node: > > /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0'] > > > > > > > /martin > > > > > Andy > > > > > > > > > > > > > > Hmm, so you mean change the leaf "stream-xpath-filter" to say: > > > > > > > > o The set of namespace declarations has one member for > > each > > > > YANG module supported by the server. This member maps > > > > from the YANG module name to the YANG module namespace. > > > > > > > > This means that in the XPath expression, the module > > name > > > > serves as the prefix. > > > > > > > > .... and then also give an example of this. > > > > > > > > This is probably what we need to do in all places where > > yang:xpath1.0 > > > > is used, going forward. Maybe even define a new type > > > > yang:xpath1.0-2 (name?) with the set of namespace declarations > > > > built-in. > > > > > > > > > > > > > We should avoid making off-the-shelf implementations of standards like > > > XPath unusable. > > > At the very least this should be only available if the server supports it > > > (with a capability URI) > > > > > > > > > > > > > So we need an update to RFC7951? > > > > > > > > Regards, > > > > Reshad. > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > How is this supposed to work with JSON? > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > From nobody Thu Oct 11 03:43:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA7130E73 for ; Thu, 11 Oct 2018 03:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.956 X-Spam-Level: X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 qp3wWy_fMgec for ; Thu, 11 Oct 2018 03:43:33 -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 D034A130E69 for ; Thu, 11 Oct 2018 03:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7234; q=dns/txt; s=iport; t=1539254613; x=1540464213; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=gBjbKb5fNyIzKE+/q0vu/gSiBLIagPqj2rnp18QdKXk=; b=LXLBUG6bij1R+hA1JMnjx6cpMWpYcu1w3NR2SStpn7h9RNfUKGOzmxMr GQac59CbxArzjKEmJLiMKXDOHFiHq3ySKLepK4yUUo06hXcklIg1bjRb/ O0MkIjLHMFwmuSEFzZyfvDC92aXUpZYSf8OUCAkbhWphCtfANFcSUw7BR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AABeKL9b/xbLJq1YChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCan8og3WIdY1kmHoNGAuEA0YChHY4FgEDAQECAQE?= =?us-ascii?q?CbRwMhTkBAQEBAgEBASEECwEFNgsQCw4KAgImAgInMAYBCQMGAgEBgxwBgXk?= =?us-ascii?q?ID6V1ezOEd4ReBYELilGBQT+BOYJrgxsBAYE2FYMXglcCiD2Fdo9dCZBOBhe?= =?us-ascii?q?BT4dWhmyJFIZKhjSBWSGBVTMaCBsVO4JsixeFPz4wjGEBAQ?= X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208";a="7157774" 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; 11 Oct 2018 10:43:30 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9BAhTWJ010065; Thu, 11 Oct 2018 10:43:30 GMT To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20181011.083904.763170181197608903.mbj@tail-f.com> <20181011.122137.1647095802972927089.mbj@tail-f.com> From: Robert Wilton Message-ID: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> Date: Thu, 11 Oct 2018 11:43:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181011.122137.1647095802972927089.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 10:43:44 -0000 On 11/10/2018 11:21, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < >>> rrahman@cisco.com> >>>> wrote: >>>> >>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < >>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: >>>>> >>>>> Ladislav Lhotka wrote: >>>>> > Martin Bjorklund writes: >>>>> > >>>>> > > Hi, >>>>> > > >>>>> > > While reviewing restconf-notif, I saw this example: >>>>> > > >>>>> > > { >>>>> > > "ietf-subscribed-notifications:input": { >>>>> > > "stream": "NETCONF", >>>>> > > "stream-xpath-filter": "/ds:foo/", >>>>> > > "dscp": "10" >>>>> > > } >>>>> > > } >>>>> > > >>>>> > > Note the "stream-xpath-filter". It has a prefix in the XPath >>>>> string. >>>>> > > How are prefixes declared when JSON is used? >>>>> > > >>>>> > > The leaf "stream-xpath-filter" says: >>>>> > > >>>>> > > o The set of namespace declarations are those in >>>>> scope on >>>>> > > the 'stream-xpath-filter' leaf element. >>>>> > > >>>>> > > (I think I provided that text...) >>>>> > > >>>>> > > This assumes that the encoding is XML, or at leas that the >>> encoding >>>>> > > can somehow transfer namespace declarations. >>>>> > >>>>> > It can't. There are two options: >>>>> > >>>>> > 1. have different representations of this value in XML and JSON, >>>>> > analogically to instance indentifiers (sec. 6.11 in RFC 7951). >>>>> > >>>>> > 2. use a module name rather than a prefix in XML, too. >>>>> > >>>>> > I would suggest #2. >>>>> But that means making non-backwards compatible change to the XML >>>>> representation? >>>>> >>>> Not really. It means NETMOD WG would be creating its own special variant >>> of >>>> XPath. >>> Not at all. What I propose is perfectly fine, legal XPath 1.0. >>> >>> XPath 1.0 says that an XPath expression is evaluated in a context. >>> One item in the context is a set of mappings from to , >>> where is used to lookup prefixes used in the XPath >>> expression, e.g. in "/foo:interfaces" "foo" is the prefix. >>> >>> It is perfectly fine to say that the prefix mapping set is this: >>> >>> "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" >>> "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" >>> >>> and use that to evaluate the expression >>> >>> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 >>> >>> >>> >> The XPath expression is normally parsed within an XML instance document. >> There are "xmlns" attributes present that map the prefix to a namespace URI. >> These mappings will not be present in the JSON at all. >> >> A custom XPath implementation is required to magically identify the prefix >> as a module name and magically find the namespace URI for the module >> name. > I disagree. You need an XPath implementation + custom code to set up > the environment. This is OK, but can we just use the JSON encoding instance identifier format exactly?  I.e .RFC 7951 section 6.11. So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled" can trivially be expanded to: "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled", and then interpreted with the context: "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" Thanks, Rob > > There is no standard XPath implementation that can just take an XML > instance document + YANG module and figure out what to do. Custom > code is needed to connect things together. This proposal doesn't > change this. > > > /martin > > >> A normal XPath implementation will not find any namespace mapping for the >> prefixes. >> >> An XPath expression has no concept of the "current module" inherited from >> the parent >> like the JSON encoding. This is problematic for predicates >> >> /ietf-interfaces:interfaces/interface[name='eth0'] >> >> XPath says the missing prefixes for 'interface' and 'name' are simply >> missing (no namespace). >> The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and >> 'interface'. >> There is no specification for the 'name' node inside a predicate. >> >> So you must mean the full module name will be used at every node: >> >> /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0'] >> >> >> >>> /martin >>> >>> >> Andy >> >> >>>> >>>>> Hmm, so you mean change the leaf "stream-xpath-filter" to say: >>>>> >>>>> o The set of namespace declarations has one member for >>> each >>>>> YANG module supported by the server. This member maps >>>>> from the YANG module name to the YANG module namespace. >>>>> >>>>> This means that in the XPath expression, the module >>> name >>>>> serves as the prefix. >>>>> >>>>> .... and then also give an example of this. >>>>> >>>>> This is probably what we need to do in all places where >>> yang:xpath1.0 >>>>> is used, going forward. Maybe even define a new type >>>>> yang:xpath1.0-2 (name?) with the set of namespace declarations >>>>> built-in. >>>>> >>>> >>>> We should avoid making off-the-shelf implementations of standards like >>>> XPath unusable. >>>> At the very least this should be only available if the server supports it >>>> (with a capability URI) >>>> >>>> >>>> >>>>> So we need an update to RFC7951? >>>>> >>>>> Regards, >>>>> Reshad. >>>>> >>>>> >>>> Andy >>>> >>>> >>>>> /martin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > >>>>> > Lada >>>>> > >>>>> > > >>>>> > > How is this supposed to work with JSON? >>>>> > > >>>>> > > >>>>> > > /martin >>>>> > > >>>>> > > _______________________________________________ >>>>> > > netmod mailing list >>>>> > > netmod@ietf.org >>>>> > > https://www.ietf.org/mailman/listinfo/netmod >>>>> > >>>>> > -- >>>>> > Ladislav Lhotka >>>>> > Head, CZ.NIC Labs >>>>> > PGP Key ID: 0xB8F92B08A9F76C67 >>>>> > >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Oct 11 03:50:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5C130E90 for ; Thu, 11 Oct 2018 03:50:13 -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, 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 Bvi908erBeqj for ; Thu, 11 Oct 2018 03:50:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0B33130E91 for ; Thu, 11 Oct 2018 03:50:08 -0700 (PDT) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C473F1AE0310; Thu, 11 Oct 2018 12:50:07 +0200 (CEST) Date: Thu, 11 Oct 2018 12:50:07 +0200 (CEST) Message-Id: <20181011.125007.434815114996317742.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> References: <20181011.122137.1647095802972927089.mbj@tail-f.com> <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 10:50:19 -0000 Robert Wilton wrote: > = > = > On 11/10/2018 11:21, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund > >> wrote: > >> > >>> Andy Bierman wrote: > >>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < > >>> rrahman@cisco.com> > >>>> wrote: > >>>> > >>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" = < > >>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>> > Martin Bjorklund writes: > >>>>> > > >>>>> > > Hi, > >>>>> > > > >>>>> > > While reviewing restconf-notif, I saw this example: > >>>>> > > > >>>>> > > { > >>>>> > > "ietf-subscribed-notifications:input": { > >>>>> > > "stream": "NETCONF", > >>>>> > > "stream-xpath-filter": "/ds:foo/", > >>>>> > > "dscp": "10" > >>>>> > > } > >>>>> > > } > >>>>> > > > >>>>> > > Note the "stream-xpath-filter". It has a prefix in th= e XPath > >>>>> string. > >>>>> > > How are prefixes declared when JSON is used? > >>>>> > > > >>>>> > > The leaf "stream-xpath-filter" says: > >>>>> > > > >>>>> > > o The set of namespace declarations are= those in > >>>>> scope on > >>>>> > > the 'stream-xpath-filter' leaf elemen= t. > >>>>> > > > >>>>> > > (I think I provided that text...) > >>>>> > > > >>>>> > > This assumes that the encoding is XML, or at leas that= the > >>> encoding > >>>>> > > can somehow transfer namespace declarations. > >>>>> > > >>>>> > It can't. There are two options: > >>>>> > > >>>>> > 1. have different representations of this value in XML a= nd JSON, > >>>>> > analogically to instance indentifiers (sec. 6.11 in R= FC 7951). > >>>>> > > >>>>> > 2. use a module name rather than a prefix in XML, too. > >>>>> > > >>>>> > I would suggest #2. > >>>>> But that means making non-backwards compatible change to t= he XML > >>>>> representation? > >>>>> > >>>> Not really. It means NETMOD WG would be creating its own special= > >>>> variant > >>> of > >>>> XPath. > >>> Not at all. What I propose is perfectly fine, legal XPath 1.0. > >>> > >>> XPath 1.0 says that an XPath expression is evaluated in a context= .= > >>> One item in the context is a set of mappings from to , > >>> where is used to lookup prefixes used in the XPath > >>> expression, e.g. in "/foo:interfaces" "foo" is the prefix. > >>> > >>> It is perfectly fine to say that the prefix mapping set is this: > >>> > >>> "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interf= aces" > >>> "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > >>> > >>> and use that to evaluate the expression > >>> > >>> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/= ipv4 > >>> > >>> > >>> > >> The XPath expression is normally parsed within an XML instance > >> document. > >> There are "xmlns" attributes present that map the prefix to a > >> namespace URI. > >> These mappings will not be present in the JSON at all. > >> > >> A custom XPath implementation is required to magically identify th= e > >> prefix > >> as a module name and magically find the namespace URI for the modu= le > >> name. > > I disagree. You need an XPath implementation + custom code to set = up > > the environment. > This is OK, but can we just use the JSON encoding instance identifier= > format exactly?=A0 I.e .RFC 7951 section 6.11. > = > So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled" > = > can trivially be expanded to: > = > "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/i= etf-ip:enabled", > = > and then interpreted with the context: > "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interface= s" > "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" *this* would require a custom XPath implementation. and it is not obvious what the rules for the "auto-assignment" of prefixes would be. For example: /ietf-interfaces//ietf-ip:address[../foo] what is the prefix for "foo"? /martin > = > Thanks, > Rob > = > = > > > > There is no standard XPath implementation that can just take an XML= > > instance document + YANG module and figure out what to do. Custom > > code is needed to connect things together. This proposal doesn't > > change this. > > > > > > /martin > > > > > >> A normal XPath implementation will not find any namespace mapping = for > >> the > >> prefixes. > >> > >> An XPath expression has no concept of the "current module" inherit= ed > >> from > >> the parent > >> like the JSON encoding. This is problematic for predicates > >> > >> /ietf-interfaces:interfaces/interface[name=3D'eth0'] > >> > >> XPath says the missing prefixes for 'interface' and 'name' are sim= ply > >> missing (no namespace). > >> The JSON encoding says "ietf-interfaces" is used for 'interfaces'.= and > >> 'interface'. > >> There is no specification for the 'name' node inside a predicate. > >> > >> So you must mean the full module name will be used at every node: > >> > >> /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-inter= faces:name=3D'eth0'] > >> > >> > >> > >>> /martin > >>> > >>> > >> Andy > >> > >> > >>>> > >>>>> Hmm, so you mean change the leaf "stream-xpath-filter" to = say: > >>>>> > >>>>> o The set of namespace declarations has one memb= er for > >>> each > >>>>> YANG module supported by the server. This mem= ber maps > >>>>> from the YANG module name to the YANG module n= amespace. > >>>>> > >>>>> This means that in the XPath expression, the m= odule > >>> name > >>>>> serves as the prefix. > >>>>> > >>>>> .... and then also give an example of this. > >>>>> > >>>>> This is probably what we need to do in all places where > >>> yang:xpath1.0 > >>>>> is used, going forward. Maybe even define a new type > >>>>> yang:xpath1.0-2 (name?) with the set of namespace declarat= ions > >>>>> built-in. > >>>>> > >>>> > >>>> We should avoid making off-the-shelf implementations of standard= s like > >>>> XPath unusable. > >>>> At the very least this should be only available if the server su= pports > >>>> it > >>>> (with a capability URI) > >>>> > >>>> > >>>> > >>>>> So we need an update to RFC7951? > >>>>> > >>>>> Regards, > >>>>> Reshad. > >>>>> > >>>>> > >>>> Andy > >>>> > >>>> > >>>>> /martin > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > > >>>>> > Lada > >>>>> > > >>>>> > > > >>>>> > > How is this supposed to work with JSON? > >>>>> > > > >>>>> > > > >>>>> > > /martin > >>>>> > > > >>>>> > > _______________________________________________ > >>>>> > > netmod mailing list > >>>>> > > netmod@ietf.org > >>>>> > > https://www.ietf.org/mailman/listinfo/netmod > >>>>> > > >>>>> > -- > >>>>> > Ladislav Lhotka > >>>>> > Head, CZ.NIC Labs > >>>>> > PGP Key ID: 0xB8F92B08A9F76C67 > >>>>> > > >>>>> > >>>>> _______________________________________________ > >>>>> netmod mailing list > >>>>> netmod@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netmod mailing list > >>>>> netmod@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > = From nobody Thu Oct 11 04:00:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1A130E55 for ; Thu, 11 Oct 2018 04:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtUFIG0CPpe2 for ; Thu, 11 Oct 2018 04:00:30 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AE6130DE5 for ; Thu, 11 Oct 2018 04:00:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5C60D14448D7; Thu, 11 Oct 2018 13:00:28 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SFyo8bshopDF; Thu, 11 Oct 2018 13:00:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1F97014448DA; Thu, 11 Oct 2018 13:00:28 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F3pmW-R6myLc; Thu, 11 Oct 2018 13:00:28 +0200 (CEST) Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id ECD6914448D7; Thu, 11 Oct 2018 13:00:27 +0200 (CEST) To: Andy Bierman , Martin Bjorklund Cc: NetMod WG References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <20181011.083904.763170181197608903.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: <36a3971c-d3ab-dd0f-48e5-8de0fc4cc064@transpacket.com> Date: Thu, 11 Oct 2018 13:00:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 11:00:32 -0000 On 10/11/18 11:21 AM, Andy Bierman wrote: > > So you must mean the full module name will be used at every node: > > =C2=A0/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interf= aces:name=3D'eth0'] Length is the only real problem I see with the solution. The lexical=20 representation of identityref type has made a compromise accepting=20 prefix instead of module name. This has its own unsolved issues but=20 those could be addressed by a limitation not allowing modules with=20 identical prefix statements to define homonyme data nodes and identities=20 (which is not the case currently). If this is done module name can be=20 replaced with prefix and the instance-identifiers will be shorter and=20 encoding independent but still Xpath 1.0 compatible: =C2=A0/if:interfaces/if:interface[if:name=3D'eth0'] Vladimir From nobody Thu Oct 11 04:09:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAFC130E47 for ; Thu, 11 Oct 2018 04:09:17 -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, 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 bJbCOAyc-pqy for ; Thu, 11 Oct 2018 04:09:15 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E63F130DE7 for ; Thu, 11 Oct 2018 04:09:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7C3001444360; Thu, 11 Oct 2018 13:09:13 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xc2uU25CEGjc; Thu, 11 Oct 2018 13:09:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4DC96144438B; Thu, 11 Oct 2018 13:09:13 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aCWLUpeSMae6; Thu, 11 Oct 2018 13:09:13 +0200 (CEST) Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 0EA571444360; Thu, 11 Oct 2018 13:09:13 +0200 (CEST) From: Vladimir Vassilev To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20181010.155915.278994099457235212.mbj@tail-f.com> <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com> <20181011.083904.763170181197608903.mbj@tail-f.com> Message-ID: <4996f333-f847-2a0c-1d0d-668408c576f5@transpacket.com> Date: Thu, 11 Oct 2018 13:09:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 11:09:18 -0000 On 10/11/18 11:43 AM, Vladimir Vassilev wrote: > > +1. This is one of the two necessary changes to make the=20 > instance-identifier type canonical. Proposed changes RFC 7950: > > OLD: > > 9.13.2.=C2=A0 Lexical Representation > > =C2=A0=C2=A0 An instance-identifier value is lexically represented as a= string. > =C2=A0=C2=A0 All node names in an instance-identifier value MUST be qua= lified with > =C2=A0=C2=A0 explicit namespace prefixes, and these prefixes MUST be de= clared in > =C2=A0=C2=A0 the XML namespace scope in the instance-identifier's XML e= lement. > > =C2=A0=C2=A0 Any prefixes used in the encoding are local to each instan= ce > =C2=A0=C2=A0 encoding.=C2=A0 This means that the same instance-identifi= er may be > =C2=A0=C2=A0 encoded differently by different implementations. > > 9.13.3.=C2=A0 Canonical Form > > =C2=A0=C2=A0 Since the lexical form depends on the XML context in which= the value > =C2=A0=C2=A0 occurs, this type does not have a canonical form. > > NEW: > > 9.13.2.=C2=A0 Lexical Representation > > =C2=A0=C2=A0 An instance-identifier value is lexically represented as a= string. > =C2=A0=C2=A0 All node names in an instance-identifier value MUST be qua= lified with > =C2=A0=C2=A0 explicit namespace prefixes where the module name is used = as prefix. > > =C2=A0=C2=A0 All predicates must appear in alphabetical order. > > > 9.13.3.=C2=A0 Canonical Form > > =C2=A0=C2=A0 Since the lexical form is encoding independent and tere is= prescribed > > =C2=A0=C2=A0 alphabetical order of the predicates the type has a canoni= cal form. The order of the keys does not need to be alphabetical. It can be the=20 order of the keys specified in the YANG module but currently there is no=20 requirement for order at all. Vladimir > > > Vladimir > > >> >> >> >> >> /martin >> >> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 Hmm, so you mean change the leaf "stream-xp= ath-filter" to say: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 o=C2=A0 The set of namespace declarations has one member=20 >>>> for each >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG module supported by the server.=C2=A0 Th= is member=20 >>>> maps >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 from the YANG module name to the YANG module=20 >>>> namespace. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 This means that in the XPath expression, the=20 >>>> module name >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 serves as the prefix. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 .... and then also give an example of this. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 This is probably what we need to do in all = places where=20 >>>> yang:xpath1.0 >>>> =C2=A0=C2=A0=C2=A0=C2=A0 is used, going forward.=C2=A0 Maybe even de= fine a new type >>>> =C2=A0=C2=A0=C2=A0=C2=A0 yang:xpath1.0-2 (name?) with the set of nam= espace declarations >>>> =C2=A0=C2=A0=C2=A0=C2=A0 built-in. >>>> >>> >>> We should avoid making off-the-shelf implementations of standards lik= e >>> XPath unusable. >>> At the very least this should be only available if the server=20 >>> supports it >>> (with a capability URI) >>> >>> >>> >>>> So we need an update to RFC7951? >>>> >>>> Regards, >>>> Reshad. >>>> >>>> >>> Andy >>> >>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 /martin >>>> >>>> >>>> >>>> >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > Lada >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > How is this supposed to work with JSON? >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > /martin >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > _______________________________________= ________ >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > netmod mailing list >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > netmod@ietf.org >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > > https://www.ietf.org/mailman/listinfo/n= etmod >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > -- >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > Ladislav Lhotka >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > Head, CZ.NIC Labs >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > PGP Key ID: 0xB8F92B08A9F76C67 >>>> =C2=A0=C2=A0=C2=A0=C2=A0 > >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0 ___________________________________________= ____ >>>> =C2=A0=C2=A0=C2=A0=C2=A0 netmod mailing list >>>> =C2=A0=C2=A0=C2=A0=C2=A0 netmod@ietf.org >>>> =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/netmo= d >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 11 04:16:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B64D130DD5 for ; Thu, 11 Oct 2018 04:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.955 X-Spam-Level: X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 CLpw_tTeNdB9 for ; Thu, 11 Oct 2018 04:16:53 -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 7392C130E47 for ; Thu, 11 Oct 2018 04:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24149; q=dns/txt; s=iport; t=1539256612; x=1540466212; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iy2I2KTOfQA+WpLRDDmKNTIlKdHcpJSB2C5aruhRM5k=; b=gUrX4868PSdKMx4HNp+w2kTQdE01ngRlWNY0lTEVSVZw9SK5HYgrCyqw ZRIyHCtP6o0JO0sVSeJMzKvZkuBwEytPJpezS5VQwQu5bZ3inht9s/Dys /O4Q79YUZeFuivJmuYBHydPqNuXDEHK6DffgxSHm4AjZKREW0sHW/lvpe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAACqML9b/xbLJq0XAUAKGgEBAQE?= =?us-ascii?q?BAgEBAQEHAgEBAQGBZQKBC4FdfyiDdYh1jT8lmHoNGAEKhANGAoR2OBYBAwE?= =?us-ascii?q?BAgEBAm0cDIU5AQEBAQIBAQEhBEcLEAsOCioCAicwBgoDBgIBAYMcAYF5CA+?= =?us-ascii?q?Idp0MezMfhFiEXgWLXIFBP4E5DIJfgxsBAYE2FYMXglcCiD2FdoVziRdTCZB?= =?us-ascii?q?OBheBT4dWhmyJFIZKhjSBWSGBVTMaCBsVO4JsixeFPz4wjGEBAQ?= X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208,217";a="7100597" 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; 11 Oct 2018 11:16:30 +0000 Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9BBGTHN014676; Thu, 11 Oct 2018 11:16:29 GMT To: Martin Bjorklund Cc: andy@yumaworks.com, netmod@ietf.org References: <20181011.122137.1647095802972927089.mbj@tail-f.com> <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> From: Robert Wilton Message-ID: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> Date: Thu, 11 Oct 2018 12:16:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181011.125007.434815114996317742.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------F0173358FD26197A1AA1B457" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [netmod] xpath expressions in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 11:16:56 -0000 This is a multi-part message in MIME format. --------------F0173358FD26197A1AA1B457 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/10/2018 11:50, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 11/10/2018 11:21, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund >>>> wrote: >>>> >>>>> Andy Bierman wrote: >>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) < >>>>> rrahman@cisco.com> >>>>>> wrote: >>>>>> >>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" < >>>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: >>>>>>> >>>>>>> Ladislav Lhotka wrote: >>>>>>> > Martin Bjorklund writes: >>>>>>> > >>>>>>> > > Hi, >>>>>>> > > >>>>>>> > > While reviewing restconf-notif, I saw this example: >>>>>>> > > >>>>>>> > > { >>>>>>> > > "ietf-subscribed-notifications:input": { >>>>>>> > > "stream": "NETCONF", >>>>>>> > > "stream-xpath-filter": "/ds:foo/", >>>>>>> > > "dscp": "10" >>>>>>> > > } >>>>>>> > > } >>>>>>> > > >>>>>>> > > Note the "stream-xpath-filter". It has a prefix in the XPath >>>>>>> string. >>>>>>> > > How are prefixes declared when JSON is used? >>>>>>> > > >>>>>>> > > The leaf "stream-xpath-filter" says: >>>>>>> > > >>>>>>> > > o The set of namespace declarations are those in >>>>>>> scope on >>>>>>> > > the 'stream-xpath-filter' leaf element. >>>>>>> > > >>>>>>> > > (I think I provided that text...) >>>>>>> > > >>>>>>> > > This assumes that the encoding is XML, or at leas that the >>>>> encoding >>>>>>> > > can somehow transfer namespace declarations. >>>>>>> > >>>>>>> > It can't. There are two options: >>>>>>> > >>>>>>> > 1. have different representations of this value in XML and JSON, >>>>>>> > analogically to instance indentifiers (sec. 6.11 in RFC 7951). >>>>>>> > >>>>>>> > 2. use a module name rather than a prefix in XML, too. >>>>>>> > >>>>>>> > I would suggest #2. >>>>>>> But that means making non-backwards compatible change to the XML >>>>>>> representation? >>>>>>> >>>>>> Not really. It means NETMOD WG would be creating its own special >>>>>> variant >>>>> of >>>>>> XPath. >>>>> Not at all. What I propose is perfectly fine, legal XPath 1.0. >>>>> >>>>> XPath 1.0 says that an XPath expression is evaluated in a context. >>>>> One item in the context is a set of mappings from to , >>>>> where is used to lookup prefixes used in the XPath >>>>> expression, e.g. in "/foo:interfaces" "foo" is the prefix. >>>>> >>>>> It is perfectly fine to say that the prefix mapping set is this: >>>>> >>>>> "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" >>>>> "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" >>>>> >>>>> and use that to evaluate the expression >>>>> >>>>> /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4 >>>>> >>>>> >>>>> >>>> The XPath expression is normally parsed within an XML instance >>>> document. >>>> There are "xmlns" attributes present that map the prefix to a >>>> namespace URI. >>>> These mappings will not be present in the JSON at all. >>>> >>>> A custom XPath implementation is required to magically identify the >>>> prefix >>>> as a module name and magically find the namespace URI for the module >>>> name. >>> I disagree. You need an XPath implementation + custom code to set up >>> the environment. >> This is OK, but can we just use the JSON encoding instance identifier >> format exactly?  I.e .RFC 7951 section 6.11. >> >> So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled" >> >> can trivially be expanded to: >> >> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled", >> >> and then interpreted with the context: >> "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces" >> "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip" > *this* would require a custom XPath implementation. Why?  I.e. how is this different from stating "Custom code is needed to connect things together"? > > and it is not obvious what the rules for the "auto-assignment" of > prefixes would be. For example: > > /ietf-interfaces//ietf-ip:address[../foo] > > what is the prefix for "foo"? OK, so here the module for "../foo" would need to be specified. Perhaps the rule that I'm looking for is the module name may be omitted when it matches the parent node module, and can easily be inferred.  I.e. so that for any XPath string, it is possible to trivially expand it without any additional schema context. It just seems to be that requiring the long hand of "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled" seems like it will get very verbose, and I wonder whether we are introducing yet another Xpath format to YANG. Finally, I'm trying to figure out have RFC 8040 query parameter (sect 4.8.4), which also uses XPath expressions is meant to work. That states: The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name and the namespace is as defined by the "namespace" statement in the YANG module. Yet the examples in section 8.3.6 don't seem to use namespace prefixes in very many places, e.g. why is it "/example-mod:event1/name='joe'" and not "/example-mod:event1/example-mod:name='joe'"?  Is the example wrong, or otherwise what am I missing? :-) Thanks, Rob > > > > /martin > > > >> Thanks, >> Rob >> >> >>> There is no standard XPath implementation that can just take an XML >>> instance document + YANG module and figure out what to do. Custom >>> code is needed to connect things together. This proposal doesn't >>> change this. >>> >>> >>> /martin >>> >>> >>>> A normal XPath implementation will not find any namespace mapping for >>>> the >>>> prefixes. >>>> >>>> An XPath expression has no concept of the "current module" inherited >>>> from >>>> the parent >>>> like the JSON encoding. This is problematic for predicates >>>> >>>> /ietf-interfaces:interfaces/interface[name='eth0'] >>>> >>>> XPath says the missing prefixes for 'interface' and 'name' are simply >>>> missing (no namespace). >>>> The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and >>>> 'interface'. >>>> There is no specification for the 'name' node inside a predicate. >>>> >>>> So you must mean the full module name will be used at every node: >>>> >>>> /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0'] >>>> >>>> >>>> >>>>> /martin >>>>> >>>>> >>>> Andy >>>> >>>> >>>>>>> Hmm, so you mean change the leaf "stream-xpath-filter" to say: >>>>>>> >>>>>>> o The set of namespace declarations has one member for >>>>> each >>>>>>> YANG module supported by the server. This member maps >>>>>>> from the YANG module name to the YANG module namespace. >>>>>>> >>>>>>> This means that in the XPath expression, the module >>>>> name >>>>>>> serves as the prefix. >>>>>>> >>>>>>> .... and then also give an example of this. >>>>>>> >>>>>>> This is probably what we need to do in all places where >>>>> yang:xpath1.0 >>>>>>> is used, going forward. Maybe even define a new type >>>>>>> yang:xpath1.0-2 (name?) with the set of namespace declarations >>>>>>> built-in. >>>>>>> >>>>>> We should avoid making off-the-shelf implementations of standards like >>>>>> XPath unusable. >>>>>> At the very least this should be only available if the server supports >>>>>> it >>>>>> (with a capability URI) >>>>>> >>>>>> >>>>>> >>>>>>> So we need an update to RFC7951? >>>>>>> >>>>>>> Regards, >>>>>>> Reshad. >>>>>>> >>>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>>> /martin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > Lada >>>>>>> > >>>>>>> > > >>>>>>> > > How is this supposed to work with JSON? >>>>>>> > > >>>>>>> > > >>>>>>> > > /martin >>>>>>> > > >>>>>>> > > _______________________________________________ >>>>>>> > > netmod mailing list >>>>>>> > > netmod@ietf.org >>>>>>> > > https://www.ietf.org/mailman/listinfo/netmod >>>>>>> > >>>>>>> > -- >>>>>>> > Ladislav Lhotka >>>>>>> > Head, CZ.NIC Labs >>>>>>> > PGP Key ID: 0xB8F92B08A9F76C67 >>>>>>> > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > . > --------------F0173358FD26197A1AA1B457 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/10/2018 11:50, Martin Bjorklund wrote:
Robert Wilton <rwilton@cisco.com> wrote:


On 11/10/2018 11:21, Martin Bjorklund wrote:

Andy Bierman <andy@yumaworks.com> wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <mbj@tail-f.com>
wrote:


Andy Bierman <andy@yumaworks.com> wrote:

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <

rrahman@cisco.com>

wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:

     Ladislav Lhotka <lhotka@nic.cz> wrote:
     > Martin Bjorklund <mbj@tail-f.com> writes:
     >
     > > Hi,
     > >
     > > While reviewing restconf-notif, I saw this example:
     > >
     > >    {
     > >       "ietf-subscribed-notifications:input": {
     > >          "stream": "NETCONF",
     > >          "stream-xpath-filter": "/ds:foo/",
     > >          "dscp": "10"
     > >       }
     > >    }
     > >
     > > Note the "stream-xpath-filter".  It has a prefix in the XPath
string.
     > > How are prefixes declared when JSON is used?
     > >
     > > The leaf "stream-xpath-filter" says:
     > >
     > >               o  The set of namespace declarations are those in
scope on
     > >                  the 'stream-xpath-filter' leaf element.
     > >
     > > (I think I provided that text...)
     > >
     > > This assumes that the encoding is XML, or at leas that the

encoding

     > > can somehow transfer namespace declarations.
     >
     > It can't. There are two options:
     >
     > 1. have different representations of this value in XML and JSON,
     >    analogically to instance indentifiers (sec. 6.11 in RFC 7951).
     >
     > 2. use a module name rather than a prefix in XML, too.
     >
     > I would suggest #2.
<RR> But that means making non-backwards compatible change to the XML
representation?


Not really. It means NETMOD WG would be creating its own special
variant

of

XPath.

Not at all.  What I propose is perfectly fine, legal XPath 1.0.

XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from <prefix> to <uri>,
where <prefix> is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the prefix.

It is perfectly fine to say that the prefix mapping set is this:

    "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
    "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"

and use that to evaluate the expression

   /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4




The XPath expression is normally parsed within an XML instance
document.
There are "xmlns" attributes present that map the prefix to a
namespace URI.
These mappings will not be present in the JSON at all.

A custom XPath implementation is required to magically identify the
prefix
as a module name and magically find the namespace URI for the module
name.

I disagree.  You need an XPath implementation + custom code to set up
the environment.

This is OK, but can we just use the JSON encoding instance identifier
format exactly?  I.e .RFC 7951 section 6.11.

So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"

can trivially be expanded to:

"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",

and then interpreted with the context:
     "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
   "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"

*this* would require a custom XPath implementation.
Why?  I.e. how is this different from stating "Custom code is needed to connect things together"?


and it is not obvious what the rules for the "auto-assignment" of
prefixes would be.  For example:

  /ietf-interfaces//ietf-ip:address[../foo]

what is the prefix for "foo"?
OK, so here the module for "../foo" would need to be specified.

Perhaps the rule that I'm looking for is the module name may be omitted when it matches the parent node module, and can easily be inferred.  I.e. so that for any XPath string, it is possible to trivially expand it without any additional schema context.

It just seems to be that requiring the long hand of "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled" seems like it will get very verbose, and I wonder whether we are introducing yet another Xpath format to YANG.

Finally, I'm trying to figure out have RFC 8040 query parameter (sect 4.8.4), which also uses XPath expressions is meant to work.  That states:

The set of namespace declarations is the set of prefix and
      namespace pairs for all supported YANG modules, where the prefix
      is the YANG module name and the namespace is as defined by the
      "namespace" statement in the YANG module.

Yet the examples in section 8.3.6 don't seem to use namespace prefixes in very many places, e.g. why is it "/example-mod:event1/name='joe'" and not "/example-mod:event1/example-mod:name='joe'"?  Is the example wrong, or otherwise what am I missing? :-)

Thanks,
Rob





/martin




Thanks,
Rob
 


There is no standard XPath implementation that can just take an XML
instance document + YANG module and figure out what to do.  Custom
code is needed to connect things together.  This proposal doesn't
change this.


/martin



A normal XPath implementation will not find any namespace mapping for
the
prefixes.

An XPath expression has no concept of the "current module" inherited
from
the parent
like the JSON encoding. This is problematic for predicates

    /ietf-interfaces:interfaces/interface[name='eth0']

XPath says the missing prefixes for 'interface' and 'name' are simply
missing (no namespace).
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and
'interface'.
There is no specification for the 'name' node inside a predicate.

So you must mean the full module name will be used at every node:

  /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']




/martin



Andy




                

                  
     Hmm, so you mean change the leaf "stream-xpath-filter" to say:

              o  The set of namespace declarations has one member for


                

              

              
each


              

                

                  
                 YANG module supported by the server.  This member maps
                 from the YANG module name to the YANG module namespace.

                 This means that in the XPath expression, the module


                

              

              
name


              

                

                  
                 serves as the prefix.

     .... and then also give an example of this.

     This is probably what we need to do in all places where


                

              

              
yang:xpath1.0


              

                

                  
     is used, going forward.  Maybe even define a new type
     yang:xpath1.0-2 (name?) with the set of namespace declarations
     built-in.



                

                
We should avoid making off-the-shelf implementations of standards like
XPath unusable.
At the very least this should be only available if the server supports
it
(with a capability URI)





                

                  
<RR> So we need an update to RFC7951?

Regards,
Reshad.




                

                
Andy




                

                  
     /martin





     >
     > Lada
     >
     > >
     > > How is this supposed to work with JSON?
     > >
     > >
     > > /martin
     > >
     > > _______________________________________________
     > > netmod mailing list
     > > netmod@ietf.org
     > > https://www.ietf.org/mailman/listinfo/netmod
     >
     > --
     > Ladislav Lhotka
     > Head, CZ.NIC Labs
     > PGP Key ID: 0xB8F92B08A9F76C67
     >

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


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



                

              

            

          

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



        

        

      

      
.



    

    

  


--------------F0173358FD26197A1AA1B457--


From nobody Thu Oct 11 05:37:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE2130E64 for ; Thu, 11 Oct 2018 05:37: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 qH4xKa69fHoY for ; Thu, 11 Oct 2018 05:37:48 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 143AA130E62 for ; Thu, 11 Oct 2018 05:37:45 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id t22-v6so6557368lfb.7 for ; Thu, 11 Oct 2018 05:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOc9ECJCNRc/XwS0f1JVN702AN1z1ccPJQVmokBDyqw=; b=zy+IMXXuAJJ+E7eHBSvk+sg19BW0wM0/9HbaJhBbzurJJHPkyQg2ZAD+g1ZVpdKPYV AEvVQHcuSwKAySkMj3ad0AmD/FuduslGRe787BL4f4AECir72DGmjTKBxs5qN1P2yycZ h7muAOJGBFWNMKX34Of3m4zqig2qJyC1see2ul9z13EXr68SHhSoa4XFVL+oktabOGNa etXm74/0aZ08gO4+gFnLyiV4TR3V3usD4GjzBb1TmBhPqxR0eOFKFi20Jh/ldH5WxGCw ezZI/khWclvOHckDfBokXycVvQldtFG1JlFYsnmlVdiTd+Os9oigdP3EJdc5JrLCvC3w zeVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IOc9ECJCNRc/XwS0f1JVN702AN1z1ccPJQVmokBDyqw=; b=cMGLxCaHYBDrwy21tHm9D0UQ25TmesL8v530ijhQ8NzONtFX5+eAmhjIye0v42lpCG NS0ieL0Tm9j9d2CJQMfuh441q4bqqWxbNbDdM0UBgl6SsM5eenlMjnIAGLQtPD2GUiEb 8RbPiJp1Q5M0fLdxMyGZ/O7dJBreNUhjdrpSI3P0FPYx6fhA56FkyiM6bpy4lpURTgSU xaUxl9QQ4U9KDov2NKDOJDSRDnfcSZ4RTIhNR6Fs/DNopZ+19SPfOlOLBBAFrRun6rv7 hvcY86XwKs3U3P3+ophO8/e0q5ZhQB6jKUtSo00Y8PG5EqgEbTJWzVP1GKcxbdKLizdd NUOA==
X-Gm-Message-State: ABuFfohWDczvMhtaEDqf4Ag9IBYMFTwRTvfEHZa/q+H1K54ZWFWux9FT MFqNdCGHjlkUbHMFlWeKv/0KH9GSCXfMPeREW8r98w==
X-Google-Smtp-Source: ACcGV6154nbDpjcoau0ipB0bS6735krYHHpcseWhrwzdDZjWGikNh0i8ym7b58zrf3Q0B8qqW1vUd9QS7fTJTDExo68=
X-Received: by 2002:a19:7391:: with SMTP id h17-v6mr1083146lfk.140.1539261462966;  Thu, 11 Oct 2018 05:37:42 -0700 (PDT)
MIME-Version: 1.0
References:  <20181010.153831.1958991667250114039.mbj@tail-f.com>  <20181011.091817.1727547509052700274.mbj@tail-f.com>
In-Reply-To: <20181011.091817.1727547509052700274.mbj@tail-f.com>
From: Eric Rescorla 
Date: Thu, 11 Oct 2018 05:37:09 -0700
Message-ID: 
To: =?UTF-8?Q?martin_bj=C3=B6rklund?= 
Cc: IESG , NetMod WG Chairs , NetMod WG ,  joel jaeggli , draft-ietf-netmod-schema-mount@ietf.org,  Kent Watsen , Lou Berger 
Content-Type: multipart/alternative; boundary="000000000000b78bba0577f33c52"
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 12:37:52 -0000

--000000000000b78bba0577f33c52
Content-Type: text/plain; charset="UTF-8"

That seems like it's going to have some pretty surprising consequences and
at minimum needs more information in the Security Considerations.

On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  wrote:

> Eric Rescorla  wrote:
> > I'm sorry but I don't understand this.
> >
> > Does the externally visible behavior of any mounted module depend in any
> > way on these XPATH references
>
> Yes, but note that these XPath expressions ("parent-reference") are
> read-only (config false in the YANG model).  Thus they are set by the
> implementation, and used to inform the operator about the environment
> in which other XPath expressions are evaluated.
>
>
> /martin
>
>
> >
> > -Ekr
> >
> >
> >
> >
> > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund  wrote:
> >
> > > Eric Rescorla  wrote:
> > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund 
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Eric Rescorla  wrote:
> > > > > > Eric Rescorla has entered the following ballot position for
> > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > >
> > > > > > When responding, please keep the subject line intact and reply
> to all
> > > > > > email addresses included in the To and CC lines. (Feel free to
> cut
> > > this
> > > > > > introductory paragraph, however.)
> > > > > >
> > > > > >
> > > > > > Please refer to
> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > >
> > > > > >
> > > > > > The document, along with other ballot positions, can be found
> here:
> > > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > ----------------------------------------------------------------------
> > > > > > DISCUSS:
> > > > > >
> > > ----------------------------------------------------------------------
> > > > > >
> > > > > > Rich version of this review at:
> > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > >
> > > > > >
> > > > > >
> > > > > > DETAIL
> > > > > > S 4.
> > > > > > >
> > > > > > >      It is worth emphasizing that the nodes specified in
> > > > > > >      "parent-reference" leaf-list are available in the mounted
> > > schema
> > > > > only
> > > > > > >      for XPath evaluations.  In particular, they cannot be
> accessed
> > > > > there
> > > > > > >      via network management protocols such as NETCONF
> [RFC6241] or
> > > > > > >      RESTCONF [RFC8040].
> > > > > >
> > > > > > What are the security implications of this XPath reference
> outside
> > > the
> > > > > > mount jail? Specifically, how does it interact with the access
> > > control
> > > > > > for the enclosing module.
> > > > >
> > > > > There is no such interaction, since access control comes into play
> > > > > when some external entity accesses the data through some management
> > > > > protocol, and the nodes from the "parent-reference" expressions
> cannot
> > > > > be accessed via management protocols.
> > > > >
> > > > > The last sentence of the quoted paragraph was supposed to make this
> > > > > clear, but it seems we might need some additional explanation?
> > > > >
> > > >
> > > > Yes, I think so. I guess I'm not clear on what the XPath expressions
> are
> > > > for if they
> > > > can't be accessed via the management protocols. How can they be used?
> > >
> > > These are XPath expressions defined in the YANG models themselves,
> > > such as "must" expressions or "leafrefs".   The description of
> > > "parent-reference" refer to them as:
> > >
> > >                [...] XPath
> > >                expressions whose context nodes are defined in the
> > >                mounted schema
> > >
> > >
> > >
> > > /martin
> > >
>

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


That seems like it's going to have some pretty surpris=
ing consequences and at minimum needs more information in the Security Cons=
iderations.

On Thu=
, Oct 11, 2018 at 12:18 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Eric Rescorla <ekr@rtfm.com> wrote:

> I'm sorry but I don't understand this.

> 

> Does the externally visible behavior of any mounted module depend in a=
ny

> way on these XPATH references



Yes, but note that these XPath expressions ("parent-reference") a=
re

read-only (config false in the YANG model).=C2=A0 Thus they are set by the<=
br>
implementation, and used to inform the operator about the environment

in which other XPath expressions are evaluated.





/martin





> 

> -Ekr

> 

> 

> 

> 

> On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> 

> > Eric Rescorla <ekr@rtfm.com> wrote:

> > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund <mbj@tail-f.com> wrote:<=
br>
> > >

> > > > Hi,

> > > >

> > > > Eric Rescorla <ekr@rtfm.com> wrote:

> > > > > Eric Rescorla has entered the following ballot pos=
ition for

> > > > > draft-ietf-netmod-schema-mount-11: Discuss

> > > > >

> > > > > When responding, please keep the subject line inta=
ct and reply to all

> > > > > email addresses included in the To and CC lines. (=
Feel free to cut

> > this

> > > > > introductory paragraph, however.)

> > > > >

> > > > >

> > > > > Please refer to

> > > > https://www.ietf.org/ie=
sg/statement/discuss-criteria.html

> > > > > for more information about IESG DISCUSS and COMMEN=
T positions.

> > > > >

> > > > >

> > > > > The document, along with other ballot positions, c=
an be found here:

> > > > > https://dat=
atracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

> > > > >

> > > > >

> > > > >

> > > > >

> > -----------------------------------------------------------------=
-----

> > > > > DISCUSS:

> > > > >

> > -----------------------------------------------------------------=
-----

> > > > >

> > > > > Rich version of this review at:

> > > > > https://mozphab-ietf.devsvcd=
ev.mozaws.net/D3506

> > > > >

> > > > >

> > > > >

> > > > > DETAIL

> > > > > S 4.

> > > > > >

> > > > > >=C2=A0 =C2=A0 =C2=A0 It is worth emphasizing t=
hat the nodes specified in

> > > > > >=C2=A0 =C2=A0 =C2=A0 "parent-reference&qu=
ot; leaf-list are available in the mounted

> > schema

> > > > only

> > > > > >=C2=A0 =C2=A0 =C2=A0 for XPath evaluations.=C2=
=A0 In particular, they cannot be accessed

> > > > there

> > > > > >=C2=A0 =C2=A0 =C2=A0 via network management pr=
otocols such as NETCONF [RFC6241] or

> > > > > >=C2=A0 =C2=A0 =C2=A0 RESTCONF [RFC8040].

> > > > >

> > > > > What are the security implications of this XPath r=
eference outside

> > the

> > > > > mount jail? Specifically, how does it interact wit=
h the access

> > control

> > > > > for the enclosing module.

> > > >

> > > > There is no such interaction, since access control come=
s into play

> > > > when some external entity accesses the data through som=
e management

> > > > protocol, and the nodes from the "parent-reference=
" expressions cannot

> > > > be accessed via management protocols.

> > > >

> > > > The last sentence of the quoted paragraph was supposed =
to make this

> > > > clear, but it seems we might need some additional expla=
nation?

> > > >

> > >

> > > Yes, I think so. I guess I'm not clear on what the XPath=
 expressions are

> > > for if they

> > > can't be accessed via the management protocols. How can =
they be used?

> >

> > These are XPath expressions defined in the YANG models themselves=
,

> > such as "must" expressions or "leafrefs".=C2=
=A0 =C2=A0The description of

> > "parent-reference" refer to them as:

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...] XPat=
h

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expression=
s whose context nodes are defined in the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mounted sc=
hema

> >

> >

> >

> > /martin

> >




--000000000000b78bba0577f33c52--


From nobody Thu Oct 11 07:44:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45E6130EA2 for ; Thu, 11 Oct 2018 07:44:00 -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 oyMcNx2Fb6s9 for ; Thu, 11 Oct 2018 07:43:59 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 5FA19130E9E for ; Thu, 11 Oct 2018 07:43:59 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id n5-v6so6775766ioh.5 for ; Thu, 11 Oct 2018 07:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Xmsyptp9wiyRPz1zwE0ef+GpCqHy9BAU2RMouEU+6go=; b=n6iP/NjyamJCWn+lmQ+jFFfW7o+lVEISg28eYzFPtZfVL0WNPnJamazz3JnP2nn2e/ NL6OlmATVNKbsCSosahAWTNCSHvlGxbEqJfFf2XgY0Je9hTZ+MXLYLMf98PiQjr/MNv+ Zu9SsY33KQLBDj+HgHF5pFlBNWBnIXjELypOzGlVzDF8xur9WidZbh6Vu4pKJa0edyEn 5GiZbuuDM3MWS8SD8XFMSwg/MaN3ozA9mAaYp8mkqH4TnSA5CQKZAGKPu0APaGpHbAa8 VAravy6ZlrYIjaTevOSwZIDnc4U4GDqxKZ9o0lk6I0eB+z7sMQa9Wz69KUx9PrIorBTM Ly4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Xmsyptp9wiyRPz1zwE0ef+GpCqHy9BAU2RMouEU+6go=; b=dqJrxxgBGXfuBrtNbtIV/z1UZJHTeagh8AceLDeISBS4vTUJRcJT5bIjj7BNUdOHqE XGy2qoBaTLbh//RV8TE1UgNwFA8ABdByjLMH1KJJmVhiwuQQaSaLBPW8Y6B834Bq9BIq 60sLiUDrn2gmindt4iqroFwLi9RMr5vESlQGKN1lintVT+Rw0zmfNS1ISMApc3b0Mafc BMb/ySlFhHDDeIvHJNth1JOz59iZPXV55LKBnRpSEuo630kkhTVEWh3CCR1reJqnyfWW 9kQCLsQJlN5IYtXDXBBtu5a2abfT/fGumLN8MHgmhHfEuZPIKObP2/GiXIjNzwnQazzm wChA==
X-Gm-Message-State: ABuFfoi+/2h8h8c67kA9A4GR5DSC0BveBaI3bXFNyCQWNXkxYoeD2E2r 7Mx9rZRL/SJeyVmviDGpe6Y=
X-Google-Smtp-Source: ACcGV61T7gOePSeV08v+R1JF2BzNySgIC0BjFD8q1CvnnflnFy37pXQo6eirmtUzSHiNMDm0egamSg==
X-Received: by 2002:a6b:bf43:: with SMTP id p64-v6mr1221770iof.41.1539269038547;  Thu, 11 Oct 2018 07:43:58 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:dc6b:6218:31f6:98b9? ([2601:647:4700:1280:dc6b:6218:31f6:98b9]) by smtp.gmail.com with ESMTPSA id h66-v6sm8949108ita.22.2018.10.11.07.43.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 07:43:58 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: <2DC2347C-3029-4033-BC35-9F308201ADF4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1F189172-2DA4-4F2B-B7F1-C43C7C23DEAD"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 11 Oct 2018 07:43:55 -0700
In-Reply-To: <20181011.085131.1823310178537216646.mbj@tail-f.com>
Cc: jernej.tuljak@mg-soft.si, netmod@ietf.org
To: Martin Bjorklund 
References:  <20181008.145313.1979034555219874418.mbj@tail-f.com>  <20181011.085131.1823310178537216646.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Place to download Standard YANG Modules ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 14:44:01 -0000

--Apple-Mail=_1F189172-2DA4-4F2B-B7F1-C43C7C23DEAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
>=20
> I just which there was a one-click way (or better some repo) to get
> all files.

There is. Benoit had written it, but for the life of me I cannot =
remember what it is called. Have send him a note, but he is offline till =
Nov.

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_1F189172-2DA4-4F2B-B7F1-C43C7C23DEAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Oct 10, 2018, at 11:51 PM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

I just which there was a =
one-click way (or better some repo) to get
all files.

There is. Benoit had written it, but for the life =
of me I cannot remember what it is called. Have send him a note, but he =
is offline till Nov.



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_1F189172-2DA4-4F2B-B7F1-C43C7C23DEAD--


From nobody Thu Oct 11 08:05:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA94F130DF3 for ; Thu, 11 Oct 2018 08:05:05 -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, 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 r91m4IKC4bd3 for ; Thu, 11 Oct 2018 08:05:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 91E9F130DE6 for ; Thu, 11 Oct 2018 08:05:04 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 43C581AE0310; Thu, 11 Oct 2018 17:05:00 +0200 (CEST)
Date: Thu, 11 Oct 2018 17:04:59 +0200 (CEST)
Message-Id: <20181011.170459.1195717619306547806.mbj@tail-f.com>
To: mjethanandani@gmail.com
Cc: jernej.tuljak@mg-soft.si, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <2DC2347C-3029-4033-BC35-9F308201ADF4@gmail.com>
References:  <20181011.085131.1823310178537216646.mbj@tail-f.com> <2DC2347C-3029-4033-BC35-9F308201ADF4@gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Place to download Standard YANG Modules ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 15:05:06 -0000

Mahesh Jethanandani  wrote:
> 
> 
> > On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
> > 
> > I just which there was a one-click way (or better some repo) to get
> > all files.
> 
> There is. Benoit had written it, but for the life of me I cannot
> remember what it is called.

I meant from IANA.  3rd party mirrored repos are fine, but it would be
nice to get them directly from IANA in a simple way.


/martin


From nobody Thu Oct 11 08:24:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520B6130DD3 for ; Thu, 11 Oct 2018 08:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.032
X-Spam-Level: 
X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=cpJc3pjT; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=AaTppRh2
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 I51H3cbqePrI for ; Thu, 11 Oct 2018 08:24:32 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 C92A1130DF3 for ; Thu, 11 Oct 2018 08:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539271470; x=1541863470; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HFWvU0SCVLTQmC2gnTvADR6zYklYE8XgwBXDLDKD4Mw=; b=cpJc3pjTBbxXLSXbaqq60nIi9gRJS94uS1PGlNNl88P3efC5uEaIupJvPV4b5IA7 lBzeafXsuntA7ubFg7UtQ4g74rwrHoZOBtCzPFaSMiZi0T+RTLWXAe+Z6JK2TcX8 uUZOHls5i2GUMdhqfQwn6AIDOj5iTBao+vuzdYJkGoU=;
X-AuditID: c1b4fb25-573ff700000018b4-f8-5bbf6b2e8de0
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.A3.06324.E2B6FBB5; Thu, 11 Oct 2018 17:24:30 +0200 (CEST)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 11 Oct 2018 17:24:29 +0200
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 11 Oct 2018 17:24:29 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TS3ZvQwOGUFrKW8tSbzG7eOmNt/8Mc+JJs2+ZK1YAB0=; b=AaTppRh262LtfMfBNSStHB1Qo0BgS/2/ug4oRmcpM/THslS5myZW0XufzQcOkt6CQAPZ+rATkFo13bWeewI/wvHf8fYS4Kb04RnYaHfsilkiRW7iKgmL+ueVKw0AgRevXZZO1CelbFmu/j25+n9tbjfhnIvSAGY2MsjGQdyJ8H0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.1] (89.135.192.225) by DB6PR0701MB2728.eurprd07.prod.outlook.com (2603:10a6:4:24::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.11; Thu, 11 Oct 2018 15:24:28 +0000
To: Kent Watsen , Martin Bjorklund 
CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
References:  <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> <20181009.142506.637283350958767455.mbj@tail-f.com> <9e389747-74ed-0f62-24ce-813ce3cdc870@ericsson.com> <652D49CE-6469-412F-B708-D8496DFC0F16@juniper.net>
From: Balazs Lengyel 
Message-ID: 
Date: Thu, 11 Oct 2018 17:24:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <652D49CE-6469-412F-B708-D8496DFC0F16@juniper.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030102080105010003070206"
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: PR2P264CA0027.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101:1::15) To DB6PR0701MB2728.eurprd07.prod.outlook.com (2603:10a6:4:24::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 61eeca56-98eb-48cd-74b7-08d62f8da2bd
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2728; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2728; 3:mna1RQKKo2zWe/TfjpolmLATZ44pSbupuYIWRldyC2ysLkOZ2Tzc9sfohNM8FAHkM2OkdmipS0x+4P0SIa0mMQ5sQs3fK65tO5/DvKAwRo0Som9SPga2VdfFude+qViG2kWgRp8oegFmHxvZYri4mTlUW5fc2aciQftnyQshiM++elvtM8oD17Hp0qbZizohjjJ0rVw5gTiLuSZ4bMtgH3KwyQiYjdqGM5pOvyl99pZsyqYJe3N/z2QQUdxrhUty; 25:e09a4O/diQ03VDXo0qw8786GAmMuBk1BnVpRAd4dkMhfQBLgPyOphG5iLS+c9OfyzclmP9PeXx3/VGo3mTHavRsEg7aLttk9vKCpsZ8kcXJpaPYlZCOeF9MJ1FRLMKU8AsIPsOePxIk/THmHFaFIjV89+ou222gsDOGkc8zoSlI+ahyYm9wB3WklzkpO7v7SgLVs4jT85tLiJ6k0ZbUJlr8Gk4aMs6n/3zp9TnLF0+X0Fao2iI/zYw9WybXQa6k/Gw4BwD3qJFwwEtv96kE3suepKq6RiMStGRw2fUuCcwvyywXeDRCl6yn0dRpTLGbx2QUc2qWsGwkDuzaKnb4zhg==; 31:cBvNtFcFlfgM+8X02gffsccvJraj97ayQR3qEXt7RktnHa29dvqCPyqjWkAFknWDiHwFb9X0OkYeHdOEWHcRc5oWLhblO8czq+86xiUUnMQ1pXk30/n5V6g1NiwTPnSsfCNaO90Bc+hYPyUMXcarqHTQ7c9tSmAWPcG71cPFkrzE8MDG6N8byZsf6fCl4kLnL59Kd49VvNHc6OxGavnykBlOoRelsHTKfiwvwM7pPYQ=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2728:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2728; 20:psCQ3PiLMtEWcnEAeSNe6XBhvk577EtgwolyG472TJnOKBOue3WqxWH6oLKoTCxboqvY1fX0vrahp2EPH0v6R6o1ApBsOKLBhn4sZ4K8YRADYRg40cqzk2ABs/621n2/ELzCddC+uN/WV+cixNuM/sXj84isiXe9gFC19YllgpbKiu7PbaRHpzzrkd20/H1XgLD4KN85N+wEfM0dwLVb56p1ebF878nRdtuAu/K6Whn4ilV0Q4zELvsVXcFdvXAiz9MgAb4BmQM1vFWtkvjxl0ar8KgfT7/Ai/Dir9vhI6LsU9vKVXXC+Tqcz3CYBgpYrP8BefH89umWXg01GsyLzkk/aXYkGkjrjgokonrJ+uHJqDIQzf787+i+2JN4g5qqZX4Q22kypLwOq3DL3piQxyqRYKKvUs9qoOFnoxv/QLu5A8XhlVOUcdSca3cIaCk/uTvw3+ySVbPoUFewXtOFf6L4fIcCf4FMwgOZSbYT8HdDREunfXD6vftMw8BIXmHW; 4:lIyILoIlV8tf2YgYSiPVbBzj65P+xpXw1NofEOU4MDY+KguV4wtZp5H8bU8NdSZlnqqL0ZIBbeq62zu20RCMveyfzq1W0TA5ClxznbU5RPMkgB/zKevLuUUXE+4wEOWFmH8gBL/QKeq0e8dGB6wPvPIbeNRBAzYPVUjstKtcB5xvv/xFgzXAAX0lZk8JQ7fP/jxEJpaAAqa0ooGd/aY3zSeuZZXMoJSsudUqRd5ADc+n99D03xi4cJmvytBcJnBUmPixQs9WvhKd9NBSNAO/R8inb/hsPvCq3KTSr6jFv8lqFjA/xNEflZtFgNLyY15QtBLhNAqWXBsrOR3ON9e3I76vQ1MfucftvgPiNQFPeJiP9YezwgeZfX9zuZHMNprWaPkVUeXsaUJd6IPzMkKg2TGvkcbE/nZfTfXLVKYggUQ=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(248295561703944)(37575265505322)(138986009662008); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051); SRVR:DB6PR0701MB2728; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2728; 
X-Forefront-PRVS: 08220FA8D6
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(376002)(39860400002)(396003)(136003)(346002)(252514010)(13464003)(189003)(199004)(5660300001)(65826007)(2616005)(53936002)(3846002)(386003)(11346002)(84326002)(236005)(956004)(53546011)(476003)(36756003)(2906002)(6116002)(606006)(6666004)(446003)(1941001)(486006)(68736007)(8936002)(81156014)(6246003)(71190400001)(97736004)(25786009)(8676002)(44832011)(316002)(81166006)(3260700006)(4326008)(16576012)(478600001)(6486002)(16526019)(49976009)(54906003)(93886005)(5024004)(14444005)(16586007)(26005)(58126008)(64126003)(110136005)(65806001)(66574009)(31686004)(66066001)(229853002)(186003)(568964002)(6306002)(76176011)(33964004)(65956001)(106356001)(31696002)(105586002)(52116002)(7736002)(86362001)(966005)(54896002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2728; H:[159.107.197.1]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR0701MB2728; 23:kLKGfOAPDREtwRUWN/ZNR8ofWGcj2qFkO1srF/6?= =?us-ascii?Q?oa4/7BL933XioA9VFoaUC8FaBxaBKdm3rjg/iNzG4gvqVOrw5aSCOT0OvYOM?= =?us-ascii?Q?tYoLVvxAFTqhv97rSFKsJywzL9s5V8/X5+Q7FddzmPxAViNypvjwv0nCPPGE?= =?us-ascii?Q?zhkyh0zhr/O6yBDT60mhBj58GtrtVT9tuuQrjVLnh8XhgHx2lDPRolmNGiks?= =?us-ascii?Q?PsWURcxqdiJ7o3bcSQE3I5TxAjsxr8ONENreYLuFGjICtDjJkHo8oYVY6/IK?= =?us-ascii?Q?zdb+jL7LnGMn5b8VX28HgkzeJoIByc9n1wm+Nub7D6r1gh0Uu9KyD2iR2/su?= =?us-ascii?Q?c3W3HVQdIwSpErWfC51UqC67mKM+dnKYM2a/TleXki5dITlIZBbkQ4+7M7Yu?= =?us-ascii?Q?aa5o2WMfD6qqJOkKiZ0mORzE1bjV+OZfCSUVKZ/BIvEBxUmsZWqq1yFizSXU?= =?us-ascii?Q?rQVlLd5+0y2poblkrZr2O5/VU5SB6qsk9cJS96Ae4wl6MctwVL7lWt42p6vq?= =?us-ascii?Q?N3cKhtCSIei3kLmLv3Z/LhWKjeLx17pTDxsa7W/Ku/nVW+vCQxmOwmIZWlFk?= =?us-ascii?Q?7yjFLor4DmAmMT6Qk8oNSHGBReYVIA2omgpvRJagH/B9o89Y7ow63AurltqX?= =?us-ascii?Q?lU2wInE+WD8onL1fm3K9EvCpDdXsHdUjwFKyva4/88HQEBsTdfPKE4fjE8nN?= =?us-ascii?Q?Ukjc5veOYpVGitKAoA3nMX5FWg1DU6OMGvl9zIt1AXeKUPJOC4TVuYVBUARN?= =?us-ascii?Q?Fl3wLLqyjRVpe4+/G4YWNMgsB0LJCPjS2WphoHGKZMfKiob7j8jmt7DUCHEl?= =?us-ascii?Q?Palnjv24VzwQGvhYjTxXPqXOhBlb2C2BmBhqptWbqFZvT2as3lkKgrdyioge?= =?us-ascii?Q?GqijbFU5+pi7wvkHkuhTAyaL1vgkGHOGDodHQVlvN4+moiq5vFHjMiWlI6Hi?= =?us-ascii?Q?IRE6TaDQmGrITxwnOoakVUhMDI1YygNnNzl8m7Fbft/CuT0wgofNFYF3XOz0?= =?us-ascii?Q?jMIilPtGH3hlgOPisqi64muFPoatoj3NJjkT6kJ1h5axMLThfhYaBxx3SZMK?= =?us-ascii?Q?eJKn9Fn81valIbm7EvKR8C4BGyLZ2H6P5/O9aB+yNas7n0LCy6Ydd5hnXRbF?= =?us-ascii?Q?OT/ZJR6VBWXnXlGYEAkydcWhNxOvnADb1aZeZPa+4DtUXiV2GAIXNuxGQudN?= =?us-ascii?Q?x8Zt6O2wdIuBtqyuyBEkt6apLNrNyTWYM9udR6fD8cLNjBxQ80NXMbZdpfad?= =?us-ascii?Q?SwYcxRe/QFYtfOIsEN97py4IR56LBt3mxKXxxHHUlee0MNxwGi+zYWuXh9mK?= =?us-ascii?Q?VAbdGIMPh90bLKYxYmUpK5xpMPEuPGFda4aY0Y9s+FM4/1gi5a0eUklO5cg0?= =?us-ascii?Q?Gk/dgEomhPNE3TZoS3J5uMbYmgy9XCxK73qDyIkX2hqaUlI2MVaDtyniJBi3?= =?us-ascii?Q?Xh224y15jXAyQd/eo9ZTj8BqNK+j0uUhvMo0Yfsr4yKhFJ7GHOMRvHzVey/C?= =?us-ascii?Q?4IUMvcqagni+P1lUmvkt2tZW8BlG6gt00xgfEL2CNINbHsHPIY2dkFfaQdy1?= =?us-ascii?Q?nCB4/jzHoP5S+MrVSydpjW+K+0aqIuxyjkGUoRSRmC3lFE0DwGyBtObiZJbK?= =?us-ascii?Q?T0BjQRQ7rotWsKuCPryBhLGmEcySMY74Jyx+Ruvmf64fnDfQjiT7/UF1Ccjf?= =?us-ascii?Q?pcsJ9jKvMhD3YFJpUU7NxOxGBCQ=3D=3D?=
X-Microsoft-Antispam-Message-Info: KJBwKPSLhMxNuj/JdoJBc21+oKYejnsec9jlxyfcQ1A9IlP8o5Rpbu6fmuccB4JQEBj1WiK2kNorkPLskUU8sEnYXZNMoQzcJOB4IxYLq/FKfQTfUajZ5ZHA6HCaqAPl70fwdP5zoOL/0EZWaSavHCjivzpMIfstDyrWpg+qY9nlTJPMB0jY7LeHxqZzNDrRQQCYbg6ZpDR2spp5qhSn5nkbI+Cdy3Dq2zHsWd5nA432ljHfbkyw2XCZywnUxH9CJMR4Kuh0Q+N9Di1o5VFx+i4WDcP329Fo4JSoUhNuppmJjuqtanb9yzSoODmGYl3MJIfBay7hDmE4Kidmpa2/OGxrzBw5rjwaxN6crM/mg5s=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2728; 6:IdV8/uZmpT5jwS5w2S5dataVRG+INupJbayvoydz363THO9oQ6+/6H7JDI1ZS9/JG/UQKus1o9EgxuvAgdusHzieu5XjV1jZErTM7rpJ48xHx+qfjB0r0zk7kNaTYzcMUYmqoyDEpkUivf6KS1Xh0swTP+ChEuxcH0VmP6Rf6JG52Q1Fjy1SNpbFD2emFobhogsSz2KeMzALTNRCz96SUzRT4RcQ39cs7X4+EP+E141SYlaEeOFVA3eEKNNKwZY0mZX72SfKPDbaQFzNrILXs0Y5fTyySV2AydkfFV3ajs+NCvOSuSlEfcSl5ljl3+8agt8HC1RfR66bjGgVo2n4+HsZGutOkfoLvh6zRSKPgoaR+0c5kXU7huICa6ljk7l5f4/azAeA230n3GmkxIXY64tsQDTW2Hbd6BUInps4x15bLCBOaq5PWy7fg9FkIbaqbjHIzN0UGCAO9mHi9lFG/g==; 5:JZz2Pv+sV7g69LubY4g4r/yu+eSCe/tBtMlx6xBlZ7RIigoc9UvgbEuHkZjxOpOCFeqWoQjtEH11PQFg7V8WS68oXiLpsmr6aJAkM6vas3uacVx3GC4tm17Bd3edvo32uiGsECmjwVl0PB0JDWNdxYHzTX875lISCrz+YPqVCzQ=; 7:Y3tEUCvvHMb6FpN7ButJ3NlRD7TjGHkToU/xagGP0oW1B+u6SC34uVgc3S7sRWLSbSydGo1BJhmuN0YuGpHvv5saj9oV7IxCxj1PVLMMImlA6Xmam3OqwKKHMPoxHevlQDw7VEWc8ULtA5uItLpxuKAmswYt0MHx53bzZa4dTBXx9JsQtMK9kVNkOkLsfYzZDnDwXqqdSbEaOSbY95GyWOgs91sXUuPVSvtz0xvpM5YCjkyDyXDCi5isx73br1Ur
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2018 15:24:28.3570 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61eeca56-98eb-48cd-74b7-08d62f8da2bd
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2728
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe8852zkTF6eT5oNW4Jp2d6WVo6KLH2IURdSHIitbddKlHuWc JRkE0xAv6yKlUWba0izbilmhSXiZNUTRWivJpC/mBdTspglpWtveBX77Pc//d56H5+UwJNcj C2UMgpEXBX2KSh5A3TxYZ1wdldwUvyb3KqVtLqW1ZvMgrbVeitSWv82SbaN0lZW/Cd2H7C5a VzNZQe0lDwVsPsmnGDJ4UbPlWEBS1m83mV5jPHu/4xptQrl8AWIYYNdB58CZAhTAcKwTgenW RQIXEwjc1WUyXFQSUF12mypACoZiC0kY69J6GbFHod5m8UsXCMi21sm9wXx2A1T2tcq8HMTq wDTm9PVJ9jC0Ntyj8AdtBLhHbT5JzkZD8ZU3vg1Kdivk2IZkeFsE2MtfEl4OZo/Az/cVJHbm QdvNfp+v8PjX/3yi8YJ8BOY80cvAqsA9fp3CXIzg1btAL3PsMuh1TctwfxE4O0v9zm4wNTp9 9wPbhmDmhwvhIpuG+v5mhK1V8C3/OYmDQRoe1ttJHKSB9Vmtf2wqOGdsfl4M7Zde+8fWk1Dh mJDht18I34fCC9HqklkXlcy6osRjkWwkVOWocDsEevrLCcwrocoyQmLeBDcmHXLM4VBk7qUx r4cR5w+EOQaqHk/L7yDFQxQs8dLx1MTomCheNJyQpDQhSuCNT5DnL3M8m4p4jt592d6CWAap ApXCjqZ4TqbPkDJTW5DaM+ez3epCoZSQJvCqIKXmRmM8pzypzzzHi2kJ4pkUXmpBYQylClH2 xj49xLGJeiOfzPPpvPg/JRhFqAkt1zza0x0cx6nn1ioebO9Qn5pzWSNVNazNOF1miNyvshx4 6XCLRP7Ugs4gyRqSsHNRBlH9oDD5bX9r2OKEZQNtGtvX9r7YK597/m5s7vy4dVdR43jcCUXp aN6S4YiG8x0a+4t9OvdSOolSx3CZwvjwlrs1R12jTXu7LVni3NO/clWUlKRfu4IUJf0/u5qk YW0DAAA=
Archived-At: 
Subject: Re: [netmod] WG adoption poll - instance-data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 15:24:35 -0000

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


  
    
  
  
    
Hello Kent,

    
If needed I can do a quick update, but 

    

    
    
      
  • As you stated this is a living document
    • 
      
  • IMHO the scope is clear: This is only a data format draft, how
        it is used is only here a set of use-cases. I did not see anyone
        disagreeing with this.
    
      
    • 
      
  • I would like to avoid redoing this poll. 
    
      
    • 
      
  • My wish (if the good fairy can fulfill it) is that the draft
        is adopted, and I update it before the IETF to clarify the scope
        as above.
    • 
    

    
Naturally I will consider all other comments too, but they may
      take some time to discuss.

    

    
regards Balazs

    

    
On 2018. 10. 09. 19:07, Kent Watsen
      wrote:

    

    

      
As co-chair, I have two minds:

  1) requests a fix and redo the adoption poll
  2) realize that it's a living doc and regardless
     how it begins, the WG can sort it out in time.
     i.e., we're adopting to work on the problem,
     not necessarily the specific solution.

While (1) seems more proper, given the timing of=20
things, I'm willing to go for (2).   To this extent,
the comments being made now be thought to carry
the same weight as Last Call comments.  The chairs
will discuss this again when making a determination
on the adoption poll.

As contributor, can we please not call this "YANG
instance data"?  - that means something else to=20
me.  This seems to be more about capturing data
about a server instances.  So maybe "YANG-based
Server Instance Data"?  (open to suggestions!)

Kent



=EF=BB=BF-----Original Message-----
From: netmod <netmod-bounces@ietf.org> on behalf of Bal=C3=A1=
zs Lengyel <balazs.lengyel@ericsson.com>
Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@=
ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] WG adoption poll - instance-data

OK, If the chairs are happy with that, I can update the document before=20
I store it as an official netmod document.

regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:


      

        
Hi,

Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:


        

          
Hello Martin,

I agree that this document shall be about defining the file format,
and server capabilities shall only be a use-case.)

I already took out a lot of text, that explicitly recommended using
instance data for documenting capabilities. Server capabilities are
only mentioned in the introduction chapter.
As you wrote: There is no _normative_  specification of how a server
would document its capabilities, because this is
what the WG requested, so I removed it.


        

        
Hmm.  Ok, if this is what =
the WG wants, then it is fine to just have
server capabilities as an example use case.  (I thought that the WG
wanted a normative description of server capabilities...)



        

          
I see that I forgot to c=
hange the title and the introduction can be
reworded to make
it more clear that documenting server capabilities is just a use-case.
(I still see it as the primary use-case for instance data.)


        

        
I think all text in 2 Intr=
oduction (except the last para) in this case
should be moved to section 2.1, and new text should be written in 2.

(*if* there will be a separate doc for server capabilities, the text
in 2 should be moved to that doc instead.)



        

          
  If I promise to change=
 the title and clarify the introduction can you
support adoption?


        

        
First of all I'd like to e=
nsure that the WG in fact just wants to do
the file format.  Since people have expressed support for adopting the
draft with the current title, I'm not so sure that this is the case.

I think you should make those changes, and I support the adoption of
the modified document.  I don't see any reason not to make these
chanegs before posting as a WG doc.


/martin





        

          
regards Balazs

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:


          

            
Hi,

I still think that this draft should either be split into two, one for
specifiying the generic file format (ok with examples), and one for
"Documenting Server Capabilities", or the document should just be
about the file format (+ *examples*).

[The current document mixes the two; it's a bit as if we had "The
YANG language and a model for interfaces" as one doc...]

It is clear that the document specifies a file format for YANG
instance data, which is good.  But it is not clear if the document
intends to specify how a server should document its capabilities.

The Introduction mainly talks about why it is important to document
server capabilities.  But then AFAICT there is no normative
specification of how a server would document its capabilities.


/martin


Lou Berger <lberger@labn.net> wrote:


            

              
All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

_______________________________________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



            

            
______________________=
_________________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



          

          
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com




        

      

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms030102080105010003070206
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAxMTE1MjQyNFow
LwYJKoZIhvcNAQkEMSIEIFS3batgdIltfXaghjcdTIHrrsmU46ISxJHPOHOx0VA9MGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBABUt6IcrHXRkmxAxcp2NKYgJtTfPendkDlm0icVrC8mizBHE
sxAjvOeoq+r2fDR5rYdqmrfz2/5tKy2T0o/1mFWOcvd17cGvYp6eOuZBy2Qtar8bcZbuMFlZ
NH8yWS3TQFafeFmX9zfv4HTvIq6opH9sf9ETOEKot/AEHb2Hc4lbfWfMOQhqa+J2UvUZkvhD
a2Revn82OnSLhXseYMAW80mShVG6bsCtnqcVY9DAzZ0ZomGIOnkjcSGNimN+2dzPnv4oGmxa
nxESNfDYsl2HCNCJ86FhYGQCiC5af67j40G8GLv1mvTcMu3g0qiWBsmgQQeBg/IISd7juj6n
Dy/ubXMAAAAAAAA=
--------------ms030102080105010003070206--


From nobody Thu Oct 11 08:34:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B66130DF3 for ; Thu, 11 Oct 2018 08:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.49
X-Spam-Level: 
X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf7rI3mtczKW for ; Thu, 11 Oct 2018 08:34:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB43130E7C for ; Thu, 11 Oct 2018 08:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68264; q=dns/txt; s=iport; t=1539272077; x=1540481677; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EzFioOiZW9Tb9gYkL5sWcCEU0A5ZGd4tME4mF0+uJSc=; b=ex6+DDsPiX3CGRtPIUew4FGFS9DIDKzivtPXNMZ3KCXS2qC/Y0eYvYCX v5FtWxxMXV3Ur6di0c7woqIh5T6i+D944I1JIiA/qveRBRR8asjTx7Ch/ dkunYlCNpRm5VybwBlzaxB4gFU+m0OCBSAqniTmGC3vNW8gWOAckc05MN Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAPbb9b/4kNJK1YChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYEMd2Z/KAqDa5Y0JZh3AwsBARgBCgm?= =?us-ascii?q?DekYCF4Q+ITcKDQEDAQECAQECbRwMhTkBAQEBAgEBASEERwsFCwIBCBEDAQI?= =?us-ascii?q?hAQYDAgICJQsUCQgCBAEJBAWDIAGBHVwID6YCezOJVQWLRReBQT+BOQwTgky?= =?us-ascii?q?DGwEBgTYEES0JFoJLMYImAog9gRuERhWFc4kXUwkCkFIXgU+OQokUjFcCERS?= =?us-ascii?q?BJTMigVVwFTsqAYJBCYsOhT5vgRaIfoEuAYEeAQE?=
X-IronPort-AV: E=Sophos;i="5.54,368,1534809600";  d="scan'208,217";a="246901717"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 15:34:35 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w9BFYZTG032076 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2018 15:34:35 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 10:34:35 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 11 Oct 2018 10:34:34 -0500
From: "Reshad Rahman (rrahman)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgIAASaoAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgAAFDgA=
Date: Thu, 11 Oct 2018 15:34:34 +0000
Message-ID: 
References:  <20181011.122137.1647095802972927089.mbj@tail-f.com> <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>
In-Reply-To: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.54]
Content-Type: multipart/alternative; boundary="_000_BE8F576F2A5644D885546576B9CDB0F8ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 15:34:40 -0000

--_000_BE8F576F2A5644D885546576B9CDB0F8ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUm9iLA0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh
bGYgb2YgIlJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBDaXNj
bykiIDxyd2lsdG9uQGNpc2NvLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDExLCAyMDE4
IGF0IDc6MTcgQU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCkNjOiAi
bmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2Rd
IHhwYXRoIGV4cHJlc3Npb25zIGluIEpTT04NCg0KDQoNCg0KT24gMTEvMTAvMjAxOCAxMTo1MCwg
TWFydGluIEJqb3JrbHVuZCB3cm90ZToNCg0KUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5j
b20+PG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQoNCg0KDQpPbiAxMS8xMC8yMDE4
IDExOjIxLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KDQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVt
YXdvcmtzLmNvbT48bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQoNCk9uIFdlZCwg
T2N0IDEwLCAyMDE4IGF0IDExOjM5IFBNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNv
bT48bWFpbHRvOm1iakB0YWlsLWYuY29tPg0KDQp3cm90ZToNCg0KDQoNCkFuZHkgQmllcm1hbiA8
YW5keUB5dW1hd29ya3MuY29tPjxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCg0K
T24gV2VkLCBPY3QgMTAsIDIwMTggYXQgNjo1OSBQTSwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikg
PA0KDQpycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+Pg0KDQp3cm90
ZToNCg0KDQoNCk9uIDIwMTgtMTAtMTAsIDk6NTkgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1h
cnRpbiBCam9ya2x1bmQiIDwNCg0KbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgbWJqQHRhaWwtZi5jb208bWFpbHRvOm1i
akB0YWlsLWYuY29tPj4gd3JvdGU6DQoNCg0KDQogICAgIExhZGlzbGF2IExob3RrYSA8bGhvdGth
QG5pYy5jej48bWFpbHRvOmxob3RrYUBuaWMuY3o+IHdyb3RlOg0KDQogICAgID4gTWFydGluIEJq
b3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+PG1haWx0bzptYmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0K
DQogICAgID4NCg0KICAgICA+ID4gSGksDQoNCiAgICAgPiA+DQoNCiAgICAgPiA+IFdoaWxlIHJl
dmlld2luZyByZXN0Y29uZi1ub3RpZiwgSSBzYXcgdGhpcyBleGFtcGxlOg0KDQogICAgID4gPg0K
DQogICAgID4gPiAgICB7DQoNCiAgICAgPiA+ICAgICAgICJpZXRmLXN1YnNjcmliZWQtbm90aWZp
Y2F0aW9uczppbnB1dCI6IHsNCg0KICAgICA+ID4gICAgICAgICAgInN0cmVhbSI6ICJORVRDT05G
IiwNCg0KICAgICA+ID4gICAgICAgICAgInN0cmVhbS14cGF0aC1maWx0ZXIiOiAiL2RzOmZvby8i
LA0KDQogICAgID4gPiAgICAgICAgICAiZHNjcCI6ICIxMCINCg0KICAgICA+ID4gICAgICAgfQ0K
DQogICAgID4gPiAgICB9DQoNCiAgICAgPiA+DQoNCiAgICAgPiA+IE5vdGUgdGhlICJzdHJlYW0t
eHBhdGgtZmlsdGVyIi4gIEl0IGhhcyBhIHByZWZpeCBpbiB0aGUgWFBhdGgNCg0Kc3RyaW5nLg0K
DQogICAgID4gPiBIb3cgYXJlIHByZWZpeGVzIGRlY2xhcmVkIHdoZW4gSlNPTiBpcyB1c2VkPw0K
DQogICAgID4gPg0KDQogICAgID4gPiBUaGUgbGVhZiAic3RyZWFtLXhwYXRoLWZpbHRlciIgc2F5
czoNCg0KICAgICA+ID4NCg0KICAgICA+ID4gICAgICAgICAgICAgICBvICBUaGUgc2V0IG9mIG5h
bWVzcGFjZSBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluDQoNCnNjb3BlIG9uDQoNCiAgICAgPiA+
ICAgICAgICAgICAgICAgICAgdGhlICdzdHJlYW0teHBhdGgtZmlsdGVyJyBsZWFmIGVsZW1lbnQu
DQoNCiAgICAgPiA+DQoNCiAgICAgPiA+IChJIHRoaW5rIEkgcHJvdmlkZWQgdGhhdCB0ZXh0Li4u
KQ0KDQogICAgID4gPg0KDQogICAgID4gPiBUaGlzIGFzc3VtZXMgdGhhdCB0aGUgZW5jb2Rpbmcg
aXMgWE1MLCBvciBhdCBsZWFzIHRoYXQgdGhlDQoNCmVuY29kaW5nDQoNCiAgICAgPiA+IGNhbiBz
b21laG93IHRyYW5zZmVyIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMuDQoNCiAgICAgPg0KDQogICAg
ID4gSXQgY2FuJ3QuIFRoZXJlIGFyZSB0d28gb3B0aW9uczoNCg0KICAgICA+DQoNCiAgICAgPiAx
LiBoYXZlIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgb2YgdGhpcyB2YWx1ZSBpbiBYTUwgYW5k
IEpTT04sDQoNCiAgICAgPiAgICBhbmFsb2dpY2FsbHkgdG8gaW5zdGFuY2UgaW5kZW50aWZpZXJz
IChzZWMuIDYuMTEgaW4gUkZDIDc5NTEpLg0KDQogICAgID4NCg0KICAgICA+IDIuIHVzZSBhIG1v
ZHVsZSBuYW1lIHJhdGhlciB0aGFuIGEgcHJlZml4IGluIFhNTCwgdG9vLg0KDQogICAgID4NCg0K
ICAgICA+IEkgd291bGQgc3VnZ2VzdCAjMi4NCg0KPFJSPiBCdXQgdGhhdCBtZWFucyBtYWtpbmcg
bm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIGNoYW5nZSB0byB0aGUgWE1MDQoNCnJlcHJlc2VudGF0
aW9uPw0KDQoNCg0KTm90IHJlYWxseS4gSXQgbWVhbnMgTkVUTU9EIFdHIHdvdWxkIGJlIGNyZWF0
aW5nIGl0cyBvd24gc3BlY2lhbA0KDQp2YXJpYW50DQoNCm9mDQoNClhQYXRoLg0KDQpOb3QgYXQg
YWxsLiAgV2hhdCBJIHByb3Bvc2UgaXMgcGVyZmVjdGx5IGZpbmUsIGxlZ2FsIFhQYXRoIDEuMC4N
Cg0KDQoNClhQYXRoIDEuMCBzYXlzIHRoYXQgYW4gWFBhdGggZXhwcmVzc2lvbiBpcyBldmFsdWF0
ZWQgaW4gYSBjb250ZXh0Lg0KDQpPbmUgaXRlbSBpbiB0aGUgY29udGV4dCBpcyBhIHNldCBvZiBt
YXBwaW5ncyBmcm9tIDxwcmVmaXg+IHRvIDx1cmk+LA0KDQp3aGVyZSA8cHJlZml4PiBpcyB1c2Vk
IHRvIGxvb2t1cCBwcmVmaXhlcyB1c2VkIGluIHRoZSBYUGF0aA0KDQpleHByZXNzaW9uLCBlLmcu
IGluICIvZm9vOmludGVyZmFjZXMiICJmb28iIGlzIHRoZSBwcmVmaXguDQoNCg0KDQpJdCBpcyBw
ZXJmZWN0bHkgZmluZSB0byBzYXkgdGhhdCB0aGUgcHJlZml4IG1hcHBpbmcgc2V0IGlzIHRoaXM6
DQoNCg0KDQogICAgImlldGYtaW50ZXJmYWNlcyIgLT4gInVybjppZXRmOnBhcmFtczp4bWw6bnM6
eWFuZzppZXRmLWludGVyZmFjZXMiDQoNCiAgICAiaWV0Zi1pcCIgICAgICAgICAtPiAidXJuOmll
dGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaXAiDQoNCg0KDQphbmQgdXNlIHRoYXQgdG8gZXZh
bHVhdGUgdGhlIGV4cHJlc3Npb24NCg0KDQoNCiAgIC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNl
cy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXAvaXB2NA0KDQoNCg0KDQoNCg0KDQpU
aGUgWFBhdGggZXhwcmVzc2lvbiBpcyBub3JtYWxseSBwYXJzZWQgd2l0aGluIGFuIFhNTCBpbnN0
YW5jZQ0KDQpkb2N1bWVudC4NCg0KVGhlcmUgYXJlICJ4bWxucyIgYXR0cmlidXRlcyBwcmVzZW50
IHRoYXQgbWFwIHRoZSBwcmVmaXggdG8gYQ0KDQpuYW1lc3BhY2UgVVJJLg0KDQpUaGVzZSBtYXBw
aW5ncyB3aWxsIG5vdCBiZSBwcmVzZW50IGluIHRoZSBKU09OIGF0IGFsbC4NCg0KDQoNCkEgY3Vz
dG9tIFhQYXRoIGltcGxlbWVudGF0aW9uIGlzIHJlcXVpcmVkIHRvIG1hZ2ljYWxseSBpZGVudGlm
eSB0aGUNCg0KcHJlZml4DQoNCmFzIGEgbW9kdWxlIG5hbWUgYW5kIG1hZ2ljYWxseSBmaW5kIHRo
ZSBuYW1lc3BhY2UgVVJJIGZvciB0aGUgbW9kdWxlDQoNCm5hbWUuDQoNCkkgZGlzYWdyZWUuICBZ
b3UgbmVlZCBhbiBYUGF0aCBpbXBsZW1lbnRhdGlvbiArIGN1c3RvbSBjb2RlIHRvIHNldCB1cA0K
DQp0aGUgZW52aXJvbm1lbnQuDQoNClRoaXMgaXMgT0ssIGJ1dCBjYW4gd2UganVzdCB1c2UgdGhl
IEpTT04gZW5jb2RpbmcgaW5zdGFuY2UgaWRlbnRpZmllcg0KDQpmb3JtYXQgZXhhY3RseT8gIEku
ZSAuUkZDIDc5NTEgc2VjdGlvbiA2LjExLg0KDQoNCg0KU28gIi9pZXRmLWludGVyZmFjZXM6aW50
ZXJmYWNlcy9pbnRlcmZhY2UvaWV0Zi1pcDppcHY0L2VuYWJsZWQiDQoNCg0KDQpjYW4gdHJpdmlh
bGx5IGJlIGV4cGFuZGVkIHRvOg0KDQoNCg0KIi9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9p
ZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXA6aXB2NC9pZXRmLWlwOmVuYWJsZWQiLA0K
DQoNCg0KYW5kIHRoZW4gaW50ZXJwcmV0ZWQgd2l0aCB0aGUgY29udGV4dDoNCg0KICAgICAiaWV0
Zi1pbnRlcmZhY2VzIiAtPiAidXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaW50ZXJm
YWNlcyINCg0KICAgImlldGYtaXAiICAgICAgICAgLT4gInVybjppZXRmOnBhcmFtczp4bWw6bnM6
eWFuZzppZXRmLWlwIg0KDQoqdGhpcyogd291bGQgcmVxdWlyZSBhIGN1c3RvbSBYUGF0aCBpbXBs
ZW1lbnRhdGlvbi4NCldoeT8gIEkuZS4gaG93IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gc3RhdGlu
ZyAiQ3VzdG9tIGNvZGUgaXMgbmVlZGVkIHRvIGNvbm5lY3QgdGhpbmdzIHRvZ2V0aGVyIj8NCg0K
DQoNCg0KDQphbmQgaXQgaXMgbm90IG9idmlvdXMgd2hhdCB0aGUgcnVsZXMgZm9yIHRoZSAiYXV0
by1hc3NpZ25tZW50IiBvZg0KDQpwcmVmaXhlcyB3b3VsZCBiZS4gIEZvciBleGFtcGxlOg0KDQoN
Cg0KICAvaWV0Zi1pbnRlcmZhY2VzLy9pZXRmLWlwOmFkZHJlc3NbLi4vZm9vXQ0KDQoNCg0Kd2hh
dCBpcyB0aGUgcHJlZml4IGZvciAiZm9vIj8NCk9LLCBzbyBoZXJlIHRoZSBtb2R1bGUgZm9yICIu
Li9mb28iIHdvdWxkIG5lZWQgdG8gYmUgc3BlY2lmaWVkLg0KDQpQZXJoYXBzIHRoZSBydWxlIHRo
YXQgSSdtIGxvb2tpbmcgZm9yIGlzIHRoZSBtb2R1bGUgbmFtZSBtYXkgYmUgb21pdHRlZCB3aGVu
IGl0IG1hdGNoZXMgdGhlIHBhcmVudCBub2RlIG1vZHVsZSwgYW5kIGNhbiBlYXNpbHkgYmUgaW5m
ZXJyZWQuICBJLmUuIHNvIHRoYXQgZm9yIGFueSBYUGF0aCBzdHJpbmcsIGl0IGlzIHBvc3NpYmxl
IHRvIHRyaXZpYWxseSBleHBhbmQgaXQgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzY2hlbWEgY29u
dGV4dC4NCg0KSXQganVzdCBzZWVtcyB0byBiZSB0aGF0IHJlcXVpcmluZyB0aGUgbG9uZyBoYW5k
IG9mICIvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFj
ZS9pZXRmLWlwOmlwdjQvaWV0Zi1pcDplbmFibGVkIiBzZWVtcyBsaWtlIGl0IHdpbGwgZ2V0IHZl
cnkgdmVyYm9zZSwgYW5kIEkgd29uZGVyIHdoZXRoZXIgd2UgYXJlIGludHJvZHVjaW5nIHlldCBh
bm90aGVyIFhwYXRoIGZvcm1hdCB0byBZQU5HLg0KPFJSPiBJ4oCZbSB3aWxsaW5nIHRvIGxpdmUg
d2l0aCB2ZXJib3NpdHkgaWYgaXQgYXZvaWRzIHRoZSBuZWVkIG9mIGFub3RoZXIgZm9ybWF0Lg0K
DQpGaW5hbGx5LCBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaGF2ZSBSRkMgODA0MCBxdWVyeSBw
YXJhbWV0ZXIgKHNlY3QgNC44LjQpLCB3aGljaCBhbHNvIHVzZXMgWFBhdGggZXhwcmVzc2lvbnMg
aXMgbWVhbnQgdG8gd29yay4gIFRoYXQgc3RhdGVzOg0KDQoNCg0KVGhlIHNldCBvZiBuYW1lc3Bh
Y2UgZGVjbGFyYXRpb25zIGlzIHRoZSBzZXQgb2YgcHJlZml4IGFuZA0KDQogICAgICBuYW1lc3Bh
Y2UgcGFpcnMgZm9yIGFsbCBzdXBwb3J0ZWQgWUFORyBtb2R1bGVzLCB3aGVyZSB0aGUgcHJlZml4
DQoNCiAgICAgIGlzIHRoZSBZQU5HIG1vZHVsZSBuYW1lIGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFz
IGRlZmluZWQgYnkgdGhlDQoNCiAgICAgICJuYW1lc3BhY2UiIHN0YXRlbWVudCBpbiB0aGUgWUFO
RyBtb2R1bGUuDQoNCllldCB0aGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA4LjMuNiBkb24ndCBzZWVt
IHRvIHVzZSBuYW1lc3BhY2UgcHJlZml4ZXMgaW4gdmVyeSBtYW55IHBsYWNlcywgZS5nLiB3aHkg
aXMgaXQgIi9leGFtcGxlLW1vZDpldmVudDEvbmFtZT0nam9lJyIgYW5kIG5vdCAiL2V4YW1wbGUt
bW9kOmV2ZW50MS9leGFtcGxlLW1vZDpuYW1lPSdqb2UnIj8gIElzIHRoZSBleGFtcGxlIHdyb25n
LCBvciBvdGhlcndpc2Ugd2hhdCBhbSBJIG1pc3Npbmc/IDotKQ0KDQo8UlI+IFNlY3Rpb24gOC4z
LjYgb2Ygd2hpY2ggZG9jdW1lbnQ/DQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNClRoYW5rcywNClJv
Yg0KDQoNCg0KDQoNCg0KDQoNCg0KDQovbWFydGluDQoNCg0KDQoNCg0KDQoNClRoYW5rcywNCg0K
Um9iDQoNCg0KDQoNCg0KVGhlcmUgaXMgbm8gc3RhbmRhcmQgWFBhdGggaW1wbGVtZW50YXRpb24g
dGhhdCBjYW4ganVzdCB0YWtlIGFuIFhNTA0KDQppbnN0YW5jZSBkb2N1bWVudCArIFlBTkcgbW9k
dWxlIGFuZCBmaWd1cmUgb3V0IHdoYXQgdG8gZG8uICBDdXN0b20NCg0KY29kZSBpcyBuZWVkZWQg
dG8gY29ubmVjdCB0aGluZ3MgdG9nZXRoZXIuICBUaGlzIHByb3Bvc2FsIGRvZXNuJ3QNCg0KY2hh
bmdlIHRoaXMuDQoNCg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KDQoNCkEgbm9ybWFsIFhQYXRoIGlt
cGxlbWVudGF0aW9uIHdpbGwgbm90IGZpbmQgYW55IG5hbWVzcGFjZSBtYXBwaW5nIGZvcg0KDQp0
aGUNCg0KcHJlZml4ZXMuDQoNCg0KDQpBbiBYUGF0aCBleHByZXNzaW9uIGhhcyBubyBjb25jZXB0
IG9mIHRoZSAiY3VycmVudCBtb2R1bGUiIGluaGVyaXRlZA0KDQpmcm9tDQoNCnRoZSBwYXJlbnQN
Cg0KbGlrZSB0aGUgSlNPTiBlbmNvZGluZy4gVGhpcyBpcyBwcm9ibGVtYXRpYyBmb3IgcHJlZGlj
YXRlcw0KDQoNCg0KICAgIC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pbnRlcmZhY2VbbmFt
ZT0nZXRoMCddDQoNCg0KDQpYUGF0aCBzYXlzIHRoZSBtaXNzaW5nIHByZWZpeGVzIGZvciAnaW50
ZXJmYWNlJyBhbmQgJ25hbWUnIGFyZSBzaW1wbHkNCg0KbWlzc2luZyAobm8gbmFtZXNwYWNlKS4N
Cg0KVGhlIEpTT04gZW5jb2Rpbmcgc2F5cyAiaWV0Zi1pbnRlcmZhY2VzIiBpcyB1c2VkIGZvciAn
aW50ZXJmYWNlcycuIGFuZA0KDQonaW50ZXJmYWNlJy4NCg0KVGhlcmUgaXMgbm8gc3BlY2lmaWNh
dGlvbiBmb3IgdGhlICduYW1lJyBub2RlIGluc2lkZSBhIHByZWRpY2F0ZS4NCg0KDQoNClNvIHlv
dSBtdXN0IG1lYW4gdGhlIGZ1bGwgbW9kdWxlIG5hbWUgd2lsbCBiZSB1c2VkIGF0IGV2ZXJ5IG5v
ZGU6DQoNCg0KDQogIC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6
aW50ZXJmYWNlW2lldGYtaW50ZXJmYWNlczpuYW1lPSdldGgwJ10NCg0KDQoNCg0KDQoNCg0KL21h
cnRpbg0KDQoNCg0KDQoNCkFuZHkNCg0KDQoNCg0KDQogICAgIEhtbSwgc28geW91IG1lYW4gY2hh
bmdlIHRoZSBsZWFmICJzdHJlYW0teHBhdGgtZmlsdGVyIiB0byBzYXk6DQoNCg0KDQogICAgICAg
ICAgICAgIG8gIFRoZSBzZXQgb2YgbmFtZXNwYWNlIGRlY2xhcmF0aW9ucyBoYXMgb25lIG1lbWJl
ciBmb3INCg0KZWFjaA0KDQogICAgICAgICAgICAgICAgIFlBTkcgbW9kdWxlIHN1cHBvcnRlZCBi
eSB0aGUgc2VydmVyLiAgVGhpcyBtZW1iZXIgbWFwcw0KDQogICAgICAgICAgICAgICAgIGZyb20g
dGhlIFlBTkcgbW9kdWxlIG5hbWUgdG8gdGhlIFlBTkcgbW9kdWxlIG5hbWVzcGFjZS4NCg0KDQoN
CiAgICAgICAgICAgICAgICAgVGhpcyBtZWFucyB0aGF0IGluIHRoZSBYUGF0aCBleHByZXNzaW9u
LCB0aGUgbW9kdWxlDQoNCm5hbWUNCg0KICAgICAgICAgICAgICAgICBzZXJ2ZXMgYXMgdGhlIHBy
ZWZpeC4NCg0KDQoNCiAgICAgLi4uLiBhbmQgdGhlbiBhbHNvIGdpdmUgYW4gZXhhbXBsZSBvZiB0
aGlzLg0KDQoNCg0KICAgICBUaGlzIGlzIHByb2JhYmx5IHdoYXQgd2UgbmVlZCB0byBkbyBpbiBh
bGwgcGxhY2VzIHdoZXJlDQoNCnlhbmc6eHBhdGgxLjANCg0KICAgICBpcyB1c2VkLCBnb2luZyBm
b3J3YXJkLiAgTWF5YmUgZXZlbiBkZWZpbmUgYSBuZXcgdHlwZQ0KDQogICAgIHlhbmc6eHBhdGgx
LjAtMiAobmFtZT8pIHdpdGggdGhlIHNldCBvZiBuYW1lc3BhY2UgZGVjbGFyYXRpb25zDQoNCiAg
ICAgYnVpbHQtaW4uDQoNCg0KDQpXZSBzaG91bGQgYXZvaWQgbWFraW5nIG9mZi10aGUtc2hlbGYg
aW1wbGVtZW50YXRpb25zIG9mIHN0YW5kYXJkcyBsaWtlDQoNClhQYXRoIHVudXNhYmxlLg0KDQpB
dCB0aGUgdmVyeSBsZWFzdCB0aGlzIHNob3VsZCBiZSBvbmx5IGF2YWlsYWJsZSBpZiB0aGUgc2Vy
dmVyIHN1cHBvcnRzDQoNCml0DQoNCih3aXRoIGEgY2FwYWJpbGl0eSBVUkkpDQoNCg0KDQoNCg0K
DQoNCjxSUj4gU28gd2UgbmVlZCBhbiB1cGRhdGUgdG8gUkZDNzk1MT8NCg0KDQoNClJlZ2FyZHMs
DQoNClJlc2hhZC4NCg0KDQoNCg0KDQpBbmR5DQoNCg0KDQoNCg0KICAgICAvbWFydGluDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KICAgICA+DQoNCiAgICAgPiBMYWRhDQoNCiAgICAgPg0KDQogICAg
ID4gPg0KDQogICAgID4gPiBIb3cgaXMgdGhpcyBzdXBwb3NlZCB0byB3b3JrIHdpdGggSlNPTj8N
Cg0KICAgICA+ID4NCg0KICAgICA+ID4NCg0KICAgICA+ID4gL21hcnRpbg0KDQogICAgID4gPg0K
DQogICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KDQogICAgID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCiAgICAgPiA+IG5ldG1vZEBpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQogICAgID4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQogICAgID4NCg0KICAgICA+IC0tDQoNCiAg
ICAgPiBMYWRpc2xhdiBMaG90a2ENCg0KICAgICA+IEhlYWQsIENaLk5JQyBMYWJzDQoNCiAgICAg
PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCg0KICAgICA+DQoNCg0KDQogICAgIF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICAgbmV0
bW9kIG1haWxpbmcgbGlzdA0KDQogICAgIG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll
dGYub3JnPg0KDQogICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KbmV0bW9kIG1haWxpbmcgbGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l
dG1vZEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2QNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt
b2RAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQoNCi4uDQoNCg0KDQouDQoNCg0KDQoNCg==

--_000_BE8F576F2A5644D885546576B9CDB0F8ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <5669257C50510F49B682711096AAF9B5@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp
Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h
dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw
dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPkhpIFJvYiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm5ldG1vZCAmbHQ7bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtSb2JlcnQgV2lsdG9uIC1Y
IChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pJnF1b3Q7ICZsdDtyd2lsdG9uQGNp
c2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE9jdG9iZXIgMTEsIDIwMTgg
YXQgNzoxNyBBTTxicj4NCjxiPlRvOiA8L2I+TWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwt
Zi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0
O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtuZXRtb2RdIHhw
YXRoIGV4cHJlc3Npb25zIGluIEpTT048bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHA+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5P
biAxMS8xMC8yMDE4IDExOjUwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPlJvYmVydCBXaWx0b24gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyd2lsdG9u
QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jmx0O3J3aWx0b25AY2lzY28uY29tJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+T24gMTEvMTAvMjAxOCAxMToyMSwgTWFydGluIEJqb3JrbHVuZCB3cm90
ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BbmR5IEJpZXJtYW4gPC9zcGFuPjxhIGhyZWY9Im1haWx0
bzphbmR5QHl1bWF3b3Jrcy5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPiZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
Pk9uIFdlZCwgT2N0IDEwLCAyMDE4IGF0IDExOjM5IFBNLCBNYXJ0aW4gQmpvcmtsdW5kIDwvc3Bh
bj48YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPiZsdDttYmpAdGFpbC1mLmNvbSZndDs8L3NwYW4+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkFuZHkg
Qmllcm1hbiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmx0O2FuZHlAeXVtYXdvcmtz
LmNvbSZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k
eSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gV2VkLCBPY3QgMTAsIDIwMTggYXQgNjo1
OSBQTSwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgJmx0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJyYWhtYW5AY2lzY28uY29tIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5ycmFobWFuQGNpc2NvLmNv
bTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw
YW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+T24gMjAxOC0xMC0xMCwgOTo1OSBBTSwgJnF1b3Q7bmV0bW9kIG9uIGJl
aGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z
cGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8
L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFu
PjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4gb24gYmVo
YWxmIG9mIDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm1iakB0YWlsLWYuY29tPC9zcGFuPjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBMYWRpc2xhdiBMaG90a2EgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmlj
LmN6Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbHQ7bGhv
dGthQG5pYy5jeiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmZ3Q7IE1hcnRpbiBCam9ya2x1bmQgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1m
LmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmx0O21i
akB0YWlsLWYuY29tJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPiB3cml0ZXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7
ICZndDsgSGksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7
ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0
OyBXaGlsZSByZXZpZXdpbmcgcmVzdGNvbmYtbm90aWYsIEkgc2F3IHRoaXMgZXhhbXBsZTo8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZXRmLXN1YnNj
cmliZWQtbm90aWZpY2F0aW9uczppbnB1dCZxdW90OzogezxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3N0cmVhbSZxdW90OzogJnF1b3Q7TkVU
Q09ORiZxdW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmcXVvdDtzdHJlYW0teHBhdGgtZmlsdGVyJnF1b3Q7OiAmcXVvdDsvZHM6Zm9vLyZxdW90
Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZndDsgJmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv
dDtkc2NwJnF1b3Q7OiAmcXVvdDsxMCZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZndDsgJmd0OyBOb3RlIHRoZSAmcXVvdDtzdHJlYW0teHBhdGgtZmlsdGVyJnF1b3Q7LiZu
YnNwOyBJdCBoYXMgYSBwcmVmaXggaW4gdGhlIFhQYXRoPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnN0cmlu
Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBI
b3cgYXJlIHByZWZpeGVzIGRlY2xhcmVkIHdoZW4gSlNPTiBpcyB1c2VkPzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgVGhlIGxlYWYgJnF1b3Q7c3RyZWFt
LXhwYXRoLWZpbHRlciZxdW90OyBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4gJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUg
c2V0IG9mIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPnNjb3BlIG9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl
ICdzdHJlYW0teHBhdGgtZmlsdGVyJyBsZWFmIGVsZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAoSSB0aGluayBJIHByb3ZpZGVkIHRoYXQgdGV4
dC4uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IFRo
aXMgYXNzdW1lcyB0aGF0IHRoZSBlbmNvZGluZyBpcyBYTUwsIG9yIGF0IGxlYXMgdGhhdCB0aGU8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ZW5jb2Rpbmc8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsg
Y2FuIHNvbWVob3cgdHJhbnNmZXIgbmFtZXNwYWNlIGRlY2xhcmF0aW9ucy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSXQgY2FuJ3QuIFRoZXJlIGFyZSB0d28gb3B0aW9u
czo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMS4gaGF2ZSBkaWZmZXJl
bnQgcmVwcmVzZW50YXRpb25zIG9mIHRoaXMgdmFsdWUgaW4gWE1MIGFuZCBKU09OLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyBhbmFsb2dpY2FsbHkgdG8gaW5zdGFuY2UgaW5kZW50aWZpZXJzIChzZWMuIDYuMTEgaW4gUkZD
IDc5NTEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAyLiB1c2UgYSBt
b2R1bGUgbmFtZSByYXRoZXIgdGhhbiBhIHByZWZpeCBpbiBYTUwsIHRvby48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSSB3b3VsZCBzdWdnZXN0ICMyLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij4mbHQ7UlImZ3Q7IEJ1dCB0aGF0IG1lYW5zIG1ha2luZyBub24tYmFja3dhcmRzIGNv
bXBhdGlibGUgY2hhbmdlIHRvIHRoZSBYTUw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+cmVwcmVzZW50YXRp
b24/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij5Ob3QgcmVhbGx5LiBJdCBtZWFucyBORVRNT0QgV0cgd291bGQgYmUgY3JlYXRpbmcgaXRz
IG93biBzcGVjaWFsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnZhcmlhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+b2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5YUGF0aC48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Tm90IGF0IGFsbC4mbmJzcDsgV2hhdCBJIHByb3Bvc2UgaXMg
cGVyZmVjdGx5IGZpbmUsIGxlZ2FsIFhQYXRoIDEuMC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPlhQYXRoIDEuMCBzYXlzIHRoYXQgYW4gWFBhdGggZXhwcmVzc2lv
biBpcyBldmFsdWF0ZWQgaW4gYSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbmUgaXRlbSBp
biB0aGUgY29udGV4dCBpcyBhIHNldCBvZiBtYXBwaW5ncyBmcm9tICZsdDtwcmVmaXgmZ3Q7IHRv
ICZsdDt1cmkmZ3Q7LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij53aGVyZSAmbHQ7cHJlZml4Jmd0OyBpcyB1
c2VkIHRvIGxvb2t1cCBwcmVmaXhlcyB1c2VkIGluIHRoZSBYUGF0aDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij5leHByZXNzaW9uLCBlLmcuIGluICZxdW90Oy9mb286aW50ZXJmYWNlcyZxdW90OyAmcXVvdDtm
b28mcXVvdDsgaXMgdGhlIHByZWZpeC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPkl0IGlzIHBlcmZlY3RseSBmaW5lIHRvIHNheSB0aGF0IHRoZSBwcmVmaXggbWFw
cGluZyBzZXQgaXMgdGhpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZXRmLWludGVyZmFjZXMmcXVvdDsgLSZndDsg
JnF1b3Q7dXJuOmlldGY6cGFyYW1zOjwvc3Bhbj48YSBocmVmPSJ4bWw6bnM6eWFuZzppZXRmLWlu
dGVyZmFjZXMiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnht
bDpuczp5YW5nOmlldGYtaW50ZXJmYWNlczwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsm
bmJzcDsgJnF1b3Q7aWV0Zi1pcCZxdW90OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAtJmd0OyAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6PC9zcGFuPjxhIGhy
ZWY9InhtbDpuczp5YW5nOmlldGYtaXAiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPnhtbDpuczp5YW5nOmlldGYtaXA8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPmFuZCB1c2UgdGhhdCB0byBldmFsdWF0ZSB0aGUgZXhwcmVzc2lv
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7
IC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2ll
dGYtaXAvaXB2NDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij5UaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBub3JtYWxseSBwYXJzZWQgd2l0aGluIGFuIFhN
TCBpbnN0YW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5kb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
VGhlcmUgYXJlICZxdW90O3htbG5zJnF1b3Q7IGF0dHJpYnV0ZXMgcHJlc2VudCB0aGF0IG1hcCB0
aGUgcHJlZml4IHRvIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bmFtZXNwYWNlIFVSSS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+VGhlc2UgbWFwcGluZ3Mgd2lsbCBub3QgYmUgcHJlc2VudCBpbiB0aGUgSlNPTiBh
dCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BIGN1c3Rv
bSBYUGF0aCBpbXBsZW1lbnRhdGlvbiBpcyByZXF1aXJlZCB0byBtYWdpY2FsbHkgaWRlbnRpZnkg
dGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPnByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5hcyBhIG1vZHVs
ZSBuYW1lIGFuZCBtYWdpY2FsbHkgZmluZCB0aGUgbmFtZXNwYWNlIFVSSSBmb3IgdGhlIG1vZHVs
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij5uYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij5JIGRpc2FncmVlLiZuYnNwOyBZb3UgbmVlZCBhbiBYUGF0aCBpbXBsZW1lbnRhdGlvbiAmIzQz
OyBjdXN0b20gY29kZSB0byBzZXQgdXA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dGhlIGVudmlyb25tZW50
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGlzIGlzIE9LLCBidXQgY2FuIHdl
IGp1c3QgdXNlIHRoZSBKU09OIGVuY29kaW5nIGluc3RhbmNlIGlkZW50aWZpZXI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+Zm9ybWF0IGV4YWN0bHk/Jm5ic3A7IEkuZSAuUkZDIDc5NTEgc2VjdGlvbiA2LjEx
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U28gJnF1b3Q7L2ll
dGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2ludGVyZmFjZS9pZXRmLWlwOmlwdjQvZW5hYmxlZCZx
dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Y2FuIHRyaXZp
YWxseSBiZSBleHBhbmRlZCB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPiZxdW90Oy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6
aW50ZXJmYWNlL2lldGYtaXA6aXB2NC9pZXRmLWlwOmVuYWJsZWQmcXVvdDssPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5hbmQgdGhlbiBpbnRlcnByZXRlZCB3aXRo
IHRoZSBjb250ZXh0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JnF1b3Q7aWV0Zi1pbnRlcmZhY2VzJnF1b3Q7IC0mZ3Q7ICZxdW90O3VybjppZXRmOnBhcmFtczo8
L3NwYW4+PGEgaHJlZj0ieG1sOm5zOnlhbmc6aWV0Zi1pbnRlcmZhY2VzIj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij54bWw6bnM6eWFuZzppZXRmLWludGVyZmFj
ZXM8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z
cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mcXVv
dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2lldGYtaXAmcXVvdDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgJnF1b3Q7
dXJuOmlldGY6cGFyYW1zOjwvc3Bhbj48YSBocmVmPSJ4bWw6bnM6eWFuZzppZXRmLWlwIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij54bWw6bnM6eWFuZzppZXRm
LWlwPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv
c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+JnF1
b3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPip0aGlzKiB3b3VsZCByZXF1aXJl
IGEgY3VzdG9tIFhQYXRoIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+V2h5PyZuYnNwOyBJLmUuIGhvdyBpcyB0aGlzIGRpZmZl
cmVudCBmcm9tIHN0YXRpbmcgJnF1b3Q7Q3VzdG9tIGNvZGUgaXMgbmVlZGVkIHRvIGNvbm5lY3Qg
dGhpbmdzIHRvZ2V0aGVyJnF1b3Q7Pzxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+YW5kIGl0IGlzIG5vdCBvYnZpb3VzIHdoYXQgdGhl
IHJ1bGVzIGZvciB0aGUgJnF1b3Q7YXV0by1hc3NpZ25tZW50JnF1b3Q7IG9mPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPnByZWZpeGVzIHdvdWxkIGJlLiZuYnNwOyBGb3IgZXhhbXBsZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyAvaWV0Zi1pbnRlcmZhY2VzLy9p
ZXRmLWlwOmFkZHJlc3NbLi4vZm9vXTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+d2hhdCBpcyB0aGUgcHJlZml4IGZvciAmcXVvdDtmb28mcXVvdDs/PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PSywgc28gaGVyZSB0aGUg
bW9kdWxlIGZvciAmcXVvdDsuLi9mb28mcXVvdDsgd291bGQgbmVlZCB0byBiZSBzcGVjaWZpZWQu
PGJyPg0KPGJyPg0KUGVyaGFwcyB0aGUgcnVsZSB0aGF0IEknbSBsb29raW5nIGZvciBpcyB0aGUg
bW9kdWxlIG5hbWUgbWF5IGJlIG9taXR0ZWQgd2hlbiBpdCBtYXRjaGVzIHRoZSBwYXJlbnQgbm9k
ZSBtb2R1bGUsIGFuZCBjYW4gZWFzaWx5IGJlIGluZmVycmVkLiZuYnNwOyBJLmUuIHNvIHRoYXQg
Zm9yIGFueSBYUGF0aCBzdHJpbmcsIGl0IGlzIHBvc3NpYmxlIHRvIHRyaXZpYWxseSBleHBhbmQg
aXQgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzY2hlbWEgY29udGV4dC48YnI+DQo8YnI+DQpJdCBq
dXN0IHNlZW1zIHRvIGJlIHRoYXQgcmVxdWlyaW5nIHRoZSBsb25nIGhhbmQgb2YgJnF1b3Q7L2ll
dGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2UvaWV0Zi1p
cDppcHY0L2lldGYtaXA6ZW5hYmxlZCZxdW90OyBzZWVtcyBsaWtlIGl0IHdpbGwgZ2V0IHZlcnkg
dmVyYm9zZSwgYW5kIEkgd29uZGVyIHdoZXRoZXIgd2UgYXJlIGludHJvZHVjaW5nIHlldCBhbm90
aGVyIFhwYXRoIGZvcm1hdCB0byBZQU5HLjxicj4NCiZsdDtSUiZndDsgSeKAmW0gd2lsbGluZyB0
byBsaXZlIHdpdGggdmVyYm9zaXR5IGlmIGl0IGF2b2lkcyB0aGUgbmVlZCBvZiBhbm90aGVyIGZv
cm1hdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpGaW5hbGx5LCBJJ20g
dHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaGF2ZSBSRkMgODA0MCBxdWVyeSBwYXJhbWV0ZXIgKHNlY3Qg
NC44LjQpLCB3aGljaCBhbHNvIHVzZXMgWFBhdGggZXhwcmVzc2lvbnMgaXMgbWVhbnQgdG8gd29y
ay4mbmJzcDsgVGhhdCBzdGF0ZXM6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBzZXQgb2YgbmFtZXNwYWNlIGRlY2xhcmF0aW9u
cyBpcyB0aGUgc2V0IG9mIHByZWZpeCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5hbWVz
cGFjZSBwYWlycyBmb3IgYWxsIHN1cHBvcnRlZCBZQU5HIG1vZHVsZXMsIHdoZXJlIHRoZSBwcmVm
aXg8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHRoZSBZQU5HIG1vZHVsZSBuYW1lIGFuZCB0
aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmluZWQgYnkgdGhlPG86cD48L286cD48L3NwYW4+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmcXVvdDtuYW1lc3BhY2UmcXVvdDsgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVsZS48bzpw
PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpZZXQgdGhlIGV4YW1w
bGVzIGluIHNlY3Rpb24gOC4zLjYgZG9uJ3Qgc2VlbSB0byB1c2UgbmFtZXNwYWNlIHByZWZpeGVz
IGluIHZlcnkgbWFueSBwbGFjZXMsIGUuZy4gd2h5IGlzIGl0ICZxdW90Oy9leGFtcGxlLW1vZDpl
dmVudDEvbmFtZT0nam9lJyZxdW90OyBhbmQgbm90ICZxdW90Oy9leGFtcGxlLW1vZDpldmVudDEv
ZXhhbXBsZS1tb2Q6bmFtZT0nam9lJyZxdW90Oz8mbmJzcDsgSXMgdGhlIGV4YW1wbGUgd3Jvbmcs
IG9yIG90aGVyd2lzZSB3aGF0IGFtIEkgbWlzc2luZz8gOi0pPGJyPg0KPGJyPg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmx0O1JSJmd0OyBTZWN0aW9uIDguMy42IG9mIHdoaWNo
IGRvY3VtZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NClRo
YW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf
TWFpbE9yaWdpbmFsQm9keSI+L21hcnRpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Um9iPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf
TWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhlcmUgaXMgbm8g
c3RhbmRhcmQgWFBhdGggaW1wbGVtZW50YXRpb24gdGhhdCBjYW4ganVzdCB0YWtlIGFuIFhNTDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij5pbnN0YW5jZSBkb2N1bWVudCAmIzQzOyBZQU5HIG1vZHVsZSBhbmQg
ZmlndXJlIG91dCB3aGF0IHRvIGRvLiZuYnNwOyBDdXN0b208bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Y29k
ZSBpcyBuZWVkZWQgdG8gY29ubmVjdCB0aGluZ3MgdG9nZXRoZXIuJm5ic3A7IFRoaXMgcHJvcG9z
YWwgZG9lc24ndDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5jaGFuZ2UgdGhpcy48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k
eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4vbWFy
dGluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij5BIG5vcm1hbCBYUGF0aCBpbXBsZW1lbnRhdGlvbiB3aWxsIG5vdCBm
aW5kIGFueSBuYW1lc3BhY2UgbWFwcGluZyBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dGhlPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPnByZWZpeGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+QW4gWFBhdGggZXhwcmVzc2lvbiBoYXMgbm8gY29uY2VwdCBvZiB0aGUgJnF1b3Q7
Y3VycmVudCBtb2R1bGUmcXVvdDsgaW5oZXJpdGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmZyb208bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+dGhlIHBhcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5saWtlIHRoZSBKU09O
IGVuY29kaW5nLiBUaGlzIGlzIHByb2JsZW1hdGljIGZvciBwcmVkaWNhdGVzPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsgL2lldGYt
aW50ZXJmYWNlczppbnRlcmZhY2VzL2ludGVyZmFjZVtuYW1lPSdldGgwJ108bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlhQYXRoIHNheXMgdGhlIG1pc3NpbmcgcHJl
Zml4ZXMgZm9yICdpbnRlcmZhY2UnIGFuZCAnbmFtZScgYXJlIHNpbXBseTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij5taXNzaW5nIChubyBuYW1lc3BhY2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGUgSlNPTiBl
bmNvZGluZyBzYXlzICZxdW90O2lldGYtaW50ZXJmYWNlcyZxdW90OyBpcyB1c2VkIGZvciAnaW50
ZXJmYWNlcycuIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4naW50ZXJmYWNlJy48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+VGhlcmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBmb3IgdGhlICduYW1lJyBub2RlIGluc2lk
ZSBhIHByZWRpY2F0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PlNvIHlvdSBtdXN0IG1lYW4gdGhlIGZ1bGwgbW9kdWxlIG5hbWUgd2lsbCBiZSB1c2VkIGF0IGV2
ZXJ5IG5vZGU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz
cDsgL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2Vb
aWV0Zi1pbnRlcmZhY2VzOm5hbWU9J2V0aDAnXTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPi9tYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BbmR5PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhtbSwgc28geW91IG1lYW4gY2hhbmdl
IHRoZSBsZWFmICZxdW90O3N0cmVhbS14cGF0aC1maWx0ZXImcXVvdDsgdG8gc2F5OjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IG8mbmJzcDsgVGhlIHNldCBvZiBuYW1lc3BhY2UgZGVjbGFyYXRpb25zIGhhcyBvbmUgbWVtYmVy
IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5lYWNo
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgWUFORyBtb2R1bGUgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIuJm5ic3A7IFRoaXMgbWVt
YmVyIG1hcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGZyb20gdGhlIFlBTkcgbW9kdWxlIG5hbWUgdG8gdGhlIFlBTkcgbW9kdWxlIG5h
bWVzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIG1lYW5zIHRoYXQgaW4gdGhl
IFhQYXRoIGV4cHJlc3Npb24sIHRoZSBtb2R1bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+bmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZlcyBhcyB0aGUgcHJlZml4LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IC4uLi4gYW5kIHRoZW4gYWxzbyBnaXZlIGFuIGV4YW1wbGUgb2YgdGhpcy48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBUaGlzIGlzIHByb2JhYmx5IHdoYXQgd2UgbmVlZCB0byBkbyBpbiBhbGwgcGxhY2VzIHdo
ZXJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnlhbmc6
eHBhdGgxLjA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp
cyB1c2VkLCBnb2luZyBmb3J3YXJkLiZuYnNwOyBNYXliZSBldmVuIGRlZmluZSBhIG5ldyB0eXBl
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB5YW5nOnhwYXRoMS4w
LTIgKG5hbWU/KSB3aXRoIHRoZSBzZXQgb2YgbmFtZXNwYWNlIGRlY2xhcmF0aW9uczxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnVpbHQtaW4uPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5XZSBzaG91bGQg
YXZvaWQgbWFraW5nIG9mZi10aGUtc2hlbGYgaW1wbGVtZW50YXRpb25zIG9mIHN0YW5kYXJkcyBs
aWtlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPlhQYXRoIHVudXNhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5B
dCB0aGUgdmVyeSBsZWFzdCB0aGlzIHNob3VsZCBiZSBvbmx5IGF2YWlsYWJsZSBpZiB0aGUgc2Vy
dmVyIHN1cHBvcnRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPml0PG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPih3aXRo
IGEgY2FwYWJpbGl0eSBVUkkpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jmx0O1JSJmd0OyBTbyB3ZSBuZWVkIGFuIHVwZGF0ZSB0byBSRkM3OTUxPzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
UmVzaGFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAvbWFydGluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZndDsgTGFkYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
Z3Q7ICZndDsgSG93IGlzIHRoaXMgc3VwcG9zZWQgdG8gd29yayB3aXRoIEpTT04/PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IC9tYXJ0aW48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IDwvc3Bhbj48YSBocmVmPSJt
YWlsdG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICZndDsgJmd0OyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9z
cGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0tPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IExhZGlzbGF2IExob3RrYTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBIZWFkLCBDWi5OSUMgTGFiczxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBQR1AgS2V5IElEOiAweEI4
RjkyQjA4QTlGNzZDNjc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV0bW9k
IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPm5ldG1vZCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5uZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5uZXRtb2RAaWV0Zi5vcmc8L3Nw
YW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwv
YT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxicj4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BE8F576F2A5644D885546576B9CDB0F8ciscocom_--


From nobody Thu Oct 11 08:56:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D371130E1B for ; Thu, 11 Oct 2018 08:56: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, DKIMWL_WL_MED=-0.001, 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 s0Km_NvdF-L7 for ; Thu, 11 Oct 2018 08:56:24 -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 84CB2130DF3 for ; Thu, 11 Oct 2018 08:56:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64055; q=dns/txt; s=iport; t=1539273383; x=1540482983; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=D21CR7QfkxqiDNnGckYmMT4HKKJdb6I5Lo6TshEv4Yc=; b=D8gO6K/zSzk8bdWzEhH4S0A0tGUqqrNl4jo0A1K+/ANyVvofyHsprs35 hcfomRyy/rqXoLzN2W/ZYZVxaWCbovCQ92TNIxh9OJfBNKaw0wVdC0XXn jNVYb3XCa9eI/wFOy7130c3YmJdk+XHkMj0zMd4vqMaF9tJ3dHQkpPcFH Y=;
X-IronPort-AV: E=Sophos;i="5.54,368,1534809600"; d="scan'208,217";a="7168909"
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; 11 Oct 2018 15:56:21 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9BFuKwb030109; Thu, 11 Oct 2018 15:56:20 GMT
To: "Reshad Rahman (rrahman)" 
Cc: Martin Bjorklund , "netmod@ietf.org" 
References:  <20181011.122137.1647095802972927089.mbj@tail-f.com> <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 11 Oct 2018 16:56:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------69F31FB9FB948F839665BC10"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 15:56:28 -0000

This is a multi-part message in MIME format.
--------------69F31FB9FB948F839665BC10
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Reshad,

Please see RW: inline.


On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
>
> Hi Rob,
>
> *From: *netmod  on behalf of "Robert Wilton 
> -X (rwilton - ENSOFT LIMITED at Cisco)" 
> *Date: *Thursday, October 11, 2018 at 7:17 AM
> *To: *Martin Bjorklund 
> *Cc: *"netmod@ietf.org" 
> *Subject: *Re: [netmod] xpath expressions in JSON
>
> On 11/10/2018 11:50, Martin Bjorklund wrote:
>
>     Robert Wilton wrote:
>
>         On 11/10/2018 11:21, Martin Bjorklund wrote:
>
>             Andy Bierman
>             wrote:
>
>                 On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
>                 
>
>                 wrote:
>
>                     Andy Bierman
>                     wrote:
>
>                         On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman
>                         (rrahman) <
>
>                     rrahman@cisco.com>
>
>                         wrote:
>
>                             On 2018-10-10, 9:59 AM, "netmod on behalf
>                             of Martin Bjorklund" <
>
>                             netmod-bounces@ietf.orgon
>                             behalf of
>                             mbj@tail-f.com> wrote:
>
>                                  Ladislav Lhotka
>                             wrote:
>
>                                  > Martin Bjorklund
>                             writes:
>
>                                  >
>
>                                  > > Hi,
>
>                                  > >
>
>                                  > > While reviewing restconf-notif, I
>                             saw this example:
>
>                                  > >
>
>                                  > >    {
>
>                                  > >      
>                             "ietf-subscribed-notifications:input": {
>
>                                  > >          "stream": "NETCONF",
>
>                                  > >          "stream-xpath-filter":
>                             "/ds:foo/",
>
>                                  > >          "dscp": "10"
>
>                                  > >       }
>
>                                  > >    }
>
>                                  > >
>
>                                  > > Note the "stream-xpath-filter". 
>                             It has a prefix in the XPath
>
>                             string.
>
>                                  > > How are prefixes declared when
>                             JSON is used?
>
>                                  > >
>
>                                  > > The leaf "stream-xpath-filter" says:
>
>                                 > >
>
>                                  > >               o  The set of
>                             namespace declarations are those in
>
>                             scope on
>
>                                  > >                  the
>                             'stream-xpath-filter' leaf element.
>
>                                  > >
>
>                                  > > (I think I provided that text...)
>
>                                  > >
>
>                                  > > This assumes that the encoding is
>                             XML, or at leas that the
>
>                     encoding
>
>                                  > > can somehow transfer namespace
>                             declarations.
>
>                                  >
>
>                                  > It can't. There are two options:
>
>                                  >
>
>                                  > 1. have different representations
>                             of this value in XML and JSON,
>
>                                  >    analogically to instance
>                             indentifiers (sec. 6.11 in RFC 7951).
>
>                                  >
>
>                                  > 2. use a module name rather than a
>                             prefix in XML, too.
>
>                                  >
>
>                                  > I would suggest #2.
>
>                              But that means making non-backwards
>                             compatible change to the XML
>
>                             representation?
>
>                         Not really. It means NETMOD WG would be
>                         creating its own special
>
>                         variant
>
>                     of
>
>                         XPath.
>
>                     Not at all.  What I propose is perfectly fine,
>                     legal XPath 1.0.
>
>                     XPath 1.0 says that an XPath expression is
>                     evaluated in a context.
>
>                     One item in the context is a set of mappings from
>                      to ,
>
>                     where  is used to lookup prefixes used in
>                     the XPath
>
>                     expression, e.g. in "/foo:interfaces" "foo" is the
>                     prefix.
>
>                     It is perfectly fine to say that the prefix
>                     mapping set is this:
>
>                         "ietf-interfaces" ->
>                     "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
>                         "ietf-ip"         ->
>                     "urn:ietf:params:xml:ns:yang:ietf-ip"
>
>                     and use that to evaluate the expression
>
>                       
>                     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
>
>                 The XPath expression is normally parsed within an XML
>                 instance
>
>                 document.
>
>                 There are "xmlns" attributes present that map the
>                 prefix to a
>
>                 namespace URI.
>
>                 These mappings will not be present in the JSON at all.
>
>                 A custom XPath implementation is required to magically
>                 identify the
>
>                 prefix
>
>                 as a module name and magically find the namespace URI
>                 for the module
>
>                 name.
>
>             I disagree.  You need an XPath implementation + custom
>             code to set up
>
>             the environment.
>
>         This is OK, but can we just use the JSON encoding instance
>         identifier
>
>         format exactly?  I.e .RFC 7951 section 6.11.
>
>         So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
>
>         can trivially be expanded to:
>
>         "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",
>
>         and then interpreted with the context:
>
>              "ietf-interfaces" ->
>         "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>
>            "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
>
>     *this* would require a custom XPath implementation.
>
> Why?  I.e. how is this different from stating "Custom code is needed 
> to connect things together"?
>
>
>     and it is not obvious what the rules for the "auto-assignment" of
>
>     prefixes would be.  For example:
>
>       /ietf-interfaces//ietf-ip:address[../foo]
>
>     what is the prefix for "foo"?
>
> OK, so here the module for "../foo" would need to be specified.
>
> Perhaps the rule that I'm looking for is the module name may be 
> omitted when it matches the parent node module, and can easily be 
> inferred.  I.e. so that for any XPath string, it is possible to 
> trivially expand it without any additional schema context.
>
> It just seems to be that requiring the long hand of 
> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled" 
> seems like it will get very verbose, and I wonder whether we are 
> introducing yet another Xpath format to YANG.
>  I’m willing to live with verbosity if it avoids the need of 
> another format.
>
RW:

This is already looks like another format:

Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241 sec 
8.9.5.1

          
         


The standard JSON encoding for instance-data (IIRC, the same scheme is 
used for CBOR) uses the module-name but omits it where it matches the 
parent (e.g.

"/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled")


RFC 8040 query parameter is as described below, but having looked at the 
examples I'm not really sure how that is meant to work :-)



>
> Finally, I'm trying to figure out have RFC 8040 query parameter (sect 
> 4.8.4), which also uses XPath expressions is meant to work.  That states:
>
>
> The set of namespace declarations is the set of prefix and
>       namespace pairs for all supported YANG modules, where the prefix
>       is the YANG module name and the namespace is as defined by the
>       "namespace" statement in the YANG module.
>
>
> Yet the examples in section 8.3.6 don't seem to use namespace prefixes 
> in very many places, e.g. why is it "/example-mod:event1/name='joe'" 
> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example 
> wrong, or otherwise what am I missing? :-)
>
>  Section 8.3.6 of which document?
>
RFC 8040.

Thanks,
Rob

> Regards,
>
> Reshad.
>
>
> Thanks,
> Rob
>
>
>
>     /martin
>
>         Thanks,
>
>         Rob
>
>             There is no standard XPath implementation that can just
>             take an XML
>
>             instance document + YANG module and figure out what to
>             do.  Custom
>
>             code is needed to connect things together.  This proposal
>             doesn't
>
>             change this.
>
>             /martin
>
>                 A normal XPath implementation will not find any
>                 namespace mapping for
>
>                 the
>
>                 prefixes.
>
>                 An XPath expression has no concept of the "current
>                 module" inherited
>
>                 from
>
>                 the parent
>
>                 like the JSON encoding. This is problematic for predicates
>
>                     /ietf-interfaces:interfaces/interface[name='eth0']
>
>                 XPath says the missing prefixes for 'interface' and
>                 'name' are simply
>
>                 missing (no namespace).
>
>                 The JSON encoding says "ietf-interfaces" is used for
>                 'interfaces'. and
>
>                 'interface'.
>
>                 There is no specification for the 'name' node inside a
>                 predicate.
>
>                 So you must mean the full module name will be used at
>                 every node:
>
>                  
>                 /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']
>
>                     /martin
>
>                 Andy
>
>                                  Hmm, so you mean change the leaf
>                             "stream-xpath-filter" to say:
>
>                                           o  The set of namespace
>                             declarations has one member for
>
>                     each
>
>                                              YANG module supported by
>                             the server.  This member maps
>
>                                              from the YANG module name
>                             to the YANG module namespace.
>
>                                              This means that in the
>                             XPath expression, the module
>
>                     name
>
>                                              serves as the prefix.
>
>                                  .... and then also give an example of
>                             this.
>
>                                  This is probably what we need to do
>                             in all places where
>
>                     yang:xpath1.0
>
>                                  is used, going forward.  Maybe even
>                             define a new type
>
>                                  yang:xpath1.0-2 (name?) with the set
>                             of namespace declarations
>
>                                  built-in.
>
>                         We should avoid making off-the-shelf
>                         implementations of standards like
>
>                         XPath unusable.
>
>                         At the very least this should be only
>                         available if the server supports
>
>                         it
>
>                         (with a capability URI)
>
>                              So we need an update to RFC7951?
>
>                             Regards,
>
>                             Reshad.
>
>                         Andy
>
>                                  /martin
>
>                                  >
>
>                                  > Lada
>
>                                  >
>
>                                  > >
>
>                                  > > How is this supposed to work with
>                             JSON?
>
>                                  > >
>
>                                  > >
>
>                                  > > /martin
>
>                                  > >
>
>                                  > >
>                             _______________________________________________
>
>                                  > > netmod mailing list
>
>                                  > >
>                             netmod@ietf.org
>
>                                  > >
>                             https://www.ietf.org/mailman/listinfo/netmod
>
>                                  >
>
>                                  > --
>
>                                  > Ladislav Lhotka
>
>                                  > Head, CZ.NIC Labs
>
>                                  > PGP Key ID: 0xB8F92B08A9F76C67
>
>                                  >
>
>                                 
>                             _______________________________________________
>
>                                  netmod mailing list
>
>                             netmod@ietf.org
>
>                             https://www.ietf.org/mailman/listinfo/netmod
>
>                             _______________________________________________
>
>                             netmod mailing list
>
>                             netmod@ietf.org
>
>                             https://www.ietf.org/mailman/listinfo/netmod
>
>             _______________________________________________
>
>             netmod mailing list
>
>             netmod@ietf.org
>
>             https://www.ietf.org/mailman/listinfo/netmod
>
>             ..
>
>     .
>
>
>


--------------69F31FB9FB948F839665BC10
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Reshad,

    
Please see RW: inline.

    

    

    
On 11/10/2018 16:34, Reshad Rahman
      (rrahman) wrote:

    

    

      
      
      
      

        
Hi Rob,

        
 

        

          
From: netmod
              <netmod-bounces@ietf.org> on behalf of "Robert
              Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
              <rwilton@cisco.com>

              Date: Thursday, October 11, 2018 at 7:17 AM

              To: Martin Bjorklund <mbj@tail-f.com>

              Cc: "netmod@ietf.org" <netmod@ietf.org>

              Subject: Re: [netmod] xpath expressions in JSON

        

        

          
 

        

        
 

        
 

        

          
On 11/10/2018
              11:50, Martin Bjorklund wrote:

        

        

          
Robert Wilton <rwilton@cisco.com> wrote:

          

            
 

            
On 11/10/2018 11:21, Martin Bjorklund wrote:

            

              
Andy Bierman <andy@yumaworks.com> wrote:

              

                
On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund <mbj@tail-f.com>

                
wrote:

                
 

                

                  
Andy Bierman <andy@yumaworks.com> wrote:

                  

                    
On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <

                  

                  
rrahman@cisco.com>

                  

                    
wrote:

                    
 

                    

                      
On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <

                      
netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:

                      
 

                      
     Ladislav Lhotka <lhotka@nic.cz> wrote:

                      
     > Martin Bjorklund <mbj@tail-f.com> writes:

                      
     >

                      
     > > Hi,

                      
     > >

                      
     > > While reviewing restconf-notif, I saw this example:

                      
     > >

                      
     > >    {

                      
     > >       "ietf-subscribed-notifications:input": {

                      
     > >          "stream": "NETCONF",

                      
     > >          "stream-xpath-filter": "/ds:foo/",

                      
     > >          "dscp": "10"

                      
     > >       }

                      
     > >    }

                      
     > >

                      
     > > Note the "stream-xpath-filter".  It has a prefix in the XPath

                      
string.

                      
     > > How are prefixes declared when JSON is used?

                      
     > >

                      
     > > The leaf "stream-xpath-filter" says:

                      
     > >

                      
     > >               o  The set of namespace declarations are those in

                      
scope on

                      
     > >                  the 'stream-xpath-filter' leaf element.

                      
     > >

                      
     > > (I think I provided that text...)

                      
     > >

                      
     > > This assumes that the encoding is XML, or at leas that the

                    

                  

                  
encoding

                  

                    

                      
     > > can somehow transfer namespace declarations.

                      
     >

                      
     > It can't. There are two options:

                      
     >

                      
     > 1. have different representations of this value in XML and JSON,

                      
     >    analogically to instance indentifiers (sec. 6.11 in RFC 7951).

                      
     >

                      
     > 2. use a module name rather than a prefix in XML, too.

                      
     >

                      
     > I would suggest #2.

                      
<RR> But that means making non-backwards compatible change to the XML

                      
representation?

                      
 

                    

                    
Not really. It means NETMOD WG would be creating its own special

                    
variant

                  

                  
of

                  

                    
XPath.

                  

                  
Not at all.  What I propose is perfectly fine, legal XPath 1.0.

                  
 

                  
XPath 1.0 says that an XPath expression is evaluated in a context.

                  
One item in the context is a set of mappings from <prefix> to <uri>,

                  
where <prefix> is used to lookup prefixes used in the XPath

                  
expression, e.g. in "/foo:interfaces" "foo" is the prefix.

                  
 

                  
It is perfectly fine to say that the prefix mapping set is this:

                  
 

                  
    "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"

                  
    "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"

                  
 

                  
and use that to evaluate the expression

                  
 

                  
   /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4

                  
 

                  
 

                  
 

                

                
The XPath expression is normally parsed within an XML instance

                
document.

                
There are "xmlns" attributes present that map the prefix to a

                
namespace URI.

                
These mappings will not be present in the JSON at all.

                
 

                
A custom XPath implementation is required to magically identify the

                
prefix

                
as a module name and magically find the namespace URI for the module

                
name.

              

              
I disagree.  You need an XPath implementation + custom code to set up

              
the environment.

            

            
This is OK, but can we just use the JSON encoding instance identifier

            
format exactly?  I.e .RFC 7951 section 6.11.

            
 

            
So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"

            
 

            
can trivially be expanded to:

            
 

            
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",

            
 

            
and then interpreted with the context:

            
     "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"

            
   "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"

          

          
*this* would require a custom XPath implementation.

        

        
Why?  I.e. how is
            this different from stating "Custom code is needed to
            connect things together"?

            

            

            

        

          
 

          
and it is not obvious what the rules for the "auto-assignment" of

          
prefixes would be.  For example:

          
 

          
  /ietf-interfaces//ietf-ip:address[../foo]

          
 

          
what is the prefix for "foo"?

        

        
OK, so here the
            module for "../foo" would need to be specified.

            

            Perhaps the rule that I'm looking for is the module name may
            be omitted when it matches the parent node module, and can
            easily be inferred.  I.e. so that for any XPath string, it
            is possible to trivially expand it without any additional
            schema context.

            

            It just seems to be that requiring the long hand of
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled"
            seems like it will get very verbose, and I wonder whether we
            are introducing yet another Xpath format to YANG.

            <RR> I’m willing to live with verbosity if it avoids
            the need of another format.

      

    

    RW:

    

    This is already looks like another format:

    

    Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241
    sec 8.9.5.1

    

    
         <filter xmlns:t="http://example.com/schema/1.2/config"
                 type="xpath"
                 select="/t:top/t:users/t:user[t:name='fred']"/>
        </get-config>

    

    The standard JSON encoding for instance-data (IIRC, the same scheme
    is used for CBOR) uses the module-name but omits it where it matches
    the parent (e.g.
    
"/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled")


    

    RFC 8040 query parameter is as described below, but having looked at
    the examples I'm not really sure how that is meant to work :-)

    

    

    

    

      

        

        


            Finally, I'm trying to figure out have RFC 8040 query
            parameter (sect 4.8.4), which also uses XPath expressions is
            meant to work.  That states:

            

            

            

        
The set of namespace declarations is the set of prefix and

        
      namespace pairs for all supported YANG modules, where the prefix

        
      is the YANG module name and the namespace is as defined by the

        
      "namespace" statement in the YANG module.

        


            Yet the examples in section 8.3.6 don't seem to use
            namespace prefixes in very many places, e.g. why is it
            "/example-mod:event1/name='joe'" and not
            "/example-mod:event1/example-mod:name='joe'"?  Is the
            example wrong, or otherwise what am I missing? :-)

            

            

        
<RR> Section
            8.3.6 of which document?

      

    

    RFC 8040.

    

    Thanks,

    Rob

    

    

      

        

        
 

        
Regards,

        
Reshad.

        


            Thanks,

            Rob

            

            

            

            

        

          
 

          
 

          
 

          
/martin

          
 

          
 

          
 

          

            
Thanks,

            
Rob

            
 

            
 

            

              
There is no standard XPath implementation that can just take an XML

              
instance document + YANG module and figure out what to do.  Custom

              
code is needed to connect things together.  This proposal doesn't

              
change this.

              
 

              
 

              
/martin

              
 

              
 

              

                
A normal XPath implementation will not find any namespace mapping for

                
the

                
prefixes.

                
 

                
An XPath expression has no concept of the "current module" inherited

                
from

                
the parent

                
like the JSON encoding. This is problematic for predicates

                
 

                
    /ietf-interfaces:interfaces/interface[name='eth0']

                
 

                
XPath says the missing prefixes for 'interface' and 'name' are simply

                
missing (no namespace).

                
The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and

                
'interface'.

                
There is no specification for the 'name' node inside a predicate.

                
 

                
So you must mean the full module name will be used at every node:

                
 

                
  /ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']

                
 

                
 

                
 

                

                  
/martin

                  
 

                  
 

                

                
Andy

                
 

                
 

                

                  

                    

                      
     Hmm, so you mean change the leaf "stream-xpath-filter" to say:

                      
 

                      
              o  The set of namespace declarations has one member for

                    

                  

                  
each

                  

                    

                      
                 YANG module supported by the server.  This member maps

                      
                 from the YANG module name to the YANG module namespace.

                      
 

                      
                 This means that in the XPath expression, the module

                    

                  

                  
name

                  

                    

                      
                 serves as the prefix.

                      
 

                      
     .... and then also give an example of this.

                      
 

                      
     This is probably what we need to do in all places where

                    

                  

                  
yang:xpath1.0

                  

                    

                      
     is used, going forward.  Maybe even define a new type

                      
     yang:xpath1.0-2 (name?) with the set of namespace declarations

                      
     built-in.

                      
 

                    

                    
We should avoid making off-the-shelf implementations of standards like

                    
XPath unusable.

                    
At the very least this should be only available if the server supports

                    
it

                    
(with a capability URI)

                    
 

                    
 

                    
 

                    

                      
<RR> So we need an update to RFC7951?

                      
 

                      
Regards,

                      
Reshad.

                      
 

                      
 

                    

                    
Andy

                    
 

                    
 

                    

                      
     /martin

                      
 

                      
 

                      
 

                      
 

                      
 

                      
     >

                      
     > Lada

                      
     >

                      
     > >

                      
     > > How is this supposed to work with JSON?

                      
     > >

                      
     > >

                      
     > > /martin

                      
     > >

                      
     > > _______________________________________________

                      
     > > netmod mailing list

                      
     > > netmod@ietf.org

                      
     > > https://www.ietf.org/mailman/listinfo/netmod

                      
     >

                      
     > --

                      
     > Ladislav Lhotka

                      
     > Head, CZ.NIC Labs

                      
     > PGP Key ID: 0xB8F92B08A9F76C67

                      
     >

                      
 

                      
     _______________________________________________

                      
     netmod mailing list

                      
     netmod@ietf.org

                      
     https://www.ietf.org/mailman/listinfo/netmod

                      
 

                      
 

                      
_______________________________________________

                      
netmod mailing list

                      
netmod@ietf.org

                      
https://www.ietf.org/mailman/listinfo/netmod

                      
 

                    

                  

                

              

              
_______________________________________________

              
netmod mailing list

              
netmod@ietf.org

              
https://www.ietf.org/mailman/listinfo/netmod

              
..

              
 

            

          

          
.

          
 

        

        


            

          

      

    

    

  


--------------69F31FB9FB948F839665BC10--


From nobody Thu Oct 11 09:11:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08B6130EB8 for ; Thu, 11 Oct 2018 09:11:56 -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, 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 8w7F0iUM5KNS for ; Thu, 11 Oct 2018 09:11:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34795130E1B for ; Thu, 11 Oct 2018 09:11:54 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 47FF41AE0310; Thu, 11 Oct 2018 18:11:51 +0200 (CEST)
Date: Thu, 11 Oct 2018 18:11:50 +0200 (CEST)
Message-Id: <20181011.181150.1840683183107627057.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>
References: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 16:11:57 -0000

Robert Wilton  wrote:
> =

> =

> On 11/10/2018 11:50, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 11/10/2018 11:21, Martin Bjorklund wrote:
> >>> Andy Bierman  wrote:
> >>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
> >>>> wrote:
> >>>>
> >>>>> Andy Bierman  wrote:
> >>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>>>> rrahman@cisco.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund=
" <
> >>>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
> >>>>>>>
> >>>>>>>       Ladislav Lhotka  wrote:
> >>>>>>>       > Martin Bjorklund  writes:
> >>>>>>>       >
> >>>>>>>       > > Hi,
> >>>>>>>       > >
> >>>>>>>       > > While reviewing restconf-notif, I saw this example:=

> >>>>>>>       > >
> >>>>>>>       > >    {
> >>>>>>>       > >       "ietf-subscribed-notifications:input": {
> >>>>>>>       > >          "stream": "NETCONF",
> >>>>>>>       > >          "stream-xpath-filter": "/ds:foo/",
> >>>>>>>       > >          "dscp": "10"
> >>>>>>>       > >       }
> >>>>>>>       > >    }
> >>>>>>>       > >
> >>>>>>>       > > Note the "stream-xpath-filter".  It has a prefix in=
 the XPath
> >>>>>>> string.
> >>>>>>>       > > How are prefixes declared when JSON is used?
> >>>>>>>       > >
> >>>>>>>       > > The leaf "stream-xpath-filter" says:
> >>>>>>>       > >
> >>>>>>>       > >               o The set of namespace declarations a=
re those
> >>>>>>>       > >               in
> >>>>>>> scope on
> >>>>>>>       > >                  the 'stream-xpath-filter' leaf ele=
ment.
> >>>>>>>       > >
> >>>>>>>       > > (I think I provided that text...)
> >>>>>>>       > >
> >>>>>>>       > > This assumes that the encoding is XML, or at leas t=
hat the
> >>>>> encoding
> >>>>>>>       > > can somehow transfer namespace declarations.
> >>>>>>>       >
> >>>>>>>       > It can't. There are two options:
> >>>>>>>       >
> >>>>>>>       > 1. have different representations of this value in XM=
L and
> >>>>>>>       > JSON,
> >>>>>>>       >    analogically to instance indentifiers (sec. 6.11 i=
n RFC
> >>>>>>>       >    7951).
> >>>>>>>       >
> >>>>>>>       > 2. use a module name rather than a prefix in XML, too=
.=

> >>>>>>>       >
> >>>>>>>       > I would suggest #2.
> >>>>>>>  But that means making non-backwards compatible change to=
 the XML
> >>>>>>> representation?
> >>>>>>>
> >>>>>> Not really. It means NETMOD WG would be creating its own speci=
al
> >>>>>> variant
> >>>>> of
> >>>>>> XPath.
> >>>>> Not at all.  What I propose is perfectly fine, legal XPath 1.0.=

> >>>>>
> >>>>> XPath 1.0 says that an XPath expression is evaluated in a conte=
xt.
> >>>>> One item in the context is a set of mappings from  to <=
uri>,
> >>>>> where  is used to lookup prefixes used in the XPath
> >>>>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
> >>>>>
> >>>>> It is perfectly fine to say that the prefix mapping set is this=
:
> >>>>>
> >>>>>      "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-int=
erfaces"
> >>>>>      "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"=

> >>>>>
> >>>>> and use that to evaluate the expression
> >>>>>
> >>>>>     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-=
ip/ipv4
> >>>>>
> >>>>>
> >>>>>
> >>>> The XPath expression is normally parsed within an XML instance
> >>>> document.
> >>>> There are "xmlns" attributes present that map the prefix to a
> >>>> namespace URI.
> >>>> These mappings will not be present in the JSON at all.
> >>>>
> >>>> A custom XPath implementation is required to magically identify =
the
> >>>> prefix
> >>>> as a module name and magically find the namespace URI for the mo=
dule
> >>>> name.
> >>> I disagree.  You need an XPath implementation + custom code to se=
t up
> >>> the environment.
> >> This is OK, but can we just use the JSON encoding instance identif=
ier
> >> format exactly?=A0 I.e .RFC 7951 section 6.11.
> >>
> >> So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
> >>
> >> can trivially be expanded to:
> >>
> >> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv=
4/ietf-ip:enabled",
> >>
> >> and then interpreted with the context:
> >>       "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-inter=
faces"
> >>     "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> > *this* would require a custom XPath implementation.
> Why?=A0 I.e. how is this different from stating "Custom code is neede=
d
> to connect things together"?

B/c the specification of XPath allows you to (actually, *requires* you
to) construct the set of prefix strings to url mappings.

This is "custom code to connect things".

But changing the syntax means changin the specification.

> > and it is not obvious what the rules for the "auto-assignment" of
> > prefixes would be.  For example:
> >
> >    /ietf-interfaces//ietf-ip:address[../foo]
> >
> > what is the prefix for "foo"?
> OK, so here the module for "../foo" would need to be specified.
> =

> Perhaps the rule that I'm looking for is the module name may be
> omitted when it matches the parent node module, and can easily be
> inferred.=A0 I.e. so that for any XPath string, it is possible to
> trivially expand it without any additional schema context.
> =

> It just seems to be that requiring the long hand of
> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/i=
etf-ip:enabled"
> seems like it will get very verbose, and I wonder whether we are
> introducing yet another Xpath format to YANG.

I agree that it is very verbose.  But do not mix XPath expressions in
leaf values (which is what this thread is about) with
instance-identfiers.

> Finally, I'm trying to figure out have RFC 8040 query parameter (sect=

> 4.8.4), which also uses XPath expressions is meant to work. That
> states:
> =

> The set of namespace declarations is the set of prefix and
>       namespace pairs for all supported YANG modules, where the prefi=
x
>       is the YANG module name and the namespace is as defined by the
>       "namespace" statement in the YANG module.

Perfect!  It seems the authors of 8040 thought of this ;-)

> Yet the examples in section 8.3.6 don't seem to use namespace prefixe=
s
> in very many places, e.g. why is it "/example-mod:event1/name=3D'joe'=
"
> and not "/example-mod:event1/example-mod:name=3D'joe'"?=A0 Is the exa=
mple
> wrong, or otherwise what am I missing? :-)

It seems the example is wrong!


/martin


From nobody Thu Oct 11 09:16:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FE130EB8 for ; Thu, 11 Oct 2018 09:16:56 -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, 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 XhRYild45xtd for ; Thu, 11 Oct 2018 09:16:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B76F8130E1B for ; Thu, 11 Oct 2018 09:16:53 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id ECE361AE0310; Thu, 11 Oct 2018 18:16:52 +0200 (CEST)
Date: Thu, 11 Oct 2018 18:16:52 +0200 (CEST)
Message-Id: <20181011.181652.1065283062766537981.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: rrahman@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 16:16:56 -0000

Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiBIaSBSZXNoYWQsDQo+
IA0KPiBQbGVhc2Ugc2VlIFJXOiBpbmxpbmUuDQo+IA0KPiANCj4gT24gMTEvMTAvMjAxOCAxNjoz
NCwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6DQo+ID4NCj4gPiBIaSBSb2IsDQo+ID4N
Cj4gPiAqRnJvbTogKm5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv
ZiAiUm9iZXJ0IFdpbHRvbiAtWA0KPiA+ICoocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENp
c2NvKSIgPHJ3aWx0b25AY2lzY28uY29tPg0KPiA+ICpEYXRlOiAqVGh1cnNkYXksIE9jdG9iZXIg
MTEsIDIwMTggYXQgNzoxNyBBTQ0KPiA+ICpUbzogKk1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls
LWYuY29tPg0KPiA+ICpDYzogKiJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQo+
ID4gKlN1YmplY3Q6ICpSZTogW25ldG1vZF0geHBhdGggZXhwcmVzc2lvbnMgaW4gSlNPTg0KPiA+
DQo+ID4gT24gMTEvMTAvMjAxOCAxMTo1MCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPg0K
PiA+ICAgICBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT48bWFpbHRvOnJ3aWx0b25A
Y2lzY28uY29tPndyb3RlOg0KPiA+DQo+ID4gICAgICAgICBPbiAxMS8xMC8yMDE4IDExOjIxLCBN
YXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgQW5keSBCaWVybWFu
DQo+ID4gICAgICAgICAgICAgPGFuZHlAeXVtYXdvcmtzLmNvbT48bWFpbHRvOmFuZHlAeXVtYXdv
cmtzLmNvbT53cm90ZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBPbiBXZWQsIE9jdCAxMCwg
MjAxOCBhdCAxMTozOSBQTSwgTWFydGluIEJqb3JrbHVuZA0KPiA+ICAgICAgICAgICAgICAgICA8
bWJqQHRhaWwtZi5jb20+PG1haWx0bzptYmpAdGFpbC1mLmNvbT4NCj4gPg0KPiA+ICAgICAgICAg
ICAgICAgICB3cm90ZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgQW5keSBCaWVybWFu
DQo+ID4gICAgICAgICAgICAgICAgICAgICA8YW5keUB5dW1hd29ya3MuY29tPjxtYWlsdG86YW5k
eUB5dW1hd29ya3MuY29tPndyb3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg
T24gV2VkLCBPY3QgMTAsIDIwMTggYXQgNjo1OSBQTSwgUmVzaGFkIFJhaG1hbg0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgICAgIChycmFobWFuKSA8DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAg
ICAgIHJyYWhtYW5AY2lzY28uY29tPG1haWx0bzpycmFobWFuQGNpc2NvLmNvbT4+DQo+ID4NCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBPbiAyMDE4LTEwLTEwLCA5OjU5IEFNLCAibmV0bW9kIG9uIGJlaGFsZg0K
PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiBNYXJ0aW4gQmpvcmtsdW5kIiA8DQo+
ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPm9uDQo+ID4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGJlaGFsZiBvZg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt
YmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCj4gPg0KPiA+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCBMYWRpc2xhdiBMaG90a2ENCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGxob3RrYUBuaWMuY3o+PG1haWx0bzpsaG90a2FA
bmljLmN6Pndyb3RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDC
oMKgID4gTWFydGluIEJqb3JrbHVuZA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
bWJqQHRhaWwtZi5jb20+PG1haWx0bzptYmpAdGFpbC1mLmNvbT53cml0ZXM6DQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPg0KPiA+DQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgIMKgwqDCoD4gPiBIaSwNCj4gPg0KPiA+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoMKgwqDCoCA+ID4gV2hpbGUgcmV2aWV3aW5nIHJlc3Rjb25mLW5vdGlmLCBJ
DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNhdyB0aGlzIGV4YW1wbGU6DQo+ID4N
Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+DQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+wqDCoMKgIHsNCj4gPg0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID7CoMKgwqDCoMKgwqANCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRp
b25zOmlucHV0Ijogew0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDC
oMKgID4gPsKgwqDCoMKgwqDCoMKgwqDCoCAic3RyZWFtIjogIk5FVENPTkYiLA0KPiA+DQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4gPsKgwqDCoMKgwqDCoMKgwqDC
oCAic3RyZWFtLXhwYXRoLWZpbHRlciI6DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICIvZHM6Zm9vLyIsDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKg
IMKgPiA+wqDCoMKgwqDCoMKgwqDCoMKgICJkc2NwIjogIjEwIg0KPiA+DQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4gPsKgwqDCoMKgwqDCoCB9DQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+wqDCoMKgIH0NCj4gPg0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID4NCj4gPg0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID4gTm90ZSB0aGUgInN0cmVhbS14cGF0
aC1maWx0ZXIiLsKgDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIEl0IGhhcyBhIHBy
ZWZpeCBpbiB0aGUgWFBhdGgNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJpbmcuDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+
IEhvdyBhcmUgcHJlZml4ZXMgZGVjbGFyZWQgd2hlbg0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBKU09OIGlzIHVzZWQ/DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqDCoMKgwqAgPiA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDC
oMKgwqAgPiA+IFRoZSBsZWFmICJzdHJlYW0teHBhdGgtZmlsdGVyIiBzYXlzOg0KPiA+DQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgPiA+DQo+ID4NCj4gPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBvwqAgVGhlIHNldCBvZg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuYW1l
c3BhY2UgZGVjbGFyYXRpb25zIGFyZSB0aG9zZSBpbg0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNjb3BlIG9uDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqDCoMKgwqAgPiA+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGUNCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ3N0cmVhbS14cGF0aC1maWx0ZXInIGxlYWYg
ZWxlbWVudC4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+
ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID4gKEkg
dGhpbmsgSSBwcm92aWRlZCB0aGF0IHRleHQuLi4pDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqDCoMKgwqAgPiA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqDCoMKgwqAgPiA+IFRoaXMgYXNzdW1lcyB0aGF0IHRoZSBlbmNvZGluZyBpcw0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYTUwsIG9yIGF0IGxlYXMgdGhhdCB0aGUNCj4g
Pg0KPiA+ICAgICAgICAgICAgICAgICAgICAgZW5jb2RpbmcNCj4gPg0KPiA+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+ID4gY2FuIHNvbWVob3cgdHJhbnNmZXIgbmFtZXNw
YWNlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlY2xhcmF0aW9ucy4NCj4gPg0K
PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+DQo+ID4NCj4gPiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiBJdCBjYW4ndC4gVGhlcmUgYXJlIHR3
byBvcHRpb25zOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKg
ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+IDEuIGhh
dmUgZGlmZmVyZW50IHJlcHJlc2VudGF0aW9ucw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBvZiB0aGlzIHZhbHVlIGluIFhNTCBhbmQgSlNPTiwNCj4gPg0KPiA+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+wqDCoMKgIGFuYWxvZ2ljYWxseSB0byBpbnN0YW5j
ZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmRlbnRpZmllcnMgKHNlYy4gNi4x
MSBpbiBSRkMgNzk1MSkuDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDC
oMKgwqAgPg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4g
Mi4gdXNlIGEgbW9kdWxlIG5hbWUgcmF0aGVyIHRoYW4gYQ0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBwcmVmaXggaW4gWE1MLCB0b28uDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqDCoMKgwqAgPg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIMKgwqDCoMKgID4gSSB3b3VsZCBzdWdnZXN0ICMyLg0KPiA+DQo+ID4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxSUj4gQnV0IHRoYXQgbWVhbnMgbWFraW5nIG5vbi1iYWNrd2FyZHMN
Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSBjaGFuZ2UgdG8gdGhl
IFhNTA0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcHJlc2VudGF0aW9u
Pw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgTm90IHJlYWxseS4gSXQgbWVhbnMg
TkVUTU9EIFdHIHdvdWxkIGJlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXRpbmcg
aXRzIG93biBzcGVjaWFsDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICB2YXJpYW50
DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIG9mDQo+ID4NCj4gPiAgICAgICAgICAgICAg
ICAgICAgICAgICBYUGF0aC4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgTm90IGF0IGFs
bC7CoCBXaGF0IEkgcHJvcG9zZSBpcyBwZXJmZWN0bHkgZmluZSwNCj4gPiAgICAgICAgICAgICAg
ICAgICAgIGxlZ2FsIFhQYXRoIDEuMC4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgWFBh
dGggMS4wIHNheXMgdGhhdCBhbiBYUGF0aCBleHByZXNzaW9uIGlzDQo+ID4gICAgICAgICAgICAg
ICAgICAgICBldmFsdWF0ZWQgaW4gYSBjb250ZXh0Lg0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
ICAgICBPbmUgaXRlbSBpbiB0aGUgY29udGV4dCBpcyBhIHNldCBvZiBtYXBwaW5ncyBmcm9tDQo+
ID4gICAgICAgICAgICAgICAgICAgICA8cHJlZml4PiB0byA8dXJpPiwNCj4gPg0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgd2hlcmUgPHByZWZpeD4gaXMgdXNlZCB0byBsb29rdXAgcHJlZml4ZXMg
dXNlZCBpbg0KPiA+ICAgICAgICAgICAgICAgICAgICAgdGhlIFhQYXRoDQo+ID4NCj4gPiAgICAg
ICAgICAgICAgICAgICAgIGV4cHJlc3Npb24sIGUuZy4gaW4gIi9mb286aW50ZXJmYWNlcyIgImZv
byIgaXMgdGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICBwcmVmaXguDQo+ID4NCj4gPiAgICAg
ICAgICAgICAgICAgICAgIEl0IGlzIHBlcmZlY3RseSBmaW5lIHRvIHNheSB0aGF0IHRoZSBwcmVm
aXgNCj4gPiAgICAgICAgICAgICAgICAgICAgIG1hcHBpbmcgc2V0IGlzIHRoaXM6DQo+ID4NCj4g
PiAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCAiaWV0Zi1pbnRlcmZhY2VzIiAtPg0KPiA+ICAg
ICAgICAgICAgICAgICAgICAgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWludGVy
ZmFjZXMiDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCAiaWV0Zi1pcCLCoMKg
wqDCoMKgwqDCoMKgIC0+DQo+ID4gICAgICAgICAgICAgICAgICAgICAidXJuOmlldGY6cGFyYW1z
OnhtbDpuczp5YW5nOmlldGYtaXAiDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIGFuZCB1
c2UgdGhhdCB0byBldmFsdWF0ZSB0aGUgZXhwcmVzc2lvbg0KPiA+DQo+ID4gICAgICAgICAgICAg
ICAgICAgICDCoMKgDQo+ID4gICAgICAgICAgICAgICAgICAgICAvaWV0Zi1pbnRlcmZhY2VzOmlu
dGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRmLWlwL2lwdjQNCj4gPg0KPiA+
ICAgICAgICAgICAgICAgICBUaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBub3JtYWxseSBwYXJzZWQg
d2l0aGluIGFuIFhNTA0KPiA+ICAgICAgICAgICAgICAgICBpbnN0YW5jZQ0KPiA+DQo+ID4gICAg
ICAgICAgICAgICAgIGRvY3VtZW50Lg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIFRoZXJlIGFy
ZSAieG1sbnMiIGF0dHJpYnV0ZXMgcHJlc2VudCB0aGF0IG1hcCB0aGUNCj4gPiAgICAgICAgICAg
ICAgICAgcHJlZml4IHRvIGENCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBuYW1lc3BhY2UgVVJJ
Lg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIFRoZXNlIG1hcHBpbmdzIHdpbGwgbm90IGJlIHBy
ZXNlbnQgaW4gdGhlIEpTT04gYXQgYWxsLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIEEgY3Vz
dG9tIFhQYXRoIGltcGxlbWVudGF0aW9uIGlzIHJlcXVpcmVkIHRvIG1hZ2ljYWxseQ0KPiA+ICAg
ICAgICAgICAgICAgICBpZGVudGlmeSB0aGUNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBwcmVm
aXgNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBhcyBhIG1vZHVsZSBuYW1lIGFuZCBtYWdpY2Fs
bHkgZmluZCB0aGUgbmFtZXNwYWNlIFVSSQ0KPiA+ICAgICAgICAgICAgICAgICBmb3IgdGhlIG1v
ZHVsZQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIG5hbWUuDQo+ID4NCj4gPiAgICAgICAgICAg
ICBJIGRpc2FncmVlLsKgIFlvdSBuZWVkIGFuIFhQYXRoIGltcGxlbWVudGF0aW9uICsgY3VzdG9t
DQo+ID4gICAgICAgICAgICAgY29kZSB0byBzZXQgdXANCj4gPg0KPiA+ICAgICAgICAgICAgIHRo
ZSBlbnZpcm9ubWVudC4NCj4gPg0KPiA+ICAgICAgICAgVGhpcyBpcyBPSywgYnV0IGNhbiB3ZSBq
dXN0IHVzZSB0aGUgSlNPTiBlbmNvZGluZyBpbnN0YW5jZQ0KPiA+ICAgICAgICAgaWRlbnRpZmll
cg0KPiA+DQo+ID4gICAgICAgICBmb3JtYXQgZXhhY3RseT/CoCBJLmUgLlJGQyA3OTUxIHNlY3Rp
b24gNi4xMS4NCj4gPg0KPiA+ICAgICAgICAgU28gIi9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNl
cy9pbnRlcmZhY2UvaWV0Zi1pcDppcHY0L2VuYWJsZWQiDQo+ID4NCj4gPiAgICAgICAgIGNhbiB0
cml2aWFsbHkgYmUgZXhwYW5kZWQgdG86DQo+ID4NCj4gPiAgICAgICAgICIvaWV0Zi1pbnRlcmZh
Y2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRmLWlwOmlwdjQvaWV0
Zi1pcDplbmFibGVkIiwNCj4gPg0KPiA+ICAgICAgICAgYW5kIHRoZW4gaW50ZXJwcmV0ZWQgd2l0
aCB0aGUgY29udGV4dDoNCj4gPg0KPiA+ICAgICAgICAgwqDCoMKgwqAgImlldGYtaW50ZXJmYWNl
cyIgLT4NCj4gPiAgICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pbnRl
cmZhY2VzIg0KPiA+DQo+ID4gICAgICAgICDCoMKgICJpZXRmLWlwIsKgwqDCoMKgwqDCoMKgwqAg
LT4gInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWlwIg0KPiA+DQo+ID4gICAgICp0
aGlzKiB3b3VsZCByZXF1aXJlIGEgY3VzdG9tIFhQYXRoIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+
ID4gV2h5P8KgIEkuZS4gaG93IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gc3RhdGluZyAiQ3VzdG9t
IGNvZGUgaXMgbmVlZGVkDQo+ID4gdG8gY29ubmVjdCB0aGluZ3MgdG9nZXRoZXIiPw0KPiA+DQo+
ID4NCj4gPiAgICAgYW5kIGl0IGlzIG5vdCBvYnZpb3VzIHdoYXQgdGhlIHJ1bGVzIGZvciB0aGUg
ImF1dG8tYXNzaWdubWVudCIgb2YNCj4gPg0KPiA+ICAgICBwcmVmaXhlcyB3b3VsZCBiZS7CoCBG
b3IgZXhhbXBsZToNCj4gPg0KPiA+ICAgICDCoCAvaWV0Zi1pbnRlcmZhY2VzLy9pZXRmLWlwOmFk
ZHJlc3NbLi4vZm9vXQ0KPiA+DQo+ID4gICAgIHdoYXQgaXMgdGhlIHByZWZpeCBmb3IgImZvbyI/
DQo+ID4NCj4gPiBPSywgc28gaGVyZSB0aGUgbW9kdWxlIGZvciAiLi4vZm9vIiB3b3VsZCBuZWVk
IHRvIGJlIHNwZWNpZmllZC4NCj4gPg0KPiA+IFBlcmhhcHMgdGhlIHJ1bGUgdGhhdCBJJ20gbG9v
a2luZyBmb3IgaXMgdGhlIG1vZHVsZSBuYW1lIG1heSBiZQ0KPiA+IG9taXR0ZWQgd2hlbiBpdCBt
YXRjaGVzIHRoZSBwYXJlbnQgbm9kZSBtb2R1bGUsIGFuZCBjYW4gZWFzaWx5IGJlDQo+ID4gaW5m
ZXJyZWQuwqAgSS5lLiBzbyB0aGF0IGZvciBhbnkgWFBhdGggc3RyaW5nLCBpdCBpcyBwb3NzaWJs
ZSB0bw0KPiA+IHRyaXZpYWxseSBleHBhbmQgaXQgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzY2hl
bWEgY29udGV4dC4NCj4gPg0KPiA+IEl0IGp1c3Qgc2VlbXMgdG8gYmUgdGhhdCByZXF1aXJpbmcg
dGhlIGxvbmcgaGFuZCBvZg0KPiA+ICIvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1p
bnRlcmZhY2VzOmludGVyZmFjZS9pZXRmLWlwOmlwdjQvaWV0Zi1pcDplbmFibGVkIg0KPiA+IHNl
ZW1zIGxpa2UgaXQgd2lsbCBnZXQgdmVyeSB2ZXJib3NlLCBhbmQgSSB3b25kZXIgd2hldGhlciB3
ZSBhcmUNCj4gPiBpbnRyb2R1Y2luZyB5ZXQgYW5vdGhlciBYcGF0aCBmb3JtYXQgdG8gWUFORy4N
Cj4gPiA8UlI+IEnigJltIHdpbGxpbmcgdG8gbGl2ZSB3aXRoIHZlcmJvc2l0eSBpZiBpdCBhdm9p
ZHMgdGhlIG5lZWQgb2YNCj4gPiBhbm90aGVyIGZvcm1hdC4NCj4gPg0KPiBSVzoNCj4gDQo+IFRo
aXMgaXMgYWxyZWFkeSBsb29rcyBsaWtlIGFub3RoZXIgZm9ybWF0Og0KDQpBZ2FpbiwgaXQgaXMg
Km5vdCogYW5vdGhlciBmb3JtYXQhDQoNCg0KPiANCj4gWHBhdGggZmlsdGVycyB1c2VkIGluIE5l
dGNvbmYgdXNlIGV4cGxpY2l0IG5hbWVzcGFjZXMsIGUuZy4gcmZjNjI0MQ0KPiBzZWMgOC45LjUu
MQ0KPiANCj4gICAgICAgICAgPGZpbHRlciB4bWxuczp0PSJodHRwOi8vZXhhbXBsZS5jb20vc2No
ZW1hLzEuMi9jb25maWciDQo+ICAgICAgICAgICAgICAgICAgdHlwZT0ieHBhdGgiDQo+ICAgICAg
ICAgICAgICAgICAgc2VsZWN0PSIvdDp0b3AvdDp1c2Vycy90OnVzZXJbdDpuYW1lPSdmcmVkJ10i
Lz4NCj4gICAgICAgICA8L2dldC1jb25maWc+DQoNCkluIHRoaXMgY2FzZSwgdGhlIHByZWZpeC1z
dHJpbmcgLT4gdXJpIG1hcHBpbmcgaXMgdGFrZW4gZnJvbSB0aGUgWE1MDQpuYW1lc3BhY2UgZGVj
bGFyYXRpb24gaW4gdGhlIFhNTCBkb2N1bWVudC4NCg0KDQo+IFRoZSBzdGFuZGFyZCBKU09OIGVu
Y29kaW5nIGZvciBpbnN0YW5jZS1kYXRhIChJSVJDLCB0aGUgc2FtZSBzY2hlbWUgaXMNCj4gdXNl
ZCBmb3IgQ0JPUikgdXNlcyB0aGUgbW9kdWxlLW5hbWUgYnV0IG9taXRzIGl0IHdoZXJlIGl0IG1h
dGNoZXMgdGhlDQo+IHBhcmVudCAoZS5nLg0KPiANCj4gIi9pZXRmLWludGVyZmFjZXM6aW50ZXJm
YWNlcy9pbnRlcmZhY2UvaWV0Zi1pcDppcHY0L2VuYWJsZWQiKQ0KDQpEbyB5b3UgbWVhbiBpbnN0
YW5jZS1pZGVudGlmaWVyPyAgSWYgc28sIGl0IGlzIGEgc3BlY2lhbCB0eXBlIHRoYXQNCmhhcHBl
bnMgdG8gc2hhcmUgdGhlIHN5bnRheCB3aXRoIFhQYXRoLCBhbmQgdGhlIEpTT04gc3ludGF4IGlz
IGRlZmluZWQNCmluIFJGQyA3OTUxIHNlY3Rpb24gNi4xMS4NCg0KPiANCj4gUkZDIDgwNDAgcXVl
cnkgcGFyYW1ldGVyIGlzIGFzIGRlc2NyaWJlZCBiZWxvdywgYnV0IGhhdmluZyBsb29rZWQgYXQN
Cj4gdGhlIGV4YW1wbGVzIEknbSBub3QgcmVhbGx5IHN1cmUgaG93IHRoYXQgaXMgbWVhbnQgdG8g
d29yayA6LSkNCg0KSW4gdGhpcyBjYXNlLCB0aGUgcHJlZml4LXN0cmluZyAtPiB1cmkgbWFwcGlu
ZyBpcyBnaXZlbiBpbiB0aGUNCmRvY3VtZW50Lg0KDQoNCldlIHVzZSBYUGF0aCBpbiB2YXJpb3Vz
IGRpZmZlcmVudCBwbGFjZXMsIGFuZCBlYWNoIHBsYWNlIE1VU1Qgc3BlY2lmeQ0KdGhlIGV2YWx1
YXRpb24gY29udGV4dC4NCg0KDQoNCi9tYXJ0aW4NCg0KDQo+ID4gRmluYWxseSwgSSdtIHRyeWlu
ZyB0byBmaWd1cmUgb3V0IGhhdmUgUkZDIDgwNDAgcXVlcnkgcGFyYW1ldGVyIChzZWN0DQo+ID4g
NC44LjQpLCB3aGljaCBhbHNvIHVzZXMgWFBhdGggZXhwcmVzc2lvbnMgaXMgbWVhbnQgdG8gd29y
ay7CoCBUaGF0DQo+ID4gc3RhdGVzOg0KPiA+DQo+ID4NCj4gPiBUaGUgc2V0IG9mIG5hbWVzcGFj
ZSBkZWNsYXJhdGlvbnMgaXMgdGhlIHNldCBvZiBwcmVmaXggYW5kDQo+ID4gwqDCoMKgwqDCoCBu
YW1lc3BhY2UgcGFpcnMgZm9yIGFsbCBzdXBwb3J0ZWQgWUFORyBtb2R1bGVzLCB3aGVyZSB0aGUg
cHJlZml4DQo+ID4gwqDCoMKgwqDCoCBpcyB0aGUgWUFORyBtb2R1bGUgbmFtZSBhbmQgdGhlIG5h
bWVzcGFjZSBpcyBhcyBkZWZpbmVkIGJ5IHRoZQ0KPiA+IMKgwqDCoMKgwqAgIm5hbWVzcGFjZSIg
c3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVsZS4NCj4gPg0KPiA+DQo+ID4gWWV0IHRoZSBleGFt
cGxlcyBpbiBzZWN0aW9uIDguMy42IGRvbid0IHNlZW0gdG8gdXNlIG5hbWVzcGFjZSBwcmVmaXhl
cw0KPiA+IGluIHZlcnkgbWFueSBwbGFjZXMsIGUuZy4gd2h5IGlzIGl0ICIvZXhhbXBsZS1tb2Q6
ZXZlbnQxL25hbWU9J2pvZSciDQo+ID4gYW5kIG5vdCAiL2V4YW1wbGUtbW9kOmV2ZW50MS9leGFt
cGxlLW1vZDpuYW1lPSdqb2UnIj/CoCBJcyB0aGUgZXhhbXBsZQ0KPiA+IHdyb25nLCBvciBvdGhl
cndpc2Ugd2hhdCBhbSBJIG1pc3Npbmc/IDotKQ0KPiA+DQo+ID4gPFJSPiBTZWN0aW9uIDguMy42
IG9mIHdoaWNoIGRvY3VtZW50Pw0KPiA+DQo+IFJGQyA4MDQwLg0KPiANCj4gVGhhbmtzLA0KPiBS
b2INCj4gDQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IFJlc2hhZC4NCj4gPg0KPiA+DQo+ID4gVGhh
bmtzLA0KPiA+IFJvYg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAvbWFydGluDQo+ID4NCj4gPiAg
ICAgICAgIFRoYW5rcywNCj4gPg0KPiA+ICAgICAgICAgUm9iDQo+ID4NCj4gPiAgICAgICAgICAg
ICBUaGVyZSBpcyBubyBzdGFuZGFyZCBYUGF0aCBpbXBsZW1lbnRhdGlvbiB0aGF0IGNhbiBqdXN0
DQo+ID4gICAgICAgICAgICAgdGFrZSBhbiBYTUwNCj4gPg0KPiA+ICAgICAgICAgICAgIGluc3Rh
bmNlIGRvY3VtZW50ICsgWUFORyBtb2R1bGUgYW5kIGZpZ3VyZSBvdXQgd2hhdCB0bw0KPiA+ICAg
ICAgICAgICAgIGRvLsKgIEN1c3RvbQ0KPiA+DQo+ID4gICAgICAgICAgICAgY29kZSBpcyBuZWVk
ZWQgdG8gY29ubmVjdCB0aGluZ3MgdG9nZXRoZXIuwqAgVGhpcyBwcm9wb3NhbA0KPiA+ICAgICAg
ICAgICAgIGRvZXNuJ3QNCj4gPg0KPiA+ICAgICAgICAgICAgIGNoYW5nZSB0aGlzLg0KPiA+DQo+
ID4gICAgICAgICAgICAgL21hcnRpbg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIEEgbm9ybWFs
IFhQYXRoIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IGZpbmQgYW55DQo+ID4gICAgICAgICAgICAg
ICAgIG5hbWVzcGFjZSBtYXBwaW5nIGZvcg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIHRoZQ0K
PiA+DQo+ID4gICAgICAgICAgICAgICAgIHByZWZpeGVzLg0KPiA+DQo+ID4gICAgICAgICAgICAg
ICAgIEFuIFhQYXRoIGV4cHJlc3Npb24gaGFzIG5vIGNvbmNlcHQgb2YgdGhlICJjdXJyZW50DQo+
ID4gICAgICAgICAgICAgICAgIG1vZHVsZSIgaW5oZXJpdGVkDQo+ID4NCj4gPiAgICAgICAgICAg
ICAgICAgZnJvbQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIHRoZSBwYXJlbnQNCj4gPg0KPiA+
ICAgICAgICAgICAgICAgICBsaWtlIHRoZSBKU09OIGVuY29kaW5nLiBUaGlzIGlzIHByb2JsZW1h
dGljIGZvciBwcmVkaWNhdGVzDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgwqDCoMKgIC9pZXRm
LWludGVyZmFjZXM6aW50ZXJmYWNlcy9pbnRlcmZhY2VbbmFtZT0nZXRoMCddDQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgWFBhdGggc2F5cyB0aGUgbWlzc2luZyBwcmVmaXhlcyBmb3IgJ2ludGVy
ZmFjZScgYW5kDQo+ID4gICAgICAgICAgICAgICAgICduYW1lJyBhcmUgc2ltcGx5DQo+ID4NCj4g
PiAgICAgICAgICAgICAgICAgbWlzc2luZyAobm8gbmFtZXNwYWNlKS4NCj4gPg0KPiA+ICAgICAg
ICAgICAgICAgICBUaGUgSlNPTiBlbmNvZGluZyBzYXlzICJpZXRmLWludGVyZmFjZXMiIGlzIHVz
ZWQgZm9yDQo+ID4gICAgICAgICAgICAgICAgICdpbnRlcmZhY2VzJy4gYW5kDQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgJ2ludGVyZmFjZScuDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgVGhl
cmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBmb3IgdGhlICduYW1lJyBub2RlIGluc2lkZSBhDQo+ID4g
ICAgICAgICAgICAgICAgIHByZWRpY2F0ZS4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICBTbyB5
b3UgbXVzdCBtZWFuIHRoZSBmdWxsIG1vZHVsZSBuYW1lIHdpbGwgYmUgdXNlZCBhdA0KPiA+ICAg
ICAgICAgICAgICAgICBldmVyeSBub2RlOg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIMKgDQo+
ID4gICAgICAgICAgICAgICAgIC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pZXRmLWludGVy
ZmFjZXM6aW50ZXJmYWNlW2lldGYtaW50ZXJmYWNlczpuYW1lPSdldGgwJ10NCj4gPg0KPiA+ICAg
ICAgICAgICAgICAgICAgICAgL21hcnRpbg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgIEFuZHkN
Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCBIbW0sIHNvIHlv
dSBtZWFuIGNoYW5nZSB0aGUgbGVhZg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
c3RyZWFtLXhwYXRoLWZpbHRlciIgdG8gc2F5Og0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG/CoCBUaGUgc2V0IG9mIG5hbWVz
cGFjZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWNsYXJhdGlvbnMgaGFzIG9u
ZSBtZW1iZXIgZm9yDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgIGVhY2gNCj4gPg0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCBZQU5HIG1vZHVsZSBzdXBwb3J0ZWQgYnkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGhlIHNlcnZlci7CoCBUaGlzIG1lbWJlciBtYXBzDQo+ID4NCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZnJvbSB0
aGUgWUFORyBtb2R1bGUgbmFtZQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byB0
aGUgWUFORyBtb2R1bGUgbmFtZXNwYWNlLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoFRoaXMgbWVhbnMgdGhhdCBp
biB0aGUNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWFBhdGggZXhwcmVzc2lvbiwg
dGhlIG1vZHVsZQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICBuYW1lDQo+ID4NCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgc2VydmVzIGFzIHRoZSBwcmVmaXguDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqDCoMKgwqAgLi4uLiBhbmQgdGhlbiBhbHNvIGdpdmUgYW4gZXhhbXBsZSBvZg0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzLg0KPiA+DQo+ID4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIMKgwqDCoMKgIFRoaXMgaXMgcHJvYmFibHkgd2hhdCB3ZSBuZWVkIHRv
IGRvDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIGFsbCBwbGFjZXMgd2hlcmUN
Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgeWFuZzp4cGF0aDEuMA0KPiA+DQo+ID4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgIGlzIHVzZWQsIGdvaW5nIGZvcndhcmQu
wqAgTWF5YmUgZXZlbg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmUgYSBu
ZXcgdHlwZQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgIHlh
bmc6eHBhdGgxLjAtMiAobmFtZT8pIHdpdGggdGhlIHNldA0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBvZiBuYW1lc3BhY2UgZGVjbGFyYXRpb25zDQo+ID4NCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgYnVpbHQtaW4uDQo+ID4NCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICBXZSBzaG91bGQgYXZvaWQgbWFraW5nIG9mZi10aGUtc2hlbGYNCj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICBpbXBsZW1lbnRhdGlvbnMgb2Ygc3RhbmRhcmRzIGxpa2UN
Cj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIFhQYXRoIHVudXNhYmxlLg0KPiA+DQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgQXQgdGhlIHZlcnkgbGVhc3QgdGhpcyBzaG91bGQg
YmUgb25seQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIGF2YWlsYWJsZSBpZiB0aGUgc2Vy
dmVyIHN1cHBvcnRzDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBpdA0KPiA+DQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgKHdpdGggYSBjYXBhYmlsaXR5IFVSSSkNCj4gPg0K
PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8UlI+IFNvIHdlIG5lZWQgYW4gdXBkYXRl
IHRvIFJGQzc5NTE/DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVnYXJk
cywNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXNoYWQuDQo+ID4NCj4g
PiAgICAgICAgICAgICAgICAgICAgICAgICBBbmR5DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqDCoMKgwqAgL21hcnRpbg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgwqDCoMKgID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICDCoMKgwqDCoCA+IExhZGENCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDC
oMKgwqDCoCA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAg
PiA+DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+IEhv
dyBpcyB0aGlzIHN1cHBvc2VkIHRvIHdvcmsgd2l0aA0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBKU09OPw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDC
oMKgID4gPg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4g
Pg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4gPiAvbWFy
dGluDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+DQo+
ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+DQo+ID4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDC
oMKgwqAgPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoMKgwqDCoCA+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4NCj4gPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPiA+DQo+ID4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+
ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKgwqAgPg0KPiA+DQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4gLS0NCj4gPg0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+IExhZGlzbGF2IExob3RrYQ0KPiA+DQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoMKgID4gSGVhZCwgQ1ouTklDIExh
YnMNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqDCoCA+IFBHUCBL
ZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgwqDCoMKgID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDC
oMKgwqDCoA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgwqDCoMKgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPg0KPiA+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZz4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+DQo+ID4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV0bW9kIG1haWxpbmcg
bGlzdA0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5ldG1vZEBpZXRmLm9y
ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4N
Cj4gPiAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiA+DQo+ID4gICAgICAgICAgICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+DQo+
ID4gICAgICAgICAgICAgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+
ID4NCj4gPiAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KPiA+DQo+ID4gICAgICAgICAgICAgLi4NCj4gPg0KPiA+ICAgICAuDQo+ID4NCj4g
Pg0KPiA+DQo+IA0K


From nobody Thu Oct 11 09:25:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42299130EA6 for ; Thu, 11 Oct 2018 09:25:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 KOBMC42wtBYp for ; Thu, 11 Oct 2018 09:25:24 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 EB7AC130E96 for ; Thu, 11 Oct 2018 09:25:23 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id w21-v6so7146626lff.6 for ; Thu, 11 Oct 2018 09:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jYaUGPxdFsVirh2FyUGluNyoIGiBVdpZW3wS9EguPzM=; b=jSV8xD+PmiEvuz0dYIiCfJN0bhvZiZ1KenyQaaIjP2Xrk5JN32FXHtuy83YSGEOp60 WtaPgdvwNWnuL3NYLSIdAFu4kbAvLodJuhjWNa8srEMDfPWFDKqKtTkxxn93QZmdNCDR FzqrphKd4zC6attl9qi6OJYx3oYy5ntbJPv3tG/8ZWE7konw3Z1k6psq0rhSBW27apk2 jUpsYBdW2hcBght92H9JfN44V+twYiiu/yf0vZ4mfSYNPpz0vpoKMGg/mXJngMjYoz+R v9M4fz9u4wuM5oV/68PGr/fUMvu5Vfvd0g+FS3LD7GfujJ/AnAwflggdSHK/17X+tcWb ZdLg==
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=jYaUGPxdFsVirh2FyUGluNyoIGiBVdpZW3wS9EguPzM=; b=Zyg/a7rJxbCZ1JIml1lsgPTdkQXu5DDbL/s4JCjw/Iw7DvRoJLhkx64s/OfBuoQILK bIlslbKauBT99J8Azq0A5C1qt3EUp3y59ZbHm5wbn9vZfWa5s7PbLGrvoQtXzCJhPpi3 GnqHkqanqEUuLi4Es53W8wm7UcSSHAAOYhtGfwtB3cqxFEDbwQMllGKj6RtdGIrbVSSp gs0OvjqHuLUTHpCL8kHQT8tA5Ugq8X1YmGVoTz5EUd6n3VQIVu/5lo773r6DKI1VGp2Y 8MpZUCp+HIApunV+z1Og0q+YtNlNfbbKzKlP5p5lLuYV843lwnrrtwia79VFF+TEhQvh /H/A==
X-Gm-Message-State: ABuFfoiMtROF9vHygYtOOs42R/aPLEg6PhoVq6fQFKTHFMMwTLr4sB82 9ljdwBCKugLidY2JrdS0p1bf9DWl6JqHrSFpvo287g==
X-Google-Smtp-Source: ACcGV63VFtY7n+xDdPvWVJ5XYTdLqqzwCtEZ3boZQ8USMN6KXg5UpnjEEo2Wcb5ylL/XLwZDd/GiBxWAT4VGbX94vEA=
X-Received: by 2002:a19:7709:: with SMTP id s9-v6mr1596145lfc.84.1539275121876;  Thu, 11 Oct 2018 09:25:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 11 Oct 2018 09:25:20 -0700 (PDT)
In-Reply-To: <20181011.181652.1065283062766537981.mbj@tail-f.com>
References: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>   <20181011.181652.1065283062766537981.mbj@tail-f.com>
From: Andy Bierman 
Date: Thu, 11 Oct 2018 09:25:20 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Robert Wilton , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000d9f63c0577f66a9c"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 16:25:28 -0000

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

On Thu, Oct 11, 2018 at 9:16 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > Hi Reshad,
> >
> > Please see RW: inline.
> >
> >
> > On 11/10/2018 16:34, Reshad Rahman (rrahman) wrote:
> > >
> > > Hi Rob,
> > >
> > > *From: *netmod  on behalf of "Robert Wilton
> -X
> > > *(rwilton - ENSOFT LIMITED at Cisco)" 
> > > *Date: *Thursday, October 11, 2018 at 7:17 AM
> > > *To: *Martin Bjorklund 
> > > *Cc: *"netmod@ietf.org" 
> > > *Subject: *Re: [netmod] xpath expressions in JSON
> > >
> > > On 11/10/2018 11:50, Martin Bjorklund wrote:
> > >
> > >     Robert Wilton wrote:
> > >
> > >         On 11/10/2018 11:21, Martin Bjorklund wrote:
> > >
> > >             Andy Bierman
> > >             wrote:
> > >
> > >                 On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund
> > >                 
> > >
> > >                 wrote:
> > >
> > >                     Andy Bierman
> > >                      >wrote:
> > >
> > >                         On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahma=
n
> > >                         (rrahman) <
> > >
> > >                     rrahman@cisco.com>
> > >
> > >                         wrote:
> > >
> > >                             On 2018-10-10, 9:59 AM, "netmod on behalf
> > >                             of Martin Bjorklund" <
> > >
> > >                             netmod-bounces@ietf.org netmod-bounces@ietf.org>on
> > >                             behalf of
> > >                             mbj@tail-f.com>
> wrote:
> > >
> > >                                  Ladislav Lhotka
> > >                              >wrote:
> > >
> > >                                  > Martin Bjorklund
> > >                              >writes:
> > >
> > >                                  >
> > >
> > >                                  > > Hi,
> > >
> > >                                  > >
> > >
> > >                                  > > While reviewing restconf-notif, =
I
> > >                             saw this example:
> > >
> > >                                  > >
> > >
> > >                                  > >    {
> > >
> > >                                  > >
> > >                             "ietf-subscribed-notifications:input": {
> > >
> > >                                  > >          "stream": "NETCONF",
> > >
> > >                                  > >          "stream-xpath-filter":
> > >                             "/ds:foo/",
> > >
> > >                                  > >          "dscp": "10"
> > >
> > >                                  > >       }
> > >
> > >                                  > >    }
> > >
> > >                                  > >
> > >
> > >                                  > > Note the "stream-xpath-filter".
> > >                             It has a prefix in the XPath
> > >
> > >                             string.
> > >
> > >                                  > > How are prefixes declared when
> > >                             JSON is used?
> > >
> > >                                  > >
> > >
> > >                                  > > The leaf "stream-xpath-filter"
> says:
> > >
> > >                                 > >
> > >
> > >                                  > >               o  The set of
> > >                             namespace declarations are those in
> > >
> > >                             scope on
> > >
> > >                                  > >                  the
> > >                             'stream-xpath-filter' leaf element.
> > >
> > >                                  > >
> > >
> > >                                  > > (I think I provided that text...=
)
> > >
> > >                                  > >
> > >
> > >                                  > > This assumes that the encoding i=
s
> > >                             XML, or at leas that the
> > >
> > >                     encoding
> > >
> > >                                  > > can somehow transfer namespace
> > >                             declarations.
> > >
> > >                                  >
> > >
> > >                                  > It can't. There are two options:
> > >
> > >                                  >
> > >
> > >                                  > 1. have different representations
> > >                             of this value in XML and JSON,
> > >
> > >                                  >    analogically to instance
> > >                             indentifiers (sec. 6.11 in RFC 7951).
> > >
> > >                                  >
> > >
> > >                                  > 2. use a module name rather than a
> > >                             prefix in XML, too.
> > >
> > >                                  >
> > >
> > >                                  > I would suggest #2.
> > >
> > >                              But that means making non-backwards
> > >                             compatible change to the XML
> > >
> > >                             representation?
> > >
> > >                         Not really. It means NETMOD WG would be
> > >                         creating its own special
> > >
> > >                         variant
> > >
> > >                     of
> > >
> > >                         XPath.
> > >
> > >                     Not at all.  What I propose is perfectly fine,
> > >                     legal XPath 1.0.
> > >
> > >                     XPath 1.0 says that an XPath expression is
> > >                     evaluated in a context.
> > >
> > >                     One item in the context is a set of mappings from
> > >                      to ,
> > >
> > >                     where  is used to lookup prefixes used in
> > >                     the XPath
> > >
> > >                     expression, e.g. in "/foo:interfaces" "foo" is th=
e
> > >                     prefix.
> > >
> > >                     It is perfectly fine to say that the prefix
> > >                     mapping set is this:
> > >
> > >                         "ietf-interfaces" ->
> > >                     "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > >
> > >                         "ietf-ip"         ->
> > >                     "urn:ietf:params:xml:ns:yang:ietf-ip"
> > >
> > >                     and use that to evaluate the expression
> > >
> > >
> > >                     /ietf-interfaces:interfaces/
> ietf-interfaces:interface/ietf-ip/ipv4
> > >
> > >                 The XPath expression is normally parsed within an XML
> > >                 instance
> > >
> > >                 document.
> > >
> > >                 There are "xmlns" attributes present that map the
> > >                 prefix to a
> > >
> > >                 namespace URI.
> > >
> > >                 These mappings will not be present in the JSON at all=
.
> > >
> > >                 A custom XPath implementation is required to magicall=
y
> > >                 identify the
> > >
> > >                 prefix
> > >
> > >                 as a module name and magically find the namespace URI
> > >                 for the module
> > >
> > >                 name.
> > >
> > >             I disagree.  You need an XPath implementation + custom
> > >             code to set up
> > >
> > >             the environment.
> > >
> > >         This is OK, but can we just use the JSON encoding instance
> > >         identifier
> > >
> > >         format exactly?  I.e .RFC 7951 section 6.11.
> > >
> > >         So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/
> enabled"
> > >
> > >         can trivially be expanded to:
> > >
> > >         "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> ietf-ip:ipv4/ietf-ip:enabled",
> > >
> > >         and then interpreted with the context:
> > >
> > >              "ietf-interfaces" ->
> > >         "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > >
> > >            "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> > >
> > >     *this* would require a custom XPath implementation.
> > >
> > > Why?  I.e. how is this different from stating "Custom code is needed
> > > to connect things together"?
> > >
> > >
> > >     and it is not obvious what the rules for the "auto-assignment" of
> > >
> > >     prefixes would be.  For example:
> > >
> > >       /ietf-interfaces//ietf-ip:address[../foo]
> > >
> > >     what is the prefix for "foo"?
> > >
> > > OK, so here the module for "../foo" would need to be specified.
> > >
> > > Perhaps the rule that I'm looking for is the module name may be
> > > omitted when it matches the parent node module, and can easily be
> > > inferred.  I.e. so that for any XPath string, it is possible to
> > > trivially expand it without any additional schema context.
> > >
> > > It just seems to be that requiring the long hand of
> > > "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> ietf-ip:ipv4/ietf-ip:enabled"
> > > seems like it will get very verbose, and I wonder whether we are
> > > introducing yet another Xpath format to YANG.
> > >  I=E2=80=99m willing to live with verbosity if it avoids the need=
 of
> > > another format.
> > >
> > RW:
> >
> > This is already looks like another format:
>
> Again, it is *not* another format!
>
>
> >
> > Xpath filters used in Netconf use explicit namespaces, e.g. rfc6241
> > sec 8.9.5.1
> >
> >           >                  type=3D"xpath"
> >                  select=3D"/t:top/t:users/t:user[t:name=3D'fred']"/>
> >         
>
> In this case, the prefix-string -> uri mapping is taken from the XML
> namespace declaration in the XML document.
>
>
> > The standard JSON encoding for instance-data (IIRC, the same scheme is
> > used for CBOR) uses the module-name but omits it where it matches the
> > parent (e.g.
> >
> > "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled")
>
> Do you mean instance-identifier?  If so, it is a special type that
> happens to share the syntax with XPath, and the JSON syntax is defined
> in RFC 7951 section 6.11.
>
> >
> > RFC 8040 query parameter is as described below, but having looked at
> > the examples I'm not really sure how that is meant to work :-)
>
> In this case, the prefix-string -> uri mapping is given in the
> document.
>
>
> We use XPath in various different places, and each place MUST specify
> the evaluation context.
>
>

You are right.
Our custom XPath code needs to be told to get prefix mappings from XML or
YANG import-stmts
already, so 1 more internal mapping directly to module name is not going to
require
any significant changes to XPath processing.

More importantly, it does not require any redefinition of the XPath
standard.


>
>
> /martin
>

Andy


>
>
> > > Finally, I'm trying to figure out have RFC 8040 query parameter (sect
> > > 4.8.4), which also uses XPath expressions is meant to work.  That
> > > states:
> > >
> > >
> > > The set of namespace declarations is the set of prefix and
> > >       namespace pairs for all supported YANG modules, where the prefi=
x
> > >       is the YANG module name and the namespace is as defined by the
> > >       "namespace" statement in the YANG module.
> > >
> > >
> > > Yet the examples in section 8.3.6 don't seem to use namespace prefixe=
s
> > > in very many places, e.g. why is it "/example-mod:event1/name=3D'joe'=
"
> > > and not "/example-mod:event1/example-mod:name=3D'joe'"?  Is the examp=
le
> > > wrong, or otherwise what am I missing? :-)
> > >
> > >  Section 8.3.6 of which document?
> > >
> > RFC 8040.
> >
> > Thanks,
> > Rob
> >
> > > Regards,
> > >
> > > Reshad.
> > >
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > >
> > >     /martin
> > >
> > >         Thanks,
> > >
> > >         Rob
> > >
> > >             There is no standard XPath implementation that can just
> > >             take an XML
> > >
> > >             instance document + YANG module and figure out what to
> > >             do.  Custom
> > >
> > >             code is needed to connect things together.  This proposal
> > >             doesn't
> > >
> > >             change this.
> > >
> > >             /martin
> > >
> > >                 A normal XPath implementation will not find any
> > >                 namespace mapping for
> > >
> > >                 the
> > >
> > >                 prefixes.
> > >
> > >                 An XPath expression has no concept of the "current
> > >                 module" inherited
> > >
> > >                 from
> > >
> > >                 the parent
> > >
> > >                 like the JSON encoding. This is problematic for
> predicates
> > >
> > >                     /ietf-interfaces:interfaces/interface[name=3D'eth=
0']
> > >
> > >                 XPath says the missing prefixes for 'interface' and
> > >                 'name' are simply
> > >
> > >                 missing (no namespace).
> > >
> > >                 The JSON encoding says "ietf-interfaces" is used for
> > >                 'interfaces'. and
> > >
> > >                 'interface'.
> > >
> > >                 There is no specification for the 'name' node inside =
a
> > >                 predicate.
> > >
> > >                 So you must mean the full module name will be used at
> > >                 every node:
> > >
> > >
> > >                 /ietf-interfaces:interfaces/ietf-interfaces:interface=
[
> ietf-interfaces:name=3D'eth0']
> > >
> > >                     /martin
> > >
> > >                 Andy
> > >
> > >                                  Hmm, so you mean change the leaf
> > >                             "stream-xpath-filter" to say:
> > >
> > >                                           o  The set of namespace
> > >                             declarations has one member for
> > >
> > >                     each
> > >
> > >                                              YANG module supported by
> > >                             the server.  This member maps
> > >
> > >                                              from the YANG module nam=
e
> > >                             to the YANG module namespace.
> > >
> > >                                              This means that in the
> > >                             XPath expression, the module
> > >
> > >                     name
> > >
> > >                                              serves as the prefix.
> > >
> > >                                  .... and then also give an example o=
f
> > >                             this.
> > >
> > >                                  This is probably what we need to do
> > >                             in all places where
> > >
> > >                     yang:xpath1.0
> > >
> > >                                  is used, going forward.  Maybe even
> > >                             define a new type
> > >
> > >                                  yang:xpath1.0-2 (name?) with the set
> > >                             of namespace declarations
> > >
> > >                                  built-in.
> > >
> > >                         We should avoid making off-the-shelf
> > >                         implementations of standards like
> > >
> > >                         XPath unusable.
> > >
> > >                         At the very least this should be only
> > >                         available if the server supports
> > >
> > >                         it
> > >
> > >                         (with a capability URI)
> > >
> > >                              So we need an update to RFC7951?
> > >
> > >                             Regards,
> > >
> > >                             Reshad.
> > >
> > >                         Andy
> > >
> > >                                  /martin
> > >
> > >                                  >
> > >
> > >                                  > Lada
> > >
> > >                                  >
> > >
> > >                                  > >
> > >
> > >                                  > > How is this supposed to work wit=
h
> > >                             JSON?
> > >
> > >                                  > >
> > >
> > >                                  > >
> > >
> > >                                  > > /martin
> > >
> > >                                  > >
> > >
> > >                                  > >
> > >                             ______________________________
> _________________
> > >
> > >                                  > > netmod mailing list
> > >
> > >                                  > >
> > >                             netmod@ietf.org
> > >
> > >                                  > >
> > >                             https://www.ietf.org/mailman/
> listinfo/netmod
> > >
> > >                                  >
> > >
> > >                                  > --
> > >
> > >                                  > Ladislav Lhotka
> > >
> > >                                  > Head, CZ.NIC Labs
> > >
> > >                                  > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > >                                  >
> > >
> > >
> > >                             ______________________________
> _________________
> > >
> > >                                  netmod mailing list
> > >
> > >                             netmod@ietf.org
> > >
> > >                             https://www.ietf.org/mailman/
> listinfo/netmod
> > >
> > >                             ______________________________
> _________________
> > >
> > >                             netmod mailing list
> > >
> > >                             netmod@ietf.org
> > >
> > >                             https://www.ietf.org/mailman/
> listinfo/netmod
> > >
> > >             _______________________________________________
> > >
> > >             netmod mailing list
> > >
> > >             netmod@ietf.org
> > >
> > >             https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >             ..
> > >
> > >     .
> > >
> > >
> > >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

PGRpdiBkaXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPk9uIFRodSwgT2N0IDExLCAyMDE4IGF0IDk6MTYgQU0sIE1hcnRpbiBC
am9ya2x1bmQgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5j
b20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8
YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Um9iZXJ0IFdp
bHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2Nv
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSGkgUmVzaGFkLDxicj4NCiZndDsgPGJyPg0K
Jmd0OyBQbGVhc2Ugc2VlIFJXOiBpbmxpbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgT24gMTEvMTAvMjAxOCAxNjozNCwgUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6PGJy
Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIFJvYiw8YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgKkZyb206ICpuZXRtb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg
JnF1b3Q7Um9iZXJ0IFdpbHRvbiAtWDxicj4NCiZndDsgJmd0OyAqKHJ3aWx0b24gLSBFTlNPRlQg
TElNSVRFRCBhdCBDaXNjbykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2Nv
LmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAqRGF0ZTogKlRo
dXJzZGF5LCBPY3RvYmVyIDExLCAyMDE4IGF0IDc6MTcgQU08YnI+DQomZ3Q7ICZndDsgKlRvOiAq
TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpA
dGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICpDYzogKiZxdW90OzxhIGhyZWY9Im1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICpTdWJqZWN0OiAqUmU6IFtuZXRtb2RdIHhwYXRoIGV4cHJlc3Npb25zIGluIEpT
T048YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gMTEvMTAvMjAxOCAxMTo1MCwgTWFy
dGluIEJqb3JrbHVuZCB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDC
oFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndp
bHRvbkBjaXNjby5jb208L2E+Jmd0OyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25A
Y2lzY28uY29tIj5yd2k8d2JyPmx0b25AY2lzY28uY29tPC9hPiZndDt3cm90ZTo8YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoE9uIDExLzEwLzIwMTggMTE6MjEsIE1h
cnRpbiBCam9ya2x1bmQgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAg
wqAgwqAgwqAgwqAgwqBBbmR5IEJpZXJtYW48YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jr
cy5jb208L2E+Jmd0OyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv
bSI+YW48d2JyPmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0O3dyb3RlOjxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgT24gV2VkLCBPY3QgMTAsIDIw
MTggYXQgMTE6MzkgUE0sIE1hcnRpbiBCam9ya2x1bmQ8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0
YWlsLWYuY29tPC9hPiZndDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNv
bSI+bWJqQDx3YnI+dGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFuZHkgQmllcm1hbjxicj4N
CiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0OzxhIGhyZWY9Im1h
aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7Jmx0O21h
aWx0bzo8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbjx3YnI+ZHlAeXVtYXdv
cmtzLmNvbTwvYT4mZ3Q7d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCA2
OjU5IFBNLCBSZXNoYWQgUmFobWFuPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAocnJhaG1hbikgJmx0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0ibWFpbHRvOnJyYWht
YW5AY2lzY28uY29tIj5ycmFobWFuQGNpc2NvLmNvbTwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1h
aWx0bzpycmFobWFuQGNpc2NvLmNvbSI+cnJhaG08d2JyPmFuQGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0
Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPbiAyMDE4LTEwLTEwLCA5OjU5IEFN
LCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBNYXJ0aW4gQmpvcmtsdW5kJnF1b3Q7ICZsdDs8
YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmx0Ozx3YnI+bWFpbHRvOjxhIGhyZWY9Im1haWx0
bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHdi
cj4mZ3Q7b248YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoGJlaGFsZiBvZjxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpA
dGFpbC1mLmNvbTwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+
bWJqQDx3YnI+dGFpbC1mLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKg
wqDCoMKgIExhZGlzbGF2IExob3RrYTxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6
Ij5saG90a2FAbmljLmN6PC9hPiZndDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsaG90a2FA
bmljLmN6Ij5saG90a2FAPHdicj5uaWMuY3o8L2E+Jmd0O3dyb3RlOjxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
wqDCoMKgwqAgJmd0OyBNYXJ0aW4gQmpvcmtsdW5kPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0
YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7Jmx0O21haWx0bzo8YSBocmVmPSJtYWls
dG86bWJqQHRhaWwtZi5jb20iPm1iakA8d2JyPnRhaWwtZi5jb208L2E+Jmd0O3dyaXRlczo8YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgIMKgwqDCoCZndDsg
Jmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgwqDCoMKgwqAgJmd0OyAmZ3Q7IFdoaWxlIHJldmlld2luZyByZXN0Y29uZi1ub3RpZiwgSTxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
c2F3IHRoaXMgZXhhbXBsZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0Ozxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyAmZ3Q7wqDCoMKgIHs8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKg
wqDCoMKgICZndDsgJmd0O8KgwqDCoMKgwqDCoDxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJnF1b3Q7aWV0Zi1zdWJzY3JpYmVkLTx3YnI+
bm90aWZpY2F0aW9uczppbnB1dCZxdW90Ozogezxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0
O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0
OyAmZ3Q7wqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O3N0cmVhbSZxdW90OzogJnF1b3Q7TkVUQ09O
RiZxdW90Oyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0O8KgwqDCoMKgwqDCoMKg
wqDCoCAmcXVvdDtzdHJlYW0teHBhdGgtZmlsdGVyJnF1b3Q7Ojxicj4NCiZndDsgJmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJnF1b3Q7L2RzOmZvby8mcXVv
dDssPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqAgwqAmZ3Q7ICZndDvCoMKgwqDCoMKgwqDCoMKgwqAg
JnF1b3Q7ZHNjcCZxdW90OzogJnF1b3Q7MTAmcXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKg
ICZndDsgJmd0O8KgwqDCoMKgwqDCoCB9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZn
dDvCoMKgwqAgfTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDsgTm90ZSB0aGUgJnF1b3Q7c3RyZWFtLXhwYXRoLWZpbHRl
ciZxdW90Oy7CoDxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgSXQgaGFzIGEgcHJlZml4IGluIHRoZSBYUGF0aDxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
c3RyaW5nLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyAmZ3Q7IEhvdyBhcmUgcHJlZml4
ZXMgZGVjbGFyZWQgd2hlbjxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgSlNPTiBpcyB1c2VkPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDsgVGhlIGxlYWYgJnF1
b3Q7c3RyZWFtLXhwYXRoLWZpbHRlciZxdW90OyBzYXlzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKg
wqAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0O8KgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgb8KgIFRoZSBzZXQgb2Y8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMg
YXJlIHRob3NlIGluPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzY29wZSBvbjxicj4NCiZndDsgJmd0Ozxicj4N
CiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDC
oMKgwqAgJmd0OyAmZ3Q7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGU8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCYj
Mzk7c3RyZWFtLXhwYXRoLWZpbHRlciYjMzk7IGxlYWYgZWxlbWVudC48YnI+DQomZ3Q7ICZndDs8
YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oMKgwqDCoMKgICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyAmZ3Q7IChJ
IHRoaW5rIEkgcHJvdmlkZWQgdGhhdCB0ZXh0Li4uKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDsgVGhpcyBhc3N1bWVz
IHRoYXQgdGhlIGVuY29kaW5nIGlzPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBYTUwsIG9yIGF0IGxlYXMgdGhhdCB0aGU8YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVuY29k
aW5nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDsgY2FuIHNvbWVob3cgdHJhbnNm
ZXIgbmFtZXNwYWNlPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqBkZWNsYXJhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7IEl0IGNhbiYjMzk7dC4gVGhlcmUgYXJlIHR3
byBvcHRpb25zOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0Ozxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
wqDCoMKgwqAgJmd0OyAxLiBoYXZlIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnM8YnI+DQomZ3Q7
ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9mIHRoaXMg
dmFsdWUgaW4gWE1MIGFuZCBKU09OLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0O8KgwqDC
oCBhbmFsb2dpY2FsbHkgdG8gaW5zdGFuY2U8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGluZGVudGlmaWVycyAoc2VjLiA2LjExIGluIFJG
QyA3OTUxKS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKg
wqDCoMKgICZndDsgMi4gdXNlIGEgbW9kdWxlIG5hbWUgcmF0aGVyIHRoYW4gYTxicj4NCiZndDsg
Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJlZml4IGlu
IFhNTCwgdG9vLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0Ozxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
wqDCoMKgwqAgJmd0OyBJIHdvdWxkIHN1Z2dlc3QgIzIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7UlIm
Z3Q7IEJ1dCB0aGF0IG1lYW5zIG1ha2luZyBub24tYmFja3dhcmRzPGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBjb21wYXRpYmxlIGNoYW5n
ZSB0byB0aGUgWE1MPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByZXByZXNlbnRhdGlvbj88YnI+DQomZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE5v
dCByZWFsbHkuIEl0IG1lYW5zIE5FVE1PRCBXRyB3b3VsZCBiZTxicj4NCiZndDsgJmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgY3JlYXRpbmcgaXRzIG93biBzcGVjaWFs
PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqB2YXJpYW50PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8Kg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgWFBhdGguPGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBOb3QgYXQgYWxs
LsKgIFdoYXQgSSBwcm9wb3NlIGlzIHBlcmZlY3RseSBmaW5lLDxicj4NCiZndDsgJmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGVnYWwgWFBhdGggMS4wLjxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgWFBhdGggMS4w
IHNheXMgdGhhdCBhbiBYUGF0aCBleHByZXNzaW9uIGlzPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBldmFsdWF0ZWQgaW4gYSBjb250ZXh0Ljxicj4NCiZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgT25lIGl0
ZW0gaW4gdGhlIGNvbnRleHQgaXMgYSBzZXQgb2YgbWFwcGluZ3MgZnJvbTxicj4NCiZndDsgJmd0
O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O3ByZWZpeCZndDsgdG8gJmx0O3Vy
aSZndDssPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqB3aGVyZSAmbHQ7cHJlZml4Jmd0OyBpcyB1c2VkIHRvIGxvb2t1cCBwcmVmaXhl
cyB1c2VkIGluPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0
aGUgWFBhdGg8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGV4cHJlc3Npb24sIGUuZy4gaW4gJnF1b3Q7L2ZvbzppbnRlcmZhY2VzJnF1
b3Q7ICZxdW90O2ZvbyZxdW90OyBpcyB0aGU8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoHByZWZpeC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEl0IGlzIHBlcmZlY3RseSBmaW5lIHRvIHNheSB0
aGF0IHRoZSBwcmVmaXg8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoG1hcHBpbmcgc2V0IGlzIHRoaXM6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqAgJnF1b3Q7aWV0Zi1pbnRlcmZhY2Vz
JnF1b3Q7IC0mZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAmcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6PHdicj5pZXRmLWludGVyZmFjZXMm
cXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoMKgwqDCoCAmcXVvdDtpZXRmLWlwJnF1b3Q7wqDCoMKgwqDCoMKgwqDCoCAtJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJnF1b3Q7dXJu
OmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOjx3YnI+aWV0Zi1pcCZxdW90Ozxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYW5kIHVzZSB0
aGF0IHRvIGV2YWx1YXRlIHRoZSBleHByZXNzaW9uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgPGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMv
PHdicj5pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlLzx3YnI+aWV0Zi1pcC9pcHY0PGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUaGUgWFBhdGgg
ZXhwcmVzc2lvbiBpcyBub3JtYWxseSBwYXJzZWQgd2l0aGluIGFuIFhNTDxicj4NCiZndDsgJmd0
O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW5zdGFuY2U8YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRvY3VtZW50Ljxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhlcmUgYXJlICZxdW90
O3htbG5zJnF1b3Q7IGF0dHJpYnV0ZXMgcHJlc2VudCB0aGF0IG1hcCB0aGU8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByZWZpeCB0byBhPGJyPg0KJmd0OyAmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuYW1lc3BhY2UgVVJJLjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhlc2Ug
bWFwcGluZ3Mgd2lsbCBub3QgYmUgcHJlc2VudCBpbiB0aGUgSlNPTiBhdCBhbGwuPGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBIGN1c3RvbSBY
UGF0aCBpbXBsZW1lbnRhdGlvbiBpcyByZXF1aXJlZCB0byBtYWdpY2FsbHk8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGlkZW50aWZ5IHRoZTxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcHJlZml4PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBhcyBhIG1vZHVsZSBu
YW1lIGFuZCBtYWdpY2FsbHkgZmluZCB0aGUgbmFtZXNwYWNlIFVSSTxicj4NCiZndDsgJmd0O8Kg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZm9yIHRoZSBtb2R1bGU8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5hbWUuPGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqBJIGRpc2FncmVlLsKgIFlvdSBuZWVk
IGFuIFhQYXRoIGltcGxlbWVudGF0aW9uICsgY3VzdG9tPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqBjb2RlIHRvIHNldCB1cDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8Kg
IMKgIMKgIMKgIMKgIMKgIMKgdGhlIGVudmlyb25tZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0O8KgIMKgIMKgIMKgIMKgVGhpcyBpcyBPSywgYnV0IGNhbiB3ZSBqdXN0IHVzZSB0aGUg
SlNPTiBlbmNvZGluZyBpbnN0YW5jZTxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgaWRlbnRp
Zmllcjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgZm9ybWF0IGV4
YWN0bHk/wqAgSS5lIC5SRkMgNzk1MSBzZWN0aW9uIDYuMTEuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqBTbyAmcXVvdDsvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFj
ZXMvPHdicj5pbnRlcmZhY2UvaWV0Zi1pcDppcHY0Lzx3YnI+ZW5hYmxlZCZxdW90Ozxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgY2FuIHRyaXZpYWxseSBiZSBleHBh
bmRlZCB0bzo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCZxdW90
Oy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy88d2JyPmlldGYtaW50ZXJmYWNlczppbnRlcmZh
Y2UvPHdicj5pZXRmLWlwOmlwdjQvaWV0Zi1pcDplbmFibGVkJnF1b3Q7LDxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgYW5kIHRoZW4gaW50ZXJwcmV0ZWQgd2l0aCB0
aGUgY29udGV4dDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoMKg
wqDCoMKgICZxdW90O2lldGYtaW50ZXJmYWNlcyZxdW90OyAtJmd0Ozxicj4NCiZndDsgJmd0O8Kg
IMKgIMKgIMKgIMKgJnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOjx3YnI+aWV0Zi1p
bnRlcmZhY2VzJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAg
wqDCoMKgICZxdW90O2lldGYtaXAmcXVvdDvCoMKgwqDCoMKgwqDCoMKgIC0mZ3Q7ICZxdW90O3Vy
bjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzo8d2JyPmlldGYtaXAmcXVvdDs8YnI+DQomZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCp0aGlzKiB3b3VsZCByZXF1aXJlIGEgY3VzdG9tIFhQ
YXRoIGltcGxlbWVudGF0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXaHk/wqAg
SS5lLiBob3cgaXMgdGhpcyBkaWZmZXJlbnQgZnJvbSBzdGF0aW5nICZxdW90O0N1c3RvbSBjb2Rl
IGlzIG5lZWRlZDxicj4NCiZndDsgJmd0OyB0byBjb25uZWN0IHRoaW5ncyB0b2dldGhlciZxdW90
Oz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoGFu
ZCBpdCBpcyBub3Qgb2J2aW91cyB3aGF0IHRoZSBydWxlcyBmb3IgdGhlICZxdW90O2F1dG8tYXNz
aWdubWVudCZxdW90OyBvZjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgcHJl
Zml4ZXMgd291bGQgYmUuwqAgRm9yIGV4YW1wbGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7wqAgwqAgwqDCoCAvaWV0Zi1pbnRlcmZhY2VzLy9pZXRmLWlwOjx3YnI+YWRkcmVzc1suLi9m
b29dPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqB3aGF0IGlzIHRoZSBwcmVm
aXggZm9yICZxdW90O2ZvbyZxdW90Oz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT0ss
IHNvIGhlcmUgdGhlIG1vZHVsZSBmb3IgJnF1b3Q7Li4vZm9vJnF1b3Q7IHdvdWxkIG5lZWQgdG8g
YmUgc3BlY2lmaWVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQZXJoYXBzIHRoZSBy
dWxlIHRoYXQgSSYjMzk7bSBsb29raW5nIGZvciBpcyB0aGUgbW9kdWxlIG5hbWUgbWF5IGJlPGJy
Pg0KJmd0OyAmZ3Q7IG9taXR0ZWQgd2hlbiBpdCBtYXRjaGVzIHRoZSBwYXJlbnQgbm9kZSBtb2R1
bGUsIGFuZCBjYW4gZWFzaWx5IGJlPGJyPg0KJmd0OyAmZ3Q7IGluZmVycmVkLsKgIEkuZS4gc28g
dGhhdCBmb3IgYW55IFhQYXRoIHN0cmluZywgaXQgaXMgcG9zc2libGUgdG88YnI+DQomZ3Q7ICZn
dDsgdHJpdmlhbGx5IGV4cGFuZCBpdCB3aXRob3V0IGFueSBhZGRpdGlvbmFsIHNjaGVtYSBjb250
ZXh0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJdCBqdXN0IHNlZW1zIHRvIGJlIHRo
YXQgcmVxdWlyaW5nIHRoZSBsb25nIGhhbmQgb2Y8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7L2lldGYt
aW50ZXJmYWNlczppbnRlcmZhY2VzLzx3YnI+aWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS88d2Jy
PmlldGYtaXA6aXB2NC9pZXRmLWlwOmVuYWJsZWQmcXVvdDs8YnI+DQomZ3Q7ICZndDsgc2VlbXMg
bGlrZSBpdCB3aWxsIGdldCB2ZXJ5IHZlcmJvc2UsIGFuZCBJIHdvbmRlciB3aGV0aGVyIHdlIGFy
ZTxicj4NCiZndDsgJmd0OyBpbnRyb2R1Y2luZyB5ZXQgYW5vdGhlciBYcGF0aCBmb3JtYXQgdG8g
WUFORy48YnI+DQomZ3Q7ICZndDsgJmx0O1JSJmd0OyBJ4oCZbSB3aWxsaW5nIHRvIGxpdmUgd2l0
aCB2ZXJib3NpdHkgaWYgaXQgYXZvaWRzIHRoZSBuZWVkIG9mPGJyPg0KJmd0OyAmZ3Q7IGFub3Ro
ZXIgZm9ybWF0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgUlc6PGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFRoaXMgaXMgYWxyZWFkeSBsb29rcyBsaWtlIGFub3RoZXIgZm9ybWF0Ojxicj4NCjxicj4N
CkFnYWluLCBpdCBpcyAqbm90KiBhbm90aGVyIGZvcm1hdCE8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7
IDxicj4NCiZndDsgWHBhdGggZmlsdGVycyB1c2VkIGluIE5ldGNvbmYgdXNlIGV4cGxpY2l0IG5h
bWVzcGFjZXMsIGUuZy4gcmZjNjI0MTxicj4NCiZndDsgc2VjIDguOS41LjE8YnI+DQomZ3Q7IDxi
cj4NCiZndDvCoCDCoCDCoCDCoCDCoCAmbHQ7ZmlsdGVyIHhtbG5zOnQ9JnF1b3Q7PGEgaHJlZj0i
aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIiByZWw9Im5vcmVmZXJyZXIiIHRh
cmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vPHdicj5zY2hlbWEvMS4yL2NvbmZpZzwv
YT4mcXVvdDs8YnI+DQomZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHlwZT0mcXVvdDt4
cGF0aCZxdW90Ozxicj4NCiZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZWxlY3Q9JnF1
b3Q7L3Q6dG9wL3Q6dXNlcnMvdDp1c2VyWzx3YnI+dDpuYW1lPSYjMzk7ZnJlZCYjMzk7XSZxdW90
Oy8mZ3Q7PGJyPg0KJmd0O8KgIMKgIMKgIMKgIMKgJmx0Oy9nZXQtY29uZmlnJmd0Ozxicj4NCjxi
cj4NCkluIHRoaXMgY2FzZSwgdGhlIHByZWZpeC1zdHJpbmcgLSZndDsgdXJpIG1hcHBpbmcgaXMg
dGFrZW4gZnJvbSB0aGUgWE1MPGJyPg0KbmFtZXNwYWNlIGRlY2xhcmF0aW9uIGluIHRoZSBYTUwg
ZG9jdW1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBUaGUgc3RhbmRhcmQgSlNPTiBlbmNvZGlu
ZyBmb3IgaW5zdGFuY2UtZGF0YSAoSUlSQywgdGhlIHNhbWUgc2NoZW1lIGlzPGJyPg0KJmd0OyB1
c2VkIGZvciBDQk9SKSB1c2VzIHRoZSBtb2R1bGUtbmFtZSBidXQgb21pdHMgaXQgd2hlcmUgaXQg
bWF0Y2hlcyB0aGU8YnI+DQomZ3Q7IHBhcmVudCAoZS5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyAm
cXVvdDsvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvPHdicj5pbnRlcmZhY2UvaWV0Zi1pcDpp
cHY0Lzx3YnI+ZW5hYmxlZCZxdW90Oyk8YnI+DQo8YnI+DQpEbyB5b3UgbWVhbiBpbnN0YW5jZS1p
ZGVudGlmaWVyP8KgIElmIHNvLCBpdCBpcyBhIHNwZWNpYWwgdHlwZSB0aGF0PGJyPg0KaGFwcGVu
cyB0byBzaGFyZSB0aGUgc3ludGF4IHdpdGggWFBhdGgsIGFuZCB0aGUgSlNPTiBzeW50YXggaXMg
ZGVmaW5lZDxicj4NCmluIFJGQyA3OTUxIHNlY3Rpb24gNi4xMS48YnI+DQo8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgUkZDIDgwNDAgcXVlcnkgcGFyYW1ldGVyIGlzIGFzIGRlc2NyaWJlZCBiZWxvdywg
YnV0IGhhdmluZyBsb29rZWQgYXQ8YnI+DQomZ3Q7IHRoZSBleGFtcGxlcyBJJiMzOTttIG5vdCBy
ZWFsbHkgc3VyZSBob3cgdGhhdCBpcyBtZWFudCB0byB3b3JrIDotKTxicj4NCjxicj4NCkluIHRo
aXMgY2FzZSwgdGhlIHByZWZpeC1zdHJpbmcgLSZndDsgdXJpIG1hcHBpbmcgaXMgZ2l2ZW4gaW4g
dGhlPGJyPg0KZG9jdW1lbnQuPGJyPg0KPGJyPg0KPGJyPg0KV2UgdXNlIFhQYXRoIGluIHZhcmlv
dXMgZGlmZmVyZW50IHBsYWNlcywgYW5kIGVhY2ggcGxhY2UgTVVTVCBzcGVjaWZ5PGJyPg0KdGhl
IGV2YWx1YXRpb24gY29udGV4dC48YnI+DQo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91IGFyZSByaWdodC48L2Rpdj48ZGl2Pk91ciBjdXN0b20g
WFBhdGggY29kZSBuZWVkcyB0byBiZSB0b2xkIHRvIGdldCBwcmVmaXggbWFwcGluZ3MgZnJvbSBY
TUwgb3IgWUFORyBpbXBvcnQtc3RtdHM8L2Rpdj48ZGl2PmFscmVhZHksIHNvIDEgbW9yZSBpbnRl
cm5hbCBtYXBwaW5nIGRpcmVjdGx5IHRvIG1vZHVsZSBuYW1lIGlzIG5vdCBnb2luZyB0byByZXF1
aXJlPC9kaXY+PGRpdj5hbnkgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBYUGF0aCBwcm9jZXNzaW5n
LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TW9yZSBpbXBvcnRhbnRseSwgaXQgZG9lcyBub3Qg
cmVxdWlyZSBhbnkgcmVkZWZpbml0aW9uIG9mIHRoZSBYUGF0aCBzdGFuZGFyZC48L2Rpdj48ZGl2
PsKgPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg
MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8
YnI+DQo8YnI+DQovbWFydGluPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkFu
ZHk8L2Rpdj48ZGl2PsKgPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls
ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s
ZWZ0OjFleCI+DQo8YnI+DQo8YnI+DQomZ3Q7ICZndDsgRmluYWxseSwgSSYjMzk7bSB0cnlpbmcg
dG8gZmlndXJlIG91dCBoYXZlIFJGQyA4MDQwIHF1ZXJ5IHBhcmFtZXRlciAoc2VjdDxicj4NCiZn
dDsgJmd0OyA0LjguNCksIHdoaWNoIGFsc28gdXNlcyBYUGF0aCBleHByZXNzaW9ucyBpcyBtZWFu
dCB0byB3b3JrLsKgIFRoYXQ8YnI+DQomZ3Q7ICZndDsgc3RhdGVzOjxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgc2V0IG9mIG5hbWVzcGFjZSBkZWNsYXJh
dGlvbnMgaXMgdGhlIHNldCBvZiBwcmVmaXggYW5kPGJyPg0KJmd0OyAmZ3Q7IMKgwqDCoMKgwqAg
bmFtZXNwYWNlIHBhaXJzIGZvciBhbGwgc3VwcG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhl
IHByZWZpeDxicj4NCiZndDsgJmd0OyDCoMKgwqDCoMKgIGlzIHRoZSBZQU5HIG1vZHVsZSBuYW1l
IGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmluZWQgYnkgdGhlPGJyPg0KJmd0OyAmZ3Q7IMKg
wqDCoMKgwqAgJnF1b3Q7bmFtZXNwYWNlJnF1b3Q7IHN0YXRlbWVudCBpbiB0aGUgWUFORyBtb2R1
bGUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlldCB0aGUg
ZXhhbXBsZXMgaW4gc2VjdGlvbiA4LjMuNiBkb24mIzM5O3Qgc2VlbSB0byB1c2UgbmFtZXNwYWNl
IHByZWZpeGVzPGJyPg0KJmd0OyAmZ3Q7IGluIHZlcnkgbWFueSBwbGFjZXMsIGUuZy4gd2h5IGlz
IGl0ICZxdW90Oy9leGFtcGxlLW1vZDpldmVudDEvbmFtZT0mIzM5Ozx3YnI+am9lJiMzOTsmcXVv
dDs8YnI+DQomZ3Q7ICZndDsgYW5kIG5vdCAmcXVvdDsvZXhhbXBsZS1tb2Q6ZXZlbnQxL2V4YW1w
bGUtPHdicj5tb2Q6bmFtZT0mIzM5O2pvZSYjMzk7JnF1b3Q7P8KgIElzIHRoZSBleGFtcGxlPGJy
Pg0KJmd0OyAmZ3Q7IHdyb25nLCBvciBvdGhlcndpc2Ugd2hhdCBhbSBJIG1pc3Npbmc/IDotKTxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7UlImZ3Q7IFNlY3Rpb24gOC4zLjYgb2Yg
d2hpY2ggZG9jdW1lbnQ/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBSRkMgODA0MC48YnI+DQom
Z3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgUm9iPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgUmVzaGFkLjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0
OyAmZ3Q7IFJvYjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgL21hcnRpbjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0
O8KgIMKgIMKgIMKgIMKgVGhhbmtzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKg
IMKgIMKgIMKgUm9iPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqBUaGVyZSBpcyBubyBzdGFuZGFyZCBYUGF0aCBpbXBsZW1lbnRhdGlvbiB0aGF0IGNhbiBq
dXN0PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqB0YWtlIGFuIFhNTDxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgaW5zdGFuY2UgZG9jdW1l
bnQgKyBZQU5HIG1vZHVsZSBhbmQgZmlndXJlIG91dCB3aGF0IHRvPGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqBkby7CoCBDdXN0b208YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoGNvZGUgaXMgbmVlZGVkIHRvIGNvbm5lY3QgdGhpbmdzIHRv
Z2V0aGVyLsKgIFRoaXMgcHJvcG9zYWw8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oGRvZXNuJiMzOTt0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqBjaGFuZ2UgdGhpcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoC9tYXJ0aW48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoEEgbm9ybWFsIFhQYXRoIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IGZp
bmQgYW55PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuYW1lc3BhY2Ug
bWFwcGluZyBmb3I8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoHRoZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgcHJlZml4ZXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqBBbiBYUGF0aCBleHByZXNzaW9uIGhhcyBubyBjb25jZXB0IG9m
IHRoZSAmcXVvdDtjdXJyZW50PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqBtb2R1bGUmcXVvdDsgaW5oZXJpdGVkPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmcm9tPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgcGFyZW50PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWtlIHRoZSBKU09OIGVuY29kaW5n
LiBUaGlzIGlzIHByb2JsZW1hdGljIGZvciBwcmVkaWNhdGVzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqAgL2lldGYtaW50ZXJmYWNl
czppbnRlcmZhY2VzLzx3YnI+aW50ZXJmYWNlW25hbWU9JiMzOTtldGgwJiMzOTtdPGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBYUGF0aCBzYXlz
IHRoZSBtaXNzaW5nIHByZWZpeGVzIGZvciAmIzM5O2ludGVyZmFjZSYjMzk7IGFuZDxicj4NCiZn
dDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJiMzOTtuYW1lJiMzOTsgYXJlIHNpbXBs
eTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
bWlzc2luZyAobm8gbmFtZXNwYWNlKS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoFRoZSBKU09OIGVuY29kaW5nIHNheXMgJnF1b3Q7aWV0Zi1p
bnRlcmZhY2VzJnF1b3Q7IGlzIHVzZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAmIzM5O2ludGVyZmFjZXMmIzM5Oy4gYW5kPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmIzM5O2ludGVyZmFjZSYjMzk7Ljxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhl
cmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBmb3IgdGhlICYjMzk7bmFtZSYjMzk7IG5vZGUgaW5zaWRl
IGE8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByZWRpY2F0ZS48YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFNvIHlv
dSBtdXN0IG1lYW4gdGhlIGZ1bGwgbW9kdWxlIG5hbWUgd2lsbCBiZSB1c2VkIGF0PGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBldmVyeSBub2RlOjxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy88
d2JyPmlldGYtaW50ZXJmYWNlczppbnRlcmZhY2VbPHdicj5pZXRmLWludGVyZmFjZXM6bmFtZT0m
IzM5O2V0aDAmIzM5O108YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoC9tYXJ0aW48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFuZHk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgIEht
bSwgc28geW91IG1lYW4gY2hhbmdlIHRoZSBsZWFmPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmcXVvdDtzdHJlYW0teHBhdGgtZmlsdGVy
JnF1b3Q7IHRvIHNheTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IG/CoCBUaGUgc2V0IG9mIG5hbWVzcGFjZTxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVjbGFyYXRpb25zIGhhcyBvbmUgbWVtYmVyIGZv
cjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgZWFjaDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgWUFORyBtb2R1bGUgc3VwcG9ydGVkIGJ5PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgc2VydmVyLsKgIFRoaXMgbWVtYmVyIG1h
cHM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGZyb20g
dGhlIFlBTkcgbW9kdWxlIG5hbWU8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRvIHRoZSBZQU5HIG1vZHVsZSBuYW1lc3BhY2UuPGJyPg0K
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqDCoMKgwqDCoMKgwqDCoMKgIMKgwqDCoMKgwqDCoMKgwqBUaGlzIG1lYW5zIHRo
YXQgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBYUGF0aCBleHByZXNzaW9uLCB0aGUgbW9kdWxlPGJyPg0KJmd0OyAmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBuYW1lPGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzZXJ2ZXMgYXMgdGhlIHBy
ZWZpeC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgIC4uLi4gYW5kIHRoZW4gYWxzbyBnaXZlIGFu
IGV4YW1wbGUgb2Y8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoHRoaXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCBUaGlzIGlzIHByb2Jh
Ymx5IHdoYXQgd2UgbmVlZCB0byBkbzxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW4gYWxsIHBsYWNlcyB3aGVyZTxicj4NCiZndDsgJmd0
Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgeWFuZzp4cGF0
aDEuMDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgaXMgdXNlZCwgZ29pbmcgZm9yd2FyZC7CoCBN
YXliZSBldmVuPGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBkZWZpbmUgYSBuZXcgdHlwZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0
O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgeWFu
Zzp4cGF0aDEuMC0yIChuYW1lPykgd2l0aCB0aGUgc2V0PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvZiBuYW1lc3BhY2UgZGVjbGFyYXRp
b25zPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCBidWlsdC1pbi48YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFdlIHNob3Vs
ZCBhdm9pZCBtYWtpbmcgb2ZmLXRoZS1zaGVsZjxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW1wbGVtZW50YXRpb25zIG9mIHN0YW5kYXJkcyBsaWtl
PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBYUGF0aCB1bnVzYWJsZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEF0IHRoZSB2ZXJ5IGxlYXN0IHRo
aXMgc2hvdWxkIGJlIG9ubHk8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGF2YWlsYWJsZSBpZiB0aGUgc2VydmVyIHN1cHBvcnRzPGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBp
dDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgKHdpdGggYSBjYXBhYmlsaXR5IFVSSSk8YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDtS
UiZndDsgU28gd2UgbmVlZCBhbiB1cGRhdGUgdG8gUkZDNzk1MT88YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFJl
Z2FyZHMsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBSZXNoYWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBBbmR5PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqDCoMKgwqDCoCAvbWFydGluPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7IExhZGE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZn
dDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4N
CiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDC
oMKgwqAgJmd0OyAmZ3Q7IEhvdyBpcyB0aGlzIHN1cHBvc2VkIHRvIHdvcmsgd2l0aDxicj4NCiZn
dDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSlNPTj88
YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqDCoMKg
wqAgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDsgL21hcnRpbjxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDC
oCAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0OyBuZXRtb2QgbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Im1haWx0
bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9
Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEA8d2JyPmlldGYub3JnPC9hPiZndDs8YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoMKgwqDCoMKgICZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9uZXRtb2Q8
L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDC
oCAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoMKgwqDCoCAmZ3Q7IExhZGlzbGF2IExob3RrYTxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgwqDCoMKgwqAgJmd0OyBIZWFkLCBDWi5OSUMgTGFiczxicj4NCiZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgwqDCoMKgwqAgJmd0OyBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjc8YnI+DQom
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoMKgwqDCoMKgICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgwqDCoMKgPGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqDCoMKgwqDCoCBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8YSBocmVm
PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8
YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAPHdicj5pZXRmLm9yZzwvYT4m
Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxh
IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mbHQ7bWFp
bHRvOjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEA8d2JyPmlldGYub3Jn
PC9hPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vbmV0bW9kPC9hPjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0ibWFp
bHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJl
Zj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQDx3YnI+aWV0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHJlbD0ibm9yZWZl
cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5s
aXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAuLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O8KgIMKgIMKgLjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGJyPg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4N
Cm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn
Ij5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9uZXRtb2Q8L2E+PGJy
Pg0KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj4NCg==
--000000000000d9f63c0577f66a9c--


From nobody Thu Oct 11 09:45:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFC6130EBC for ; Thu, 11 Oct 2018 09:45:38 -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, DKIMWL_WL_MED=-0.001, 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 bZh5dJb1-aoo for ; Thu, 11 Oct 2018 09:45:35 -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 68AE3130EBB for ; Thu, 11 Oct 2018 09:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7557; q=dns/txt; s=iport; t=1539276335; x=1540485935; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oXlAbGeX8dcCnYDdxCN5yQ0uHYeW+2GDbGs+fjgEdPg=; b=gu3JEAuv1wGQoEnor2ScONEUglgc54f2Kw/RcysdNypELwkUfek36O4t hCk23zRwo5i6yjG9s6QtGuDfKmTBGTRrxSZnP+OYPmFEyMjTNSFxsTrs8 hphVuDgIb5AU71rToWJ4lykFoKy7LKIx+sd6v/KtfFSNuLc6TGvZy0ePj k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAAOfb9b/xbLJq1YChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWWDVxIog3WIdY03CCWYeg2EbAKEdjgWAQMBAQIBAQJtKIU?= =?us-ascii?q?5AQEBAQIBIwQLAQVBEAsOCgICJgICVwYKAwYCAQGDHIF6CKYsezOEd4RlgQu?= =?us-ascii?q?KUYFBP4E5DIJfhFODLIJXAo4zjwpTCZBOBheBT4RrgmuGbI9ehjSBWSGBVTM?= =?us-ascii?q?aCBsVgyeQVj4wjDUBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,369,1534809600";  d="scan'208";a="7166649"
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; 11 Oct 2018 16:45:32 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9BGjWdj025197; Thu, 11 Oct 2018 16:45:32 GMT
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod@ietf.org
References: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
Date: Thu, 11 Oct 2018 17:45:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181011.181150.1840683183107627057.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 16:45:39 -0000

On 11/10/2018 17:11, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>>
>> On 11/10/2018 11:50, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
>>>> On 11/10/2018 11:21, Martin Bjorklund wrote:
>>>>> Andy Bierman  wrote:
>>>>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
>>>>>> wrote:
>>>>>>
>>>>>>> Andy Bierman  wrote:
>>>>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
>>>>>>> rrahman@cisco.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>>>>>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
>>>>>>>>>
>>>>>>>>>        Ladislav Lhotka  wrote:
>>>>>>>>>        > Martin Bjorklund  writes:
>>>>>>>>>        >
>>>>>>>>>        > > Hi,
>>>>>>>>>        > >
>>>>>>>>>        > > While reviewing restconf-notif, I saw this example:
>>>>>>>>>        > >
>>>>>>>>>        > >    {
>>>>>>>>>        > >       "ietf-subscribed-notifications:input": {
>>>>>>>>>        > >          "stream": "NETCONF",
>>>>>>>>>        > >          "stream-xpath-filter": "/ds:foo/",
>>>>>>>>>        > >          "dscp": "10"
>>>>>>>>>        > >       }
>>>>>>>>>        > >    }
>>>>>>>>>        > >
>>>>>>>>>        > > Note the "stream-xpath-filter".  It has a prefix in the XPath
>>>>>>>>> string.
>>>>>>>>>        > > How are prefixes declared when JSON is used?
>>>>>>>>>        > >
>>>>>>>>>        > > The leaf "stream-xpath-filter" says:
>>>>>>>>>        > >
>>>>>>>>>        > >               o The set of namespace declarations are those
>>>>>>>>>        > >               in
>>>>>>>>> scope on
>>>>>>>>>        > >                  the 'stream-xpath-filter' leaf element.
>>>>>>>>>        > >
>>>>>>>>>        > > (I think I provided that text...)
>>>>>>>>>        > >
>>>>>>>>>        > > This assumes that the encoding is XML, or at leas that the
>>>>>>> encoding
>>>>>>>>>        > > can somehow transfer namespace declarations.
>>>>>>>>>        >
>>>>>>>>>        > It can't. There are two options:
>>>>>>>>>        >
>>>>>>>>>        > 1. have different representations of this value in XML and
>>>>>>>>>        > JSON,
>>>>>>>>>        >    analogically to instance indentifiers (sec. 6.11 in RFC
>>>>>>>>>        >    7951).
>>>>>>>>>        >
>>>>>>>>>        > 2. use a module name rather than a prefix in XML, too.
>>>>>>>>>        >
>>>>>>>>>        > I would suggest #2.
>>>>>>>>>  But that means making non-backwards compatible change to the XML
>>>>>>>>> representation?
>>>>>>>>>
>>>>>>>> Not really. It means NETMOD WG would be creating its own special
>>>>>>>> variant
>>>>>>> of
>>>>>>>> XPath.
>>>>>>> Not at all.  What I propose is perfectly fine, legal XPath 1.0.
>>>>>>>
>>>>>>> XPath 1.0 says that an XPath expression is evaluated in a context.
>>>>>>> One item in the context is a set of mappings from  to ,
>>>>>>> where  is used to lookup prefixes used in the XPath
>>>>>>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
>>>>>>>
>>>>>>> It is perfectly fine to say that the prefix mapping set is this:
>>>>>>>
>>>>>>>       "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>>>>       "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
>>>>>>>
>>>>>>> and use that to evaluate the expression
>>>>>>>
>>>>>>>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> The XPath expression is normally parsed within an XML instance
>>>>>> document.
>>>>>> There are "xmlns" attributes present that map the prefix to a
>>>>>> namespace URI.
>>>>>> These mappings will not be present in the JSON at all.
>>>>>>
>>>>>> A custom XPath implementation is required to magically identify the
>>>>>> prefix
>>>>>> as a module name and magically find the namespace URI for the module
>>>>>> name.
>>>>> I disagree.  You need an XPath implementation + custom code to set up
>>>>> the environment.
>>>> This is OK, but can we just use the JSON encoding instance identifier
>>>> format exactly?  I.e .RFC 7951 section 6.11.
>>>>
>>>> So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
>>>>
>>>> can trivially be expanded to:
>>>>
>>>> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",
>>>>
>>>> and then interpreted with the context:
>>>>        "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>      "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
>>> *this* would require a custom XPath implementation.
>> Why?  I.e. how is this different from stating "Custom code is needed
>> to connect things together"?
> B/c the specification of XPath allows you to (actually, *requires* you
> to) construct the set of prefix strings to url mappings.
>
> This is "custom code to connect things".
>
> But changing the syntax means changin the specification.
Not really.

It would just mean that the filter value is not an "Xpath" expression.  
It is a more a concise string that can be expanded into an Xpath expression.

>
>>> and it is not obvious what the rules for the "auto-assignment" of
>>> prefixes would be.  For example:
>>>
>>>     /ietf-interfaces//ietf-ip:address[../foo]
>>>
>>> what is the prefix for "foo"?
>> OK, so here the module for "../foo" would need to be specified.
>>
>> Perhaps the rule that I'm looking for is the module name may be
>> omitted when it matches the parent node module, and can easily be
>> inferred.  I.e. so that for any XPath string, it is possible to
>> trivially expand it without any additional schema context.
>>
>> It just seems to be that requiring the long hand of
>> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled"
>> seems like it will get very verbose, and I wonder whether we are
>> introducing yet another Xpath format to YANG.
> I agree that it is very verbose.  But do not mix XPath expressions in
> leaf values (which is what this thread is about) with
> instance-identfiers.
OK, but ultimately:
- these are both leaf values.
- they both identify nodes in a YANG datastore.
- the fact that their format is somewhat subtlety different will catch 
people out.


>
>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
>> 4.8.4), which also uses XPath expressions is meant to work. That
>> states:
>>
>> The set of namespace declarations is the set of prefix and
>>        namespace pairs for all supported YANG modules, where the prefix
>>        is the YANG module name and the namespace is as defined by the
>>        "namespace" statement in the YANG module.
> Perfect!  It seems the authors of 8040 thought of this ;-)
OK, what you propose would at least be consistent with how the XPath is 
formed in sec 8040, 4.8.4?

I can live with that.  But still strongly think that WG should think of 
trying to move YANG on from Xpath 1.0.

>
>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
>> in very many places, e.g. why is it "/example-mod:event1/name='joe'"
>> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
>> wrong, or otherwise what am I missing? :-)
> It seems the example is wrong!
Please can you check section 8040, 8.3.6.  Are all the examples wrong?

Thanks,
Rob

>
>
> /martin
> .
>


From nobody Thu Oct 11 09:53:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A327F130EC6 for ; Thu, 11 Oct 2018 09:52:55 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 ovwwXt2ukP0p for ; Thu, 11 Oct 2018 09:52:53 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 442FA130EC5 for ; Thu, 11 Oct 2018 09:52:53 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id u21-v6so8852516lja.8 for ; Thu, 11 Oct 2018 09:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0m0YJuae2wnd98hPxRgs3JF2IjeQ+OCG1Im/6NecqIE=; b=KTflXcPeoGIvneu3hT2n2+UJq74zdfwYmiZnpE+OIw3w+8tm/hd96/wevi3i032S9l Xg2sti2DbyxyvV/EFVoBjgkD8ETVh5r9836nX542wVvmzmA6iyveougTgiS0eVXoRduN XLztzStDlGslBySoCTyaiWRZbe1+nEQ94blRrlDBr0lPW198Hm57WDMM/kNKVWbg31gY agkujkff00P5cHBZOiU99gsYXrjsX5H9VKPefhdf1YQkHPI2BKt+rh9KyYLUv9GWF4sF h0myBne5sA8rhSKU9tQoljp8ybgu9OCaCnWNEfubO9f6XGhFxQ9UVBlcTxHL2xIPy298 qt6w==
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=0m0YJuae2wnd98hPxRgs3JF2IjeQ+OCG1Im/6NecqIE=; b=TxENiBPl4CIOdZCXu1K+Cx2scK0o0OmjlYoeJDyt6R8C0iwcoJ1zFS/h0pLmcviXfl hb9pEz0rhkkdJmPUiLcNwFNF6H5GhsRBfRqRj4Nlcmus1YLdcA0M17ypNS+l7akUI6A5 mUTHS0+/D20Uc1IvtsB72LwQ5aq05uz5CAXN6Qh8N31eEghVJ8D0EAaeBqoqZT76oTfm 3kJSuhU6JhVd4NvO+g7Xnj2haUfG0JarKpv7sQhPGFsl8SXoGqICJL8YRP1xSgxZBCex TkbIi0trLe1XY8Cup0JBwMmvNkN6zPc80e8IARyfuOtf/BFkwPJPu3AfqmrXGe0zHzyJ GHsg==
X-Gm-Message-State: ABuFfojmP+ez64rX96/i6yYu8U87+FuXvYZdHwvwT9aV0JRq1WDTT5uL 1KZkrnOsNQ7lRRpweub286kRiP7QKSYTsCx0KBeFk/ht
X-Google-Smtp-Source: ACcGV63LNuPzWrE+MPoClLrbBkj9DzOkcoHCVn5vCI6eqo4Z2QegY+JkaF1u97CXxhwih202rf3tNjIOiv4cz2AI72I=
X-Received: by 2002:a2e:1456:: with SMTP id 22-v6mr1747432lju.116.1539276771166;  Thu, 11 Oct 2018 09:52:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 11 Oct 2018 09:52:49 -0700 (PDT)
In-Reply-To: <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
References: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
From: Andy Bierman 
Date: Thu, 11 Oct 2018 09:52:49 -0700
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000002838e70577f6cd3a"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 16:52:56 -0000

--0000000000002838e70577f6cd3a
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  wrote:

>
> ....
>
>>
>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
>>> 4.8.4), which also uses XPath expressions is meant to work. That
>>> states:
>>>
>>> The set of namespace declarations is the set of prefix and
>>>        namespace pairs for all supported YANG modules, where the prefix
>>>        is the YANG module name and the namespace is as defined by the
>>>        "namespace" statement in the YANG module.
>>>
>> Perfect!  It seems the authors of 8040 thought of this ;-)
>>
> OK, what you propose would at least be consistent with how the XPath is
> formed in sec 8040, 4.8.4?
>
> I can live with that.  But still strongly think that WG should think of
> trying to move YANG on from Xpath 1.0.
>


I do not agree YANG should change any statements where XPath is being used.
(Note that leafs like the filter are free to use whatever data type they
want, including yang:xpath1.0).

The WG is on the right track already wrt/ XPath by creating custom XPath
functions
like 'deref' that simplify syntax or extend functionality.



>
>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
>>> in very many places, e.g. why is it "/example-mod:event1/name='joe'"
>>> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
>>> wrong, or otherwise what am I missing? :-)
>>>
>> It seems the example is wrong!
>>
> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>
> Thanks,
> Rob
>
>
>>
>> /martin
>> .
>>
>>
>

Andy

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




On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

....







Finally, I'm trying to figure out have RFC 8040 query parameter (sect
4.8.4), which also uses XPath expressions is meant to work. That

states:



The set of namespace declarations is the set of prefix and

=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace pairs for all supported YANG modules, =
where the prefix

=C2=A0 =C2=A0 =C2=A0 =C2=A0is the YANG module name and the namespace is as =
defined by the

=C2=A0 =C2=A0 =C2=A0 =C2=A0"namespace" statement in the YANG modu=
le.



Perfect!=C2=A0 It seems the authors of 8040 thought of this ;-)



OK, what you propose would at least be consistent with how the XPath is for=
med in sec 8040, 4.8.4?



I can live with that.=C2=A0 But still strongly think that WG should think o=
f trying to move YANG on from Xpath 1.0.


I do not agree YANG should change any statements where XPa=
th is being used.
(Note that leafs like the filter are free to us=
e whatever data type they want, including yang:xpath1.0).

The WG is on the right track already wrt/ XPath by creating custom =
XPath functions
like 'deref' that simplify syntax or exte=
nd functionality.=C2=A0











Yet the examples in section 8.3.6 don't seem to use namespace prefixes<=
br>
in very many places, e.g. why is it "/example-mod:event1/name=3D'j=
oe'"

and not "/example-mod:event1/example-mod:name=3D'joe'&quo=
t;?=C2=A0 Is the example

wrong, or otherwise what am I missing? :-)



It seems the example is wrong!



Please can you check section 8040, 8.3.6.=C2=A0 Are all the examples wrong?=




Thanks,

Rob









/martin

.










Andy



--0000000000002838e70577f6cd3a--


From nobody Thu Oct 11 11:00:32 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5F130EC8 for ; Thu, 11 Oct 2018 11:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level: 
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 BzjR6-Kh-zoj for ; Thu, 11 Oct 2018 11:00:26 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9723130EB9 for ; Thu, 11 Oct 2018 11:00:23 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE4.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 11 Oct 2018 21:00:20 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE4.corp.amdocs.com (10.237.241.95) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 11 Oct 2018 21:00:19 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Thu, 11 Oct 2018 21:00:19 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Thu, 11 Oct 2018 21:00:19 +0300
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Thu, 11 Oct 2018 21:00:18 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P69mfv6TvbXARLo9/2cEPV7LUoCJIYRRX0tHwsuEXbw=; b=JDk4R02N+4PZjNTIl1nujm8YO3sydsrIYZCnaZjRdApZ/sn2rdh3Cd1CQ70p99oo1CvoH3S3xnht5ZWDaDr8eyQn68RBoCVn8alnzCBMxhmYUjWL8qKOaSHQ1abmiL4NHDzmPoFVhuBadWIVbaLoBqslNmnOiOdzri9LYkFYhBE=
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com (10.168.22.154) by DB6PR06MB4085.eurprd06.prod.outlook.com (10.168.22.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.23; Thu, 11 Oct 2018 18:00:16 +0000
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707]) by DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707%3]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 18:00:16 +0000
From: Michael Rehder 
To: Andy Bierman 
CC: Juergen Schoenwaelder , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5A=
Date: Thu, 11 Oct 2018 18:00:16 +0000
Message-ID: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR06MB4085; 6:EaOVDOl/xer+WB+f2ntTjCI6CFYPhMHgkUrvhrOFELLbYdZg9gF6ZPoxPmTbBlIViBhnXhTHTG5B5FnJZEhSsTRsCo38qNUlBO+K+JO7WiaUUamnR54BwS+4fG9/ISFeut70wwgbML1skXSlYOdBYjdMX9agwMvdrKyqtYgPTfRGDjAnmt03QHGcYLYCQ1QA/ofZVmErAw6sG3Fn4eTIC3XjS3h3dtyBx4bd+zEo42mrQB486tzZGBJWfNIfV8W13vXrUf4YXzIsBRi6Zuqrv5mxJWQgKP0ax7qKQQFjvt8lkSfFjdT2545QAxEfw6ihbSDQWRsNhOv6lwLs4Iwwn+ze9Sj1yGJye4GUfWb8neYIqqwcOyCB755N8p0etuAM12h5z0gskleDv80VMuPEoC6jBQ7yGl3Pz+E93oNaNMqhCofjtIzV1GumrvtUHx8mCWjMJaKsXT6xno1vRXUnEw==; 5:glvr6ySPYEwjIA8RTR7S+77v9Z031ASHjzW4h/3daR92JyaJiSRzja1vSaEy+RrPvRar97t9xHt8xlpII/IGJsA/32zYNvXguK0ZpLkApx1mOAZ2t8MfLCkJz8GqroOnDgMEzC+vxDIKlR78lPwq01keKyaQGQbW4EztlDf3HxE=; 7:W4Cx+IwVG1pQTp35NCB4haIrl45Wq7cuFOViyHTOmZhUH1JFqF15ty1VyyU8VsTmSfHaz1eRXS2Wu4T83HghxBT3eG8wZBlRKeVye6fBDhI902FTninVl4ZNR9pp+p7u0PCqz75euzW3yQC8avP9arBQzyNrJhoO9GIh3VsrMN/c/40SH/IXz/MIT5lcdUPoY0Jl/mhRbOxi1H9G93Sma2I/84UUjevr5gpLFTBx3oqfPVKQKUWN0uc4VzzZrQpA
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8d0a157c-37ea-453d-bc01-08d62fa366ad
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR06MB4085; 
x-ms-traffictypediagnostic: DB6PR06MB4085:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(131327999870524)(166566539817055)(62221491112393)(95692535739014)(17755550239193)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991057); SRVR:DB6PR06MB4085; BCL:0; PCL:0; RULEID:; SRVR:DB6PR06MB4085; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(346002)(376002)(189003)(51444003)(199004)(13464003)(106356001)(2906002)(2900100001)(74316002)(606006)(114624004)(6436002)(25786009)(105586002)(54896002)(486006)(6306002)(4326008)(6916009)(236005)(19609705001)(33656002)(9686003)(55016002)(229853002)(66066001)(5660300001)(53936002)(14444005)(256004)(102836004)(53546011)(6116002)(3846002)(790700001)(7736002)(99286004)(97736004)(86362001)(93886005)(6246003)(5250100002)(54906003)(6506007)(476003)(186003)(26005)(71190400001)(71200400001)(81156014)(4744004)(8936002)(11346002)(14454004)(966005)(72206003)(446003)(316002)(76176011)(8676002)(7696005)(81166006)(478600001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR06MB4085; H:DB6PR06MB4085.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aRlWTXSbbke14aMA1c/ZlQ8hZi8gMOY5rCTy9N/uflKTXFb9WnVbhv/6szxTCaWrtjoA/fbaKsCXAS1UH5mDjXPm5gTHJgpWkjjNF+sT3XGSbJnDhsg4viWe3KzetUjzu/IGvkTx+Q9D1wEW4Ur2PHzvzyJTIrU/8CYRn2MXVl6etxSWrfXEZoVsOcTYyYeJXP6v4Xg56eLC/30XpN00hyFtN5WrDnWHzIatM16Lvfa9hW/MRixyFKqPVsdnBbrFDtqOMdvEBLMZtThF6Trbq28M2B0Cy8gGcKgYg41UQpjbVaL+MhXv45Zg+Wb3lZUrK8OpXRSCbHPvdLz1Z6cz6/fCCGLZqCjtgeFGqm+BbzU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR06MB4085D91F66023AC98122FEDFE7E10DB6PR06MB4085eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d0a157c-37ea-453d-bc01-08d62fa366ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 18:00:16.7559 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR06MB4085
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:00:30 -0000

--_000_DB6PR06MB4085D91F66023AC98122FEDFE7E10DB6PR06MB4085eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SSB0aGluayB0aGUgd29yZGluZyBpcyByZWxldmFudCAtIHNvbWV0aGluZyBjYW4gYmUgY29uZGl0
aW9uYWwgYnV0IHN0aWxsIHJlcXVpcmVkLg0KSXQgc2hvdWxkIGJlIGNsYXJpZmllZCB0aGF0IGVs
ZW1lbnRzIGJlY29tZSBpbXBsaWNpdGx5IOKAnG1hbmRhdG9yeSBmYWxzZeKAnSB3aGVuIGEg4oCc
d2hlbuKAnSBzdGF0ZW1lbnQgaXMgdXNlZC4NCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBlbmhh
bmNlbWVudCB0byBZQU5HIHRvIGNvbnRyb2wgdGhpcyBiZWhhdmlvciwgdG8gYWxsb3cgdGhlIG1h
bmRhdG9yeSBzdGF0dXMgdG8gYmUgZW5mb3JjZWQuDQpUaGF0IGlzLCBzdXBwb3J0IGFsc28g4oCc
Y29uZGl0aW9uYWxseSByZXF1aXJlZOKAnSBpbnN0ZWFkIG9mIG9ubHkgdGhlIGN1cnJlbnQg4oCc
Y29uZGl0aW9uYWxseSBvcHRpb25hbOKAnS4NCg0KVGhhbmtzDQpNaWtlDQoNCkZyb206IEFuZHkg
Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0
b2JlciAxMCwgMjAxOCAyOjUyIFBNDQpUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVy
QEFtZG9jcy5jb20+DQpDYzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJA
amFjb2JzLXVuaXZlcnNpdHkuZGU+OyBXYWxrZXIsIEphc29uIChKYXNvbl9XYWxrZXIyQGNvbWNh
c3QuY29tKSA8SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0
cyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdA0KDQoNCg0K
T24gV2VkLCBPY3QgMTAsIDIwMTggYXQgMTE6NDQgQU0sIE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVs
LlJlaGRlckBhbWRvY3MuY29tPG1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPj4gd3Jv
dGU6DQpTdXJlLg0KDQpJIHRoaW5rIHRoZSBSRkMgaXMgdW5jbGVhciBzaW5jZSBpdCBzZWVtcyB0
aGF0IHRoZSBzZW1hbnRpY3MgYXJlIGNvbnNpc3RlbnQgaW4gdGhlIGJhY2stZW5kIGNoZWNrcy4N
Ck9uZSBjYW4gcmVhZCB0aGUgUkZDIGFuZCBub3Qgbm90aWNlIGJ5IGl0cyBhYnNlbmNlIHRoYXQg
dGhlIHdoZW4gY2xhdXNlIGRvZXNuJ3QgcmVxdWlyZSBhbnl0aGluZyB0byBiZSBwcmVzZW50Lg0K
DQogICAgIFRoZSAid2hlbiIgc3RhdGVtZW50IG1ha2VzIGl0cyBwYXJlbnQgZGF0YSBkZWZpbml0
aW9uIHN0YXRlbWVudCBjb25kaXRpb25hbC4NClNob3VsZCBiZQ0KICAgIFRoZSAid2hlbiIgc3Rh
dGVtZW50IG1ha2VzIGl0cyBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVudCBjb25kaXRp
b25hbCBhbmQgb3B0aW9uYWwuDQoNClRoaXMgaXMgbm90IGNvcnJlY3QuDQoNClN0ZXAgMSkgaWYt
ZmVhdHVyZSBtYWtlcyB0aGUgc2NoZW1hIG5vZGUgY29uZGl0aW9uYWwNCg0KU3RlcCAyKSB3aGVu
LXN0bXQgbWFrZXMgaW5zdGFuY2VzIG9mIHRoZSBzY2hlbWEtbm9kZSBjb25kaXRpb25hbA0KDQpT
dGVwIDMpIFlBTkcgdmFsaWRhdGlvbiBhcHBsaWVzIHRvIGluc3RhbmNlcyBvZiBkYXRhIG5vZGVz
IChvciB0aGUgWUFORyBkZWZhdWx0IHZhbHVlIGlmIGFwcGxpY2FibGUpDQoNClN0ZXAgMiBpcyBv
bmx5IHJlbGV2YW50IGlmIFN0ZXAgMSBpcyB0cnVlIG9yIG5vbi1leGlzdGVudA0KU3RlcCAzIGlz
IG9ubHkgcmVsZXZhbnQgaWYgU3RlcCAyIGlzIHRydWUgb3Igbm9uLWV4aXN0ZW50DQoNCkFuZHkN
Cg0KDQpJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIG1vcmUgZGVmaW5pdGUgc3RhdGVtZW50IGFi
b3V0IHRoaXMgb3ZlcnJpZGluZyBhbnkgbWFuZGF0b3J5IHN0YXR1cyBvZiB0aGUgcGFyZW50IGRh
dGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQuDQpMaWtlDQogICAgICJBbnkgbWFuZGF0b3J5IHN0YXR1
cyBvZiB0aGUgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQgKG1hbmRhdG9yeSBzdGF0
ZW1lbnQsIG1pbi1lbGVtZW50IHN0YXRlbWVudCBldGMuKSBpcyBvdmVycmlkZGVuIGJ5IHRoaXMg
c3RhdGVtZW50IGFuZCBtYWRlIG5vbi1tYW5kYXRvcnkuIg0KDQpUaGF0IHdvdWxkIGhhdmUgbWFk
ZSB0aGUgc2lkZS1lZmZlY3Qgb2YgIndoZW4iIG9uIG90aGVyIGRlY2xhcmF0aW9ucyBjbGVhcmVy
Lg0KDQpUaGFua3MNCm1pa2UNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
SnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+XQ0K
PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMjoyNSBQTQ0KPiBUbzogTWljaGFl
bCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVy
QEFtZG9jcy5jb20+Pg0KPiBDYzogUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb208bWFp
bHRvOnJ3aWx0b25AY2lzY28uY29tPj47IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxt
YWlsdG86bGhvdGthQG5pYy5jej4+Ow0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp
ZXRmLm9yZz47IFdhbGtlciwgSmFzb24gKEphc29uX1dhbGtlcjJAY29tY2FzdC5jb208bWFpbHRv
Okphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+KQ0KPiA8SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNv
bTxtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbT4+DQo+IFN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndA0KPiBl
bnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3QNCj4NCj4gTWljaGFlbCwNCj4N
Cj4gd2hhdCBtYXR0ZXJzIGhlcmUgaXMgd2hhdCB0aGUgWUFORyBzcGVjaWZpY2F0aW9uIChSRkMg
Nzk1MCkgc2F5cy4gSXMgdGhlcmUgYQ0KPiByZWFzb24gdG8gYmVsaWV2ZSB0aGUgSVBBZGRyZXNz
ZXMgbGlzdCBpbiB5b3VyIGV4YW1wbGUgY2FuIGJlIGFic2VudCBvciBoYXZlIG5vDQo+IGVsZW1l
bnRzIGJhc2VkIG9uIHdoYXQgUkZDIDc5NTAgc2F5cz8gT3IgZG8gd2UgdGFsayBhYm91dCBhIHNo
b3J0Y29taW5nIG9mDQo+IFJGQyA2MTEwPw0KPg0KPiAvanMNCj4NCj4gT24gV2VkLCBPY3QgMTAs
IDIwMTggYXQgMDY6MTc6MjZQTSArMDAwMCwgTWljaGFlbCBSZWhkZXIgd3JvdGU6DQo+ID4gSWYg
dGhlIGxpc3QgaGFzIGEgIndoZW4iIGNsYXVzZSB0aGUgUk5HIGZpbGUgYWN0dWFsbHkgcHJvZHVj
ZXMgYSAiT25lT3JNb3JlIg0KPiB3aGljaCBoYXMgYSBjaG9pY2Ugb2YgPGVtcHR5PiBvciB0aGUg
bGlzdCBzbyBpdCBhY3R1YWxseSBkb2Vzbid0IGVuZm9yY2UgdGhlDQo+IHByZXNlbmNlIGF0IGxl
YXN0IG9uZSByb3cgb2YgdGhlIGxpc3QgKHVubGVzcyBJJ20gbWlzdGFrZW4gaW4gbXkgcmVhZGlu
ZykuDQo+ID4gICAgICAgICAgICAgICA8b25lT3JNb3JlPg0KPiA+ICAgICAgICAgICAgICAgICA8
Y2hvaWNlPg0KPiA+ICAgICAgICAgICAgICAgICAgIDxlbXB0eS8+DQo+ID4gICAgICAgICAgICAg
ICAgICAgPGVsZW1lbnQgbmFtZT0iSVBBZGRyZXNzZXMiPg0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgPGVsZW1lbnQgbmFtZT0iQWRkcmVzcyI+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgIDxy
ZWYgbmFtZT0idHlwZXNfX0lQdjRBZGRyZXNzIi8+DQo+ID4gICAgICAgICAgICAgICAgICAgICA8
L2VsZW1lbnQ+DQo+ID4gICAgICAgICAgICAgICAgICAgICA8ZW1wdHkvPg0KPiA+ICAgICAgICAg
ICAgICAgICAgIDwvZWxlbWVudD4NCj4gPiAgICAgICAgICAgICAgICAgPC9jaG9pY2U+DQo+ID4g
ICAgICAgICAgICAgICA8L29uZU9yTW9yZT4NCj4gPg0KPiA+IEEgbGVhZi9jb250YWluZXIgd291
bGQgYmUgYSBzaW1wbGVyIGV4YW1wbGUgYnV0IHdvdWxkIHJlc3VsdCBpbiB0aGUgc2FtZQ0KPiBs
YWNrIG9mIGVuZm9yY2VtZW50IG9mIHRoZSBtYW5kYXRvcnkgc3RhdHVzIG9mIGFuIGVsZW1lbnQg
d2l0aCBhICJ3aGVuIg0KPiBjbGF1c2UuDQo+ID4NCj4gPiBUaGlzIFJORyBzZWVtcyBjb25zaXN0
ZW50IHdpdGggdGhlIFNjaGVtYXRyb24gcnVsZXMgdGhhdCAid2hlbiIgbWFrZXMNCj4gc29tZXRo
aW5nIG9wdGlvbmFsLg0KPiA+DQo+ID4NCj4gPiBJIHRoaW5rIGEgd29ya2Fyb3VuZCB3b3VsZCBi
ZSBjaG9pY2Ugd2l0aCBtYW5kYXRvcnkgdHJ1ZSBhbmQgYSB3aGVuIGNsYXVzZQ0KPiBvbiB0aGUg
Y2FzZXMuIFRoaXMgd291bGQgZW5zdXJlIHRoYXQgYXQgbGVhc3Qgb25lIGNhc2UgaXMgcHJlc2Vu
dCBzaW5jZSB0aGUNCj4gbWFuZGF0b3J5IGNsYXVzZSBpbXBsZW1lbnRzIGEgU2NoZW1hdHJvbiBl
eGlzdGVuY2UgY29uc3RyYWludC4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+IE1pa2UNCj4gPiA+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBSb2JlcnQgV2lsdG9uIFttYWls
dG86cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPl0NCj4gPiA+IFNl
bnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMCwgMjAxOCAxMTozMyBBTQ0KPiA+ID4gVG86IE1pY2hh
ZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPG1haWx0bzpNaWNoYWVsLlJlaGRl
ckBBbWRvY3MuY29tPj47IExhZGlzbGF2IExob3RrYQ0KPiA+ID4gPGxob3RrYUBuaWMuY3o8bWFp
bHRvOmxob3RrYUBuaWMuY3o+PjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v
cmc+DQo+ID4gPiBDYzogV2Fsa2VyLCBKYXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTxt
YWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbT4pDQo+ID4gPiA8SmFzb25fV2Fsa2VyMkBj
b21jYXN0LmNvbTxtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbT4+DQo+ID4gPiBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3Rz
DQo+ID4gPiBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdA0K
PiA+ID4NCj4gPiA+IEhpIE1pa2UsDQo+ID4gPg0KPiA+ID4gSSB0aGluayB0aGF0IHRoZSBZQU5H
IGJlbG93IGFscmVhZHkgZW5mb3JjZXMgd2hhdCB5b3Ugd2FudCwgb3INCj4gPiA+IG90aGVyd2lz
ZSBJIGRvbid0IGZvbGxvdyB5b3VyIGlzc3VlLg0KPiA+ID4NCj4gPiA+IFRoZSBZQU5HIGJlbG93
IGlzIHZhbGlkIGluIHR3byBjYXNlczoNCj4gPiA+DQo+ID4gPiAoMSkgQXNzaWdubWVudE1lY2hh
bmlzbSA9IERIQ1AsIGFuZCBJUEFkZHJlc3NlcyBpcyBub3QgcHJlc2VudCBpbg0KPiA+ID4gdGhl
IGNvbmZpZyAoZHVlIHRvIHRoZSB3aGVuIHN0YXRlbWVudCkuDQo+ID4gPiAoMikgQXNzaWdubWVu
dE1lY2hhbmlzbSA9IFN0YXRpYywgSVBBZGRyZXNzZXMgZXhpc3RzIGFuZCBoYXMgYXQNCj4gPiA+
IGxlYXN0IG9uZSBlbGVtZW50IChkdWUgdG8gbWluLWVsZW1lbnRzIDEpLg0KPiA+ID4NCj4gPiA+
IFRoYW5rcywNCj4gPiA+IFJvYg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAxMC8xMC8yMDE4IDE2
OjIzLCBNaWNoYWVsIFJlaGRlciB3cm90ZToNCj4gPiA+ID4gQ29udGFpbmVyICJmb28iIHdvdWxk
IGJlIG1hbmRhdG9yeSBpZiBub3QgZm9yIHRoZSAid2hlbiIgY2hpbGQgZWxlbWVudC4NCj4gPiA+
ID4gV2l0aCB0aGUgIndoZW4iIGNoaWxkIGVsZW1lbnQsIHRoZSBsb2dpYyBiZWNvbWVzICJpbnZl
cnRlZCIgYW5kDQo+ID4gPiA+IHRoZQ0KPiA+ID4gY29uc3RyYWludCBpcyBhIG5lZ2F0aXZlIG9u
ZSBvZiAiZGlzYWxsb3dlZCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbiIuDQo+ID4gPiA+DQo+ID4g
PiA+IFRoZSBVQyBpcyBmb3IgZW5mb3JjZW1lbnQgaW4gUkVTVCBBUEkgcGF5bG9hZHMuDQo+ID4g
PiA+IEZvciBhIHByYWN0aWNhbCBleGFtcGxlOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAg
bGVhZiBBc3NpZ25tZW50TWVjaGFuaXNtIHsNCj4gPiA+ID4gICAgICAgICAgICAgIHR5cGUgZW51
bWVyYXRpb24gew0KPiA+ID4gPiAgICAgICAgICAgICAgICBlbnVtICJESENQIjsNCj4gPiA+ID4g
ICAgICAgICAgICAgICAgZW51bSAiU3RhdGljIjsNCj4gPiA+ID4gICAgICAgICAgICAgIH0NCj4g
PiA+ID4gICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiA+ID4gPiAgICAgICAgICAgICAg
ZGVzY3JpcHRpb24gIlRoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtLiI7DQo+ID4gPiA+
ICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAgICAgICAgIGxpc3QgSVBBZGRyZXNzZXMgew0KPiA+
ID4gPiAgICAgICAgICAgICAgd2hlbiAiLi4vQXNzaWdubWVudE1lY2hhbmlzbSA9ICdTdGF0aWMn
IjsNCj4gPiA+ID4gICAgICAgICAgICAgIGtleSBBZGRyZXNzOw0KPiA+ID4gPiAgICAgICAgICAg
ICAgbWluLWVsZW1lbnRzIDE7DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAgICBsZWFmIEFk
ZHJlc3Mgew0KPiA+ID4gPiAgICAgICAgICAgICAgICB0eXBlIGNhcGl0OklQdjRBZGRyZXNzOw0K
PiA+ID4gPiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiQW4gaXB2NCBhZGRyZXNzLiI7DQo+
ID4gPiA+ICAgICAgICAgICAgICB9DQo+ID4gPiA+ICAgICAgICAgICAgIH0NCj4gPiA+ID4NCj4g
PiA+ID4gVGhlcmUgaXMgbm8gd2F5IGluIHRoZSBJUEFkZHJlc3NlcyBsaXN0IHRvIGVuZm9yY2Ug
dGhhdCB0aGVyZSBpcw0KPiA+ID4gPiBhdCBsZWFzdCBvbmUgSVANCj4gPiA+IEFkZHJlc3Mgd2hl
biB0aGUgYXNzaWdubWVudCBtZXRob2QgaXMgIlN0YXRpYyIuDQo+ID4gPiA+IE9uZSBjb3VsZCBw
dXQgYSAibXVzdCIgb24gIkFzc2lnbm1lbnRNZWNoYW5pc20iIHRvIGVuc3VyZSBhdCBsZWFzdA0K
PiA+ID4gPiBvbmUNCj4gPiA+IGVsZW1lbnQgb2YgdGhlIElQQWRkcmVzc2VzIGxpc3Qgd2hlbiAi
U3RhdGljIiwgYnV0IEkgZG9uJ3Qgc2VlIHRoaXMNCj4gPiA+IGFzIGEgZ29vZCBzY2hlbWEgZGVz
aWduLCB0byBoYXZlIHRoZSBjb250cm9sbGluZyBhdHRyaWJ1dGUgY2hlY2sgY29udHJvbGxlZA0K
PiBhdHRyaWJ1dGVzLg0KPiA+ID4gPg0KPiA+ID4gPiBJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIHNl
bWFudGljIGNhbid0IGJlIGNoYW5nZWQgaW4gWUFORyBhdCB0aGlzIHBvaW50Lg0KPiA+ID4gPiBD
b3VsZCB0aGUgIndoZW4iIHN0YXRlbWVudCBoYXZlIGEgbW9kaWZ5aW5nIGNoaWxkIGVsZW1lbnQg
dG8gc3RhdGUNCj4gPiA+ID4gdGhhdCB0aGUNCj4gPiA+IG1hbmRhdG9yeSBzdGF0dXMgb2YgdGhl
IGVsZW1lbnQgaXMgdG8gYmUgZW5mb3JjZWQ/DQo+ID4gPiA+IExpa2UNCj4gPiA+ID4gICAgICBj
b250YWluZXIgZm9vIHsNCj4gPiA+ID4gICAgICAgIHdoZW4gImNvbmRpdGlvbiIgew0KPiA+ID4g
PiAgICAgICAgICAgIGVuZm9yY2UtbWFuZGF0b3J5LXN0YXR1czsNCj4gPiA+ID4gICAgICAgIH0N
Cj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgaXMgYWxyZWFkeSBiYWNrLWVuZCBmb3IgZXhpc3RlbnRp
YWwgY2hlY2tzIGZvciBtYW5kYXRvcnkNCj4gPiA+ID4gY2hvaWNlIHNvIHRoaXMNCj4gPiA+IHNl
ZW1zIHJlYXNvbmFibHkgY29uc2lzdGVudCB0byBtZS4NCj4gPiA+ID4gSSBhcHByZWNpYXRlIHRo
ZXJlIGFyZSBleGlzdGluZyBpc3N1ZXMgZm9yICJ3aGVuIiBidXQgSSBkb24ndCBzZWUNCj4gPiA+
ID4gd2h5IHRoaXMNCj4gPiA+IHdvdWxkIG1ha2UgdGhpbmdzIGFueSB3b3JzZS4NCj4gPiA+ID4g
SW4gZmFjdCBieSBwcm9tb3RpbmcgYSBiZXR0ZXIgZGVwZW5kZW5jeSAiZGlyZWN0aW9uIiBiZXR3
ZWVuDQo+ID4gPiA+IHNjaGVtYQ0KPiA+ID4gZWxlbWVudHMsICB0aGluayBpdCBjb3VsZCBzaW1w
bGlmeSB0aGluZ3MgKHNvIEkgbmFpdmVseSB0aGluayA6KSApLg0KPiA+ID4gPg0KPiA+ID4gPiBU
aGFua3MNCj4gPiA+ID4gTWlrZQ0KPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiA+ID4+IEZyb206IExhZGlzbGF2IExob3RrYSBbbWFpbHRvOmxob3RrYUBuaWMuY3o8bWFp
bHRvOmxob3RrYUBuaWMuY3o+XQ0KPiA+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEw
LCAyMDE4IDEwOjI4IEFNDQo+ID4gPiA+PiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVo
ZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+PjsgbmV0bW9k
QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gPiA+PiBTdWJqZWN0OiBSZTog
W25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzDQo+ID4gPiA+
PiBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdA0KPiA+ID4g
Pj4NCj4gPiA+ID4+IE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPG1h
aWx0bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPj4gd3JpdGVzOg0KPiA+ID4gPj4NCj4gPiA+
ID4+PiBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCDigJx3aGVu4oCdIGFuZCBtYW5kYXRvcnkgb2Jq
ZWN0cy4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGltcGxl
bWVudGVkIHNlbWFudGljcyBvZiDigJx3aGVu4oCdIGFyZQ0KPiA+ID4gPj4+IHJlYWxseQ0KPiA+
ID4gPj4g4oCcb3B0aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5jbG9zaW5nIG9iamVjdCBj
YW4gYmUgYWJzZW50IGV2ZW4NCj4gPiA+ID4+IHRob3VnaCBpdCBpcyBtYW5kYXRvcnkgYW5kIHRo
ZSDigJx3aGVu4oCdIGNsYXVzZSBob2xkcyB0cnVlLg0KPiA+ID4gPj4+IFRoZSBSRkMgY291bGQg
YmUgY2xlYXJlciBhYm91dCB0aGlzLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gRXhhbXBsZQ0KPiA+
ID4gPj4+DQo+ID4gPiA+Pj4gICAgIGxlYWYgY29sb3Igew0KPiA+ID4gPj4+ICAgICAgIGVudW1l
cmF0aW9uICB7DQo+ID4gPiA+Pj4gICAgICAgICAgZW51bSDigJxibHVl4oCdOw0KPiA+ID4gPj4+
ICAgICAgICAgIGVudW0g4oCcYmxhY2vigJ07DQo+ID4gPiA+Pj4gICAgICAgfQ0KPiA+ID4gPj4+
ICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiA+ID4gPj4+ICAgICB9DQo+ID4gPiA+Pj4gICAgIGNv
bnRhaW5lciBmb28gew0KPiA+ID4gPj4+ICAgICAgICB3aGVuIC4uL2NvbG9yID0g4oCYYmx1ZeKA
mTsNCj4gPiA+ID4+PiAgICAgICAgZXRjLg0KPiA+ID4gPj4+ICAgICB9DQo+ID4gPiA+Pj4NCj4g
PiA+ID4+PiDigJxmb2/igJ0gaXMgb3B0aW9uYWwgZHVlIHRvIHRoZSBwcmVzZW5jZSBvZiB0aGUg
4oCcd2hlbuKAnSBzdGF0ZW1lbnQNCj4gPiA+ID4+PiBldmVuIHRob3VnaCB0aGUgb2JqZWN0IGlz
IG1hbmRhdG9yeSAoc2FtZSBpcyB0cnVlIGZvciBtYW5kYXRvcnkNCj4gPiA+ID4+PiBsZWFmLA0K
PiA+ID4gPj4+IG1pbi1lbGVtZW50cz0xIGxpc3QgZXRjLikuDQo+ID4gPiA+PiBNYXliZSB5b3Ug
aW50ZW5kZWQgdG8gaGF2ZSwgZS5nLiwgYSAibWFuZGF0b3J5IHRydWUiIGxlYWYgaW5zaWRlDQo+
ID4gPiA+PiAiY29udGFpbmVyIGZvbyI/DQo+ID4gPiA+Pg0KPiA+ID4gPj4+IFRoaXMgaXMgY29u
c2lkZXJlZCB2YWxpZCBYTUwgZm9yIHRoZSBhYm92ZQ0KPiA+ID4gPj4+ICAgICAgPGNvbG9yPmJs
dWU8L2NvbG9yPg0KPiA+ID4gPj4gWWVzLCBpdCBpcywgdW5kZXIgY3VycmVudCBZQU5HIHJ1bGVz
LCBubyBtYXR0ZXIgd2hhdCAiZXRjLiINCj4gPiA+ID4+IHN0YW5kcyBmb3IuIE5vdGUgdGhhdCBl
dmFsdWF0aW9uIG9mIHRoZSBYUGF0aCBleHByZXNzaW9uIGluIHRoaXMNCj4gPiA+ID4+IGNhc2Ug
KHdpdGggImZvbyIgbWlzc2luZykgcmVxdWlyZXMgdGhlIHBlY3VsaWFyIHByb2NlZHVyZSBvZiBz
ZWMuIDcuMjEuNQ0KPiBpbiBSRkMgNzk1MC4NCj4gPiA+ID4+DQo+ID4gPiA+Pj4gSW4gbXkgdmll
dyB0aGlzIG1ha2VzIGNvbmRpdGlvbmFsbHkgdmFyaWFudCBzY2hlbWFzIOKAnGxvb3Nl4oCdIGlu
DQo+ID4gPiA+Pj4gdGhlaXIgZW5mb3JjZW1lbnQgKHNvbWUgc2NlbmFyaW9zIGNhbiB1c2UgY2hv
aWNlIGJ1dCBpdCBkb2VzbuKAmXQNCj4gPiA+ID4+PiBjb3ZlciBldmVyeXRoaW5nKS4NCj4gPiA+
ID4+Pg0KPiA+ID4gPj4+IEkgdGhpbmsgdGhhdCBtYW5kYXRvcnkgc2hvdWxkIGJlIHJlc3BlY3Rl
ZCBmb3IgdGhlIGVuY2xvc2luZw0KPiA+ID4gPj4+IG9iamVjdHMgb2YgYSDigJx3aGVu4oCdIHN0
YXRlbWVudC4gIFRoYXQgaXMsIGEgbWFuZGF0b3J5IG9iamVjdCBtdXN0DQo+ID4gPiA+Pj4gYmUg
cHJlc2VudCB3aGVuIGl0cyDigJx3aGVu4oCdIGNsYXVzZSBob2xkcyB0cnVlIGFuZCBhIFNjaGVt
YXRyb24NCj4gPiA+ID4+PiBzdGF0ZW1lbnQgc2hvdWxkIGVuZm9yY2UgdGhhdC4NCj4gPiA+ID4+
IEluIGZhY3QsIHRoaXMgaXMgb25lIGNhc2Ugd2hlcmUgdGhlIERTREwgbWFwcGluZyAoUkZDIDYx
MTApDQo+ID4gPiA+PiBkZXZpYXRlcyBmcm9tIFlBTkcgMS4wLiBOb2RlcyB0aGF0IG1hbmRhdG9y
eSBhcmVuJ3QgZW5jbG9zZWQgaW4NCj4gPiA+ID4+IHRoZSBSRUxBWCBORyA8b3B0aW9uYWw+IHBh
dHRlcm4sIGFuZCBhcmUgdGhlbiByZXF1aXJlZCBubyBtYXR0ZXIgd2hhdA0KPiBhbnkgIndoZW4i
DQo+ID4gPiA+PiBzdGF0ZW1lbnRzIHNheSAoYmVjYXVzZSBSRUxBWCBORyB2YWxpZGF0aW9uIGNv
bWVzIGJlZm9yZQ0KPiBTY2hlbWF0cm9uKS4NCj4gPiA+ID4+DQo+ID4gPiA+Pj4gV2hhdCBpcyB0
aGUgcmF0aW9uYWxlIGJlaGluZCB0aGUgY3VycmVudCBZQU5HIHJ1bGVzIGJlaGF2aW9yLA0KPiA+
ID4gPj4+IHRoYXQgdGhlIOKAnHdoZW7igJ0gU2NoZW1hdHJvbiBtYXBwaW5nIGRvZXNu4oCZdCBj
aGVjayBmb3IgcHJlc2VuY2Ugb2YNCj4gPiA+ID4+PiB0aGUgZW5jbG9zaW5nIG1hbmRhdG9yeSBv
YmplY3Q/DQo+ID4gPiA+PiBGV0lXLCBJIGhhdmUgYmVlbiByZXBlYXRlZGx5IHByb3Rlc3Rpbmcg
YWdhaW5zdCB0aGlzIGJlaGF2aW91cg0KPiA+ID4gPj4gYnV0IHdpdGhvdXQgbXVjaCBsdWNrLiBT
ZWUgZm9yIGV4YW1wbGUNCj4gPiA+ID4+DQo+ID4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE0MDEyLmh0bQ0KPiA+ID4gPj4gbA0K
PiA+ID4gPj4NCj4gPiA+ID4+IEFzIGEgcmVzdWx0LCAid2hlbiIgaXMgdGhlIHRyaWNraWVzdCBm
ZWF0dXJlIGluIFlBTkcgYnkgZmFyLg0KPiA+ID4gPj4NCj4gPiA+ID4+IExhZGENCj4gPiA+ID4+
DQo+ID4gPiA+Pj4gdGhhbmtzDQo+ID4gPiA+Pj4gTWlrZSBSZWhkZXINCj4gPiA+ID4+IC0tDQo+
ID4gPiA+PiBMYWRpc2xhdiBMaG90a2ENCj4gPiA+ID4+IEhlYWQsIENaLk5JQyBMYWJzDQo+ID4g
PiA+PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+ID4g4oCcQW1kb2Nz4oCZ
IGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwNCj4g
PiA+ID4gY2xvdWQtYmFzZWQNCj4gPiA+IHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9j
cyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nDQo+ID4gPiBzdWNoIHN5c3RlbSBh
bmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2gNCj4gPiA+
IHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1k
b2NzDQo+ID4gPiBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0
ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywNCj4gc3RvcmluZyBhbmQgYWNjZXNz4oCdLg0KPiA+ID4g
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZA0KPiA+DQo+ID4g4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2Vk
IG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQNCj4gc3lzdGVtLiBBbnkg
ZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcg
c3VjaA0KPiBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVy
cyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQNCj4gYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBl
bWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZg0KPiBz
dWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQo+
ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBu
ZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0
Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN
Cj4NCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVy
c2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1w
dXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAg
MzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQrigJxBbWRv
Y3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRl
LCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBw
cm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUg
YnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNp
cy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2Vu
dCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3Jpbmcg
YW5kIGFjY2Vzc+KAnS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
DQoNCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5
LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9j
cyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUg
YWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBs
aW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMg
eW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2lu
Zywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLgo=

--_000_DB6PR06MB4085D91F66023AC98122FEDFE7E10DB6PR06MB4085eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGlu
ayB0aGUgd29yZGluZyBpcyByZWxldmFudCAtIHNvbWV0aGluZyBjYW4gYmUgY29uZGl0aW9uYWwg
YnV0IHN0aWxsIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBzaG91bGQgYmUgY2xhcmlm
aWVkIHRoYXQgZWxlbWVudHMgYmVjb21lIGltcGxpY2l0bHkg4oCcbWFuZGF0b3J5IGZhbHNl4oCd
IHdoZW4gYSDigJx3aGVu4oCdIHN0YXRlbWVudCBpcyB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBlbmhhbmNlbWVu
dCB0byBZQU5HIHRvIGNvbnRyb2wgdGhpcyBiZWhhdmlvciwgdG8gYWxsb3cgdGhlIG1hbmRhdG9y
eSBzdGF0dXMgdG8gYmUgZW5mb3JjZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYXQgaXMsIHN1cHBv
cnQgYWxzbyDigJxjb25kaXRpb25hbGx5IHJlcXVpcmVk4oCdIGluc3RlYWQgb2Ygb25seSB0aGUg
Y3VycmVudCDigJxjb25kaXRpb25hbGx5IG9wdGlvbmFs4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pa2U8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDI6NTIgUE08YnI+DQo8Yj5U
bzo8L2I+IE1pY2hhZWwgUmVoZGVyICZsdDtNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tJmd0Ozxi
cj4NCjxiPkNjOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJA
amFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7OyBXYWxrZXIsIEphc29uIChKYXNvbl9XYWxrZXIyQGNv
bWNhc3QuY29tKSAmbHQ7SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSZndDs7IG5ldG1vZEBpZXRm
Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0
aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5k
YXRvcnkgb2JqZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IFdlZCwgT2N0IDEwLCAyMDE4IGF0IDExOjQ0IEFNLCBNaWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOk1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo
YWVsLlJlaGRlckBhbWRvY3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U3VyZS48YnI+DQo8YnI+DQpJ
IHRoaW5rIHRoZSBSRkMgaXMgdW5jbGVhciBzaW5jZSBpdCBzZWVtcyB0aGF0IHRoZSBzZW1hbnRp
Y3MgYXJlIGNvbnNpc3RlbnQgaW4gdGhlIGJhY2stZW5kIGNoZWNrcy48YnI+DQpPbmUgY2FuIHJl
YWQgdGhlIFJGQyBhbmQgbm90IG5vdGljZSBieSBpdHMgYWJzZW5jZSB0aGF0IHRoZSB3aGVuIGNs
YXVzZSBkb2Vzbid0IHJlcXVpcmUgYW55dGhpbmcgdG8gYmUgcHJlc2VudC48YnI+DQo8YnI+DQom
bmJzcDsgJm5ic3A7ICZuYnNwO1RoZSAmcXVvdDt3aGVuJnF1b3Q7IHN0YXRlbWVudCBtYWtlcyBp
dHMgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQgY29uZGl0aW9uYWwuPGJyPg0KU2hv
dWxkIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgJnF1b3Q7d2hlbiZxdW90OyBzdGF0ZW1lbnQg
bWFrZXMgaXRzIHBhcmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGNvbmRpdGlvbmFsIGFu
ZCBvcHRpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgbm90IGNvcnJlY3QuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0ZXAgMSkgaWYtZmVhdHVyZSBtYWtl
cyB0aGUgc2NoZW1hIG5vZGUgY29uZGl0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RlcCAyKSB3aGVuLXN0bXQgbWFrZXMgaW5zdGFu
Y2VzIG9mIHRoZSBzY2hlbWEtbm9kZSBjb25kaXRpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGVwIDMpIFlBTkcgdmFsaWRhdGlvbiBh
cHBsaWVzIHRvIGluc3RhbmNlcyBvZiBkYXRhIG5vZGVzIChvciB0aGUgWUFORyBkZWZhdWx0IHZh
bHVlIGlmIGFwcGxpY2FibGUpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlN0ZXAgMiBpcyBvbmx5IHJlbGV2YW50IGlmIFN0ZXAgMSBpcyB0cnVl
IG9yIG5vbi1leGlzdGVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+U3RlcCAzIGlzIG9ubHkgcmVsZXZhbnQgaWYgU3RlcCAyIGlzIHRydWUgb3Ig
bm9uLWV4aXN0ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBtb3JlIGRlZmluaXRlIHN0YXRlbWVudCBhYm91dCB0
aGlzIG92ZXJyaWRpbmcgYW55IG1hbmRhdG9yeSBzdGF0dXMgb2YgdGhlIHBhcmVudCBkYXRhIGRl
ZmluaXRpb24gc3RhdGVtZW50Ljxicj4NCkxpa2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZx
dW90O0FueSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0
YXRlbWVudCAobWFuZGF0b3J5IHN0YXRlbWVudCwgbWluLWVsZW1lbnQgc3RhdGVtZW50IGV0Yy4p
IGlzIG92ZXJyaWRkZW4gYnkgdGhpcyBzdGF0ZW1lbnQgYW5kIG1hZGUgbm9uLW1hbmRhdG9yeS4m
cXVvdDs8YnI+DQo8YnI+DQpUaGF0IHdvdWxkIGhhdmUgbWFkZSB0aGUgc2lkZS1lZmZlY3Qgb2Yg
JnF1b3Q7d2hlbiZxdW90OyBvbiBvdGhlciBkZWNsYXJhdGlvbnMgY2xlYXJlci48YnI+DQo8YnI+
DQpUaGFua3M8YnI+DQptaWtlPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi
cj4NCiZndDsgRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86PGEgaHJlZj0ibWFp
bHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSI+ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgT2N0
b2JlciAxMCwgMjAxOCAyOjI1IFBNPGJyPg0KJmd0OyBUbzogTWljaGFlbCBSZWhkZXIgJmx0Ozxh
IGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tIj5NaWNoYWVsLlJlaGRlckBB
bWRvY3MuY29tPC9hPiZndDs8YnI+DQomZ3Q7IENjOiBSb2JlcnQgV2lsdG9uICZsdDs8YSBocmVm
PSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs7IExh
ZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiPmxob3RrYUBu
aWMuY3o8L2E+Jmd0Ozs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci
Pm5ldG1vZEBpZXRmLm9yZzwvYT47IFdhbGtlciwgSmFzb24gKDxhIGhyZWY9Im1haWx0bzpKYXNv
bl9XYWxrZXIyQGNvbWNhc3QuY29tIj5KYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPC9hPik8YnI+
DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSI+SmFz
b25fV2Fsa2VyMkBjb21jYXN0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW25l
dG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3Q8YnI+
DQomZ3Q7IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDxicj4NCiZndDsg
PGJyPg0KJmd0OyBNaWNoYWVsLDxicj4NCiZndDsgPGJyPg0KJmd0OyB3aGF0IG1hdHRlcnMgaGVy
ZSBpcyB3aGF0IHRoZSBZQU5HIHNwZWNpZmljYXRpb24gKFJGQyA3OTUwKSBzYXlzLiBJcyB0aGVy
ZSBhPGJyPg0KJmd0OyByZWFzb24gdG8gYmVsaWV2ZSB0aGUgSVBBZGRyZXNzZXMgbGlzdCBpbiB5
b3VyIGV4YW1wbGUgY2FuIGJlIGFic2VudCBvciBoYXZlIG5vPGJyPg0KJmd0OyBlbGVtZW50cyBi
YXNlZCBvbiB3aGF0IFJGQyA3OTUwIHNheXM/IE9yIGRvIHdlIHRhbGsgYWJvdXQgYSBzaG9ydGNv
bWluZyBvZjxicj4NCiZndDsgUkZDIDYxMTA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9qczxicj4N
CiZndDsgPGJyPg0KJmd0OyBPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCAwNjoxNzoyNlBNICYjNDM7
MDAwMCwgTWljaGFlbCBSZWhkZXIgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IElmIHRoZSBsaXN0IGhh
cyBhICZxdW90O3doZW4mcXVvdDsgY2xhdXNlIHRoZSBSTkcgZmlsZSBhY3R1YWxseSBwcm9kdWNl
cyBhICZxdW90O09uZU9yTW9yZSZxdW90Ozxicj4NCiZndDsgd2hpY2ggaGFzIGEgY2hvaWNlIG9m
ICZsdDtlbXB0eSZndDsgb3IgdGhlIGxpc3Qgc28gaXQgYWN0dWFsbHkgZG9lc24ndCBlbmZvcmNl
IHRoZTxicj4NCiZndDsgcHJlc2VuY2UgYXQgbGVhc3Qgb25lIHJvdyBvZiB0aGUgbGlzdCAodW5s
ZXNzIEknbSBtaXN0YWtlbiBpbiBteSByZWFkaW5nKS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O29uZU9yTW9y
ZSZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtjaG9pY2UmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7Jmx0O2VtcHR5LyZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZWxl
bWVudCBuYW1lPSZxdW90O0lQQWRkcmVzc2VzJnF1b3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsmbHQ7ZWxlbWVudCBuYW1lPSZxdW90O0FkZHJlc3MmcXVvdDsmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7cmVmIG5hbWU9JnF1b3Q7
dHlwZXNfX0lQdjRBZGRyZXNzJnF1b3Q7LyZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7Jmx0Oy9lbGVtZW50Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm
bHQ7ZW1wdHkvJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZWxlbWVudCZndDs8
YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvY2hvaWNlJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L29uZU9y
TW9yZSZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQSBsZWFmL2NvbnRhaW5lciB3
b3VsZCBiZSBhIHNpbXBsZXIgZXhhbXBsZSBidXQgd291bGQgcmVzdWx0IGluIHRoZSBzYW1lPGJy
Pg0KJmd0OyBsYWNrIG9mIGVuZm9yY2VtZW50IG9mIHRoZSBtYW5kYXRvcnkgc3RhdHVzIG9mIGFu
IGVsZW1lbnQgd2l0aCBhICZxdW90O3doZW4mcXVvdDs8YnI+DQomZ3Q7IGNsYXVzZS48YnI+DQom
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhpcyBSTkcgc2VlbXMgY29uc2lzdGVudCB3aXRoIHRo
ZSBTY2hlbWF0cm9uIHJ1bGVzIHRoYXQgJnF1b3Q7d2hlbiZxdW90OyBtYWtlczxicj4NCiZndDsg
c29tZXRoaW5nIG9wdGlvbmFsLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyBJIHRoaW5rIGEgd29ya2Fyb3VuZCB3b3VsZCBiZSBjaG9pY2Ugd2l0aCBtYW5kYXRv
cnkgdHJ1ZSBhbmQgYSB3aGVuIGNsYXVzZTxicj4NCiZndDsgb24gdGhlIGNhc2VzLiBUaGlzIHdv
dWxkIGVuc3VyZSB0aGF0IGF0IGxlYXN0IG9uZSBjYXNlIGlzIHByZXNlbnQgc2luY2UgdGhlPGJy
Pg0KJmd0OyBtYW5kYXRvcnkgY2xhdXNlIGltcGxlbWVudHMgYSBTY2hlbWF0cm9uIGV4aXN0ZW5j
ZSBjb25zdHJhaW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3M8YnI+DQom
Z3Q7ICZndDsgTWlrZTxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOjxhIGhy
ZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+XTxicj4N
CiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMCwgMjAxOCAxMTozMyBB
TTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBNaWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJlZj0ibWFp
bHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20iPk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208
L2E+Jmd0OzsgTGFkaXNsYXYgTGhvdGthPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9
Im1haWx0bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDs7IDxhIGhyZWY9Im1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmciPg0KbmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0
OyAmZ3Q7IENjOiBXYWxrZXIsIEphc29uICg8YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBj
b21jYXN0LmNvbSI+SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTwvYT4pPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tIj5KYXNv
bl9XYWxrZXIyQGNvbWNhc3QuY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBTdWJqZWN0
OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9y
eSBvYmplY3Q8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEhpIE1pa2Us
PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoYXQgdGhl
IFlBTkcgYmVsb3cgYWxyZWFkeSBlbmZvcmNlcyB3aGF0IHlvdSB3YW50LCBvcjxicj4NCiZndDsg
Jmd0OyAmZ3Q7IG90aGVyd2lzZSBJIGRvbid0IGZvbGxvdyB5b3VyIGlzc3VlLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIFlBTkcgYmVsb3cgaXMgdmFsaWQgaW4g
dHdvIGNhc2VzOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKDEpIEFz
c2lnbm1lbnRNZWNoYW5pc20gPSBESENQLCBhbmQgSVBBZGRyZXNzZXMgaXMgbm90IHByZXNlbnQg
aW48YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgY29uZmlnIChkdWUgdG8gdGhlIHdoZW4gc3RhdGVt
ZW50KS48YnI+DQomZ3Q7ICZndDsgJmd0OyAoMikgQXNzaWdubWVudE1lY2hhbmlzbSA9IFN0YXRp
YywgSVBBZGRyZXNzZXMgZXhpc3RzIGFuZCBoYXMgYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBsZWFz
dCBvbmUgZWxlbWVudCAoZHVlIHRvIG1pbi1lbGVtZW50cyAxKS48YnI+DQomZ3Q7ICZndDsgJmd0
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBSb2I8YnI+
DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
T24gMTAvMTAvMjAxOCAxNjoyMywgTWljaGFlbCBSZWhkZXIgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyBDb250YWluZXIgJnF1b3Q7Zm9vJnF1b3Q7IHdvdWxkIGJlIG1hbmRhdG9yeSBp
ZiBub3QgZm9yIHRoZSAmcXVvdDt3aGVuJnF1b3Q7IGNoaWxkIGVsZW1lbnQuPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyBXaXRoIHRoZSAmcXVvdDt3aGVuJnF1b3Q7IGNoaWxkIGVsZW1lbnQsIHRo
ZSBsb2dpYyBiZWNvbWVzICZxdW90O2ludmVydGVkJnF1b3Q7IGFuZDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uc3RyYWludCBpcyBhIG5lZ2F0aXZl
IG9uZSBvZiAmcXVvdDtkaXNhbGxvd2VkIHVuZGVyIGNlcnRhaW4gY29uZGl0aW9uJnF1b3Q7Ljxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBVQyBp
cyBmb3IgZW5mb3JjZW1lbnQgaW4gUkVTVCBBUEkgcGF5bG9hZHMuPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBGb3IgYSBwcmFjdGljYWwgZXhhbXBsZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7bGVhZiBBc3NpZ25tZW50TWVjaGFuaXNtIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUg
ZW51bWVyYXRpb24gezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gJnF1b3Q7REhDUCZxdW90
Ozs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtICZxdW90O1N0YXRpYyZxdW90Ozs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgZGVzY3JpcHRpb24gJnF1b3Q7VGhlIGFkZHJlc3MgYXNzaWdubWVudCBtZWNoYW5pc20uJnF1
b3Q7Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxpc3QgSVBBZGRyZXNzZXMgezxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgd2hlbiAmcXVvdDsuLi9Bc3NpZ25tZW50TWVjaGFuaXNtID0gJ1N0YXRpYycmcXVvdDs7PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBrZXkgQWRkcmVzczs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1pbi1lbGVtZW50cyAx
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYgQWRkcmVzcyB7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBjYXBpdDpJUHY0QWRkcmVzczs8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtBbiBpcHY0IGFkZHJlc3MuJnF1b3Q7Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMgbm8gd2F5IGluIHRoZSBJUEFkZHJl
c3NlcyBsaXN0IHRvIGVuZm9yY2UgdGhhdCB0aGVyZSBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgYXQgbGVhc3Qgb25lIElQPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQWRkcmVzcyB3aGVuIHRoZSBh
c3NpZ25tZW50IG1ldGhvZCBpcyAmcXVvdDtTdGF0aWMmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBPbmUgY291bGQgcHV0IGEgJnF1b3Q7bXVzdCZxdW90OyBvbiAmcXVvdDtBc3NpZ25t
ZW50TWVjaGFuaXNtJnF1b3Q7IHRvIGVuc3VyZSBhdCBsZWFzdDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgb25lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWxlbWVudCBvZiB0aGUgSVBBZGRyZXNzZXMg
bGlzdCB3aGVuICZxdW90O1N0YXRpYyZxdW90OywgYnV0IEkgZG9uJ3Qgc2VlIHRoaXM8YnI+DQom
Z3Q7ICZndDsgJmd0OyBhcyBhIGdvb2Qgc2NoZW1hIGRlc2lnbiwgdG8gaGF2ZSB0aGUgY29udHJv
bGxpbmcgYXR0cmlidXRlIGNoZWNrIGNvbnRyb2xsZWQ8YnI+DQomZ3Q7IGF0dHJpYnV0ZXMuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBhcHByZWNp
YXRlIHRoYXQgdGhpcyBzZW1hbnRpYyBjYW4ndCBiZSBjaGFuZ2VkIGluIFlBTkcgYXQgdGhpcyBw
b2ludC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENvdWxkIHRoZSAmcXVvdDt3aGVuJnF1b3Q7
IHN0YXRlbWVudCBoYXZlIGEgbW9kaWZ5aW5nIGNoaWxkIGVsZW1lbnQgdG8gc3RhdGU8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbWFuZGF0b3J5
IHN0YXR1cyBvZiB0aGUgZWxlbWVudCBpcyB0byBiZSBlbmZvcmNlZD88YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IExpa2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgY29udGFpbmVyIGZvbyB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyB3aGVuICZxdW90O2NvbmRpdGlvbiZxdW90OyB7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuZm9y
Y2UtbWFuZGF0b3J5LXN0YXR1czs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyBUaGVyZSBpcyBhbHJlYWR5IGJhY2stZW5kIGZvciBleGlzdGVudGlhbCBjaGVj
a3MgZm9yIG1hbmRhdG9yeTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY2hvaWNlIHNvIHRoaXM8
YnI+DQomZ3Q7ICZndDsgJmd0OyBzZWVtcyByZWFzb25hYmx5IGNvbnNpc3RlbnQgdG8gbWUuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGFwcHJlY2lhdGUgdGhlcmUgYXJlIGV4aXN0aW5nIGlz
c3VlcyBmb3IgJnF1b3Q7d2hlbiZxdW90OyBidXQgSSBkb24ndCBzZWU8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IHdoeSB0aGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd291bGQgbWFrZSB0aGluZ3Mg
YW55IHdvcnNlLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gZmFjdCBieSBwcm9tb3Rpbmcg
YSBiZXR0ZXIgZGVwZW5kZW5jeSAmcXVvdDtkaXJlY3Rpb24mcXVvdDsgYmV0d2Vlbjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgc2NoZW1hPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWxlbWVudHMsJm5i
c3A7IHRoaW5rIGl0IGNvdWxkIHNpbXBsaWZ5IHRoaW5ncyAoc28gSSBuYWl2ZWx5IHRoaW5rIDop
ICkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhh
bmtzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNaWtlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jmd0OyBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bGhvdGth
QG5pYy5jeiI+bGhvdGthQG5pYy5jejwvYT5dPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsg
U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDEwOjI4IEFNPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsgVG86IE1pY2hhZWwgUmVoZGVyICZsdDs8YSBocmVmPSJtYWlsdG86TWlj
aGFlbC5SZWhkZXJAQW1kb2NzLmNvbSI+TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTwvYT4mZ3Q7
Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0
YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jmd0OyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgTWlj
aGFlbCBSZWhkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29t
Ij5NaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPC9hPiZndDsgd3JpdGVzOjxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEkgaGF2ZSBh
IHF1ZXN0aW9uIGFib3V0IOKAnHdoZW7igJ0gYW5kIG1hbmRhdG9yeSBvYmplY3RzLjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0
OyBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBpbXBsZW1lbnRlZCBzZW1hbnRpY3Mgb2Yg4oCcd2hl
buKAnSBhcmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgcmVhbGx5PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyZndDsg4oCcb3B0aW9uYWwgd2hlbuKAnSwgaW4gdGhhdCB0aGUgZW5j
bG9zaW5nIG9iamVjdCBjYW4gYmUgYWJzZW50IGV2ZW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jmd0OyB0aG91Z2ggaXQgaXMgbWFuZGF0b3J5IGFuZCB0aGUg4oCcd2hlbuKAnSBjbGF1c2UgaG9s
ZHMgdHJ1ZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIFJGQyBjb3VsZCBi
ZSBjbGVhcmVyIGFib3V0IHRoaXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEV4YW1wbGU8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwO2xlYWYgY29sb3Igezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VudW1lcmF0aW9uJm5ic3A7IHs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVu
dW0g4oCcYmx1ZeKAnTs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0g4oCcYmxhY2vigJ07PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21hbmRhdG9y
eSB0cnVlOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i
c3A7fTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
Y29udGFpbmVyIGZvbyB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHdoZW4gLi4vY29sb3IgPSDigJhibHVl4oCZOzxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBldGMuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm
Z3Q7IOKAnGZvb+KAnSBpcyBvcHRpb25hbCBkdWUgdG8gdGhlIHByZXNlbmNlIG9mIHRoZSDigJx3
aGVu4oCdIHN0YXRlbWVudDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBldmVuIHRo
b3VnaCB0aGUgb2JqZWN0IGlzIG1hbmRhdG9yeSAoc2FtZSBpcyB0cnVlIGZvciBtYW5kYXRvcnk8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgbGVhZiw8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jmd0OyZndDsgbWluLWVsZW1lbnRzPTEgbGlzdCBldGMuKS48YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jmd0OyBNYXliZSB5b3UgaW50ZW5kZWQgdG8gaGF2ZSwgZS5nLiwgYSAmcXVvdDtt
YW5kYXRvcnkgdHJ1ZSZxdW90OyBsZWFmIGluc2lkZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsm
Z3Q7ICZxdW90O2NvbnRhaW5lciBmb28mcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBjb25zaWRlcmVkIHZh
bGlkIFhNTCBmb3IgdGhlIGFib3ZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJmx0O2NvbG9yJmd0O2JsdWUmbHQ7L2NvbG9yJmd0Ozxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFllcywgaXQgaXMsIHVuZGVyIGN1cnJlbnQgWUFORyBydWxl
cywgbm8gbWF0dGVyIHdoYXQgJnF1b3Q7ZXRjLiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmZ3Q7IHN0YW5kcyBmb3IuIE5vdGUgdGhhdCBldmFsdWF0aW9uIG9mIHRoZSBYUGF0aCBleHBy
ZXNzaW9uIGluIHRoaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBjYXNlICh3aXRoICZx
dW90O2ZvbyZxdW90OyBtaXNzaW5nKSByZXF1aXJlcyB0aGUgcGVjdWxpYXIgcHJvY2VkdXJlIG9m
IHNlYy4gNy4yMS41PGJyPg0KJmd0OyBpbiBSRkMgNzk1MC48YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBJbiBteSB2aWV3IHRoaXMg
bWFrZXMgY29uZGl0aW9uYWxseSB2YXJpYW50IHNjaGVtYXMg4oCcbG9vc2XigJ0gaW48YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhlaXIgZW5mb3JjZW1lbnQgKHNvbWUgc2NlbmFy
aW9zIGNhbiB1c2UgY2hvaWNlIGJ1dCBpdCBkb2VzbuKAmXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyZndDsgY292ZXIgZXZlcnl0aGluZykuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhhdCBtYW5k
YXRvcnkgc2hvdWxkIGJlIHJlc3BlY3RlZCBmb3IgdGhlIGVuY2xvc2luZzxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBvYmplY3RzIG9mIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQuJm5i
c3A7IFRoYXQgaXMsIGEgbWFuZGF0b3J5IG9iamVjdCBtdXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsmZ3Q7IGJlIHByZXNlbnQgd2hlbiBpdHMg4oCcd2hlbuKAnSBjbGF1c2UgaG9sZHMg
dHJ1ZSBhbmQgYSBTY2hlbWF0cm9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHN0
YXRlbWVudCBzaG91bGQgZW5mb3JjZSB0aGF0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7
IEluIGZhY3QsIHRoaXMgaXMgb25lIGNhc2Ugd2hlcmUgdGhlIERTREwgbWFwcGluZyAoUkZDIDYx
MTApPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgZGV2aWF0ZXMgZnJvbSBZQU5HIDEuMC4g
Tm9kZXMgdGhhdCBtYW5kYXRvcnkgYXJlbid0IGVuY2xvc2VkIGluPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyZndDsgdGhlIFJFTEFYIE5HICZsdDtvcHRpb25hbCZndDsgcGF0dGVybiwgYW5kIGFy
ZSB0aGVuIHJlcXVpcmVkIG5vIG1hdHRlciB3aGF0PGJyPg0KJmd0OyBhbnkgJnF1b3Q7d2hlbiZx
dW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IHN0YXRlbWVudHMgc2F5IChiZWNhdXNl
IFJFTEFYIE5HIHZhbGlkYXRpb24gY29tZXMgYmVmb3JlPGJyPg0KJmd0OyBTY2hlbWF0cm9uKS48
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7
Jmd0OyBXaGF0IGlzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBjdXJyZW50IFlBTkcgcnVsZXMg
YmVoYXZpb3IsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRoYXQgdGhlIOKAnHdo
ZW7igJ0gU2NoZW1hdHJvbiBtYXBwaW5nIGRvZXNu4oCZdCBjaGVjayBmb3IgcHJlc2VuY2Ugb2Y8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhlIGVuY2xvc2luZyBtYW5kYXRvcnkg
b2JqZWN0Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IEZXSVcsIEkgaGF2ZSBiZWVuIHJl
cGVhdGVkbHkgcHJvdGVzdGluZyBhZ2FpbnN0IHRoaXMgYmVoYXZpb3VyPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsgYnV0IHdpdGhvdXQgbXVjaCBsdWNrLiBTZWUgZm9yIGV4YW1wbGU8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJl
bnQvbXNnMTQwMTIuaHRtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE0MDEyLmh0bTwvYT48YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jmd0OyBsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBBcyBhIHJlc3VsdCwgJnF1b3Q7d2hlbiZxdW90OyBpcyB0
aGUgdHJpY2tpZXN0IGZlYXR1cmUgaW4gWUFORyBieSBmYXIuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBMYWRhPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhhbmtzPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IE1pa2UgUmVoZGVyPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsgLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBMYWRpc2xhdiBM
aG90a2E8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBIZWFkLCBDWi5OSUMgTGFiczxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nzxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJh
c2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IGNsb3VkLWJhc2VkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQg
dG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmc8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJv
dmlkZXJzIG9mIHN1Y2g8YnI+DQomZ3Q7ICZndDsgJmd0OyBzeXN0ZW0gb24gYSBsaW1pdGVkIGJh
c2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jczxicj4NCiZndDsgJmd0OyAmZ3Q7
IGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3Vj
aCBwcm9jZXNzaW5nLDxicj4NCiZndDsgc3RvcmluZyBhbmQgYWNjZXNz4oCdLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v
ZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7IOKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBv
biBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkPGJyPg0KJmd0OyBzeXN0ZW0u
IEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1
c2luZyBzdWNoPGJyPg0KJmd0OyBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBh
cnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQ8YnI+DQomZ3Q7IGJhc2lz
LiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50
IHRvIHRoZSB1c2Ugb2Y8YnI+DQomZ3Q7IHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3Npbmcs
IHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgbmV0bW9kIG1haWxp
bmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5u
ZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IC0tPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4N
CiZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJyPg0KJmd0
OyBGYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0
eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88
L2E+Jmd0Ozxicj4NCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRo
aXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55IGVtYWlscyBzZW50
IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVt
IGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0
ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzDQogdG8gQW1kb2Nz
IGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3Vj
aCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uPGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0
PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9h
Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdCAwLjVpbjsiPjxlbT48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+
4oCcQW1kb2Nz4oCZIGVtYWlsDQpwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3
b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55DQplbWFpbHMgc2VudCB0byBBbWRvY3Mg
d2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFj
Y2Vzc2libGUNCmJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxp
bWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZg0KZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMg
eW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2gNCnByb2Nlc3Np
bmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48L2ZvbnQ+PC9zcGFuPjwvZW0+PC9wPg0KDQo8Zm9u
dCBzaXplPSIzIj48L2ZvbnQ+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_DB6PR06MB4085D91F66023AC98122FEDFE7E10DB6PR06MB4085eurp_--


From nobody Thu Oct 11 11:05:45 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D700E130EB9 for ; Thu, 11 Oct 2018 11:05:43 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 zw8fqUIUELoy for ; Thu, 11 Oct 2018 11:05:39 -0700 (PDT)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 EDBCE130EDB for ; Thu, 11 Oct 2018 11:05:38 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id v7-v6so9068339ljg.5 for ; Thu, 11 Oct 2018 11:05:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dpE8f8JU94qsUs5S17XfIkHFNP1Hf3SDG98i4fGGovU=; b=tygo/fi5FCjpZp/OvJ3l6KGafoRUugtrmbf/0Rwn9KtZeof+vZGS2uX058TQk0ddRD jIJwtMXrtf5zjm4JPC+Xy/Yn2VgAfo/iLdJCqACdK+8nefsNsHts6RgX4a1eMTfy1ttp KEibjRaOLHd/sZQqFkJOmS0I6PtD8/MlQ5vmfRNLvqVJNCRxSeanyVebFyw6HtUMurOe HyvsbEfN6uLvD9myjw4djL31IEJLkXeqd+kqmAljmBAL22zcwdUv/1nyYAXEhhYedziZ HASKfqTbr0ma039aTXsfWMANGG6+1uGbpkE/KTfnGFlbZ7sMvOoodjrHlkgNTUNQs8n3 MoYg==
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=dpE8f8JU94qsUs5S17XfIkHFNP1Hf3SDG98i4fGGovU=; b=j37SI8MVYC3qZCVZFZO3fsuvl1decxXOGaZ22cdOq8afSjV9t7Z5opvuMWX1CjMh/g /LUtD39UXweZu4nE7tEOC2Fz5LV3Ky1Er/grON8UnTbn+XYEtXpLscROQnVzTxm7lhrv a93d7VLUKLZC5rDJo6II8jyMos3pChnyFCzrkgwgzqnBGI15Mg8EQJbiTuLBTFDlAd39 PdHBrCGfSmnobSNP7m9yeuaSmK3OuhkE6MVgZ2IOOw5Xhp8c2iHV9Sq5HALDINzpMAU+ o3k+A1pwE3xZlVYEgpwspLRpvcSuT+vSfpZ4NywSp0j2sCvWuP0jNJbTYIluyc/ZoHtp XaFw==
X-Gm-Message-State: ABuFfoixrcXzlh4OsgzlKwbZQOLKb7p1i7HIMZGFGz6MAIem5OI98czi Nq+X4GAVf+M2q20V04r2Y7TdPPEX121ahNzKEgaoKQ==
X-Google-Smtp-Source: ACcGV63nZoTCRHO8BZ93fPutkiNX7iEkndUJyy6o1ageMhNe/101R3eQ32twLIOTU8WOqvHfAOw1Mc6RPrCK5e1vQ60=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr2071098lja.21.1539281136784;  Thu, 11 Oct 2018 11:05:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 11 Oct 2018 11:05:35 -0700 (PDT)
In-Reply-To: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>   
From: Andy Bierman 
Date: Thu, 11 Oct 2018 11:05:35 -0700
Message-ID: 
To: Michael Rehder 
Cc: Juergen Schoenwaelder ,  "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005e381e0577f7d118"
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:05:44 -0000

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

On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
wrote:

> I think the wording is relevant - something can be conditional but still
> required.
>
> It should be clarified that elements become implicitly =E2=80=9Cmandatory=
 false=E2=80=9D
> when a =E2=80=9Cwhen=E2=80=9D statement is used.
>
>
>
> I would like to see an enhancement to YANG to control this behavior, to
> allow the mandatory status to be enforced.
>
> That is, support also =E2=80=9Cconditionally required=E2=80=9D instead of=
 only the current
> =E2=80=9Cconditionally optional=E2=80=9D.
>
>
>


  leaf foo {
     when "../some-other-node =3D 5";
     type int32;
     mandatory true;
 }


This leaf is mandatory if the when-expr is true.
Where is the text in 7950 that says this mandatory true is ignored if
when-stmt is present?



Thanks
>
> Mike
>

Andy



>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Wednesday, October 10, 2018 2:52 PM
> *To:* Michael Rehder 
> *Cc:* Juergen Schoenwaelder ;
> Walker, Jason (Jason_Walker2@comcast.com) ;
> netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
>
>
>
>
> On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
> Sure.
>
> I think the RFC is unclear since it seems that the semantics are
> consistent in the back-end checks.
> One can read the RFC and not notice by its absence that the when clause
> doesn't require anything to be present.
>
>      The "when" statement makes its parent data definition statement
> conditional.
> Should be
>     The "when" statement makes its parent data definition statement
> conditional and optional.
>
>
>
> This is not correct.
>
>
>
> Step 1) if-feature makes the schema node conditional
>
>
>
> Step 2) when-stmt makes instances of the schema-node conditional
>
>
>
> Step 3) YANG validation applies to instances of data nodes (or the YANG
> default value if applicable)
>
>
>
> Step 2 is only relevant if Step 1 is true or non-existent
>
> Step 3 is only relevant if Step 2 is true or non-existent
>
>
>
> Andy
>
>
>
>
>
> I think there should be a more definite statement about this overriding
> any mandatory status of the parent data definition statement.
> Like
>      "Any mandatory status of the parent data definition statement
> (mandatory statement, min-element statement etc.) is overridden by this
> statement and made non-mandatory."
>
> That would have made the side-effect of "when" on other declarations
> clearer.
>
> Thanks
> mike
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d=
e
> ]
> > Sent: Wednesday, October 10, 2018 2:25 PM
> > To: Michael Rehder 
> > Cc: Robert Wilton ; Ladislav Lhotka ;
> > netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com)
> > 
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> >
> > Michael,
> >
> > what matters here is what the YANG specification (RFC 7950) says. Is
> there a
> > reason to believe the IPAddresses list in your example can be absent or
> have no
> > elements based on what RFC 7950 says? Or do we talk about a shortcoming
> of
> > RFC 6110?
> >
> > /js
> >
> > On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:
> > > If the list has a "when" clause the RNG file actually produces a
> "OneOrMore"
> > which has a choice of  or the list so it actually doesn't enforc=
e
> the
> > presence at least one row of the list (unless I'm mistaken in my
> reading).
> > >               
> > >                 
> > >                   
> > >                   
> > >                     
> > >                       
> > >                     
> > >                     
> > >                   
> > >                 
> > >               
> > >
> > > A leaf/container would be a simpler example but would result in the
> same
> > lack of enforcement of the mandatory status of an element with a "when"
> > clause.
> > >
> > > This RNG seems consistent with the Schematron rules that "when" makes
> > something optional.
> > >
> > >
> > > I think a workaround would be choice with mandatory true and a when
> clause
> > on the cases. This would ensure that at least one case is present since
> the
> > mandatory clause implements a Schematron existence constraint.
> > >
> > > Thanks
> > > Mike
> > > > -----Original Message-----
> > > > From: Robert Wilton [mailto:rwilton@cisco.com]
> > > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > > To: Michael Rehder ; Ladislav Lhotka
> > > > ; netmod@ietf.org
> > > > Cc: Walker, Jason (Jason_Walker2@comcast.com)
> > > > 
> > > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > doesn't ensure presence of the mandatory object
> > > >
> > > > Hi Mike,
> > > >
> > > > I think that the YANG below already enforces what you want, or
> > > > otherwise I don't follow your issue.
> > > >
> > > > The YANG below is valid in two cases:
> > > >
> > > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not present in
> > > > the config (due to the when statement).
> > > > (2) AssignmentMechanism =3D Static, IPAddresses exists and has at
> > > > least one element (due to min-elements 1).
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > > Container "foo" would be mandatory if not for the "when" child
> element.
> > > > > With the "when" child element, the logic becomes "inverted" and
> > > > > the
> > > > constraint is a negative one of "disallowed under certain condition=
".
> > > > >
> > > > > The UC is for enforcement in REST API payloads.
> > > > > For a practical example:
> > > > >
> > > > >           leaf AssignmentMechanism {
> > > > >              type enumeration {
> > > > >                enum "DHCP";
> > > > >                enum "Static";
> > > > >              }
> > > > >              mandatory true;
> > > > >              description "The address assignment mechanism.";
> > > > >            }
> > > > >            list IPAddresses {
> > > > >              when "../AssignmentMechanism =3D 'Static'";
> > > > >              key Address;
> > > > >              min-elements 1;
> > > > >
> > > > >              leaf Address {
> > > > >                type capit:IPv4Address;
> > > > >                description "An ipv4 address.";
> > > > >              }
> > > > >             }
> > > > >
> > > > > There is no way in the IPAddresses list to enforce that there is
> > > > > at least one IP
> > > > Address when the assignment method is "Static".
> > > > > One could put a "must" on "AssignmentMechanism" to ensure at leas=
t
> > > > > one
> > > > element of the IPAddresses list when "Static", but I don't see this
> > > > as a good schema design, to have the controlling attribute check
> controlled
> > attributes.
> > > > >
> > > > > I appreciate that this semantic can't be changed in YANG at this
> point.
> > > > > Could the "when" statement have a modifying child element to stat=
e
> > > > > that the
> > > > mandatory status of the element is to be enforced?
> > > > > Like
> > > > >      container foo {
> > > > >        when "condition" {
> > > > >            enforce-mandatory-status;
> > > > >        }
> > > > >
> > > > > There is already back-end for existential checks for mandatory
> > > > > choice so this
> > > > seems reasonably consistent to me.
> > > > > I appreciate there are existing issues for "when" but I don't see
> > > > > why this
> > > > would make things any worse.
> > > > > In fact by promoting a better dependency "direction" between
> > > > > schema
> > > > elements,  think it could simplify things (so I naively think :) ).
> > > > >
> > > > > Thanks
> > > > > Mike
> > > > >> -----Original Message-----
> > > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > > > >> Sent: Wednesday, October 10, 2018 10:28 AM
> > > > >> To: Michael Rehder ; netmod@ietf.org
> > > > >> Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > >> doesn't ensure presence of the mandatory object
> > > > >>
> > > > >> Michael Rehder  writes:
> > > > >>
> > > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D and mandatory ob=
jects.
> > > > >>>
> > > > >>> It seems to me that the implemented semantics of =E2=80=9Cwhen=
=E2=80=9D are
> > > > >>> really
> > > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclosing object ca=
n be absent even
> > > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80=9D clause hol=
ds true.
> > > > >>> The RFC could be clearer about this.
> > > > >>>
> > > > >>> Example
> > > > >>>
> > > > >>>     leaf color {
> > > > >>>       enumeration  {
> > > > >>>          enum =E2=80=9Cblue=E2=80=9D;
> > > > >>>          enum =E2=80=9Cblack=E2=80=9D;
> > > > >>>       }
> > > > >>>       mandatory true;
> > > > >>>     }
> > > > >>>     container foo {
> > > > >>>        when ../color =3D =E2=80=98blue=E2=80=99;
> > > > >>>        etc.
> > > > >>>     }
> > > > >>>
> > > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the presence of the =
=E2=80=9Cwhen=E2=80=9D statement
> > > > >>> even though the object is mandatory (same is true for mandatory
> > > > >>> leaf,
> > > > >>> min-elements=3D1 list etc.).
> > > > >> Maybe you intended to have, e.g., a "mandatory true" leaf inside
> > > > >> "container foo"?
> > > > >>
> > > > >>> This is considered valid XML for the above
> > > > >>>      blue
> > > > >> Yes, it is, under current YANG rules, no matter what "etc."
> > > > >> stands for. Note that evaluation of the XPath expression in this
> > > > >> case (with "foo" missing) requires the peculiar procedure of sec=
.
> 7.21.5
> > in RFC 7950.
> > > > >>
> > > > >>> In my view this makes conditionally variant schemas =E2=80=9Clo=
ose=E2=80=9D in
> > > > >>> their enforcement (some scenarios can use choice but it doesn=
=E2=80=99t
> > > > >>> cover everything).
> > > > >>>
> > > > >>> I think that mandatory should be respected for the enclosing
> > > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement.  That is, a mand=
atory object must
> > > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clause holds true an=
d a Schematron
> > > > >>> statement should enforce that.
> > > > >> In fact, this is one case where the DSDL mapping (RFC 6110)
> > > > >> deviates from YANG 1.0. Nodes that mandatory aren't enclosed in
> > > > >> the RELAX NG  pattern, and are then required no matter
> what
> > any "when"
> > > > >> statements say (because RELAX NG validation comes before
> > Schematron).
> > > > >>
> > > > >>> What is the rationale behind the current YANG rules behavior,
> > > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapping doesn=E2=80=
=99t check for presence of
> > > > >>> the enclosing mandatory object?
> > > > >> FWIW, I have been repeatedly protesting against this behaviour
> > > > >> but without much luck. See for example
> > > > >>
> > > > >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.ht=
m
> > > > >> l
> > > > >>
> > > > >> As a result, "when" is the trickiest feature in YANG by far.
> > > > >>
> > > > >> Lada
> > > > >>
> > > > >>> thanks
> > > > >>> Mike Rehder
> > > > >> --
> > > > >> Ladislav Lhotka
> > > > >> Head, CZ.NIC Labs
> > > > >> PGP Key ID: 0xB8F92B08A9F76C67
> > > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide,
> > > > > cloud-based
> > > > system. Any emails sent to Amdocs will be processed and stored usin=
g
> > > > such system and are accessible by third party providers of such
> > > > system on a limited basis. Your sending of emails to Amdocs
> > > > evidences your consent to the use of such system and such processin=
g,
> > storing and access=E2=80=9D.
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, wo=
rldwide,
> cloud-based
> > system. Any emails sent to Amdocs will be processed and stored using su=
ch
> > system and are accessible by third party providers of such system on a
> limited
> > basis. Your sending of emails to Amdocs evidences your consent to the
> use of
> > such system and such processing, storing and access=E2=80=9D.
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> 
> > Fax:   +49 421 200 3103         
> =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw=
ide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> *=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, world=
wide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.*
>

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




On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <=
Michael.Rehd=
er@amdocs.com> wrote:











I think the wording is relevant - som=
ething can be conditional but still required.


It should be clarified that elements =
become implicitly =E2=80=9Cmandatory false=E2=80=9D when a =E2=80=9Cwhen=E2=
=80=9D statement is used.


=C2=A0


I would like to see an enhancement to=
 YANG to control this behavior, to allow the mandatory status to be enforce=
d.


That is, support also =E2=80=9Ccondit=
ionally required=E2=80=9D instead of only the current =E2=80=9Cconditionall=
y optional=E2=80=9D.


=C2=A0
<=
/blockquote>


=C2=A0 leaf foo {
=
=C2=A0 =C2=A0 =C2=A0when "../some-other-node =3D 5";
=
=C2=A0 =C2=A0 =C2=A0type int32;
=C2=A0 =C2=A0 =C2=A0mandatory tru=
e;
=C2=A0}


This leaf is m=
andatory if the when-expr is true.
Where is the text in 7950 that=
 says this mandatory true is ignored if when-stmt is present?




Thanks


Mike

Andy

=C2=A0


=C2=A0








From: Andy Bierman [mailto:andy@yumaworks.com]


Sent: Wednesday, October 10, 2018 2:52 PM

To: Michael Rehder <Michael.Rehder@Amdocs.com>

Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.=
de>; Walker, Jason (Jason_Walker2@comcast.com) <Jason_Walker2@comcast.com>; netmod@ietf.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn&=
#39;t ensure presence of the mandatory object






=C2=A0




=C2=A0




=C2=A0




On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <=
;Michael.Reh=
der@amdocs.com> wrote:




Sure.



I think the RFC is unclear since it seems that the semantics are consistent=
 in the back-end checks.

One can read the RFC and not notice by its absence that the when clause doe=
sn't require anything to be present.



=C2=A0 =C2=A0 =C2=A0The "when" statement makes its parent data de=
finition statement conditional.

Should be

=C2=A0 =C2=A0 The "when" statement makes its parent data definiti=
on statement conditional and optional.






=C2=A0






This is not correct.






=C2=A0






Step 1) if-feature makes the schema node conditional=







=C2=A0






Step 2) when-stmt makes instances of the schema-node=
 conditional






=C2=A0






Step 3) YANG validation applies to instances of data=
 nodes (or the YANG default value if applicable)






=C2=A0






Step 2 is only relevant if Step 1 is true or non-exi=
stent






Step 3 is only relevant if Step 2 is true or non-exi=
stent






=C2=A0






Andy






=C2=A0






=C2=A0






I think there should be a more definite statement ab=
out this overriding any mandatory status of the parent data definition stat=
ement.

Like

=C2=A0 =C2=A0 =C2=A0"Any mandatory status of the parent data definitio=
n statement (mandatory statement, min-element statement etc.) is overridden=
 by this statement and made non-mandatory."



That would have made the side-effect of "when" on other declarati=
ons clearer.



Thanks

mike

> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-univers=
ity.de]

> Sent: Wednesday, October 10, 2018 2:25 PM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> Cc: Robert Wilton <rwilton@cisco.com>; Ladislav Lhotka <lhotka@nic.cz>;

> netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com)

> <Jas=
on_Walker2@comcast.com>

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn=
9;t

> ensure presence of the mandatory object

> 

> Michael,

> 

> what matters here is what the YANG specification (RFC 7950) says. Is t=
here a

> reason to believe the IPAddresses list in your example can be absent o=
r have no

> elements based on what RFC 7950 says? Or do we talk about a shortcomin=
g of

> RFC 6110?

> 

> /js

> 

> On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:

> > If the list has a "when" clause the RNG file actually p=
roduces a "OneOrMore"

> which has a choice of <empty> or the list so it actually doesn&#=
39;t enforce the

> presence at least one row of the list (unless I'm mistaken in my r=
eading).

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<oneOrMo=
re>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
choice>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0<empty/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0<element name=3D"IPAddresses">

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<element name=3D"Address">

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0<ref name=3D"types__IPv4Address"/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</element>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<empty/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</element>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/choice>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</oneOrM=
ore>

> >

> > A leaf/container would be a simpler example but would result in t=
he same

> lack of enforcement of the mandatory status of an element with a "=
;when"

> clause.

> >

> > This RNG seems consistent with the Schematron rules that "wh=
en" makes

> something optional.

> >

> >

> > I think a workaround would be choice with mandatory true and a wh=
en clause

> on the cases. This would ensure that at least one case is present sinc=
e the

> mandatory clause implements a Schematron existence constraint.

> >

> > Thanks

> > Mike

> > > -----Original Message-----

> > > From: Robert Wilton [mailto:rwilton@cisco.com]

> > > Sent: Wednesday, October 10, 2018 11:33 AM

> > > To: Michael Rehder <Michael.Rehder@Amdocs.com>; Ladislav Lhotk=
a

> > > <lhotk=
a@nic.cz>; 
netmod@ietf.org

> > > Cc: Walker, Jason (Jason_Walker2@comcast.com)

> > > <Jason_Walker2@comcast.com>

> > > Subject: Re: [netmod] WHEN statement within mandatory object=
s

> > > doesn't ensure presence of the mandatory object

> > >

> > > Hi Mike,

> > >

> > > I think that the YANG below already enforces what you want, =
or

> > > otherwise I don't follow your issue.

> > >

> > > The YANG below is valid in two cases:

> > >

> > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not pre=
sent in

> > > the config (due to the when statement).

> > > (2) AssignmentMechanism =3D Static, IPAddresses exists and h=
as at

> > > least one element (due to min-elements 1).

> > >

> > > Thanks,

> > > Rob

> > >

> > >

> > > On 10/10/2018 16:23, Michael Rehder wrote:

> > > > Container "foo" would be mandatory if not for=
 the "when" child element.

> > > > With the "when" child element, the logic beco=
mes "inverted" and

> > > > the

> > > constraint is a negative one of "disallowed under certa=
in condition".

> > > >

> > > > The UC is for enforcement in REST API payloads.

> > > > For a practical example:

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf Assignment=
Mechanism {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type en=
umeration {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
enum "DHCP";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
enum "Static";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandato=
ry true;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descrip=
tion "The address assignment mechanism.";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list IPAddress=
es {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when &q=
uot;../AssignmentMechanism =3D 'Static'";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key Add=
ress;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 min-ele=
ments 1;

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf Ad=
dress {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
type capit:IPv4Address;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
description "An ipv4 address.";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > >

> > > > There is no way in the IPAddresses list to enforce that=
 there is

> > > > at least one IP

> > > Address when the assignment method is "Static".
> > > > One could put a "must" on "AssignmentMec=
hanism" to ensure at least

> > > > one

> > > element of the IPAddresses list when "Static", but=
 I don't see this

> > > as a good schema design, to have the controlling attribute c=
heck controlled

> attributes.

> > > >

> > > > I appreciate that this semantic can't be changed in=
 YANG at this point.

> > > > Could the "when" statement have a modifying c=
hild element to state

> > > > that the

> > > mandatory status of the element is to be enforced?

> > > > Like

> > > >=C2=A0 =C2=A0 =C2=A0 container foo {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "condition" {=


> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce-mandat=
ory-status;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >

> > > > There is already back-end for existential checks for ma=
ndatory

> > > > choice so this

> > > seems reasonably consistent to me.

> > > > I appreciate there are existing issues for "when&q=
uot; but I don't see

> > > > why this

> > > would make things any worse.

> > > > In fact by promoting a better dependency "directio=
n" between

> > > > schema

> > > elements,=C2=A0 think it could simplify things (so I naively=
 think :) ).

> > > >

> > > > Thanks

> > > > Mike

> > > >> -----Original Message-----

> > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]

> > > >> Sent: Wednesday, October 10, 2018 10:28 AM

> > > >> To: Michael Rehder <Michael.Rehder@Amdocs.com>;
netmod@ietf.org
> > > >> Subject: Re: [netmod] WHEN statement within mandato=
ry objects

> > > >> doesn't ensure presence of the mandatory object=


> > > >>

> > > >> Michael Rehder <Michael.Rehder@Amdocs.com> writes:
> > > >>

> > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D =
and mandatory objects.

> > > >>>

> > > >>> It seems to me that the implemented semantics o=
f =E2=80=9Cwhen=E2=80=9D are

> > > >>> really

> > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclos=
ing object can be absent even

> > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80=
=9D clause holds true.

> > > >>> The RFC could be clearer about this.

> > > >>>

> > > >>> Example

> > > >>>

> > > >>>=C2=A0 =C2=A0 =C2=A0leaf color {

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration=C2=A0 {
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80=
=9Cblue=E2=80=9D;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80=
=9Cblack=E2=80=9D;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

> > > >>>=C2=A0 =C2=A0 =C2=A0}

> > > >>>=C2=A0 =C2=A0 =C2=A0container foo {

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 when ../color =3D =
=E2=80=98blue=E2=80=99;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 etc.

> > > >>>=C2=A0 =C2=A0 =C2=A0}

> > > >>>

> > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the pr=
esence of the =E2=80=9Cwhen=E2=80=9D statement

> > > >>> even though the object is mandatory (same is tr=
ue for mandatory

> > > >>> leaf,

> > > >>> min-elements=3D1 list etc.).

> > > >> Maybe you intended to have, e.g., a "mandatory=
 true" leaf inside

> > > >> "container foo"?

> > > >>

> > > >>> This is considered valid XML for the above

> > > >>>=C2=A0 =C2=A0 =C2=A0 <color>blue</color=
>

> > > >> Yes, it is, under current YANG rules, no matter wha=
t "etc."

> > > >> stands for. Note that evaluation of the XPath expre=
ssion in this

> > > >> case (with "foo" missing) requires the pe=
culiar procedure of sec. 7.21.5

> in RFC 7950.

> > > >>

> > > >>> In my view this makes conditionally variant sch=
emas =E2=80=9Cloose=E2=80=9D in

> > > >>> their enforcement (some scenarios can use choic=
e but it doesn=E2=80=99t

> > > >>> cover everything).

> > > >>>

> > > >>> I think that mandatory should be respected for =
the enclosing

> > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement.=
=C2=A0 That is, a mandatory object must

> > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clau=
se holds true and a Schematron

> > > >>> statement should enforce that.

> > > >> In fact, this is one case where the DSDL mapping (R=
FC 6110)

> > > >> deviates from YANG 1.0. Nodes that mandatory aren&#=
39;t enclosed in

> > > >> the RELAX NG <optional> pattern, and are then=
 required no matter what

> any "when"

> > > >> statements say (because RELAX NG validation comes b=
efore

> Schematron).

> > > >>

> > > >>> What is the rationale behind the current YANG r=
ules behavior,

> > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapp=
ing doesn=E2=80=99t check for presence of

> > > >>> the enclosing mandatory object?

> > > >> FWIW, I have been repeatedly protesting against thi=
s behaviour

> > > >> but without much luck. See for example

> > > >>

> > > >> 
https://www.ietf.org/mail-archive/web/netmod/current/msg14012.htm=


> > > >> l

> > > >>

> > > >> As a result, "when" is the trickiest feat=
ure in YANG by far.

> > > >>

> > > >> Lada

> > > >>

> > > >>> thanks

> > > >>> Mike Rehder

> > > >> --

> > > >> Ladislav Lhotka

> > > >> Head, CZ.NIC Labs

> > > >> PGP Key ID: 0xB8F92B08A9F76C67

> > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a t=
hird-party, worldwide,

> > > > cloud-based

> > > system. Any emails sent to Amdocs will be processed and stor=
ed using

> > > such system and are accessible by third party providers of s=
uch

> > > system on a limited basis. Your sending of emails to Amdocs<=
br>
> > > evidences your consent to the use of such system and such pr=
ocessing,

> storing and access=E2=80=9D.

> > > > _______________________________________________
> > > > netmod mailing list

> > > > ne=
tmod@ietf.org

> > > > https://www.ietf.org/mailman/listinfo/netmod
> >

> > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access=E2=80=9D.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.=
org

> > https://www.ietf.org/mailman/listinfo/netmod

> 

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany

> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
;https://ww=
w.jacobs-university.de/>

=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldwid=
e, cloud-based system. Any emails sent to Amdocs will be processed and stor=
ed using such system and are accessible by third party providers of such sy=
stem on a limited basis. Your sending of emails
 to Amdocs evidences your consent to the use of such system and such proces=
sing, storing and access=E2=80=9D.

_______________________________________________

netmod mailing list

netmod@ietf.org
=
https://www.ietf.org/mailman/listinfo/netmod






=C2=A0










=E2=80=9CAmdocs=E2=80=99 email
platform is based on a third-party, worldwide, cloud-based system. Any
emails sent to Amdocs will be processed and stored using such system and ar=
e accessible
by third party providers of such system on a limited basis. Your sending of
emails to Amdocs evidences your consent to the use of such system and such
processing, storing and access=E2=80=9D.









--0000000000005e381e0577f7d118--


From nobody Thu Oct 11 11:12:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09D1200D7 for ; Thu, 11 Oct 2018 11:12:23 -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, DKIMWL_WL_MED=-0.001, 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 VF_iysuMU9UZ for ; Thu, 11 Oct 2018 11:12:20 -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 3BBBF130E82 for ; Thu, 11 Oct 2018 11:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35874; q=dns/txt; s=iport; t=1539281540; x=1540491140; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IZK1Dq6bfa5Ew+Xc6A2qi994qDYw5c61jbnxw8840C0=; b=f4MGiEX4r6LfRT9+HPFPO7jeQ8HJiRY5c+UBVdnahNL9vBlYnMJs2HPR arpCgL8qpM/+BMCRU6tVvNUWAvRhpnyc8xpF8Jk0i2DBjnF/bRJwdetYw LUqvslN1V9SXuoBjgjJEEO23phUfnRE04RKrMvkyrSC50kBHR5GjxxAPD g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAlkr9b/5FdJa1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQx3Zn8VEwqDa5RMgWgllwCBdwMLAQE?= =?us-ascii?q?YAQoJg3pGAheEPiE1DA0BAwEBAgEBAm0cDIU5AQEBAQIBAQEhSwsFCwIBCBE?= =?us-ascii?q?DAQIhAQYDAgICJQsUCQgCBA4FgyABgR1cCA+mH4EuiVgFi0UXgUE/gTkME4J?= =?us-ascii?q?MgxsBAYE6ETYWgksxgiYCiD2BG4RGFYVziWoJApBSF4FPjkKJFIxXAhEUgSU?= =?us-ascii?q?eATaBVXAVOyoBgkEJiw6FPm+BFohSgS4BgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,369,1534809600";  d="scan'208,217";a="184917008"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 18:12:19 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9BICJQw028198 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2018 18:12:19 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Oct 2018 13:12:18 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 11 Oct 2018 13:12:18 -0500
From: "Reshad Rahman (rrahman)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
CC: Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgIAASaoAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgAAFDgCAAEkjAP//4u6A
Date: Thu, 11 Oct 2018 18:12:18 +0000
Message-ID: 
References:  <20181011.122137.1647095802972927089.mbj@tail-f.com> <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.54]
Content-Type: multipart/alternative; boundary="_000_D4E6916FB17F45249A3D2990DF9D6FF8ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:12:23 -0000

--_000_D4E6916FB17F45249A3D2990DF9D6FF8ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUm9iLA0KDQoNCkZyb206ICJSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJ
TUlURUQgYXQgQ2lzY28pIiA8cndpbHRvbkBjaXNjby5jb20+DQpEYXRlOiBUaHVyc2RheSwgT2N0
b2JlciAxMSwgMjAxOCBhdCAxMTo1NiBBTQ0KVG86ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIg
PHJyYWhtYW5AY2lzY28uY29tPg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t
PiwgIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0
bW9kXSB4cGF0aCBleHByZXNzaW9ucyBpbiBKU09ODQoNCg0KPHRyaW1tZWQ+DQoNCllldCB0aGUg
ZXhhbXBsZXMgaW4gc2VjdGlvbiA4LjMuNiBkb24ndCBzZWVtIHRvIHVzZSBuYW1lc3BhY2UgcHJl
Zml4ZXMgaW4gdmVyeSBtYW55IHBsYWNlcywgZS5nLiB3aHkgaXMgaXQgIi9leGFtcGxlLW1vZDpl
dmVudDEvbmFtZT0nam9lJyIgYW5kIG5vdCAiL2V4YW1wbGUtbW9kOmV2ZW50MS9leGFtcGxlLW1v
ZDpuYW1lPSdqb2UnIj8gIElzIHRoZSBleGFtcGxlIHdyb25nLCBvciBvdGhlcndpc2Ugd2hhdCBh
bSBJIG1pc3Npbmc/IDotKQ0KDQoNCjxSUj4gU2VjdGlvbiA4LjMuNiBvZiB3aGljaCBkb2N1bWVu
dD8NClJGQyA4MDQwLg0KDQo8UlIyPiBCLjMuNiwgZ290IGl0LiBXYXMgbG9va2luZyBmb3IgOC4z
LjYsIHRoYXTigJlzIHdoeSBkaWRu4oCZdCBmaW5kIGl0Lg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0K
DQoNClRoYW5rcywNClJvYg0KDQoNCg0KUmVnYXJkcywNClJlc2hhZC4NCg0KVGhhbmtzLA0KUm9i
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KDQoNCg0KDQpUaGFua3MsDQoN
ClJvYg0KDQoNCg0KDQoNClRoZXJlIGlzIG5vIHN0YW5kYXJkIFhQYXRoIGltcGxlbWVudGF0aW9u
IHRoYXQgY2FuIGp1c3QgdGFrZSBhbiBYTUwNCg0KaW5zdGFuY2UgZG9jdW1lbnQgKyBZQU5HIG1v
ZHVsZSBhbmQgZmlndXJlIG91dCB3aGF0IHRvIGRvLiAgQ3VzdG9tDQoNCmNvZGUgaXMgbmVlZGVk
IHRvIGNvbm5lY3QgdGhpbmdzIHRvZ2V0aGVyLiAgVGhpcyBwcm9wb3NhbCBkb2Vzbid0DQoNCmNo
YW5nZSB0aGlzLg0KDQoNCg0KDQoNCi9tYXJ0aW4NCg0KDQoNCg0KDQpBIG5vcm1hbCBYUGF0aCBp
bXBsZW1lbnRhdGlvbiB3aWxsIG5vdCBmaW5kIGFueSBuYW1lc3BhY2UgbWFwcGluZyBmb3INCg0K
dGhlDQoNCnByZWZpeGVzLg0KDQoNCg0KQW4gWFBhdGggZXhwcmVzc2lvbiBoYXMgbm8gY29uY2Vw
dCBvZiB0aGUgImN1cnJlbnQgbW9kdWxlIiBpbmhlcml0ZWQNCg0KZnJvbQ0KDQp0aGUgcGFyZW50
DQoNCmxpa2UgdGhlIEpTT04gZW5jb2RpbmcuIFRoaXMgaXMgcHJvYmxlbWF0aWMgZm9yIHByZWRp
Y2F0ZXMNCg0KDQoNCiAgICAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaW50ZXJmYWNlW25h
bWU9J2V0aDAnXQ0KDQoNCg0KWFBhdGggc2F5cyB0aGUgbWlzc2luZyBwcmVmaXhlcyBmb3IgJ2lu
dGVyZmFjZScgYW5kICduYW1lJyBhcmUgc2ltcGx5DQoNCm1pc3NpbmcgKG5vIG5hbWVzcGFjZSku
DQoNClRoZSBKU09OIGVuY29kaW5nIHNheXMgImlldGYtaW50ZXJmYWNlcyIgaXMgdXNlZCBmb3Ig
J2ludGVyZmFjZXMnLiBhbmQNCg0KJ2ludGVyZmFjZScuDQoNClRoZXJlIGlzIG5vIHNwZWNpZmlj
YXRpb24gZm9yIHRoZSAnbmFtZScgbm9kZSBpbnNpZGUgYSBwcmVkaWNhdGUuDQoNCg0KDQpTbyB5
b3UgbXVzdCBtZWFuIHRoZSBmdWxsIG1vZHVsZSBuYW1lIHdpbGwgYmUgdXNlZCBhdCBldmVyeSBu
b2RlOg0KDQoNCg0KICAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2Vz
OmludGVyZmFjZVtpZXRmLWludGVyZmFjZXM6bmFtZT0nZXRoMCddDQoNCg0KDQoNCg0KDQoNCi9t
YXJ0aW4NCg0KDQoNCg0KDQpBbmR5DQoNCg0KDQoNCg0KICAgICBIbW0sIHNvIHlvdSBtZWFuIGNo
YW5nZSB0aGUgbGVhZiAic3RyZWFtLXhwYXRoLWZpbHRlciIgdG8gc2F5Og0KDQoNCg0KICAgICAg
ICAgICAgICBvICBUaGUgc2V0IG9mIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMgaGFzIG9uZSBtZW1i
ZXIgZm9yDQoNCmVhY2gNCg0KICAgICAgICAgICAgICAgICBZQU5HIG1vZHVsZSBzdXBwb3J0ZWQg
YnkgdGhlIHNlcnZlci4gIFRoaXMgbWVtYmVyIG1hcHMNCg0KICAgICAgICAgICAgICAgICBmcm9t
IHRoZSBZQU5HIG1vZHVsZSBuYW1lIHRvIHRoZSBZQU5HIG1vZHVsZSBuYW1lc3BhY2UuDQoNCg0K
DQogICAgICAgICAgICAgICAgIFRoaXMgbWVhbnMgdGhhdCBpbiB0aGUgWFBhdGggZXhwcmVzc2lv
biwgdGhlIG1vZHVsZQ0KDQpuYW1lDQoNCiAgICAgICAgICAgICAgICAgc2VydmVzIGFzIHRoZSBw
cmVmaXguDQoNCg0KDQogICAgIC4uLi4gYW5kIHRoZW4gYWxzbyBnaXZlIGFuIGV4YW1wbGUgb2Yg
dGhpcy4NCg0KDQoNCiAgICAgVGhpcyBpcyBwcm9iYWJseSB3aGF0IHdlIG5lZWQgdG8gZG8gaW4g
YWxsIHBsYWNlcyB3aGVyZQ0KDQp5YW5nOnhwYXRoMS4wDQoNCiAgICAgaXMgdXNlZCwgZ29pbmcg
Zm9yd2FyZC4gIE1heWJlIGV2ZW4gZGVmaW5lIGEgbmV3IHR5cGUNCg0KICAgICB5YW5nOnhwYXRo
MS4wLTIgKG5hbWU/KSB3aXRoIHRoZSBzZXQgb2YgbmFtZXNwYWNlIGRlY2xhcmF0aW9ucw0KDQog
ICAgIGJ1aWx0LWluLg0KDQoNCg0KV2Ugc2hvdWxkIGF2b2lkIG1ha2luZyBvZmYtdGhlLXNoZWxm
IGltcGxlbWVudGF0aW9ucyBvZiBzdGFuZGFyZHMgbGlrZQ0KDQpYUGF0aCB1bnVzYWJsZS4NCg0K
QXQgdGhlIHZlcnkgbGVhc3QgdGhpcyBzaG91bGQgYmUgb25seSBhdmFpbGFibGUgaWYgdGhlIHNl
cnZlciBzdXBwb3J0cw0KDQppdA0KDQood2l0aCBhIGNhcGFiaWxpdHkgVVJJKQ0KDQoNCg0KDQoN
Cg0KDQo8UlI+IFNvIHdlIG5lZWQgYW4gdXBkYXRlIHRvIFJGQzc5NTE/DQoNCg0KDQpSZWdhcmRz
LA0KDQpSZXNoYWQuDQoNCg0KDQoNCg0KQW5keQ0KDQoNCg0KDQoNCiAgICAgL21hcnRpbg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCiAgICAgPg0KDQogICAgID4gTGFkYQ0KDQogICAgID4NCg0KICAg
ICA+ID4NCg0KICAgICA+ID4gSG93IGlzIHRoaXMgc3VwcG9zZWQgdG8gd29yayB3aXRoIEpTT04/
DQoNCiAgICAgPiA+DQoNCiAgICAgPiA+DQoNCiAgICAgPiA+IC9tYXJ0aW4NCg0KICAgICA+ID4N
Cg0KICAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KICAgICA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KDQogICAgID4gPiBuZXRtb2RAaWV0
Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KICAgICA+ID4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KICAgICA+DQoNCiAgICAgPiAtLQ0KDQog
ICAgID4gTGFkaXNsYXYgTGhvdGthDQoNCiAgICAgPiBIZWFkLCBDWi5OSUMgTGFicw0KDQogICAg
ID4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQoNCiAgICAgPg0KDQoNCg0KICAgICBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAgIG5l
dG1vZCBtYWlsaW5nIGxpc3QNCg0KICAgICBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp
ZXRmLm9yZz4NCg0KICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpu
ZXRtb2RAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KDQouLg0KDQoNCg0KLg0KDQoNCg0KDQoNCg0KDQo=

--_000_D4E6916FB17F45249A3D2990DF9D6FF8ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <01D9CFECD15EA44BB525C1446CBDFC7A@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp
Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h
dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv
bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w
cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+SGkgUm9iLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90O1JvYmVydCBX
aWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykmcXVvdDsgJmx0O3J3
aWx0b25AY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciAx
MSwgMjAxOCBhdCAxMTo1NiBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmVzaGFkIFJhaG1hbiAo
cnJhaG1hbikmcXVvdDsgJmx0O3JyYWhtYW5AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+
TWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7LCAmcXVvdDtuZXRtb2RAaWV0
Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+
UmU6IFtuZXRtb2RdIHhwYXRoIGV4cHJlc3Npb25zIGluIEpTT048bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij4mbHQ7dHJp
bW1lZCZndDs8bzpwPjwvbzpwPjwvYT48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCllldCB0aGUgZXhh
bXBsZXMgaW4gc2VjdGlvbiA4LjMuNiBkb24ndCBzZWVtIHRvIHVzZSBuYW1lc3BhY2UgcHJlZml4
ZXMgaW4gdmVyeSBtYW55IHBsYWNlcywgZS5nLiB3aHkgaXMgaXQgJnF1b3Q7L2V4YW1wbGUtbW9k
OmV2ZW50MS9uYW1lPSdqb2UnJnF1b3Q7IGFuZCBub3QgJnF1b3Q7L2V4YW1wbGUtbW9kOmV2ZW50
MS9leGFtcGxlLW1vZDpuYW1lPSdqb2UnJnF1b3Q7PyZuYnNwOyBJcyB0aGUgZXhhbXBsZSB3cm9u
Zywgb3Igb3RoZXJ3aXNlIHdoYXQgYW0gSSBtaXNzaW5nPyA6LSk8YnI+DQo8YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbHQ7UlImZ3Q7IFNlY3Rpb24gOC4zLjYg
b2Ygd2hpY2ggZG9jdW1lbnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+UkZDIDgwNDAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmx0O1JSMiZndDsgQi4zLjYsIGdvdCBp
dC4gV2FzIGxvb2tpbmcgZm9yIDguMy42LCB0aGF04oCZcyB3aHkgZGlkbuKAmXQgZmluZCBpdC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJl
c2hhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQpUaGFua3Ms
PGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlc2hhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij48YnI+DQpUaGFua3MsPGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf
TWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPi9tYXJ0aW48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PlJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPlRoZXJlIGlzIG5vIHN0YW5kYXJkIFhQYXRoIGltcGxlbWVudGF0aW9uIHRo
YXQgY2FuIGp1c3QgdGFrZSBhbiBYTUw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aW5zdGFuY2UgZG9jdW1l
bnQgJiM0MzsgWUFORyBtb2R1bGUgYW5kIGZpZ3VyZSBvdXQgd2hhdCB0byBkby4mbmJzcDsgQ3Vz
dG9tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPmNvZGUgaXMgbmVlZGVkIHRvIGNvbm5lY3QgdGhpbmdzIHRv
Z2V0aGVyLiZuYnNwOyBUaGlzIHByb3Bvc2FsIGRvZXNuJ3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Y2hh
bmdlIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+L21hcnRpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QSBub3JtYWwgWFBhdGgg
aW1wbGVtZW50YXRpb24gd2lsbCBub3QgZmluZCBhbnkgbmFtZXNwYWNlIG1hcHBpbmcgZm9yPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPnRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5wcmVmaXhlcy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkFuIFhQYXRoIGV4cHJlc3Npb24gaGFz
IG5vIGNvbmNlcHQgb2YgdGhlICZxdW90O2N1cnJlbnQgbW9kdWxlJnF1b3Q7IGluaGVyaXRlZDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij5mcm9tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnRoZSBwYXJlbnQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+bGlrZSB0aGUgSlNPTiBlbmNvZGluZy4gVGhpcyBpcyBwcm9ibGVtYXRpYyBm
b3IgcHJlZGljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pbnRlcmZhY2Vb
bmFtZT0nZXRoMCddPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Y
UGF0aCBzYXlzIHRoZSBtaXNzaW5nIHByZWZpeGVzIGZvciAnaW50ZXJmYWNlJyBhbmQgJ25hbWUn
IGFyZSBzaW1wbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bWlzc2luZyAobm8gbmFtZXNwYWNlKS48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+VGhlIEpTT04gZW5jb2Rpbmcgc2F5cyAmcXVvdDtpZXRmLWludGVyZmFj
ZXMmcXVvdDsgaXMgdXNlZCBmb3IgJ2ludGVyZmFjZXMnLiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
J2ludGVyZmFjZScuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24g
Zm9yIHRoZSAnbmFtZScgbm9kZSBpbnNpZGUgYSBwcmVkaWNhdGUuPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5TbyB5b3UgbXVzdCBtZWFuIHRoZSBmdWxsIG1vZHVs
ZSBuYW1lIHdpbGwgYmUgdXNlZCBhdCBldmVyeSBub2RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7IC9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9p
ZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlW2lldGYtaW50ZXJmYWNlczpuYW1lPSdldGgwJ108bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4vbWFydGluPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k
eSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBIbW0sIHNvIHlvdSBtZWFuIGNoYW5nZSB0aGUgbGVhZiAmcXVvdDtzdHJlYW0teHBhdGgtZmls
dGVyJnF1b3Q7IHRvIHNheTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv
ZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBzZXQgb2YgbmFtZXNwYWNlIGRl
Y2xhcmF0aW9ucyBoYXMgb25lIG1lbWJlciBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+ZWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlBTkcgbW9kdWxlIHN1cHBvcnRlZCBieSB0
aGUgc2VydmVyLiZuYnNwOyBUaGlzIG1lbWJlciBtYXBzPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmcm9tIHRoZSBZQU5HIG1vZHVsZSBu
YW1lIHRvIHRoZSBZQU5HIG1vZHVsZSBuYW1lc3BhY2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7VGhpcyBtZWFucyB0aGF0IGluIHRoZSBYUGF0aCBleHByZXNzaW9uLCB0aGUgbW9kdWxlPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm5hbWU8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz
ZXJ2ZXMgYXMgdGhlIHByZWZpeC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi4uIGFuZCB0aGVuIGFsc28gZ2l2ZSBh
biBleGFtcGxlIG9mIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBpcyBwcm9iYWJseSB3aGF0IHdlIG5l
ZWQgdG8gZG8gaW4gYWxsIHBsYWNlcyB3aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij55YW5nOnhwYXRoMS4wPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgdXNlZCwgZ29pbmcgZm9yd2FyZC4mbmJzcDsgTWF5
YmUgZXZlbiBkZWZpbmUgYSBuZXcgdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgeWFuZzp4cGF0aDEuMC0yIChuYW1lPykgd2l0aCB0aGUgc2V0IG9mIG5hbWVz
cGFjZSBkZWNsYXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGJ1aWx0LWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+V2Ugc2hvdWxkIGF2b2lkIG1ha2luZyBvZmYtdGhlLXNoZWxmIGltcGxl
bWVudGF0aW9ucyBvZiBzdGFuZGFyZHMgbGlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5YUGF0aCB1bnVz
YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QXQgdGhlIHZlcnkgbGVhc3QgdGhpcyBzaG91bGQgYmUg
b25seSBhdmFpbGFibGUgaWYgdGhlIHNlcnZlciBzdXBwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5p
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij4od2l0aCBhIGNhcGFiaWxpdHkgVVJJKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZsdDtSUiZndDsgU28gd2UgbmVlZCBhbiB1cGRhdGUg
dG8gUkZDNzk1MT88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlc2hhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL21hcnRpbjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IExhZGE8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k
eSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IEhvdyBpcyB0aGlzIHN1cHBvc2VkIHRv
IHdvcmsgd2l0aCBKU09OPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
Z3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
Jmd0OyAvbWFydGluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
Z3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IG5ldG1vZCBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn
dDsgJmd0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bmV0bW9kQGlldGYub3JnPC9zcGFu
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgPC9zcGFuPjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAt
LTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBMYWRpc2xh
diBMaG90a2E8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg
SGVhZCwgQ1ouTklDIExhYnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZndDsgUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGll
dGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5uZXRt
b2RAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5uZXRtb2QgbWFpbGlu
ZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tYm9v
a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGll
dGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5uZXRt
b2RAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+bmV0
bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFpbHRv
Om5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2Q8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Li48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPi48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D4E6916FB17F45249A3D2990DF9D6FF8ciscocom_--


From nobody Thu Oct 11 11:14:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D725130EA7 for ; Thu, 11 Oct 2018 11:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level: 
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 zfsp5ZM7Cb17 for ; Thu, 11 Oct 2018 11:14:41 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83871200D7 for ; Thu, 11 Oct 2018 11:14:39 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 11 Oct 2018 21:14:37 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE1 (10.237.240.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 11 Oct 2018 21:14:35 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Thu, 11 Oct 2018 21:14:35 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Thu, 11 Oct 2018 21:14:35 +0300
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Thu, 11 Oct 2018 21:14:34 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mA/sV7i2zluqlEJ2KVv0Sr5lMLC2R7yZ/3MJja2D/V8=; b=CLm4lR2ZNptxHDxmG2UIeFpbzJ3spjNfzD9fQHl9QVcYPDsir0Zww5gAnTmOPcJkf2ipL8kAiby7PeJiTzTRuQWwRNOtnLOKHJM5blHkKjTbcysc98Vf9tq6+6xMX21zNTEpZn973eVMVEf/5zeVT97hu+zoPip4zTua6nTpeA8=
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com (10.168.22.154) by DB6PR06MB3894.eurprd06.prod.outlook.com (10.168.21.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.23; Thu, 11 Oct 2018 18:14:31 +0000
Received: from DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707]) by DB6PR06MB4085.eurprd06.prod.outlook.com ([fe80::e01f:4549:decc:b707%3]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 18:14:31 +0000
From: Michael Rehder 
To: Andy Bierman 
CC: Juergen Schoenwaelder , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAAKEBg
Date: Thu, 11 Oct 2018 18:14:31 +0000
Message-ID: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR06MB3894; 6:0Enh//t4IJXJnI1FhIBdBK9sue7mQiV7LsrxwA6lPpuOvhSqL3nuvduozLhWqc3baBOx/BoBzuietBheRcOIaWO0u2SRdmSP24D4n13Ezeyx+UxV/veLUlDgoj7FHW5Ve04u1LZ7oLdsyYWdV5ZZi/Mulr0w9uo/AtNyTqjoJkE9N+J1c4w6iokQejyfG4jaTtTlS8eFYnBzvMV8Gwg7/ZMwDM7AVKM4gmutWeoG5yNVGd6cEJ2BNq8BWI9cC2W3eLttUTIo2As+LunoXPYLq5i4hKynvEEKuJv4o4TuFhE8xkyBYCrk8bbspKGv1vMHA4bsIEnHOK27AlPnNJN2FeODrtL+og+z6a6fgUfCoRF32vacFAvO2RVO640/vxdUXZ7D3ql8pbnalh054RHVwhueGkyDM7xbYmErsnWWP3NgKvoOtgcadsSQ48hH/eMD/UR82kD2n3cU1sfX8PiO0w==; 5:ClD/+BBL1/x1Mx/YBKDvJGItwuPqzC/mYhQAxOaZGWHqNocRvq2QpKmgSzWCX4WPvjskqFA3Rl/tSO44gd9LaCNUQkpbjq5atq+6fEhEKOlPBbswSd7Elw5aKGmybxzx9cMdHRLdXbSEig9kipTjz7sjaE3jXGviH0/7L7sXPqA=; 7:QbHgFMAIUwMgRuYYNyBa8bkD5zaZrx9FgkqJO28DZSxIy8ZRTs+ws/sep0Lp/lrDO6zf/PX5AAZGk65SM4MC52AaaO8og0OwuKPcigbFbKwRSsc2ehub8SVDsE4QvFuJpWZZ799h+qxSfU75sKTf4OwDHgKfLYXsHOG2d3qB4vljEbSdMFyviGK0+LHxz8vk67LHGRug8pRbITiaQPfNSuepVBjM9WjJWvCqKOwVgamgeFT/tdFexrp6Su1lgkav
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: fb255749-7b1c-435d-6014-08d62fa56439
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6PR06MB3894; 
x-ms-traffictypediagnostic: DB6PR06MB3894:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166566539817055)(62221491112393)(131327999870524)(95692535739014)(17755550239193)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(106180626270275);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:DB6PR06MB3894; BCL:0; PCL:0; RULEID:; SRVR:DB6PR06MB3894; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(346002)(366004)(376002)(396003)(136003)(51444003)(13464003)(189003)(199004)(11346002)(105586002)(66066001)(53546011)(6506007)(25786009)(4326008)(97736004)(186003)(7696005)(6436002)(5660300001)(6916009)(54896002)(236005)(9686003)(54906003)(2906002)(229853002)(6306002)(55016002)(86362001)(486006)(71200400001)(26005)(99286004)(476003)(71190400001)(76176011)(446003)(316002)(93886005)(4744004)(74316002)(7736002)(68736007)(114624004)(6116002)(3846002)(790700001)(33656002)(256004)(14444005)(102836004)(478600001)(19609705001)(5250100002)(53936002)(6246003)(53946003)(72206003)(966005)(106356001)(14454004)(81166006)(8676002)(606006)(2900100001)(81156014)(8936002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR06MB3894; H:DB6PR06MB4085.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: V9+/S5nUowFeYDoZFJGWBshFAri15x6HIERh0lt6ropYqW1mzJXjo6beL3elVv4MSoz8FCK7ECLEKHEuTS2bKu3of6JHKDc0pbSTaUlgRxOKuGCL6D43Rl3ULbbf+rxn8rJ5lvzWizJZNygl4aA1HmgMTNYGLqTCyRVBQvZwSO42J7wqzaIgiQ9Cj8DIkn02ud3XOsDYt+2sU3iOf9pJXTTwBmL0tl1cUXjJfdr62aO2Uq0Byziidu/yIBtANf/UeKR30L83GBYCdJJFc40K5ENV1l752hY+Kdyw5mBwQ1nq5oyKTXQXdr8GnBdVANp/TwKysX3zMKy+yb9qwz2NUWISS7PGhN8hAHIUaUSGv0U=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR06MB408599478F23AD524F2840BCE7E10DB6PR06MB4085eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fb255749-7b1c-435d-6014-08d62fa56439
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 18:14:31.6157 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR06MB3894
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:14:45 -0000

--_000_DB6PR06MB408599478F23AD524F2840BCE7E10DB6PR06MB4085eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

VGhlcmUgaXMgbm8gc3BlY2lmaWMgdGV4dCAtIHRoZSB0ZXh0IGp1c3Qgc2F5cyBpdCBpcyDigJxj
b25kaXRpb25hbOKAnS4NCkhvd2V2ZXIgdGhlIGltcGxlbWVudGF0aW9uIGZvcmNlcyBpdCBvcHRp
b25hbDoNCg0KLSAgICAgICAgICBUaGUgUk5HIGZpbGUgbWFrZXMgaXQgb3B0aW9uYWwgKEnigJlt
IG5vdCBhY3R1YWxseSBydW5uaW5nIHRoaXMgZm9yIHZhcmlvdXMgcmVhc29ucyBzbyBJ4oCZbSBq
dXN0IGludGVycHJldGluZyB0aGUgZmlsZSBnZW5lcmF0ZWQg4oCTIG1heWJlIEkgbWlzdW5kZXJz
dGFuZCBSTkcpDQoNCi0gICAgICAgICAgU2NoZW1hdHJvbiBkb2VzbuKAmXQgY2hlY2sgZm9yIGl0
cyBleGlzdGVuY2UgKGxpa2UgaXQgZG9lcyBmb3IgYSBtYW5kYXRvcnkgY2hvaWNlIGNhc2UpDQoN
ClRoYW5rcw0KTWlrZQ0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jr
cy5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMSwgMjAxOCAyOjA2IFBNDQpUbzogTWlj
aGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+DQpDYzogSnVlcmdlbiBTY2hv
ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyBXYWxrZXIs
IEphc29uIChKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tKSA8SmFzb25fV2Fsa2VyMkBjb21jYXN0
LmNvbT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVt
ZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0
aGUgbWFuZGF0b3J5IG9iamVjdA0KDQoNCg0KT24gVGh1LCBPY3QgMTEsIDIwMTggYXQgMTE6MDAg
QU0sIE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPG1haWx0bzpNaWNo
YWVsLlJlaGRlckBhbWRvY3MuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHRoZSB3b3JkaW5nIGlzIHJl
bGV2YW50IC0gc29tZXRoaW5nIGNhbiBiZSBjb25kaXRpb25hbCBidXQgc3RpbGwgcmVxdWlyZWQu
DQpJdCBzaG91bGQgYmUgY2xhcmlmaWVkIHRoYXQgZWxlbWVudHMgYmVjb21lIGltcGxpY2l0bHkg
4oCcbWFuZGF0b3J5IGZhbHNl4oCdIHdoZW4gYSDigJx3aGVu4oCdIHN0YXRlbWVudCBpcyB1c2Vk
Lg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIGFuIGVuaGFuY2VtZW50IHRvIFlBTkcgdG8gY29udHJv
bCB0aGlzIGJlaGF2aW9yLCB0byBhbGxvdyB0aGUgbWFuZGF0b3J5IHN0YXR1cyB0byBiZSBlbmZv
cmNlZC4NClRoYXQgaXMsIHN1cHBvcnQgYWxzbyDigJxjb25kaXRpb25hbGx5IHJlcXVpcmVk4oCd
IGluc3RlYWQgb2Ygb25seSB0aGUgY3VycmVudCDigJxjb25kaXRpb25hbGx5IG9wdGlvbmFs4oCd
Lg0KDQoNCg0KICBsZWFmIGZvbyB7DQogICAgIHdoZW4gIi4uL3NvbWUtb3RoZXItbm9kZSA9IDUi
Ow0KICAgICB0eXBlIGludDMyOw0KICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiB9DQoNCg0KVGhpcyBs
ZWFmIGlzIG1hbmRhdG9yeSBpZiB0aGUgd2hlbi1leHByIGlzIHRydWUuDQpXaGVyZSBpcyB0aGUg
dGV4dCBpbiA3OTUwIHRoYXQgc2F5cyB0aGlzIG1hbmRhdG9yeSB0cnVlIGlzIGlnbm9yZWQgaWYg
d2hlbi1zdG10IGlzIHByZXNlbnQ/DQoNCg0KDQpUaGFua3MNCk1pa2UNCg0KQW5keQ0KDQoNCg0K
RnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5
QHl1bWF3b3Jrcy5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDI6NTIg
UE0NClRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTxtYWlsdG86
TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4+DQpDYzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq
LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+OyBXYWxrZXIsIEphc29uIChKYXNvbl9XYWxrZXIyQGNv
bWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPikgPEphc29uX1dhbGtl
cjJAY29tY2FzdC5jb208bWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+PjsgbmV0bW9k
QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0g
V0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QgZW5zdXJlIHBy
ZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQoNCg0KDQpPbiBXZWQsIE9jdCAxMCwgMjAx
OCBhdCAxMTo0NCBBTSwgTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb208
bWFpbHRvOk1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb20+PiB3cm90ZToNClN1cmUuDQoNCkkgdGhp
bmsgdGhlIFJGQyBpcyB1bmNsZWFyIHNpbmNlIGl0IHNlZW1zIHRoYXQgdGhlIHNlbWFudGljcyBh
cmUgY29uc2lzdGVudCBpbiB0aGUgYmFjay1lbmQgY2hlY2tzLg0KT25lIGNhbiByZWFkIHRoZSBS
RkMgYW5kIG5vdCBub3RpY2UgYnkgaXRzIGFic2VuY2UgdGhhdCB0aGUgd2hlbiBjbGF1c2UgZG9l
c24ndCByZXF1aXJlIGFueXRoaW5nIHRvIGJlIHByZXNlbnQuDQoNCiAgICAgVGhlICJ3aGVuIiBz
dGF0ZW1lbnQgbWFrZXMgaXRzIHBhcmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGNvbmRp
dGlvbmFsLg0KU2hvdWxkIGJlDQogICAgVGhlICJ3aGVuIiBzdGF0ZW1lbnQgbWFrZXMgaXRzIHBh
cmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGNvbmRpdGlvbmFsIGFuZCBvcHRpb25hbC4N
Cg0KVGhpcyBpcyBub3QgY29ycmVjdC4NCg0KU3RlcCAxKSBpZi1mZWF0dXJlIG1ha2VzIHRoZSBz
Y2hlbWEgbm9kZSBjb25kaXRpb25hbA0KDQpTdGVwIDIpIHdoZW4tc3RtdCBtYWtlcyBpbnN0YW5j
ZXMgb2YgdGhlIHNjaGVtYS1ub2RlIGNvbmRpdGlvbmFsDQoNClN0ZXAgMykgWUFORyB2YWxpZGF0
aW9uIGFwcGxpZXMgdG8gaW5zdGFuY2VzIG9mIGRhdGEgbm9kZXMgKG9yIHRoZSBZQU5HIGRlZmF1
bHQgdmFsdWUgaWYgYXBwbGljYWJsZSkNCg0KU3RlcCAyIGlzIG9ubHkgcmVsZXZhbnQgaWYgU3Rl
cCAxIGlzIHRydWUgb3Igbm9uLWV4aXN0ZW50DQpTdGVwIDMgaXMgb25seSByZWxldmFudCBpZiBT
dGVwIDIgaXMgdHJ1ZSBvciBub24tZXhpc3RlbnQNCg0KQW5keQ0KDQoNCkkgdGhpbmsgdGhlcmUg
c2hvdWxkIGJlIGEgbW9yZSBkZWZpbml0ZSBzdGF0ZW1lbnQgYWJvdXQgdGhpcyBvdmVycmlkaW5n
IGFueSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0YXRl
bWVudC4NCkxpa2UNCiAgICAgIkFueSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBwYXJlbnQgZGF0
YSBkZWZpbml0aW9uIHN0YXRlbWVudCAobWFuZGF0b3J5IHN0YXRlbWVudCwgbWluLWVsZW1lbnQg
c3RhdGVtZW50IGV0Yy4pIGlzIG92ZXJyaWRkZW4gYnkgdGhpcyBzdGF0ZW1lbnQgYW5kIG1hZGUg
bm9uLW1hbmRhdG9yeS4iDQoNClRoYXQgd291bGQgaGF2ZSBtYWRlIHRoZSBzaWRlLWVmZmVjdCBv
ZiAid2hlbiIgb24gb3RoZXIgZGVjbGFyYXRpb25zIGNsZWFyZXIuDQoNClRoYW5rcw0KbWlrZQ0K
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxk
ZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmou
c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT5dDQo+IFNlbnQ6IFdlZG5lc2RheSwg
T2N0b2JlciAxMCwgMjAxOCAyOjI1IFBNDQo+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5S
ZWhkZXJAQW1kb2NzLmNvbTxtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4+DQo+IENj
OiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5j
b20+PjsgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6
Pj47DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgV2Fsa2VyLCBK
YXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTxtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21j
YXN0LmNvbT4pDQo+IDxKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxr
ZXIyQGNvbWNhc3QuY29tPj4NCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50
IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0DQo+IGVuc3VyZSBwcmVzZW5jZSBvZiB0
aGUgbWFuZGF0b3J5IG9iamVjdA0KPg0KPiBNaWNoYWVsLA0KPg0KPiB3aGF0IG1hdHRlcnMgaGVy
ZSBpcyB3aGF0IHRoZSBZQU5HIHNwZWNpZmljYXRpb24gKFJGQyA3OTUwKSBzYXlzLiBJcyB0aGVy
ZSBhDQo+IHJlYXNvbiB0byBiZWxpZXZlIHRoZSBJUEFkZHJlc3NlcyBsaXN0IGluIHlvdXIgZXhh
bXBsZSBjYW4gYmUgYWJzZW50IG9yIGhhdmUgbm8NCj4gZWxlbWVudHMgYmFzZWQgb24gd2hhdCBS
RkMgNzk1MCBzYXlzPyBPciBkbyB3ZSB0YWxrIGFib3V0IGEgc2hvcnRjb21pbmcgb2YNCj4gUkZD
IDYxMTA/DQo+DQo+IC9qcw0KPg0KPiBPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCAwNjoxNzoyNlBN
ICswMDAwLCBNaWNoYWVsIFJlaGRlciB3cm90ZToNCj4gPiBJZiB0aGUgbGlzdCBoYXMgYSAid2hl
biIgY2xhdXNlIHRoZSBSTkcgZmlsZSBhY3R1YWxseSBwcm9kdWNlcyBhICJPbmVPck1vcmUiDQo+
IHdoaWNoIGhhcyBhIGNob2ljZSBvZiA8ZW1wdHk+IG9yIHRoZSBsaXN0IHNvIGl0IGFjdHVhbGx5
IGRvZXNuJ3QgZW5mb3JjZSB0aGUNCj4gcHJlc2VuY2UgYXQgbGVhc3Qgb25lIHJvdyBvZiB0aGUg
bGlzdCAodW5sZXNzIEknbSBtaXN0YWtlbiBpbiBteSByZWFkaW5nKS4NCj4gPiAgICAgICAgICAg
ICAgIDxvbmVPck1vcmU+DQo+ID4gICAgICAgICAgICAgICAgIDxjaG9pY2U+DQo+ID4gICAgICAg
ICAgICAgICAgICAgPGVtcHR5Lz4NCj4gPiAgICAgICAgICAgICAgICAgICA8ZWxlbWVudCBuYW1l
PSJJUEFkZHJlc3NlcyI+DQo+ID4gICAgICAgICAgICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJB
ZGRyZXNzIj4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgPHJlZiBuYW1lPSJ0eXBlc19fSVB2
NEFkZHJlc3MiLz4NCj4gPiAgICAgICAgICAgICAgICAgICAgIDwvZWxlbWVudD4NCj4gPiAgICAg
ICAgICAgICAgICAgICAgIDxlbXB0eS8+DQo+ID4gICAgICAgICAgICAgICAgICAgPC9lbGVtZW50
Pg0KPiA+ICAgICAgICAgICAgICAgICA8L2Nob2ljZT4NCj4gPiAgICAgICAgICAgICAgIDwvb25l
T3JNb3JlPg0KPiA+DQo+ID4gQSBsZWFmL2NvbnRhaW5lciB3b3VsZCBiZSBhIHNpbXBsZXIgZXhh
bXBsZSBidXQgd291bGQgcmVzdWx0IGluIHRoZSBzYW1lDQo+IGxhY2sgb2YgZW5mb3JjZW1lbnQg
b2YgdGhlIG1hbmRhdG9yeSBzdGF0dXMgb2YgYW4gZWxlbWVudCB3aXRoIGEgIndoZW4iDQo+IGNs
YXVzZS4NCj4gPg0KPiA+IFRoaXMgUk5HIHNlZW1zIGNvbnNpc3RlbnQgd2l0aCB0aGUgU2NoZW1h
dHJvbiBydWxlcyB0aGF0ICJ3aGVuIiBtYWtlcw0KPiBzb21ldGhpbmcgb3B0aW9uYWwuDQo+ID4N
Cj4gPg0KPiA+IEkgdGhpbmsgYSB3b3JrYXJvdW5kIHdvdWxkIGJlIGNob2ljZSB3aXRoIG1hbmRh
dG9yeSB0cnVlIGFuZCBhIHdoZW4gY2xhdXNlDQo+IG9uIHRoZSBjYXNlcy4gVGhpcyB3b3VsZCBl
bnN1cmUgdGhhdCBhdCBsZWFzdCBvbmUgY2FzZSBpcyBwcmVzZW50IHNpbmNlIHRoZQ0KPiBtYW5k
YXRvcnkgY2xhdXNlIGltcGxlbWVudHMgYSBTY2hlbWF0cm9uIGV4aXN0ZW5jZSBjb25zdHJhaW50
Lg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4gTWlrZQ0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gPiA+IEZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNv
bTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBPY3Rv
YmVyIDEwLCAyMDE4IDExOjMzIEFNDQo+ID4gPiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwu
UmVoZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+PjsgTGFk
aXNsYXYgTGhvdGthDQo+ID4gPiA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+
OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+IENjOiBXYWxr
ZXIsIEphc29uIChKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxrZXIy
QGNvbWNhc3QuY29tPikNCj4gPiA+IDxKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpK
YXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPj4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBX
SEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMNCj4gPiA+IGRvZXNuJ3QgZW5z
dXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4gPg0KPiA+ID4gSGkgTWlr
ZSwNCj4gPiA+DQo+ID4gPiBJIHRoaW5rIHRoYXQgdGhlIFlBTkcgYmVsb3cgYWxyZWFkeSBlbmZv
cmNlcyB3aGF0IHlvdSB3YW50LCBvcg0KPiA+ID4gb3RoZXJ3aXNlIEkgZG9uJ3QgZm9sbG93IHlv
dXIgaXNzdWUuDQo+ID4gPg0KPiA+ID4gVGhlIFlBTkcgYmVsb3cgaXMgdmFsaWQgaW4gdHdvIGNh
c2VzOg0KPiA+ID4NCj4gPiA+ICgxKSBBc3NpZ25tZW50TWVjaGFuaXNtID0gREhDUCwgYW5kIElQ
QWRkcmVzc2VzIGlzIG5vdCBwcmVzZW50IGluDQo+ID4gPiB0aGUgY29uZmlnIChkdWUgdG8gdGhl
IHdoZW4gc3RhdGVtZW50KS4NCj4gPiA+ICgyKSBBc3NpZ25tZW50TWVjaGFuaXNtID0gU3RhdGlj
LCBJUEFkZHJlc3NlcyBleGlzdHMgYW5kIGhhcyBhdA0KPiA+ID4gbGVhc3Qgb25lIGVsZW1lbnQg
KGR1ZSB0byBtaW4tZWxlbWVudHMgMSkuDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gUm9i
DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIDEwLzEwLzIwMTggMTY6MjMsIE1pY2hhZWwgUmVoZGVy
IHdyb3RlOg0KPiA+ID4gPiBDb250YWluZXIgImZvbyIgd291bGQgYmUgbWFuZGF0b3J5IGlmIG5v
dCBmb3IgdGhlICJ3aGVuIiBjaGlsZCBlbGVtZW50Lg0KPiA+ID4gPiBXaXRoIHRoZSAid2hlbiIg
Y2hpbGQgZWxlbWVudCwgdGhlIGxvZ2ljIGJlY29tZXMgImludmVydGVkIiBhbmQNCj4gPiA+ID4g
dGhlDQo+ID4gPiBjb25zdHJhaW50IGlzIGEgbmVnYXRpdmUgb25lIG9mICJkaXNhbGxvd2VkIHVu
ZGVyIGNlcnRhaW4gY29uZGl0aW9uIi4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIFVDIGlzIGZvciBl
bmZvcmNlbWVudCBpbiBSRVNUIEFQSSBwYXlsb2Fkcy4NCj4gPiA+ID4gRm9yIGEgcHJhY3RpY2Fs
IGV4YW1wbGU6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICBsZWFmIEFzc2lnbm1lbnRNZWNo
YW5pc20gew0KPiA+ID4gPiAgICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4gPiA+
ICAgICAgICAgICAgICAgIGVudW0gIkRIQ1AiOw0KPiA+ID4gPiAgICAgICAgICAgICAgICBlbnVt
ICJTdGF0aWMiOw0KPiA+ID4gPiAgICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAgICAgICAgICAg
bWFuZGF0b3J5IHRydWU7DQo+ID4gPiA+ICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVGhlIGFk
ZHJlc3MgYXNzaWdubWVudCBtZWNoYW5pc20uIjsNCj4gPiA+ID4gICAgICAgICAgICB9DQo+ID4g
PiA+ICAgICAgICAgICAgbGlzdCBJUEFkZHJlc3NlcyB7DQo+ID4gPiA+ICAgICAgICAgICAgICB3
aGVuICIuLi9Bc3NpZ25tZW50TWVjaGFuaXNtID0gJ1N0YXRpYyciOw0KPiA+ID4gPiAgICAgICAg
ICAgICAga2V5IEFkZHJlc3M7DQo+ID4gPiA+ICAgICAgICAgICAgICBtaW4tZWxlbWVudHMgMTsN
Cj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgIGxlYWYgQWRkcmVzcyB7DQo+ID4gPiA+ICAg
ICAgICAgICAgICAgIHR5cGUgY2FwaXQ6SVB2NEFkZHJlc3M7DQo+ID4gPiA+ICAgICAgICAgICAg
ICAgIGRlc2NyaXB0aW9uICJBbiBpcHY0IGFkZHJlc3MuIjsNCj4gPiA+ID4gICAgICAgICAgICAg
IH0NCj4gPiA+ID4gICAgICAgICAgICAgfQ0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBpcyBubyB3
YXkgaW4gdGhlIElQQWRkcmVzc2VzIGxpc3QgdG8gZW5mb3JjZSB0aGF0IHRoZXJlIGlzDQo+ID4g
PiA+IGF0IGxlYXN0IG9uZSBJUA0KPiA+ID4gQWRkcmVzcyB3aGVuIHRoZSBhc3NpZ25tZW50IG1l
dGhvZCBpcyAiU3RhdGljIi4NCj4gPiA+ID4gT25lIGNvdWxkIHB1dCBhICJtdXN0IiBvbiAiQXNz
aWdubWVudE1lY2hhbmlzbSIgdG8gZW5zdXJlIGF0IGxlYXN0DQo+ID4gPiA+IG9uZQ0KPiA+ID4g
ZWxlbWVudCBvZiB0aGUgSVBBZGRyZXNzZXMgbGlzdCB3aGVuICJTdGF0aWMiLCBidXQgSSBkb24n
dCBzZWUgdGhpcw0KPiA+ID4gYXMgYSBnb29kIHNjaGVtYSBkZXNpZ24sIHRvIGhhdmUgdGhlIGNv
bnRyb2xsaW5nIGF0dHJpYnV0ZSBjaGVjayBjb250cm9sbGVkDQo+IGF0dHJpYnV0ZXMuDQo+ID4g
PiA+DQo+ID4gPiA+IEkgYXBwcmVjaWF0ZSB0aGF0IHRoaXMgc2VtYW50aWMgY2FuJ3QgYmUgY2hh
bmdlZCBpbiBZQU5HIGF0IHRoaXMgcG9pbnQuDQo+ID4gPiA+IENvdWxkIHRoZSAid2hlbiIgc3Rh
dGVtZW50IGhhdmUgYSBtb2RpZnlpbmcgY2hpbGQgZWxlbWVudCB0byBzdGF0ZQ0KPiA+ID4gPiB0
aGF0IHRoZQ0KPiA+ID4gbWFuZGF0b3J5IHN0YXR1cyBvZiB0aGUgZWxlbWVudCBpcyB0byBiZSBl
bmZvcmNlZD8NCj4gPiA+ID4gTGlrZQ0KPiA+ID4gPiAgICAgIGNvbnRhaW5lciBmb28gew0KPiA+
ID4gPiAgICAgICAgd2hlbiAiY29uZGl0aW9uIiB7DQo+ID4gPiA+ICAgICAgICAgICAgZW5mb3Jj
ZS1tYW5kYXRvcnktc3RhdHVzOw0KPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPg0KPiA+ID4gPiBU
aGVyZSBpcyBhbHJlYWR5IGJhY2stZW5kIGZvciBleGlzdGVudGlhbCBjaGVja3MgZm9yIG1hbmRh
dG9yeQ0KPiA+ID4gPiBjaG9pY2Ugc28gdGhpcw0KPiA+ID4gc2VlbXMgcmVhc29uYWJseSBjb25z
aXN0ZW50IHRvIG1lLg0KPiA+ID4gPiBJIGFwcHJlY2lhdGUgdGhlcmUgYXJlIGV4aXN0aW5nIGlz
c3VlcyBmb3IgIndoZW4iIGJ1dCBJIGRvbid0IHNlZQ0KPiA+ID4gPiB3aHkgdGhpcw0KPiA+ID4g
d291bGQgbWFrZSB0aGluZ3MgYW55IHdvcnNlLg0KPiA+ID4gPiBJbiBmYWN0IGJ5IHByb21vdGlu
ZyBhIGJldHRlciBkZXBlbmRlbmN5ICJkaXJlY3Rpb24iIGJldHdlZW4NCj4gPiA+ID4gc2NoZW1h
DQo+ID4gPiBlbGVtZW50cywgIHRoaW5rIGl0IGNvdWxkIHNpbXBsaWZ5IHRoaW5ncyAoc28gSSBu
YWl2ZWx5IHRoaW5rIDopICkuDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcw0KPiA+ID4gPiBNaWtl
DQo+ID4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPj4gRnJvbTogTGFk
aXNsYXYgTGhvdGthIFttYWlsdG86bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej5d
DQo+ID4gPiA+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMTA6MjggQU0NCj4g
PiA+ID4+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTxtYWls
dG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l
dG1vZEBpZXRmLm9yZz4NCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRl
bWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMNCj4gPiA+ID4+IGRvZXNuJ3QgZW5zdXJlIHBy
ZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4gPiA+Pg0KPiA+ID4gPj4gTWljaGFl
bCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVy
QEFtZG9jcy5jb20+PiB3cml0ZXM6DQo+ID4gPiA+Pg0KPiA+ID4gPj4+IEkgaGF2ZSBhIHF1ZXN0
aW9uIGFib3V0IOKAnHdoZW7igJ0gYW5kIG1hbmRhdG9yeSBvYmplY3RzLg0KPiA+ID4gPj4+DQo+
ID4gPiA+Pj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgaW1wbGVtZW50ZWQgc2VtYW50aWNzIG9m
IOKAnHdoZW7igJ0gYXJlDQo+ID4gPiA+Pj4gcmVhbGx5DQo+ID4gPiA+PiDigJxvcHRpb25hbCB3
aGVu4oCdLCBpbiB0aGF0IHRoZSBlbmNsb3Npbmcgb2JqZWN0IGNhbiBiZSBhYnNlbnQgZXZlbg0K
PiA+ID4gPj4gdGhvdWdoIGl0IGlzIG1hbmRhdG9yeSBhbmQgdGhlIOKAnHdoZW7igJ0gY2xhdXNl
IGhvbGRzIHRydWUuDQo+ID4gPiA+Pj4gVGhlIFJGQyBjb3VsZCBiZSBjbGVhcmVyIGFib3V0IHRo
aXMuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBFeGFtcGxlDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAg
ICAgbGVhZiBjb2xvciB7DQo+ID4gPiA+Pj4gICAgICAgZW51bWVyYXRpb24gIHsNCj4gPiA+ID4+
PiAgICAgICAgICBlbnVtIOKAnGJsdWXigJ07DQo+ID4gPiA+Pj4gICAgICAgICAgZW51bSDigJxi
bGFja+KAnTsNCj4gPiA+ID4+PiAgICAgICB9DQo+ID4gPiA+Pj4gICAgICAgbWFuZGF0b3J5IHRy
dWU7DQo+ID4gPiA+Pj4gICAgIH0NCj4gPiA+ID4+PiAgICAgY29udGFpbmVyIGZvbyB7DQo+ID4g
PiA+Pj4gICAgICAgIHdoZW4gLi4vY29sb3IgPSDigJhibHVl4oCZOw0KPiA+ID4gPj4+ICAgICAg
ICBldGMuDQo+ID4gPiA+Pj4gICAgIH0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IOKAnGZvb+KAnSBp
cyBvcHRpb25hbCBkdWUgdG8gdGhlIHByZXNlbmNlIG9mIHRoZSDigJx3aGVu4oCdIHN0YXRlbWVu
dA0KPiA+ID4gPj4+IGV2ZW4gdGhvdWdoIHRoZSBvYmplY3QgaXMgbWFuZGF0b3J5IChzYW1lIGlz
IHRydWUgZm9yIG1hbmRhdG9yeQ0KPiA+ID4gPj4+IGxlYWYsDQo+ID4gPiA+Pj4gbWluLWVsZW1l
bnRzPTEgbGlzdCBldGMuKS4NCj4gPiA+ID4+IE1heWJlIHlvdSBpbnRlbmRlZCB0byBoYXZlLCBl
LmcuLCBhICJtYW5kYXRvcnkgdHJ1ZSIgbGVhZiBpbnNpZGUNCj4gPiA+ID4+ICJjb250YWluZXIg
Zm9vIj8NCj4gPiA+ID4+DQo+ID4gPiA+Pj4gVGhpcyBpcyBjb25zaWRlcmVkIHZhbGlkIFhNTCBm
b3IgdGhlIGFib3ZlDQo+ID4gPiA+Pj4gICAgICA8Y29sb3I+Ymx1ZTwvY29sb3I+DQo+ID4gPiA+
PiBZZXMsIGl0IGlzLCB1bmRlciBjdXJyZW50IFlBTkcgcnVsZXMsIG5vIG1hdHRlciB3aGF0ICJl
dGMuIg0KPiA+ID4gPj4gc3RhbmRzIGZvci4gTm90ZSB0aGF0IGV2YWx1YXRpb24gb2YgdGhlIFhQ
YXRoIGV4cHJlc3Npb24gaW4gdGhpcw0KPiA+ID4gPj4gY2FzZSAod2l0aCAiZm9vIiBtaXNzaW5n
KSByZXF1aXJlcyB0aGUgcGVjdWxpYXIgcHJvY2VkdXJlIG9mIHNlYy4gNy4yMS41DQo+IGluIFJG
QyA3OTUwLg0KPiA+ID4gPj4NCj4gPiA+ID4+PiBJbiBteSB2aWV3IHRoaXMgbWFrZXMgY29uZGl0
aW9uYWxseSB2YXJpYW50IHNjaGVtYXMg4oCcbG9vc2XigJ0gaW4NCj4gPiA+ID4+PiB0aGVpciBl
bmZvcmNlbWVudCAoc29tZSBzY2VuYXJpb3MgY2FuIHVzZSBjaG9pY2UgYnV0IGl0IGRvZXNu4oCZ
dA0KPiA+ID4gPj4+IGNvdmVyIGV2ZXJ5dGhpbmcpLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSSB0
aGluayB0aGF0IG1hbmRhdG9yeSBzaG91bGQgYmUgcmVzcGVjdGVkIGZvciB0aGUgZW5jbG9zaW5n
DQo+ID4gPiA+Pj4gb2JqZWN0cyBvZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50LiAgVGhhdCBpcywg
YSBtYW5kYXRvcnkgb2JqZWN0IG11c3QNCj4gPiA+ID4+PiBiZSBwcmVzZW50IHdoZW4gaXRzIOKA
nHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUgYW5kIGEgU2NoZW1hdHJvbg0KPiA+ID4gPj4+IHN0
YXRlbWVudCBzaG91bGQgZW5mb3JjZSB0aGF0Lg0KPiA+ID4gPj4gSW4gZmFjdCwgdGhpcyBpcyBv
bmUgY2FzZSB3aGVyZSB0aGUgRFNETCBtYXBwaW5nIChSRkMgNjExMCkNCj4gPiA+ID4+IGRldmlh
dGVzIGZyb20gWUFORyAxLjAuIE5vZGVzIHRoYXQgbWFuZGF0b3J5IGFyZW4ndCBlbmNsb3NlZCBp
bg0KPiA+ID4gPj4gdGhlIFJFTEFYIE5HIDxvcHRpb25hbD4gcGF0dGVybiwgYW5kIGFyZSB0aGVu
IHJlcXVpcmVkIG5vIG1hdHRlciB3aGF0DQo+IGFueSAid2hlbiINCj4gPiA+ID4+IHN0YXRlbWVu
dHMgc2F5IChiZWNhdXNlIFJFTEFYIE5HIHZhbGlkYXRpb24gY29tZXMgYmVmb3JlDQo+IFNjaGVt
YXRyb24pLg0KPiA+ID4gPj4NCj4gPiA+ID4+PiBXaGF0IGlzIHRoZSByYXRpb25hbGUgYmVoaW5k
IHRoZSBjdXJyZW50IFlBTkcgcnVsZXMgYmVoYXZpb3IsDQo+ID4gPiA+Pj4gdGhhdCB0aGUg4oCc
d2hlbuKAnSBTY2hlbWF0cm9uIG1hcHBpbmcgZG9lc27igJl0IGNoZWNrIGZvciBwcmVzZW5jZSBv
Zg0KPiA+ID4gPj4+IHRoZSBlbmNsb3NpbmcgbWFuZGF0b3J5IG9iamVjdD8NCj4gPiA+ID4+IEZX
SVcsIEkgaGF2ZSBiZWVuIHJlcGVhdGVkbHkgcHJvdGVzdGluZyBhZ2FpbnN0IHRoaXMgYmVoYXZp
b3VyDQo+ID4gPiA+PiBidXQgd2l0aG91dCBtdWNoIGx1Y2suIFNlZSBmb3IgZXhhbXBsZQ0KPiA+
ID4gPj4NCj4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0
bW9kL2N1cnJlbnQvbXNnMTQwMTIuaHRtDQo+ID4gPiA+PiBsDQo+ID4gPiA+Pg0KPiA+ID4gPj4g
QXMgYSByZXN1bHQsICJ3aGVuIiBpcyB0aGUgdHJpY2tpZXN0IGZlYXR1cmUgaW4gWUFORyBieSBm
YXIuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gTGFkYQ0KPiA+ID4gPj4NCj4gPiA+ID4+PiB0aGFua3MN
Cj4gPiA+ID4+PiBNaWtlIFJlaGRlcg0KPiA+ID4gPj4gLS0NCj4gPiA+ID4+IExhZGlzbGF2IExo
b3RrYQ0KPiA+ID4gPj4gSGVhZCwgQ1ouTklDIExhYnMNCj4gPiA+ID4+IFBHUCBLZXkgSUQ6IDB4
QjhGOTJCMDhBOUY3NkM2Nw0KPiA+ID4gPiDigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMg
YmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLA0KPiA+ID4gPiBjbG91ZC1iYXNlZA0K
PiA+ID4gc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2Vk
IGFuZCBzdG9yZWQgdXNpbmcNCj4gPiA+IHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBi
eSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Ygc3VjaA0KPiA+ID4gc3lzdGVtIG9uIGEgbGltaXRl
ZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MNCj4gPiA+IGV2aWRlbmNl
cyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNz
aW5nLA0KPiBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4gPiA+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4g
PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4g
PiDigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwg
d29ybGR3aWRlLCBjbG91ZC1iYXNlZA0KPiBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRv
Y3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoDQo+IHN5c3RlbSBhbmQg
YXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9u
IGEgbGltaXRlZA0KPiBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZp
ZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9mDQo+IHN1Y2ggc3lzdGVtIGFuZCBzdWNo
IHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS4NCj4gPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QN
Cj4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPiAtLQ0KPiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K
PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55PGh0dHBzOi8vbWFwcy5nb29nbGUuY29tLz9xPUNhbXB1cytSaW5nKzEr
JTdDKzI4NzU5K0JyZW1lbislN0MrR2VybWFueSZlbnRyeT1nbWFpbCZzb3VyY2U9Zz4NCj4gRmF4
OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNp
dHkuZGUvPg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQt
cGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQgdG8g
QW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3VjaCBzeXN0ZW0gYW5k
IGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBv
biBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2aWRl
bmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9j
ZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu
b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KDQoNCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNl
ZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55IGVt
YWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1
Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Yg
c3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRv
IEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0g
YW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLg0KDQrigJxBbWRvY3Pi
gJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBj
bG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9j
ZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkg
dGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4g
WW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0
byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5k
IGFjY2Vzc+KAnS4K

--_000_DB6PR06MB408599478F23AD524F2840BCE7E10DB6PR06MB4085eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp
bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6
MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv
TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47
DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou
NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47
DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7
cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7
bXNvLWxpc3QtaWQ6MTkyODk5ODY4ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz
dC10ZW1wbGF0ZS1pZHM6MzI3NDE4IC00NzQ0NjE3OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4
OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs
MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZh
bWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs
OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s
DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl
ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i
ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv
aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgbm8gc3BlY2lmaWMgdGV4dCAtIHRoZSB0ZXh0
IGp1c3Qgc2F5cyBpdCBpcyDigJxjb25kaXRpb25hbOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG93
ZXZlciB0aGUgaW1wbGVtZW50YXRpb24gZm9yY2VzIGl0IG9wdGlvbmFsOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6
LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+
LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw
YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PlRoZSBSTkcgZmlsZSBtYWtlcyBpdCBvcHRpb25hbCAoSeKAmW0gbm90IGFjdHVhbGx5IHJ1bm5p
bmcgdGhpcyBmb3IgdmFyaW91cyByZWFzb25zIHNvIEnigJltIGp1c3QgaW50ZXJwcmV0aW5nIHRo
ZSBmaWxlIGdlbmVyYXRlZCDigJMgbWF5YmUgSSBtaXN1bmRlcnN0YW5kDQogUk5HKTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p
bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3Rz
XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln
bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlNjaGVtYXRyb24gZG9lc27igJl0IGNoZWNrIGZvciBpdHMgZXhpc3RlbmNlIChsaWtl
IGl0IGRvZXMgZm9yIGEgbWFuZGF0b3J5IGNob2ljZSBjYXNlKTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pa2U8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMTEsIDIwMTggMjowNiBQTTxicj4NCjxiPlRv
OjwvYj4gTWljaGFlbCBSZWhkZXIgJmx0O01pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20mZ3Q7PGJy
Pg0KPGI+Q2M6PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBq
YWNvYnMtdW5pdmVyc2l0eS5kZSZndDs7IFdhbGtlciwgSmFzb24gKEphc29uX1dhbGtlcjJAY29t
Y2FzdC5jb20pICZsdDtKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tJmd0OzsgbmV0bW9kQGlldGYu
b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRo
aW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRh
dG9yeSBvYmplY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
VGh1LCBPY3QgMTEsIDIwMTggYXQgMTE6MDAgQU0sIE1pY2hhZWwgUmVoZGVyICZsdDs8YSBocmVm
PSJtYWlsdG86TWljaGFlbC5SZWhkZXJAYW1kb2NzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh
ZWwuUmVoZGVyQGFtZG9jcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J
IHRoaW5rIHRoZSB3b3JkaW5nIGlzIHJlbGV2YW50IC0gc29tZXRoaW5nIGNhbiBiZSBjb25kaXRp
b25hbCBidXQgc3RpbGwgcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgc2hvdWxkIGJl
IGNsYXJpZmllZCB0aGF0IGVsZW1lbnRzIGJlY29tZSBpbXBsaWNpdGx5IOKAnG1hbmRhdG9yeSBm
YWxzZeKAnSB3aGVuIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQgaXMNCiB1c2VkLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgbGlrZSB0byBzZWUg
YW4gZW5oYW5jZW1lbnQgdG8gWUFORyB0byBjb250cm9sIHRoaXMgYmVoYXZpb3IsIHRvIGFsbG93
IHRoZSBtYW5kYXRvcnkgc3RhdHVzDQogdG8gYmUgZW5mb3JjZWQuPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+VGhhdCBpcywgc3VwcG9ydCBhbHNvIOKAnGNvbmRpdGlvbmFsbHkgcmVxdWlyZWTigJ0gaW5z
dGVhZCBvZiBvbmx5IHRoZSBjdXJyZW50IOKAnGNvbmRpdGlvbmFsbHkgb3B0aW9uYWzigJ0uPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7IGxlYWYgZm9vIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7d2hlbiAmcXVvdDsuLi9zb21lLW90aGVyLW5v
ZGUgPSA1JnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGludDMyOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtt
YW5kYXRvcnkgdHJ1ZTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGxlYWYgaXMgbWFuZGF0b3J5IGlmIHRoZSB3aGVuLWV4cHIg
aXMgdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPldoZXJlIGlzIHRoZSB0ZXh0IGluIDc5NTAgdGhhdCBzYXlzIHRoaXMgbWFuZGF0b3J5IHRy
dWUgaXMgaWdub3JlZCBpZiB3aGVuLXN0bXQgaXMgcHJlc2VudD88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pa2U8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJp
ZXJtYW4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5keUB5dW1hd29ya3MuY29tPC9zcGFu
PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9j
dG9iZXIgMTAsIDIwMTggMjo1MiBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBSZWhkZXIgJmx0
Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5NaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPC9zcGFuPjwvYT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PC9z
cGFuPjxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KIFdhbGtlciwg
SmFzb24gKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNv
bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4pICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv
Okphc29uX1dhbGtlcjJAY29tY2FzdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPkphc29uX1dhbGtlcjJAY29tY2FzdC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVu
dCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhl
IG1hbmRhdG9yeSBvYmplY3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5PbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCAxMTo0NCBBTSwgTWljaGFlbCBSZWhk
ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tIiB0YXJnZXQ9
Il9ibGFuayI+TWljaGFlbC5SZWhkZXJAYW1kb2NzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPlN1cmUuPGJyPg0KPGJyPg0KSSB0aGluayB0aGUgUkZDIGlzIHVu
Y2xlYXIgc2luY2UgaXQgc2VlbXMgdGhhdCB0aGUgc2VtYW50aWNzIGFyZSBjb25zaXN0ZW50IGlu
IHRoZSBiYWNrLWVuZCBjaGVja3MuPGJyPg0KT25lIGNhbiByZWFkIHRoZSBSRkMgYW5kIG5vdCBu
b3RpY2UgYnkgaXRzIGFic2VuY2UgdGhhdCB0aGUgd2hlbiBjbGF1c2UgZG9lc24ndCByZXF1aXJl
IGFueXRoaW5nIHRvIGJlIHByZXNlbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtU
aGUgJnF1b3Q7d2hlbiZxdW90OyBzdGF0ZW1lbnQgbWFrZXMgaXRzIHBhcmVudCBkYXRhIGRlZmlu
aXRpb24gc3RhdGVtZW50IGNvbmRpdGlvbmFsLjxicj4NClNob3VsZCBiZTxicj4NCiZuYnNwOyAm
bmJzcDsgVGhlICZxdW90O3doZW4mcXVvdDsgc3RhdGVtZW50IG1ha2VzIGl0cyBwYXJlbnQgZGF0
YSBkZWZpbml0aW9uIHN0YXRlbWVudCBjb25kaXRpb25hbCBhbmQgb3B0aW9uYWwuPG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
VGhpcyBpcyBub3QgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0ZXAgMSkgaWYtZmVhdHVyZSBtYWtlcyB0aGUgc2NoZW1h
IG5vZGUgY29uZGl0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPlN0ZXAgMikgd2hlbi1zdG10IG1ha2VzIGluc3RhbmNlcyBvZiB0
aGUgc2NoZW1hLW5vZGUgY29uZGl0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0ZXAgMykgWUFORyB2YWxpZGF0aW9uIGFwcGxp
ZXMgdG8gaW5zdGFuY2VzIG9mIGRhdGEgbm9kZXMgKG9yIHRoZSBZQU5HIGRlZmF1bHQgdmFsdWUg
aWYgYXBwbGljYWJsZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPlN0ZXAgMiBpcyBvbmx5IHJlbGV2YW50IGlmIFN0ZXAgMSBpcyB0cnVl
IG9yIG5vbi1leGlzdGVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5TdGVwIDMgaXMgb25seSByZWxldmFudCBpZiBTdGVwIDIgaXMgdHJ1ZSBv
ciBub24tZXhpc3RlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+SSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBtb3JlIGRlZmluaXRlIHN0YXRl
bWVudCBhYm91dCB0aGlzIG92ZXJyaWRpbmcgYW55IG1hbmRhdG9yeSBzdGF0dXMgb2YgdGhlIHBh
cmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50Ljxicj4NCkxpa2U8YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwOyZxdW90O0FueSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBwYXJlbnQgZGF0YSBk
ZWZpbml0aW9uIHN0YXRlbWVudCAobWFuZGF0b3J5IHN0YXRlbWVudCwgbWluLWVsZW1lbnQgc3Rh
dGVtZW50IGV0Yy4pIGlzIG92ZXJyaWRkZW4gYnkgdGhpcyBzdGF0ZW1lbnQgYW5kIG1hZGUgbm9u
LW1hbmRhdG9yeS4mcXVvdDs8YnI+DQo8YnI+DQpUaGF0IHdvdWxkIGhhdmUgbWFkZSB0aGUgc2lk
ZS1lZmZlY3Qgb2YgJnF1b3Q7d2hlbiZxdW90OyBvbiBvdGhlciBkZWNsYXJhdGlvbnMgY2xlYXJl
ci48YnI+DQo8YnI+DQpUaGFua3M8YnI+DQptaWtlPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86
PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFy
Z2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT5dPGJy
Pg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMjoyNSBQTTxicj4NCiZn
dDsgVG86IE1pY2hhZWwgUmVoZGVyICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5SZWhkZXJA
QW1kb2NzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208L2E+
Jmd0Ozxicj4NCiZndDsgQ2M6IFJvYmVydCBXaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyd2ls
dG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs7
IExhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdl
dD0iX2JsYW5rIj5saG90a2FAbmljLmN6PC9hPiZndDs7PGJyPg0KJmd0OyA8YSBocmVmPSJtYWls
dG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjsg
V2Fsa2VyLCBKYXNvbiAoPGEgaHJlZj0ibWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20i
IHRhcmdldD0iX2JsYW5rIj5KYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPC9hPik8YnI+DQomZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPkphc29uX1dhbGtlcjJAY29tY2FzdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVj
dDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBk
b2Vzbid0PGJyPg0KJmd0OyBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3Q8
YnI+DQomZ3Q7IDxicj4NCiZndDsgTWljaGFlbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgd2hhdCBt
YXR0ZXJzIGhlcmUgaXMgd2hhdCB0aGUgWUFORyBzcGVjaWZpY2F0aW9uIChSRkMgNzk1MCkgc2F5
cy4gSXMgdGhlcmUgYTxicj4NCiZndDsgcmVhc29uIHRvIGJlbGlldmUgdGhlIElQQWRkcmVzc2Vz
IGxpc3QgaW4geW91ciBleGFtcGxlIGNhbiBiZSBhYnNlbnQgb3IgaGF2ZSBubzxicj4NCiZndDsg
ZWxlbWVudHMgYmFzZWQgb24gd2hhdCBSRkMgNzk1MCBzYXlzPyBPciBkbyB3ZSB0YWxrIGFib3V0
IGEgc2hvcnRjb21pbmcgb2Y8YnI+DQomZ3Q7IFJGQyA2MTEwPzxicj4NCiZndDsgPGJyPg0KJmd0
OyAvanM8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBPY3QgMTAsIDIwMTggYXQgMDY6MTc6
MjZQTSAmIzQzOzAwMDAsIE1pY2hhZWwgUmVoZGVyIHdyb3RlOjxicj4NCiZndDsgJmd0OyBJZiB0
aGUgbGlzdCBoYXMgYSAmcXVvdDt3aGVuJnF1b3Q7IGNsYXVzZSB0aGUgUk5HIGZpbGUgYWN0dWFs
bHkgcHJvZHVjZXMgYSAmcXVvdDtPbmVPck1vcmUmcXVvdDs8YnI+DQomZ3Q7IHdoaWNoIGhhcyBh
IGNob2ljZSBvZiAmbHQ7ZW1wdHkmZ3Q7IG9yIHRoZSBsaXN0IHNvIGl0IGFjdHVhbGx5IGRvZXNu
J3QgZW5mb3JjZSB0aGU8YnI+DQomZ3Q7IHByZXNlbmNlIGF0IGxlYXN0IG9uZSByb3cgb2YgdGhl
IGxpc3QgKHVubGVzcyBJJ20gbWlzdGFrZW4gaW4gbXkgcmVhZGluZykuPGJyPg0KJmd0OyAmZ3Q7
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs
dDtvbmVPck1vcmUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y2hvaWNlJmd0Ozxicj4NCiZn
dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlbXB0eS8mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7Jmx0O2VsZW1lbnQgbmFtZT0mcXVvdDtJUEFkZHJlc3NlcyZxdW90OyZndDs8YnI+DQomZ3Q7
ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VsZW1lbnQgbmFtZT0mcXVvdDtBZGRyZXNzJnF1
b3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3JlZiBu
YW1lPSZxdW90O3R5cGVzX19JUHY0QWRkcmVzcyZxdW90Oy8mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZsdDsvZWxlbWVudCZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7Jmx0O2VtcHR5LyZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2Vs
ZW1lbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2Nob2ljZSZndDs8YnI+DQomZ3Q7ICZn
dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
Jmx0Oy9vbmVPck1vcmUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgbGVhZi9j
b250YWluZXIgd291bGQgYmUgYSBzaW1wbGVyIGV4YW1wbGUgYnV0IHdvdWxkIHJlc3VsdCBpbiB0
aGUgc2FtZTxicj4NCiZndDsgbGFjayBvZiBlbmZvcmNlbWVudCBvZiB0aGUgbWFuZGF0b3J5IHN0
YXR1cyBvZiBhbiBlbGVtZW50IHdpdGggYSAmcXVvdDt3aGVuJnF1b3Q7PGJyPg0KJmd0OyBjbGF1
c2UuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgUk5HIHNlZW1zIGNvbnNpc3Rl
bnQgd2l0aCB0aGUgU2NoZW1hdHJvbiBydWxlcyB0aGF0ICZxdW90O3doZW4mcXVvdDsgbWFrZXM8
YnI+DQomZ3Q7IHNvbWV0aGluZyBvcHRpb25hbC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgSSB0aGluayBhIHdvcmthcm91bmQgd291bGQgYmUgY2hvaWNlIHdp
dGggbWFuZGF0b3J5IHRydWUgYW5kIGEgd2hlbiBjbGF1c2U8YnI+DQomZ3Q7IG9uIHRoZSBjYXNl
cy4gVGhpcyB3b3VsZCBlbnN1cmUgdGhhdCBhdCBsZWFzdCBvbmUgY2FzZSBpcyBwcmVzZW50IHNp
bmNlIHRoZTxicj4NCiZndDsgbWFuZGF0b3J5IGNsYXVzZSBpbXBsZW1lbnRzIGEgU2NoZW1hdHJv
biBleGlzdGVuY2UgY29uc3RyYWludC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhh
bmtzPGJyPg0KJmd0OyAmZ3Q7IE1pa2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IFJvYmVydCBXaWx0b24gW21h
aWx0bzo8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5y
d2lsdG9uQGNpc2NvLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5
LCBPY3RvYmVyIDEwLCAyMDE4IDExOjMzIEFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVG86IE1pY2hh
ZWwgUmVoZGVyICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208L2E+Jmd0OzsgTGFkaXNs
YXYgTGhvdGthPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FA
bmljLmN6IiB0YXJnZXQ9Il9ibGFuayI+bGhvdGthQG5pYy5jejwvYT4mZ3Q7OyA8YSBocmVmPSJt
YWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpuZXRtb2RAaWV0Zi5vcmc8
L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6IFdhbGtlciwgSmFzb24gKDxhIGhyZWY9Im1haWx0
bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFzb25fV2Fsa2Vy
MkBjb21jYXN0LmNvbTwvYT4pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0
bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFzb25fV2Fsa2Vy
MkBjb21jYXN0LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtu
ZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0czxicj4NCiZndDsg
Jmd0OyAmZ3Q7IGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0
PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBNaWtlLDxicj4NCiZn
dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSB0aGluayB0aGF0IHRoZSBZQU5HIGJl
bG93IGFscmVhZHkgZW5mb3JjZXMgd2hhdCB5b3Ugd2FudCwgb3I8YnI+DQomZ3Q7ICZndDsgJmd0
OyBvdGhlcndpc2UgSSBkb24ndCBmb2xsb3cgeW91ciBpc3N1ZS48YnI+DQomZ3Q7ICZndDsgJmd0
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBZQU5HIGJlbG93IGlzIHZhbGlkIGluIHR3byBjYXNl
czo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICgxKSBBc3NpZ25tZW50
TWVjaGFuaXNtID0gREhDUCwgYW5kIElQQWRkcmVzc2VzIGlzIG5vdCBwcmVzZW50IGluPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgdGhlIGNvbmZpZyAoZHVlIHRvIHRoZSB3aGVuIHN0YXRlbWVudCkuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgKDIpIEFzc2lnbm1lbnRNZWNoYW5pc20gPSBTdGF0aWMsIElQQWRk
cmVzc2VzIGV4aXN0cyBhbmQgaGFzIGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgbGVhc3Qgb25lIGVs
ZW1lbnQgKGR1ZSB0byBtaW4tZWxlbWVudHMgMSkuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUm9iPGJyPg0KJmd0OyAm
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDEwLzEw
LzIwMTggMTY6MjMsIE1pY2hhZWwgUmVoZGVyIHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgQ29udGFpbmVyICZxdW90O2ZvbyZxdW90OyB3b3VsZCBiZSBtYW5kYXRvcnkgaWYgbm90IGZv
ciB0aGUgJnF1b3Q7d2hlbiZxdW90OyBjaGlsZCBlbGVtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgV2l0aCB0aGUgJnF1b3Q7d2hlbiZxdW90OyBjaGlsZCBlbGVtZW50LCB0aGUgbG9naWMg
YmVjb21lcyAmcXVvdDtpbnZlcnRlZCZxdW90OyBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbnN0cmFpbnQgaXMgYSBuZWdhdGl2ZSBvbmUgb2Yg
JnF1b3Q7ZGlzYWxsb3dlZCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbiZxdW90Oy48YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgVUMgaXMgZm9yIGVu
Zm9yY2VtZW50IGluIFJFU1QgQVBJIHBheWxvYWRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Rm9yIGEgcHJhY3RpY2FsIGV4YW1wbGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O2xlYWYgQXNzaWdubWVudE1lY2hhbmlzbSB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIGVudW1lcmF0
aW9uIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtICZxdW90O0RIQ1AmcXVvdDs7PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgZW51bSAmcXVvdDtTdGF0aWMmcXVvdDs7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBtYW5kYXRvcnkgdHJ1ZTs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlc2Ny
aXB0aW9uICZxdW90O1RoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtLiZxdW90Ozs8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgfTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBsaXN0IElQQWRkcmVzc2VzIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdoZW4g
JnF1b3Q7Li4vQXNzaWdubWVudE1lY2hhbmlzbSA9ICdTdGF0aWMnJnF1b3Q7Ozxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsga2V5IEFkZHJlc3M7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtaW4tZWxlbWVudHMgMTs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIEFkZHJlc3Mgezxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHR5cGUgY2FwaXQ6SVB2NEFkZHJlc3M7PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7QW4gaXB2NCBhZGRyZXNzLiZxdW90Ozs8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIG5vIHdheSBpbiB0aGUgSVBBZGRyZXNzZXMgbGlz
dCB0byBlbmZvcmNlIHRoYXQgdGhlcmUgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGF0IGxl
YXN0IG9uZSBJUDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFkZHJlc3Mgd2hlbiB0aGUgYXNzaWdubWVu
dCBtZXRob2QgaXMgJnF1b3Q7U3RhdGljJnF1b3Q7Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
T25lIGNvdWxkIHB1dCBhICZxdW90O211c3QmcXVvdDsgb24gJnF1b3Q7QXNzaWdubWVudE1lY2hh
bmlzbSZxdW90OyB0byBlbnN1cmUgYXQgbGVhc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9u
ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGVsZW1lbnQgb2YgdGhlIElQQWRkcmVzc2VzIGxpc3Qgd2hl
biAmcXVvdDtTdGF0aWMmcXVvdDssIGJ1dCBJIGRvbid0IHNlZSB0aGlzPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgYXMgYSBnb29kIHNjaGVtYSBkZXNpZ24sIHRvIGhhdmUgdGhlIGNvbnRyb2xsaW5nIGF0
dHJpYnV0ZSBjaGVjayBjb250cm9sbGVkPGJyPg0KJmd0OyBhdHRyaWJ1dGVzLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgYXBwcmVjaWF0ZSB0aGF0
IHRoaXMgc2VtYW50aWMgY2FuJ3QgYmUgY2hhbmdlZCBpbiBZQU5HIGF0IHRoaXMgcG9pbnQuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDb3VsZCB0aGUgJnF1b3Q7d2hlbiZxdW90OyBzdGF0ZW1l
bnQgaGF2ZSBhIG1vZGlmeWluZyBjaGlsZCBlbGVtZW50IHRvIHN0YXRlPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyB0aGF0IHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG1hbmRhdG9yeSBzdGF0dXMg
b2YgdGhlIGVsZW1lbnQgaXMgdG8gYmUgZW5mb3JjZWQ/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyBMaWtlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRh
aW5lciBmb28gezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgd2hlbiAmcXVvdDtjb25kaXRpb24mcXVvdDsgezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbmZvcmNlLW1hbmRh
dG9yeS1zdGF0dXM7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgVGhlcmUgaXMgYWxyZWFkeSBiYWNrLWVuZCBmb3IgZXhpc3RlbnRpYWwgY2hlY2tzIGZvciBt
YW5kYXRvcnk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNob2ljZSBzbyB0aGlzPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgc2VlbXMgcmVhc29uYWJseSBjb25zaXN0ZW50IHRvIG1lLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgSSBhcHByZWNpYXRlIHRoZXJlIGFyZSBleGlzdGluZyBpc3N1ZXMgZm9y
ICZxdW90O3doZW4mcXVvdDsgYnV0IEkgZG9uJ3Qgc2VlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyB3aHkgdGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7IHdvdWxkIG1ha2UgdGhpbmdzIGFueSB3b3Jz
ZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluIGZhY3QgYnkgcHJvbW90aW5nIGEgYmV0dGVy
IGRlcGVuZGVuY3kgJnF1b3Q7ZGlyZWN0aW9uJnF1b3Q7IGJldHdlZW48YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IHNjaGVtYTxicj4NCiZndDsgJmd0OyAmZ3Q7IGVsZW1lbnRzLCZuYnNwOyB0aGlu
ayBpdCBjb3VsZCBzaW1wbGlmeSB0aGluZ3MgKHNvIEkgbmFpdmVseSB0aGluayA6KSApLjxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoYW5rczxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgTWlrZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgRnJv
bTogTGFkaXNsYXYgTGhvdGthIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oi
IHRhcmdldD0iX2JsYW5rIj5saG90a2FAbmljLmN6PC9hPl08YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMTA6MjggQU08YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBUbzogTWljaGFlbCBSZWhkZXIgJmx0OzxhIGhyZWY9Im1h
aWx0bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5S
ZWhkZXJAQW1kb2NzLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1h
bmRhdG9yeSBvYmplY3RzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgZG9lc24ndCBlbnN1
cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IE1pY2hhZWwgUmVoZGVyICZsdDs8
YSBocmVmPSJtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
Pk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208L2E+Jmd0OyB3cml0ZXM6PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSSBoYXZlIGEg
cXVlc3Rpb24gYWJvdXQg4oCcd2hlbuKAnSBhbmQgbWFuZGF0b3J5IG9iamVjdHMuPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7
IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGltcGxlbWVudGVkIHNlbWFudGljcyBvZiDigJx3aGVu
4oCdIGFyZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyByZWFsbHk8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jmd0OyDigJxvcHRpb25hbCB3aGVu4oCdLCBpbiB0aGF0IHRoZSBlbmNs
b3Npbmcgb2JqZWN0IGNhbiBiZSBhYnNlbnQgZXZlbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsm
Z3Q7IHRob3VnaCBpdCBpcyBtYW5kYXRvcnkgYW5kIHRoZSDigJx3aGVu4oCdIGNsYXVzZSBob2xk
cyB0cnVlLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUgUkZDIGNvdWxkIGJl
IGNsZWFyZXIgYWJvdXQgdGhpcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgRXhhbXBsZTxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7bGVhZiBjb2xvciB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW51bWVyYXRpb24mbmJzcDsgezxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW51
bSDigJxibHVl4oCdOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW51bSDigJxibGFja+KAnTs8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuZGF0b3J5
IHRydWU7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDt9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtj
b250YWluZXIgZm9vIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgd2hlbiAuLi9jb2xvciA9IOKAmGJsdWXigJk7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGV0Yy48YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZn
dDsg4oCcZm9v4oCdIGlzIG9wdGlvbmFsIGR1ZSB0byB0aGUgcHJlc2VuY2Ugb2YgdGhlIOKAnHdo
ZW7igJ0gc3RhdGVtZW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGV2ZW4gdGhv
dWdoIHRoZSBvYmplY3QgaXMgbWFuZGF0b3J5IChzYW1lIGlzIHRydWUgZm9yIG1hbmRhdG9yeTxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBsZWFmLDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7Jmd0OyBtaW4tZWxlbWVudHM9MSBsaXN0IGV0Yy4pLjxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsmZ3Q7IE1heWJlIHlvdSBpbnRlbmRlZCB0byBoYXZlLCBlLmcuLCBhICZxdW90O21h
bmRhdG9yeSB0cnVlJnF1b3Q7IGxlYWYgaW5zaWRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDsgJnF1b3Q7Y29udGFpbmVyIGZvbyZxdW90Oz88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGNvbnNpZGVyZWQgdmFs
aWQgWE1MIGZvciB0aGUgYWJvdmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbHQ7Y29sb3ImZ3Q7Ymx1ZSZsdDsvY29sb3ImZ3Q7PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyZndDsgWWVzLCBpdCBpcywgdW5kZXIgY3VycmVudCBZQU5HIHJ1bGVz
LCBubyBtYXR0ZXIgd2hhdCAmcXVvdDtldGMuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsgc3RhbmRzIGZvci4gTm90ZSB0aGF0IGV2YWx1YXRpb24gb2YgdGhlIFhQYXRoIGV4cHJl
c3Npb24gaW4gdGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGNhc2UgKHdpdGggJnF1
b3Q7Zm9vJnF1b3Q7IG1pc3NpbmcpIHJlcXVpcmVzIHRoZSBwZWN1bGlhciBwcm9jZWR1cmUgb2Yg
c2VjLiA3LjIxLjU8YnI+DQomZ3Q7IGluIFJGQyA3OTUwLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IEluIG15IHZpZXcgdGhpcyBt
YWtlcyBjb25kaXRpb25hbGx5IHZhcmlhbnQgc2NoZW1hcyDigJxsb29zZeKAnSBpbjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGVpciBlbmZvcmNlbWVudCAoc29tZSBzY2VuYXJp
b3MgY2FuIHVzZSBjaG9pY2UgYnV0IGl0IGRvZXNu4oCZdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmZ3Q7Jmd0OyBjb3ZlciBldmVyeXRoaW5nKS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0
OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSSB0aGluayB0aGF0IG1hbmRh
dG9yeSBzaG91bGQgYmUgcmVzcGVjdGVkIGZvciB0aGUgZW5jbG9zaW5nPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7IG9iamVjdHMgb2YgYSDigJx3aGVu4oCdIHN0YXRlbWVudC4mbmJz
cDsgVGhhdCBpcywgYSBtYW5kYXRvcnkgb2JqZWN0IG11c3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyZndDsgYmUgcHJlc2VudCB3aGVuIGl0cyDigJx3aGVu4oCdIGNsYXVzZSBob2xkcyB0
cnVlIGFuZCBhIFNjaGVtYXRyb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgc3Rh
dGVtZW50IHNob3VsZCBlbmZvcmNlIHRoYXQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsg
SW4gZmFjdCwgdGhpcyBpcyBvbmUgY2FzZSB3aGVyZSB0aGUgRFNETCBtYXBwaW5nIChSRkMgNjEx
MCk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBkZXZpYXRlcyBmcm9tIFlBTkcgMS4wLiBO
b2RlcyB0aGF0IG1hbmRhdG9yeSBhcmVuJ3QgZW5jbG9zZWQgaW48YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jmd0OyB0aGUgUkVMQVggTkcgJmx0O29wdGlvbmFsJmd0OyBwYXR0ZXJuLCBhbmQgYXJl
IHRoZW4gcmVxdWlyZWQgbm8gbWF0dGVyIHdoYXQ8YnI+DQomZ3Q7IGFueSAmcXVvdDt3aGVuJnF1
b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgc3RhdGVtZW50cyBzYXkgKGJlY2F1c2Ug
UkVMQVggTkcgdmFsaWRhdGlvbiBjb21lcyBiZWZvcmU8YnI+DQomZ3Q7IFNjaGVtYXRyb24pLjxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm
Z3Q7IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIGN1cnJlbnQgWUFORyBydWxlcyBi
ZWhhdmlvciw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgdGhhdCB0aGUg4oCcd2hl
buKAnSBTY2hlbWF0cm9uIG1hcHBpbmcgZG9lc27igJl0IGNoZWNrIGZvciBwcmVzZW5jZSBvZjxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGUgZW5jbG9zaW5nIG1hbmRhdG9yeSBv
YmplY3Q/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgRldJVywgSSBoYXZlIGJlZW4gcmVw
ZWF0ZWRseSBwcm90ZXN0aW5nIGFnYWluc3QgdGhpcyBiZWhhdmlvdXI8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jmd0OyBidXQgd2l0aG91dCBtdWNoIGx1Y2suIFNlZSBmb3IgZXhhbXBsZTxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgPGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVu
dC9tc2cxNDAxMi5odG0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQwMTIuaHRtPC9hPjxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsmZ3Q7IGw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IEFzIGEgcmVzdWx0LCAmcXVvdDt3aGVuJnF1b3Q7IGlzIHRo
ZSB0cmlja2llc3QgZmVhdHVyZSBpbiBZQU5HIGJ5IGZhci48YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IExhZGE8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGFua3M8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgTWlrZSBSZWhkZXI8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IExhZGlzbGF2IExo
b3RrYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IEhlYWQsIENaLk5JQyBMYWJzPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyDigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFz
ZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Y2xvdWQtYmFzZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0
byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZzxicj4NCiZndDsgJmd0
OyAmZ3Q7IHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92
aWRlcnMgb2Ygc3VjaDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFz
aXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
ZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNo
IHByb2Nlc3NpbmcsPGJyPg0KJmd0OyBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8
L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IOKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0
Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkPGJy
Pg0KJmd0OyBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNz
ZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoPGJyPg0KJmd0OyBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3Np
YmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQ8
YnI+DQomZ3Q7IGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5j
ZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Y8YnI+DQomZ3Q7IHN1Y2ggc3lzdGVtIGFuZCBz
dWNoIHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48YnI+DQomZ3Q7ICZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZn
dDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0
bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZn
dDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgSnVlcmdlbiBT
Y2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKYWNv
YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQomZ3Q7IFBob25lOiAmIzQzOzQ5IDQyMSAy
MDAgMzU4NyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczov
L21hcHMuZ29vZ2xlLmNvbS8/cT1DYW1wdXMmIzQzO1JpbmcmIzQzOzEmIzQzOyU3QyYjNDM7Mjg3
NTkmIzQzO0JyZW1lbiYjNDM7JTdDJiM0MztHZXJtYW55JmFtcDtlbnRyeT1nbWFpbCZhbXA7c291
cmNlPWciPkNhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PC9hPjxicj4NCiZn
dDsgRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNp
dHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv
PC9hPiZndDs8YnI+DQrigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0
aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2Vu
dCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3Rl
bSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lz
dGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscw0KIHRvIEFtZG9j
cyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1
Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5u
ZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDou
NWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxBbWRvY3Pi
gJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBj
bG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9j
ZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkg
dGhpcmQgcGFydHkgcHJvdmlkZXJzDQogb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lz
LiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50
IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBh
bmQgYWNjZXNz4oCdLjwvc3Bhbj48L2VtPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDBwdCAwLjVpbjsiPjxlbT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGZvbnQgZmFj
ZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+4oCcQW1kb2Nz4oCZIGVtYWlsDQpwbGF0Zm9ybSBpcyBiYXNl
ZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55DQpl
bWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBz
dWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUNCmJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBv
ZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZg0KZW1haWxz
IHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0
ZW0gYW5kIHN1Y2gNCnByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48L2ZvbnQ+PC9z
cGFuPjwvZW0+PC9wPg0KDQo8Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_DB6PR06MB408599478F23AD524F2840BCE7E10DB6PR06MB4085eurp_--


From nobody Thu Oct 11 11:17:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED121200D7 for ; Thu, 11 Oct 2018 11:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.155
X-Spam-Level: 
X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSnpz0yLHwCy for ; Thu, 11 Oct 2018 11:17:39 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7B1130EB9 for ; Thu, 11 Oct 2018 11:17:39 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9BIDg0I009462; Thu, 11 Oct 2018 11:17:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=NcXj9fJV3oFj4WSkYDe10woF5cFYk/JHaT4qa5cfNN8=; b=l5hI/47LTy/Ud1BTDET2z3jN8GkBiYoeC8xd5lcJS7JAY4CXXJzLKSJa3Eunv4njMked GwUQrht6962Q9cToyxvMnuelGfqdtVVBGDaFfa7R7WI47oFEczkcFZx1qvYYYYetHeHx 2kFcxRRaTLDD4VGyh3d5+Ukc8Sy1cJKJs3gu5BHHNK8eHoz1c/5KjQKW/1oMMUyUzd7w AtNUMf7bhfhuQEUYonStEMdvMUcb+i2oQGLGmxT+J7fXU/HlVMEYfQEPXO2HPWKaBmfP 8ywueqYG30ZV8PaSI/2l7/WGr1+nhF69gYKkRgPlZbnjU458+MQHLOVaUSSo07LoDDwc zA== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0085.outbound.protection.outlook.com [207.46.163.85]) by mx0b-00273201.pphosted.com with ESMTP id 2n289k8duy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Oct 2018 11:17:31 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5003.namprd05.prod.outlook.com (20.177.223.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.16; Thu, 11 Oct 2018 18:17:29 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1228.020; Thu, 11 Oct 2018 18:17:29 +0000
From: Kent Watsen 
To: Andy Bierman 
CC: Alexander Clemm , Ladislav Lhotka , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
Thread-Index: AQHUWyPz6FAZXxCAuEeMxCal0HeWUaUO37yAgAAnp4CAAARbAIAABz8AgABBFoD//8WNgIAAWzMAgAAFdID//8jaAIABBsKAgAWVBYCAAQ+mgIACJjWA///4hoAACcgtAAAZEaIA
Date: Thu, 11 Oct 2018 18:17:29 +0000
Message-ID: 
References: <201810031419.w93EJNpn040188@idle.juniper.net> <20181004.121417.2190375850946168105.mbj@tail-f.com> <69afa537-9a5f-6fb6-de21-2add0ffec4b2@cisco.com> <0aa239221e80e812f920db6ae023eabc6b3ef5ed.camel@nic.cz>  <27c125fa83754c5f6723e04243f1efdaf4be8e82.camel@nic.cz> <7E46B2E3-3F12-4E08-8172-823E73E25D50@juniper.net> <20181004190754.fsu5ck5jblw5uuah@anna.jacobs.jacobs-university.de>  <8704A29D-EBAB-4AA0-B5A3-3CAC74403360@juniper.net> <87sh1kde7u.fsf@nic.cz> <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6D575@sjceml521-mbx.china.huawei.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EB6E244@sjceml521-mbx.china.huawei.com> <8E17601A-EE48-4750-B11F-63BC6068C530@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5003; 6:GPuBvuoLFNxdzgjS8++XkE9zHi4a/eGN9BDKSUKraAYJW/hXfLG1/2kDC83BdmUFmxHh5QmGlqI1+T4jrVFlcdi1aX8cPsVPShbIkVnSyXuoiogbfphBCIbxDsBlh65natTClArGw5vVf3PtMS3FHt98/JEjy5ikLCkpUClzTjP+XKzzTcvi5MQdszLlAW2UiRPE8ncxg0LqlFWmeylAZI2Ebd6clsBky0OFoJ5oHdMyLvLQ3gJjlCJ6Uzv4wB45AQyhRz2KEA4KGLzbIXSJNeN6tgnENz1U+nUUvBIwWxCRhKd6cJextCo0Ay29Qc0DHpaWDljzcI4iR0y20qsLrAy4QC6gKkfKSG+OgxhWG3QM1U3opV0aWN0XtMwlyar7gu9SjTDLOqcvk11rijxzYcB9xfKGW5MnJ38rvpa7Ggn0V6Zxj5NuhvPmB7yENr56H8mp2iZr5/ydaCcdoOsl7g==; 5:fuHs2/iujjzDN/YslelIs6Pnon45jX1sba50Yt1AVex0N/lB7lcoz3JBP6Pr3sKIzd67FYN7IbJZtkPqsEYWslZB5uFJKBzpxahQQYLWout6dw2l0vxz9LeflYXBcapvsUEFcFHOBT9wek70u49PNz0iHBisUs6s9HF7N9Dauio=; 7:cwhiZwxf8R5nrwf9+X0NjSlhyqohoD1ZfbDTUY5ErSALC43fGB4WHkI4pBn/61+RI5L/QolrHflPqLuU9KRsHQSE/09ndw2oKQDE8l3Wky2WTS/26DEI+xdb2KT9vcxYkTmPPidFqkKGw6fYIXHQRprMaLNm7Zrv7mp49kaYUjHAm1nbnlrTDM1eiAV9A2Fgl9Z/Je66UVp+7L+qSOYYf6zfTvlfgUSnT9KGtCDUxhCjv9TfaDmrQMWBoRmNfhlM
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6e463ad2-2456-4efa-d1a3-08d62fa5ce37
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5003; 
x-ms-traffictypediagnostic: DM6PR05MB5003:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(50582790962513)(158342451672863)(95692535739014)(10436049006162)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(163750095850);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051); SRVR:DM6PR05MB5003; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5003; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(396003)(376002)(366004)(346002)(13464003)(189003)(199004)(51444003)(6306002)(6506007)(6246003)(102836004)(82746002)(53936002)(33656002)(256004)(99286004)(81166006)(81156014)(14454004)(7736002)(66066001)(14444005)(76176011)(53546011)(4744004)(606006)(97736004)(966005)(25786009)(478600001)(83716004)(5250100002)(486006)(316002)(114624004)(4326008)(26005)(790700001)(229853002)(476003)(106356001)(6436002)(68736007)(2616005)(71200400001)(105586002)(6916009)(71190400001)(6116002)(58126008)(186003)(8676002)(93886005)(5660300001)(6486002)(86362001)(446003)(236005)(11346002)(8936002)(6512007)(2906002)(2900100001)(36756003)(3846002)(54896002)(575784001)(53946003)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5003; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: H5fVRA6uvcLOqu4YkyZPYGWpQHThicUGd91VFQ6UO90daZHJ4VrE7vAF13p+IIGoTq4Z36pVa4+lBFLL1zJCL+Rg38H0SUklYBat8dIsj829chsrPSzF6g8WpSX0wuxAxI+IXZ1xzIk3R2vEtiM8fRix6efJbRkAIfr655pJFOunfrM0JKDzHudGoTehVppIYLEhVQdX70RsfkekWBG9znWmutLmP6Rujtu5CoMt5DnsLz0HpKQ9cWmXGiZAC6JvdnTD9nnx/iogs4fTZQBt/cmfeuYKgVqyBBNOaqvNzyxytSPkkDeJXuHc2sZ/hlRR0AtLAf5cVF+Bq4/yHGeukUub3qHXmCCRu5gaClVed3s=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B1676BDFC522418EBBEE771657063B1Ejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e463ad2-2456-4efa-d1a3-08d62fa5ce37
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2018 18:17:29.4126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5003
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-11_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810110172
Archived-At: 
Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:17:46 -0000

--_000_B1676BDFC522418EBBEE771657063B1Ejunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WWVzLCBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGNsZWFyIG9uIHRoZSB1c2UgY2FzZXMuDQoNCkl0
IGlzIG5vdCBteSBpbnRlbnRpb24gZm9yIHN1cHBvcnQgaHVtYW4gaW50ZXJhY3Rpb24sIHRob3Vn
aCB0aGF0IG1heSBvY2N1ci4NCg0KVGhlICBwcmltYXJ5IHF1ZXN0aW9uIEnigJltIGhvcGluZyB0
aGlzIHdvcmsgc3VwcG9ydHMgaXMg4oCcaG93IGRvIHR3byBkYXRhc3RvcmVzDQpkaWZmZXI/4oCd
LCB3aGljaCBJIHZpZXcgYXMgbmVlZGluZyB0byByZXR1cm4gZWl0aGVyLCBwZXJoYXBzIGJhc2Vk
IG9uIGEgY2xpZW50LQ0Kc2VsZWN0YWJsZSBwYXJhbWV0ZXI6DQoNCiAgMS4gIGEgbGlzdCBvZiB4
cGF0aHMgd2hlcmUgZGlmZnMgb2NjdXIgb3INCiAgMi4gIGEgbGlzdCBvZiB4cGF0aHMgd2hlcmUg
ZGlmZnMgb2NjdXIgKmFuZCogYm90aCB2YWx1ZXMgZm9yIGVhY2ggZGlmZg0KDQpIb3cgdGhlIGRp
ZmYgaXMgY29uc3VtZWQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBpZiBpdCBsZWFkcyB0byBhbiBjb25m
aWd1cmF0aW9uDQpvcGVyYXRpb24gdGhhdCBpbnRlbmRzIHRvIGFsaWduIG9uZSBkYXRhc3RvcmUg
dG8gdGhlIG90aGVyLCBpcyBiZSBhIHNlY29uZGFyeQ0KY29uc2lkZXJhdGlvbiBJTU8uDQoNCktl
bnQgLy8gY29udHJpYnV0b3INCg0KT24gMTAvMTAvMTgsIDEwOjIwIFBNLCAiQW5keSBCaWVybWFu
IiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90ZToN
Cg0KDQoNCk9uIFdlZCwgT2N0IDEwLCAyMDE4IGF0IDY6MzkgUE0sIEtlbnQgV2F0c2VuIDxrd2F0
c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQpIaSBB
bGV4LCBubyBvYmplY3Rpb24uDQoNCk15IHN1cHBvcnQgd2l0aGRyYXcgYXBwZWFycyB0byBwdXQg
bWUgaW4gdGhlIHJvdWdoLCB3aGljaCBpcyBmaW5lIGZyb20gYSBwcm9jZXNzIHBlcnNwZWN0aXZl
LiAgQnV0IG1ha2Ugbm8gbWlzdGFrZSwgSSB0aGluayB0aGF0IGl0J3MgYml6YWFyIGZvciBhICJk
aWZmIiB0byBub3Qgc2hvdyBib3RoIHZhbHVlcy4gIEFuZHkncyBpZGVhIHRvIGF1Z21lbnQgaW4g
YW4gJ29sZC12YWx1ZScgbm9kZSBzZWVtcyBsaWtlIGEgc3RlcCBpbiB0aGUgcmlnaHQgZGlyZWN0
aW9uLg0KDQpUaGUgcmVxdWlyZW1lbnRzIGFuZCB1c2UtY2FzZXMgaGF2ZSBub3QgcmVhbGx5IGJl
ZW4gZGlzY3Vzc2VkIGZpcnN0Lg0KSWYgdGhlIHVzZS1jYXNlIGlzIGZvciBodW1hbnMgdG8gY29t
cGFyZSB0aGUgZGF0YXN0b3JlcyAoZS5nLiwgYSBzaWRlLWJ5LXNpZGUgZGlmZiBsaWtlIGFuIEkt
RCkNCnRoZW4gdGhlIGZvcm1hdCB3b3VsZCBiZSB2ZXJ5IGRpZmZlcmVudCB0aGFuIGlmIHRoZSB1
c2UtY2FzZSB3YXMgbW9yZSBwcm9ncmFtbWF0aWMNCihlLmcuLCBsb29rIGZvciBubyBkaWZmcywg
bG9vayBmb3IgYW4gZWRpdCBjb21wbGV0ZWQsIHBhdGNoIGEgbG9jYWwgY29weSkuDQoNCktlbnQg
Ly8gY29udHJpYnV0b3INCg0KQW5keQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRv
OmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciAx
MCwgMjAxOCBhdCA2OjA2IFBNDQpUbzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8
bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmlj
LmN6PG1haWx0bzpsaG90a2FAbmljLmN6Pj4sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu
Y29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq
LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA
aWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3Vi
amVjdDogUkU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1v
ZC1ubWRhLWRpZmYtMDANCg0KV2hpY2ggZm9ybWF0IHRvIG1ha2UgbWFuZGF0b3J5IHNvdW5kcyBs
aWtlIHNvbWV0aGluZyB3ZSBjYW4gZGlzY3VzcyBpbiBCYW5na29rLiAgVGhlIHJlYXNvbiBZQU5H
LXBhdGNoIHdhcyBjaG9zZW4gaXMgcmV1c2UsIGFsdGhvdWdoIGl0IGlzIGNlcnRhaW5seSBjb25j
ZWl2YWJsZSB0byBkZXZlbG9wIGFub3RoZXIgZm9ybWF0LiAgKFBlciBkaXNjdXNzaW9uIG9uIHRo
ZSBsaXN0IHdlIHdpbGwgcHV0IHRoZSBob29rcyBpbiBwbGFjZSB0byBhbGxvdyBmb3Igb3RoZXIg
b3B0aW9ucy4pICBFaXRoZXIgd2F5LCB0aGlzIHNlZW1zIHRvIGJlIG9uZSBvZiB0aGUgdGVjaG5p
Y2FsIGRldGFpbHMgdGhhdCBuZWVkIHRvIGJlIGRlY2lkZWQsIG5vdCBzb21ldGhpbmcgdGhhdCB3
b3VsZCBtYWtlIG9yIGJyZWFrIHN1cHBvcnQgYXMgYSB3aG9sZT8NCi0tLSBBbGV4DQoNCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS2VudCBXYXRzZW4gW21haWx0bzprd2F0
c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pl0NCj4gU2VudDogVHVl
c2RheSwgT2N0b2JlciAwOSwgMjAxOCAxMDoxNyBBTQ0KPiBUbzogQWxleGFuZGVyIENsZW1tIDxh
bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5j
b20+PjsgTGFkaXNsYXYgTGhvdGthDQo+IDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmlj
LmN6Pj47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3
b3Jrcy5jb20+PjsgSnVlcmdlbg0KPiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVj
dDogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1u
bWRhLWRpZmYtMDANCj4NCj4gSSBhZ3JlZSB0aGF0IGEgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBm
b3JtYXQgaXMgZGVzaXJhYmxlLg0KPg0KPiBJIGRpc2FncmVlIHRoYXQgWUFORy1QYXRjaCBpcyB0
aGUgcmlnaHQgZm9ybWF0LCBmb3IgcmVhc29ucyBzdGF0ZWQgYmVmb3JlLiAgSSBmZWVsDQo+IHRo
YXQgYSBjb21wcm9taXNlIG9mIHRoaXMgc29ydCBmb3IgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50
IGlzIHdyb25nLg0KPg0KPiBJZiB0aGlzIGlzIHdoYXQgdGhlIFdHIHdhbnRzLCBJIHdpdGhkcmF3
IG15IHN1cHBvcnQuDQo+DQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4NCj4NCj4NCj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIu
Y2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+Pg0KPiBE
YXRlOiBNb25kYXksIE9jdG9iZXIgOCwgMjAxOCBhdCA1OjA1IFBNDQo+IFRvOiBMYWRpc2xhdiBM
aG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMuY3o+PiwgS2VudCBXYXRzZW4g
PGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiwNCj4gQW5k
eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+
LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4sICJu
ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iDQo+IDxuZXRtb2RAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJFOiBbbmV0bW9kXSBXRyBh
ZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+DQo+IEkg
d291bGQgc2Vjb25kIHRoZSByZXF1ZXN0IGZvciBvbmUgZm9ybWF0ICh3aGljaCBpcyBtYW5kYXRv
cnkgdG8gc3VwcG9ydCksDQo+IHdoaWNoIG11c3QgYmUgc3BlY2lmaWVkLiAgWUFORy1QYXRjaCBp
cyB0aGUgbG9naWNhbCBjYW5kaWRhdGUgSU1ITy4NCj4NCj4gVG8gYWxsb3cgc2VsZWN0aW9uIG9m
IG90aGVyIGZvcm1hdHMgdXNpbmcgYW4gaW5wdXQgcGFyYW1ldGVyIG1ha2VzIHNlbnNlLCBidXQN
Cj4gYWRkcyBzb21lIGNvbXBsZXhpdHkgZnJvbSB0aGVyZTogIEhvdyB0byBrbm93IHdoaWNoIGZv
cm1hdHMgYXJlIHN1cHBvcnRlZD8NCj4gKEFkZCBhIGxpc3Qgb2Ygc3VwcG9ydGVkIGZvcm1hdHMg
c29tZXdoZXJlPykgICBPciBzaW1wbHkgcmVseSBvbiBhdWdtZW50YXRpb24NCj4gZm9yIHRob3Nl
IGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgaXQ/DQo+DQo+IC0tLSBBbGV4DQo+DQo+ID4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh
bGYgT2YgTGFkaXNsYXYNCj4gPiBMaG90a2ENCj4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDUs
IDIwMTggMTI6NTAgQU0NCj4gPiBUbzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8
bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PjsgQW5keSBCaWVybWFuDQo+ID4gPGFuZHlAeXVt
YXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj47IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy0NCj4gPiB1bml2ZXJzaXR5LmRlPGh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX191bml2ZXJzaXR5LmRl
JmQ9RHdNRmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1XdWJPY0ZRd3ct
MWlBQUJ0WGtBWGtaV3pnczRQeWd3MFozZHJRX1BfTHRjJnM9ZWZYZVN3dm9BWlhUT21ybC1WTGxm
XzhwbTZPM3lSdGxRQWZvc3EwQ0RDbyZlPT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBm
b3INCj4gPiBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+ID4NCj4gPiBLZW50IFdh
dHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdy
aXRlczoNCj4gPg0KPiA+ID4gU3VyZSwgb25lIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgZm9ybWF0
LCBvdGhlcnMgbmljZSB0byBoYXZlLg0KPiA+ID4gSW50ZXJvcGVyYWJpbGl0eSBnb29kLiAgQWdy
ZWVkLg0KPiA+ID4NCj4gPiA+IEJ1dCB3aHkgWUFORy1wYXRjaCBhbmQgbm90IHNvbWV0aGluZyBi
dWlsdCBmb3IgdGhlIHB1cnBvc2UgKGUuZy4sDQo+ID4gPiBZQU5HLWRpZmYpIHRoYXQsIGluIHBh
cnRpY3VsYXIsIHByb3ZpZGVzIGFuIGFjdHVhbCBkaWZmIGFzIG9wcG9zZWQNCj4gPiA+IHRvIGEg
ZGF0YS10cmVlIG9wZXJhdGlvbiB0aGF0IG9ubHkgc2hvd3Mgb25lIG9mIHRoZSB0d28gdmFsdWVz
Pw0KPiA+DQo+ID4gU3VjaCBhIGZvcm1hdCBjYW4gYmUgZGV2ZWxvcGVkIGluZGVwZW5kZW50bHks
IEkgd291bGQgc3VwcG9ydCBpdC4NCj4gPg0KPiA+IExhZGENCj4gPg0KPiA+ID4NCj4gPiA+IEtl
bnQgLy8gY29udHJpYnV0b3INCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gMTAvNC8xOCwgMzoyNyBQ
TSwgIkFuZHkgQmllcm1hbiINCj4gPiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1
bWF3b3Jrcy5jb20+PG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdv
cmtzLmNvbT4+PiB3cm90ZToNCj4gPiA+DQo+ID4gPiBPbiBUaHUsIE9jdCA0LCAyMDE4IGF0IDEy
OjA3IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku
ZGU+PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLTxtYWlsdG86ai5zY2hvZW53YWVsZGVy
QGphY29icy0+DQo+ID4gdW5pdmVyc2l0eS5kZTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdW5pdmVyc2l0eS5kZSZkPUR3TUZhUSZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09V3ViT2NGUXd3LTFpQUFCdFhrQVhrWld6Z3M0UHln
dzBaM2RyUV9QX0x0YyZzPWVmWGVTd3ZvQVpYVE9tcmwtVkxsZl84cG02TzN5UnRsUUFmb3NxMENE
Q28mZT0+Pj4gd3JvdGU6DQo+ID4gPiBGb2xrcywgdGhlIG1vcmUgZm9ybWF0cyB0aGVyZSBhcmUs
IHRoZSBsZXNzIGludGVyb3BlcmFiaWxpdHkgd2UgZ2V0Lg0KPiA+ID4gSWYgdGhlcmUgYXJlIG11
bHRpcGxlIGZvcm1hdHMsIGlzIHRoZXJlIGEgbWFuZGF0b3J5IHRvIGltcGxlbWVudA0KPiA+ID4g
Zm9ybWF0PyBEb2VzIHRoZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCBkZXBlbmQgb24g
dGhlDQo+ID4gPiBwcm90b2NvbCB0aGF0IGlzIGJlaW5nIHVzZWQ/DQo+ID4gPg0KPiA+ID4gSSBw
cmVmZXIgb25lIGZvcm1hdCBvciBpZiBuZWNlc3NhcnkgSSBhbSBmaW5lIHdpdGggb25lIG1hbmRh
dG9yeSB0bw0KPiA+ID4gaW1wbGVtZW50IGZvcm1hdC4gQW4gb3BlbiBlbmRlZCBjb2xsZWN0aW9u
IG9mIGltcGxlbWVudGF0aW9uDQo+ID4gPiBzcGVjaWZpYyBmb3JtYXRzIGlzIHN1cGVyIGZsZXhp
YmxlIGJ1dCBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGENCj4gPiA+IHN0YW5kYXJkLCBuYW1lbHkg
aW50ZXJvcGVyYWJpbGl0eS4NCj4gPiA+DQo+ID4gPiBJIGFncmVlIHRoZXJlIG5lZWRzIHRvIGJl
IDEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBmb3JtYXQuDQo+ID4gPg0KPiA+ID4gSU1PIHRoaXMg
bmVlZHMgdG8gYmUgWUFORyBQYXRjaCBiZWNhdXNlIGl0IGlzIG1vcmUgcHJlY2lzZSB0aGVuDQo+
ID4gPiBjb25zdHJ1Y3RpbmcgYW4gWE1MIHRyZWUgd2l0aCBvcGVyYXRpb24gYXR0cmlidXRlcyBp
biBpdCAoZS5nLiwgaG93DQo+ID4gPiBlbHNlIGRvIHlvdSByZXByZXNlbnQgYSBkZWxldGUgb3Ig
YSBtb3ZlPykgQWxzbywgWUFORyBQdXNoIGlzIHVzaW5nDQo+ID4gPiBZQU5HIFBhdGNoIGZvcm1h
dCBhbmQgY29tbW9uIGNvZGUgZm9yIHB1c2ggYW5kIGRpZmYgd291bGQgYmUgcG9zc2libGUuDQo+
ID4gPg0KPiA+ID4gSSB0aGluayBvdGhlciBmb3JtYXRzIHNob3VsZCBiZSBhbGxvd2VkLg0KPiA+
ID4gVGhpcyBpcyB2ZXJ5IHRvb2wtc3BlY2lmaWMuIEkgY291bGQgc2VlIGhvdyBzb21lYm9keSBt
aWdodCB3YW50IGENCj4gPiA+IHRleHR1YWwgcGF0Y2ggb2YgdGhlIFhNTCByZXByZXNlbnRhdGlv
biB0byBwcm9kdWNlIHRoZSBuZXcgWE1MDQo+ID4gcmVwcmVzZW50YXRpb24uDQo+ID4gPg0KPiA+
ID4NCj4gPiA+IC9qcw0KPiA+ID4NCj4gPiA+IEFuZHkNCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24g
VGh1LCBPY3QgMDQsIDIwMTggYXQgMDU6NDE6MjJQTSArMDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6
DQo+ID4gPj4gV2UgYWdyZWUgdGhhdCB0aGUgZGlmZi1mb3JtYXQgc2hvdWxkIGJlIGNsaWVudC1z
ZWxlY3RhYmxlLCBtb2R1bG8NCj4gPiA+PiB3aGF0IHRoZQ0KPiA+IHNlcnZlciBzdXBwb3J0cy4g
IHlhbmctcGF0Y2ggYW5kIGVkaXQtY29uZmlnIGJvdGggYXJlIHZpYWJsZS4gIFNob3VsZA0KPiA+
IHdlIGRvY3VtZW50IHRoZW0gYm90aD8NCj4gPiA+Pg0KPiA+ID4+IFRoYXQgc2FpZCwgc2luY2Ug
bmVpdGhlciBlZGl0LWNvbmZpZyBub3IgeWFuZy1wYXRjaCBhcmUgZGlmZmluZw0KPiA+ID4+IGZv
cm1hdHMsIHNvDQo+ID4gbXVjaCBhcyBmb3JtYXRzIGZvciBjb252ZXJ0aW5nIG9uZSBkYXRhIHRy
ZWUgdG8gYW5vdGhlciwgd291bGQgaXQgbWFrZQ0KPiA+IHNlbnNlIHRvIGRlZmluZSBhbiBhY3R1
YWwgZGlmZmluZyBmb3JtYXQ/ICBJIHdvdWxkIHRoaW5rIHRoYXQgYSBkaWZmDQo+ID4gd291bGQg
cHJvdmlkZSBib3RoIHZhbHVlcywgbm90IGp1c3QgYSBuZXcgdmFsdWUuDQo+ID4gPj4NCj4gPiA+
PiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogbmV0bW9kDQo+ID4gPj4gPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+PiBvbiBi
ZWhhbGYNCj4gPiA+PiBvZiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxo
b3RrYUBuaWMuY3o+PG1haWx0bzpsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6Pj4+
DQo+ID4gPj4gT3JnYW5pemF0aW9uOiBDWi5OSUMNCj4gPiA+PiBEYXRlOiBUaHVyc2RheSwgT2N0
b2JlciA0LCAyMDE4IGF0IDE6MTEgUE0NCj4gPiA+PiBUbzogUm9iZXJ0IFdpbHRvbiA8cndpbHRv
bkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPjxtYWlsdG86cndpbHRvbkBjaXNj
by5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4+LA0KPiA+ID4+ICJuZXRtb2RAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz48bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86
bmV0bW9kQGlldGYub3JnPj4iDQo+ID4gPj4gPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k
QGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+
Pj4NCj4gPiA+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgYWRvcHRpb24gcG9sbCBmb3INCj4g
PiA+PiBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwDQo+ID4gPj4NCj4gPiA+PiBPbiBU
aHUsIDIwMTgtMTAtMDQgYXQgMTQ6MTcgKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4g
Pj4gPg0KPiA+ID4+ID4gT24gMDQvMTAvMjAxOCAxMzo1MSwgTGFkaXNsYXYgTGhvdGthIHdyb3Rl
Og0KPiA+ID4+ID4gPiBPbiBUaHUsIDIwMTgtMTAtMDQgYXQgMTM6MzYgKzAxMDAsIFJvYmVydCBX
aWx0b24gd3JvdGU6DQo+ID4gPj4gPiA+ID4gT24gMDQvMTAvMjAxOCAxMToxNCwgTWFydGluIEJq
b3JrbHVuZCB3cm90ZToNCj4gPiA+PiA+ID4gPiA+IFBoaWwgU2hhZmVyIDxwaGlsQGp1bmlwZXIu
bmV0PG1haWx0bzpwaGlsQGp1bmlwZXIubmV0PjxtYWlsdG86cGhpbEBqdW5pcGVyLm5ldDxtYWls
dG86cGhpbEBqdW5pcGVyLm5ldD4+PiB3cm90ZToNCj4gPiA+PiA+ID4gPiA+ID4gQmFsP3pzIExl
bmd5ZWwgd3JpdGVzOg0KPiA+ID4+ID4gPiA+ID4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG8NCj4gPiA+PiA+ID4gPiA+ID4gPiBvbA0K
PiA+ID4+ID4gPiA+ID4gPiA+IHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGNsZW1tLTJEbmV0bW9k
LTJEbm1kYS0yRGRpZmYtMkQNCj4gPiA+PiA+ID4gPiA+ID4gPiAwMA0KPiA+ID4+ID4gPiA+ID4g
PiA+ICZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gPiBuZGIzdm9E
VFhjV3pvQ0kmcg0KPiA+ID4+ID4gPiA+ID4gPiA+DQo+ID4gPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03czZWZHp6SDlPDQo+ID4gPj4gPiA+ID4gPiA+ID4N
Cj4gPiBsM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2Mmcz1nUVdKdGpjXzJFRjNRZ1J2
QUJnWksNCj4gPiA+PiA+ID4gPiA+ID4gPiBzanF6dUl3OXlVcV94ZWU2YUZKT2N3JmU9DQo+ID4g
Pj4gPiA+ID4gPiA+IFtJJ3ZlIG1vdmVkIHRvIGEgImRlZXAgbHVya2VyIiByb2xlIGhlcmUsIGJ1
dCAuLi5dDQo+ID4gPj4gPiA+ID4gPiA+DQo+ID4gPj4gPiA+ID4gPiA+IENhbiB3ZSBlbnN1cmUg
dGhpcyBtb2RlbCBjb250YWlucyBhICJmb3JtYXQiIGxlYWYgaW4gdGhlIFJQQydzDQo+IGlucHV0
DQo+ID4gPj4gPiA+ID4gPiA+IHNvIHRoYXQgZnV0dXJlIChhbmQgcHJvcHJpZXRhcnkpIGZvcm1h
dHMgY2FuIGJlIHN1cHBvcnRlZD8gICBUaGF0DQo+ID4gPj4gPiA+ID4gPiA+IGxlYWYgY2FuIGJl
IGFuIGlkZW50aXR5cmVmIHRoYXQgZGVmYXVsdHMgdG8geWFuZy1wYXRjaC4NCj4gPiA+PiA+ID4g
PiA+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYS4gIEkgd291bGQgcHJlZmVyIHRoZQ0KPiA+
ID4+ID4gPiA+ID4gZWRpdC1jb25maWcgZm9ybWF0IG92ZXIgWUFORyBwYXRjaCBmb3IgZGVzY3Jp
YmluZyBhIGRpZmYuDQo+ID4gPj4gPiA+ID4gPiBUaGUgZWRpdC1jb25maWcgZm9ybWF0IGlzIG1v
cmUgc3VpdGVkIGZvciB0aGlzIHB1cnBvc2UgaW1vLg0KPiA+ID4+ID4gPiA+ICsxDQo+ID4gPj4g
PiA+ID4NCj4gPiA+PiA+ID4gPiBJIHdvdWxkIGxpa2Ugc29tZXRoaW5nIGNsb3NlciB0byBlZGl0
LWNvbmZpZyB0byBiZSBhdmFpbGFibGUNCj4gPiA+PiA+ID4gPiB2aWEgUkVTVENPTkYgYXMgd2Vs
bC4NCj4gPiA+PiA+ID4gWUFORyBQYXRjaCBpcyBJTU8gYmV0dGVyIGJlY2F1c2UgaXQgY2xlYXJs
eSBzZXBhcmF0ZXMgdGhlDQo+ID4gPj4gPiA+IHRhcmdldCBmb3IgdGhlIGVkaXRzIGZyb20gdGhl
IG5ldyBjb250ZW50Lg0KPiA+ID4+ID4gPiBJbiBlZGl0LWNvbmZpZyB0aGVzZSB0d28gYXJlIG1p
eGVkIHRvZ2V0aGVyLg0KPiA+ID4+ID4gWWVzLCB0aGF0IGlzIHByaW1hcmlseSB3aHkgSSBwcmVm
ZXIgdGhlIGVkaXQtY29uZmlnLiAgSSBwZXJjZWl2ZQ0KPiA+ID4+ID4gdGhhdCBpdCBpcyBhIGRl
bnNlciBhbmQgbW9yZSBlZmZpY2llbnQgZm9ybWF0LiAgSSB0aGluayB0aGF0IGl0DQo+ID4gPj4g
PiBpcyBib3RoIGVhc2llciB0byBjb25zdHJ1Y3QgKHdoZW4gZGlmZmluZyB0d28gdHJlZXMpIGFu
ZCBhbHNvDQo+ID4gPj4gPiBtb3JlIGVmZmljaWVudCB0byBhcHBseSB3aGVuIGdlbmVyYXRpbmcg
YW4gdXBkYXRlZCB0cmVlLg0KPiA+ID4+DQo+ID4gPj4gRXhjZXB0IGZvciBjZXJ0YWluIGNvcm5l
ciBjYXNlcywgZm9yIGV4YW1wbGUgaWYgdHdvIHRyZWVzIGRpZmZlcg0KPiA+ID4+IG9ubHkgaW4g
dGhlIHZhbHVlIG9mIGEgc2luZ2xlIGxlYWYgYnV0IHRoaXMgbGVhZiBoYXBwZW5zIHRvIGJlIGEg
bGlzdCBrZXkuDQo+ID4gPj4NCj4gPiA+PiBMYWRhDQo+ID4gPj4NCj4gPiA+PiA+DQo+ID4gPj4g
PiBUaGFua3MsDQo+ID4gPj4gPiBSb2INCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ID4+ID4gPiBU
aGF0IGJlaW5nIHNhaWQsIEkgc3VwcG9ydCBzcGVjaWZ5aW5nIGZvcm1hdC9tZWRpYS10eXBlIGFu
ZA0KPiA+ID4+ID4gPiBoYXZpbmcgcG90ZW50aWFsbHkgbXVsdGlwbGUgb3B0aW9ucy4NCj4gPiA+
PiA+ID4NCj4gPiA+PiA+ID4gTGFkYQ0KPiA+ID4+ID4gPg0KPiA+ID4+ID4gPiA+IFRoYW5rcywN
Cj4gPiA+PiA+ID4gPiBSb2INCj4gPiA+PiA+ID4gPg0KPiA+ID4+ID4gPiA+DQo+ID4gPj4gPiA+
ID4gPiAvbWFydGluDQo+ID4gPj4gPiA+ID4gPg0KPiA+ID4+ID4gPiA+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiA+ID4gPiA+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCj4gPiA+PiA+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v
cmc+Pg0KPiA+ID4+ID4gPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX193d3cuaWUNCj4gPiA+PiA+ID4gPiA+IHRmDQo+ID4gPj4gPiA+ID4g
Pg0KPiA+IC5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFUNCj4gPiA+PiA+ID4gPiA+IGpCWGVNSy0NCj4gPiBuZGIzdm9EVFhjV3pvQ0km
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVMNCj4gPiA+PiA+ID4gPiA+DQo+
ID4gbGFKZGNabyZtPTdzNlZkenpIOU9sM0JPQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2Mm
cz1SVkpjZw0KPiA+ID4+ID4gPiA+ID4gNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I5
bl9BUFEmZT0NCj4gPiA+PiA+ID4gPiA+IC4NCj4gPiA+PiA+ID4gPiA+DQo+ID4gPj4gPiA+ID4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiA+
ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPj4gPiA+ID4gbmV0bW9kQGlldGYub3JnPG1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmc+PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4+DQo+ID4gPj4gPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zg0KPiA+ID4+ID4gPiA+IC5vDQo+ID4gPj4g
PiA+ID4NCj4gPiByZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGUNCj4gPiA+PiA+ID4gPiBNSy0NCj4gPiBuZGIzdm9EVFhjV3pvQ0km
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1oNCj4gPiA+PiA+ID4g
Pg0KPiA+IG8mbT03czZWZHp6SDlPbDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJnM9
UlZKY2c1cHpIVy16aQ0KPiA+ID4+ID4gPiA+IDFPYm9DTDRTWDJodVc5ZXVIaVZSU0NvcjluX0FQ
USZlPQ0KPiA+ID4+IC0tDQo+ID4gPj4gTGFkaXNsYXYgTGhvdGthDQo+ID4gPj4gSGVhZCwgQ1ou
TklDIExhYnMNCj4gPiA+PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+Pg0K
PiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86
bmV0bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0
Zi5vcmc+Pg0KPiA+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX20NCj4gPiA+PiBhaQ0KPiA+ID4+IGxtYW5fbGlzdGlu
Zm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiA+IG5k
YjN2b0RUWA0KPiA+ID4+DQo+ID4NCj4gY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFu
MmdzQllhR1R2aklTbGFKZGNabyZtPTdzNlZkenpIOU9sMw0KPiA+IEJPDQo+ID4gPj4gQ2JWTEJh
ckJyUTVmRDB2VHQ4a19JMktERU45N2Mmcz1SVkpjZzVwekhXLQ0KPiA+IHppMU9ib0NMNFNYMmh1
VzlldUhpVlJTQ29yDQo+ID4gPj4gOW5fQVBRJmU9DQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+IG5ldG1vZCBtYWls
aW5nIGxpc3QNCj4gPiA+PiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz48
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPiA+PiBo
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p
ZXRmLm9yZ19tDQo+ID4gPj4gYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3YNCj4gPiA+Pg0KPiBvRFRYY1d6b0NJJnI9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpzdw0KPiBu
TQ0KPiA+ID4+IDQ4R3dkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9ZzB4X0ItDQo+
IFhlejd0RDloTFg3MUQ1dmxjSGRab2huDQo+ID4gPj4gVGtpTVZJS0poQUhpdmsmZT08aHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+ID4+IDNBX191
cmxkZWZlbnNlLnByb29mJmQ9RHdJRkFnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0K
PiBuZGIzdm9EDQo+ID4gPj4NCj4gVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y
Z3NCWWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk0NCj4gNDgNCj4gPiA+PiBHd2RJNHRlei0NCj4g
SnRmMnVhMmp2dExaVktmaXdrYndiSXJVJnM9YnpMYUxvQkNKODhsYXZldXBMcWFwWU40YnRqRUJC
dg0KPiA+ID4+IE5FTk55MDlUc29vYyZlPQ0KPiA+ID4+IHBvaW50LmNvbS92Mi91cmw/dT1odHRw
cy08aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Bv
aW50LmNvbV92Ml91cmwtM0Z1LTNEaHR0cHMtMkQmZD1Ed01GYVEmYz1IQWtZdWg2M3JzdWhyNlNj
YmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz
QllhR1R2aklTbGFKZGNabyZtPVd1Yk9jRlF3dy0xaUFBQnRYa0FYa1pXemdzNFB5Z3cwWjNkclFf
UF9MdGMmcz1ia1dXdjRrQTJhV01wMk16YXA3bmlxQ2hhbTN0aEFyNk9BbDVrRGJKZ1hVJmU9Pg0K
PiA+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1EDQo+ID4gPj4g
d01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+ID4gbmRiM3ZvRFRYY1d6b0NJ
JnI9OXprUDB4bkpVdlpHSjlFDQo+ID4gPj4gUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt
PU83ZC0NCj4gPiBiOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2DQo+ID4gPj4gVzNx
dDQmcz01TEhoYmZRWmVvcVlsQzQwVDNtbS1BRXo0clNzeVJXWWpxVEs3THVXVFB3JmU9Pg0KPiA+
ID4NCj4gPiA+IC0tDQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29i
cyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg
ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+ID4gRmF4
OiAgICs0OSA0MjEgMjAwIDMxMDMNCj4gPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmphY29icy0NCj4gMkQmZD1Ed0lGQWcmYz1IQWtZdWg2
M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5
RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1EDQo+IE0xanN3bk00OEd3ZEk0dGV6LUp0
ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZzPTVSRDk2LQ0KPiBUanltVTFaaG1mWkZ0V0VtNGFia2tk
YXhxcmtDS3p1djRQWlJRJmU9DQo+ID4gdW5pdmVyc2l0eS5kZS88aHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3VuaXZlcnNpdHkuZGVfJmQ9RHdNRmFR
JmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5K
VXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1XdWJPY0ZRd3ctMWlBQUJ0WGtB
WGtaV3pnczRQeWd3MFozZHJRX1BfTHRjJnM9d1luTUtrbU5VOFVnOVhqTVg5c01HWERSTm1CZk9Y
N0hKTFY1TW1aUVhtZyZlPT48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLQ0KPiA+IDNBX193d3cuamFjb2JzLQ0KPiA+IDJEdW5pdmVyc2l0eS5kZV8mZD1E
d01GYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+ID4NCj4gbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPU8NCj4g
PiA3ZC0NCj4gPg0KPiBiOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2VzNxdDQmcz16
aDdxRVBTbXd2aWFTcVpCcUcxR2MNCj4gPiBxSXRYd0k5cHd5cUlGVlc2eEM4cks4JmU9Pj4NCj4g
PiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0
bzpuZXRtb2RAaWV0Zi5vcmc+PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp
ZXRmLm9yZz4+DQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYQ0KPiA+ID4gaWxtYW5fbGlzdGluZm9fbmV0bW9k
JmQ9RHdJRkFnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EDQo+ID4g
Pg0KPiBUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mbT1ETTFqc3duTQ0KPiA0OEcNCj4gPiA+IHdkSTR0ZXotSnRmMnVhMmp2dExaVktmaXdrYndi
SXJVJnM9ZzB4X0ItDQo+IFhlejd0RDloTFg3MUQ1dmxjSGRab2huVGtpTQ0KPiA+ID4gVklLSmhB
SGl2ayZlPTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3UNCj4gPiA+IHJsZGVmZW5zZS5wcm9vZnAmZD1Ed0lGQWcmYz1IQWtZdWg2M3JzdWhyNlNj
YmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXeg0KPiA+ID4NCj4gb0NJJnI9OXprUDB4bkpVdlpH
SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPURNMWpzd25NNDhHd2QNCj4gSTR0DQo+
ID4gPiBlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJclUmcz1pZDVrZFhERWI0YWZub2JXVC0NCj4g
ZlVxM1lmc0lrSG9vejVSdFhZc28NCj4gPiA+IFFSdDFvJmU9DQo+ID4gPiBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy08aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHAtM0FfX29pbnQuY29tX3YyX3VybC0zRnUtM0RodHRwcy0yRCZkPUR3TUZhUSZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09V3ViT2NGUXd3LTFpQUFCdFhrQVhrWld6Z3M0UHln
dzBaM2RyUV9QX0x0YyZzPUl2cXU0RkJVUVdBajI2LWp4WkhXU2szakFwOXlyNVBCWFJwbWY0UDV1
ZTgmZT0+DQo+ID4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3
TQ0KPiA+ID4gRmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiA+IG5kYjN2b0RU
WGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvTw0KPiA+ID4gSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPU83ZC0NCj4gPiBiOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdRTG84X1c2VzNxdA0K
PiA+ID4gNCZzPTVMSGhiZlFaZW9xWWxDNDBUM21tLUFFejRyU3N5UldZanFUSzdMdVdUUHcmZT0+
DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZzxt
YWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWENCj4gPiA+IGlsbWFuX2xp
c3RpbmZvX25ldG1vZCZkPUR3SUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4g
bmRiM3ZvRA0KPiA+ID4NCj4gVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJm09RE0xanN3bk0NCj4gNDhHDQo+ID4gPiB3ZEk0dGV6LUp0ZjJ1YTJq
dnRMWlZLZml3a2J3YklyVSZzPWcweF9CLQ0KPiBYZXo3dEQ5aExYNzFENXZsY0hkWm9oblRraU0N
Cj4gPiA+IFZJS0poQUhpdmsmZT0NCj4gPg0KPiA+IC0tDQo+ID4gTGFkaXNsYXYgTGhvdGthDQo+
ID4gSGVhZCwgQ1ouTklDIExhYnMNCj4gPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcN
Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwNCj4gPiBtYW5fbGlzdGluZm9fbmV0bW9k
JmQ9RHdJRkFnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjVw0K
PiA+DQo+IHpvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
Jm09RE0xanN3bk00OEd3DQo+IGRJNHRlDQo+ID4gei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJclUm
cz1nMHhfQi0NCj4gWGV6N3REOWhMWDcxRDV2bGNIZFpvaG5Ua2lNVklLSmhBSGkNCj4gPiB2ayZl
PQ0KDQoNCg==

--_000_B1676BDFC522418EBBEE771657063B1Ejunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz
dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7
bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww
DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFyaWFu
dDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3Jt
Om5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNl
bGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K
CXttc28tbGlzdC1pZDoxMzY2NTIyMTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp
c3QtdGVtcGxhdGUtaWRzOi0yMDI5MzgyMTcyIDEzMzU4OTE3NDAgNjc2OTg2OTEgNjc2OTg2OTMg
Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K
QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxMTsNCgltc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MjMuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU5LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s
ZWZ0Ojk1LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTMxLjI1cHQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CW1hcmdpbi1sZWZ0OjE2Ny4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls
eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMDMu
MjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzkuMjVwdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu
LWxlZnQ6Mjc1LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMxMS4yNXB0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEN
Cgl7bXNvLWxpc3QtaWQ6MTgyOTkwNzI1NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t
bGlzdC10ZW1wbGF0ZS1pZHM6LTk0MzQzNzc5NCAtODEwNzgwNjU0IDY3Njk4NzEzIDY3Njk4NzE1
IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30N
CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN
Cgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzLjI1cHQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTkuMjVwdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv
bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6OTUuMjVwdDsNCgl0ZXh0LWluZGVudDotOS4w
cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzEuMjVwdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjcuMjVwdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv
bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MjAzLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTku
MHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM5LjI1cHQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mjc1LjI1cHQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy
b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMxMS4yNXB0Ow0KCXRleHQtaW5kZW50Oi05
LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp
bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlllcywgaXQgd291bGQgYmUgZ29vZCB0byBi
ZSBjbGVhciBvbiB0aGUgdXNlIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+SXQgaXMgbm90IG15IGludGVudGlvbiBmb3Igc3VwcG9ydCBodW1hbiBpbnRl
cmFjdGlvbiwgdGhvdWdoIHRoYXQgbWF5IG9jY3VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+VGhlICZuYnNwO3ByaW1hcnkgcXVlc3Rpb24gSeKAmW0gaG9waW5n
IHRoaXMgd29yayBzdXBwb3J0cyBpcyDigJxob3cgZG8gdHdvIGRhdGFzdG9yZXMNCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij5kaWZmZXI/4oCdLCB3aGljaCBJIHZpZXcgYXMgbmVlZGluZyB0byByZXR1cm4g
ZWl0aGVyLCBwZXJoYXBzIGJhc2VkIG9uIGEgY2xpZW50LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5zZWxl
Y3RhYmxlIHBhcmFtZXRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdp
bi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh
cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTIuNzVwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YSBsaXN0IG9mIHhwYXRocyB3aGVyZSBk
aWZmcyBvY2N1ciBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTEyLjc1cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm
bzIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmEgbGlzdCBvZiB4cGF0aHMgd2hl
cmUgZGlmZnMgb2NjdXIgKmFuZCogYm90aCB2YWx1ZXMgZm9yIGVhY2ggZGlmZjxvOnA+PC9vOnA+
PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SG93IHRoZSBkaWZmIGlzIGNv
bnN1bWVkIGFuZCwgaW4gcGFydGljdWxhciwgaWYgaXQgbGVhZHMgdG8gYW4gY29uZmlndXJhdGlv
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij5vcGVyYXRpb24gdGhhdCBpbnRlbmRzIHRvIGFsaWduIG9uZSBk
YXRhc3RvcmUgdG8gdGhlIG90aGVyLCBpcyBiZSBhIHNlY29uZGFyeQ0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPmNvbnNpZGVyYXRpb24gSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdCI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IDEwLzEwLzE4LCAxMDoyMCBQTSwgJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVm
PSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBXZWQsIE9jdCAxMCwgMjAxOCBhdCA2OjM5IFBNLCBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5rd2F0c2VuQGp1bmlw
ZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBBbGV4LCBubyBv
YmplY3Rpb24uPGJyPg0KPGJyPg0KTXkgc3VwcG9ydCB3aXRoZHJhdyBhcHBlYXJzIHRvIHB1dCBt
ZSBpbiB0aGUgcm91Z2gsIHdoaWNoIGlzIGZpbmUgZnJvbSBhIHByb2Nlc3MgcGVyc3BlY3RpdmUu
Jm5ic3A7IEJ1dCBtYWtlIG5vIG1pc3Rha2UsIEkgdGhpbmsgdGhhdCBpdCdzIGJpemFhciBmb3Ig
YSAmcXVvdDtkaWZmJnF1b3Q7IHRvIG5vdCBzaG93IGJvdGggdmFsdWVzLiZuYnNwOyBBbmR5J3Mg
aWRlYSB0byBhdWdtZW50IGluIGFuICdvbGQtdmFsdWUnIG5vZGUgc2VlbXMgbGlrZSBhIHN0ZXAg
aW4gdGhlIHJpZ2h0DQogZGlyZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlcXVpcmVtZW50cyBhbmQgdXNlLWNh
c2VzIGhhdmUgbm90IHJlYWxseSBiZWVuIGRpc2N1c3NlZCBmaXJzdC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSB1c2UtY2FzZSBpcyBm
b3IgaHVtYW5zIHRvIGNvbXBhcmUgdGhlIGRhdGFzdG9yZXMgKGUuZy4sIGEgc2lkZS1ieS1zaWRl
IGRpZmYgbGlrZSBhbiBJLUQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj50aGVuIHRoZSBmb3JtYXQgd291bGQgYmUgdmVyeSBkaWZmZXJlbnQgdGhh
biBpZiB0aGUgdXNlLWNhc2Ugd2FzIG1vcmUgcHJvZ3JhbW1hdGljPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oZS5nLiwgbG9vayBmb3Igbm8gZGlm
ZnMsIGxvb2sgZm9yIGFuIGVkaXQgY29tcGxldGVkLCBwYXRjaCBhIGxvY2FsIGNvcHkpLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5L
ZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln
aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBBbGV4
YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNv
bSI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCkRhdGU6IFdlZG5lc2Rh
eSwgT2N0b2JlciAxMCwgMjAxOCBhdCA2OjA2IFBNPGJyPg0KVG86IEtlbnQgV2F0c2VuICZsdDs8
YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwv
YT4mZ3Q7LCBMYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6
Ij5saG90a2FAbmljLmN6PC9hPiZndDssIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDssIEp1ZXJnZW4g
U2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZSI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZn
dDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYu
b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9k
QGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSRTogW25ldG1vZF0gV0cgYWRvcHRpb24g
cG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMDxicj4NCjxicj4NCldoaWNo
IGZvcm1hdCB0byBtYWtlIG1hbmRhdG9yeSBzb3VuZHMgbGlrZSBzb21ldGhpbmcgd2UgY2FuIGRp
c2N1c3MgaW4gQmFuZ2tvay4mbmJzcDsgVGhlIHJlYXNvbiBZQU5HLXBhdGNoIHdhcyBjaG9zZW4g
aXMgcmV1c2UsIGFsdGhvdWdoIGl0IGlzIGNlcnRhaW5seSBjb25jZWl2YWJsZSB0byBkZXZlbG9w
IGFub3RoZXIgZm9ybWF0LiZuYnNwOyAoUGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3Qgd2Ugd2ls
bCBwdXQgdGhlIGhvb2tzIGluIHBsYWNlIHRvIGFsbG93DQogZm9yIG90aGVyIG9wdGlvbnMuKSZu
YnNwOyBFaXRoZXIgd2F5LCB0aGlzIHNlZW1zIHRvIGJlIG9uZSBvZiB0aGUgdGVjaG5pY2FsIGRl
dGFpbHMgdGhhdCBuZWVkIHRvIGJlIGRlY2lkZWQsIG5vdCBzb21ldGhpbmcgdGhhdCB3b3VsZCBt
YWtlIG9yIGJyZWFrIHN1cHBvcnQgYXMgYSB3aG9sZT8mbmJzcDsNCjxicj4NCi0tLSBBbGV4PGJy
Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog
S2VudCBXYXRzZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+
a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT5dPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBPY3RvYmVy
IDA5LCAyMDE4IDEwOjE3IEFNPGJyPg0KJmd0OyBUbzogQWxleGFuZGVyIENsZW1tICZsdDs8YSBo
cmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20iPmFsZXhhbmRlci5jbGVtbUBo
dWF3ZWkuY29tPC9hPiZndDs7IExhZGlzbGF2IExob3RrYTxicj4NCiZndDsgJmx0OzxhIGhyZWY9
Im1haWx0bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDs7IEFuZHkgQmllcm1h
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3Mu
Y29tPC9hPiZndDs7IEp1ZXJnZW48YnI+DQomZ3Q7IFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9
Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtu
ZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYt
MDA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhZ3JlZSB0aGF0IGEgbWFuZGF0b3J5IHRvIGltcGxl
bWVudCBmb3JtYXQgaXMgZGVzaXJhYmxlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGRpc2FncmVl
IHRoYXQgWUFORy1QYXRjaCBpcyB0aGUgcmlnaHQgZm9ybWF0LCBmb3IgcmVhc29ucyBzdGF0ZWQg
YmVmb3JlLiZuYnNwOyBJIGZlZWw8YnI+DQomZ3Q7IHRoYXQgYSBjb21wcm9taXNlIG9mIHRoaXMg
c29ydCBmb3IgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlzIHdyb25nLjxicj4NCiZndDsgPGJy
Pg0KJmd0OyBJZiB0aGlzIGlzIHdoYXQgdGhlIFdHIHdhbnRzLCBJIHdpdGhkcmF3IG15IHN1cHBv
cnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEtlbnQgLy8gY29udHJpYnV0b3I8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
PGJyPg0KJmd0OyBGcm9tOiBBbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4
YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0
Ozxicj4NCiZndDsgRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDgsIDIwMTggYXQgNTowNSBQTTxicj4N
CiZndDsgVG86IExhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMu
Y3oiPmxob3RrYUBuaWMuY3o8L2E+Jmd0OywgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0
bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDssPGJyPg0K
Jmd0OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20i
PmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+DQom
Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5
LmRlIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0OywgJnF1b3Q7
PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZxdW90
Ozxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBp
ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW25ldG1vZF0gV0cgYWRvcHRp
b24gcG9sbCBmb3IgZHJhZnQtY2xlbW0tbmV0bW9kLW5tZGEtZGlmZi0wMDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBJIHdvdWxkIHNlY29uZCB0aGUgcmVxdWVzdCBmb3Igb25lIGZvcm1hdCAod2hpY2gg
aXMgbWFuZGF0b3J5IHRvIHN1cHBvcnQpLDxicj4NCiZndDsgd2hpY2ggbXVzdCBiZSBzcGVjaWZp
ZWQuJm5ic3A7IFlBTkctUGF0Y2ggaXMgdGhlIGxvZ2ljYWwgY2FuZGlkYXRlIElNSE8uPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IFRvIGFsbG93IHNlbGVjdGlvbiBvZiBvdGhlciBmb3JtYXRzIHVzaW5n
IGFuIGlucHV0IHBhcmFtZXRlciBtYWtlcyBzZW5zZSwgYnV0PGJyPg0KJmd0OyBhZGRzIHNvbWUg
Y29tcGxleGl0eSBmcm9tIHRoZXJlOiZuYnNwOyBIb3cgdG8ga25vdyB3aGljaCBmb3JtYXRzIGFy
ZSBzdXBwb3J0ZWQ/PGJyPg0KJmd0OyAoQWRkIGEgbGlzdCBvZiBzdXBwb3J0ZWQgZm9ybWF0cyBz
b21ld2hlcmU/KSZuYnNwOyAmbmJzcDtPciBzaW1wbHkgcmVseSBvbiBhdWdtZW50YXRpb248YnI+
DQomZ3Q7IGZvciB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3YW50IGl0Pzxicj4NCiZndDsg
PGJyPg0KJmd0OyAtLS0gQWxleDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IG5ldG1vZCBbbWFpbHRvOjxhIGhy
ZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmc8L2E+XSBPbiBCZWhhbGYgT2YgTGFkaXNsYXY8YnI+DQomZ3Q7ICZndDsgTGhvdGthPGJyPg0K
Jmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNSwgMjAxOCAxMjo1MCBBTTxicj4NCiZn
dDsgJmd0OyBUbzogS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlw
ZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs7IEFuZHkgQmllcm1hbjxicj4NCiZn
dDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1h
d29ya3MuY29tPC9hPiZndDs7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVs
ZGVyQGphY29icy08YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3VuaXZlcnNpdHkuZGUmYW1wO2Q9RHdNRmFR
JmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1XdWJPY0ZR
d3ctMWlBQUJ0WGtBWGtaV3pnczRQeWd3MFozZHJRX1BfTHRjJmFtcDtzPWVmWGVTd3ZvQVpYVE9t
cmwtVkxsZl84cG02TzN5UnRsUUFmb3NxMENEQ28mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQp1
bml2ZXJzaXR5LmRlPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5l
dG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtuZXRtb2RdIFdH
IGFkb3B0aW9uIHBvbGwgZm9yPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRh
LWRpZmYtMDA8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgS2VudCBXYXRzZW4gJmx0Ozxh
IGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9h
PiZndDsgd3JpdGVzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFN1cmUsIG9u
ZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcm1hdCwgb3RoZXJzIG5pY2UgdG8gaGF2ZS48YnI+
DQomZ3Q7ICZndDsgJmd0OyBJbnRlcm9wZXJhYmlsaXR5IGdvb2QuJm5ic3A7IEFncmVlZC48YnI+
DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEJ1dCB3aHkgWUFORy1wYXRjaCBh
bmQgbm90IHNvbWV0aGluZyBidWlsdCBmb3IgdGhlIHB1cnBvc2UgKGUuZy4sPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgWUFORy1kaWZmKSB0aGF0LCBpbiBwYXJ0aWN1bGFyLCBwcm92aWRlcyBhbiBhY3R1
YWwgZGlmZiBhcyBvcHBvc2VkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gYSBkYXRhLXRyZWUgb3Bl
cmF0aW9uIHRoYXQgb25seSBzaG93cyBvbmUgb2YgdGhlIHR3byB2YWx1ZXM/PGJyPg0KJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1Y2ggYSBmb3JtYXQgY2FuIGJlIGRldmVsb3BlZCBpbmRlcGVu
ZGVudGx5LCBJIHdvdWxkIHN1cHBvcnQgaXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
IExhZGE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm
Z3Q7IEtlbnQgLy8gY29udHJpYnV0b3I8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gMTAvNC8xOCwgMzoyNyBQTSwgJnF1b3Q7QW5k
eSBCaWVybWFuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5
dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJt
YWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyZndDsg
d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBUaHUsIE9j
dCA0LCAyMDE4IGF0IDEyOjA3IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+DQomZ3Q7ICZn
dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku
ZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mbHQ7bWFpbHRvOjxh
IGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLSI+ai5zY2hvZW53YWVsZGVyQGph
Y29icy08L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX191bml2ZXJzaXR5LmRlJmFtcDtkPUR3TUZhUSZh
bXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6
a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209V3ViT2NGUXd3
LTFpQUFCdFhrQVhrWld6Z3M0UHlndzBaM2RyUV9QX0x0YyZhbXA7cz1lZlhlU3d2b0FaWFRPbXJs
LVZMbGZfOHBtNk8zeVJ0bFFBZm9zcTBDRENvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KdW5p
dmVyc2l0eS5kZTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBGb2xrcywg
dGhlIG1vcmUgZm9ybWF0cyB0aGVyZSBhcmUsIHRoZSBsZXNzIGludGVyb3BlcmFiaWxpdHkgd2Ug
Z2V0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IElmIHRoZXJlIGFyZSBtdWx0aXBsZSBmb3JtYXRzLCBp
cyB0aGVyZSBhIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQ8YnI+DQomZ3Q7ICZndDsgJmd0OyBmb3Jt
YXQ/IERvZXMgdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgZm9ybWF0IGRlcGVuZCBvbiB0aGU8
YnI+DQomZ3Q7ICZndDsgJmd0OyBwcm90b2NvbCB0aGF0IGlzIGJlaW5nIHVzZWQ/PGJyPg0KJmd0
OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHByZWZlciBvbmUgZm9ybWF0IG9yIGlm
IG5lY2Vzc2FyeSBJIGFtIGZpbmUgd2l0aCBvbmUgbWFuZGF0b3J5IHRvPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgaW1wbGVtZW50IGZvcm1hdC4gQW4gb3BlbiBlbmRlZCBjb2xsZWN0aW9uIG9mIGltcGxl
bWVudGF0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWMgZm9ybWF0cyBpcyBzdXBlciBm
bGV4aWJsZSBidXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
c3RhbmRhcmQsIG5hbWVseSBpbnRlcm9wZXJhYmlsaXR5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgSSBhZ3JlZSB0aGVyZSBuZWVkcyB0byBiZSAxIG1hbmRhdG9yeS10
by1pbXBsZW1lbnQgZm9ybWF0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgSU1PIHRoaXMgbmVlZHMgdG8gYmUgWUFORyBQYXRjaCBiZWNhdXNlIGl0IGlzIG1vcmUgcHJl
Y2lzZSB0aGVuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uc3RydWN0aW5nIGFuIFhNTCB0cmVlIHdp
dGggb3BlcmF0aW9uIGF0dHJpYnV0ZXMgaW4gaXQgKGUuZy4sIGhvdzxicj4NCiZndDsgJmd0OyAm
Z3Q7IGVsc2UgZG8geW91IHJlcHJlc2VudCBhIGRlbGV0ZSBvciBhIG1vdmU/KSBBbHNvLCBZQU5H
IFB1c2ggaXMgdXNpbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBZQU5HIFBhdGNoIGZvcm1hdCBhbmQg
Y29tbW9uIGNvZGUgZm9yIHB1c2ggYW5kIGRpZmYgd291bGQgYmUgcG9zc2libGUuPGJyPg0KJmd0
OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIG90aGVyIGZvcm1hdHMgc2hv
dWxkIGJlIGFsbG93ZWQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhpcyBpcyB2ZXJ5IHRvb2wtc3Bl
Y2lmaWMuIEkgY291bGQgc2VlIGhvdyBzb21lYm9keSBtaWdodCB3YW50IGE8YnI+DQomZ3Q7ICZn
dDsgJmd0OyB0ZXh0dWFsIHBhdGNoIG9mIHRoZSBYTUwgcmVwcmVzZW50YXRpb24gdG8gcHJvZHVj
ZSB0aGUgbmV3IFhNTDxicj4NCiZndDsgJmd0OyByZXByZXNlbnRhdGlvbi48YnI+DQomZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgL2pzPGJyPg0K
Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5PGJyPg0KJmd0OyAmZ3Q7ICZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIFRodSwgT2N0IDA0
LCAyMDE4IGF0IDA1OjQxOjIyUE0gJiM0MzswMDAwLCBLZW50IFdhdHNlbiB3cm90ZTo8YnI+DQom
Z3Q7ICZndDsgJmd0OyZndDsgV2UgYWdyZWUgdGhhdCB0aGUgZGlmZi1mb3JtYXQgc2hvdWxkIGJl
IGNsaWVudC1zZWxlY3RhYmxlLCBtb2R1bG88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgd2hhdCB0
aGU8YnI+DQomZ3Q7ICZndDsgc2VydmVyIHN1cHBvcnRzLiZuYnNwOyB5YW5nLXBhdGNoIGFuZCBl
ZGl0LWNvbmZpZyBib3RoIGFyZSB2aWFibGUuJm5ic3A7IFNob3VsZDxicj4NCiZndDsgJmd0OyB3
ZSBkb2N1bWVudCB0aGVtIGJvdGg/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmZ3Q7IFRoYXQgc2FpZCwgc2luY2UgbmVpdGhlciBlZGl0LWNvbmZpZyBub3IgeWFu
Zy1wYXRjaCBhcmUgZGlmZmluZzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBmb3JtYXRzLCBzbzxi
cj4NCiZndDsgJmd0OyBtdWNoIGFzIGZvcm1hdHMgZm9yIGNvbnZlcnRpbmcgb25lIGRhdGEgdHJl
ZSB0byBhbm90aGVyLCB3b3VsZCBpdCBtYWtlPGJyPg0KJmd0OyAmZ3Q7IHNlbnNlIHRvIGRlZmlu
ZSBhbiBhY3R1YWwgZGlmZmluZyBmb3JtYXQ/Jm5ic3A7IEkgd291bGQgdGhpbmsgdGhhdCBhIGRp
ZmY8YnI+DQomZ3Q7ICZndDsgd291bGQgcHJvdmlkZSBib3RoIHZhbHVlcywgbm90IGp1c3QgYSBu
ZXcgdmFsdWUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7
IEtlbnQgLy8gY29udHJpYnV0b3I8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgRnJvbTogbmV0bW9kPGJyPg0KJmd0OyAmZ3Q7
ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5l
dG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBv
biBiZWhhbGY8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgb2YgTGFkaXNsYXYgTGhvdGthICZsdDs8
YSBocmVmPSJtYWlsdG86bGhvdGthQG5pYy5jeiI+bGhvdGthQG5pYy5jejwvYT4mbHQ7bWFpbHRv
OjxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDsmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IE9yZ2FuaXphdGlvbjogQ1ouTklDPGJyPg0KJmd0OyAm
Z3Q7ICZndDsmZ3Q7IERhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDQsIDIwMTggYXQgMToxMSBQTTxi
cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBUbzogUm9iZXJ0IFdpbHRvbiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mbHQ7bWFpbHRvOjxh
IGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0
OyZndDssPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRt
b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0
bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7JnF1b3Q7PGJyPg0KJmd0
OyAmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn
Ij5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgU3Vi
amVjdDogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsmZ3Q7IGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLWRpZmYtMDA8YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgT24gVGh1LCAyMDE4LTEwLTA0IGF0IDE0OjE3
ICYjNDM7MDEwMCwgUm9iZXJ0IFdpbHRvbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IE9uIDA0LzEwLzIwMTggMTM6NTEsIExh
ZGlzbGF2IExob3RrYSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IE9u
IFRodSwgMjAxOC0xMC0wNCBhdCAxMzozNiAmIzQzOzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6
PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIDA0LzEwLzIwMTggMTE6
MTQsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgUGhpbCBTaGFmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsQGp1bmlw
ZXIubmV0Ij5waGlsQGp1bmlwZXIubmV0PC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBo
aWxAanVuaXBlci5uZXQiPnBoaWxAanVuaXBlci5uZXQ8L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBCYWw/enMgTGVuZ3ll
bCB3cml0ZXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fdG8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9sPGJyPg0KJmd0OyAmZ3Q7ICZndDsm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0y
RGNsZW1tLTJEbmV0bW9kLTJEbm1kYS0yRGRpZmYtMkQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMDA8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmFtcDtkPUR3SUNBZyZhbXA7Yz1IQWtZdWg2
M3JzdWhyNlNjYmZoMFVqQlhlTUstPGJyPg0KJmd0OyAmZ3Q7IG5kYjN2b0RUWGNXem9DSSZhbXA7
cjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0OyA9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa
byZhbXA7bT03czZWZHp6SDlPPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGwzQk9DYlZMQmFyQnJRNWZEMHZUdDhrX0ky
S0RFTjk3YyZhbXA7cz1nUVdKdGpjXzJFRjNRZ1J2QUJnWks8YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgc2pxenVJdzl5VXFfeGVlNmFGSk9jdyZh
bXA7ZT08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFtJ
J3ZlIG1vdmVkIHRvIGEgJnF1b3Q7ZGVlcCBsdXJrZXImcXVvdDsgcm9sZSBoZXJlLCBidXQgLi4u
XTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENhbiB3ZSBlbnN1cmUg
dGhpcyBtb2RlbCBjb250YWlucyBhICZxdW90O2Zvcm1hdCZxdW90OyBsZWFmIGluIHRoZSBSUEMn
czxicj4NCiZndDsgaW5wdXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IHNvIHRoYXQgZnV0dXJlIChhbmQgcHJvcHJpZXRhcnkpIGZvcm1hdHMgY2FuIGJl
IHN1cHBvcnRlZD8mbmJzcDsgJm5ic3A7VGhhdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgbGVhZiBjYW4gYmUgYW4gaWRlbnRpdHlyZWYgdGhhdCBkZWZh
dWx0cyB0byB5YW5nLXBhdGNoLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYS4mbmJzcDsgSSB3b3VsZCBwcmVmZXIg
dGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZWRpdC1jb25m
aWcgZm9ybWF0IG92ZXIgWUFORyBwYXRjaCBmb3IgZGVzY3JpYmluZyBhIGRpZmYuPGJyPg0KJmd0
OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGVkaXQtY29uZmlnIGZvcm1h
dCBpcyBtb3JlIHN1aXRlZCBmb3IgdGhpcyBwdXJwb3NlIGltby48YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDsgJmd0OyAmZ3Q7ICZndDsgJiM0MzsxPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgd291bGQg
bGlrZSBzb21ldGhpbmcgY2xvc2VyIHRvIGVkaXQtY29uZmlnIHRvIGJlIGF2YWlsYWJsZTxicj4N
CiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyB2aWEgUkVTVENPTkYgYXMgd2VsbC48
YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IFlBTkcgUGF0Y2ggaXMgSU1PIGJldHRl
ciBiZWNhdXNlIGl0IGNsZWFybHkgc2VwYXJhdGVzIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0
OyAmZ3Q7ICZndDsgdGFyZ2V0IGZvciB0aGUgZWRpdHMgZnJvbSB0aGUgbmV3IGNvbnRlbnQuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBJbiBlZGl0LWNvbmZpZyB0aGVzZSB0d28g
YXJlIG1peGVkIHRvZ2V0aGVyLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFllcywgdGhh
dCBpcyBwcmltYXJpbHkgd2h5IEkgcHJlZmVyIHRoZSBlZGl0LWNvbmZpZy4mbmJzcDsgSSBwZXJj
ZWl2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHRoYXQgaXQgaXMgYSBkZW5zZXIgYW5k
IG1vcmUgZWZmaWNpZW50IGZvcm1hdC4mbmJzcDsgSSB0aGluayB0aGF0IGl0PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmZ3Q7ICZndDsgaXMgYm90aCBlYXNpZXIgdG8gY29uc3RydWN0ICh3aGVuIGRpZmZp
bmcgdHdvIHRyZWVzKSBhbmQgYWxzbzxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IG1vcmUg
ZWZmaWNpZW50IHRvIGFwcGx5IHdoZW4gZ2VuZXJhdGluZyBhbiB1cGRhdGVkIHRyZWUuPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEV4Y2VwdCBmb3IgY2Vy
dGFpbiBjb3JuZXIgY2FzZXMsIGZvciBleGFtcGxlIGlmIHR3byB0cmVlcyBkaWZmZXI8YnI+DQom
Z3Q7ICZndDsgJmd0OyZndDsgb25seSBpbiB0aGUgdmFsdWUgb2YgYSBzaW5nbGUgbGVhZiBidXQg
dGhpcyBsZWFmIGhhcHBlbnMgdG8gYmUgYSBsaXN0IGtleS48YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgTGFkYTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg
VGhhbmtzLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFJvYjxicj4NCiZndDsgJmd0OyAm
Z3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg
Jmd0OyZndDsgJmd0OyAmZ3Q7IFRoYXQgYmVpbmcgc2FpZCwgSSBzdXBwb3J0IHNwZWNpZnlpbmcg
Zm9ybWF0L21lZGlhLXR5cGUgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBo
YXZpbmcgcG90ZW50aWFsbHkgbXVsdGlwbGUgb3B0aW9ucy48YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBMYWRhPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7
ICZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IFJvYjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IC9tYXJ0aW48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7
ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRt
b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0
bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWUiIHRhcmdldD0iX2JsYW5r
Ij4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmllPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRm
PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDsgLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVo
NjNyc3VocjZTY2JmaDBVPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgakJYZU1LLTxicj4NCiZndDsgJmd0OyBuZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpV
dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgbGFKZGNabyZhbXA7bT03czZWZHp6SDlPbDNC
T0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJmFtcDtzPVJWSmNnPGJyPg0KJmd0OyAmZ3Q7
ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgNXB6SFctemkxT2JvQ0w0U1gyaHVXOWV1SGlW
UlNDb3I5bl9BUFEmYW1wO2U9PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsgLjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAm
Z3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3Jn
PC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll
dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDsgPGEg
aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuaWV0ZiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0ZjwvYT48YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDsgJmd0OyAmZ3Q7ICZndDsgLm88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsgcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJ
Q0FnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDsgJmd0OyAmZ3Q7ICZndDsgTUstPGJyPg0KJmd0OyAmZ3Q7IG5kYjN2b0RUWGNXem9DSSZhbXA7
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1o8YnI+DQomZ3Q7ICZn
dDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgbyZhbXA7bT03czZWZHp6
SDlPbDNCT0NiVkxCYXJCclE1ZkQwdlR0OGtfSTJLREVOOTdjJmFtcDtzPVJWSmNnNXB6SFctemk8
YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZndDsgMU9ib0NMNFNYMmh1VzlldUhp
VlJTQ29yOW5fQVBRJmFtcDtlPTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyAtLTxicj4NCiZndDsg
Jmd0OyAmZ3Q7Jmd0OyBMYWRpc2xhdiBMaG90a2E8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSGVh
ZCwgQ1ouTklDIExhYnM8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgUEdQIEtleSBJRDogMHhCOEY5
MkIwOEE5Rjc2QzY3PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9h
PiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYu
b3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbSIg
dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbTwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsg
YWk8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJ
Q0FnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy08YnI+DQomZ3Q7ICZndDsgbmRi
M3ZvRFRYPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBj
V3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZh
bXA7bT03czZWZHp6SDlPbDM8YnI+DQomZ3Q7ICZndDsgQk88YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDsgQ2JWTEJhckJyUTVmRDB2VHQ4a19JMktERU45N2MmYW1wO3M9UlZKY2c1cHpIVy08YnI+DQom
Z3Q7ICZndDsgemkxT2JvQ0w0U1gyaHVXOWV1SGlWUlNDb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyZn
dDsgOW5fQVBRJmFtcDtlPTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAm
Z3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7
ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9y
ZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBp
ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn
X20iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX208L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsm
Z3Q7IGFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJRkFnJmFtcDtjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy08YnI+DQomZ3Q7IG5kYjN2PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7
PGJyPg0KJmd0OyBvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mYW1wO209RE0xanN3PGJyPg0KJmd0OyBuTTxicj4NCiZndDsgJmd0OyAm
Z3Q7Jmd0OyA0OEd3ZEk0dGV6LUp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZhbXA7cz1nMHhfQi08
YnI+DQomZ3Q7IFhlejd0RDloTFg3MUQ1dmxjSGRab2huPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7
IFRraU1WSUtKaEFIaXZrJmFtcDtlPSZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTwvYT48YnI+DQomZ3Q7ICZndDsg
Jmd0OyZndDsgM0FfX3VybGRlZmVuc2UucHJvb2YmYW1wO2Q9RHdJRkFnJmFtcDtjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy08YnI+DQomZ3Q7IG5kYjN2b0Q8YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDs8YnI+DQomZ3Q7IFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mYW1wO209RE0xanN3bk08YnI+DQomZ3Q7IDQ4PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmZ3Q7IEd3ZEk0dGV6LTxicj4NCiZndDsgSnRmMnVhMmp2dExaVktmaXdrYndiSXJV
JmFtcDtzPWJ6TGFMb0JDSjg4bGF2ZXVwTHFhcFlONGJ0akVCQnY8YnI+DQomZ3Q7ICZndDsgJmd0
OyZndDsgTkVOTnkwOVRzb29jJmFtcDtlPTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVm
PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fcG9p
bnQuY29tX3YyX3VybC0zRnUtM0RodHRwcy0yRCZhbXA7ZD1Ed01GYVEmYW1wO2M9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPVd1Yk9jRlF3dy0xaUFBQnRYa0FYa1pX
emdzNFB5Z3cwWjNkclFfUF9MdGMmYW1wO3M9YmtXV3Y0a0EyYVdNcDJNemFwN25pcUNoYW0zdGhB
cjZPQWw1a0RiSmdYVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy08L2E+PGJyPg0KJmd0OyAmZ3Q7IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0
aW5mb19uZXRtb2QmYW1wO2Q9RDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB3TUZhUSZhbXA7Yz1I
QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstPGJyPg0KJmd0OyAmZ3Q7IG5kYjN2b0RUWGNXem9D
SSZhbXA7cj05emtQMHhuSlV2WkdKOUU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgUG9PSDdZaHFu
MmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1PN2QtPGJyPg0KJmd0OyAmZ3Q7IGI5Z3lQdnNhc0pv
MXVlS2szZG9ESDdmNVM1V1FMbzhfVzY8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgVzNxdDQmYW1w
O3M9NUxIaGJmUVplb3FZbEM0MFQzbW0tQUV6NHJTc3lSV1lqcVRLN0x1V1RQdyZhbXA7ZT0mZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0
OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMzxicj4NCiZn
dDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmphY29icy0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5qYWNvYnMtPC9hPjxicj4N
CiZndDsgMkQmYW1wO2Q9RHdJRkFnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy08
YnI+DQomZ3Q7IG5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y
Z3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPUQ8YnI+DQomZ3Q7IE0xanN3bk00OEd3ZEk0dGV6LUp0
ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZhbXA7cz01UkQ5Ni08YnI+DQomZ3Q7IFRqeW1VMVpobWZa
RnRXRW00YWJra2RheHFya0NLenV2NFBaUlEmYW1wO2U9PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX191bml2
ZXJzaXR5LmRlXyZhbXA7ZD1Ed01GYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJmFtcDttPVd1Yk9jRlF3dy0xaUFBQnRYa0FYa1pXemdzNFB5Z3cwWjNkclFfUF9M
dGMmYW1wO3M9d1luTUtrbU5VOFVnOVhqTVg5c01HWERSTm1CZk9YN0hKTFY1TW1aUVhtZyZhbXA7
ZT0iIHRhcmdldD0iX2JsYW5rIj4NCnVuaXZlcnNpdHkuZGUvPC9hPiZsdDs8YSBocmVmPSJodHRw
czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTwv
YT48YnI+DQomZ3Q7ICZndDsgM0FfX3d3dy5qYWNvYnMtPGJyPg0KJmd0OyAmZ3Q7IDJEdW5pdmVy
c2l0eS5kZV8mYW1wO2Q9RHdNRmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy08
YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IG5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2
WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPU88YnI+DQomZ3Q7ICZndDsg
N2QtPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBiOWd5UHZzYXNKbzF1ZUtrM2RvREg3ZjVTNVdR
TG84X1c2VzNxdDQmYW1wO3M9emg3cUVQU213dmlhU3FaQnFHMUdjPGJyPg0KJmd0OyAmZ3Q7IHFJ
dFh3STlwd3lxSUZWVzZ4QzhySzgmYW1wO2U9Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v
ZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf
bWEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7
IGlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lGQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLTxicj4NCiZndDsgbmRiM3ZvRDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyBUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNs
YUpkY1pvJmFtcDttPURNMWpzd25NPGJyPg0KJmd0OyA0OEc8YnI+DQomZ3Q7ICZndDsgJmd0OyB3
ZEk0dGV6LUp0ZjJ1YTJqdnRMWlZLZml3a2J3YklyVSZhbXA7cz1nMHhfQi08YnI+DQomZ3Q7IFhl
ejd0RDloTFg3MUQ1dmxjSGRab2huVGtpTTxicj4NCiZndDsgJmd0OyAmZ3Q7IFZJS0poQUhpdmsm
YW1wO2U9Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fdSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdTwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyBy
bGRlZmVuc2UucHJvb2ZwJmFtcDtkPUR3SUZBZyZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstPGJyPg0KJmd0OyBuZGIzdm9EVFhjV3o8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn
dDsgb0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8m
YW1wO209RE0xanN3bk00OEd3ZDxicj4NCiZndDsgSTR0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZXot
SnRmMnVhMmp2dExaVktmaXdrYndiSXJVJmFtcDtzPWlkNWtkWERFYjRhZm5vYldULTxicj4NCiZn
dDsgZlVxM1lmc0lrSG9vejVSdFhZc288YnI+DQomZ3Q7ICZndDsgJmd0OyBRUnQxbyZhbXA7ZT08
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb2ludC5jb21fdjJfdXJsLTNGdS0zRGh0dHBzLTJEJmFt
cDtkPUR3TUZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6
b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1w
O209V3ViT2NGUXd3LTFpQUFCdFhrQVhrWld6Z3M0UHlndzBaM2RyUV9QX0x0YyZhbXA7cz1JdnF1
NEZCVVFXQWoyNi1qeFpIV1NrM2pBcDl5cjVQQlhScG1mNFA1dWU4JmFtcDtlPSIgdGFyZ2V0PSJf
YmxhbmsiPg0Kb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtPC9hPjxicj4NCiZndDsgJmd0OyAzQV9f
d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TTxicj4NCiZndDsg
Jmd0OyAmZ3Q7IEZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstPGJyPg0KJmd0
OyAmZ3Q7IG5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb088YnI+DQomZ3Q7
ICZndDsgJmd0OyBIN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPU83ZC08YnI+DQomZ3Q7
ICZndDsgYjlneVB2c2FzSm8xdWVLazNkb0RIN2Y1UzVXUUxvOF9XNlczcXQ8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA0JmFtcDtzPTVMSGhiZlFaZW9xWWxDNDBUM21tLUFFejRyU3N5UldZanFUSzdMdVdU
UHcmYW1wO2U9Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZn
dDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0i
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0
OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t
YTwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyBpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJ
RkFnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy08YnI+DQomZ3Q7IG5kYjN2b0Q8
YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpH
SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1ETTFqc3duTTxicj4NCiZndDsg
NDhHPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd2RJNHRlei1KdGYydWEyanZ0TFpWS2Zpd2tid2JJclUm
YW1wO3M9ZzB4X0ItPGJyPg0KJmd0OyBYZXo3dEQ5aExYNzFENXZsY0hkWm9oblRraU08YnI+DQom
Z3Q7ICZndDsgJmd0OyBWSUtKaEFIaXZrJmFtcDtlPTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg
Jmd0OyAtLTxicj4NCiZndDsgJmd0OyBMYWRpc2xhdiBMaG90a2E8YnI+DQomZ3Q7ICZndDsgSGVh
ZCwgQ1ouTklDIExhYnM8YnI+DQomZ3Q7ICZndDsgUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2
QzY3PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxp
c3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9k
QGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsIiB0YXJn
ZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsPC9hPjxicj4NCiZndDsgJmd0OyBtYW5fbGlzdGlu
Zm9fbmV0bW9kJmFtcDtkPUR3SUZBZyZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst
PGJyPg0KJmd0OyBuZGIzdm9EVFhjVzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgem9DSSZhbXA7
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPURNMWpz
d25NNDhHdzxicj4NCiZndDsgZEk0dGU8YnI+DQomZ3Q7ICZndDsgei1KdGYydWEyanZ0TFpWS2Zp
d2tid2JJclUmYW1wO3M9ZzB4X0ItPGJyPg0KJmd0OyBYZXo3dEQ5aExYNzFENXZsY0hkWm9oblRr
aU1WSUtKaEFIaTxicj4NCiZndDsgJmd0OyB2ayZhbXA7ZT08YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_B1676BDFC522418EBBEE771657063B1Ejunipernet_--


From nobody Thu Oct 11 11:48:23 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3250212008A for ; Thu, 11 Oct 2018 11:48:21 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 Q9ae_CK7JRqc for ; Thu, 11 Oct 2018 11:48:17 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 47846130ED0 for ; Thu, 11 Oct 2018 11:48:15 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id 63-v6so9193626ljs.4 for ; Thu, 11 Oct 2018 11:48:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0bmAysdM6iFX5cPTXD94UpycqPc2a+4nRYT/IBOpvHs=; b=Eq99R/TjmsIw3vao4kGR/Ab1jqtgSxRu2fw6WF5PENSzbbh4Mo5rdE4bP2uwHHFWgY eKKRInp5H7l1RqLD9D5QjckIcZFIrVxJMvtvnXz0MczDEQounEQ2fJpZi8eh8NiVN//y CORWm18c3uaWc2+aLopvSJp46CL5MoUfIfcRhzqGlp9hItM/DFBzU5sRu9/HNv9UcFsd gXOyxajwBmFhZBG+TBSbZNbzkPmbyBjyQjEO+02M0AHoe72N29f+nl/n860zzYsYbZlv R50+MFPnLwOsRBoE0K0Xjo2Dk1IsJcrqFY4xNQaEMjJFwekCff7aS7enviiNSDWQm1d/ DCGg==
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=0bmAysdM6iFX5cPTXD94UpycqPc2a+4nRYT/IBOpvHs=; b=JBE3LEi69n2bV0g9t1/YF1s4t7WqGynQkUgaVZyvIMgaUcrjtL6/jyelypqjmQG2wT ALrnvZDV7BByWB/4wYPOPxRRavYxwfOjSO70VDEEGqkrxBcx1bd/OQi87T7xsYZeoYyJ rjL/3cOiP/X8i6hZ1eGKedCaS7EgbjRTqofPWcA7mHm9xlS1qxCS/CB2Y31U7LNofegU X3efn0UF5QIwlrByXubATHtzxF4COAOFi25gVqwSPowJbP19K+EbCxYV2t4F2ocH08I0 cE8nZ0LhYeEIY8Tc3hlr97p/VoIlNXxnQhJDI58jT1u70eA1HPiJyZuL/v0TS353NoXA RBdQ==
X-Gm-Message-State: ABuFfoj2C4lc+bebAkTdHwzJCDlJB9kq00xtlAxKYkekdqLNs1NtJCMp MY6C8wiTE4jtpDqqEzdqAzD8iSqlfVGTPur2DqYEfw==
X-Google-Smtp-Source: ACcGV60seoxpJT2VELZanQrogmwVSa4FiSxJzD01GcHghMSux9MMfLpOuVgCmmQwK9obfcSG4BuMhywXJ9k9DFhStfM=
X-Received: by 2002:a2e:810e:: with SMTP id d14-v6mr1997693ljg.170.1539283693162;  Thu, 11 Oct 2018 11:48:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Thu, 11 Oct 2018 11:48:12 -0700 (PDT)
In-Reply-To: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     
From: Andy Bierman 
Date: Thu, 11 Oct 2018 11:48:12 -0700
Message-ID: 
To: Michael Rehder 
Cc: Juergen Schoenwaelder ,  "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bd700e0577f86945"
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:48:21 -0000

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

On Thu, Oct 11, 2018 at 11:14 AM, Michael Rehder 
wrote:

> There is no specific text - the text just says it is =E2=80=9Cconditional=
=E2=80=9D.
>
> However the implementation forces it optional:
>
> -          The RNG file makes it optional (I=E2=80=99m not actually runni=
ng this
> for various reasons so I=E2=80=99m just interpreting the file generated =
=E2=80=93 maybe I
> misunderstand RNG)
>
> -          Schematron doesn=E2=80=99t check for its existence (like it do=
es for a
> mandatory choice case)
>
>
>

So change the implementation so it conforms to the spec.



> Thanks
>
> Mike
>

Andy


>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, October 11, 2018 2:06 PM
> *To:* Michael Rehder 
> *Cc:* Juergen Schoenwaelder ;
> Walker, Jason (Jason_Walker2@comcast.com) ;
> netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
>
>
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
> I think the wording is relevant - something can be conditional but still
> required.
>
> It should be clarified that elements become implicitly =E2=80=9Cmandatory=
 false=E2=80=9D
> when a =E2=80=9Cwhen=E2=80=9D statement is used.
>
>
>
> I would like to see an enhancement to YANG to control this behavior, to
> allow the mandatory status to be enforced.
>
> That is, support also =E2=80=9Cconditionally required=E2=80=9D instead of=
 only the current
> =E2=80=9Cconditionally optional=E2=80=9D.
>
>
>
>
>
>
>
>   leaf foo {
>
>      when "../some-other-node =3D 5";
>
>      type int32;
>
>      mandatory true;
>
>  }
>
>
>
>
>
> This leaf is mandatory if the when-expr is true.
>
> Where is the text in 7950 that says this mandatory true is ignored if
> when-stmt is present?
>
>
>
>
>
>
>
> Thanks
>
> Mike
>
>
>
> Andy
>
>
>
>
>
>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Wednesday, October 10, 2018 2:52 PM
> *To:* Michael Rehder 
> *Cc:* Juergen Schoenwaelder ;
> Walker, Jason (Jason_Walker2@comcast.com) ;
> netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
>
>
>
>
> On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
> Sure.
>
> I think the RFC is unclear since it seems that the semantics are
> consistent in the back-end checks.
> One can read the RFC and not notice by its absence that the when clause
> doesn't require anything to be present.
>
>      The "when" statement makes its parent data definition statement
> conditional.
> Should be
>     The "when" statement makes its parent data definition statement
> conditional and optional.
>
>
>
> This is not correct.
>
>
>
> Step 1) if-feature makes the schema node conditional
>
>
>
> Step 2) when-stmt makes instances of the schema-node conditional
>
>
>
> Step 3) YANG validation applies to instances of data nodes (or the YANG
> default value if applicable)
>
>
>
> Step 2 is only relevant if Step 1 is true or non-existent
>
> Step 3 is only relevant if Step 2 is true or non-existent
>
>
>
> Andy
>
>
>
>
>
> I think there should be a more definite statement about this overriding
> any mandatory status of the parent data definition statement.
> Like
>      "Any mandatory status of the parent data definition statement
> (mandatory statement, min-element statement etc.) is overridden by this
> statement and made non-mandatory."
>
> That would have made the side-effect of "when" on other declarations
> clearer.
>
> Thanks
> mike
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d=
e
> ]
> > Sent: Wednesday, October 10, 2018 2:25 PM
> > To: Michael Rehder 
> > Cc: Robert Wilton ; Ladislav Lhotka ;
> > netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com)
> > 
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> >
> > Michael,
> >
> > what matters here is what the YANG specification (RFC 7950) says. Is
> there a
> > reason to believe the IPAddresses list in your example can be absent or
> have no
> > elements based on what RFC 7950 says? Or do we talk about a shortcoming
> of
> > RFC 6110?
> >
> > /js
> >
> > On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:
> > > If the list has a "when" clause the RNG file actually produces a
> "OneOrMore"
> > which has a choice of  or the list so it actually doesn't enforc=
e
> the
> > presence at least one row of the list (unless I'm mistaken in my
> reading).
> > >               
> > >                 
> > >                   
> > >                   
> > >                     
> > >                       
> > >                     
> > >                     
> > >                   
> > >                 
> > >               
> > >
> > > A leaf/container would be a simpler example but would result in the
> same
> > lack of enforcement of the mandatory status of an element with a "when"
> > clause.
> > >
> > > This RNG seems consistent with the Schematron rules that "when" makes
> > something optional.
> > >
> > >
> > > I think a workaround would be choice with mandatory true and a when
> clause
> > on the cases. This would ensure that at least one case is present since
> the
> > mandatory clause implements a Schematron existence constraint.
> > >
> > > Thanks
> > > Mike
> > > > -----Original Message-----
> > > > From: Robert Wilton [mailto:rwilton@cisco.com]
> > > > Sent: Wednesday, October 10, 2018 11:33 AM
> > > > To: Michael Rehder ; Ladislav Lhotka
> > > > ; netmod@ietf.org
> > > > Cc: Walker, Jason (Jason_Walker2@comcast.com)
> > > > 
> > > > Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > doesn't ensure presence of the mandatory object
> > > >
> > > > Hi Mike,
> > > >
> > > > I think that the YANG below already enforces what you want, or
> > > > otherwise I don't follow your issue.
> > > >
> > > > The YANG below is valid in two cases:
> > > >
> > > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not present in
> > > > the config (due to the when statement).
> > > > (2) AssignmentMechanism =3D Static, IPAddresses exists and has at
> > > > least one element (due to min-elements 1).
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > On 10/10/2018 16:23, Michael Rehder wrote:
> > > > > Container "foo" would be mandatory if not for the "when" child
> element.
> > > > > With the "when" child element, the logic becomes "inverted" and
> > > > > the
> > > > constraint is a negative one of "disallowed under certain condition=
".
> > > > >
> > > > > The UC is for enforcement in REST API payloads.
> > > > > For a practical example:
> > > > >
> > > > >           leaf AssignmentMechanism {
> > > > >              type enumeration {
> > > > >                enum "DHCP";
> > > > >                enum "Static";
> > > > >              }
> > > > >              mandatory true;
> > > > >              description "The address assignment mechanism.";
> > > > >            }
> > > > >            list IPAddresses {
> > > > >              when "../AssignmentMechanism =3D 'Static'";
> > > > >              key Address;
> > > > >              min-elements 1;
> > > > >
> > > > >              leaf Address {
> > > > >                type capit:IPv4Address;
> > > > >                description "An ipv4 address.";
> > > > >              }
> > > > >             }
> > > > >
> > > > > There is no way in the IPAddresses list to enforce that there is
> > > > > at least one IP
> > > > Address when the assignment method is "Static".
> > > > > One could put a "must" on "AssignmentMechanism" to ensure at leas=
t
> > > > > one
> > > > element of the IPAddresses list when "Static", but I don't see this
> > > > as a good schema design, to have the controlling attribute check
> controlled
> > attributes.
> > > > >
> > > > > I appreciate that this semantic can't be changed in YANG at this
> point.
> > > > > Could the "when" statement have a modifying child element to stat=
e
> > > > > that the
> > > > mandatory status of the element is to be enforced?
> > > > > Like
> > > > >      container foo {
> > > > >        when "condition" {
> > > > >            enforce-mandatory-status;
> > > > >        }
> > > > >
> > > > > There is already back-end for existential checks for mandatory
> > > > > choice so this
> > > > seems reasonably consistent to me.
> > > > > I appreciate there are existing issues for "when" but I don't see
> > > > > why this
> > > > would make things any worse.
> > > > > In fact by promoting a better dependency "direction" between
> > > > > schema
> > > > elements,  think it could simplify things (so I naively think :) ).
> > > > >
> > > > > Thanks
> > > > > Mike
> > > > >> -----Original Message-----
> > > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > > > >> Sent: Wednesday, October 10, 2018 10:28 AM
> > > > >> To: Michael Rehder ; netmod@ietf.org
> > > > >> Subject: Re: [netmod] WHEN statement within mandatory objects
> > > > >> doesn't ensure presence of the mandatory object
> > > > >>
> > > > >> Michael Rehder  writes:
> > > > >>
> > > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D and mandatory ob=
jects.
> > > > >>>
> > > > >>> It seems to me that the implemented semantics of =E2=80=9Cwhen=
=E2=80=9D are
> > > > >>> really
> > > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclosing object ca=
n be absent even
> > > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80=9D clause hol=
ds true.
> > > > >>> The RFC could be clearer about this.
> > > > >>>
> > > > >>> Example
> > > > >>>
> > > > >>>     leaf color {
> > > > >>>       enumeration  {
> > > > >>>          enum =E2=80=9Cblue=E2=80=9D;
> > > > >>>          enum =E2=80=9Cblack=E2=80=9D;
> > > > >>>       }
> > > > >>>       mandatory true;
> > > > >>>     }
> > > > >>>     container foo {
> > > > >>>        when ../color =3D =E2=80=98blue=E2=80=99;
> > > > >>>        etc.
> > > > >>>     }
> > > > >>>
> > > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the presence of the =
=E2=80=9Cwhen=E2=80=9D statement
> > > > >>> even though the object is mandatory (same is true for mandatory
> > > > >>> leaf,
> > > > >>> min-elements=3D1 list etc.).
> > > > >> Maybe you intended to have, e.g., a "mandatory true" leaf inside
> > > > >> "container foo"?
> > > > >>
> > > > >>> This is considered valid XML for the above
> > > > >>>      blue
> > > > >> Yes, it is, under current YANG rules, no matter what "etc."
> > > > >> stands for. Note that evaluation of the XPath expression in this
> > > > >> case (with "foo" missing) requires the peculiar procedure of sec=
.
> 7.21.5
> > in RFC 7950.
> > > > >>
> > > > >>> In my view this makes conditionally variant schemas =E2=80=9Clo=
ose=E2=80=9D in
> > > > >>> their enforcement (some scenarios can use choice but it doesn=
=E2=80=99t
> > > > >>> cover everything).
> > > > >>>
> > > > >>> I think that mandatory should be respected for the enclosing
> > > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement.  That is, a mand=
atory object must
> > > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clause holds true an=
d a Schematron
> > > > >>> statement should enforce that.
> > > > >> In fact, this is one case where the DSDL mapping (RFC 6110)
> > > > >> deviates from YANG 1.0. Nodes that mandatory aren't enclosed in
> > > > >> the RELAX NG  pattern, and are then required no matter
> what
> > any "when"
> > > > >> statements say (because RELAX NG validation comes before
> > Schematron).
> > > > >>
> > > > >>> What is the rationale behind the current YANG rules behavior,
> > > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapping doesn=E2=80=
=99t check for presence of
> > > > >>> the enclosing mandatory object?
> > > > >> FWIW, I have been repeatedly protesting against this behaviour
> > > > >> but without much luck. See for example
> > > > >>
> > > > >> https://www.ietf.org/mail-archive/web/netmod/current/msg14012.ht=
m
> > > > >> l
> > > > >>
> > > > >> As a result, "when" is the trickiest feature in YANG by far.
> > > > >>
> > > > >> Lada
> > > > >>
> > > > >>> thanks
> > > > >>> Mike Rehder
> > > > >> --
> > > > >> Ladislav Lhotka
> > > > >> Head, CZ.NIC Labs
> > > > >> PGP Key ID: 0xB8F92B08A9F76C67
> > > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide,
> > > > > cloud-based
> > > > system. Any emails sent to Amdocs will be processed and stored usin=
g
> > > > such system and are accessible by third party providers of such
> > > > system on a limited basis. Your sending of emails to Amdocs
> > > > evidences your consent to the use of such system and such processin=
g,
> > storing and access=E2=80=9D.
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, wo=
rldwide,
> cloud-based
> > system. Any emails sent to Amdocs will be processed and stored using su=
ch
> > system and are accessible by third party providers of such system on a
> limited
> > basis. Your sending of emails to Amdocs evidences your consent to the
> use of
> > such system and such processing, storing and access=E2=80=9D.
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> 
> > Fax:   +49 421 200 3103         
> =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw=
ide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> *=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, world=
wide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.*
>
>
>
> *=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, world=
wide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.*
>

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




On Thu, Oct 11, 2018 at 11:14 AM, Michael Rehder <=
Michael.Rehd=
er@amdocs.com> wrote:











There is no specific text - the text =
just says it is =E2=80=9Cconditional=E2=80=9D.


However the implementation forces it =
optional:


-=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
The RNG file makes it optional (=
I=E2=80=99m not actually running this for various reasons so I=E2=80=99m ju=
st interpreting the file generated =E2=80=93 maybe I misunderstand
 RNG)


-=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Schematron doesn=E2=80=99t check=
 for its existence (like it does for a mandatory choice case)=



=C2=A0
<=
/blockquote>

So change the implementation so it conforms=
 to the spec.

=C2=A0


Thanks


Mike

Andy
=C2=A0


=C2=A0








From: Andy Bierman [mailto:andy@yumaworks.com]


Sent: Thursday, October 11, 2018 2:06 PM

To: Michael Rehder <Michael.Rehder@Amdocs.com>

Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.=
de>; Walker, Jason (Jason_Walker2@comcast.com) <Jason_Walker2@comcast.com>; netmod@ietf.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn&=
#39;t ensure presence of the mandatory object






=C2=A0




=C2=A0




=C2=A0




On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <=
;Michael.Reh=
der@amdocs.com> wrote:








I think the wording is relevant - som=
ething can be conditional but still required.


It should be clarified that elements =
become implicitly =E2=80=9Cmandatory false=E2=80=9D when a =E2=80=9Cwhen=E2=
=80=9D statement is
 used.


=C2=A0


I would like to see an enhancement to=
 YANG to control this behavior, to allow the mandatory status
 to be enforced.


That is, support also =E2=80=9Ccondit=
ionally required=E2=80=9D instead of only the current =E2=80=9Cconditionall=
y optional=E2=80=9D.


=C2=A0










=C2=A0






=C2=A0






=C2=A0 leaf foo {






=C2=A0 =C2=A0 =C2=A0when "../some-other-node =
=3D 5";






=C2=A0 =C2=A0 =C2=A0type int32;






=C2=A0 =C2=A0 =C2=A0mandatory true;





=C2=A0}






=C2=A0






=C2=A0






This leaf is mandatory if the when-expr is true.<=
/u>






Where is the text in 7950 that says this mandatory t=
rue is ignored if when-stmt is present?






=C2=A0






=C2=A0






=C2=A0










Thanks


Mike










=C2=A0






Andy






=C2=A0






=C2=A0










=C2=A0








From: Andy Bierman [mailto:andy@yumaworks.com]


Sent: Wednesday, October 10, 2018 2:52 PM

To: Michael Rehder <Michael.Rehder@Amdocs.com>

Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni=
versity.de>;
 Walker, Jason (Jason_Walker2@comcast.com) <Jason_Walker2@comcast.c=
om>;
netmod@ietf.or=
g

Subject: Re: [netmod] WHEN statement within mandatory objects doesn&=
#39;t ensure presence of the mandatory object






=C2=A0




=C2=A0




=C2=A0




On Wed, Oct 10, 2018 at 11:44 AM, Michael Rehder <=
;Michael.Reh=
der@amdocs.com> wrote:




Sure.



I think the RFC is unclear since it seems that the semantics are consistent=
 in the back-end checks.

One can read the RFC and not notice by its absence that the when clause doe=
sn't require anything to be present.



=C2=A0 =C2=A0 =C2=A0The "when" statement makes its parent data de=
finition statement conditional.

Should be

=C2=A0 =C2=A0 The "when" statement makes its parent data definiti=
on statement conditional and optional.






=C2=A0






This is not correct.






=C2=A0






Step 1) if-feature makes the schema node conditional=







=C2=A0






Step 2) when-stmt makes instances of the schema-node=
 conditional






=C2=A0






Step 3) YANG validation applies to instances of data=
 nodes (or the YANG default value if applicable)






=C2=A0






Step 2 is only relevant if Step 1 is true or non-exi=
stent






Step 3 is only relevant if Step 2 is true or non-exi=
stent






=C2=A0






Andy






=C2=A0






=C2=A0






I think there should be a more definite statement ab=
out this overriding any mandatory status of the parent data definition stat=
ement.

Like

=C2=A0 =C2=A0 =C2=A0"Any mandatory status of the parent data definitio=
n statement (mandatory statement, min-element statement etc.) is overridden=
 by this statement and made non-mandatory."



That would have made the side-effect of "when" on other declarati=
ons clearer.



Thanks

mike

> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-univers=
ity.de]

> Sent: Wednesday, October 10, 2018 2:25 PM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> Cc: Robert Wilton <rwilton@cisco.com>; Ladislav Lhotka <lhotka@nic.cz>;

> netmod@ietf.org; Walker, Jason (Jason_Walker2@comcast.com)

> <Jas=
on_Walker2@comcast.com>

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn=
9;t

> ensure presence of the mandatory object

> 

> Michael,

> 

> what matters here is what the YANG specification (RFC 7950) says. Is t=
here a

> reason to believe the IPAddresses list in your example can be absent o=
r have no

> elements based on what RFC 7950 says? Or do we talk about a shortcomin=
g of

> RFC 6110?

> 

> /js

> 

> On Wed, Oct 10, 2018 at 06:17:26PM +0000, Michael Rehder wrote:

> > If the list has a "when" clause the RNG file actually p=
roduces a "OneOrMore"

> which has a choice of <empty> or the list so it actually doesn&#=
39;t enforce the

> presence at least one row of the list (unless I'm mistaken in my r=
eading).

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<oneOrMo=
re>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
choice>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0<empty/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0<element name=3D"IPAddresses">

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<element name=3D"Address">

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0<ref name=3D"types__IPv4Address"/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0</element>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<empty/>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0</element>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/choice>

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</oneOrM=
ore>

> >

> > A leaf/container would be a simpler example but would result in t=
he same

> lack of enforcement of the mandatory status of an element with a "=
;when"

> clause.

> >

> > This RNG seems consistent with the Schematron rules that "wh=
en" makes

> something optional.

> >

> >

> > I think a workaround would be choice with mandatory true and a wh=
en clause

> on the cases. This would ensure that at least one case is present sinc=
e the

> mandatory clause implements a Schematron existence constraint.

> >

> > Thanks

> > Mike

> > > -----Original Message-----

> > > From: Robert Wilton [mailto:rwilton@cisco.com]

> > > Sent: Wednesday, October 10, 2018 11:33 AM

> > > To: Michael Rehder <Michael.Rehder@Amdocs.com>; Ladislav Lhotk=
a

> > > <lhotk=
a@nic.cz>; 
netmod@ietf.org

> > > Cc: Walker, Jason (Jason_Walker2@comcast.com)

> > > <Jason_Walker2@comcast.com>

> > > Subject: Re: [netmod] WHEN statement within mandatory object=
s

> > > doesn't ensure presence of the mandatory object

> > >

> > > Hi Mike,

> > >

> > > I think that the YANG below already enforces what you want, =
or

> > > otherwise I don't follow your issue.

> > >

> > > The YANG below is valid in two cases:

> > >

> > > (1) AssignmentMechanism =3D DHCP, and IPAddresses is not pre=
sent in

> > > the config (due to the when statement).

> > > (2) AssignmentMechanism =3D Static, IPAddresses exists and h=
as at

> > > least one element (due to min-elements 1).

> > >

> > > Thanks,

> > > Rob

> > >

> > >

> > > On 10/10/2018 16:23, Michael Rehder wrote:

> > > > Container "foo" would be mandatory if not for=
 the "when" child element.

> > > > With the "when" child element, the logic beco=
mes "inverted" and

> > > > the

> > > constraint is a negative one of "disallowed under certa=
in condition".

> > > >

> > > > The UC is for enforcement in REST API payloads.

> > > > For a practical example:

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf Assignment=
Mechanism {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type en=
umeration {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
enum "DHCP";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
enum "Static";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandato=
ry true;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descrip=
tion "The address assignment mechanism.";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list IPAddress=
es {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when &q=
uot;../AssignmentMechanism =3D 'Static'";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key Add=
ress;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 min-ele=
ments 1;

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf Ad=
dress {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
type capit:IPv4Address;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
description "An ipv4 address.";

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > >

> > > > There is no way in the IPAddresses list to enforce that=
 there is

> > > > at least one IP

> > > Address when the assignment method is "Static".
> > > > One could put a "must" on "AssignmentMec=
hanism" to ensure at least

> > > > one

> > > element of the IPAddresses list when "Static", but=
 I don't see this

> > > as a good schema design, to have the controlling attribute c=
heck controlled

> attributes.

> > > >

> > > > I appreciate that this semantic can't be changed in=
 YANG at this point.

> > > > Could the "when" statement have a modifying c=
hild element to state

> > > > that the

> > > mandatory status of the element is to be enforced?

> > > > Like

> > > >=C2=A0 =C2=A0 =C2=A0 container foo {

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when "condition" {=


> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enforce-mandat=
ory-status;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> > > >

> > > > There is already back-end for existential checks for ma=
ndatory

> > > > choice so this

> > > seems reasonably consistent to me.

> > > > I appreciate there are existing issues for "when&q=
uot; but I don't see

> > > > why this

> > > would make things any worse.

> > > > In fact by promoting a better dependency "directio=
n" between

> > > > schema

> > > elements,=C2=A0 think it could simplify things (so I naively=
 think :) ).

> > > >

> > > > Thanks

> > > > Mike

> > > >> -----Original Message-----

> > > >> From: Ladislav Lhotka [mailto:lhotka@nic.cz]

> > > >> Sent: Wednesday, October 10, 2018 10:28 AM

> > > >> To: Michael Rehder <Michael.Rehder@Amdocs.com>;
netmod@ietf.org
> > > >> Subject: Re: [netmod] WHEN statement within mandato=
ry objects

> > > >> doesn't ensure presence of the mandatory object=


> > > >>

> > > >> Michael Rehder <Michael.Rehder@Amdocs.com> writes:
> > > >>

> > > >>> I have a question about =E2=80=9Cwhen=E2=80=9D =
and mandatory objects.

> > > >>>

> > > >>> It seems to me that the implemented semantics o=
f =E2=80=9Cwhen=E2=80=9D are

> > > >>> really

> > > >> =E2=80=9Coptional when=E2=80=9D, in that the enclos=
ing object can be absent even

> > > >> though it is mandatory and the =E2=80=9Cwhen=E2=80=
=9D clause holds true.

> > > >>> The RFC could be clearer about this.

> > > >>>

> > > >>> Example

> > > >>>

> > > >>>=C2=A0 =C2=A0 =C2=A0leaf color {

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration=C2=A0 {
> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80=
=9Cblue=E2=80=9D;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum =E2=80=
=9Cblack=E2=80=9D;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;

> > > >>>=C2=A0 =C2=A0 =C2=A0}

> > > >>>=C2=A0 =C2=A0 =C2=A0container foo {

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 when ../color =3D =
=E2=80=98blue=E2=80=99;

> > > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 etc.

> > > >>>=C2=A0 =C2=A0 =C2=A0}

> > > >>>

> > > >>> =E2=80=9Cfoo=E2=80=9D is optional due to the pr=
esence of the =E2=80=9Cwhen=E2=80=9D statement

> > > >>> even though the object is mandatory (same is tr=
ue for mandatory

> > > >>> leaf,

> > > >>> min-elements=3D1 list etc.).

> > > >> Maybe you intended to have, e.g., a "mandatory=
 true" leaf inside

> > > >> "container foo"?

> > > >>

> > > >>> This is considered valid XML for the above

> > > >>>=C2=A0 =C2=A0 =C2=A0 <color>blue</color=
>

> > > >> Yes, it is, under current YANG rules, no matter wha=
t "etc."

> > > >> stands for. Note that evaluation of the XPath expre=
ssion in this

> > > >> case (with "foo" missing) requires the pe=
culiar procedure of sec. 7.21.5

> in RFC 7950.

> > > >>

> > > >>> In my view this makes conditionally variant sch=
emas =E2=80=9Cloose=E2=80=9D in

> > > >>> their enforcement (some scenarios can use choic=
e but it doesn=E2=80=99t

> > > >>> cover everything).

> > > >>>

> > > >>> I think that mandatory should be respected for =
the enclosing

> > > >>> objects of a =E2=80=9Cwhen=E2=80=9D statement.=
=C2=A0 That is, a mandatory object must

> > > >>> be present when its =E2=80=9Cwhen=E2=80=9D clau=
se holds true and a Schematron

> > > >>> statement should enforce that.

> > > >> In fact, this is one case where the DSDL mapping (R=
FC 6110)

> > > >> deviates from YANG 1.0. Nodes that mandatory aren&#=
39;t enclosed in

> > > >> the RELAX NG <optional> pattern, and are then=
 required no matter what

> any "when"

> > > >> statements say (because RELAX NG validation comes b=
efore

> Schematron).

> > > >>

> > > >>> What is the rationale behind the current YANG r=
ules behavior,

> > > >>> that the =E2=80=9Cwhen=E2=80=9D Schematron mapp=
ing doesn=E2=80=99t check for presence of

> > > >>> the enclosing mandatory object?

> > > >> FWIW, I have been repeatedly protesting against thi=
s behaviour

> > > >> but without much luck. See for example

> > > >>

> > > >> 
https://www.ietf.org/mail-archive/web/netmod/current/msg14012.htm=


> > > >> l

> > > >>

> > > >> As a result, "when" is the trickiest feat=
ure in YANG by far.

> > > >>

> > > >> Lada

> > > >>

> > > >>> thanks

> > > >>> Mike Rehder

> > > >> --

> > > >> Ladislav Lhotka

> > > >> Head, CZ.NIC Labs

> > > >> PGP Key ID: 0xB8F92B08A9F76C67

> > > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a t=
hird-party, worldwide,

> > > > cloud-based

> > > system. Any emails sent to Amdocs will be processed and stor=
ed using

> > > such system and are accessible by third party providers of s=
uch

> > > system on a limited basis. Your sending of emails to Amdocs<=
br>
> > > evidences your consent to the use of such system and such pr=
ocessing,

> storing and access=E2=80=9D.

> > > > _______________________________________________
> > > > netmod mailing list

> > > > ne=
tmod@ietf.org

> > > > https://www.ietf.org/mailman/listinfo/netmod
> >

> > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access=E2=80=9D.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.=
org

> > https://www.ietf.org/mailman/listinfo/netmod

> 

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen=
 | Germany

> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
;https://ww=
w.jacobs-university.de/>

=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldwid=
e, cloud-based system. Any emails sent to Amdocs will be processed and stor=
ed using such system and are accessible by third party providers of such sy=
stem on a limited basis. Your sending of emails
 to Amdocs evidences your consent to the use of such system and such proces=
sing, storing and access=E2=80=9D.

_______________________________________________

netmod mailing list

netmod@ietf.org
=
https://www.ietf.org/mailman/listinfo/netmod






=C2=A0











=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw=
ide, cloud-based system. Any emails sent to Amdocs will be processed and st=
ored using such system and are accessible by third party providers
 of such system on a limited basis. Your sending of emails to Amdocs eviden=
ces your consent to the use of such system and such processing, storing and=
 access=E2=80=9D.








=C2=A0










=E2=80=9CAmdocs=E2=80=99 email
platform is based on a third-party, worldwide, cloud-based system. Any
emails sent to Amdocs will be processed and stored using such system and ar=
e accessible
by third party providers of such system on a limited basis. Your sending of
emails to Amdocs evidences your consent to the use of such system and such
processing, storing and access=E2=80=9D.









--000000000000bd700e0577f86945--


From nobody Thu Oct 11 11:49:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA450130ECF; Thu, 11 Oct 2018 11:49:08 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqjOA0En_zJi; Thu, 11 Oct 2018 11:49:06 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 ECEB212008A; Thu, 11 Oct 2018 11:49:05 -0700 (PDT)
X-AuditID: 1209190e-803ff7000000723e-dd-5bbf9b1fa781
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 55.CE.29246.02B9FBB5; Thu, 11 Oct 2018 14:49:04 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w9BImwwX024705; Thu, 11 Oct 2018 14:48:59 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9BImqVO013900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2018 14:48:55 -0400
Date: Thu, 11 Oct 2018 13:48:52 -0500
From: Benjamin Kaduk 
To: Martin Bjorklund 
Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com,  lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org
Message-ID: <20181011184852.GU3293@kduck.kaduk.org>
References: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> <20181010.153528.100217893480849067.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181010.153528.100217893480849067.mbj@tail-f.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixG6noqswe3+0wbJr2hYTD9hbzPgzkdli 97zL7BYH5rBbdDS/ZbHo7n7GbrG6V81i/sVGVgcOj52z7rJ7LFnyk8njetNVdo8Pm5rZPDb+ WswSwBrFZZOSmpNZllqkb5fAlXHnclDBKfeK13PmMzYwHrfoYuTkkBAwkfh4+wxjFyMXh5DA YiaJFYtbWSGcjYwSk26uZQSpEhK4yiTx8LoqiM0ioCqx9tNTJhCbTUBFoqH7MjOILQIUf7Jz LQtIM7PAOkaJ+12zWEESwgKJEpMmzGUDsXkFjCXWL1oJta6ZUeLVjW3sEAlBiZMzn7CA2MwC WhI3/r0E2sABZEtLLP/HARLmFHCQeP7kLNgyUQFlib19h9gnMArMQtI9C0n3LITuBYzMqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYJCn1OSbwfjpAbvQ4wCHIxKPLw/Ju6P FmJNLCuuzD3EKMnBpCTKe8QLKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV3/Gvmgh3pTEyqrU onyYlDQHi5I474SWxdFCAumJJanZqakFqUUwWRkODiUJ3spZQEMFi1LTUyvSMnNKENJMHJwg w3mAhk8CqeEtLkjMLc5Mh8ifYjTmaHt6fQYzRweIFGLJy89LlRLntQQpFQApzSjNg5sGSl8S 2ftrXjGKAz0nzHtgJlAVDzD1wc17BbSKCWjVqZA9IKtKEhFSUg2MSvO4OcsW3Pi6vWvW3Vvf HjV8LYlxXx97zetcctalPw6TJmzg+ZoRtItnwco7CRu/CavPjOnV7ufL25Q7+fBpk1B2de5m w5KXkiYFPz7Mrzr1+m5we4tgjQNTjmXU1GOR++4ktpqJbLh2d2H4l/uOtlyin/R5a/VtJY90 p85s15ttlbVyXoO+EktxRqKhFnNRcSIAr3FMjToDAAA=
Archived-At: 
Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 18:49:09 -0000

On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Benjamin Kaduk  wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-schema-mount-11: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Whenever we introduce a new namespace "sub-hierarchy" there is some level
> > of risk about surpirses with respect to the security properties of the
> > combined system.  I appreciate that the mounted schemas are "jailed" into
> > their own subtree except for the specific exceptions for XPath access,
> > which helps a lot.  But there may still be potential for surprise with
> > respect to, e.g., access control on mounted schemas, if an administrator
> > previously assumed that such controls would only be needed at the
> > top-level.  The document itself doesn't give me a great picture of to what
> > extent these risks and the possible consequences of the new nested
> > structure have been considered; I'd be happy to hear if they've been
> > thought about a lot already and the conclusion was that the situation is so
> > boring that nothing needs to be mentioned in the document.
> 
> The intention was that this is covered in Section 7, Interaction with
> the Network Configuration Access Control Model (NACM).
> 
> But it is probably a good idea to explicitly mention this in the
> Security Considerations section as well (together with your last point
> below).  So maybe add a paragraph at the end of Section 11:
> 
>   It is important to take the security considerations for all nodes in
>   the mounted schemas into account, and control access to these nodes
>   by using the mechanism described in Section 7.

I guess this addresses my concern; thanks.

> > Section 3.3
> > 
> >    If multiple mount points with the same name are defined in the same
> >    module - either directly or because the mount point is defined in a
> >    grouping and the grouping is used multiple times - then the
> >    corresponding "mount-point" entry applies equally to all such mount
> >    points.
> > 
> > Does this mean that the multiple mount points must serve the same
> > data/contents, or just that they must use the same schema?
> > (Is this related to "inline" vs. "shared-schema"?)
> 
> No, this document intentionally doesn't assume anything about the
> source of the instance data (as explained in section 1).  So the
> answer is that they just use the same schema.
> 
> > Section 3.4
> > 
> > So this means that there can be multiple
> > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> > locations in the hierarchy?  When I was first reading the document, the
> > design seemed fairly clean with just a single list of mount-points at the
> > "top-level" that tracks everything, but this kind of recursion seems like
> > it would make implementation potentially quite complex.  What kind of
> > implementation experience do we have that can replace my half-informed
> > suppositions about complexity?
> 
> I agree with you that multiple levels of mounting probably can be
> complex.  But there is nothing in the design of schema mount that
> prohibits this.  In fact, it "falls out for free" from the design.
> 
> A 2-level example is a physical device with LNEs
> (draft-ietf-rtgwg-lne-model) which has NIs
> (draft-ietf-rtgwg-ni-model).
> 
> > Section 4
> > 
> >    Therefore, schema mount also allows for such references.  For every
> >    mount point in the "shared-schema" case, it is possible to specify a
> >    leaf-list named "parent-reference" that contains zero or more XPath
> >    1.0 expressions.  [...]
> > 
> > editorial: """the "shared-schema" case""" reads oddly to me; it might be
> > clearer to refer to schemas mounted using "shared-schema" instead.  As in,
> > """For every mount point under "shared-schema", [...]"""
> 
> We use the wording "in the 'shared-schema' case" in a couple of
> places.  I don't think "mount point under 'shared-schema'" is
> correct.

Okay.

> > Can we get a reference added for XPath?
> 
> Sure, I will add this.
> 
> > It's still a little unclear to me exactly how a node in the mounted tree
> > constructs an XPath expression to refer to the parent-reference
> > nodes
> 
> It's rather the other way around.  If a node in the mounted schema has
> an XPath expression that refers to a node that is not part of the
> jailed mounted schema, that node can be brought in by the
> parent-reference expressions.   An example of this is given in A.3
> where an "outgoing-interface" (which is a reference to
> /if:interfaces/if:interface/if:name) works thanks to the
> parent-reference.

Sorry for being dense here.  Just to check -- the idea is that I have
an existing schema that has references to external nodes, and those
external references are represented as "absolute paths" from the root node.
When I mount that existing schema, because of the namespace jailing, it
goes looking for the external reference from that path but starting at the
mountpoint instead of the real root, and the referred-to node is only
present in the mounted hierarchy if the external module in question is also
part of the same mounted schema.  What the parent-reference is doing is
allowing this absolute-path external node reference to escape the mounted
hierarchy and find the corresponding nodes from the top-level.
So there's no new "construction" of XPath expressions; it's just allowing
existing references to continue to work.

Do we need to specify a search order when there are multiple levels of
hierarchical mounts and a referred-to external node is present at both the
top-level and an intermediate mount level?

> >, but
> > I did not read very far down the reference chain and maybe this is going to
> > be clear to a practitioner without any more text in the document.
> > Basically, do I need to know where I am mounted in order to construct
> > references to nodes in the parent?
> > 
> > Section 7
> > 
> > NACM "can be used" to control access to mounted nodes.  Is there a risk
> > that administrators will be "unpleasantly surprised" by mounted nodes by
> > default not receiving access control, in cases when access control is
> > already configured at the top level?
> 
> Mounted nodes are no different that normal nodes in this regard; i.e.,
> if NACM is configured to provide read access by default, this read
> access is applied to all nodes, mounted or not.

I think I'm considering a somewhat different case, with read-write access
by default but certain hierarchies restricted to read-only.  If those
hierarchies are then mounted in a subtree, the read-only restriction could
be absent in some cases.

> Maybe we should do:
> 
> OLD:
> 
>    If NACM [RFC8341] is implemented on a server, it can be used to
>    control access
> 
> NEW:
> 
>    If NACM [RFC8341] is implemented on a server, it is used to
>    control access 
> 
> to emphasize that no additional steps need to be taken by the
> administrator if NACM is used in the first place.

Combined with the new paragraph in the security considerations, I think
this would account for everything; thanks.

> > Section 9
> > 
> > Should the top-level module description be using the RFC 8174 boilerplate
> > instead of thet 2119 boilerplate?
> 
> Yes, I will fix.
> 
> > Should the requirement for servers that mount any schema to also mount
> > ietf-yang-library under the mountpoint be mentioned somewhere other than
> > the description for the 'inline' and 'shared-schema' containers (i.e., in
> > the discussion text)?
> 
> Section 3.3 says:
> 
>    The mounted schema is determined at run time: every instance of the
>    mount point that exists in the operational state MUST contain a copy
>    of YANG library data that defines the mounted schema exactly as for a
>    top-level schema. 

"contain a copy of YANG library data" only mostly translates to "mount
ietf-yang-library".  It might be beneficial to be more explicit and/or cite
rfc7895bis here (but this is a non-blocking comment, so do what you think
is best).

-Benjamin

> > Section 11
> > 
> > We should probably also have some bland statement about how "the security
> > considerations for mounted schemas continue to apply to the nodes in the
> > mounted tree".
> 
> Yes, see my proposed text above.
> 
> 
> /martin


From nobody Thu Oct 11 12:42:13 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB6130DE7 for ; Thu, 11 Oct 2018 12:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6-z6n8bjEdS7 for ; Thu, 11 Oct 2018 12:42:10 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 53FF8130ED7 for ; Thu, 11 Oct 2018 12:42:10 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id v133-v6so4657380pgb.2 for ; Thu, 11 Oct 2018 12:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ACbDFirW7jPE1aetsFXxHFh2GS1CJk+uPxP3e0eZTVg=; b=NYyaOnU04gtHd/ysoscV5yI8h0oen1CYvb96u2v9e26tPEZ/xAJWSCLG2eaXqx9ImD rVvqezVOLQWmwWRiEJf68956VXcbkK7Lj7IR2b5v19H7uVxj8jMH45pYuk+EGhDhVL0o W1hqhXQyD0TYvvlVHT4b/9Eru0BE0/W3H3eF4+ITEtBg9+2Db2ZrMXQO9Rx2yLXYCEjd sG6XpkXMAG3DLGm7J2pUvzyeapGTGWLc921UErRyKCDY1puv+xaAnR5wt7CYApaMsp8Z 8c4uUQFZ31vzMWtQJJu+bGwz3n8Haxn8PlC9tWZ1R4jn4uXE1aMpi/wQBhfRGA2Uldvh gkJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ACbDFirW7jPE1aetsFXxHFh2GS1CJk+uPxP3e0eZTVg=; b=tdWkvgOZzH13zsCVi8axKmVQMOhi9FmsEquR85W4rtf7xXEMVIXTIWQ4cf5Rcvf3wm Gdfhx2J0Y8N4D8nsmNzW7eOciCtT0/1GQRieWM6MVibXNitEmkS+K0RT4+QK0sPDB2nJ Br/BFk/NWwcmVitY3nSkFMOAqw0po5fUJ4QtQQ8ZdaUTx+goTcREW229rzEnNTaSD2OS qNVzi7pEJ1GubdvQ1OlKNYoqECni3kZ8mezlhG7N62oaClsmJJ77OyvwYkPshYzjFbAV WHmjKDQgxphHW91D5x2oNj+HxE4p4hVrxrVWe2B7IQw431nMMQBGFPwYQva5/o2QkQX3 +Qag==
X-Gm-Message-State: ABuFfoj9GXXv3qWofXz6OUYruv8pP9TdDpNK8lNGHmDL7nYjb0uKB/hZ HDqCvC+EEbXVffDMKp/VWwQ=
X-Google-Smtp-Source: ACcGV6058SC32/8qg8KeqRhZmzXt/wtErorxaLdpppygEgoyAZ4R5lhbHY9uA1hHPBvW1dokcuzEbA==
X-Received: by 2002:a62:1b45:: with SMTP id b66-v6mr2887606pfb.94.1539286929726;  Thu, 11 Oct 2018 12:42:09 -0700 (PDT)
Received: from [10.33.122.212] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id g123-v6sm34907029pfc.67.2018.10.11.12.42.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 12:42:08 -0700 (PDT)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB23E603-A815-40B5-96D0-0C45FEF57744"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 11 Oct 2018 12:42:07 -0700
In-Reply-To: <20181011.170459.1195717619306547806.mbj@tail-f.com>
Cc: jernej.tuljak@mg-soft.si, netmod@ietf.org
To: Martin Bjorklund 
References:  <20181011.085131.1823310178537216646.mbj@tail-f.com> <2DC2347C-3029-4033-BC35-9F308201ADF4@gmail.com> <20181011.170459.1195717619306547806.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Place to download Standard YANG Modules ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2018 19:42:12 -0000

--Apple-Mail=_AB23E603-A815-40B5-96D0-0C45FEF57744
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



> On Oct 11, 2018, at 8:04 AM, Martin Bjorklund  wrote:
> 
> Mahesh Jethanandani  wrote:
>> 
>> 
>>> On Oct 10, 2018, at 11:51 PM, Martin Bjorklund  wrote:
>>> 
>>> I just which there was a one-click way (or better some repo) to get
>>> all files.
>> 
>> There is. Benoit had written it, but for the life of me I cannot
>> remember what it is called.
> 
> I meant from IANA.  3rd party mirrored repos are fine, but it would be
> nice to get them directly from IANA in a simple way.

Ok. Here is the process.

You can get the entire IANA repository by doing this:

rsync -avzH rsync.iana.org ::assignments std/iana

But if you care just about the YANG models in the IANA repository, do this:

rsync -avz --delete rsync.ietf.org::iana/yang-parameters .

> 
> 
> /martin

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_AB23E603-A815-40B5-96D0-0C45FEF57744
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Oct 11, 2018, at 8:04 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:


On Oct 10, 2018, at =
11:51 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

I =
just which there was a one-click way (or better some repo) to get
all files.

There =
is. Benoit had written it, but for the life of me I cannot
remember what it is called.

I meant from IANA.  3rd party mirrored repos are fine, =
but it would be
nice to get them directly from IANA in a =
simple way.

Ok. Here is the process.

You can get the entire IANA repository by doing =
this:

rsync -avzH rsync.iana.org::assignments =
std/iana

But if you care just about the =
YANG models in the IANA repository, do this:

rsync =
-avz --delete rsync.ietf.org::iana/yang-parameters =
.



/martin



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_AB23E603-A815-40B5-96D0-0C45FEF57744--


From nobody Fri Oct 12 01:37:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B549D130DC4 for ; Fri, 12 Oct 2018 01:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVNhQ-804c3A for ; Fri, 12 Oct 2018 01:37:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B586130DC2 for ; Fri, 12 Oct 2018 01:37:29 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id F2D161AE08F5; Fri, 12 Oct 2018 10:37:27 +0200 (CEST)
Date: Fri, 12 Oct 2018 10:37:27 +0200 (CEST)
Message-Id: <20181012.103727.731509761734796510.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
References: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 08:37:32 -0000

Robert Wilton  wrote:
> =

> =

> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 11/10/2018 11:50, Martin Bjorklund wrote:
> >>> Robert Wilton  wrote:
> >>>> On 11/10/2018 11:21, Martin Bjorklund wrote:
> >>>>> Andy Bierman  wrote:
> >>>>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Andy Bierman  wrote:
> >>>>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>>>>>> rrahman@cisco.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklu=
nd" <
> >>>>>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:=

> >>>>>>>>>
> >>>>>>>>>        Ladislav Lhotka  wrote:
> >>>>>>>>>        > Martin Bjorklund  writes:
> >>>>>>>>>        >
> >>>>>>>>>        > > Hi,
> >>>>>>>>>        > >
> >>>>>>>>>        > > While reviewing restconf-notif, I saw this examp=
le:
> >>>>>>>>>        > >
> >>>>>>>>>        > >    {
> >>>>>>>>>        > >       "ietf-subscribed-notifications:input": {
> >>>>>>>>>        > >          "stream": "NETCONF",
> >>>>>>>>>        > >          "stream-xpath-filter": "/ds:foo/",
> >>>>>>>>>        > >          "dscp": "10"
> >>>>>>>>>        > >       }
> >>>>>>>>>        > >    }
> >>>>>>>>>        > >
> >>>>>>>>>        > > Note the "stream-xpath-filter".  It has a prefix=
 in the
> >>>>>>>>>        > > XPath
> >>>>>>>>> string.
> >>>>>>>>>        > > How are prefixes declared when JSON is used?
> >>>>>>>>>        > >
> >>>>>>>>>        > > The leaf "stream-xpath-filter" says:
> >>>>>>>>>        > >
> >>>>>>>>>        > >               o The set of namespace declaration=
s are
> >>>>>>>>>        > >               those
> >>>>>>>>>        > >               in
> >>>>>>>>> scope on
> >>>>>>>>>        > >                  the 'stream-xpath-filter' leaf =
element.
> >>>>>>>>>        > >
> >>>>>>>>>        > > (I think I provided that text...)
> >>>>>>>>>        > >
> >>>>>>>>>        > > This assumes that the encoding is XML, or at lea=
s that the
> >>>>>>> encoding
> >>>>>>>>>        > > can somehow transfer namespace declarations.
> >>>>>>>>>        >
> >>>>>>>>>        > It can't. There are two options:
> >>>>>>>>>        >
> >>>>>>>>>        > 1. have different representations of this value in=
 XML and
> >>>>>>>>>        > JSON,
> >>>>>>>>>        >    analogically to instance indentifiers (sec. 6.1=
1 in RFC
> >>>>>>>>>        >    7951).
> >>>>>>>>>        >
> >>>>>>>>>        > 2. use a module name rather than a prefix in XML, =
too.
> >>>>>>>>>        >
> >>>>>>>>>        > I would suggest #2.
> >>>>>>>>>  But that means making non-backwards compatible change =
to the XML
> >>>>>>>>> representation?
> >>>>>>>>>
> >>>>>>>> Not really. It means NETMOD WG would be creating its own spe=
cial
> >>>>>>>> variant
> >>>>>>> of
> >>>>>>>> XPath.
> >>>>>>> Not at all.  What I propose is perfectly fine, legal XPath 1.=
0.
> >>>>>>>
> >>>>>>> XPath 1.0 says that an XPath expression is evaluated in a con=
text.
> >>>>>>> One item in the context is a set of mappings from  to=
 ,
> >>>>>>> where  is used to lookup prefixes used in the XPath
> >>>>>>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
> >>>>>>>
> >>>>>>> It is perfectly fine to say that the prefix mapping set is th=
is:
> >>>>>>>
> >>>>>>>       "ietf-interfaces" ->
> >>>>>>>       "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>>>       "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-=
ip"
> >>>>>>>
> >>>>>>> and use that to evaluate the expression
> >>>>>>>
> >>>>>>>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ie=
tf-ip/ipv4
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> The XPath expression is normally parsed within an XML instance=

> >>>>>> document.
> >>>>>> There are "xmlns" attributes present that map the prefix to a
> >>>>>> namespace URI.
> >>>>>> These mappings will not be present in the JSON at all.
> >>>>>>
> >>>>>> A custom XPath implementation is required to magically identif=
y the
> >>>>>> prefix
> >>>>>> as a module name and magically find the namespace URI for the =
module
> >>>>>> name.
> >>>>> I disagree.  You need an XPath implementation + custom code to =
set up
> >>>>> the environment.
> >>>> This is OK, but can we just use the JSON encoding instance ident=
ifier
> >>>> format exactly?=A0 I.e .RFC 7951 section 6.11.
> >>>>
> >>>> So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
> >>>>
> >>>> can trivially be expanded to:
> >>>>
> >>>> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:i=
pv4/ietf-ip:enabled",
> >>>>
> >>>> and then interpreted with the context:
> >>>>        "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-in=
terfaces"
> >>>>      "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
> >>> *this* would require a custom XPath implementation.
> >> Why?=A0 I.e. how is this different from stating "Custom code is ne=
eded
> >> to connect things together"?
> > B/c the specification of XPath allows you to (actually, *requires* =
you
> > to) construct the set of prefix strings to url mappings.
> >
> > This is "custom code to connect things".
> >
> > But changing the syntax means changin the specification.
> Not really.
> =

> It would just mean that the filter value is not an "Xpath"
> expression.=A0 It is a more a concise string that can be expanded int=
o
> an Xpath expression.
> =

> >
> >>> and it is not obvious what the rules for the "auto-assignment" of=

> >>> prefixes would be.  For example:
> >>>
> >>>     /ietf-interfaces//ietf-ip:address[../foo]
> >>>
> >>> what is the prefix for "foo"?
> >> OK, so here the module for "../foo" would need to be specified.
> >>
> >> Perhaps the rule that I'm looking for is the module name may be
> >> omitted when it matches the parent node module, and can easily be
> >> inferred.=A0 I.e. so that for any XPath string, it is possible to
> >> trivially expand it without any additional schema context.
> >>
> >> It just seems to be that requiring the long hand of
> >> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv=
4/ietf-ip:enabled"
> >> seems like it will get very verbose, and I wonder whether we are
> >> introducing yet another Xpath format to YANG.
> > I agree that it is very verbose.  But do not mix XPath expressions =
in
> > leaf values (which is what this thread is about) with
> > instance-identfiers.
> OK, but ultimately:
> - these are both leaf values.
> - they both identify nodes in a YANG datastore.
> - the fact that their format is somewhat subtlety different will catc=
h
>   people out.

Agreed.

We already have:

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes

So an alternative could be to use different encodings for
"stream-xpath-filter" as well, depending on if it is XML or JSON.

So, we could do in SN:

             o  If the node is encoded in XML, the set of namespace
                declarations are those in scope on the
                'stream-xpath-filter' leaf element.

             o  If the node is encoded in JSON, the set of namespace
                declarations is the set of prefix and namespace pairs
                for all supported YANG modules, where the prefix is
                the YANG module name and the namespace is as defined
                by the "namespace" statement in the YANG module.

This is far from perfect, but at least the format is consistent within
each encoding.  One problem is that it is unclear how to handle other
encodings.


If we do this, we'll set a precedence for future models.

Now, suppose we have a module "ex-foo" with namespace
"urn:example:foo".  If an XML client writes:

   
     /f:bar/f:baz
   

a JSON will read this node as:

   "example-expr": "/ex-foo:bar/ex-foo:baz"


[This context-dependent encoding that we have for a couple of types is
probably the biggest mistake in YANG]


BTW, we already have this issue w/ NACM's node-instance-identifier.
It is highly unclear what a JSON client is supposed to see if it reads
NACM rules with node-instance-identifiers.

> >> Finally, I'm trying to figure out have RFC 8040 query parameter (s=
ect
> >> 4.8.4), which also uses XPath expressions is meant to work. That
> >> states:
> >>
> >> The set of namespace declarations is the set of prefix and
> >>        namespace pairs for all supported YANG modules, where the p=
refix
> >>        is the YANG module name and the namespace is as defined by =
the
> >>        "namespace" statement in the YANG module.
> > Perfect!  It seems the authors of 8040 thought of this ;-)
> OK, what you propose would at least be consistent with how the XPath
> is formed in sec 8040, 4.8.4?
> =

> I can live with that.=A0 But still strongly think that WG should thin=
k
> of trying to move YANG on from Xpath 1.0.
> =

> >
> >> Yet the examples in section 8.3.6 don't seem to use namespace pref=
ixes
> >> in very many places, e.g. why is it "/example-mod:event1/name=3D'j=
oe'"
> >> and not "/example-mod:event1/example-mod:name=3D'joe'"?=A0 Is the =
example
> >> wrong, or otherwise what am I missing? :-)
> > It seems the example is wrong!
> Please can you check section 8040, 8.3.6.=A0 Are all the examples wro=
ng?

Yes it seems so.  Except the last one.


/martin


From nobody Fri Oct 12 02:44:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA58F130DC5 for ; Fri, 12 Oct 2018 02:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.957
X-Spam-Level: 
X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 PDTA0udmkXX3 for ; Fri, 12 Oct 2018 02:44:35 -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 8368B130DC0 for ; Fri, 12 Oct 2018 02:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11295; q=dns/txt; s=iport; t=1539337474; x=1540547074; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WDRx+aXpK8pFyOtrkzx6zxu91DtLYf3fzA1R8y6pvfU=; b=XuxRcJm+80UhZlYOfAc1FOraeUkP2y0OqgPj1JxlNACuivfbTHXc2Rhq XRRJLA51H6ZZeukrv651CWHF0dlfd3JVl4T1QtbHiVnc+Ly7azp/uYh2o XgkuBxjQ6/Ktiet9vnK4oX1PCrqiYBr0hGWaaZpDlBot9eqhYWDzaKhqA U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAD9a8Bb/xbLJq1aChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgWWDVxIog3WIdY07CCWZAQ2EbAKEdzgWAQMBAQIBAQJtKIU?= =?us-ascii?q?5AQEBAwEjBAsBBUEQCw4KAgImAgJXBgoDBgIBAYMcgXoIpVh7M4R3hGqBC4p?= =?us-ascii?q?SgUE/gRInDIJfhFODLIJXAohhhVmPD1MJkFIGF4FPhG+CayaGR49uhjaBWiG?= =?us-ascii?q?BVTMaCBsVgyeQVz4wjFcBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,371,1534809600";  d="scan'208";a="7125615"
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 2018 09:44:32 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9C9iVGg006981; Fri, 12 Oct 2018 09:44:31 GMT
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod@ietf.org
References: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <02d21880-4268-e1b5-80c1-5db432813508@cisco.com>
Date: Fri, 12 Oct 2018 10:44:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181012.103727.731509761734796510.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 09:44:38 -0000

On 12/10/2018 09:37, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>>
>> On 11/10/2018 17:11, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
>>>> On 11/10/2018 11:50, Martin Bjorklund wrote:
>>>>> Robert Wilton  wrote:
>>>>>> On 11/10/2018 11:21, Martin Bjorklund wrote:
>>>>>>> Andy Bierman  wrote:
>>>>>>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Andy Bierman  wrote:
>>>>>>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
>>>>>>>>> rrahman@cisco.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>>>>>>>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>         Ladislav Lhotka  wrote:
>>>>>>>>>>>         > Martin Bjorklund  writes:
>>>>>>>>>>>         >
>>>>>>>>>>>         > > Hi,
>>>>>>>>>>>         > >
>>>>>>>>>>>         > > While reviewing restconf-notif, I saw this example:
>>>>>>>>>>>         > >
>>>>>>>>>>>         > >    {
>>>>>>>>>>>         > >       "ietf-subscribed-notifications:input": {
>>>>>>>>>>>         > >          "stream": "NETCONF",
>>>>>>>>>>>         > >          "stream-xpath-filter": "/ds:foo/",
>>>>>>>>>>>         > >          "dscp": "10"
>>>>>>>>>>>         > >       }
>>>>>>>>>>>         > >    }
>>>>>>>>>>>         > >
>>>>>>>>>>>         > > Note the "stream-xpath-filter".  It has a prefix in the
>>>>>>>>>>>         > > XPath
>>>>>>>>>>> string.
>>>>>>>>>>>         > > How are prefixes declared when JSON is used?
>>>>>>>>>>>         > >
>>>>>>>>>>>         > > The leaf "stream-xpath-filter" says:
>>>>>>>>>>>         > >
>>>>>>>>>>>         > >               o The set of namespace declarations are
>>>>>>>>>>>         > >               those
>>>>>>>>>>>         > >               in
>>>>>>>>>>> scope on
>>>>>>>>>>>         > >                  the 'stream-xpath-filter' leaf element.
>>>>>>>>>>>         > >
>>>>>>>>>>>         > > (I think I provided that text...)
>>>>>>>>>>>         > >
>>>>>>>>>>>         > > This assumes that the encoding is XML, or at leas that the
>>>>>>>>> encoding
>>>>>>>>>>>         > > can somehow transfer namespace declarations.
>>>>>>>>>>>         >
>>>>>>>>>>>         > It can't. There are two options:
>>>>>>>>>>>         >
>>>>>>>>>>>         > 1. have different representations of this value in XML and
>>>>>>>>>>>         > JSON,
>>>>>>>>>>>         >    analogically to instance indentifiers (sec. 6.11 in RFC
>>>>>>>>>>>         >    7951).
>>>>>>>>>>>         >
>>>>>>>>>>>         > 2. use a module name rather than a prefix in XML, too.
>>>>>>>>>>>         >
>>>>>>>>>>>         > I would suggest #2.
>>>>>>>>>>>  But that means making non-backwards compatible change to the XML
>>>>>>>>>>> representation?
>>>>>>>>>>>
>>>>>>>>>> Not really. It means NETMOD WG would be creating its own special
>>>>>>>>>> variant
>>>>>>>>> of
>>>>>>>>>> XPath.
>>>>>>>>> Not at all.  What I propose is perfectly fine, legal XPath 1.0.
>>>>>>>>>
>>>>>>>>> XPath 1.0 says that an XPath expression is evaluated in a context.
>>>>>>>>> One item in the context is a set of mappings from  to ,
>>>>>>>>> where  is used to lookup prefixes used in the XPath
>>>>>>>>> expression, e.g. in "/foo:interfaces" "foo" is the prefix.
>>>>>>>>>
>>>>>>>>> It is perfectly fine to say that the prefix mapping set is this:
>>>>>>>>>
>>>>>>>>>        "ietf-interfaces" ->
>>>>>>>>>        "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>>>>>>        "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
>>>>>>>>>
>>>>>>>>> and use that to evaluate the expression
>>>>>>>>>
>>>>>>>>>       /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The XPath expression is normally parsed within an XML instance
>>>>>>>> document.
>>>>>>>> There are "xmlns" attributes present that map the prefix to a
>>>>>>>> namespace URI.
>>>>>>>> These mappings will not be present in the JSON at all.
>>>>>>>>
>>>>>>>> A custom XPath implementation is required to magically identify the
>>>>>>>> prefix
>>>>>>>> as a module name and magically find the namespace URI for the module
>>>>>>>> name.
>>>>>>> I disagree.  You need an XPath implementation + custom code to set up
>>>>>>> the environment.
>>>>>> This is OK, but can we just use the JSON encoding instance identifier
>>>>>> format exactly?  I.e .RFC 7951 section 6.11.
>>>>>>
>>>>>> So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"
>>>>>>
>>>>>> can trivially be expanded to:
>>>>>>
>>>>>> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",
>>>>>>
>>>>>> and then interpreted with the context:
>>>>>>         "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>>>       "ietf-ip"         -> "urn:ietf:params:xml:ns:yang:ietf-ip"
>>>>> *this* would require a custom XPath implementation.
>>>> Why?  I.e. how is this different from stating "Custom code is needed
>>>> to connect things together"?
>>> B/c the specification of XPath allows you to (actually, *requires* you
>>> to) construct the set of prefix strings to url mappings.
>>>
>>> This is "custom code to connect things".
>>>
>>> But changing the syntax means changin the specification.
>> Not really.
>>
>> It would just mean that the filter value is not an "Xpath"
>> expression.  It is a more a concise string that can be expanded into
>> an Xpath expression.
>>
>>>>> and it is not obvious what the rules for the "auto-assignment" of
>>>>> prefixes would be.  For example:
>>>>>
>>>>>      /ietf-interfaces//ietf-ip:address[../foo]
>>>>>
>>>>> what is the prefix for "foo"?
>>>> OK, so here the module for "../foo" would need to be specified.
>>>>
>>>> Perhaps the rule that I'm looking for is the module name may be
>>>> omitted when it matches the parent node module, and can easily be
>>>> inferred.  I.e. so that for any XPath string, it is possible to
>>>> trivially expand it without any additional schema context.
>>>>
>>>> It just seems to be that requiring the long hand of
>>>> "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled"
>>>> seems like it will get very verbose, and I wonder whether we are
>>>> introducing yet another Xpath format to YANG.
>>> I agree that it is very verbose.  But do not mix XPath expressions in
>>> leaf values (which is what this thread is about) with
>>> instance-identfiers.
>> OK, but ultimately:
>> - these are both leaf values.
>> - they both identify nodes in a YANG datastore.
>> - the fact that their format is somewhat subtlety different will catch
>>    people out.
> Agreed.
>
> We already have:
>
>    o  instance-identifier in XML uses prefixes from the XML document
>    o  instance-identifier in JSON uses module names as prefixes
>    o  XPath in NETCONF filter uses prefixes from the XML document
>    o  XPath in JSON query filter uses module names as prefixes
Yes, but in the two JSON cases, the way that they use the module name 
prefixes is still different.  I.e. they differ in the required namespace 
encoding when a child element is in the same namespace it is parent, for 
an instance-identifier they MUST be excluded, for the XPath in JSON 
query filter they MUST be included.

I think that the crux of the problem is XPath is designed/specified for 
XML documents.

>
> So an alternative could be to use different encodings for
> "stream-xpath-filter" as well, depending on if it is XML or JSON.
>
> So, we could do in SN:
>
>               o  If the node is encoded in XML, the set of namespace
>                  declarations are those in scope on the
>                  'stream-xpath-filter' leaf element.
>
>               o  If the node is encoded in JSON, the set of namespace
>                  declarations is the set of prefix and namespace pairs
>                  for all supported YANG modules, where the prefix is
>                  the YANG module name and the namespace is as defined
>                  by the "namespace" statement in the YANG module.
>
> This is far from perfect, but at least the format is consistent within
> each encoding.  One problem is that it is unclear how to handle other
> encodings.
I agree that this is a valid alternative.  I don't know whether or not I 
prefer it.  Arguably it is more consistent and doesn't cause the RFC 
7951 JSON style encoding to leech into the XML encoding.

I would expect the CBOR encoding to either define its own binary format 
for this, or follow the JSON style.

>
>
> If we do this, we'll set a precedence for future models.
Yes, this is the part that concerns me the most, that we are reinforcing 
that the format for these type of leaves can be encoding dependent.

>
> Now, suppose we have a module "ex-foo" with namespace
> "urn:example:foo".  If an XML client writes:
>
>     
>       /f:bar/f:baz
>     
>
> a JSON will read this node as:
>
>     "example-expr": "/ex-foo:bar/ex-foo:baz"
>
>
> [This context-dependent encoding that we have for a couple of types is
> probably the biggest mistake in YANG]
I agree that it is far from ideal.

In an ideal world, I would like to see an encoding like the JSON 
instance identifier one (because it seems reasonably concise and simple) 
used for both instance identifiers and XPath expressions, but that would 
require us defining a replacement for XPath and is obviously out of 
scope for this particular problem.

>
>
> BTW, we already have this issue w/ NACM's node-instance-identifier.
> It is highly unclear what a JSON client is supposed to see if it reads
> NACM rules with node-instance-identifiers.
I agree.

Thanks,
Rob


>
>>>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
>>>> 4.8.4), which also uses XPath expressions is meant to work. That
>>>> states:
>>>>
>>>> The set of namespace declarations is the set of prefix and
>>>>         namespace pairs for all supported YANG modules, where the prefix
>>>>         is the YANG module name and the namespace is as defined by the
>>>>         "namespace" statement in the YANG module.
>>> Perfect!  It seems the authors of 8040 thought of this ;-)
>> OK, what you propose would at least be consistent with how the XPath
>> is formed in sec 8040, 4.8.4?
>>
>> I can live with that.  But still strongly think that WG should think
>> of trying to move YANG on from Xpath 1.0.
>>
>>>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
>>>> in very many places, e.g. why is it "/example-mod:event1/name='joe'"
>>>> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
>>>> wrong, or otherwise what am I missing? :-)
>>> It seems the example is wrong!
>> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
> Yes it seems so.  Except the last one.
>
>
> /martin
> .
>


From nobody Fri Oct 12 03:22:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CC2129BBF for ; Fri, 12 Oct 2018 03:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level: 
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 bg_vyvNknsgi for ; Fri, 12 Oct 2018 03:22:55 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB17130DC5 for ; Fri, 12 Oct 2018 03:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10593; q=dns/txt; s=iport; t=1539339775; x=1540549375; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=hg4BzxXd8YOGSRuYCwdK73x6Y7u4StHEOXFWCSrq5Ks=; b=OfcvfjkWxMM3EPphO69UxcTx5KLeRNwYpqqB2hsMHLXroxk084QYeiP0 9p+Vzf2e9czKukB1KHIQfyvkeUNeqgAlRs2lFZ2hRdAMFJmDs/q0/5W6/ xjJpv3G51lNZwybLEhFraSsyZtQvghGAsZ+e95Oe9kSEyqnDHBFJdHCEP U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAABtdcBb/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoNVEiiDdYh1jTstkT+HQg2EbAKEeTgWAQMBAQIBAQJ?= =?us-ascii?q?tKIU5AQEBAwEjVhAJAhgnAwICRhEGDQYCAQGDHIF6CIhegSmbTYEuH4RYhGu?= =?us-ascii?q?LXYFBP4E5gW1+h3+CVwKOOoV1iW0JkFIGF4FPhG+Ca4Ztj26GNoFaIYFVMxo?= =?us-ascii?q?IGxWDJ5BXPjCKDCuCIAEB?=
X-IronPort-AV: E=Sophos;i="5.54,371,1534809600"; d="scan'208,217";a="7127935"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 10:22:52 +0000
Received: from [10.63.23.158] (dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com [10.63.23.158]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9CAMpAE013007; Fri, 12 Oct 2018 10:22:52 GMT
To: Andy Bierman 
Cc: Martin Bjorklund , NetMod WG 
References: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Fri, 12 Oct 2018 11:22:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2C698DB853FD9C85A04B84A3"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.158, dhcp-ensft1-uk-vla370-10-63-23-158.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 10:22:57 -0000

This is a multi-part message in MIME format.
--------------2C698DB853FD9C85A04B84A3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

On 11/10/2018 17:52, Andy Bierman wrote:
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  > wrote:
>
>
>     ....
>
>
>             Finally, I'm trying to figure out have RFC 8040 query
>             parameter (sect
>             4.8.4), which also uses XPath expressions is meant to
>             work. That
>             states:
>
>             The set of namespace declarations is the set of prefix and
>                    namespace pairs for all supported YANG modules,
>             where the prefix
>                    is the YANG module name and the namespace is as
>             defined by the
>                    "namespace" statement in the YANG module.
>
>         Perfect!  It seems the authors of 8040 thought of this ;-)
>
>     OK, what you propose would at least be consistent with how the
>     XPath is formed in sec 8040, 4.8.4?
>
>     I can live with that.  But still strongly think that WG should
>     think of trying to move YANG on from Xpath 1.0.
>
>
>
> I do not agree YANG should change any statements where XPath is being 
> used.
> (Note that leafs like the filter are free to use whatever data type 
> they want, including yang:xpath1.0).

OK, I think that I would be proposing either doing this as part of 
YANG.next, or perhaps as different leaf types.

>
> The WG is on the right track already wrt/ XPath by creating custom 
> XPath functions
> like 'deref' that simplify syntax or extend functionality.

Yes, the functions partially help.

But there are bits of Xpath expressions that are not meaningful for YANG 
(e.g. NodeType checks or processing-instruction).

The fact that NodeSets are sets rather than sequences isn't particularly 
helpful (fixed in future versions of XPath).

E.g. if I wanted to check that a particular YANG boolean leaf is true 
then I might write "enabled = true" ... which is valid XPath, but 
probably doesn't do what most people expect ...
When they realize that is wrong, perhaps they will try "enabled = 
true()" instead ... which is also valid XPath, but still probably won't 
do what they expect ...
Instead they have to do 'enabled = "true"'.

And then what about comparisons for 64 bit numbers that don't work properly?

So, it seems like there are quite a lots of gotchas when using XPath for 
YANG, and it is far from an ideal language for expressing configuration 
constraints.

If YANG adoption increases, and if folks start putting more validation 
constrains into the model then I hope that we will end up with a better 
language for expressing those constraints.

Thanks,
Rob


>
>
>
>
>             Yet the examples in section 8.3.6 don't seem to use
>             namespace prefixes
>             in very many places, e.g. why is it
>             "/example-mod:event1/name='joe'"
>             and not "/example-mod:event1/example-mod:name='joe'"? Is
>             the example
>             wrong, or otherwise what am I missing? :-)
>
>         It seems the example is wrong!
>
>     Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>
>     Thanks,
>     Rob
>
>
>
>         /martin
>         .
>
>
>
>
> Andy
>


--------------2C698DB853FD9C85A04B84A3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

    

    
On 11/10/2018 17:52, Andy Bierman
      wrote:

    

    

      
      


        


          
On Thu, Oct 11, 2018 at 9:45 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            


              ....

              

                

                

                  Finally, I'm trying to figure out have RFC 8040 query
                  parameter (sect

                  4.8.4), which also uses XPath expressions is meant to
                  work. That

                  states:

                  

                  The set of namespace declarations is the set of prefix
                  and

                         namespace pairs for all supported YANG modules,
                  where the prefix

                         is the YANG module name and the namespace is as
                  defined by the

                         "namespace" statement in the YANG module.

                

                Perfect!  It seems the authors of 8040 thought of this
                ;-)

              

              OK, what you propose would at least be consistent with how
              the XPath is formed in sec 8040, 4.8.4?

              

              I can live with that.  But still strongly think that WG
              should think of trying to move YANG on from Xpath 1.0.

            

            


            

            


            

            
I do not agree YANG should change any statements where
              XPath is being used.

            
(Note that leafs like the filter are free to use
              whatever data type they want, including yang:xpath1.0).

          

        

      

    

    

    OK, I think that I would be proposing either doing this as part of
    YANG.next, or perhaps as different leaf types.

    

    

      

        

          

            


            

            
The WG is on the right track already wrt/ XPath by
              creating custom XPath functions

            
like 'deref' that simplify syntax or extend
              functionality. 

            

          

        

      

    

    

    Yes, the functions partially help.

    

    But there are bits of Xpath expressions that are not meaningful for
    YANG (e.g. NodeType checks or processing-instruction).

    

    The fact that NodeSets are sets rather than sequences isn't
    particularly helpful (fixed in future versions of XPath).

    

    E.g. if I wanted to check that a particular YANG boolean leaf is
    true then I might write "enabled = true" ... which is valid XPath,
    but probably doesn't do what most people expect ...

    When they realize that is wrong, perhaps they will try "enabled =
    true()" instead ... which is also valid XPath, but still probably
    won't do what they expect ...

    Instead they have to do 'enabled = "true"'.

    

    And then what about comparisons for 64 bit numbers that don't work
    properly?

    

    So, it seems like there are quite a lots of gotchas when using XPath
    for YANG, and it is far from an ideal language for expressing
    configuration constraints.

    

    If YANG adoption increases, and if folks start putting more
    validation constrains into the model then I hope that we will end up
    with a better language for expressing those constraints.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            

              

              

                

                

                  Yet the examples in section 8.3.6 don't seem to use
                  namespace prefixes

                  in very many places, e.g. why is it
                  "/example-mod:event1/name='joe'"

                  and not "/example-mod:event1/example-mod:name='joe'"? 
                  Is the example

                  wrong, or otherwise what am I missing? :-)

                

                It seems the example is wrong!

              

              Please can you check section 8040, 8.3.6.  Are all the
              examples wrong?

              

              Thanks,

              Rob

              

              

                

                

                /martin

                .

                

              

              

            

          

          

        

        


        

        
Andy

        


        

      

    

    

  


--------------2C698DB853FD9C85A04B84A3--


From nobody Fri Oct 12 07:07:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEBF130DE4 for ; Fri, 12 Oct 2018 07:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level: 
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 9ZHWnAHBdVuq for ; Fri, 12 Oct 2018 07:07:42 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A29127148 for ; Fri, 12 Oct 2018 07:07:39 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE3.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 12 Oct 2018 17:07:26 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE3 (10.237.240.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 12 Oct 2018 17:07:26 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 17:07:25 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Fri, 12 Oct 2018 17:07:25 +0300
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 17:07:24 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=La4JhPIT5MeLf3kMOGU/brarNQM06l1nq+Pmg0uHqmI=; b=dskNBQjuBWVTcz3XAIUXCGtDpGVGH7ptt8PvDGF1CK8u4OxlW1CWq5I2xUQqc0O3WAGnjF/ia1zUwDu0P0Z3exLoPAhJicUUQz6uoRLB9C1LsFO2ouxChgIJlLUyammjXH1nAVV4ClKRHB9s+HCHxz3chDNEDHqir9LdMtC2QqI=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4257.eurprd06.prod.outlook.com (52.135.150.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.24; Fri, 12 Oct 2018 14:07:23 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 14:07:23 +0000
From: Michael Rehder 
To: Andy Bierman 
CC: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAAKEBgAAFUxgAAABj8IA==
Date: Fri, 12 Oct 2018 14:07:23 +0000
Message-ID: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB4257; 6:h3anhhSy57Dq4QvIQerlbFbk6p4msVIMskeVWoE6nGehUmsZwD448KJYkXeMnudUMjW/g0WF12OEII6gTmTE5/ZCyNDuY8LWO7cKIS5EMC+0ohPHtTjJtezG9LIbnfq0MJUyZuUfgnmhjtpfceWoOhQzCeHK8i9Cb71DvRtEp/DgLWXaJLYtCdmHKx6VwhFcA/Ld2ECxBPTQDzau7xViOGMhf12NARXCVjKHgLQ4F3cXgdNn1YSB5PgEsQTQU926WO/Yp7e/GtVJqbWX2abWXTHes2xgyP241D8OxsaDWjrpuFd7CzCiRhMKdkWHEaP+CfQl11xVui2oVYKsETN14q230eKVf0e3snXZCQ0sDzIa2TKL3iUJfAKfuoullMgNq07bJU9OVB2rPqfsz2scAl8B2YYYxUPkS+PNOxxih6mvZwpp3GaNxAZVP4IC9CyW9tETIdXK0nQiMG7FQwLG7w==; 5:5gzzMdZn9gnrMMYUiIN4JWx4amHxbmBhJnqvtndLbX1xoCeIgm6A7Jw6a7NI3fq6Ww61BEruF3wsw0oel5vKS1GdRgO0UnwHihojAJ6zMAbXE5Ir1Hu3z0MB/q3Jjqx/t3R6kOGzhTc0iCltowbUKoSM11icpRScCBNTKoCOGzQ=; 7:6Jd038SIrab6piGFMyIVsk/rRuhsbbKcKSJWbPkNeWhDwKDRGbRbHXPiV8QDkM8OZn7jXUJ1bODQ51vRvY+pRRKyBaOePe/RvnAAEurkZkJlVDas8o8rufHoWgCBGGI4jXrdG87jQmmuL4xj96lVQVoDu0Q6RCkT2PBRamnc5FCPLIH03p3aiPrgMdwS/zBpC4p65Cax3KjWKhY/NmReS7mxCSgAI6naM2yIa14HpaT+kUe39fiJKAG9+Fc6AVPt
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 881d47c7-779e-4aeb-159a-08d6304c0847
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4257; 
x-ms-traffictypediagnostic: AM0PR06MB4257:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166566539817055)(62221491112393)(131327999870524)(95692535739014)(17755550239193)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(106180626270275);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991067); SRVR:AM0PR06MB4257; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4257; 
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(366004)(39860400002)(396003)(51444003)(189003)(199004)(13464003)(97736004)(33656002)(99286004)(6506007)(6916009)(316002)(74316002)(5660300001)(66066001)(86362001)(71200400001)(71190400001)(2900100001)(76176011)(7736002)(966005)(478600001)(186003)(102836004)(54906003)(6246003)(72206003)(26005)(53546011)(7696005)(105586002)(8936002)(53936002)(53946003)(8676002)(81166006)(114624004)(236005)(9686003)(54896002)(68736007)(6306002)(790700001)(6116002)(606006)(3846002)(476003)(486006)(229853002)(81156014)(4326008)(6436002)(106356001)(25786009)(14444005)(55016002)(256004)(4744004)(14454004)(2906002)(11346002)(19609705001)(446003)(5250100002)(93886005)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4257; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8QLYb0lE3TI4vB+t9A0Haf6WpAFFeJBL6Rwjsqr3AHyZw+FgysHtlcoK3DU2kS3cjb1AC1qka/F9F5PJtqSSe+MTBLu3BJeeHKQyLd4uiQPwsHCyaeC1PIMX5SC0BtFbv6rbm5Filp1e6kTS9O6e4aR/VSebJo0cJG7qGrFrwHFZFuVsW9/11wKfsotMJnTIBrWcJ+KeWAyXtIDp149/qayURUwFIY1GGHZlxpQpYvxubraU1SZO/IwpwS1FSlh9NiSlt//IifDkFaGftlrkme2wbVlp4iKYUxQBcgRfK9Zv/GrPOYCJvm0PYYxJbe/3AK3NKkMYbNQ6TmDcprklK8GtjBoPuCld06NqYPpCmn0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB4083E3B92D12FE1678CEDE52E7E20AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 881d47c7-779e-4aeb-159a-08d6304c0847
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 14:07:23.2196 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4257
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 14:07:45 -0000

--_000_AM0PR06MB4083E3B92D12FE1678CEDE52E7E20AM0PR06MB4083eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SXQgZGVwZW5kcyB3aGF04oCZcyBtZWFudCBieSDigJxDb25kaXRpb25hbOKAnS4gSSB0aGluayB0
aGUgdGVybSBpcyBkaXN0aW5jdCBmcm9tIOKAnE9wdGlvbmFs4oCdLg0KDQpJIGRvbuKAmXQgdGhp
bmsgdGhlIGltcGxlbWVudGF0aW9uIGNhbiBiZSBjaGFuZ2VkICh1bmxlc3MgeW91IG1lYW50IHRo
YXQgSSBjaGFuZ2UgbXkgb3duIGxvY2FsIGltcGxlbWVudGF0aW9uKS4NCg0KVGhhdOKAmXMgd2h5
IEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgWUFORyBsYW5ndWFnZSBhZGRpdGlvbiB0byBjb250
cm9sIHRoaXMgYmVoYXZpb3IsIHNpbmNlIHRoZXJlIGFyZSB2YWxpZCB1c2UgY2FzZXMgZm9yIGl0
Lg0KQWRkaW5nIG9wdGlvbnMgdG8gdGhlIFdIRU4gc3RhdGVtZW50IHNlZW1zIGEgcmVhc29uYWJs
ZSB3YXkgdG8gZG8gdGhpcy4NCg0KVGhhbmtzDQpNaWtlDQoNCkZyb206IEFuZHkgQmllcm1hbiBb
bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDExLCAy
MDE4IDI6NDggUE0NClRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNv
bT4NCkNjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p
dmVyc2l0eS5kZT47IFdhbGtlciwgSmFzb24gKEphc29uX1dhbGtlcjJAY29tY2FzdC5jb20pIDxK
YXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3Qg
ZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQoNCg0KDQpPbiBUaHUsIE9j
dCAxMSwgMjAxOCBhdCAxMToxNCBBTSwgTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQGFt
ZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb20+PiB3cm90ZToNClRoZXJl
IGlzIG5vIHNwZWNpZmljIHRleHQgLSB0aGUgdGV4dCBqdXN0IHNheXMgaXQgaXMg4oCcY29uZGl0
aW9uYWzigJ0uDQpIb3dldmVyIHRoZSBpbXBsZW1lbnRhdGlvbiBmb3JjZXMgaXQgb3B0aW9uYWw6
DQoNCi0gICAgICAgICAgVGhlIFJORyBmaWxlIG1ha2VzIGl0IG9wdGlvbmFsIChJ4oCZbSBub3Qg
YWN0dWFsbHkgcnVubmluZyB0aGlzIGZvciB2YXJpb3VzIHJlYXNvbnMgc28gSeKAmW0ganVzdCBp
bnRlcnByZXRpbmcgdGhlIGZpbGUgZ2VuZXJhdGVkIOKAkyBtYXliZSBJIG1pc3VuZGVyc3RhbmQg
Uk5HKQ0KDQotICAgICAgICAgIFNjaGVtYXRyb24gZG9lc27igJl0IGNoZWNrIGZvciBpdHMgZXhp
c3RlbmNlIChsaWtlIGl0IGRvZXMgZm9yIGEgbWFuZGF0b3J5IGNob2ljZSBjYXNlKQ0KDQoNClNv
IGNoYW5nZSB0aGUgaW1wbGVtZW50YXRpb24gc28gaXQgY29uZm9ybXMgdG8gdGhlIHNwZWMuDQoN
Cg0KVGhhbmtzDQpNaWtlDQoNCkFuZHkNCg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT5dDQpTZW50OiBUaHVy
c2RheSwgT2N0b2JlciAxMSwgMjAxOCAyOjA2IFBNDQpUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hh
ZWwuUmVoZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+Pg0K
Q2M6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz
aXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PjsgV2Fs
a2VyLCBKYXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTxtYWlsdG86SmFzb25fV2Fsa2Vy
MkBjb21jYXN0LmNvbT4pIDxKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9X
YWxrZXIyQGNvbWNhc3QuY29tPj47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu
b3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRv
cnkgb2JqZWN0cyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVj
dA0KDQoNCg0KT24gVGh1LCBPY3QgMTEsIDIwMTggYXQgMTE6MDAgQU0sIE1pY2hhZWwgUmVoZGVy
IDxNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPG1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3Mu
Y29tPj4gd3JvdGU6DQpJIHRoaW5rIHRoZSB3b3JkaW5nIGlzIHJlbGV2YW50IC0gc29tZXRoaW5n
IGNhbiBiZSBjb25kaXRpb25hbCBidXQgc3RpbGwgcmVxdWlyZWQuDQpJdCBzaG91bGQgYmUgY2xh
cmlmaWVkIHRoYXQgZWxlbWVudHMgYmVjb21lIGltcGxpY2l0bHkg4oCcbWFuZGF0b3J5IGZhbHNl
4oCdIHdoZW4gYSDigJx3aGVu4oCdIHN0YXRlbWVudCBpcyB1c2VkLg0KDQpJIHdvdWxkIGxpa2Ug
dG8gc2VlIGFuIGVuaGFuY2VtZW50IHRvIFlBTkcgdG8gY29udHJvbCB0aGlzIGJlaGF2aW9yLCB0
byBhbGxvdyB0aGUgbWFuZGF0b3J5IHN0YXR1cyB0byBiZSBlbmZvcmNlZC4NClRoYXQgaXMsIHN1
cHBvcnQgYWxzbyDigJxjb25kaXRpb25hbGx5IHJlcXVpcmVk4oCdIGluc3RlYWQgb2Ygb25seSB0
aGUgY3VycmVudCDigJxjb25kaXRpb25hbGx5IG9wdGlvbmFs4oCdLg0KDQoNCg0KICBsZWFmIGZv
byB7DQogICAgIHdoZW4gIi4uL3NvbWUtb3RoZXItbm9kZSA9IDUiOw0KICAgICB0eXBlIGludDMy
Ow0KICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiB9DQoNCg0KVGhpcyBsZWFmIGlzIG1hbmRhdG9yeSBp
ZiB0aGUgd2hlbi1leHByIGlzIHRydWUuDQpXaGVyZSBpcyB0aGUgdGV4dCBpbiA3OTUwIHRoYXQg
c2F5cyB0aGlzIG1hbmRhdG9yeSB0cnVlIGlzIGlnbm9yZWQgaWYgd2hlbi1zdG10IGlzIHByZXNl
bnQ/DQoNCg0KDQpUaGFua3MNCk1pa2UNCg0KQW5keQ0KDQoNCg0KRnJvbTogQW5keSBCaWVybWFu
IFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+XQ0K
U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDI6NTIgUE0NClRvOiBNaWNoYWVsIFJl
aGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTxtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1k
b2NzLmNvbT4+DQpDYzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZT4+OyBXYWxrZXIsIEphc29uIChKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpK
YXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPikgPEphc29uX1dhbGtlcjJAY29tY2FzdC5jb208bWFp
bHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+PjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpu
ZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0
aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5k
YXRvcnkgb2JqZWN0DQoNCg0KDQpPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCAxMTo0NCBBTSwgTWlj
aGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVo
ZGVyQGFtZG9jcy5jb20+PiB3cm90ZToNClN1cmUuDQoNCkkgdGhpbmsgdGhlIFJGQyBpcyB1bmNs
ZWFyIHNpbmNlIGl0IHNlZW1zIHRoYXQgdGhlIHNlbWFudGljcyBhcmUgY29uc2lzdGVudCBpbiB0
aGUgYmFjay1lbmQgY2hlY2tzLg0KT25lIGNhbiByZWFkIHRoZSBSRkMgYW5kIG5vdCBub3RpY2Ug
YnkgaXRzIGFic2VuY2UgdGhhdCB0aGUgd2hlbiBjbGF1c2UgZG9lc24ndCByZXF1aXJlIGFueXRo
aW5nIHRvIGJlIHByZXNlbnQuDQoNCiAgICAgVGhlICJ3aGVuIiBzdGF0ZW1lbnQgbWFrZXMgaXRz
IHBhcmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGNvbmRpdGlvbmFsLg0KU2hvdWxkIGJl
DQogICAgVGhlICJ3aGVuIiBzdGF0ZW1lbnQgbWFrZXMgaXRzIHBhcmVudCBkYXRhIGRlZmluaXRp
b24gc3RhdGVtZW50IGNvbmRpdGlvbmFsIGFuZCBvcHRpb25hbC4NCg0KVGhpcyBpcyBub3QgY29y
cmVjdC4NCg0KU3RlcCAxKSBpZi1mZWF0dXJlIG1ha2VzIHRoZSBzY2hlbWEgbm9kZSBjb25kaXRp
b25hbA0KDQpTdGVwIDIpIHdoZW4tc3RtdCBtYWtlcyBpbnN0YW5jZXMgb2YgdGhlIHNjaGVtYS1u
b2RlIGNvbmRpdGlvbmFsDQoNClN0ZXAgMykgWUFORyB2YWxpZGF0aW9uIGFwcGxpZXMgdG8gaW5z
dGFuY2VzIG9mIGRhdGEgbm9kZXMgKG9yIHRoZSBZQU5HIGRlZmF1bHQgdmFsdWUgaWYgYXBwbGlj
YWJsZSkNCg0KU3RlcCAyIGlzIG9ubHkgcmVsZXZhbnQgaWYgU3RlcCAxIGlzIHRydWUgb3Igbm9u
LWV4aXN0ZW50DQpTdGVwIDMgaXMgb25seSByZWxldmFudCBpZiBTdGVwIDIgaXMgdHJ1ZSBvciBu
b24tZXhpc3RlbnQNCg0KQW5keQ0KDQoNCkkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgbW9yZSBk
ZWZpbml0ZSBzdGF0ZW1lbnQgYWJvdXQgdGhpcyBvdmVycmlkaW5nIGFueSBtYW5kYXRvcnkgc3Rh
dHVzIG9mIHRoZSBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVudC4NCkxpa2UNCiAgICAg
IkFueSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBwYXJlbnQgZGF0YSBkZWZpbml0aW9uIHN0YXRl
bWVudCAobWFuZGF0b3J5IHN0YXRlbWVudCwgbWluLWVsZW1lbnQgc3RhdGVtZW50IGV0Yy4pIGlz
IG92ZXJyaWRkZW4gYnkgdGhpcyBzdGF0ZW1lbnQgYW5kIG1hZGUgbm9uLW1hbmRhdG9yeS4iDQoN
ClRoYXQgd291bGQgaGF2ZSBtYWRlIHRoZSBzaWRlLWVmZmVjdCBvZiAid2hlbiIgb24gb3RoZXIg
ZGVjbGFyYXRpb25zIGNsZWFyZXIuDQoNClRoYW5rcw0KbWlrZQ0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9l
bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNv
YnMtdW5pdmVyc2l0eS5kZT5dDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMCwgMjAxOCAy
OjI1IFBNDQo+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTxt
YWlsdG86TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4+DQo+IENjOiBSb2JlcnQgV2lsdG9uIDxy
d2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgTGFkaXNsYXYgTGhv
dGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6Pj47DQo+IG5ldG1vZEBpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgV2Fsa2VyLCBKYXNvbiAoSmFzb25fV2Fsa2Vy
MkBjb21jYXN0LmNvbTxtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbT4pDQo+IDxKYXNv
bl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPj4N
Cj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkg
b2JqZWN0cyBkb2Vzbid0DQo+IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVj
dA0KPg0KPiBNaWNoYWVsLA0KPg0KPiB3aGF0IG1hdHRlcnMgaGVyZSBpcyB3aGF0IHRoZSBZQU5H
IHNwZWNpZmljYXRpb24gKFJGQyA3OTUwKSBzYXlzLiBJcyB0aGVyZSBhDQo+IHJlYXNvbiB0byBi
ZWxpZXZlIHRoZSBJUEFkZHJlc3NlcyBsaXN0IGluIHlvdXIgZXhhbXBsZSBjYW4gYmUgYWJzZW50
IG9yIGhhdmUgbm8NCj4gZWxlbWVudHMgYmFzZWQgb24gd2hhdCBSRkMgNzk1MCBzYXlzPyBPciBk
byB3ZSB0YWxrIGFib3V0IGEgc2hvcnRjb21pbmcgb2YNCj4gUkZDIDYxMTA/DQo+DQo+IC9qcw0K
Pg0KPiBPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCAwNjoxNzoyNlBNICswMDAwLCBNaWNoYWVsIFJl
aGRlciB3cm90ZToNCj4gPiBJZiB0aGUgbGlzdCBoYXMgYSAid2hlbiIgY2xhdXNlIHRoZSBSTkcg
ZmlsZSBhY3R1YWxseSBwcm9kdWNlcyBhICJPbmVPck1vcmUiDQo+IHdoaWNoIGhhcyBhIGNob2lj
ZSBvZiA8ZW1wdHk+IG9yIHRoZSBsaXN0IHNvIGl0IGFjdHVhbGx5IGRvZXNuJ3QgZW5mb3JjZSB0
aGUNCj4gcHJlc2VuY2UgYXQgbGVhc3Qgb25lIHJvdyBvZiB0aGUgbGlzdCAodW5sZXNzIEknbSBt
aXN0YWtlbiBpbiBteSByZWFkaW5nKS4NCj4gPiAgICAgICAgICAgICAgIDxvbmVPck1vcmU+DQo+
ID4gICAgICAgICAgICAgICAgIDxjaG9pY2U+DQo+ID4gICAgICAgICAgICAgICAgICAgPGVtcHR5
Lz4NCj4gPiAgICAgICAgICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJJUEFkZHJlc3NlcyI+DQo+
ID4gICAgICAgICAgICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJBZGRyZXNzIj4NCj4gPiAgICAg
ICAgICAgICAgICAgICAgICAgPHJlZiBuYW1lPSJ0eXBlc19fSVB2NEFkZHJlc3MiLz4NCj4gPiAg
ICAgICAgICAgICAgICAgICAgIDwvZWxlbWVudD4NCj4gPiAgICAgICAgICAgICAgICAgICAgIDxl
bXB0eS8+DQo+ID4gICAgICAgICAgICAgICAgICAgPC9lbGVtZW50Pg0KPiA+ICAgICAgICAgICAg
ICAgICA8L2Nob2ljZT4NCj4gPiAgICAgICAgICAgICAgIDwvb25lT3JNb3JlPg0KPiA+DQo+ID4g
QSBsZWFmL2NvbnRhaW5lciB3b3VsZCBiZSBhIHNpbXBsZXIgZXhhbXBsZSBidXQgd291bGQgcmVz
dWx0IGluIHRoZSBzYW1lDQo+IGxhY2sgb2YgZW5mb3JjZW1lbnQgb2YgdGhlIG1hbmRhdG9yeSBz
dGF0dXMgb2YgYW4gZWxlbWVudCB3aXRoIGEgIndoZW4iDQo+IGNsYXVzZS4NCj4gPg0KPiA+IFRo
aXMgUk5HIHNlZW1zIGNvbnNpc3RlbnQgd2l0aCB0aGUgU2NoZW1hdHJvbiBydWxlcyB0aGF0ICJ3
aGVuIiBtYWtlcw0KPiBzb21ldGhpbmcgb3B0aW9uYWwuDQo+ID4NCj4gPg0KPiA+IEkgdGhpbmsg
YSB3b3JrYXJvdW5kIHdvdWxkIGJlIGNob2ljZSB3aXRoIG1hbmRhdG9yeSB0cnVlIGFuZCBhIHdo
ZW4gY2xhdXNlDQo+IG9uIHRoZSBjYXNlcy4gVGhpcyB3b3VsZCBlbnN1cmUgdGhhdCBhdCBsZWFz
dCBvbmUgY2FzZSBpcyBwcmVzZW50IHNpbmNlIHRoZQ0KPiBtYW5kYXRvcnkgY2xhdXNlIGltcGxl
bWVudHMgYSBTY2hlbWF0cm9uIGV4aXN0ZW5jZSBjb25zdHJhaW50Lg0KPiA+DQo+ID4gVGhhbmtz
DQo+ID4gTWlrZQ0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206
IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBj
aXNjby5jb20+XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDExOjMz
IEFNDQo+ID4gPiBUbzogTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208
bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+PjsgTGFkaXNsYXYgTGhvdGthDQo+ID4g
PiA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+OyBuZXRtb2RAaWV0Zi5vcmc8
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiA+IENjOiBXYWxrZXIsIEphc29uIChKYXNvbl9X
YWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPikNCj4g
PiA+IDxKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPG1haWx0bzpKYXNvbl9XYWxrZXIyQGNvbWNh
c3QuY29tPj4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRo
aW4gbWFuZGF0b3J5IG9iamVjdHMNCj4gPiA+IGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRo
ZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4gPg0KPiA+ID4gSGkgTWlrZSwNCj4gPiA+DQo+ID4gPiBJ
IHRoaW5rIHRoYXQgdGhlIFlBTkcgYmVsb3cgYWxyZWFkeSBlbmZvcmNlcyB3aGF0IHlvdSB3YW50
LCBvcg0KPiA+ID4gb3RoZXJ3aXNlIEkgZG9uJ3QgZm9sbG93IHlvdXIgaXNzdWUuDQo+ID4gPg0K
PiA+ID4gVGhlIFlBTkcgYmVsb3cgaXMgdmFsaWQgaW4gdHdvIGNhc2VzOg0KPiA+ID4NCj4gPiA+
ICgxKSBBc3NpZ25tZW50TWVjaGFuaXNtID0gREhDUCwgYW5kIElQQWRkcmVzc2VzIGlzIG5vdCBw
cmVzZW50IGluDQo+ID4gPiB0aGUgY29uZmlnIChkdWUgdG8gdGhlIHdoZW4gc3RhdGVtZW50KS4N
Cj4gPiA+ICgyKSBBc3NpZ25tZW50TWVjaGFuaXNtID0gU3RhdGljLCBJUEFkZHJlc3NlcyBleGlz
dHMgYW5kIGhhcyBhdA0KPiA+ID4gbGVhc3Qgb25lIGVsZW1lbnQgKGR1ZSB0byBtaW4tZWxlbWVu
dHMgMSkuDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gUm9iDQo+ID4gPg0KPiA+ID4NCj4g
PiA+IE9uIDEwLzEwLzIwMTggMTY6MjMsIE1pY2hhZWwgUmVoZGVyIHdyb3RlOg0KPiA+ID4gPiBD
b250YWluZXIgImZvbyIgd291bGQgYmUgbWFuZGF0b3J5IGlmIG5vdCBmb3IgdGhlICJ3aGVuIiBj
aGlsZCBlbGVtZW50Lg0KPiA+ID4gPiBXaXRoIHRoZSAid2hlbiIgY2hpbGQgZWxlbWVudCwgdGhl
IGxvZ2ljIGJlY29tZXMgImludmVydGVkIiBhbmQNCj4gPiA+ID4gdGhlDQo+ID4gPiBjb25zdHJh
aW50IGlzIGEgbmVnYXRpdmUgb25lIG9mICJkaXNhbGxvd2VkIHVuZGVyIGNlcnRhaW4gY29uZGl0
aW9uIi4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIFVDIGlzIGZvciBlbmZvcmNlbWVudCBpbiBSRVNU
IEFQSSBwYXlsb2Fkcy4NCj4gPiA+ID4gRm9yIGEgcHJhY3RpY2FsIGV4YW1wbGU6DQo+ID4gPiA+
DQo+ID4gPiA+ICAgICAgICAgICBsZWFmIEFzc2lnbm1lbnRNZWNoYW5pc20gew0KPiA+ID4gPiAg
ICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ID4gPiA+ICAgICAgICAgICAgICAgIGVu
dW0gIkRIQ1AiOw0KPiA+ID4gPiAgICAgICAgICAgICAgICBlbnVtICJTdGF0aWMiOw0KPiA+ID4g
PiAgICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+
ID4gPiA+ICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVGhlIGFkZHJlc3MgYXNzaWdubWVudCBt
ZWNoYW5pc20uIjsNCj4gPiA+ID4gICAgICAgICAgICB9DQo+ID4gPiA+ICAgICAgICAgICAgbGlz
dCBJUEFkZHJlc3NlcyB7DQo+ID4gPiA+ICAgICAgICAgICAgICB3aGVuICIuLi9Bc3NpZ25tZW50
TWVjaGFuaXNtID0gJ1N0YXRpYyciOw0KPiA+ID4gPiAgICAgICAgICAgICAga2V5IEFkZHJlc3M7
DQo+ID4gPiA+ICAgICAgICAgICAgICBtaW4tZWxlbWVudHMgMTsNCj4gPiA+ID4NCj4gPiA+ID4g
ICAgICAgICAgICAgIGxlYWYgQWRkcmVzcyB7DQo+ID4gPiA+ICAgICAgICAgICAgICAgIHR5cGUg
Y2FwaXQ6SVB2NEFkZHJlc3M7DQo+ID4gPiA+ICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJB
biBpcHY0IGFkZHJlc3MuIjsNCj4gPiA+ID4gICAgICAgICAgICAgIH0NCj4gPiA+ID4gICAgICAg
ICAgICAgfQ0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBpcyBubyB3YXkgaW4gdGhlIElQQWRkcmVz
c2VzIGxpc3QgdG8gZW5mb3JjZSB0aGF0IHRoZXJlIGlzDQo+ID4gPiA+IGF0IGxlYXN0IG9uZSBJ
UA0KPiA+ID4gQWRkcmVzcyB3aGVuIHRoZSBhc3NpZ25tZW50IG1ldGhvZCBpcyAiU3RhdGljIi4N
Cj4gPiA+ID4gT25lIGNvdWxkIHB1dCBhICJtdXN0IiBvbiAiQXNzaWdubWVudE1lY2hhbmlzbSIg
dG8gZW5zdXJlIGF0IGxlYXN0DQo+ID4gPiA+IG9uZQ0KPiA+ID4gZWxlbWVudCBvZiB0aGUgSVBB
ZGRyZXNzZXMgbGlzdCB3aGVuICJTdGF0aWMiLCBidXQgSSBkb24ndCBzZWUgdGhpcw0KPiA+ID4g
YXMgYSBnb29kIHNjaGVtYSBkZXNpZ24sIHRvIGhhdmUgdGhlIGNvbnRyb2xsaW5nIGF0dHJpYnV0
ZSBjaGVjayBjb250cm9sbGVkDQo+IGF0dHJpYnV0ZXMuDQo+ID4gPiA+DQo+ID4gPiA+IEkgYXBw
cmVjaWF0ZSB0aGF0IHRoaXMgc2VtYW50aWMgY2FuJ3QgYmUgY2hhbmdlZCBpbiBZQU5HIGF0IHRo
aXMgcG9pbnQuDQo+ID4gPiA+IENvdWxkIHRoZSAid2hlbiIgc3RhdGVtZW50IGhhdmUgYSBtb2Rp
ZnlpbmcgY2hpbGQgZWxlbWVudCB0byBzdGF0ZQ0KPiA+ID4gPiB0aGF0IHRoZQ0KPiA+ID4gbWFu
ZGF0b3J5IHN0YXR1cyBvZiB0aGUgZWxlbWVudCBpcyB0byBiZSBlbmZvcmNlZD8NCj4gPiA+ID4g
TGlrZQ0KPiA+ID4gPiAgICAgIGNvbnRhaW5lciBmb28gew0KPiA+ID4gPiAgICAgICAgd2hlbiAi
Y29uZGl0aW9uIiB7DQo+ID4gPiA+ICAgICAgICAgICAgZW5mb3JjZS1tYW5kYXRvcnktc3RhdHVz
Ow0KPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBpcyBhbHJlYWR5IGJh
Y2stZW5kIGZvciBleGlzdGVudGlhbCBjaGVja3MgZm9yIG1hbmRhdG9yeQ0KPiA+ID4gPiBjaG9p
Y2Ugc28gdGhpcw0KPiA+ID4gc2VlbXMgcmVhc29uYWJseSBjb25zaXN0ZW50IHRvIG1lLg0KPiA+
ID4gPiBJIGFwcHJlY2lhdGUgdGhlcmUgYXJlIGV4aXN0aW5nIGlzc3VlcyBmb3IgIndoZW4iIGJ1
dCBJIGRvbid0IHNlZQ0KPiA+ID4gPiB3aHkgdGhpcw0KPiA+ID4gd291bGQgbWFrZSB0aGluZ3Mg
YW55IHdvcnNlLg0KPiA+ID4gPiBJbiBmYWN0IGJ5IHByb21vdGluZyBhIGJldHRlciBkZXBlbmRl
bmN5ICJkaXJlY3Rpb24iIGJldHdlZW4NCj4gPiA+ID4gc2NoZW1hDQo+ID4gPiBlbGVtZW50cywg
IHRoaW5rIGl0IGNvdWxkIHNpbXBsaWZ5IHRoaW5ncyAoc28gSSBuYWl2ZWx5IHRoaW5rIDopICku
DQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcw0KPiA+ID4gPiBNaWtlDQo+ID4gPiA+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPj4gRnJvbTogTGFkaXNsYXYgTGhvdGthIFttYWls
dG86bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej5dDQo+ID4gPiA+PiBTZW50OiBX
ZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMTA6MjggQU0NCj4gPiA+ID4+IFRvOiBNaWNoYWVs
IFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTxtYWlsdG86TWljaGFlbC5SZWhkZXJA
QW1kb2NzLmNvbT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4g
PiA+ID4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0
b3J5IG9iamVjdHMNCj4gPiA+ID4+IGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5k
YXRvcnkgb2JqZWN0DQo+ID4gPiA+Pg0KPiA+ID4gPj4gTWljaGFlbCBSZWhkZXIgPE1pY2hhZWwu
UmVoZGVyQEFtZG9jcy5jb208bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+PiB3cml0
ZXM6DQo+ID4gPiA+Pg0KPiA+ID4gPj4+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IOKAnHdoZW7i
gJ0gYW5kIG1hbmRhdG9yeSBvYmplY3RzLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSXQgc2VlbXMg
dG8gbWUgdGhhdCB0aGUgaW1wbGVtZW50ZWQgc2VtYW50aWNzIG9mIOKAnHdoZW7igJ0gYXJlDQo+
ID4gPiA+Pj4gcmVhbGx5DQo+ID4gPiA+PiDigJxvcHRpb25hbCB3aGVu4oCdLCBpbiB0aGF0IHRo
ZSBlbmNsb3Npbmcgb2JqZWN0IGNhbiBiZSBhYnNlbnQgZXZlbg0KPiA+ID4gPj4gdGhvdWdoIGl0
IGlzIG1hbmRhdG9yeSBhbmQgdGhlIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUuDQo+ID4g
PiA+Pj4gVGhlIFJGQyBjb3VsZCBiZSBjbGVhcmVyIGFib3V0IHRoaXMuDQo+ID4gPiA+Pj4NCj4g
PiA+ID4+PiBFeGFtcGxlDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAgICAgbGVhZiBjb2xvciB7DQo+
ID4gPiA+Pj4gICAgICAgZW51bWVyYXRpb24gIHsNCj4gPiA+ID4+PiAgICAgICAgICBlbnVtIOKA
nGJsdWXigJ07DQo+ID4gPiA+Pj4gICAgICAgICAgZW51bSDigJxibGFja+KAnTsNCj4gPiA+ID4+
PiAgICAgICB9DQo+ID4gPiA+Pj4gICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ID4gPiA+Pj4gICAg
IH0NCj4gPiA+ID4+PiAgICAgY29udGFpbmVyIGZvbyB7DQo+ID4gPiA+Pj4gICAgICAgIHdoZW4g
Li4vY29sb3IgPSDigJhibHVl4oCZOw0KPiA+ID4gPj4+ICAgICAgICBldGMuDQo+ID4gPiA+Pj4g
ICAgIH0NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IOKAnGZvb+KAnSBpcyBvcHRpb25hbCBkdWUgdG8g
dGhlIHByZXNlbmNlIG9mIHRoZSDigJx3aGVu4oCdIHN0YXRlbWVudA0KPiA+ID4gPj4+IGV2ZW4g
dGhvdWdoIHRoZSBvYmplY3QgaXMgbWFuZGF0b3J5IChzYW1lIGlzIHRydWUgZm9yIG1hbmRhdG9y
eQ0KPiA+ID4gPj4+IGxlYWYsDQo+ID4gPiA+Pj4gbWluLWVsZW1lbnRzPTEgbGlzdCBldGMuKS4N
Cj4gPiA+ID4+IE1heWJlIHlvdSBpbnRlbmRlZCB0byBoYXZlLCBlLmcuLCBhICJtYW5kYXRvcnkg
dHJ1ZSIgbGVhZiBpbnNpZGUNCj4gPiA+ID4+ICJjb250YWluZXIgZm9vIj8NCj4gPiA+ID4+DQo+
ID4gPiA+Pj4gVGhpcyBpcyBjb25zaWRlcmVkIHZhbGlkIFhNTCBmb3IgdGhlIGFib3ZlDQo+ID4g
PiA+Pj4gICAgICA8Y29sb3I+Ymx1ZTwvY29sb3I+DQo+ID4gPiA+PiBZZXMsIGl0IGlzLCB1bmRl
ciBjdXJyZW50IFlBTkcgcnVsZXMsIG5vIG1hdHRlciB3aGF0ICJldGMuIg0KPiA+ID4gPj4gc3Rh
bmRzIGZvci4gTm90ZSB0aGF0IGV2YWx1YXRpb24gb2YgdGhlIFhQYXRoIGV4cHJlc3Npb24gaW4g
dGhpcw0KPiA+ID4gPj4gY2FzZSAod2l0aCAiZm9vIiBtaXNzaW5nKSByZXF1aXJlcyB0aGUgcGVj
dWxpYXIgcHJvY2VkdXJlIG9mIHNlYy4gNy4yMS41DQo+IGluIFJGQyA3OTUwLg0KPiA+ID4gPj4N
Cj4gPiA+ID4+PiBJbiBteSB2aWV3IHRoaXMgbWFrZXMgY29uZGl0aW9uYWxseSB2YXJpYW50IHNj
aGVtYXMg4oCcbG9vc2XigJ0gaW4NCj4gPiA+ID4+PiB0aGVpciBlbmZvcmNlbWVudCAoc29tZSBz
Y2VuYXJpb3MgY2FuIHVzZSBjaG9pY2UgYnV0IGl0IGRvZXNu4oCZdA0KPiA+ID4gPj4+IGNvdmVy
IGV2ZXJ5dGhpbmcpLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSSB0aGluayB0aGF0IG1hbmRhdG9y
eSBzaG91bGQgYmUgcmVzcGVjdGVkIGZvciB0aGUgZW5jbG9zaW5nDQo+ID4gPiA+Pj4gb2JqZWN0
cyBvZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50LiAgVGhhdCBpcywgYSBtYW5kYXRvcnkgb2JqZWN0
IG11c3QNCj4gPiA+ID4+PiBiZSBwcmVzZW50IHdoZW4gaXRzIOKAnHdoZW7igJ0gY2xhdXNlIGhv
bGRzIHRydWUgYW5kIGEgU2NoZW1hdHJvbg0KPiA+ID4gPj4+IHN0YXRlbWVudCBzaG91bGQgZW5m
b3JjZSB0aGF0Lg0KPiA+ID4gPj4gSW4gZmFjdCwgdGhpcyBpcyBvbmUgY2FzZSB3aGVyZSB0aGUg
RFNETCBtYXBwaW5nIChSRkMgNjExMCkNCj4gPiA+ID4+IGRldmlhdGVzIGZyb20gWUFORyAxLjAu
IE5vZGVzIHRoYXQgbWFuZGF0b3J5IGFyZW4ndCBlbmNsb3NlZCBpbg0KPiA+ID4gPj4gdGhlIFJF
TEFYIE5HIDxvcHRpb25hbD4gcGF0dGVybiwgYW5kIGFyZSB0aGVuIHJlcXVpcmVkIG5vIG1hdHRl
ciB3aGF0DQo+IGFueSAid2hlbiINCj4gPiA+ID4+IHN0YXRlbWVudHMgc2F5IChiZWNhdXNlIFJF
TEFYIE5HIHZhbGlkYXRpb24gY29tZXMgYmVmb3JlDQo+IFNjaGVtYXRyb24pLg0KPiA+ID4gPj4N
Cj4gPiA+ID4+PiBXaGF0IGlzIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBjdXJyZW50IFlBTkcg
cnVsZXMgYmVoYXZpb3IsDQo+ID4gPiA+Pj4gdGhhdCB0aGUg4oCcd2hlbuKAnSBTY2hlbWF0cm9u
IG1hcHBpbmcgZG9lc27igJl0IGNoZWNrIGZvciBwcmVzZW5jZSBvZg0KPiA+ID4gPj4+IHRoZSBl
bmNsb3NpbmcgbWFuZGF0b3J5IG9iamVjdD8NCj4gPiA+ID4+IEZXSVcsIEkgaGF2ZSBiZWVuIHJl
cGVhdGVkbHkgcHJvdGVzdGluZyBhZ2FpbnN0IHRoaXMgYmVoYXZpb3VyDQo+ID4gPiA+PiBidXQg
d2l0aG91dCBtdWNoIGx1Y2suIFNlZSBmb3IgZXhhbXBsZQ0KPiA+ID4gPj4NCj4gPiA+ID4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQw
MTIuaHRtDQo+ID4gPiA+PiBsDQo+ID4gPiA+Pg0KPiA+ID4gPj4gQXMgYSByZXN1bHQsICJ3aGVu
IiBpcyB0aGUgdHJpY2tpZXN0IGZlYXR1cmUgaW4gWUFORyBieSBmYXIuDQo+ID4gPiA+Pg0KPiA+
ID4gPj4gTGFkYQ0KPiA+ID4gPj4NCj4gPiA+ID4+PiB0aGFua3MNCj4gPiA+ID4+PiBNaWtlIFJl
aGRlcg0KPiA+ID4gPj4gLS0NCj4gPiA+ID4+IExhZGlzbGF2IExob3RrYQ0KPiA+ID4gPj4gSGVh
ZCwgQ1ouTklDIExhYnMNCj4gPiA+ID4+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0K
PiA+ID4gPiDigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1w
YXJ0eSwgd29ybGR3aWRlLA0KPiA+ID4gPiBjbG91ZC1iYXNlZA0KPiA+ID4gc3lzdGVtLiBBbnkg
ZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcN
Cj4gPiA+IHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92
aWRlcnMgb2Ygc3VjaA0KPiA+ID4gc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5k
aW5nIG9mIGVtYWlscyB0byBBbWRvY3MNCj4gPiA+IGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8g
dGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNzaW5nLA0KPiBzdG9yaW5nIGFu
ZCBhY2Nlc3PigJ0uDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbmV0bW9k
QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gPiA+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gPiDigJxBbWRvY3PigJkgZW1h
aWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1i
YXNlZA0KPiBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNz
ZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoDQo+IHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkg
dGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZA0KPiBiYXNp
cy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2Vu
dCB0byB0aGUgdXNlIG9mDQo+IHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3Jp
bmcgYW5kIGFjY2Vzc+KAnS4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAg
ICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAy
MDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGh0
dHBzOi8vbWFwcy5nb29nbGUuY29tLz9xPUNhbXB1cytSaW5nKzErJTdDKzI4NzU5K0JyZW1lbisl
N0MrR2VybWFueSZlbnRyeT1nbWFpbCZzb3VyY2U9Zz4NCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMx
MDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K4oCcQW1kb2Nz
4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwg
Y2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJv
Y2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3VjaCBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5
IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMu
IFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQg
dG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFu
ZCBhY2Nlc3PigJ0uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA
aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K
DQoNCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5
LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9j
cyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUg
YWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBs
aW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMg
eW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2lu
Zywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLg0KDQoNCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9y
bSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3Rl
bS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVk
IHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92
aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2Yg
ZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3Vj
aCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLg0KDQri
gJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29y
bGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2ls
bCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vz
c2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRl
ZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIg
Y29uc2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVtIGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0
b3JpbmcgYW5kIGFjY2Vzc+KAnS4K

--_000_AM0PR06MB4083E3B92D12FE1678CEDE52E7E20AM0PR06MB4083eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K
CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTEz
NjIwMjY2NDI3MzUwNTkwMTFtc29saXN0cGFyYWdyYXBoLCBsaS5tMTM2MjAyNjY0MjczNTA1OTAx
MW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tMTM2MjAyNjY0MjczNTA1OTAxMW1zb2xpc3RwYXJhZ3Jh
cGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8xMzYyMDI2NjQyNzM1MDU5MDExbXNvbGlzdHBhcmFncmFw
aDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t
bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N
CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g
MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGRlcGVuZHMgd2hhdOKAmXMgbWVhbnQgYnkg4oCcQ29uZGl0
aW9uYWzigJ0uIEkgdGhpbmsgdGhlIHRlcm0gaXMgZGlzdGluY3QgZnJvbSDigJxPcHRpb25hbOKA
nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0
aGluayB0aGUgaW1wbGVtZW50YXRpb24gY2FuIGJlIGNoYW5nZWQgKHVubGVzcyB5b3UgbWVhbnQg
dGhhdCBJIGNoYW5nZSBteSBvd24gbG9jYWwgaW1wbGVtZW50YXRpb24pLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgd2h5IEkgdGhpbmsgdGhlcmUg
c2hvdWxkIGJlIGEgWUFORyBsYW5ndWFnZSBhZGRpdGlvbiB0byBjb250cm9sIHRoaXMgYmVoYXZp
b3IsIHNpbmNlIHRoZXJlIGFyZSB2YWxpZCB1c2UgY2FzZXMgZm9yIGl0LjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5BZGRpbmcgb3B0aW9ucyB0byB0aGUgV0hFTiBzdGF0ZW1lbnQgc2VlbXMgYSByZWFzb25h
YmxlIHdheSB0byBkbyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJt
YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk
YXksIE9jdG9iZXIgMTEsIDIwMTggMjo0OCBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBSZWhk
ZXIgJmx0O01pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKdWVy
Z2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k
ZSZndDs7IFdhbGtlciwgSmFzb24gKEphc29uX1dhbGtlcjJAY29tY2FzdC5jb20pICZsdDtKYXNv
bl9XYWxrZXIyQGNvbWNhc3QuY29tJmd0OzsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVj
dHMgZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3Q8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMTEsIDIwMTgg
YXQgMTE6MTQgQU0sIE1pY2hhZWwgUmVoZGVyICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5S
ZWhkZXJAYW1kb2NzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuUmVoZGVyQGFtZG9jcy5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6
MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBubyBzcGVjaWZp
YyB0ZXh0IC0gdGhlIHRleHQganVzdCBzYXlzIGl0IGlzIOKAnGNvbmRpdGlvbmFs4oCdLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgdGhlIGltcGxlbWVudGF0aW9uIGZvcmNlcyBpdCBvcHRp
b25hbDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTEzNjIwMjY2NDI3MzUwNTkw
MTFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LTwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgUk5HIGZpbGUgbWFrZXMgaXQgb3B0aW9uYWwg
KEnigJltIG5vdCBhY3R1YWxseSBydW5uaW5nIHRoaXMgZm9yIHZhcmlvdXMgcmVhc29ucyBzbyBJ
4oCZbSBqdXN0IGludGVycHJldGluZyB0aGUgZmlsZSBnZW5lcmF0ZWQg4oCTIG1heWJlIEkgbWlz
dW5kZXJzdGFuZCBSTkcpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xMzYyMDI2
NjQyNzM1MDU5MDExbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2NoZW1hdHJvbiBkb2VzbuKAmXQg
Y2hlY2sgZm9yIGl0cyBleGlzdGVuY2UgKGxpa2UgaXQgZG9lcyBmb3IgYSBtYW5kYXRvcnkgY2hv
aWNlIGNhc2UpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlNvIGNoYW5nZSB0aGUgaW1wbGVtZW50YXRpb24gc28gaXQgY29uZm9ybXMgdG8gdGhl
IHNwZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+TWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g
MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv
OmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YW5k
eUB5dW1hd29ya3MuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNl
bnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAxMSwgMjAxOCAyOjA2IFBNPGJyPg0KPGI+VG86PC9i
PiBNaWNoYWVsIFJlaGRlciAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRl
ckBBbWRvY3MuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb208
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBq
YWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZndDs7DQogV2Fsa2VyLCBKYXNvbiAoPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpKYXNvbl9X
YWxrZXIyQGNvbWNhc3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5KYXNv
bl9XYWxrZXIyQGNvbWNhc3QuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPikgJmx0Ozwv
c3Bhbj48YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldG1vZEBpZXRmLm9y
Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtu
ZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0IGVu
c3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgT2N0IDExLCAyMDE4IGF0IDEx
OjAwIEFNLCBNaWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuUmVoZGVy
QGFtZG9jcy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGUgd29yZGluZyBpcyBy
ZWxldmFudCAtIHNvbWV0aGluZyBjYW4gYmUgY29uZGl0aW9uYWwgYnV0IHN0aWxsIHJlcXVpcmVk
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IHNob3VsZCBiZSBjbGFyaWZpZWQgdGhhdCBlbGVtZW50
cyBiZWNvbWUgaW1wbGljaXRseSDigJxtYW5kYXRvcnkgZmFsc2XigJ0gd2hlbiBhIOKAnHdoZW7i
gJ0gc3RhdGVtZW50IGlzDQogdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5JIHdvdWxkIGxpa2UgdG8gc2VlIGFuIGVuaGFuY2VtZW50IHRvIFlBTkcg
dG8gY29udHJvbCB0aGlzIGJlaGF2aW9yLCB0byBhbGxvdyB0aGUgbWFuZGF0b3J5IHN0YXR1cw0K
IHRvIGJlIGVuZm9yY2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYXQgaXMsIHN1cHBvcnQgYWxz
byDigJxjb25kaXRpb25hbGx5IHJlcXVpcmVk4oCdIGluc3RlYWQgb2Ygb25seSB0aGUgY3VycmVu
dCDigJxjb25kaXRpb25hbGx5IG9wdGlvbmFs4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBsZWFmIGZvbyB7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OyAmbmJzcDsgJm5ic3A7d2hlbiAmcXVvdDsuLi9zb21lLW90aGVyLW5vZGUgPSA1JnF1b3Q7Ozxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDsgJm5ic3A7ICZuYnNwO3R5cGUgaW50MzI7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7bWFuZGF0b3J5IHRy
dWU7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5UaGlzIGxlYWYgaXMgbWFuZGF0b3J5IGlmIHRoZSB3aGVuLWV4cHIgaXMg
dHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+V2hlcmUgaXMgdGhlIHRleHQgaW4gNzk1MCB0aGF0IHNheXMgdGhpcyBtYW5kYXRvcnkgdHJ1
ZSBpcyBpZ25vcmVkIGlmIHdoZW4tc3RtdCBpcyBwcmVzZW50PzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWlrZTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzphbmR5QHl1
bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmFuZHlAeXVtYXdv
cmtzLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g
V2VkbmVzZGF5LCBPY3RvYmVyIDEwLCAyMDE4IDI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hh
ZWwgUmVoZGVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9j
cy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hhZWwuUmVoZGVyQEFt
ZG9jcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g
SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vu
d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiZndDs7DQogV2Fsa2VyLCBKYXNvbiAoPC9zcGFuPjxhIGhyZWY9Im1haWx0
bzpKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5KYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PikgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNv
bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0
bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldG1v
ZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBk
b2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgT2N0IDEwLCAy
MDE4IGF0IDExOjQ0IEFNLCBNaWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh
ZWwuUmVoZGVyQGFtZG9jcy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLlJlaGRlckBhbWRv
Y3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+U3VyZS48YnI+
DQo8YnI+DQpJIHRoaW5rIHRoZSBSRkMgaXMgdW5jbGVhciBzaW5jZSBpdCBzZWVtcyB0aGF0IHRo
ZSBzZW1hbnRpY3MgYXJlIGNvbnNpc3RlbnQgaW4gdGhlIGJhY2stZW5kIGNoZWNrcy48YnI+DQpP
bmUgY2FuIHJlYWQgdGhlIFJGQyBhbmQgbm90IG5vdGljZSBieSBpdHMgYWJzZW5jZSB0aGF0IHRo
ZSB3aGVuIGNsYXVzZSBkb2Vzbid0IHJlcXVpcmUgYW55dGhpbmcgdG8gYmUgcHJlc2VudC48YnI+
DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO1RoZSAmcXVvdDt3aGVuJnF1b3Q7IHN0YXRlbWVu
dCBtYWtlcyBpdHMgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnQgY29uZGl0aW9uYWwu
PGJyPg0KU2hvdWxkIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgJnF1b3Q7d2hlbiZxdW90OyBz
dGF0ZW1lbnQgbWFrZXMgaXRzIHBhcmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGNvbmRp
dGlvbmFsIGFuZCBvcHRpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIG5vdCBjb3JyZWN0LjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3RlcCAx
KSBpZi1mZWF0dXJlIG1ha2VzIHRoZSBzY2hlbWEgbm9kZSBjb25kaXRpb25hbDxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3RlcCAyKSB3
aGVuLXN0bXQgbWFrZXMgaW5zdGFuY2VzIG9mIHRoZSBzY2hlbWEtbm9kZSBjb25kaXRpb25hbDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
U3RlcCAzKSBZQU5HIHZhbGlkYXRpb24gYXBwbGllcyB0byBpbnN0YW5jZXMgb2YgZGF0YSBub2Rl
cyAob3IgdGhlIFlBTkcgZGVmYXVsdCB2YWx1ZSBpZiBhcHBsaWNhYmxlKTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3RlcCAyIGlzIG9u
bHkgcmVsZXZhbnQgaWYgU3RlcCAxIGlzIHRydWUgb3Igbm9uLWV4aXN0ZW50PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0ZXAgMyBpcyBvbmx5
IHJlbGV2YW50IGlmIFN0ZXAgMiBpcyB0cnVlIG9yIG5vbi1leGlzdGVudDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5keTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoZXJlIHNo
b3VsZCBiZSBhIG1vcmUgZGVmaW5pdGUgc3RhdGVtZW50IGFib3V0IHRoaXMgb3ZlcnJpZGluZyBh
bnkgbWFuZGF0b3J5IHN0YXR1cyBvZiB0aGUgcGFyZW50IGRhdGEgZGVmaW5pdGlvbiBzdGF0ZW1l
bnQuPGJyPg0KTGlrZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7QW55IG1hbmRhdG9y
eSBzdGF0dXMgb2YgdGhlIHBhcmVudCBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IChtYW5kYXRv
cnkgc3RhdGVtZW50LCBtaW4tZWxlbWVudCBzdGF0ZW1lbnQgZXRjLikgaXMgb3ZlcnJpZGRlbiBi
eSB0aGlzIHN0YXRlbWVudCBhbmQgbWFkZSBub24tbWFuZGF0b3J5LiZxdW90Ozxicj4NCjxicj4N
ClRoYXQgd291bGQgaGF2ZSBtYWRlIHRoZSBzaWRlLWVmZmVjdCBvZiAmcXVvdDt3aGVuJnF1b3Q7
IG9uIG90aGVyIGRlY2xhcmF0aW9ucyBjbGVhcmVyLjxicj4NCjxicj4NClRoYW5rczxicj4NCm1p
a2U8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBK
dWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVs
ZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgT2N0
b2JlciAxMCwgMjAxOCAyOjI1IFBNPGJyPg0KJmd0OyBUbzogTWljaGFlbCBSZWhkZXIgJmx0Ozxh
IGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+
TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogUm9iZXJ0IFdp
bHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OzsgTGFkaXNsYXYgTGhvdGthICZsdDs8YSBocmVm
PSJtYWlsdG86bGhvdGthQG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPmxob3RrYUBuaWMuY3o8L2E+
Jmd0Ozs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+OyBXYWxrZXIsIEphc29uICg8YSBocmVmPSJtYWls
dG86SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkphc29uX1dhbGtl
cjJAY29tY2FzdC5jb208L2E+KTxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpKYXNvbl9X
YWxrZXIyQGNvbWNhc3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFzb25fV2Fsa2VyMkBjb21jYXN0
LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1l
bnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3Q8YnI+DQomZ3Q7IGVuc3VyZSBwcmVz
ZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDxicj4NCiZndDsgPGJyPg0KJmd0OyBNaWNoYWVs
LDxicj4NCiZndDsgPGJyPg0KJmd0OyB3aGF0IG1hdHRlcnMgaGVyZSBpcyB3aGF0IHRoZSBZQU5H
IHNwZWNpZmljYXRpb24gKFJGQyA3OTUwKSBzYXlzLiBJcyB0aGVyZSBhPGJyPg0KJmd0OyByZWFz
b24gdG8gYmVsaWV2ZSB0aGUgSVBBZGRyZXNzZXMgbGlzdCBpbiB5b3VyIGV4YW1wbGUgY2FuIGJl
IGFic2VudCBvciBoYXZlIG5vPGJyPg0KJmd0OyBlbGVtZW50cyBiYXNlZCBvbiB3aGF0IFJGQyA3
OTUwIHNheXM/IE9yIGRvIHdlIHRhbGsgYWJvdXQgYSBzaG9ydGNvbWluZyBvZjxicj4NCiZndDsg
UkZDIDYxMTA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9qczxicj4NCiZndDsgPGJyPg0KJmd0OyBP
biBXZWQsIE9jdCAxMCwgMjAxOCBhdCAwNjoxNzoyNlBNICYjNDM7MDAwMCwgTWljaGFlbCBSZWhk
ZXIgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IElmIHRoZSBsaXN0IGhhcyBhICZxdW90O3doZW4mcXVv
dDsgY2xhdXNlIHRoZSBSTkcgZmlsZSBhY3R1YWxseSBwcm9kdWNlcyBhICZxdW90O09uZU9yTW9y
ZSZxdW90Ozxicj4NCiZndDsgd2hpY2ggaGFzIGEgY2hvaWNlIG9mICZsdDtlbXB0eSZndDsgb3Ig
dGhlIGxpc3Qgc28gaXQgYWN0dWFsbHkgZG9lc24ndCBlbmZvcmNlIHRoZTxicj4NCiZndDsgcHJl
c2VuY2UgYXQgbGVhc3Qgb25lIHJvdyBvZiB0aGUgbGlzdCAodW5sZXNzIEknbSBtaXN0YWtlbiBp
biBteSByZWFkaW5nKS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O29uZU9yTW9yZSZndDs8YnI+DQomZ3Q7ICZn
dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyZsdDtjaG9pY2UmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VtcHR5
LyZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZWxlbWVudCBuYW1lPSZxdW90O0lQ
QWRkcmVzc2VzJnF1b3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7
ZWxlbWVudCBuYW1lPSZxdW90O0FkZHJlc3MmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7cmVmIG5hbWU9JnF1b3Q7dHlwZXNfX0lQdjRBZGRyZXNz
JnF1b3Q7LyZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lbGVtZW50
Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZW1wdHkvJmd0Ozxicj4N
CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvZWxlbWVudCZndDs8YnI+DQomZ3Q7ICZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyZsdDsvY2hvaWNlJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L29uZU9yTW9yZSZndDs8YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsgQSBsZWFmL2NvbnRhaW5lciB3b3VsZCBiZSBhIHNpbXBsZXIg
ZXhhbXBsZSBidXQgd291bGQgcmVzdWx0IGluIHRoZSBzYW1lPGJyPg0KJmd0OyBsYWNrIG9mIGVu
Zm9yY2VtZW50IG9mIHRoZSBtYW5kYXRvcnkgc3RhdHVzIG9mIGFuIGVsZW1lbnQgd2l0aCBhICZx
dW90O3doZW4mcXVvdDs8YnI+DQomZ3Q7IGNsYXVzZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDsgVGhpcyBSTkcgc2VlbXMgY29uc2lzdGVudCB3aXRoIHRoZSBTY2hlbWF0cm9uIHJ1bGVz
IHRoYXQgJnF1b3Q7d2hlbiZxdW90OyBtYWtlczxicj4NCiZndDsgc29tZXRoaW5nIG9wdGlvbmFs
Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIHRoaW5rIGEg
d29ya2Fyb3VuZCB3b3VsZCBiZSBjaG9pY2Ugd2l0aCBtYW5kYXRvcnkgdHJ1ZSBhbmQgYSB3aGVu
IGNsYXVzZTxicj4NCiZndDsgb24gdGhlIGNhc2VzLiBUaGlzIHdvdWxkIGVuc3VyZSB0aGF0IGF0
IGxlYXN0IG9uZSBjYXNlIGlzIHByZXNlbnQgc2luY2UgdGhlPGJyPg0KJmd0OyBtYW5kYXRvcnkg
Y2xhdXNlIGltcGxlbWVudHMgYSBTY2hlbWF0cm9uIGV4aXN0ZW5jZSBjb25zdHJhaW50Ljxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3M8YnI+DQomZ3Q7ICZndDsgTWlrZTxicj4N
CiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgRnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyd2lsdG9u
QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPl08YnI+DQom
Z3Q7ICZndDsgJmd0OyBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTggMTE6MzMgQU08
YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogTWljaGFlbCBSZWhkZXIgJmx0OzxhIGhyZWY9Im1haWx0
bzpNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5SZWhk
ZXJAQW1kb2NzLmNvbTwvYT4mZ3Q7OyBMYWRpc2xhdiBMaG90a2E8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj5saG90
a2FAbmljLmN6PC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj4NCm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyBDYzog
V2Fsa2VyLCBKYXNvbiAoPGEgaHJlZj0ibWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20i
IHRhcmdldD0iX2JsYW5rIj5KYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPC9hPik8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20i
IHRhcmdldD0iX2JsYW5rIj5KYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tPC9hPiZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGlu
IG1hbmRhdG9yeSBvYmplY3RzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZG9lc24ndCBlbnN1cmUgcHJl
c2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3Q8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyAmZ3Q7IEhpIE1pa2UsPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBJIHRoaW5rIHRoYXQgdGhlIFlBTkcgYmVsb3cgYWxyZWFkeSBlbmZvcmNlcyB3aGF0IHlv
dSB3YW50LCBvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IG90aGVyd2lzZSBJIGRvbid0IGZvbGxvdyB5
b3VyIGlzc3VlLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIFlB
TkcgYmVsb3cgaXMgdmFsaWQgaW4gdHdvIGNhc2VzOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgKDEpIEFzc2lnbm1lbnRNZWNoYW5pc20gPSBESENQLCBhbmQgSVBBZGRy
ZXNzZXMgaXMgbm90IHByZXNlbnQgaW48YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgY29uZmlnIChk
dWUgdG8gdGhlIHdoZW4gc3RhdGVtZW50KS48YnI+DQomZ3Q7ICZndDsgJmd0OyAoMikgQXNzaWdu
bWVudE1lY2hhbmlzbSA9IFN0YXRpYywgSVBBZGRyZXNzZXMgZXhpc3RzIGFuZCBoYXMgYXQ8YnI+
DQomZ3Q7ICZndDsgJmd0OyBsZWFzdCBvbmUgZWxlbWVudCAoZHVlIHRvIG1pbi1lbGVtZW50cyAx
KS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQom
Z3Q7ICZndDsgJmd0OyBSb2I8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gMTAvMTAvMjAxOCAxNjoyMywgTWljaGFlbCBSZWhkZXIg
d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDb250YWluZXIgJnF1b3Q7Zm9vJnF1b3Q7
IHdvdWxkIGJlIG1hbmRhdG9yeSBpZiBub3QgZm9yIHRoZSAmcXVvdDt3aGVuJnF1b3Q7IGNoaWxk
IGVsZW1lbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaXRoIHRoZSAmcXVvdDt3aGVuJnF1
b3Q7IGNoaWxkIGVsZW1lbnQsIHRoZSBsb2dpYyBiZWNvbWVzICZxdW90O2ludmVydGVkJnF1b3Q7
IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29u
c3RyYWludCBpcyBhIG5lZ2F0aXZlIG9uZSBvZiAmcXVvdDtkaXNhbGxvd2VkIHVuZGVyIGNlcnRh
aW4gY29uZGl0aW9uJnF1b3Q7Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IFRoZSBVQyBpcyBmb3IgZW5mb3JjZW1lbnQgaW4gUkVTVCBBUEkgcGF5bG9h
ZHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3IgYSBwcmFjdGljYWwgZXhhbXBsZTo8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZiBBc3NpZ25tZW50TWVjaGFuaXNtIHs8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHR5cGUgZW51bWVyYXRpb24gezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IGVudW0gJnF1b3Q7REhDUCZxdW90Ozs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtICZxdW90
O1N0YXRpYyZxdW90Ozs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hbmRhdG9y
eSB0cnVlOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7VGhlIGFkZHJlc3MgYXNz
aWdubWVudCBtZWNoYW5pc20uJnF1b3Q7Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxpc3QgSVBBZGRy
ZXNzZXMgezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2hlbiAmcXVvdDsuLi9Bc3NpZ25tZW50TWVjaGFuaXNt
ID0gJ1N0YXRpYycmcXVvdDs7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBrZXkgQWRkcmVzczs8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IG1pbi1lbGVtZW50cyAxOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IGxlYWYgQWRkcmVzcyB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBjYXBpdDpJ
UHY0QWRkcmVzczs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtBbiBp
cHY0IGFkZHJlc3MuJnF1b3Q7Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUgaXMg
bm8gd2F5IGluIHRoZSBJUEFkZHJlc3NlcyBsaXN0IHRvIGVuZm9yY2UgdGhhdCB0aGVyZSBpczxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYXQgbGVhc3Qgb25lIElQPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgQWRkcmVzcyB3aGVuIHRoZSBhc3NpZ25tZW50IG1ldGhvZCBpcyAmcXVvdDtTdGF0aWMmcXVv
dDsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbmUgY291bGQgcHV0IGEgJnF1b3Q7bXVzdCZx
dW90OyBvbiAmcXVvdDtBc3NpZ25tZW50TWVjaGFuaXNtJnF1b3Q7IHRvIGVuc3VyZSBhdCBsZWFz
dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb25lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWxlbWVu
dCBvZiB0aGUgSVBBZGRyZXNzZXMgbGlzdCB3aGVuICZxdW90O1N0YXRpYyZxdW90OywgYnV0IEkg
ZG9uJ3Qgc2VlIHRoaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBhcyBhIGdvb2Qgc2NoZW1hIGRlc2ln
biwgdG8gaGF2ZSB0aGUgY29udHJvbGxpbmcgYXR0cmlidXRlIGNoZWNrIGNvbnRyb2xsZWQ8YnI+
DQomZ3Q7IGF0dHJpYnV0ZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgSSBhcHByZWNpYXRlIHRoYXQgdGhpcyBzZW1hbnRpYyBjYW4ndCBiZSBjaGFu
Z2VkIGluIFlBTkcgYXQgdGhpcyBwb2ludC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENvdWxk
IHRoZSAmcXVvdDt3aGVuJnF1b3Q7IHN0YXRlbWVudCBoYXZlIGEgbW9kaWZ5aW5nIGNoaWxkIGVs
ZW1lbnQgdG8gc3RhdGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoYXQgdGhlPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgbWFuZGF0b3J5IHN0YXR1cyBvZiB0aGUgZWxlbWVudCBpcyB0byBiZSBlbmZv
cmNlZD88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IExpa2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29udGFpbmVyIGZvbyB7PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aGVuICZxdW90O2NvbmRpdGlvbiZx
dW90OyB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IGVuZm9yY2UtbWFuZGF0b3J5LXN0YXR1czs8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGVyZSBpcyBhbHJlYWR5IGJhY2stZW5k
IGZvciBleGlzdGVudGlhbCBjaGVja3MgZm9yIG1hbmRhdG9yeTxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgY2hvaWNlIHNvIHRoaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZWVtcyByZWFzb25hYmx5
IGNvbnNpc3RlbnQgdG8gbWUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGFwcHJlY2lhdGUg
dGhlcmUgYXJlIGV4aXN0aW5nIGlzc3VlcyBmb3IgJnF1b3Q7d2hlbiZxdW90OyBidXQgSSBkb24n
dCBzZWU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdoeSB0aGlzPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgd291bGQgbWFrZSB0aGluZ3MgYW55IHdvcnNlLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
SW4gZmFjdCBieSBwcm9tb3RpbmcgYSBiZXR0ZXIgZGVwZW5kZW5jeSAmcXVvdDtkaXJlY3Rpb24m
cXVvdDsgYmV0d2Vlbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2NoZW1hPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgZWxlbWVudHMsJm5ic3A7IHRoaW5rIGl0IGNvdWxkIHNpbXBsaWZ5IHRoaW5ncyAo
c28gSSBuYWl2ZWx5IHRoaW5rIDopICkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgVGhhbmtzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBNaWtlPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzo8
YSBocmVmPSJtYWlsdG86bGhvdGthQG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPmxob3RrYUBuaWMu
Y3o8L2E+XTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgT2N0
b2JlciAxMCwgMjAxOCAxMDoyOCBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFRvOiBN
aWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5j
b20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPC9hPiZndDs7DQo8
YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGll
dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHM8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7Jmd0OyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5
IG9iamVjdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsgTWljaGFlbCBSZWhkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRl
ckBBbWRvY3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbTwv
YT4mZ3Q7IHdyaXRlczo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCDigJx3aGVu4oCdIGFu
ZCBtYW5kYXRvcnkgb2JqZWN0cy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgaW1w
bGVtZW50ZWQgc2VtYW50aWNzIG9mIOKAnHdoZW7igJ0gYXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsmZ3Q7IHJlYWxseTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IOKAnG9wdGlv
bmFsIHdoZW7igJ0sIGluIHRoYXQgdGhlIGVuY2xvc2luZyBvYmplY3QgY2FuIGJlIGFic2VudCBl
dmVuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgdGhvdWdoIGl0IGlzIG1hbmRhdG9yeSBh
bmQgdGhlIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsmZ3Q7IFRoZSBSRkMgY291bGQgYmUgY2xlYXJlciBhYm91dCB0aGlzLjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0
OyBFeGFtcGxlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGNvbG9yIHs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlbnVt
ZXJhdGlvbiZuYnNwOyB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtIOKAnGJsdWXigJ07PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVt
IOKAnGJsYWNr4oCdOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDttYW5kYXRvcnkgdHJ1ZTs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnRhaW5lciBmb28gezxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aGVuIC4uL2Nv
bG9yID0g4oCYYmx1ZeKAmTs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZXRjLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0
OyZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyDigJxmb2/igJ0gaXMgb3B0aW9uYWwgZHVl
IHRvIHRoZSBwcmVzZW5jZSBvZiB0aGUg4oCcd2hlbuKAnSBzdGF0ZW1lbnQ8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7Jmd0OyZndDsgZXZlbiB0aG91Z2ggdGhlIG9iamVjdCBpcyBtYW5kYXRvcnkg
KHNhbWUgaXMgdHJ1ZSBmb3IgbWFuZGF0b3J5PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm
Z3Q7IGxlYWYsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IG1pbi1lbGVtZW50cz0x
IGxpc3QgZXRjLikuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgTWF5YmUgeW91IGludGVu
ZGVkIHRvIGhhdmUsIGUuZy4sIGEgJnF1b3Q7bWFuZGF0b3J5IHRydWUmcXVvdDsgbGVhZiBpbnNp
ZGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmcXVvdDtjb250YWluZXIgZm9vJnF1b3Q7
Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZn
dDsmZ3Q7IFRoaXMgaXMgY29uc2lkZXJlZCB2YWxpZCBYTUwgZm9yIHRoZSBhYm92ZTxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtjb2xvciZn
dDtibHVlJmx0Oy9jb2xvciZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBZZXMsIGl0
IGlzLCB1bmRlciBjdXJyZW50IFlBTkcgcnVsZXMsIG5vIG1hdHRlciB3aGF0ICZxdW90O2V0Yy4m
cXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBzdGFuZHMgZm9yLiBOb3RlIHRoYXQg
ZXZhbHVhdGlvbiBvZiB0aGUgWFBhdGggZXhwcmVzc2lvbiBpbiB0aGlzPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsgY2FzZSAod2l0aCAmcXVvdDtmb28mcXVvdDsgbWlzc2luZykgcmVxdWly
ZXMgdGhlIHBlY3VsaWFyIHByb2NlZHVyZSBvZiBzZWMuIDcuMjEuNTxicj4NCiZndDsgaW4gUkZD
IDc5NTAuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyZndDsgSW4gbXkgdmlldyB0aGlzIG1ha2VzIGNvbmRpdGlvbmFsbHkgdmFyaWFudCBz
Y2hlbWFzIOKAnGxvb3Nl4oCdIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IHRo
ZWlyIGVuZm9yY2VtZW50IChzb21lIHNjZW5hcmlvcyBjYW4gdXNlIGNob2ljZSBidXQgaXQgZG9l
c27igJl0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsmZ3Q7IGNvdmVyIGV2ZXJ5dGhpbmcp
Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgbWFuZGF0b3J5IHNob3VsZCBiZSByZXNwZWN0ZWQgZm9y
IHRoZSBlbmNsb3Npbmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgb2JqZWN0cyBv
ZiBhIOKAnHdoZW7igJ0gc3RhdGVtZW50LiZuYnNwOyBUaGF0IGlzLCBhIG1hbmRhdG9yeSBvYmpl
Y3QgbXVzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBiZSBwcmVzZW50IHdoZW4g
aXRzIOKAnHdoZW7igJ0gY2xhdXNlIGhvbGRzIHRydWUgYW5kIGEgU2NoZW1hdHJvbjxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0OyBzdGF0ZW1lbnQgc2hvdWxkIGVuZm9yY2UgdGhhdC48
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBJbiBmYWN0LCB0aGlzIGlzIG9uZSBjYXNlIHdo
ZXJlIHRoZSBEU0RMIG1hcHBpbmcgKFJGQyA2MTEwKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsm
Z3Q7IGRldmlhdGVzIGZyb20gWUFORyAxLjAuIE5vZGVzIHRoYXQgbWFuZGF0b3J5IGFyZW4ndCBl
bmNsb3NlZCBpbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IHRoZSBSRUxBWCBORyAmbHQ7
b3B0aW9uYWwmZ3Q7IHBhdHRlcm4sIGFuZCBhcmUgdGhlbiByZXF1aXJlZCBubyBtYXR0ZXIgd2hh
dDxicj4NCiZndDsgYW55ICZxdW90O3doZW4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
Jmd0OyBzdGF0ZW1lbnRzIHNheSAoYmVjYXVzZSBSRUxBWCBORyB2YWxpZGF0aW9uIGNvbWVzIGJl
Zm9yZTxicj4NCiZndDsgU2NoZW1hdHJvbikuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyZndDsgV2hhdCBpcyB0aGUgcmF0aW9uYWxlIGJl
aGluZCB0aGUgY3VycmVudCBZQU5HIHJ1bGVzIGJlaGF2aW9yLDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsmZ3Q7Jmd0OyB0aGF0IHRoZSDigJx3aGVu4oCdIFNjaGVtYXRyb24gbWFwcGluZyBkb2Vz
buKAmXQgY2hlY2sgZm9yIHByZXNlbmNlIG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsm
Z3Q7IHRoZSBlbmNsb3NpbmcgbWFuZGF0b3J5IG9iamVjdD88YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7Jmd0OyBGV0lXLCBJIGhhdmUgYmVlbiByZXBlYXRlZGx5IHByb3Rlc3RpbmcgYWdhaW5zdCB0
aGlzIGJlaGF2aW91cjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IGJ1dCB3aXRob3V0IG11
Y2ggbHVjay4gU2VlIGZvciBleGFtcGxlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE0MDEyLmh0bSIgdGFyZ2V0PSJfYmxh
bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVu
dC9tc2cxNDAxMi5odG08L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgbDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgQXMgYSBy
ZXN1bHQsICZxdW90O3doZW4mcXVvdDsgaXMgdGhlIHRyaWNraWVzdCBmZWF0dXJlIGluIFlBTkcg
YnkgZmFyLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyZndDsgTGFkYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyZndDsmZ3Q7IHRoYW5rczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7Jmd0
OyBNaWtlIFJlaGRlcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IC0tPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyZndDsgTGFkaXNsYXYgTGhvdGthPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyZndDsgSGVhZCwgQ1ouTklDIExhYnM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBQR1Ag
S2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IOKAnEFt
ZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdp
ZGUsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjbG91ZC1iYXNlZDxicj4NCiZndDsgJmd0OyAm
Z3Q7IHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBh
bmQgc3RvcmVkIHVzaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3VjaCBzeXN0ZW0gYW5kIGFyZSBh
Y2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0
byBBbWRvY3M8YnI+DQomZ3Q7ICZndDsgJmd0OyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRo
ZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZyw8YnI+DQomZ3Q7IHN0b3Jp
bmcgYW5kIGFjY2Vzc+KAnS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJt
YWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9h
Pjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDsg4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFy
dHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQ8YnI+DQomZ3Q7IHN5c3RlbS4gQW55IGVtYWlscyBz
ZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2g8YnI+
DQomZ3Q7IHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJz
IG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZDxicj4NCiZndDsgYmFzaXMuIFlvdXIgc2VuZGlu
ZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBv
Zjxicj4NCiZndDsgc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQg
YWNjZXNz4oCdLjxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0K
Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IC0tPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxi
cj4NCiZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbWFwcy5nb29nbGUuY29tLz9xPUNhbXB1cyYj
NDM7UmluZyYjNDM7MSYjNDM7JTdDJiM0MzsyODc1OSYjNDM7QnJlbWVuJiM0MzslN0MmIzQzO0dl
cm1hbnkmYW1wO2VudHJ5PWdtYWlsJmFtcDtzb3VyY2U9ZyIgdGFyZ2V0PSJfYmxhbmsiPkNhbXB1
cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PC9hPjxicj4NCiZndDsgRmF4OiZuYnNw
OyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+
DQrigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwg
d29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mg
d2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFj
Y2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGlt
aXRlZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscw0KIHRvIEFtZG9jcyBldmlkZW5jZXMg
eW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2lu
Zywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5v
cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ij4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnEFtZG9jc+KAmSBlbWFpbCBw
bGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2Vk
IHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQg
c3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0
eSBwcm92aWRlcnMNCiBvZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2Vu
ZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVz
ZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3Pi
gJ0uPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow
aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21h
cmdpbi1ib3R0b206LjAwMDFwdCI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxBbWRvY3PigJkgZW1h
aWwgcGxhdGZvcm0gaXMgYmFzZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1i
YXNlZCBzeXN0ZW0uIEFueSBlbWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQg
YW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQg
cGFydHkgcHJvdmlkZXJzDQogb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3Vy
IHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRo
ZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNj
ZXNz4oCdLjwvc3Bhbj48L2VtPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBw
dCAwLjVpbjsiPjxlbT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGZvbnQgZmFjZT0iQ2Fs
aWJyaSIgc2l6ZT0iMyI+4oCcQW1kb2Nz4oCZIGVtYWlsDQpwbGF0Zm9ybSBpcyBiYXNlZCBvbiBh
IHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55DQplbWFpbHMg
c2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNoIHN5
c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUNCmJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNo
IHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZg0KZW1haWxzIHRvIEFt
ZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5k
IHN1Y2gNCnByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48L2ZvbnQ+PC9zcGFuPjwv
ZW0+PC9wPg0KDQo8Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_AM0PR06MB4083E3B92D12FE1678CEDE52E7E20AM0PR06MB4083eurp_--



From nobody Fri Oct 12 07:13:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62397130E2E for ; Fri, 12 Oct 2018 07:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.054
X-Spam-Level: 
X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RypX1xUC; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jnedFzSC
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 jWpEkRa3vWx7 for ; Fri, 12 Oct 2018 07:13:51 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DA2130E1F for ; Fri, 12 Oct 2018 07:13:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539353629; x=1541945629; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f/5KGsyJkDqUF0ONEkXCtaZ701IM6j5gRy8/VGiDq40=; b=RypX1xUCIYUDKOkxfoMK6Xc5n2aHwWy+GKqgO5/V8KYEdgcCBjeOKfbXJGxOTLmB dC4Qx7nLOUQJAXNrhoQjzHhNsQx55S7zj29XlvyPLDJfqBNb5H6LfmzT/vnZnZAW bXsOAjT1Diy1L//73VrVxnSyB7/fcBC7YN+Vy/vmLOM=;
X-AuditID: c1b4fb2d-b4fff70000003a27-c9-5bc0ac1d39df
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.AF.14887.D1CA0CB5; Fri, 12 Oct 2018 16:13:49 +0200 (CEST)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 12 Oct 2018 16:13:48 +0200
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 12 Oct 2018 16:13:48 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EFercualyMUbGeuk2L7rFyDl+eCpJrZgeu1OM5/04y4=; b=jnedFzSCfmbPmJ8paQPrkFTtd7iX0vuUm2Ba4fGe3J/PGyeK81AiwRs9EhM+sWfPoHrXracSRVibQmjT0avbgtJzVpMVAx9qXJL9PRi76yT2Meh8LVBAdEqLCdbFhndLIyS3T7w82mQ1Nenal94YT44M5gUBTu0Tceenzw2TC5w=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2127.eurprd07.prod.outlook.com (10.169.137.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.12; Fri, 12 Oct 2018 14:13:47 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 14:13:47 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] Whitespace in XML encoding - allowed ?
Thread-Index: AQHUX65zMY3LKhsc8UeIQzNDxdo7xaUbrDIA
Date: Fri, 12 Oct 2018 14:13:47 +0000
Message-ID: <4bd29364-2e4c-8087-7d59-998ceeb525b3@ericsson.com>
References: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com>
In-Reply-To: <14e78aaa-4508-970a-d1a0-e091ffaf5c8e@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: HE1PR0902CA0008.eurprd09.prod.outlook.com (2603:10a6:3:e5::18) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2127; 6:p/xsqsFJGNVKilgUUfr/Bk12I0wW3jl8MFoIPB4cPRArxjtm8ZRpmNibS5tdAecZoDNreDH6048JtM+B/HnL1mue1kYvrMbX0dhAJZm3K4bj9ZhaqZLXceDUQjInAJPJbR7AfsC8OTgFENY5UIrrJ81rJcJe9AOJY6OTARcrLdDdhiY6ZUZu1lhPvtvih7owjzn1URClr63duwC9Iz6eaw5LFM33E2fgQgMp8dy+AP57cViArGMrZcDZBsEm4aqj8MioJkc/8/SCsnQ6kQhaF6naYS2l9tNsh0lQlSqyQe2S4YYiMhRdvgb4aGt6FRv5LkElljDNC4Mp9ApD2k4YVUNyPbx4sIYulBQPlDyrKJnFp/OajTh9uUwOjhf2lxqXDH+miycu3JVRb/7NeZmn9FF3g2qwWWkb0mn14vAkm0vDVVi3ccGz6W1Few02tyuWxfUoX4f7EbMHi8Y0CjMw3Q==; 5:G7Lh40T4PytIa2Sjz4I3MvrrBpD1lUdl3IbPSayFX7Bv21pJsmhAf3bcsX9Iti5HRBS7U9rbYaEoEEcEtBev+1Lk/wZ94fkveLmN4GyWq//VAMU7FSGmlP/4WdVOKs5n1mWgK/oaW5C1AGKBKnEt4wxtmkGP/8niHQVdtgQZ0LE=; 7:bfbbpEn9D5ipoYxwVT2vvx6ePJXqjDy8wcxf2FGXJ7c+WPo+1bWPlmPpcDAFCMXXZpkf+rNfTGsrdvyWYPtGWoomO7LSiDU+/tte4NRPr+0k7LCinZgWXPNYdlbQezSoLapDspQlWMOQSLZZK3XUTLPFxbaflX/5z+5RlVQTMpvEuaQ04vAWsuE4YpMSa/w0juF9ubyD4cUtwN7S17nSlPlFDEaSCbewEgOb4BR7XzPCHYKXw41f3qbr4iQLLZVJ
x-ms-office365-filtering-correlation-id: 9e855568-7da9-4ac4-a67b-08d6304cebd8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2127; 
x-ms-traffictypediagnostic: VI1PR0701MB2127:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(4982022)(52105095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991067); SRVR:VI1PR0701MB2127; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2127; 
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(136003)(346002)(39860400002)(199004)(189003)(252514010)(14454004)(53376002)(68736007)(6246003)(31686004)(3260700006)(25786009)(606006)(86362001)(36756003)(66066001)(6916009)(478600001)(65956001)(65806001)(966005)(99936001)(5660300001)(31696002)(64126003)(85182001)(2900100001)(65826007)(256004)(7736002)(386003)(186003)(2501003)(52116002)(5250100002)(81166006)(81156014)(85202003)(53936002)(106356001)(99286004)(97736004)(6506007)(236005)(2906002)(66574009)(446003)(71200400001)(71190400001)(102836004)(26005)(76176011)(3846002)(6512007)(476003)(2616005)(8936002)(486006)(11346002)(54896002)(1730700003)(6306002)(6116002)(58126008)(5640700003)(8676002)(6486002)(6436002)(229853002)(2351001)(105586002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2127; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: AfIW6fSK7XV6FUt6NwnOsybrR57sZUUnL2lUow8xI4vfA8TTcUMozEMzipGwOpkHfMjnvtI+9lokrRy+KMiMbIiXgeqA2EJa6aGI62Uh88fVfat+bdTENlqbG4napq8qKl8M8SguMqgA8gaTos/8JRQEIYlTJA767x8aWvEW2rDNG3lg7KBH1C8PmlqkFc076JPD+IWlQw6oZf+nL9EuabKo9vmePKsf2Yo5m//+ea9RXQcnCcwChbeaWfu3ZaePRSeqtEBQ22nA7xubzFibkhIOM2bUvrNcQe18h9V/Hy1Pdel3A7C3N1q6JgLvvx75/EPFT/CRPdHNpIuZC6pSoQmhpYr3mlEmR/eAVrkR2Wo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000604000909090503080604"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e855568-7da9-4ac4-a67b-08d6304cebd8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 14:13:47.4963 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2127
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0iTYRTHefa+294tB09L82CMaGV5SfNSUGleIMyQwCIhtJUjX7ykc+5d ptEHLa3UD6mkuBFpNKycqEwpFUNdDlreLfKSXZYKmREolaUl7d1jUN9+55z/+fM/Dw9DyYeF Xky6Rs/qNOpMpUhKG049zgtQNPYkBU0tSPbXjhYKo1CsyfRTEI8SpeEpbGZ6LqvbE5EsTTOP dAu140l5r5tWqQJkjy9FEgbwXrA03qdKkZSRYxuCtY8/RKT4jsDWahOTwiQAs2NAwBc0Lqeg YmhtfVItAMuDTiFvJsczCMaKg3kW4cNw/Uu3gGd3vAsMHc0injfhcGgpWRST/iEYnFuhCIfA pGPapaexNzzrfunylOFIeDh8lSb+kfBuoNfpwzASHAVN5VF8G+HNsPy80bVKYU+Ymq0VkNvc wTHaLyLsAfMza0LCSqj5NOViD6yCIrtRyN8CuAaBwWoQE9FuGByfRYQVMFZbhoioRwxFnUvr Tsdg7NcATQYvEDRXmig+Hb9d1R5N0p2Brrc31lNkw+CVtnWOg8JCO1WOgo3/BDc6rShcgqBo YlxkdD3ARrAbZmmj05bCO6G+WPm/nmd/qL+7QBEOg5qVXhHhbXCrzCEmvA8WbIuIcCjUN/0W 1SFpA/LgWI7LSg0JDWR16ec4LlsTqGH1FuT8Wr1tqwHtyLwQbUWYQUo32URxT5JcqM7l8rOs aIfT50OLeQR50ZpsDat0l9VlOMeyFHX+JVaXfVZ3IZPlrGgLQys9ZYENXYlynKrWs+dZVsvq /k4FjMSrAPlUBa2ptk4kMLa4476r8U8yWo3deKnPd7txpK637mT1Ne/lmPQ3Nd4jYz4Jxpmc r7H5lcITVlPH0UN9M22PclT68Gk/FQy5HemKkIe9dws5fe9AzivLRYdYPtf2NDHIOyauZYNM ofK/rP2mVX4uW2lWzSfX3jk4qbg9XSqpuNmvpLk0dbAfpePUfwCLlkmNYgMAAA==
Archived-At: 
Subject: Re: [netmod] Whitespace in XML encoding - allowed ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 14:13:55 -0000

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


  
    
  
  
    
Hello,

    
Thanks for all the replies. So preceding and following whitespace
      is not allowed. 

      However as I got similar questions often, and some RFC examples
      seem to indicate that it is allowed, I feel that an explanatory
      statement like the following would help YANG users.:

    
"It is not allowed to add preceding or following whitespace after
      the value of a leaf/leaf-list. 

      Note that some text documents may add whitespace to Netconf
      examples to avoid long lines, 

      however this extra whitespace MUST NOT be present in the actual
      Netconf encoding."

    
regards Balazs

    

    
On 2018. 10. 09. 10:59, Bal=C3=A1zs Le=
ngyel
      wrote:

    

    

      
      
Hello,

      
Recently we came up against a problem where a certain
        implementation did not accept the following:

      
<with-defaul=
ts xmlns=3D"...">
    report-all
</with-defaults>

      
while it did accept 

      

      
<with-defaul=
ts xmlns=3D"...">report-all</with-defaults>


      
I am unsure whether YANG's XML encoding allows whitespace
        before and after a leaf's value? In RFC7950 it does not say yes
        or no. I have found the following examples that seem to allow
        preceding/following whitespace:

      
https://tools.ietf.org/html/rfc7950#se=
ction-4.2.9

      
       <stat=
us xmlns=3D"http://example.com/system">
         The image example-fw-2.3 is being installed.
       </status>


      
https://tools.ietf.org/html/rfc7950#se=
ction-7.16.3

      
         <re=
porting-entity>
           /ex:interface[ex:name=3D'Ethernet0']
         </reporting-entity>


      
https://tools.ietf.org/html/rfc6243#ap=
pendix-A.3.1

      
        <wit=
h-defaults
         xmlns=3D"urn:ietf:params:xml:=
ns:yang:ietf-netconf-with-defaults">
          report-all
        </with-defaults>


      
It is problematic that this is not clarified. IMHO this should
        be clarified in an errata to rfc7950. Chose one:

      
    
        
  1. It is not allowed to add preceding or following whitespace
          after the value of a leaf/leaf-list. 
    
          Note that some text documents may add whitespace to Netconf
          examples to avoid long lines, 
    
          however this extra whitespace MUST NOT be present in the
          actual Netconf encoding.
    
        
    2. 
        
  2. It is not allowed to add preceding or following whitespace
          after the value of a leaf/leaf-list.
    3. 
        
  3. It is allowed to add preceding or following whitespace after
          the value of a leaf/leaf-list except 
    
          for string based types, where the whitespace could be part of
          the leaf's value itself..
    4. 
      

      
What do you think?

      

      
regards Balazs

      

      
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


      

      

      
____________________________=
___________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/netmod


    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  



--------------ms000604000909090503080604
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAxMjE0MTM0Mlow
LwYJKoZIhvcNAQkEMSIEIKHfA/zUePmiUVXCEJbYz3kVdvTT6h2Xgwo+nB3aAN8HMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBACLY2aoWQ1pB4pI5clynYxUTF4x8hgPQ89Prm0oxXi8N/sI7
gSpV+xkzS8VVNVlOcJQjjAHEsfHr2msKuNTci40rd/qJjNfG6Qj7ztVcHxm1uBwo5P5MG3Cf
m+HZiql237p3tzJ7NYiiqBrMazXIG0js+G/3m9Y50vR8e57aJFmHpvxuC1LKa/OE0I8H8RpG
rmTJ3HlGGrJuXTtX+keR7NX+0Ed4CPSVd5Uy0iusCCjfC7Uto0WzVmFqL19NWBGo0OjIcoYh
Z4UYUl+aqvy++4/zL4tE8wP/VGWVfATU8zXbXtlh6Nv0HpRZIvjRM3tlkyeo1kv0AMTH5InD
66SnzR8AAAAAAAA=

--------------ms000604000909090503080604--


From nobody Fri Oct 12 09:05:45 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8795E130E36 for ; Fri, 12 Oct 2018 09:05:43 -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, DKIMWL_WL_MED=-0.001, 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 zXaEsBPs9w1x for ; Fri, 12 Oct 2018 09:05:41 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EC5130DEB for ; Fri, 12 Oct 2018 09:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9246; q=dns/txt; s=iport; t=1539360341; x=1540569941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=aRJ6P+miVngcWkYlaPLxkTaHjEDtqQPz3d1vFnMQG90=; b=Tk+3DK0DWHmzT6hTDypg2Ts1NbDdwfXejDUTLzKlX/P6lgr6FzNuZY1x g+BRo53dtx/XvbSWXPQShoblN0cHphm5rGDnrT7JVHLFBRAKGi1qOU25k xCk7avIKon36OfnV5UM7xZNb7TxVwCDU2vPozgNLoba7GQFkd+XlKui7K A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAAAqxcBb/xbLJq0ZAUoaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFlAoELgkoSKIN1iHWNMi2RP4dCDYRsAoR9OBYBAwEBAgE?= =?us-ascii?q?BAm0ohTkBAQEBAgEjVgULCxgjBAMCAkYRBg0GAgEBgxyBegiIa50IgS4fhFi?= =?us-ascii?q?EYotdgUE/gTmCa4d/glcCnhwJkFIGF4FPhG+Ca4Ztj26GNoFaIYFVMxoIGxU?= =?us-ascii?q?7gmyCTo4JPjCMZAEB?=
X-IronPort-AV: E=Sophos;i="5.54,373,1534809600"; d="scan'208,217";a="7135301"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 16:05:38 +0000
Received: from [10.61.220.128] ([10.61.220.128]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9CG5a3X023556; Fri, 12 Oct 2018 16:05:37 GMT
To: Michael Rehder 
Cc: Andy Bierman , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>    
From: Robert Wilton 
Message-ID: <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>
Date: Fri, 12 Oct 2018 17:05:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4670FDBE1650E759BC2292E2"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.220.128, [10.61.220.128]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 16:05:43 -0000

This is a multi-part message in MIME format.
--------------4670FDBE1650E759BC2292E2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mike,


On 11/10/2018 19:05, Andy Bierman wrote:
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder 
> > wrote:
>
>     I think the wording is relevant - something can be conditional but
>     still required.
>
Yes, but I think that this is already expressed by a node that has both 
a when condition and mandatory statement.

container a {
   container x {
     when "some condition";
     leaf foo {
       mandatory true;
     }
     leaf bar {
       ...
     }
   }
   container y {
     leaf baz {
       mandatory true;
     }
     leaf tee {
       ...
     }
   }
}

a/x/foo is conditional (due to when) but required (if the when condition is met).
a/x/bar is conditional (due to when) but optional (if the when condition is met).
a/y/baz is unconditional but required.
a/y/tee is unconditional but optional.


>     It should be clarified that elements become implicitly “mandatory
>     false†when a “when†statement is used.
>
But they don't.

>     I would like to see an enhancement to YANG to control this
>     behavior, to allow the mandatory status to be enforced.
>
>     That is, support also “conditionally required†instead of only the
>     current “conditionally optionalâ€.
>
I'm trying to understand what this would even mean.

Taking your original example, but with "enforce-mandatory-status":

          leaf AssignmentMechanism {
             type enumeration {
               enum "DHCP";
               enum "Static";
             }
             mandatory true;
             description "The address assignment mechanism.";
           }
           list IPAddresses {
             when "../AssignmentMechanism = 'Static'" {
               enforce-mandatory-status;
             }  key Address;
             min-elements 1;
             
             leaf Address {
               type capit:IPv4Address;
               description "An ipv4 address.";
             }
            }


So this means that list IPaddresses must have at least one element 
regardless of whether the when condition holds.  I.e. no matter whether 
the assignment is DHCP or Static there must always be at least one 1 
address configured.  But I don't understand what this actually means - 
it seems like a contradiction.  What am I missing? Please can you give a 
concrete example (in YANG) of what behaviour you are looking for.

Thanks,
Rob


--------------4670FDBE1650E759BC2292E2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Mike,

    

    

    
On 11/10/2018 19:05, Andy Bierman
      wrote:

    

    

      
      


        


          
On Thu, Oct 11, 2018 at 11:00 AM,
            Michael Rehder <Michael.Rehder@amdocs.com>
            wrote:

            

              

                

                  
I
                      think the wording is relevant - something can be
                      conditional but still required.

                

              

            

          

        

      

    

    Yes, but I think that this is already expressed by a node that has
    both a when condition and mandatory statement.

    

    
container a {
  container x {
    when "some condition";
    leaf foo {
      mandatory true;
    }
    leaf bar {
      ...
    }
  }
  container y {
    leaf baz {
      mandatory true;
    }
    leaf tee {
      ...
    }
  }
}

a/x/foo is conditional (due to when) but required (if the when condition is met).
a/x/bar is conditional (due to when) but optional (if the when condition is met).
a/y/baz is unconditional but required.
a/y/tee is unconditional but optional.




    

      

        

          

            

              

                

                  
It
                      should be clarified that elements become
                      implicitly “mandatory false†when a “whenâ€
                      statement is used.

                

              

            

          

        

      

    

    But they don't.

    

    

      

        

          

            

              

                

                  
 

                  
I
                      would like to see an enhancement to YANG to
                      control this behavior, to allow the mandatory
                      status to be enforced.

                

              

            

          

        

      

    

    

      

        

          

            

              

                

                  
That
                      is, support also “conditionally required†instead
                      of only the current “conditionally optionalâ€.

                

              

            

          

        

      

    

    I'm trying to understand what this would even mean.

    

    Taking your original example, but with "enforce-mandatory-status":
    
         leaf AssignmentMechanism {
            type enumeration {
              enum "DHCP";
              enum "Static";
            }
            mandatory true;
            description "The address assignment mechanism.";
          }
          list IPAddresses {
            when "../AssignmentMechanism = 'Static'" {
              enforce-mandatory-status;
            }  key Address;
            min-elements 1;
            
            leaf Address {
              type capit:IPv4Address;
              description "An ipv4 address.";
            }
           }

    

    So this means that list IPaddresses must have at least one element
    regardless of whether the when condition holds.  I.e. no matter
    whether the assignment is DHCP or Static there must always be at
    least one 1 address configured.  But I don't understand what this
    actually means - it seems like a contradiction.  What am I missing? 
    Please can you give a concrete example (in YANG) of what behaviour
    you are looking for.

    

    Thanks,

    Rob

    

  


--------------4670FDBE1650E759BC2292E2--


From nobody Fri Oct 12 09:09:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B42130E4D for ; Fri, 12 Oct 2018 09:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level: 
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 1nMZx4IWdcTp for ; Fri, 12 Oct 2018 09:08:55 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C26E130E2F for ; Fri, 12 Oct 2018 09:08:53 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 12 Oct 2018 19:08:51 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE1 (10.237.240.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 12 Oct 2018 19:08:51 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 19:08:50 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Fri, 12 Oct 2018 19:08:50 +0300
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 19:08:50 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tqC+SkVYSxmcUssMKFMrDcRz7aHxmjnj4gikOFU4He0=; b=eXLVwquwSNgdTNRMtoyl4SDoe+FrpoUF4T2hNaPuxVnoR0Mo8xL1SDlYTEDycxnLeQlE2ISOpH2xwi33sZoeTGNlbBqiCsCUxP7U8x1Ln9oRaZ7Pqqa7HZbiWtcw8AlX6s98DmQcdMPCmxp1pkPiUhGh9hN+NScB0tIK6hflP84=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB5058.eurprd06.prod.outlook.com (20.178.19.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.27; Fri, 12 Oct 2018 16:08:48 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 16:08:48 +0000
From: Michael Rehder 
To: Robert Wilton 
CC: Andy Bierman , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoA=
Date: Fri, 12 Oct 2018 16:08:48 +0000
Message-ID: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>
In-Reply-To: <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB5058; 6:FCrIzZmn8e9Jn2JPkbIdUahzFy++xTHj04tvUpOvIQKHxTf5EJByY/xECAcNJq05GcObk05ryQDwOlTe8lDi9JfRaColt3WMcFU2gGUudgEvUT745Z6t3iXIsPi3pjOmGVnjdTyiQKSy5CZ/eh3fhUwWrmoHH4c1K13ykONE0utgFatjdURWgSIuewr4+74RpwHO4sRDE0RCC8SfUn7o+Z5/XfH27MbDEdccoZ7V4lXRKD9biJgMUA4vLNCBOe2kHIpqbPtA3E9bohV6v4T10cmwDdc1X6rXRRPtcGv1LADZlgfGguEbkmkMY4F/3S5wANlRnLnMNtBTch40whQaapRAhNbkWDhoPF+lKIHro4nVjzkUmrb7lEiI6JvXrhLAwLPsw5nd2WGNHaAxnRQYvlG6NQ0srbHp8GZGaI4hltPVDDZ0Wgjb/ZkzrdHDHoc4O/uKNIoYhupggCcMsGYRDw==; 5:B5WGBupEVLITcZM/NrUqRULpiDUC89Xc/BtIaMniniPctWOKE1lct++7bUnSPP8bOoN1rybqoCW7qxtojLDlUiJ7wC1Qz18/yuvViiwGST4sRDXvwzo+yfSaBNOq3qylgMmrXLAifmF/noDFCacomyPds/E7BSJLytWpkk8GUPs=; 7:hk6OFnp8yHXmR377/uNfmjGCQdJNqTuWI4sl1CC1A8yjejgUIJmFfWwC1O0UmHnA7io1PmJtPh/ZPO6zl/9X4U06s+ZTSnu4RSV/i8MLPtjCN0qF4sPi/HIwC67SNuDk7e3buqZSNpKJG7nz8S6CJtf1+hs7BBKQlep5SBmjlBjp+PJ/ZQDNDNXBP7Kb+IesuahClnyUQt9qxKUEMNSQZJk/PVt5vyrrIOIipNoD85fN8/qDCnotIzwCGIcYT2mY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: ab20aad6-96b7-4bf4-b839-08d6305cfea3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB5058; 
x-ms-traffictypediagnostic: AM0PR06MB5058:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014)(166566539817055)(62221491112393)(131327999870524)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(93006095)(93001095)(3002001)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:AM0PR06MB5058; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB5058; 
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(346002)(136003)(366004)(199004)(189003)(51444003)(7696005)(55016002)(76176011)(53936002)(236005)(9686003)(53546011)(54896002)(11346002)(486006)(5660300001)(6506007)(446003)(33656002)(6306002)(2900100001)(2906002)(99286004)(66066001)(14454004)(54906003)(106356001)(476003)(105586002)(26005)(102836004)(25786009)(4326008)(186003)(6436002)(8936002)(229853002)(72206003)(478600001)(97736004)(6246003)(5250100002)(8676002)(81166006)(81156014)(6916009)(86362001)(7736002)(3846002)(6116002)(74316002)(316002)(71200400001)(68736007)(71190400001)(93886005)(256004)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB5058; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: OvJaxplcoaViU0Bqm16dVrHY2IoK2es5x+g97H/sIUVdsqwzX62okTjv3aWvkaxPG7/W82qaO/GiQoqy2dMHQkBlRLkLVvr8ByKycGZGy/MphDaPiAnp7wjuiME6H8ECW3gUM6ybvFBrnSywep+7/1XqC7+5ZgvPuepMrWMLBudhSb5TtPJt4YfF0I2mCmhoizQ74SyUlsDvhwD7ydKnVdmgPGmbPlL9eX+RXldlQMv+HwbLtu4K3Agi9jTmWzH7A9bDgR4bPYlr2Y/iJhhBltSN9wRP9sC0je3XA8RKBd6a/tAFbFvgsgv6ZFk1mO5+cLr338pm9nTuxMa/dKaycxQjAzQXHniwQNy0l87JxRk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB40839FD87E10433E10B4377CE7E20AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ab20aad6-96b7-4bf4-b839-08d6305cfea3
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 16:08:48.5269 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB5058
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 16:08:58 -0000

--_000_AM0PR06MB40839FD87E10433E10B4377CE7E20AM0PR06MB4083eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

VGhlIG1hbmRhdG9yeSBzdGF0ZW1lbnQgaW4gdGhhdCBjYXNlIGlzIGlnbm9yZWQgKEnigJl2ZSBw
b2ludGVkIG91dCB0aGUgUk5HIGFuZCBTY2hlbWF0cm9uIGxhY2sgb2YgZW5mb3JjZW1lbnQpLg0K
V0hFTiB0cnVtcHMgdGhlIG1hbmRhdG9yeSBzdGF0dXMgKHZpYSBleHBsaWNpdCBtYW5kYXRvcnkg
b3IgaW1wbGljaXQgbWFuZGF0b3J5IHZpYSBtaW4tZWxlbWVudHMgMSkNCg0KVGhhbmtzDQpNaWtl
DQoNCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NClNlbnQ6
IEZyaWRheSwgT2N0b2JlciAxMiwgMjAxOCAxMjowNiBQTQ0KVG86IE1pY2hhZWwgUmVoZGVyIDxN
aWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPg0KQ2M6IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y
a3MuY29tPjsgV2Fsa2VyLCBKYXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSkgPEphc29u
X1dhbGtlcjJAY29tY2FzdC5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndCBlbnN1
cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3QNCg0KDQpIaSBNaWtlLA0KDQpPbiAx
MS8xMC8yMDE4IDE5OjA1LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQoNCg0KT24gVGh1LCBPY3QgMTEs
IDIwMTggYXQgMTE6MDAgQU0sIE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBhbWRvY3Mu
Y29tPG1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHRo
ZSB3b3JkaW5nIGlzIHJlbGV2YW50IC0gc29tZXRoaW5nIGNhbiBiZSBjb25kaXRpb25hbCBidXQg
c3RpbGwgcmVxdWlyZWQuDQpZZXMsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbHJlYWR5IGV4
cHJlc3NlZCBieSBhIG5vZGUgdGhhdCBoYXMgYm90aCBhIHdoZW4gY29uZGl0aW9uIGFuZCBtYW5k
YXRvcnkgc3RhdGVtZW50Lg0KDQoNCg0KY29udGFpbmVyIGEgew0KDQogIGNvbnRhaW5lciB4IHsN
Cg0KICAgIHdoZW4gInNvbWUgY29uZGl0aW9uIjsNCg0KICAgIGxlYWYgZm9vIHsNCg0KICAgICAg
bWFuZGF0b3J5IHRydWU7DQoNCiAgICB9DQoNCiAgICBsZWFmIGJhciB7DQoNCiAgICAgIC4uLg0K
DQogICAgfQ0KDQogIH0NCg0KICBjb250YWluZXIgeSB7DQoNCiAgICBsZWFmIGJheiB7DQoNCiAg
ICAgIG1hbmRhdG9yeSB0cnVlOw0KDQogICAgfQ0KDQogICAgbGVhZiB0ZWUgew0KDQogICAgICAu
Li4NCg0KICAgIH0NCg0KICB9DQoNCn0NCg0KDQoNCmEveC9mb28gaXMgY29uZGl0aW9uYWwgKGR1
ZSB0byB3aGVuKSBidXQgcmVxdWlyZWQgKGlmIHRoZSB3aGVuIGNvbmRpdGlvbiBpcyBtZXQpLg0K
DQphL3gvYmFyIGlzIGNvbmRpdGlvbmFsIChkdWUgdG8gd2hlbikgYnV0IG9wdGlvbmFsIChpZiB0
aGUgd2hlbiBjb25kaXRpb24gaXMgbWV0KS4NCg0KYS95L2JheiBpcyB1bmNvbmRpdGlvbmFsIGJ1
dCByZXF1aXJlZC4NCg0KYS95L3RlZSBpcyB1bmNvbmRpdGlvbmFsIGJ1dCBvcHRpb25hbC4NCg0K
DQoNCg0KSXQgc2hvdWxkIGJlIGNsYXJpZmllZCB0aGF0IGVsZW1lbnRzIGJlY29tZSBpbXBsaWNp
dGx5IOKAnG1hbmRhdG9yeSBmYWxzZeKAnSB3aGVuIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQgaXMg
dXNlZC4NCkJ1dCB0aGV5IGRvbid0Lg0KDQoNCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBlbmhh
bmNlbWVudCB0byBZQU5HIHRvIGNvbnRyb2wgdGhpcyBiZWhhdmlvciwgdG8gYWxsb3cgdGhlIG1h
bmRhdG9yeSBzdGF0dXMgdG8gYmUgZW5mb3JjZWQuDQpUaGF0IGlzLCBzdXBwb3J0IGFsc28g4oCc
Y29uZGl0aW9uYWxseSByZXF1aXJlZOKAnSBpbnN0ZWFkIG9mIG9ubHkgdGhlIGN1cnJlbnQg4oCc
Y29uZGl0aW9uYWxseSBvcHRpb25hbOKAnS4NCkknbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB3aGF0
IHRoaXMgd291bGQgZXZlbiBtZWFuLg0KDQpUYWtpbmcgeW91ciBvcmlnaW5hbCBleGFtcGxlLCBi
dXQgd2l0aCAiZW5mb3JjZS1tYW5kYXRvcnktc3RhdHVzIjoNCg0KICAgICAgICAgbGVhZiBBc3Np
Z25tZW50TWVjaGFuaXNtIHsNCg0KICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQoNCiAg
ICAgICAgICAgICAgZW51bSAiREhDUCI7DQoNCiAgICAgICAgICAgICAgZW51bSAiU3RhdGljIjsN
Cg0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCg0KICAgICAg
ICAgICAgZGVzY3JpcHRpb24gIlRoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtLiI7DQoN
CiAgICAgICAgICB9DQoNCiAgICAgICAgICBsaXN0IElQQWRkcmVzc2VzIHsNCg0KICAgICAgICAg
ICAgd2hlbiAiLi4vQXNzaWdubWVudE1lY2hhbmlzbSA9ICdTdGF0aWMnIiB7DQoNCiAgICAgICAg
ICAgICAgZW5mb3JjZS1tYW5kYXRvcnktc3RhdHVzOw0KDQogICAgICAgICAgICB9ICBrZXkgQWRk
cmVzczsNCg0KICAgICAgICAgICAgbWluLWVsZW1lbnRzIDE7DQoNCg0KDQogICAgICAgICAgICBs
ZWFmIEFkZHJlc3Mgew0KDQogICAgICAgICAgICAgIHR5cGUgY2FwaXQ6SVB2NEFkZHJlc3M7DQoN
CiAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkFuIGlwdjQgYWRkcmVzcy4iOw0KDQogICAgICAg
ICAgICB9DQoNCiAgICAgICAgICAgfQ0KDQpTbyB0aGlzIG1lYW5zIHRoYXQgbGlzdCBJUGFkZHJl
c3NlcyBtdXN0IGhhdmUgYXQgbGVhc3Qgb25lIGVsZW1lbnQgcmVnYXJkbGVzcyBvZiB3aGV0aGVy
IHRoZSB3aGVuIGNvbmRpdGlvbiBob2xkcy4gIEkuZS4gbm8gbWF0dGVyIHdoZXRoZXIgdGhlIGFz
c2lnbm1lbnQgaXMgREhDUCBvciBTdGF0aWMgdGhlcmUgbXVzdCBhbHdheXMgYmUgYXQgbGVhc3Qg
b25lIDEgYWRkcmVzcyBjb25maWd1cmVkLiAgQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRo
aXMgYWN0dWFsbHkgbWVhbnMgLSBpdCBzZWVtcyBsaWtlIGEgY29udHJhZGljdGlvbi4gIFdoYXQg
YW0gSSBtaXNzaW5nPyAgUGxlYXNlIGNhbiB5b3UgZ2l2ZSBhIGNvbmNyZXRlIGV4YW1wbGUgKGlu
IFlBTkcpIG9mIHdoYXQgYmVoYXZpb3VyIHlvdSBhcmUgbG9va2luZyBmb3IuDQoNClRoYW5rcywN
ClJvYg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFy
dHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQgdG8gQW1k
b2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3VjaCBzeXN0ZW0gYW5kIGFy
ZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3RlbSBvbiBh
IGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNl
cyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBwcm9jZXNz
aW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uCg==

--_000_AM0PR06MB40839FD87E10433E10B4377CE7E20AM0PR06MB4083eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIG1hbmRhdG9yeSBz
dGF0ZW1lbnQgaW4gdGhhdCBjYXNlIGlzIGlnbm9yZWQgKEnigJl2ZSBwb2ludGVkIG91dCB0aGUg
Uk5HIGFuZCBTY2hlbWF0cm9uIGxhY2sgb2YgZW5mb3JjZW1lbnQpLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5XSEVOIHRydW1wcyB0aGUgbWFuZGF0b3J5IHN0YXR1cyAodmlhIGV4cGxpY2l0IG1hbmRhdG9y
eSBvciBpbXBsaWNpdCBtYW5kYXRvcnkgdmlhIG1pbi1lbGVtZW50cyAxKTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1p
a2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdp
bHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh
eSwgT2N0b2JlciAxMiwgMjAxOCAxMjowNiBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBSZWhk
ZXIgJmx0O01pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmR5
IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs7IFdhbGtlciwgSmFzb24gKEphc29u
X1dhbGtlcjJAY29tY2FzdC5jb20pICZsdDtKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tJmd0Ozsg
bmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBXSEVOIHN0
YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndCBlbnN1cmUgcHJlc2VuY2Ug
b2YgdGhlIG1hbmRhdG9yeSBvYmplY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5IaSBN
aWtlLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTEvMTAvMjAxOCAxOTowNSwg
QW5keSBCaWVybWFuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiBUaHUsIE9jdCAxMSwgMjAxOCBhdCAxMTowMCBBTSwgTWljaGFlbCBSZWhkZXIgJmx0
OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+TWljaGFlbC5SZWhkZXJAYW1kb2NzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGUgd29yZGluZyBpcyByZWxldmFu
dCAtIHNvbWV0aGluZyBjYW4gYmUgY29uZGl0aW9uYWwgYnV0IHN0aWxsIHJlcXVpcmVkLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMs
IGJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbHJlYWR5IGV4cHJlc3NlZCBieSBhIG5vZGUgdGhh
dCBoYXMgYm90aCBhIHdoZW4gY29uZGl0aW9uIGFuZCBtYW5kYXRvcnkgc3RhdGVtZW50Ljxicj4N
Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5jb250YWluZXIgYSB7PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7IGNvbnRhaW5lciB4IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDsgd2hlbiAmcXVvdDtzb21lIGNvbmRpdGlvbiZxdW90Ozs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBmb28gezxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5kYXRvcnkg
dHJ1ZTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGJhciB7PG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgY29udGFpbmVyIHkgezxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGJheiB7PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0
cnVlOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgdGVlIHs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsgfTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPn08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5hL3gvZm9vIGlzIGNvbmRpdGlvbmFsIChkdWUg
dG8gd2hlbikgYnV0IHJlcXVpcmVkIChpZiB0aGUgd2hlbiBjb25kaXRpb24gaXMgbWV0KS48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5hL3gvYmFyIGlzIGNvbmRpdGlvbmFsIChkdWUgdG8gd2hlbikg
YnV0IG9wdGlvbmFsIChpZiB0aGUgd2hlbiBjb25kaXRpb24gaXMgbWV0KS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5hL3kvYmF6IGlzIHVuY29uZGl0aW9uYWwgYnV0IHJlcXVpcmVkLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPmEveS90ZWUgaXMgdW5jb25kaXRpb25hbCBidXQgb3B0aW9uYWwuPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+SXQgc2hvdWxkIGJlIGNsYXJpZmllZCB0aGF0IGVsZW1lbnRzIGJlY29tZSBpbXBs
aWNpdGx5IOKAnG1hbmRhdG9yeSBmYWxzZeKAnSB3aGVuIGEg4oCcd2hlbuKAnSBzdGF0ZW1lbnQg
aXMNCiB1c2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5CdXQgdGhleSBkb24ndC48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBlbmhhbmNlbWVudCB0
byBZQU5HIHRvIGNvbnRyb2wgdGhpcyBiZWhhdmlvciwgdG8gYWxsb3cgdGhlIG1hbmRhdG9yeSBz
dGF0dXMNCiB0byBiZSBlbmZvcmNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF0IGlz
LCBzdXBwb3J0IGFsc28g4oCcY29uZGl0aW9uYWxseSByZXF1aXJlZOKAnSBpbnN0ZWFkIG9mIG9u
bHkgdGhlIGN1cnJlbnQg4oCcY29uZGl0aW9uYWxseSBvcHRpb25hbOKAnS48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHRyeWluZyB0
byB1bmRlcnN0YW5kIHdoYXQgdGhpcyB3b3VsZCBldmVuIG1lYW4uPGJyPg0KPGJyPg0KVGFraW5n
IHlvdXIgb3JpZ2luYWwgZXhhbXBsZSwgYnV0IHdpdGggJnF1b3Q7ZW5mb3JjZS1tYW5kYXRvcnkt
c3RhdHVzJnF1b3Q7OiA8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBBc3NpZ25tZW50TWVjaGFuaXNt
IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBlbnVtZXJhdGlvbiB7PG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gJnF1b3Q7REhD
UCZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51
bSAmcXVvdDtTdGF0aWMmcXVvdDs7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuZGF0b3J5IHRydWU7PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uICZxdW90O1RoZSBhZGRyZXNzIGFz
c2lnbm1lbnQgbWVjaGFuaXNtLiZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBsaXN0IElQQWRkcmVzc2VzIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgd2hlbiAmcXVvdDsuLi9Bc3NpZ25tZW50TWVjaGFuaXNtID0gJ1N0YXRpYycmcXVv
dDsgezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmZvcmNl
LW1hbmRhdG9yeS1zdGF0dXM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJz
cDsga2V5IEFkZHJlc3M7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pbi1lbGVt
ZW50cyAxOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsZWFmIEFkZHJlc3MgezxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGNhcGl0OklQdjRBZGRyZXNzOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtB
biBpcHY0IGFkZHJlc3MuJnF1b3Q7OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpTbyB0aGlzIG1l
YW5zIHRoYXQgbGlzdCBJUGFkZHJlc3NlcyBtdXN0IGhhdmUgYXQgbGVhc3Qgb25lIGVsZW1lbnQg
cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSB3aGVuIGNvbmRpdGlvbiBob2xkcy4mbmJzcDsgSS5l
LiBubyBtYXR0ZXIgd2hldGhlciB0aGUgYXNzaWdubWVudCBpcyBESENQIG9yIFN0YXRpYyB0aGVy
ZSBtdXN0IGFsd2F5cyBiZSBhdCBsZWFzdCBvbmUgMSBhZGRyZXNzIGNvbmZpZ3VyZWQuJm5ic3A7
IEJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdA0KIHRoaXMgYWN0dWFsbHkgbWVhbnMgLSBpdCBz
ZWVtcyBsaWtlIGEgY29udHJhZGljdGlvbi4mbmJzcDsgV2hhdCBhbSBJIG1pc3Npbmc/Jm5ic3A7
IFBsZWFzZSBjYW4geW91IGdpdmUgYSBjb25jcmV0ZSBleGFtcGxlIChpbiBZQU5HKSBvZiB3aGF0
IGJlaGF2aW91ciB5b3UgYXJlIGxvb2tpbmcgZm9yLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpS
b2I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDBwdCAwLjVpbjsiPjxlbT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PGZvbnQgZmFj
ZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+4oCcQW1kb2Nz4oCZIGVtYWlsDQpwbGF0Zm9ybSBpcyBiYXNl
ZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55DQpl
bWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBz
dWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUNCmJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBv
ZiBzdWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZg0KZW1haWxz
IHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0
ZW0gYW5kIHN1Y2gNCnByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS48L2ZvbnQ+PC9z
cGFuPjwvZW0+PC9wPg0KDQo8Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_AM0PR06MB40839FD87E10433E10B4377CE7E20AM0PR06MB4083eurp_--


From nobody Fri Oct 12 09:09:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7978A130E37 for ; Fri, 12 Oct 2018 09:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 TvF4agptSU-1 for ; Fri, 12 Oct 2018 09:09:25 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 0EB87130E39 for ; Fri, 12 Oct 2018 09:09:25 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id z21-v6so11855718ljz.0 for ; Fri, 12 Oct 2018 09:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=86HqzWYweAJMoohJbyruLMeB2kBAk/jPe/3lEf3u7/Q=; b=wSjbCGaKhhnI5m8axYSvC18bClkWn80n8O28mIVQqZ3eK+DAO9/GYbSwzc7XDO2J04 n3oOPvLKeooHiM+W3tXNsHFIq6DroZQQIn0Srd++XxfkFARilFKt/WYGcpfnEPp9YtR4 Ipues6T9tRoDLY4rZe+u1fRA+izR1oRJ2DPKTuSd17x+WKdIEbQDrJaxFIkd1bFei75S Juq+leoazMra2ohoaFuOJw8KHLUP4VibS2B4ym8rOYBRn2mzuTsr7LdLKmk80pUb9DyR 73Q0v7ihNc/Pe1pSE/aumxROpMEPmvcvaNN+qCAv5/uEiFDwlGbcdgw6Ry/tsnfahdtW wQ3w==
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=86HqzWYweAJMoohJbyruLMeB2kBAk/jPe/3lEf3u7/Q=; b=eGdyWY3+dNHiIWUTHlJmvxtHO8k+xzxRgS4+tQ8BZh1wCmfoSciVgUYOSbu6bDt2Ap jkp2oNwRBnJcy/zdU4tdohfXJPPolWfbXE2nwWhPcFvxJpQih62yNtVK1ZWHrIRFTdzh d/dkmqk8MNYOzgvYpVxultFH7fL+ya+Dk2ugJk/ibIFz1/R7qXNnRE22JIuJHoWc6tuD F+aya7/O2MPsWKKHEy0uvfrCUSwhMKM5VVcBv+aEwprO6RNDrrDkmz/AVCQnM6tQOiv/ gKwVwNu1Vrtx30JQ3BqSdJLHuSUyPP5vBGefeTuT30s9Qif0oKXsmzMab5YGfWMQD8f1 3vvA==
X-Gm-Message-State: ABuFfohN9R8NHO6H/Y9vsq50HoVv8JdwF45XH/0xRKjcsUyyOxokI7vv Ac/FBOf1RWdb5zMZ8qwvAOqCM7XQGRWicJs4o6FGvA==
X-Google-Smtp-Source: ACcGV61UVpORBaZgG6qVDmFDLWh5YpBMpZd0/BN5JQgfvKmK33KX/VrrU83y87NJhUrGeHUw9s1cRr19+9qSUjOF5FU=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr4878677lja.21.1539360562907;  Fri, 12 Oct 2018 09:09:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Fri, 12 Oct 2018 09:09:21 -0700 (PDT)
In-Reply-To: 
References: <461820e8-4ed9-823b-a2c4-a04c74e4f7c1@cisco.com> <20181011.125007.434815114996317742.mbj@tail-f.com> <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>  
From: Andy Bierman 
Date: Fri, 12 Oct 2018 09:09:21 -0700
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000088a6f805780a4fd4"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 16:09:34 -0000

--00000000000088a6f805780a4fd4
Content-Type: text/plain; charset="UTF-8"

On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton  wrote:

> Hi Andy,
> On 11/10/2018 17:52, Andy Bierman wrote:
>
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton  wrote:
>
>>
>> ....
>>
>>>
>>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
>>>> 4.8.4), which also uses XPath expressions is meant to work. That
>>>> states:
>>>>
>>>> The set of namespace declarations is the set of prefix and
>>>>        namespace pairs for all supported YANG modules, where the prefix
>>>>        is the YANG module name and the namespace is as defined by the
>>>>        "namespace" statement in the YANG module.
>>>>
>>> Perfect!  It seems the authors of 8040 thought of this ;-)
>>>
>> OK, what you propose would at least be consistent with how the XPath is
>> formed in sec 8040, 4.8.4?
>>
>> I can live with that.  But still strongly think that WG should think of
>> trying to move YANG on from Xpath 1.0.
>>
>
>
> I do not agree YANG should change any statements where XPath is being used.
> (Note that leafs like the filter are free to use whatever data type they
> want, including yang:xpath1.0).
>
>
> OK, I think that I would be proposing either doing this as part of
> YANG.next, or perhaps as different leaf types.
>
>
> The WG is on the right track already wrt/ XPath by creating custom XPath
> functions
> like 'deref' that simplify syntax or extend functionality.
>
>
> Yes, the functions partially help.
>
> But there are bits of Xpath expressions that are not meaningful for YANG
> (e.g. NodeType checks or processing-instruction).
>
> The fact that NodeSets are sets rather than sequences isn't particularly
> helpful (fixed in future versions of XPath).
>
> E.g. if I wanted to check that a particular YANG boolean leaf is true then
> I might write "enabled = true" ... which is valid XPath, but probably
> doesn't do what most people expect ...
> When they realize that is wrong, perhaps they will try "enabled = true()"
> instead ... which is also valid XPath, but still probably won't do what
> they expect ...
> Instead they have to do 'enabled = "true"'.
>
> And then what about comparisons for 64 bit numbers that don't work
> properly?
>
> So, it seems like there are quite a lots of gotchas when using XPath for
> YANG, and it is far from an ideal language for expressing configuration
> constraints.
>
> If YANG adoption increases, and if folks start putting more validation
> constrains into the model then I hope that we will end up with a better
> language for expressing those constraints.
>
>

There are parts of XPath that are not used and most people are unaware
XPath even has
those details. Not a real problem.

There is usually a high cost to pay for instability. IMO we have already
seen that with the churn
that NMDA has caused. Training people over again has a cost.  Confusing
people by having
6 or 7 different path language variants that mostly look the same has a
cost.

I guess we will have this debate for real if YANG 2.0 is ever done


Thanks,
> Rob
>
>
Andy


>
>
>
>
>>
>>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
>>>> in very many places, e.g. why is it "/example-mod:event1/name='joe'"
>>>> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
>>>> wrong, or otherwise what am I missing? :-)
>>>>
>>> It seems the example is wrong!
>>>
>> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>> .
>>>
>>>
>>
>
> Andy
>
>
>

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




On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    

    
On 11/10/2018 17:5=
2, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Thu, Oct 11, 2018 at 9:45 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            


              ....

              

                

                

                  Finally, I'm trying to figure out have RFC 8040 query
                  parameter (sect

                  4.8.4), which also uses XPath expressions is meant to
                  work. That

                  states:

                  

                  The set of namespace declarations is the set of prefix
                  and

                  =C2=A0 =C2=A0 =C2=A0 =C2=A0namespace pairs for all suppor=
ted YANG modules,
                  where the prefix

                  =C2=A0 =C2=A0 =C2=A0 =C2=A0is the YANG module name and th=
e namespace is as
                  defined by the

                  =C2=A0 =C2=A0 =C2=A0 =C2=A0"namespace" statemen=
t in the YANG module.

                

                Perfect!=C2=A0 It seems the authors of 8040 thought of this
                ;-)

              

              OK, what you propose would at least be consistent with how
              the XPath is formed in sec 8040, 4.8.4?

              

              I can live with that.=C2=A0 But still strongly think that WG
              should think of trying to move YANG on from Xpath 1.0.

            

            


            

            


            

            
I do not agree YANG should change any statements where
              XPath is being used.

            
(Note that leafs like the filter are free to use
              whatever data type they want, including yang:xpath1.0).

          

        

      

    

    

    OK, I think that I would be proposing either doing this as part of
    YANG.next, or perhaps as different leaf types.

    

    

      

        

          

            


            

            
The WG is on the right track already wrt/ XPath by
              creating custom XPath functions

            
like 'deref' that simplify syntax or extend
              functionality. 

            

          

        

      

    

    

    Yes, the functions partially help.

    

    But there are bits of Xpath expressions that are not meaningful for
    YANG (e.g. NodeType checks or processing-instruction).

    

    The fact that NodeSets are sets rather than sequences isn't
    particularly helpful (fixed in future versions of XPath).

    

    E.g. if I wanted to check that a particular YANG boolean leaf is
    true then I might write "enabled =3D true" ... which is valid=
 XPath,
    but probably doesn't do what most people expect ...

    When they realize that is wrong, perhaps they will try "enabled =
=3D
    true()" instead ... which is also valid XPath, but still probably
    won't do what they expect ...

    Instead they have to do 'enabled =3D "true"'.

    

    And then what about comparisons for 64 bit numbers that don't work
    properly?

    

    So, it seems like there are quite a lots of gotchas when using XPath
    for YANG, and it is far from an ideal language for expressing
    configuration constraints.

    

    If YANG adoption increases, and if folks start putting more
    validation constrains into the model then I hope that we will end up
    with a better language for expressing those constraints.

    


There are par=
ts of XPath that are not used and most people are unaware XPath even has
those details. Not a real problem.

There i=
s usually a high cost to pay for instability. IMO we have already seen that=
 with the churn
that NMDA has caused. Training people over again =
has a cost.=C2=A0 Confusing people by having
6 or 7 different pat=
h language variants that mostly look the same has a cost.

I guess we will have this debate for real if YANG 2.0 is ever done<=
/div>



    Thanks,

    Rob

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

    

      

        

          

            


            

            


            

            

              

              

                

                

                  Yet the examples in section 8.3.6 don't seem to use
                  namespace prefixes

                  in very many places, e.g. why is it
                  "/example-mod:event1/name=3D'joe'"=


                  and not "/example-mod:event1/example-mod:name=
=3D'joe'"?=C2=A0
                  Is the example

                  wrong, or otherwise what am I missing? :-)

                

                It seems the example is wrong!

              

              Please can you check section 8040, 8.3.6.=C2=A0 Are all the
              examples wrong?

              

              Thanks,

              Rob

              

              

                

                

                /martin

                .

                

              

              

            

          

          

        

        


        

        
Andy

        


        

      

    

    

  






--00000000000088a6f805780a4fd4--


From nobody Fri Oct 12 09:29:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B586130E4D for ; Fri, 12 Oct 2018 09:29:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 sMM-D7jhMM8A for ; Fri, 12 Oct 2018 09:29:10 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 5D867130E3A for ; Fri, 12 Oct 2018 09:29:09 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id r191-v6so9766952lff.2 for ; Fri, 12 Oct 2018 09:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=15xrYkUKx640kFiVSRvEiRqnUoPFXDqWLZQWQf0jqLg=; b=Eve/Houtd19d0KBcR/LqyIpGS7LH91pgcpWLLPdpwCqJzx1q20Pa3NH9vTZedCHPMC iykuCYaHE8/6GGEKPBDerhEkoMo5Sa1G+T4Ufkk72F1/YYVUi8la7ZC6j4whpFVIosYL HpChy+4zzb+NQtDMU063GEDfKEzHrvaA0wZmR3+yB5QOqPlJKaflRM6rsweQxngYK2Me s7WDCsPPvgM7ceE+xN8fjr4Rj4xZ1NXoDlGcGqM1DJpZfZG/BwWLKQ6NaoS5eTztbsz3 /jUYToTFFn3xLYrF/oXtRcM4Oy2y2+A/ytwET4q3ZokyGPuwk5CT+99s6HDf1kljIlDo 9VkA==
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=15xrYkUKx640kFiVSRvEiRqnUoPFXDqWLZQWQf0jqLg=; b=HtBDwRfYeldno/+TGtZIvzPiqqkcGew9eBC7LPa+UpjYFftxP0YnES20n17SquhPWI nyMNkyVMI/qRY4wRw0hqJIHIafVOGmFxr7bDKZYQn2kfdm+HylF1Xmlp4emdAr/Vt5Y3 esMJNyvPQKPpNEakGVLHqGWI9YRsXSZhl76TlAI4qEUH3NnsssstajrPCMVSIS9OVKgI xDn9Hf3vAY8zw/zUX72+Cr/Qq5igOIMKbU7+BdDmnq+n4ARS6BpVngXS7VWxi8woUpoT hD6Ag9W4aUBBjYU6LQGZsdbs/fikQjUUz82B+j+572fTcGs29DEeKtEuU/FwBf0B9a9O 2Xrw==
X-Gm-Message-State: ABuFfoiHYivtUnMqxS01Y6WvParvxxFUxpfJOiIFcL+kW0uweptCM6HO 9irZVjW0y8zsaOgLM3kprLQjBOU+LduICRgLueY0Mdf5
X-Google-Smtp-Source: ACcGV63AXU3xG/qUDPlCAHAzX+pePgzcvH/9VA+MZuzbBMpTZx+Lnk4mn33xZlZFT3X5A1qMFC+zXK82KD2o2kp87Tg=
X-Received: by 2002:a19:f00a:: with SMTP id p10-v6mr4201883lfc.43.1539361747312;  Fri, 12 Oct 2018 09:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Fri, 12 Oct 2018 09:29:06 -0700 (PDT)
In-Reply-To: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com> 
From: Andy Bierman 
Date: Fri, 12 Oct 2018 09:29:06 -0700
Message-ID: 
To: Michael Rehder 
Cc: Robert Wilton ,  "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000213acd05780a9603"
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 16:29:12 -0000

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

On Fri, Oct 12, 2018 at 9:08 AM, Michael Rehder 
wrote:

> The mandatory statement in that case is ignored (I=E2=80=99ve pointed out=
 the RNG
> and Schematron lack of enforcement).
>
> WHEN trumps the mandatory status (via explicit mandatory or implicit
> mandatory via min-elements 1)
>
>
>


Implementation of the when-stmt is complicated, especially if the server is
expected to be fast.
RFC 7950 has many more details than RFC 6020 about implementation of this
statement,
but it is still difficult.

The schema dictates what can be in the instance documents. The when-stmt
modifies the
schema based on what is in the instance document.  Even the default value
goes away if the
when-stmt is false (as it should). I would be very surprised if static
document validation tools could handle that.

YANG validation is already heavyweight and complex to implement.
Allowing designers to pick and choose when which constraints are active,
would make much more complex.



> Thanks
>
> Mike
>

Andy


>
>
> *From:* Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Friday, October 12, 2018 12:06 PM
> *To:* Michael Rehder 
> *Cc:* Andy Bierman ; Walker, Jason (
> Jason_Walker2@comcast.com) ; netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
> Hi Mike,
>
>
>
> On 11/10/2018 19:05, Andy Bierman wrote:
>
>
>
>
>
> On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
> I think the wording is relevant - something can be conditional but still
> required.
>
> Yes, but I think that this is already expressed by a node that has both a
> when condition and mandatory statement.
>
>
> container a {
>
>   container x {
>
>     when "some condition";
>
>     leaf foo {
>
>       mandatory true;
>
>     }
>
>     leaf bar {
>
>       ...
>
>     }
>
>   }
>
>   container y {
>
>     leaf baz {
>
>       mandatory true;
>
>     }
>
>     leaf tee {
>
>       ...
>
>     }
>
>   }
>
> }
>
>
>
> a/x/foo is conditional (due to when) but required (if the when condition =
is met).
>
> a/x/bar is conditional (due to when) but optional (if the when condition =
is met).
>
> a/y/baz is unconditional but required.
>
> a/y/tee is unconditional but optional.
>
>
>
>
>
> It should be clarified that elements become implicitly =E2=80=9Cmandatory=
 false=E2=80=9D
> when a =E2=80=9Cwhen=E2=80=9D statement is used.
>
> But they don't.
>
>
>
>
> I would like to see an enhancement to YANG to control this behavior, to
> allow the mandatory status to be enforced.
>
> That is, support also =E2=80=9Cconditionally required=E2=80=9D instead of=
 only the current
> =E2=80=9Cconditionally optional=E2=80=9D.
>
> I'm trying to understand what this would even mean.
>
> Taking your original example, but with "enforce-mandatory-status":
>
>          leaf AssignmentMechanism {
>
>             type enumeration {
>
>               enum "DHCP";
>
>               enum "Static";
>
>             }
>
>             mandatory true;
>
>             description "The address assignment mechanism.";
>
>           }
>
>           list IPAddresses {
>
>             when "../AssignmentMechanism =3D 'Static'" {
>
>               enforce-mandatory-status;
>
>             }  key Address;
>
>             min-elements 1;
>
>
>
>             leaf Address {
>
>               type capit:IPv4Address;
>
>               description "An ipv4 address.";
>
>             }
>
>            }
>
>
> So this means that list IPaddresses must have at least one element
> regardless of whether the when condition holds.  I.e. no matter whether t=
he
> assignment is DHCP or Static there must always be at least one 1 address
> configured.  But I don't understand what this actually means - it seems
> like a contradiction.  What am I missing?  Please can you give a concrete
> example (in YANG) of what behaviour you are looking for.
>
> Thanks,
> Rob
>
> *=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, world=
wide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.*
>

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




On Fri, Oct 12, 2018 at 9:08 AM, Michael Rehder <<=
a href=3D"mailto:Michael.Rehder@amdocs.com" target=3D"_blank">Michael.Rehde=
r@amdocs.com> wrote:











The mandatory statement in that case =
is ignored (I=E2=80=99ve pointed out the RNG and Schematron lack of enforce=
ment).


WHEN trumps the mandatory status (via=
 explicit mandatory or implicit mandatory via min-elements 1)=



=C2=A0
<=
/blockquote>


Implementation of the when-s=
tmt is complicated, especially if the server is expected to be fast.
<=
div>RFC 7950 has many more details than RFC 6020 about implementation of th=
is statement,
but it is still difficult.

The schema dictates what can be in the instance documents. The when-stmt m=
odifies the
schema based on what is in the instance document.=C2=
=A0 Even the default value goes away if the
when-stmt is false (a=
s it should). I would be very surprised if static document validation tools=
 could handle that.

YANG validation is already hea=
vyweight and complex to implement.
Allowing designers to pick and=
 choose when which constraints are active, would make much more complex.

=C2=A0
<=
u>


Thanks


Mike

Andy
=C2=A0
=



=C2=A0








From: Robert Wilton [mailto:rwilton@cisco.com]


Sent: Friday, October 12, 2018 12:06 PM

To: Michael Rehder <Michael.Rehder@Amdocs.com>

Cc: Andy Bierman <andy@yumaworks.com>; Walker, Jason (Jason_Walker2@comcast.com) <=
Jason_Walker=
2@comcast.com>; netmod@ietf.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn&=
#39;t ensure presence of the mandatory object






=C2=A0


Hi Mike,


=C2=A0




On 11/10/2018 19:05, Andy Bierman wrote:








=C2=A0




=C2=A0




On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder <=
;Michael.Reh=
der@amdocs.com> wrote:








I think the wording is relevant - som=
ething can be conditional but still required.
















Yes, but I think that this is already expressed by a=
 node that has both a when condition and mandatory statement.








container a {


=C2=A0 container x {


=C2=A0=C2=A0=C2=A0 when "some condition";

=C2=A0=C2=A0=C2=A0 leaf foo {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mandatory true;


=C2=A0=C2=A0=C2=A0 }


=C2=A0=C2=A0=C2=A0 leaf bar {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...


=C2=A0=C2=A0=C2=A0 }


=C2=A0 }


=C2=A0 container y {


=C2=A0=C2=A0=C2=A0 leaf baz {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mandatory true;


=C2=A0=C2=A0=C2=A0 }


=C2=A0=C2=A0=C2=A0 leaf tee {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...


=C2=A0=C2=A0=C2=A0 }


=C2=A0 }


}


=C2=A0


a/x/foo is conditional (due to when) but required (if the when conditi=
on is met).


a/x/bar is conditional (due to when) but optional (if the when conditi=
on is met).


a/y/baz is unconditional but required.


a/y/tee is unconditional but optional.


=C2=A0


=C2=A0
















It should be clarified that elements =
become implicitly =E2=80=9Cmandatory false=E2=80=9D when a =E2=80=9Cwhen=E2=
=80=9D statement is
 used.
















But they don't.






















=C2=A0


I would like to see an enhancement to=
 YANG to control this behavior, to allow the mandatory status
 to be enforced.






























That is, support also =E2=80=9Ccondit=
ionally required=E2=80=9D instead of only the current =E2=80=9Cconditionall=
y optional=E2=80=9D.
















I'm trying to understand what this would even me=
an.



Taking your original example, but with "enforce-mandatory-status"=
: 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf AssignmentM=
echanism {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 typ=
e enumeration {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 enum "DHCP";


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 enum "Static";


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 man=
datory true;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 des=
cription "The address assignment mechanism.";


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list IPAddresse=
s {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whe=
n "../AssignmentMechanism =3D 'Static'" {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 enforce-mandatory-status;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=
=C2=A0 key Address;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 min=
-elements 1;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0leaf Address {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 type capit:IPv4Address;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description "An ipv4 address.";


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<=
u>




So this means that list IPaddresses must have at least one element regardle=
ss of whether the when condition holds.=C2=A0 I.e. no matter whether the as=
signment is DHCP or Static there must always be at least one 1 address conf=
igured.=C2=A0 But I don't understand what
 this actually means - it seems like a contradiction.=C2=A0 What am I missi=
ng?=C2=A0 Please can you give a concrete example (in YANG) of what behaviou=
r you are looking for.



Thanks,

Rob






=E2=80=9CAmdocs=E2=80=99 email
platform is based on a third-party, worldwide, cloud-based system. Any
emails sent to Amdocs will be processed and stored using such system and ar=
e accessible
by third party providers of such system on a limited basis. Your sending of
emails to Amdocs evidences your consent to the use of such system and such
processing, storing and access=E2=80=9D.









--000000000000213acd05780a9603--


From nobody Fri Oct 12 09:30:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE998130E06 for ; Fri, 12 Oct 2018 09:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.946
X-Spam-Level: 
X-Spam-Status: No, score=-14.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 uAKKZNtjML_o for ; Fri, 12 Oct 2018 09:30:09 -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 1BEE5130E3E for ; Fri, 12 Oct 2018 09:30:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20852; q=dns/txt; s=iport; t=1539361809; x=1540571409; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=nGItOjInJ3If8KMT2bvCQQ4udcwTiynvgf/ubf13OcI=; b=H/3Xl3jndm1lPiBFj9/ZjDVkGaONgnbKL57CiMMKBpVVWzoAWm5J07S9 kGIQT0n2iEvvhIby1XoT7PnrM3TyGz0OLr5fjCJJuUKWN9JVQUJ52CcrK OY9oksgAa1OlhiIZ4Ex5RGUNLrexToW15G9qCuTdz949pw2dFFaQEp3N7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAaysBb/xbLJq0ZAUoZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFTAgEBAQEBCwEBgQsBgkkSKIN1iHWNOiWXBxSBZg2?= =?us-ascii?q?EbAKEfTYLDQEDAQECAQECbSiFOQEBAQMBIwpMBQsJAhEEAQEBIAMEAwICRgk?= =?us-ascii?q?IBg0GAgEBF4MFgXoIiHSBPJtNgS4fhFiEYotdgUE/gTkMgl+ESwELBwFVgku?= =?us-ascii?q?CVwKeHAmQUgYXgU+Eb4Jrhm2PboY2gUoMJWRxMxoIGxU7gmyCTo4JPjCKDg8?= =?us-ascii?q?XgicBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,373,1534809600"; d="scan'208,217";a="7192012"
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; 12 Oct 2018 16:30:06 +0000
Received: from [10.61.220.128] ([10.61.220.128]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9CGU4YY005112; Fri, 12 Oct 2018 16:30:05 GMT
To: Michael Rehder 
Cc: Andy Bierman , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com> 
From: Robert Wilton 
Message-ID: <884fca1e-7366-b7a6-c588-0e64b3d032a0@cisco.com>
Date: Fri, 12 Oct 2018 17:30:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0282843CF8AFD4B524FFB6B9"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.220.128, [10.61.220.128]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 16:30:12 -0000

This is a multi-part message in MIME format.
--------------0282843CF8AFD4B524FFB6B9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/10/2018 17:08, Michael Rehder wrote:
>
> The mandatory statement in that case is ignored (I’ve pointed out the 
> RNG and Schematron lack of enforcement).
>
OK, I'm not familiar with RNG and Schematron.

> WHEN trumps the mandatory status (via explicit mandatory or implicit 
> mandatory via min-elements 1)
>
So I think that you are asking for mandatory to trump a when condition.  
Can you provide a concrete example where this is required, or even useful?

A solution here, that doesn't require any changes in the YANG language, 
would be to just move the when condition, down to each of the child 
nodes that are not marked as mandatory.

But, sorry, at the moment I'm still at a loss to see how where this 
would actually be useful.

Thanks,
Rob

> Thanks
>
> Mike
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Friday, October 12, 2018 12:06 PM
> *To:* Michael Rehder 
> *Cc:* Andy Bierman ; Walker, Jason 
> (Jason_Walker2@comcast.com) ; netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects 
> doesn't ensure presence of the mandatory object
>
> Hi Mike,
>
> On 11/10/2018 19:05, Andy Bierman wrote:
>
>     On Thu, Oct 11, 2018 at 11:00 AM, Michael Rehder
>     > wrote:
>
>         I think the wording is relevant - something can be conditional
>         but still required.
>
> Yes, but I think that this is already expressed by a node that has 
> both a when condition and mandatory statement.
>
>
> container a {
>    container x {
>      when "some condition";
>      leaf foo {
>        mandatory true;
>      }
>      leaf bar {
>        ...
>      }
>    }
>    container y {
>      leaf baz {
>        mandatory true;
>      }
>      leaf tee {
>        ...
>      }
>    }
> }
> a/x/foo is conditional (due to when) but required (if the when condition is met).
> a/x/bar is conditional (due to when) but optional (if the when condition is met).
> a/y/baz is unconditional but required.
> a/y/tee is unconditional but optional.
>
>         It should be clarified that elements become implicitly
>         “mandatory false†when a “when†statement is used.
>
> But they don't.
>
>
>         I would like to see an enhancement to YANG to control this
>         behavior, to allow the mandatory status to be enforced.
>
>         That is, support also “conditionally required†instead of only
>         the current “conditionally optionalâ€.
>
> I'm trying to understand what this would even mean.
>
> Taking your original example, but with "enforce-mandatory-status":
>
>           leaf AssignmentMechanism {
>              type enumeration {
>                enum "DHCP";
>                enum "Static";
>              }
>              mandatory true;
>              description "The address assignment mechanism.";
>            }
>            list IPAddresses {
>              when "../AssignmentMechanism = 'Static'" {
>                enforce-mandatory-status;
>              }  key Address;
>              min-elements 1;
>              
>              leaf Address {
>                type capit:IPv4Address;
>                description "An ipv4 address.";
>              }
>             }
>
>
> So this means that list IPaddresses must have at least one element 
> regardless of whether the when condition holds. I.e. no matter whether 
> the assignment is DHCP or Static there must always be at least one 1 
> address configured.  But I don't understand what this actually means - 
> it seems like a contradiction.  What am I missing?  Please can you 
> give a concrete example (in YANG) of what behaviour you are looking for.
>
> Thanks,
> Rob
>
> /“Amdocs’ email platform is based on a third-party, worldwide, 
> cloud-based system. Any emails sent to Amdocs will be processed and 
> stored using such system and are accessible by third party providers 
> of such system on a limited basis. Your sending of emails to Amdocs 
> evidences your consent to the use of such system and such processing, 
> storing and accessâ€./
>


--------------0282843CF8AFD4B524FFB6B9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 12/10/2018 17:08, Michael Rehder
      wrote:

    

    

      
      
      
      

        
The
            mandatory statement in that case is ignored (I’ve pointed
            out the RNG and Schematron lack of enforcement).

      

    

    OK, I'm not familiar with RNG and Schematron.

    

    

      

        

        
WHEN
            trumps the mandatory status (via explicit mandatory or
            implicit mandatory via min-elements 1)

      

    

    So I think that you are asking for mandatory to trump a when
    condition.  Can you provide a concrete example where this is
    required, or even useful?

    

    A solution here, that doesn't require any changes in the YANG
    language, would be to just move the when condition, down to each of
    the child nodes that are not marked as mandatory.

    

    But, sorry, at the moment I'm still at a loss to see how where this
    would actually be useful.

    

    Thanks,

    Rob

    

    

      

        

        
 

        
Thanks

        
Mike

        
 

        

          

            

              
From:
                  Robert Wilton [mailto:rwilton@cisco.com]
                  

                  Sent: Friday, October 12, 2018 12:06 PM

                  To: Michael Rehder
                  <Michael.Rehder@Amdocs.com>

                  Cc: Andy Bierman <andy@yumaworks.com>;
                  Walker, Jason (Jason_Walker2@comcast.com)
                  <Jason_Walker2@comcast.com>; netmod@ietf.org

                  Subject: Re: [netmod] WHEN statement within
                  mandatory objects doesn't ensure presence of the
                  mandatory object

            

          

          
 

          
Hi Mike,

          
 

          

            
On 11/10/2018 19:05, Andy Bierman
              wrote:

          

          

            

              
 

              

                
 

                

                  
On Thu, Oct 11, 2018 at 11:00 AM,
                    Michael Rehder <Michael.Rehder@amdocs.com>
                    wrote:

                  

                    

                      

                        
I
                            think the wording is relevant - something
                            can be conditional but still required.

                      

                    

                  

                

              

            

          

          
Yes, but I think that this is already
            expressed by a node that has both a when condition and
            mandatory statement.

            

            

            

          
container a {

          
  container x {

          
    when "some condition";

          
    leaf foo {

          
      mandatory true;

          
    }

          
    leaf bar {

          
      ...

          
    }

          
  }

          
  container y {

          
    leaf baz {

          
      mandatory true;

          
    }

          
    leaf tee {

          
      ...

          
    }

          
  }

          
}

          
 

          
a/x/foo is conditional (due to when) but required (if the when condition is met).

          
a/x/bar is conditional (due to when) but optional (if the when condition is met).

          
a/y/baz is unconditional but required.

          
a/y/tee is unconditional but optional.

          
 

          
 

          

            

              

                

                  

                    

                      

                        
It
                            should be clarified that elements become
                            implicitly “mandatory false†when a “whenâ€
                            statement is used.

                      

                    

                  

                

              

            

          

          
But they don't.

            

            

            

          

            

              

                

                  

                    

                      

                        
 

                        
I
                            would like to see an enhancement to YANG to
                            control this behavior, to allow the
                            mandatory status to be enforced.

                      

                    

                  

                

              

            

          

          

            

              

                

                  

                    

                      

                        
That
                            is, support also “conditionally requiredâ€
                            instead of only the current “conditionally
                            optionalâ€.

                      

                    

                  

                

              

            

          

          
I'm trying to understand what this would
            even mean.

            

            Taking your original example, but with
            "enforce-mandatory-status": 

          
         leaf AssignmentMechanism {

          
            type enumeration {

          
              enum "DHCP";

          
              enum "Static";

          
            }

          
            mandatory true;

          
            description "The address assignment mechanism.";

          
          }

          
          list IPAddresses {

          
            when "../AssignmentMechanism = 'Static'" {

          
              enforce-mandatory-status;

          
            }  key Address;

          
            min-elements 1;

          
            

          
            leaf Address {

          
              type capit:IPv4Address;

          
              description "An ipv4 address.";

          
            }

          
           }

          


            So this means that list IPaddresses must have at least one
            element regardless of whether the when condition holds. 
            I.e. no matter whether the assignment is DHCP or Static
            there must always be at least one 1 address configured.  But
            I don't understand what this actually means - it seems like
            a contradiction.  What am I missing?  Please can you give a
            concrete example (in YANG) of what behaviour you are looking
            for.

            

            Thanks,

            Rob

        

      

      
“Amdocs’
              email
              platform is based on a third-party, worldwide, cloud-based
              system. Any
              emails sent to Amdocs will be processed and stored using
              such system and are accessible
              by third party providers of such system on a limited
              basis. Your sending of
              emails to Amdocs evidences your consent to the use of such
              system and such
              processing, storing and accessâ€.

    

    

  


--------------0282843CF8AFD4B524FFB6B9--


From nobody Fri Oct 12 10:34:41 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683F130E60 for ; Fri, 12 Oct 2018 10:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.957
X-Spam-Level: 
X-Spam-Status: No, score=-14.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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 ezfBIEHl7IfB for ; Fri, 12 Oct 2018 10:34:36 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F15C130E1A for ; Fri, 12 Oct 2018 10:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15444; q=dns/txt; s=iport; t=1539365676; x=1540575276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0YOXsFVo1GE2Fog1AJVbnxQuhDoftdrz3ctm+6+/5LQ=; b=IFm4YRk3W2+iKj+Bg7QInizFD4uEIAADu6qsCvcjHJdGr4FIOg7wgW+6 oCYZggJYjkyIs9w0Jl5S+CCgkbbHcdroCh4T17vlZb+iYpwMX5g5FerwA CDHAp3yfNi63UKRQGfYgZN4pXn3BRcx/aWiL8IZfJmTclNsm77XQtw8VH k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAQ2sBb/4YNJK1aChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFUL2Z/KAqDa4gWjDGBaCWXB4F6CwE?= =?us-ascii?q?BGAsJg3pGAheERSE0DQ0BAwEBAgEBAm0cDIU5AQEBAwEBASEEDToLEAIBCA4?= =?us-ascii?q?KAgImAgICJQsVEAIECgQFgyABgXkID6VJezOJUwWBC4o7F4FBP4ESJwwTgky?= =?us-ascii?q?DGwEBgTZCI4JHMYImAohhhVmFdYkaUwkCkFYXgU+Eb4MRhkeVfQIRFIEmHTi?= =?us-ascii?q?BVXAVOyoBgkGLGIU+b4EoihQBgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,373,1534809600"; d="scan'208";a="184541545"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 17:34:35 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9CHYZNi022979 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Oct 2018 17:34:35 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Oct 2018 12:34:34 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 12 Oct 2018 12:34:34 -0500
From: "Reshad Rahman (rrahman)" 
To: Martin Bjorklund , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgIAASaoAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgABShQCAAAlqgIABCfeAgABTBAA=
Date: Fri, 12 Oct 2018 17:34:34 +0000
Message-ID: <09F70090-6876-462C-B2C4-0319CEAA10BC@cisco.com>
References: <7a9b1a5f-db66-7431-a2c7-82acebb2082b@cisco.com> <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com>
In-Reply-To: <20181012.103727.731509761734796510.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.54]
Content-Type: text/plain; charset="utf-8"
Content-ID: <726F579F0CEA044BB5E9C388DCEFE4E0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 17:34:40 -0000

T24gMjAxOC0xMC0xMiwgNDozNyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTWFydGluIEJqb3Jr
bHVuZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNv
bT4gd3JvdGU6DQoNCiAgICBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6
DQogICAgPiANCiAgICA+IA0KICAgID4gT24gMTEvMTAvMjAxOCAxNzoxMSwgTWFydGluIEJqb3Jr
bHVuZCB3cm90ZToNCiAgICA+ID4gUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdy
b3RlOg0KICAgID4gPj4NCiAgICA+ID4+IE9uIDExLzEwLzIwMTggMTE6NTAsIE1hcnRpbiBCam9y
a2x1bmQgd3JvdGU6DQogICAgPiA+Pj4gUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+
IHdyb3RlOg0KICAgID4gPj4+PiBPbiAxMS8xMC8yMDE4IDExOjIxLCBNYXJ0aW4gQmpvcmtsdW5k
IHdyb3RlOg0KICAgID4gPj4+Pj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdy
b3RlOg0KICAgID4gPj4+Pj4+IE9uIFdlZCwgT2N0IDEwLCAyMDE4IGF0IDExOjM5IFBNLCBNYXJ0
aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCiAgICA+ID4+Pj4+PiB3cm90ZToNCiAgICA+
ID4+Pj4+Pg0KICAgID4gPj4+Pj4+PiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4g
d3JvdGU6DQogICAgPiA+Pj4+Pj4+PiBPbiBXZWQsIE9jdCAxMCwgMjAxOCBhdCA2OjU5IFBNLCBS
ZXNoYWQgUmFobWFuIChycmFobWFuKSA8DQogICAgPiA+Pj4+Pj4+IHJyYWhtYW5AY2lzY28uY29t
Pg0KICAgID4gPj4+Pj4+Pj4gd3JvdGU6DQogICAgPiA+Pj4+Pj4+Pg0KICAgID4gPj4+Pj4+Pj4+
IE9uIDIwMTgtMTAtMTAsIDk6NTkgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRpbiBCam9y
a2x1bmQiIDwNCiAgICA+ID4+Pj4+Pj4+PiBuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh
bGYgb2YgbWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KICAgID4gPj4+Pj4+Pj4+DQogICAgPiA+Pj4+
Pj4+Pj4gICAgICAgIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQogICAg
PiA+Pj4+Pj4+Pj4gICAgICAgID4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdy
aXRlczoNCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPg0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+
ID4gSGksDQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gPg0KICAgID4gPj4+Pj4+Pj4+ICAgICAg
ICA+ID4gV2hpbGUgcmV2aWV3aW5nIHJlc3Rjb25mLW5vdGlmLCBJIHNhdyB0aGlzIGV4YW1wbGU6
DQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gPg0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4g
ICAgew0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4gICAgICAgImlldGYtc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zOmlucHV0Ijogew0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4gICAgICAg
ICAgInN0cmVhbSI6ICJORVRDT05GIiwNCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPiA+ICAgICAg
ICAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjogIi9kczpmb28vIiwNCiAgICA+ID4+Pj4+Pj4+PiAg
ICAgICAgPiA+ICAgICAgICAgICJkc2NwIjogIjEwIg0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+
ID4gICAgICAgfQ0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4gICAgfQ0KICAgID4gPj4+Pj4+
Pj4+ICAgICAgICA+ID4NCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPiA+IE5vdGUgdGhlICJzdHJl
YW0teHBhdGgtZmlsdGVyIi4gIEl0IGhhcyBhIHByZWZpeCBpbiB0aGUNCiAgICA+ID4+Pj4+Pj4+
PiAgICAgICAgPiA+IFhQYXRoDQogICAgPiA+Pj4+Pj4+Pj4gc3RyaW5nLg0KICAgID4gPj4+Pj4+
Pj4+ICAgICAgICA+ID4gSG93IGFyZSBwcmVmaXhlcyBkZWNsYXJlZCB3aGVuIEpTT04gaXMgdXNl
ZD8NCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPiA+DQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4g
PiBUaGUgbGVhZiAic3RyZWFtLXhwYXRoLWZpbHRlciIgc2F5czoNCiAgICA+ID4+Pj4+Pj4+PiAg
ICAgICAgPiA+DQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gPiAgICAgICAgICAgICAgIG8gVGhl
IHNldCBvZiBuYW1lc3BhY2UgZGVjbGFyYXRpb25zIGFyZQ0KICAgID4gPj4+Pj4+Pj4+ICAgICAg
ICA+ID4gICAgICAgICAgICAgICB0aG9zZQ0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4gICAg
ICAgICAgICAgICBpbg0KICAgID4gPj4+Pj4+Pj4+IHNjb3BlIG9uDQogICAgPiA+Pj4+Pj4+Pj4g
ICAgICAgID4gPiAgICAgICAgICAgICAgICAgIHRoZSAnc3RyZWFtLXhwYXRoLWZpbHRlcicgbGVh
ZiBlbGVtZW50Lg0KICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ID4NCiAgICA+ID4+Pj4+Pj4+PiAg
ICAgICAgPiA+IChJIHRoaW5rIEkgcHJvdmlkZWQgdGhhdCB0ZXh0Li4uKQ0KICAgID4gPj4+Pj4+
Pj4+ICAgICAgICA+ID4NCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPiA+IFRoaXMgYXNzdW1lcyB0
aGF0IHRoZSBlbmNvZGluZyBpcyBYTUwsIG9yIGF0IGxlYXMgdGhhdCB0aGUNCiAgICA+ID4+Pj4+
Pj4gZW5jb2RpbmcNCiAgICA+ID4+Pj4+Pj4+PiAgICAgICAgPiA+IGNhbiBzb21laG93IHRyYW5z
ZmVyIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMuDQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4NCiAg
ICA+ID4+Pj4+Pj4+PiAgICAgICAgPiBJdCBjYW4ndC4gVGhlcmUgYXJlIHR3byBvcHRpb25zOg0K
ICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+DQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gMS4gaGF2
ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIG9mIHRoaXMgdmFsdWUgaW4gWE1MIGFuZA0KICAg
ID4gPj4+Pj4+Pj4+ICAgICAgICA+IEpTT04sDQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gICAg
YW5hbG9naWNhbGx5IHRvIGluc3RhbmNlIGluZGVudGlmaWVycyAoc2VjLiA2LjExIGluIFJGQw0K
ICAgID4gPj4+Pj4+Pj4+ICAgICAgICA+ICAgIDc5NTEpLg0KICAgID4gPj4+Pj4+Pj4+ICAgICAg
ICA+DQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4gMi4gdXNlIGEgbW9kdWxlIG5hbWUgcmF0aGVy
IHRoYW4gYSBwcmVmaXggaW4gWE1MLCB0b28uDQogICAgPiA+Pj4+Pj4+Pj4gICAgICAgID4NCiAg
ICA+ID4+Pj4+Pj4+PiAgICAgICAgPiBJIHdvdWxkIHN1Z2dlc3QgIzIuDQogICAgPiA+Pj4+Pj4+
Pj4gPFJSPiBCdXQgdGhhdCBtZWFucyBtYWtpbmcgbm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIGNo
YW5nZSB0byB0aGUgWE1MDQogICAgPiA+Pj4+Pj4+Pj4gcmVwcmVzZW50YXRpb24/DQogICAgPiA+
Pj4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4+IE5vdCByZWFsbHkuIEl0IG1lYW5zIE5FVE1PRCBXRyB3
b3VsZCBiZSBjcmVhdGluZyBpdHMgb3duIHNwZWNpYWwNCiAgICA+ID4+Pj4+Pj4+IHZhcmlhbnQN
CiAgICA+ID4+Pj4+Pj4gb2YNCiAgICA+ID4+Pj4+Pj4+IFhQYXRoLg0KICAgID4gPj4+Pj4+PiBO
b3QgYXQgYWxsLiAgV2hhdCBJIHByb3Bvc2UgaXMgcGVyZmVjdGx5IGZpbmUsIGxlZ2FsIFhQYXRo
IDEuMC4NCiAgICA+ID4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4gWFBhdGggMS4wIHNheXMgdGhhdCBh
biBYUGF0aCBleHByZXNzaW9uIGlzIGV2YWx1YXRlZCBpbiBhIGNvbnRleHQuDQogICAgPiA+Pj4+
Pj4+IE9uZSBpdGVtIGluIHRoZSBjb250ZXh0IGlzIGEgc2V0IG9mIG1hcHBpbmdzIGZyb20gPHBy
ZWZpeD4gdG8gPHVyaT4sDQogICAgPiA+Pj4+Pj4+IHdoZXJlIDxwcmVmaXg+IGlzIHVzZWQgdG8g
bG9va3VwIHByZWZpeGVzIHVzZWQgaW4gdGhlIFhQYXRoDQogICAgPiA+Pj4+Pj4+IGV4cHJlc3Np
b24sIGUuZy4gaW4gIi9mb286aW50ZXJmYWNlcyIgImZvbyIgaXMgdGhlIHByZWZpeC4NCiAgICA+
ID4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4gSXQgaXMgcGVyZmVjdGx5IGZpbmUgdG8gc2F5IHRoYXQg
dGhlIHByZWZpeCBtYXBwaW5nIHNldCBpcyB0aGlzOg0KICAgID4gPj4+Pj4+Pg0KICAgID4gPj4+
Pj4+PiAgICAgICAiaWV0Zi1pbnRlcmZhY2VzIiAtPg0KICAgID4gPj4+Pj4+PiAgICAgICAidXJu
OmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaW50ZXJmYWNlcyINCiAgICA+ID4+Pj4+Pj4g
ICAgICAgImlldGYtaXAiICAgICAgICAgLT4gInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp
ZXRmLWlwIg0KICAgID4gPj4+Pj4+Pg0KICAgID4gPj4+Pj4+PiBhbmQgdXNlIHRoYXQgdG8gZXZh
bHVhdGUgdGhlIGV4cHJlc3Npb24NCiAgICA+ID4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4gICAgICAv
aWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRm
LWlwL2lwdjQNCiAgICA+ID4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4NCiAgICA+ID4+Pj4+Pj4NCiAg
ICA+ID4+Pj4+PiBUaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBub3JtYWxseSBwYXJzZWQgd2l0aGlu
IGFuIFhNTCBpbnN0YW5jZQ0KICAgID4gPj4+Pj4+IGRvY3VtZW50Lg0KICAgID4gPj4+Pj4+IFRo
ZXJlIGFyZSAieG1sbnMiIGF0dHJpYnV0ZXMgcHJlc2VudCB0aGF0IG1hcCB0aGUgcHJlZml4IHRv
IGENCiAgICA+ID4+Pj4+PiBuYW1lc3BhY2UgVVJJLg0KICAgID4gPj4+Pj4+IFRoZXNlIG1hcHBp
bmdzIHdpbGwgbm90IGJlIHByZXNlbnQgaW4gdGhlIEpTT04gYXQgYWxsLg0KICAgID4gPj4+Pj4+
DQogICAgPiA+Pj4+Pj4gQSBjdXN0b20gWFBhdGggaW1wbGVtZW50YXRpb24gaXMgcmVxdWlyZWQg
dG8gbWFnaWNhbGx5IGlkZW50aWZ5IHRoZQ0KICAgID4gPj4+Pj4+IHByZWZpeA0KICAgID4gPj4+
Pj4+IGFzIGEgbW9kdWxlIG5hbWUgYW5kIG1hZ2ljYWxseSBmaW5kIHRoZSBuYW1lc3BhY2UgVVJJ
IGZvciB0aGUgbW9kdWxlDQogICAgPiA+Pj4+Pj4gbmFtZS4NCiAgICA+ID4+Pj4+IEkgZGlzYWdy
ZWUuICBZb3UgbmVlZCBhbiBYUGF0aCBpbXBsZW1lbnRhdGlvbiArIGN1c3RvbSBjb2RlIHRvIHNl
dCB1cA0KICAgID4gPj4+Pj4gdGhlIGVudmlyb25tZW50Lg0KICAgID4gPj4+PiBUaGlzIGlzIE9L
LCBidXQgY2FuIHdlIGp1c3QgdXNlIHRoZSBKU09OIGVuY29kaW5nIGluc3RhbmNlIGlkZW50aWZp
ZXINCiAgICA+ID4+Pj4gZm9ybWF0IGV4YWN0bHk/ICBJLmUgLlJGQyA3OTUxIHNlY3Rpb24gNi4x
MS4NCiAgICA+ID4+Pj4NCiAgICA+ID4+Pj4gU28gIi9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNl
cy9pbnRlcmZhY2UvaWV0Zi1pcDppcHY0L2VuYWJsZWQiDQogICAgPiA+Pj4+DQogICAgPiA+Pj4+
IGNhbiB0cml2aWFsbHkgYmUgZXhwYW5kZWQgdG86DQogICAgPiA+Pj4+DQogICAgPiA+Pj4+ICIv
aWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRm
LWlwOmlwdjQvaWV0Zi1pcDplbmFibGVkIiwNCiAgICA+ID4+Pj4NCiAgICA+ID4+Pj4gYW5kIHRo
ZW4gaW50ZXJwcmV0ZWQgd2l0aCB0aGUgY29udGV4dDoNCiAgICA+ID4+Pj4gICAgICAgICJpZXRm
LWludGVyZmFjZXMiIC0+ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pbnRlcmZh
Y2VzIg0KICAgID4gPj4+PiAgICAgICJpZXRmLWlwIiAgICAgICAgIC0+ICJ1cm46aWV0ZjpwYXJh
bXM6eG1sOm5zOnlhbmc6aWV0Zi1pcCINCiAgICA+ID4+PiAqdGhpcyogd291bGQgcmVxdWlyZSBh
IGN1c3RvbSBYUGF0aCBpbXBsZW1lbnRhdGlvbi4NCiAgICA+ID4+IFdoeT8gIEkuZS4gaG93IGlz
IHRoaXMgZGlmZmVyZW50IGZyb20gc3RhdGluZyAiQ3VzdG9tIGNvZGUgaXMgbmVlZGVkDQogICAg
PiA+PiB0byBjb25uZWN0IHRoaW5ncyB0b2dldGhlciI/DQogICAgPiA+IEIvYyB0aGUgc3BlY2lm
aWNhdGlvbiBvZiBYUGF0aCBhbGxvd3MgeW91IHRvIChhY3R1YWxseSwgKnJlcXVpcmVzKiB5b3UN
CiAgICA+ID4gdG8pIGNvbnN0cnVjdCB0aGUgc2V0IG9mIHByZWZpeCBzdHJpbmdzIHRvIHVybCBt
YXBwaW5ncy4NCiAgICA+ID4NCiAgICA+ID4gVGhpcyBpcyAiY3VzdG9tIGNvZGUgdG8gY29ubmVj
dCB0aGluZ3MiLg0KICAgID4gPg0KICAgID4gPiBCdXQgY2hhbmdpbmcgdGhlIHN5bnRheCBtZWFu
cyBjaGFuZ2luIHRoZSBzcGVjaWZpY2F0aW9uLg0KICAgID4gTm90IHJlYWxseS4NCiAgICA+IA0K
ICAgID4gSXQgd291bGQganVzdCBtZWFuIHRoYXQgdGhlIGZpbHRlciB2YWx1ZSBpcyBub3QgYW4g
IlhwYXRoIg0KICAgID4gZXhwcmVzc2lvbi4gIEl0IGlzIGEgbW9yZSBhIGNvbmNpc2Ugc3RyaW5n
IHRoYXQgY2FuIGJlIGV4cGFuZGVkIGludG8NCiAgICA+IGFuIFhwYXRoIGV4cHJlc3Npb24uDQog
ICAgPiANCiAgICA+ID4NCiAgICA+ID4+PiBhbmQgaXQgaXMgbm90IG9idmlvdXMgd2hhdCB0aGUg
cnVsZXMgZm9yIHRoZSAiYXV0by1hc3NpZ25tZW50IiBvZg0KICAgID4gPj4+IHByZWZpeGVzIHdv
dWxkIGJlLiAgRm9yIGV4YW1wbGU6DQogICAgPiA+Pj4NCiAgICA+ID4+PiAgICAgL2lldGYtaW50
ZXJmYWNlcy8vaWV0Zi1pcDphZGRyZXNzWy4uL2Zvb10NCiAgICA+ID4+Pg0KICAgID4gPj4+IHdo
YXQgaXMgdGhlIHByZWZpeCBmb3IgImZvbyI/DQogICAgPiA+PiBPSywgc28gaGVyZSB0aGUgbW9k
dWxlIGZvciAiLi4vZm9vIiB3b3VsZCBuZWVkIHRvIGJlIHNwZWNpZmllZC4NCiAgICA+ID4+DQog
ICAgPiA+PiBQZXJoYXBzIHRoZSBydWxlIHRoYXQgSSdtIGxvb2tpbmcgZm9yIGlzIHRoZSBtb2R1
bGUgbmFtZSBtYXkgYmUNCiAgICA+ID4+IG9taXR0ZWQgd2hlbiBpdCBtYXRjaGVzIHRoZSBwYXJl
bnQgbm9kZSBtb2R1bGUsIGFuZCBjYW4gZWFzaWx5IGJlDQogICAgPiA+PiBpbmZlcnJlZC4gIEku
ZS4gc28gdGhhdCBmb3IgYW55IFhQYXRoIHN0cmluZywgaXQgaXMgcG9zc2libGUgdG8NCiAgICA+
ID4+IHRyaXZpYWxseSBleHBhbmQgaXQgd2l0aG91dCBhbnkgYWRkaXRpb25hbCBzY2hlbWEgY29u
dGV4dC4NCiAgICA+ID4+DQogICAgPiA+PiBJdCBqdXN0IHNlZW1zIHRvIGJlIHRoYXQgcmVxdWly
aW5nIHRoZSBsb25nIGhhbmQgb2YNCiAgICA+ID4+ICIvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFj
ZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRmLWlwOmlwdjQvaWV0Zi1pcDplbmFibGVk
Ig0KICAgID4gPj4gc2VlbXMgbGlrZSBpdCB3aWxsIGdldCB2ZXJ5IHZlcmJvc2UsIGFuZCBJIHdv
bmRlciB3aGV0aGVyIHdlIGFyZQ0KICAgID4gPj4gaW50cm9kdWNpbmcgeWV0IGFub3RoZXIgWHBh
dGggZm9ybWF0IHRvIFlBTkcuDQogICAgPiA+IEkgYWdyZWUgdGhhdCBpdCBpcyB2ZXJ5IHZlcmJv
c2UuICBCdXQgZG8gbm90IG1peCBYUGF0aCBleHByZXNzaW9ucyBpbg0KICAgID4gPiBsZWFmIHZh
bHVlcyAod2hpY2ggaXMgd2hhdCB0aGlzIHRocmVhZCBpcyBhYm91dCkgd2l0aA0KICAgID4gPiBp
bnN0YW5jZS1pZGVudGZpZXJzLg0KICAgID4gT0ssIGJ1dCB1bHRpbWF0ZWx5Og0KICAgID4gLSB0
aGVzZSBhcmUgYm90aCBsZWFmIHZhbHVlcy4NCiAgICA+IC0gdGhleSBib3RoIGlkZW50aWZ5IG5v
ZGVzIGluIGEgWUFORyBkYXRhc3RvcmUuDQogICAgPiAtIHRoZSBmYWN0IHRoYXQgdGhlaXIgZm9y
bWF0IGlzIHNvbWV3aGF0IHN1YnRsZXR5IGRpZmZlcmVudCB3aWxsIGNhdGNoDQogICAgPiAgIHBl
b3BsZSBvdXQuDQogICAgDQogICAgQWdyZWVkLg0KICAgIA0KICAgIFdlIGFscmVhZHkgaGF2ZToN
CiAgICANCiAgICAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIgaW4gWE1MIHVzZXMgcHJlZml4ZXMg
ZnJvbSB0aGUgWE1MIGRvY3VtZW50DQogICAgICBvICBpbnN0YW5jZS1pZGVudGlmaWVyIGluIEpT
T04gdXNlcyBtb2R1bGUgbmFtZXMgYXMgcHJlZml4ZXMNCiAgICAgIG8gIFhQYXRoIGluIE5FVENP
TkYgZmlsdGVyIHVzZXMgcHJlZml4ZXMgZnJvbSB0aGUgWE1MIGRvY3VtZW50DQogICAgICBvICBY
UGF0aCBpbiBKU09OIHF1ZXJ5IGZpbHRlciB1c2VzIG1vZHVsZSBuYW1lcyBhcyBwcmVmaXhlcw0K
ICAgIA0KICAgIFNvIGFuIGFsdGVybmF0aXZlIGNvdWxkIGJlIHRvIHVzZSBkaWZmZXJlbnQgZW5j
b2RpbmdzIGZvcg0KICAgICJzdHJlYW0teHBhdGgtZmlsdGVyIiBhcyB3ZWxsLCBkZXBlbmRpbmcg
b24gaWYgaXQgaXMgWE1MIG9yIEpTT04uDQogICAgDQogICAgU28sIHdlIGNvdWxkIGRvIGluIFNO
Og0KICAgIA0KICAgICAgICAgICAgICAgICBvICBJZiB0aGUgbm9kZSBpcyBlbmNvZGVkIGluIFhN
TCwgdGhlIHNldCBvZiBuYW1lc3BhY2UNCiAgICAgICAgICAgICAgICAgICAgZGVjbGFyYXRpb25z
IGFyZSB0aG9zZSBpbiBzY29wZSBvbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgJ3N0cmVhbS14
cGF0aC1maWx0ZXInIGxlYWYgZWxlbWVudC4NCiAgICANCiAgICAgICAgICAgICAgICAgbyAgSWYg
dGhlIG5vZGUgaXMgZW5jb2RlZCBpbiBKU09OLCB0aGUgc2V0IG9mIG5hbWVzcGFjZQ0KICAgICAg
ICAgICAgICAgICAgICBkZWNsYXJhdGlvbnMgaXMgdGhlIHNldCBvZiBwcmVmaXggYW5kIG5hbWVz
cGFjZSBwYWlycw0KICAgICAgICAgICAgICAgICAgICBmb3IgYWxsIHN1cHBvcnRlZCBZQU5HIG1v
ZHVsZXMsIHdoZXJlIHRoZSBwcmVmaXggaXMNCiAgICAgICAgICAgICAgICAgICAgdGhlIFlBTkcg
bW9kdWxlIG5hbWUgYW5kIHRoZSBuYW1lc3BhY2UgaXMgYXMgZGVmaW5lZA0KICAgICAgICAgICAg
ICAgICAgICBieSB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVsZS4N
Cg0KICAgIFRoaXMgaXMgZmFyIGZyb20gcGVyZmVjdCwgYnV0IGF0IGxlYXN0IHRoZSBmb3JtYXQg
aXMgY29uc2lzdGVudCB3aXRoaW4NCiAgICBlYWNoIGVuY29kaW5nLiAgDQo8UlI+IEknZCBiZSBv
ayB3aXRoIHRoYXQgc2luY2UgaXQncyBjb25zaXN0ZW50IHdpdGggd2hhdCdzIGFscmVhZHkgZG9u
ZSBmb3Igb3RoZXIgInR5cGVzIi4gU28gdGhlIHN0cmVhbS14cGF0aC1maWx0ZXIgaW4gQS4xLjEg
b2YgUkVTVENPTkYtbm90aWYgd291bGQgYmUgYWxvbmcgdGhlIGxpbmVzIG9mICIvZXgtZm9vOmZv
by8iLg0KDQoNCk9uZSBwcm9ibGVtIGlzIHRoYXQgaXQgaXMgdW5jbGVhciBob3cgdG8gaGFuZGxl
IG90aGVyDQogICAgZW5jb2RpbmdzLg0KICAgIA0KICAgIA0KICAgIElmIHdlIGRvIHRoaXMsIHdl
J2xsIHNldCBhIHByZWNlZGVuY2UgZm9yIGZ1dHVyZSBtb2RlbHMuDQogICAgDQogICAgTm93LCBz
dXBwb3NlIHdlIGhhdmUgYSBtb2R1bGUgImV4LWZvbyIgd2l0aCBuYW1lc3BhY2UNCiAgICAidXJu
OmV4YW1wbGU6Zm9vIi4gIElmIGFuIFhNTCBjbGllbnQgd3JpdGVzOg0KICAgIA0KICAgICAgIDxl
eGFtcGxlLWV4cHIgeG1sbnM6Zj0idXJuOmV4YW1wbGU6Zm9vIj4NCiAgICAgICAgIC9mOmJhci9m
OmJheg0KICAgICAgIDwvZXhhbXBsZS1leHByPg0KICAgIA0KICAgIGEgSlNPTiB3aWxsIHJlYWQg
dGhpcyBub2RlIGFzOg0KICAgIA0KICAgICAgICJleGFtcGxlLWV4cHIiOiAiL2V4LWZvbzpiYXIv
ZXgtZm9vOmJheiINCiAgICANCiAgICANCiAgICBbVGhpcyBjb250ZXh0LWRlcGVuZGVudCBlbmNv
ZGluZyB0aGF0IHdlIGhhdmUgZm9yIGEgY291cGxlIG9mIHR5cGVzIGlzDQogICAgcHJvYmFibHkg
dGhlIGJpZ2dlc3QgbWlzdGFrZSBpbiBZQU5HXQ0KICAgIA0KICAgIA0KICAgIEJUVywgd2UgYWxy
ZWFkeSBoYXZlIHRoaXMgaXNzdWUgdy8gTkFDTSdzIG5vZGUtaW5zdGFuY2UtaWRlbnRpZmllci4N
CiAgICBJdCBpcyBoaWdobHkgdW5jbGVhciB3aGF0IGEgSlNPTiBjbGllbnQgaXMgc3VwcG9zZWQg
dG8gc2VlIGlmIGl0IHJlYWRzDQogICAgTkFDTSBydWxlcyB3aXRoIG5vZGUtaW5zdGFuY2UtaWRl
bnRpZmllcnMuDQogICAgDQogICAgPiA+PiBGaW5hbGx5LCBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBv
dXQgaGF2ZSBSRkMgODA0MCBxdWVyeSBwYXJhbWV0ZXIgKHNlY3QNCiAgICA+ID4+IDQuOC40KSwg
d2hpY2ggYWxzbyB1c2VzIFhQYXRoIGV4cHJlc3Npb25zIGlzIG1lYW50IHRvIHdvcmsuIFRoYXQN
CiAgICA+ID4+IHN0YXRlczoNCiAgICA+ID4+DQogICAgPiA+PiBUaGUgc2V0IG9mIG5hbWVzcGFj
ZSBkZWNsYXJhdGlvbnMgaXMgdGhlIHNldCBvZiBwcmVmaXggYW5kDQogICAgPiA+PiAgICAgICAg
bmFtZXNwYWNlIHBhaXJzIGZvciBhbGwgc3VwcG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhl
IHByZWZpeA0KICAgID4gPj4gICAgICAgIGlzIHRoZSBZQU5HIG1vZHVsZSBuYW1lIGFuZCB0aGUg
bmFtZXNwYWNlIGlzIGFzIGRlZmluZWQgYnkgdGhlDQogICAgPiA+PiAgICAgICAgIm5hbWVzcGFj
ZSIgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVsZS4NCiAgICA+ID4gUGVyZmVjdCEgIEl0IHNl
ZW1zIHRoZSBhdXRob3JzIG9mIDgwNDAgdGhvdWdodCBvZiB0aGlzIDstKQ0KICAgID4gT0ssIHdo
YXQgeW91IHByb3Bvc2Ugd291bGQgYXQgbGVhc3QgYmUgY29uc2lzdGVudCB3aXRoIGhvdyB0aGUg
WFBhdGgNCiAgICA+IGlzIGZvcm1lZCBpbiBzZWMgODA0MCwgNC44LjQ/DQogICAgPiANCiAgICA+
IEkgY2FuIGxpdmUgd2l0aCB0aGF0LiAgQnV0IHN0aWxsIHN0cm9uZ2x5IHRoaW5rIHRoYXQgV0cg
c2hvdWxkIHRoaW5rDQogICAgPiBvZiB0cnlpbmcgdG8gbW92ZSBZQU5HIG9uIGZyb20gWHBhdGgg
MS4wLg0KICAgID4gDQogICAgPiA+DQogICAgPiA+PiBZZXQgdGhlIGV4YW1wbGVzIGluIHNlY3Rp
b24gOC4zLjYgZG9uJ3Qgc2VlbSB0byB1c2UgbmFtZXNwYWNlIHByZWZpeGVzDQogICAgPiA+PiBp
biB2ZXJ5IG1hbnkgcGxhY2VzLCBlLmcuIHdoeSBpcyBpdCAiL2V4YW1wbGUtbW9kOmV2ZW50MS9u
YW1lPSdqb2UnIg0KICAgID4gPj4gYW5kIG5vdCAiL2V4YW1wbGUtbW9kOmV2ZW50MS9leGFtcGxl
LW1vZDpuYW1lPSdqb2UnIj8gIElzIHRoZSBleGFtcGxlDQogICAgPiA+PiB3cm9uZywgb3Igb3Ro
ZXJ3aXNlIHdoYXQgYW0gSSBtaXNzaW5nPyA6LSkNCiAgICA+ID4gSXQgc2VlbXMgdGhlIGV4YW1w
bGUgaXMgd3JvbmchDQogICAgPiBQbGVhc2UgY2FuIHlvdSBjaGVjayBzZWN0aW9uIDgwNDAsIDgu
My42LiAgQXJlIGFsbCB0aGUgZXhhbXBsZXMgd3Jvbmc/DQogICAgDQogICAgWWVzIGl0IHNlZW1z
IHNvLiAgRXhjZXB0IHRoZSBsYXN0IG9uZS4NCjxSUj4gSSdtIHZvbHVudGVlcmluZyBSb2IgdG8g
c3VibWl0IHRoZSBlcnJhdGEgKA0KDQpSZWdhcmRzLA0KUmVzaGFkLiAgICANCiAgICANCiAgICAv
bWFydGluDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQog
ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K


From nobody Fri Oct 12 12:15:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06734130E7B for ; Fri, 12 Oct 2018 12:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.779
X-Spam-Level: 
X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 wYPVxJxVmXlM for ; Fri, 12 Oct 2018 12:14:59 -0700 (PDT)
Received: from mx1.amdocs.com (ramail1.amdocs.com [193.43.244.133]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC75130E82 for ; Fri, 12 Oct 2018 12:14:56 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail01.corp.amdocs.com with ESMTP; 12 Oct 2018 22:14:54 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE1 (10.237.240.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 12 Oct 2018 22:14:53 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 22:14:53 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Fri, 12 Oct 2018 22:14:53 +0300
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Fri, 12 Oct 2018 22:14:53 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xWv0rtBp70SPHGMRDKtGjhY8C25mMb9HGaWqwMrB5Zo=; b=d4VZvc0PEX+fKxT51TOJBamsk9bJiaA7SGYwJrvhiIfJElIKcNTpxDhzBM30/7p9GCT+zM/gefo3pRT1ShShf/OvuF1VTw5wTMZ+WqytTxCrkMyodMgpoUwJMZe4Vaockdb1xl1uK91Elc0/J/sAc8ZU0+rISphgky49R+0YRKg=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB3953.eurprd06.prod.outlook.com (52.133.57.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.23; Fri, 12 Oct 2018 19:14:51 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 19:14:51 +0000
From: Michael Rehder 
To: Robert Wilton 
CC: Andy Bierman , "Walker, Jason (Jason_Walker2@comcast.com)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoAAAMcsgAAFm1JQ
Date: Fri, 12 Oct 2018 19:14:51 +0000
Message-ID: 
References:  <87zhvlvpts.fsf@nic.cz>    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <884fca1e-7366-b7a6-c588-0e64b3d032a0@cisco.com>
In-Reply-To: <884fca1e-7366-b7a6-c588-0e64b3d032a0@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB3953; 6:XlY5b+BeG7poG62TXzpJGk65WUOtz1Z5YvJ2XtLXPyX6men+hGgFRCiZqZVOBgNy+L61HK1ydvQoN1CzqdkDYgvv3sKgyiwYbhgbUMuD6eeod5ounq6vOf4UMzSHeDiA0AKxWWIelmUjZI6iuatSK3FLiON8wLwKzPetthV9o7Hn26i+Xdq7JJ+TXUdJVQXPjcWUNkJUgRvtBmEODhh1V+QDwxmFTdFFUpRO7cRvE6iRExlvbxyTzwYFRSTOcarqD879eGZVVG8oS72VPmKmgSLRrl9L4+/EoYiBncOECGiLuIK4jox/Z78JjNZK6hSjauOlRlt/Q+s1vaIRZlaMPRy/rAYB1/spIbP+nEZp4j3BdVjbXX/dsNSo7w7a5alQ6Ai7EXXh5b9fryXDPw+QgnwMEZ3UHGxM/+INqx9mSFfEU7G6ETbg2iOhEZRBLVWs72crRs/LCDXMtgPkX+85zw==; 5:VGKysSaAG62vI5ZwKSMJilvLbvLj6gOOiziU05Uz8q7bNjv2AKEBORb5KCkKJvRd+Zxec5tbQ11YejaPPckNcBoyljf1hcCvHi0HSZhi411eCdoq/DWK77Pso8vjT9+rN/WH9fK2lYjrdDs0+4LtsEsCcOkTXUuL+gP6SPDCklg=; 7:C2Nq7Ornqj5FHsR5qXxYiTX4SFZf1watKfahqm8DxrayTsTDUBNqEVVysmf7PwS9vzQnFJArxOnx12HhH2A2aNG1GZkI82YKxpANW/kuZ4vf9imI/HXVWP5OMXRFhRnTOV/BqKXxxqo5zwi0t48M+36w0i3rIoiyuO4bjCgGh5D6DBuJg32kpMM339+IdX8hBwE1HOCyXkTE/t320bbwT3+31DhqrPr9aUKs5VNGLPgQ6ZSlVbkzR8Kml3EN3W1B
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7deae242-34e9-41a9-262f-08d63076fc4c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB3953; 
x-ms-traffictypediagnostic: AM0PR06MB3953:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014)(166566539817055)(62221491112393)(131327999870524)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991067); SRVR:AM0PR06MB3953; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB3953; 
x-forefront-prvs: 0823A5777B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(366004)(396003)(199004)(189003)(51444003)(66066001)(4326008)(53546011)(93886005)(2906002)(54896002)(55016002)(71200400001)(71190400001)(6306002)(5250100002)(72206003)(97736004)(25786009)(81166006)(8936002)(476003)(486006)(8676002)(6246003)(7696005)(2900100001)(11346002)(446003)(81156014)(54906003)(316002)(99286004)(6116002)(790700001)(6506007)(478600001)(3846002)(76176011)(68736007)(6916009)(5660300001)(33656002)(7736002)(105586002)(74316002)(256004)(53936002)(86362001)(6436002)(186003)(102836004)(9686003)(236005)(229853002)(26005)(106356001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB3953; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: GYOR8LiZ1d5TXvFgOsfCoKZ0KobFLSjECCh29MMSGV3Ky9UdPVVLAJO/ufYujXTxXViK13NxYoS88VrUBJWtyTbBez5kNmVv9QgulMLVIJ9Of3B1h2ngLmc+AZPkNM4+UzNC9K5d6v/JYlNgH7eb0CxPgvlqEqbu6H5wsIlz9Mma9wBB/Hd0Qgg2OozUy0CftLw7Q53MIS8At7DftCeCD9k8qZle3RL5k2suBfKsd9VX4a7IPHxXFzUKWmWZT/ifWDukFyux5mfNBBrorPr/f53x95SvI4726KlL9mNRNcsC8mJHUJZsojxXwF8Ck5Ai+efr9QfLUEKFzNbwGOi/hRdaHp8Pmy7ffa81HQxQj44=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB408379793AE9733A9F9FEC94E7E20AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7deae242-34e9-41a9-262f-08d63076fc4c
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 19:14:51.6276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB3953
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 19:15:02 -0000

--_000_AM0PR06MB408379793AE9733A9F9FEC94E7E20AM0PR06MB4083eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

SSBwcm92aWRlZCBhbiBleGFtcGxlLg0KUmVxdWlyaW5nIHNvbWV0aGluZyB0byBiZSBwcmVzZW50
IHdoZW4gYSBjb25kaXRpb24gaXMgdG8gbWUgYSB1c2VmdWwgY2FwYWJpbGl0eS4NCkhvdyBlbHNl
IHdvdWxkIHlvdSBlbmZvcmNlIGluIGFuIG9wdGltYWwgd2F5IHRoYXQgc29tZXRoaW5nIGlzIHBy
ZXNlbnQgdW5kZXIgb25seSBjZXJ0YWluIGNvbmRpdGlvbnMgKGRlZmluZSBpdCBvbiB0aGUgY29u
dHJvbGxlZCBzZWN0aW9uLCBub3QgdXNlIGEgemlsbGlvbiBpZi1mZWF0dXJlKT8NCg0KVGhhbmtz
DQpNaWtlDQoNCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0N
ClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMiwgMjAxOCAxMjozMCBQTQ0KVG86IE1pY2hhZWwgUmVo
ZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPg0KQ2M6IEFuZHkgQmllcm1hbiA8YW5keUB5
dW1hd29ya3MuY29tPjsgV2Fsa2VyLCBKYXNvbiAoSmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbSkg
PEphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24n
dCBlbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3QNCg0KDQpPbiAxMi8xMC8y
MDE4IDE3OjA4LCBNaWNoYWVsIFJlaGRlciB3cm90ZToNClRoZSBtYW5kYXRvcnkgc3RhdGVtZW50
IGluIHRoYXQgY2FzZSBpcyBpZ25vcmVkIChJ4oCZdmUgcG9pbnRlZCBvdXQgdGhlIFJORyBhbmQg
U2NoZW1hdHJvbiBsYWNrIG9mIGVuZm9yY2VtZW50KS4NCk9LLCBJJ20gbm90IGZhbWlsaWFyIHdp
dGggUk5HIGFuZCBTY2hlbWF0cm9uLg0KDQoNCldIRU4gdHJ1bXBzIHRoZSBtYW5kYXRvcnkgc3Rh
dHVzICh2aWEgZXhwbGljaXQgbWFuZGF0b3J5IG9yIGltcGxpY2l0IG1hbmRhdG9yeSB2aWEgbWlu
LWVsZW1lbnRzIDEpDQpTbyBJIHRoaW5rIHRoYXQgeW91IGFyZSBhc2tpbmcgZm9yIG1hbmRhdG9y
eSB0byB0cnVtcCBhIHdoZW4gY29uZGl0aW9uLiAgQ2FuIHlvdSBwcm92aWRlIGEgY29uY3JldGUg
ZXhhbXBsZSB3aGVyZSB0aGlzIGlzIHJlcXVpcmVkLCBvciBldmVuIHVzZWZ1bD8NCg0KQSBzb2x1
dGlvbiBoZXJlLCB0aGF0IGRvZXNuJ3QgcmVxdWlyZSBhbnkgY2hhbmdlcyBpbiB0aGUgWUFORyBs
YW5ndWFnZSwgd291bGQgYmUgdG8ganVzdCBtb3ZlIHRoZSB3aGVuIGNvbmRpdGlvbiwgZG93biB0
byBlYWNoIG9mIHRoZSBjaGlsZCBub2RlcyB0aGF0IGFyZSBub3QgbWFya2VkIGFzIG1hbmRhdG9y
eS4NCg0KQnV0LCBzb3JyeSwgYXQgdGhlIG1vbWVudCBJJ20gc3RpbGwgYXQgYSBsb3NzIHRvIHNl
ZSBob3cgd2hlcmUgdGhpcyB3b3VsZCBhY3R1YWxseSBiZSB1c2VmdWwuDQoNClRoYW5rcywNClJv
Yg0KDQoNCg0KVGhhbmtzDQpNaWtlDQoNCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2ls
dG9uQGNpc2NvLmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxMiwgMjAxOCAxMjowNiBQTQ0K
VG86IE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPjxtYWlsdG86TWlj
aGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4NCkNjOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtz
LmNvbT48bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT47IFdhbGtlciwgSmFzb24gKEphc29uX1dh
bGtlcjJAY29tY2FzdC5jb208bWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+KSA8SmFz
b25fV2Fsa2VyMkBjb21jYXN0LmNvbT48bWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20+
OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
bmV0bW9kXSBXSEVOIHN0YXRlbWVudCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndCBl
bnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBvYmplY3QNCg0KDQpIaSBNaWtlLA0KDQpP
biAxMS8xMC8yMDE4IDE5OjA1LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQoNCg0KT24gVGh1LCBPY3Qg
MTEsIDIwMTggYXQgMTE6MDAgQU0sIE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBhbWRv
Y3MuY29tPG1haWx0bzpNaWNoYWVsLlJlaGRlckBhbWRvY3MuY29tPj4gd3JvdGU6DQpJIHRoaW5r
IHRoZSB3b3JkaW5nIGlzIHJlbGV2YW50IC0gc29tZXRoaW5nIGNhbiBiZSBjb25kaXRpb25hbCBi
dXQgc3RpbGwgcmVxdWlyZWQuDQpZZXMsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbHJlYWR5
IGV4cHJlc3NlZCBieSBhIG5vZGUgdGhhdCBoYXMgYm90aCBhIHdoZW4gY29uZGl0aW9uIGFuZCBt
YW5kYXRvcnkgc3RhdGVtZW50Lg0KDQoNCg0KDQpjb250YWluZXIgYSB7DQoNCiAgY29udGFpbmVy
IHggew0KDQogICAgd2hlbiAic29tZSBjb25kaXRpb24iOw0KDQogICAgbGVhZiBmb28gew0KDQog
ICAgICBtYW5kYXRvcnkgdHJ1ZTsNCg0KICAgIH0NCg0KICAgIGxlYWYgYmFyIHsNCg0KICAgICAg
Li4uDQoNCiAgICB9DQoNCiAgfQ0KDQogIGNvbnRhaW5lciB5IHsNCg0KICAgIGxlYWYgYmF6IHsN
Cg0KICAgICAgbWFuZGF0b3J5IHRydWU7DQoNCiAgICB9DQoNCiAgICBsZWFmIHRlZSB7DQoNCiAg
ICAgIC4uLg0KDQogICAgfQ0KDQogIH0NCg0KfQ0KDQoNCg0KYS94L2ZvbyBpcyBjb25kaXRpb25h
bCAoZHVlIHRvIHdoZW4pIGJ1dCByZXF1aXJlZCAoaWYgdGhlIHdoZW4gY29uZGl0aW9uIGlzIG1l
dCkuDQoNCmEveC9iYXIgaXMgY29uZGl0aW9uYWwgKGR1ZSB0byB3aGVuKSBidXQgb3B0aW9uYWwg
KGlmIHRoZSB3aGVuIGNvbmRpdGlvbiBpcyBtZXQpLg0KDQphL3kvYmF6IGlzIHVuY29uZGl0aW9u
YWwgYnV0IHJlcXVpcmVkLg0KDQphL3kvdGVlIGlzIHVuY29uZGl0aW9uYWwgYnV0IG9wdGlvbmFs
Lg0KDQoNCg0KDQpJdCBzaG91bGQgYmUgY2xhcmlmaWVkIHRoYXQgZWxlbWVudHMgYmVjb21lIGlt
cGxpY2l0bHkg4oCcbWFuZGF0b3J5IGZhbHNl4oCdIHdoZW4gYSDigJx3aGVu4oCdIHN0YXRlbWVu
dCBpcyB1c2VkLg0KQnV0IHRoZXkgZG9uJ3QuDQoNCg0KDQoNCkkgd291bGQgbGlrZSB0byBzZWUg
YW4gZW5oYW5jZW1lbnQgdG8gWUFORyB0byBjb250cm9sIHRoaXMgYmVoYXZpb3IsIHRvIGFsbG93
IHRoZSBtYW5kYXRvcnkgc3RhdHVzIHRvIGJlIGVuZm9yY2VkLg0KVGhhdCBpcywgc3VwcG9ydCBh
bHNvIOKAnGNvbmRpdGlvbmFsbHkgcmVxdWlyZWTigJ0gaW5zdGVhZCBvZiBvbmx5IHRoZSBjdXJy
ZW50IOKAnGNvbmRpdGlvbmFsbHkgb3B0aW9uYWzigJ0uDQpJJ20gdHJ5aW5nIHRvIHVuZGVyc3Rh
bmQgd2hhdCB0aGlzIHdvdWxkIGV2ZW4gbWVhbi4NCg0KVGFraW5nIHlvdXIgb3JpZ2luYWwgZXhh
bXBsZSwgYnV0IHdpdGggImVuZm9yY2UtbWFuZGF0b3J5LXN0YXR1cyI6DQoNCiAgICAgICAgIGxl
YWYgQXNzaWdubWVudE1lY2hhbmlzbSB7DQoNCiAgICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24g
ew0KDQogICAgICAgICAgICAgIGVudW0gIkRIQ1AiOw0KDQogICAgICAgICAgICAgIGVudW0gIlN0
YXRpYyI7DQoNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQoN
CiAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUaGUgYWRkcmVzcyBhc3NpZ25tZW50IG1lY2hhbmlz
bS4iOw0KDQogICAgICAgICAgfQ0KDQogICAgICAgICAgbGlzdCBJUEFkZHJlc3NlcyB7DQoNCiAg
ICAgICAgICAgIHdoZW4gIi4uL0Fzc2lnbm1lbnRNZWNoYW5pc20gPSAnU3RhdGljJyIgew0KDQog
ICAgICAgICAgICAgIGVuZm9yY2UtbWFuZGF0b3J5LXN0YXR1czsNCg0KICAgICAgICAgICAgfSAg
a2V5IEFkZHJlc3M7DQoNCiAgICAgICAgICAgIG1pbi1lbGVtZW50cyAxOw0KDQoNCg0KICAgICAg
ICAgICAgbGVhZiBBZGRyZXNzIHsNCg0KICAgICAgICAgICAgICB0eXBlIGNhcGl0OklQdjRBZGRy
ZXNzOw0KDQogICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJBbiBpcHY0IGFkZHJlc3MuIjsNCg0K
ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgIH0NCg0KU28gdGhpcyBtZWFucyB0aGF0IGxpc3Qg
SVBhZGRyZXNzZXMgbXVzdCBoYXZlIGF0IGxlYXN0IG9uZSBlbGVtZW50IHJlZ2FyZGxlc3Mgb2Yg
d2hldGhlciB0aGUgd2hlbiBjb25kaXRpb24gaG9sZHMuICBJLmUuIG5vIG1hdHRlciB3aGV0aGVy
IHRoZSBhc3NpZ25tZW50IGlzIERIQ1Agb3IgU3RhdGljIHRoZXJlIG11c3QgYWx3YXlzIGJlIGF0
IGxlYXN0IG9uZSAxIGFkZHJlc3MgY29uZmlndXJlZC4gIEJ1dCBJIGRvbid0IHVuZGVyc3RhbmQg
d2hhdCB0aGlzIGFjdHVhbGx5IG1lYW5zIC0gaXQgc2VlbXMgbGlrZSBhIGNvbnRyYWRpY3Rpb24u
ICBXaGF0IGFtIEkgbWlzc2luZz8gIFBsZWFzZSBjYW4geW91IGdpdmUgYSBjb25jcmV0ZSBleGFt
cGxlIChpbiBZQU5HKSBvZiB3aGF0IGJlaGF2aW91ciB5b3UgYXJlIGxvb2tpbmcgZm9yLg0KDQpU
aGFua3MsDQpSb2INCg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEg
dGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1haWxzIHNl
bnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3VjaCBzeXN0
ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5
c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2Nz
IGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3Vj
aCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQoNCuKAnEFtZG9jc+KAmSBlbWFp
bCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJh
c2VkIHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBh
bmQgc3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBw
YXJ0eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNl
bmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1
c2Ugb2Ygc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz
4oCdLgo=

--_000_AM0PR06MB408379793AE9733A9F9FEC94E7E20AM0PR06MB4083eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHByb3ZpZGVkIGFuIGV4YW1wbGUuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPlJlcXVpcmluZyBzb21ldGhpbmcgdG8gYmUgcHJlc2VudCB3aGVuIGEgY29u
ZGl0aW9uIGlzIHRvIG1lIGEgdXNlZnVsIGNhcGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhv
dyBlbHNlIHdvdWxkIHlvdSBlbmZvcmNlIGluIGFuIG9wdGltYWwgd2F5IHRoYXQgc29tZXRoaW5n
IGlzIHByZXNlbnQgdW5kZXIgb25seSBjZXJ0YWluIGNvbmRpdGlvbnMgKGRlZmluZSBpdCBvbiB0
aGUgY29udHJvbGxlZCBzZWN0aW9uLCBub3QgdXNlIGEgemlsbGlvbiBpZi1mZWF0dXJlKT88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5NaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7
cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv
d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+
IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBGcmlkYXksIE9jdG9iZXIgMTIsIDIwMTggMTI6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1p
Y2hhZWwgUmVoZGVyICZsdDtNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tJmd0Ozxicj4NCjxiPkNj
OjwvYj4gQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7OyBXYWxrZXIsIEph
c29uIChKYXNvbl9XYWxrZXIyQGNvbWNhc3QuY29tKSAmbHQ7SmFzb25fV2Fsa2VyMkBjb21jYXN0
LmNvbSZndDs7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1v
ZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QgZW5zdXJl
IHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gMTIvMTAvMjAxOCAxNzowOCwgTWljaGFlbCBSZWhkZXIgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBtYW5kYXRvcnkgc3RhdGVtZW50IGluIHRoYXQg
Y2FzZSBpcyBpZ25vcmVkIChJ4oCZdmUgcG9pbnRlZCBvdXQgdGhlIFJORyBhbmQgU2NoZW1hdHJv
biBsYWNrIG9mIGVuZm9yY2VtZW50KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgSSdtIG5vdCBmYW1pbGlhciB3aXRoIFJORyBh
bmQgU2NoZW1hdHJvbi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldIRU4gdHJ1bXBz
IHRoZSBtYW5kYXRvcnkgc3RhdHVzICh2aWEgZXhwbGljaXQgbWFuZGF0b3J5IG9yIGltcGxpY2l0
IG1hbmRhdG9yeSB2aWEgbWluLWVsZW1lbnRzIDEpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSB0aGluayB0aGF0IHlvdSBhcmUg
YXNraW5nIGZvciBtYW5kYXRvcnkgdG8gdHJ1bXAgYSB3aGVuIGNvbmRpdGlvbi4mbmJzcDsgQ2Fu
IHlvdSBwcm92aWRlIGEgY29uY3JldGUgZXhhbXBsZSB3aGVyZSB0aGlzIGlzIHJlcXVpcmVkLCBv
ciBldmVuIHVzZWZ1bD88YnI+DQo8YnI+DQpBIHNvbHV0aW9uIGhlcmUsIHRoYXQgZG9lc24ndCBy
ZXF1aXJlIGFueSBjaGFuZ2VzIGluIHRoZSBZQU5HIGxhbmd1YWdlLCB3b3VsZCBiZSB0byBqdXN0
IG1vdmUgdGhlIHdoZW4gY29uZGl0aW9uLCBkb3duIHRvIGVhY2ggb2YgdGhlIGNoaWxkIG5vZGVz
IHRoYXQgYXJlIG5vdCBtYXJrZWQgYXMgbWFuZGF0b3J5Ljxicj4NCjxicj4NCkJ1dCwgc29ycnks
IGF0IHRoZSBtb21lbnQgSSdtIHN0aWxsIGF0IGEgbG9zcyB0byBzZWUgaG93IHdoZXJlIHRoaXMg
d291bGQgYWN0dWFsbHkgYmUgdXNlZnVsLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSb2I8YnI+
DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFu
a3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+TWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ3aWx0
b25AY2lzY28uY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbTwv
c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPl0NCjxicj4NCjxiPlNl
bnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMTIsIDIwMTggMTI6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+
IE1pY2hhZWwgUmVoZGVyIDwvc3Bhbj48YSBocmVmPSJtYWlsdG86TWljaGFlbC5SZWhkZXJAQW1k
b2NzLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbSZn
dDs8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48YnI+DQo8Yj5D
Yzo8L2I+IEFuZHkgQmllcm1hbiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtz
LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjsgV2Fsa2VyLCBKYXNvbg0KICg8
L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkphc29uX1dhbGtlcjJAY29tY2FzdC5jb20iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+SmFzb25fV2Fsa2VyMkBjb21jYXN0LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOndpbmRvd3RleHQiPikNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SmFzb25fV2Fs
a2VyMkBjb21jYXN0LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7SmFzb25fV2Fsa2VyMkBjb21j
YXN0LmNvbSZndDs8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij47
DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0
ZXh0Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdp
dGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0IGVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFu
ZGF0b3J5IG9iamVjdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkhpIE1pa2UsPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8xMC8yMDE4IDE5OjA1LCBBbmR5IEJpZXJt
YW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo
dSwgT2N0IDExLCAyMDE4IGF0IDExOjAwIEFNLCBNaWNoYWVsIFJlaGRlciAmbHQ7PGEgaHJlZj0i
bWFpbHRvOk1pY2hhZWwuUmVoZGVyQGFtZG9jcy5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVs
LlJlaGRlckBhbWRvY3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0
aGluayB0aGUgd29yZGluZyBpcyByZWxldmFudCAtIHNvbWV0aGluZyBjYW4gYmUgY29uZGl0aW9u
YWwgYnV0IHN0aWxsIHJlcXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBhbHJl
YWR5IGV4cHJlc3NlZCBieSBhIG5vZGUgdGhhdCBoYXMgYm90aCBhIHdoZW4gY29uZGl0aW9uIGFu
ZCBtYW5kYXRvcnkgc3RhdGVtZW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPHByZT5jb250YWluZXIgYSB7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IGNv
bnRhaW5lciB4IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgd2hl
biAmcXVvdDtzb21lIGNvbmRpdGlvbiZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDsgbGVhZiBmb28gezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5kYXRvcnkgdHJ1ZTs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyZuYnNwOyBsZWFmIGJhciB7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyB9PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsgY29udGFpbmVyIHkgezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyZuYnNwOyBsZWFmIGJheiB7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hbmRhdG9yeSB0cnVlOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGxlYWYgdGVlIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPn08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5hL3gvZm9vIGlzIGNvbmRpdGlvbmFsIChkdWUgdG8gd2hlbikgYnV0IHJlcXVpcmVkIChp
ZiB0aGUgd2hlbiBjb25kaXRpb24gaXMgbWV0KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hL3gv
YmFyIGlzIGNvbmRpdGlvbmFsIChkdWUgdG8gd2hlbikgYnV0IG9wdGlvbmFsIChpZiB0aGUgd2hl
biBjb25kaXRpb24gaXMgbWV0KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hL3kvYmF6IGlzIHVu
Y29uZGl0aW9uYWwgYnV0IHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEveS90ZWUg
aXMgdW5jb25kaXRpb25hbCBidXQgb3B0aW9uYWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IHNob3VsZCBiZSBjbGFyaWZpZWQgdGhhdCBlbGVtZW50
cyBiZWNvbWUgaW1wbGljaXRseSDigJxtYW5kYXRvcnkgZmFsc2XigJ0gd2hlbiBhIOKAnHdoZW7i
gJ0gc3RhdGVtZW50IGlzDQogdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHRoZXkgZG9uJ3QuPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGxpa2UgdG8gc2VlIGFuIGVuaGFuY2VtZW50IHRv
IFlBTkcgdG8gY29udHJvbCB0aGlzIGJlaGF2aW9yLCB0byBhbGxvdyB0aGUgbWFuZGF0b3J5IHN0
YXR1cw0KIHRvIGJlIGVuZm9yY2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF0IGlzLCBzdXBwb3J0IGFsc28g4oCcY29u
ZGl0aW9uYWxseSByZXF1aXJlZOKAnSBpbnN0ZWFkIG9mIG9ubHkgdGhlIGN1cnJlbnQg4oCcY29u
ZGl0aW9uYWxseSBvcHRpb25hbOKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgdGhp
cyB3b3VsZCBldmVuIG1lYW4uPGJyPg0KPGJyPg0KVGFraW5nIHlvdXIgb3JpZ2luYWwgZXhhbXBs
ZSwgYnV0IHdpdGggJnF1b3Q7ZW5mb3JjZS1tYW5kYXRvcnktc3RhdHVzJnF1b3Q7OiA8bzpwPjwv
bzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7bGVhZiBBc3NpZ25tZW50TWVjaGFuaXNtIHs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgdHlwZSBlbnVtZXJhdGlvbiB7PG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gJnF1b3Q7REhDUCZxdW90Ozs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSAmcXVvdDtTdGF0aWMmcXVvdDs7
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgbWFuZGF0b3J5IHRydWU7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGRlc2NyaXB0aW9uICZxdW90O1RoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWVjaGFuaXNtLiZx
dW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IElQ
QWRkcmVzc2VzIHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hlbiAmcXVvdDsu
Li9Bc3NpZ25tZW50TWVjaGFuaXNtID0gJ1N0YXRpYycmcXVvdDsgezxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmZvcmNlLW1hbmRhdG9yeS1zdGF0dXM7PG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsga2V5IEFkZHJlc3M7PG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pbi1lbGVtZW50cyAxOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDtsZWFmIEFkZHJlc3MgezxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB0eXBlIGNhcGl0OklQdjRBZGRyZXNzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtBbiBpcHY0IGFkZHJlc3MuJnF1b3Q7
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IH08bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpTbyB0aGlzIG1lYW5zIHRoYXQgbGlzdCBJUGFkZHJl
c3NlcyBtdXN0IGhhdmUgYXQgbGVhc3Qgb25lIGVsZW1lbnQgcmVnYXJkbGVzcyBvZiB3aGV0aGVy
IHRoZSB3aGVuIGNvbmRpdGlvbiBob2xkcy4mbmJzcDsgSS5lLiBubyBtYXR0ZXIgd2hldGhlciB0
aGUgYXNzaWdubWVudCBpcyBESENQIG9yIFN0YXRpYyB0aGVyZSBtdXN0IGFsd2F5cyBiZSBhdCBs
ZWFzdCBvbmUgMSBhZGRyZXNzIGNvbmZpZ3VyZWQuJm5ic3A7IEJ1dCBJIGRvbid0IHVuZGVyc3Rh
bmQgd2hhdA0KIHRoaXMgYWN0dWFsbHkgbWVhbnMgLSBpdCBzZWVtcyBsaWtlIGEgY29udHJhZGlj
dGlvbi4mbmJzcDsgV2hhdCBhbSBJIG1pc3Npbmc/Jm5ic3A7IFBsZWFzZSBjYW4geW91IGdpdmUg
YSBjb25jcmV0ZSBleGFtcGxlIChpbiBZQU5HKSBvZiB3aGF0IGJlaGF2aW91ciB5b3UgYXJlIGxv
b2tpbmcgZm9yLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt
YXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+
DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj7igJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFzZWQg
b24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBlbWFp
bHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBzdWNo
IHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzDQogb2Yg
c3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRv
IEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0ZW0g
YW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLjwvc3Bhbj48L2VtPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwcHQgMC41aW47Ij48ZW0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxmb250IGZhY2U9
IkNhbGlicmkiIHNpemU9IjMiPuKAnEFtZG9jc+KAmSBlbWFpbA0KcGxhdGZvcm0gaXMgYmFzZWQg
b24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueQ0KZW1h
aWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3Vj
aCBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlDQpieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Yg
c3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YNCmVtYWlscyB0
byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVt
IGFuZCBzdWNoDQpwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uPC9mb250Pjwvc3Bh
bj48L2VtPjwvcD4NCg0KPGZvbnQgc2l6ZT0iMyI+PC9mb250PjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_AM0PR06MB408379793AE9733A9F9FEC94E7E20AM0PR06MB4083eurp_--



From nobody Fri Oct 12 13:48:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773312D4EB; Fri, 12 Oct 2018 13:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 F_cTdIQMSMOT; Fri, 12 Oct 2018 13:48:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4C682128B14; Fri, 12 Oct 2018 13:48:03 -0700 (PDT)
Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9CKlkkc061909 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Oct 2018 15:47:48 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27]
From: Ben Campbell 
Message-Id: <434741F1-C981-4619-84A8-8DA348B59F05@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_AFA03675-C355-4D70-A29C-783C874FF7B9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Fri, 12 Oct 2018 15:47:46 -0500
In-Reply-To: <20181011.102336.1101712961765874974.mbj@tail-f.com>
Cc: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, joelja@gmail.com, iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, lberger@labn.net
To: Martin Bjorklund 
References: <153920340311.5891.2170334410096287507.idtracker@ietfa.amsl.com> <20181011.102336.1101712961765874974.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2018 20:48:05 -0000

--Apple-Mail=_AFA03675-C355-4D70-A29C-783C874FF7B9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_76079C4A-447E-4253-8645-DA7B4D344F51"


--Apple-Mail=_76079C4A-447E-4253-8645-DA7B4D344F51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Oct 11, 2018, at 3:23 AM, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> Ben Campbell > wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-netmod-schema-mount-11: No Objection
>>=20
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut =
this
>> introductory paragraph, however.)
>>=20
>>=20
>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>>=20
>>=20
>>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> Substantive:
>>=20
>> =C2=A73.3, 4th paragraph: The MUST NOT seems like a statement of fact =
-- if no
>> schema is mounted, it doesn't seem possible for it to include =
anything.
>=20
> Right, so this MUST NOT is directed to an implementor.  If you think
> it is stating the obvious, I'd be happy to modify this to maybe "does
> not=E2=80=9D.

I guess it comes down to whether it is reasonably possible for an =
implementor to get it wrong :-)

>=20
>=20

>> =C2=A75, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would =
it ever make
>> sense to violate this?
>=20
> Probably not, but it could depend on how the mount point is supposed
> to be used.  Maybe it is used in such a way that mounted rpcs are not
> applicable.
>=20

Okay. Some guidance to that effect in the document would be helpful.

>> =C2=A79: The model includes RFC 2119 boilerplate, but the document =
itself uses the
>> newer RFC 8174 boilerplate. Is it normal to include the normative =
keyword
>> boilerplate in the model?
>=20
> No, but in some cases models use 2119 language w/o the boilerplate and
> since models have a life on their own outside the RFC, we thought that
> it would be a good idea to clarify the intention by including the
> boilerplate.

Okay.

>=20
>> If so, it should probably match that of the
>> containing document.
>=20
> Yes, fixed.

Thanks!

>=20
>> Editorial:
>>=20
>> =C2=A71, list item 2: "... and is stable as YANG library information =
of the server."
>> Assuming you mean specific YANG library information rather than the =
general
>> concept, there is a missing article before "YANG". (This pattern =
repeats a few
>> time throughout the document.)
>=20
> Yes, fixed.
>=20
>=20
> /martin


--Apple-Mail=_76079C4A-447E-4253-8645-DA7B4D344F51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Oct 11, 2018, at 3:23 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

Hi,

Ben Campbell <ben@nostrum.com> wrote:
Ben =
Campbell has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: No Objection

When responding, please keep the subject line =
intact and reply to all
email addresses included in the To =
and CC lines. (Feel free to cut this
introductory =
paragraph, however.)


Please =
refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT =
positions.


The document, =
along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount=
/



---------------------------------------------------------------=
-------
COMMENT:
---------------------------------------------------------------=
-------

Substantive:

=C2=A73.3, 4th paragraph: The MUST NOT seems like a statement =
of fact -- if no
schema is mounted, it doesn't seem =
possible for it to include anything.

Right, so this MUST NOT is =
directed to an implementor.  If you think
it is stating the obvious, I'd =
be happy to modify this to maybe "does
not=E2=80=9D.

I guess it comes down to whether it is reasonably =
possible for an implementor to get it wrong :-)

 


=C2=A75=
, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever =
make
sense to violate this?

Probably not, but it could =
depend on how the mount point is supposed
to be used.  Maybe it is used in such a way that mounted =
rpcs are not
applicable.


Okay. Some guidance to that effect in the document =
would be helpful.

=C2=A79=
: The model includes RFC 2119 boilerplate, but the document itself uses =
the
newer RFC 8174 boilerplate. Is it normal to include =
the normative keyword
boilerplate in the model?

No, but in some cases models use 2119 language w/o the =
boilerplate and
since models have a life on their own outside the RFC, we =
thought that
it would be a =
good idea to clarify the intention by including the
boilerplate.

Okay.


If so, it should probably match that =
of the
containing document.

Yes, fixed.

Thanks!


Editorial:

=C2=A71, list item 2: "... and is stable as YANG library =
information of the server."
Assuming you mean specific =
YANG library information rather than the general
concept, =
there is a missing article before "YANG". (This pattern repeats a few
time throughout the document.)

Yes, fixed.


/martin

=

--Apple-Mail=_76079C4A-447E-4253-8645-DA7B4D344F51--

--Apple-Mail=_AFA03675-C355-4D70-A29C-783C874FF7B9
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 - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlvBCHIACgkQgFZKbJXz
1A172hAAq6IPUNpxVtzC+2zpqOKTzDEH/DlGUEM7wX+ZK4P4AUga7WNmgGw/NxIn
ECs9mKRgABHB2/UQI07LhPGw4kKBdN2RyVu8scd0qVHr1gFolrcXWJAlpJdOWE1+
xU1ogPTQbxQjxuRkKdGvQZw6BdF0une3iQWRFtXjXpAYBIioYtJO1zdo3a/BFu+I
JXFbFb7K3KAswAdScQ8kIqa/OQgWOBDulrJzvOVMkuPQfdFELQfv1N545uCjzFYV
/7C1wY8K2baRwqQT61LfvDSTRvaGhY4iozILOI8a0xEvuGPtyZkh7va86mtTKRpf
3tREblzlANxeEQHag6sXlqW2O1U9GXLSyb0NIeHfQdIr9JY4f/eky+PUe3n1/Hi1
YIHJH5wMPQkHJb/iTiNxNmwaAAuIr5r8ASYNWNO20l1QAfuc32gifqh9QQONTdbg
w4WDX/OjxCxMzuVm4Cm8afOR4TM/VqLahH+oSCck/05owP/p2M1fALlqRcXwbwLl
Zh164lFcMUzXz9kiasLQn9tYct8T3JLm2uVKsS2oQ1kAV+Zz8Yk32nMkznOWrGCO
Sw5vGBgsklbAtjVt6jwlkIXyijH8rt/tUIM+jWGxepYzIpHXUx6mHtrKa0tLp5aP
OhlUhpEXH80C3z2j0Net6zkFTIj76a+5RmYTyG3HNK/s/D/6CCM=
=LzXn
-----END PGP SIGNATURE-----

--Apple-Mail=_AFA03675-C355-4D70-A29C-783C874FF7B9--


From nobody Sat Oct 13 08:13:32 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CAE130EE5 for ; Sat, 13 Oct 2018 08:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level: 
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=g5Cj1xVi; dkim=pass (1024-bit key) header.d=ericsson.com header.b=DFFRDUZg
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 TpipKGpL47bN for ; Sat, 13 Oct 2018 08:13:28 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5B033130EDC for ; Sat, 13 Oct 2018 08:13:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539443606; x=1542035606; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nKNUrhcALSdNV6OvrRxDdHG+/oH8j5fqNPLwWfDPs5E=; b=g5Cj1xVizYznvzXlQHcxiPRTuJn6avXpLz9VsNtI6w12DlDsJO/H+vhLRDG53S/f hgFe6crgorlmPpsHuOIfXS8Jfd4JcRH7FhjhleFLICjRB2/vBNBomXlGMTupKTGw wWwuzyE/3jeKepj2rgneOU2aH//gp+PYdXWe27SWmpw=;
X-AuditID: c1b4fb30-2bbff700000047d2-8f-5bc20b967d50
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.7F.18386.69B02CB5; Sat, 13 Oct 2018 17:13:26 +0200 (CEST)
Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 17:13:26 +0200
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 13 Oct 2018 17:13:26 +0200
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 13 Oct 2018 17:13:25 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yUIVLfTNlhGTdKADPxWjp/oRF+Ut8VgnK9fS5BSqi24=; b=DFFRDUZgx6+CoOLAdRDe2KvrvzlL9JqL3FppbCy+ZCSKHIQrXpEg8rb1tPqtnDP/wE5lk8zY8JTlceWx3Gs76ngJTJR6MZPY2SIZZCLf/pXDMPJZ2aE8zJhAEKIp4xMtGU2s/KdElyrsv7cBHBgZkdbRu/LzN0xbgMDWltlXz1I=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2703.eurprd07.prod.outlook.com (10.173.80.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.20; Sat, 13 Oct 2018 15:13:24 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%10]) with mapi id 15.20.1228.020; Sat, 13 Oct 2018 15:13:24 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Martin Bjorklund 
CC: "lberger@labn.net" , "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Server Capabilities [was: Re: [netmod] WG adoption poll - instance-data]
Thread-Index: AQHUYwdJUC3pMgxg0UOtjQ0/UpH0gw==
Date: Sat, 13 Oct 2018 15:13:24 +0000
Message-ID: <3500e5b2-b9f2-b7d8-6ac7-dcb0f8b8f4ee@ericsson.com>
References:  <20181009.125822.1764836266889190398.mbj@tail-f.com> <58f8baa5-320c-a75e-62ef-e277d488b962@ericsson.com> <20181009.142506.637283350958767455.mbj@tail-f.com>
In-Reply-To: <20181009.142506.637283350958767455.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: HE1PR0501CA0023.eurprd05.prod.outlook.com (2603:10a6:3:1a::33) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2703; 6:ydcyQ7kXnQczI9r+h4ZyOFkwU2MukdHo2UNVPXUUM2YvwlxwFkRdEMJgQ1Eb8cArTqVCmZE3aoHU+EZTBB13INAygt8g5x3y2LrWP/o6l/EGp4ay6UNgSl/hrRQSGgiYu0fsxS+4teRFdYY5NMNek9aykEfhD5AU3hcvXWmQdCEnT2DKJv5zfRcFdY6x2pYM2qt5E45wP5YaFPh+O+y0rEc2ckZ8mi/eSsf+peRuAmg3mJVerr5hFIFPEL68QEgSbNT73gNkzdnqKn6l4Poykofiy6C8vbuw66AfkpSJMLcwUxSUYRKF8ZUBRDjlL6vtGSh6pbyhKdBdEShwJgHBiqyUhpjIEW8a0Ws9xPUNA33NyYu6Xmmsy0plEGBU7p7Qh3J8YU018JHh9sbUo+ZHa/a1gdX60f6J0IEYo0PdLBkDv7yD5QzEo2ukuaWlzdGWMP0O+zCj0Q7DJ/R4aDJmXw==; 5:9GE/fC68ZWQ6zlSvsGDXm9H/H9tx4uk+hA9Zz02LbDlhAJUEBYo5QFrEJ47Mahh9FPsgwOnmztTO7PGr6lCxTnk+XXjjVPPFSxHbNAO4AuNvl8oNS1IysKZFafUNHD518rAUNqajzurw5NbA3l/MX5S7vH7oqSZEHv9iAk2J0mI=; 7:i6Hj3ZSmWsG+XC/IlioMvgdScjzvXqctqQyu8tD9fYr0/u/UAfv+OqAM5PUIerZSB8iKPHYudekc6/j6vaz7wq3ZBalgUR9hYrPwhMv90TndZ2OPf5020DMvVGXwxyrDmf+V4CpdthT2GaCT4KpHmVBjGbknZXpPkcpV95wXmqVETXzln340iAxkHfmS9o/KX3tG9B0HHRIASKm4dGNbHqMKU4CMKm5xaVQEOqztgswNgf2/rhRU6ZWcRx+MDLvG
x-ms-office365-filtering-correlation-id: 68efbecc-5e5b-45f5-18a6-08d6311e6a52
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2703; 
x-ms-traffictypediagnostic: VI1PR0701MB2703:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(37575265505322)(248295561703944); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991067); SRVR:VI1PR0701MB2703; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2703; 
x-forefront-prvs: 082465FB26
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(39860400002)(396003)(366004)(189003)(199004)(252514010)(53936002)(6486002)(14444005)(256004)(6512007)(6306002)(6506007)(25786009)(3260700006)(386003)(52116002)(76176011)(6436002)(58126008)(54906003)(2900100001)(65956001)(305945005)(66066001)(99286004)(65806001)(97736004)(64126003)(36756003)(7736002)(85182001)(478600001)(14454004)(966005)(93886005)(99936001)(65826007)(71200400001)(85202003)(106356001)(71190400001)(6916009)(316002)(86362001)(3846002)(105586002)(476003)(66574009)(446003)(6116002)(2616005)(11346002)(31696002)(486006)(8676002)(8936002)(81166006)(81156014)(5660300001)(5250100002)(4326008)(186003)(31686004)(6346003)(102836004)(2906002)(68736007)(561944003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2703; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-message-info: 29UowTe8FU61ro3c3IaR12FRXBGTmQSchcFNS6cWIzjlKIQeO39LOvUtJUcXUNOM6hNR7HFKJdwxqJ4gIq4UcOvlr71RMPFc/hMKbKgwzhZcVyrYKHgZuFEsjeGCf1bB74seumTPP3lM52Rv8PAILKCMeKvh4y/B+lKpWWafoHTOcmGpFIPVmgA69FkyP5eY3Hshg5Xx/s8S/ArRiBI5cPDIF3PBtOb+eUqE6LdqAT3W5lxYsOOS11GXnw2aTaqEoDmr/B4dr4nsexDfmizG36KntW/K4sinecsc1/ukuG8wKnkzrr5cEGEJfKQTLMUd7+apUs6i1mlU/NZ5f2nXvx7pKtYgkNrofluBDZiAZno=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040900050802010703020000"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 68efbecc-5e5b-45f5-18a6-08d6311e6a52
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2018 15:13:24.6424 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2703
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0iTURjGOdu3bxdbnebUF6Wgkf6ReUmdjVLTCBIyMyoQRXS6LxV1k21K +kfMJmlKwy7mBUpFUUrzMo1UyMtAS6WcNywt8ZamZmhU1ixr26dR//1enuc5z3sOh8MULLMc OYlyNaWUS5NFJI8oCX+qdrtnY4j0nFx3luRqVwlJfv4CW1J700VSNpTFCiSCq6p+MILX9Foy uMlUSYQxI3h+Mio5MZ1SegTE8BIG9b1kat/FKwul7SwN6j+ThzgcwD5QvsHNQzyOAPcgqGtq YNDDNwTG9g3y71C4NmAeuOahigH1c0KLQOACJrzoHWTRQhEDxjoUdGIOwZfRV1aBxKcg51Mn w8JC7AzzbY8Ji4mJtQj0ptvIItjiCzD2XIdoUzgMDLRvszvUPNRZqwlzeG21lbQszscnQJft SpdNIWir6bCWcXEgjL3psjLC9rDRX2ctZmIHmJgvszJgIcwM0dcBbAdLc1ssmkVQvDxhZTsc Bdl9pSxLAeBiBJ3GETZtOgwvx+cRzftguCwf0aYuNnzsbNg2nQVdbve2MIKgrKuJ3EnfuT+9 nVZAe+MtVgHyLv1nw1Lr09xA8MywybYIfLwX+krmCdrkCw+aZ5g0u0J1xQrz/7CFj0OxqZuk +QDczZ9h0yyGlZ51RLM3VNf/IssR7xGyU1Gq2JR4Ly93SpkYp1Ip5O5ySq1H5l/X3bLp2YqW FoMMCHOQaBdfxjBECljSdFVGigEdNJ8z21hrRI6EXCGnREK+71x3pIAvk2ZkUkpFtDItmVIZ kBOHEDnwJaHNEQIcL1VTSRSVSil3VAaH66hBmtE0cezvTKHTd2nO281pnri1aLzop8fR+NVs 7XvZyu4oxrDJEGJjyFv+GtR01S2eWxmWpJttWbQPsPU5WxHSEHa91U/8wVYzWRgTc8zf38M4 GxeM/Xtea97t2Wq7po9GfFP/SbFD0VLJZe/pLNP+89r1J+nnjLLPPp6hl1xOT4kIVYL0yCGm UiX9A8PCvel9AwAA
Archived-At: 
Subject: [netmod] Server Capabilities [was: Re: WG adoption poll - instance-data]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2018 15:13:32 -0000

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

Hello Martin,

I see the yang-instance-data draft as a prerequisite for a draft/RFC=20
about documenting server capabilities: after all my proposal is to=20
document them using instance data. Actually I do plan to write a draft=20
about documenting server capabilities too. However at this moment I have =

too any drafts with my name on them, so I will wait a bit.=C2=A0 If someo=
ne=20
wants to write co-author a draft on server-capabilities that would be=20
nice :-)

I hope after this clarification you will support adoption of my instance =

data draft.

regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:
> Hi,
>
> Bal=C3=A1zs Lengyel  wrote:
>> Hello Martin,
>>
>> I agree that this document shall be about defining the file format,
>> and server capabilities shall only be a use-case.)
>>
>> I already took out a lot of text, that explicitly recommended using
>> instance data for documenting capabilities. Server capabilities are
>> only mentioned in the introduction chapter.
>> As you wrote: There is no _normative_=C2=A0 specification of how a ser=
ver
>> would document its capabilities, because this is
>> what the WG requested, so I removed it.
> Hmm.  Ok, if this is what the WG wants, then it is fine to just have
> server capabilities as an example use case.  (I thought that the WG
> wanted a normative description of server capabilities...)
>
>> I see that I forgot to change the title and the introduction can be
>> reworded to make
>> it more clear that documenting server capabilities is just a use-case.=

>> (I still see it as the primary use-case for instance data.)
> I think all text in 2 Introduction (except the last para) in this case
> should be moved to section 2.1, and new text should be written in 2.
>
> (*if* there will be a separate doc for server capabilities, the text
> in 2 should be moved to that doc instead.)
>
>>  =C2=A0If I promise to change the title and clarify the introduction c=
an you
>> support adoption?
> First of all I'd like to ensure that the WG in fact just wants to do
> the file format.  Since people have expressed support for adopting the
> draft with the current title, I'm not so sure that this is the case.
>
> I think you should make those changes, and I support the adoption of
> the modified document.  I don't see any reason not to make these
> chanegs before posting as a WG doc.
>
>
> /martin
>
>
>
>> regards Balazs
>>
>> On 2018. 10. 09. 12:58, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> I still think that this draft should either be split into two, one fo=
r
>>> specifiying the generic file format (ok with examples), and one for
>>> "Documenting Server Capabilities", or the document should just be
>>> about the file format (+ *examples*).
>>>
>>> [The current document mixes the two; it's a bit as if we had "The
>>> YANG language and a model for interfaces" as one doc...]
>>>
>>> It is clear that the document specifies a file format for YANG
>>> instance data, which is good.  But it is not clear if the document
>>> intends to specify how a server should document its capabilities.
>>>
>>> The Introduction mainly talks about why it is important to document
>>> server capabilities.  But then AFAICT there is no normative
>>> specification of how a server would document its capabilities.
>>>
>>>
>>> /martin
>>>
>>>
>>> Lou Berger  wrote:
>>>> All,
>>>>
>>>> This is start of a two week poll on making
>>>> draft-lengyel-netmod-yang-instance-data-04 a working group
>>>> document. Please send email to the list indicating "yes/support" or
>>>> "no/do not support".  If indicating no, please state your reservatio=
ns
>>>> with the document.  If yes, please also feel free to provide comment=
s
>>>> you'd like to see addressed once the document is a WG document.
>>>>
>>>> The poll ends Oct 22.
>>>>
>>>> Thanks,
>>>>
>>>> Lou (and co-chairs)
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> --=20
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
>>
>>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms040900050802010703020000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAxMzE1MTMxOFow
LwYJKoZIhvcNAQkEMSIEIGEqsnnZG+ZKLoEkyT+/SEjd/XdryC4tPIed5PprLU3MMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAMsYowGSbYV6DNeCOcF5tMgkPLJ3yxHJfWSNGPhvi5WXddQA
dHRzyoGOzlx0kvsjtKeWlnzCW7oWxGoqxFSmTwYhrBSxv6OXBOPVur5x1mOn+Ed0OZMRsjdY
JYzK4h3y4KYujT4XxsjocNvJoQhWe341QDJuvpVTZ9gY5JSY6DPgKCcl1px2RYCox8oz1IcV
G1/sEOZ3peLdsbmJqZA/opVDN1y9gTw/jNRAniWCeVU+gKGF+jfjabI5v31MOO0YC8YElizG
acUhJjOcR3KRrt8OBo0JCF5TpJ3xXvAyGnrjCBQjZlR9AHRQ9VjD8OIbOmLDQZfXgmYZuI2e
K0UV0GsAAAAAAAA=

--------------ms040900050802010703020000--


From nobody Sat Oct 13 14:19:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774B71286E3 for ; Sat, 13 Oct 2018 14:19:50 -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 IHeU-eIPcEUZ for ; Sat, 13 Oct 2018 14:19:48 -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 A675F12D4EA for ; Sat, 13 Oct 2018 14:19:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 04E55DA4; Sat, 13 Oct 2018 23:19:45 +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 diYEE1NDtDPp; Sat, 13 Oct 2018 23:19:42 +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; Sat, 13 Oct 2018 23:19:44 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B845A20037; Sat, 13 Oct 2018 23:19:44 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u1fy0GpHaVV3; Sat, 13 Oct 2018 23:19:44 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6E12620036; Sat, 13 Oct 2018 23:19:44 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Sat, 13 Oct 2018 23:19:43 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 98C4F3000E900F; Sat, 13 Oct 2018 23:19:43 +0200 (CEST)
Date: Sat, 13 Oct 2018 23:19:43 +0200
From: Juergen Schoenwaelder 
To: Michael Rehder 
CC: "netmod@ietf.org" 
Message-ID: <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Michael Rehder , "netmod@ietf.org" 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@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: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2018 21:19:51 -0000

On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:

> The mandatory statement in that case is ignored (I’ve pointed out
> the RNG and Schematron lack of enforcement).  WHEN trumps the
> mandatory status (via explicit mandatory or implicit mandatory via
> min-elements 1)

Has the RNG and Schematron been obtained following RFC 6110? If so,
this may be a problem with RFC 6110 but not with YANG itself. There
are validators that do not use RNG or Schematron.

/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 Mon Oct 15 00:33:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EC8130DBE; Mon, 15 Oct 2018 00:33:16 -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, 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 Y_QVLy5O9NHw; Mon, 15 Oct 2018 00:33:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4A12D4E8; Mon, 15 Oct 2018 00:33:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 405E31AE033A; Mon, 15 Oct 2018 09:33:10 +0200 (CEST)
Date: Mon, 15 Oct 2018 09:33:09 +0200 (CEST)
Message-Id: <20181015.093309.2040803844255950012.mbj@tail-f.com>
To: kaduk@mit.edu
Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com, lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181011184852.GU3293@kduck.kaduk.org>
References: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> <20181010.153528.100217893480849067.mbj@tail-f.com> <20181011184852.GU3293@kduck.kaduk.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 07:33:17 -0000

Hi,

Benjamin Kaduk  wrote:
> On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Benjamin Kaduk  wrote:
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-netmod-schema-mount-11: No Objection
> > > 
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > > 
> > > 
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > > 
> > > 
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > 
> > > 
> > > 
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > > 
> > > Whenever we introduce a new namespace "sub-hierarchy" there is some level
> > > of risk about surpirses with respect to the security properties of the
> > > combined system.  I appreciate that the mounted schemas are "jailed" into
> > > their own subtree except for the specific exceptions for XPath access,
> > > which helps a lot.  But there may still be potential for surprise with
> > > respect to, e.g., access control on mounted schemas, if an administrator
> > > previously assumed that such controls would only be needed at the
> > > top-level.  The document itself doesn't give me a great picture of to what
> > > extent these risks and the possible consequences of the new nested
> > > structure have been considered; I'd be happy to hear if they've been
> > > thought about a lot already and the conclusion was that the situation is so
> > > boring that nothing needs to be mentioned in the document.
> > 
> > The intention was that this is covered in Section 7, Interaction with
> > the Network Configuration Access Control Model (NACM).
> > 
> > But it is probably a good idea to explicitly mention this in the
> > Security Considerations section as well (together with your last point
> > below).  So maybe add a paragraph at the end of Section 11:
> > 
> >   It is important to take the security considerations for all nodes in
> >   the mounted schemas into account, and control access to these nodes
> >   by using the mechanism described in Section 7.
> 
> I guess this addresses my concern; thanks.
> 
> > > Section 3.3
> > > 
> > >    If multiple mount points with the same name are defined in the same
> > >    module - either directly or because the mount point is defined in a
> > >    grouping and the grouping is used multiple times - then the
> > >    corresponding "mount-point" entry applies equally to all such mount
> > >    points.
> > > 
> > > Does this mean that the multiple mount points must serve the same
> > > data/contents, or just that they must use the same schema?
> > > (Is this related to "inline" vs. "shared-schema"?)
> > 
> > No, this document intentionally doesn't assume anything about the
> > source of the instance data (as explained in section 1).  So the
> > answer is that they just use the same schema.
> > 
> > > Section 3.4
> > > 
> > > So this means that there can be multiple
> > > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> > > locations in the hierarchy?  When I was first reading the document, the
> > > design seemed fairly clean with just a single list of mount-points at the
> > > "top-level" that tracks everything, but this kind of recursion seems like
> > > it would make implementation potentially quite complex.  What kind of
> > > implementation experience do we have that can replace my half-informed
> > > suppositions about complexity?
> > 
> > I agree with you that multiple levels of mounting probably can be
> > complex.  But there is nothing in the design of schema mount that
> > prohibits this.  In fact, it "falls out for free" from the design.
> > 
> > A 2-level example is a physical device with LNEs
> > (draft-ietf-rtgwg-lne-model) which has NIs
> > (draft-ietf-rtgwg-ni-model).
> > 
> > > Section 4
> > > 
> > >    Therefore, schema mount also allows for such references.  For every
> > >    mount point in the "shared-schema" case, it is possible to specify a
> > >    leaf-list named "parent-reference" that contains zero or more XPath
> > >    1.0 expressions.  [...]
> > > 
> > > editorial: """the "shared-schema" case""" reads oddly to me; it might be
> > > clearer to refer to schemas mounted using "shared-schema" instead.  As in,
> > > """For every mount point under "shared-schema", [...]"""
> > 
> > We use the wording "in the 'shared-schema' case" in a couple of
> > places.  I don't think "mount point under 'shared-schema'" is
> > correct.
> 
> Okay.
> 
> > > Can we get a reference added for XPath?
> > 
> > Sure, I will add this.
> > 
> > > It's still a little unclear to me exactly how a node in the mounted tree
> > > constructs an XPath expression to refer to the parent-reference
> > > nodes
> > 
> > It's rather the other way around.  If a node in the mounted schema has
> > an XPath expression that refers to a node that is not part of the
> > jailed mounted schema, that node can be brought in by the
> > parent-reference expressions.   An example of this is given in A.3
> > where an "outgoing-interface" (which is a reference to
> > /if:interfaces/if:interface/if:name) works thanks to the
> > parent-reference.
> 
> Sorry for being dense here.  Just to check -- the idea is that I have
> an existing schema that has references to external nodes, and those
> external references are represented as "absolute paths" from the root node.
> When I mount that existing schema, because of the namespace jailing, it
> goes looking for the external reference from that path but starting at the
> mountpoint instead of the real root, and the referred-to node is only
> present in the mounted hierarchy if the external module in question is also
> part of the same mounted schema.  What the parent-reference is doing is
> allowing this absolute-path external node reference to escape the mounted
> hierarchy and find the corresponding nodes from the top-level.
> So there's no new "construction" of XPath expressions; it's just allowing
> existing references to continue to work.

Yes I think this is a correct description.

> Do we need to specify a search order when there are multiple levels of
> hierarchical mounts and a referred-to external node is present at both the
> top-level and an intermediate mount level?

Regarding parent refs, section 4 says:

   For the purposes of evaluating XPath
   expressions within the mounted data tree, the union of all such
   nodesets [from parent references] is added to the accessible data tree.

For example, if we have:

  A implements ietf-schema-mount and mounts B with some parent-refs Pb
  B implements ietf-schema-mount and mounts C with some parent-refs Pc

The parent-refs Pc are XPath expressions in B.  So, applying section
4, it follows that before evaluating Pc, we need to add the result
from evaluating Pb.


And it doesn't really matter if a node is present at both the
top-level and mounted, since the nodes from the parent reference
statement are added to the accessible data tree.  The result can be a
mix of nodes from the parent refs and the mounted tree.

> > >, but
> > > I did not read very far down the reference chain and maybe this is going to
> > > be clear to a practitioner without any more text in the document.
> > > Basically, do I need to know where I am mounted in order to construct
> > > references to nodes in the parent?
> > > 
> > > Section 7
> > > 
> > > NACM "can be used" to control access to mounted nodes.  Is there a risk
> > > that administrators will be "unpleasantly surprised" by mounted nodes by
> > > default not receiving access control, in cases when access control is
> > > already configured at the top level?
> > 
> > Mounted nodes are no different that normal nodes in this regard; i.e.,
> > if NACM is configured to provide read access by default, this read
> > access is applied to all nodes, mounted or not.
> 
> I think I'm considering a somewhat different case, with read-write access
> by default but certain hierarchies restricted to read-only.  If those
> hierarchies are then mounted in a subtree, the read-only restriction could
> be absent in some cases.
> 
> > Maybe we should do:
> > 
> > OLD:
> > 
> >    If NACM [RFC8341] is implemented on a server, it can be used to
> >    control access
> > 
> > NEW:
> > 
> >    If NACM [RFC8341] is implemented on a server, it is used to
> >    control access 
> > 
> > to emphasize that no additional steps need to be taken by the
> > administrator if NACM is used in the first place.
> 
> Combined with the new paragraph in the security considerations, I think
> this would account for everything; thanks.
> 
> > > Section 9
> > > 
> > > Should the top-level module description be using the RFC 8174 boilerplate
> > > instead of thet 2119 boilerplate?
> > 
> > Yes, I will fix.
> > 
> > > Should the requirement for servers that mount any schema to also mount
> > > ietf-yang-library under the mountpoint be mentioned somewhere other than
> > > the description for the 'inline' and 'shared-schema' containers (i.e., in
> > > the discussion text)?
> > 
> > Section 3.3 says:
> > 
> >    The mounted schema is determined at run time: every instance of the
> >    mount point that exists in the operational state MUST contain a copy
> >    of YANG library data that defines the mounted schema exactly as for a
> >    top-level schema. 
> 
> "contain a copy of YANG library data" only mostly translates to "mount
> ietf-yang-library".  It might be beneficial to be more explicit and/or cite
> rfc7895bis here (but this is a non-blocking comment, so do what you think
> is best).

Ok.



/martin



> 
> -Benjamin
> 
> > > Section 11
> > > 
> > > We should probably also have some bland statement about how "the security
> > > considerations for mounted schemas continue to apply to the nodes in the
> > > mounted tree".
> > 
> > Yes, see my proposed text above.
> > 
> > 
> > /martin
> 


From nobody Mon Oct 15 07:25:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E3130E76 for ; Mon, 15 Oct 2018 07:25:55 -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, 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 8uENMxMmYeyt for ; Mon, 15 Oct 2018 07:25:52 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 37F36130E7E for ; Mon, 15 Oct 2018 07:25:52 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id CF4201821139; Mon, 15 Oct 2018 16:33:01 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1E6211820053; Mon, 15 Oct 2018 16:32:59 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: andy@yumaworks.com, rrahman@cisco.com, netmod@ietf.org
In-Reply-To: <20181011.084242.2147348417024315805.mbj@tail-f.com>
References: <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com>  <74ab4ac248f1933ba7a3a095eb7bb1865325588e.camel@nic.cz> <20181011.084242.2147348417024315805.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, rrahman@cisco.com, netmod@ietf.org
Date: Mon, 15 Oct 2018 16:25:48 +0200
Message-ID: <87zhvfi8wj.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 14:25:56 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
>> > 
>> > 
>> > On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
>> > wrote:
>> > > On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>> > > netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
>> > > 
>> > >     Ladislav Lhotka  wrote:
>> > >     > Martin Bjorklund  writes:
>> > >     > 
>> > >     > > Hi,
>> > >     > >
>> > >     > > While reviewing restconf-notif, I saw this example:
>> > >     > >
>> > >     > >    {
>> > >     > >       "ietf-subscribed-notifications:input": {
>> > >     > >          "stream": "NETCONF",
>> > >     > >          "stream-xpath-filter": "/ds:foo/",
>> > >     > >          "dscp": "10"
>> > >     > >       }
>> > >     > >    }
>> > >     > >
>> > >     > > Note the "stream-xpath-filter".  It has a prefix in the XPath
>> > > string.
>> > >     > > How are prefixes declared when JSON is used?
>> > >     > >
>> > >     > > The leaf "stream-xpath-filter" says:
>> > >     > >
>> > >     > >               o  The set of namespace declarations are those in
>> > > scope on
>> > >     > >                  the 'stream-xpath-filter' leaf element.
>> > >     > >
>> > >     > > (I think I provided that text...)
>> > >     > >
>> > >     > > This assumes that the encoding is XML, or at leas that the encoding
>> > >     > > can somehow transfer namespace declarations.
>> > >     > 
>> > >     > It can't. There are two options:
>> > >     > 
>> > >     > 1. have different representations of this value in XML and JSON,
>> > >     >    analogically to instance indentifiers (sec. 6.11 in RFC 7951).
>> > >     > 
>> > >     > 2. use a module name rather than a prefix in XML, too.
>> > >     > 
>> > >     > I would suggest #2.
>> > >  But that means making non-backwards compatible change to the XML
>> > > representation?
>> > 
>> > Not really. It means NETMOD WG would be creating its own special variant of
>> > XPath.
>> 
>> The thing is that XPath is "XML Path Language", so using it outside XML is
>> problematic.
>
> Not necessarily.  Section 5 of the XPath 1.0 spec defins the "data
> model" where an XPath expression is applied.  We could make a formal
> specification of how a YANG data tree maps to this data model (pretty
> straightforward...).  I think experience from implementations over the
> last 8 years show that this in fact works quite well.

Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.

This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.

Lada

>
>
> /martin
>
>
>
>> 
>> Lada
>> 
>> > 
>> > >     Hmm, so you mean change the leaf "stream-xpath-filter" to say:
>> > > 
>> > >              o  The set of namespace declarations has one member for each
>> > >                 YANG module supported by the server.  This member maps
>> > >                 from the YANG module name to the YANG module namespace.
>> > > 
>> > >                 This means that in the XPath expression, the module name
>> > >                 serves as the prefix.
>> > > 
>> > >     .... and then also give an example of this.
>> > > 
>> > >     This is probably what we need to do in all places where yang:xpath1.0
>> > >     is used, going forward.  Maybe even define a new type
>> > >     yang:xpath1.0-2 (name?) with the set of namespace declarations
>> > >     built-in.
>> > 
>> > 
>> > We should avoid making off-the-shelf implementations of standards like XPath
>> > unusable.
>> > At the very least this should be only available if the server supports it
>> > (with a capability URI)
>> > 
>> >  
>> > >  So we need an update to RFC7951?
>> > > 
>> > > Regards,
>> > > Reshad.
>> > > 
>> > 
>> > 
>> > Andy
>> >  
>> > >     /martin
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > >     > 
>> > >     > Lada
>> > >     > 
>> > >     > >
>> > >     > > How is this supposed to work with JSON?
>> > >     > >
>> > >     > >
>> > >     > > /martin
>> > >     > >
>> > >     > > _______________________________________________
>> > >     > > netmod mailing list
>> > >     > > netmod@ietf.org
>> > >     > > https://www.ietf.org/mailman/listinfo/netmod
>> > >     > 
>> > >     > -- 
>> > >     > Ladislav Lhotka
>> > >     > Head, CZ.NIC Labs
>> > >     > PGP Key ID: 0xB8F92B08A9F76C67
>> > >     > 
>> > > 
>> > >     _______________________________________________
>> > >     netmod mailing list
>> > >     netmod@ietf.org
>> > >     https://www.ietf.org/mailman/listinfo/netmod
>> > > 
>> > > 
>> > > _______________________________________________
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > 
>> > 
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Oct 15 08:36:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CEB130EA0; Mon, 15 Oct 2018 08:35:53 -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 pQ9IABGM007q; Mon, 15 Oct 2018 08:35:50 -0700 (PDT)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 8D24E130E9D; Mon, 15 Oct 2018 08:35:50 -0700 (PDT)
Received: by mail-vs1-xe29.google.com with SMTP id g201so16480307vsd.12; Mon, 15 Oct 2018 08:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KdFaf+AQvA47AyfX3eiYST4umbX0SwWT/1LqQ1FViDE=; b=LmPAnsXiC+L5HwDhXGp0n1j30foepzrBrm/MOt72IOW83v2f5Of7fXDTZHchNxVlQ2 Fa5+AxqqTlf11qddtmjPVTI5GIqhezIjIC78+zfp25V6nV/ExkcpY8G/ZmrCVM6/o7cw BsmOhO51a56TP8OghbCkrNTYaQlqHdtMIjEbLdHt0rhLhM/wlXb2PweMnFnK9ZZRGQmG R+I5MHw2/6gCIO68ogE1Adwy2Os164fpC5iF3l/hxgOQdMaNkzewmuaapGoF1TDpFgLS khPmMSmGRBn/ptB6/DPBqvvzlNoKtQOxn9FkAmo6xKOYM4u9e0pb371/zfyY9W1zc0IF XKcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KdFaf+AQvA47AyfX3eiYST4umbX0SwWT/1LqQ1FViDE=; b=HWERMogz5AdXY30zJlFblLLY3cRFbeSOoMvrcQ6JOsQqzMcP6CrnB7X221/NXbEPny nd3/J6kUhX3vKi2woa8ahruTSsDNLw1oQD/+Ir5ZxFhutgGU1VU0V+5urzUvPaYUKbH9 e2Cr1nW/3vay1e1igR+PJ6DL94RSx2nss5t2hwB030T2D8VMp70GU3CWAJ+l7cp/iN5N QneV2yV7pxD5FIDqvhxvzy8zJbtbha0f4PrUBToKMTN45st+QTM89VEDotvQ4pjUu7LT QhVTbiNhuHNFoI/41IM0v4Jq8NzlOtG/QrI457NU7lQ6xgWJk0pZ4kZ4/4nFrggeGtLQ O72g==
X-Gm-Message-State: ABuFfohHLn60U5bTKxWsaoCu/OG6Q1aMmS0tPF5ULvSx+eqLiN6pa+kS OB3ky9eoyyrfArbZlylL5XkEiawnlWcK8N3vJRTlYtM9
X-Google-Smtp-Source: ACcGV61svbxNCZMG4km1VgBeu4DfhsBEkiJ9KPu0oi886afcjOKlggZLJSbOikxh5J38Gc1NpuruJ3Y0pFpKsdg0JJw=
X-Received: by 2002:a67:64c1:: with SMTP id y184mr939754vsb.193.1539617749489;  Mon, 15 Oct 2018 08:35:49 -0700 (PDT)
MIME-Version: 1.0
References: <153904592430.18394.3630036782970324198@ietfa.amsl.com>
In-Reply-To: <153904592430.18394.3630036782970324198@ietfa.amsl.com>
From: Ankit Kumar Sinha 
Date: Mon, 15 Oct 2018 21:05:37 +0530
Message-ID: 
To: andy@yumaworks.com
Cc: yang-doctors@ietf.org, ntp@ietf.org, netmod@ietf.org,  draft-ietf-ntp-yang-data-model.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000c5d4a0578463141"
Archived-At: 
Subject: Re: [netmod] Yangdoctors early review of draft-ietf-ntp-yang-data-model-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 15:35:54 -0000

--0000000000000c5d4a0578463141
Content-Type: text/plain; charset="UTF-8"

Hi Andy,

Please find our comment in line below

Thanks,
Ankit

On Tue, 9 Oct 2018 at 06:15, Andy Bierman  wrote:

> Reviewer: Andy Bierman
> Review result: Almost Ready
>
>
>
>
> Overall:
>    - no compiler warnings; passes --ietf check as well
>
> Normative Sections:
>
> sec 1:
>    - YANG version cited should be RFC 7950, not 6020.
>      YANG 1.1 is used in this document.\
>

[Authors]: Updated

>
> sec 4: Relationship with RFC 7317
>   - this section should say how overlapping configuration
>     objects interact. Does setting 1 field (e.g., /system/ntp/enabled)
>     change the other field at the same time  (e.g., /ntp/enabled)
>     It seems the intent is to ignore and deprecate /system/ntp if
>     /ntp is implemented.  This section should explain.
>

[Authors]: Updated

>
> sec 5:
>   - this section is supposed to have citations for every imported
>     YANG module used in the ietf-ntp YANG module
>

[Authors]: In section 1.4, we have a table of all the improted yang modules
with references. We also use reference statement in the yang model in
section 5. All imported modules are mentioned as normative reference. Is
there any other change you would like to see?

>
>
> YANG Module Issues:
>   1 - Indexing used in /ntp/associations list
>      key "address local-mode isConfigured";
>
>      a) will there really be multiple instances per address for
>         different association-modes?  The list description-stmt
>         should explain.
>

[Authors]: It is possible to have different association-modes for same
address. Example is updated in the the document

>
>      b) There can be configured values (isConfigured key) and learned
>         entries for the same address and association-modes?  Why isn't
>         NMDA used instead? (i.e. intended and operational datastores
>         used instead of the isConfigured list key?)
>

[Authors]: Here /ntp/associations/ is read only, which can have learned
entries and configured entries. Configured entries depends on "unicast,
broadcast, multicast and manycast" configurations. Lets take following
examples

1) If RT1 acting as broadcast server,
   and RT2 acting as broadcast client, then RT2
   will form dynamic association with address as RT1,
   local-mode as client and isconfigured as false.

2) When RT2 is configured
   with unicast-server RT1, then RT2 will form
   association with address as RT1, local-mode as client
   and isconfigured as true.

>
>   2 - Purpose of /ntp/access-rules
>       There is no explanation for what it means to configure an entry
>       here that points at an ACL entry in /acls/acl; The description
>       statement needs to specify the details.  Doesn't the ACL module
>       just work? How does the /ntp/access-rules/access-rule list
>       change behavior?
>

[Authors]: We have updated draft with "section 5 Access Rules" with
explanation

>
>   3 - Reinvent Key Management
>       It does not seem like a good idea for every protocol to
>       duplicate key management functionality. The draft should
>       explain why other YANG modules related to this work are not
>       relevant here
>

[Authors]: We have updated draft with "section 6 Key Management" with
explanation

>
>   4 - Reference statements
>       There are no reference statements used in any objects or typedes
>       Definitions which are intended to match a definition in NTP
>       should include a reference-stmt
>

[Authors]: Updated

>
> Minor Issues:
>    - typedef names should be singular
>       - access-mode not access-modes
>       - association-mode not association-modes
>    - grouping comman-attributes should be common-attributes
>    - mixed-case naming should not be used (isConfigured)
>    - indentation used in module needs a lot of corrections
>    - some descriptions have incorrect tense (e.g., "NTP is enable")
>    - port definition should be based on inet:port-number, not uint16
>      OLD:
>          type uint16 {
>            range "123 | 1025..max";
>          }
>      NEW:
>          type inet:port-number {
>            range "123 | 1025..max";
>          }
>

[Authors]: All the above comments are updated

   - /ntp/authentication/trusted-keys
>      Why is this list needed? Seems a leaf (e.g., trusted-key (true/false)
>      added to the authentication-keys list is sufficient
>
[Authors]: trusted-key is removed and leaf istrusted is added to
authentication-key

   - /ntp/clock-state : some leafs should have a units-stmt instead of
>      specifying the units in the description-stmt (could also apply
> elsewhere)
>    - Examples should use line continuation convention
>      e.g.:
>      OLD:
>       10-10-2017 07:33:55.300 Z+05:30
>          
>      NEW:
>       10-10-2017 07:33:55.300 Z+05:30\
>          
>    - a spell checker should be used; There are many description-stmts
>      with spelling errors
>

[Authors]: All the above comments are updated

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


Hi Andy,

Please find our comment in line below

Thanks,
Ankit

On Tue, 9 Oct 2018 at 06:15, Andy Bierman <andy@yumaworks.com> wrote:
Reviewer: Andy Bierman

Review result: Almost Ready









Overall:

=C2=A0 =C2=A0- no compiler warnings; passes --ietf check as well



Normative Sections:



sec 1:

=C2=A0 =C2=A0- YANG version cited should be RFC 7950, not 6020.

=C2=A0 =C2=A0 =C2=A0YANG 1.1 is used in this document.\

[Authors]: Updated 



sec 4: Relationship with RFC 7317

=C2=A0 - this section should say how overlapping configuration

=C2=A0 =C2=A0 objects interact. Does setting 1 field (e.g., /system/ntp/ena=
bled)

=C2=A0 =C2=A0 change the other field at the same time=C2=A0 (e.g., /ntp/ena=
bled)

=C2=A0 =C2=A0 It seems the intent is to ignore and deprecate /system/ntp if=


=C2=A0 =C2=A0 /ntp is implemented.=C2=A0 This section should explain.

[Authors]: Updated<=
/span> 



sec 5:

=C2=A0 - this section is supposed to have citations for every imported

=C2=A0 =C2=A0 YANG module used in the ietf-ntp YANG module
=

=C2=A0
[Authors]:
 In section 1.4, we have a table of all the improted yang modules with=20
references. We also use reference statement in the yang model in section
 5. All imported modules are mentioned as normative reference. Is there=20
any other change you would like to see?=C2=A0 





YANG Module Issues:

=C2=A0 1 - Indexing used in /ntp/associations list

=C2=A0 =C2=A0 =C2=A0key "address local-mode isConfigured";



=C2=A0 =C2=A0 =C2=A0a) will there really be multiple instances per address =
for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 different association-modes?=C2=A0 The list des=
cription-stmt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 should explain.
=C2=A0
[Authors]: It is possible to have differen=
t association-modes for same address. Example is updated in the the documen=
t 



=C2=A0 =C2=A0 =C2=A0b) There can be configured values (isConfigured key) an=
d learned

=C2=A0 =C2=A0 =C2=A0 =C2=A0 entries for the same address and association-mo=
des?=C2=A0 Why isn't

=C2=A0 =C2=A0 =C2=A0 =C2=A0 NMDA used instead? (i.e. intended and operation=
al datastores

=C2=A0 =C2=A0 =C2=A0 =C2=A0 used instead of the isConfigured list key?)
=

=C2=A0
[Authors]:
 Here /ntp/associations/ is read only, which can have learned entries=20
and configured entries. Configured entries depends on "unicast,=20
broadcast, multicast and manycast" configurations. Lets take following=
 examples

1) If RT1 acting as broadcast server,
=C2=A0=C2=A0 and RT2 acting a=
s broadcast client, then RT2
=C2=A0=C2=A0 will form dynamic association =
with address as RT1,
=C2=A0=C2=A0 local-mode as client and isconfigured =
as false.

<=
span id=3D"gmail-:fy.co" class=3D"gmail-tL8wMe gmail-EMoHub" style=3D"text-=
align:left" dir=3D"ltr">2) When RT2 is configured
=C2=A0=C2=A0 with unic=
ast-server RT1, then RT2 will form
=C2=A0=C2=A0 association with address=
 as RT1, local-mode as client
=C2=A0=C2=A0 and isconfigured as true.
=




=C2=A0 2 - Purpose of /ntp/access-rules

=C2=A0 =C2=A0 =C2=A0 There is no explanation for what it means to configure=
 an entry

=C2=A0 =C2=A0 =C2=A0 here that points at an ACL entry in /acls/acl; The des=
cription

=C2=A0 =C2=A0 =C2=A0 statement needs to specify the details.=C2=A0 Doesn=
9;t the ACL module

=C2=A0 =C2=A0 =C2=A0 just work? How does the /ntp/access-rules/access-rule =
list

=C2=A0 =C2=A0 =C2=A0 change behavior?

<=
span id=3D"gmail-:fy.co" class=3D"gmail-tL8wMe gmail-EMoHub" style=3D"text-=
align:left" dir=3D"ltr">[Authors]: We have updated draft with "section=
 5 Access Rules" with explanation 



=C2=A0 3 - Reinvent Key Management

=C2=A0 =C2=A0 =C2=A0 It does not seem like a good idea for every protocol t=
o

=C2=A0 =C2=A0 =C2=A0 duplicate key management functionality. The draft shou=
ld

=C2=A0 =C2=A0 =C2=A0 explain why other YANG modules related to this work ar=
e not

=C2=A0 =C2=A0 =C2=A0 relevant here

[Authors]: We have updated draft with "section 6 =
Key Management" with explanation 



=C2=A0 4 - Reference statements

=C2=A0 =C2=A0 =C2=A0 There are no reference statements used in any objects =
or typedes

=C2=A0 =C2=A0 =C2=A0 Definitions which are intended to match a definition i=
n NTP

=C2=A0 =C2=A0 =C2=A0 should include a reference-stmt
<=
br>
[Authors]: Updated 
=




Minor Issues:

=C2=A0 =C2=A0- typedef names should be singular

=C2=A0 =C2=A0 =C2=A0 - access-mode not access-modes

=C2=A0 =C2=A0 =C2=A0 - association-mode not association-modes

=C2=A0 =C2=A0- grouping comman-attributes should be common-attributes

=C2=A0 =C2=A0- mixed-case naming should not be used (isConfigured)

=C2=A0 =C2=A0- indentation used in module needs a lot of corrections

=C2=A0 =C2=A0- some descriptions have incorrect tense (e.g., "NTP is e=
nable")

=C2=A0 =C2=A0- port definition should be based on inet:port-number, not uin=
t16

=C2=A0 =C2=A0 =C2=A0OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0range "123 | 1025..max";=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type inet:port-number {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0range "123 | 1025..max";=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0
[Authors]: All the above c=
omments are updated 


=C2=A0 =C2=A0- /ntp/authentication/trusted-keys

=C2=A0 =C2=A0 =C2=A0Why is this list needed? Seems a leaf (e.g., trusted-ke=
y (true/false)

=C2=A0 =C2=A0 =C2=A0added to the authentication-keys list is sufficient
=

[Authors]: trusted-key is remove=
d and leaf istrusted is added to authentication-key


=C2=A0 =C2=A0- /ntp/clock-state : some leafs should have a units-stmt inste=
ad of

=C2=A0 =C2=A0 =C2=A0specifying the units in the description-stmt (could als=
o apply elsewhere)

=C2=A0 =C2=A0- Examples should use line continuation convention

=C2=A0 =C2=A0 =C2=A0e.g.:

=C2=A0 =C2=A0 =C2=A0OLD:

=C2=A0 =C2=A0 =C2=A0 <transmit-time>10-10-2017 07:33:55.300 Z+05:30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</transmit-time>

=C2=A0 =C2=A0 =C2=A0NEW:

=C2=A0 =C2=A0 =C2=A0 <transmit-time>10-10-2017 07:33:55.300 Z+05:30\<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</transmit-time>

=C2=A0 =C2=A0- a spell checker should be used; There are many description-s=
tmts

=C2=A0 =C2=A0 =C2=A0with spelling errors
=C2=A0
<=
div>[Authors]: All the above comments are updated 


--0000000000000c5d4a0578463141--


From nobody Mon Oct 15 11:41:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B466B130EBB for ; Mon, 15 Oct 2018 11:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 iY8KlUd--P5j for ; Mon, 15 Oct 2018 11:41:53 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B671130EAA for ; Mon, 15 Oct 2018 11:41:53 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id A73D9240240 for ; Mon, 15 Oct 2018 20:41:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1539628910; bh=84LC9k97XPYU1jeUJUAuvUmV454wBp7rrt4c1EaRuWs=; h=To:From:Subject:Date; b=H1EZ1MlnbInyaxbmER2jHc53oMSs+t/2lvyjKRfLDd8SMe+6NolIe0zgXNJpBd0V1 YsY+CZMhaRUTWNXrvZ2h+HDa5ZbVZmiKd7Teauq8rryCRKqtf+mQcxc9m1136kmx+l kjlMyUf2XajBqulDW2YwXdXEcJc+KLTV84SSHvEw=
To: "netmod@ietf.org" 
From: Robert Varga 
Openpgp: preference=signencrypt
Message-ID: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
Date: Mon, 15 Oct 2018 20:41:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="38YuB15dySnhpqARToYxE2N3zOTRqiGlW"
Archived-At: 
Subject: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 18:41:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--38YuB15dySnhpqARToYxE2N3zOTRqiGlW
Content-Type: multipart/mixed; boundary="Fvu4ujVOjTS8PdYitfcbm2y18zgn7uvDc";
 protected-headers="v1"
From: Robert Varga 
To: "netmod@ietf.org" 
Message-ID: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
Subject: schematree-statement extension?

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

Hello,

I have recently been reminded that there is a potential interoperability
issue between RFC6020/RFC7950 and extension statements. So far the only
case where this has manifested is tailf:action, but there may be others
lurking in the future.

The issue is that a YANG extension has no standardized way of declaring
it is a part of the schema tree, which means that unless a parser has at
least partial support for a particular extension, attempting to use
deviation or augment statements with it cannot work.

It is wide-spread practice to use tailf:action and target statements
within it with augment/deviate statements -- which I think is a failure
to follow RFC7950 section 6.3.1:

   Care must be taken when defining extensions so that modules that use
   the extensions are meaningful also for applications that do not
   support the extensions.

Therefore a parser which ignores the extension in its entirety, as per
section 6.3.1, will not populate the schema tree with the production of
(for example) 'tailf:action foo' nor its descendants and hence an
attempt to augment the use of the extension or any of its descendant
will result in failure to resolve the schema node identifier to a schema
tree node -- similar to what happens when an attempt is made to augment
a non-existing statement, a grouping, a typedef or an extension
statement (which may itself be unsupported).

I think the proper way of fixing this would be to define a YANG
extension, which, when used within another extension, would indicate
that the extension being defined is part of the schema tree, for example:=


   extension schematree-statement;

   extension foo {
       argument bar;

       sts:schematree-statement;
   }

With that, any parser not knowing "foo", but understanding
"sts:schematree-statement" would know that:
- foo's argument is an identifier as per RFC7950 section 14
- the use of "foo" follows the usual schema tree population rules

Using that knowledge, the parser can correctly interpret
augment/deviation arguments as validly pointing to a particular use of
foo (or its descendants) and correctly ignore their effects.

Is this something the WG feels is a real problem and would be interested
in solving?

Thanks,
Robert


--Fvu4ujVOjTS8PdYitfcbm2y18zgn7uvDc--

--38YuB15dySnhpqARToYxE2N3zOTRqiGlW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlvE32kLHG5pdGVAaHEu
c2sACgkQJKB0S2uuNdsusg/8CptkOHK7QkfjBd06EXTh0TfFFVI98OcvMdCcsjPI
JrKs61gqOtLZDqcFn6AAF8MJZeShke7OlsfPuaRpoxwwqXHCVqIx16GkuArLqQwR
D75Ii21QDN3rL7YPa2NzxruKRrfrEhvxueb+7+Ymt9m/fGevPbo5OeDP68jhCFZH
4Wndf3mNL43pJxL2xst8D08l+swdAnfXwuhexjYybjDTRYXDHhG+2GPPqkkCZj3l
5Eg6QZEgPBMILQQJtRirJPiAQhrzMU1LCCb1rGaI4wDp7sMH6qX+Fzg5q3fIw/e+
+edFB4J8iVby9PsNBlh9llMzvRjSodPh9VDPGyXZNp/j8RTjXobf4tKatKDMlSWx
5U1+Cm9NoQTW+9GJ1KLszR8sWg0zek9M3/lPKPfav54pleR03pC5JakRdgWD1i0F
iq/EvoTkkqMHWWPzI0/ZJQeUvwV1eUmdnQyJpR2HJcmS/fzGD7GyhyDE3Bsph61z
PtUk55Y3EWwRI34YNrQLpGj3ZkC3s93YKtMvdkQchnHkf0417ohKZnTfLItb9HA1
49hSdzwqGBpLA0y7LQeyTFJqNWPqbp5pC3Zen4fHcnm24MNNyf7joSf1rtkol+IF
FNbSPqf7rWuLyTH3q+C+rrv9AvhNe71gJcMrlGPlMjr8Ob12wz0wfs9OxbT7vBUe
VC4=
=ok2E
-----END PGP SIGNATURE-----

--38YuB15dySnhpqARToYxE2N3zOTRqiGlW--


From nobody Mon Oct 15 12:09:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74145124C04 for ; Mon, 15 Oct 2018 12:09:43 -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, 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 gZRDaI62m8od for ; Mon, 15 Oct 2018 12:09:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB038130F24 for ; Mon, 15 Oct 2018 12:09:38 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 313861AE033A; Mon, 15 Oct 2018 21:09:37 +0200 (CEST)
Date: Mon, 15 Oct 2018 21:09:37 +0200 (CEST)
Message-Id: <20181015.210937.2105117531520960939.mbj@tail-f.com>
To: nite@hq.sk
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 19:09:51 -0000

Hi,

Robert Varga  wrote:
> Hello,
> 
> I have recently been reminded that there is a potential interoperability
> issue between RFC6020/RFC7950 and extension statements. So far the only
> case where this has manifested is tailf:action, but there may be others
> lurking in the future.
> 
> The issue is that a YANG extension has no standardized way of declaring
> it is a part of the schema tree, which means that unless a parser has at
> least partial support for a particular extension, attempting to use
> deviation or augment statements with it cannot work.
> 
> It is wide-spread practice to use tailf:action and target statements
> within it with augment/deviate statements -- which I think is a failure
> to follow RFC7950 section 6.3.1:
> 
>    Care must be taken when defining extensions so that modules that use
>    the extensions are meaningful also for applications that do not
>    support the extensions.

Yes, but note that 7950 means a 1.1 module, and tailf:action should be
replaced with 'action' in a 1.1 module.

One reason we added the quoted paragraph to 7950 was because of the
problem you describe with tailf:action.

> Therefore a parser which ignores the extension in its entirety, as per
> section 6.3.1, will not populate the schema tree with the production of
> (for example) 'tailf:action foo' nor its descendants and hence an
> attempt to augment the use of the extension or any of its descendant
> will result in failure to resolve the schema node identifier to a schema
> tree node -- similar to what happens when an attempt is made to augment
> a non-existing statement, a grouping, a typedef or an extension
> statement (which may itself be unsupported).
> 
> I think the proper way of fixing this would be to define a YANG
> extension, which, when used within another extension, would indicate
> that the extension being defined is part of the schema tree, for example:
> 
>    extension schematree-statement;
> 
>    extension foo {
>        argument bar;
> 
>        sts:schematree-statement;
>    }

Unfortunately, this doesn't solve the problem, since a parser that
doesn't understand sts:schematree-statement still wouldn't know that
foo defined a schema node, and thus it will still complain if it sees
an augment of a node introduced with "ex:foo".

In order for this to work, "schematree-statement" would have to be a
builtin statement.

(... and if we had this statement, we could have used it in yang-ext
as well, and avoid augement-yang-data)

> With that, any parser not knowing "foo", but understanding
> "sts:schematree-statement" would know that:
> - foo's argument is an identifier as per RFC7950 section 14
> - the use of "foo" follows the usual schema tree population rules
> 
> Using that knowledge, the parser can correctly interpret
> augment/deviation arguments as validly pointing to a particular use of
> foo (or its descendants) and correctly ignore their effects.
> 
> Is this something the WG feels is a real problem and would be interested
> in solving?

The current advice is of course to NEVER add nodes to the schema tree
with an extension.  I think it is probably best to stick to this
advice...


/martin


From nobody Mon Oct 15 12:36:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB52130DDA for ; Mon, 15 Oct 2018 12:36:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 L5JX6RH7qEHR for ; Mon, 15 Oct 2018 12:36:11 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86608130ED2 for ; Mon, 15 Oct 2018 12:36:09 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 1F5AC240246; Mon, 15 Oct 2018 21:36:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1539632167; bh=hjcwdiHM42/PhYgQIUAdso+ZkcvW1YzhMVBtifu+a4o=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PnwzG0KmuYKXSii/JVrlnWVinTDXBstRxA/S0uFjB/s9lvtBT8Tv5zEMNyFjRjBca IMQUxxaxzq9+Wxea1Tui4ZuS35lJU9q990kCIY5Jo0Iw6PV6bJ/2vodnK9C0ZB4j9S YOYEoO+q2s5mrffKIQB2I59eiY/hRfVARNnXf7ew=
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk> <20181015.210937.2105117531520960939.mbj@tail-f.com>
From: Robert Varga 
Openpgp: preference=signencrypt
Message-ID: <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
Date: Mon, 15 Oct 2018 21:36:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181015.210937.2105117531520960939.mbj@tail-f.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a0mg9xpwXjVMEzShwSmugjD8S99cMwxDX"
Archived-At: 
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 19:36:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--a0mg9xpwXjVMEzShwSmugjD8S99cMwxDX
Content-Type: multipart/mixed; boundary="8QnrtAcdOkIIrv7nY7yQS3sijiYaw1H1D";
 protected-headers="v1"
From: Robert Varga 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
Subject: Re: [netmod] schematree-statement extension?
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
 <20181015.210937.2105117531520960939.mbj@tail-f.com>
In-Reply-To: <20181015.210937.2105117531520960939.mbj@tail-f.com>

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

On 15/10/2018 21:09, Martin Bjorklund wrote:
> Hi,
>=20
> Robert Varga  wrote:
>> It is wide-spread practice to use tailf:action and target statements
>> within it with augment/deviate statements -- which I think is a failur=
e
>> to follow RFC7950 section 6.3.1:
>>
>>    Care must be taken when defining extensions so that modules that us=
e
>>    the extensions are meaningful also for applications that do not
>>    support the extensions.
>=20
> Yes, but note that 7950 means a 1.1 module, and tailf:action should be
> replaced with 'action' in a 1.1 module.

I think the argument applies (and proposed extension would be
applicable) to RFC6020 as well.

I am not complaining about tailf:action specifically, I will just map it
YANG 1.1 action even in YANG 1.0 mode and I'm done :)

> One reason we added the quoted paragraph to 7950 was because of the
> problem you describe with tailf:action.

I suspected as much, thank you for that :)

>> I think the proper way of fixing this would be to define a YANG
>> extension, which, when used within another extension, would indicate
>> that the extension being defined is part of the schema tree, for examp=
le:
>>
>>    extension schematree-statement;
>>
>>    extension foo {
>>        argument bar;
>>
>>        sts:schematree-statement;
>>    }
>=20
> Unfortunately, this doesn't solve the problem, since a parser that
> doesn't understand sts:schematree-statement still wouldn't know that
> foo defined a schema node, and thus it will still complain if it sees
> an augment of a node introduced with "ex:foo".
>=20
> In order for this to work, "schematree-statement" would have to be a
> builtin statement.
>=20
> (... and if we had this statement, we could have used it in yang-ext
> as well, and avoid augement-yang-data)

Understood and agreed, parsers not supporting schematree-statement would
be left unfixed, but also no worse off.

My skin in the game is to future-proof my parser (based on supporting
widely-available specifications) until this is fixed for everyone with
YANG 1.2. Adding support for a language extension is much simpler than
to bump YANG language support by 0.1, at least in my experience.

This could even help augment-yang-data in that the semantics of what it
does would be kept with the extension (yang-data) as opposed to a
different, related (as understandable by humans), language extension. An
an implementor,

Such extension would also address a piece of RFC7950 section 7.19's:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section 7.20.3.2), but the mechanism for how this is defined is
   outside the scope of this specification.

by defining how an extension can declare that it _does_allow_ refinement
and deviations without getting into the business of how that
refinement/deviations are done. This could even be separate extensions:

   extension augmentable-statement;
   extension deviable-statement;

Such a language extension can be picked up by parsers across all YANG
versions, making adoption much easier and faster.

>> Using that knowledge, the parser can correctly interpret
>> augment/deviation arguments as validly pointing to a particular use of=

>> foo (or its descendants) and correctly ignore their effects.
>>
>> Is this something the WG feels is a real problem and would be interest=
ed
>> in solving?
>=20
> The current advice is of course to NEVER add nodes to the schema tree
> with an extension.  I think it is probably best to stick to this
> advice...

That advice I missed. Is there a link I can quote? :)

Thanks,
Robert


--8QnrtAcdOkIIrv7nY7yQS3sijiYaw1H1D--

--a0mg9xpwXjVMEzShwSmugjD8S99cMwxDX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlvE7CYLHG5pdGVAaHEu
c2sACgkQJKB0S2uuNdvLyw/+IESjNDUpSieP3T6FxGikobqWSy8dc5U3oE8QlJFs
BTTDTExbytBGCdw0eN3TYuQyM+wQVi5IRZvVkMlJAiJVX2w0GzRWdweeltXZIGs8
S3W8KjNGbVdtxdGv+Iyw60idHoY2I6lX7yr78AT+B240LN26ZZYI1Dkyp2Y1AhBw
ydgRmdWfjxxxQgblGes9r26pAQtkKGxh3N9Bc6xKUYvel0bN2YBho6rGzZweCwK1
VRUIMPLd3m15BeK2/I5U2DUMGn/TJucqUSSmdFbVt/jiNlIm/Vs6GwO2db/+W6uu
YqxBNQjwPEiJLhxxNWIxkh5729goMhswTRTnVuG5sQJwP+YQk/qfYSh+s+4263gc
3TRzNI3zRMLfZ/3Ebq8Z6HMMRU9DicLT5CPf5IRU1FBfBY6+Oqaav+WENyn4iirP
slU1arrBBKdBqHwKnE19uWWhUiMF79Z90HpFLN5qiKX7JwgS/eT2iIw44pncTVmw
0pTpRLkW1T8LPGOX3lqF5kg3EjOyFqHcqHizGAf7FqGGFdkx2Vc1GDQ0CAQh1q0L
gqPZ66OGFrokPZr/LSsMvkkUUNe4B9+oU7JXamn+vNLqjgN5OCaBQjNnFM43uF5x
eFX3GYp2W6MBPXDArL4270zihof+kIOm/tVnKV+6BdzoNWCgRXTiAJSH/BEth0vT
x1o=
=kcbd
-----END PGP SIGNATURE-----

--a0mg9xpwXjVMEzShwSmugjD8S99cMwxDX--


From nobody Mon Oct 15 12:49:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BA3130DDA for ; Mon, 15 Oct 2018 12:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level: 
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER5I9k2MgYqG for ; Mon, 15 Oct 2018 12:49:32 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FB1127332 for ; Mon, 15 Oct 2018 12:49:32 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9FJjDcJ002402; Mon, 15 Oct 2018 12:49:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=cHlAp/UHMLbexHa/PY7ByPeOtVzn01TgmnhYSTixLZ0=; b=Nh+QTkFKLJQomM6YZItIYugAq6RB21NfkewmFdZOlEc4mmN4a7RS3fZDrCyagVTJaQGJ bZj9YRu9qdwoNUYm1hs35hM+2JKNfMenEaRUcDc3GI0IgzIuolvYYtveikubLxjazNR+ A4Ig/WMNgkHT7OteEZFG7rSby1/d7kgLO0veTbr52t/GfofF+VFaX1IkMpwW6wWmVVtz aQ0G4ifMTisK6Fb9QzP8jLgUTLyHEpOnNLWW6eoqVFW1g7IBRvw2sRhUzPif17FiXTMt qsl8hK0Yqhbrq5jVe9bnystugnCl1MqT93VQdjhD6uu5JVFn8w0SvUEWJiqSLqMg5ydT JQ== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0b-00273201.pphosted.com with ESMTP id 2n4ur98m6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Oct 2018 12:49:24 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6SPR01MB0042.namprd05.prod.outlook.com (20.178.24.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.13; Mon, 15 Oct 2018 19:49:22 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::8574:3388:660d:e495%5]) with mapi id 15.20.1228.020; Mon, 15 Oct 2018 19:49:22 +0000
From: Kent Watsen 
To: Robert Varga , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] schematree-statement extension?
Thread-Index: AQHUZLbE4000Z90T/kKAKI2z38PgOKUgq82AgAAHZgD//8DFgA==
Date: Mon, 15 Oct 2018 19:49:22 +0000
Message-ID: <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk> <20181015.210937.2105117531520960939.mbj@tail-f.com> <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
In-Reply-To: <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6SPR01MB0042; 6:H1Xl9bbBEOfZbx2OIi8S0KNoym+RzP1CUKI3RAxwmHVJMew9LZ7JXynBHxVt3Y5EYyS1h/pLuixlbgcNRD/DOnXpbVdhe8JTNgSJ1XNvhvxOBRBYRyG9oi7jme47GXrx3W4AqcRqWHCh8eRP4LnSl9CaeWiO5HKcbMfCgXo+T5oK+gq/6uoE2oQrhOkNKKU7jyUQYFcEpRBNPdfRerszGBsSRs1XZ3o3jtL36eyA1Rm7kzrrRtQ2yvOYS2Xrx5MoSpvZlWPuDbHvmpLrvmDGBg4oz/fS2Yyx9b5tskxjfSw+Cl4UDF3V2D3mqYKo00LiH7wCNOht93qj/RjUZApA9ipu9wU8YHdEQXWlFqvmeP+6yN9AmV/OrTG2TCNKWWiOmsh7u60E4AocXFoAy50VVD5wppOwUcHMB2Nqm5eKa0gisTiXDXmY5mrr78EuV2o3wiA0N098GchW+C6yn/3WIA==; 5:CbyL1+IW4y/WKB+XWs4hQDYrIz+MSPjznEwydGgivu6D2NjhcyrLH3tv+WTIm2kPJlW1nlL4qeK7h4yYjkhMNTxsjqGQIW4OF1sGFD7+PzjD/tBkM5bzppNT7j/jT5ukTGV5LdevrpVkohLgeTrZR9FN+N/P5QYJVyvwyze1aG4=; 7:GNH0x3RwWJbMQgHFcfjZE8/I5Bn4LBG70ore8W1IVAfhnGRWopuPPKQfxOEiI1s4S6OPSEYThHZG/Pa5CNe01tX6WNdAFp8RP3O6X6MpCxGFiFA+dCQHBNS51CYRksiVexnBTdJY8sUeqASP9BECGjVDcizAv3MAJvUp73C8e3fA7by+ozGSpMMYTpGWDjRDOy+mrDuo8iy9qeMq7oZflzQ4bYMNHlphrvLHlVUGfImHoGCRtgtL2mNZOO10nNAt
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4086dc52-96f8-41a3-c2c5-08d632d74de7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6SPR01MB0042; 
x-ms-traffictypediagnostic: DM6SPR01MB0042:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(278428928389397);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:DM6SPR01MB0042; BCL:0; PCL:0; RULEID:; SRVR:DM6SPR01MB0042; 
x-forefront-prvs: 0826B2F01B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(366004)(346002)(13464003)(189003)(199004)(316002)(14454004)(76176011)(53546011)(6506007)(110136005)(58126008)(26005)(2906002)(966005)(478600001)(105586002)(83716004)(5660300001)(86362001)(71200400001)(71190400001)(97736004)(4326008)(81156014)(5250100002)(229853002)(99286004)(186003)(102836004)(2900100001)(8676002)(345774005)(6436002)(81166006)(25786009)(82746002)(36756003)(33656002)(6246003)(6486002)(66066001)(305945005)(7736002)(106356001)(2616005)(476003)(53936002)(68736007)(486006)(446003)(11346002)(14444005)(6512007)(6306002)(3846002)(256004)(6116002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6SPR01MB0042; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Mt96aPA7Bd9w6iDuXxcsIzthPY0DL9Vpo+LeZ5rphnSEtp291d8JMz9qDrOq7snv3fA/gZ8ay+bzfixHLP1CQ94RBPqysIVRDsVuGSenzMbfmSErP4JI8wlV3bp/nGZgTthgkTlw1Sxpt4xJfgDXToU4gdZm6lA6Ljh1hr9AcXCzH5OJNk+bNoRSHYnTVU0Mk1dy9z0voSIQ83ETvTjUthJbVyyqsj//NqACd+VGs8ODccsoR9r3xhRDDLI36IrOnlt8CB8a09C34k5iZBWEAKa0isJdIEvT5wh23039MXQ17tzvxF7UXBDlHvywQR5VFsjS19fovhKuhvkbnmkN/vHkAEuazYFIFwb2Obey2r0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F829689C0DD7B4ABE2660A2C3ACB326@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4086dc52-96f8-41a3-c2c5-08d632d74de7
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2018 19:49:22.4714 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6SPR01MB0042
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-15_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810150170
Archived-At: 
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 19:49:36 -0000

SGkgUm9iZXJ0LA0KDQpQaWNraW5nIHVwIG9uIHlvdXIgWUFORyAxLjIgY29tbWVudC4gIFBsZWFz
ZSBhZGQgYSBZQU5HLW5leHQgaXNzdWUsIGlmIHRoaXMNCmlzIG5vdCBiZWluZyB0cmFja2VkIGFs
cmVhZHkuIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cveWFuZy1uZXh0L2lzc3Vlcy4NCg0K
VGhhbmtzLA0KS2VudA0KDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSb2JlcnQgVmFy
Z2EgPG5pdGVAaHEuc2s+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMTUsIDIwMTggYXQgMzozNiBQ
TQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KQ2M6ICJuZXRtb2RAaWV0
Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gc2NoZW1hdHJl
ZS1zdGF0ZW1lbnQgZXh0ZW5zaW9uPw0KDQpPbiAxNS8xMC8yMDE4IDIxOjA5LCBNYXJ0aW4gQmpv
cmtsdW5kIHdyb3RlOg0KPiBIaSwNCj4gDQo+IFJvYmVydCBWYXJnYSA8bml0ZUBocS5zaz4gd3Jv
dGU6DQo+PiBJdCBpcyB3aWRlLXNwcmVhZCBwcmFjdGljZSB0byB1c2UgdGFpbGY6YWN0aW9uIGFu
ZCB0YXJnZXQgc3RhdGVtZW50cw0KPj4gd2l0aGluIGl0IHdpdGggYXVnbWVudC9kZXZpYXRlIHN0
YXRlbWVudHMgLS0gd2hpY2ggSSB0aGluayBpcyBhIGZhaWx1cmUNCj4+IHRvIGZvbGxvdyBSRkM3
OTUwIHNlY3Rpb24gNi4zLjE6DQo+Pg0KPj4gICAgQ2FyZSBtdXN0IGJlIHRha2VuIHdoZW4gZGVm
aW5pbmcgZXh0ZW5zaW9ucyBzbyB0aGF0IG1vZHVsZXMgdGhhdCB1c2UNCj4+ICAgIHRoZSBleHRl
bnNpb25zIGFyZSBtZWFuaW5nZnVsIGFsc28gZm9yIGFwcGxpY2F0aW9ucyB0aGF0IGRvIG5vdA0K
Pj4gICAgc3VwcG9ydCB0aGUgZXh0ZW5zaW9ucy4NCj4gDQo+IFllcywgYnV0IG5vdGUgdGhhdCA3
OTUwIG1lYW5zIGEgMS4xIG1vZHVsZSwgYW5kIHRhaWxmOmFjdGlvbiBzaG91bGQgYmUNCj4gcmVw
bGFjZWQgd2l0aCAnYWN0aW9uJyBpbiBhIDEuMSBtb2R1bGUuDQoNCkkgdGhpbmsgdGhlIGFyZ3Vt
ZW50IGFwcGxpZXMgKGFuZCBwcm9wb3NlZCBleHRlbnNpb24gd291bGQgYmUNCmFwcGxpY2FibGUp
IHRvIFJGQzYwMjAgYXMgd2VsbC4NCg0KSSBhbSBub3QgY29tcGxhaW5pbmcgYWJvdXQgdGFpbGY6
YWN0aW9uIHNwZWNpZmljYWxseSwgSSB3aWxsIGp1c3QgbWFwIGl0DQpZQU5HIDEuMSBhY3Rpb24g
ZXZlbiBpbiBZQU5HIDEuMCBtb2RlIGFuZCBJJ20gZG9uZSA6KQ0KDQo+IE9uZSByZWFzb24gd2Ug
YWRkZWQgdGhlIHF1b3RlZCBwYXJhZ3JhcGggdG8gNzk1MCB3YXMgYmVjYXVzZSBvZiB0aGUNCj4g
cHJvYmxlbSB5b3UgZGVzY3JpYmUgd2l0aCB0YWlsZjphY3Rpb24uDQoNCkkgc3VzcGVjdGVkIGFz
IG11Y2gsIHRoYW5rIHlvdSBmb3IgdGhhdCA6KQ0KDQo+PiBJIHRoaW5rIHRoZSBwcm9wZXIgd2F5
IG9mIGZpeGluZyB0aGlzIHdvdWxkIGJlIHRvIGRlZmluZSBhIFlBTkcNCj4+IGV4dGVuc2lvbiwg
d2hpY2gsIHdoZW4gdXNlZCB3aXRoaW4gYW5vdGhlciBleHRlbnNpb24sIHdvdWxkIGluZGljYXRl
DQo+PiB0aGF0IHRoZSBleHRlbnNpb24gYmVpbmcgZGVmaW5lZCBpcyBwYXJ0IG9mIHRoZSBzY2hl
bWEgdHJlZSwgZm9yIGV4YW1wbGU6DQo+Pg0KPj4gICAgZXh0ZW5zaW9uIHNjaGVtYXRyZWUtc3Rh
dGVtZW50Ow0KPj4NCj4+ICAgIGV4dGVuc2lvbiBmb28gew0KPj4gICAgICAgIGFyZ3VtZW50IGJh
cjsNCj4+DQo+PiAgICAgICAgc3RzOnNjaGVtYXRyZWUtc3RhdGVtZW50Ow0KPj4gICAgfQ0KPiAN
Cj4gVW5mb3J0dW5hdGVseSwgdGhpcyBkb2Vzbid0IHNvbHZlIHRoZSBwcm9ibGVtLCBzaW5jZSBh
IHBhcnNlciB0aGF0DQo+IGRvZXNuJ3QgdW5kZXJzdGFuZCBzdHM6c2NoZW1hdHJlZS1zdGF0ZW1l
bnQgc3RpbGwgd291bGRuJ3Qga25vdyB0aGF0DQo+IGZvbyBkZWZpbmVkIGEgc2NoZW1hIG5vZGUs
IGFuZCB0aHVzIGl0IHdpbGwgc3RpbGwgY29tcGxhaW4gaWYgaXQgc2Vlcw0KPiBhbiBhdWdtZW50
IG9mIGEgbm9kZSBpbnRyb2R1Y2VkIHdpdGggImV4OmZvbyIuDQo+IA0KPiBJbiBvcmRlciBmb3Ig
dGhpcyB0byB3b3JrLCAic2NoZW1hdHJlZS1zdGF0ZW1lbnQiIHdvdWxkIGhhdmUgdG8gYmUgYQ0K
PiBidWlsdGluIHN0YXRlbWVudC4NCj4gDQo+ICguLi4gYW5kIGlmIHdlIGhhZCB0aGlzIHN0YXRl
bWVudCwgd2UgY291bGQgaGF2ZSB1c2VkIGl0IGluIHlhbmctZXh0DQo+IGFzIHdlbGwsIGFuZCBh
dm9pZCBhdWdlbWVudC15YW5nLWRhdGEpDQoNClVuZGVyc3Rvb2QgYW5kIGFncmVlZCwgcGFyc2Vy
cyBub3Qgc3VwcG9ydGluZyBzY2hlbWF0cmVlLXN0YXRlbWVudCB3b3VsZA0KYmUgbGVmdCB1bmZp
eGVkLCBidXQgYWxzbyBubyB3b3JzZSBvZmYuDQoNCk15IHNraW4gaW4gdGhlIGdhbWUgaXMgdG8g
ZnV0dXJlLXByb29mIG15IHBhcnNlciAoYmFzZWQgb24gc3VwcG9ydGluZw0Kd2lkZWx5LWF2YWls
YWJsZSBzcGVjaWZpY2F0aW9ucykgdW50aWwgdGhpcyBpcyBmaXhlZCBmb3IgZXZlcnlvbmUgd2l0
aA0KWUFORyAxLjIuIEFkZGluZyBzdXBwb3J0IGZvciBhIGxhbmd1YWdlIGV4dGVuc2lvbiBpcyBt
dWNoIHNpbXBsZXIgdGhhbg0KdG8gYnVtcCBZQU5HIGxhbmd1YWdlIHN1cHBvcnQgYnkgMC4xLCBh
dCBsZWFzdCBpbiBteSBleHBlcmllbmNlLg0KDQpUaGlzIGNvdWxkIGV2ZW4gaGVscCBhdWdtZW50
LXlhbmctZGF0YSBpbiB0aGF0IHRoZSBzZW1hbnRpY3Mgb2Ygd2hhdCBpdA0KZG9lcyB3b3VsZCBi
ZSBrZXB0IHdpdGggdGhlIGV4dGVuc2lvbiAoeWFuZy1kYXRhKSBhcyBvcHBvc2VkIHRvIGENCmRp
ZmZlcmVudCwgcmVsYXRlZCAoYXMgdW5kZXJzdGFuZGFibGUgYnkgaHVtYW5zKSwgbGFuZ3VhZ2Ug
ZXh0ZW5zaW9uLiBBbg0KYW4gaW1wbGVtZW50b3IsDQoNClN1Y2ggZXh0ZW5zaW9uIHdvdWxkIGFs
c28gYWRkcmVzcyBhIHBpZWNlIG9mIFJGQzc5NTAgc2VjdGlvbiA3LjE5J3M6DQoNCiAgIEFuIGV4
dGVuc2lvbiBjYW4gYWxsb3cgcmVmaW5lbWVudCAoc2VlIFNlY3Rpb24gNy4xMy4yKSBhbmQgZGV2
aWF0aW9ucw0KICAgKFNlY3Rpb24gNy4yMC4zLjIpLCBidXQgdGhlIG1lY2hhbmlzbSBmb3IgaG93
IHRoaXMgaXMgZGVmaW5lZCBpcw0KICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZp
Y2F0aW9uLg0KDQpieSBkZWZpbmluZyBob3cgYW4gZXh0ZW5zaW9uIGNhbiBkZWNsYXJlIHRoYXQg
aXQgX2RvZXNfYWxsb3dfIHJlZmluZW1lbnQNCmFuZCBkZXZpYXRpb25zIHdpdGhvdXQgZ2V0dGlu
ZyBpbnRvIHRoZSBidXNpbmVzcyBvZiBob3cgdGhhdA0KcmVmaW5lbWVudC9kZXZpYXRpb25zIGFy
ZSBkb25lLiBUaGlzIGNvdWxkIGV2ZW4gYmUgc2VwYXJhdGUgZXh0ZW5zaW9uczoNCg0KICAgZXh0
ZW5zaW9uIGF1Z21lbnRhYmxlLXN0YXRlbWVudDsNCiAgIGV4dGVuc2lvbiBkZXZpYWJsZS1zdGF0
ZW1lbnQ7DQoNClN1Y2ggYSBsYW5ndWFnZSBleHRlbnNpb24gY2FuIGJlIHBpY2tlZCB1cCBieSBw
YXJzZXJzIGFjcm9zcyBhbGwgWUFORw0KdmVyc2lvbnMsIG1ha2luZyBhZG9wdGlvbiBtdWNoIGVh
c2llciBhbmQgZmFzdGVyLg0KDQo+PiBVc2luZyB0aGF0IGtub3dsZWRnZSwgdGhlIHBhcnNlciBj
YW4gY29ycmVjdGx5IGludGVycHJldA0KPj4gYXVnbWVudC9kZXZpYXRpb24gYXJndW1lbnRzIGFz
IHZhbGlkbHkgcG9pbnRpbmcgdG8gYSBwYXJ0aWN1bGFyIHVzZSBvZg0KPj4gZm9vIChvciBpdHMg
ZGVzY2VuZGFudHMpIGFuZCBjb3JyZWN0bHkgaWdub3JlIHRoZWlyIGVmZmVjdHMuDQo+Pg0KPj4g
SXMgdGhpcyBzb21ldGhpbmcgdGhlIFdHIGZlZWxzIGlzIGEgcmVhbCBwcm9ibGVtIGFuZCB3b3Vs
ZCBiZSBpbnRlcmVzdGVkDQo+PiBpbiBzb2x2aW5nPw0KPiANCj4gVGhlIGN1cnJlbnQgYWR2aWNl
IGlzIG9mIGNvdXJzZSB0byBORVZFUiBhZGQgbm9kZXMgdG8gdGhlIHNjaGVtYSB0cmVlDQo+IHdp
dGggYW4gZXh0ZW5zaW9uLiAgSSB0aGluayBpdCBpcyBwcm9iYWJseSBiZXN0IHRvIHN0aWNrIHRv
IHRoaXMNCj4gYWR2aWNlLi4uDQoNClRoYXQgYWR2aWNlIEkgbWlzc2VkLiBJcyB0aGVyZSBhIGxp
bmsgSSBjYW4gcXVvdGU/IDopDQoNClRoYW5rcywNClJvYmVydA0KDQoNCg==


From nobody Mon Oct 15 12:53:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF50130F0D for ; Mon, 15 Oct 2018 12:53:34 -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, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKH8ZalGicCP for ; Mon, 15 Oct 2018 12:53:31 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E45130EE2 for ; Mon, 15 Oct 2018 12:53:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A79861443EF5; Mon, 15 Oct 2018 21:53:28 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 63BZU7EgyTaW; Mon, 15 Oct 2018 21:53:28 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7B3A61443EDD; Mon, 15 Oct 2018 21:53:28 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 14VUqqAIEttc; Mon, 15 Oct 2018 21:53:28 +0200 (CEST)
Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 5192E1443EA0; Mon, 15 Oct 2018 21:53:28 +0200 (CEST)
To: Ladislav Lhotka , netmod@ietf.org
References: <3B614CF4-9545-4C31-BEF4-CDFBF72AA045@cisco.com>  <74ab4ac248f1933ba7a3a095eb7bb1865325588e.camel@nic.cz> <20181011.084242.2147348417024315805.mbj@tail-f.com> <87zhvfi8wj.fsf@nic.cz>
From: Vladimir Vassilev 
Message-ID: <82c86e19-e626-a4c3-b1d4-e803bc0fd05c@transpacket.com>
Date: Mon, 15 Oct 2018 21:53:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87zhvfi8wj.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 19:53:41 -0000

On 10/15/18 4:25 PM, Ladislav Lhotka wrote:

> Martin Bjorklund  writes:
>
>> Ladislav Lhotka  wrote:
>>> On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:
>>>>
>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
>>>> wrote:
>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
>>>>> netmod-bounces@ietf.org on behalf of mbj@tail-f.com> wrote:
>>>>>
>>>>>      Ladislav Lhotka  wrote:
>>>>>      > Martin Bjorklund  writes:
>>>>>      >
>>>>>      > > Hi,
>>>>>      > >
>>>>>      > > While reviewing restconf-notif, I saw this example:
>>>>>      > >
>>>>>      > >    {
>>>>>      > >       "ietf-subscribed-notifications:input": {
>>>>>      > >          "stream": "NETCONF",
>>>>>      > >          "stream-xpath-filter": "/ds:foo/",
>>>>>      > >          "dscp": "10"
>>>>>      > >       }
>>>>>      > >    }
>>>>>      > >
>>>>>      > > Note the "stream-xpath-filter".  It has a prefix in the XP=
ath
>>>>> string.
>>>>>      > > How are prefixes declared when JSON is used?
>>>>>      > >
>>>>>      > > The leaf "stream-xpath-filter" says:
>>>>>      > >
>>>>>      > >               o  The set of namespace declarations are tho=
se in
>>>>> scope on
>>>>>      > >                  the 'stream-xpath-filter' leaf element.
>>>>>      > >
>>>>>      > > (I think I provided that text...)
>>>>>      > >
>>>>>      > > This assumes that the encoding is XML, or at leas that the=
 encoding
>>>>>      > > can somehow transfer namespace declarations.
>>>>>      >
>>>>>      > It can't. There are two options:
>>>>>      >
>>>>>      > 1. have different representations of this value in XML and J=
SON,
>>>>>      >    analogically to instance indentifiers (sec. 6.11 in RFC 7=
951).
>>>>>      >
>>>>>      > 2. use a module name rather than a prefix in XML, too.
>>>>>      >
>>>>>      > I would suggest #2.
>>>>>  But that means making non-backwards compatible change to the X=
ML
>>>>> representation?
>>>> Not really. It means NETMOD WG would be creating its own special var=
iant of
>>>> XPath.
>>> The thing is that XPath is "XML Path Language", so using it outside X=
ML is
>>> problematic.
>> Not necessarily.  Section 5 of the XPath 1.0 spec defins the "data
>> model" where an XPath expression is applied.  We could make a formal
>> specification of how a YANG data tree maps to this data model (pretty
>> straightforward...).  I think experience from implementations over the
>> last 8 years show that this in fact works quite well.
> Except some parts that don't apply. For example, siblings nodes in XPat=
h
> are ordered, whereas in YANG 'foo[1]' may give unpredictable results.

Not all XPath expressions map to something meaningful in the context of=20
YANG data.=C2=A0 However a subset of them do.

IMO introducing yang:ypath1.0 makes sense but it is practical to define=20
it as a subset of yang:xpath1.0. Martins proposal 2) for an encoding=20
independent solution where the prefixes are restricted to be module=20
names works. Proposal 1) seems to be a step back clogging YANG with=20
encoding specific details.

Vladimir

>
> This is probably OK in YANG modules but not so much if XPath expression=
s
> are used as configuration data.
>
> Lada
>
>>
>> /martin
>>
>>
>>
>>> Lada
>>>
>>>>>      Hmm, so you mean change the leaf "stream-xpath-filter" to say:
>>>>>
>>>>>               o  The set of namespace declarations has one member f=
or each
>>>>>                  YANG module supported by the server.  This member =
maps
>>>>>                  from the YANG module name to the YANG module names=
pace.
>>>>>
>>>>>                  This means that in the XPath expression, the modul=
e name
>>>>>                  serves as the prefix.
>>>>>
>>>>>      .... and then also give an example of this.
>>>>>
>>>>>      This is probably what we need to do in all places where yang:x=
path1.0
>>>>>      is used, going forward.  Maybe even define a new type
>>>>>      yang:xpath1.0-2 (name?) with the set of namespace declarations
>>>>>      built-in.
>>>>
>>>> We should avoid making off-the-shelf implementations of standards li=
ke XPath
>>>> unusable.
>>>> At the very least this should be only available if the server suppor=
ts it
>>>> (with a capability URI)
>>>>
>>>>  =20
>>>>>  So we need an update to RFC7951?
>>>>>
>>>>> Regards,
>>>>> Reshad.
>>>>>
>>>>
>>>> Andy
>>>>  =20
>>>>>      /martin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      >
>>>>>      > Lada
>>>>>      >
>>>>>      > >
>>>>>      > > How is this supposed to work with JSON?
>>>>>      > >
>>>>>      > >
>>>>>      > > /martin
>>>>>      > >
>>>>>      > > _______________________________________________
>>>>>      > > netmod mailing list
>>>>>      > > netmod@ietf.org
>>>>>      > > https://www.ietf.org/mailman/listinfo/netmod
>>>>>      >
>>>>>      > --
>>>>>      > Ladislav Lhotka
>>>>>      > Head, CZ.NIC Labs
>>>>>      > PGP Key ID: 0xB8F92B08A9F76C67
>>>>>      >
>>>>>
>>>>>      _______________________________________________
>>>>>      netmod mailing list
>>>>>      netmod@ietf.org
>>>>>      https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>> --=20
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>


From nobody Mon Oct 15 13:28:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5840B130EC3 for ; Mon, 15 Oct 2018 13:28:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 D76lDWzELp9M for ; Mon, 15 Oct 2018 13:28:14 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A086130DE2 for ; Mon, 15 Oct 2018 13:28:14 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 7C1A42401B7 for ; Mon, 15 Oct 2018 22:28:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1539635291; bh=5laEnXvmYX509t1W9qrm64kfmH7xEP9fvigRH65UxM8=; h=Subject:References:From:To:Date:In-Reply-To; b=GHvqvjGiEXukWPBslva95QZZG7wEHDed6L+59K6KaGDgdvGABATt4qgVQXiB6oqnN v7wSQVD84hXXQJcnKU/XjEnC2InVqOceobKhKkb3b393lVSR0Cj/vGshnCEfpdz0iC ao4+ymKwMLSKIdEOCeIMAjgDpXPAz9c6jpnQ/tZ8=
References: <152029421633.12842.1970354425067689893@ietfa.amsl.com>
From: Robert Varga 
Openpgp: preference=signencrypt
To: netmod@ietf.org
Message-ID: <828a5858-f12e-aa7f-40af-c39679fd2cc9@hq.sk>
Date: Mon, 15 Oct 2018 22:28:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <152029421633.12842.1970354425067689893@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vs5nfXtnc4S6uu7jGNNlge2wHoUbl8BLI"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 20:28:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vs5nfXtnc4S6uu7jGNNlge2wHoUbl8BLI
Content-Type: multipart/mixed; boundary="LgZ3sucqeAXVrxAsmXewgKvZQeGI6l2qy";
 protected-headers="v1"
From: Robert Varga 
To: netmod@ietf.org
Message-ID: <828a5858-f12e-aa7f-40af-c39679fd2cc9@hq.sk>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt
References: <152029421633.12842.1970354425067689893@ietfa.amsl.com>
In-Reply-To: <152029421633.12842.1970354425067689893@ietfa.amsl.com>

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

On 06/03/2018 00:56, 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 Network Modeling WG of the IETF.
>=20
>         Title           : YANG Data Extensions
>         Authors         : Andy Bierman
>                           Martin Bjorklund
>                           Kent Watsen
> 	Filename        : draft-ietf-netmod-yang-data-ext-01.txt
> 	Pages           : 11
> 	Date            : 2018-03-05
>=20
> Abstract:
>    This document describes YANG mechanisms for defining abstract data
>    structures with YANG.  It is intended to replace and extend the
>    "yang-data" extension statement defined in RFC 8040.

Sorry to be a late reviewer on this.

To me "augment-yang-data" feels really like "augment a particular
instance of a schema tree", i.e. increasing specificity of augment
target node with knowledge on which tree instantiation it operates.

RFC7950 already does this (implicitly) for notification, rpc and action
statements by making them members of the schema tree and the same
"augment" and "deviation" mechanics for them being defined shared with
the data tree.

I would argue this problem from a different point of view.

I think the purpose of "augment-yang-data" would be much better
addressed with an extension usable within augment (and deviate) to
reference a particular schema tree instantiation.

What that means in terms of YANG metamodel is two-fold:

1) an extension statement can define a conceptual schema tree
instantiation -- very much like NMDA does, but applied not to datastore,
but to schema tree.

2) an augment (or deviation) statement can be restricted to operate on a
schema tree instantiation defined by an extension statement

Rough example:

    extension augmentable-statement;
    extension schematree-instance;

    extension yang-data {
        as:augmentable-statement;
    }

    yd:yang-data foo;

    augment /foo {
        // i.e. interpret argument as a target valid in the schema tree
        // as defined by yang-data, with the semantics specified therein
        si:schematree-instance "yd:yang-data";
    }

Note how as:schematree-instance is completely unnecessary here:
yang-data's use of as:augmentable-statement is already indicating that
the statement is augmentable, thus bridging it to RFC7950 section 7.19:

   An extension can allow refinement (see Section 7.13.2) and deviations
   (Section 7.20.3.2), but the mechanism for how this is defined is
   outside the scope of this specification.

hence the only extension that is needed for yang-data and future similar
extensions is augmentable-statement, simply because as soon as "augment"
argument touches an extension statement, you have to know something
about it. If an augment argument crosses an extension statement, it must
share fate with the parser's handling of the extension: if the parser
chooses to ignore the extension, it should reasonably also ignore the
augment statement.

Unless "augment" is not allowed to touch extension statements (i.e.
extensions must never define a schema tree member) -- if that is the
case, that should be normatively defined somewhere, too.

Regards,
Robert


--LgZ3sucqeAXVrxAsmXewgKvZQeGI6l2qy--

--vs5nfXtnc4S6uu7jGNNlge2wHoUbl8BLI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlvE+FsLHG5pdGVAaHEu
c2sACgkQJKB0S2uuNdvd1BAAjMNWS15u+cY1/zVv7KoyM7VUiWhcMl7dZsE4W7LQ
WXaFo6IKQu3fYst9gCb3FPiKYxLybvuAnKwbnJ2UMkedfFDYarZxAfB5XgcuG6D6
fFV/7+SJgs9RRpZNj34Og21G/2cKd65IQFd9OUS8FtZi8nlkwITs4WnOMU+of2Cz
1Yly09XzBfyxV4og0M9UQYDrImHRy+EhlBLpHOTexgxRquHIuym4GckWeRtnKfMJ
KM0xIcAe2m0Gmxt+NQLidoG0iqC5NXqz2/m9S5Z9RHHKrJJsqUI8Pk3EbKoZL9eO
z6TDld1unSRU2bKyRtpcPzCVo3g5klqaNmMKeUweTewcXZWI1TFAkraSqpsnLkzF
ZOh1duitmlyBjn9hsJTJ9ts9TqHspWNeMOXywEZJpf+vtHsQ45v4i/WzfO0XOUU6
eLWThSs364HB3trJbtVYuEFG/U7/N1i0FrjlxKXt64q5KNKA2oLIW2TlxVchOXKU
A1YyOkickpog34PDL5Fs6U82noMVWnjIEqhXnf/UPwDWSnMPV/cpGjyTCmxgxM9+
B9VjaXKeOjLNDisNZ6R1G716YiDgGN7RPiitnkHSFhpVOlm4aYHc7lmIkiyG7gr5
ze/Any6qenXzxwyJsa6ggr+1ZO5eAOgyq18qx1OFqr+ueqImY1sLkeDOUNE5/JHs
Cio=
=xSEF
-----END PGP SIGNATURE-----

--vs5nfXtnc4S6uu7jGNNlge2wHoUbl8BLI--


From nobody Mon Oct 15 14:27:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A30130ED9 for ; Mon, 15 Oct 2018 14:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 M6eFpITtkqHu for ; Mon, 15 Oct 2018 14:27:19 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0430130DEA for ; Mon, 15 Oct 2018 14:27:18 -0700 (PDT)
Received: from nitebug.localdomain (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 7652C24244E; Mon, 15 Oct 2018 23:27:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1539638836; bh=uL6N6TOb1G/hlt57yr2wUx6YRDw+AGeYi6hpI92ZQR8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TAVJOJq+pczPru2E1QcNF0WkOTF/aF5bVKGPGZVgPWscAKgwjPcUp3RViEtFsKveT 567rPotWmAbdO7kfvXf1wcAcPEKW7aHQBNDQW0miIqvMps+fSuRM3gg3Zzhw+gLdB4 s32tNDjMuZHJZOeQ/QqOHq0IWKWlzJtOz/9EPBO4=
To: Kent Watsen , Martin Bjorklund 
Cc: "netmod@ietf.org" 
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk> <20181015.210937.2105117531520960939.mbj@tail-f.com> <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk> <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>
From: Robert Varga 
Openpgp: preference=signencrypt
Message-ID: 
Date: Mon, 15 Oct 2018 23:27:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="54QKhzIOYaEMWrIwpDZcHrzQzToYQEEG4"
Archived-At: 
Subject: Re: [netmod] schematree-statement extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2018 21:27:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--54QKhzIOYaEMWrIwpDZcHrzQzToYQEEG4
Content-Type: multipart/mixed; boundary="fHuukgDuVSi4h4hjfSBEyY8H3e3eTkeFB";
 protected-headers="v1"
From: Robert Varga 
To: Kent Watsen , Martin Bjorklund 
Cc: "netmod@ietf.org" 
Message-ID: 
Subject: Re: [netmod] schematree-statement extension?
References: <4d793f08-4073-751e-105d-f83ce407611c@hq.sk>
 <20181015.210937.2105117531520960939.mbj@tail-f.com>
 <6a6a6411-9d60-3918-fdf7-f38a1220adc7@hq.sk>
 <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>
In-Reply-To: <8A1331E9-5707-4306-B873-00C97CC23AF1@juniper.net>

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

On 15/10/2018 21:49, Kent Watsen wrote:
> Hi Robert,
>=20
> Picking up on your YANG 1.2 comment.  Please add a YANG-next issue, if =
this
> is not being tracked already. https://github.com/netmod-wg/yang-next/is=
sues.

https://github.com/netmod-wg/yang-next/issues/53

I think I captured the gist of the issue, but let's fleshing out the
definition.

Regards,
Robert


--fHuukgDuVSi4h4hjfSBEyY8H3e3eTkeFB--

--54QKhzIOYaEMWrIwpDZcHrzQzToYQEEG4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

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

iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAlvFBjQLHG5pdGVAaHEu
c2sACgkQJKB0S2uuNdsMiw//Ugw2NcLrSclxwKmQ/kkuUPRZ46mAWeJqS3LCRpiv
XCJO7wU1l+2GRcaedHSWwVofTRSIi+/MxcrU3EtU7pcOjeIzoTcn7fz79e1IRoYZ
xov57dPUjKnh39ip0IyaiAvFcuCJ8Es3T9zzykwst3HTIZKnR6lI32KO8Xnd549q
PGlidkqCuxYr46rrtLeu3KJNjYs+WnMgklHJRF1edGNPvRWGB0fx5OJy1TKTE4E4
5lfTVd6TveRNby0umbDaH6/5lz5CfOqODOyDAA19oWhQsdd+JgrnafJYsQBRad1D
LnWK/suV46GzC/0IglCqoSm4xxonn5k8jvD3EL5rifh2R3GWOBk0NJBOevP6S0By
6MYYDVUkEAy8WQeJj1vHbGYO5gFT1V9bX6K5Jy0bcbtGm3QyK4WMtkaazy/lo5ou
0qoQxq+sJRpVhDLhtc6HU3deOD1jLkUelmaxOmmGnSjwLy1GkYtpgcEC5jgIAVdt
ib8mYzgT0CTE8qHiKYVWmjTfiLrvCQyyYEGhB/Nt+f5T9JMLkuZ1v0NNSJUNvyYO
+vx/i16qzgbHSrevkOJr7oaqwtOf1gD9Ku5uTBDIPf7CVLv3wQzJPFkMMUIL2HtC
yhu2FVGgBJRM/P+RhimpdLDUDV1bb5e6mF1KE6w2HABtlEyaG9tDGs7pxdLXkL9H
Oeo=
=8Nb+
-----END PGP SIGNATURE-----

--54QKhzIOYaEMWrIwpDZcHrzQzToYQEEG4--


From nobody Mon Oct 15 17:07:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE18126CC7; Mon, 15 Oct 2018 17:07:47 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zNCtULpxwJ8; Mon, 15 Oct 2018 17:07:45 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B8721124C04; Mon, 15 Oct 2018 17:07:44 -0700 (PDT)
X-AuditID: 12074424-4d5ff70000005ce9-4d-5bc52bcdf586
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 88.E5.23785.ECB25CB5; Mon, 15 Oct 2018 20:07:42 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w9G07dGh030722; Mon, 15 Oct 2018 20:07:40 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9G07Yfj027310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Oct 2018 20:07:36 -0400
Date: Mon, 15 Oct 2018 19:07:34 -0500
From: Benjamin Kaduk 
To: Martin Bjorklund 
Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com,  lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org
Message-ID: <20181016000733.GK19309@kduck.kaduk.org>
References: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> <20181010.153528.100217893480849067.mbj@tail-f.com> <20181011184852.GU3293@kduck.kaduk.org> <20181015.093309.2040803844255950012.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181015.093309.2040803844255950012.mbj@tail-f.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrHtO+2i0wZkeS4uJB+wtZvyZyGyx e95ldosDc9gtOprfslh0dz9jt1jdq2Yx/2IjqwOHx85Zd9k9liz5yeRxvekqu8eHTc1sHht/ LWYJYI3isklJzcksSy3St0vgymg7OYelYLJ9xeGXzewNjJ8Muhg5OSQETCQmvHjH1MXIxSEk sJhJ4mvrDBYIZyOjxMkZa9ggnKtMEktOv2cFaWERUJU4tWIhC4jNJqAi0dB9mRnEFgGKP9m5 FqybWWAdo8T9rllgDcICiRKTJsxlA7F5gfZ9nt4Pte8Jo8SrvmZmiISgxMmZT8CmMgtoSdz4 9xKoiAPIlpZY/o8DJMwp4Chx4/U+sJmiAsoSe/sOsU9gFJiFpHsWku5ZCN0LGJlXMcqm5Fbp 5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBIU/u4vKDsbuHu9DjAIcjEo8vD+uH4kWYk0s K67MPcQoycGkJMqrugcoxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ34TZQjjclsbIqtSgfJiXN waIkzjuxZXG0kEB6YklqdmpqQWoRTFaGg0NJgnee1tFoIcGi1PTUirTMnBKENBMHJ8hwHqDh t0FqeIsLEnOLM9Mh8qcYjTnanl6fwczRASKFWPLy81KlxHkfgZQKgJRmlObBTQOlMIns/TWv GMWBnhPmPQJSxQNMf3DzXgGtYgJa5W4L8kdxSSJCSqqB0Vhm9pmqBRrh140fplT8N595qvmf sYdOc43g/+b7f6NfmN+9tvhSVNDn/txTTW+TU7QYCldYJFXW/37N97Gt8+x8UaXrq/TPeMcv tlddvcggYa1LiYBke71wW7bRAtGN9Y/SlV6a7pzF+N5uQwXbrId7dr1OKvFfk1F+d6q83vT+ tx5H7/CmK7EUZyQaajEXFScCAE70AwQ8AwAA
Archived-At: 
Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 00:07:48 -0000

On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Benjamin Kaduk  wrote:
> > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Benjamin Kaduk  wrote:
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-netmod-schema-mount-11: No Objection
> > > > 
> > > > When responding, please keep the subject line intact and reply to all
> > > > email addresses included in the To and CC lines. (Feel free to cut this
> > > > introductory paragraph, however.)
> > > > 
> > > > 
> > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > 
> > > > 
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > 
> > > > 
> > > > 
> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------
> > > > 
> > > > Whenever we introduce a new namespace "sub-hierarchy" there is some level
> > > > of risk about surpirses with respect to the security properties of the
> > > > combined system.  I appreciate that the mounted schemas are "jailed" into
> > > > their own subtree except for the specific exceptions for XPath access,
> > > > which helps a lot.  But there may still be potential for surprise with
> > > > respect to, e.g., access control on mounted schemas, if an administrator
> > > > previously assumed that such controls would only be needed at the
> > > > top-level.  The document itself doesn't give me a great picture of to what
> > > > extent these risks and the possible consequences of the new nested
> > > > structure have been considered; I'd be happy to hear if they've been
> > > > thought about a lot already and the conclusion was that the situation is so
> > > > boring that nothing needs to be mentioned in the document.
> > > 
> > > The intention was that this is covered in Section 7, Interaction with
> > > the Network Configuration Access Control Model (NACM).
> > > 
> > > But it is probably a good idea to explicitly mention this in the
> > > Security Considerations section as well (together with your last point
> > > below).  So maybe add a paragraph at the end of Section 11:
> > > 
> > >   It is important to take the security considerations for all nodes in
> > >   the mounted schemas into account, and control access to these nodes
> > >   by using the mechanism described in Section 7.
> > 
> > I guess this addresses my concern; thanks.
> > 
> > > > Section 3.3
> > > > 
> > > >    If multiple mount points with the same name are defined in the same
> > > >    module - either directly or because the mount point is defined in a
> > > >    grouping and the grouping is used multiple times - then the
> > > >    corresponding "mount-point" entry applies equally to all such mount
> > > >    points.
> > > > 
> > > > Does this mean that the multiple mount points must serve the same
> > > > data/contents, or just that they must use the same schema?
> > > > (Is this related to "inline" vs. "shared-schema"?)
> > > 
> > > No, this document intentionally doesn't assume anything about the
> > > source of the instance data (as explained in section 1).  So the
> > > answer is that they just use the same schema.
> > > 
> > > > Section 3.4
> > > > 
> > > > So this means that there can be multiple
> > > > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> > > > locations in the hierarchy?  When I was first reading the document, the
> > > > design seemed fairly clean with just a single list of mount-points at the
> > > > "top-level" that tracks everything, but this kind of recursion seems like
> > > > it would make implementation potentially quite complex.  What kind of
> > > > implementation experience do we have that can replace my half-informed
> > > > suppositions about complexity?
> > > 
> > > I agree with you that multiple levels of mounting probably can be
> > > complex.  But there is nothing in the design of schema mount that
> > > prohibits this.  In fact, it "falls out for free" from the design.
> > > 
> > > A 2-level example is a physical device with LNEs
> > > (draft-ietf-rtgwg-lne-model) which has NIs
> > > (draft-ietf-rtgwg-ni-model).
> > > 
> > > > Section 4
> > > > 
> > > >    Therefore, schema mount also allows for such references.  For every
> > > >    mount point in the "shared-schema" case, it is possible to specify a
> > > >    leaf-list named "parent-reference" that contains zero or more XPath
> > > >    1.0 expressions.  [...]
> > > > 
> > > > editorial: """the "shared-schema" case""" reads oddly to me; it might be
> > > > clearer to refer to schemas mounted using "shared-schema" instead.  As in,
> > > > """For every mount point under "shared-schema", [...]"""
> > > 
> > > We use the wording "in the 'shared-schema' case" in a couple of
> > > places.  I don't think "mount point under 'shared-schema'" is
> > > correct.
> > 
> > Okay.
> > 
> > > > Can we get a reference added for XPath?
> > > 
> > > Sure, I will add this.
> > > 
> > > > It's still a little unclear to me exactly how a node in the mounted tree
> > > > constructs an XPath expression to refer to the parent-reference
> > > > nodes
> > > 
> > > It's rather the other way around.  If a node in the mounted schema has
> > > an XPath expression that refers to a node that is not part of the
> > > jailed mounted schema, that node can be brought in by the
> > > parent-reference expressions.   An example of this is given in A.3
> > > where an "outgoing-interface" (which is a reference to
> > > /if:interfaces/if:interface/if:name) works thanks to the
> > > parent-reference.
> > 
> > Sorry for being dense here.  Just to check -- the idea is that I have
> > an existing schema that has references to external nodes, and those
> > external references are represented as "absolute paths" from the root node.
> > When I mount that existing schema, because of the namespace jailing, it
> > goes looking for the external reference from that path but starting at the
> > mountpoint instead of the real root, and the referred-to node is only
> > present in the mounted hierarchy if the external module in question is also
> > part of the same mounted schema.  What the parent-reference is doing is
> > allowing this absolute-path external node reference to escape the mounted
> > hierarchy and find the corresponding nodes from the top-level.
> > So there's no new "construction" of XPath expressions; it's just allowing
> > existing references to continue to work.
> 
> Yes I think this is a correct description.
> 
> > Do we need to specify a search order when there are multiple levels of
> > hierarchical mounts and a referred-to external node is present at both the
> > top-level and an intermediate mount level?
> 
> Regarding parent refs, section 4 says:
> 
>    For the purposes of evaluating XPath
>    expressions within the mounted data tree, the union of all such
>    nodesets [from parent references] is added to the accessible data tree.
> 
> For example, if we have:
> 
>   A implements ietf-schema-mount and mounts B with some parent-refs Pb
>   B implements ietf-schema-mount and mounts C with some parent-refs Pc
> 
> The parent-refs Pc are XPath expressions in B.  So, applying section
> 4, it follows that before evaluating Pc, we need to add the result
> from evaluating Pb.
> 
> 
> And it doesn't really matter if a node is present at both the
> top-level and mounted, since the nodes from the parent reference
> statement are added to the accessible data tree.  The result can be a
> mix of nodes from the parent refs and the mounted tree.

Ah, I think I get it now.  Sorry for being so dense.

-Benjamin


From nobody Tue Oct 16 05:04:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5415A130DDE for ; Tue, 16 Oct 2018 05:04:24 -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] 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 7vS8EExTy312 for ; Tue, 16 Oct 2018 05:04:22 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDDB130DDB for ; Tue, 16 Oct 2018 05:04:22 -0700 (PDT)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id BA3BB6005B; Tue, 16 Oct 2018 12:04:21 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <1538612528590.11321@Aviatnet.com>
Date: Tue, 16 Oct 2018 08:04:19 -0400
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org>
References:  <1538612528590.11321@Aviatnet.com>
To: Alex Campbell 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 12:04:24 -0000

>=20
> On Oct 3, 2018, at 8:22 PM, Alex Campbell  =
wrote:
>=20
> The introduction does not explain what they are useful for

The second sentence of the abstract: "The expectation is for such tags =
to be used to help classify and organize modules." The introduction =
repeats this in the first sentence. I'm not sure how much differently we =
could say "Tags are useful for organizing and classifying modules". Are =
you asking for justification on the usefulness of organizing and =
classifying things? I think this concept is rather widely accepted.


> , it just makes a comparison to #hashtags (which is something I would =
expect to see in an April 1st RFC).

Using tags to help organize collections of data is literally ubiquitous: =
Movies/music/media, IP routes, and yes even social media are just a few =
examples.  Regarding April 1st, are you are unfairly restricting your =
perspective to only the ironic use of hashtags? Hashtags organically =
developed as a useful and widely used way for people and groups to add =
meta-data to their messages which then allowed other services to collect =
and present them in useful ways. Indeed businesses and other groups use =
hashtags for this purpose to great success. It was hardly a joke, and =
for many folks it is immediately useful to understand what is being =
proposed.

Thanks,
Chris.=


From nobody Tue Oct 16 05:31:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1CA130DDE for ; Tue, 16 Oct 2018 05: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] 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 zrNsYfCX8dQf for ; Tue, 16 Oct 2018 05:31:47 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2A130DC9 for ; Tue, 16 Oct 2018 05:31:46 -0700 (PDT)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E54C36005B; Tue, 16 Oct 2018 12:31:45 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de>
Date: Tue, 16 Oct 2018 08:31:43 -0400
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org>
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 12:31:50 -0000

On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder =
 wrote:
> Not ready, comments posted earlier here:
>=20
> =
https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg


Hi Re-quoting to keep the discussion on this thread.

> - What does this mean? In particular the second sentence makes me =
wonder.
>=20
>   Implementations MUST ensure that a modules tag list is consistent
>   across any location from which the list is accessible.  So if a user
>   adds a tag through configuration that tag should also be seen when
>   using any augmentation that exposes the modules tag list.

This text exists b/c originally the module tags list was being proposed =
to be accessible in 2 places, with a read-only version in a yang library =
augmentation. The WG decided that this read-only augmentation was not =
useful so we removed. It.  I'll remove this text as it's now more =
confusing than useful apparently. :)

> - Wording - suggest to remove 'types':
>=20
>    Tags may be IANA assigned or privately defined types.";

Done.

> - Leaf names:
>=20
>   module: ietf-module-tags
>       +--rw module-tags* [name]
>          +--rw name          yang:yang-identifier
>          +--rw tag*          string
>          +--rw masked-tag*   string
>=20
>   Name seems to refer to a module but this is not clear until you
>   read the description. I understand that in RFC 7895 and its bis we
>   also just use 'name' but I would find things easier to understand
>   if we would have this:
>=20
>   module: ietf-module-tags
>       +--rw module-tags* [module]
>          +--rw module        yang:yang-identifier
>          +--rw tags*         string
>          +--rw masked-tags*  string
>=20
>   Note that I also used plural for the leaf-lists.
>=20
>   In the description, I would also say "A list of tags associated
>   with..."  instead of "A tag associated with...".

I'll change it to module-name, and pluralize "tag" to "tags".

>=20
> - Editorial
>=20
>  s/This user/A user

Done

> - Adding and masking the same tag
>=20
>  What happens if config adds a tag and masks the same tag? Is the
>  masking taking priority in this case, i.e., you first all all tags
>  and then you filter those that are masked?

The mask takes precedence. I'll add text to clarify this.

> - Standard tags defined in description statements
>=20
>  I do not like this. YANG has extension statements and having to
>  parse stuff out of free text description statements seems to be a
>  movement backwards.

This is used by the human implementer of the module (i.e., they need to =
write code to implement the module). As such it was not intended for =
machine parsing.

> - System management
>=20
>  What is 'system management' and a 'system management protocol'?

These were derived from the work the RtgYangDT originally did where we =
were organizing everything under a single device tree. This tree concept =
was (rightly) abandoned to be replaced with use of tags. Examples of =
protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to =
the description.
=20
> - Tag format
>=20
>  Apparently, the colon has a special meaning in a tag string and
>  otherwise there do not seem to be any restrictions. (Which is good,
>  I can finally put various smileys on my gear.)
>=20
>  Should we state explicitly somewhere that a colon has a special
>  meaning and that tag strings are structured into a sequence of
>  'taggies' separated by colons? Or is definition by example good
>  enough?

I think it's good enough. :)

> - Meaning of tag masks
>=20
>  Do masks mean a complete string match or can I mask along the prefix
>  hierarchy, i.e., 'vendor:acme:' masks everything starting with
>  'vendor:acme:'?

Exact match, I've added text to clarify this.

>=20
> - Retrieval of the final list of tags
>=20
>  Once I have configured tags and masks, how do I obtain the resulting
>  tag list? Do I have to calculate this locally? Or will the final
>  list be found in the operational state datastore (i.e., the applied
>  config

No need to calculate locally, and yes the final list is found in =
operational state datastore.

The description of the "tags" list includes the following text:

             The operational view of this list will contain all
             user-configured tags as well as any predefined tags that
             have not been masked by the user using the masked-tag leaf
             list below.";

Thanks,
Chris.

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         





> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Oct 02, 2018 at 01:21:04PM -0700, joel jaeggli wrote:
>> This is start of a two week working group last-call for
>> draft-ietf-netmod-module-tags-02 a current netmod working group
>> document.
>>=20
>> You may review at:
>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>>=20
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd =
like
>> to see addressed once the document is a WG document.
>=20
> Not ready, comments posted earlier here:
>=20
> =
https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20


From nobody Tue Oct 16 05:46:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF3E130DC9; Tue, 16 Oct 2018 05:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux47fqLRb4hn; Tue, 16 Oct 2018 05:45:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4474A130DE1; Tue, 16 Oct 2018 05:45:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id A74611AE0498; Tue, 16 Oct 2018 14:45:46 +0200 (CEST)
Date: Tue, 16 Oct 2018 14:45:45 +0200 (CEST)
Message-Id: <20181016.144545.1184951335260453665.mbj@tail-f.com>
To: ekr@rtfm.com
Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181011.091817.1727547509052700274.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 12:45:51 -0000

Hi,

Eric Rescorla  wrote:
> That seems like it's going to have some pretty surprising consequences and
> at minimum needs more information in the Security Considerations.

Ok.  Howabout we add a paragraph to the end of the Security
Considerations section:

  Care must be taken when the "parent-reference" XPath expressions are
  constructed, since the result of the evaluation of these expressions
  is added to the accessible tree for any XPath expression found in
  the mounted schema.


/martin

> On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  wrote:
> 
> > Eric Rescorla  wrote:
> > > I'm sorry but I don't understand this.
> > >
> > > Does the externally visible behavior of any mounted module depend in any
> > > way on these XPATH references
> >
> > Yes, but note that these XPath expressions ("parent-reference") are
> > read-only (config false in the YANG model).  Thus they are set by the
> > implementation, and used to inform the operator about the environment
> > in which other XPath expressions are evaluated.
> >
> >
> > /martin
> >
> >
> > >
> > > -Ekr
> > >
> > >
> > >
> > >
> > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund  wrote:
> > >
> > > > Eric Rescorla  wrote:
> > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund 
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Eric Rescorla  wrote:
> > > > > > > Eric Rescorla has entered the following ballot position for
> > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > > >
> > > > > > > When responding, please keep the subject line intact and reply
> > to all
> > > > > > > email addresses included in the To and CC lines. (Feel free to
> > cut
> > > > this
> > > > > > > introductory paragraph, however.)
> > > > > > >
> > > > > > >
> > > > > > > Please refer to
> > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > > >
> > > > > > >
> > > > > > > The document, along with other ballot positions, can be found
> > here:
> > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > ----------------------------------------------------------------------
> > > > > > > DISCUSS:
> > > > > > >
> > > > ----------------------------------------------------------------------
> > > > > > >
> > > > > > > Rich version of this review at:
> > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > DETAIL
> > > > > > > S 4.
> > > > > > > >
> > > > > > > >      It is worth emphasizing that the nodes specified in
> > > > > > > >      "parent-reference" leaf-list are available in the mounted
> > > > schema
> > > > > > only
> > > > > > > >      for XPath evaluations.  In particular, they cannot be
> > accessed
> > > > > > there
> > > > > > > >      via network management protocols such as NETCONF
> > [RFC6241] or
> > > > > > > >      RESTCONF [RFC8040].
> > > > > > >
> > > > > > > What are the security implications of this XPath reference
> > outside
> > > > the
> > > > > > > mount jail? Specifically, how does it interact with the access
> > > > control
> > > > > > > for the enclosing module.
> > > > > >
> > > > > > There is no such interaction, since access control comes into play
> > > > > > when some external entity accesses the data through some management
> > > > > > protocol, and the nodes from the "parent-reference" expressions
> > cannot
> > > > > > be accessed via management protocols.
> > > > > >
> > > > > > The last sentence of the quoted paragraph was supposed to make this
> > > > > > clear, but it seems we might need some additional explanation?
> > > > > >
> > > > >
> > > > > Yes, I think so. I guess I'm not clear on what the XPath expressions
> > are
> > > > > for if they
> > > > > can't be accessed via the management protocols. How can they be used?
> > > >
> > > > These are XPath expressions defined in the YANG models themselves,
> > > > such as "must" expressions or "leafrefs".   The description of
> > > > "parent-reference" refer to them as:
> > > >
> > > >                [...] XPath
> > > >                expressions whose context nodes are defined in the
> > > >                mounted schema
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> >


From nobody Tue Oct 16 06:01:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB6A130DE4 for ; Tue, 16 Oct 2018 06:01:13 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.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 4bCuf0SS-nWp for ; Tue, 16 Oct 2018 06:01:06 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 BDFD0130DEA for ; Tue, 16 Oct 2018 06:00:57 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id o21-v6so16867178lfe.0 for ; Tue, 16 Oct 2018 06:00:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ECC8bNKU5bfg/6BBibCPR8ABG3AyrFNYpLu20hbVxs=; b=bx3FNqswjvDMIpi4XSCn9KlNvjk1Ik/UNGjWVt+QuzCFfooR0YR0kD4SfQUGK9xkWT L7G2cSreEIWfxqoOagZ3BzmFQ2WaaW5suDOyTWe2sO8jOa4KqXk16P02GvyY+28FIN6P VoZqcI/a+vBaXzG5h0N5/LPeGpJXwm9LP0rwzwKu6mvW77xBJ81tOsdVEP8qEkipF1cV jmxPDnm0ZZV6PuCv2AV0qVIqQHy9WO41EYOwK0ouRc1CIFlhNlKYPhU8F+5k0lMQ3Qwg kbqgZ3oAvEGliIMCRd1YnIMVPfjgXrZLOx68pXw0yPLYWYTWUsIYO2zVw8D5KIU5FZ0k Qw7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ECC8bNKU5bfg/6BBibCPR8ABG3AyrFNYpLu20hbVxs=; b=O0f69va7XvEw0TdJM8Vv1TbKEHme5fM+xDsxJ/JrZnxnGRJj1VLhOA8SRtjYbDcrLn g0u2VOMu5FrqgToBqljKnaPDLXsXpcZR6AB5revbe1wNNO2ICIQfypOvhYA4PE0enK9O nY6mIBLdTT++j9hQFX0bR6dec4fRru8VPAmHd7EMLv9Pk1wBkntKbvXypJk+UiOG+jZg GsPOqobGPhmQj4bfqd/fz/K5vORi0uOVI3Xk+n2kE/yyMjGWp7D8W0eGpXfBq6a/YHm2 ER9ZW5EDf3ooQQBZ6w4HI9tRzWiT5TTzHx2TKG5BDp4mRFOgxzCYoAkokRZYwDRq9LAC phwA==
X-Gm-Message-State: ABuFfohl/22JMzhhRiQPQb+e9C6+cX0lm85rgWaLTB4F5/vhSA2NdZSW CtORsZ1trFEZvbZb40YWxgw94kOiInkWB2PzusAF7w==
X-Google-Smtp-Source: ACcGV61NLNoGi1bytnEfjxkI/FL4lsmFyitfv8l8UN89fuelYcYQ5BTX1gx/Y8aOJDviRAOkZdrWC7/2n2ek2JPyong=
X-Received: by 2002:ac2:434d:: with SMTP id o13-v6mr13173301lfl.129.1539694855832;  Tue, 16 Oct 2018 06:00:55 -0700 (PDT)
MIME-Version: 1.0
References:  <20181011.091817.1727547509052700274.mbj@tail-f.com>  <20181016.144545.1184951335260453665.mbj@tail-f.com>
In-Reply-To: <20181016.144545.1184951335260453665.mbj@tail-f.com>
From: Eric Rescorla 
Date: Tue, 16 Oct 2018 06:00:18 -0700
Message-ID: 
To: =?UTF-8?Q?martin_bj=C3=B6rklund?= 
Cc: IESG , NetMod WG Chairs , NetMod WG ,  joel jaeggli , draft-ietf-netmod-schema-mount@ietf.org,  Kent Watsen , Lou Berger 
Content-Type: multipart/alternative; boundary="000000000000f20b6f0578582470"
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 13:01:13 -0000

--000000000000f20b6f0578582470
Content-Type: text/plain; charset="UTF-8"

I'm sorry, but I still don't think I understand the security impacts of
this well enough to know if this text is OK.

Can you provide a more detailed explanation of what XPath expressions can
and cannot do here? Happy to discuss live either on the phone or in BKK

-Ekr


On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  wrote:

> Hi,
>
> Eric Rescorla  wrote:
> > That seems like it's going to have some pretty surprising consequences
> and
> > at minimum needs more information in the Security Considerations.
>
> Ok.  Howabout we add a paragraph to the end of the Security
> Considerations section:
>
>   Care must be taken when the "parent-reference" XPath expressions are
>   constructed, since the result of the evaluation of these expressions
>   is added to the accessible tree for any XPath expression found in
>   the mounted schema.
>
>
> /martin
>
> > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund 
> wrote:
> >
> > > Eric Rescorla  wrote:
> > > > I'm sorry but I don't understand this.
> > > >
> > > > Does the externally visible behavior of any mounted module depend in
> any
> > > > way on these XPATH references
> > >
> > > Yes, but note that these XPath expressions ("parent-reference") are
> > > read-only (config false in the YANG model).  Thus they are set by the
> > > implementation, and used to inform the operator about the environment
> > > in which other XPath expressions are evaluated.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > -Ekr
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund 
> wrote:
> > > >
> > > > > Eric Rescorla  wrote:
> > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  >
> > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Eric Rescorla  wrote:
> > > > > > > > Eric Rescorla has entered the following ballot position for
> > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > > > >
> > > > > > > > When responding, please keep the subject line intact and
> reply
> > > to all
> > > > > > > > email addresses included in the To and CC lines. (Feel free
> to
> > > cut
> > > > > this
> > > > > > > > introductory paragraph, however.)
> > > > > > > >
> > > > > > > >
> > > > > > > > Please refer to
> > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > > > for more information about IESG DISCUSS and COMMENT
> positions.
> > > > > > > >
> > > > > > > >
> > > > > > > > The document, along with other ballot positions, can be found
> > > here:
> > > > > > > >
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > > > > DISCUSS:
> > > > > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > > > >
> > > > > > > > Rich version of this review at:
> > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > DETAIL
> > > > > > > > S 4.
> > > > > > > > >
> > > > > > > > >      It is worth emphasizing that the nodes specified in
> > > > > > > > >      "parent-reference" leaf-list are available in the
> mounted
> > > > > schema
> > > > > > > only
> > > > > > > > >      for XPath evaluations.  In particular, they cannot be
> > > accessed
> > > > > > > there
> > > > > > > > >      via network management protocols such as NETCONF
> > > [RFC6241] or
> > > > > > > > >      RESTCONF [RFC8040].
> > > > > > > >
> > > > > > > > What are the security implications of this XPath reference
> > > outside
> > > > > the
> > > > > > > > mount jail? Specifically, how does it interact with the
> access
> > > > > control
> > > > > > > > for the enclosing module.
> > > > > > >
> > > > > > > There is no such interaction, since access control comes into
> play
> > > > > > > when some external entity accesses the data through some
> management
> > > > > > > protocol, and the nodes from the "parent-reference" expressions
> > > cannot
> > > > > > > be accessed via management protocols.
> > > > > > >
> > > > > > > The last sentence of the quoted paragraph was supposed to make
> this
> > > > > > > clear, but it seems we might need some additional explanation?
> > > > > > >
> > > > > >
> > > > > > Yes, I think so. I guess I'm not clear on what the XPath
> expressions
> > > are
> > > > > > for if they
> > > > > > can't be accessed via the management protocols. How can they be
> used?
> > > > >
> > > > > These are XPath expressions defined in the YANG models themselves,
> > > > > such as "must" expressions or "leafrefs".   The description of
> > > > > "parent-reference" refer to them as:
> > > > >
> > > > >                [...] XPath
> > > > >                expressions whose context nodes are defined in the
> > > > >                mounted schema
> > > > >
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > >
>

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


I'm sorry, but I still don't think I understa=
nd the security impacts of this well enough to know if this text is OK.

Can you provide a more detailed explanation of what X=
Path expressions can and cannot do here? Happy to discuss live either on th=
e phone or in BKK

-Ekr


On Tue, Oct 16, 2018 at =
5:45 AM Martin Bjorklund <mbj@tail-f.c=
om> wrote:
Hi,



Eric Rescorla <ekr@rtf=
m.com> wrote:

> That seems like it's going to have some pretty surprising conseque=
nces and

> at minimum needs more information in the Security Considerations.



Ok.=C2=A0 Howabout we add a paragraph to the end of the Security

Considerations section:



=C2=A0 Care must be taken when the "parent-reference" XPath expre=
ssions are

=C2=A0 constructed, since the result of the evaluation of these expressions=


=C2=A0 is added to the accessible tree for any XPath expression found in
=C2=A0 the mounted schema.





/martin



> On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> 

> > Eric Rescorla <ekr@rtfm.com> wrote:

> > > I'm sorry but I don't understand this.

> > >

> > > Does the externally visible behavior of any mounted module d=
epend in any

> > > way on these XPATH references

> >

> > Yes, but note that these XPath expressions ("parent-referenc=
e") are

> > read-only (config false in the YANG model).=C2=A0 Thus they are s=
et by the

> > implementation, and used to inform the operator about the environ=
ment

> > in which other XPath expressions are evaluated.

> >

> >

> > /martin

> >

> >

> > >

> > > -Ekr

> > >

> > >

> > >

> > >

> > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund <mbj@tail-f.com> wrote:<=
br>
> > >

> > > > Eric Rescorla <ekr@rtfm.com> wrote:

> > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund &=
lt;mbj@tail-f.com&g=
t;

> > wrote:

> > > > >

> > > > > > Hi,

> > > > > >

> > > > > > Eric Rescorla <ekr@rtfm.com> wrote:

> > > > > > > Eric Rescorla has entered the following =
ballot position for

> > > > > > > draft-ietf-netmod-schema-mount-11: Discu=
ss

> > > > > > >

> > > > > > > When responding, please keep the subject=
 line intact and reply

> > to all

> > > > > > > email addresses included in the To and C=
C lines. (Feel free to

> > cut

> > > > this

> > > > > > > introductory paragraph, however.)

> > > > > > >

> > > > > > >

> > > > > > > Please refer to

> > > > > > https://www.i=
etf.org/iesg/statement/discuss-criteria.html

> > > > > > > for more information about IESG DISCUSS =
and COMMENT positions.

> > > > > > >

> > > > > > >

> > > > > > > The document, along with other ballot po=
sitions, can be found

> > here:

> > > > > > > h=
ttps://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

> > > > > > >

> > > > > > >

> > > > > > >

> > > > > > >

> > > > -------------------------------------------------------=
---------------

> > > > > > > DISCUSS:

> > > > > > >

> > > > -------------------------------------------------------=
---------------

> > > > > > >

> > > > > > > Rich version of this review at:

> > > > > > > https://mozphab-ie=
tf.devsvcdev.mozaws.net/D3506

> > > > > > >

> > > > > > >

> > > > > > >

> > > > > > > DETAIL

> > > > > > > S 4.

> > > > > > > >

> > > > > > > >=C2=A0 =C2=A0 =C2=A0 It is worth emp=
hasizing that the nodes specified in

> > > > > > > >=C2=A0 =C2=A0 =C2=A0 "parent-re=
ference" leaf-list are available in the mounted

> > > > schema

> > > > > > only

> > > > > > > >=C2=A0 =C2=A0 =C2=A0 for XPath evalu=
ations.=C2=A0 In particular, they cannot be

> > accessed

> > > > > > there

> > > > > > > >=C2=A0 =C2=A0 =C2=A0 via network man=
agement protocols such as NETCONF

> > [RFC6241] or

> > > > > > > >=C2=A0 =C2=A0 =C2=A0 RESTCONF [RFC80=
40].

> > > > > > >

> > > > > > > What are the security implications of th=
is XPath reference

> > outside

> > > > the

> > > > > > > mount jail? Specifically, how does it in=
teract with the access

> > > > control

> > > > > > > for the enclosing module.

> > > > > >

> > > > > > There is no such interaction, since access co=
ntrol comes into play

> > > > > > when some external entity accesses the data t=
hrough some management

> > > > > > protocol, and the nodes from the "parent=
-reference" expressions

> > cannot

> > > > > > be accessed via management protocols.

> > > > > >

> > > > > > The last sentence of the quoted paragraph was=
 supposed to make this

> > > > > > clear, but it seems we might need some additi=
onal explanation?

> > > > > >

> > > > >

> > > > > Yes, I think so. I guess I'm not clear on what=
 the XPath expressions

> > are

> > > > > for if they

> > > > > can't be accessed via the management protocols=
. How can they be used?

> > > >

> > > > These are XPath expressions defined in the YANG models =
themselves,

> > > > such as "must" expressions or "leafrefs&=
quot;.=C2=A0 =C2=A0The description of

> > > > "parent-reference" refer to them as:

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
[...] XPath

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
expressions whose context nodes are defined in the

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
mounted schema

> > > >

> > > >

> > > >

> > > > /martin

> > > >

> >




--000000000000f20b6f0578582470--


From nobody Tue Oct 16 06:08:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25A130DE2 for ; Tue, 16 Oct 2018 06:08:37 -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 canCZ4CMDMYs for ; Tue, 16 Oct 2018 06:08:34 -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 B844F130DC9 for ; Tue, 16 Oct 2018 06:08:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 00847E71; Tue, 16 Oct 2018 15:08:32 +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 oNn5o0w0zvXd; Tue, 16 Oct 2018 15:08: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; Tue, 16 Oct 2018 15:08:31 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3D2220037; Tue, 16 Oct 2018 15:08:31 +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 8TMxR_qDzuvj; Tue, 16 Oct 2018 15:08:31 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5D17220036; Tue, 16 Oct 2018 15:08:31 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 16 Oct 2018 15:08:30 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 378B8300222ACC; Tue, 16 Oct 2018 15:08:29 +0200 (CEST)
Date: Tue, 16 Oct 2018 15:08:29 +0200
From: Juergen Schoenwaelder 
To: Christian Hopps 
CC: joel jaeggli , NETMOD Working Group 
Message-ID: <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , joel jaeggli , NETMOD Working Group 
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 13:08:38 -0000

On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
> 
> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder  wrote:

> > - Standard tags defined in description statements
> > 
> >  I do not like this. YANG has extension statements and having to
> >  parse stuff out of free text description statements seems to be a
> >  movement backwards.
> 
> This is used by the human implementer of the module (i.e., they need to write code to implement the module). As such it was not intended for machine parsing.
>

I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.

> > - System management
> > 
> >  What is 'system management' and a 'system management protocol'?
> 
> These were derived from the work the RtgYangDT originally did where we were organizing everything under a single device tree. This tree concept was (rightly) abandoned to be replaced with use of tags. Examples of protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to the description.
>

I am generally not a fan of definition by example. Is SSH a 'system
management protocol'?

> > - Tag format
> > 
> >  Apparently, the colon has a special meaning in a tag string and
> >  otherwise there do not seem to be any restrictions. (Which is good,
> >  I can finally put various smileys on my gear.)
> > 
> >  Should we state explicitly somewhere that a colon has a special
> >  meaning and that tag strings are structured into a sequence of
> >  'taggies' separated by colons? Or is definition by example good
> >  enough?
> 
> I think it's good enough. :)

I am not convinced this will work well. My understanding is that other
'hashtags' also have restrictions - whitespace and punctuation
characters are often excluded, it seems. Apparently ':' already means
something special here. Should you later need more special meanings,
you will love to have characters available that you can use. What
about tags that include whitespace or control characters? Do we really
want such tags?

> > - Meaning of tag masks
> > 
> >  Do masks mean a complete string match or can I mask along the prefix
> >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
> >  'vendor:acme:'?
> 
> Exact match, I've added text to clarify this.

OK. One obvious extension is then to have at some point in time tag
match expressions, such as 'vendor:acme:*' (assuming that * is not
a valid character for a tag, see above).

/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 16 06:26:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB2130DC9 for ; Tue, 16 Oct 2018 06:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 BiZWqQ9Dbi8y for ; Tue, 16 Oct 2018 06:26:31 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C3212D4EE for ; Tue, 16 Oct 2018 06:26:29 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE4.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 16 Oct 2018 16:26:27 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE4.corp.amdocs.com (10.237.241.95) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 16 Oct 2018 16:26:27 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Tue, 16 Oct 2018 16:26:27 +0300
Received: from ILRNAEXCHEDGE01.corp.amdocs.com (10.233.34.167) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Tue, 16 Oct 2018 16:26:27 +0300
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Tue, 16 Oct 2018 16:26:27 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3fl4hEi+PLGjsP24GQh7lc+IYydMl6lFJLXNN8M7tk0=; b=hJx2ueDDNM4KsIW/VRGaY4LDkCa/QbUcOlE2Q8Mb98bBE8zNUQloIGqWpW1JijZFi7iZfL96PBcdZUw+poZJvObC5LBT/Azk7ajCUUvgqiffgCyY4YF0v7m8UpqSuWpnDTeXZQBsaARhHFvqgqsRwoWHpEJ5XU70DlejiZb1e+g=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4515.eurprd06.prod.outlook.com (20.178.16.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.24; Tue, 16 Oct 2018 13:26:26 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.027; Tue, 16 Oct 2018 13:26:26 +0000
From: Michael Rehder 
To: Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoAAPS9MgABQPKNg
Date: Tue, 16 Oct 2018 13:26:25 +0000
Message-ID: 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB4515; 6:p7SF8PHK8GRUf5uSYmIUVM50RHjNrH3pDzSp0NzFgqyVKtbSkkuOiYrRlIqCtoTlVGF+oYsLMlVBzAnmipo003A1gXU/MLkLvh+AZvXwTPxMQXxWFf4PF0F9wlR3jYtOVBaBNsc0RUFg4zQ08xkieQrCNnG1uUfZI7/Qtq1w/TBcw54fDsvGwmocCfL/J0TwiXS+/y2AsGCSfGF4rbsXuWr46FrZidZL2ERfj9hBI5rHvhcjvrYJps+ICSSg0Dv5ZbVmN8fQtgj+8Mv2haoi/8qJzghAJJkuiukSca9AMsZdNrWp3H5HhJXnJ6e+KGwzYsWz0lf6om8cldt5fxPSVZQGM41NlM7o9jngFl/e1kSu65YCYXImipCFaez694ohahx2QvyGta+XUu5mUNG+LR5w+Q2/BHn1wI2R0bs4qEG8KJA3qqrWqFt34yPeeptaY/LHG83jVtiFJAidvtLnMQ==; 5:B+W+zzLB3BtkAmWSCWgflZhavbT8nEIXlQYDm8dQPbg7sAmhJ56Xbj+kutQEBMEJJML/Z1FIG+BaBQjy8yMyDpPE1lOj9OklX3pyD61Goy6g9H2I5Mb+F3Pfyh0RIE+asa6sg3TMmoAUGDvG2BU4yspnrUeF3O0nlrkB8Xd8vlE=; 7:58q+nSip8CQ3SJscJj8LFyVi6dImuF8x1nsoxL72yGQ4+JrFmdykQtU5GQPAwSmV2dzbJzEzLVV1AB7Kw92vjXeX83JtZBvgpncha/6W2A8q7uPZzRGN/3yh6QgZC1U6Wdy+blj9tHwvQN3+4p0Kg96FxjoS/7hbizEmsx2FQAWp41+iStHP3Ane7059UxjAQnEuvM8uxdjvTg0Ksvm2lr56YsIaIMa90+Jr7prIP/BFTwAbYjjzFlY6aLcGqtaZ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f38d0178-bd35-413e-4d64-08d6336af935
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4515; 
x-ms-traffictypediagnostic: AM0PR06MB4515:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166566539817055);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991067); SRVR:AM0PR06MB4515; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4515; 
x-forefront-prvs: 0827D7ACB9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(366004)(396003)(39860400002)(199004)(189003)(13464003)(5250100002)(66066001)(33656002)(99286004)(76176011)(2906002)(7696005)(2900100001)(102836004)(53546011)(6506007)(478600001)(72206003)(97736004)(14454004)(86362001)(68736007)(3846002)(93886005)(6116002)(71190400001)(71200400001)(316002)(6246003)(9686003)(53936002)(476003)(8936002)(486006)(446003)(11346002)(229853002)(186003)(5660300001)(6306002)(55016002)(6916009)(25786009)(81166006)(6436002)(256004)(8676002)(305945005)(74316002)(26005)(7736002)(4326008)(106356001)(81156014)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4515; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fIseJG/SO8VWykhA07bG4C0vZMPftdcdQ4lv3vyOCDkm1NdbdRAMMIsZq7JDS5Asbqm89PNq+XYmZx93GChjtWRkR/Mj4GLfm/o4zaBKxFLI3PIm+/Iyi42Ylafax7yv6NeBjbanQJewWElfRW98weSnhpBDkQ0gTRu1Rhm1/suX0q48XHBWsnH8DAyToi74c3NjokQHWUyZd45vsrpLkUqYCtKTLP/MQcTzqDQDSFWUpIdRFj2p9c4boZKV0KiupOvvnQcpvNTlUi6WTVe8w78KMoGGZfTycOS8Mmc3velJ8Cj0EKSmZIR98x932FODgSaAp8MsEdQ9I7pdaFUm5Zz1Pc0QAM2v0cvSemE0BzQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f38d0178-bd35-413e-4d64-08d6336af935
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 13:26:25.8883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4515
X-OriginatorOrg: amdocs.com
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 13:26:38 -0000

SSd2ZSByZWFkIHJmYzYxMTAgYW5kIEkgZGlkbid0IHNlZSBhbnkgbWVudGlvbiBvZiAiV0hFTiIg
b24gdGhlIG1hbmRhdG9yeSBzdGF0dXMgKHNlY3Rpb24gOS4xLjEgT3B0aW9uYWwgYW5kIE1hbmRh
dG9yeSBOb2RlcyBkb2Vzbid0IGxpc3QgaXQgd2hpY2ggc2VlbXMgYSBiaXQgb2RkIHRvIG1lKS4N
ClRoZSBzZWN0aW9uIG9uICJXSEVOIiBqdXN0IG1lbnRpb25zIHRoZSB4cGF0aCBtYXBwaW5nLCBu
b3QgYW55dGhpbmcgYWJvdXQgY2hhbmdpbmcgdGhlIG1hbmRhdG9yeSBzdGF0dXMgb2YgdGhlIGVu
Y2xvc2luZyBub2RlLg0KDQpJIHN0aWxsIHRoaW5rIHRoYXQgdGhlIFlBTkcgUkZDIHdvcmRpbmcg
b2YgImNvbmRpdGlvbmFsIiBuZWVkcyB0byBpbmRpY2F0ZSBpZiB0aGUgbm9kZSBpcyBtYW5kYXRv
cnkgc3RhdHVzIGlzIGFmZmVjdGVkIG9yIG5vdC4NCk5vdGUgdGhhdCByZmM2MDYwICIzLjEgTWFu
ZGF0b3J5IE5vZGVzIiBkb2Vzbid0IG1lbnRpb24gIldIRU4iIChpdCBkb2VzIG1lbnRpb24gcHJl
c2VuY2UpLg0KDQpUaGFua3MNCk1pa2UNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlXQ0KPiBTZW50OiBTYXR1cmRheSwgT2N0b2JlciAxMywgMjAxOCA1OjIw
IFBNDQo+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT4NCj4g
Q2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1l
bnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QNCj4gZW5zdXJlIHByZXNlbmNlIG9m
IHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+IA0KPiBPbiBGcmksIE9jdCAxMiwgMjAxOCBhdCAwNDow
ODo0OFBNICswMDAwLCBNaWNoYWVsIFJlaGRlciB3cm90ZToNCj4gDQo+ID4gVGhlIG1hbmRhdG9y
eSBzdGF0ZW1lbnQgaW4gdGhhdCBjYXNlIGlzIGlnbm9yZWQgKEnigJl2ZSBwb2ludGVkIG91dCB0
aGUNCj4gPiBSTkcgYW5kIFNjaGVtYXRyb24gbGFjayBvZiBlbmZvcmNlbWVudCkuICBXSEVOIHRy
dW1wcyB0aGUgbWFuZGF0b3J5DQo+ID4gc3RhdHVzICh2aWEgZXhwbGljaXQgbWFuZGF0b3J5IG9y
IGltcGxpY2l0IG1hbmRhdG9yeSB2aWEgbWluLWVsZW1lbnRzDQo+ID4gMSkNCj4gDQo+IEhhcyB0
aGUgUk5HIGFuZCBTY2hlbWF0cm9uIGJlZW4gb2J0YWluZWQgZm9sbG93aW5nIFJGQyA2MTEwPyBJ
ZiBzbywgdGhpcyBtYXkNCj4gYmUgYSBwcm9ibGVtIHdpdGggUkZDIDYxMTAgYnV0IG5vdCB3aXRo
IFlBTkcgaXRzZWxmLiBUaGVyZSBhcmUgdmFsaWRhdG9ycyB0aGF0DQo+IGRvIG5vdCB1c2UgUk5H
IG9yIFNjaGVtYXRyb24uDQo+IA0KPiAvanMNCj4gDQo+IC0tDQo+IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiAr
NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdl
cm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFj
b2JzLXVuaXZlcnNpdHkuZGUvPg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2Vk
IG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1h
aWxzIHNlbnQgdG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3Vj
aCBzeXN0ZW0gYW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBz
dWNoIHN5c3RlbSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8g
QW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBh
bmQgc3VjaCBwcm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uCg==


From nobody Tue Oct 16 06:41:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52369130DE4 for ; Tue, 16 Oct 2018 06:41:37 -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, DKIMWL_WL_MED=-0.001, 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 NxhKRQc9Hn-D for ; Tue, 16 Oct 2018 06:41:35 -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 78D40130DE1 for ; Tue, 16 Oct 2018 06:41:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8521; q=dns/txt; s=iport; t=1539697294; x=1540906894; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=F2TdxYsowfzTodnT6YX0JK80h8MYUbG7i2obBLWj0Jo=; b=lfnM+O7SyEVJKHidBD4cUrtbcYSOPpNGTgwmCWJGv/o9K0rr+EK4fMj1 0f96K9jb3eoRYebt5HSFm20kwDE9fDGG6zHTCCZVmBC8/hr/gjtEDFqrm bKraaPoBOxPCKxcllw/4gU0pTSOR3e4iTBe//o+dqXQohdDaN/NsBXmuH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAAu6cVb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWBDYFdbRIog3WIdo1ckT+FXIFmDRgBCoQDRgKFBzg?= =?us-ascii?q?WAQMBAQIBAQJtHAyFOQEBAQECAQEBIUsLDAICCxABBAEBASMEAwICGwwfCQg?= =?us-ascii?q?GAQwGAgEBgxwBgXkID6YCgS4fhRuEYQUFi16BQT+BEieCa4MbAQGBLgELBwE?= =?us-ascii?q?lGyaCPIJXAp4qCZBVBheBT4deJoZLj3aGN4FaIWRxMxoIGxU7gmyCToNphGG?= =?us-ascii?q?FPz4wiSwCDRcHgiABAQ?=
X-IronPort-AV: E=Sophos;i="5.54,388,1534809600"; d="scan'208,217";a="7285016"
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; 16 Oct 2018 13:41:32 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9GDfVtV026070; Tue, 16 Oct 2018 13:41:32 GMT
To: Michael Rehder , Juergen Schoenwaelder 
Cc: "netmod@ietf.org" 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de> 
From: Robert Wilton 
Message-ID: <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com>
Date: Tue, 16 Oct 2018 14:41:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5352D69A5CA7578E7AD44A25"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 13:41:38 -0000

This is a multi-part message in MIME format.
--------------5352D69A5CA7578E7AD44A25
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mike,


On 16/10/2018 14:26, Michael Rehder wrote:
> I've read rfc6110 and I didn't see any mention of "WHEN" on the mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't list it which seems a bit odd to me).
> The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node.
>
> I still think that the YANG RFC wording of "conditional" needs to indicate if the node is mandatory status is affected or not.
> Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it does mention presence).
By YANG RFC do you mean RFC 6020/7950?

Section 8.1 of RFC 7950 states the following constraints apply on valid 
data trees:

    o  There MUST be no nodes tagged with "when" present if the "when"
       condition evaluates to "false" in the data tree.

    o  The "mandatory" constraint is enforced for leafs and choices,
       unless the node or any of its ancestors has a "when" condition or
       "if-feature" expression that evaluates to "false".

    o  The "min-elements" and "max-elements" constraints are enforced for
       lists and leaf-lists, unless the node or any of its ancestors has
       a "when" condition or "if-feature" expression that evaluates to
       "false".

These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements".

Thanks,
Rob
  

>
> Thanks
> Mike
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: Saturday, October 13, 2018 5:20 PM
>> To: Michael Rehder 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> ensure presence of the mandatory object
>>
>> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
>>
>>> The mandatory statement in that case is ignored (I’ve pointed out the
>>> RNG and Schematron lack of enforcement).  WHEN trumps the mandatory
>>> status (via explicit mandatory or implicit mandatory via min-elements
>>> 1)
>> Has the RNG and Schematron been obtained following RFC 6110? If so, this may
>> be a problem with RFC 6110 but not with YANG itself. There are validators that
>> do not use RNG or Schematron.
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
> “Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------5352D69A5CA7578E7AD44A25
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Mike,

    

    
On 16/10/2018 14:26, Michael Rehder
      wrote:

    

    

      
I've read rfc6110 and I didn't see any mention of "WHEN" on the mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't list it which seems a bit odd to me).
The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node.

I still think that the YANG RFC wording of "conditional" needs to indicate if the node is mandatory status is affected or not.
Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it does mention presence).

    

    By YANG RFC do you mean RFC 6020/7950?

    
Section 8.1 of RFC 7950 states the following constraints apply on
      valid data trees:

    
   o  There MUST be no nodes tagged with "when" present if the "when"
      condition evaluates to "false" in the data tree.



    
   o  The "mandatory" constraint is enforced for leafs and choices,
      unless the node or any of its ancestors has a "when" condition or
      "if-feature" expression that evaluates to "false".

   o  The "min-elements" and "max-elements" constraints are enforced for
      lists and leaf-lists, unless the node or any of its ancestors has
      a "when" condition or "if-feature" expression that evaluates to
      "false".

These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements".

Thanks,
Rob
 



    

      

Thanks
Mike


      

        
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Saturday, October 13, 2018 5:20 PM
To: Michael Rehder <Michael.Rehder@Amdocs.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
ensure presence of the mandatory object

On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:



        

          
The mandatory statement in that case is ignored (I’ve pointed out the
RNG and Schematron lack of enforcement).  WHEN trumps the mandatory
status (via explicit mandatory or implicit mandatory via min-elements
1)


        

        
Has the RNG and Schematron been obtained following RFC 6110? If so, this may
be a problem with RFC 6110 but not with YANG itself. There are validators that
do not use RNG or Schematron.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


      

      
“Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    

  


--------------5352D69A5CA7578E7AD44A25--


From nobody Tue Oct 16 07:20:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E017130DE8 for ; Tue, 16 Oct 2018 07:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BtWL-5_GqI for ; Tue, 16 Oct 2018 07:20:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 128FF130DE4 for ; Tue, 16 Oct 2018 07:20:34 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A6621AE0498 for ; Tue, 16 Oct 2018 16:20:33 +0200 (CEST)
Date: Tue, 16 Oct 2018 16:20:32 +0200 (CEST)
Message-Id: <20181016.162032.2229087452409342445.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] mbj's WGLC review of module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 14:20:36 -0000

Hi,

Here are my (mostly editorial) WGLC comments on
draft-ietf-netmod-module-tags-02:


o  add boilerplate reference to RFC 8340

o  2

  Use 8174 boilerplate


o  4.1

    A module definition SHOULD indicate a set of tags to be automatically
    added by the module implementer.

  I think statement doesn't belong here, but rather to section 7
  (which also has this statement already)

  And how are the tags supposed to be "automatically added"?

  As I have written in previous discussions, and others as well, I
  think that you should define a YANG extension that can be used to
  define the tags, instead of relying on description statements.  Is
  there a reason why you think an extension statement wouldn't work?

o  4.1


  OLD:

   If the module definition will be
   standard the tags MUST also be standard tags (Section 3.1).

  NEW:

   If the module definition will be
   IETF standards track, the tags MUST also be IETF standard tags
   (Section 3.1).


o  4.3

    Implementations MUST ensure that a modules tag list is consistent
    across any location from which the list is accessible.  So if a user
    adds a tag through configuration that tag should also be seen when
    using any augmentation that exposes the modules tag list.

  I don't understand the last sentence.  What kind of augmentation do
  you mean?



o  5.1

  OLD:

    The tree associated with the tags module is:

  NEW:

    The tree associated with the "ietf-module-tags" module is:


o  5.1

  I know this has been discussed before, and Juergen wanted plural
  names, but I propose the following structure:

       +--rw module-tags
          +--rw module* [name]
             +--rw name          yang:yang-identifier
             +--rw tag*          string
             +--rw masked-tag*   string


  I prefer a container an the top level over a list.  Also with the
  list called "module", the key can be called just "name".  And
  leaf-lists (and lists) usually have names in singular.


o  5.2

 I think the YANG version should be 1.1.

 Add the standard boilerplate to the YANG module.


o  5.2 leaf name

            "The YANG module or submodule name.";

  Do we really want to attach tags to submodules, or should the tags
  only be visisble for the module?


o  5.2  type for tag

    leaf-list tag {
        type string;

  Can I use *any* string as a tag?  No limitations at all?  Is ":"
  special in a tag?


o  5.2

  The module should be consistently formatted wrt whitespaces.

  (e.g., you can try pyang --keep-comments -f yang)


o  6

  s/yang/YANG/


o  6 and 3.3

  When I read 3.3 I thought that the word "local" seemed odd, and was
  going to suggest "user" instead.  It seems 8199 also uses
  standard/vendor/user.  So, I suggest we change "local tags" to "user
  tags".


o  7.1

   The module writer may use existing standard tags, or use new tags
   defined in the model definition, as appropriate.  New tags should be
   assigned in the IANA registry defined below, see Section 8.2 below.

  Hmm, once the "new" tags are defined, they are IETF standard tags,
  right?  So this text should really be:

   The module writer must use only IETF standard tags

  and also write that if new tags are needed, they MUST be
  registered.


o  8.2

  Remove the Editor's note.


o  8.2

  Why have both ietf:rfc8199:service and ietf:network-service?


o  References

  You need to add RFC 7950 as a normative ref since you define a YANG
  module.



/martin


From nobody Tue Oct 16 08:35:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1B4130DE9 for ; Tue, 16 Oct 2018 08:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level: 
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 Iu-GATYSQySm for ; Tue, 16 Oct 2018 08:35:04 -0700 (PDT)
Received: from mx1.amdocs.com (ramail1.amdocs.com [193.43.244.133]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9277130DC5 for ; Tue, 16 Oct 2018 08:35:02 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE1.corp.amdocs.com) ([10.224.0.130]) by ilmail01.corp.amdocs.com with ESMTP; 16 Oct 2018 18:34:53 +0300
Received: from ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) by ILHFDAGDRFE1 (10.237.240.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 16 Oct 2018 18:34:53 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS01.corp.amdocs.com (10.232.216.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Tue, 16 Oct 2018 18:34:52 +0300
Received: from ILRNAEXCHEDGE01.corp.amdocs.com (10.233.34.167) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Tue, 16 Oct 2018 18:34:52 +0300
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Tue, 16 Oct 2018 18:34:52 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SVnE81UVrLxbfGP+6pgZLhAPx5mmTjunYySXbdF+t4s=; b=OegBi0k0DrvF5UzeRZBFsbXEwUsb6uN9vAmfeKbWHAkQ0CkC6e5Hjj69bDFOKv0Bu8jZ1zGlVKU/eH+86hc1hklet9jN5Qvvcg4Q+ba/b+B4fv5tvYc0JEiEUvLVXSv7TJpso0wGWM8vn/m5SmimvcADwIqDSX8MsDBlwtocxhM=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB4324.eurprd06.prod.outlook.com (52.135.150.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Tue, 16 Oct 2018 15:34:50 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.027; Tue, 16 Oct 2018 15:34:50 +0000
From: Michael Rehder 
To: Robert Wilton , Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoAAPS9MgABQPKNgADaijIAAAJ4ccA==
Date: Tue, 16 Oct 2018 15:34:50 +0000
Message-ID: 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com>
In-Reply-To: <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB4324; 6:XexKjI0d3hwN7zOvnOfDTudzf4XNIF5e3iqa3By6EnN0IkGesC/4moX05/QHDJaveGCvXOW3dDMo1kh2V/suSMutOn0lPtpY3+byPmzBB3fxUFcSa6ABcj1SBa4/7P0yxv8NkRaVN34UuowpaQkjj9c1yDE6BE6uveFijvYieuektsqhXsY0LLHnToCG4GOXmB+iJlgwgDCYATz8c5Vv2Be1IY+s80trefaLcAnmVrBni9au0iaRypxWInNitJ8uMjb4sFZxG7wKcDSw4ACokPcB5mXVSm7UfhWUldo0mCzkbVpN3r4QXbtSlOG9C4kJ0mFx+fOk4EoZqpRtkgRWrpZS6PA2wN39u3bTOzVNkYydp8LGJEWYudb2WrE7YUUTRKWzxLc+9emT+VfS6NrqCeuxdWOZnGCHqXSTN3lpyy/wJIEwik/6xtA4a3ltkTy09JvzgK2iNmaWx0QNhC4L5Q==; 5:KQx9johKYw3Ljm3pk+qeO6MpoF4DBeA9WbPZuv0O0JhaceWqaMOH77jqp86HssoXXtyLjhWd0Z53jAS1XemEHowHoH5Rwa6GyU52EO8oXPGSLxolnMPvwHUJ3iOtfs/HdQ+tM/7jldXK7GLS/93lE0KVcDpaYI30w28ZWFXRm54=; 7:t40/K+KmCxnuVhh4veEg613CPuBEeZj5hYxdNsWpDiEK4SsvXjhfE/nqCHGMhk7ucZo6rV1qwI9jxOXOC/BjAsXBkHWrkaTDR6PfZA/fwYyYcEWCLEKboZ8Kp9lPP46FsnNGiER5h5J18mcXeVZFeT8jGdBFY3kfZ/2Yb6m39OCsV9SRk2HL2rLBlzymF4Uy1e/6J+knIgCk61wZcEqhFjBBaizX8uHpTNY1UGi5YkYDx8EaIF9J3TO/mMxa6PK2
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c026fdc1-ffc3-4912-dc1b-08d6337ce954
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB4324; 
x-ms-traffictypediagnostic: AM0PR06MB4324:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014)(166566539817055)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991067); SRVR:AM0PR06MB4324; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB4324; 
x-forefront-prvs: 0827D7ACB9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(346002)(376002)(199004)(189003)(13464003)(110136005)(26005)(966005)(102836004)(476003)(86362001)(4326008)(11346002)(186003)(446003)(72206003)(8936002)(81156014)(99286004)(486006)(7696005)(8676002)(14454004)(76176011)(53546011)(2900100001)(68736007)(256004)(97736004)(6506007)(33656002)(606006)(74316002)(7736002)(5250100002)(71190400001)(54896002)(81166006)(316002)(478600001)(93886005)(71200400001)(66066001)(25786009)(106356001)(2906002)(229853002)(9686003)(105586002)(6436002)(55016002)(3846002)(6116002)(236005)(53936002)(5660300001)(790700001)(6246003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB4324; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Zd1BabMflEj8FghGG61sbdHHuEcpcqwjJJz86RHUdFCCFNdV/UybcHp8QNh1WA5ZZpcLLlUyoU56buuhqd0FoKdFOlAi+vh1CKUWoERUpAxTUoPCIKGRPYLVEFWEHErkYzlFQjh60430JCg2FTOwK+vpObastZ/39xyusMuQuXKD7C8voXGeqkIpDT+omnqW81WMMCUaQabd0+lFrKwjgApY5VZzlNVqxgiob59+w+odsCnnaA4ckZmt+FsIkx7o9oTQJPkHVQPPGpDfveHxEvls0pWTnzdtLutpCx8jgYnA5zsF98CBry/0OPi8JRzq6JHDq+A5TsMm/qzI6lyRsqNYr5blPLl0mgeTxr98u2k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR06MB4083F4308E68CC156082B2B8E7FE0AM0PR06MB4083eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c026fdc1-ffc3-4912-dc1b-08d6337ce954
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 15:34:50.2337 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB4324
X-OriginatorOrg: amdocs.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 15:35:07 -0000

--_000_AM0PR06MB4083F4308E68CC156082B2B8E7FE0AM0PR06MB4083eurp_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

T2ssIHNvIGl0IGlzIHRoZXJlIGluIHRoZSBSRkMsIGp1c3Qgc29tZXdoYXQgc2VwYXJhdGVkIChp
biBteSB2aWV3KSBmcm9tIHRoZSBkZWZpbml0aW9uIG9mIOKAnHdoZW7igJ0uDQoNCkkgc3RpbGwg
YW0gc29tZXdoYXQgc3VycHJpc2VkIGJ5IHRoaXMgaW1wbGVtZW50YXRpb24uDQpGYXIgbW9yZSBv
ZnRlbiB0aGUgSSBzZWUgYSBuZWVkIHRvIGVuZm9yY2UgdGhlIHByZXNlbmNlIG9mIGEgdmFyaWFu
dC4NCg0KVGhhbmtzDQpNaWtlDQoNCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9u
QGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTggOTo0MiBBTQ0KVG86
IE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tPjsgSnVlcmdlbiBTY2hv
ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpDYzogbmV0
bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGlu
IG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QgZW5zdXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRv
cnkgb2JqZWN0DQoNCg0KSGkgTWlrZSwNCg0KT24gMTYvMTAvMjAxOCAxNDoyNiwgTWljaGFlbCBS
ZWhkZXIgd3JvdGU6DQoNCkkndmUgcmVhZCByZmM2MTEwIGFuZCBJIGRpZG4ndCBzZWUgYW55IG1l
bnRpb24gb2YgIldIRU4iIG9uIHRoZSBtYW5kYXRvcnkgc3RhdHVzIChzZWN0aW9uIDkuMS4xIE9w
dGlvbmFsIGFuZCBNYW5kYXRvcnkgTm9kZXMgZG9lc24ndCBsaXN0IGl0IHdoaWNoIHNlZW1zIGEg
Yml0IG9kZCB0byBtZSkuDQoNClRoZSBzZWN0aW9uIG9uICJXSEVOIiBqdXN0IG1lbnRpb25zIHRo
ZSB4cGF0aCBtYXBwaW5nLCBub3QgYW55dGhpbmcgYWJvdXQgY2hhbmdpbmcgdGhlIG1hbmRhdG9y
eSBzdGF0dXMgb2YgdGhlIGVuY2xvc2luZyBub2RlLg0KDQoNCg0KSSBzdGlsbCB0aGluayB0aGF0
IHRoZSBZQU5HIFJGQyB3b3JkaW5nIG9mICJjb25kaXRpb25hbCIgbmVlZHMgdG8gaW5kaWNhdGUg
aWYgdGhlIG5vZGUgaXMgbWFuZGF0b3J5IHN0YXR1cyBpcyBhZmZlY3RlZCBvciBub3QuDQoNCk5v
dGUgdGhhdCByZmM2MDYwICIzLjEgTWFuZGF0b3J5IE5vZGVzIiBkb2Vzbid0IG1lbnRpb24gIldI
RU4iIChpdCBkb2VzIG1lbnRpb24gcHJlc2VuY2UpLg0KQnkgWUFORyBSRkMgZG8geW91IG1lYW4g
UkZDIDYwMjAvNzk1MD8NCg0KU2VjdGlvbiA4LjEgb2YgUkZDIDc5NTAgc3RhdGVzIHRoZSBmb2xs
b3dpbmcgY29uc3RyYWludHMgYXBwbHkgb24gdmFsaWQgZGF0YSB0cmVlczoNCg0KICAgbyAgVGhl
cmUgTVVTVCBiZSBubyBub2RlcyB0YWdnZWQgd2l0aCAid2hlbiIgcHJlc2VudCBpZiB0aGUgIndo
ZW4iDQoNCiAgICAgIGNvbmRpdGlvbiBldmFsdWF0ZXMgdG8gImZhbHNlIiBpbiB0aGUgZGF0YSB0
cmVlLg0KDQoNCg0KICAgbyAgVGhlICJtYW5kYXRvcnkiIGNvbnN0cmFpbnQgaXMgZW5mb3JjZWQg
Zm9yIGxlYWZzIGFuZCBjaG9pY2VzLA0KDQogICAgICB1bmxlc3MgdGhlIG5vZGUgb3IgYW55IG9m
IGl0cyBhbmNlc3RvcnMgaGFzIGEgIndoZW4iIGNvbmRpdGlvbiBvcg0KDQogICAgICAiaWYtZmVh
dHVyZSIgZXhwcmVzc2lvbiB0aGF0IGV2YWx1YXRlcyB0byAiZmFsc2UiLg0KDQoNCg0KICAgbyAg
VGhlICJtaW4tZWxlbWVudHMiIGFuZCAibWF4LWVsZW1lbnRzIiBjb25zdHJhaW50cyBhcmUgZW5m
b3JjZWQgZm9yDQoNCiAgICAgIGxpc3RzIGFuZCBsZWFmLWxpc3RzLCB1bmxlc3MgdGhlIG5vZGUg
b3IgYW55IG9mIGl0cyBhbmNlc3RvcnMgaGFzDQoNCiAgICAgIGEgIndoZW4iIGNvbmRpdGlvbiBv
ciAiaWYtZmVhdHVyZSIgZXhwcmVzc2lvbiB0aGF0IGV2YWx1YXRlcyB0bw0KDQogICAgICAiZmFs
c2UiLg0KDQoNCg0KVGhlc2UgcnVsZXMgaW5kaWNhdGUgdGhhdCAid2hlbiIgdHJ1bXBzICJtYW5k
YXRvcnkiLCAibWluLWVsZW1lbnRzIiBhbmQgIm1heC1lbGVtZW50cyIuDQoNCg0KDQpUaGFua3Ms
DQoNClJvYg0KDQoNCg0KDQoNCg0KDQoNCg0KVGhhbmtzDQoNCk1pa2UNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXQ0KDQpTZW50OiBTYXR1cmRheSwgT2N0
b2JlciAxMywgMjAxOCA1OjIwIFBNDQoNClRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhk
ZXJAQW1kb2NzLmNvbT48bWFpbHRvOk1pY2hhZWwuUmVoZGVyQEFtZG9jcy5jb20+DQoNCkNjOiBu
ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtu
ZXRtb2RdIFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0DQoN
CmVuc3VyZSBwcmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdA0KDQoNCg0KT24gRnJpLCBP
Y3QgMTIsIDIwMTggYXQgMDQ6MDg6NDhQTSArMDAwMCwgTWljaGFlbCBSZWhkZXIgd3JvdGU6DQoN
Cg0KDQpUaGUgbWFuZGF0b3J5IHN0YXRlbWVudCBpbiB0aGF0IGNhc2UgaXMgaWdub3JlZCAoSeKA
mXZlIHBvaW50ZWQgb3V0IHRoZQ0KDQpSTkcgYW5kIFNjaGVtYXRyb24gbGFjayBvZiBlbmZvcmNl
bWVudCkuICBXSEVOIHRydW1wcyB0aGUgbWFuZGF0b3J5DQoNCnN0YXR1cyAodmlhIGV4cGxpY2l0
IG1hbmRhdG9yeSBvciBpbXBsaWNpdCBtYW5kYXRvcnkgdmlhIG1pbi1lbGVtZW50cw0KDQoxKQ0K
DQoNCg0KSGFzIHRoZSBSTkcgYW5kIFNjaGVtYXRyb24gYmVlbiBvYnRhaW5lZCBmb2xsb3dpbmcg
UkZDIDYxMTA/IElmIHNvLCB0aGlzIG1heQ0KDQpiZSBhIHByb2JsZW0gd2l0aCBSRkMgNjExMCBi
dXQgbm90IHdpdGggWUFORyBpdHNlbGYuIFRoZXJlIGFyZSB2YWxpZGF0b3JzIHRoYXQNCg0KZG8g
bm90IHVzZSBSTkcgb3IgU2NoZW1hdHJvbi4NCg0KDQoNCi9qcw0KDQoNCg0KLS0NCg0KSnVlcmdl
biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN
Cg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg
QnJlbWVuIHwgR2VybWFueQ0KDQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw
czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+PGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJz
aXR5LmRlLz4NCg0K4oCcQW1kb2Nz4oCZIGVtYWlsIHBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhp
cmQtcGFydHksIHdvcmxkd2lkZSwgY2xvdWQtYmFzZWQgc3lzdGVtLiBBbnkgZW1haWxzIHNlbnQg
dG8gQW1kb2NzIHdpbGwgYmUgcHJvY2Vzc2VkIGFuZCBzdG9yZWQgdXNpbmcgc3VjaCBzeXN0ZW0g
YW5kIGFyZSBhY2Nlc3NpYmxlIGJ5IHRoaXJkIHBhcnR5IHByb3ZpZGVycyBvZiBzdWNoIHN5c3Rl
bSBvbiBhIGxpbWl0ZWQgYmFzaXMuIFlvdXIgc2VuZGluZyBvZiBlbWFpbHMgdG8gQW1kb2NzIGV2
aWRlbmNlcyB5b3VyIGNvbnNlbnQgdG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaCBw
cm9jZXNzaW5nLCBzdG9yaW5nIGFuZCBhY2Nlc3PigJ0uDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0
bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9y
bSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3Rl
bS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVk
IHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92
aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2Yg
ZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3Vj
aCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLgo=

--_000_AM0PR06MB4083F4308E68CC156082B2B8E7FE0AM0PR06MB4083eurp_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T2ssIHNvIGl0IGlzIHRo
ZXJlIGluIHRoZSBSRkMsIGp1c3Qgc29tZXdoYXQgc2VwYXJhdGVkIChpbiBteSB2aWV3KSBmcm9t
IHRoZSBkZWZpbml0aW9uIG9mIOKAnHdoZW7igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5JIHN0aWxsIGFtIHNvbWV3aGF0IHN1cnByaXNlZCBieSB0aGlzIGlt
cGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GYXIgbW9yZSBvZnRlbiB0aGUgSSBzZWUg
YSBuZWVkIHRvIGVuZm9yY2UgdGhlIHByZXNlbmNlIG9mIGEgdmFyaWFudC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N
aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow
aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBX
aWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz
ZGF5LCBPY3RvYmVyIDE2LCAyMDE4IDk6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgUmVo
ZGVyICZsdDtNaWNoYWVsLlJlaGRlckBBbWRvY3MuY29tJmd0OzsgSnVlcmdlbiBTY2hvZW53YWVs
ZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PGJyPg0KPGI+
Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2Rd
IFdIRU4gc3RhdGVtZW50IHdpdGhpbiBtYW5kYXRvcnkgb2JqZWN0cyBkb2Vzbid0IGVuc3VyZSBw
cmVzZW5jZSBvZiB0aGUgbWFuZGF0b3J5IG9iamVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwPkhpIE1pa2UsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNi8xMC8yMDE4
IDE0OjI2LCBNaWNoYWVsIFJlaGRlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cHJlPkkndmUgcmVhZCByZmM2MTEwIGFuZCBJIGRpZG4ndCBzZWUgYW55IG1lbnRpb24gb2YgJnF1
b3Q7V0hFTiZxdW90OyBvbiB0aGUgbWFuZGF0b3J5IHN0YXR1cyAoc2VjdGlvbiA5LjEuMSBPcHRp
b25hbCBhbmQgTWFuZGF0b3J5IE5vZGVzIGRvZXNuJ3QgbGlzdCBpdCB3aGljaCBzZWVtcyBhIGJp
dCBvZGQgdG8gbWUpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBzZWN0aW9uIG9uICZxdW90
O1dIRU4mcXVvdDsganVzdCBtZW50aW9ucyB0aGUgeHBhdGggbWFwcGluZywgbm90IGFueXRoaW5n
IGFib3V0IGNoYW5naW5nIHRoZSBtYW5kYXRvcnkgc3RhdHVzIG9mIHRoZSBlbmNsb3Npbmcgbm9k
ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J
IHN0aWxsIHRoaW5rIHRoYXQgdGhlIFlBTkcgUkZDIHdvcmRpbmcgb2YgJnF1b3Q7Y29uZGl0aW9u
YWwmcXVvdDsgbmVlZHMgdG8gaW5kaWNhdGUgaWYgdGhlIG5vZGUgaXMgbWFuZGF0b3J5IHN0YXR1
cyBpcyBhZmZlY3RlZCBvciBub3QuPG86cD48L286cD48L3ByZT4NCjxwcmU+Tm90ZSB0aGF0IHJm
YzYwNjAgJnF1b3Q7My4xIE1hbmRhdG9yeSBOb2RlcyZxdW90OyBkb2Vzbid0IG1lbnRpb24gJnF1
b3Q7V0hFTiZxdW90OyAoaXQgZG9lcyBtZW50aW9uIHByZXNlbmNlKS48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnkgWUFORyBSRkMgZG8geW91
IG1lYW4gUkZDIDYwMjAvNzk1MD88bzpwPjwvbzpwPjwvcD4NCjxwPlNlY3Rpb24gOC4xIG9mIFJG
QyA3OTUwIHN0YXRlcyB0aGUgZm9sbG93aW5nIGNvbnN0cmFpbnRzIGFwcGx5IG9uIHZhbGlkIGRh
dGEgdHJlZXM6PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2U7
Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlv
bi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBU
aGVyZSBNVVNUIGJlIG5vIG5vZGVzIHRhZ2dlZCB3aXRoICZxdW90O3doZW4mcXVvdDsgcHJlc2Vu
dCBpZiB0aGUgJnF1b3Q7d2hlbiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25kaXRpb24gZXZhbHVhdGVzIHRvICZxdW90O2ZhbHNl
JnF1b3Q7IGluIHRoZSBkYXRhIHRyZWUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlh
bnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAy
O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBp
bml0aWFsO3dvcmQtc3BhY2luZzowcHgiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSAmcXVvdDtt
YW5kYXRvcnkmcXVvdDsgY29uc3RyYWludCBpcyBlbmZvcmNlZCBmb3IgbGVhZnMgYW5kIGNob2lj
ZXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHVubGVzcyB0aGUgbm9kZSBvciBhbnkgb2YgaXRzIGFuY2VzdG9ycyBoYXMgYSAmcXVvdDt3aGVu
JnF1b3Q7IGNvbmRpdGlvbiBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpZi1mZWF0dXJlJnF1b3Q7IGV4cHJlc3Npb24gdGhhdCBl
dmFsdWF0ZXMgdG8gJnF1b3Q7ZmFsc2UmcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlICZxdW90
O21pbi1lbGVtZW50cyZxdW90OyBhbmQgJnF1b3Q7bWF4LWVsZW1lbnRzJnF1b3Q7IGNvbnN0cmFp
bnRzIGFyZSBlbmZvcmNlZCBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgbGlzdHMgYW5kIGxlYWYtbGlzdHMsIHVubGVzcyB0aGUgbm9kZSBv
ciBhbnkgb2YgaXRzIGFuY2VzdG9ycyBoYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSAmcXVvdDt3aGVuJnF1b3Q7IGNvbmRpdGlvbiBvciAm
cXVvdDtpZi1mZWF0dXJlJnF1b3Q7IGV4cHJlc3Npb24gdGhhdCBldmFsdWF0ZXMgdG88bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZmFs
c2UmcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+VGhlc2UgcnVsZXMgaW5kaWNhdGUgdGhhdCAmcXVvdDt3aGVuJnF1b3Q7IHRydW1wcyAm
cXVvdDttYW5kYXRvcnkmcXVvdDssICZxdW90O21pbi1lbGVtZW50cyZxdW90OyBhbmQgJnF1b3Q7
bWF4LWVsZW1lbnRzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPlRoYW5rcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Sb2I8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1p
a2U8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86
cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFs8YSBocmVm
PSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIj5tYWlsdG86ai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPl08bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5TZW50OiBTYXR1cmRheSwgT2N0b2JlciAxMywgMjAxOCA1OjIwIFBNPG86cD48L286cD48
L3ByZT4NCjxwcmU+VG86IE1pY2hhZWwgUmVoZGVyIDxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlJl
aGRlckBBbWRvY3MuY29tIj4mbHQ7TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbSZndDs8L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci
Pm5ldG1vZEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTog
W25ldG1vZF0gV0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3Q8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lbnN1cmUgcHJlc2VuY2Ugb2YgdGhlIG1hbmRhdG9yeSBv
YmplY3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5PbiBGcmksIE9jdCAxMiwgMjAxOCBhdCAwNDowODo0OFBNICYjNDM7MDAwMCwgTWljaGFlbCBS
ZWhkZXIgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHByZT5UaGUgbWFuZGF0b3J5IHN0YXRlbWVudCBpbiB0aGF0IGNhc2UgaXMgaWdub3Jl
ZCAoSeKAmXZlIHBvaW50ZWQgb3V0IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJORyBhbmQg
U2NoZW1hdHJvbiBsYWNrIG9mIGVuZm9yY2VtZW50KS4mbmJzcDsgV0hFTiB0cnVtcHMgdGhlIG1h
bmRhdG9yeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN0YXR1cyAodmlhIGV4cGxpY2l0IG1hbmRh
dG9yeSBvciBpbXBsaWNpdCBtYW5kYXRvcnkgdmlhIG1pbi1lbGVtZW50czxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjEpPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+SGFzIHRoZSBSTkcgYW5kIFNjaGVtYXRyb24gYmVlbiBv
YnRhaW5lZCBmb2xsb3dpbmcgUkZDIDYxMTA/IElmIHNvLCB0aGlzIG1heTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmJlIGEgcHJvYmxlbSB3aXRoIFJGQyA2MTEwIGJ1dCBub3Qgd2l0aCBZQU5HIGl0
c2VsZi4gVGhlcmUgYXJlIHZhbGlkYXRvcnMgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRv
IG5vdCB1c2UgUk5HIG9yIFNjaGVtYXRyb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+L2pzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5KdWVyZ2Vu
IFNjaG9lbndhZWxkZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPG86cD48L286
cD48L3ByZT4NCjxwcmU+UGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55PG86cD48L286cD48L3ByZT4NCjxwcmU+RmF4OiZuYnNwOyZuYnNwOyAm
IzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iPiZs
dDtodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPuKAnEFtZG9jc+KAmSBlbWFpbCBwbGF0Zm9ybSBpcyBi
YXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJhc2VkIHN5c3RlbS4gQW55
IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3NlZCBhbmQgc3RvcmVkIHVzaW5n
IHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0aGlyZCBwYXJ0eSBwcm92aWRlcnMg
b2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkIGJhc2lzLiBZb3VyIHNlbmRpbmcgb2YgZW1haWxz
IHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50IHRvIHRoZSB1c2Ugb2Ygc3VjaCBzeXN0
ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3RvcmluZyBhbmQgYWNjZXNz4oCdLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPG86cD48L286cD48L3ByZT4NCjxwcmU+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0IDAuNWluOyI+PGVtPjxzcGFuIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj7igJxBbWRvY3PigJkg
ZW1haWwNCnBsYXRmb3JtIGlzIGJhc2VkIG9uIGEgdGhpcmQtcGFydHksIHdvcmxkd2lkZSwgY2xv
dWQtYmFzZWQgc3lzdGVtLiBBbnkNCmVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nl
c3NlZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2ggc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZQ0KYnkg
dGhpcmQgcGFydHkgcHJvdmlkZXJzIG9mIHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4g
WW91ciBzZW5kaW5nIG9mDQplbWFpbHMgdG8gQW1kb2NzIGV2aWRlbmNlcyB5b3VyIGNvbnNlbnQg
dG8gdGhlIHVzZSBvZiBzdWNoIHN5c3RlbSBhbmQgc3VjaA0KcHJvY2Vzc2luZywgc3RvcmluZyBh
bmQgYWNjZXNz4oCdLjwvZm9udD48L3NwYW4+PC9lbT48L3A+DQoNCjxmb250IHNpemU9IjMiPjwv
Zm9udD48L2JvZHk+DQo8L2h0bWw+DQo=

--_000_AM0PR06MB4083F4308E68CC156082B2B8E7FE0AM0PR06MB4083eurp_--


From nobody Tue Oct 16 09:06:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F646130E1B; Tue, 16 Oct 2018 09:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGxv7uOiaA5O; Tue, 16 Oct 2018 09:05:54 -0700 (PDT)
Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 C3AD0130DF7; Tue, 16 Oct 2018 09:05:54 -0700 (PDT)
Received: by mail-pl1-x642.google.com with SMTP id f8-v6so11257790plb.2; Tue, 16 Oct 2018 09:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=bq/ri17kbcdrqNgxGgrmaqpu5Z9zgjTJn6pZKq71OuU=; b=OZZUwg/BP/Cu9tkXiFXtJfRcYsFD0bAyqGWc2Q7j1Zsgi6NoJlWdkEMCgD67JAactl ffD2tF7nEiSUCnRFTginxRfkGHKF1JpIehi/L21x2tviY58KBDXOG7po7TbM0TVnpKpA eGwwhWyYYv8P5cJvOxw7neetR6atcmEr7xAYsVM14zsTCIqwBqJEvRfCLN2pfcXgRWTp Vbl+JTDHce99wsWS0QJQ0OKza56Bpo+JJHrMu0RkzHClRm+shBiwBXIaZZkGWfyF14pp AYcWAB92PGCOoJektWfo2I5g2j/55KHh/owe1ebl8TTU2DuJ1TcqicGpEz/P+r7d6UuA Lmhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=bq/ri17kbcdrqNgxGgrmaqpu5Z9zgjTJn6pZKq71OuU=; b=iqUJtyRvdhCmnFOK/I/wWu9sjm06pEAC1sJ2XKUqaw0dCSbjufr7CrILlv8qyRR6Sw YPsjqbowUKBACnqUVkfRWpvjRuFuiL4xN7tQZvhXEjhkzikOFpoEfA6uYymwCkFFo/e1 U4IgwtlYCa4n99gxmi37AUK0Hxrnz3J0rTfRkcjKH6h/cRgK6Tsff2uN8wH65qVF66N/ 0S3dYuEjs0fV9v+UsCkBJ2Nez/dKWHPsX/m40XgVPNzPlbja4LJQb2S/nmgo/78gJnxH vO4ihKCgbFsOLWBCob1s5T52SV1GiVv2VaADKLInZVoSoUtH6pb8w1XqmZubZVSdsIVR /d5w==
X-Gm-Message-State: ABuFfogC6g3PVjuqX/s9mEAqRi9F9ta3FDK2dwfehm6AFnmi4s0j17gT nWJOTpRhwaXyAew57NmEVd0=
X-Google-Smtp-Source: ACcGV60EMFSDNt2plgpB1OTmZy1rtNP7uIznDZXIWopjcug/KNuNdcPXnvD0xA8xFUjdGTMlvimJaQ==
X-Received: by 2002:a17:902:48:: with SMTP id 66-v6mr22228277pla.7.1539705953952;  Tue, 16 Oct 2018 09:05:53 -0700 (PDT)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net. [73.202.177.209]) by smtp.googlemail.com with ESMTPSA id a11-v6sm17257195pfn.66.2018.10.16.09.05.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 09:05:52 -0700 (PDT)
To: Eric Rescorla , =?UTF-8?Q?martin_bj=c3=b6rklund?= 
Cc: IESG , NetMod WG Chairs , NetMod WG , draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger 
References:  <20181011.091817.1727547509052700274.mbj@tail-f.com>  <20181016.144545.1184951335260453665.mbj@tail-f.com> 
From: joel jaeggli 
Openpgp: preference=signencrypt
Autocrypt: addr=joelja@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w=
Message-ID: <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com>
Date: Tue, 16 Oct 2018 09:05:50 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6Guctn3gkvKcuWZ32l3z3dS3OrbuTNxRP"
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 16:06:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6Guctn3gkvKcuWZ32l3z3dS3OrbuTNxRP
Content-Type: multipart/mixed; boundary="nkk3rebIGyyXlUnTJDvANvx9Po76vx8vv";
 protected-headers="v1"
From: joel jaeggli 
To: Eric Rescorla , =?UTF-8?Q?martin_bj=c3=b6rklund?=
 
Cc: IESG , NetMod WG Chairs ,
 NetMod WG , draft-ietf-netmod-schema-mount@ietf.org,
 Kent Watsen , Lou Berger 
Message-ID: <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11:
 (with DISCUSS)
References: 
 <20181011.091817.1727547509052700274.mbj@tail-f.com>
 
 <20181016.144545.1184951335260453665.mbj@tail-f.com>
 
In-Reply-To: 

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

On 10/16/18 06:00, Eric Rescorla wrote:
> I'm sorry, but I still don't think I understand the security impacts of=

> this well enough to know if this text is OK.
>=20
> Can you provide a more detailed explanation of what XPath expressions
> can and cannot do here? Happy to discuss live either on the phone or in=
 BKK
I'm probably grossly simplifying the goal here, but.

xpath statement allow for referencing another path or applying
constraints e.g. when / must (rfc 6020)

the canonical example in 6020 being something like

  container interface {
      leaf ifType {
          type enumeration {
              enum ethernet;
              enum atm;
          }
      }
      leaf ifMTU {
          type uint32;
      }
      must "ifType !=3D 'ethernet' or " +
           "(ifType =3D 'ethernet' and ifMTU =3D 1500)" {
          error-message "An ethernet MTU must be 1500";
      }
      must "ifType !=3D 'atm' or " +
           "(ifType =3D 'atm' and ifMTU <=3D 17966 and ifMTU >=3D 64)" {
          error-message "An atm MTU must be  64 .. 17966";
      }

http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpa=
th

Imposing constraints using nodes in mounted modules is kind of a key
application of schema-mount.

> -Ekr
>=20
>=20
> On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > wrote:
>=20
>     Hi,
>=20
>     Eric Rescorla > wrote:
>     > That seems like it's going to have some pretty surprising
>     consequences and
>     > at minimum needs more information in the Security Considerations.=

>=20
>     Ok.=C2=A0 Howabout we add a paragraph to the end of the Security
>     Considerations section:
>=20
>     =C2=A0 Care must be taken when the "parent-reference" XPath express=
ions are
>     =C2=A0 constructed, since the result of the evaluation of these exp=
ressions
>     =C2=A0 is added to the accessible tree for any XPath expression fou=
nd in
>     =C2=A0 the mounted schema.
>=20
>=20
>     /martin
>=20
>     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund      > wrote:
>     >
>     > > Eric Rescorla > wrote:
>     > > > I'm sorry but I don't understand this.
>     > > >
>     > > > Does the externally visible behavior of any mounted module
>     depend in any
>     > > > way on these XPATH references
>     > >
>     > > Yes, but note that these XPath expressions ("parent-reference")=
 are
>     > > read-only (config false in the YANG model).=C2=A0 Thus they are=
 set
>     by the
>     > > implementation, and used to inform the operator about the
>     environment
>     > > in which other XPath expressions are evaluated.
>     > >
>     > >
>     > > /martin
>     > >
>     > >
>     > > >
>     > > > -Ekr
>     > > >
>     > > >
>     > > >
>     > > >
>     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
>     > wrote:
>     > > >
>     > > > > Eric Rescorla > wrote:
>     > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
>     >
>     > > wrote:
>     > > > > >
>     > > > > > > Hi,
>     > > > > > >
>     > > > > > > Eric Rescorla > wrot=
e:
>     > > > > > > > Eric Rescorla has entered the following ballot
>     position for
>     > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
>     > > > > > > >
>     > > > > > > > When responding, please keep the subject line intact
>     and reply
>     > > to all
>     > > > > > > > email addresses included in the To and CC lines. (Fee=
l
>     free to
>     > > cut
>     > > > > this
>     > > > > > > > introductory paragraph, however.)
>     > > > > > > >
>     > > > > > > >
>     > > > > > > > Please refer to
>     > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.ht=
ml
>     > > > > > > > for more information about IESG DISCUSS and COMMENT
>     positions.
>     > > > > > > >
>     > > > > > > >
>     > > > > > > > The document, along with other ballot positions, can
>     be found
>     > > here:
>     > > > > > > >
>     https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>     > > > > > > >
>     > > > > > > >
>     > > > > > > >
>     > > > > > > >
>     > > > >
>     -------------------------------------------------------------------=
---
>     > > > > > > > DISCUSS:
>     > > > > > > >
>     > > > >
>     -------------------------------------------------------------------=
---
>     > > > > > > >
>     > > > > > > > Rich version of this review at:
>     > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
>     > > > > > > >
>     > > > > > > >
>     > > > > > > >
>     > > > > > > > DETAIL
>     > > > > > > > S 4.
>     > > > > > > > >
>     > > > > > > > >=C2=A0 =C2=A0 =C2=A0 It is worth emphasizing that th=
e nodes specified in
>     > > > > > > > >=C2=A0 =C2=A0 =C2=A0 "parent-reference" leaf-list ar=
e available in
>     the mounted
>     > > > > schema
>     > > > > > > only
>     > > > > > > > >=C2=A0 =C2=A0 =C2=A0 for XPath evaluations.=C2=A0 In=
 particular, they
>     cannot be
>     > > accessed
>     > > > > > > there
>     > > > > > > > >=C2=A0 =C2=A0 =C2=A0 via network management protocol=
s such as NETCONF
>     > > [RFC6241] or
>     > > > > > > > >=C2=A0 =C2=A0 =C2=A0 RESTCONF [RFC8040].
>     > > > > > > >
>     > > > > > > > What are the security implications of this XPath refe=
rence
>     > > outside
>     > > > > the
>     > > > > > > > mount jail? Specifically, how does it interact with
>     the access
>     > > > > control
>     > > > > > > > for the enclosing module.
>     > > > > > >
>     > > > > > > There is no such interaction, since access control come=
s
>     into play
>     > > > > > > when some external entity accesses the data through som=
e
>     management
>     > > > > > > protocol, and the nodes from the "parent-reference"
>     expressions
>     > > cannot
>     > > > > > > be accessed via management protocols.
>     > > > > > >
>     > > > > > > The last sentence of the quoted paragraph was supposed
>     to make this
>     > > > > > > clear, but it seems we might need some additional
>     explanation?
>     > > > > > >
>     > > > > >
>     > > > > > Yes, I think so. I guess I'm not clear on what the XPath
>     expressions
>     > > are
>     > > > > > for if they
>     > > > > > can't be accessed via the management protocols. How can
>     they be used?
>     > > > >
>     > > > > These are XPath expressions defined in the YANG models
>     themselves,
>     > > > > such as "must" expressions or "leafrefs".=C2=A0 =C2=A0The d=
escription of
>     > > > > "parent-reference" refer to them as:
>     > > > >
>     > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [...=
] XPath
>     > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expr=
essions whose context nodes are defined
>     in the
>     > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 moun=
ted schema
>     > > > >
>     > > > >
>     > > > >
>     > > > > /martin
>     > > > >
>     > >
>=20



--nkk3rebIGyyXlUnTJDvANvx9Po76vx8vv--

--6Guctn3gkvKcuWZ32l3z3dS3OrbuTNxRP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCW8YMXgAKCRDwADWrtn9W
shnYAJ4mcRkNbRMx933GnvYMESNVF1Z8ewCfT+ON+YlDZKbONO2wcX9c3cXsFR4=
=zY3d
-----END PGP SIGNATURE-----

--6Guctn3gkvKcuWZ32l3z3dS3OrbuTNxRP--


From nobody Tue Oct 16 09:06:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0040130E5F for ; Tue, 16 Oct 2018 09:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.491
X-Spam-Level: 
X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 tyWjU_TMTQXE for ; Tue, 16 Oct 2018 09:06:23 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EA2130E5B for ; Tue, 16 Oct 2018 09:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20452; q=dns/txt; s=iport; t=1539705982; x=1540915582; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=wPeZSF82SNEHm0V3dnwoKHBJIVpWFnxfp4/FEv9BMYk=; b=l9qJe6adeBmusp0mt61kCa8wod11Ytec7ju6P3mAqYDkve2Jkgyn/7CJ bNeLYWMJQlEcZs84JvlnT6fTPaxoq4FHyaUjCuO0RrJ2rhkK8Y2Y8elta xAaf95V7KMzjLxhxz7WEESHqOVJDWZNL3YGKBSc6p8TfDEHm6v/t2LpZb o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACTC8Zb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYEMAUeBFW0SKIN1iHaNLwgllwcUgWY?= =?us-ascii?q?NGAEKhANGAoUINgsNAQMBAQIBAQJtHAyFOQEBAQMBAQEhCkELBQcCAgkCEAE?= =?us-ascii?q?EAQEBIwQDAgIbDB8JCAYNBgIBAYMcAYF5CA+KXJtNgS4fhRuEYQUFi16BQT+?= =?us-ascii?q?BEicMgl+DGwEBgS4BCwcBCRwbFRGCPIJXAokMhnCEOYl1CZBVBheBT4deJoZ?= =?us-ascii?q?Lj3aGN4FKBitkcTMaCBsVO4Jsgk6DaYRhhT8+MIkoAg0XB4IgAQE?=
X-IronPort-AV: E=Sophos;i="5.54,389,1534809600"; d="scan'208,217";a="7233244"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2018 16:06:20 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w9GG6Jam024278; Tue, 16 Oct 2018 16:06:19 GMT
To: Michael Rehder 
Cc: "netmod@ietf.org" 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <9d1627e3-8a0d-491e-1d2d-ed589e12b1c5@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 16 Oct 2018 17:06:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7E3D8A655F317CC1C1EBA036"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 16:06:31 -0000

This is a multi-part message in MIME format.
--------------7E3D8A655F317CC1C1EBA036
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Mike,


On 16/10/2018 16:34, Michael Rehder wrote:
>
> Ok, so it is there in the RFC, just somewhat separated (in my view) 
> from the definition of “whenâ€.
>
> I still am somewhat surprised by this implementation.
>
> Far more often the I see a need to enforce the presence of a variant.
>
I'm sorry, but I still haven't seen you provide any concrete example in 
YANG where this is useful.

Early in the thread you provided an example with static/dynamic IP 
addresses, and wrote 'There is no way in the IPAddresses list to enforce 
that there is at least one IP Address when the assignment method is 
"Static".'.  But as I replied previously, for YANG at least, this 
statement is wrong since your YANG achieves exactly that constraint!

Specifically, if you have a server that implements the YANG module that 
you provided and a client attempted to configure it via NETCONF or 
RESTCONF then the server would enforce that either the assignment is 
DHCP or at least one static IP address is provided, otherwise the config 
change would be rejected.

I think that your issue may be more with how the YANG is translated via 
the methods in RFC 6110 (which I am not familiar with), but that doesn't 
mean that there is a problem with the YANG definition itself.  Allowing 
mandatory/min-elements/max-elements to have precedence over 'when' 
doesn't make much sense to me, I'm missing a concrete example where it 
seems that this would be useful, certainly your IP address example does 
not require it.

Thanks,
Rob


> Thanks
>
> Mike
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Tuesday, October 16, 2018 9:42 AM
> *To:* Michael Rehder ; Juergen 
> Schoenwaelder 
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects 
> doesn't ensure presence of the mandatory object
>
> Hi Mike,
>
> On 16/10/2018 14:26, Michael Rehder wrote:
>
>     I've read rfc6110 and I didn't see any mention of "WHEN" on the mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't list it which seems a bit odd to me).
>
>     The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node.
>
>     I still think that the YANG RFC wording of "conditional" needs to indicate if the node is mandatory status is affected or not.
>
>     Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it does mention presence).
>
> By YANG RFC do you mean RFC 6020/7950?
>
> Section 8.1 of RFC 7950 states the following constraints apply on 
> valid data trees:
>
>     o  There MUST be no nodes tagged with "when" present if the "when"
>        condition evaluates to "false" in the data tree.
>     o  The "mandatory" constraint is enforced for leafs and choices,
>        unless the node or any of its ancestors has a "when" condition or
>        "if-feature" expression that evaluates to "false".
>     o  The "min-elements" and "max-elements" constraints are enforced for
>        lists and leaf-lists, unless the node or any of its ancestors has
>        a "when" condition or "if-feature" expression that evaluates to
>        "false".
> These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements".
> Thanks,
> Rob
>   
>
>     Thanks
>
>     Mike
>
>         -----Original Message-----
>
>         From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
>
>         Sent: Saturday, October 13, 2018 5:20 PM
>
>         To: Michael Rehder 
>
>         Cc:netmod@ietf.org 
>
>         Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>
>         ensure presence of the mandatory object
>
>         On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
>
>             The mandatory statement in that case is ignored (I’ve pointed out the
>
>             RNG and Schematron lack of enforcement).  WHEN trumps the mandatory
>
>             status (via explicit mandatory or implicit mandatory via min-elements
>
>             1)
>
>         Has the RNG and Schematron been obtained following RFC 6110? If so, this may
>
>         be a problem with RFC 6110 but not with YANG itself. There are validators that
>
>         do not use RNG or Schematron.
>
>         /js
>
>         --
>
>         Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>
>         Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>
>         Fax:   +49 421 200 3103
>         
>
>     “Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€.
>
>     _______________________________________________
>
>     netmod mailing list
>
>     netmod@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netmod
>
> /“Amdocs’ email platform is based on a third-party, worldwide, 
> cloud-based system. Any emails sent to Amdocs will be processed and 
> stored using such system and are accessible by third party providers 
> of such system on a limited basis. Your sending of emails to Amdocs 
> evidences your consent to the use of such system and such processing, 
> storing and accessâ€./
>


--------------7E3D8A655F317CC1C1EBA036
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Mike,

    

    

    
On 16/10/2018 16:34, Michael Rehder
      wrote:

    

    

      
      
      
      

        
Ok,
            so it is there in the RFC, just somewhat separated (in my
            view) from the definition of “whenâ€.

        
 

        
I
            still am somewhat surprised by this implementation.

        
Far
            more often the I see a need to enforce the presence of a
            variant.

      

    

    I'm sorry, but I still haven't seen you provide any concrete example
    in YANG where this is useful.

    

    Early in the thread you provided an example with static/dynamic IP
    addresses, and wrote 'There is no way in the IPAddresses list to
    enforce that there is at least one IP Address when the assignment
    method is "Static".'.  But as I replied previously, for YANG at
    least, this statement is wrong since your YANG achieves exactly that
    constraint!

    

    Specifically, if you have a server that implements the YANG module
    that you provided and a client attempted to configure it via NETCONF
    or RESTCONF then the server would enforce that either the assignment
    is DHCP or at least one static IP address is provided, otherwise the
    config change would be rejected.

    

    I think that your issue may be more with how the YANG is translated
    via the methods in RFC 6110 (which I am not familiar with), but that
    doesn't mean that there is a problem with the YANG definition
    itself.  Allowing mandatory/min-elements/max-elements to have
    precedence over 'when' doesn't make much sense to me, I'm missing a
    concrete example where it seems that this would be useful, certainly
    your IP address example does not require it.

    

    Thanks,

    Rob

    

    

    

      

        

        
 

        
Thanks

        
Mike

        
 

        

          

            

              
From:
                  Robert Wilton [mailto:rwilton@cisco.com]
                  

                  Sent: Tuesday, October 16, 2018 9:42 AM

                  To: Michael Rehder
                  <Michael.Rehder@Amdocs.com>; Juergen
                  Schoenwaelder
                  <j.schoenwaelder@jacobs-university.de>

                  Cc: netmod@ietf.org

                  Subject: Re: [netmod] WHEN statement within
                  mandatory objects doesn't ensure presence of the
                  mandatory object

            

          

          
 

          
Hi Mike,

          
 

          

            
On 16/10/2018 14:26, Michael Rehder
              wrote:

          

          

            
I've read rfc6110 and I didn't see any mention of "WHEN" on the mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't list it which seems a bit odd to me).

            
The section on "WHEN" just mentions the xpath mapping, not anything about changing the mandatory status of the enclosing node.

            
 

            
I still think that the YANG RFC wording of "conditional" needs to indicate if the node is mandatory status is affected or not.

            
Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it does mention presence).

          

          
By YANG RFC do you mean RFC 6020/7950?

          
Section 8.1 of RFC 7950 states the following constraints
            apply on valid data trees:

          
   o  There MUST be no nodes tagged with "when" present if the "when"

          
      condition evaluates to "false" in the data tree.

          
 

          
   o  The "mandatory" constraint is enforced for leafs and choices,

          
      unless the node or any of its ancestors has a "when" condition or

          
      "if-feature" expression that evaluates to "false".

          
 

          
   o  The "min-elements" and "max-elements" constraints are enforced for

          
      lists and leaf-lists, unless the node or any of its ancestors has

          
      a "when" condition or "if-feature" expression that evaluates to

          
      "false".

          
 

          
These rules indicate that "when" trumps "mandatory", "min-elements" and "max-elements".

          
 

          
Thanks,

          
Rob

          
 

          
 

          

            
 

            
 

            
Thanks

            
Mike

            

              
-----Original Message-----

              
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]

              
Sent: Saturday, October 13, 2018 5:20 PM

              
To: Michael Rehder <Michael.Rehder@Amdocs.com>

              
Cc: netmod@ietf.org

              
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't

              
ensure presence of the mandatory object

              
 

              
On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:

              
 

              

                
The mandatory statement in that case is ignored (I’ve pointed out the

                
RNG and Schematron lack of enforcement).  WHEN trumps the mandatory

                
status (via explicit mandatory or implicit mandatory via min-elements

                
1)

              

              
 

              
Has the RNG and Schematron been obtained following RFC 6110? If so, this may

              
be a problem with RFC 6110 but not with YANG itself. There are validators that

              
do not use RNG or Schematron.

              
 

              
/js

              
 

              
--

              
Juergen Schoenwaelder           Jacobs University Bremen gGmbH

              
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

              
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

            

            
“Amdocs’ email platform is based on a third-party, worldwide, cloud-based system. Any emails sent to Amdocs will be processed and stored using such system and are accessible by third party providers of such system on a limited basis. Your sending of emails to Amdocs evidences your consent to the use of such system and such processing, storing and accessâ€.

            
_______________________________________________

            
netmod mailing list

            
netmod@ietf.org

            
https://www.ietf.org/mailman/listinfo/netmod

          

          
 

        

      

      
“Amdocs’
              email
              platform is based on a third-party, worldwide, cloud-based
              system. Any
              emails sent to Amdocs will be processed and stored using
              such system and are accessible
              by third party providers of such system on a limited
              basis. Your sending of
              emails to Amdocs evidences your consent to the use of such
              system and such
              processing, storing and accessâ€.

    

    

  


--------------7E3D8A655F317CC1C1EBA036--


From nobody Tue Oct 16 11:43:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDCF130E2B for ; Tue, 16 Oct 2018 11:43:36 -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] 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 gcIKALmwocy3 for ; Tue, 16 Oct 2018 11:43:34 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 562B6130E48 for ; Tue, 16 Oct 2018 11:43:33 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A326C6005A; Tue, 16 Oct 2018 18:43:32 +0000 (UTC)
References: <20181016.162032.2229087452409342445.mbj@tail-f.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Martin Bjorklund 
Cc: netmod@ietf.org
In-reply-to: <20181016.162032.2229087452409342445.mbj@tail-f.com>
Date: Tue, 16 Oct 2018 14:43:31 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] mbj's WGLC review of module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 18:43:37 -0000

Martin Bjorklund  writes:

> Hi,
>
> Here are my (mostly editorial) WGLC comments on
> draft-ietf-netmod-module-tags-02:
>
>
> o  add boilerplate reference to RFC 8340

Done.

> o  2
>
>   Use 8174 boilerplate

Done.

> o  4.1
>
>     A module definition SHOULD indicate a set of tags to be automatically
>     added by the module implementer.
>
>   I think statement doesn't belong here, but rather to section 7
>   (which also has this statement already)

When I remove that sentence the paragraph doesn't really read well. I have slightly modified the text to adapt to use of a module-tag extension statement though.


>   And how are the tags supposed to be "automatically added"?

In their code presumably. :)

>   As I have written in previous discussions, and others as well, I
>   think that you should define a YANG extension that can be used to
>   define the tags, instead of relying on description statements.  Is
>   there a reason why you think an extension statement wouldn't work?

It just all seemed overly complex for indicating something that a human has to add by hand anyway (in their code). I will add this as it seems to be a sticking point that multiple people have requested as you indicate.

> o  4.1
>
>
>   OLD:
>
>    If the module definition will be
>    standard the tags MUST also be standard tags (Section 3.1).
>
>   NEW:
>
>    If the module definition will be
>    IETF standards track, the tags MUST also be IETF standard tags
>    (Section 3.1).

Done.

> o  4.3
>
>     Implementations MUST ensure that a modules tag list is consistent
>     across any location from which the list is accessible.  So if a user
>     adds a tag through configuration that tag should also be seen when
>     using any augmentation that exposes the modules tag list.
>
>   I don't understand the last sentence.  What kind of augmentation do
>   you mean?

Mentioned this in another reply, this is left-over text for when we had exposed the module tags in mulitiple places (i.e., a read-only list through augmenting yang library). I've removed the text as it's now confusing.

> o  5.1
>
>   OLD:
>
>     The tree associated with the tags module is:
>
>   NEW:
>
>     The tree associated with the "ietf-module-tags" module is:

Done.

> o  5.1
>
>   I know this has been discussed before, and Juergen wanted plural
>   names, but I propose the following structure:
>
>        +--rw module-tags
>           +--rw module* [name]
>              +--rw name          yang:yang-identifier
>              +--rw tag*          string
>              +--rw masked-tag*   string
>
>
>   I prefer a container an the top level over a list.  Also with the
>   list called "module", the key can be called just "name".  And
>   leaf-lists (and lists) usually have names in singular.

Ok I've adopted this.

> o  5.2
>
>  I think the YANG version should be 1.1.

But nothing in this module requires 1.1 features, so why restrict its use to 1.1 only?

>  Add the standard boilerplate to the YANG module.

Done.

> o  5.2 leaf name
>
>             "The YANG module or submodule name.";
>
>   Do we really want to attach tags to submodules, or should the tags
>   only be visisble for the module?

Modules, I've changed the text.

>
> o  5.2  type for tag
>
>     leaf-list tag {
>         type string;
>
>   Can I use *any* string as a tag?  No limitations at all?  Is ":"
>   special in a tag?

The only thing special in the tag is the prefix. The document is suggestive in it's use of secondary ":"s; however, I see no reason to "over-specify" (i.e., over-complicate) this.

> o  5.2
>
>   The module should be consistently formatted wrt whitespaces.
>
>   (e.g., you can try pyang --keep-comments -f yang)

Done.

> o  6
>
>   s/yang/YANG/

Done.

> o  6 and 3.3
>
>   When I read 3.3 I thought that the word "local" seemed odd, and was
>   going to suggest "user" instead.  It seems 8199 also uses
>   standard/vendor/user.  So, I suggest we change "local tags" to "user
>   tags".

Prior art, OK, Done.

> o  7.1
>
>    The module writer may use existing standard tags, or use new tags
>    defined in the model definition, as appropriate.  New tags should be
>    assigned in the IANA registry defined below, see Section 8.2 below.
>
>   Hmm, once the "new" tags are defined, they are IETF standard tags,
>   right?  So this text should really be:
>
>    The module writer must use only IETF standard tags
>
>   and also write that if new tags are needed, they MUST be
>   registered.

The intention was that the module author could use non-standardized tags if the module itself was not standardized.  The text now reads:

    The module writer may use existing standard tags, or use new
    tags defined in the model definition, as appropriate. For
    standardized modules new tags MUST be assigned in the IANA
    registry defined below, see 
    below.

> o  8.2
>
>   Remove the Editor's note.

Done.

>
> o  8.2
>
>   Why have both ietf:rfc8199:service and ietf:network-service?

They are different. A network-service is something like a DHCP server. I've added examples (NTP server, DHCP server, DNS server) to the description.

> o  References
>
>   You need to add RFC 7950 as a normative ref since you define a YANG
>   module.

I've added a reference to 6020, we can update to 7950 if there is some reason to require YANG 1.1.

Thanks,
Chris.

>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 16 11:45:19 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45C3130E2F for ; Tue, 16 Oct 2018 11:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 ymac7TRAwxXu for ; Tue, 16 Oct 2018 11:45:14 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 706CE130E25 for ; Tue, 16 Oct 2018 11:45:10 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id v7-v6so21914232ljg.5 for ; Tue, 16 Oct 2018 11:45:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=P/yVxqBjTZtfzAsg2RFFkUrYdoifVnHCVuXgxwwkRTQ=; b=bW6Iac82SAN5iASpptr2CeOiRg5diQdiY1RGYRG4Dw/Hp5Z6bndRdsOdEqVkMR7EHR CD4Ef27SjqFF1s20uPxmatCUaPMAiQDJpVGdKqX0OXsVmg2+cSDkR6IQ+kQRMaw7ziYv cPYWcRvhHu3M7+Mr68WKSLgOh/thcGBXTdaVgDbIc3WpGLVF5rJyUOMheAioxEojkGRg KVrJvpbN9sRVsy2dmc5w72pnyO4yfQeWk3da/rF8ZRPd3JENzdHCT1OtO2uhjYFfEGFE eWFwQk4Iop5WxZiLqOWy1TfdowQJQvZDZdP7NEskxdWf5U+gbHsQycaiQvhL7PXlOk1Y QyoA==
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=P/yVxqBjTZtfzAsg2RFFkUrYdoifVnHCVuXgxwwkRTQ=; b=mR4xj3LjSjT2NPOg6hpla/hDS4mEkb2ni1l7WkVa6MPgZ9grqTqLYFZN61pX43oH7S CO1ji/3Q/WbY4OZ/0jmgStRJMGYpVI44qasROQN7Yc559hHc05QLRmyZTMcc+AFssMIL U5hyfATx4tm4R6qCZNg4pnygc10nunoOaaxPKt3EN+4gJ+rpFTDtIng695Dzm7ulpBFs MUtagC3AW1SCO7Cmkg9M2QdNJSvVDsS4hXKcdy9UbWJmcZPA2V14K9UT9bvSb/QE60rT yaov1BcqK48j01idsObrpf32SL/RTBhTxuTgVbol7kLaRnNsR4DN68fqdmzzgNNwgBrc bDbA==
X-Gm-Message-State: ABuFfogbTEjFQoLWjbEj1DWQfQh1bX27uFfpFC6Sn0EoBcO8ZHVVIEfx 6W0THsYDaRt8CZQVEt3/vnWIopTwmxeXi5ATe8ie1w==
X-Google-Smtp-Source: ACcGV63so2e/GNZSoCtQcfORg3Dw2XlNRhNdR9w+oNiPucct86zmaYNAuZhuMY/gSNuv5D5TB8ZAaLSvcYG6QCX0bzc=
X-Received: by 2002:a2e:9796:: with SMTP id y22-v6mr2492522lji.20.1539715508382;  Tue, 16 Oct 2018 11:45:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Tue, 16 Oct 2018 11:45:07 -0700 (PDT)
In-Reply-To: <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Tue, 16 Oct 2018 11:45:07 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  Christian Hopps , joel jaeggli ,  NETMOD Working Group 
Content-Type: multipart/alternative; boundary="000000000000eec73405785cf3f5"
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 18:45:18 -0000

--000000000000eec73405785cf3f5
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
> >
> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > > - Standard tags defined in description statements
> > >
> > >  I do not like this. YANG has extension statements and having to
> > >  parse stuff out of free text description statements seems to be a
> > >  movement backwards.
> >
> > This is used by the human implementer of the module (i.e., they need to
> write code to implement the module). As such it was not intended for
> machine parsing.
> >
>
> I am personally not convinced. The whole reason why we have YANG is
> automation and I believe people will go and write tools to extract
> tags and having to extract them out of free form text looks like a
> step backwards.
>


It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag conformance,
in addition to the module-tag mappings.

All YANG designers are supposed to learn the exact text to write (not
free-form at all)
and this draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers are supposed to parse the description-stmt looking
for the
module-tag definitions. But instead, tool developers are going to say "Use
our
proprietary YANG extension because we are never going to parse description
statements"


> > > - System management
> > >
> > >  What is 'system management' and a 'system management protocol'?
> >
> > These were derived from the work the RtgYangDT originally did where we
> were organizing everything under a single device tree. This tree concept
> was (rightly) abandoned to be replaced with use of tags. Examples of
> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
> the description.
> >
>
> I am generally not a fan of definition by example. Is SSH a 'system
> management protocol'?
>


An example is not a definition.
The IETF is supposed to know the difference.



>
> > > - Tag format
> > >
> > >  Apparently, the colon has a special meaning in a tag string and
> > >  otherwise there do not seem to be any restrictions. (Which is good,
> > >  I can finally put various smileys on my gear.)
> > >
> > >  Should we state explicitly somewhere that a colon has a special
> > >  meaning and that tag strings are structured into a sequence of
> > >  'taggies' separated by colons? Or is definition by example good
> > >  enough?
> >
> > I think it's good enough. :)
>
> I am not convinced this will work well. My understanding is that other
> 'hashtags' also have restrictions - whitespace and punctuation
> characters are often excluded, it seems. Apparently ':' already means
> something special here. Should you later need more special meanings,
> you will love to have characters available that you can use. What
> about tags that include whitespace or control characters? Do we really
> want such tags?
>


Section 3 defines prefixes for different types of module tags
There is no actual definition of a module tag.
Is it UTF-8 encoding? US-ASCII? Is it structured such that a pattern could
be defined?
Is every protocol draft that uses module-tags somehow going to define their
own version?

I don't see how this draft provides enough interoperability to be useful.


> > > - Meaning of tag masks
> > >
> > >  Do masks mean a complete string match or can I mask along the prefix
> > >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
> > >  'vendor:acme:'?
> >
> > Exact match, I've added text to clarify this.
>
> OK. One obvious extension is then to have at some point in time tag
> match expressions, such as 'vendor:acme:*' (assuming that * is not
> a valid character for a tag, see above).
>
> /js
>
>

Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian =
Hopps wrote:

> 

> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers=
ity.de> wrote:



> > - Standard tags defined in description statements

> > 

> >=C2=A0 I do not like this. YANG has extension statements and havin=
g to

> >=C2=A0 parse stuff out of free text description statements seems t=
o be a

> >=C2=A0 movement backwards.

> 

> This is used by the human implementer of the module (i.e., they need t=
o write code to implement the module). As such it was not intended for mach=
ine parsing.

>



I am personally not convinced. The whole reason why we have YANG is

automation and I believe people will go and write tools to extract

tags and having to extract them out of free form text looks like a

step backwards.


It is mo=
re than a step backwards.
There is an unexplained procedure for d=
eclaring the =C2=A0module-tag conformance,
in addition to the mod=
ule-tag mappings.

All YANG designers are supposed =
to learn the exact text to write (not free-form at all)
and this =
draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers =
are supposed to parse the description-stmt looking for the
module=
-tag definitions. But instead, tool developers are going to say "Use o=
ur
proprietary YANG extension because we are never going to parse=
 description statements"




> > - System management

> > 

> >=C2=A0 What is 'system management' and a 'system manag=
ement protocol'?

> 

> These were derived from the work the RtgYangDT originally did where we=
 were organizing everything under a single device tree. This tree concept w=
as (rightly) abandoned to be replaced with use of tags. Examples of protoco=
ls would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to the d=
escription.

>



I am generally not a fan of definition by example. Is SSH a 'system

management protocol'?


An example is not a definition.
The IETF is supposed to know th=
e difference.

=C2=A0



> > - Tag format

> > 

> >=C2=A0 Apparently, the colon has a special meaning in a tag string=
 and

> >=C2=A0 otherwise there do not seem to be any restrictions. (Which =
is good,

> >=C2=A0 I can finally put various smileys on my gear.)

> > 

> >=C2=A0 Should we state explicitly somewhere that a colon has a spe=
cial

> >=C2=A0 meaning and that tag strings are structured into a sequence=
 of

> >=C2=A0 'taggies' separated by colons? Or is definition by =
example good

> >=C2=A0 enough?

> 

> I think it's good enough. :)



I am not convinced this will work well. My understanding is that other

'hashtags' also have restrictions - whitespace and punctuation

characters are often excluded, it seems. Apparently ':' already mea=
ns

something special here. Should you later need more special meanings,

you will love to have characters available that you can use. What

about tags that include whitespace or control characters? Do we really

want such tags?


Section =
3 defines prefixes for different types of module tags
There is no=
 actual definition of a module tag.
Is it UTF-8 encoding? US-ASCI=
I? Is it structured such that a pattern could be defined?
Is ever=
y protocol draft that uses module-tags somehow going to define their own ve=
rsion?

I don't see how this draft provides eno=
ugh interoperability to be useful.




> > - Meaning of tag masks

> > 

> >=C2=A0 Do masks mean a complete string match or can I mask along t=
he prefix

> >=C2=A0 hierarchy, i.e., 'vendor:acme:' masks everything st=
arting with

> >=C2=A0 'vendor:acme:'?

> 

> Exact match, I've added text to clarify this.



OK. One obvious extension is then to have at some point in time tag

match expressions, such as 'vendor:acme:*' (assuming that * is not<=
br>
a valid character for a tag, see above).



/js




Andy
=C2=A0

-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--000000000000eec73405785cf3f5--


From nobody Tue Oct 16 11:57:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFD9130E30 for ; Tue, 16 Oct 2018 11:57:05 -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] 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 S-Xd4-dA_3J9 for ; Tue, 16 Oct 2018 11:57:03 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 778EC130E27 for ; Tue, 16 Oct 2018 11:57:03 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8A4E86005A; Tue, 16 Oct 2018 18:57:02 +0000 (UTC)
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Juergen Schoenwaelder 
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group 
In-reply-to: <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>
Date: Tue, 16 Oct 2018 14:57:01 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 18:57:05 -0000

Juergen Schoenwaelder  writes:

> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>>
>> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder  wrote:
>
>> > - Standard tags defined in description statements
>> >
>> >  I do not like this. YANG has extension statements and having to
>> >  parse stuff out of free text description statements seems to be a
>> >  movement backwards.
>>
>> This is used by the human implementer of the module (i.e., they need to write code to implement the module). As such it was not intended for machine parsing.
>>
>
> I am personally not convinced. The whole reason why we have YANG is
> automation and I believe people will go and write tools to extract
> tags and having to extract them out of free form text looks like a
> step backwards.

I've now added an "module-tag" extension statement.

>> > - Tag format
>> >
>> >  Apparently, the colon has a special meaning in a tag string and
>> >  otherwise there do not seem to be any restrictions. (Which is good,
>> >  I can finally put various smileys on my gear.)
>> >
>> >  Should we state explicitly somewhere that a colon has a special
>> >  meaning and that tag strings are structured into a sequence of
>> >  'taggies' separated by colons? Or is definition by example good
>> >  enough?
>>
>> I think it's good enough. :)
>
> I am not convinced this will work well. My understanding is that other
> 'hashtags' also have restrictions - whitespace and punctuation
> characters are often excluded, it seems. Apparently ':' already means
> something special here. Should you later need more special meanings,
> you will love to have characters available that you can use. What
> about tags that include whitespace or control characters? Do we really
> want such tags?

I *really* want to stay away from over-specifying (over-complicating) this by imposing a lot of structure and rules. The text uses ":"s suggestively, but I'd rather remove that than start down the path of standardizing additional structure.

It probably would be useful to restrict the actual characters used in the string to avoid odd whitespace (e.g., tabs, newlines/carriage returns). Is there a standard type that just leaves these specific whitespace characters out? I was hesitant to just use something like yang identifier b/c I figured it might be useful for people to include non-ascii-like characters (umlats etc..)

Thanks,
Chris.

>> > - Meaning of tag masks
>> >
>> >  Do masks mean a complete string match or can I mask along the prefix
>> >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
>> >  'vendor:acme:'?
>>
>> Exact match, I've added text to clarify this.
>
> OK. One obvious extension is then to have at some point in time tag
> match expressions, such as 'vendor:acme:*' (assuming that * is not
> a valid character for a tag, see above).
>
> /js


From nobody Tue Oct 16 12:42:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DC8130E3B for ; Tue, 16 Oct 2018 12:42:52 -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] 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 alHG6GNhzcj9 for ; Tue, 16 Oct 2018 12:42:50 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 97163130E36 for ; Tue, 16 Oct 2018 12:42:50 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7B55F6005A; Tue, 16 Oct 2018 19:42:49 +0000 (UTC)
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de> 
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Andy Bierman 
Cc: Juergen Schoenwaelder , Christian Hopps , joel jaeggli , NETMOD Working Group 
In-reply-to: 
Date: Tue, 16 Oct 2018 15:42:48 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 19:42:53 -0000

Andy Bierman  writes:

> On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>> >
>> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>> > > - Standard tags defined in description statements
>> > >
>> > >  I do not like this. YANG has extension statements and having to
>> > >  parse stuff out of free text description statements seems to be a
>> > >  movement backwards.
>> >
>> > This is used by the human implementer of the module (i.e., they need to
>> write code to implement the module). As such it was not intended for
>> machine parsing.
>> >
>>
>> I am personally not convinced. The whole reason why we have YANG is
>> automation and I believe people will go and write tools to extract
>> tags and having to extract them out of free form text looks like a
>> step backwards.
>>
>
>
> It is more than a step backwards.
> There is an unexplained procedure for declaring the  module-tag conformance,
> in addition to the module-tag mappings.
>
> All YANG designers are supposed to learn the exact text to write (not
> free-form at all)
> and this draft updates 6087bis with procedures for declaring the module-tags
> in the description-stmt.
>
> Also, tool developers are supposed to parse the description-stmt looking
> for the
> module-tag definitions. But instead, tool developers are going to say "Use
> our
> proprietary YANG extension because we are never going to parse description
> statements"

I've added the extension statement.

>> > > - System management
>> > >
>> > >  What is 'system management' and a 'system management protocol'?
>> >
>> > These were derived from the work the RtgYangDT originally did where we
>> were organizing everything under a single device tree. This tree concept
>> was (rightly) abandoned to be replaced with use of tags. Examples of
>> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
>> the description.
>> >
>>
>> I am generally not a fan of definition by example. Is SSH a 'system
>> management protocol'?
>>
>
>
> An example is not a definition.
> The IETF is supposed to know the difference.

Do you have some suggestions for text that could replace the examples?

Some of these things seem painful obvious, like do we *really* need to define what we mean by a routing protocol?

Thanks,
Chris.


From nobody Tue Oct 16 13:11:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BC2130E37 for ; Tue, 16 Oct 2018 13:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 KwfO73mk0Qzm for ; Tue, 16 Oct 2018 13:11:13 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 A51DD130E36 for ; Tue, 16 Oct 2018 13:11:12 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id u21-v6so22128627lja.8 for ; Tue, 16 Oct 2018 13:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=60mHRPsHnFb/MV4bh6VvgcNQn96wNHVtebp0lQDoYL0=; b=tCdaGdEW/L2lacLICex4eHdzlj4qvSSPkKelAMUPl1vC5IgLuthJgKlTBlKVl9b87n Odn++An0GqXk4iY85j26utqVNGZ8804gydf2RhznoFnXb4xx6MaFFvZ0a7TuJQg6xrt4 TdvhLU456ImF/mWgsBs4/yY2ZCA99klAMnISwUsvYJCC2n23MutbO7Llm731kve6HWne zK7QzRUapA8pPCZ0l0gnhT6pRlrSxgJmPt8dR4ABY/lgog5SgWmab4vBMCPoP0u1L2MO T1rQH4mKJcwiQS+Njkvcak7xlPLdJ8nxMH6cAPbC2SIxW+g5iaEwhrN4yumV31dalgeU EEMQ==
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=60mHRPsHnFb/MV4bh6VvgcNQn96wNHVtebp0lQDoYL0=; b=e0fTQ6afx/9Uw4Cvk6Ps1qnb/b8BDq1PJoDdbayK4HEV4uDhXUGXvQS1boVVO2cgLN MF0mGDi0a0Kppiffp62y1ea0CmEWF7/nwMCb9EcGzt3tFVDYQjVccHaZ/u1WxNbIvlMH 1F70+XTb8TE5Ck/PKUTuK/d5ClUQMYMX254LgVD2o/7WEBVNzlQQiA5estW+2xNHVSIn /B7K+9fpqhB/V70rMZZ7mkImo9Z7c8PXIXw0hQfGmhVRcggHLhGiRS1wOl1lpv+Zmvm3 9s2PvTNH5CCatp1y1NiCB911o99LCWY2ClEIBcAZwG3fVyeQwn5NX5acgxrn+qvt1swu 91fg==
X-Gm-Message-State: ABuFfoitB7Wc/Qmb49Bv8H21LJtWBbcG0g/uQNHGAxLKlVC4D45uIF/o lmFHaSvwfyzgT3vA0W08eKP5J6Tg0mIaY+RZRSWjPsby
X-Google-Smtp-Source: ACcGV60yOq6njuU3BACnzyDdNfGKAYPqUcRDtGCMwmUrecNisiwvKfXrVoY51uVDbg50UxyKqq+IwJ0uEG8q76/JYSI=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr16305663lja.21.1539720670601;  Tue, 16 Oct 2018 13:11:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Tue, 16 Oct 2018 13:11:09 -0700 (PDT)
In-Reply-To: 
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>  
From: Andy Bierman 
Date: Tue, 16 Oct 2018 13:11:09 -0700
Message-ID: 
To: Christian Hopps 
Cc: Juergen Schoenwaelder , joel jaeggli , NETMOD Working Group 
Content-Type: multipart/alternative; boundary="0000000000009ff63105785e2792"
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 20:11:15 -0000

--0000000000009ff63105785e2792
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 16, 2018 at 12:42 PM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>>> >
>>> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> > > - Standard tags defined in description statements
>>> > >
>>> > >  I do not like this. YANG has extension statements and having to
>>> > >  parse stuff out of free text description statements seems to be a
>>> > >  movement backwards.
>>> >
>>> > This is used by the human implementer of the module (i.e., they need to
>>> write code to implement the module). As such it was not intended for
>>> machine parsing.
>>> >
>>>
>>> I am personally not convinced. The whole reason why we have YANG is
>>> automation and I believe people will go and write tools to extract
>>> tags and having to extract them out of free form text looks like a
>>> step backwards.
>>>
>>>
>>
>> It is more than a step backwards.
>> There is an unexplained procedure for declaring the  module-tag
>> conformance,
>> in addition to the module-tag mappings.
>>
>> All YANG designers are supposed to learn the exact text to write (not
>> free-form at all)
>> and this draft updates 6087bis with procedures for declaring the
>> module-tags
>> in the description-stmt.
>>
>> Also, tool developers are supposed to parse the description-stmt looking
>> for the
>> module-tag definitions. But instead, tool developers are going to say "Use
>> our
>> proprietary YANG extension because we are never going to parse description
>> statements"
>>
>
> I've added the extension statement.
>

good


>
> > > - System management
>>> > >
>>> > >  What is 'system management' and a 'system management protocol'?
>>> >
>>> > These were derived from the work the RtgYangDT originally did where we
>>> were organizing everything under a single device tree. This tree concept
>>> was (rightly) abandoned to be replaced with use of tags. Examples of
>>> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
>>> the description.
>>> >
>>>
>>> I am generally not a fan of definition by example. Is SSH a 'system
>>> management protocol'?
>>>
>>>
>>
>> An example is not a definition.
>> The IETF is supposed to know the difference.
>>
>
> Do you have some suggestions for text that could replace the examples?
>
> Some of these things seem painful obvious, like do we *really* need to
> define what we mean by a routing protocol?
>
>

This draft needs to define the module-tag encoding wrt/
   - valid characters (e.g., some subset of UTF-8)
   - min/max length (e.g., implementation MUST support at least 64 chars
and can support larger)

Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
structure to specify the naming authority.

According to the YANG module, the data type is a plain string, which
includes lots of
problematic chars and zero-length strings.

Does the string "routing" match "ietf:routing" or "vendor:routing"? How
about "routing:bgp"?
Is the char ":" allowed in a tag?
Is "vendor::::::::" a valid tag?

IMO this draft does not need to define any specific module-tag content but
it does need to define
in precise terms how a protocol encodes a module-tag and how a module-tag
match is determined.


Thanks,
> Chris.
>

Andy

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




On Tue, Oct 16, 2018 at 12:42 PM, Christian Hopps <=
;chopps@chopps.org> wrote:


Andy Bierman <an=
dy@yumaworks.com> writes:





On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <

j=
.schoenwaelder@jacobs-university.de> wrote:





On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:

>

> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <

j=
.schoenwaelder@jacobs-university.de> wrote:



> > - Standard tags defined in description statements

> >

> >=C2=A0 I do not like this. YANG has extension statements and havin=
g to

> >=C2=A0 parse stuff out of free text description statements seems t=
o be a

> >=C2=A0 movement backwards.

>

> This is used by the human implementer of the module (i.e., they need t=
o

write code to implement the module). As such it was not intended for

machine parsing.

>



I am personally not convinced. The whole reason why we have YANG is

automation and I believe people will go and write tools to extract

tags and having to extract them out of free form text looks like a

step backwards.









It is more than a step backwards.

There is an unexplained procedure for declaring the=C2=A0 module-tag confor=
mance,

in addition to the module-tag mappings.



All YANG designers are supposed to learn the exact text to write (not

free-form at all)

and this draft updates 6087bis with procedures for declaring the module-tag=
s

in the description-stmt.



Also, tool developers are supposed to parse the description-stmt looking
for the

module-tag definitions. But instead, tool developers are going to say "=
;Use

our

proprietary YANG extension because we are never going to parse description<=
br>
statements"





I've added the extension statement.

good
=C2=A0





> > - System management

> >

> >=C2=A0 What is 'system management' and a 'system manag=
ement protocol'?

>

> These were derived from the work the RtgYangDT originally did where we=


were organizing everything under a single device tree. This tree concept
was (rightly) abandoned to be replaced with use of tags. Examples of

protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that t=
o

the description.

>



I am generally not a fan of definition by example. Is SSH a 'system

management protocol'?









An example is not a definition.

The IETF is supposed to know the difference.





Do you have some suggestions for text that could replace the examples?



Some of these things seem painful obvious, like do we *really* need to defi=
ne what we mean by a routing protocol?




This draft needs to def=
ine the module-tag encoding wrt/
=C2=A0 =C2=A0- valid characters =
(e.g., some subset of UTF-8)
=C2=A0 =C2=A0- min/max length (e.g.,=
 implementation MUST support at least 64 chars and can support larger)

Section 3 (Tag Prefixes) seems to imply that all modul=
es tags follow a structure to specify the naming authority.

<=
/div>
According to the YANG module, the data type is a plain string, wh=
ich includes lots of
problematic chars and zero-length strings.

Does the string "routing" match "iet=
f:routing" or "vendor:routing"? How about "routing:bgp&=
quot;?
Is the char ":" allowed in a tag?=C2=A0
Is "vendor::::::::" a valid tag?

IMO t=
his draft does not need to define any specific module-tag content but it do=
es need to define
in precise terms how a protocol encodes a modul=
e-tag and how a module-tag match is determined.


Thanks,

Chris.



Andy



--0000000000009ff63105785e2792--


From nobody Tue Oct 16 13:28:01 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 932E0130E4F; Tue, 16 Oct 2018 13:27:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153972167959.9417.2591492950842010783.idtracker@ietfa.amsl.com>
Date: Tue, 16 Oct 2018 13:27:59 -0700
Archived-At: 
Subject: [netmod] The NETMOD WG has placed draft-kwatsen-netmod-artwork-folding in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 20:27:59 -0000

The NETMOD WG has placed draft-kwatsen-netmod-artwork-folding in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-folding/

Comment:
IPR poll started:


From nobody Tue Oct 16 13:41:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B086F130E42 for ; Tue, 16 Oct 2018 13:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slnfRl3Z4Lee for ; Tue, 16 Oct 2018 13:41:24 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 F2637130E3D for ; Tue, 16 Oct 2018 13:41:23 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id BD7D9140E8C for ; Tue, 16 Oct 2018 14:26:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id CVv5g5hTjd20TCVv5g3CkO; Tue, 16 Oct 2018 14:26:23 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gudoOtOrCAtiVE+ic6F/TU3/Ua1b132AH5v7ZqN71hE=; b=Al+FtLiloS9eV+8ZTLO5Xpostf ILrJ4lSpioCS8zw/lyV43uL11mDOVMglZtWrMhxh/Pfrb4LRlKdtq5BrZveg3dWizwJh41qgwEM9n pQL+e4l/rgev/iueeUSuGgYEy;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:40736 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gCVv5-001OBD-DE; Tue, 16 Oct 2018 14:26:23 -0600
From: Lou Berger 
To: Kent Watsen , Benoit Claise , bill.wu@huawei.com, afarrel@juniper.net
Cc: NetMod WG Chairs , NetMod WG 
Message-ID: 
Date: Tue, 16 Oct 2018 16:26:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gCVv5-001OBD-DE
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:40736
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 20:41:26 -0000

Authors, Contributors, WG,

As part of preparation for WG Adoption

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




From nobody Tue Oct 16 14:24:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB94130E46; Tue, 16 Oct 2018 14:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0FpB33vp6at; Tue, 16 Oct 2018 14:23:59 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 9CC50130E35; Tue, 16 Oct 2018 14:23:58 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9GLNl9X031449; Tue, 16 Oct 2018 22:23:47 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DEEAE2203B; Tue, 16 Oct 2018 22:23:46 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id C968F2203A; Tue, 16 Oct 2018 22:23:46 +0100 (BST)
Received: from 950129200 (4.43.114.87.dyn.plus.net [87.114.43.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9GLNjFS031338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2018 22:23:46 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Lou Berger'" , "'Kent Watsen'" ,  "'Benoit Claise'" , , 
Cc: "'NetMod WG Chairs'" , "'NetMod WG'" 
References: 
In-Reply-To: 
Date: Tue, 16 Oct 2018 22:23:47 +0100
Message-ID: <056c01d46596$874bd260$95e37720$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQI6eby6oK+EqSJZ0E1/T6GCOcbbRqRWOV2g
X-Originating-IP: 87.114.43.4
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24160.003
X-TM-AS-Result: No--14.474-10.0-31-10
X-imss-scan-details: No--14.474-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24160.003
X-TMASE-Result: 10--14.474100-10.000000
X-TMASE-MatchedRID: byfwvk+IcRnxIbpQ8BhdbOLdprnA5EQR+IfriO3cV8SObf10apLcScLm p4jPUF8t0GKpxI6So2kcmNdopTCzDMI1H91m7urhYPK6HbWWX3AsL3b83U5aWbV5fSMRD1zqPk7 szcK45eB5OyeMA/FqQW2YskIKD+qDXBtzGjIuBpm8coKUcaOOvbdO/3LnRgJ7u3gEBpQvABUY6B 4Aeuq7La2HNHnBof2ZVkyrSTMBmfBJdpt3T6o+M6mukiZOfPi2IZm2INWXDp6safcFLFlU1Kyqc SRToWuMjHWeNkD3ZMkeHK7zCEjkMJ1hipc7KZhnKWuiyZLRI4BNth7eneXK80X5hc8ioB2+Yfdo +TRWGhaPWZvDr+0qa881NvjC6w1UXwylrz/+EAOeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47hTZDO rzlZ+cHQdJ7XfU86eOwBXM346/+yUqXkwLVjHdrJfC6dqgD4Z+cu+cs+DZ4r3cLrGY20h89VVls E8py5G
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 21:24:01 -0000

Hi Lou,

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Adrian

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 16 October 2018 21:26
> To: Kent Watsen; Benoit Claise; bill.wu@huawei.com; afarrel@juniper.net
> Cc: NetMod WG Chairs; NetMod WG
> Subject: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
> 
> Authors, Contributors, WG,
> 
> As part of preparation for WG Adoption
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 16 14:52:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965C130E5D for ; Tue, 16 Oct 2018 14:52:28 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.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 u49xrjlwK4E9 for ; Tue, 16 Oct 2018 14:52:24 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 E9FBF130E4A for ; Tue, 16 Oct 2018 14:52:20 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id y10-v6so18210028lfj.1 for ; Tue, 16 Oct 2018 14:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G0ezwqOHv92tR2a71YKBQCScqSACaAa5ysnHAIDzb/g=; b=vWrSkdvinYtUDBQEESEOLDXvRHGrBo2lw4otPEJIlrX7FRwwbAJ0f264PRsOgVh1Ux o4a5MXqm8EAO445pFAKwXrysRW/DWqk3cvANZXDILIKCSQmgBVKs9TRc2bbjPdgdMR/v siDbZak1JHcpsL+jPy2c1gZY+9ujuMzSLhEEiYftcMJVRwRfX06EiaoYndn8rAojEAmH 17lj3O+MliLeg99oErq1ZvrSAlk+jd5UEtkapcVy1QVwwdd2JIrc5iaBlviLtBwPRbKJ 8qzKV/HYz4uTtQu0HK8Z81xK3y5jsNMVCIs8BrJ3GlIV7IsgFRZdESTaz/s8vwC0rtQy /R+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G0ezwqOHv92tR2a71YKBQCScqSACaAa5ysnHAIDzb/g=; b=BWVrfAQjP6byIa036kdhFoBY+SgbhOG1vsjq9AKr8e1IH5VOXhUbHA5k+NVCsi2s7m hkiFo9weBadKjltkHPpCGdRiXOoWg36uBtSP9ad7DGlnDKg2Tgzqo4s2TpRkTwqT8UTf 5MHvHmc+0BLAtidQBGy0ul2EC6gDATpBgstkAy1FRnRL5TCQOsWCZ7l/3W/qN88SdD0w Vkaqu95UOwwg9RcOmdyLSccQ9KqM6VfSrnBffzDOeoW8NOQoD57URLU0wiUAOYTMGlVt 2usCVPkWY1m5DpBH80XFbdqzbHck+XoA2t7+L8Dg5LjQsJHsMpPJ8Tj9mv0DziRspnEA UdnQ==
X-Gm-Message-State: ABuFfoi6IMlbTi2b2oGNnH2Vg0XIr9T7LfE+28oTeQt5uakEWaXsXTWU 1J2++elweFZinctBtF0zT+gHxcsPcxow9Rz0g5rXCw==
X-Google-Smtp-Source: ACcGV63pA4wY/c+cX+jXN/u+IpUCBltOfnDQeEbE4QAWk9Qy1ILiZu4gR7cB/a7/Q+pxXdDZd8YZapkME/uHyxNsxOo=
X-Received: by 2002:a19:a90f:: with SMTP id s15-v6mr13511381lfe.154.1539726739019;  Tue, 16 Oct 2018 14:52:19 -0700 (PDT)
MIME-Version: 1.0
References:  <20181011.091817.1727547509052700274.mbj@tail-f.com>  <20181016.144545.1184951335260453665.mbj@tail-f.com>  <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com>
In-Reply-To: <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com>
From: Eric Rescorla 
Date: Tue, 16 Oct 2018 14:51:41 -0700
Message-ID: 
To: joel jaeggli 
Cc: =?UTF-8?Q?martin_bj=C3=B6rklund?= , IESG ,  NetMod WG Chairs , NetMod WG ,  draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen ,  Lou Berger 
Content-Type: multipart/alternative; boundary="00000000000054d0a205785f91af"
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 21:52:29 -0000

--00000000000054d0a205785f91af
Content-Type: text/plain; charset="UTF-8"

OK, after reading your explanation and the example, I think I am clearer on
the use case and the text you propose seems appropriate. Why don't you
provide a new ID and I'll clear my DISCUSS

-Ekr


On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  wrote:

> On 10/16/18 06:00, Eric Rescorla wrote:
> > I'm sorry, but I still don't think I understand the security impacts of
> > this well enough to know if this text is OK.
> >
> > Can you provide a more detailed explanation of what XPath expressions
> > can and cannot do here? Happy to discuss live either on the phone or in
> BKK
> I'm probably grossly simplifying the goal here, but.
>
> xpath statement allow for referencing another path or applying
> constraints e.g. when / must (rfc 6020)
>
> the canonical example in 6020 being something like
>
>   container interface {
>       leaf ifType {
>           type enumeration {
>               enum ethernet;
>               enum atm;
>           }
>       }
>       leaf ifMTU {
>           type uint32;
>       }
>       must "ifType != 'ethernet' or " +
>            "(ifType = 'ethernet' and ifMTU = 1500)" {
>           error-message "An ethernet MTU must be 1500";
>       }
>       must "ifType != 'atm' or " +
>            "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
>           error-message "An atm MTU must be  64 .. 17966";
>       }
>
> http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath
>
> Imposing constraints using nodes in mounted modules is kind of a key
> application of schema-mount.
>
> > -Ekr
> >
> >
> > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > > wrote:
> >
> >     Hi,
> >
> >     Eric Rescorla > wrote:
> >     > That seems like it's going to have some pretty surprising
> >     consequences and
> >     > at minimum needs more information in the Security Considerations.
> >
> >     Ok.  Howabout we add a paragraph to the end of the Security
> >     Considerations section:
> >
> >       Care must be taken when the "parent-reference" XPath expressions
> are
> >       constructed, since the result of the evaluation of these
> expressions
> >       is added to the accessible tree for any XPath expression found in
> >       the mounted schema.
> >
> >
> >     /martin
> >
> >     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  >     > wrote:
> >     >
> >     > > Eric Rescorla > wrote:
> >     > > > I'm sorry but I don't understand this.
> >     > > >
> >     > > > Does the externally visible behavior of any mounted module
> >     depend in any
> >     > > > way on these XPATH references
> >     > >
> >     > > Yes, but note that these XPath expressions ("parent-reference")
> are
> >     > > read-only (config false in the YANG model).  Thus they are set
> >     by the
> >     > > implementation, and used to inform the operator about the
> >     environment
> >     > > in which other XPath expressions are evaluated.
> >     > >
> >     > >
> >     > > /martin
> >     > >
> >     > >
> >     > > >
> >     > > > -Ekr
> >     > > >
> >     > > >
> >     > > >
> >     > > >
> >     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> >     > wrote:
> >     > > >
> >     > > > > Eric Rescorla > wrote:
> >     > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
> >     >
> >     > > wrote:
> >     > > > > >
> >     > > > > > > Hi,
> >     > > > > > >
> >     > > > > > > Eric Rescorla >
> wrote:
> >     > > > > > > > Eric Rescorla has entered the following ballot
> >     position for
> >     > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> >     > > > > > > >
> >     > > > > > > > When responding, please keep the subject line intact
> >     and reply
> >     > > to all
> >     > > > > > > > email addresses included in the To and CC lines. (Feel
> >     free to
> >     > > cut
> >     > > > > this
> >     > > > > > > > introductory paragraph, however.)
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > > Please refer to
> >     > > > > > >
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >     > > > > > > > for more information about IESG DISCUSS and COMMENT
> >     positions.
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > > The document, along with other ballot positions, can
> >     be found
> >     > > here:
> >     > > > > > > >
> >     https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > >
> >     > > > >
> >
>  ----------------------------------------------------------------------
> >     > > > > > > > DISCUSS:
> >     > > > > > > >
> >     > > > >
> >
>  ----------------------------------------------------------------------
> >     > > > > > > >
> >     > > > > > > > Rich version of this review at:
> >     > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > >
> >     > > > > > > > DETAIL
> >     > > > > > > > S 4.
> >     > > > > > > > >
> >     > > > > > > > >      It is worth emphasizing that the nodes
> specified in
> >     > > > > > > > >      "parent-reference" leaf-list are available in
> >     the mounted
> >     > > > > schema
> >     > > > > > > only
> >     > > > > > > > >      for XPath evaluations.  In particular, they
> >     cannot be
> >     > > accessed
> >     > > > > > > there
> >     > > > > > > > >      via network management protocols such as NETCONF
> >     > > [RFC6241] or
> >     > > > > > > > >      RESTCONF [RFC8040].
> >     > > > > > > >
> >     > > > > > > > What are the security implications of this XPath
> reference
> >     > > outside
> >     > > > > the
> >     > > > > > > > mount jail? Specifically, how does it interact with
> >     the access
> >     > > > > control
> >     > > > > > > > for the enclosing module.
> >     > > > > > >
> >     > > > > > > There is no such interaction, since access control comes
> >     into play
> >     > > > > > > when some external entity accesses the data through some
> >     management
> >     > > > > > > protocol, and the nodes from the "parent-reference"
> >     expressions
> >     > > cannot
> >     > > > > > > be accessed via management protocols.
> >     > > > > > >
> >     > > > > > > The last sentence of the quoted paragraph was supposed
> >     to make this
> >     > > > > > > clear, but it seems we might need some additional
> >     explanation?
> >     > > > > > >
> >     > > > > >
> >     > > > > > Yes, I think so. I guess I'm not clear on what the XPath
> >     expressions
> >     > > are
> >     > > > > > for if they
> >     > > > > > can't be accessed via the management protocols. How can
> >     they be used?
> >     > > > >
> >     > > > > These are XPath expressions defined in the YANG models
> >     themselves,
> >     > > > > such as "must" expressions or "leafrefs".   The description
> of
> >     > > > > "parent-reference" refer to them as:
> >     > > > >
> >     > > > >                [...] XPath
> >     > > > >                expressions whose context nodes are defined
> >     in the
> >     > > > >                mounted schema
> >     > > > >
> >     > > > >
> >     > > > >
> >     > > > > /martin
> >     > > > >
> >     > >
> >
>
>
>

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


OK, after reading your explanation and the example, I=
 think I am clearer on the use case and the text you propose seems appropri=
ate. Why don't you provide a new ID and I'll clear my DISCUSS

-Ekr


On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli &l=
t;joelja@gmail.com> wrote:
On 10/16/18 06:00, Eric Rescorla wrote:<=
br>
> I'm sorry, but I still don't think I understand the security i=
mpacts of

> this well enough to know if this text is OK.

> 

> Can you provide a more detailed explanation of what XPath expressions<=
br>
> can and cannot do here? Happy to discuss live either on the phone or i=
n BKK

I'm probably grossly simplifying the goal here, but.



xpath statement allow for referencing another path or applying

constraints e.g. when / must (rfc 6020)



the canonical example in 6020 being something like



=C2=A0 container interface {

=C2=A0 =C2=A0 =C2=A0 leaf ifType {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum ethernet;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum atm;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 leaf ifMTU {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 must "ifType !=3D 'ethernet' or " +<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"(ifType =3D 'ethernet=
9; and ifMTU =3D 1500)" {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error-message "An ethernet MTU must=
 be 1500";

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 must "ifType !=3D 'atm' or " +

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"(ifType =3D 'atm' an=
d ifMTU <=3D 17966 and ifMTU >=3D 64)" {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error-message "An atm MTU must be=
=C2=A0 64 .. 17966";

=C2=A0 =C2=A0 =C2=A0 }



http://www.yang-central.o=
rg/twiki/pub/Main/YangDocuments/rfc6020.html#xpath



Imposing constraints using nodes in mounted modules is kind of a key

application of schema-mount.



> -Ekr

> 

> 

> On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund <mbj@tail-f.com

> <mailto:mbj@tai=
l-f.com>> wrote:

> 

>=C2=A0 =C2=A0 =C2=A0Hi,

> 

>=C2=A0 =C2=A0 =C2=A0Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0> That seems like it's going to have some pr=
etty surprising

>=C2=A0 =C2=A0 =C2=A0consequences and

>=C2=A0 =C2=A0 =C2=A0> at minimum needs more information in the Secur=
ity Considerations.

> 

>=C2=A0 =C2=A0 =C2=A0Ok.=C2=A0 Howabout we add a paragraph to the end of=
 the Security

>=C2=A0 =C2=A0 =C2=A0Considerations section:

> 

>=C2=A0 =C2=A0 =C2=A0=C2=A0 Care must be taken when the "parent-ref=
erence" XPath expressions are

>=C2=A0 =C2=A0 =C2=A0=C2=A0 constructed, since the result of the evaluat=
ion of these expressions

>=C2=A0 =C2=A0 =C2=A0=C2=A0 is added to the accessible tree for any XPat=
h expression found in

>=C2=A0 =C2=A0 =C2=A0=C2=A0 the mounted schema.

> 

> 

>=C2=A0 =C2=A0 =C2=A0/martin

> 

>=C2=A0 =C2=A0 =C2=A0> On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorkl=
und <mbj@tail-f.com<=
/a>

>=C2=A0 =C2=A0 =C2=A0<mailto:mbj@tail-f.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> > Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0> > > I'm sorry but I don't unders=
tand this.

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > > Does the externally visible behavior=
 of any mounted module

>=C2=A0 =C2=A0 =C2=A0depend in any

>=C2=A0 =C2=A0 =C2=A0> > > way on these XPATH references

>=C2=A0 =C2=A0 =C2=A0> >

>=C2=A0 =C2=A0 =C2=A0> > Yes, but note that these XPath expression=
s ("parent-reference") are

>=C2=A0 =C2=A0 =C2=A0> > read-only (config false in the YANG model=
).=C2=A0 Thus they are set

>=C2=A0 =C2=A0 =C2=A0by the

>=C2=A0 =C2=A0 =C2=A0> > implementation, and used to inform the op=
erator about the

>=C2=A0 =C2=A0 =C2=A0environment

>=C2=A0 =C2=A0 =C2=A0> > in which other XPath expressions are eval=
uated.

>=C2=A0 =C2=A0 =C2=A0> >

>=C2=A0 =C2=A0 =C2=A0> >

>=C2=A0 =C2=A0 =C2=A0> > /martin

>=C2=A0 =C2=A0 =C2=A0> >

>=C2=A0 =C2=A0 =C2=A0> >

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > > -Ekr

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > > On Wed, Oct 10, 2018 at 6:38 AM Mart=
in Bjorklund

>=C2=A0 =C2=A0 =C2=A0<mbj@tail-f.com <mailto:mbj@tail-f.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0> > >

>=C2=A0 =C2=A0 =C2=A0> > > > Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0> > > > > On Wed, Oct 10, 2018 at 5:=
32 AM Martin Bjorklund

>=C2=A0 =C2=A0 =C2=A0<mbj@tail-f.com <mailto:mbj@tail-f.com>>

>=C2=A0 =C2=A0 =C2=A0> > wrote:

>=C2=A0 =C2=A0 =C2=A0> > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > Hi,

>=C2=A0 =C2=A0 =C2=A0> > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > Eric Rescorla <ekr@rtfm.com <mailto:=
ekr@rtfm.com>> =
wrote:

>=C2=A0 =C2=A0 =C2=A0> > > > > > > Eric Rescorla ha=
s entered the following ballot

>=C2=A0 =C2=A0 =C2=A0position for

>=C2=A0 =C2=A0 =C2=A0> > > > > > > draft-ietf-netmo=
d-schema-mount-11: Discuss

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > When responding,=
 please keep the subject line intact

>=C2=A0 =C2=A0 =C2=A0and reply

>=C2=A0 =C2=A0 =C2=A0> > to all

>=C2=A0 =C2=A0 =C2=A0> > > > > > > email addresses =
included in the To and CC lines. (Feel

>=C2=A0 =C2=A0 =C2=A0free to

>=C2=A0 =C2=A0 =C2=A0> > cut

>=C2=A0 =C2=A0 =C2=A0> > > > this

>=C2=A0 =C2=A0 =C2=A0> > > > > > > introductory par=
agraph, however.)

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > Please refer to<=
br>
>=C2=A0 =C2=A0 =C2=A0> > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
>=C2=A0 =C2=A0 =C2=A0> > > > > > > for more informa=
tion about IESG DISCUSS and COMMENT

>=C2=A0 =C2=A0 =C2=A0positions.

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > The document, al=
ong with other ballot positions, can

>=C2=A0 =C2=A0 =C2=A0be found

>=C2=A0 =C2=A0 =C2=A0> > here:

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0https://data=
tracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------=
-------------------

>=C2=A0 =C2=A0 =C2=A0> > > > > > > DISCUSS:

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0---------------------------------------------------=
-------------------

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > Rich version of =
this review at:

>=C2=A0 =C2=A0 =C2=A0> > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > DETAIL

>=C2=A0 =C2=A0 =C2=A0> > > > > > > S 4.

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=
=A0 =C2=A0 It is worth emphasizing that the nodes specified in

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=
=A0 =C2=A0 "parent-reference" leaf-list are available in

>=C2=A0 =C2=A0 =C2=A0the mounted

>=C2=A0 =C2=A0 =C2=A0> > > > schema

>=C2=A0 =C2=A0 =C2=A0> > > > > > only

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=
=A0 =C2=A0 for XPath evaluations.=C2=A0 In particular, they

>=C2=A0 =C2=A0 =C2=A0cannot be

>=C2=A0 =C2=A0 =C2=A0> > accessed

>=C2=A0 =C2=A0 =C2=A0> > > > > > there

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=
=A0 =C2=A0 via network management protocols such as NETCONF

>=C2=A0 =C2=A0 =C2=A0> > [RFC6241] or

>=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=
=A0 =C2=A0 RESTCONF [RFC8040].

>=C2=A0 =C2=A0 =C2=A0> > > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > > What are the sec=
urity implications of this XPath reference

>=C2=A0 =C2=A0 =C2=A0> > outside

>=C2=A0 =C2=A0 =C2=A0> > > > the

>=C2=A0 =C2=A0 =C2=A0> > > > > > > mount jail? Spec=
ifically, how does it interact with

>=C2=A0 =C2=A0 =C2=A0the access

>=C2=A0 =C2=A0 =C2=A0> > > > control

>=C2=A0 =C2=A0 =C2=A0> > > > > > > for the enclosin=
g module.

>=C2=A0 =C2=A0 =C2=A0> > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > There is no such inte=
raction, since access control comes

>=C2=A0 =C2=A0 =C2=A0into play

>=C2=A0 =C2=A0 =C2=A0> > > > > > when some external en=
tity accesses the data through some

>=C2=A0 =C2=A0 =C2=A0management

>=C2=A0 =C2=A0 =C2=A0> > > > > > protocol, and the nod=
es from the "parent-reference"

>=C2=A0 =C2=A0 =C2=A0expressions

>=C2=A0 =C2=A0 =C2=A0> > cannot

>=C2=A0 =C2=A0 =C2=A0> > > > > > be accessed via manag=
ement protocols.

>=C2=A0 =C2=A0 =C2=A0> > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > > The last sentence of =
the quoted paragraph was supposed

>=C2=A0 =C2=A0 =C2=A0to make this

>=C2=A0 =C2=A0 =C2=A0> > > > > > clear, but it seems w=
e might need some additional

>=C2=A0 =C2=A0 =C2=A0explanation?

>=C2=A0 =C2=A0 =C2=A0> > > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > >

>=C2=A0 =C2=A0 =C2=A0> > > > > Yes, I think so. I guess I=
'm not clear on what the XPath

>=C2=A0 =C2=A0 =C2=A0expressions

>=C2=A0 =C2=A0 =C2=A0> > are

>=C2=A0 =C2=A0 =C2=A0> > > > > for if they

>=C2=A0 =C2=A0 =C2=A0> > > > > can't be accessed via =
the management protocols. How can

>=C2=A0 =C2=A0 =C2=A0they be used?

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> > > > These are XPath expressions def=
ined in the YANG models

>=C2=A0 =C2=A0 =C2=A0themselves,

>=C2=A0 =C2=A0 =C2=A0> > > > such as "must" expres=
sions or "leafrefs".=C2=A0 =C2=A0The description of

>=C2=A0 =C2=A0 =C2=A0> > > > "parent-reference" re=
fer to them as:

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 [...] XPath

>=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 expressions whose context nodes are defined

>=C2=A0 =C2=A0 =C2=A0in the

>=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 mounted schema

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> > > > /martin

>=C2=A0 =C2=A0 =C2=A0> > > >

>=C2=A0 =C2=A0 =C2=A0> >

> 








--00000000000054d0a205785f91af--


From nobody Tue Oct 16 14:54:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D141130E73; Tue, 16 Oct 2018 14:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R-7pq_vw36k; Tue, 16 Oct 2018 14:54:12 -0700 (PDT)
Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 057BD130E46; Tue, 16 Oct 2018 14:54:12 -0700 (PDT)
Received: by mail-pl1-x641.google.com with SMTP id y11-v6so11637733plt.3; Tue, 16 Oct 2018 14:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Cngt926I9SVXthWfNXe5RsyhHrj9yKno4jXju21Lj/A=; b=l4S9iTBS/9LBhn0KddiOITBlvuzZf09Cx7axoqDNrpuOohGr0jMLFDzq9EaPCcxcQy C55aOpZxWXpDKd5cz20o3kXxzclVktZao7euCMMEP59uHCpoHdkGJ4ppt3vs0zfu2z8v lZ0EIcu0+SRxajKFdhU7pwRwKsj1gyEOcWsH/AJLm3Clr0qWCzLF2nMFDZ9gqzl71BDE gb8qRU7xjC9KD9uLFxCdU9YLgreOLStade6e43xYob/AdNYB3tbNTwfEJDpb+h95PRdM FbRWBFjwI8zJhSq8sBO9PnXq0PaYhvOk6pwhbKsEYTcHwyOpjsDmGVnxPTq+WhkpB6ja +aLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Cngt926I9SVXthWfNXe5RsyhHrj9yKno4jXju21Lj/A=; b=olc96FPrCZrzgscL/lSSqI9TBQhw7YoVoxqSwGVHSwHIEz2LD9y9Z17Xh+wE1kFF2m iQDKE7Fx4h1o+R1Cua9/0g2jTgNX+jqY6DNu5eQEjnQ400hmc8egLCRGB+n+L9lAfXKR DGT62rErbAhWgSo+/TCDHxaxBs4c+qJCStcA1MtRBmvshcp8oQfHsS7z/RP4fAlDwI/0 /V80UM//BGIW8iO2Ck+8I3/VuLVfvpBzPM5YvTFCp3ov3+AO1Cnu88a1n9JgHA9l3f5O tnWJxj95/Otljyf6fmi9O0K4UbfRotE896t+6PBm53FoiykWBvTaeNH01SIl/uCL/rNR 9/4g==
X-Gm-Message-State: ABuFfoja5M4hcNwNJqtXip+c4onzEDyfQHY61Wct5/trNma3FkxSBZjL kv/mUHAhi8yBzSwEeQm6U01B37i5ZZA=
X-Google-Smtp-Source: ACcGV62rKzY25HzuvTayyNVz7h4xBa1RwZWWbSoNNQgvn6nZF7UdP4V14CIcQNWVdBA+Ajl6aFaJGQ==
X-Received: by 2002:a17:902:5a89:: with SMTP id r9-v6mr22893627pli.95.1539726851282;  Tue, 16 Oct 2018 14:54:11 -0700 (PDT)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net. [73.202.177.209]) by smtp.googlemail.com with ESMTPSA id b62-v6sm30740969pfa.159.2018.10.16.14.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 14:54:10 -0700 (PDT)
To: Eric Rescorla 
Cc: =?UTF-8?Q?martin_bj=c3=b6rklund?= , IESG ,  NetMod WG Chairs , NetMod WG , draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen , Lou Berger 
References:  <20181011.091817.1727547509052700274.mbj@tail-f.com>  <20181016.144545.1184951335260453665.mbj@tail-f.com>  <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com> 
From: joel jaeggli 
Openpgp: preference=signencrypt
Autocrypt: addr=joelja@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w=
Message-ID: 
Date: Tue, 16 Oct 2018 14:54:07 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRNKmZJ7VK08eE7GmCCODjoUqg4dfxqDO"
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 21:54:16 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GRNKmZJ7VK08eE7GmCCODjoUqg4dfxqDO
Content-Type: multipart/mixed; boundary="dAHQdIuXCAeupmDj43Lgw4nXQz14jY0bZ";
 protected-headers="v1"
From: joel jaeggli 
To: Eric Rescorla 
Cc: =?UTF-8?Q?martin_bj=c3=b6rklund?= , IESG ,
 NetMod WG Chairs , NetMod WG ,
 draft-ietf-netmod-schema-mount@ietf.org, Kent Watsen ,
 Lou Berger 
Message-ID: 
Subject: Re: Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11:
 (with DISCUSS)
References: 
 <20181011.091817.1727547509052700274.mbj@tail-f.com>
 
 <20181016.144545.1184951335260453665.mbj@tail-f.com>
 
 <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com>
 
In-Reply-To: 

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

On 10/16/18 14:51, Eric Rescorla wrote:
> OK, after reading your explanation and the example, I think I am cleare=
r
> on the use case and the text you propose seems appropriate. Why don't
> you provide a new ID and I'll clear my DISCUSS

Thanks I think the authors will have that out shortly.

joel

> -Ekr
>=20
>=20
> On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  > wrote:
>=20
>     On 10/16/18 06:00, Eric Rescorla wrote:
>     > I'm sorry, but I still don't think I understand the security
>     impacts of
>     > this well enough to know if this text is OK.
>     >
>     > Can you provide a more detailed explanation of what XPath express=
ions
>     > can and cannot do here? Happy to discuss live either on the phone=

>     or in BKK
>     I'm probably grossly simplifying the goal here, but.
>=20
>     xpath statement allow for referencing another path or applying
>     constraints e.g. when / must (rfc 6020)
>=20
>     the canonical example in 6020 being something like
>=20
>     =C2=A0 container interface {
>     =C2=A0 =C2=A0 =C2=A0 leaf ifType {
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum ethernet;
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum atm;
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>     =C2=A0 =C2=A0 =C2=A0 }
>     =C2=A0 =C2=A0 =C2=A0 leaf ifMTU {
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;
>     =C2=A0 =C2=A0 =C2=A0 }
>     =C2=A0 =C2=A0 =C2=A0 must "ifType !=3D 'ethernet' or " +
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"(ifType =3D 'ethernet' an=
d ifMTU =3D 1500)" {
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error-message "An ethernet MTU m=
ust be 1500";
>     =C2=A0 =C2=A0 =C2=A0 }
>     =C2=A0 =C2=A0 =C2=A0 must "ifType !=3D 'atm' or " +
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"(ifType =3D 'atm' and ifM=
TU <=3D 17966 and ifMTU >=3D 64)" {
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error-message "An atm MTU must b=
e=C2=A0 64 .. 17966";
>     =C2=A0 =C2=A0 =C2=A0 }
>=20
>     http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.ht=
ml#xpath
>=20
>     Imposing constraints using nodes in mounted modules is kind of a ke=
y
>     application of schema-mount.
>=20
>     > -Ekr
>     >
>     >
>     > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund      
>     > >> wrote:
>     >
>     >=C2=A0 =C2=A0 =C2=A0Hi,
>     >
>     >=C2=A0 =C2=A0 =C2=A0Eric Rescorla 
>     >> wrote:
>     >=C2=A0 =C2=A0 =C2=A0> That seems like it's going to have some pret=
ty surprising
>     >=C2=A0 =C2=A0 =C2=A0consequences and
>     >=C2=A0 =C2=A0 =C2=A0> at minimum needs more information in the Sec=
urity
>     Considerations.
>     >
>     >=C2=A0 =C2=A0 =C2=A0Ok.=C2=A0 Howabout we add a paragraph to the e=
nd of the Security
>     >=C2=A0 =C2=A0 =C2=A0Considerations section:
>     >
>     >=C2=A0 =C2=A0 =C2=A0=C2=A0 Care must be taken when the "parent-ref=
erence" XPath
>     expressions are
>     >=C2=A0 =C2=A0 =C2=A0=C2=A0 constructed, since the result of the ev=
aluation of these
>     expressions
>     >=C2=A0 =C2=A0 =C2=A0=C2=A0 is added to the accessible tree for any=
 XPath expression
>     found in
>     >=C2=A0 =C2=A0 =C2=A0=C2=A0 the mounted schema.
>     >
>     >
>     >=C2=A0 =C2=A0 =C2=A0/martin
>     >
>     >=C2=A0 =C2=A0 =C2=A0> On Thu, Oct 11, 2018 at 12:18 AM Martin Bjor=
klund
>     
>     >=C2=A0 =C2=A0 =C2=A0=
>> wrote:
>     >=C2=A0 =C2=A0 =C2=A0>
>     >=C2=A0 =C2=A0 =C2=A0> > Eric Rescorla 
>     >> wrote:
>     >=C2=A0 =C2=A0 =C2=A0> > > I'm sorry but I don't understand this.
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > > Does the externally visible behavior of =
any mounted module
>     >=C2=A0 =C2=A0 =C2=A0depend in any
>     >=C2=A0 =C2=A0 =C2=A0> > > way on these XPATH references
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >=C2=A0 =C2=A0 =C2=A0> > Yes, but note that these XPath expressions=

>     ("parent-reference") are
>     >=C2=A0 =C2=A0 =C2=A0> > read-only (config false in the YANG model)=
=2E=C2=A0 Thus they are set
>     >=C2=A0 =C2=A0 =C2=A0by the
>     >=C2=A0 =C2=A0 =C2=A0> > implementation, and used to inform the ope=
rator about the
>     >=C2=A0 =C2=A0 =C2=A0environment
>     >=C2=A0 =C2=A0 =C2=A0> > in which other XPath expressions are evalu=
ated.
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >=C2=A0 =C2=A0 =C2=A0> > /martin
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > > -Ekr
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > > On Wed, Oct 10, 2018 at 6:38 AM Martin B=
jorklund
>     >=C2=A0 =C2=A0 =C2=A0      >> wrote:
>     >=C2=A0 =C2=A0 =C2=A0> > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > Eric Rescorla 
>     >> wrote:
>     >=C2=A0 =C2=A0 =C2=A0> > > > > On Wed, Oct 10, 2018 at 5:32 AM Mart=
in Bjorklund
>     >=C2=A0 =C2=A0 =C2=A0      >>
>     >=C2=A0 =C2=A0 =C2=A0> > wrote:
>     >=C2=A0 =C2=A0 =C2=A0> > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > Hi,
>     >=C2=A0 =C2=A0 =C2=A0> > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > Eric Rescorla 
>     >> wrote:
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > Eric Rescorla has entered the fo=
llowing ballot
>     >=C2=A0 =C2=A0 =C2=A0position for
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > draft-ietf-netmod-schema-mount-1=
1: Discuss
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > When responding, please keep the=
 subject line intact
>     >=C2=A0 =C2=A0 =C2=A0and reply
>     >=C2=A0 =C2=A0 =C2=A0> > to all
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > email addresses included in the =
To and CC lines.
>     (Feel
>     >=C2=A0 =C2=A0 =C2=A0free to
>     >=C2=A0 =C2=A0 =C2=A0> > cut
>     >=C2=A0 =C2=A0 =C2=A0> > > > this
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > introductory paragraph, however.=
)
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > Please refer to
>     >=C2=A0 =C2=A0 =C2=A0> > > > > >
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > for more information about IESG =
DISCUSS and COMMENT
>     >=C2=A0 =C2=A0 =C2=A0positions.
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > The document, along with other b=
allot positions, can
>     >=C2=A0 =C2=A0 =C2=A0be found
>     >=C2=A0 =C2=A0 =C2=A0> > here:
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ne=
tmod-schema-mount/
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0
>     =C2=A0-------------------------------------------------------------=
---------
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > DISCUSS:
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0
>     =C2=A0-------------------------------------------------------------=
---------
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > Rich version of this review at:
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > https://mozphab-ietf.devsvcdev.m=
ozaws.net/D3506
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > DETAIL
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > S 4.
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=A0 =C2=A0 It is wort=
h emphasizing that the nodes
>     specified in
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=A0 =C2=A0 "parent-re=
ference" leaf-list are available in
>     >=C2=A0 =C2=A0 =C2=A0the mounted
>     >=C2=A0 =C2=A0 =C2=A0> > > > schema
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > only
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=A0 =C2=A0 for XPath =
evaluations.=C2=A0 In particular, they
>     >=C2=A0 =C2=A0 =C2=A0cannot be
>     >=C2=A0 =C2=A0 =C2=A0> > accessed
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > there
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=A0 =C2=A0 via networ=
k management protocols such as
>     NETCONF
>     >=C2=A0 =C2=A0 =C2=A0> > [RFC6241] or
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > >=C2=A0 =C2=A0 =C2=A0 RESTCONF [=
RFC8040].
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > What are the security implicatio=
ns of this XPath
>     reference
>     >=C2=A0 =C2=A0 =C2=A0> > outside
>     >=C2=A0 =C2=A0 =C2=A0> > > > the
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > mount jail? Specifically, how do=
es it interact with
>     >=C2=A0 =C2=A0 =C2=A0the access
>     >=C2=A0 =C2=A0 =C2=A0> > > > control
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > > for the enclosing module.
>     >=C2=A0 =C2=A0 =C2=A0> > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > There is no such interaction, sinc=
e access control
>     comes
>     >=C2=A0 =C2=A0 =C2=A0into play
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > when some external entity accesses=
 the data
>     through some
>     >=C2=A0 =C2=A0 =C2=A0management
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > protocol, and the nodes from the "=
parent-reference"
>     >=C2=A0 =C2=A0 =C2=A0expressions
>     >=C2=A0 =C2=A0 =C2=A0> > cannot
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > be accessed via management protoco=
ls.
>     >=C2=A0 =C2=A0 =C2=A0> > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > The last sentence of the quoted pa=
ragraph was supposed
>     >=C2=A0 =C2=A0 =C2=A0to make this
>     >=C2=A0 =C2=A0 =C2=A0> > > > > > clear, but it seems we might need =
some additional
>     >=C2=A0 =C2=A0 =C2=A0explanation?
>     >=C2=A0 =C2=A0 =C2=A0> > > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > > Yes, I think so. I guess I'm not cle=
ar on what the XPath
>     >=C2=A0 =C2=A0 =C2=A0expressions
>     >=C2=A0 =C2=A0 =C2=A0> > are
>     >=C2=A0 =C2=A0 =C2=A0> > > > > for if they
>     >=C2=A0 =C2=A0 =C2=A0> > > > > can't be accessed via the management=
 protocols. How can
>     >=C2=A0 =C2=A0 =C2=A0they be used?
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > These are XPath expressions defined in=
 the YANG models
>     >=C2=A0 =C2=A0 =C2=A0themselves,
>     >=C2=A0 =C2=A0 =C2=A0> > > > such as "must" expressions or "leafref=
s".=C2=A0 =C2=A0The
>     description of
>     >=C2=A0 =C2=A0 =C2=A0> > > > "parent-reference" refer to them as:
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 [...] XPath
>     >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 expressions whose context nodes are defined
>     >=C2=A0 =C2=A0 =C2=A0in the
>     >=C2=A0 =C2=A0 =C2=A0> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 mounted schema
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> > > > /martin
>     >=C2=A0 =C2=A0 =C2=A0> > > >
>     >=C2=A0 =C2=A0 =C2=A0> >
>     >
>=20
>=20



--dAHQdIuXCAeupmDj43Lgw4nXQz14jY0bZ--

--GRNKmZJ7VK08eE7GmCCODjoUqg4dfxqDO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCW8Zd/wAKCRDwADWrtn9W
sjuAAJ9e0L0Wk5xKFEz7uqgUfPKwR5+KbACfeqmNaJltMcvD1ahdeOoLgGTjOPQ=
=x//6
-----END PGP SIGNATURE-----

--GRNKmZJ7VK08eE7GmCCODjoUqg4dfxqDO--


From nobody Tue Oct 16 14:56:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24316130E51; Tue, 16 Oct 2018 14:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level: 
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeoRrpK7JVA; Tue, 16 Oct 2018 14:56:43 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3A1130E4B; Tue, 16 Oct 2018 14:56:42 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9GLtIkw011119; Tue, 16 Oct 2018 14:56:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=fyz44cmrRfP9DC7Jm5aArGUR/goTvdwZgTRdlgr4O78=; b=gA/bSaZNEHqJvnL4B0bImMYuGNSErs58Oyyhu2uJ/DfdlPGgHmNDQyMuUSEYyoo2upU4 xr8dIEwbp9ph/s7FHSX7EPiiIjyFLsUPeKsj8gisr/yBGjrd91qZNbXXD8NX0UYEydh7 EIXOBunEOUiCG0SNH8xUNAPBwvaxl9O0yybb4bMaKZUM/9PcxSkiKjv5MKuSO9Ei9YYY wV+OtkfazhcWWIe8gQ2Qq/wZx4ZIqTvnjtGz0kiC8ALasrDJsiu8xC+E+W+eAfU9b5F4 GR9bTgydvKWf00Qpq5B8/LJTJKitnchdKPMZ08KYhuko3guYib0CQhHyzyLsV+vBsA4l VA== 
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) by mx0b-00273201.pphosted.com with ESMTP id 2n5mex8eyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Oct 2018 14:56:37 -0700
Received: from BYAPR05MB4664.namprd05.prod.outlook.com (52.135.233.78) by BYAPR05MB5575.namprd05.prod.outlook.com (20.177.186.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.26; Tue, 16 Oct 2018 21:56:34 +0000
Received: from BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::812b:820c:a928:78a6]) by BYAPR05MB4664.namprd05.prod.outlook.com ([fe80::812b:820c:a928:78a6%3]) with mapi id 15.20.1250.014; Tue, 16 Oct 2018 21:56:14 +0000
From: Kent Watsen 
To: "adrian@olddog.co.uk" , 'Lou Berger' , 'Benoit Claise' , "bill.wu@huawei.com" , Adrian Farrel 
CC: 'NetMod WG Chairs' , 'NetMod WG' 
Thread-Topic: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZY6I5LhbhRNoSE+s2fqNNYsKoqUiYe+A///GIgA=
Date: Tue, 16 Oct 2018 21:56:13 +0000
Message-ID: <34042279-8A05-4D95-9452-D2634E6408AF@juniper.net>
References:  <056c01d46596$874bd260$95e37720$@olddog.co.uk>
In-Reply-To: <056c01d46596$874bd260$95e37720$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB5575; 6:iry+pSkTwQ8P3vGWyFq3RovpAMJQ0L4jDkMT1zbHRnXExjBaIaQHHIG/VuOqbI+pqg3w477szpEc9KWvqji1tsWePadG/0Dt547h03gkfNls8HYl6ZP5MmIAx0tlEymcsD480s58wF+4D7Jk9GoMjv5IIj6sTK09FkglHZ1BDQB0n29FaYa1IMyQwT+5sDwfRS9q5M9wIdGNJkS/GyNv31+wXuwR6y4CNQCO/Cn73RbcU4JfOvdFjWQg9svCoSMpQWSKH+WnN9kiKMo7ZHxsUr6nu44suthitongW0SureZW3kuTRbO9BfxKjsutiokk1fwMHJfbtpW8FAxV6uOzXWM7dLBd8esDnEXm9gwAAKgCs7GAwoFW6JFIeyr4JzG5a6xKoxOxsP7c7FSUeII3Fnj0Hkk9B7RtYYIdMA70sxUJ0xawHzz1enjvCRgs5ssORUXndggjqmM9cvSMnfkd9g==; 5:CRK21zn1DHZy3dTa52A86vbIqUXuV6DnLLp+0h/B6SsZ0BVznQ4qn5OcpNsPnXlfcPRrOA6TUPmUYT/lVSOK5uIOpJ1jwyIZafW+FT/9w0UjhHCVQJF+u5wnx6rDb5ZbjIKPCMyhM0OEqn/YISuIEUKT8Qe9lnyfFnOqp8wMPyg=; 7:OXow5TVYpHCgcUq3penqfOQXDUjjEtPJPf8Ab6UAexQt7J/60kbZ8AmZRsI14vAzEbxexzfuy8nK7oJsSdqxrWkSq5gDIbVrP2G71e0QPOOfLmdPLg3IOyaOfDSe1nR2/YF+wVm3rlhp9/NYoBMXIBavQL2o/XeDfhQtX3XmnRN0lXROlgcH4BArpcDO89LFZg6bEB1ykqNYg+Y5eaEa+vxHFZeiZ31oJnHLG33ymh008fkRJEmIbxs0V8F26qni
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(39860400002)(136003)(13464003)(189003)(199004)(4326008)(68736007)(6486002)(6436002)(5250100002)(81166006)(6246003)(81156014)(33656002)(476003)(6306002)(6512007)(11346002)(14454004)(305945005)(8936002)(446003)(8676002)(2616005)(110136005)(58126008)(76176011)(86362001)(6636002)(99286004)(6506007)(25786009)(575784001)(186003)(53546011)(54906003)(36756003)(2501003)(6346003)(82746002)(102836004)(229853002)(26005)(478600001)(97736004)(7736002)(2906002)(83716004)(5660300001)(105586002)(2900100001)(256004)(316002)(1941001)(66066001)(53936002)(71190400001)(106356001)(6116002)(486006)(71200400001)(966005)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5575; H:BYAPR05MB4664.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
x-ms-office365-filtering-correlation-id: 5b2582a9-5503-47f1-c164-08d633b2311e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5575; 
x-ms-traffictypediagnostic: BYAPR05MB5575:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(50582790962513)(138986009662008)(10436049006162)(95692535739014); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4982022)(52105095)(6055026)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991077); SRVR:BYAPR05MB5575; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5575; 
x-forefront-prvs: 0827D7ACB9
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: l67WeCVtAVU5lwRodPx/Et70v788Q2K1qVL1SHBxhUFwjn24BoDn1yoO7ikDO8UpBI5zvvIK3Sj7oh5/+mKnjNM3sEAzktx/SU9LaxizcjgDuJE3lZFV+nz0oIcBZOGzYZagg9KUP2/ze09oAHZIssgDUCKSn0+iHkl76hjeCIbeaYfD76Fll2qQfS8lY3poLTRzuZZR/mRX/fyaIs8jBnM06xPNmyB/oCHErdPiUXabNJ+gG/9TlRp0DEJnqHKGY55ufF+nzZUQjoc/iFcYbhs5x42U229sMtM5xlrshElk6qmnSpSr41Mr/+qd97n+tiSbyCO3Uo4PoqWfSKZ2+eyd3T/pEaD8+kLnihhEfS8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b2582a9-5503-47f1-c164-08d633b2311e
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2018 21:56:13.9704 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5575
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810160183
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 21:56:45 -0000

Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K
DQpLZW50IC8vIGFzIGFuIGF1dGhvcg0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KUmVwbHktVG86ICJh
ZHJpYW5Ab2xkZG9nLmNvLnVrIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCkRhdGU6IFR1ZXNkYXks
IE9jdG9iZXIgMTYsIDIwMTggYXQgNToyNCBQTQ0KVG86ICdMb3UgQmVyZ2VyJyA8bGJlcmdlckBs
YWJuLm5ldD4sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiwgQmVub2l0IENsYWlz
ZSA8YmNsYWlzZUBjaXNjby5jb20+LCAiYmlsbC53dUBodWF3ZWkuY29tIiA8YmlsbC53dUBodWF3
ZWkuY29tPiwgQWRyaWFuIEZhcnJlbCA8YWZhcnJlbEBqdW5pcGVyLm5ldD4NCkNjOiAibmV0bW9k
LWNoYWlyc0BpZXRmLm9yZyIgPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+LCAibmV0bW9kQGlldGYu
b3JnIiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtuZXRtb2RdIFJlZ2FyZGluZyBJ
UFIgb24gZHJhZnQta3dhdHNlbi1uZXRtb2QtYXJ0d29yay1mb2xkaW5nLTA4DQpSZXNlbnQtRnJv
bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IDxqb2VsamFAYm9ndXMuY29t
PiwgPHdhbmd6aXRhb0BodWF3ZWkuY29tPiwgPGxiZXJnZXJAbGFibi5uZXQ+LCA8a3dhdHNlbkBq
dW5pcGVyLm5ldD4NClJlc2VudC1EYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDE2LCAyMDE4IGF0IDU6
MjQgUE0NCg0KSGkgTG91LA0KDQoiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw
cGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KVGhhbmtzLA0KQWRyaWFuDQoNCj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+IFNlbnQ6IDE2IE9jdG9iZXIgMjAxOCAy
MToyNg0KPiBUbzogS2VudCBXYXRzZW47IEJlbm9pdCBDbGFpc2U7IGJpbGwud3VAaHVhd2VpLmNv
bTsgYWZhcnJlbEBqdW5pcGVyLm5ldA0KPiBDYzogTmV0TW9kIFdHIENoYWlyczsgTmV0TW9kIFdH
DQo+IFN1YmplY3Q6IFtuZXRtb2RdIFJlZ2FyZGluZyBJUFIgb24gZHJhZnQta3dhdHNlbi1uZXRt
b2QtYXJ0d29yay1mb2xkaW5nLTA4DQo+IA0KPiBBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0K
PiANCj4gQXMgcGFydCBvZiBwcmVwYXJhdGlvbiBmb3IgV0cgQWRvcHRpb24NCj4gDQo+IEFyZSB5
b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJv
dmU/DQo+IA0KPiBQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPiANCj4gIk5vLCBJJ20gbm90IGF3YXJl
IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQo+IG9yDQo+ICJZZXMsIEkn
bSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQo+IA0KPiBJZiBzbywg
aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy
dWxlcw0KPiAoc2VlIFJGQ3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8N
Cj4gDQo+IElmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQo+IA0KPiAi
WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ
UFIgcnVsZXMiDQo+IG9yDQo+ICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0K
PiANCj4gSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0
YWlscyB5b3UgdGhpbmsNCj4gYXBwcm9wcmlhdGUuDQo+IA0KPiBJZiB5b3UgYXJlIGxpc3RlZCBh
cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KPiBh
Ym92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9y
IG5vdCB5b3UgYXJlDQo+IGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQg
d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0KPiBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhh
cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KPiBjb250cmlidXRv
ci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FH
RSdTDQo+IFRPIExJTkVTLg0KPiANCj4gSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBv
ciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkDQo+IGFzIGFuIGF1dGhvciBv
ciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyDQo+
IHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElF
VEYgaWYgeW91IGFyZQ0KPiBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJp
YnV0aW9uLCBvciB0byByZWZyYWluIGZyb20NCj4gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJp
YnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyDQo+IHVuZGlzY2xvc2VkIElQUi4g
Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQo+
IGFuZA0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0z
QV9fdHJhYy50b29scy5pZXRmLm9yZ19ncm91cF9pZXNnX3RyYWNfd2lraV9JbnRlbGxlY3R1YWxQ
cm9wZXJ0eSZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj
V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09TVlh
NS1YTlZnUG9jcTFjckxuTXJPZ3hRemhfOC1SRmtEM0Fjc200WDQ4NCZzPTJhZ2RpQmxTSjJ5TUx5
cmx3ZHc4MFdMNWpza25fZnVWZ08yamZma3lmRlkmZT0uDQo+IA0KPiBUaGFuayB5b3UsDQo+IE5l
dE1vZCBXRyBDaGFpcnMNCj4gDQo+IFBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhl
IGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCj4gcmVzcG9uc2UuDQo+IA0KPiANCj4g
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f
bGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k
YjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mbT1NWWE1LVhOVmdQb2NxMWNyTG5Nck9neFF6aF84LVJGa0QzQWNzbTRYNDg0JnM9aVlyMFRV
ZVZKWjJ4U0J5OWd2ZWxVZjJIaUsydVAzTGg1RXNvQnFmb0FDdyZlPQ0KDQoNCg==


From nobody Tue Oct 16 15:15:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8053130E52 for ; Tue, 16 Oct 2018 15:15: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] 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 nqp2_ucPHqpx for ; Tue, 16 Oct 2018 15:15:31 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58B130E4B for ; Tue, 16 Oct 2018 15:15:31 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1F51F6005A; Tue, 16 Oct 2018 22:15:30 +0000 (UTC)
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>   
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Andy Bierman 
Cc: Christian Hopps , Juergen Schoenwaelder , joel jaeggli , NETMOD Working Group 
In-reply-to: 
Date: Tue, 16 Oct 2018 18:15:29 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 22:15:33 -0000

Andy Bierman  writes:
>
> This draft needs to define the module-tag encoding wrt/
>    - valid characters (e.g., some subset of UTF-8)
>    - min/max length (e.g., implementation MUST support at least 64 chars
> and can support larger)

I'm looking for suggestions on how to do this subset. We had intended to allow for as wide as possible content; however, I think disallowing tabs, newlines, carriage returns is more than reasonable. Has a type like this already been standardized or is there an example available somewhere?

> Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
> structure to specify the naming authority.
>
> According to the YANG module, the data type is a plain string, which
> includes lots of
> problematic chars and zero-length strings.
>
> Does the string "routing" match "ietf:routing" or "vendor:routing"? How
> about "routing:bgp"?

No. Do we need to state that non-matching strings don't match?

> Is the char ":" allowed in a tag?

Yes, why not?

> Is "vendor::::::::" a valid tag?

Again why not?

The only thing the draft talks about are standard prefixes. Why should a standard enumerate a subset of the unbounded set of things it isn't standardizing? This seems more confusing (why was X included as OK but not Y) than just sticking to what it *is* standardizing.

Perhaps a bit of text saying more explicitly that only the prefix is restricted would help though?

> IMO this draft does not need to define any specific module-tag content but
> it does need to define
> in precise terms how a protocol encodes a module-tag and how a module-tag
> match is determined.

We considered leaving out all the predefined tags, but conversely we also thought it would be useful to establish a base set. We went with the latter obviously. Perhaps it just needs to be trimmed down more?

Thanks,
Chris.

>
>
> Thanks,
>> Chris.
>>
>
> Andy


From nobody Tue Oct 16 16:32:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EF0130E61 for ; Tue, 16 Oct 2018 16:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 KdRW63IByymG for ; Tue, 16 Oct 2018 16:32:30 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::612]) (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 4393C130E35 for ; Tue, 16 Oct 2018 16:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7P4Bxswv7d7QM+kTlc5U4h0Lujhnb6pwTNB/b3O/5gA=; b=XBUqFyU8EAYy9qVGxe7aFgYKyrsRJdCErUFbLhJQtJTfKugN32kOgYMH3a/MFsufj8Ujaob3btnnQhqRVDrKD5x8S/0+AR7VBde//sHEKzoxwRI+xxao7T/ZsxuWfOQIiDQqzcbWLErO+pxzjkB6eaKKlmlGw9pJ3lTcBWjozUU=
Received: from CY4PR2201CA0036.namprd22.prod.outlook.com (2603:10b6:910:3e::25) by BN6PR2201MB1105.namprd22.prod.outlook.com (2603:10b6:405:35::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Tue, 16 Oct 2018 23:32:28 +0000
Received: from DM3NAM03FT021.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::205) by CY4PR2201CA0036.outlook.office365.com (2603:10b6:910:3e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20 via Frontend Transport; Tue, 16 Oct 2018 23:32:27 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT021.mail.protection.outlook.com (10.152.82.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Tue, 16 Oct 2018 23:32:26 +0000
From: Alex Campbell 
To: Christian Hopps 
CC: joel jaeggli , NETMOD Working Group 
Thread-Topic: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
Thread-Index: AQHUZah+SzztZMo5A0KjAPoDQs/leQ==
Date: Tue, 16 Oct 2018 23:32:25 +0000
Message-ID: <1539732745739.66497@Aviatnet.com>
References:  <1538612528590.11321@Aviatnet.com>, <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org>
In-Reply-To: <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(376002)(39850400004)(2980300002)(438002)(199004)(189003)(8676002)(36736006)(106002)(8746002)(6916009)(246002)(97876018)(446003)(118246002)(7696005)(36756003)(8936002)(53416004)(76176011)(3846002)(4326008)(102836004)(316002)(117636001)(2616005)(6116002)(54906003)(5660300001)(486006)(336012)(476003)(106466001)(126002)(11346002)(53546011)(956004)(47776003)(14444005)(6486002)(72206003)(478600001)(26005)(23756003)(186003)(6246003)(50466002)(86362001)(229853002)(305945005)(356004)(2906002)(25786009)(7736002)(7596002)(7636002)(66574009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1105; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT021; 1:X4+HZpaRqdoUH6nw+k5Gc3MqRcKJ/O7X/76kMzMf20tsTRv+gF+SAvUn8KpKJ2fcOCDAz0DnJjsSXICUMZr5cr63JwXF134sPgJlhmZigupJGQjTFA5XX5ntuajwWdjI
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f6d88290-182e-4c71-ce91-08d633bfa22e
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1105; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1105; 3:+0Z2BHQppDJpWZcY3e9/zVPmmvACJWqCrhcWb+2v/BwGSXJgy1xsTkTpljGmPaqschsdegpv+T0fVXM1uts/yRk69GOB7ol3pITLKv/oWYLAaVlKNdXo3ol0HQ1CBIICSJOnE2GuEGv/DrcvUYM2XGkW+Dg5qf+AGuQDrHg2w/q86hqVHQAmqiMdmrzU4/RkTzH2oqhYmbvrgi0gjTFpKDi7Hj4aZqk7OEhUXH1t8lg1dMJOtIMzIuK1BnlbZNN4eTL6iSi4cN0GYsh8A6oGJ2BN+hFcwCQ9pKPE1fwhp8LFIHzuUG8tpkzF4vdnQeEP9ZC1+MUcX897cVoaBe2618ym0t629IV0+IgTvQsrTL4=; 25:ah+Kj8nZmY6EeX/LtqW1PG1pdZBhoCb9Z4OUsmSQylRDMQHGMnk14Ee6hqnE184X1XMZZEqSPAENiTO1LDoBa9hTb90k5E81mp0c4fqkViNin5XS8oJHCLmRl8GVwT5pnEd/9HUSwRwFKqQk+c3wGsCCZPttkt1qI16xiBoNyu095c2gcPxavsRbv/hxDbU7YHJDQt5p16TOFR4LNS5q5tpvCNzwvL0KtsTXnsvegI3UInr2JhdCmAJEMaUX/2jzrTvS0Q7Nu3NipSQXU5rZw0iasSeJfWNx13bMM6fc2r0Pbwzd4u8QDRsP4V6NLJarNZN+OBTR0NgnKn6Dv1m/Pw==
X-MS-TrafficTypeDiagnostic: BN6PR2201MB1105:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1105; 31:V/X/xuCwzFKen7esMaalgRVQUCk7nKtweeoLMk3cm7CIjXPYJ5QdBt+dxeqTnk5fbXxrnTyS4nORtmOTbIMrnY/1rMVOqemFxdts8cH8pB/DM72zvTFtRZ7f9vIIPE9FwtLs3kjAmFV24riZh0WVhd+/cwBGm7MItrut+HO6EQXjbv9sAUKzJrVPUBT2Hdi/OkMZEbMmmAGO/CekvzByG4TTfWm3gLjm1rCpqDfeRbA=; 20:wdV06XwdwCuOXFtLgqestsTAz1p8yt7mQAZv/0epBiC/JQGAJtJYyun90ujl5lj/VcvsFpZUOohjJPZJWKS8B2cH9aRBTygSh+5x2R5zI8J9FkXbIAYuFngyDOR15NvMMmmtVcv4yXNxqC80fysXCkyOXpddjHXOqIBk8LiGRehUBi7leoKFk1dMtdn0sL1EXrmGJhaYfnfdX4bPM0M2IqoxCfTvkdfwJdiUHM3m+OKDSYItglYjAhzlE/PMTJvtasw9JxDYU+mAyh5BfC98V3nhfehsE1+IU4iIjzue1X5AT5zT9K/EPmNuRcK6f2sbLrCeyj61PXRZ3QCx+C72BLi4cRv/ciABdibijCljg7OAb3p/5AkEXRTDafKdpxNrGksxTYNAl84GB30desyP6uBuEJsjTWYK2F/TR9/TJtwbfFhz3kFGoEoCKaA+2XMd48USzTZ2tLcFfI2IOTCGmZbXuUd4DF6xzVGfIBndXRF0FxIvq99SHxjFLUP1Y6CF
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(131327999870524);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93004095)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991080); SRVR:BN6PR2201MB1105; BCL:0; PCL:0; RULEID:; SRVR:BN6PR2201MB1105; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1105; 4:HaKcVLr0FIbF1U2+oWjcpE2weBgS/5zCdM7/w/9GGvQkq7h/jnFzFxwMHcsicm6yFwm4X3/ivgJVbpzSiufDOWuhN1YrEFpWimDpVRB5ONUWsBd71gyvMRFFi5H2t/1b/pOwkUoBGWDnVNTGFgdy9tqxRcVAS7prFMJeKfAT5m4yg09iD4CZxN0xaBU3OirlFjGgsnUOG8n/Jgpp/F05OrgIoHAcftyG4UW0/Mgf4bphhr9X8YcgL2Tgf0FutV7FV+P9JCQ3DCwVUcR/GWbvlGRV4QbCdFruMdifwsTkwq+gNliKB3uDPXMnvxeranps1oY9dtMb491/LlykH6AiYuDU3TGRVpVwos9TfxtG+7U=
X-Forefront-PRVS: 0827D7ACB9
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN6PR2201MB1105; 23:S9QfXGXOktAd/H1ioWOERd2nRXiUfXRBDwkv/?= =?iso-8859-1?Q?og9EA5w6L+XTX3Cu6o3yuvEPvXlZRYKQvTjXNXrBcJ93GhPwwEvxtrjfew?= =?iso-8859-1?Q?0aTb/cCBIP4INsGttANUAEFmqRXRswFHhskFfpoE0XFEkL2GvR32GPyyxs?= =?iso-8859-1?Q?EJMmr9IIfuhoHjSd23VGFUT477Alzvt0AHuTOi18J2XHjl+wtkjAw0+0a5?= =?iso-8859-1?Q?tllds/7rrlysbCwdsfSs3eFVH8J/DF21QGudZ5KyzayUPl658vQMSYNixk?= =?iso-8859-1?Q?B4GzS8U1GedaqeBYYzcwcSED2qYMdrYVsFx6GL4j1W1Y9lly9oL0oLCYXI?= =?iso-8859-1?Q?5kdfeM29W2cl8Chpu7BquqIqXlTyqjbQtHeYWeogBwycOLY9Ht7crHHvhY?= =?iso-8859-1?Q?KOrKBKW4ObU4AVO9JFD2g7os/c9svSEpmh+jcry12A1w8sKqU2HxbZ9gjY?= =?iso-8859-1?Q?NA7qQjAn11HUQv93qS877NR0c8aAcg/n3buma1mUl0vFihjqxGeGdYRq0z?= =?iso-8859-1?Q?v+PM6DIxYWHijydwbwdaFhCGhZ6vuYNwIjdF/Hl8xgeLVS5Vr/nbm5e1Gd?= =?iso-8859-1?Q?183uRj1f6KFubcFtXS5tQtajqWUnIMAfZwUnlz1NiOrihy+cTuWVnvY1qh?= =?iso-8859-1?Q?H+rhufPX1KlQf32/GW/RgcBr8h2tqoAIWjbB/CoCPwMVtZKEDMVdxJ7VEL?= =?iso-8859-1?Q?RBTb/PXS6fk6Dal2/0oxLFvpKlSgUNb9tRkOrCG78U1kfSyTnzkBOvSs/j?= =?iso-8859-1?Q?oQmykVC4tOTVzK2rA6JckO1FCZRcTnR9nOlTfGHy5YE0U2uEik3mzQgTeS?= =?iso-8859-1?Q?1qYBHxt/xAhjyDS5SieKbA8BW/TqJRywktn9GYmzqQwc/0FmH012MdxY6N?= =?iso-8859-1?Q?+xExND4pUpOatCpvaxpCF4iHI6nZcxdEzO+Q/TBR26A4r2Win9kh45llrB?= =?iso-8859-1?Q?Dem4Q4oOHr38lkEZcz2LmEytqim0kIiyqWTe4oN4g39Xoyhsqg9fNgwQXC?= =?iso-8859-1?Q?/KzDHp1Te/9sd2Ozg7a2MmPvhA5nZqCPL00MvyV0zW32zJuWXVDU/J77yr?= =?iso-8859-1?Q?tMhKNLnqkqrK4sWOXPOESdkBMNx2Du3gQPsuUDDE67epbzICMTDcXu++tP?= =?iso-8859-1?Q?a2C2YgTGQzRq8hEFYwlOSgPM7n4vmXYy8XTzsjTTR9xpT/pKesTbHdXDkb?= =?iso-8859-1?Q?J4x6EcsIs39jN6mONFMi3H1gsaMyLkhwLUSCJ4/sXRRdsLb/zNHuyUB7yV?= =?iso-8859-1?Q?vo5qNiAjzayC2Z0Rk/eBLvbaJoezB2lMnpCVq+gEHbycL/uJGLCbcxDX8h?= =?iso-8859-1?Q?3VWwPycvgmOPmr0emJDq4PDzH7jyHvel8Z8NlL0n8KGkaOA=3D=3D?=
X-Microsoft-Antispam-Message-Info: rX+SjOHvpBrV+64drOeFrlFVyYzBZsE7asFKEH364vbYklhQW21Nubu09B3GiJlbI9PzQnvITh5etc5BHYIwDSxlRlsnETTv+dGQBVTtpJ5z/9ntO2azH1Gv5HPoYp7Q0GHr5+sUtfok5Itv37XMbwD4+9IcgDmflyKpJc1E0dcgT/e9QbNDCpusCo8VsX/Jvi8NbvaLrCP9BybVdwo9IFufOnwkMdtdaTziz455ejELh9rWYXtrJmfvLtAsKAckaLM4/5EdfFKJ3u1TJDTL12zUH+EDOXtD0g+PdGC8x8xy5yotJFOUkESDhZx6qj6KT7XN9b4LbInXUCAdDeuMYBNDY8+ye/myiT7ZFkf7OR0=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1105; 6:Am8YKxZYy/E0UDfBI3XxXLPHRUYNACdlJsPZpYAUKgt6/ZkG29X0BJAmv43OvIfZgItsU833fAk4ZYRUNEz4l/i+IqWeE6Jq161tozHlXXZiu8qjvLpYdPGN17zNp6Ok6hso/i0Zy9xULUiooGRW2DVW503rXc6tohw3HB+JXnNl96n8JzmjoHLqBlpU144Uznnae4RJnvkibKe+YVXzYh7i2Vx1BG2Axx30uiKQCzfMG9IA2SUssvvu/hIe/PKtoamZrjzAG5k5KJSRyO8VpoyKq4KYy7Xa/lGvxyf6cm1WMVusmOxmaBiCbPuy/0m5dpF6WNpjnidoBW7Hg/mUk8AIvDwvvQmlsAYORZ0BRzCmaZDpK+GABrmO6DZuDWnrWdOVYBrbEB7f1GJMx7+cz7T21Eclui73VdVAOvTWXgHAX8hnIjZF/8uVyAHNEIJ2tlZl/qW1Eiw4E1+a05nNVA==; 5:Uau7RzxPPVnGua9OBQI2NnCuyvafFOfvY8bhsWrNeiKolWjHjgVpSLKyhhE1Vb1eLTl77q+ooedHOJN3KNVGt5JfjEsL9xa3hfLIEXnKJ+myJeOfGq8Q40tTAmVlovR6D7WOfLB/JeBgiTk4pp6eQZ5t6T+xGeHPNUSsDgp1oKk=; 7:fcwOAEkS3vKQEZlucUCvD8A549YYJ4MUEBxfXm3xC+BHdRlL1XmlntXv0aJTAMREEkIHtbaqzGmIGE+9r8+Aglto2C93rX0JVXGVvwQPeTMpnjeWLGkXDa6j95cF3hdAsUcyxp3crq7kbNm4ygmCf5TjcnuA44LzH4PDIeVyedUGs+siLh+5hc2M0I6ShP63wimOX3T+Ff7ny5BoHlUYMN11FXKNGeX2jXob8iZTANfCXrKpqLD73y5AtTF72yQ/
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2018 23:32:26.9906 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f6d88290-182e-4c71-ce91-08d633bfa22e
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1105
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 23:32:34 -0000

I have no issue with systems using tags to classify or organize modules, ho=
wever this seems to me like something that would be specific to the system =
doing the classifying.=0A=
It would not be something that needs to be specified in the module itself (=
except perhaps as freeform description text), and it certainly would not ne=
ed to involve the NETCONF server.=0A=
What would a server do with module classification data? (unless it is also =
implementing some kind of module browsing interface, in which case it might=
 be used to supply the browser with data)=0A=
=0A=
Hashtags - all types, that I'm aware of - are inherently freeform and fluid=
, changing quickly according to the desires of users. I don't think it make=
s sense to "hard-code" them in published RFCs or even published vendor modu=
les or firmware.=0A=
=0A=
Tomorrow, I might want to list all modules for management plane protocols. =
As a network operator, should I go and update the ietf-module-tags on all o=
f my network elements? That seems silly. This should be client-side data. (=
And if I did, what happens when I add a new router and forget to update its=
 tag data? Will that confuse the client?)=0A=
=0A=
Regards, Alex=0A=
=0A=
________________________________________=0A=
From: Christian Hopps =0A=
Sent: Wednesday, 17 October 2018 1:04 a.m.=0A=
To: Alex Campbell=0A=
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10=
/16/18=0A=
=0A=
>=0A=
> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wr=
ote:=0A=
>=0A=
> The introduction does not explain what they are useful for=0A=
=0A=
The second sentence of the abstract: "The expectation is for such tags to b=
e used to help classify and organize modules." The introduction repeats thi=
s in the first sentence. I'm not sure how much differently we could say "Ta=
gs are useful for organizing and classifying modules". Are you asking for j=
ustification on the usefulness of organizing and classifying things? I thin=
k this concept is rather widely accepted.=0A=
=0A=
=0A=
> , it just makes a comparison to #hashtags (which is something I would exp=
ect to see in an April 1st RFC).=0A=
=0A=
Using tags to help organize collections of data is literally ubiquitous: Mo=
vies/music/media, IP routes, and yes even social media are just a few examp=
les.  Regarding April 1st, are you are unfairly restricting your perspectiv=
e to only the ironic use of hashtags? Hashtags organically developed as a u=
seful and widely used way for people and groups to add meta-data to their m=
essages which then allowed other services to collect and present them in us=
eful ways. Indeed businesses and other groups use hashtags for this purpose=
 to great success. It was hardly a joke, and for many folks it is immediate=
ly useful to understand what is being proposed.=0A=
=0A=
Thanks,=0A=
Chris.=0A=


From nobody Tue Oct 16 16:40:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E5130E62 for ; Tue, 16 Oct 2018 16:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 vl3w6cezoHyx for ; Tue, 16 Oct 2018 16:40:04 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6F1130E5D for ; Tue, 16 Oct 2018 16:40:01 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id v6-v6so22542348ljc.11 for ; Tue, 16 Oct 2018 16:40:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eW1E5EHz9ML8M208NZrTNkJiyTCLtbp17d1EJpvp6EA=; b=bQLrEXImNaceFspwgKKWUGqoB5VccQr3Ybtz6T2pA0/Vi0a+7ZHKFa6f6fv846gkRR CByYDdKan6lKy4E+Dep/DzfQ0hqmRM6Lr7LhhMgPTBhRVqxuSF+E41oMvsafeHHaC4M7 6JWYlV6jdhm5ObtlHQDtj4TSDKcDWcOCt6leDsupX5aPVfHqp74B6Mfw9GpKsHF1vXsX qc0+CoH7BlY/RyCC7Lnly309pp3n7ioKTw+E/Q3eatEqp+YD/ym7O1TgzDIPQlcFi0UB wDSM5Fb9JY7uJGND+1d+NOllMIqmpupVIvpcoJq8RnaA2bQAe95XIr0WSt0syh/X196H /YUA==
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=eW1E5EHz9ML8M208NZrTNkJiyTCLtbp17d1EJpvp6EA=; b=KM1TFSJS/Umba5LiEZQhTve6aEAgTnZF5M+paqnBGzj9BsSFtUr4IqQyY92GRd/RV+ IkX2uvoep7yJj5uXhRoze1g8SEoTii93VchiaPIESEKhBH5zPOHbEcAapM3+61F7+Zii c+cZml4AJHmml2zkzgpk938pwOh3heQcNK9Ij6FHHTg5R9uI4iODFkXTO81gxIROJpjf 9RS+13V+zT/gEScAXiZFtthk9ODhdgEPgqZSh6o1t1C7mi/um/W6VkCV5EeF+jS/Xi+j JwjwRo1znJ0xQUGrsPmUtn6f4gOerao6ZPMNuzAvQl4AloOKsIifOl56lCZRWov+3r1Q bH4Q==
X-Gm-Message-State: ABuFfogei/eS5q5Au4h3oqScTk2YZWd2Q2cGbEl7tCldpwOoxN+dhzWo kgz3wnKQa6TRi7YXCTOc2IKzkshy+G3NYcn3NYx7cQ==
X-Google-Smtp-Source: ACcGV61XezDyd4TVAlTNfIsYVqjT/wf/eCK12n5crVvMVoLKxsHBCjGQJ7yVhjqyrPduNIQaMgTJFiAhRzuLw6RpLH8=
X-Received: by 2002:a2e:810e:: with SMTP id d14-v6mr1848471ljg.170.1539733199893;  Tue, 16 Oct 2018 16:39:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:f811:0:0:0:0:0 with HTTP; Tue, 16 Oct 2018 16:39:59 -0700 (PDT)
In-Reply-To: 
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>    
From: Andy Bierman 
Date: Tue, 16 Oct 2018 16:39:59 -0700
Message-ID: 
To: Christian Hopps 
Cc: Juergen Schoenwaelder , joel jaeggli , NETMOD Working Group 
Content-Type: multipart/alternative; boundary="0000000000006dcc6d0578611262"
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2018 23:40:07 -0000

--0000000000006dcc6d0578611262
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
>>
>> This draft needs to define the module-tag encoding wrt/
>>    - valid characters (e.g., some subset of UTF-8)
>>    - min/max length (e.g., implementation MUST support at least 64 chars
>> and can support larger)
>>
>
> I'm looking for suggestions on how to do this subset. We had intended to
> allow for as wide as possible content; however, I think disallowing tabs,
> newlines, carriage returns is more than reasonable. Has a type like this
> already been standardized or is there an example available somewhere?
>

I suppose yang-identifier type is too restrictive so I will agree that
restricting whitespace and colon chars
is probably good enough


> Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
>> structure to specify the naming authority.
>>
>> According to the YANG module, the data type is a plain string, which
>> includes lots of
>> problematic chars and zero-length strings.
>>
>> Does the string "routing" match "ietf:routing" or "vendor:routing"? How
>> about "routing:bgp"?
>>
>
> No. Do we need to state that non-matching strings don't match?
>

The official prefixes and colon char lead people to believe the string is
structured.
Intelligent searches on sub-sfields might be purpose of such structure. Or
not I guess.


> Is the char ":" allowed in a tag?
>>
>
> Yes, why not?
>

Because it confuses people who think the colon character has special
meaning in this string



>
> Is "vendor::::::::" a valid tag?
>>
>
> Again why not?
>
> The only thing the draft talks about are standard prefixes. Why should a
> standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but not
> Y) than just sticking to what it *is* standardizing.
>
> Perhaps a bit of text saying more explicitly that only the prefix is
> restricted would help though?
>
> IMO this draft does not need to define any specific module-tag content but
>> it does need to define
>> in precise terms how a protocol encodes a module-tag and how a module-tag
>> match is determined.
>>
>
> We considered leaving out all the predefined tags, but conversely we also
> thought it would be useful to establish a base set. We went with the latter
> obviously. Perhaps it just needs to be trimmed down more?
>


I think the registry details have to be there to populate the IANA
registery



>
> Thanks,
> Chris.
>
>
>>
>> Thanks,
>>
>>> Chris.
>>>
>>>
>> Andy
>>
>
>
Andy

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




On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps <=
chopps@chopps.org> wrote:


Andy Bierman <an=
dy@yumaworks.com> writes:





This draft needs to define the module-tag encoding wrt/

=C2=A0 =C2=A0- valid characters (e.g., some subset of UTF-8)

=C2=A0 =C2=A0- min/max length (e.g., implementation MUST support at least 6=
4 chars

and can support larger)





I'm looking for suggestions on how to do this subset. We had intended t=
o allow for as wide as possible content; however, I think disallowing tabs,=
 newlines, carriage returns is more than reasonable. Has a type like this a=
lready been standardized or is there an example available somewhere?

I suppose yang-identifier type is too restric=
tive so I will agree that restricting whitespace and colon chars
=
is probably good enough=C2=A0






Section 3 (Tag Prefixes) seems to imply that all modules tags follow a

structure to specify the naming authority.



According to the YANG module, the data type is a plain string, which

includes lots of

problematic chars and zero-length strings.



Does the string "routing" match "ietf:routing" or "=
;vendor:routing"? How

about "routing:bgp"?





No. Do we need to state that non-matching strings don't match?

The official prefixes and colon char lead peopl=
e to believe the string is structured.
Intelligent searches on su=
b-sfields might be purpose of such structure. Or not I guess.






Is the char ":" allowed in a tag?





Yes, why not?

Because it confuses peopl=
e who think the colon character has special meaning in this string

=C2=A0





Is "vendor::::::::" a valid tag?





Again why not?



The only thing the draft talks about are standard prefixes. Why should a st=
andard enumerate a subset of the unbounded set of things it isn't stand=
ardizing? This seems more confusing (why was X included as OK but not Y) th=
an just sticking to what it *is* standardizing.



Perhaps a bit of text saying more explicitly that only the prefix is restri=
cted would help though?





IMO this draft does not need to define any specific module-tag content but<=
br>
it does need to define

in precise terms how a protocol encodes a module-tag and how a module-tag
match is determined.





We considered leaving out all the predefined tags, but conversely we also t=
hought it would be useful to establish a base set. We went with the latter =
obviously. Perhaps it just needs to be trimmed down more?
<=
div>

I think the registry details have to be t=
here to populate the IANA registery=C2=A0

=C2=A0



Thanks,

Chris.









Thanks,



Chris.







Andy







Andy



--0000000000006dcc6d0578611262--


From nobody Tue Oct 16 17:42:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63271127148; Tue, 16 Oct 2018 17:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 d_JAT5-0KG-4; Tue, 16 Oct 2018 17:42:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 4E557124D68; Tue, 16 Oct 2018 17:42:05 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2E9F58EA589C; Wed, 17 Oct 2018 01:42:01 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 01:42:02 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0399.000; Wed, 17 Oct 2018 08:41:58 +0800
From: Qin Wu 
To: Kent Watsen , "adrian@olddog.co.uk" , 'Lou Berger' , 'Benoit Claise' , Adrian Farrel 
CC: 'NetMod WG Chairs' , 'NetMod WG' 
Thread-Topic: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZY6JkiWGxpoetE2smXO72L+tt6Uh29KAgAAJEICAALQ9YA==
Date: Wed, 17 Oct 2018 00:41:57 +0000
Message-ID: 
References:  <056c01d46596$874bd260$95e37720$@olddog.co.uk> <34042279-8A05-4D95-9452-D2634E6408AF@juniper.net>
In-Reply-To: <34042279-8A05-4D95-9452-D2634E6408AF@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 00:42:09 -0000

Tm8sIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQot
UWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEtlbnQgV2F0c2VuIFttYWls
dG86a3dhdHNlbkBqdW5pcGVyLm5ldF0gDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQxMOaciDE35pel
IDU6NTYNCuaUtuS7tuS6ujogYWRyaWFuQG9sZGRvZy5jby51azsgJ0xvdSBCZXJnZXInOyAnQmVu
b2l0IENsYWlzZSc7IFFpbiBXdTsgQWRyaWFuIEZhcnJlbA0K5oqE6YCBOiAnTmV0TW9kIFdHIENo
YWlycyc7ICdOZXRNb2QgV0cnDQrkuLvpopg6IFJlOiBbbmV0bW9kXSBSZWdhcmRpbmcgSVBSIG9u
IGRyYWZ0LWt3YXRzZW4tbmV0bW9kLWFydHdvcmstZm9sZGluZy0wOA0KDQpObywgSSdtIG5vdCBh
d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0DQoNCktlbnQgLy8gYXMg
YW4gYXV0aG9yDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkcmlh
biBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+DQpSZXBseS1UbzogImFkcmlhbkBvbGRkb2cu
Y28udWsiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAxNiwg
MjAxOCBhdCA1OjI0IFBNDQpUbzogJ0xvdSBCZXJnZXInIDxsYmVyZ2VyQGxhYm4ubmV0PiwgS2Vu
dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+LCBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNp
c2NvLmNvbT4sICJiaWxsLnd1QGh1YXdlaS5jb20iIDxiaWxsLnd1QGh1YXdlaS5jb20+LCBBZHJp
YW4gRmFycmVsIDxhZmFycmVsQGp1bmlwZXIubmV0Pg0KQ2M6ICJuZXRtb2QtY2hhaXJzQGlldGYu
b3JnIiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4sICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RA
aWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW25ldG1vZF0gUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1r
d2F0c2VuLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmctMDgNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91
bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGpvZWxqYUBib2d1cy5jb20+LCA8d2FuZ3ppdGFv
QGh1YXdlaS5jb20+LCA8bGJlcmdlckBsYWJuLm5ldD4sIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0K
UmVzZW50LURhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTggYXQgNToyNCBQTQ0KDQpIaSBM
b3UsDQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz
IGRyYWZ0Ig0KDQpUaGFua3MsDQpBZHJpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIExvdSBCZXJnZXINCj4gU2VudDogMTYgT2N0b2JlciAyMDE4IDIxOjI2DQo+IFRvOiBL
ZW50IFdhdHNlbjsgQmVub2l0IENsYWlzZTsgYmlsbC53dUBodWF3ZWkuY29tOyANCj4gYWZhcnJl
bEBqdW5pcGVyLm5ldA0KPiBDYzogTmV0TW9kIFdHIENoYWlyczsgTmV0TW9kIFdHDQo+IFN1Ympl
Y3Q6IFtuZXRtb2RdIFJlZ2FyZGluZyBJUFIgb24gDQo+IGRyYWZ0LWt3YXRzZW4tbmV0bW9kLWFy
dHdvcmstZm9sZGluZy0wOA0KPiANCj4gQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCj4gDQo+
IEFzIHBhcnQgb2YgcHJlcGFyYXRpb24gZm9yIFdHIEFkb3B0aW9uDQo+IA0KPiBBcmUgeW91IGF3
YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0K
PiANCj4gUGxlYXNlIHN0YXRlIGVpdGhlcjoNCj4gDQo+ICJObywgSSdtIG5vdCBhd2FyZSBvZiBh
bnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPiBvcg0KPiAiWWVzLCBJJ20gYXdh
cmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPiANCj4gSWYgc28sIGhhcyB0
aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMg
DQo+IChzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KPiAN
Cj4gSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCj4gDQo+ICJZZXMs
IHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy
dWxlcyINCj4gb3INCj4gIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+IA0K
PiBJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxz
IHlvdSB0aGluayANCj4gYXBwcm9wcmlhdGUuDQo+IA0KPiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBh
IGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIA0KPiB0aGUgYWJv
dmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBu
b3QgeW91IA0KPiBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3
aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSANCj4gbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhh
cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIA0KPiBsaXN0ZWQgY29udHJpYnV0
b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIA0KPiBN
RVNTQUdFJ1MgVE8gTElORVMuDQo+IA0KPiBJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0
IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCANCj4gbGlzdGVkIGFzIGFuIGF1dGhv
ciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIA0KPiB1
bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRo
ZSBJRVRGIGlmIA0KPiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBj
b250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gDQo+IGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkg
Y29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIA0KPiB1bmRpc2Nsb3Nl
ZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCAN
Cj4gYWJvdmUgYW5kIA0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cC0zQV9fdHJhYy50b29scy5pZXRmLm9yZ19ncm91cF9pZXNnX3RyYWNfd2lraV9JbnRl
bGxlY3R1YWxQcm9wZXJ0eSZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u
ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJm09TVlhNS1YTlZnUG9jcTFjckxuTXJPZ3hRemhfOC1SRmtEM0Fjc200WDQ4NCZzPTJhZ2Rp
QmxTSjJ5TUx5cmx3ZHc4MFdMNWpza25fZnVWZ08yamZma3lmRlkmZT0uDQo+IA0KPiBUaGFuayB5
b3UsDQo+IE5ldE1vZCBXRyBDaGFpcnMNCj4gDQo+IFBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0
ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgDQo+IHJlc3BvbnNlLg0K
PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y
Z19tYWlsDQo+IG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNj
YmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz
QllhR1R2aklTbGFKZGNabyZtPU1ZYTUtWE5WZ1BvY3ExY3JMbk1yT2d4UXpoXzgtUkZrRDNBY3Nt
NFg0ODQmcz1pWXIwVFVlVkpaMnhTQnk5Z3ZlbFVmMkhpSzJ1UDNMaDVFc29CcWZvQUN3JmU9DQoN
Cg0K


From nobody Tue Oct 16 21:10:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0B612872C for ; Tue, 16 Oct 2018 21:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYA1y8unNDwh for ; Tue, 16 Oct 2018 21:10:10 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 18242127B92 for ; Tue, 16 Oct 2018 21:10:10 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AFD99D80A640F for ; Wed, 17 Oct 2018 05:10:04 +0100 (IST)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 05:10:05 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0382.000; Wed, 17 Oct 2018 12:09:54 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: Review comments for module-tags-02
Thread-Index: AdRlz2ZrcdhVQBKIRg2w21rqsHkwQQ==
Date: Wed, 17 Oct 2018 04:09:53 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BC65175dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 04:10:13 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC65175dggeml510mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1. In the desrciption of leaf-list tag
  "
  The operational view of this list will contain all
             user-configured tags as well as any predefined tags that
             have not been masked by the user using the masked-tag leaf
             list below.
  "
  =3D=3D> So the predefined tags, should be output as  origin  in =
 ?
  If so, I would suggest renaming them to "default" tags.

2. For "masked-tag", if the purpose is to only mask "predefined" tags, why =
not rename
as masked-default-tag or masked-predefined-tag ?
Also if a tag say tag-1 (not predefined) is added to this list, and tag-1 a=
dded to "tag", the tag-1
will still be output in , which may look confusing to the user=
 as the tag-1 will exist
in both "tag" and "masked-tag". Changing the "masked-tag" may help in this =
case.

3.  It is still not clear, what is the use-case where user wants to "mask" =
a predefined tag.

4. What about already existing modules which donot define the tags, should =
they be output in the
  "module-tags" list ? Or better to use "min-elements" for leaf-list "tags"=
 ?

5. I also agree with other reviewer's comment that this document must stand=
ardize what a module-tag must look like.
  Currently it only standardizes a prefix, if the rest of the tag is not st=
andardized a client has no way to parse
  this tag.
  Maybe we can say that a tag will contain 3 parts, 1st part is about organ=
ization, 2nd part is about the whether it is service / element, 3rd part
  can be a sub-category of part-2.

With Regards,
Rohit R

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC65175dggeml510mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











1. In the desrciption of leaf-l=
ist tag


  "=



  The operational view of =
this list will contain all


     &=
nbsp;       user-configured tags as well as a=
ny predefined tags that


     &=
nbsp;       have not been masked by the user =
using the masked-tag leaf


     &=
nbsp;       list below.


  "=



  =3D=3D> So the predef=
ined tags, should be output as <default> origin  in <operatio=
nal> ?


  If so, I would suggest r=
enaming them to "default" tags.


 


2. For "masked-tag", =
if the purpose is to only mask "predefined" tags, why not rename<=
o:p>


as masked-default-tag or masked=
-predefined-tag ?


Also if a tag say tag-1 (not pr=
edefined) is added to this list, and tag-1 added to "tag", the ta=
g-1


will still be output in <ope=
rational>, which may look confusing to the user as the tag-1 will exist<=
o:p>


in both "tag" and &qu=
ot;masked-tag". Changing the "masked-tag" may help in this c=
ase.


 


3.  It is still not clear,=
 what is the use-case where user wants to "mask" a predefined tag=
.



 


4. What about already existing =
modules which donot define the tags, should they be output in the


  "module-tags" =
list ? Or better to use "min-elements" for leaf-list "tags&q=
uot; ?


  


5. I also agree with other revi=
ewer's comment that this document must standardize what a module-tag must l=
ook like.


  Currently it only standa=
rdizes a prefix, if the rest of the tag is not standardized a client has no=
 way to parse


  this tag.


  Maybe we can say that a =
tag will contain 3 parts, 1st part is about organization, 2nd part is about=
 the whether it is service / element, 3rd part



  can be a sub-catego=
ry of part-2.


 


With Regards,=



Rohit R






--_000_991B70D8B4112A4699D5C00DDBBF878A6BC65175dggeml510mbxchi_--


From nobody Tue Oct 16 23:48:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCC712F1A5 for ; Tue, 16 Oct 2018 23:48:02 -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, 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 tjcS6FW68yT7 for ; Tue, 16 Oct 2018 23:48:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0E128D68 for ; Tue, 16 Oct 2018 23:47:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 662AF1AE0399; Wed, 17 Oct 2018 08:47:55 +0200 (CEST)
Date: Wed, 17 Oct 2018 08:47:54 +0200 (CEST)
Message-Id: <20181017.084754.967504021504890362.mbj@tail-f.com>
To: chopps@chopps.org
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 06:48:02 -0000

Hi,

Christian Hopps  wrote:
> 
> Andy Bierman  writes:
> >
> > This draft needs to define the module-tag encoding wrt/
> >    - valid characters (e.g., some subset of UTF-8)
> >    - min/max length (e.g., implementation MUST support at least 64 chars
> > and can support larger)
> 
> I'm looking for suggestions on how to do this subset. We had intended
> to allow for as wide as possible content; however, I think disallowing
> tabs, newlines, carriage returns is more than reasonable. Has a type
> like this already been standardized or is there an example available
> somewhere?
> 
> > Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
> > structure to specify the naming authority.
> >
> > According to the YANG module, the data type is a plain string, which
> > includes lots of
> > problematic chars and zero-length strings.
> >
> > Does the string "routing" match "ietf:routing" or "vendor:routing"?
> > How
> > about "routing:bgp"?
> 
> No. Do we need to state that non-matching strings don't match?

The word "match" is imo problematic.  Use "equal" if that's what you
mean.  But you're not actually using the word "match" in the draft, so
that's fine.  However, I think the draft can be clarified.  See below.

In this case, it _seems_ like there's some hierarchy with tags
like:

  ietf:routing
  ietf:routing:rib

For example, does ietf:routing:rib imply ietf:routing?

>From your last emails, it seems that the idea is that tags are really
just strings with the only property that they can be compared for
equality.  If this is the case, I think it can be made more clear in
the document.  And if this is the case, I think that type "string" is
actually fine.  If someone wants to assign the tag
"vendor:acme::::::::: ", let them.

OTOH, if the idea is that the tags are hierarchical, and
ietf:routing-rib implies ietf:routing, then a more specific type is
needed, and more text.


/martin



> 
> > Is the char ":" allowed in a tag?
> 
> Yes, why not?
> 
> > Is "vendor::::::::" a valid tag?
> 
> Again why not?
> 
> The only thing the draft talks about are standard prefixes. Why should
> a standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but
> not Y) than just sticking to what it *is* standardizing.
> 
> Perhaps a bit of text saying more explicitly that only the prefix is
> restricted would help though?
> 
> > IMO this draft does not need to define any specific module-tag content
> > but
> > it does need to define
> > in precise terms how a protocol encodes a module-tag and how a
> > module-tag
> > match is determined.
> 
> We considered leaving out all the predefined tags, but conversely we
> also thought it would be useful to establish a base set. We went with
> the latter obviously. Perhaps it just needs to be trimmed down more?
> 
> Thanks,
> Chris.
> 
> >
> >
> > Thanks,
> >> Chris.
> >>
> >
> > Andy
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 16 23:52:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA212F1A5 for ; Tue, 16 Oct 2018 23:52:28 -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, 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 1GEHtrkHzV24 for ; Tue, 16 Oct 2018 23:52:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC35D1277D2 for ; Tue, 16 Oct 2018 23:52:25 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id AACCE1AE0399; Wed, 17 Oct 2018 08:52:24 +0200 (CEST)
Date: Wed, 17 Oct 2018 08:52:24 +0200 (CEST)
Message-Id: <20181017.085224.1915793347645373759.mbj@tail-f.com>
To: Alex.Campbell@Aviatnet.com
Cc: chopps@chopps.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1539732745739.66497@Aviatnet.com>
References: <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 06:52:29 -0000

Alex Campbell  wrote:
> I have no issue with systems using tags to classify or organize
> modules, however this seems to me like something that would be
> specific to the system doing the classifying.
> It would not be something that needs to be specified in the module
> itself (except perhaps as freeform description text), and it certainly
> would not need to involve the NETCONF server.
> What would a server do with module classification data?

It would use it to populate the "/module-tags" list in the operational
state, where operators can read the tags.


/martin

> (unless it is
> also implementing some kind of module browsing interface, in which
> case it might be used to supply the browser with data)
> 
> Hashtags - all types, that I'm aware of - are inherently freeform and
> fluid, changing quickly according to the desires of users. I don't
> think it makes sense to "hard-code" them in published RFCs or even
> published vendor modules or firmware.
> 
> Tomorrow, I might want to list all modules for management plane
> protocols. As a network operator, should I go and update the
> ietf-module-tags on all of my network elements? That seems silly. This
> should be client-side data. (And if I did, what happens when I add a
> new router and forget to update its tag data? Will that confuse the
> client?)
> 
> Regards, Alex
> 
> ________________________________________
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 1:04 a.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18
> - 10/16/18
> 
> >
> > On Oct 3, 2018, at 8:22 PM, Alex Campbell 
> > wrote:
> >
> > The introduction does not explain what they are useful for
> 
> The second sentence of the abstract: "The expectation is for such tags
> to be used to help classify and organize modules." The introduction
> repeats this in the first sentence. I'm not sure how much differently
> we could say "Tags are useful for organizing and classifying
> modules". Are you asking for justification on the usefulness of
> organizing and classifying things? I think this concept is rather
> widely accepted.
> 
> 
> > , it just makes a comparison to #hashtags (which is something I would
> > expect to see in an April 1st RFC).
> 
> Using tags to help organize collections of data is literally
> ubiquitous: Movies/music/media, IP routes, and yes even social media
> are just a few examples.  Regarding April 1st, are you are unfairly
> restricting your perspective to only the ironic use of hashtags?
> Hashtags organically developed as a useful and widely used way for
> people and groups to add meta-data to their messages which then
> allowed other services to collect and present them in useful
> ways. Indeed businesses and other groups use hashtags for this purpose
> to great success. It was hardly a joke, and for many folks it is
> immediately useful to understand what is being proposed.
> 
> Thanks,
> Chris.
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Oct 17 00:22:50 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15086130E9E; Wed, 17 Oct 2018 00:22:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <153976095402.27608.18381012868336369104@ietfa.amsl.com>
Date: Wed, 17 Oct 2018 00:22:34 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-12.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 07:22:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : YANG Schema Mount
        Authors         : Martin Bjorklund
                          Ladislav Lhotka
	Filename        : draft-ietf-netmod-schema-mount-12.txt
	Pages           : 28
	Date            : 2018-10-17

Abstract:
   This document defines a mechanism to add the schema trees defined by
   a set of YANG modules onto a mount point defined in the schema tree
   in some YANG module.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-12
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-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 Wed Oct 17 00:24:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEAF129AB8; Wed, 17 Oct 2018 00:24:57 -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, 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 TlIL3gT-SLc8; Wed, 17 Oct 2018 00:24:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9299D12D4E8; Wed, 17 Oct 2018 00:24:53 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 228E91AE0399; Wed, 17 Oct 2018 09:24:52 +0200 (CEST)
Date: Wed, 17 Oct 2018 09:24:51 +0200 (CEST)
Message-Id: <20181017.092451.1101351547387658756.mbj@tail-f.com>
To: ekr@rtfm.com
Cc: joelja@gmail.com, iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <68a6fced-b67d-633e-fbbc-6b3d3fe4240d@gmail.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 07:24:57 -0000

Hi,

Eric Rescorla  wrote:
> OK, after reading your explanation and the example, I think I am clearer on
> the use case and the text you propose seems appropriate. Why don't you
> provide a new ID and I'll clear my DISCUSS

Thank you!  I have fixed this and uploaded a new version
(draft-ietf-netmod-schema-mount-12).


/martin


> 
> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  wrote:
> 
> > On 10/16/18 06:00, Eric Rescorla wrote:
> > > I'm sorry, but I still don't think I understand the security impacts of
> > > this well enough to know if this text is OK.
> > >
> > > Can you provide a more detailed explanation of what XPath expressions
> > > can and cannot do here? Happy to discuss live either on the phone or in
> > BKK
> > I'm probably grossly simplifying the goal here, but.
> >
> > xpath statement allow for referencing another path or applying
> > constraints e.g. when / must (rfc 6020)
> >
> > the canonical example in 6020 being something like
> >
> >   container interface {
> >       leaf ifType {
> >           type enumeration {
> >               enum ethernet;
> >               enum atm;
> >           }
> >       }
> >       leaf ifMTU {
> >           type uint32;
> >       }
> >       must "ifType != 'ethernet' or " +
> >            "(ifType = 'ethernet' and ifMTU = 1500)" {
> >           error-message "An ethernet MTU must be 1500";
> >       }
> >       must "ifType != 'atm' or " +
> >            "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
> >           error-message "An atm MTU must be  64 .. 17966";
> >       }
> >
> > http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath
> >
> > Imposing constraints using nodes in mounted modules is kind of a key
> > application of schema-mount.
> >
> > > -Ekr
> > >
> > >
> > > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > > > wrote:
> > >
> > >     Hi,
> > >
> > >     Eric Rescorla > wrote:
> > >     > That seems like it's going to have some pretty surprising
> > >     consequences and
> > >     > at minimum needs more information in the Security Considerations.
> > >
> > >     Ok.  Howabout we add a paragraph to the end of the Security
> > >     Considerations section:
> > >
> > >       Care must be taken when the "parent-reference" XPath expressions
> > are
> > >       constructed, since the result of the evaluation of these
> > expressions
> > >       is added to the accessible tree for any XPath expression found in
> > >       the mounted schema.
> > >
> > >
> > >     /martin
> > >
> > >     > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  > >     > wrote:
> > >     >
> > >     > > Eric Rescorla > wrote:
> > >     > > > I'm sorry but I don't understand this.
> > >     > > >
> > >     > > > Does the externally visible behavior of any mounted module
> > >     depend in any
> > >     > > > way on these XPATH references
> > >     > >
> > >     > > Yes, but note that these XPath expressions ("parent-reference")
> > are
> > >     > > read-only (config false in the YANG model).  Thus they are set
> > >     by the
> > >     > > implementation, and used to inform the operator about the
> > >     environment
> > >     > > in which other XPath expressions are evaluated.
> > >     > >
> > >     > >
> > >     > > /martin
> > >     > >
> > >     > >
> > >     > > >
> > >     > > > -Ekr
> > >     > > >
> > >     > > >
> > >     > > >
> > >     > > >
> > >     > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> > >     > wrote:
> > >     > > >
> > >     > > > > Eric Rescorla > wrote:
> > >     > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
> > >     >
> > >     > > wrote:
> > >     > > > > >
> > >     > > > > > > Hi,
> > >     > > > > > >
> > >     > > > > > > Eric Rescorla >
> > wrote:
> > >     > > > > > > > Eric Rescorla has entered the following ballot
> > >     position for
> > >     > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > >     > > > > > > >
> > >     > > > > > > > When responding, please keep the subject line intact
> > >     and reply
> > >     > > to all
> > >     > > > > > > > email addresses included in the To and CC lines. (Feel
> > >     free to
> > >     > > cut
> > >     > > > > this
> > >     > > > > > > > introductory paragraph, however.)
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > > Please refer to
> > >     > > > > > >
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > >     > > > > > > > for more information about IESG DISCUSS and COMMENT
> > >     positions.
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > > The document, along with other ballot positions, can
> > >     be found
> > >     > > here:
> > >     > > > > > > >
> > >     https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > >
> > >
> >  ----------------------------------------------------------------------
> > >     > > > > > > > DISCUSS:
> > >     > > > > > > >
> > >     > > > >
> > >
> >  ----------------------------------------------------------------------
> > >     > > > > > > >
> > >     > > > > > > > Rich version of this review at:
> > >     > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > >
> > >     > > > > > > > DETAIL
> > >     > > > > > > > S 4.
> > >     > > > > > > > >
> > >     > > > > > > > >      It is worth emphasizing that the nodes
> > specified in
> > >     > > > > > > > >      "parent-reference" leaf-list are available in
> > >     the mounted
> > >     > > > > schema
> > >     > > > > > > only
> > >     > > > > > > > >      for XPath evaluations.  In particular, they
> > >     cannot be
> > >     > > accessed
> > >     > > > > > > there
> > >     > > > > > > > >      via network management protocols such as NETCONF
> > >     > > [RFC6241] or
> > >     > > > > > > > >      RESTCONF [RFC8040].
> > >     > > > > > > >
> > >     > > > > > > > What are the security implications of this XPath
> > reference
> > >     > > outside
> > >     > > > > the
> > >     > > > > > > > mount jail? Specifically, how does it interact with
> > >     the access
> > >     > > > > control
> > >     > > > > > > > for the enclosing module.
> > >     > > > > > >
> > >     > > > > > > There is no such interaction, since access control comes
> > >     into play
> > >     > > > > > > when some external entity accesses the data through some
> > >     management
> > >     > > > > > > protocol, and the nodes from the "parent-reference"
> > >     expressions
> > >     > > cannot
> > >     > > > > > > be accessed via management protocols.
> > >     > > > > > >
> > >     > > > > > > The last sentence of the quoted paragraph was supposed
> > >     to make this
> > >     > > > > > > clear, but it seems we might need some additional
> > >     explanation?
> > >     > > > > > >
> > >     > > > > >
> > >     > > > > > Yes, I think so. I guess I'm not clear on what the XPath
> > >     expressions
> > >     > > are
> > >     > > > > > for if they
> > >     > > > > > can't be accessed via the management protocols. How can
> > >     they be used?
> > >     > > > >
> > >     > > > > These are XPath expressions defined in the YANG models
> > >     themselves,
> > >     > > > > such as "must" expressions or "leafrefs".   The description
> > of
> > >     > > > > "parent-reference" refer to them as:
> > >     > > > >
> > >     > > > >                [...] XPath
> > >     > > > >                expressions whose context nodes are defined
> > >     in the
> > >     > > > >                mounted schema
> > >     > > > >
> > >     > > > >
> > >     > > > >
> > >     > > > > /martin
> > >     > > > >
> > >     > >
> > >
> >
> >
> >


From nobody Wed Oct 17 01:37:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5CD12DD85 for ; Wed, 17 Oct 2018 01:37:52 -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, 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 FtaNI24NDsWy for ; Wed, 17 Oct 2018 01:37:51 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C52B6129AB8 for ; Wed, 17 Oct 2018 01:37:50 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4483F6005A; Wed, 17 Oct 2018 08:37:50 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>
Date: Wed, 17 Oct 2018 04:37:48 -0400
Cc: Christian Hopps , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>
To: Rohit R Ranade 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 08:37:53 -0000

> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade  =
wrote:
>=20
> 1. In the desrciption of leaf-list tag
>   "
>   The operational view of this list will contain all
>              user-configured tags as well as any predefined tags that
>              have not been masked by the user using the masked-tag =
leaf
>              list below.
>   "
>   =3D=3D> So the predefined tags, should be output as  origin =
 in  ?
>   If so, I would suggest renaming them to "default" tags.

default has this in it's definition:
=20
    "The default origin is only used when the configuration has not been
     provided by any other source."

The predefined tags are being added due to the module definition or by =
the vendor implementing the module, and the user would be adding to this =
set (not replacing) when they configure tags (and thus the reason for =
the mask). So I think predefined tags should have "system" origin. We =
can add text to the document to clarify this if others agree.

> 2. For "masked-tag", if the purpose is to only mask "predefined" tags, =
why not rename
> as masked-default-tag or masked-predefined-tag ?
> Also if a tag say tag-1 (not predefined) is added to this list, and =
tag-1 added to "tag", the tag-1
> will still be output in , which may look confusing to the =
user as the tag-1 will exist
> in both "tag" and "masked-tag". Changing the "masked-tag" may help in =
this case.

What's the compelling reason to make this more complex? Right now, the =
predefined tags are added, the configured tags are added, and then the =
masks are applied. KISS is the goal.

> 3.  It is still not clear, what is the use-case where user wants to =
"mask" a predefined tag..

The user is the ultimate arbiter over their network is the point. On =
example is a vendor adds a tag indicating the module belongs to a =
certain category of modules which would enable it's use in that users =
network, but for whatever reason the user does not agree.

> 4. What about already existing modules which donot define the tags, =
should they be output in the
>   "module-tags" list ? Or better to use "min-elements" for leaf-list =
"tags" ?

If they have no tags, there's no reason for them to be in the list, =
whether they come before or after the publication of this document (or =
after a device implements it). However, any client software is going to =
need to deal with no module entry, and also with an entry with no tags. =
I think it's better to stay away from adding restrictions that don't add =
real value, but do allow for software to "get it wrong".

> 5. I also agree with other reviewer's comment that this document must =
standardize what a module-tag must look like.
>   Currently it only standardizes a prefix, if the rest of the tag is =
not standardized a client has no way to parse
>   this tag.
>   Maybe we can say that a tag will contain 3 parts, 1st part is about =
organization, 2nd part is about the whether it is service / element, 3rd =
part
>   can be a sub-category of part-2.

There's a lot of prior art here in leaving this open to however people =
want to use the meta-data (see routing admin-tags, media tags, social =
media tags, etc).. The reservation of prefix space allows for future =
definition if that ends up being needed. Users are free to define =
whatever structure they want if any. This discussion in particular was =
carried out over routing admin tags in the IETF and not pre-defining =
structure/meaning was the end result and has worked out well.

Thanks,
Chris.

> =20
> With Regards,
> Rohit R
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 17 01:43:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD87129AB8 for ; Wed, 17 Oct 2018 01:43:32 -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, 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 gxT5YpYoVZyk for ; Wed, 17 Oct 2018 01:43:28 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 719DC128CF2 for ; Wed, 17 Oct 2018 01:43:28 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 14DAB182113A; Wed, 17 Oct 2018 10:51:27 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 7392E1821137; Wed, 17 Oct 2018 10:51:24 +0200 (CEST)
From: Ladislav Lhotka 
To: Michael Rehder , Juergen Schoenwaelder 
Cc: "netmod\@ietf.org" 
In-Reply-To: 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de> 
Mail-Followup-To: Michael Rehder , Juergen Schoenwaelder , "netmod\@ietf.org" 
Date: Wed, 17 Oct 2018 10:43:23 +0200
Message-ID: <87woqhhsk4.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 08:43:32 -0000

Michael Rehder  writes:

> I've read rfc6110 and I didn't see any mention of "WHEN" on the
> mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> list it which seems a bit odd to me).

RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
closely related to sec. 3.1 in 6020.

> The section on "WHEN" just mentions the xpath mapping, not anything
> about changing the mandatory status of the enclosing node.

If you take into account the DSDL validation procedure (Figure 2 in RFC
6110) then everything is IMO clear:

- Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
   and thus are required during RELAX NG schema
  validation, no matter what any "when" expression says.

- Section 12.17 explains how when expressions are mapped to Schematron
  asserts. This means that if an instance node exists in the data and a
  when expression attached to the corresponding data node in YANG
  evaluates to false, Schematron will report a failed assert.

- Note that Schematron cannot by definition report absence of an
  instance based on the when expression attached to its data
  node: Schematron rules are only fired for elements that are present in
  the instance document.=20

>
> I still think that the YANG RFC wording of "conditional" needs to indicat=
e if the node is mandatory status is affected or not.
> Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> does mention presence).

Perhaps this thread is just about misunderstanding of what "when" really
means, which is: Instances for which the "when" expression evaluates to
false must not be present.

It does NOT mean that instances for which the "when" expression
evaluates to true must be present.

Lada

>
> Thanks
> Mike
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: Saturday, October 13, 2018 5:20 PM
>> To: Michael Rehder 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> ensure presence of the mandatory object
>>=20
>> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
>>=20
>> > The mandatory statement in that case is ignored (I=E2=80=99ve pointed =
out the
>> > RNG and Schematron lack of enforcement).  WHEN trumps the mandatory
>> > status (via explicit mandatory or implicit mandatory via min-elements
>> > 1)
>>=20
>> Has the RNG and Schematron been obtained following RFC 6110? If so, this=
 may
>> be a problem with RFC 6110 but not with YANG itself. There are validator=
s that
>> do not use RNG or Schematron.
>>=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         
> =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw=
ide, cloud-based system. Any emails sent to Amdocs will be processed and st=
ored using such system and are accessible by third party providers of such =
system on a limited basis. Your sending of emails to Amdocs evidences your =
consent to the use of such system and such processing, storing and access=
=E2=80=9D.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Oct 17 01:56:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34933129AB8 for ; Wed, 17 Oct 2018 01:56:10 -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, 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 ZXGBe7LDbizF for ; Wed, 17 Oct 2018 01:56:08 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D18ED12DD85 for ; Wed, 17 Oct 2018 01:56:07 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0A35E6005A; Wed, 17 Oct 2018 08:56:06 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <1539732745739.66497@Aviatnet.com>
Date: Wed, 17 Oct 2018 04:56:05 -0400
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org>
References:  <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com>
To: Alex Campbell 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 08:56:10 -0000

The point is to keep this open to however the community might end up =
choosing to use it. The act of pre-defining tags doesn't disallow other =
tags being defined, in fact at this point I've sent a bunch of email =
defending leaving things as open as possible. They both can co-exist. :)

Thanks,
Chris.

> On Oct 16, 2018, at 7:32 PM, Alex Campbell =
 wrote:
>=20
> I have no issue with systems using tags to classify or organize =
modules, however this seems to me like something that would be specific =
to the system doing the classifying.

Sure we support this. That's what user tag configuration is there for.

> It would not be something that needs to be specified in the module =
itself (except perhaps as freeform description text), and it certainly =
would not need to involve the NETCONF server.
> What would a server do with module classification data? (unless it is =
also implementing some kind of module browsing interface, in which case =
it might be used to supply the browser with data)

The server implements the tags (at least the predefined ones), and the =
use cases that come to my mind at least involve clients not servers. I'm =
not saying there wouldn't be a server use case, but it's not as obvious =
to me.=20

And yes implementing some kind of module browsing interface (which could =
group modules by tags) is a fine example of how tags can be used.

>=20
> Hashtags - all types, that I'm aware of - are inherently freeform and =
fluid, changing quickly according to the desires of users. I don't think =
it makes sense to "hard-code" them in published RFCs or even published =
vendor modules or firmware.
>=20
> Tomorrow, I might want to list all modules for management plane =
protocols. As a network operator, should I go and update the =
ietf-module-tags on all of my network elements? That seems silly. This =
should be client-side data. (And if I did, what happens when I add a new =
router and forget to update its tag data? Will that confuse the client?)

I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to =
modules is exactly the point of pre-defined tags, but you questioned =
their value at the top of your mail.

Either way configuring a newly installed router is a given, I don't =
think this is the place to solve the "forgot to add all the config to my =
new router install" issue. :) If one is using tags in ones network then =
making sure the newly installed router has tags configured the way you =
expect is no different from making sure that you configured IS-IS =
correctly.

Thanks,
Chris.

>=20
> Regards, Alex
>=20
> ________________________________________
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 1:04 a.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 =
- 10/16/18
>=20
>>=20
>> On Oct 3, 2018, at 8:22 PM, Alex Campbell =
 wrote:
>>=20
>> The introduction does not explain what they are useful for
>=20
> The second sentence of the abstract: "The expectation is for such tags =
to be used to help classify and organize modules." The introduction =
repeats this in the first sentence. I'm not sure how much differently we =
could say "Tags are useful for organizing and classifying modules". Are =
you asking for justification on the usefulness of organizing and =
classifying things? I think this concept is rather widely accepted.
>=20
>=20
>> , it just makes a comparison to #hashtags (which is something I would =
expect to see in an April 1st RFC).
>=20
> Using tags to help organize collections of data is literally =
ubiquitous: Movies/music/media, IP routes, and yes even social media are =
just a few examples.  Regarding April 1st, are you are unfairly =
restricting your perspective to only the ironic use of hashtags? =
Hashtags organically developed as a useful and widely used way for =
people and groups to add meta-data to their messages which then allowed =
other services to collect and present them in useful ways. Indeed =
businesses and other groups use hashtags for this purpose to great =
success. It was hardly a joke, and for many folks it is immediately =
useful to understand what is being proposed.
>=20
> Thanks,
> Chris.
>=20


From nobody Wed Oct 17 02:45:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7CD12D4EA for ; Wed, 17 Oct 2018 02:45:46 -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, 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 n2MNkPw1tlKH for ; Wed, 17 Oct 2018 02:45:44 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E842129AB8 for ; Wed, 17 Oct 2018 02:45:44 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7DE116005A; Wed, 17 Oct 2018 09:45:43 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <20181017.084754.967504021504890362.mbj@tail-f.com>
Date: Wed, 17 Oct 2018 05:45:41 -0400
Cc: Christian Hopps , andy@yumaworks.com, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3400C526-0196-4405-880D-3591E0B16A85@chopps.org>
References:    <20181017.084754.967504021504890362.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 09:45:47 -0000

> On Oct 17, 2018, at 2:47 AM, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> Christian Hopps  wrote:
>>=20
>> Andy Bierman  writes:
>>>=20
>>> This draft needs to define the module-tag encoding wrt/
>>>   - valid characters (e.g., some subset of UTF-8)
>>>   - min/max length (e.g., implementation MUST support at least 64 =
chars
>>> and can support larger)
>>=20
>> I'm looking for suggestions on how to do this subset. We had intended
>> to allow for as wide as possible content; however, I think =
disallowing
>> tabs, newlines, carriage returns is more than reasonable. Has a type
>> like this already been standardized or is there an example available
>> somewhere?
>>=20
>>> Section 3 (Tag Prefixes) seems to imply that all modules tags follow =
a
>>> structure to specify the naming authority.
>>>=20
>>> According to the YANG module, the data type is a plain string, which
>>> includes lots of
>>> problematic chars and zero-length strings.
>>>=20
>>> Does the string "routing" match "ietf:routing" or "vendor:routing"?
>>> How
>>> about "routing:bgp"?
>>=20
>> No. Do we need to state that non-matching strings don't match?
>=20
> The word "match" is imo problematic.  Use "equal" if that's what you
> mean.  But you're not actually using the word "match" in the draft, so
> that's fine.  However, I think the draft can be clarified.  See below.
>=20
> In this case, it _seems_ like there's some hierarchy with tags
> like:
>=20
>  ietf:routing
>  ietf:routing:rib
>=20
> For example, does ietf:routing:rib imply ietf:routing?
>=20
> =46rom your last emails, it seems that the idea is that tags are =
really
> just strings with the only property that they can be compared for
> equality.  If this is the case, I think it can be made more clear in
> the document.  And if this is the case, I think that type "string" is
> actually fine.  If someone wants to assign the tag
> "vendor:acme::::::::: ", let them.
>=20
> OTOH, if the idea is that the tags are hierarchical, and
> ietf:routing-rib implies ietf:routing, then a more specific type is
> needed, and more text.

I'm going to remove the colons (except for the one in the prefix). This =
has caused a lot of confusion. It is as you say supposed to be free-form =
after the prefix. Yes, there was an implied structure being suggested, =
but there was no intention to try and standardize this structure. In the =
end it comes off as half-baked and confusing so better to remove it.

FWIW I originally envisioned a more flat tag space anyway, so =
ietf:routing and ietf:igp. I'm not sure how we ended up suggesting =
hierarchy.=20

Thanks,
Chris.

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>>> Is the char ":" allowed in a tag?
>>=20
>> Yes, why not?
>>=20
>>> Is "vendor::::::::" a valid tag?
>>=20
>> Again why not?
>>=20
>> The only thing the draft talks about are standard prefixes. Why =
should
>> a standard enumerate a subset of the unbounded set of things it isn't
>> standardizing? This seems more confusing (why was X included as OK =
but
>> not Y) than just sticking to what it *is* standardizing.
>>=20
>> Perhaps a bit of text saying more explicitly that only the prefix is
>> restricted would help though?
>>=20
>>> IMO this draft does not need to define any specific module-tag =
content
>>> but
>>> it does need to define
>>> in precise terms how a protocol encodes a module-tag and how a
>>> module-tag
>>> match is determined.
>>=20
>> We considered leaving out all the predefined tags, but conversely we
>> also thought it would be useful to establish a base set. We went with
>> the latter obviously. Perhaps it just needs to be trimmed down more?
>>=20
>> Thanks,
>> Chris.
>>=20
>>>=20
>>>=20
>>> Thanks,
>>>> Chris.
>>>>=20
>>>=20
>>> Andy
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 17 02:49:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5B512D4EB for ; Wed, 17 Oct 2018 02:49:35 -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, 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 x1hYGDbPlTXs for ; Wed, 17 Oct 2018 02:49:33 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6A412D4EA for ; Wed, 17 Oct 2018 02:49:33 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9906F6005A; Wed, 17 Oct 2018 09:49:32 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: 
Date: Wed, 17 Oct 2018 05:49:30 -0400
Cc: Christian Hopps , Juergen Schoenwaelder , joel jaeggli , NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de>     
To: Andy Bierman 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 09:49:35 -0000

> On Oct 16, 2018, at 7:39 PM, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps  =
wrote:
>=20
> Andy Bierman  writes:
>=20
> This draft needs to define the module-tag encoding wrt/
>    - valid characters (e.g., some subset of UTF-8)
>    - min/max length (e.g., implementation MUST support at least 64 =
chars
> and can support larger)
>=20
> I'm looking for suggestions on how to do this subset. We had intended =
to allow for as wide as possible content; however, I think disallowing =
tabs, newlines, carriage returns is more than reasonable. Has a type =
like this already been standardized or is there an example available =
somewhere?
>=20
> I suppose yang-identifier type is too restrictive so I will agree that =
restricting whitespace and colon chars
> is probably good enough=20


I'm going to use:

  typedef tag {
    type string {
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
      length "1..max";
    }
    description
      "A tag value is composed of a standard prefix followed
       by any string value that does not include carriage return,
       form-feed, newline or tab characters."
  }

I left in space -- lot's of people in the non-unix world use spaces.

Thanks,
Chris.=


From nobody Wed Oct 17 03:23:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEAF12F1AB for ; Wed, 17 Oct 2018 03:23:57 -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, 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 37wNqpa9aGLn for ; Wed, 17 Oct 2018 03:23:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC512DD85 for ; Wed, 17 Oct 2018 03:23:54 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id BF6201AE0399; Wed, 17 Oct 2018 12:23:50 +0200 (CEST)
Date: Wed, 17 Oct 2018 12:23:50 +0200 (CEST)
Message-Id: <20181017.122350.1527287254258681037.mbj@tail-f.com>
To: chopps@chopps.org
Cc: rohitrranade@huawei.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 10:23:58 -0000

Christian Hopps  wrote:
> 
> 
> > On Oct 17, 2018, at 12:09 AM, Rohit R Ranade 
> > wrote:
> > 
> > 1. In the desrciption of leaf-list tag
> >   "
> >   The operational view of this list will contain all
> >              user-configured tags as well as any predefined tags that
> >              have not been masked by the user using the masked-tag leaf
> >              list below.
> >   "
> >   ==> So the predefined tags, should be output as  origin in
> >    ?
> >   If so, I would suggest renaming them to "default" tags.
> 
> default has this in it's definition:
>  
>     "The default origin is only used when the configuration has not been
>      provided by any other source."
> 
> The predefined tags are being added due to the module definition or by
> the vendor implementing the module, and the user would be adding to
> this set (not replacing) when they configure tags (and thus the reason
> for the mask). So I think predefined tags should have "system"
> origin. We can add text to the document to clarify this if others
> agree.

I agree that the origin should be "system" for these tags.

> > 2. For "masked-tag", if the purpose is to only mask "predefined" tags,
> > why not rename
> > as masked-default-tag or masked-predefined-tag ?
> > Also if a tag say tag-1 (not predefined) is added to this list, and
> > tag-1 added to "tag", the tag-1
> > will still be output in , which may look confusing to the
> > user as the tag-1 will exist
> > in both "tag" and "masked-tag". Changing the "masked-tag" may help in
> > this case.
> 
> What's the compelling reason to make this more complex? Right now, the
> predefined tags are added, the configured tags are added, and then the
> masks are applied. KISS is the goal.

But this is not what the draft says.  The description of masked-tag
says that predefined tags are removed.

Keep it simple, but make sure the description is clear.  So maybe add
your 3 steps above to the draft, and remove the word "predefined" from
the description of masked-tag.


/martin


> > 3.  It is still not clear, what is the use-case where user wants to
> > "mask" a predefined tag..
> 
> The user is the ultimate arbiter over their network is the point. On
> example is a vendor adds a tag indicating the module belongs to a
> certain category of modules which would enable it's use in that users
> network, but for whatever reason the user does not agree.
> 
> > 4. What about already existing modules which donot define the tags,
> > should they be output in the
> >   "module-tags" list ? Or better to use "min-elements" for leaf-list
> >   "tags" ?
> 
> If they have no tags, there's no reason for them to be in the list,
> whether they come before or after the publication of this document (or
> after a device implements it). However, any client software is going
> to need to deal with no module entry, and also with an entry with no
> tags. I think it's better to stay away from adding restrictions that
> don't add real value, but do allow for software to "get it wrong".
> 
> > 5. I also agree with other reviewer's comment that this document must
> > standardize what a module-tag must look like.
> >   Currently it only standardizes a prefix, if the rest of the tag is not
> >   standardized a client has no way to parse
> >   this tag.
> >   Maybe we can say that a tag will contain 3 parts, 1st part is about
> >   organization, 2nd part is about the whether it is service / element,
> >   3rd part
> >   can be a sub-category of part-2.
> 
> There's a lot of prior art here in leaving this open to however people
> want to use the meta-data (see routing admin-tags, media tags, social
> media tags, etc).. The reservation of prefix space allows for future
> definition if that ends up being needed. Users are free to define
> whatever structure they want if any. This discussion in particular was
> carried out over routing admin tags in the IETF and not pre-defining
> structure/meaning was the end result and has worked out well.
> 
> Thanks,
> Chris.
> 
> >  
> > With Regards,
> > Rohit R
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Oct 17 03:42:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3A12DD85 for ; Wed, 17 Oct 2018 03:42:30 -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, 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 ncmGIqemvinG for ; Wed, 17 Oct 2018 03:42:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E0D4C128B14 for ; Wed, 17 Oct 2018 03:42:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D08581AE0399; Wed, 17 Oct 2018 12:42:26 +0200 (CEST)
Date: Wed, 17 Oct 2018 12:42:26 +0200 (CEST)
Message-Id: <20181017.124226.2219617093194292187.mbj@tail-f.com>
To: chopps@chopps.org
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 10:42:30 -0000

Christian Hopps  wrote:
> 
> 
> > On Oct 16, 2018, at 7:39 PM, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps  wrote:
> > 
> > Andy Bierman  writes:
> > 
> > This draft needs to define the module-tag encoding wrt/
> >    - valid characters (e.g., some subset of UTF-8)
> >    - min/max length (e.g., implementation MUST support at least 64 chars
> > and can support larger)
> > 
> > I'm looking for suggestions on how to do this subset. We had intended to allow for as wide as possible content; however, I think disallowing tabs, newlines, carriage returns is more than reasonable. Has a type like this already been standardized or is there an example available somewhere?
> > 
> > I suppose yang-identifier type is too restrictive so I will agree that restricting whitespace and colon chars
> > is probably good enough 
> 
> 
> I'm going to use:
> 
>   typedef tag {
>     type string {
>       pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';

Ok.  Note that the legal characters in "string" are different in YANG
version 1 and 1.1, so this is a good reason (theoretical perhaps) to
use 1.1.

I do think that this module should be 1.1.  A number of fixes were
done in 1.1, and unless there are strong reasons not to use 1.1, you
should use it.  The string type is one example, and the effect on the
size of  in NETCONF is another.


/martin


>       length "1..max";
>     }
>     description
>       "A tag value is composed of a standard prefix followed
>        by any string value that does not include carriage return,
>        form-feed, newline or tab characters."
>   }
> 
> I left in space -- lot's of people in the non-unix world use spaces.
> 
> Thanks,
> Chris.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Oct 17 04:46:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6783130DC8 for ; Wed, 17 Oct 2018 04:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 TDDyxANjiiqo for ; Wed, 17 Oct 2018 04:46:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9A886124BE5 for ; Wed, 17 Oct 2018 04:46:17 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 521C34C828645 for ; Wed, 17 Oct 2018 12:46:14 +0100 (IST)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 12:46:15 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0399.000; Wed, 17 Oct 2018 19:46:03 +0800
From: Rohit R Ranade 
To: Christian Hopps 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Review comments for module-tags-02
Thread-Index: AdRlz2ZrcdhVQBKIRg2w21rqsHkwQf//xHQA//9Ky/A=
Date: Wed, 17 Oct 2018 11:46:03 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 11:46:21 -0000

I think we need to define a subtree for non-NMDA clients to get the operati=
onal tags.

Reference:  https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
"   2.  Models that require immediate support for "in use" and "system
       created" information SHOULD be structured for NMDA.  A non-NMDA
       version of these models SHOULD also be published, using either an
       existing model or a model created either by hand or with suitable
       tools that support current modeling strategies.  Both the NMDA
       and the non-NMDA modules SHOULD be published in the same
       document, with NMDA modules in the document main body and the
       non-NMDA modules in a non-normative appendix.  The use of the
       non-NMDA model will allow temporary bridging of the time period
       until NMDA implementations are available." =20

-----Original Message-----
From: Christian Hopps [mailto:chopps@chopps.org]=20
Sent: 17 October 2018 14:08
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02



> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade  wr=
ote:
>=20
> 1. In the desrciption of leaf-list tag
>   "
>   The operational view of this list will contain all
>              user-configured tags as well as any predefined tags that
>              have not been masked by the user using the masked-tag leaf
>              list below.
>   "
>   =3D=3D> So the predefined tags, should be output as  origin  i=
n  ?
>   If so, I would suggest renaming them to "default" tags.

default has this in it's definition:
=20
    "The default origin is only used when the configuration has not been
     provided by any other source."

The predefined tags are being added due to the module definition or by the =
vendor implementing the module, and the user would be adding to this set (n=
ot replacing) when they configure tags (and thus the reason for the mask). =
So I think predefined tags should have "system" origin. We can add text to =
the document to clarify this if others agree.

> 2. For "masked-tag", if the purpose is to only mask "predefined" tags,=20
> why not rename as masked-default-tag or masked-predefined-tag ?
> Also if a tag say tag-1 (not predefined) is added to this list, and=20
> tag-1 added to "tag", the tag-1 will still be output in ,=20
> which may look confusing to the user as the tag-1 will exist in both "tag=
" and "masked-tag". Changing the "masked-tag" may help in this case.

What's the compelling reason to make this more complex? Right now, the pred=
efined tags are added, the configured tags are added, and then the masks ar=
e applied. KISS is the goal.

> 3.  It is still not clear, what is the use-case where user wants to "mask=
" a predefined tag..

The user is the ultimate arbiter over their network is the point. On exampl=
e is a vendor adds a tag indicating the module belongs to a certain categor=
y of modules which would enable it's use in that users network, but for wha=
tever reason the user does not agree.

> 4. What about already existing modules which donot define the tags, shoul=
d they be output in the
>   "module-tags" list ? Or better to use "min-elements" for leaf-list "tag=
s" ?

If they have no tags, there's no reason for them to be in the list, whether=
 they come before or after the publication of this document (or after a dev=
ice implements it). However, any client software is going to need to deal w=
ith no module entry, and also with an entry with no tags. I think it's bett=
er to stay away from adding restrictions that don't add real value, but do =
allow for software to "get it wrong".

> 5. I also agree with other reviewer's comment that this document must sta=
ndardize what a module-tag must look like.
>   Currently it only standardizes a prefix, if the rest of the tag is not =
standardized a client has no way to parse
>   this tag.
>   Maybe we can say that a tag will contain 3 parts, 1st part is about org=
anization, 2nd part is about the whether it is service / element, 3rd part
>   can be a sub-category of part-2.

There's a lot of prior art here in leaving this open to however people want=
 to use the meta-data (see routing admin-tags, media tags, social media tag=
s, etc).. The reservation of prefix space allows for future definition if t=
hat ends up being needed. Users are free to define whatever structure they =
want if any. This discussion in particular was carried out over routing adm=
in tags in the IETF and not pre-defining structure/meaning was the end resu=
lt and has worked out well.

Thanks,
Chris.

> =20
> With Regards,
> Rohit R
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 17 04:51:55 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3865130DCF; Wed, 17 Oct 2018 04:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 gIQbyrJ4fZv1; Wed, 17 Oct 2018 04:51:51 -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 D26CB130DC1; Wed, 17 Oct 2018 04:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4148; q=dns/txt; s=iport; t=1539777111; x=1540986711; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RkPElH7WKKcTjuWLlCtphM6b5Bb2cY0f6d5BkF/v0t4=; b=m10uw94Ay9hvMgZtdwEnI6P+5rhPs3pIcsfa2AhVwZcUqlKcbmCicXph k/x/HQsOBB0DZcT8zSt8uufex/OhTXoDRUR3WmgZEEcspQGSdj5pLoUaz ZY18c2E8fN5JXyklREUfTlKbDetijeOZDaFP+qrJ33MEOhebeVh0dCCAY M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AAALIcdb/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJrbRIog3WIdo1IlyCBZg0jhEkChRc4FgEDAQECAQE?= =?us-ascii?q?CbRwMhTkBAQEBAgEjDwEFNgYFBQcECQIOAwMBAQEDAiMDAgJGCQgGAQwGAgE?= =?us-ascii?q?BgxwBgXkID4hPm02BLoQCAYE3hFkFgQuKWIFBP4ESJ4JrgxsEGIEUARIBH4M?= =?us-ascii?q?DglcCiFaVWwmGWIoFBheBT4Rxgm6GdIxIgzmGOoFaIWRxMxoIGxU7gmyGBIo?= =?us-ascii?q?cATc9MAEBiUqCPgEB?=
X-IronPort-AV: E=Sophos;i="5.54,392,1534809600";  d="scan'208";a="7253696"
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; 17 Oct 2018 11:51:48 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9HBpm5Q027397; Wed, 17 Oct 2018 11:51:48 GMT
To: Qin Wu , Kent Watsen , "adrian@olddog.co.uk" , "'Lou Berger'" , Adrian Farrel 
Cc: "'NetMod WG Chairs'" , "'NetMod WG'" 
References:  <056c01d46596$874bd260$95e37720$@olddog.co.uk> <34042279-8A05-4D95-9452-D2634E6408AF@juniper.net> 
From: Benoit Claise 
Message-ID: <45b3f321-641c-6e34-8deb-65dfb6bca5cb@cisco.com>
Date: Wed, 17 Oct 2018 13:51:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.55.221.36, ams-bclaise-nitro3.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 11:51:54 -0000

No, I am not aware of any IPR related to this draft.

Regards, B.

> No, I am not aware of any IPR related to this draft.
>
> -Qin
> -----邮件原件-----
> å‘件人: Kent Watsen [mailto:kwatsen@juniper.net]
> å‘é€æ—¶é—´: 2018å¹´10月17æ—¥ 5:56
> 收件人: adrian@olddog.co.uk; 'Lou Berger'; 'Benoit Claise'; Qin Wu; Adrian Farrel
> 抄é€: 'NetMod WG Chairs'; 'NetMod WG'
> 主题: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
>
> No, I'm not aware of any IPR that applies to this draft
>
> Kent // as an author
>
>
> -----Original Message-----
> From: Adrian Farrel 
> Reply-To: "adrian@olddog.co.uk" 
> Date: Tuesday, October 16, 2018 at 5:24 PM
> To: 'Lou Berger' , Kent Watsen , Benoit Claise , "bill.wu@huawei.com" , Adrian Farrel 
> Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
> Subject: RE: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
> Resent-From: 
> Resent-To: , , , 
> Resent-Date: Tuesday, October 16, 2018 at 5:24 PM
>
> Hi Lou,
>
> "No, I'm not aware of any IPR that applies to this draft"
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
>> Sent: 16 October 2018 21:26
>> To: Kent Watsen; Benoit Claise; bill.wu@huawei.com;
>> afarrel@juniper.net
>> Cc: NetMod WG Chairs; NetMod WG
>> Subject: [netmod] Regarding IPR on
>> draft-kwatsen-netmod-artwork-folding-08
>>
>> Authors, Contributors, WG,
>>
>> As part of preparation for WG Adoption
>>
>> Are you aware of any IPR that applies to drafts identified above?
>>
>> Please state either:
>>
>> "No, I'm not aware of any IPR that applies to this draft"
>> or
>> "Yes, I'm aware of IPR that applies to this draft"
>>
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>> (see RFCs 3669, 5378 and 8179 for more details)?
>>
>> If yes to the above, please state either:
>>
>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>> or
>> "No, the IPR has not been disclosed"
>>
>> If you answer no, please provide any additional details you think
>> appropriate.
>>
>> If you are listed as a document author or contributor please answer
>> the above by responding to this email regardless of whether or not you
>> are aware of any relevant IPR. This document will not advance to the
>> next stage until a response has been received from each author and
>> listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
>> MESSAGE'S TO LINES.
>>
>> If you are on the WG email list or attend WG meetings but are not
>> listed as an author or contributor, we remind you of your obligations
>> under the IETF IPR rules which encourages you to notify the IETF if
>> you are aware of IPR of others on an IETF contribution, or to refrain
>> from participating in any contribution or discussion related to your
>> undisclosed IPR. For more information, please see the RFCs listed
>> above and
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_group_iesg_trac_wiki_IntellectualProperty&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484&s=2agdiBlSJ2yMLyrlwdw80WL5jskn_fuVgO2jffkyfFY&e=.
>>
>> Thank you,
>> NetMod WG Chairs
>>
>> PS Please include all listed in the headers of this message in your
>> response.
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484&s=iYr0TUeVJZ2xSBy9gvelUf2HiK2uP3Lh5EsoBqfoACw&e=
>


From nobody Wed Oct 17 04:52:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774E130DD7 for ; Wed, 17 Oct 2018 04:52:05 -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 lJg8_WItZ_fc for ; Wed, 17 Oct 2018 04:52:03 -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 A9893130E17 for ; Wed, 17 Oct 2018 04:52:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 339FAEF9; Wed, 17 Oct 2018 13:52:02 +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 LfAKeODhCDvS; Wed, 17 Oct 2018 13:52:01 +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, 17 Oct 2018 13:52:02 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D92E20036; Wed, 17 Oct 2018 13:52:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6n6eLUst0R80; Wed, 17 Oct 2018 13:52:01 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id BB22320037; Wed, 17 Oct 2018 13:52:01 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 17 Oct 2018 13:52:01 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 13FC03002517AD; Wed, 17 Oct 2018 13:52:00 +0200 (CEST)
Date: Wed, 17 Oct 2018 13:52:00 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
CC: Christian Hopps , "netmod@ietf.org" 
Message-ID: <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Christian Hopps , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 11:52:06 -0000

On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:

> I think we need to define a subtree for non-NMDA clients to get the
> operational tags.

It is not much of a change for a _client_ to read a different
datastore hence I do not think this is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Oct 17 05:22:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458DC130DD3 for ; Wed, 17 Oct 2018 05:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jteZXTcnozUj for ; Wed, 17 Oct 2018 05:22:51 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9A1BD130DC1 for ; Wed, 17 Oct 2018 05:22:51 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A37CB85AE5D99; Wed, 17 Oct 2018 13:22:47 +0100 (IST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 13:22:49 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0399.000; Wed, 17 Oct 2018 20:22:41 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: Christian Hopps , "netmod@ietf.org" 
Thread-Topic: [netmod] Review comments for module-tags-02
Thread-Index: AdRlz2ZrcdhVQBKIRg2w21rqsHkwQf//xHQA//9Ky/CAAOt3AP//ckeA
Date: Wed, 17 Oct 2018 12:22:39 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 12:22:53 -0000

If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, the=
n we will need this separate subtree to show the system defined tags.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 17 October 2018 17:22
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:

> I think we need to define a subtree for non-NMDA clients to get the=20
> operational tags.

It is not much of a change for a _client_ to read a different datastore hen=
ce I do not think this is needed.

/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 Wed Oct 17 05:43:42 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDBE12D7EA; Wed, 17 Oct 2018 05:43:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <153978021314.27604.2486079848051101872@ietfa.amsl.com>
Date: Wed, 17 Oct 2018 05:43:33 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-module-tags-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 12:43:33 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : YANG Module Tags
        Authors         : Christan Hopps
                          Lou Berger
                          Dean Bogdanovic
	Filename        : draft-ietf-netmod-module-tags-03.txt
	Pages           : 11
	Date            : 2018-10-17

Abstract:
   This document provides for the association of tags with YANG modules.
   The expectation is for such tags to be used to help classify and
   organize modules.  A method for defining, reading and writing a
   modules tags is provided.  Tags may be standardized and assigned
   during module definition; assigned by implementations; or dynamically
   defined and set by users.  This document provides guidance to future
   model writers and, as such, this document updates
   [I-D.ietf-netmod-rfc6087bis].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-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 Wed Oct 17 05:47:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F28128D68 for ; Wed, 17 Oct 2018 05:47:46 -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 4yYBCwIXlhFm for ; Wed, 17 Oct 2018 05:47:44 -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 7538912D7EA for ; Wed, 17 Oct 2018 05:47:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 38FFBEED; Wed, 17 Oct 2018 14:47: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 WceaRyn1NSGe; Wed, 17 Oct 2018 14:47:42 +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, 17 Oct 2018 14:47:43 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2218020037; Wed, 17 Oct 2018 14:47:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BTrww037P8M0; Wed, 17 Oct 2018 14:47:42 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A585720036; Wed, 17 Oct 2018 14:47:42 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 17 Oct 2018 14:47:42 +0200
Received: by anna.localdomain (Postfix, from userid 501) id F28D83002519F3; Wed, 17 Oct 2018 14:47:41 +0200 (CEST)
Date: Wed, 17 Oct 2018 14:47:41 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
CC: Christian Hopps , "netmod@ietf.org" 
Message-ID: <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Christian Hopps , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 12:47:47 -0000

Obviously, this is now a slightly different statement. There are NMDA
transition guidelines that have been discussed at length and finally
been integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA
subtrees but instead you create an additional module that goes into an
appendix and is only relevant for transition purposes. I think Rob
created tools to generate such things. Section 4.23.3.1 also provides
some guidelines for creating temporary non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we will need this separate subtree to show the system defined tags.
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 17 October 2018 17:22
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
> 
> On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
> 
> > I think we need to define a subtree for non-NMDA clients to get the 
> > operational tags.
> 
> It is not much of a change for a _client_ to read a different datastore hence I do not think this is needed.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
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 17 06:14:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F412D4F2 for ; Wed, 17 Oct 2018 06:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 nbvTY0cHp4-z for ; Wed, 17 Oct 2018 06:13:59 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 57E7C12D4E8 for ; Wed, 17 Oct 2018 06:13:59 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AB5D4E64B2E04; Wed, 17 Oct 2018 14:13:53 +0100 (IST)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Oct 2018 14:13:15 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0399.000; Wed, 17 Oct 2018 21:13:06 +0800
From: Rohit R Ranade 
To: Juergen Schoenwaelder 
CC: Christian Hopps , "netmod@ietf.org" 
Thread-Topic: [netmod] Review comments for module-tags-02
Thread-Index: AdRlz2ZrcdhVQBKIRg2w21rqsHkwQf//xHQA//9Ky/CAAOt3AP//ckeAgACdSID//3TpAA==
Date: Wed, 17 Oct 2018 13:13:06 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com> <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 13:14:02 -0000

Either defining a new module in an Appendix or a subtree, I am OK with eith=
er and both of us concur that the draft needs the changes.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 17 October 2018 18:18
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

Obviously, this is now a slightly different statement. There are NMDA trans=
ition guidelines that have been discussed at length and finally been intega=
ted into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA subtrees=
 but instead you create an additional module that goes into an appendix and=
 is only relevant for transition purposes. I think Rob created tools to gen=
erate such things. Section 4.23.3.1 also provides some guidelines for creat=
ing temporary non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, t=
hen we will need this separate subtree to show the system defined tags.
>=20
> -----Original Message-----
> From: Juergen Schoenwaelder=20
> [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: 17 October 2018 17:22
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
>=20
> On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
>=20
> > I think we need to define a subtree for non-NMDA clients to get the=20
> > operational tags.
>=20
> It is not much of a change for a _client_ to read a different datastore h=
ence I do not think this is needed.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--=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 Wed Oct 17 07:23:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23B1277C8 for ; Wed, 17 Oct 2018 07:23:13 -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 lcszqg1N6mjA for ; Wed, 17 Oct 2018 07:23:11 -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 C28A8130DD6 for ; Wed, 17 Oct 2018 07:23:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 45AB7EED; Wed, 17 Oct 2018 16:23:09 +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 zJ2voYgZMpNE; Wed, 17 Oct 2018 16:23:08 +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, 17 Oct 2018 16:23:09 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31C4220036; Wed, 17 Oct 2018 16:23:09 +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 Y4Grp0VBL_k2; Wed, 17 Oct 2018 16:23:08 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 9F5FB20037; Wed, 17 Oct 2018 16:23:08 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Wed, 17 Oct 2018 16:23:08 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 052DC300252372; Wed, 17 Oct 2018 16:23:07 +0200 (CEST)
Date: Wed, 17 Oct 2018 16:23:07 +0200
From: Juergen Schoenwaelder 
To: Rohit R Ranade 
CC: Christian Hopps , "netmod@ietf.org" 
Message-ID: <20181017142307.h4sfqmxjjyzbeght@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Rohit R Ranade , Christian Hopps , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com> <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 14:23:14 -0000

The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.

/js

On Wed, Oct 17, 2018 at 01:13:06PM +0000, Rohit R Ranade wrote:
> Either defining a new module in an Appendix or a subtree, I am OK with either and both of us concur that the draft needs the changes.
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> Sent: 17 October 2018 18:18
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
> 
> Obviously, this is now a slightly different statement. There are NMDA transition guidelines that have been discussed at length and finally been integated into
> 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3
> 
> This section 4.23.3 says under case (a):
> 
>    Both the NMDA and the non-NMDA modules SHOULD
>    be published in the same document, with NMDA modules in the document
>    main body and the non-NMDA modules in a non-normative appendix.
> 
> In other words, you do not pollute a new NMDA module with non-NMDA subtrees but instead you create an additional module that goes into an appendix and is only relevant for transition purposes. I think Rob created tools to generate such things. Section 4.23.3.1 also provides some guidelines for creating temporary non NMDA modules.
> 
> /js
> 
> On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
> > If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we will need this separate subtree to show the system defined tags.
> > 
> > -----Original Message-----
> > From: Juergen Schoenwaelder 
> > [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: 17 October 2018 17:22
> > To: Rohit R Ranade 
> > Cc: Christian Hopps ; netmod@ietf.org
> > Subject: Re: [netmod] Review comments for module-tags-02
> > 
> > On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
> > 
> > > I think we need to define a subtree for non-NMDA clients to get the 
> > > operational tags.
> > 
> > It is not much of a change for a _client_ to read a different datastore hence I do not think this is needed.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
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 17 07:39:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA3A130E12 for ; Wed, 17 Oct 2018 07:39:29 -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, 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 s68tS7p1lN12 for ; Wed, 17 Oct 2018 07:39:27 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 50E34130DF0 for ; Wed, 17 Oct 2018 07:39:27 -0700 (PDT)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 93AC36005A; Wed, 17 Oct 2018 14:39:26 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <20181017142307.h4sfqmxjjyzbeght@anna.jacobs.jacobs-university.de>
Date: Wed, 17 Oct 2018 10:39:24 -0400
Cc: Christian Hopps , Rohit R Ranade , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EC0B63D-A4AF-4879-A9C2-842205DEBFF2@chopps.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com> <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com> <20181017142307.h4sfqmxjjyzbeght@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 14:39:36 -0000

I'll chime in as an operator here, I do not feel there is a need to =
support non-NMDA implementations with this brand new work that won't be =
finished let alone start being used for another so many months (at =
best). There's nothing wrong with simply requiring NMDA for various =
modules going forward. Indeed I'd like more modules to require NMDA if =
only to add pressure to get it deployed by vendors.

Thanks,
Chris.

> On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder =
 wrote:
>=20
> The WG needs to agree whether a -state module in the Appendix is
> needed. I just commented on the proposal to add a subtree, which
> violates the guidelines.
>=20
> /js
>=20
> On Wed, Oct 17, 2018 at 01:13:06PM +0000, Rohit R Ranade wrote:
>> Either defining a new module in an Appendix or a subtree, I am OK =
with either and both of us concur that the draft needs the changes.
>>=20
>> -----Original Message-----
>> From: Juergen Schoenwaelder =
[mailto:j.schoenwaelder@jacobs-university.de]=20
>> Sent: 17 October 2018 18:18
>> To: Rohit R Ranade 
>> Cc: Christian Hopps ; netmod@ietf.org
>> Subject: Re: [netmod] Review comments for module-tags-02
>>=20
>> Obviously, this is now a slightly different statement. There are NMDA =
transition guidelines that have been discussed at length and finally =
been integated into
>>=20
>> =
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3=

>>=20
>> This section 4.23.3 says under case (a):
>>=20
>>   Both the NMDA and the non-NMDA modules SHOULD
>>   be published in the same document, with NMDA modules in the =
document
>>   main body and the non-NMDA modules in a non-normative appendix.
>>=20
>> In other words, you do not pollute a new NMDA module with non-NMDA =
subtrees but instead you create an additional module that goes into an =
appendix and is only relevant for transition purposes. I think Rob =
created tools to generate such things. Section 4.23.3.1 also provides =
some guidelines for creating temporary non NMDA modules.
>>=20
>> /js
>>=20
>> On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
>>> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA =
drafts, then we will need this separate subtree to show the system =
defined tags.
>>>=20
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder=20
>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>> Sent: 17 October 2018 17:22
>>> To: Rohit R Ranade 
>>> Cc: Christian Hopps ; netmod@ietf.org
>>> Subject: Re: [netmod] Review comments for module-tags-02
>>>=20
>>> On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
>>>=20
>>>> I think we need to define a subtree for non-NMDA clients to get the=20=

>>>> operational tags.
>>>=20
>>> It is not much of a change for a _client_ to read a different =
datastore hence I do not think this is needed.
>>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>> Fax:   +49 421 200 3103         
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20


From nobody Wed Oct 17 10:39:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01E130EDC for ; Wed, 17 Oct 2018 10:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8n-8KYHr5eq for ; Wed, 17 Oct 2018 10:39:55 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004E91293FB for ; Wed, 17 Oct 2018 10:39:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 809B7154169C; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wnB7G0EIGQWx; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5528E154169D; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7lDid9aCkwrF; Wed, 17 Oct 2018 19:39:52 +0200 (CEST)
Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id F02D21541699; Wed, 17 Oct 2018 19:39:51 +0200 (CEST)
To: Christian Hopps , Juergen Schoenwaelder 
Cc: "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC65480@dggeml510-mbx.china.huawei.com> <20181017115200.ob2kxlmt2how6jd6@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC654FE@dggeml510-mbx.china.huawei.com> <20181017124741.xkjnlma3bi42xv2d@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BC65548@dggeml510-mbx.china.huawei.com> <20181017142307.h4sfqmxjjyzbeght@anna.jacobs.jacobs-university.de> <6EC0B63D-A4AF-4879-A9C2-842205DEBFF2@chopps.org>
From: Vladimir Vassilev 
Message-ID: <8d738b2b-268c-c117-99cc-ed5518252bb0@transpacket.com>
Date: Wed, 17 Oct 2018 19:39:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <6EC0B63D-A4AF-4879-A9C2-842205DEBFF2@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Review comments for module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 17:39:57 -0000

Hi,

Adding=C2=A0 -state modules to all new drafts seems like unnecessary=20
overhead. Even mentioning NMDA in a draft that has no logical=20
relationship to NMDA also seems like unnecessary overhead.

Not a great set of alternatives. The positive thing is that vendors that=20
do not have to worry about existing applications should really have no=20
problem responding to the pressure.

Vladimir

On 10/17/18 4:39 PM, Christian Hopps wrote:
> I'll chime in as an operator here, I do not feel there is a need to sup=
port non-NMDA implementations with this brand new work that won't be fini=
shed let alone start being used for another so many months (at best). The=
re's nothing wrong with simply requiring NMDA for various modules going f=
orward. Indeed I'd like more modules to require NMDA if only to add press=
ure to get it deployed by vendors.
>
> Thanks,
> Chris.
>
>> On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder  wrote:
>>
>> The WG needs to agree whether a -state module in the Appendix is
>> needed. I just commented on the proposal to add a subtree, which
>> violates the guidelines.
>>
>> /js
>>
>> On Wed, Oct 17, 2018 at 01:13:06PM +0000, Rohit R Ranade wrote:
>>> Either defining a new module in an Appendix or a subtree, I am OK wit=
h either and both of us concur that the draft needs the changes.
>>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university=
.de]
>>> Sent: 17 October 2018 18:18
>>> To: Rohit R Ranade 
>>> Cc: Christian Hopps ; netmod@ietf.org
>>> Subject: Re: [netmod] Review comments for module-tags-02
>>>
>>> Obviously, this is now a slightly different statement. There are NMDA=
 transition guidelines that have been discussed at length and finally bee=
n integated into
>>>
>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4=
.23.3
>>>
>>> This section 4.23.3 says under case (a):
>>>
>>>    Both the NMDA and the non-NMDA modules SHOULD
>>>    be published in the same document, with NMDA modules in the docume=
nt
>>>    main body and the non-NMDA modules in a non-normative appendix.
>>>
>>> In other words, you do not pollute a new NMDA module with non-NMDA su=
btrees but instead you create an additional module that goes into an appe=
ndix and is only relevant for transition purposes. I think Rob created to=
ols to generate such things. Section 4.23.3.1 also provides some guidelin=
es for creating temporary non NMDA modules.
>>>
>>> /js
>>>
>>> On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
>>>> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA draf=
ts, then we will need this separate subtree to show the system defined ta=
gs.
>>>>
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>> Sent: 17 October 2018 17:22
>>>> To: Rohit R Ranade 
>>>> Cc: Christian Hopps ; netmod@ietf.org
>>>> Subject: Re: [netmod] Review comments for module-tags-02
>>>>
>>>> On Wed, Oct 17, 2018 at 11:46:03AM +0000, Rohit R Ranade wrote:
>>>>
>>>>> I think we need to define a subtree for non-NMDA clients to get the
>>>>> operational tags.
>>>> It is not much of a change for a _client_ to read a different datast=
ore hence I do not think this is needed.
>>>>
>>>> /js
>>>>
>>>> --=20
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germa=
ny
>>>> Fax:   +49 421 200 3103         
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | German=
y
>>> Fax:   +49 421 200 3103         
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 17 10:56:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C65130EDD for ; Wed, 17 Oct 2018 10:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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=fail (1024-bit key) reason="fail (body has been altered)" header.d=amdocs.onmicrosoft.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 n3AvpNbgTxEN for ; Wed, 17 Oct 2018 10:56:45 -0700 (PDT)
Received: from mx3.amdocs.com (ramail2.amdocs.com [193.43.244.136]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8B61293FB for ; Wed, 17 Oct 2018 10:56:43 -0700 (PDT)
Received: from unknown (HELO ILHFDAGDRFE2.corp.amdocs.com) ([10.224.0.130]) by ilmail02.corp.amdocs.com with ESMTP; 17 Oct 2018 20:56:39 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILHFDAGDRFE2 (10.237.240.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 17 Oct 2018 20:56:40 +0300
Received: from ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34; Wed, 17 Oct 2018 20:56:39 +0300
Received: from ILRNAEXCHEDGE02.corp.amdocs.com (10.233.34.168) by ILRNAEXCHCAS02.corp.amdocs.com (10.232.216.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.845.34 via Frontend Transport; Wed, 17 Oct 2018 20:56:39 +0300
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (192.168.34.8) by msgedge.amdocs.com (192.168.34.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.845.34; Wed, 17 Oct 2018 20:56:39 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Amdocs.onmicrosoft.com; s=selector1-amdocs-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u93hDCr9ga/cwwYAExLEWX8MVN4UNMwpvHaGuTVlW18=; b=NQ1rMIpbnDcSWt2/SpbhQnWqQIT6euOZXQcOmvMs2x0zevEOhBEFhPwF5VQ4YxFRTpMD9eXKmKAe6JIyZpdEEpCDiYS+IAQFUwH6JjSDrqHFIVh3h7vP1jz4wGi/KKk0mjwXf9JJSeSXj2DXrSeGtwUKSK60vd7b7cXb+qG7WCo=
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com (52.133.58.152) by AM0PR06MB5155.eurprd06.prod.outlook.com (20.178.20.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.21; Wed, 17 Oct 2018 17:56:37 +0000
Received: from AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1]) by AM0PR06MB4083.eurprd06.prod.outlook.com ([fe80::389e:ca21:ccc7:d6b1%5]) with mapi id 15.20.1228.027; Wed, 17 Oct 2018 17:56:37 +0000
From: Michael Rehder 
To: Ladislav Lhotka , Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AdRf+I5wQXpIeuYeT8uFcZ4kUETNSAArOyOAAAESuDAAATBXgAAAIxIgAAXi54AAAG/FwAAAei6AAAKI+5AALiXBgAAuGd8AAAATuoAAPS9MgABQPKNgAF6DoYAABGoXEA==
Date: Wed, 17 Oct 2018 17:56:37 +0000
Message-ID: 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <87woqhhsk4.fsf@nic.cz>
In-Reply-To: <87woqhhsk4.fsf@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Rehder@Amdocs.com; 
x-originating-ip: [192.95.160.116]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR06MB5155; 6:As1uwbO7Blo+u2Dr1SC7khBgkaihlhXf4JNrgglqKZZy5kmYCXiQmAtnhr6/2r03Z8K3846sveUZd5eJCPBpVuq++Fh2Mjq145wwRoYoK3iu2R0HZvJrotI4KYKtuqD2lF63DQyPHoO/dVZ0Dh7cfBM7r4qDZf50K3DqtLUK5OfCfV4i0BbFwA/A8/y/KIQQX3/XBW0S8PvtcFvZhadB6rJijBEFpjV1KS7ZZOEsiJ59fNmGDCJSXzTLg9WJ/pvx5Xn6tYPAkfnwDF+xJNkb310fm7op/rkIkS7q045v0wmlCbuaNMiLHrQXS+fUpccGu01PAsyQXPnSwDVxY5cWu7UdJtr99g2Pj0GMkC89SljM68cZ0HliMlqHNGcdnAGqWa+5CRDmDMUB0JUOENpZpdh66nHZmxdiTnwR7TVv2o0J0sOzOeLO+Hn6dxZMyaOKZdEPJgKvb/Nj+x2Gv49DjQ==; 5:AXbe3OWjD9kowTf3OM0GYUGdBhNQm9ICOWVbFSnb5LHC3ruFKAUCXF/W1EYnFVqL89mOF7TuHI8oBR7ohrF3d6mnUFxzJQM8c8aIvwlF4IK5gsnWeur9k+07KEnabjAm2eIUd4qo+VVrulbfXObVoUFd64v3+2QHz20WMScSXF0=; 7:An9n2CxervEXv7Gq1H8tcJF/Oa4gyBPZYNamRdag7ZxbzfOhl/FU8kp4GC500UZjoKUDqLiZE5i6mhB6j3Ffu+ylU44GRkxDQlTAAsNthxcZy2jTw1aNAMXkA8QVZYHHXMBCfjsL8TmK92cuKk8t//PiibpztJQ+yw8ER+br394Idl1fu5GcYnt60Lfb99AlJZbywrzW5b50vWZMdnGV+gSqzgLMC5kcGVXzS4ElNFd45i6YdeZjfGY9pFHcfC7o
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7c8df2e7-f72f-4dd7-8c50-08d63459e28e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR06MB5155; 
x-ms-traffictypediagnostic: AM0PR06MB5155:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(131327999870524)(166566539817055);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR06MB5155; BCL:0; PCL:0; RULEID:; SRVR:AM0PR06MB5155; 
x-forefront-prvs: 08286A0BE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(376002)(396003)(51444003)(189003)(199004)(13464003)(316002)(8676002)(93886005)(86362001)(114624004)(6436002)(2900100001)(72206003)(8936002)(81166006)(229853002)(6246003)(81156014)(25786009)(966005)(478600001)(74316002)(305945005)(7736002)(4326008)(6506007)(53546011)(71190400001)(71200400001)(76176011)(7696005)(68736007)(97736004)(110136005)(66066001)(99286004)(105586002)(14454004)(106356001)(26005)(186003)(33656002)(102836004)(5660300001)(2906002)(3846002)(256004)(5250100002)(446003)(11346002)(476003)(486006)(9686003)(55016002)(5024004)(14444005)(53936002)(6306002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR06MB5155; H:AM0PR06MB4083.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: Amdocs.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: JJf+SO9kZDYB0LIz9hNCLL0svOk4MwU0tRCOlnSJfyUf6DE575o5zHb7ijWz4gso+x1LOzCUjc/A8aXIxjklcEF1NkNZKC6VReZIT2d/fbOwmxgNHxTGQRFBeqDAwdOjwJC/qs6IFGa/gU+jn4XUy/KqnkkZOJKUhJH7f56xePjjT7ry3xYzatkPYSjiOSgFErdpkcKzblVycNnDpTGEnpZGVLG2uGSXWoDs4uSElB9/PZ6NOJ+cSupEnt47Dtb5omAwJoZubHqpPAltVg6Bo40hxT5uydF9uVMKJvgphWa7nPt5FFg/gp0MYwlve6pLiA1WOJ4BuQM6SNpD57QEqEghbkx7+ZMy0wKKTUpw0V8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c8df2e7-f72f-4dd7-8c50-08d63459e28e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2018 17:56:37.6079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8eca3ca-1276-46d5-9d9d-a0f2a028920f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB5155
X-OriginatorOrg: amdocs.com
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 17:56:48 -0000

VGhhdCdzIGV4YWN0bHkgbXkgcG9pbnQgLSBJIHRoaW5rIHRoYXQgdGhlIHdvcmRpbmcgaXMgdW5j
bGVhciBpbiB0aGUgUkZDLCB0aGF0ICJjb25kaXRpb25hbCIgZG9lc24ndCBuZWNlc3NhcmlseSBt
ZWFuIHRoZSBtYW5kYXRvcnkgc3RhdHVzIGlzIGlnbm9yZWQuDQoNCkJUVyBhIFNjaGVtYXRyb24g
cnVsZSBpcyBlbWl0dGVkIHRvIGVuc3VyZSBhICJtYW5kYXRvcnkgdHJ1ZSIgQ0hPSUNFIGhhcyBh
dCBsZWFzdCBvbmUgQ0FTRSBwcmVzZW50LCBzbyB0aGVyZSBhbHJlYWR5IGlzIGFuICJleGlzdGVu
dGlhbCIgY2hlY2sgYnVpbHQuDQoNCkknbGwgc3VnZ2VzdCBhIFlBTkcgZW5oYW5jZW1lbnQgb24g
InlhbmctbmV4dCIgZm9yIHRoZSBhYmlsaXR5IHRvIHJlc3BlY3QgbWFuZGF0b3J5IHN0YXR1cyBv
ciBub3QgYnkgYSB3aGVuIHN0YXRlbWVudC4NCg0KVGhhbmtzDQptaWtlDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExhZGlzbGF2IExob3RrYSBbbWFpbHRvOmxob3RrYUBu
aWMuY3pdDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNywgMjAxOCA0OjQzIEFNDQo+IFRv
OiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNvbT47IEp1ZXJnZW4gU2No
b2Vud2FlbGRlcg0KPiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiBD
YzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXSEVOIHN0YXRlbWVu
dCB3aXRoaW4gbWFuZGF0b3J5IG9iamVjdHMgZG9lc24ndA0KPiBlbnN1cmUgcHJlc2VuY2Ugb2Yg
dGhlIG1hbmRhdG9yeSBvYmplY3QNCj4gDQo+IE1pY2hhZWwgUmVoZGVyIDxNaWNoYWVsLlJlaGRl
ckBBbWRvY3MuY29tPiB3cml0ZXM6DQo+IA0KPiA+IEkndmUgcmVhZCByZmM2MTEwIGFuZCBJIGRp
ZG4ndCBzZWUgYW55IG1lbnRpb24gb2YgIldIRU4iIG9uIHRoZQ0KPiA+IG1hbmRhdG9yeSBzdGF0
dXMgKHNlY3Rpb24gOS4xLjEgT3B0aW9uYWwgYW5kIE1hbmRhdG9yeSBOb2RlcyBkb2Vzbid0DQo+
ID4gbGlzdCBpdCB3aGljaCBzZWVtcyBhIGJpdCBvZGQgdG8gbWUpLg0KPiANCj4gUkZDIDYxMTAg
d2FzIGJlaW5nIHByZXBhcmVkIGFsb25nIHdpdGggUkZDIDYwMjAsIGFuZCBzZWN0aW9uIDkuMS4x
IGlzIGNsb3NlbHkNCj4gcmVsYXRlZCB0byBzZWMuIDMuMSBpbiA2MDIwLg0KPiANCj4gPiBUaGUg
c2VjdGlvbiBvbiAiV0hFTiIganVzdCBtZW50aW9ucyB0aGUgeHBhdGggbWFwcGluZywgbm90IGFu
eXRoaW5nDQo+ID4gYWJvdXQgY2hhbmdpbmcgdGhlIG1hbmRhdG9yeSBzdGF0dXMgb2YgdGhlIGVu
Y2xvc2luZyBub2RlLg0KPiANCj4gSWYgeW91IHRha2UgaW50byBhY2NvdW50IHRoZSBEU0RMIHZh
bGlkYXRpb24gcHJvY2VkdXJlIChGaWd1cmUgMiBpbiBSRkMNCj4gNjExMCkgdGhlbiBldmVyeXRo
aW5nIGlzIElNTyBjbGVhcjoNCj4gDQo+IC0gTWFuZGF0b3J5IG5vZGVzIChhcyBkZWZpbmVkIGlu
IHNlYy4gOS4xLjEpIGFyZSBub3Qgd3JhcHBlZCBpbg0KPiAgIDxybmc6b3B0aW9uYWw+IGFuZCB0
aHVzIGFyZSByZXF1aXJlZCBkdXJpbmcgUkVMQVggTkcgc2NoZW1hDQo+ICAgdmFsaWRhdGlvbiwg
bm8gbWF0dGVyIHdoYXQgYW55ICJ3aGVuIiBleHByZXNzaW9uIHNheXMuDQo+IA0KPiAtIFNlY3Rp
b24gMTIuMTcgZXhwbGFpbnMgaG93IHdoZW4gZXhwcmVzc2lvbnMgYXJlIG1hcHBlZCB0byBTY2hl
bWF0cm9uDQo+ICAgYXNzZXJ0cy4gVGhpcyBtZWFucyB0aGF0IGlmIGFuIGluc3RhbmNlIG5vZGUg
ZXhpc3RzIGluIHRoZSBkYXRhIGFuZCBhDQo+ICAgd2hlbiBleHByZXNzaW9uIGF0dGFjaGVkIHRv
IHRoZSBjb3JyZXNwb25kaW5nIGRhdGEgbm9kZSBpbiBZQU5HDQo+ICAgZXZhbHVhdGVzIHRvIGZh
bHNlLCBTY2hlbWF0cm9uIHdpbGwgcmVwb3J0IGEgZmFpbGVkIGFzc2VydC4NCj4gDQo+IC0gTm90
ZSB0aGF0IFNjaGVtYXRyb24gY2Fubm90IGJ5IGRlZmluaXRpb24gcmVwb3J0IGFic2VuY2Ugb2Yg
YW4NCj4gICBpbnN0YW5jZSBiYXNlZCBvbiB0aGUgd2hlbiBleHByZXNzaW9uIGF0dGFjaGVkIHRv
IGl0cyBkYXRhDQo+ICAgbm9kZTogU2NoZW1hdHJvbiBydWxlcyBhcmUgb25seSBmaXJlZCBmb3Ig
ZWxlbWVudHMgdGhhdCBhcmUgcHJlc2VudCBpbg0KPiAgIHRoZSBpbnN0YW5jZSBkb2N1bWVudC4N
Cj4gDQo+ID4NCj4gPiBJIHN0aWxsIHRoaW5rIHRoYXQgdGhlIFlBTkcgUkZDIHdvcmRpbmcgb2Yg
ImNvbmRpdGlvbmFsIiBuZWVkcyB0byBpbmRpY2F0ZSBpZiB0aGUNCj4gbm9kZSBpcyBtYW5kYXRv
cnkgc3RhdHVzIGlzIGFmZmVjdGVkIG9yIG5vdC4NCj4gPiBOb3RlIHRoYXQgcmZjNjA2MCAiMy4x
IE1hbmRhdG9yeSBOb2RlcyIgZG9lc24ndCBtZW50aW9uICJXSEVOIiAoaXQNCj4gPiBkb2VzIG1l
bnRpb24gcHJlc2VuY2UpLg0KPiANCj4gUGVyaGFwcyB0aGlzIHRocmVhZCBpcyBqdXN0IGFib3V0
IG1pc3VuZGVyc3RhbmRpbmcgb2Ygd2hhdCAid2hlbiIgcmVhbGx5DQo+IG1lYW5zLCB3aGljaCBp
czogSW5zdGFuY2VzIGZvciB3aGljaCB0aGUgIndoZW4iIGV4cHJlc3Npb24gZXZhbHVhdGVzIHRv
IGZhbHNlDQo+IG11c3Qgbm90IGJlIHByZXNlbnQuDQo+IA0KPiBJdCBkb2VzIE5PVCBtZWFuIHRo
YXQgaW5zdGFuY2VzIGZvciB3aGljaCB0aGUgIndoZW4iIGV4cHJlc3Npb24gZXZhbHVhdGVzIHRv
DQo+IHRydWUgbXVzdCBiZSBwcmVzZW50Lg0KPiANCj4gTGFkYQ0KPiANCj4gPg0KPiA+IFRoYW5r
cw0KPiA+IE1pa2UNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog
SnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4+IFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlXQ0KPiA+PiBTZW50OiBTYXR1cmRheSwgT2N0b2JlciAxMywgMjAxOCA1
OjIwIFBNDQo+ID4+IFRvOiBNaWNoYWVsIFJlaGRlciA8TWljaGFlbC5SZWhkZXJAQW1kb2NzLmNv
bT4NCj4gPj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0g
V0hFTiBzdGF0ZW1lbnQgd2l0aGluIG1hbmRhdG9yeSBvYmplY3RzIGRvZXNuJ3QNCj4gPj4gZW5z
dXJlIHByZXNlbmNlIG9mIHRoZSBtYW5kYXRvcnkgb2JqZWN0DQo+ID4+DQo+ID4+IE9uIEZyaSwg
T2N0IDEyLCAyMDE4IGF0IDA0OjA4OjQ4UE0gKzAwMDAsIE1pY2hhZWwgUmVoZGVyIHdyb3RlOg0K
PiA+Pg0KPiA+PiA+IFRoZSBtYW5kYXRvcnkgc3RhdGVtZW50IGluIHRoYXQgY2FzZSBpcyBpZ25v
cmVkIChJ4oCZdmUgcG9pbnRlZCBvdXQNCj4gPj4gPiB0aGUgUk5HIGFuZCBTY2hlbWF0cm9uIGxh
Y2sgb2YgZW5mb3JjZW1lbnQpLiAgV0hFTiB0cnVtcHMgdGhlDQo+ID4+ID4gbWFuZGF0b3J5IHN0
YXR1cyAodmlhIGV4cGxpY2l0IG1hbmRhdG9yeSBvciBpbXBsaWNpdCBtYW5kYXRvcnkgdmlhDQo+
ID4+ID4gbWluLWVsZW1lbnRzDQo+ID4+ID4gMSkNCj4gPj4NCj4gPj4gSGFzIHRoZSBSTkcgYW5k
IFNjaGVtYXRyb24gYmVlbiBvYnRhaW5lZCBmb2xsb3dpbmcgUkZDIDYxMTA/IElmIHNvLA0KPiA+
PiB0aGlzIG1heSBiZSBhIHByb2JsZW0gd2l0aCBSRkMgNjExMCBidXQgbm90IHdpdGggWUFORyBp
dHNlbGYuIFRoZXJlDQo+ID4+IGFyZSB2YWxpZGF0b3JzIHRoYXQgZG8gbm90IHVzZSBSTkcgb3Ig
U2NoZW1hdHJvbi4NCj4gPj4NCj4gPj4gL2pzDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEp1ZXJnZW4g
U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+
ID4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5
IEJyZW1lbiB8IEdlcm1hbnkNCj4gPj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8
aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+IOKAnEFtZG9jc+KAmSBlbWFp
bCBwbGF0Zm9ybSBpcyBiYXNlZCBvbiBhIHRoaXJkLXBhcnR5LCB3b3JsZHdpZGUsIGNsb3VkLWJh
c2VkDQo+IHN5c3RlbS4gQW55IGVtYWlscyBzZW50IHRvIEFtZG9jcyB3aWxsIGJlIHByb2Nlc3Nl
ZCBhbmQgc3RvcmVkIHVzaW5nIHN1Y2gNCj4gc3lzdGVtIGFuZCBhcmUgYWNjZXNzaWJsZSBieSB0
aGlyZCBwYXJ0eSBwcm92aWRlcnMgb2Ygc3VjaCBzeXN0ZW0gb24gYSBsaW1pdGVkDQo+IGJhc2lz
LiBZb3VyIHNlbmRpbmcgb2YgZW1haWxzIHRvIEFtZG9jcyBldmlkZW5jZXMgeW91ciBjb25zZW50
IHRvIHRoZSB1c2Ugb2YNCj4gc3VjaCBzeXN0ZW0gYW5kIHN1Y2ggcHJvY2Vzc2luZywgc3Rvcmlu
ZyBhbmQgYWNjZXNz4oCdLg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9y
Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0K
PiAtLQ0KPiBMYWRpc2xhdiBMaG90a2ENCj4gSGVhZCwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJ
RDogMHhCOEY5MkIwOEE5Rjc2QzY3DQrigJxBbWRvY3PigJkgZW1haWwgcGxhdGZvcm0gaXMgYmFz
ZWQgb24gYSB0aGlyZC1wYXJ0eSwgd29ybGR3aWRlLCBjbG91ZC1iYXNlZCBzeXN0ZW0uIEFueSBl
bWFpbHMgc2VudCB0byBBbWRvY3Mgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHN0b3JlZCB1c2luZyBz
dWNoIHN5c3RlbSBhbmQgYXJlIGFjY2Vzc2libGUgYnkgdGhpcmQgcGFydHkgcHJvdmlkZXJzIG9m
IHN1Y2ggc3lzdGVtIG9uIGEgbGltaXRlZCBiYXNpcy4gWW91ciBzZW5kaW5nIG9mIGVtYWlscyB0
byBBbWRvY3MgZXZpZGVuY2VzIHlvdXIgY29uc2VudCB0byB0aGUgdXNlIG9mIHN1Y2ggc3lzdGVt
IGFuZCBzdWNoIHByb2Nlc3NpbmcsIHN0b3JpbmcgYW5kIGFjY2Vzc+KAnS4K


From nobody Wed Oct 17 11:22:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1B1130E01 for ; Wed, 17 Oct 2018 11:21:58 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 55K2ZqCnqylm for ; Wed, 17 Oct 2018 11:21:55 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 E8224130DC7 for ; Wed, 17 Oct 2018 11:21:54 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id p143-v6so9534907lfp.13 for ; Wed, 17 Oct 2018 11:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fe0A6dGjDcPw0DBHyJ15idOGT73kAukoMr+JgBZfHio=; b=HzZ0C4XThsqr0XG//qy22nfmu++5xtiDBTL22U0ZJixZ9DIy32YjJyEvHvxC2TNTqd Zc2O3bnoC2MpPli6zhDmzx+szgENgRSnFc3B9TcUlF0AcB9kJRhtELffwwLdsXQ3XhyR nwDlfar3YYTOdYIZkDqoQK3OR0e3kJK9j6xeildVLvyQ5yyMjLVNeFKOQN4j0Y/xfdZs lj85JhMyLWSnjayOYI2+Ltnq9FDZT3hPUk9mtLlFATx7RpcjLVra9aeYW1RUSfrlkPEB XLtLIXGqVZS0Z7iMYcCK8kUSBIQG1WbOwQw1+JfSYUGLxh2yAra+0gEKLEtC5QjrTodo m+sw==
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=Fe0A6dGjDcPw0DBHyJ15idOGT73kAukoMr+JgBZfHio=; b=dk456SfcnWAB9M2PWC242GHVa6MCrvWMhLuju2H39v2QiyLDgzgaitb18uoq4362/Y mWWt1Ho8GAKZazhWLHcNeybPAJxI7U3SRypEw7niv9ccV702ZkRwjsPTcoLOs4A2fXGt +02UHdP8LHaHEHCrKj0ds6RoFQzZF1VUaCHz0wk6jt7horhXVJNXUhpAh3kbOBxkDDOk ACnoVygoXJ6ZtTwjLegOC9rzDYoRo0bvL9JiFU81H1w4SShB6jSI8EG1UYAqd4tQyLco 6ScN06dLF2j6vK+72JyV0BeX3qCgBa9DhGXcI5eySVdD0nLCczoaz5iSOUYIKqPBAQ0g PcFA==
X-Gm-Message-State: ABuFfoiJ71mLjgao0EBXVqMczAIrzJ001J0qK4o/V0jfnW/admxlMmc6 6m+vrNQdNLzTsdV04omS7G0VcusIPmAgVBh1zN46JiwO
X-Google-Smtp-Source: ACcGV627UBbSk/3sxq8upKm6XVGAoso0/6T8f2NOH3YRiopTSeHkP1mKC4cclaTxJXYJvVb2JFXac7FM3KgXGohZua0=
X-Received: by 2002:a19:8d11:: with SMTP id p17-v6mr15603279lfd.116.1539800512811;  Wed, 17 Oct 2018 11:21:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 11:21:50 -0700 (PDT)
In-Reply-To: 
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <87woqhhsk4.fsf@nic.cz> 
From: Andy Bierman 
Date: Wed, 17 Oct 2018 11:21:50 -0700
Message-ID: 
To: Michael Rehder 
Cc: Ladislav Lhotka ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000976f75057870beb8"
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 18:21:59 -0000

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

On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
wrote:

> That's exactly my point - I think that the wording is unclear in the RFC,
> that "conditional" doesn't necessarily mean the mandatory status is ignor=
ed.
>
> BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has
> at least one CASE present, so there already is an "existential" check bui=
lt.
>
> I'll suggest a YANG enhancement on "yang-next" for the ability to respect
> mandatory status or not by a when statement.
>
>

The when statement works as intended. The entire subtree is on or off if
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer
to
say "this part of the model is only relevant for a subset of all possible
values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work
differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model t=
o
fit the implementation.




> Thanks
> mike
>

Andy


> > -----Original Message-----
> > From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > Sent: Wednesday, October 17, 2018 4:43 AM
> > To: Michael Rehder ; Juergen Schoenwaelder
> > 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> >
> > Michael Rehder  writes:
> >
> > > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > > list it which seems a bit odd to me).
> >
> > RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
> closely
> > related to sec. 3.1 in 6020.
> >
> > > The section on "WHEN" just mentions the xpath mapping, not anything
> > > about changing the mandatory status of the enclosing node.
> >
> > If you take into account the DSDL validation procedure (Figure 2 in RFC
> > 6110) then everything is IMO clear:
> >
> > - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
> >    and thus are required during RELAX NG schema
> >   validation, no matter what any "when" expression says.
> >
> > - Section 12.17 explains how when expressions are mapped to Schematron
> >   asserts. This means that if an instance node exists in the data and a
> >   when expression attached to the corresponding data node in YANG
> >   evaluates to false, Schematron will report a failed assert.
> >
> > - Note that Schematron cannot by definition report absence of an
> >   instance based on the when expression attached to its data
> >   node: Schematron rules are only fired for elements that are present i=
n
> >   the instance document.
> >
> > >
> > > I still think that the YANG RFC wording of "conditional" needs to
> indicate if the
> > node is mandatory status is affected or not.
> > > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > > does mention presence).
> >
> > Perhaps this thread is just about misunderstanding of what "when" reall=
y
> > means, which is: Instances for which the "when" expression evaluates to
> false
> > must not be present.
> >
> > It does NOT mean that instances for which the "when" expression
> evaluates to
> > true must be present.
> >
> > Lada
> >
> > >
> > > Thanks
> > > Mike
> > >> -----Original Message-----
> > >> From: Juergen Schoenwaelder
> > >> [mailto:j.schoenwaelder@jacobs-university.de]
> > >> Sent: Saturday, October 13, 2018 5:20 PM
> > >> To: Michael Rehder 
> > >> Cc: netmod@ietf.org
> > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn'=
t
> > >> ensure presence of the mandatory object
> > >>
> > >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
> > >>
> > >> > The mandatory statement in that case is ignored (I=E2=80=99ve poin=
ted out
> > >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> > >> > mandatory status (via explicit mandatory or implicit mandatory via
> > >> > min-elements
> > >> > 1)
> > >>
> > >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> > >> this may be a problem with RFC 6110 but not with YANG itself. There
> > >> are validators that do not use RNG or Schematron.
> > >>
> > >> /js
> > >>
> > >> --
> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germa=
ny
> > >> Fax:   +49 421 200 3103         
> > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, wo=
rldwide,
> cloud-based
> > system. Any emails sent to Amdocs will be processed and stored using su=
ch
> > system and are accessible by third party providers of such system on a
> limited
> > basis. Your sending of emails to Amdocs evidences your consent to the
> use of
> > such system and such processing, storing and access=E2=80=9D.
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldw=
ide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a
> limited basis. Your sending of emails to Amdocs evidences your consent to
> the use of such system and such processing, storing and access=E2=80=9D.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder <=
Michael.Rehd=
er@amdocs.com> wrote:
That&=
#39;s exactly my point - I think that the wording is unclear in the RFC, th=
at "conditional" doesn't necessarily mean the mandatory statu=
s is ignored.



BTW a Schematron rule is emitted to ensure a "mandatory true" CHO=
ICE has at least one CASE present, so there already is an "existential=
" check built.



I'll suggest a YANG enhancement on "yang-next" for the abilit=
y to respect mandatory status or not by a when statement.




The when statement work=
s as intended. The entire subtree is on or off if when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped int=
o 1 section, so that may make
it more complicated.

=

The whole point of "augment when" and "uses when&=
quot; is to allow the designer to
say "this part of the mode=
l is only relevant for a subset of all possible values
in another=
 part of the model".=C2=A0 In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.=C2=A0

At the abstract level I do not understand how when-=
stmt would work differently.
IMO deviation-stmt already allows en=
ough flexibility to rewrite the model to
fit the implementation.<=
/div>


=C2=A0

Thanks

mike

Andy
=C2=A0

> -----Original Message-----

> From: Ladislav Lhotka [mailto:lhotka@=
nic.cz]

> Sent: Wednesday, October 17, 2018 4:43 AM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>; Juergen Schoenwa=
elder

> <j.schoenwa=
elder@jacobs-university.de>

> Cc: netmod@ietf.org

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn=
9;t

> ensure presence of the mandatory object

> 

> Michael Rehder <Michael.Rehder@Amdocs.com> writes:

> 

> > I've read rfc6110 and I didn't see any mention of "W=
HEN" on the

> > mandatory status (section 9.1.1 Optional and Mandatory Nodes does=
n't

> > list it which seems a bit odd to me).

> 

> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is =
closely

> related to sec. 3.1 in 6020.

> 

> > The section on "WHEN" just mentions the xpath mapping, =
not anything

> > about changing the mandatory status of the enclosing node.

> 

> If you take into account the DSDL validation procedure (Figure 2 in RF=
C

> 6110) then everything is IMO clear:

> 

> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in

>=C2=A0 =C2=A0<rng:optional> and thus are required during RELAX NG=
 schema

>=C2=A0 =C2=A0validation, no matter what any "when" expression=
 says.

> 

> - Section 12.17 explains how when expressions are mapped to Schematron=


>=C2=A0 =C2=A0asserts. This means that if an instance node exists in the=
 data and a

>=C2=A0 =C2=A0when expression attached to the corresponding data node in=
 YANG

>=C2=A0 =C2=A0evaluates to false, Schematron will report a failed assert=
.

> 

> - Note that Schematron cannot by definition report absence of an

>=C2=A0 =C2=A0instance based on the when expression attached to its data=


>=C2=A0 =C2=A0node: Schematron rules are only fired for elements that ar=
e present in

>=C2=A0 =C2=A0the instance document.

> 

> >

> > I still think that the YANG RFC wording of "conditional"=
; needs to indicate if the

> node is mandatory status is affected or not.

> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't men=
tion "WHEN" (it

> > does mention presence).

> 

> Perhaps this thread is just about misunderstanding of what "when&=
quot; really

> means, which is: Instances for which the "when" expression e=
valuates to false

> must not be present.

> 

> It does NOT mean that instances for which the "when" express=
ion evaluates to

> true must be present.

> 

> Lada

> 

> >

> > Thanks

> > Mike

> >> -----Original Message-----

> >> From: Juergen Schoenwaelder

> >> [mailto:j.schoenwaelder@jacobs-university.de]

> >> Sent: Saturday, October 13, 2018 5:20 PM

> >> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects=
 doesn't

> >> ensure presence of the mandatory object

> >>

> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrot=
e:

> >>

> >> > The mandatory statement in that case is ignored (I=E2=80=
=99ve pointed out

> >> > the RNG and Schematron lack of enforcement).=C2=A0 WHEN =
trumps the

> >> > mandatory status (via explicit mandatory or implicit man=
datory via

> >> > min-elements

> >> > 1)

> >>

> >> Has the RNG and Schematron been obtained following RFC 6110? =
If so,

> >> this may be a problem with RFC 6110 but not with YANG itself.=
 There

> >> are validators that do not use RNG or Schematron.

> >>

> >> /js

> >>

> >> --

> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen gGmbH

> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp=
us Ring 1 | 28759 Bremen | Germany

> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0<https://www.jacobs-university.de/>

> > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access=E2=80=9D.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

> 

> --

> Ladislav Lhotka

> Head, CZ.NIC Labs

> PGP Key ID: 0xB8F92B08A9F76C67

=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldwid=
e, cloud-based system. Any emails sent to Amdocs will be processed and stor=
ed using such system and are accessible by third party providers of such sy=
stem on a limited basis. Your sending of emails to Amdocs evidences your co=
nsent to the use of such system and such processing, storing and access=E2=
=80=9D.

_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--000000000000976f75057870beb8--


From nobody Wed Oct 17 14:43:32 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E113F130DFF for ; Wed, 17 Oct 2018 14:43:30 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 uKlM9IHzFLjb for ; Wed, 17 Oct 2018 14:43:27 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0066.outbound.protection.outlook.com [104.47.32.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C245130E06 for ; Wed, 17 Oct 2018 14:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aZgqX9NCHlDvNs112G0LpTEwAF97FbqudmUt3XN8rPc=; b=H/89Z75iOlLESuFOXTi1suXs7RUO1tp1C0KWhlYM6EN9Osr9jWNGv95uZog8JPVfmmTLu93P3t51sc9shprA4jwlAFmv8JV+jHpt70ijxN+a33tKLjZrf3Wtc+9vnQd3gJppj1PtURTh94/KfNtiTHRZr1ahUoJybeY3Jx4oVpo=
Received: from MWHPR2201CA0078.namprd22.prod.outlook.com (2603:10b6:301:5e::31) by BN6PR2201MB1107.namprd22.prod.outlook.com (2603:10b6:405:35::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.31; Wed, 17 Oct 2018 21:43:24 +0000
Received: from DM3NAM03FT019.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by MWHPR2201CA0078.outlook.office365.com (2603:10b6:301:5e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.24 via Frontend Transport; Wed, 17 Oct 2018 21:43:23 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT019.mail.protection.outlook.com (10.152.82.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Wed, 17 Oct 2018 21:43:22 +0000
From: Alex Campbell 
To: Andy Bierman , Michael Rehder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AQHUZmJV2v7njsBPd0WncvLlgSykVw==
Date: Wed, 17 Oct 2018 21:43:20 +0000
Message-ID: <1539812601446.35899@Aviatnet.com>
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <87woqhhsk4.fsf@nic.cz> , 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_153981260144635899Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39850400004)(136003)(396003)(346002)(376002)(2980300002)(438002)(51444003)(13464003)(189003)(199004)(19627405001)(54896002)(356004)(26005)(6306002)(14444005)(236005)(36756003)(606006)(118246002)(5024004)(97876018)(72206003)(478600001)(84326002)(36736006)(316002)(246002)(16586007)(110136005)(6246003)(114624004)(476003)(5660300001)(86362001)(11346002)(8936002)(93886005)(186003)(956004)(2616005)(2906002)(6486002)(446003)(106002)(30436002)(76176011)(7696005)(8676002)(3846002)(53546011)(25786009)(6116002)(102836004)(117636001)(4744004)(486006)(7596002)(71190400001)(336012)(966005)(4546004)(7736002)(53416004)(106466001)(126002)(229853002)(7636002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1107; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT019; 1:78uvRt9EJOvq7Jz+IjEZxL/6bJK78Se4XmHGPRkVDMDFEeP7Wxsq8DgDOB+LY8rOX4Rvy7TCNHs2LdVYc/OgZQEKYzl/5VbS1nSC+/OIz32tjkCc+Lv/kO3DTUjpYKcX
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c92519c0-218f-48e4-ad2f-08d634798feb
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1107; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 3:OHz9qaMU1aKbhS6v2nEet1YlHj2QdOZyC2fNoVLEbPGbJhTqhoNYG9SwtMZSbgRz6vY8XXNGgss2wc10Xz0VuvXFIG47HcVQQ6cv8H8i98um/yloKzzMjexyWSFVep+4Ja6DHGttbBS+pUZi6GKPVUnzgY6xCWD5Ce0CNqQMcAmKoo6YeXfBKjcxiakkSAMAKK/UZqDLuyPWgpOaFq6cKrXLOXznxAo3EmWurpBTzph3oEJp7BZ/yNgsbzjGoov+Hxd/8Q289VlSeGalzj0omO2Yf/HGXGOM47684I0/SBAZINaY7aRsF9EIgzonWTSAq594Oqd+DBmli/X5+EED6X6WzKdJZwetw//3s9t78SM=; 25:dU7VITNw4yaVfVPntlbNop/Cmx3c7XdTlo589Cct2eCmqJNZdexL4Qy+XD6X5SJ09hf1FYt0FSDwBlgLdyHJvwy6MIGqPvX60YFPRw5Xz1+HG0tev13ljm/ENjK+iip9t4Fa4QxHoNhMjPk+2Km5w0UxfIhSMQQEJj3gsMADFCzt7SD+2TngNYYltQshcNbdPhtv1KU3Q7SwFoODVaO5CO+SbS9Y/tTUJXa/w+uE3ALY9puaEw9VeyKSDykxzwJbcU2SuUsIfteJ5jmp8RVxg4ngVHQcjR3XkxvHJ63XsSN2SODGNAjjK/DFiW0QXk7BygfhGXbz/6yXJh5uAt/2YA==
X-MS-TrafficTypeDiagnostic: BN6PR2201MB1107:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 31:56OVoJLcApYqAL3+VWEd/GdTzX0cvtwDCByM3Jjq2uDhX56QWaZtJRKAtGXrk5Xyy6OJQ7ptvxCceMEQChjOg3WcDIMnBpKNgeURSOaP2wxJgBE9sdySXolr+B2ECkH3VFbCSQRHYfguLQME5f5DWQgvkw44Xq3Bi7XJoNewE/Mz5dXPfqxVNxagJSF4kN0nZ3453Q4UabfHkHQUBIROo/hovmZMl+/RE5J6mXxl+cA=; 20:/ZrJYOTtBLfJ2MF5lAQgSYuxQcs0ypEO4jxiORFIQElhFOFz6COug+feJqaY+ikpXROOmK4WXXoGXq23rOWnz4GnKxQT2jvoEc8cetr3UoZen2f9PI4yOqN928kHhyAnfi1QFw+BDuQVZvcKRGgvP1uL+fZ84Jwp5j3v+DLOSEAgj67N6BA8/EiBz6QjuhJ+uu3hHT7jyi8qdmD8akWz4G+rn6jCgoFl1pG324krtN7L5qsQ1GrhgpbUKxw+3eE1sNVrM3jBLiPGBix/FHLvfc8XLZkHF+8ny1tEVSSg+vXjBosZYGfORvjxkJTR99VPQjh72EGaW/4QjVhCFDdJ64PXvt40/6pBohC2TZTRyVzNzp1Y9lUEQgjJiUwId8iOj+IXK/gvz311OFQpoDrpt+LGuur25QmsvZq+9NUlx/smbyNI1E5JV9nrlmHJvB284Ab2+krsudt8H+dEm3fuJaMlZ2caMc6Ddjldsxx/JqukUaJdM/d6n0XBjLaMj9eV
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(166566539817055)(131327999870524);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93004095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BN6PR2201MB1107; BCL:0; PCL:0; RULEID:; SRVR:BN6PR2201MB1107; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 4:a1aVvVeOa7QZooauZUA5d+gHBNTkJYKHO9irpTJE0gids1PVpZUhgZNUcKhnsVhoy/M4oBl+KVC9Ad7wrNlSppJLlE6Ptn32j8PeYcm2C+zBFURcV5VisYTf4ABUfReHABQGtdYY/G22kj/JE52x7z+0wkDme2A36KmQl8OWSsm5WTAF/G69OdjP/6G7ElEMD9m5M46On/pnh7AF9AN5eNBzV+JnFpw31V8lSV21/YEsy65IM2S8yU5Me1CBUz8Fsw3iznJLJWo681kWvQYnqQMK5kcUViRZk0VaKUSbUcKpY4RvK795VwVE74qks75gLl1KZZLX3saWQimX8rLjo4wLj9FU8KWLj8Kf+vbYWC0=
X-Forefront-PRVS: 08286A0BE2
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR2201MB1107; 23:/HZTuqFLpywtwsu4luNrhrTFs4wt+KZau9taPiL?= =?us-ascii?Q?ttUrPTMyded0w2NvpfFatk9cQgzAEBa1watLZ420pufZ9sOjGN0GQoOOVB5c?= =?us-ascii?Q?+TPKZFrzTOVfkM3BON/h+/TN5fBW4XcaPbaAcc18NPjPFT5u/Au+XX1CaBkI?= =?us-ascii?Q?CnMPPZdZEu2Bgd9N6QWdkGgD3DJbCmBVLdRtenAGZ0TOnydBZ5MruDhMbiG9?= =?us-ascii?Q?29FK4XR9K9qGTdYhmQFFM6zOvzGhLIJQUznumATaqUNyqmQzLDLlrMlDIG1P?= =?us-ascii?Q?jCEhAihp/y6UZ7abud9UhJ+jCwiVkeL0TCT87Kcqn6Nap4cXrEx3SVdnOEx2?= =?us-ascii?Q?PjSgv0Uzxh4a38wDLye0i586szGmjwg0UT684o43unze4ypVm4+XxJFIfM18?= =?us-ascii?Q?uGUdBkWD/eb9a5jJoCXo0mdVJPsmvh3hI/30nOJa7QqAwQWmd/svGl0hfGgv?= =?us-ascii?Q?0VmxShqRjTZ38pqqTbc+kngutJaDVXUKcfBVSU7V1Fe/jV9W7X7C7sbeGdAL?= =?us-ascii?Q?hm5ryZA377T6YgF3XHdCeRwOoMifasBc++Pgu8PfVBba5k4hvkyhlTK2WWyt?= =?us-ascii?Q?rE01PXA6NIUN6Qepshr8Vd5QCsfc+iPWLSGUyplCyjeuHJverqmCkgqcG7Ro?= =?us-ascii?Q?D6HhKtvom4JHvJc0fx3hBc4AfC2XLuWKoC0l/GCDHRMnmH5olni/ggmpaxl4?= =?us-ascii?Q?bqhcTWzCm2bqHieEEYzcMsAn34Tq2+o+pebrpnjoke5ymUpjtjl5ANYe840w?= =?us-ascii?Q?0IadD0L3fO5gAVqurcsedir5tbZ6TAI4aZPYEnMpeWQ00lknbGU7slPUA597?= =?us-ascii?Q?euWTsmkwe5FqplOtREeorTpXV5eQL2AilHv8UXct7JiMrgpOtEJUJEBzyuqQ?= =?us-ascii?Q?2m0rt5n2+pxM9hfgdx3wFJExEckPkG2wTzfa1FnBHx0pkIskjTgO5CqgpFbl?= =?us-ascii?Q?TGmN+AIIea3TwC2rUpD5jA8yvz5aKANuX/a4+LisMldOZTKeitEAKpMJVv32?= =?us-ascii?Q?ruVzAwJB6dRa315DWJ7GhNdU/1yEEuBOSWt4J5Cs6xgKx4WAWhsVMfI20gH7?= =?us-ascii?Q?I60J4ynn+u1SS1t2c2P4xllNsrXHWBALMLmbnlvQl6ZG0MsRLMh8u0+v4+JZ?= =?us-ascii?Q?ELPbla3aFERXUDvtVgvFnGpApe16ySOACjxYhhyPTUJN1UQb0F9WoazIw+dC?= =?us-ascii?Q?LgLnnhToBMZO5jk2r4kMY97RK80WdJypsE2yoFnzy15n+u3WXveWOvdqEIyC?= =?us-ascii?Q?UhFR7aQSCv5AfNhb/LZUFLho1olVaKu2je5fOjm+KsLXk74d05bfujnJ9jmj?= =?us-ascii?Q?KRhIB9sMFFasMO1w7qAzVxo036SHXQSNBBSbKDGAAvc2Ophw8t34NOvx10PB?= =?us-ascii?Q?ZQGggJEnjpP+S5BWglMlHf0fkyte/wovG09qVdjkvh3jOsdQ0OrLxfA0G/B2?= =?us-ascii?Q?tRxpBQzYnYUeD4O72jvPxKO4lfcFv7Y/mgb1w9SMuzirCDYfDeAU2ykxfxhX?= =?us-ascii?Q?lk8aIQeBAe2ICJRCtsbeFls5KMDVkvgvKqpY=3D?=
X-Microsoft-Antispam-Message-Info: PIX4Raa6gYVGBvvWl5eVw2qjWAex/qVdeeu9HGrHXnhDPjhRNbMezYHPQz3cUrxFQ9AzfllR/JGUDcpBWyavvC9Hv05rEgjxOetT7UHf671KZ2CMtYeZL4EjJXBqiGOyMJYB/7d7vILvoblvACa/VvYIR+aZ2OSvvAQYY5liWOAV031Ig7tkWnEXVBsomIxEtnjKuX3KYNq6SVApcbLtDyV+ZLVAiAEBOS+Ypv/FfkBwTE42im0bb3jAujGiLQKW1HznlmUqV6DzLC+wu/G6bjm/7xnU/qLWNgZTKdEIJB0ncKQqshrJZ++C6FBMYxjyszUlaOjVj7/NcXF2D33DTkJhuEhAzx2u9tKnuCrVU0Y=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR2201MB1107; 6:2n8etR/Dt/6UPpCka1o7CApHFCIVIV+eAUDSSBRLVdU6+dfwQHnV00W8tQhmj1X3OjpT5Usz9ubsgNaOvdZcf3rAdrBWVyCaY9r+BNr78iEeU9Ns2ImUfuxYD63lBnQeTPi8bJ40rRi0aBOH+SnwX+z6qTfHAB7YlSDB3OJD6TXwtEVlw7gIHUpzACd5a6x94ZBpXihT/iEqyGPjyy4M85R0/RCiONKYdVg9Svdf3s2su3ssVMpN63PiPFZSWXR0MqBuQ0I3IYiknxedBOyfdnwVAXoUAo/LFp/U3tFt0HKMT+Xt+22ekDepHw2VODYGfY1N5ILbY/4BHpcmMJwK7ReKKBY9sI/wkCDgixvz2O0D7qrxeBXsI+vrEwFsqBgJALIDPXLPF7RkTdkBqmCsNrxvWTJ6c3gRUKyhEDy54Roge2VGXQ9iD2jDfP1vIIHUZ4BXIJ4KWD1TApxts3bIbg==; 5:nO/P1GE2kmAIkSrXzODjK1fWZp1eCGW85DbJU7ZrWNv5RAWYDS1iX1QkomwvTyZXm7y/+WfkvXqLcEgdhs3lXI9d1t+oFHKNinBUfMYOjAb3vThIpvjfLyPdu5Hk9LKA1KpEIG70KUXnHx/IfahW4qA0hh6FkPnvbeYsFpxpNWQ=; 7:dVNVy0oupP8n4aBSQ4v6OL5cUbwqmAOF2KWk/o+dJxv10Ue/eA/ITqBj0PIUex5aIwy6RDjmB6YbjnsZirZVpRVnufgvl5uJRYx1hNQrA87Sp0g3krr6DCJztLO/8CZTbQb/G9+jXDM4d2r2NPlepC9FycknxLHC32sGvpultmGmYT8jaGydO2+SkWC6tlYDv1PnDm8M/QEPtscEX5Xh1k40btavaH0RyZ6Z5BXwPHw/XaeA683cUC8n182JHStn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2018 21:43:22.7121 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c92519c0-218f-48e4-ad2f-08d634798feb
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1107
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 21:43:31 -0000

--_000_153981260144635899Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> At the abstract level I do not understand how when-stmt would work differ=
ently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model=
 to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when=
" is missing from the list of statements that can be added/removed/replaced=
.
I'm wondering if this should be considered errata.


________________________________
From: netmod  on behalf of Andy Bierman 
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensur=
e presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder > wrote:
That's exactly my point - I think that the wording is unclear in the RFC, t=
hat "conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at=
 least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect m=
andatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if wh=
en-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 sec=
tion, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer =
to
say "this part of the model is only relevant for a subset of all possible v=
alues
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differen=
tly.
IMO deviation-stmt already allows enough flexibility to rewrite the model t=
o
fit the implementation.



Thanks
mike

Andy

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> >
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is clo=
sely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>    and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
>
> >
> > I still think that the YANG RFC wording of "conditional" needs to indic=
ate if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
>
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to f=
alse
> must not be present.
>
> It does NOT mean that instances for which the "when" expression evaluates=
 to
> true must be present.
>
> Lada
>
> >
> > Thanks
> > Mike
> >> -----Original Message-----
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwaelder@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
> >>
> >> > The mandatory statement in that case is ignored (I've pointed out
> >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> >> > mandatory status (via explicit mandatory or implicit mandatory via
> >> > min-elements
> >> > 1)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG itself. There
> >> are validators that do not use RNG or Schematron.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103         
> > "Amdocs' email platform is based on a third-party, worldwide, cloud-bas=
ed
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a li=
mited
> basis. Your sending of emails to Amdocs evidences your consent to the use=
 of
> such system and such processing, storing and access".
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
"Amdocs' email platform is based on a third-party, worldwide, cloud-based s=
ystem. Any emails sent to Amdocs will be processed and stored using such sy=
stem and are accessible by third party providers of such system on a limite=
d basis. Your sending of emails to Amdocs evidences your consent to the use=
 of such system and such processing, storing and access".
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


--_000_153981260144635899Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








> At the abstract level I do not understand how when-stmt would work =
differently.



> IMO deviation-stmt already allows enough flexibility to rewrite t=
he model to


> fit the implementation.







FWIW: deviation statements cannot be used to modify when statements - =
"when" is missing from the list of statements that can be added/r=
emoved/replaced.




I'm wondering if this should be considered errata.













From: netmod <netmod-b=
ounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Sent: Thursday, 18 October 2018 7:21 a.m.

To: Michael Rehder

Cc: netmod@ietf.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn'=
t ensure presence of the mandatory object

 












On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder=
 
<Michael.=
Rehder@amdocs.com> wrote:



That's exactly my point - I think that the wording is unclear in the RFC, t=
hat "conditional" doesn't necessarily mean the mandatory status i=
s ignored.



BTW a Schematron rule is emitted to ensure a "mandatory true" CHO=
ICE has at least one CASE present, so there already is an "existential=
" check built.



I'll suggest a YANG enhancement on "yang-next" for the ability to=
 respect mandatory status or not by a when statement.
















The when statement works as intended. The entire subtree is on or off =
if when-stmt is present.


There is a lot of relevant text in 7950 and it cannot be grouped into =
1 section, so that may make


it more complicated.







The whole point of "augment when" and "uses when" =
is to allow the designer to


say "this part of the model is only relevant for a subset of all =
possible values


in another part of the model".  In SNMP we called this SPARS=
E AUGMENTS


but it was just DESCRIPTION clause text, not machine-reaable. 






At the abstract level I do not understand how when-stmt would work dif=
ferently.


IMO deviation-stmt already allows enough flexibility to rewrite the mo=
del to


fit the implementation.












 



Thanks

mike









Andy


 



> -----Original Message-----

> From: Ladislav Lhotka [mailto:lhotka@=
nic.cz]

> Sent: Wednesday, October 17, 2018 4:43 AM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>; Juergen Schoenwa=
elder

> <j.schoenwa=
elder@jacobs-university.de>

> Cc: netmod@ietf.org

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't<=
br>
> ensure presence of the mandatory object

> 

> Michael Rehder <Michael.Rehder@Amdocs.com> writes:

> 

> > I've read rfc6110 and I didn't see any mention of "WHEN"=
; on the

> > mandatory status (section 9.1.1 Optional and Mandatory Nodes does=
n't

> > list it which seems a bit odd to me).

> 

> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is =
closely

> related to sec. 3.1 in 6020.

> 

> > The section on "WHEN" just mentions the xpath mapping, =
not anything

> > about changing the mandatory status of the enclosing node.

> 

> If you take into account the DSDL validation procedure (Figure 2 in RF=
C

> 6110) then everything is IMO clear:

> 

> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in

>   <rng:optional> and thus are required during RELAX NG=
 schema

>   validation, no matter what any "when" expression=
 says.

> 

> - Section 12.17 explains how when expressions are mapped to Schematron=


>   asserts. This means that if an instance node exists in the=
 data and a

>   when expression attached to the corresponding data node in=
 YANG

>   evaluates to false, Schematron will report a failed assert=
..

> 

> - Note that Schematron cannot by definition report absence of an

>   instance based on the when expression attached to its data=


>   node: Schematron rules are only fired for elements that ar=
e present in

>   the instance document.

> 

> >

> > I still think that the YANG RFC wording of "conditional"=
; needs to indicate if the

> node is mandatory status is affected or not.

> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention=
 "WHEN" (it

> > does mention presence).

> 

> Perhaps this thread is just about misunderstanding of what "when&=
quot; really

> means, which is: Instances for which the "when" expression e=
valuates to false

> must not be present.

> 

> It does NOT mean that instances for which the "when" express=
ion evaluates to

> true must be present.

> 

> Lada

> 

> >

> > Thanks

> > Mike

> >> -----Original Message-----

> >> From: Juergen Schoenwaelder

> >> [mailto:j.schoenwaelder@jacobs-university.de]

> >> Sent: Saturday, October 13, 2018 5:20 PM

> >> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects=
 doesn't

> >> ensure presence of the mandatory object

> >>

> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder =
wrote:

> >>

> >> > The mandatory statement in that case is ignored (I’=
;ve pointed out

> >> > the RNG and Schematron lack of enforcement).  WHEN =
trumps the

> >> > mandatory status (via explicit mandatory or implicit man=
datory via

> >> > min-elements

> >> > 1)

> >>

> >> Has the RNG and Schematron been obtained following RFC 6110? =
If so,

> >> this may be a problem with RFC 6110 but not with YANG itself.=
 There

> >> are validators that do not use RNG or Schematron.

> >>

> >> /js

> >>

> >> --

> >> Juergen Schoenwaelder           =
;Jacobs University Bremen gGmbH

> >> Phone: +49 421 200 3587         =
Campus Ring 1 | 28759 Bremen | Germany

> >> Fax:   +49 421 200 3103      &nb=
sp;  <https://www.jacobs-university.de/>

> > “Amdocs’ email platform is based on a third-party, wo=
rldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access”.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > 
https://www.ietf.org/mailman/listinfo/netmod

> 

> --

> Ladislav Lhotka

> Head, CZ.NIC Labs

> PGP Key ID: 0xB8F92B08A9F76C67

“Amdocs’ email platform is based on a third-party, worldwide, c=
loud-based system. Any emails sent to Amdocs will be processed and stored u=
sing such system and are accessible by third party providers of such system=
 on a limited basis. Your sending of emails
 to Amdocs evidences your consent to the use of such system and such proces=
sing, storing and access”.

_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod

















--_000_153981260144635899Aviatnetcom_--


From nobody Wed Oct 17 14:54:50 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18818130E00 for ; Wed, 17 Oct 2018 14:54:49 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 DiK0efB7XTN3 for ; Wed, 17 Oct 2018 14:54:46 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849B1130DFF for ; Wed, 17 Oct 2018 14:54:45 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id q39-v6so20993645lfi.8 for ; Wed, 17 Oct 2018 14:54:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=loHnknnmGRdsl8qkL7e1hqXM3pvAIBCFNkREd9rKvCk=; b=pI9QYHHcQnAZVnmLDgAYQTN/3PwDwRSOflCi8uB1oGXBAuoyp8zVakNU0ybmKCvY3d AwwSLy5cnV6K5OngE7whGVl5IAQWDkrEhjyTP7UxoAgrnhvtfo3/1EYEwz1WGYwYMme3 KRhl0Od2stK4ojhe6cLoBFgpGEesPL/+ilqFqB/0Bml6atrFlkpTi28GrqwajCC68iiI /m6Rx14PTMtEYMV0eaCxilLNQmXiqI9cvDcgBm8J3svgvf2UuET/vKQeFFrNjz9XyAmD cuUb66wfuNvWZ2TOsBorgRhTD62lpHYI/d0ebOYm1inbtep5DZKRrZ439TDlReQQY/bc F0Hw==
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=loHnknnmGRdsl8qkL7e1hqXM3pvAIBCFNkREd9rKvCk=; b=gx/KaMxgwFvSaPou9vJ4Z8nDAiyusso9S+ymkHEKTZ+XdFMqgsySZP6VF3IOqNKSFh NwdZuaj8Ira3iYrpSGlcZhAeNpkWjKXWfguolAL8suCENiqMKs/2H45oMub0cOLJkKFk VJT1j0CvWTDt1tnBc9jAJW7XrZ4NHlutCJwGHCzjsk9ccADLaferRkJSTnDO+TsrEnQL czdwaxZQwCCQRb9XU9cy7VdkNSA/CJZ9j3OQNm890bt0T4/IdNskcWyRePROyKT/xQ2/ UiuatxtUrZr3QMoTgwQp6YdhITs2eDjdhAij1EbMeIKpsRIuLvgAmN/DhtMiFN61Wou1 inhA==
X-Gm-Message-State: ABuFfogZw8AmS5HvcIHKU8j2XqkyjU4uzkTbu/0mqTyLUyUYCBiBygnw FP3yOZu7belth8/wDQbCvUGD+z36v1YbHggywMfAdg==
X-Google-Smtp-Source: ACcGV631cT9AU2x2A/PaA4anfK+zyv8iTxCd5BrJw/XLDh7/5R4P8X8wsgDvTpGRIgfVwVGoTH9N4dXMhJOXqzdvCxg=
X-Received: by 2002:a19:8d11:: with SMTP id p17-v6mr15956004lfd.116.1539813283541;  Wed, 17 Oct 2018 14:54:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 17 Oct 2018 14:54:42 -0700 (PDT)
In-Reply-To: <1539812601446.35899@Aviatnet.com>
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <87woqhhsk4.fsf@nic.cz>   <1539812601446.35899@Aviatnet.com>
From: Andy Bierman 
Date: Wed, 17 Oct 2018 14:54:42 -0700
Message-ID: 
To: Alex Campbell 
Cc: Michael Rehder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c94bbb057873b7ea"
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 21:54:49 -0000

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

On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell 
wrote:

> > At the abstract level I do not understand how when-stmt would work
> differently.
> > IMO deviation-stmt already allows enough flexibility to rewrite the
> model to
> > fit the implementation.
>
> FWIW: deviation statements cannot be used to modify when statements -
> "when" is missing from the list of statements that can be
> added/removed/replaced.
> I'm wondering if this should be considered errata.
>
>
>

This was intentional.
I meant that deviations can already be used to add/replace/remove
constraints within data nodes.
It is true that there is no way to say certain constraints only apply based
on external data.
As Robert said, I don't understand why we need that.


Andy

------------------------------
> *From:* netmod  on behalf of Andy Bierman <
> andy@yumaworks.com>
> *Sent:* Thursday, 18 October 2018 7:21 a.m.
> *To:* Michael Rehder
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
> On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder <
> Michael.Rehder@amdocs.com> wrote:
>
>> That's exactly my point - I think that the wording is unclear in the RFC=
,
>> that "conditional" doesn't necessarily mean the mandatory status is igno=
red.
>>
>> BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has
>> at least one CASE present, so there already is an "existential" check bu=
ilt.
>>
>> I'll suggest a YANG enhancement on "yang-next" for the ability to respec=
t
>> mandatory status or not by a when statement.
>>
>>
>
> The when statement works as intended. The entire subtree is on or off if
> when-stmt is present.
> There is a lot of relevant text in 7950 and it cannot be grouped into 1
> section, so that may make
> it more complicated.
>
> The whole point of "augment when" and "uses when" is to allow the designe=
r
> to
> say "this part of the model is only relevant for a subset of all possible
> values
> in another part of the model".  In SNMP we called this SPARSE AUGMENTS
> but it was just DESCRIPTION clause text, not machine-reaable.
>
> At the abstract level I do not understand how when-stmt would work
> differently.
> IMO deviation-stmt already allows enough flexibility to rewrite the model
> to
> fit the implementation.
>
>
>
>
>> Thanks
>> mike
>>
>
> Andy
>
>
>> > -----Original Message-----
>> > From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> > Sent: Wednesday, October 17, 2018 4:43 AM
>> > To: Michael Rehder ; Juergen Schoenwaelder
>> > 
>> > Cc: netmod@ietf.org
>> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> > ensure presence of the mandatory object
>> >
>> > Michael Rehder  writes:
>> >
>> > > I've read rfc6110 and I didn't see any mention of "WHEN" on the
>> > > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
>> > > list it which seems a bit odd to me).
>> >
>> > RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
>> closely
>> > related to sec. 3.1 in 6020.
>> >
>> > > The section on "WHEN" just mentions the xpath mapping, not anything
>> > > about changing the mandatory status of the enclosing node.
>> >
>> > If you take into account the DSDL validation procedure (Figure 2 in RF=
C
>> > 6110) then everything is IMO clear:
>> >
>> > - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>> >    and thus are required during RELAX NG schema
>> >   validation, no matter what any "when" expression says.
>> >
>> > - Section 12.17 explains how when expressions are mapped to Schematron
>> >   asserts. This means that if an instance node exists in the data and =
a
>> >   when expression attached to the corresponding data node in YANG
>> >   evaluates to false, Schematron will report a failed assert..
>> >
>> > - Note that Schematron cannot by definition report absence of an
>> >   instance based on the when expression attached to its data
>> >   node: Schematron rules are only fired for elements that are present =
in
>> >   the instance document.
>> >
>> > >
>> > > I still think that the YANG RFC wording of "conditional" needs to
>> indicate if the
>> > node is mandatory status is affected or not.
>> > > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
>> > > does mention presence).
>> >
>> > Perhaps this thread is just about misunderstanding of what "when" real=
ly
>> > means, which is: Instances for which the "when" expression evaluates t=
o
>> false
>> > must not be present.
>> >
>> > It does NOT mean that instances for which the "when" expression
>> evaluates to
>> > true must be present.
>> >
>> > Lada
>> >
>> > >
>> > > Thanks
>> > > Mike
>> > >> -----Original Message-----
>> > >> From: Juergen Schoenwaelder
>> > >> [mailto:j.schoenwaelder@jacobs-university.de]
>> > >> Sent: Saturday, October 13, 2018 5:20 PM
>> > >> To: Michael Rehder 
>> > >> Cc: netmod@ietf.org
>> > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn=
't
>> > >> ensure presence of the mandatory object
>> > >>
>> > >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
>> > >>
>> > >> > The mandatory statement in that case is ignored (I=E2=80=99ve poi=
nted out
>> > >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
>> > >> > mandatory status (via explicit mandatory or implicit mandatory vi=
a
>> > >> > min-elements
>> > >> > 1)
>> > >>
>> > >> Has the RNG and Schematron been obtained following RFC 6110? If so,
>> > >> this may be a problem with RFC 6110 but not with YANG itself. There
>> > >> are validators that do not use RNG or Schematron.
>> > >>
>> > >> /js
>> > >>
>> > >> --
>> > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>> Germany
>> 
>> > >> Fax:   +49 421 200 3103         
>> > > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, w=
orldwide,
>> cloud-based
>> > system. Any emails sent to Amdocs will be processed and stored using
>> such
>> > system and are accessible by third party providers of such system on a
>> limited
>> > basis. Your sending of emails to Amdocs evidences your consent to the
>> use of
>> > such system and such processing, storing and access=E2=80=9D.
>> > > _______________________________________________
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > --
>> > Ladislav Lhotka
>> > Head, CZ.NIC Labs
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, world=
wide, cloud-based
>> system. Any emails sent to Amdocs will be processed and stored using suc=
h
>> system and are accessible by third party providers of such system on a
>> limited basis. Your sending of emails to Amdocs evidences your consent t=
o
>> the use of such system and such processing, storing and access=E2=80=9D.
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>

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




On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell <Alex.Campbell=
@aviatnet.com> wrote:








> At the abstract level I do not understand how when-stmt would work =
differently.



> IMO deviation-stmt already allows enough flexibility to rewrite t=
he model to


> fit the implementation.







FWIW: deviation statements cannot be used to modify when statements - =
"when" is missing from the list of statements that can be added/r=
emoved/replaced.




I'm wondering if this should be considered errata.







This was i=
ntentional.
I meant that deviations can already be used to add/re=
place/remove constraints within data nodes.
It is true that there=
 is no way to say certain constraints only apply based on external data.
As Robert said, I don't understand why we need that.
=


Andy



From: =
netmod <net=
mod-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>

Sent: Thursday, 18 October 2018 7:21 a.m.

To: Michael Rehder

Cc: netmod@ietf=
.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn&=
#39;t ensure presence of the mandatory object

=C2=A0












On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder=
 
<Michael.=
Rehder@amdocs.com> wrote:



That's exactly my point - I think that the wording is unclear in the RF=
C, that "conditional" doesn't necessarily mean the mandatory =
status is ignored.



BTW a Schematron rule is emitted to ensure a "mandatory true" CHO=
ICE has at least one CASE present, so there already is an "existential=
" check built.



I'll suggest a YANG enhancement on "yang-next" for the abilit=
y to respect mandatory status or not by a when statement.
















The when statement works as intended. The entire subtree is on or off =
if when-stmt is present.


There is a lot of relevant text in 7950 and it cannot be grouped into =
1 section, so that may make


it more complicated.







The whole point of "augment when" and "uses when" =
is to allow the designer to


say "this part of the model is only relevant for a subset of all =
possible values


in another part of the model".=C2=A0 In SNMP we called this SPARS=
E AUGMENTS


but it was just DESCRIPTION clause text, not machine-reaable.=C2=A0






At the abstract level I do not understand how when-stmt would work dif=
ferently.


IMO deviation-stmt already allows enough flexibility to rewrite the mo=
del to


fit the implementation.












=C2=A0



Thanks

mike









Andy


=C2=A0



> -----Original Message-----

> From: Ladislav Lhotka [mailto:lhotka@nic.cz]

> Sent: Wednesday, October 17, 2018 4:43 AM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>; Juergen Schoenwa=
elder

> <j.schoenwaelder@jacobs-university.de>

> Cc: netmod@ietf.o=
rg

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn=
9;t

> ensure presence of the mandatory object

> 

> Michael Rehder <Michael.Rehder@Amdocs.com> writes:

> 

> > I've read rfc6110 and I didn't see any mention of "W=
HEN" on the

> > mandatory status (section 9.1.1 Optional and Mandatory Nodes does=
n't

> > list it which seems a bit odd to me).

> 

> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is =
closely

> related to sec. 3.1 in 6020.

> 

> > The section on "WHEN" just mentions the xpath mapping, =
not anything

> > about changing the mandatory status of the enclosing node.

> 

> If you take into account the DSDL validation procedure (Figure 2 in RF=
C

> 6110) then everything is IMO clear:

> 

> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in

>=C2=A0 =C2=A0<rng:optional> and thus are required during RELAX NG=
 schema

>=C2=A0 =C2=A0validation, no matter what any "when" expression=
 says.

> 

> - Section 12.17 explains how when expressions are mapped to Schematron=


>=C2=A0 =C2=A0asserts. This means that if an instance node exists in the=
 data and a

>=C2=A0 =C2=A0when expression attached to the corresponding data node in=
 YANG

>=C2=A0 =C2=A0evaluates to false, Schematron will report a failed assert=
..

> 

> - Note that Schematron cannot by definition report absence of an

>=C2=A0 =C2=A0instance based on the when expression attached to its data=


>=C2=A0 =C2=A0node: Schematron rules are only fired for elements that ar=
e present in

>=C2=A0 =C2=A0the instance document.

> 

> >

> > I still think that the YANG RFC wording of "conditional"=
; needs to indicate if the

> node is mandatory status is affected or not.

> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't men=
tion "WHEN" (it

> > does mention presence).

> 

> Perhaps this thread is just about misunderstanding of what "when&=
quot; really

> means, which is: Instances for which the "when" expression e=
valuates to false

> must not be present.

> 

> It does NOT mean that instances for which the "when" express=
ion evaluates to

> true must be present.

> 

> Lada

> 

> >

> > Thanks

> > Mike

> >> -----Original Message-----

> >> From: Juergen Schoenwaelder

> >> [mailto:j.schoenwaelder@jacobs-university.de]

> >> Sent: Saturday, October 13, 2018 5:20 PM

> >> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> >> Cc: netm=
od@ietf.org

> >> Subject: Re: [netmod] WHEN statement within mandatory objects=
 doesn't

> >> ensure presence of the mandatory object

> >>

> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrot=
e:

> >>

> >> > The mandatory statement in that case is ignored (I=E2=80=
=99ve pointed out

> >> > the RNG and Schematron lack of enforcement).=C2=A0 WHEN =
trumps the

> >> > mandatory status (via explicit mandatory or implicit man=
datory via

> >> > min-elements

> >> > 1)

> >>

> >> Has the RNG and Schematron been obtained following RFC 6110? =
If so,

> >> this may be a problem with RFC 6110 but not with YANG itself.=
 There

> >> are validators that do not use RNG or Schematron.

> >>

> >> /js

> >>

> >> --

> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen gGmbH

> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | German=
y

> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0<https://www.jacobs-university.de/>

> > =E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party=
, worldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access=E2=80=9D.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.=
org

> > 
https://www.ietf.org/mailman/listinfo/netmod

> 

> --

> Ladislav Lhotka

> Head, CZ.NIC Labs

> PGP Key ID: 0xB8F92B08A9F76C67

=E2=80=9CAmdocs=E2=80=99 email platform is based on a third-party, worldwid=
e, cloud-based system. Any emails sent to Amdocs will be processed and stor=
ed using such system and are accessible by third party providers of such sy=
stem on a limited basis. Your sending of emails
 to Amdocs evidences your consent to the use of such system and such proces=
sing, storing and access=E2=80=9D.

_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod





















--000000000000c94bbb057873b7ea--


From nobody Wed Oct 17 14:55:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5A4130E00 for ; Wed, 17 Oct 2018 14:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 dRDTsDzAIK5i for ; Wed, 17 Oct 2018 14:55:47 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0082.outbound.protection.outlook.com [104.47.36.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12847130DFF for ; Wed, 17 Oct 2018 14:55:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qzWTK5QHL80wHmOLtdRNG1jvjlP1GS2bgvgR8SJvCIo=; b=MfbTAklkzXaZFCwrNyeSQudK4XeHVMOaaJ3fWjGhTRWg+ZGlNpXQrkAO9dlTQtSeUQ5huqVk/SbWVDRXYMjkAgQ6AYV88GXEagv5OfmJkHU2TRBuGtAyjSgGctb2u6NBr0Xghf/VYGXbyQRz6YXroqFEb87HrK0A/0gCqOh1184=
Received: from MWHPR22CA0019.namprd22.prod.outlook.com (2603:10b6:300:ef::29) by MWHPR22MB0608.namprd22.prod.outlook.com (2603:10b6:300:ff::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Wed, 17 Oct 2018 21:55:45 +0000
Received: from DM3NAM03FT025.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by MWHPR22CA0019.outlook.office365.com (2603:10b6:300:ef::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20 via Frontend Transport; Wed, 17 Oct 2018 21:55:45 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; bogus.com; dkim=none (message not signed) header.d=none;bogus.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by DM3NAM03FT025.mail.protection.outlook.com (10.152.82.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Wed, 17 Oct 2018 21:55:44 +0000
From: Alex Campbell 
To: Christian Hopps 
CC: joel jaeggli , NETMOD Working Group 
Thread-Topic: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
Thread-Index: AQHUZmQm2mqZ6rTnIE6Bya/iFyD5iw==
Date: Wed, 17 Oct 2018 21:55:43 +0000
Message-ID: <1539813344223.22743@Aviatnet.com>
References:  <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com>, <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org>
In-Reply-To: <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39850400004)(136003)(2980300002)(438002)(199004)(189003)(25786009)(53416004)(36736006)(50466002)(93886005)(23756003)(6116002)(316002)(8676002)(356004)(54906003)(66574009)(3846002)(14444005)(8746002)(5660300001)(8936002)(86362001)(6486002)(36756003)(7596002)(305945005)(7636002)(118246002)(7736002)(486006)(336012)(106466001)(106002)(478600001)(229853002)(4326008)(72206003)(2906002)(2616005)(11346002)(7696005)(47776003)(956004)(186003)(476003)(126002)(26005)(246002)(6246003)(97876018)(117636001)(446003)(53546011)(102836004)(76176011)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0608; H:mail-send.aviatnet.com; FPR:;  SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT025; 1:oUXM4e97GBLMQ2IlIVjibG4ndnTk6eN+zGRQB5msgNXVbSM2i2xRRdO8fVvQmOW7PDBhXUEJEIfci4WhrLPqt6agVZ4QB8lzKVaMTczyw30PKNnWX79OQZo5GxJfq0bx
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 396649fc-7714-4a20-321a-08d6347b4a30
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0608; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0608; 3:nIEQZqwpaNwOWX1QzPMXViFh+SGmvr9ODDJ16enaQa2cBsNG3rfPbRSdbyPTnRR3nScMfIroPNyYhrAulDweZHvhN6o49bxcB4Klu7uKdsazl8wA5y8BQTHweOaAb7IBs/Hg+FRg2dG1LRk0rKGVAz0EzqZLSxt1uyG0Cws/jDJ91r5Vo+XQV+bAzbdwQMaMvhaF+9ic4jaSSlrxa9W6j/JhZmx19qQxGXA9BRYbgjf8jb9vs6Ujc8RFDKxFSwB5l07HOAbkkav82jFB0EJq/6WtzfTn03gKlM910zZPAscDsrcb552+40k7jUpqIIj7xNxvruS0Xb/TLXpMGWLkmOn3aqK4WCu2xC751kh4Gp0=; 25:wH7m2maedSQIShwo8hDq9gO9uWpExjLrT8EQE6FVpuwuu/1dmTCeSAVl5NobEuNBO8Lm4+JO/lkw+dTbLIZY/Li/BpvdSK1+pizmQJVS6R5Jf0wNMlGHRvtjexaH8ugB12fHE8scecPzJaIJto1hQasPUBlpwTdsjR4lmWN9UaPd1sWNpJB2u+3892mrSe56bdk/GklioNcfx80Jzm3Qf3+1tVEsJnqnAce1maO5/tticLCW2Oua+onGbiGmygo1pl6bZC/R3iaJTG0p6cbHyynqsMGgKtvCqRWmpe6Ow+gT3V9MvnSv3EPedI/Ml45tuwqIhC6TVL46FwpU2hZ4Ow==
X-MS-TrafficTypeDiagnostic: MWHPR22MB0608:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0608; 31:C/lqDMluMuj/E4V8+CO/M4m0UxMmhv5YJPaEGbgIFhJX4YtGWg7sy/Wjwh8ceq8vkWBVikjXHdP/I0b4yftNHJSdIyKgEsN210lR2DLtHFRas4fC/Ls5Xm/xIlZtDKxL+35iXaNVs0orE9K36ZMe8ppm3Ij7sxQkePQIVgc76vYO0yNIUxJ91EklxzhohRowg29sRIBq/HG+2cWeU7VuQd9Gmb+Deh820mzC77fE8Fk=; 20:UEZtydZknvCt1BsPiPGGATZBmJhbH98FmCf1Zyt14vLhxnEShS0LUWlsub3yl9MzbWU96n41UaSuLw5WLBfBcdh9DLkcavmAdBoQ46QzsqwBiZAjFTy8lIML16M6QUSa+5bPkMKuoOvxtI67S1sy7KW0MCDlNKGTPOlXMi0++5mu4QU6coJ/nYov8p3Ui+177ixOZzT1NVTRvq4jJ1oMbBPyYCXnmChjH5U/wBQ+cz3U8A7lASpfPQz4otEQMAePZba3u0pDcUSoBlyF05YrZXLbJHQwcXybROCnWhbD+6Zt/v/0xLXgEqfvBxPTdYNwwel7kbAuukL+j/C5vfsNq/ucOu71Z4IsD3CuKjgBzUgQshzWsQcuF74oazqzgkg0Z4yB/ieazGdgTo4Z+BKlbRR7Cki4oNmAlB0fOhmaA2Jq5vMGF/zOSHwn25zlg2eP1lHrwKvVCmgngm1EvNjkHx77jdpOpnZfVTO+gFvOualTxoagreiWvljVrRVIBizW
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(131327999870524);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93004095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MWHPR22MB0608; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0608; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0608; 4:SMDv+B4AHPlMVJ3MREM/H2ye7i1V90A8vonwW0CVWlT3T07C4LJ7EbNouzPWGzVyQwWsCpYfwLQZ5cmN0Iv0ptvXKsgMM1vbqV3lPCUqx0S5epse21n2Ql2F4IO7Dbt92p//f6UwHUtppxQ6lbsc6+LBM+B0aCuMuE+EkBn2e+KHGMeYY+9H/i3iuyYY4HNJ9I7xkimEqTFlv7d2kFk5fhCkHWqxnfytZ+0MnkCEDphZcWw7HkEXjg4b5ebkE4cKIvLK0MovlgPucJTVfbxo+1+uU7gS6wl3MDKBbFmN3tAqqlJV94pl1rryf9na0hN1m4hT588l/gmEIc41aaSBbaID4Rse6Pqt4ctqz0w3fOM=
X-Forefront-PRVS: 08286A0BE2
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; MWHPR22MB0608; 23:RsCLFG+sKI32/15Tl5mGU/piTFZYWUyn0r1y/ls?= =?iso-8859-1?Q?02VWweQwNtT5pgRbCPeTbHqDCOhQKwJm0eOF3e2aR0RlaylGupL1I6wTam?= =?iso-8859-1?Q?WjtlXEGaEvqF4U3dNZomagM64gyh10UUXjiFfbj3W3nFFgQhrjQYizajY0?= =?iso-8859-1?Q?+SMUHWvNYwwQSWkFUzQ7gif60JrNGhfMDFIQQ+fs5FgOAPmY0IaGjpt1IP?= =?iso-8859-1?Q?n5DYkZv2fEnxfmMY8mu5dASAFlrEZseZrUGuYxPGqUBloyMC4P5Ufv1bQc?= =?iso-8859-1?Q?gNtl1ANQYFeo+O9N/gY0k1jDEEqIme1u+eya1QfKbcxnZBGk4jHp49rV2l?= =?iso-8859-1?Q?3bq4ZUgOucduz5zK6BnFoqcuQlWHs9GDgSRePubvW+FRDUI6cXfon9gaZA?= =?iso-8859-1?Q?k2FL8x5WkCtjueTa4lBaAZ3hCUhWWOkV9YE5Ox7vK4sLAKYoaNIJT8p8W/?= =?iso-8859-1?Q?aQkqs90s3FaJLdx48/RsbrdyhQ7Tuc82NfqoQ9yHZsRCmjznBC5UrwKh44?= =?iso-8859-1?Q?CMLM/UzYo2ZfAFXkitRomqEZxxoY3CtWcIu3GrhIamOJJ8KNZNpqelqv6y?= =?iso-8859-1?Q?Vm/269BBSoK18tApd/rp6t6oPzhGlSmotTtJ4+Bzmeg03JRxWo62v1fzXc?= =?iso-8859-1?Q?EueaOJVqPIKs6Tgn3bIGanHVa7ACcupLBeuvVdKyQHTJBKxX6LL18LLBH7?= =?iso-8859-1?Q?4Z6bpPvFi6vw8fgzS3/uPuNK1emaZNw9s5UOtUYa5BHZSZx2AyicZ0gGxN?= =?iso-8859-1?Q?HgTmEACZ/6V47KJj3H0oY++O12jmzHGYLTS1OamXL/YLMFXbAmB9ovqOeF?= =?iso-8859-1?Q?U5TJeh5UX8vnSSJlsnAprJ9Ec7StRoZnHZxvqw8PimKLGi3467G8TqB3lO?= =?iso-8859-1?Q?z62qLy/bE57G+J45B6YLeryB/lnK3IdUdNW/Y9fG8FfGhqONHlQ01NFoDu?= =?iso-8859-1?Q?+7sDJjTupQFiEnulrjEg3GaVxcvj3Fv1Wp0ISG4IVNDWsGMN6qQXWCB+5q?= =?iso-8859-1?Q?87tWKpiU/SvVvOXWHy4uQ0l9ri/86rEMClDA5wqaUC5EdkTessBwodKRdI?= =?iso-8859-1?Q?KBW5hjsDC4DIUL3G8jR6LMVQsHRnr8oCJaz94VGHjSFndAtvhkecNRCRT6?= =?iso-8859-1?Q?xFK1uuloLsPW378B6zPI4wx24o66KkhCwxb/U0LA/ESnPUOumFpp7Y916P?= =?iso-8859-1?Q?D3HxMoGXjTwvBwC01UmuMC1YZGBe7sGH5FaFFr17ahjoWAMVEqnN+QW7aD?= =?iso-8859-1?Q?05cZpo0mC9J6JIpsTDMiGOh7rWz8VGrDOheMSM807i8xOA4Gv8F2BHVGxo?= =?iso-8859-1?Q?sLhvnRayrsZUUw0HW1HlyHp0oGsDI+l6WyWsz5VO8lLrhoGTTN56KXMUME?= =?iso-8859-1?Q?FZxtNI+0=3D?=
X-Microsoft-Antispam-Message-Info: G+68vhIjMqarPk8V5Rzl2bl7R+xyLJBsWwWwVdcXEgBp8NPqfeYt3gK+9ese1lebRyCb65wTOKQZUl4kXylU5OLL3A1HQICtvr03tFe1KmwXtbbwTh5dJunDjTm8vDR52+w+j/FgERnBjWZsUeYIQOHgcZ2KLarBzYI22/zaZKuGnAGHZY+Tpd0envnU1Bv6D8P63mKzDWJ3yogCgyZzPMtoGtIP4V11mIO/JX6Mgt7BWPMmU3/y+lfasgAmrwKIymrSqGiq+W+39dsxA5VkRoQswK9ueK0AOQRS0F6m32H2YHJ5+rkEjGdX7pRuAF9LtB/WFKWnef1rxAH29I6fgWD14C0ZLCZ0Ugpozza/KUc=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0608; 6:zUnkArNBr7wLjWaj0d0Ej3G/CfSkEsq2ex5Bzw9LB8Y2xUt9tfuMYfyb1Riy5pMHqRTfyAV3rfZZF0NS1AoS3S1VW/1P4EGrr8aro8NyLLwNigTkOi9tfYY8a6kBOi+35dmqG32X+q54i6Nt2TfySJ/QjIcVFwZi0W3jaqHKalozMMy2LsfpURQMh8GoeWeuzj5Ti0EselTKXpRaGCfoeTVCe9BQJo2Ppv48WT4blRph6wl4NLrTrbbSXfg6Ojkv6XXtOGLXcHHKQsc7gM4umgyzUqdR0Dv+J2jI98BiE76zvFrjZxzy/HutSLo2HRzP2xYspBWMzSF+DtwUEl1FrdqBvIW1L/6eeoxlMqwgYHDu3JRjaQb25cWZlU6mkMkORqX+3e+lCFHTcMkWZYVK1v/UQRxeFj3tc88jNsmPu6kfJ3TgyoDBn07NWgS7bWGOmVkuOKoaESBAuhxeQD91BQ==; 5:6URB0ww4ERd5eD3nmWUqYzFwDjcWNZrRO5OEYbV8zzXF2rP0V7YSaeN3YKynV7h0kINdExCPD1UHJ2/4CifOODi3d2GMFrHQRbZxZn/n7Vccj8pv22hzFshdkuUKPPEpKNuf73qBtuxXikoHxwVueopBFJpx9V6agCgKG10fO88=; 7:nnFYXmK4cOd9GhEktKIc0XM559jfXriJe+asMDOZyR2PHaXkT0qZ4fcBQ8/r2WS7goBNUiLv95AjcMk2Fcyjim87dx4OpTytoRrv3F2iNmpa1LptwfCNmB7fbCDeua+oYND1mtWkSSoJOCn46kXwWsYl8BOh4aiIOyQ62411OSDAe9KjfEIGtQMYGUz4I0vi7etbrG5zBkiRYsL8lB2dDviD+1lCQqlYm+Zj0S5jEsJefJ/EVeBVC7pRBMiGBMz3
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2018 21:55:44.5735 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 396649fc-7714-4a20-321a-08d6347b4a30
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0608
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2018 21:55:51 -0000

Hi,=0A=
=0A=
> The server implements the tags (at least the predefined ones), and the us=
e cases that come to my mind at least involve clients not servers.=0A=
=0A=
I assume that the server here is a network element implementing ietf-module=
-tags.=0A=
=0A=
I still don't see why network elements should implement ietf-module-tags.=
=0A=
What benefit is gained from storing the tags on the server instead of the c=
lient? It seems backwards.=0A=
=0A=
Have I misunderstood? I assumed that ietf-module-tags was meant to be imple=
mented by network elements that are NETCONF servers - but now I see the doc=
ument doesn't actually specify who is meant to implement the module. Your c=
omment about newly installed routers supports my understanding however.=0A=
=0A=
> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to mo=
dules is exactly the point of pre-defined tags, but you questioned their va=
lue at the top of your mail.=0A=
=0A=
The problem with pre-defined tags is that they are never complete. I can al=
ways find a useful tag that is not pre-defined.=0A=
=0A=
> Either way configuring a newly installed router is a given, I don't think=
 this is the place to solve the "forgot to add all the config to my new rou=
ter install" issue. :) If one is using tags in ones network then making sur=
e the newly installed router has tags configured the way you expect is no d=
ifferent from making sure that you configured IS-IS correctly.=0A=
=0A=
The reason I find this problematic is the same as above - that the router h=
as no use for the tag data.=0A=
It's as if my PC were to download its keyboard mapping table from my home r=
outer. Then I change ISPs and have to swap the router, and suddenly my keyb=
oard doesn't work correctly.=0A=
It would be much better to store the keyboard mapping table for my PC *on m=
y PC* instead of adding needless external dependencies.=0A=
=0A=
Alex=0A=
=0A=
=0A=
________________________________________=0A=
From: Christian Hopps =0A=
Sent: Wednesday, 17 October 2018 9:56 p.m.=0A=
To: Alex Campbell=0A=
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10=
/16/18=0A=
=0A=
The point is to keep this open to however the community might end up choosi=
ng to use it. The act of pre-defining tags doesn't disallow other tags bein=
g defined, in fact at this point I've sent a bunch of email defending leavi=
ng things as open as possible. They both can co-exist. :)=0A=
=0A=
Thanks,=0A=
Chris.=0A=
=0A=
> On Oct 16, 2018, at 7:32 PM, Alex Campbell  w=
rote:=0A=
>=0A=
> I have no issue with systems using tags to classify or organize modules, =
however this seems to me like something that would be specific to the syste=
m doing the classifying.=0A=
=0A=
Sure we support this. That's what user tag configuration is there for.=0A=
=0A=
> It would not be something that needs to be specified in the module itself=
 (except perhaps as freeform description text), and it certainly would not =
need to involve the NETCONF server.=0A=
> What would a server do with module classification data? (unless it is als=
o implementing some kind of module browsing interface, in which case it mig=
ht be used to supply the browser with data)=0A=
=0A=
The server implements the tags (at least the predefined ones), and the use =
cases that come to my mind at least involve clients not servers. I'm not sa=
ying there wouldn't be a server use case, but it's not as obvious to me.=0A=
=0A=
And yes implementing some kind of module browsing interface (which could gr=
oup modules by tags) is a fine example of how tags can be used.=0A=
=0A=
>=0A=
> Hashtags - all types, that I'm aware of - are inherently freeform and flu=
id, changing quickly according to the desires of users. I don't think it ma=
kes sense to "hard-code" them in published RFCs or even published vendor mo=
dules or firmware.=0A=
>=0A=
> Tomorrow, I might want to list all modules for management plane protocols=
. As a network operator, should I go and update the ietf-module-tags on all=
 of my network elements? That seems silly. This should be client-side data.=
 (And if I did, what happens when I add a new router and forget to update i=
ts tag data? Will that confuse the client?)=0A=
=0A=
I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modu=
les is exactly the point of pre-defined tags, but you questioned their valu=
e at the top of your mail.=0A=
=0A=
Either way configuring a newly installed router is a given, I don't think t=
his is the place to solve the "forgot to add all the config to my new route=
r install" issue. :) If one is using tags in ones network then making sure =
the newly installed router has tags configured the way you expect is no dif=
ferent from making sure that you configured IS-IS correctly.=0A=
=0A=
Thanks,=0A=
Chris.=0A=
=0A=
>=0A=
> Regards, Alex=0A=
>=0A=
> ________________________________________=0A=
> From: Christian Hopps =0A=
> Sent: Wednesday, 17 October 2018 1:04 a.m.=0A=
> To: Alex Campbell=0A=
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - =
10/16/18=0A=
>=0A=
>>=0A=
>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  w=
rote:=0A=
>>=0A=
>> The introduction does not explain what they are useful for=0A=
>=0A=
> The second sentence of the abstract: "The expectation is for such tags to=
 be used to help classify and organize modules." The introduction repeats t=
his in the first sentence. I'm not sure how much differently we could say "=
Tags are useful for organizing and classifying modules". Are you asking for=
 justification on the usefulness of organizing and classifying things? I th=
ink this concept is rather widely accepted.=0A=
>=0A=
>=0A=
>> , it just makes a comparison to #hashtags (which is something I would ex=
pect to see in an April 1st RFC).=0A=
>=0A=
> Using tags to help organize collections of data is literally ubiquitous: =
Movies/music/media, IP routes, and yes even social media are just a few exa=
mples.  Regarding April 1st, are you are unfairly restricting your perspect=
ive to only the ironic use of hashtags? Hashtags organically developed as a=
 useful and widely used way for people and groups to add meta-data to their=
 messages which then allowed other services to collect and present them in =
useful ways. Indeed businesses and other groups use hashtags for this purpo=
se to great success. It was hardly a joke, and for many folks it is immedia=
tely useful to understand what is being proposed.=0A=
>=0A=
> Thanks,=0A=
> Chris.=0A=
>=0A=
=0A=


From nobody Wed Oct 17 17:40:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92598130E42 for ; Wed, 17 Oct 2018 17:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 gpuuxWJmLmEk for ; Wed, 17 Oct 2018 17:40:12 -0700 (PDT)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::60e]) (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 63E3A130DF0 for ; Wed, 17 Oct 2018 17:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vqhTRlqKcfIeSsTUuMBayVXJKfrBdC+ULDwdzfdh7MU=; b=h/UnOzu8+V4fSx0ioqw3Cu5aI71kzI7GfwyQ3oM3qkUqOqfYExpGgeVumWyky3pT2Nj2gbEn1IWE5J7iINsVefkgxhceco3skQW6bKJiTCQPEIYqffB6aKUliNp4aXJ7/pKKlV5Bgqe5Y4QpUZp6BIhbFbdKsguIz1FOBuNK/zQ=
Received: from BN6PR22CA0036.namprd22.prod.outlook.com (2603:10b6:404:37::22) by MWHPR22MB0158.namprd22.prod.outlook.com (2603:10b6:300:5b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.26; Thu, 18 Oct 2018 00:40:10 +0000
Received: from DM3NAM03FT054.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by BN6PR22CA0036.outlook.office365.com (2603:10b6:404:37::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20 via Frontend Transport; Thu, 18 Oct 2018 00:40:10 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.54) smtp.mailfrom=Aviatnet.com; amdocs.com; dkim=none (message not signed) header.d=none;amdocs.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.54 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.54; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.54) by DM3NAM03FT054.mail.protection.outlook.com (10.152.83.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Thu, 18 Oct 2018 00:40:09 +0000
From: Alex Campbell 
To: Andy Bierman 
CC: Michael Rehder , "netmod@ietf.org" 
Thread-Topic: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
Thread-Index: AQHUZnseNYinCTu490GybfdVN02+zQ==
Date: Thu, 18 Oct 2018 00:40:08 +0000
Message-ID: <1539823208124.44400@Aviatnet.com>
References:    <20181010182529.rhbu56qx4ogpb3st@anna.jacobs.jacobs-university.de>     <7308ac7c-aa29-8a3d-a79a-5c70b8d3f5ef@cisco.com>  <20181013211943.mpumhw5pflgq5tf3@anna.jacobs.jacobs-university.de>  <87woqhhsk4.fsf@nic.cz>   <1539812601446.35899@Aviatnet.com>, 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_153982320812444400Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.54; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(39850400004)(346002)(376002)(136003)(2980300002)(438002)(13464003)(51444003)(199004)(189003)(118246002)(6916009)(4326008)(84326002)(316002)(16586007)(36736006)(25786009)(26005)(8676002)(97876018)(8936002)(6306002)(6246003)(236005)(6116002)(229853002)(53416004)(3846002)(54896002)(86362001)(14444005)(6486002)(5024004)(106466001)(102836004)(19627405001)(478600001)(72206003)(54906003)(4744004)(966005)(117636001)(71190400001)(956004)(30436002)(93886005)(336012)(11346002)(4546004)(356004)(186003)(476003)(5660300001)(53546011)(36756003)(7596002)(486006)(2616005)(126002)(7636002)(446003)(246002)(606006)(114624004)(7736002)(106002)(76176011)(2906002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0158; H:mail-send.aviatnet.com; FPR:;  SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT054; 1:+d3131QNBunMdBxDbBlAWrCmwMLSrj7vGI3tPFUqHHhPGh5UyF/3iOCvdOaKgdfMaMLm2FeHNkh24HF4KU2rJ49FKIAGknep0OyD+tq2tulyr28S7FhRmrq2IBcAppYm
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 0849e28e-43ef-4d72-c09b-08d63492421d
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0158; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 3:Dgp17XEygyy51l9JjqUQ4IqEfOn4fcg5ReCMGQAhkqZJ9hJWAdj812i1BaHqamuZ+H/oQFeBzuTI/TeDzxZ5u7jbEpb+i9x/QsLcLF6DVulwdkLBXR5b5CBsXrDBE5GXRMOAK02ufDtapvYrruTkNsKSB1498nUao1TG+pxsdNMaiaONfDuds849CrO5LJY4/o+aNu+bk1nfEyTF03iD9QHdf1ZkF//jFcGmsl13VXUv25K1F+7wJd2NmrCTyiTzYUoUQoorIjPS8ZNC51XkAc5g5aHEx32xFJ7ob9CYDvcM1EORW83H1i+9p9NGYF1XL0Tp/TbzqVWK6JE1AGNMHFh8pJyhmm72S7NG979OYTk=; 25:VULYfKGjN/SV/TJAUd5r/+T46/QK1FEEqmk34i6WM/941jkWe8qf8Us/FtaN9wBidyuLXZ6G7nM5zFSU6sX2JmOHCdlVauup4Tfm4C4C+DI9KpJJtZ/ii5/ryKYxdKOi7ipz3nuw69BE+Bn8/efvEZlkz24s24/P6NEyb+0cwaaGzfsS6C8cdUqku/YaUJkEm0sfXO6ZzLnUYyxXpeciuk63dyyJC9HX+fpTrlgFCRXGAnT2MyXUi+ppcIRMQd9SAayX1uS+hzsjL0pv6d5CA6lvz+mKaT13QQlu6PgfrfMGZAmyamSZUV+UTZF+jErY/tF86nIGKfjWQ2bUU3kRBQ==
X-MS-TrafficTypeDiagnostic: MWHPR22MB0158:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 31:mIt/0wCLNVq20B/aMdadyFnUqWRsyWltr7XIjUti4zp/c5B4Pdmnhn5Sa5PI0zsu42RWT+Qx9kwqr2JKN7SP/Y0UgZQAC+ck4gtuvSyWAk/QqdCq5AxDUUbEdcA9wUUnUHp7kFlWBYJVQLat1JqNwNVr1AVxwTmthVMGVeke7rDO1PxmXBObDGesRO5jutj4z2VrLI0+Qmsbn5/Q8xquOa86obPq8y4lto+eAWhDZC8=; 20:CcQ9re+0qH8rZO9oVUGxGytvTDei54WU87+CXBvpc20NtI+d9+0azDg5yrklAC/UyTsI9RzdxOWmFnH5nXaiK0FdMYLVyKE6baCXAaPelEcTFkWHnNqn1rf5n+WdxPd9dcz3FnSaWZFXvnI8oKidtClpk8D6r5wUmj7/FIE7QTVJ9obYvMBzBJtVy2a2gRTUPK9ivMvarLiimUGfq3y+AGBPs+3ck7xPaTUSnmEwuMVIQkzPzunueyvzntwjdHRSG0NhivSrK/gYafM4rdVbgC1I5WixpS0L78Y5aCh5mAsjWcSGrtjVqg4fyiTsUysXe0rQPRPikd5V/yF7/1ZHa5UXo3Z6AGFqPzgQAPSY2Qsu+y2AL6rKm3AwOsU3G7uUsywPMGyUEpNmPaKJ1IFPcpmhk9SNtv2WzmpgBgbsP7L/JU7rXJDN0UXJg2P6hqVvvyYUvGwGq5QJr6KJIheMzhhVG+yUZLF34delUKUScrJQdHCkPMlv4ZeDAtBHTLDc
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(788757137089)(166566539817055)(131327999870524)(106180626270275)(211936372134217);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93004095)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MWHPR22MB0158; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0158; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 4:u3bCbmI693H9Tbd2J2sLTkOGs5igHykbyVBMHlEGQurWMD1z3MSNG+atDZX3Bprrn6UMUtALAmYwZEFQ4YhEjmNF/bfNZ8oscexYWWSm89MLN2Q8fDoldg84vLX6bBKGC44sUiTW/i6gyb6Yc3eURV6peU8e9EuKhCFafosuYTH390KvefOU1DRyu/1pNCyluO7y+nL7JIjZ/pcLTU1cQiO1JcU/djeIM6XiP/g7xFQB8zlcXJHFzC1jicpuVUqiIf8pbv46lGhPtD8onxViUOguV+526kizjtjkl32acZhSeA6BHC1C8kCtPPx41Ny6qY7hPVqh1TxsIj8+U7mYUpF9jJLeFLmY2PShEiCjNY6mbOYxD78907VPk3Of9rISXZcLaGiqN3NIC2SX4xgaqAaa1si0Zcdn/IWAjl3puJbRQG6AmhJXizTIgcmkOL95
X-Forefront-PRVS: 08296C9B35
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR22MB0158; 23:So+rPN4/W2gVMMrnpOftxxYW9s6cG2pYNcv2l2/Wo?= =?us-ascii?Q?f2TFqVweSXX4HxyhmZkGhO3moZRsfXf8Aw9lrcYZ5UlCvinbY3L/a+CH4AYd?= =?us-ascii?Q?t6HKkrRBTSqwL6Ahr/5lylcSKbX3ZEfg46DQ5V3B4VmsoBd2GsfSNOiKmyHB?= =?us-ascii?Q?RYFWMJf7fGxifrtyEY40fJjwVMJE6n+DqVU9uWTM87FY8/7MsQpVcT4i3ANv?= =?us-ascii?Q?G/9HRdaLXY67H+/Vu4KMoAu5jPZBUeJ7cU1SoiQRZOq78kJmLW/sFFu/DBWl?= =?us-ascii?Q?LhkGRAr+GNM2LrqIXgJmCxBdFd876q2tGN+gHYDqiF4/fJymAmoVAgAKFUTQ?= =?us-ascii?Q?LiS1UAsYzpKexmh4F8HzNiE/llQqeI+kdIVC7AIXhI/LXJ0gFd7vaVB2aKvh?= =?us-ascii?Q?EMx1yaeGCLhgTW3AeAIMzwsp5jkt9QWRj/6AjACSBir6pPD0Zb53XG2fLUnW?= =?us-ascii?Q?Ik0DLnZaLV2rzBCcgi3gzdRsRcVqTX+mCIu0g8rl8UhSwA7+wIzbOerYwxnC?= =?us-ascii?Q?9o4U2hgTqVJ+HrRxQvTcr7/AWVYSTbBnJUeFiWa75eQtSfVdAA/RjttMMqat?= =?us-ascii?Q?tNa7PAZSB7/ZdgTouDC0Y1fkhd58xb0Q6XhAM9Ll6EzR0SVNRIzEQerJXE/7?= =?us-ascii?Q?glxpWeSUMILTPwf4NHysLEVNRUfc6FYujVMf80ey5eD/3cINLtr6bfDjIoh/?= =?us-ascii?Q?aZibcO4/Z8a/d7S1UYROtooDylT/+CbjfqUN4Q99yh7py65wOtN0C1TPgAkF?= =?us-ascii?Q?B4Qy4gdiO1MEk0dpVpN2rWc4eUOx5HrrPSUOja97ZpIblDCTFNQ/rG2AZoLQ?= =?us-ascii?Q?dR6d3pqEzcCVzCS45ddZnwD4sYTVAkwKUhCq23vZpNL68WYn/jUIhkbTOur7?= =?us-ascii?Q?fdUGIQ9gml/AkwPPhc3ATQOyCcaSR48J8ye8+FLm0biQs7oBVqhpy4TZ3l8s?= =?us-ascii?Q?+j2vdmLvFd9XyzsTT1EnnccuWBeYkXnI0//CGGO3g4szL6x6JdDjBBm/zFPZ?= =?us-ascii?Q?iQvse/DKF0H2pXMuzWx4PPD2zmQDxQngzz9ndb8g//vcxOYc87B3z6nXpOs7?= =?us-ascii?Q?a+KxRAwZdrfU+GEa0cySKD+Y+j+kk9rinHajvqSgZw+IeaVsdDGMWY+SwjPY?= =?us-ascii?Q?psPPRaDqeu3MFQNVodW8odrK4LNOpepJ/mmT8RYhUN5FQ0TFbmuN0hvsSrfJ?= =?us-ascii?Q?MjpPFskMTDoJE6nXwk9shgGP4Bf8GoG0cz4VX/s5DGRsDIzqxo7Utaezi1/p?= =?us-ascii?Q?T3NWvHrVpEjCgsuR/rseDVOgHWtbd7ykdlYO/A9rQHhJ3RW8WtxO4JUgEOX+?= =?us-ascii?Q?8ZM7yTYyluG0R6K9YW73WjYgj4GGa6vt/hAYuHeQKjHz3UFI+PlZs3+9Iy2I?= =?us-ascii?Q?8lryiqHNevpJ1n/tri6mypUkfKipaqjwL6g6h3Te+nWFOZA0c8k1GJzKU/Rw?= =?us-ascii?Q?czhaVvbXwKIq0/rn5KQWs2wI1HZzxNjgKkKxVI0MT+GfD8djGA/gCIlmzL/8?= =?us-ascii?Q?OhtIDU690W2g3N8fnC07Tl7wNUI6s3DQaU=3D?=
X-Microsoft-Antispam-Message-Info: Li9M7IzO29d6grLNUJxfSIIZjZfbkjkHUtW5TleqZqB2QsLvyUnYqz49X6DavSkEns2t5VnSzUWT9HkARtSrSLErhAjqcaCCLKPFKC1y74VgTjmtLoA6ewIXeKp5WHCzmhaTZETN+yO7eNpjwmm1/9Vh+JWZlSemdGa4nfhsQih68JWKuRwrUkJ5wfAb2qTxkkk02t/1Hm0xjQZJDyIReLLSys9McArm4TsT/zGm1yS4btCOFiHNwfZdW3N6JYVMbGG9VyXunukya9DoMTsjfXt9eWSub0L95dzkwhcA1UH6UXjTBRjuinA7hvS7EoJTI5etj25+aCRgX1jafaoRgse4F0s24HCV9r9NxQDLjbA=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR22MB0158; 6:izIZuqdwnYmuQh0Jx7F+HqZjb4Gbi1OZY8ui1q8+ptL8ew9tYpOW1dZuEbPk7Wo7wQUAYfhheXb1vG+EGKX7Z6TqcETrOnDuAs9yRN3vGGLrU4DreTpv2BblNgZLREIYaEz/P/8SlTxaQgSS7OvH2wMEOqGdon/BBb/1S3FpS3d9DU95pSzEeqKXfZeLemo3IJzbLhcba9gYlJeoy0YrPlvn896fEo9KUEu6SR/9imr3Vq2bPOxdMLr/UuJTIb6ZS/rO3X9OOZolLGowgDqi2DopND1uUZLFWlt0EUEovDcHBd7lIPye7tJB3YQ/EycGHBIZ/wPhGY7sjJp1X9HBqjNO2dXZ2LrB6pTwYgZHMJ2lkNvpC0vg0MYcHCiMBJlbplJ2rbPwe4hry0wq7JKkYXjajFIgzTVKPVcFC91tnuHdt+/JQMLdHIwzh3Tzqd//v6fHShSGOh6jYuiOjwyshQ==; 5:X68WJaToeCWnwQj3ZJDm9Mtr+WlsCbxX3C5YwLQmqkPHBvKQxLauGRzQTpfR/4sar6kdQty+Ti6Zy1Aa2crklPJlKXJVMvILFPKFWKH9XfB/YLYW89OojEF/3uuG8tiTYD/K66aBxYDLqTam46uBIfBzSp8R+pukvt6sJSu8yEA=; 7:eYgnudwL20tQHADxB5rD+OUibKayGqSUjvQ2h+rBHJX2t5cdNq1GvNA6woD2agc+ELYzEmrBRjfaNn+Z7LkowlJJyroVFlcr6TVp5Tnm0YT2afFGOV8lrJqEM+aCHT0iE5MXvzZEdYiKKEGP9w5XeR/PBGOY/SCtyCm8zsgWqyNcw7Si3MvcR2OUJ4Iiq+KYc5fn65DEI+14yXmBB21KJCidzDuoaDOqYUSX2aosEtTf7EF91pFbuAoUSA0iSSr1
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2018 00:40:09.5963 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 0849e28e-43ef-4d72-c09b-08d63492421d
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.54];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0158
Archived-At: 
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 00:40:16 -0000

--_000_153982320812444400Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It means if the model has a node such as:


    leaf some-feature {

        when "../type =3D 'ipv4' or ../type =3D 'ipv6'";

        type int32;

    }


and a certain device doesn't supports this on IPv6, it is not possible for =
a deviation to change the condition to "../type =3D 'ipv4'"


Is that intentional? It seems more like an omission to me.


________________________________
From: Andy Bierman 
Sent: Thursday, 18 October 2018 10:54 a.m.
To: Alex Campbell
Cc: Michael Rehder; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensur=
e presence of the mandatory object



On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell > wrote:

> At the abstract level I do not understand how when-stmt would work differ=
ently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model=
 to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when=
" is missing from the list of statements that can be added/removed/replaced=
.
I'm wondering if this should be considered errata.



This was intentional.
I meant that deviations can already be used to add/replace/remove constrain=
ts within data nodes.
It is true that there is no way to say certain constraints only apply based=
 on external data.
As Robert said, I don't understand why we need that.


Andy

________________________________
From: netmod > on b=
ehalf of Andy Bierman >
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensur=
e presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder > wrote:
That's exactly my point - I think that the wording is unclear in the RFC, t=
hat "conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at=
 least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect m=
andatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if wh=
en-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 sec=
tion, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer =
to
say "this part of the model is only relevant for a subset of all possible v=
alues
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differen=
tly.
IMO deviation-stmt already allows enough flexibility to rewrite the model t=
o
fit the implementation.



Thanks
mike

Andy

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> >
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is clo=
sely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>    and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
>
> >
> > I still think that the YANG RFC wording of "conditional" needs to indic=
ate if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
>
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to f=
alse
> must not be present.
>
> It does NOT mean that instances for which the "when" expression evaluates=
 to
> true must be present.
>
> Lada
>
> >
> > Thanks
> > Mike
> >> -----Original Message-----
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwaelder@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder wrote:
> >>
> >> > The mandatory statement in that case is ignored (I've pointed out
> >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> >> > mandatory status (via explicit mandatory or implicit mandatory via
> >> > min-elements
> >> > 1)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG itself. There
> >> are validators that do not use RNG or Schematron.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany=

> >> Fax:   +49 421 200 3103         
> > "Amdocs' email platform is based on a third-party, worldwide, cloud-bas=
ed
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a li=
mited
> basis. Your sending of emails to Amdocs evidences your consent to the use=
 of
> such system and such processing, storing and access".
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
"Amdocs' email platform is based on a third-party, worldwide, cloud-based s=
ystem. Any emails sent to Amdocs will be processed and stored using such sy=
stem and are accessible by third party providers of such system on a limite=
d basis. Your sending of emails to Amdocs evidences your consent to the use=
 of such system and such processing, storing and access".
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--_000_153982320812444400Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








It means if the model has a node such as:







    leaf some-feature {


        when "../type =3D 'ipv4' or ../type =3D=
 'ipv6'";


        type int32;




    }







and a certain device doesn't supports this on IPv6, it is not possible f=
or a deviation to change the condition to "../type =3D 'ipv4'"








Is that intentional? It seems more like an omission to me.













From: Andy Bierman <an=
dy@yumaworks.com>

Sent: Thursday, 18 October 2018 10:54 a.m.

To: Alex Campbell

Cc: Michael Rehder; netmod@ietf.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn'=
t ensure presence of the mandatory object

 












On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell <=
span dir=3D"ltr">
<Alex.Ca=
mpbell@aviatnet.com> wrote:






> At the abstract level I do not understand how when-stmt would work =
differently.



> IMO deviation-stmt already allows enough flexibility to rewrite t=
he model to


> fit the implementation.







FWIW: deviation statements cannot be used to modify when statements - =
"when" is missing from the list of statements that can be added/r=
emoved/replaced.




I'm wondering if this should be considered errata.























This was intentional.


I meant that deviations can already be used to add/replace/remove cons=
traints within data nodes.


It is true that there is no way to say certain constraints only apply =
based on external data.


As Robert said, I don't understand why we need that.












Andy















From: =
netmod <net=
mod-bounces@ietf.org> on behalf of Andy Bierman
 <andy@yumaworks=
.com>

Sent: Thursday, 18 October 2018 7:21 a.m.

To: Michael Rehder

Cc: netmod@ietf=
.org

Subject: Re: [netmod] WHEN statement within mandatory objects doesn'=
t ensure presence of the mandatory object

 












On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder=
 
<Michael.=
Rehder@amdocs.com> wrote:



That's exactly my point - I think that the wording is unclear in the RFC, t=
hat "conditional" doesn't necessarily mean the mandatory status i=
s ignored.



BTW a Schematron rule is emitted to ensure a "mandatory true" CHO=
ICE has at least one CASE present, so there already is an "existential=
" check built.



I'll suggest a YANG enhancement on "yang-next" for the ability to=
 respect mandatory status or not by a when statement.
















The when statement works as intended. The entire subtree is on or off =
if when-stmt is present.


There is a lot of relevant text in 7950 and it cannot be grouped into =
1 section, so that may make


it more complicated.







The whole point of "augment when" and "uses when" =
is to allow the designer to


say "this part of the model is only relevant for a subset of all =
possible values


in another part of the model".  In SNMP we called this SPARS=
E AUGMENTS


but it was just DESCRIPTION clause text, not machine-reaable. 






At the abstract level I do not understand how when-stmt would work dif=
ferently.


IMO deviation-stmt already allows enough flexibility to rewrite the mo=
del to


fit the implementation.












 



Thanks

mike









Andy


 



> -----Original Message-----

> From: Ladislav Lhotka [mailto:lhotka@nic.cz]

> Sent: Wednesday, October 17, 2018 4:43 AM

> To: Michael Rehder <Michael.Rehder@Amdocs.com>; Juergen Schoenwa=
elder

> <j.schoenwaelder@jacobs-university.de>

> Cc: netmod@ietf.o=
rg

> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't<=
br>
> ensure presence of the mandatory object

> 

> Michael Rehder <Michael.Rehder@Amdocs.com> writes:

> 

> > I've read rfc6110 and I didn't see any mention of "WHEN"=
; on the

> > mandatory status (section 9.1.1 Optional and Mandatory Nodes does=
n't

> > list it which seems a bit odd to me).

> 

> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is =
closely

> related to sec. 3.1 in 6020.

> 

> > The section on "WHEN" just mentions the xpath mapping, =
not anything

> > about changing the mandatory status of the enclosing node.

> 

> If you take into account the DSDL validation procedure (Figure 2 in RF=
C

> 6110) then everything is IMO clear:

> 

> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in

>   <rng:optional> and thus are required during RELAX NG=
 schema

>   validation, no matter what any "when" expression=
 says.

> 

> - Section 12.17 explains how when expressions are mapped to Schematron=


>   asserts. This means that if an instance node exists in the=
 data and a

>   when expression attached to the corresponding data node in=
 YANG

>   evaluates to false, Schematron will report a failed assert=
..

> 

> - Note that Schematron cannot by definition report absence of an

>   instance based on the when expression attached to its data=


>   node: Schematron rules are only fired for elements that ar=
e present in

>   the instance document.

> 

> >

> > I still think that the YANG RFC wording of "conditional"=
; needs to indicate if the

> node is mandatory status is affected or not.

> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention=
 "WHEN" (it

> > does mention presence).

> 

> Perhaps this thread is just about misunderstanding of what "when&=
quot; really

> means, which is: Instances for which the "when" expression e=
valuates to false

> must not be present.

> 

> It does NOT mean that instances for which the "when" express=
ion evaluates to

> true must be present.

> 

> Lada

> 

> >

> > Thanks

> > Mike

> >> -----Original Message-----

> >> From: Juergen Schoenwaelder

> >> [mailto:j.schoenwaelder@jacobs-university.de]

> >> Sent: Saturday, October 13, 2018 5:20 PM

> >> To: Michael Rehder <Michael.Rehder@Amdocs.com>

> >> Cc: netm=
od@ietf.org

> >> Subject: Re: [netmod] WHEN statement within mandatory objects=
 doesn't

> >> ensure presence of the mandatory object

> >>

> >> On Fri, Oct 12, 2018 at 04:08:48PM +0000, Michael Rehder =
wrote:

> >>

> >> > The mandatory statement in that case is ignored (I’=
;ve pointed out

> >> > the RNG and Schematron lack of enforcement).  WHEN =
trumps the

> >> > mandatory status (via explicit mandatory or implicit man=
datory via

> >> > min-elements

> >> > 1)

> >>

> >> Has the RNG and Schematron been obtained following RFC 6110? =
If so,

> >> this may be a problem with RFC 6110 but not with YANG itself.=
 There

> >> are validators that do not use RNG or Schematron.

> >>

> >> /js

> >>

> >> --

> >> Juergen Schoenwaelder           =
;Jacobs University Bremen gGmbH

> >> Phone: +49 421 200 3587         =
Campu=
s Ring 1 | 28759 Bremen | Germany

> >> Fax:   +49 421 200 3103      &nb=
sp;  <https://www.jacobs-university.de/>

> > “Amdocs’ email platform is based on a third-party, wo=
rldwide, cloud-based

> system. Any emails sent to Amdocs will be processed and stored using s=
uch

> system and are accessible by third party providers of such system on a=
 limited

> basis. Your sending of emails to Amdocs evidences your consent to the =
use of

> such system and such processing, storing and access”.

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.=
org

> > 
https://www.ietf.org/mailman/listinfo/netmod

> 

> --

> Ladislav Lhotka

> Head, CZ.NIC Labs

> PGP Key ID: 0xB8F92B08A9F76C67

“Amdocs’ email platform is based on a third-party, worldwide, c=
loud-based system. Any emails sent to Amdocs will be processed and stored u=
sing such system and are accessible by third party providers of such system=
 on a limited basis. Your sending of emails
 to Amdocs evidences your consent to the use of such system and such proces=
sing, storing and access”.

_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

































--_000_153982320812444400Aviatnetcom_--


From nobody Wed Oct 17 21:55:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C01277CC; Wed, 17 Oct 2018 21:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sgdjPqewOKKb; Wed, 17 Oct 2018 21:55:11 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E6D127332; Wed, 17 Oct 2018 21:55:11 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 561F5B80E97; Wed, 17 Oct 2018 21:54:45 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netmod@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20181018045445.561F5B80E97@rfc-editor.org>
Date: Wed, 17 Oct 2018 21:54:45 -0700 (PDT)
Archived-At: 
Subject: [netmod] =?utf-8?q?BCP_216=2C_RFC_8407_on_Guidelines_for_Authors?= =?utf-8?q?_and_Reviewers_of_Documents_Containing_YANG_Data_Models?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 04:55:13 -0000

A new Request for Comments is now available in online RFC libraries.

        BCP 216        
        RFC 8407

        Title:      Guidelines for Authors and Reviewers 
                    of Documents Containing YANG Data Models 
        Author:     A. Bierman
        Status:     Best Current Practice
        Stream:     IETF
        Date:       October 2018
        Mailbox:    andy@yumaworks.com
        Pages:      63
        Characters: 123260
        Obsoletes:  RFC 6087
        See Also:   BCP 216

        I-D Tag:    draft-ietf-netmod-rfc6087bis-20.txt

        URL:        https://www.rfc-editor.org/info/rfc8407

        DOI:        10.17487/RFC8407

This memo provides guidelines for authors and reviewers of
specifications containing YANG modules.  Recommendations and
procedures are defined, which are intended to increase
interoperability and usability of Network Configuration Protocol
(NETCONF) and RESTCONF protocol implementations that utilize YANG
modules.  This document obsoletes RFC 6087.

This document is a product of the Network Modeling Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


From nobody Thu Oct 18 03:16:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0212F1A5 for ; Thu, 18 Oct 2018 03:16:55 -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] 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 l-V8L3tSMWml for ; Thu, 18 Oct 2018 03:16:54 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D409612D4ED for ; Thu, 18 Oct 2018 03:16:53 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1DEC960079; Thu, 18 Oct 2018 10:16:53 +0000 (UTC)
References:  <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com> <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org> <1539813344223.22743@Aviatnet.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Alex Campbell 
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group 
In-reply-to: <1539813344223.22743@Aviatnet.com>
Date: Thu, 18 Oct 2018 06:16:52 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 10:16:56 -0000

A router has no use for it's capability/feature/deviation advertisements either; module-tags are no different in this respect.

Thanks,
Chris.

Alex Campbell  writes:

> Hi,
>
>> The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers.
>
> I assume that the server here is a network element implementing ietf-module-tags.
>
> I still don't see why network elements should implement ietf-module-tags.
> What benefit is gained from storing the tags on the server instead of the client? It seems backwards.
>
> Have I misunderstood? I assumed that ietf-module-tags was meant to be implemented by network elements that are NETCONF servers - but now I see the document doesn't actually specify who is meant to implement the module. Your comment about newly installed routers supports my understanding however.
>
>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.
>
> The problem with pre-defined tags is that they are never complete. I can always find a useful tag that is not pre-defined.
>
>> Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in ones network then making sure the newly installed router has tags configured the way you expect is no different from making sure that you configured IS-IS correctly.
>
> The reason I find this problematic is the same as above - that the router has no use for the tag data.
> It's as if my PC were to download its keyboard mapping table from my home router. Then I change ISPs and have to swap the router, and suddenly my keyboard doesn't work correctly.
> It would be much better to store the keyboard mapping table for my PC *on my PC* instead of adding needless external dependencies.
>
> Alex
>
>
> ________________________________________
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 9:56 p.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>
> The point is to keep this open to however the community might end up choosing to use it. The act of pre-defining tags doesn't disallow other tags being defined, in fact at this point I've sent a bunch of email defending leaving things as open as possible. They both can co-exist. :)
>
> Thanks,
> Chris.
>
>> On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:
>>
>> I have no issue with systems using tags to classify or organize modules, however this seems to me like something that would be specific to the system doing the classifying.
>
> Sure we support this. That's what user tag configuration is there for.
>
>> It would not be something that needs to be specified in the module itself (except perhaps as freeform description text), and it certainly would not need to involve the NETCONF server.
>> What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data)
>
> The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers. I'm not saying there wouldn't be a server use case, but it's not as obvious to me.
>
> And yes implementing some kind of module browsing interface (which could group modules by tags) is a fine example of how tags can be used.
>
>>
>> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, changing quickly according to the desires of users. I don't think it makes sense to "hard-code" them in published RFCs or even published vendor modules or firmware.
>>
>> Tomorrow, I might want to list all modules for management plane protocols. As a network operator, should I go and update the ietf-module-tags on all of my network elements? That seems silly. This should be client-side data. (And if I did, what happens when I add a new router and forget to update its tag data? Will that confuse the client?)
>
> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.
>
> Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in ones network then making sure the newly installed router has tags configured the way you expect is no different from making sure that you configured IS-IS correctly.
>
> Thanks,
> Chris.
>
>>
>> Regards, Alex
>>
>> ________________________________________
>> From: Christian Hopps 
>> Sent: Wednesday, 17 October 2018 1:04 a.m.
>> To: Alex Campbell
>> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
>> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>>
>>>
>>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wrote:
>>>
>>> The introduction does not explain what they are useful for
>>
>> The second sentence of the abstract: "The expectation is for such tags to be used to help classify and organize modules." The introduction repeats this in the first sentence. I'm not sure how much differently we could say "Tags are useful for organizing and classifying modules". Are you asking for justification on the usefulness of organizing and classifying things? I think this concept is rather widely accepted.
>>
>>
>>> , it just makes a comparison to #hashtags (which is something I would expect to see in an April 1st RFC).
>>
>> Using tags to help organize collections of data is literally ubiquitous: Movies/music/media, IP routes, and yes even social media are just a few examples.  Regarding April 1st, are you are unfairly restricting your perspective to only the ironic use of hashtags? Hashtags organically developed as a useful and widely used way for people and groups to add meta-data to their messages which then allowed other services to collect and present them in useful ways. Indeed businesses and other groups use hashtags for this purpose to great success. It was hardly a joke, and for many folks it is immediately useful to understand what is being proposed.
>>
>> Thanks,
>> Chris.
>>


From nobody Thu Oct 18 03:30:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4F12D7F8 for ; Thu, 18 Oct 2018 03:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPWLS2y2chh9 for ; Thu, 18 Oct 2018 03:30:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF4130E4D for ; Thu, 18 Oct 2018 03:30:38 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 208821AE033A for ; Thu, 18 Oct 2018 12:30:37 +0200 (CEST)
Date: Thu, 18 Oct 2018 12:30:36 +0200 (CEST)
Message-Id: <20181018.123036.731934458688841323.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181012.103727.731509761734796510.mbj@tail-f.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 10:30:44 -0000

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--------------

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

    o  If the node is encoded in XML, the set of namespace
       declarations are those in scope on the
       'stream-xpath-filter' leaf element.

    o  If the node is encoded in JSON, the set of namespace
       declarations is the set of prefix and namespace pairs
       for all supported YANG modules, where the prefix is
       the YANG module name and the namespace is as defined
       by the "namespace" statement in the YANG module.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  
    /if:interfaces/if:interface/ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--------------

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

    o  The set of namespace
       declarations is the set of prefix and namespace pairs
       for all supported YANG modules, where the prefix is
       the YANG module name and the namespace is as defined
       by the "namespace" statement in the YANG module.

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
     expressions, such as get-config filter and nacm rules.

Example in XML:

  
    /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin


From nobody Thu Oct 18 03:55:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C9112D4E9 for ; Thu, 18 Oct 2018 03:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 Jb6J7TetFV7A for ; Thu, 18 Oct 2018 03:55:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 5563112D4F1 for ; Thu, 18 Oct 2018 03:55:38 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 99169621B1 for ; Thu, 18 Oct 2018 12:55:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1539860136; bh=Q/p711IAL4Y55qFCuiFvUHFnlSYfgDnE59FeAMfRhCs=; h=From:To:Date; b=OOaKw7yrbPloxbNTE2QO/py/i9MPbBW0xYXGqDMD2seg7JroXDX9fEyPAuz5jIW0k E6GZ+TZPSe2GZ54WXusxofIoRjEaUEhDMekJY4mFO86LAZIavXSqmTDl2tjILXc74c 5fKZgDd8kDdQqIxtDW1Gag+qyVrGwiBm3ClAMcoM=
Message-ID: <0939cd18e7c9a8e91497a1d6e91279b9a2e1a35f.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Thu, 18 Oct 2018 12:55:36 +0200
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 10:55:41 -0000

On Thu, 2018-10-18 at 12:30 +0200, Martin Bjorklund wrote:
> Hi,
> 
> Going back to the most urgent issue, what is this WG's recommendation
> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> yang:xpath1.0 in filters?
> 
> To summarize:
> 
> We already have
> 
>   o  instance-identifier in XML uses prefixes from the XML document
>   o  instance-identifier in JSON uses module names as prefixes
>   o  XPath in NETCONF filter uses prefixes from the XML document
>   o  XPath in JSON query filter uses module names as prefixes

Actually, schema mount uses yet another approach - prefix/namespace mapping is a
part of the data itself:

        +--ro namespace* [prefix]
        |  +--ro prefix    yang:yang-identifier
        |  +--ro uri?      inet:uri

It could work here, too.

Lada

> 
> 
> Alternative A:
> --------------
> 
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
> 
> We would do in SN:
> 
>     o  If the node is encoded in XML, the set of namespace
>        declarations are those in scope on the
>        'stream-xpath-filter' leaf element.
> 
>     o  If the node is encoded in JSON, the set of namespace
>        declarations is the set of prefix and namespace pairs
>        for all supported YANG modules, where the prefix is
>        the YANG module name and the namespace is as defined
>        by the "namespace" statement in the YANG module.
> 
> Pro: the format is consistent within each encoding.
> 
> Con: unclear how to handle other encodings.
> Con: we keep using context-depending encodings.
> 
> We could probably add that CBOR uses the same representation as JSON.
> 
> Example in XML:
> 
>          xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>     /if:interfaces/if:interface/ip:ipv4
>   
> 
> Example in JSON:
> 
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> 
> 
> 
> Alternative B:
> --------------
> 
> Use a non-context depending encoding, with the module name as prefix.
> 
> We would do in SN:
> 
>     o  The set of namespace
>        declarations is the set of prefix and namespace pairs
>        for all supported YANG modules, where the prefix is
>        the YANG module name and the namespace is as defined
>        by the "namespace" statement in the YANG module.
> 
> Pro: the format is independent from the protocol encoding
> 
> Con: in XML, this leaf is treated differently from other XPath
>      expressions, such as get-config filter and nacm rules.
> 
> Example in XML:
> 
>   
>     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   
> 
> Example in JSON:
> 
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> 
> 
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.
> 
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
> 
> 
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Oct 18 04:10:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D212D4E9 for ; Thu, 18 Oct 2018 04:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 DI71mYGshxjf for ; Thu, 18 Oct 2018 04:10:45 -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 3A70212DD85 for ; Thu, 18 Oct 2018 04:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3331; q=dns/txt; s=iport; t=1539861045; x=1541070645; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ioVGWRR4nEISt6r8lfzQ/76rH8kCH97oSwqJelXTX9Q=; b=V5R2bx8qLPdoGJFPSn/v9gGH0dN0imG6HHtRZOqinNzaqtP6BGatCmnH FwQHc4AB61N0cBwrVD7AE+7tp+H06MNSEkEjW/5QTZ3oOtUtx85xi89Lh qWTxr1kAqsBw6qWRXZA5xr/+nYgK1Jb9UU/cbaz1Kp+veQh/FkG/ZAD5h c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAD5Z8hb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYFbgRBtEiiDdYh2jUmZCQ0YC4QDRgKFIDgWAQMBAQI?= =?us-ascii?q?BAQJtHAyFOgEBAQMBASEVNhsLDgoCAiYCAicwBgEMBgIBAYMcAYIBD6YGgS6?= =?us-ascii?q?FOoRlBYELilmBQT+BESeCa4MbAQGEZIJXAohlBIVZQI82CZBhBheJLoZ5kAq?= =?us-ascii?q?GOoFaIYFVMxoIGxU7gmyCJhd8AQuHU4U/PjCLDQEB?=
X-IronPort-AV: E=Sophos;i="5.54,396,1534809600";  d="scan'208";a="7339568"
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; 18 Oct 2018 11:10:42 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9IBAfDw030463; Thu, 18 Oct 2018 11:10:42 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <85d40a83-5dfc-a651-e4f1-1c65035704dc@cisco.com>
Date: Thu, 18 Oct 2018 12:10:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 11:10:47 -0000

Given where we are, I also agree that A is the better choice.

I would also like to have a context-independent encoding of all YANG 
types in the future.

Thanks,
Rob


On 18/10/2018 11:30, Martin Bjorklund wrote:
> Hi,
>
> Going back to the most urgent issue, what is this WG's recommendation
> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> yang:xpath1.0 in filters?
>
> To summarize:
>
> We already have
>
>    o  instance-identifier in XML uses prefixes from the XML document
>    o  instance-identifier in JSON uses module names as prefixes
>    o  XPath in NETCONF filter uses prefixes from the XML document
>    o  XPath in JSON query filter uses module names as prefixes
>
>
> Alternative A:
> --------------
>
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
>
> We would do in SN:
>
>      o  If the node is encoded in XML, the set of namespace
>         declarations are those in scope on the
>         'stream-xpath-filter' leaf element.
>
>      o  If the node is encoded in JSON, the set of namespace
>         declarations is the set of prefix and namespace pairs
>         for all supported YANG modules, where the prefix is
>         the YANG module name and the namespace is as defined
>         by the "namespace" statement in the YANG module.
>
> Pro: the format is consistent within each encoding.
>
> Con: unclear how to handle other encodings.
> Con: we keep using context-depending encodings.
>
> We could probably add that CBOR uses the same representation as JSON.
>
> Example in XML:
>
>            xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>      /if:interfaces/if:interface/ip:ipv4
>    
>
> Example in JSON:
>
>    "stream-xpath-filter":
>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
>
> Alternative B:
> --------------
>
> Use a non-context depending encoding, with the module name as prefix.
>
> We would do in SN:
>
>      o  The set of namespace
>         declarations is the set of prefix and namespace pairs
>         for all supported YANG modules, where the prefix is
>         the YANG module name and the namespace is as defined
>         by the "namespace" statement in the YANG module.
>
> Pro: the format is independent from the protocol encoding
>
> Con: in XML, this leaf is treated differently from other XPath
>       expressions, such as get-config filter and nacm rules.
>
> Example in XML:
>
>    
>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>    
>
> Example in JSON:
>
>    "stream-xpath-filter":
>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.
>
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
>
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Oct 18 06:12:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01A12D4EE for ; Thu, 18 Oct 2018 06:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.592
X-Spam-Level: 
X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpVaaInz7xau for ; Thu, 18 Oct 2018 06:12:00 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 45E7712008A for ; Thu, 18 Oct 2018 06:12:00 -0700 (PDT)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id C564942B07 for ; Thu, 18 Oct 2018 07:03:43 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id D7xng98AevdTuD7xngU46C; Thu, 18 Oct 2018 07:03:43 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mwn4qdVcs5pmPYn64quq6OG+6dz18wh+5gfUSDf7D0Q=; b=GZKxW0vEWV5m8XMDFDMVNeCF6N ibTqzKA9+EKgZWAEWdIiNe2LEqu2OtSyDeopDGwQLajH7L5outA/0IgY4oJQ7KhqYQennu3seRNj+ tgqLozw/pW9BDprjfDe1JPs9b;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:48522 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gD7xn-000Hzz-Gy; Thu, 18 Oct 2018 07:03:43 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
Message-ID: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Date: Thu, 18 Oct 2018 09:03:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gD7xn-000Hzz-Gy
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:48522
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Org: HG=bhcustomer;ORG=bluehost;
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 13:12:02 -0000

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)


From nobody Thu Oct 18 06:18:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5242130F2F for ; Thu, 18 Oct 2018 06:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 gSjXzo9FdR5s for ; Thu, 18 Oct 2018 06:17:56 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1575130F1A for ; Thu, 18 Oct 2018 06:17:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4910; q=dns/txt; s=iport; t=1539868675; x=1541078275; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mRu3pmAqXcCimSchf+ch3LEiLr1OFtJ17KKREzZh43Q=; b=hMBovf+anokcW5tz0mu0KXx9q75W0mOisWnj+FhuPTIhTwSqjhHvToim WRSCB/Q+Vs2i8c/DLTy7dmqMliGMMLdCPOMRXAqI2i5KcgfVbeO0PEzR5 RDeTFVfX7ZcGLq7FOj1iyUe4X92lYBKWOD2KvppDloc4eriOHuEZkgDE+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADjhshb/5BdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVQUqZn8oCoNriBeMG4FolzSBegsBARgLhAN?= =?us-ascii?q?GAheEaiE0DQ0BAwEBAgEBAm0cDIU6AgEDAQEhETobAgEIDgwCJgICAiULFRA?= =?us-ascii?q?CBAESgyABggEPphOBLooeBYELikIXgUE/gREnDBOCTIMbAQGBYReCbDGCJgK?= =?us-ascii?q?IZQSFWY92CQKQZReQJ5YdAhEUgSYdOIFVcBU7KgGCQYImF3wBC4dThT5viiG?= =?us-ascii?q?BHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,396,1534809600"; d="scan'208";a="250133401"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2018 13:17:53 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w9IDHrnQ028508 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Oct 2018 13:17:53 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct 2018 08:17:52 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Thu, 18 Oct 2018 08:17:53 -0500
From: "Reshad Rahman (rrahman)" 
To: Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIqyJUA4hM8yQEuWRAlaWHhia6UYv5+AgAAV+YCAAIZOgIAASaoAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgABShQCAAAlqgIABCfeAgAmNmgD//+uuAA==
Date: Thu, 18 Oct 2018 13:17:53 +0000
Message-ID: <6ED21B8D-A711-4489-AECB-32DCF5947C02@cisco.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.253.209]
Content-Type: text/plain; charset="utf-8"
Content-ID: <14C063152F07A048A49AC94425609664@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 13:18:05 -0000

V2UgY2FuJ3QgdGltZSB0cmF2ZWwgYW5kIGFzIHlvdSBtZW50aW9uZWQgb3B0aW9uIEEgaGFzIGNv
bnNpc3RlbmN5IHdpdGhpbiBlYWNoIGVuY29kaW5nLCBzbyBJJ20gYWxzbyBmb3Igb3B0aW9uIEEu
IA0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQrvu79PbiAyMDE4LTEwLTE4LCA2OjMwIEFNLCAibmV0
bW9kIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmcgb24gYmVoYWxmIG9mIG1iakB0YWlsLWYuY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0K
ICAgIEdvaW5nIGJhY2sgdG8gdGhlIG1vc3QgdXJnZW50IGlzc3VlLCB3aGF0IGlzIHRoaXMgV0cn
cyByZWNvbW1lbmRhdGlvbg0KICAgIGZvciB0aGUgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGRy
YWZ0IGluIE5FVENPTkYgd3J0LyB0aGVpciB1c2FnZSBvZg0KICAgIHlhbmc6eHBhdGgxLjAgaW4g
ZmlsdGVycz8NCiAgICANCiAgICBUbyBzdW1tYXJpemU6DQogICAgDQogICAgV2UgYWxyZWFkeSBo
YXZlDQogICAgDQogICAgICBvICBpbnN0YW5jZS1pZGVudGlmaWVyIGluIFhNTCB1c2VzIHByZWZp
eGVzIGZyb20gdGhlIFhNTCBkb2N1bWVudA0KICAgICAgbyAgaW5zdGFuY2UtaWRlbnRpZmllciBp
biBKU09OIHVzZXMgbW9kdWxlIG5hbWVzIGFzIHByZWZpeGVzDQogICAgICBvICBYUGF0aCBpbiBO
RVRDT05GIGZpbHRlciB1c2VzIHByZWZpeGVzIGZyb20gdGhlIFhNTCBkb2N1bWVudA0KICAgICAg
byAgWFBhdGggaW4gSlNPTiBxdWVyeSBmaWx0ZXIgdXNlcyBtb2R1bGUgbmFtZXMgYXMgcHJlZml4
ZXMNCiAgICANCiAgICANCiAgICBBbHRlcm5hdGl2ZSBBOg0KICAgIC0tLS0tLS0tLS0tLS0tDQog
ICAgDQogICAgVXNlIGRpZmZlcmVudCBlbmNvZGluZ3MgZm9yICJzdHJlYW0teHBhdGgtZmlsdGVy
IiBhcyB3ZWxsLCBkZXBlbmRpbmcNCiAgICBvbiBpZiBpdCBpcyBYTUwgb3IgSlNPTi4NCiAgICAN
CiAgICBXZSB3b3VsZCBkbyBpbiBTTjoNCiAgICANCiAgICAgICAgbyAgSWYgdGhlIG5vZGUgaXMg
ZW5jb2RlZCBpbiBYTUwsIHRoZSBzZXQgb2YgbmFtZXNwYWNlDQogICAgICAgICAgIGRlY2xhcmF0
aW9ucyBhcmUgdGhvc2UgaW4gc2NvcGUgb24gdGhlDQogICAgICAgICAgICdzdHJlYW0teHBhdGgt
ZmlsdGVyJyBsZWFmIGVsZW1lbnQuDQogICAgDQogICAgICAgIG8gIElmIHRoZSBub2RlIGlzIGVu
Y29kZWQgaW4gSlNPTiwgdGhlIHNldCBvZiBuYW1lc3BhY2UNCiAgICAgICAgICAgZGVjbGFyYXRp
b25zIGlzIHRoZSBzZXQgb2YgcHJlZml4IGFuZCBuYW1lc3BhY2UgcGFpcnMNCiAgICAgICAgICAg
Zm9yIGFsbCBzdXBwb3J0ZWQgWUFORyBtb2R1bGVzLCB3aGVyZSB0aGUgcHJlZml4IGlzDQogICAg
ICAgICAgIHRoZSBZQU5HIG1vZHVsZSBuYW1lIGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmlu
ZWQNCiAgICAgICAgICAgYnkgdGhlICJuYW1lc3BhY2UiIHN0YXRlbWVudCBpbiB0aGUgWUFORyBt
b2R1bGUuDQogICAgDQogICAgUHJvOiB0aGUgZm9ybWF0IGlzIGNvbnNpc3RlbnQgd2l0aGluIGVh
Y2ggZW5jb2RpbmcuDQogICAgDQogICAgQ29uOiB1bmNsZWFyIGhvdyB0byBoYW5kbGUgb3RoZXIg
ZW5jb2RpbmdzLg0KICAgIENvbjogd2Uga2VlcCB1c2luZyBjb250ZXh0LWRlcGVuZGluZyBlbmNv
ZGluZ3MuDQogICAgDQogICAgV2UgY291bGQgcHJvYmFibHkgYWRkIHRoYXQgQ0JPUiB1c2VzIHRo
ZSBzYW1lIHJlcHJlc2VudGF0aW9uIGFzIEpTT04uDQogICAgDQogICAgRXhhbXBsZSBpbiBYTUw6
DQogICAgDQogICAgICA8c3RyZWFtLXhwYXRoLWZpbHRlcg0KICAgICAgICAgIHhtbG5zOmlmPSJ1
cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pbnRlcmZhY2VzIg0KICAgICAgICAgIHht
bG5zOmlwPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pcCI+DQogICAgICAgIC9p
ZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9pcDppcHY0DQogICAgICA8L3N0cmVhbS14cGF0aC1m
aWx0ZXI+DQogICAgDQogICAgRXhhbXBsZSBpbiBKU09OOg0KICAgIA0KICAgICAgInN0cmVhbS14
cGF0aC1maWx0ZXIiOg0KICAgICAgICAiL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYt
aW50ZXJmYWNlczppbnRlcmZhY2UvaWV0Zi1pcDppcHY0Ig0KICAgIA0KICAgIA0KICAgIA0KICAg
IEFsdGVybmF0aXZlIEI6DQogICAgLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICBVc2UgYSBub24t
Y29udGV4dCBkZXBlbmRpbmcgZW5jb2RpbmcsIHdpdGggdGhlIG1vZHVsZSBuYW1lIGFzIHByZWZp
eC4NCiAgICANCiAgICBXZSB3b3VsZCBkbyBpbiBTTjoNCiAgICANCiAgICAgICAgbyAgVGhlIHNl
dCBvZiBuYW1lc3BhY2UNCiAgICAgICAgICAgZGVjbGFyYXRpb25zIGlzIHRoZSBzZXQgb2YgcHJl
Zml4IGFuZCBuYW1lc3BhY2UgcGFpcnMNCiAgICAgICAgICAgZm9yIGFsbCBzdXBwb3J0ZWQgWUFO
RyBtb2R1bGVzLCB3aGVyZSB0aGUgcHJlZml4IGlzDQogICAgICAgICAgIHRoZSBZQU5HIG1vZHVs
ZSBuYW1lIGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmluZWQNCiAgICAgICAgICAgYnkgdGhl
ICJuYW1lc3BhY2UiIHN0YXRlbWVudCBpbiB0aGUgWUFORyBtb2R1bGUuDQogICAgDQogICAgUHJv
OiB0aGUgZm9ybWF0IGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHByb3RvY29sIGVuY29kaW5nDQog
ICAgDQogICAgQ29uOiBpbiBYTUwsIHRoaXMgbGVhZiBpcyB0cmVhdGVkIGRpZmZlcmVudGx5IGZy
b20gb3RoZXIgWFBhdGgNCiAgICAgICAgIGV4cHJlc3Npb25zLCBzdWNoIGFzIGdldC1jb25maWcg
ZmlsdGVyIGFuZCBuYWNtIHJ1bGVzLg0KICAgIA0KICAgIEV4YW1wbGUgaW4gWE1MOg0KICAgIA0K
ICAgICAgPHN0cmVhbS14cGF0aC1maWx0ZXI+DQogICAgICAgIC9pZXRmLWludGVyZmFjZXM6aW50
ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXA6aXB2NA0KICAgICAgPC9z
dHJlYW0teHBhdGgtZmlsdGVyPg0KICAgIA0KICAgIEV4YW1wbGUgaW4gSlNPTjoNCiAgICANCiAg
ICAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoNCiAgICAgICAgIi9pZXRmLWludGVyZmFjZXM6aW50
ZXJmYWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXA6aXB2NCINCiAgICANCiAg
ICANCiAgICBNeSBwcm9wb3NhbCBpcyBBLiAgSSB0aGluayBpdCBpcyBtb3JlIGltcG9ydGFudCB3
aXRoIGNvbnNpc3RlbmN5DQogICAgd2l0aGluIGVhY2ggZW5jb2RpbmcgdGhhbiBhY3Jvc3MgZW5j
b2RpbmdzLg0KICAgIA0KICAgIChUaGlzIHNhaWQsIEkgd291bGQgbGlrZSB0byBoYXZlIGEgY29u
dGV4dC1pbmRlcGVuZGVudCBlbmNvZGluZyBvZiBhbGwNCiAgICBZQU5HIHR5cGVzIGluIHRoZSBm
dXR1cmUuICBCdXQgbm90IG5vdy4pDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgL21hcnRp
bg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgIGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgDQoNCg==


From nobody Thu Oct 18 06:23:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB06130DCB for ; Thu, 18 Oct 2018 06:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mMbae9ShiQA for ; Thu, 18 Oct 2018 06:23:06 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 8ADC212D4ED for ; Thu, 18 Oct 2018 06:23:06 -0700 (PDT)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id AAD40178CDC for ; Thu, 18 Oct 2018 07:13:19 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id D875gZBbbj0soD875gB262; Thu, 18 Oct 2018 07:13:19 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=CYHR+SManCqIOk4kIlpCaGNrRsmG3QOIZAFEJyIJnuI=; b=c9iJizldNtlvCHthz6Xx8aNJXZ xkCn2d96+mpBeomJuFM31E4sYAWWkENSvW6kWbxABrTQEavouD5Xu+03MmIbQ/FzEGRM44/pWWZ3r 69eAU0zxS/KaOsX6fN+mwDWz/;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:48682 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gD875-000LPH-Ex; Thu, 18 Oct 2018 07:13:19 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Message-ID: <41a696e4-9658-95b1-5f37-b736d9af02ca@labn.net>
Date: Thu, 18 Oct 2018 09:13:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gD875-000LPH-Ex
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:48682
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 13:23:08 -0000

Poll ends Nov 1 - sorry about that...


On 10/18/2018 9:03 AM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Thu Oct 18 07:40:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612B4129C6B; Thu, 18 Oct 2018 07:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level: 
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpC3tqZZpv7m; Thu, 18 Oct 2018 07:40:39 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D0A12426A; Thu, 18 Oct 2018 07:40:39 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9IEdUqH015159; Thu, 18 Oct 2018 07:40:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=/jjaIc1Tbt9AQbTeHho13Wz0OZGAAb8yin+PcnfXjqs=; b=hkguJnYOepTcwKvnWsM9J9zTnPxssaYXcFRRMNSj1EJx+dnS5KKeWrC+6t6n9Mx0rWaa cRSatym0QCbMOAskfTQkKb+eRQwu4CI30JdncJc65Y7vxddRr15kbAhC2AXECpHxcBp1 qWXfDiO7K8rahzUxp5B7BTNYwGKFwo/pD0eJcIx6KURbmMLnHdxXJF560UdhgVBj8slC 9js5WVJEyHu+q3r93tBvFgxFZdJZS+oaG+sm9hJCjweF1YcUTIkyQTe26Dgvc7ke7H/A cUo/GlmeWcZ0fDPgr/wZXFpYpMUpqW1GwkR90OKgbiW/sQpDFTcXRRU5L/DWcIif4LXn sQ== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) by mx0b-00273201.pphosted.com with ESMTP id 2n6smd89dw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 07:40:38 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5305.namprd05.prod.outlook.com (20.176.119.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Thu, 18 Oct 2018 14:40:35 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%4]) with mapi id 15.20.1250.020; Thu, 18 Oct 2018 14:40:35 +0000
From: Kent Watsen 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZuQVidlHv6+/gECDyKpE/4pPA6Uk0FyA
Date: Thu, 18 Oct 2018 14:40:35 +0000
Message-ID: <220C36CA-C819-4FAA-8CF9-A906529C44FA@juniper.net>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5305; 6:1ZJekTYIlFSyqDbIvjy7ixdXUi6JC8vJx82L3xRHtLH4RVPkRgOfP2g128Smk8as682mYPGygal1KU4U8ywolVo2HP3UHkiAD+ef0of3izqUfOTbmEbkb2FIHklEvMR5fyDUD4o93xAVeB+rszJoFV6Kxlac+M2QRL/aBx0VvyaEmufyRppSzKJo3m9gcvSsXywr4zrdOjyIfK7kAw83eHluLHbnrTUymz1wqo09j5I2nHzlVOHnwPSMCD3UToqTxSPKTnvAOD1h+WGvIEzaRnd71yh8cMpN8XHOg6Ans9Tu+taLR2MgUInd/YsV2ntOI0rT69vr9GAV5bSY8a9AC01Vf7j18CbH7OlGwCSeqbq5Vr1eLcV5L4V83vPkbypNiDDFxABjgp5QI66r3ntXZVU693q1aRqmlWsBolHO9sQGI7l1RIQoHNxf0wPgC1umu3lZhGRao/bBUdGzf/UnNA==; 5:W0iJ4tfk6KuXsyacBsYmrYjrIrtmmmKlg6ZQ7LFcf2X+0HQJgI14jMPs27eDXO4JP2CvmW2nV8JxCDvGdKvmK0ACObQp62TJlGG3+kSwG5LDqHg4C/5eKwsanQPa868S7tmI0cxec6AjsN28GOhCG2VvswvfD1eG08C2PJc71bo=; 7:DCi2X3AWz7e7qmCevL3q7Zpn0j0Q2+hx7DGHho8fVJ7QnHsdsIVyytVSvIFJefssd39DdvsQUyxBJraDoERMKhEfbaPihKW+5EhLZbGUhMNHX8nsdFH5+CAAwhqqz/T3uRcRDMIwEYi7zUkEdNWYwrIJvC7AmHeZ8dDE4JAgZ4fWxDqTe6Q2vNWbMTkb5RztIeU3VjQJ2OhajVaraep3KeOxaKnS7wlvr68QFDkSVSaJsnq5IcUgH8fSNWHO5aPB
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7d5532ca-04c0-4e18-6099-08d63507aa55
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5305; 
x-ms-traffictypediagnostic: DM6PR05MB5305:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5305; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5305; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(39860400002)(376002)(346002)(199004)(189003)(13464003)(6506007)(6486002)(106356001)(2906002)(6346003)(6512007)(186003)(102836004)(53936002)(26005)(105586002)(305945005)(6436002)(25786009)(33656002)(3846002)(82746002)(66066001)(97736004)(86362001)(8936002)(6116002)(5660300001)(7736002)(71190400001)(2900100001)(5250100002)(476003)(71200400001)(68736007)(14454004)(4326008)(99286004)(478600001)(486006)(83716004)(81156014)(8676002)(110136005)(53546011)(229853002)(6246003)(36756003)(2616005)(81166006)(256004)(446003)(316002)(58126008)(76176011)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5305; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 7uUJcJoISGZQTfiell5Ej+W4hUbYWiBgcrLFWziI+7oeZT1Mqe1uRW3sqcUa+9pvdzEqzefTVSHgg2x0svPDA3WzuSyWivIVuuFM0yDhXbCCx0eMztwsDNxvr+xES90Dray64fZ0TJb0aHh8wMp/nLsGCIJ9HqYNe1hn8vS8BgLFmrHiDeNYjul73+PWaOjHAqIU3YCu/8Ru6BmWSgc2Ypt1FvIDivodSJ+I6Z/NWseKwyaOzWPWtjqaLdq+uRYJK3UvW/QZY0y8AMzVKe8FI88demMRoO10SiXXVLXKzizoQ3UdZAF+cFSroR02kEOZlFX1M6XRGBitQ7EDWCNjE+no6AVZ6Q73EZEbh12leu4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d5532ca-04c0-4e18-6099-08d63507aa55
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 14:40:35.6862 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5305
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180127
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 14:40:42 -0000

W2ZpeGVkIHRoZSBkYXRlIGluIExvdSdzIG1lc3NhZ2UgYmVsb3ddDQoNCk5vIG9iamVjdGlvbi4N
Cg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KRGF0ZTogVGh1cnNkYXksIE9j
dG9iZXIgMTgsIDIwMTggYXQgOToxMSBBTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RA
aWV0Zi5vcmc+DQpDYzogIm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciIDxuZXRtb2QtY2hhaXJzQGll
dGYub3JnPg0KU3ViamVjdDogV0cgYWRvcHRpb24gcG9sbCBkcmFmdC1rd2F0c2VuLW5ldG1vZC1h
cnR3b3JrLWZvbGRpbmctMDgNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4N
ClJlc2VudC1UbzogPGpvZWxqYUBib2d1cy5jb20+LCA8bGJlcmdlckBsYWJuLm5ldD4sIDxrd2F0
c2VuQGp1bmlwZXIubmV0Pg0KUmVzZW50LURhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDE4LCAyMDE4
IGF0IDk6MTEgQU0NCg0KQWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCBv
biBtYWtpbmcNCmRyYWZ0LWt3YXRzZW4tbmV0bW9kLWFydHdvcmstZm9sZGluZy0wOCBhIHdvcmtp
bmcgZ3JvdXANCmRvY3VtZW50LiBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0
aW5nICJ5ZXMvc3VwcG9ydCIgb3INCiJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5n
IG5vLCBwbGVhc2Ugc3RhdGUgeW91ciByZXNlcnZhdGlvbnMNCndpdGggdGhlIGRvY3VtZW50LiAg
SWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cw0KeW91J2Qg
bGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQu
DQoNClRoZSBwb2xsIGVuZHMgTm92IDEuDQoNClRoYW5rcywNCg0KTG91IChhbmQgY28tY2hhaXJz
KQ0KDQo=


From nobody Thu Oct 18 08:00:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D512F1A2; Thu, 18 Oct 2018 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzTRRelmCdON; Thu, 18 Oct 2018 08:00:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 268CF128CE4; Thu, 18 Oct 2018 08:00:34 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 15B596B05A80D; Thu, 18 Oct 2018 16:00:31 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Oct 2018 16:00:32 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Thu, 18 Oct 2018 23:00:26 +0800
From: Qin Wu 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AdRm8wxMd0TQkYrvQ4WqPAn/6ZCCtw==
Date: Thu, 18 Oct 2018 15:00:26 +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.45.108.218]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 15:00:37 -0000

WWVzL3N1cHBvcnQuDQoNCi1RaW4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpEYXRlOiBUaHVyc2RheSwgT2N0b2Jl
ciAxOCwgMjAxOCBhdCA5OjExIEFNDQpUbzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRm
Lm9yZz4NCkNjOiAibmV0bW9kLWNoYWlyc0BpZXRmLm9yZyIgPG5ldG1vZC1jaGFpcnNAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBXRyBhZG9wdGlvbiBwb2xsIGRyYWZ0LWt3YXRzZW4tbmV0bW9kLWFydHdv
cmstZm9sZGluZy0wOA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVz
ZW50LVRvOiA8am9lbGphQGJvZ3VzLmNvbT4sIDxsYmVyZ2VyQGxhYm4ubmV0PiwgPGt3YXRzZW5A
anVuaXBlci5uZXQ+DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgMTgsIDIwMTggYXQg
OToxMSBBTQ0KDQpBbGwsDQoNClRoaXMgaXMgc3RhcnQgb2YgYSB0d28gd2VlayBwb2xsIG9uIG1h
a2luZw0KZHJhZnQta3dhdHNlbi1uZXRtb2QtYXJ0d29yay1mb2xkaW5nLTA4IGEgd29ya2luZyBn
cm91cCBkb2N1bWVudC4gUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyAi
eWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5nIG5vLCBw
bGVhc2Ugc3RhdGUgeW91ciByZXNlcnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMs
IHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzIHlvdSdkIGxpa2UgdG8g
c2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50Lg0KDQpUaGUg
cG9sbCBlbmRzIE5vdiAxLg0KDQpUaGFua3MsDQoNCkxvdSAoYW5kIGNvLWNoYWlycykNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls
aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCg==


From nobody Thu Oct 18 08:20:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13B12D7EA; Thu, 18 Oct 2018 08:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 nAirSATLzMnp; Thu, 18 Oct 2018 08:20:46 -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 9899F1277C8; Thu, 18 Oct 2018 08:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=696; q=dns/txt; s=iport; t=1539876046; x=1541085646; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=boxmpIDbrd3Ip6LuzOBKjx8ITw6/6aKlmSXiqf0hGSw=; b=CVG5iToe5GjpUJVJvWaWVaR8tzeEJapLdYU/jdXonoWLH2fFySPhzusC IMynUXk05Lk2cyvmeWhYOX0KkRyZs0/sedXpS047ZwHG/LGv7qqjIMwp6 zgx51qO55F1ozSYborhmeJlAaTQsxc2Bv1iNzpO6qYjK0sPfmD2EkUqJ0 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AADwo8hb/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJrbRIog3WIdo0cLZcjgWYNGAuEA0YChSQ4FgEDAQE?= =?us-ascii?q?CAQECbRwMhToBAQEDAQEhDwEFNgsQCw4KAgImAgInMAYBDAYCAQGDHAGCAQ+?= =?us-ascii?q?mO4EuhTqEYgWBC4pZgUE/gTiCa4MbAQGBLgESAYMiglcCnjgJkGEGF4FPhHG?= =?us-ascii?q?CboZ5kAqGOoFaIWRxMxoIGxU7gmyLGIU/PjCJAoI+AQE?=
X-IronPort-AV: E=Sophos;i="5.54,396,1534809600";  d="scan'208";a="7342573"
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; 18 Oct 2018 15:20:43 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w9IFKfZA011213; Thu, 18 Oct 2018 15:20:43 GMT
To: Lou Berger , NetMod WG 
Cc: NetMod WG Chairs 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
From: Robert Wilton 
Message-ID: <943ddbc3-1a29-2f09-691b-00bdd1148bf8@cisco.com>
Date: Thu, 18 Oct 2018 16:20:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 15:20:48 -0000

Yes/support.

Thanks,
Rob


On 18/10/2018 14:03, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Oct 18 10:42:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74702130DCB for ; Thu, 18 Oct 2018 10:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Level: 
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAjYmUJh_RZy for ; Thu, 18 Oct 2018 10:42:03 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215CD130DC6 for ; Thu, 18 Oct 2018 10:42:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B78A21541824; Thu, 18 Oct 2018 19:42:00 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id quqIKB55Dcjc; Thu, 18 Oct 2018 19:42:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 81D281541821; Thu, 18 Oct 2018 19:42:00 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gjVvY90lOqen; Thu, 18 Oct 2018 19:42:00 +0200 (CEST)
Received: from [192.168.209.177] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 579F91541753; Thu, 18 Oct 2018 19:42:00 +0200 (CEST)
To: Martin Bjorklund , netmod@ietf.org
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
From: Vladimir Vassilev 
Message-ID: <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>
Date: Thu, 18 Oct 2018 19:42:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 17:42:06 -0000

Hi,

Seems this discussion affects 10 draft modules using the xpath1.0 type.=20
The proposed boilerplate description text that was not added to some RFC=20
modules like ietf-netconf-monitoring@2010-10-04.yang

should be as consistent as possible (or skipped based on the=20
ietf-netconf-monitoring precedent) until a better alternative is=20
available. Here is an example of a better alternative.

 =C2=A0=C2=A0 typedef ypath1.0 {
 =C2=A0=C2=A0=C2=A0 type xpath1.0;
 =C2=A0=C2=A0=C2=A0 description
 =C2=A0=C2=A0=C2=A0=C2=A0 "This type represents subset of XPATH 1.0 expre=
ssions
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that apply to a data tree conforming to a=
 YANG model.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Each encoding should allow conversion to =
an encoding
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 independent lexical representation where =
data node
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prefixes are resolved to and substituted =
with module
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 names.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When a schema node is defined that uses t=
his type, the
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description of the schema node MUST speci=
fy the
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context in which the expression is evalua=
ted if it
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is different from the default context.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The default context is as follows:

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The set of variable b=
indings is empty.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The function library =
is the core function library, and
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the XPath f=
unctions defined in section 10 in RFC 7950.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The context node is t=
he leaf node.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ";
 =C2=A0=C2=A0=C2=A0 reference
 =C2=A0=C2=A0=C2=A0=C2=A0 "XPATH: XML Path Language (XPath) Version 1.0";
 =C2=A0 }

That said I do not object to short-term application of alternative A as=20
long as a long-term solution is on its way for future modules.

Vladimir

On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> Hi,
>
> Going back to the most urgent issue, what is this WG's recommendation
> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> yang:xpath1.0 in filters?
>
> To summarize:
>
> We already have
>
>    o  instance-identifier in XML uses prefixes from the XML document
>    o  instance-identifier in JSON uses module names as prefixes
>    o  XPath in NETCONF filter uses prefixes from the XML document
>    o  XPath in JSON query filter uses module names as prefixes
>
>
> Alternative A:
> --------------
>
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
>
> We would do in SN:
>
>      o  If the node is encoded in XML, the set of namespace
>         declarations are those in scope on the
>         'stream-xpath-filter' leaf element.
>
>      o  If the node is encoded in JSON, the set of namespace
>         declarations is the set of prefix and namespace pairs
>         for all supported YANG modules, where the prefix is
>         the YANG module name and the namespace is as defined
>         by the "namespace" statement in the YANG module.
>
> Pro: the format is consistent within each encoding.
>
> Con: unclear how to handle other encodings.
> Con: we keep using context-depending encodings.
>
> We could probably add that CBOR uses the same representation as JSON.
>
> Example in XML:
>
>            xmlns:if=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces"
>        xmlns:ip=3D"urn:ietf:params:xml:ns:yang:ietf-ip">
>      /if:interfaces/if:interface/ip:ipv4
>    
>
> Example in JSON:
>
>    "stream-xpath-filter":
>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv=
4"
>
>
>
> Alternative B:
> --------------
>
> Use a non-context depending encoding, with the module name as prefix.
>
> We would do in SN:
>
>      o  The set of namespace
>         declarations is the set of prefix and namespace pairs
>         for all supported YANG modules, where the prefix is
>         the YANG module name and the namespace is as defined
>         by the "namespace" statement in the YANG module.
>
> Pro: the format is independent from the protocol encoding
>
> Con: in XML, this leaf is treated differently from other XPath
>       expressions, such as get-config filter and nacm rules.
>
> Example in XML:
>
>    
>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>    
>
> Example in JSON:
>
>    "stream-xpath-filter":
>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv=
4"
>
>
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.
>
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
>
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Oct 18 10:47:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D74130DC6; Thu, 18 Oct 2018 10:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7y6_Whz_HyV; Thu, 18 Oct 2018 10:47:05 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E501130DC0; Thu, 18 Oct 2018 10:47:05 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id f8-v6so14522437pgq.5; Thu, 18 Oct 2018 10:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8N42dN/hWGzt7GW2DSTkM7ckpqEzb7fgkiAVQMcJHlI=; b=Oxy9B633W7FY4v1khneYhq87nRMzVgVBj25lApRneWNAxsKZw4nw7JwBHED6c7UO39 6RrORJBXAe4CxM6LBDBT8mDmSRjI9oI66k08BA2yee/5GGuLKClOR1M1DvebP/1caohy OSm7JJ46/7Ww8UlP/Bw7c5Exme2BMY2R9myHMIHRe67hyvILTHpQ4vqb3MyFcMPWbn+j hMvhwbDS/UUcbF76aqzQI6RejsS1kah5uthH/WrmeLMpbhMh/ztW/f++nDSn1xgZDoUQ qzR2N6GmiJsCMrg3vS98aY4Hc0E5skZX8O96I/5mZKpTNslQ7dljorx3OX7DyT0RoNqq 4kyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8N42dN/hWGzt7GW2DSTkM7ckpqEzb7fgkiAVQMcJHlI=; b=IutDpK52LzaVzPm0GFcNb3rk0AC8Tzh1PfbE8PB69mNDcLT+ao6n4BQjoIhe9yElnv fdQmDHxqyWtvn4DbN3js8VD6OV/Zwcdo9BH7CTmaCMV8J9dSLx7W40mhCiMjBOcLC+OT jf7WAXSm3nEU9yVR3vK1VhdRj/kRm1urRQyG/s0gsKjUfoElRpaeaASHfBicZ+1mhRrT MfHxF7HBcoQlR96yx8kjoXjt85xEVSnOlLPRQOHNu4NDKrydUNqVKzG6tzDFQFs2V2Yo 6T3L2yEz4kj/rfRa3kVQHPHAPHqa6B2xR0ufMp8RK52O53disStso4MnzbdVEjrmMrV3 rc/A==
X-Gm-Message-State: ABuFfoiDJ96NtfZz1u9f90y8M84oCwn6Hr7gRRZmjydykyoWw1OPVEOG F2sEKqSB8bgC4aejbn9C/OBv0DY5
X-Google-Smtp-Source: ACcGV62nLKNwDfo7/gQdFbaH/GNSSQOZ9ezp63MtjGXJi0dHVMTOKBbWUtCp+41p+ufbLQ5gMoYMUg==
X-Received: by 2002:a62:571b:: with SMTP id l27-v6mr31606830pfb.209.1539884825060;  Thu, 18 Oct 2018 10:47:05 -0700 (PDT)
Received: from [10.33.122.212] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id m20-v6sm21786201pgv.93.2018.10.18.10.47.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 10:47:04 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani 
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Date: Thu, 18 Oct 2018 10:47:03 -0700
Cc: NetMod WG , NetMod WG Chairs 
Content-Transfer-Encoding: 7bit
Message-Id: <5E1AF7A3-D483-45BB-B66A-68511B155EAD@gmail.com>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
To: Lou Berger 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 17:47:08 -0000

Support.

> On Oct 18, 2018, at 6:03 AM, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Thu Oct 18 12:45:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6EF130DE5 for ; Thu, 18 Oct 2018 12:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 Dgtn4gcXaHw0 for ; Thu, 18 Oct 2018 12:45:48 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 EF455130DDB for ; Thu, 18 Oct 2018 12:45:47 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id 63-v6so28842634ljs.4 for ; Thu, 18 Oct 2018 12:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lvas54jfLTCIoV+7vYXstv+BSzbH9p6pNZ8IT4GOfQM=; b=raEjb+GS50OMEN6DiDbPlH8M1dXaqM2nEFH9pUWo9uNeBEhNnS1lFY+AwwwGQ/URDB 7Ge3WmmvUlL6Hy+Bnu+xqjE7rxvOZ5dYun0lffxDp1i/i9l0RcGxTfeOzMpKobloZirb JdOkmq6+glUp4U2Qm0/AXs1W8DGFFmfbVyIhPPDiqT+s25qj/CpKaoIF4x+VRiaDqUbR UMHznKTvjXfHJRnXWGQ/+KKVwauzf4iEFbz4Woy2+LXcrBGGdl6+OgVWwFCaWNxWzupP wu+0EYi25bpmBxI18XTr1Skd5Xw3ZiFdiHoRBOst+NjN4nFpBcttuSfW0glm7RebnYx8 Ps0w==
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=lvas54jfLTCIoV+7vYXstv+BSzbH9p6pNZ8IT4GOfQM=; b=rZNZX1G0bmG+HbP28j+wWFp/N56JJWUVRiKI2sDZYYEY5BIjFJ2gpgEOQU42qCQFL4 JYw0OwAseor0wwqBGXrGqKH+NQRdJwj3Wd7N816nMMKLns+OYYnVuMoGQf7CNmv/N8bR UEQCABTAzub0WFrzD03g8s2huFkYjwChbCra4UDyWjpPg5BpzIACR8yoQsuU+bsU9Klz /pUXpHT2iK4cJmXARms2MIrNhhJd6I6d64WYKygaPF2EQWz9dmvcm2k0unqiYuVXc5qZ gGnRHYhJBBPxNWy1o8mJfdITYIDgAM52Mtqdbvy89go6NWbVkDCsXRmwaN0Bl+0oO4GC C9Mw==
X-Gm-Message-State: ABuFfojreKdl6+uuaGzq6jg35YacwvL66a13UCvEpb42Ljxvdih5iOUO /mEKFx0mTDRyQJdxlI6Ap0tsuPw937RM9sAIDfEOu0Kd
X-Google-Smtp-Source: ACcGV62Zlxc2Swp1OYrQJeZbDt/wuxMoag1DEJDxnM2QMMPSkrjuaYbTADUbJFxp6EXOaokyNM9ZdEsQSABHPw+1zC4=
X-Received: by 2002:a2e:9047:: with SMTP id n7-v6mr18339729ljg.10.1539891945921;  Thu, 18 Oct 2018 12:45:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 12:45:44 -0700 (PDT)
In-Reply-To: <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>
From: Andy Bierman 
Date: Thu, 18 Oct 2018 12:45:44 -0700
Message-ID: 
To: Vladimir Vassilev 
Cc: Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000006e097a05788608ff"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 19:45:51 -0000

--0000000000006e097a05788608ff
Content-Type: text/plain; charset="UTF-8"

Hi,

I strongly agree that a new data type is needed (ypath1.0 or just ypath is
fine)
Adding new semantics or requirements to published data types is
unacceptable.

Also, we must get the type and module containing the data type right on the
first try.
No moving it later because the import looks bad. That said, a "quick
6991-bis" is unrealistic,
and a multi-year 6991-bis is unhelpful.

Should there be a canonical format, based on module-names as prefixes?
Consider how to compare 2 values using this data type.


Andy


On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
vladimir@transpacket.com> wrote:

> Hi,
>
> Seems this discussion affects 10 draft modules using the xpath1.0 type.
> The proposed boilerplate description text that was not added to some RFC
> modules like ietf-netconf-monitoring@2010-10-04.yang
>
> should be as consistent as possible (or skipped based on the
> ietf-netconf-monitoring precedent) until a better alternative is available.
> Here is an example of a better alternative.
>
>    typedef ypath1.0 {
>     type xpath1.0;
>     description
>      "This type represents subset of XPATH 1.0 expressions
>       that apply to a data tree conforming to a YANG model.
>
>       Each encoding should allow conversion to an encoding
>       independent lexical representation where data node
>       prefixes are resolved to and substituted with module
>       names.
>
>       When a schema node is defined that uses this type, the
>       description of the schema node MUST specify the
>       context in which the expression is evaluated if it
>       is different from the default context.
>
>       The default context is as follows:
>
>         o  The set of variable bindings is empty.
>
>         o  The function library is the core function library, and
>            the XPath functions defined in section 10 in RFC 7950.
>
>         o  The context node is the leaf node.
>
>       ";
>     reference
>      "XPATH: XML Path Language (XPath) Version 1.0";
>   }
>
> That said I do not object to short-term application of alternative A as
> long as a long-term solution is on its way for future modules.
>
> Vladimir
>
> On 10/18/18 12:30 PM, Martin Bjorklund wrote:
>
>> Hi,
>>
>> Going back to the most urgent issue, what is this WG's recommendation
>> for the subscribed-notifications draft in NETCONF wrt/ their usage of
>> yang:xpath1.0 in filters?
>>
>> To summarize:
>>
>> We already have
>>
>>    o  instance-identifier in XML uses prefixes from the XML document
>>    o  instance-identifier in JSON uses module names as prefixes
>>    o  XPath in NETCONF filter uses prefixes from the XML document
>>    o  XPath in JSON query filter uses module names as prefixes
>>
>>
>> Alternative A:
>> --------------
>>
>> Use different encodings for "stream-xpath-filter" as well, depending
>> on if it is XML or JSON.
>>
>> We would do in SN:
>>
>>      o  If the node is encoded in XML, the set of namespace
>>         declarations are those in scope on the
>>         'stream-xpath-filter' leaf element.
>>
>>      o  If the node is encoded in JSON, the set of namespace
>>         declarations is the set of prefix and namespace pairs
>>         for all supported YANG modules, where the prefix is
>>         the YANG module name and the namespace is as defined
>>         by the "namespace" statement in the YANG module.
>>
>> Pro: the format is consistent within each encoding.
>>
>> Con: unclear how to handle other encodings.
>> Con: we keep using context-depending encodings.
>>
>> We could probably add that CBOR uses the same representation as JSON.
>>
>> Example in XML:
>>
>>    >        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>>      /if:interfaces/if:interface/ip:ipv4
>>    
>>
>> Example in JSON:
>>
>>    "stream-xpath-filter":
>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>>
>> Alternative B:
>> --------------
>>
>> Use a non-context depending encoding, with the module name as prefix.
>>
>> We would do in SN:
>>
>>      o  The set of namespace
>>         declarations is the set of prefix and namespace pairs
>>         for all supported YANG modules, where the prefix is
>>         the YANG module name and the namespace is as defined
>>         by the "namespace" statement in the YANG module.
>>
>> Pro: the format is independent from the protocol encoding
>>
>> Con: in XML, this leaf is treated differently from other XPath
>>       expressions, such as get-config filter and nacm rules.
>>
>> Example in XML:
>>
>>    
>>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>>    
>>
>> Example in JSON:
>>
>>    "stream-xpath-filter":
>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>> My proposal is A.  I think it is more important with consistency
>> within each encoding than across encodings.
>>
>> (This said, I would like to have a context-independent encoding of all
>> YANG types in the future.  But not now.)
>>
>>
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I strongly agree that a new data ty=
pe is needed (ypath1.0 or just ypath is fine)
Adding new semantic=
s or requirements to published data types is unacceptable.

Also, we must get the type and module containing the data type rig=
ht on the first try.
No moving it later because the import looks =
bad. That said, a "quick 6991-bis" is unrealistic,
and =
a multi-year 6991-bis is unhelpful.

Should there b=
e a canonical format, based on module-names as prefixes?
Consider=
 how to compare 2 values using this data type.

Andy


On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <vladimir@transpacket.com> wrote:
Hi,



Seems this discussion affects 10 draft modules using the xpath1.0 type. The=
 proposed boilerplate description text that was not added to some RFC modul=
es like ietf-netconf-monitoring@2010-10-04.yang



should be as consistent as possible (or skipped based on the ietf-netconf-m=
onitoring precedent) until a better alternative is available. Here is an ex=
ample of a better alternative.



=C2=A0=C2=A0 typedef ypath1.0 {

=C2=A0=C2=A0=C2=A0 type xpath1.0;

=C2=A0=C2=A0=C2=A0 description

=C2=A0=C2=A0=C2=A0=C2=A0 "This type represents subset of XPATH 1.0 exp=
ressions

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that apply to a data tree conforming to a YA=
NG model.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Each encoding should allow conversion to an =
encoding

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 independent lexical representation where dat=
a node

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prefixes are resolved to and substituted wit=
h module

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 names.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When a schema node is defined that uses this=
 type, the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description of the schema node MUST specify =
the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context in which the expression is evaluated=
 if it

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is different from the default context.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The default context is as follows:



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The set of variable bind=
ings is empty.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The function library is =
the core function library, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the XPath func=
tions defined in section 10 in RFC 7950.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The context node is the =
leaf node.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ";

=C2=A0=C2=A0=C2=A0 reference

=C2=A0=C2=A0=C2=A0=C2=A0 "XPATH: XML Path Language (XPath) Version 1.0=
";

=C2=A0 }



That said I do not object to short-term application of alternative A as lon=
g as a long-term solution is on its way for future modules.



Vladimir



On 10/18/18 12:30 PM, Martin Bjorklund wrote:



Hi,



Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of

yang:xpath1.0 in filters?



To summarize:



We already have



=C2=A0 =C2=A0o=C2=A0 instance-identifier in XML uses prefixes from the XML =
document

=C2=A0 =C2=A0o=C2=A0 instance-identifier in JSON uses module names as prefi=
xes

=C2=A0 =C2=A0o=C2=A0 XPath in NETCONF filter uses prefixes from the XML doc=
ument

=C2=A0 =C2=A0o=C2=A0 XPath in JSON query filter uses module names as prefix=
es





Alternative A:

--------------



Use different encodings for "stream-xpath-filter" as well, depend=
ing

on if it is XML or JSON.



We would do in SN:



=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the node is encoded in XML, the set of names=
pace

=C2=A0 =C2=A0 =C2=A0 =C2=A0 declarations are those in scope on the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 'stream-xpath-filter' leaf element.



=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the node is encoded in JSON, the set of name=
space

=C2=A0 =C2=A0 =C2=A0 =C2=A0 declarations is the set of prefix and namespace=
 pairs

=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all supported YANG modules, where the prefi=
x is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the YANG module name and the namespace is as de=
fined

=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the "namespace" statement in the Y=
ANG module.



Pro: the format is consistent within each encoding.



Con: unclear how to handle other encodings.

Con: we keep using context-depending encodings.



We could probably add that CBOR uses the same representation as JSON.



Example in XML:



=C2=A0 =C2=A0<stream-xpath-filter

=C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:if=3D"urn:ietf:params:xml:ns:yan=
g:ietf-interfaces"

=C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ip=3D"urn:ietf:params:xml:ns:yan=
g:ietf-ip">

=C2=A0 =C2=A0 =C2=A0/if:interfaces/if:interface/ip:ipv4

=C2=A0 =C2=A0</stream-xpath-filter>



Example in JSON:



=C2=A0 =C2=A0"stream-xpath-filter":

=C2=A0 =C2=A0 =C2=A0"/ietf-interfaces:interfaces/ietf-interfaces:=
interface/ietf-ip:ipv4"







Alternative B:

--------------



Use a non-context depending encoding, with the module name as prefix.



We would do in SN:



=C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of namespace

=C2=A0 =C2=A0 =C2=A0 =C2=A0 declarations is the set of prefix and namespace=
 pairs

=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all supported YANG modules, where the prefi=
x is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the YANG module name and the namespace is as de=
fined

=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the "namespace" statement in the Y=
ANG module.



Pro: the format is independent from the protocol encoding



Con: in XML, this leaf is treated differently from other XPath

=C2=A0 =C2=A0 =C2=A0 expressions, such as get-config filter and nacm rules.=




Example in XML:



=C2=A0 =C2=A0<stream-xpath-filter>

=C2=A0 =C2=A0 =C2=A0/ietf-interfaces:interfaces/ietf-interfaces:interf=
ace/ietf-ip:ipv4

=C2=A0 =C2=A0</stream-xpath-filter>



Example in JSON:



=C2=A0 =C2=A0"stream-xpath-filter":

=C2=A0 =C2=A0 =C2=A0"/ietf-interfaces:interfaces/ietf-interfaces:=
interface/ietf-ip:ipv4"





My proposal is A.=C2=A0 I think it is more important with consistency

within each encoding than across encodings.



(This said, I would like to have a context-independent encoding of all

YANG types in the future.=C2=A0 But not now.)









/martin



_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




--0000000000006e097a05788608ff--


From nobody Thu Oct 18 12:50:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788A6130DEC for ; Thu, 18 Oct 2018 12:50:47 -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 T9hqKOw_zowg for ; Thu, 18 Oct 2018 12:50:44 -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 9AD46130DE4 for ; Thu, 18 Oct 2018 12:50:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D8DB0F39; Thu, 18 Oct 2018 21:50:42 +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 63M3qppZk0Ir; Thu, 18 Oct 2018 21:50:41 +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; Thu, 18 Oct 2018 21:50:42 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A15D20037; Thu, 18 Oct 2018 21:50:42 +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 5r7Y7F_nxRMs; Thu, 18 Oct 2018 21:50:42 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 55F1520036; Thu, 18 Oct 2018 21:50:42 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Thu, 18 Oct 2018 21:48:46 +0200
Received: by anna.localdomain (Postfix, from userid 501) id B25893002615A8; Thu, 18 Oct 2018 21:50:41 +0200 (CEST)
Date: Thu, 18 Oct 2018 21:50:41 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: Vladimir Vassilev , NetMod WG 
Message-ID: <20181018195041.qqm22qgscwoejlos@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Vladimir Vassilev , NetMod WG 
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 19:50:48 -0000

On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:

> No moving it later because the import looks bad. That said, a "quick
> 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.

https://datatracker.ietf.org/doc/rfc6991/

/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 Thu Oct 18 12:58:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB0130DC7 for ; Thu, 18 Oct 2018 12:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAQ6wnkfjBFI for ; Thu, 18 Oct 2018 12:58:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06F871286E3 for ; Thu, 18 Oct 2018 12:58:29 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C69F1AE033A; Thu, 18 Oct 2018 21:58:27 +0200 (CEST)
Date: Thu, 18 Oct 2018 21:58:26 +0200 (CEST)
Message-Id: <20181018.215826.2271077466982765895.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: vladimir@transpacket.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 19:58:32 -0000

Andy Bierman  wrote:
> Hi,
> 
> I strongly agree that a new data type is needed (ypath1.0 or just ypath is
> fine)
> Adding new semantics or requirements to published data types is
> unacceptable.
> 
> Also, we must get the type and module containing the data type right on the
> first try.
> No moving it later because the import looks bad. That said, a "quick
> 6991-bis" is unrealistic,
> and a multi-year 6991-bis is unhelpful.
> 
> Should there be a canonical format, based on module-names as prefixes?
> Consider how to compare 2 values using this data type.

Ok.  So which alternative do you prefer for stream-xpath-filter, which
is supposed to work also for JSON?  The current definition doesn't
work for JSON.


/martin


> 
> 
> Andy
> 
> 
> On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> vladimir@transpacket.com> wrote:
> 
> > Hi,
> >
> > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > The proposed boilerplate description text that was not added to some RFC
> > modules like ietf-netconf-monitoring@2010-10-04.yang
> >
> > should be as consistent as possible (or skipped based on the
> > ietf-netconf-monitoring precedent) until a better alternative is available.
> > Here is an example of a better alternative.
> >
> >    typedef ypath1.0 {
> >     type xpath1.0;
> >     description
> >      "This type represents subset of XPATH 1.0 expressions
> >       that apply to a data tree conforming to a YANG model.
> >
> >       Each encoding should allow conversion to an encoding
> >       independent lexical representation where data node
> >       prefixes are resolved to and substituted with module
> >       names.
> >
> >       When a schema node is defined that uses this type, the
> >       description of the schema node MUST specify the
> >       context in which the expression is evaluated if it
> >       is different from the default context.
> >
> >       The default context is as follows:
> >
> >         o  The set of variable bindings is empty.
> >
> >         o  The function library is the core function library, and
> >            the XPath functions defined in section 10 in RFC 7950.
> >
> >         o  The context node is the leaf node.
> >
> >       ";
> >     reference
> >      "XPATH: XML Path Language (XPath) Version 1.0";
> >   }
> >
> > That said I do not object to short-term application of alternative A as
> > long as a long-term solution is on its way for future modules.
> >
> > Vladimir
> >
> > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> >
> >> Hi,
> >>
> >> Going back to the most urgent issue, what is this WG's recommendation
> >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> >> yang:xpath1.0 in filters?
> >>
> >> To summarize:
> >>
> >> We already have
> >>
> >>    o  instance-identifier in XML uses prefixes from the XML document
> >>    o  instance-identifier in JSON uses module names as prefixes
> >>    o  XPath in NETCONF filter uses prefixes from the XML document
> >>    o  XPath in JSON query filter uses module names as prefixes
> >>
> >>
> >> Alternative A:
> >> --------------
> >>
> >> Use different encodings for "stream-xpath-filter" as well, depending
> >> on if it is XML or JSON.
> >>
> >> We would do in SN:
> >>
> >>      o  If the node is encoded in XML, the set of namespace
> >>         declarations are those in scope on the
> >>         'stream-xpath-filter' leaf element.
> >>
> >>      o  If the node is encoded in JSON, the set of namespace
> >>         declarations is the set of prefix and namespace pairs
> >>         for all supported YANG modules, where the prefix is
> >>         the YANG module name and the namespace is as defined
> >>         by the "namespace" statement in the YANG module.
> >>
> >> Pro: the format is consistent within each encoding.
> >>
> >> Con: unclear how to handle other encodings.
> >> Con: we keep using context-depending encodings.
> >>
> >> We could probably add that CBOR uses the same representation as JSON.
> >>
> >> Example in XML:
> >>
> >>     >>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> >>      /if:interfaces/if:interface/ip:ipv4
> >>    
> >>
> >> Example in JSON:
> >>
> >>    "stream-xpath-filter":
> >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> >>
> >>
> >>
> >> Alternative B:
> >> --------------
> >>
> >> Use a non-context depending encoding, with the module name as prefix.
> >>
> >> We would do in SN:
> >>
> >>      o  The set of namespace
> >>         declarations is the set of prefix and namespace pairs
> >>         for all supported YANG modules, where the prefix is
> >>         the YANG module name and the namespace is as defined
> >>         by the "namespace" statement in the YANG module.
> >>
> >> Pro: the format is independent from the protocol encoding
> >>
> >> Con: in XML, this leaf is treated differently from other XPath
> >>       expressions, such as get-config filter and nacm rules.
> >>
> >> Example in XML:
> >>
> >>    
> >>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> >>    
> >>
> >> Example in JSON:
> >>
> >>    "stream-xpath-filter":
> >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> >>
> >>
> >> My proposal is A.  I think it is more important with consistency
> >> within each encoding than across encodings.
> >>
> >> (This said, I would like to have a context-independent encoding of all
> >> YANG types in the future.  But not now.)
> >>
> >>
> >>
> >>
> >> /martin
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >


From nobody Thu Oct 18 12:58:50 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6012F130E83 for ; Thu, 18 Oct 2018 12:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 X7fLuFAknyR3 for ; Thu, 18 Oct 2018 12:58:37 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B3EC4130E8A for ; Thu, 18 Oct 2018 12:58:36 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id n14-v6so11665557lfe.6 for ; Thu, 18 Oct 2018 12:58:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WA15ZMC1k3BlivLkhg1+rL7VuaeEMqB8fA4GHgJnCNA=; b=l5NfJ9cd6sv0AT27EbYNnfWdEybOfPPkcwkBPO+GJaxoVs/DwJIy0Q66bbq2OPm2nI ghhHCkQsmgT4hhSUIuUjbnpirzbWOzwskvi+vDwFw/KQzNMSK+7eo8nCo0rdLVM3/UwE 5rl2t1tbXVT1oWZ4jdFJI1eMUoi669Y4guCPX+zE74ei6MQK/orW51tXITGWjzfs8wos fnWajJ5QRCdS/wTlK3z0nO+93b3U4J/Ts5/GfAhMz/xT4Ly4VWNeBVkroe/qlzLnXQ+1 mtpXsFBPqZ0TylcP/lAV1OJRdTtMaDEtzklwl7nqaPUuZqHWPqY6ztk6n5hLaCQRzQ1p hnow==
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=WA15ZMC1k3BlivLkhg1+rL7VuaeEMqB8fA4GHgJnCNA=; b=RCVH8kJtPaOeoi3dAPqT65m7qK+31wH5iWKzrL0+tc9Q8zxEwxpddNCK20Veu9y8eX WwF5+DYdAQvHsWpOFCCEfJLXi9gBjVvyWrP4AHdGPqEf6HVAWf5AfwGr9PeLkMcLsHhr eItEu8RoJ1ndPOHTFwVAsvjy1Hcn0TMriVUSB8Rc192g4YVN2Hr9lZCYDP8KRaPmoi+8 FK+fGSS9tST6d32tHXhkXUG4Tl6Tws/mzUfyjYLQTXNFCybM+4qeBF6kWo5ktT37oyas NjuAe+JzLx1LHIYhzYTEbj41l2RjVA0OuyBWMc31xMrVxoPd9xn2OCZScK2TAqCiSz3S B47w==
X-Gm-Message-State: ABuFfogb1FD/SOX+eqcISgGCGZqw/w/uxLZQjff9vCF8+5lNJgcDmhm0 Op3402j4+sup3tSiOYfkcQ3vxygk1x6Oc5Omo1+/4g==
X-Google-Smtp-Source: ACcGV63kslgjRL+fsxMdb3SmWDOD6BNJgSrRtKsDnLlPATrShALMlhaE9GMtNCUTIEo1Y1AQ5MhzRyUuZHxrmTLHROo=
X-Received: by 2002:a19:2102:: with SMTP id h2-v6mr1003313lfh.119.1539892714620;  Thu, 18 Oct 2018 12:58:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d2d3:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 12:58:33 -0700 (PDT)
In-Reply-To: <20181018195041.qqm22qgscwoejlos@anna.jacobs.jacobs-university.de>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>  <20181018195041.qqm22qgscwoejlos@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Thu, 18 Oct 2018 12:58:33 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Vladimir Vassilev , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000003f9d2905788636a0"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 19:58:43 -0000

--0000000000003f9d2905788636a0
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
>
> > No moving it later because the import looks bad. That said, a "quick
> > 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.
>
> https://datatracker.ietf.org/doc/rfc6991/


Are you suggesting that because it only took  11 months last time we will
not keep adding "1 more thing" over and over for 24+ months (like some
other work items)?
If so, I hope you are right.



>
> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bier=
man wrote:



> No moving it later because the import looks bad. That said, a "qu=
ick

> 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.=




https://datatracker.ietf.org/doc/rfc6991/

Are you suggesting that because it only took =C2=A0=
11 months last time we will
not keep adding "1 more thing&qu=
ot; over and over for 24+ months (like some other work items)?
If=
 so, I hope you are right.






/js

Andy
=C2=A0=




-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--0000000000003f9d2905788636a0--


From nobody Thu Oct 18 13:28:55 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D4E130DEC for ; Thu, 18 Oct 2018 13:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 tdM9nR3VBqc3 for ; Thu, 18 Oct 2018 13:28:49 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 D81C6130E0F for ; Thu, 18 Oct 2018 13:28:48 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id l1-v6so3799717lfc.3 for ; Thu, 18 Oct 2018 13:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Bpmk/tRnQLwBtAsm9C4qM+HAiZ9sCrOMQFWNjUlO3s=; b=pRi5QZM6PDZv2J3YWNHoK/QIIwLDY7OTFeWmBjVPUArkGhHqvtdsc8ctoOedf7JWDA 7XscBZOkqobGiYNf11Exv6XyWfebjTi1K5QoXzOfjrfQpLH2F2UkuojUSyzKEMZX03qr 9E6kANlWyYtt2eGpLxj8h4hzP4ay7NfuRUEWOcRnQu5S+G3MNYDEPzF1PqfNPPXc7tnl Bo7inrt+dpf/LWtzs4+kQigFiVyMUI/03XGiBUt1SFqUABlbROSP2E5dGO1/uGhcb3u1 bfR0/BzmU7fmiy3DHklaNc/PnLpS4d3VgqHqX6aVSChypcfvsRo/x2q/9nzKkpWpkqkI py5g==
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=0Bpmk/tRnQLwBtAsm9C4qM+HAiZ9sCrOMQFWNjUlO3s=; b=bGT5B7HkTJcZL2JGzDaJQOHQvFWCF7t56gpJUhKn2qJj0pcEKOq90ThLf3g19a+6Hh 7AxQK/nZnC8bgvk1JUkGLJXF4p4fTjcui0Hp3ejThR6Vai3D7MU2Ee3l217LraAcYZ1a 6z96ZIS54ejnzuyokLbe1SO6562tG7gKxIofLiZW2LCrgdPNvOMGH91Jf25pVUg9zgGB A9FEcj3aM2Y3LmgGB/iwGxhKCfC8WYdCK51RWHl1KauCZ7zIxw3zwSS/vKfPHm/1x3jr nIqbwiV1drzkPtvFm5iZGEqkqMvG21LmkWLYchlc1zyjzbftgcir4c+XkO49hNB6Dywn ukpQ==
X-Gm-Message-State: ABuFfojdOTDiK4Y52fOm4KsirL6X/ryrlNq3NHImhOqxjRyXlbpzEqeq N9ohCaBk4ZJmBA8iCyPoBiiaexO3wY9NOmMmP/Otrg==
X-Google-Smtp-Source: ACcGV62M+c+gqVpiH+iAd5ucgc8OmomRuSulDHbJPGMIUEZqHK5eqi9VaaFYdSZ+hG8NU9ptdRSChRwIRcVPc64YOX0=
X-Received: by 2002:a19:771b:: with SMTP id s27-v6mr1133254lfc.84.1539894526662;  Thu, 18 Oct 2018 13:28:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 13:28:45 -0700 (PDT)
In-Reply-To: <20181018.215826.2271077466982765895.mbj@tail-f.com>
References: <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>  <20181018.215826.2271077466982765895.mbj@tail-f.com>
From: Andy Bierman 
Date: Thu, 18 Oct 2018 13:28:45 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Vladimir Vassilev , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000040fe30057886a237"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 20:28:53 -0000

--00000000000040fe30057886a237
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > Hi,
> >
> > I strongly agree that a new data type is needed (ypath1.0 or just ypath
> is
> > fine)
> > Adding new semantics or requirements to published data types is
> > unacceptable.
> >
> > Also, we must get the type and module containing the data type right on
> the
> > first try.
> > No moving it later because the import looks bad. That said, a "quick
> > 6991-bis" is unrealistic,
> > and a multi-year 6991-bis is unhelpful.
> >
> > Should there be a canonical format, based on module-names as prefixes?
> > Consider how to compare 2 values using this data type.
>
> Ok.  So which alternative do you prefer for stream-xpath-filter, which
> is supposed to work also for JSON?  The current definition doesn't
> work for JSON.
>
>

I don't like calling it xpath when it is not XPath any more.
It should be as clear as possible to readers and designers that xpath
means XPath and ypath is not XPath.

I would prefer a new encoding that allows the parent node module-name to be
used somehow,
consistent with the JSON encoding used now.

Perhaps each absolute-path expression starts with a module-name step and
relative-path
expressions assume the module name of the context node if there is no
module-name.

Neither alternative below is a good long-term solution.

The old problems come up again:

  Client A writes the /foo node in XML.
  Client B reads the /foo node returned in JSON

Which format is returned? Does the server magically convert the value for
each encoding type?
If we bother to fix this problem at all, then we should get rid of reliance
on prefix to namespace mappings.





> /martin
>
>

Andy


>
> >
> >
> > Andy
> >
> >
> > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > vladimir@transpacket.com> wrote:
> >
> > > Hi,
> > >
> > > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > > The proposed boilerplate description text that was not added to some
> RFC
> > > modules like ietf-netconf-monitoring@2010-10-04.yang
> > >
> > > should be as consistent as possible (or skipped based on the
> > > ietf-netconf-monitoring precedent) until a better alternative is
> available.
> > > Here is an example of a better alternative.
> > >
> > >    typedef ypath1.0 {
> > >     type xpath1.0;
> > >     description
> > >      "This type represents subset of XPATH 1.0 expressions
> > >       that apply to a data tree conforming to a YANG model.
> > >
> > >       Each encoding should allow conversion to an encoding
> > >       independent lexical representation where data node
> > >       prefixes are resolved to and substituted with module
> > >       names.
> > >
> > >       When a schema node is defined that uses this type, the
> > >       description of the schema node MUST specify the
> > >       context in which the expression is evaluated if it
> > >       is different from the default context.
> > >
> > >       The default context is as follows:
> > >
> > >         o  The set of variable bindings is empty.
> > >
> > >         o  The function library is the core function library, and
> > >            the XPath functions defined in section 10 in RFC 7950.
> > >
> > >         o  The context node is the leaf node.
> > >
> > >       ";
> > >     reference
> > >      "XPATH: XML Path Language (XPath) Version 1.0";
> > >   }
> > >
> > > That said I do not object to short-term application of alternative A as
> > > long as a long-term solution is on its way for future modules.
> > >
> > > Vladimir
> > >
> > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > >
> > >> Hi,
> > >>
> > >> Going back to the most urgent issue, what is this WG's recommendation
> > >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > >> yang:xpath1.0 in filters?
> > >>
> > >> To summarize:
> > >>
> > >> We already have
> > >>
> > >>    o  instance-identifier in XML uses prefixes from the XML document
> > >>    o  instance-identifier in JSON uses module names as prefixes
> > >>    o  XPath in NETCONF filter uses prefixes from the XML document
> > >>    o  XPath in JSON query filter uses module names as prefixes
> > >>
> > >>
> > >> Alternative A:
> > >> --------------
> > >>
> > >> Use different encodings for "stream-xpath-filter" as well, depending
> > >> on if it is XML or JSON.
> > >>
> > >> We would do in SN:
> > >>
> > >>      o  If the node is encoded in XML, the set of namespace
> > >>         declarations are those in scope on the
> > >>         'stream-xpath-filter' leaf element.
> > >>
> > >>      o  If the node is encoded in JSON, the set of namespace
> > >>         declarations is the set of prefix and namespace pairs
> > >>         for all supported YANG modules, where the prefix is
> > >>         the YANG module name and the namespace is as defined
> > >>         by the "namespace" statement in the YANG module.
> > >>
> > >> Pro: the format is consistent within each encoding.
> > >>
> > >> Con: unclear how to handle other encodings.
> > >> Con: we keep using context-depending encodings.
> > >>
> > >> We could probably add that CBOR uses the same representation as JSON.
> > >>
> > >> Example in XML:
> > >>
> > >>     > >>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > >>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > >>      /if:interfaces/if:interface/ip:ipv4
> > >>    
> > >>
> > >> Example in JSON:
> > >>
> > >>    "stream-xpath-filter":
> > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> ietf-ip:ipv4"
> > >>
> > >>
> > >>
> > >> Alternative B:
> > >> --------------
> > >>
> > >> Use a non-context depending encoding, with the module name as prefix.
> > >>
> > >> We would do in SN:
> > >>
> > >>      o  The set of namespace
> > >>         declarations is the set of prefix and namespace pairs
> > >>         for all supported YANG modules, where the prefix is
> > >>         the YANG module name and the namespace is as defined
> > >>         by the "namespace" statement in the YANG module.
> > >>
> > >> Pro: the format is independent from the protocol encoding
> > >>
> > >> Con: in XML, this leaf is treated differently from other XPath
> > >>       expressions, such as get-config filter and nacm rules.
> > >>
> > >> Example in XML:
> > >>
> > >>    
> > >>      /ietf-interfaces:interfaces/ietf-interfaces:interface/
> ietf-ip:ipv4
> > >>    
> > >>
> > >> Example in JSON:
> > >>
> > >>    "stream-xpath-filter":
> > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> ietf-ip:ipv4"
> > >>
> > >>
> > >> My proposal is A.  I think it is more important with consistency
> > >> within each encoding than across encodings.
> > >>
> > >> (This said, I would like to have a context-independent encoding of all
> > >> YANG types in the future.  But not now.)
> > >>
> > >>
> > >>
> > >>
> > >> /martin
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>

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




On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> Hi,

> 

> I strongly agree that a new data type is needed (ypath1.0 or just ypat=
h is

> fine)

> Adding new semantics or requirements to published data types is

> unacceptable.

> 

> Also, we must get the type and module containing the data type right o=
n the

> first try.

> No moving it later because the import looks bad. That said, a "qu=
ick

> 6991-bis" is unrealistic,

> and a multi-year 6991-bis is unhelpful.

> 

> Should there be a canonical format, based on module-names as prefixes?=


> Consider how to compare 2 values using this data type.



Ok.=C2=A0 So which alternative do you prefer for stream-xpath-filter, which=


is supposed to work also for JSON?=C2=A0 The current definition doesn't=


work for JSON.




I don't like callin=
g it xpath when it is not XPath any more.
It should be as clear a=
s possible to readers and designers that xpath
means XPath and yp=
ath is not XPath.

I would prefer a new encoding th=
at allows the parent node module-name to be used somehow,
consist=
ent with the JSON encoding used now.

Perhaps each =
absolute-path expression starts with a module-name step and relative-path
expressions assume the module name of the context node if there is=
 no module-name.

Neither alternative below is a go=
od long-term solution.

The old problems come up ag=
ain:

=C2=A0 Client A writes the /foo node in XML.<=
/div>
=C2=A0 Client B reads the /foo node returned in JSON
Which format is returned? Does the server magically convert th=
e value for each encoding type?
If we bother to fix this problem =
at all, then we should get rid of reliance on prefix to namespace mappings.=








/martin




Andy
=C2=A0



> 

> 

> Andy

> 

> 

> On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <

> vladimir@transpacket.com> wrote:

> 

> > Hi,

> >

> > Seems this discussion affects 10 draft modules using the xpath1.0=
 type.

> > The proposed boilerplate description text that was not added to s=
ome RFC

> > modules like ietf-netconf-monitoring@2010-10-04.yang

> >

> > should be as consistent as possible (or skipped based on the

> > ietf-netconf-monitoring precedent) until a better alternative is =
available.

> > Here is an example of a better alternative.

> >

> >=C2=A0 =C2=A0 typedef ypath1.0 {

> >=C2=A0 =C2=A0 =C2=A0type xpath1.0;

> >=C2=A0 =C2=A0 =C2=A0description

> >=C2=A0 =C2=A0 =C2=A0 "This type represents subset of XPATH 1.=
0 expressions

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that apply to a data tree conforming to=
 a YANG model.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Each encoding should allow conversion t=
o an encoding

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0independent lexical representation wher=
e data node

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes are resolved to and substitute=
d with module

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0names.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0When a schema node is defined that uses=
 this type, the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description of the schema node MUST spe=
cify the

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0context in which the expression is eval=
uated if it

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0is different from the default context.<=
br>
> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The default context is as follows:

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of variable bind=
ings is empty.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The function library is =
the core function library, and

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the XPath functions defi=
ned in section 10 in RFC 7950.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The context node is the =
leaf node.

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0";

> >=C2=A0 =C2=A0 =C2=A0reference

> >=C2=A0 =C2=A0 =C2=A0 "XPATH: XML Path Language (XPath) Versio=
n 1.0";

> >=C2=A0 =C2=A0}

> >

> > That said I do not object to short-term application of alternativ=
e A as

> > long as a long-term solution is on its way for future modules.
> >

> > Vladimir

> >

> > On 10/18/18 12:30 PM, Martin Bjorklund wrote:

> >

> >> Hi,

> >>

> >> Going back to the most urgent issue, what is this WG's re=
commendation

> >> for the subscribed-notifications draft in NETCONF wrt/ their =
usage of

> >> yang:xpath1.0 in filters?

> >>

> >> To summarize:

> >>

> >> We already have

> >>

> >>=C2=A0 =C2=A0 o=C2=A0 instance-identifier in XML uses prefixes=
 from the XML document

> >>=C2=A0 =C2=A0 o=C2=A0 instance-identifier in JSON uses module =
names as prefixes

> >>=C2=A0 =C2=A0 o=C2=A0 XPath in NETCONF filter uses prefixes fr=
om the XML document

> >>=C2=A0 =C2=A0 o=C2=A0 XPath in JSON query filter uses module n=
ames as prefixes

> >>

> >>

> >> Alternative A:

> >> --------------

> >>

> >> Use different encodings for "stream-xpath-filter" a=
s well, depending

> >> on if it is XML or JSON.

> >>

> >> We would do in SN:

> >>

> >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 If the node is encoded in XML, th=
e set of namespace

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations are those in sc=
ope on the

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'stream-xpath-filter'=
; leaf element.

> >>

> >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 If the node is encoded in JSON, t=
he set of namespace

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations is the set of p=
refix and namespace pairs

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for all supported YANG modul=
es, where the prefix is

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the YANG module name and the=
 namespace is as defined

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the "namespace"=
 statement in the YANG module.

> >>

> >> Pro: the format is consistent within each encoding.

> >>

> >> Con: unclear how to handle other encodings.

> >> Con: we keep using context-depending encodings.

> >>

> >> We could probably add that CBOR uses the same representation =
as JSON.

> >>

> >> Example in XML:

> >>

> >>=C2=A0 =C2=A0 <stream-xpath-filter

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:if=3D"urn:ietf:params:x=
ml:ns:yang:ietf-interfaces"

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:ip=3D"urn:ietf:params:x=
ml:ns:yang:ietf-ip">

> >>=C2=A0 =C2=A0 =C2=A0 /if:interfaces/if:interface/ip:ipv4<=
br>
> >>=C2=A0 =C2=A0 </stream-xpath-filter>

> >>

> >> Example in JSON:

> >>

> >>=C2=A0 =C2=A0 "stream-xpath-filter":

> >>=C2=A0 =C2=A0 =C2=A0 "/ietf-interfaces:interfaces/ie=
tf-interfaces:interface/ietf-ip:ipv4"

> >>

> >>

> >>

> >> Alternative B:

> >> --------------

> >>

> >> Use a non-context depending encoding, with the module name as=
 prefix.

> >>

> >> We would do in SN:

> >>

> >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The set of namespace

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations is the set of p=
refix and namespace pairs

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for all supported YANG modul=
es, where the prefix is

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the YANG module name and the=
 namespace is as defined

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the "namespace"=
 statement in the YANG module.

> >>

> >> Pro: the format is independent from the protocol encoding

> >>

> >> Con: in XML, this leaf is treated differently from other XPat=
h

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0expressions, such as get-config fil=
ter and nacm rules.

> >>

> >> Example in XML:

> >>

> >>=C2=A0 =C2=A0 <stream-xpath-filter>

> >>=C2=A0 =C2=A0 =C2=A0 /ietf-interfaces:interfaces/ietf-int=
erfaces:interface/ietf-ip:ipv4

> >>=C2=A0 =C2=A0 </stream-xpath-filter>

> >>

> >> Example in JSON:

> >>

> >>=C2=A0 =C2=A0 "stream-xpath-filter":

> >>=C2=A0 =C2=A0 =C2=A0 "/ietf-interfaces:interfaces/ie=
tf-interfaces:interface/ietf-ip:ipv4"

> >>

> >>

> >> My proposal is A.=C2=A0 I think it is more important with con=
sistency

> >> within each encoding than across encodings.

> >>

> >> (This said, I would like to have a context-independent encodi=
ng of all

> >> YANG types in the future.=C2=A0 But not now.)

> >>

> >>

> >>

> >>

> >> /martin

> >>

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@ietf.org

> >> https://www.ietf.org/mailman/listinf=
o/netmod

> >>

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

> >





--00000000000040fe30057886a237--


From nobody Thu Oct 18 13:31:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5217A130E1B for ; Thu, 18 Oct 2018 13:31: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 QgOXzRYJZZk7 for ; Thu, 18 Oct 2018 13:31:39 -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 29006130E19 for ; Thu, 18 Oct 2018 13:31: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 CE701BBD; Thu, 18 Oct 2018 22:31:37 +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 MJdqPUQI9qKQ; Thu, 18 Oct 2018 22:31:36 +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; Thu, 18 Oct 2018 22:31:37 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B815F20037; Thu, 18 Oct 2018 22:31:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HXYObcByYRA0; Thu, 18 Oct 2018 22:31:36 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id DB68120036; Thu, 18 Oct 2018 22:31:36 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Thu, 18 Oct 2018 22:29:40 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 6FA7830026183B; Thu, 18 Oct 2018 22:31:34 +0200 (CEST)
Date: Thu, 18 Oct 2018 22:31:34 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: Vladimir Vassilev , NetMod WG 
Message-ID: <20181018203134.kpz2azdxlktowlk4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Vladimir Vassilev , NetMod WG 
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>  <20181018195041.qqm22qgscwoejlos@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 20:31:41 -0000

On Thu, Oct 18, 2018 at 12:58:33PM -0700, Andy Bierman wrote:
> On Thu, Oct 18, 2018 at 12:50 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, Oct 18, 2018 at 12:45:44PM -0700, Andy Bierman wrote:
> >
> > > No moving it later because the import looks bad. That said, a "quick
> > > 6991-bis" is unrealistic, and a multi-year 6991-bis is unhelpful.
> >
> > https://datatracker.ietf.org/doc/rfc6991/
> 
> Are you suggesting that because it only took  11 months last time we will
> not keep adding "1 more thing" over and over for 24+ months (like some
> other work items)?

There is no guarantee but as long as we start with the assumption that
what we do will be slow, we should not be surprised that things are
actually slow. ;-)

/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 Thu Oct 18 13:32:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4705A130E21 for ; Thu, 18 Oct 2018 13:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSE2LfbrVgEn for ; Thu, 18 Oct 2018 13:32:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00851130E1B for ; Thu, 18 Oct 2018 13:32:49 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 1CAC81AE033A; Thu, 18 Oct 2018 22:32:49 +0200 (CEST)
Date: Thu, 18 Oct 2018 22:32:48 +0200 (CEST)
Message-Id: <20181018.223248.2170782709410525886.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: vladimir@transpacket.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181018.215826.2271077466982765895.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 20:32:53 -0000

Andy Bierman  wrote:
> On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > I strongly agree that a new data type is needed (ypath1.0 or just ypath
> > is
> > > fine)
> > > Adding new semantics or requirements to published data types is
> > > unacceptable.
> > >
> > > Also, we must get the type and module containing the data type right on
> > the
> > > first try.
> > > No moving it later because the import looks bad. That said, a "quick
> > > 6991-bis" is unrealistic,
> > > and a multi-year 6991-bis is unhelpful.
> > >
> > > Should there be a canonical format, based on module-names as prefixes?
> > > Consider how to compare 2 values using this data type.
> >
> > Ok.  So which alternative do you prefer for stream-xpath-filter, which
> > is supposed to work also for JSON?  The current definition doesn't
> > work for JSON.
> >
> >
> 
> I don't like calling it xpath when it is not XPath any more.

But stream-xpath-filter *is* XPath.  The alternative solutions differ
only in how the prefix mapping is defined.

> It should be as clear as possible to readers and designers that xpath
> means XPath and ypath is not XPath.
> 
> I would prefer a new encoding that allows the parent node module-name to be
> used somehow,
> consistent with the JSON encoding used now.
> 
> Perhaps each absolute-path expression starts with a module-name step and
> relative-path
> expressions assume the module name of the context node if there is no
> module-name.
> 
> Neither alternative below is a good long-term solution.

Agreed, but we need to find a solution for stream-xpath-filter, or
else we should remove it from SN.

> The old problems come up again:
> 
>   Client A writes the /foo node in XML.
>   Client B reads the /foo node returned in JSON
> 
> Which format is returned? Does the server magically convert the value for
> each encoding type?

Yes, just like it does with i-i and identityref.

> If we bother to fix this problem at all, then we should get rid of reliance
> on prefix to namespace mappings.

Long-term, yes!


/martin


> 
> 
> 
> 
> 
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > >
> > > Andy
> > >
> > >
> > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > vladimir@transpacket.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Seems this discussion affects 10 draft modules using the xpath1.0 type.
> > > > The proposed boilerplate description text that was not added to some
> > RFC
> > > > modules like ietf-netconf-monitoring@2010-10-04.yang
> > > >
> > > > should be as consistent as possible (or skipped based on the
> > > > ietf-netconf-monitoring precedent) until a better alternative is
> > available.
> > > > Here is an example of a better alternative.
> > > >
> > > >    typedef ypath1.0 {
> > > >     type xpath1.0;
> > > >     description
> > > >      "This type represents subset of XPATH 1.0 expressions
> > > >       that apply to a data tree conforming to a YANG model.
> > > >
> > > >       Each encoding should allow conversion to an encoding
> > > >       independent lexical representation where data node
> > > >       prefixes are resolved to and substituted with module
> > > >       names.
> > > >
> > > >       When a schema node is defined that uses this type, the
> > > >       description of the schema node MUST specify the
> > > >       context in which the expression is evaluated if it
> > > >       is different from the default context.
> > > >
> > > >       The default context is as follows:
> > > >
> > > >         o  The set of variable bindings is empty.
> > > >
> > > >         o  The function library is the core function library, and
> > > >            the XPath functions defined in section 10 in RFC 7950.
> > > >
> > > >         o  The context node is the leaf node.
> > > >
> > > >       ";
> > > >     reference
> > > >      "XPATH: XML Path Language (XPath) Version 1.0";
> > > >   }
> > > >
> > > > That said I do not object to short-term application of alternative A as
> > > > long as a long-term solution is on its way for future modules.
> > > >
> > > > Vladimir
> > > >
> > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Going back to the most urgent issue, what is this WG's recommendation
> > > >> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > > >> yang:xpath1.0 in filters?
> > > >>
> > > >> To summarize:
> > > >>
> > > >> We already have
> > > >>
> > > >>    o  instance-identifier in XML uses prefixes from the XML document
> > > >>    o  instance-identifier in JSON uses module names as prefixes
> > > >>    o  XPath in NETCONF filter uses prefixes from the XML document
> > > >>    o  XPath in JSON query filter uses module names as prefixes
> > > >>
> > > >>
> > > >> Alternative A:
> > > >> --------------
> > > >>
> > > >> Use different encodings for "stream-xpath-filter" as well, depending
> > > >> on if it is XML or JSON.
> > > >>
> > > >> We would do in SN:
> > > >>
> > > >>      o  If the node is encoded in XML, the set of namespace
> > > >>         declarations are those in scope on the
> > > >>         'stream-xpath-filter' leaf element.
> > > >>
> > > >>      o  If the node is encoded in JSON, the set of namespace
> > > >>         declarations is the set of prefix and namespace pairs
> > > >>         for all supported YANG modules, where the prefix is
> > > >>         the YANG module name and the namespace is as defined
> > > >>         by the "namespace" statement in the YANG module.
> > > >>
> > > >> Pro: the format is consistent within each encoding.
> > > >>
> > > >> Con: unclear how to handle other encodings.
> > > >> Con: we keep using context-depending encodings.
> > > >>
> > > >> We could probably add that CBOR uses the same representation as JSON.
> > > >>
> > > >> Example in XML:
> > > >>
> > > >>     > > >>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > > >>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > > >>      /if:interfaces/if:interface/ip:ipv4
> > > >>    
> > > >>
> > > >> Example in JSON:
> > > >>
> > > >>    "stream-xpath-filter":
> > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4"
> > > >>
> > > >>
> > > >>
> > > >> Alternative B:
> > > >> --------------
> > > >>
> > > >> Use a non-context depending encoding, with the module name as prefix.
> > > >>
> > > >> We would do in SN:
> > > >>
> > > >>      o  The set of namespace
> > > >>         declarations is the set of prefix and namespace pairs
> > > >>         for all supported YANG modules, where the prefix is
> > > >>         the YANG module name and the namespace is as defined
> > > >>         by the "namespace" statement in the YANG module.
> > > >>
> > > >> Pro: the format is independent from the protocol encoding
> > > >>
> > > >> Con: in XML, this leaf is treated differently from other XPath
> > > >>       expressions, such as get-config filter and nacm rules.
> > > >>
> > > >> Example in XML:
> > > >>
> > > >>    
> > > >>      /ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4
> > > >>    
> > > >>
> > > >> Example in JSON:
> > > >>
> > > >>    "stream-xpath-filter":
> > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > ietf-ip:ipv4"
> > > >>
> > > >>
> > > >> My proposal is A.  I think it is more important with consistency
> > > >> within each encoding than across encodings.
> > > >>
> > > >> (This said, I would like to have a context-independent encoding of all
> > > >> YANG types in the future.  But not now.)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> /martin
> > > >>
> > > >> _______________________________________________
> > > >> netmod mailing list
> > > >> netmod@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > >>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> >


From nobody Thu Oct 18 13:42:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6C3130E22 for ; Thu, 18 Oct 2018 13:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level: 
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6tf0WjqVpO3 for ; Thu, 18 Oct 2018 13:42:41 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 EED6D130DD0 for ; Thu, 18 Oct 2018 13:42:40 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9IKZ9mH008279 for ; Thu, 18 Oct 2018 13:42:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=vfuVzLxLwDwkXavU4Oz8XIQLGo5UKjICogqjhgLm5Qc=; b=ldIOYxIokX0VrBSXD+g+g+nBRC3lXHY4JYrB3k0ihdCMZSjXrrVqQieLBLP8AzUhOQCu LkdA5zlpuQzdoIOJTYrvwgGRYTl+ZRLyFKLDVAxBp7U9LEPHEovprirovf0OI9qQMXyC H7p2d59mo5dz4uYWyzAOujD70EodY/qxc/6jI1/ceAjmwOv3/A8YoF7sW4b/ikLJQ12I UJ7kTL3JESrhiSqnJewRRf3Fbe0/2SF5KO9qWZn9HOCF+0rwfZXqGem/bwmABfHNDVmN 9Wg+J7wQHNd5NLWWtrzWAecKiFLizdvLVPzK/AqXuj6k6tJQthm/yYNLurhyJQLgy1Rc rw== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0180.outbound.protection.outlook.com [216.32.180.180]) by mx0a-00273201.pphosted.com with ESMTP id 2n6yh986vv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 18 Oct 2018 13:42:40 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5691.namprd05.prod.outlook.com (20.178.24.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Thu, 18 Oct 2018 20:42:37 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%4]) with mapi id 15.20.1250.020; Thu, 18 Oct 2018 20:42:37 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
Thread-Index: AQHUZyMbFOAyAfEluEavLs3BrdOyuw==
Date: Thu, 18 Oct 2018 20:42:37 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5691; 6:mDzQuZinJiO0HI13ef2ZDKhyrDpSKgK19fG7zSQXgB0hHWU785touS0slZvArYYuP65Vu+e3LtFoJ4LvRBwE1z32z6dCsl2dg8vnHqg+jBSsQ6GH65oP0PiCPWVuVtsyHf0h4aLNHqghGuYDJehu2RqZrVUI90KfkFC2KUGEd8T+o9HZzuBpRzW/pogIyxw01Pk18I4nnKKEZrp9xmHGO79/akVve4nDxmrVDJskpaUt8PpoxMnLnVjTHBkO4y8JeZRGRxAURoIppqiN6is9ABKQ3GOC7iR0epvYGW6KI2/lkowoBVGwmbN4Y4f2/cq9E0S81OHhA9hpWSTfY71DRB0O64fu/NT6Ai/W5mOdwWHmEolDP/xBUjqVyn34aAIdxRDYppKo64g1An2DYp2oJB0FQdn5QMZpBDJWEw4lkGiIoVN16Ha0gbS79qQ0iLwVmo/5LHl/UuFBbZdsg2WhwA==; 5:Tq1IJdq//fFyioezG4H6spjmoAmAV4Pe+bdZHiwCFEu09pcoFpLrI448nJKkm58ufBHhnJRINutSbHaKcaqfRFwyonf/iPCJyye/6DQguViUXB3SezcWeBdPTXIQsPS9rEGWXP9Uf8tzoumS+vUlQGw6HoQd4fNlzZnbc4c64LM=; 7:oZbqMP1otIiXQZV8uwGq68faALw/wVwhtZajcXtU5hWYFMg4QN+w/R5dszIT5o3+C2HTY3UV9uQK/dr1tI+G7gaR7z6v5QHsZL3CVZ2ZRIi2mThH3YPUq8nuzKOnRXC3B/cR0bVqHYn6H2rZ+HoZ0kr7Sb9UOoW6w1c50aguW1kROY8eDUe91dP1cFtqy++ADEVBAaXIhEXUITEJtuMvj1iic5+ZNa+PLRS4NtBqlBU9AaVyQNCOlFK+cFqVn5up
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: cb147b8c-7ed3-4491-7619-08d6353a3da4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5691; 
x-ms-traffictypediagnostic: DM6PR05MB5691:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5691; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5691; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(13464003)(97736004)(5640700003)(99286004)(105586002)(5250100002)(58126008)(2501003)(2900100001)(6506007)(476003)(26005)(478600001)(53546011)(102836004)(305945005)(256004)(106356001)(33656002)(14444005)(186003)(7736002)(6116002)(3846002)(486006)(229853002)(316002)(5660300001)(82746002)(36756003)(66066001)(2616005)(575784001)(68736007)(2351001)(86362001)(6486002)(14454004)(1730700003)(81166006)(8676002)(81156014)(8936002)(71190400001)(71200400001)(6306002)(83716004)(2906002)(6512007)(966005)(6436002)(6246003)(53936002)(25786009)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5691; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fn77FjawbOlFp3mk41pCsP832FwwIRpSCuW8aNskB1xCQjWgzRwwI4V/ZWn6Fv04No+0v454O7Mp+BPyZq8a/8Q63KBBpj1O6kapUC+2vh+3AEbcb7SgBOnFyO+T1VTwktIOVGEIGewjxZaQEmywTR68Ry3I3ITXEU2v0cvTAMapylfCAgQQlpVxv2q8zY1oUD20Bgvs65heEBWyem9ktz0aBiA1XJTPtcNihUnPt3ZZc2P+FeSXYN6Up3aktl6sx89t7RJKZoIsmpENlnzsSP1xu7HHfQ3OsKDdfYEWfFSW1yD7RNCZJ5QnpDY6enSkZeJSJRlMYK5DuERuBPIPde/u62cZEBV3pf+2gSV0T5o=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <303E5E78B99B174E93B597F8589D5425@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cb147b8c-7ed3-4491-7619-08d6353a3da4
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2018 20:42:37.6973 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5691
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180173
Archived-At: 
Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 20:42:43 -0000

VGhpcyBtZXNzYWdlIGNvbmNsdWRlcyB0aGUgc3VjY2Vzc2Z1bCBhZG9wdGlvbiBvZiBkcmFmdC1j
bGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAwLiAgDQoNCkF1dGhvcnMsIHBsZWFzZSByZXN1Ym1pdCB0
aGlzIGRyYWZ0LCB1bmNoYW5nZWQsIG90aGVyIHRoYW4gdG8gcmVuYW1lIGl0IGFzIGRyYWZ0LWll
dGYtbmV0bW9kLW5tZGEtZGlmZi0wMC4NCg0KQXMgaXMgZ2VuZXJhbGx5IHRoZSBjYXNlLCB0aGlz
IGFwcHJvdmFsIHNpZ25hbHMgdGhhdCB0aGUgd29ya2luZyBncm91cCBpcyB3aWxsaW5nIHRvIHdv
cmsgb24gdGhlIHByb2JsZW0sIG5vdCB0aGF0IHRoZSBzcGVjaWZpYyBzb2x1dGlvbiBkZXNjcmli
ZWQgaW4gdGhlIGlzIGl0c2VsZiBhcHByb3ZlZC4gIEluIHBhcnRpY3VsYXIsIHRoZSBjaGFpcnMg
cmVxdWVzdCB0aGF0IHRoZSB1c2UgY2FzZXMgYXJlIHJlZXhhbWluZWQgaW4gb3JkZXIgdG8gZGV0
ZXJtaW5lIHdoYXQgZm9ybWF0IGFuZC9vciBmb3JtYXRzIGFyZSBuZWVkZWQgYW5kLCBpZiBtb3Jl
IHRoYW4gb25lLCB3aGljaCBpcyB0aGUgZGVmYXVsdC4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIExv
dSBhbmQgSm9lbCkNCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0
bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIDxr
d2F0c2VuQGp1bmlwZXIubmV0Pg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDEsIDIwMTggYXQgMjo0
OCBQTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb
bmV0bW9kXSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZm
LTAwDQoNClRoZSBJRVRGIDEwMiBpbi1yb29tIHBvbGwgc2hvdWxkIHJlYWxseSBnb29kIHN1cHBv
cnQgdG8gYWRvcHQNCnRoaXMgZHJhZnQsIGFuZCBubyBvYmplY3Rpb25zLg0KDQpUaGlzIGVtYWls
IHN0YXJ0cyBhbiBhZG9wdGlvbiBwb2xsIGZvcjoNCg0KICBodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQt
MkRjbGVtbS0yRG5ldG1vZC0yRG5tZGEtMkRkaWZmLTJEMDAmZD1Ed0lDQWcmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ
aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWdzS2VySy1Eam9rNmxUTDBBOFNtOFBhU0pwNkZpUjBT
MTU0UTRuZ3hpbmcmcz11ODhQOEk4MXpzaW1LZ0JUWmc2ckplU0pCTVI4ZGstRHNoRnV1ZWhCa1ZN
JmU9DQoNClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBh
ZG9wdGlvbiBwb2xsLiANCklmIG9iamVjdGluZywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucyBv
biB0aGlzIHRocmVhZC4NCg0KS2VudCAoYW5kIExvdSBhbmQgSm9lbCkNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QN
Cm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lD
QWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4
bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWdzS2VySy1Eam9rNmxUTDBB
OFNtOFBhU0pwNkZpUjBTMTU0UTRuZ3hpbmcmcz1QU09NSFJQU1ZVWkhMQmxGZGhteFdqd1JjNFZI
RzQ1ay12aDJjSkpqcUk4JmU9DQoNCg==


From nobody Thu Oct 18 14:05:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27B8130E19 for ; Thu, 18 Oct 2018 14:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 WFc82EcXbtKp for ; Thu, 18 Oct 2018 14:05:32 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BD212F1AC for ; Thu, 18 Oct 2018 14:05:31 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id j17-v6so29030033lja.1 for ; Thu, 18 Oct 2018 14:05:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9MPtxdUNieloSa4HliUC3CR2lYJRsdAGVbr24xVqfZg=; b=tszmA+G3CqaPMK/CW0HLdZr8rUz/clQ7I+qLPX42aL7p+qgXbSf6ykxb6g6MYXZeAF jZo8dWCQ0vp01KF32tZdKlRmA+Qte+TMbi3czqnAc1MMAf47OFy1MVRIrUk4se4Fnl/h 1qNkAIwwYVkTSX3Xx3HLjv9k9ifGTazuo07BnFsVDiuap+WLaawLk6Tu+9ld3G+u0pv6 r4YGuWwy+fkUfN+Exl8/qCFoI8e5Im5zqVCyBcF9eQDI/PWwhvkbZTa5okBuLNfcFKNK BnqwlHca5VhEWkAdLltXP2aUWCiyIvfINpdRW1tWu9mZtMrEgdAHaCinBKGLOaa/rNFg liKg==
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=9MPtxdUNieloSa4HliUC3CR2lYJRsdAGVbr24xVqfZg=; b=OFpJxYSev2FnxSJQMjr3/EupeVnVi0AQmeUPeoeMT8cMF6cROrUhr/gdTnV9Z7T/Y2 569E7gIxacFwlKPibdJ1AsiX+Hx8mX5LK+eqOnhED2MpfUsrihnlfmoRIMykcqQV7KoZ 0GFube3scxknHxLhhHtb6Poy82MBukmAXe7dOrF0fF9rEfLZgbXPwR6Q6u6QqTLFqHgx jLk4+E+xe++HJ1R6wh9/mMBur2pCd1EFfZRSN/LbDhGMCbZpO9+zJu79nXLyG6F6os7P Qw387O3Iu2oLMpUApuoQBnLoMdWIZ74D969WdT/J5w/K7bG0fUGtvNweHepKzw29F9aq gUfw==
X-Gm-Message-State: ABuFfoh9kIK7JDfOLZUA5f0i+V4ys6jbmUnmH9TkII7vc/S3RNolIH60 mRmVGz8DK5TeHgd+WppVz1AoeuhBtlRTAFO/OaIU1J8I
X-Google-Smtp-Source: ACcGV635gID0ry4qnx3ukM7YQtbYZYK2VxxuMTWyw1K2M3ndiK9xkK8omNsoN4FWHjvvqxB0GwU6HhtJ48AYPy3OXHo=
X-Received: by 2002:a2e:9796:: with SMTP id y22-v6mr8467119lji.20.1539896729417;  Thu, 18 Oct 2018 14:05:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 14:05:28 -0700 (PDT)
In-Reply-To: <20181018.223248.2170782709410525886.mbj@tail-f.com>
References:  <20181018.215826.2271077466982765895.mbj@tail-f.com>  <20181018.223248.2170782709410525886.mbj@tail-f.com>
From: Andy Bierman 
Date: Thu, 18 Oct 2018 14:05:28 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Vladimir Vassilev , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000008c54360578872532"
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 21:05:35 -0000

--0000000000008c54360578872532
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund 
> wrote:
> >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > I strongly agree that a new data type is needed (ypath1.0 or just
> ypath
> > > is
> > > > fine)
> > > > Adding new semantics or requirements to published data types is
> > > > unacceptable.
> > > >
> > > > Also, we must get the type and module containing the data type right
> on
> > > the
> > > > first try.
> > > > No moving it later because the import looks bad. That said, a "quick
> > > > 6991-bis" is unrealistic,
> > > > and a multi-year 6991-bis is unhelpful.
> > > >
> > > > Should there be a canonical format, based on module-names as
> prefixes?
> > > > Consider how to compare 2 values using this data type.
> > >
> > > Ok.  So which alternative do you prefer for stream-xpath-filter, which
> > > is supposed to work also for JSON?  The current definition doesn't
> > > work for JSON.
> > >
> > >
> >
> > I don't like calling it xpath when it is not XPath any more.
>
> But stream-xpath-filter *is* XPath.  The alternative solutions differ
> only in how the prefix mapping is defined.
>


I don't think it should be called XPath if module-names are used as
prefixes.
Alternative A using a special data type is the least objectionable I guess


Andy


> > It should be as clear as possible to readers and designers that xpath
> > means XPath and ypath is not XPath.
> >
> > I would prefer a new encoding that allows the parent node module-name to
> be
> > used somehow,
> > consistent with the JSON encoding used now.
> >
> > Perhaps each absolute-path expression starts with a module-name step and
> > relative-path
> > expressions assume the module name of the context node if there is no
> > module-name.
> >
> > Neither alternative below is a good long-term solution.
>
> Agreed, but we need to find a solution for stream-xpath-filter, or
> else we should remove it from SN.
>
> > The old problems come up again:
> >
> >   Client A writes the /foo node in XML.
> >   Client B reads the /foo node returned in JSON
> >
> > Which format is returned? Does the server magically convert the value for
> > each encoding type?
>
> Yes, just like it does with i-i and identityref.
>
> > If we bother to fix this problem at all, then we should get rid of
> reliance
> > on prefix to namespace mappings.
>
> Long-term, yes!
>
>
> /martin
>
>
> >
> >
> >
> >
> >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
> > > > vladimir@transpacket.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Seems this discussion affects 10 draft modules using the xpath1.0
> type.
> > > > > The proposed boilerplate description text that was not added to
> some
> > > RFC
> > > > > modules like ietf-netconf-monitoring@2010-10-04.yang
> > > > >
> > > > > should be as consistent as possible (or skipped based on the
> > > > > ietf-netconf-monitoring precedent) until a better alternative is
> > > available.
> > > > > Here is an example of a better alternative.
> > > > >
> > > > >    typedef ypath1.0 {
> > > > >     type xpath1.0;
> > > > >     description
> > > > >      "This type represents subset of XPATH 1.0 expressions
> > > > >       that apply to a data tree conforming to a YANG model.
> > > > >
> > > > >       Each encoding should allow conversion to an encoding
> > > > >       independent lexical representation where data node
> > > > >       prefixes are resolved to and substituted with module
> > > > >       names.
> > > > >
> > > > >       When a schema node is defined that uses this type, the
> > > > >       description of the schema node MUST specify the
> > > > >       context in which the expression is evaluated if it
> > > > >       is different from the default context.
> > > > >
> > > > >       The default context is as follows:
> > > > >
> > > > >         o  The set of variable bindings is empty.
> > > > >
> > > > >         o  The function library is the core function library, and
> > > > >            the XPath functions defined in section 10 in RFC 7950.
> > > > >
> > > > >         o  The context node is the leaf node.
> > > > >
> > > > >       ";
> > > > >     reference
> > > > >      "XPATH: XML Path Language (XPath) Version 1.0";
> > > > >   }
> > > > >
> > > > > That said I do not object to short-term application of alternative
> A as
> > > > > long as a long-term solution is on its way for future modules.
> > > > >
> > > > > Vladimir
> > > > >
> > > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Going back to the most urgent issue, what is this WG's
> recommendation
> > > > >> for the subscribed-notifications draft in NETCONF wrt/ their
> usage of
> > > > >> yang:xpath1.0 in filters?
> > > > >>
> > > > >> To summarize:
> > > > >>
> > > > >> We already have
> > > > >>
> > > > >>    o  instance-identifier in XML uses prefixes from the XML
> document
> > > > >>    o  instance-identifier in JSON uses module names as prefixes
> > > > >>    o  XPath in NETCONF filter uses prefixes from the XML document
> > > > >>    o  XPath in JSON query filter uses module names as prefixes
> > > > >>
> > > > >>
> > > > >> Alternative A:
> > > > >> --------------
> > > > >>
> > > > >> Use different encodings for "stream-xpath-filter" as well,
> depending
> > > > >> on if it is XML or JSON.
> > > > >>
> > > > >> We would do in SN:
> > > > >>
> > > > >>      o  If the node is encoded in XML, the set of namespace
> > > > >>         declarations are those in scope on the
> > > > >>         'stream-xpath-filter' leaf element.
> > > > >>
> > > > >>      o  If the node is encoded in JSON, the set of namespace
> > > > >>         declarations is the set of prefix and namespace pairs
> > > > >>         for all supported YANG modules, where the prefix is
> > > > >>         the YANG module name and the namespace is as defined
> > > > >>         by the "namespace" statement in the YANG module.
> > > > >>
> > > > >> Pro: the format is consistent within each encoding.
> > > > >>
> > > > >> Con: unclear how to handle other encodings.
> > > > >> Con: we keep using context-depending encodings.
> > > > >>
> > > > >> We could probably add that CBOR uses the same representation as
> JSON.
> > > > >>
> > > > >> Example in XML:
> > > > >>
> > > > >>     > > > >>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > > > >>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > > > >>      /if:interfaces/if:interface/ip:ipv4
> > > > >>    
> > > > >>
> > > > >> Example in JSON:
> > > > >>
> > > > >>    "stream-xpath-filter":
> > > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > > ietf-ip:ipv4"
> > > > >>
> > > > >>
> > > > >>
> > > > >> Alternative B:
> > > > >> --------------
> > > > >>
> > > > >> Use a non-context depending encoding, with the module name as
> prefix.
> > > > >>
> > > > >> We would do in SN:
> > > > >>
> > > > >>      o  The set of namespace
> > > > >>         declarations is the set of prefix and namespace pairs
> > > > >>         for all supported YANG modules, where the prefix is
> > > > >>         the YANG module name and the namespace is as defined
> > > > >>         by the "namespace" statement in the YANG module.
> > > > >>
> > > > >> Pro: the format is independent from the protocol encoding
> > > > >>
> > > > >> Con: in XML, this leaf is treated differently from other XPath
> > > > >>       expressions, such as get-config filter and nacm rules.
> > > > >>
> > > > >> Example in XML:
> > > > >>
> > > > >>    
> > > > >>      /ietf-interfaces:interfaces/ietf-interfaces:interface/
> > > ietf-ip:ipv4
> > > > >>    
> > > > >>
> > > > >> Example in JSON:
> > > > >>
> > > > >>    "stream-xpath-filter":
> > > > >>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/
> > > ietf-ip:ipv4"
> > > > >>
> > > > >>
> > > > >> My proposal is A.  I think it is more important with consistency
> > > > >> within each encoding than across encodings.
> > > > >>
> > > > >> (This said, I would like to have a context-independent encoding
> of all
> > > > >> YANG types in the future.  But not now.)
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> /martin
> > > > >>
> > > > >> _______________________________________________
> > > > >> netmod mailing list
> > > > >> netmod@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > > >>
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > >
>

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




On Thu, Oct 18, 2018 at 1:32 PM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Thu, Oct 18, 2018 at 12:58 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> 

> > Andy Bierman <andy@yumaw=
orks.com> wrote:

> > > Hi,

> > >

> > > I strongly agree that a new data type is needed (ypath1.0 or=
 just ypath

> > is

> > > fine)

> > > Adding new semantics or requirements to published data types=
 is

> > > unacceptable.

> > >

> > > Also, we must get the type and module containing the data ty=
pe right on

> > the

> > > first try.

> > > No moving it later because the import looks bad. That said, =
a "quick

> > > 6991-bis" is unrealistic,

> > > and a multi-year 6991-bis is unhelpful.

> > >

> > > Should there be a canonical format, based on module-names as=
 prefixes?

> > > Consider how to compare 2 values using this data type.

> >

> > Ok.=C2=A0 So which alternative do you prefer for stream-xpath-fil=
ter, which

> > is supposed to work also for JSON?=C2=A0 The current definition d=
oesn't

> > work for JSON.

> >

> >

> 

> I don't like calling it xpath when it is not XPath any more.



But stream-xpath-filter *is* XPath.=C2=A0 The alternative solutions differ<=
br>
only in how the prefix mapping is defined.

<=
div>
I don't think it should be called XPath if module-na=
mes are used as prefixes.
Alternative A using a special data type=
 is the least objectionable I guess


Andy




> It should be as clear as possible to readers and designers that xpath<=
br>
> means XPath and ypath is not XPath.

> 

> I would prefer a new encoding that allows the parent node module-name =
to be

> used somehow,

> consistent with the JSON encoding used now.

> 

> Perhaps each absolute-path expression starts with a module-name step a=
nd

> relative-path

> expressions assume the module name of the context node if there is no<=
br>
> module-name.

> 

> Neither alternative below is a good long-term solution.



Agreed, but we need to find a solution for stream-xpath-filter, or

else we should remove it from SN.



> The old problems come up again:

> 

>=C2=A0 =C2=A0Client A writes the /foo node in XML.

>=C2=A0 =C2=A0Client B reads the /foo node returned in JSON

> 

> Which format is returned? Does the server magically convert the value =
for

> each encoding type?



Yes, just like it does with i-i and identityref.



> If we bother to fix this problem at all, then we should get rid of rel=
iance

> on prefix to namespace mappings.



Long-term, yes!





/martin





> 

> 

> 

> 

> 

> > /martin

> >

> >

> 

> Andy

> 

> 

> >

> > >

> > >

> > > Andy

> > >

> > >

> > > On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <

> > > vladimir@transpa=
cket.com> wrote:

> > >

> > > > Hi,

> > > >

> > > > Seems this discussion affects 10 draft modules using th=
e xpath1.0 type.

> > > > The proposed boilerplate description text that was not =
added to some

> > RFC

> > > > modules like ietf-netconf-monitoring@2010-10-04.ya=
ng

> > > >

> > > > should be as consistent as possible (or skipped based o=
n the

> > > > ietf-netconf-monitoring precedent) until a better alter=
native is

> > available.

> > > > Here is an example of a better alternative.

> > > >

> > > >=C2=A0 =C2=A0 typedef ypath1.0 {

> > > >=C2=A0 =C2=A0 =C2=A0type xpath1.0;

> > > >=C2=A0 =C2=A0 =C2=A0description

> > > >=C2=A0 =C2=A0 =C2=A0 "This type represents subset o=
f XPATH 1.0 expressions

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0that apply to a data tree con=
forming to a YANG model.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Each encoding should allow co=
nversion to an encoding

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0independent lexical represent=
ation where data node

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes are resolved to and =
substituted with module

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0names.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0When a schema node is defined=
 that uses this type, the

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description of the schema nod=
e MUST specify the

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0context in which the expressi=
on is evaluated if it

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0is different from the default=
 context.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0The default context is as fol=
lows:

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of var=
iable bindings is empty.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The function l=
ibrary is the core function library, and

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the XPath func=
tions defined in section 10 in RFC 7950.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The context no=
de is the leaf node.

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0";

> > > >=C2=A0 =C2=A0 =C2=A0reference

> > > >=C2=A0 =C2=A0 =C2=A0 "XPATH: XML Path Language (XPa=
th) Version 1.0";

> > > >=C2=A0 =C2=A0}

> > > >

> > > > That said I do not object to short-term application of =
alternative A as

> > > > long as a long-term solution is on its way for future m=
odules.

> > > >

> > > > Vladimir

> > > >

> > > > On 10/18/18 12:30 PM, Martin Bjorklund wrote:

> > > >

> > > >> Hi,

> > > >>

> > > >> Going back to the most urgent issue, what is this W=
G's recommendation

> > > >> for the subscribed-notifications draft in NETCONF w=
rt/ their usage of

> > > >> yang:xpath1.0 in filters?

> > > >>

> > > >> To summarize:

> > > >>

> > > >> We already have

> > > >>

> > > >>=C2=A0 =C2=A0 o=C2=A0 instance-identifier in XML use=
s prefixes from the XML document

> > > >>=C2=A0 =C2=A0 o=C2=A0 instance-identifier in JSON us=
es module names as prefixes

> > > >>=C2=A0 =C2=A0 o=C2=A0 XPath in NETCONF filter uses p=
refixes from the XML document

> > > >>=C2=A0 =C2=A0 o=C2=A0 XPath in JSON query filter use=
s module names as prefixes

> > > >>

> > > >>

> > > >> Alternative A:

> > > >> --------------

> > > >>

> > > >> Use different encodings for "stream-xpath-filt=
er" as well, depending

> > > >> on if it is XML or JSON.

> > > >>

> > > >> We would do in SN:

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 If the node is encoded =
in XML, the set of namespace

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations are t=
hose in scope on the

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'stream-xpath-=
filter' leaf element.

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 If the node is encoded =
in JSON, the set of namespace

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations is th=
e set of prefix and namespace pairs

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for all supported =
YANG modules, where the prefix is

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the YANG module na=
me and the namespace is as defined

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the "names=
pace" statement in the YANG module.

> > > >>

> > > >> Pro: the format is consistent within each encoding.=


> > > >>

> > > >> Con: unclear how to handle other encodings.

> > > >> Con: we keep using context-depending encodings.

> > > >>

> > > >> We could probably add that CBOR uses the same repre=
sentation as JSON.

> > > >>

> > > >> Example in XML:

> > > >>

> > > >>=C2=A0 =C2=A0 <stream-xpath-filter

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:if=3D"urn:iet=
f:params:xml:ns:yang:ietf-interfaces"

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:ip=3D"urn:iet=
f:params:xml:ns:yang:ietf-ip">

> > > >>=C2=A0 =C2=A0 =C2=A0 /if:interfaces/if:interface/ip:ipv4

> > > >>=C2=A0 =C2=A0 </stream-xpath-filter>

> > > >>

> > > >> Example in JSON:

> > > >>

> > > >>=C2=A0 =C2=A0 "stream-xpath-filter":

> > > >>=C2=A0 =C2=A0 =C2=A0 "/ietf-interfaces:interfac=
es/ietf-interfaces:interface/

> > ietf-ip:ipv4"

> > > >>

> > > >>

> > > >>

> > > >> Alternative B:

> > > >> --------------

> > > >>

> > > >> Use a non-context depending encoding, with the modu=
le name as prefix.

> > > >>

> > > >> We would do in SN:

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The set of namespace
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0declarations is th=
e set of prefix and namespace pairs

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for all supported =
YANG modules, where the prefix is

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the YANG module na=
me and the namespace is as defined

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the "names=
pace" statement in the YANG module.

> > > >>

> > > >> Pro: the format is independent from the protocol en=
coding

> > > >>

> > > >> Con: in XML, this leaf is treated differently from =
other XPath

> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0expressions, such as get-=
config filter and nacm rules.

> > > >>

> > > >> Example in XML:

> > > >>

> > > >>=C2=A0 =C2=A0 <stream-xpath-filter>

> > > >>=C2=A0 =C2=A0 =C2=A0 /ietf-interfaces:interfaces/ietf-interfaces:interface/

> > ietf-ip:ipv4

> > > >>=C2=A0 =C2=A0 </stream-xpath-filter>

> > > >>

> > > >> Example in JSON:

> > > >>

> > > >>=C2=A0 =C2=A0 "stream-xpath-filter":

> > > >>=C2=A0 =C2=A0 =C2=A0 "/ietf-interfaces:interfac=
es/ietf-interfaces:interface/

> > ietf-ip:ipv4"

> > > >>

> > > >>

> > > >> My proposal is A.=C2=A0 I think it is more importan=
t with consistency

> > > >> within each encoding than across encodings.

> > > >>

> > > >> (This said, I would like to have a context-independ=
ent encoding of all

> > > >> YANG types in the future.=C2=A0 But not now.)

> > > >>

> > > >>

> > > >>

> > > >>

> > > >> /martin

> > > >>

> > > >> ______________________________________________=
_

> > > >> netmod mailing list

> > > >> netmod@ietf.org<=
/a>

> > > >> https://www.ietf.org/mailman/listinfo/netmod

> > > >>

> > > >

> > > > _______________________________________________
> > > > netmod mailing list

> > > > netmod@ietf.org<=
br>
> > > > https://www.ietf.org/mailman/li=
stinfo/netmod

> > > >

> >





--0000000000008c54360578872532--


From nobody Thu Oct 18 14:51:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336E912F1AC for ; Thu, 18 Oct 2018 14:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.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 BlpyG0rqvCxh for ; Thu, 18 Oct 2018 14:51:41 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730081.outbound.protection.outlook.com [40.107.73.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E66130E22 for ; Thu, 18 Oct 2018 14:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TDIVEqkKnrNvOsoj3nCfQcALy0ePuRkBzJRUXjyo68A=; b=IXpxSO+CRcFhNq3J16TEBfwd8cOv12AxY7pc5iJL81tejz7xilhj8GJIk1ojwlHFcvS0XlanuRydi4uUs9Zk8Q4x8I+kOpycHpq5OJUyQRbs2KLg0SOaKolMD6PJTXyzqYAO3F90abU62wuTQ/1CydLxyndz8rQQXJI9BwD6Wss=
Received: from DM5PR2201CA0020.namprd22.prod.outlook.com (2603:10b6:4:14::30) by BN6PR22MB0147.namprd22.prod.outlook.com (2603:10b6:404:2a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Thu, 18 Oct 2018 21:51:39 +0000
Received: from BY2NAM03FT058.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by DM5PR2201CA0020.outlook.office365.com (2603:10b6:4:14::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20 via Frontend Transport; Thu, 18 Oct 2018 21:51:39 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by BY2NAM03FT058.mail.protection.outlook.com (10.152.85.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1250.12 via Frontend Transport; Thu, 18 Oct 2018 21:51:38 +0000
From: Alex Campbell 
To: Christian Hopps 
CC: NETMOD Working Group 
Thread-Topic: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
Thread-Index: AQHUZmQm2mqZ6rTnIE6Bya/iFyD5i6UlP/AAgABD5uU=
Date: Thu, 18 Oct 2018 21:51:37 +0000
Message-ID: <1539899498556.81453@Aviatnet.com>
References:  <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com> <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org> <1539813344223.22743@Aviatnet.com>,
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39850400004)(136003)(396003)(346002)(376002)(2980300002)(438002)(189003)(199004)(66574009)(2906002)(6116002)(7696005)(5660300001)(36756003)(316002)(14444005)(36736006)(6916009)(53546011)(117636001)(3846002)(50466002)(6246003)(6486002)(118246002)(102836004)(246002)(229853002)(7596002)(305945005)(7636002)(97876018)(336012)(7736002)(356004)(76176011)(8676002)(26005)(186003)(478600001)(47776003)(53416004)(93886005)(106002)(11346002)(956004)(25786009)(8746002)(446003)(8936002)(486006)(126002)(86362001)(4326008)(476003)(106466001)(23756003)(72206003)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR22MB0147; H:mail-send.aviatnet.com; FPR:;  SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT058; 1:CctM8kZuCapeId7s2iwSagWBzDfZRhaln6+Gw6PRZxDKRHFKewqS1ctvsPU9K7dM0WuB9Ha2uzuqB+GD+H9Lj8pVo94i7IEpqLUE0hi2TWKudnkappeR8bSOjCC4k0Zz
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 198f844f-3f7c-4285-c5b9-08d63543e1f9
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:BN6PR22MB0147; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR22MB0147; 3:gN4Ijg+0PnBSwGLR1jYX0fuUESgzBc35419VJKn0ekcI+UOCtgrLOqipUhVA+AQ9RHCKdOhAt7I4wBIa24quxbaiCf0sfstdxT3i/nCBWkPM7noZx1ABwE0v5WOSOXNc2KNCdkWCi/cYgypdNtOLx+VsBaELI5CKLC+RZsSiUPvpFxtov1yqCU2L3gh0tej9yjZsNIGyYC5zx5bX28v8Pw+j/VkC4SdHauXtWlIUqYtPNvesEuss+TtB21+Oc8OeqCG/5TMUgmYJ4dbTO6jC/2wZrwFYqup06QR81Ad2uO/HToN09useDPUwFouYHxT/y6PUCCYwMV0kld8KPC8t6Am1gKB20Kfyj5NE4V9pfUE=; 25:ypJtWthxcEA4JkWEP5B9+A7SL49szQj1FowPCZQETNtJVKWWuQ+TUgN98NOhFbhGtmzg9WS778wqC15K4zGApkAKbwFNlEYYGQXZUAu8O+hX4eT8CRwE+c2oZKDAJPWySEA9IuECk0HjxctEis69KIWRTAuQlkc/LiJosuuya3qySorEOrmH3y/L1qAa/18pDCOuLCLvXFixCRXbAhWvYx0+fJaRgsSlTWuVH2JYSoGffm51MCdYX5zSY0VywTbJUUEpYIfWGaPwbcCy+X3BqRTT5appCuagBNBK2K1GfSXHT2HS8krtlawZdGwqhWetwzxhFhGUkh/v09bZ5s8b9A==
X-MS-TrafficTypeDiagnostic: BN6PR22MB0147:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR22MB0147; 31:4310luYTf+5YU37YFf98ARZw0AhXO0Arcqc1QYmJifre3tEcPTwr1T9Sdg/WIyOqYF8ZJ6DQK40Sg/p+97zapGoaxaVlGIc+gSuA2vhFFFczcQij6Ki2sKCD6T85+gofJDZQ2Lv0ym0ewoJzvBsv3df32D/fYtLhdKY67ja/U9tSs01jXMCEm/5hdh5WZTpOxTwr+rPr1U8lykxh/aYz0woSdlNKf509OInNhkZFP60=; 20:8o89dc2SLYGgyzjm6fFKfRsXGSKCl1R6buBqWP9UPSl13H4vfDyDR0iH9dT5XqQCHI+AYIIhodSw2lLOGXdpdNbiMw4aXW3zQ4+osZ8nV4Sn0Ai7Cn6f6R/7qKHe0Itd4DMOoBNCl1hrwn4iI0MbJ/M9EvsjE71q5QFhC31WD/H6OFc25LJ7/FV2A6H0zXIvNoYvswJjruDVWpDuhhO7GAJxRsxaoi2ypPjSb4iOuO9BJiLFeLDRIWAiO1A7CxdD5KOabhfPFPYw3Sy4SPOl1vcJeDBKno3uotFoSKf4ZrFcl//bAoY3VEwWc3cTNUSAPJ2btjuYj5gK5WD8WiIcFV2uththSi4MAM0VFLNH3X4zD5ASTKINlsDGQo+CmMYxkxXLKE6qnUIVOmJv4eodWe6dUoWi2D6oZD5bhZvo3I73Nyz/cWi4Nd/5R8wQkmru/Ug2OOl59fYFhRdeCC77HHEQSThyWgOBHVgqThKd1U3z4QiXFLSEneDA2FSYLtzO
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(131327999870524);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93004095)(10201501046)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:BN6PR22MB0147; BCL:0; PCL:0; RULEID:; SRVR:BN6PR22MB0147; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR22MB0147; 4:bhWoFCADg8EM/irV6SO8k5e0hN5qdybgPXzxGgk3NYNqlPx5BT1UMq4UXkojy6/ZvMAiDHMHO6tuM+d4XTWzf+byBFsoTleFm9IPQYAin0OK12wXu3AEcLrVKPc363sK2z5RxcMJ3D0TcEE+Fe+IXufTiERirJba2SmxXGVWNyfVwguCtZj2psB749K3oUDwD2uvxbV2RxYp6kgxxh37Xp90vvUXAY1rfHXPVL2wVQDXfYM3B3h41M9EYSSXY+WbnFuySDEy0b5jRQzi4ujkMxyn8fdQr+bTzMcjdoCRDl8JhZe3omfp64lMVXCp3fciujzL6Tx/Hqz3HtL9GsI8UYF3wTWPhWoco9KM+81dg/c=
X-Forefront-PRVS: 08296C9B35
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN6PR22MB0147; 23:Um+98jRKMPRRZD8PrqO4WIMDbHQIJkVS8lZxiZ4?= =?iso-8859-1?Q?zJUxv2/5RO6CJPXHU9w4hnMMeymBFJnrg0Z4RwZ7T3eV6n0O/Q+jzM2aNd?= =?iso-8859-1?Q?olpRPVCj7OSftYmFYIjfJ09R8tY50N6M5PK1cfAQknhF7A6izNmwhyIV2X?= =?iso-8859-1?Q?3IaX/aCvpDZWD7JzAYLaBKlFpLNjCf2b6RKVdXAAMpdinZ+cu6UqspPLQk?= =?iso-8859-1?Q?WEbNtN/TiwOD55Eaq2aMLQC5arC1H4WvhRmx0dcvEDOxcM9jER+Eh9LrQ5?= =?iso-8859-1?Q?z/frmbCG0Uxf8Y7M7hxprvyIE/AXwGlKORL4FrHWddEgfhL+4BtGq3nua9?= =?iso-8859-1?Q?drUpqDBhjvsHEIa7WC9DKBOpPsJycEWE38j0uMj53w80Lkrie8+FJ0uCpw?= =?iso-8859-1?Q?tX/p7voBJgIop5SDncScPcygtnXajHO7PafAj4ZVgjKwTsh1mJlwRg3fhJ?= =?iso-8859-1?Q?0vNBbEkZ4EkgrEMIWRumbJWkrFanPz7bYjKDktJ+JDC3xo2fuAjCi5ZykF?= =?iso-8859-1?Q?PCym44OT9fxMZX1YHw5WzSW1rA7P+T++ozqO4pQ7GF0DDHZxLoCbqv9JRh?= =?iso-8859-1?Q?DCRS7EGfDNTvgy3qXSh7afoUHKToRKHISH4m6/11XF0DWATCQ9FKYHdwXO?= =?iso-8859-1?Q?KOTjwNgQPb9J4A3KL2YojHYfpBlJrzslxcy671Eqzrj/qaGJ0NSF66Wt25?= =?iso-8859-1?Q?IM19LmJL+ngoQutF5Okv1iO8EGU7gNnUdtTvIHLNnu8+F8sCHygdlZsgrC?= =?iso-8859-1?Q?zq9Z2ShNSjiHHgADyUoWSosp88p9pSy4864TUsqB4OoAjj2iLbCXlyl3Eg?= =?iso-8859-1?Q?eB5aFH9T30pzJXZalmyawijL7tK4K1BrfmLap54n3bZDOxSEXs0+rjtY1w?= =?iso-8859-1?Q?XYxvarI/jD0TSG+j76igm7ykTAwGDTzl13Lkj/Q8XlY9XxPlStSAIviqWZ?= =?iso-8859-1?Q?TsNxp7UOoaA7oHa5mPIB3yYB4+U5FwFDVS2jZi1OQFIYVmEKe7GFbonIil?= =?iso-8859-1?Q?Yi/KftZbt/Ne1U5qxt07jHMmw5UTykdRUzap7dNAkZqtNwnelQ/MkgF7+D?= =?iso-8859-1?Q?PySkR4UAFzETDeSNo4xYRalGeJWLlHanhwpHnobMsFW5hcVwdzCuU7Eoh1?= =?iso-8859-1?Q?1ht8O6Lzn+kHTGw6BggLcktHuqyXf2dgTQcVBUF1kHFOX7w7sqtC5RdMRk?= =?iso-8859-1?Q?gaLAb54cfo8fmL+ynoEmQyQu4u4QUp8zCfBRaxMylZ/g+Who/HqdFhJGPn?= =?iso-8859-1?Q?l4bF0kRbPjbxddMkUkycjRzJG3uGASVqmue9zmhMmR98ErbHwvxXsOUTc3?= =?iso-8859-1?Q?L9301tu/3CJYfOHoXOgcQUEVt+hA+9y47LVLywiiqL7Zg=3D=3D?=
X-Microsoft-Antispam-Message-Info: F1YOr1V9wz4detytTOQKAJX4rFyjrqJNbV9b88r8xQs3dQ0P6MzjFo5PY4iwyRLppFA/fxRPqP64kA+g28PPIZEehoy1PKACtsh//jyC/LDmI+KqiFqHw0KerUO3oaBWpaU6fEawOiYDeFX2Cee8rMY72U9OLNTnVDi/Mv/h4eUc6PjEl5E5haxcmRXIvAhIWXuUHA5iCeOtul0AeuDqKl0D+0dlA8+GdFB7iNnZiF9cBv4X+B+mTDP7cajtt077BvU1I528BC+J9sG9eQ6zj7FjV2FRX0N9NkhC3BUiXaI1Ee4gm5NlkvMRQPARkRVPtQX3GUD8sxqdqwS1O+sNl2mHSFonKByvPxBzcruhmZA=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR22MB0147; 6:7aoHD3SC76z7gdPgmxgAHsVsLCsojVd+zHCnf+PSvvJwB5w8Ja1FW5tsTf7Bqq7pWXM2Jay5djg4kLxqgdCsyZH0mtVrlLL6dqI/Y49SsLRdjdGG1CkouWqUNw/1gStsmZ3n/kCfs46DF64Eao7eG2nYJEgjZuSHhkGxY8JS5jJ8oWAllf85RAr37aQ79vYkKDglsNv1z9D6uadloSRlLw+v85oraWbITU0rADNO8CApKVdnAdu/8axd7eNRdUSQ75ALReC1b1rK4whUZGVyubRiCx8t6VNwtUPWhLGT0KAnpxSKPQQlWq4XuVS+U25X5WKlvSMyB7DMTPxgUMhHqYTJ13+4Wn6Vj4tUAstzVR99lpInEudwcz/c94x7hLt+jPX+caCSyaq/A13Nj9CsNu0M9QOAdmoQRyayKbDgmIUZwSMeSt/Uk2v+6e+P5u0Whnq3M5cGGPOMiJsT5JhxDQ==; 5:OF6elCL197MGOIL6DMdD8btPruXJ3fkqpr6J2pIkJyjVZBK4rHecdgn9cls9oJnTQ7Gne4uCZ+iihTD1LCv9qyPkWuSTw9O/829UmzNSpFF08myD/VUp+tx8napjj5Nb73liHFGCOTu2TTWS3w5DI5YahjYBKL6TlyHHd2M6TnY=; 7:LpysNrpVpIPPb7zQ3X+9x3qzo01KASUkKcRsiVl9o+Ld1/x7cNQIK245A+Xxg2Z7aoQdyZOBLE0jWGN8U1NTfjb6lwaSJjdf7msVhYiHzJqyMk8ruHvUa5EIynXz2HTVgUADs7lqP6b7js73kBj2sxYKiORG6+5TZrG9QHWAXLauIZHnUr3IYXBdj/kV3U1jeuTtNarRASl3tF1TJe/VLmqw+8N+vNmKWDEjOZ9vzQgjFLGW2WBfZonPX/OKCLEJ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2018 21:51:38.9202 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 198f844f-3f7c-4285-c5b9-08d63543e1f9
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR22MB0147
Archived-At: 
Subject: Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2018 21:51:46 -0000

Capabilities, features and deviations indicate the type of requests the rou=
ter can respond to.=0A=
=0A=
The capability advertisement may not affect the router, but the capability =
itself directly does.=0A=
The capability advertisement tells the client that the router can answer re=
quests involving the capability in question.=0A=
=0A=
Will clients base their behaviour on module tags, such as fetching all modu=
les with a particular tag?=0A=
In that case, as a vendor, I do not understand the implications of adding o=
r removing a tag and I would prefer if the RFC was clearer on that point.=
=0A=
=0A=
________________________________________=0A=
From: Christian Hopps =0A=
Sent: Thursday, 18 October 2018 11:16 p.m.=0A=
To: Alex Campbell=0A=
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10=
/2/18 - 10/16/18=0A=
=0A=
A router has no use for it's capability/feature/deviation advertisements ei=
ther; module-tags are no different in this respect.=0A=
=0A=
Thanks,=0A=
Chris.=0A=
=0A=
Alex Campbell  writes:=0A=
=0A=
> Hi,=0A=
>=0A=
>> The server implements the tags (at least the predefined ones), and the u=
se cases that come to my mind at least involve clients not servers.=0A=
>=0A=
> I assume that the server here is a network element implementing ietf-modu=
le-tags.=0A=
>=0A=
> I still don't see why network elements should implement ietf-module-tags.=
=0A=
> What benefit is gained from storing the tags on the server instead of the=
 client? It seems backwards.=0A=
>=0A=
> Have I misunderstood? I assumed that ietf-module-tags was meant to be imp=
lemented by network elements that are NETCONF servers - but now I see the d=
ocument doesn't actually specify who is meant to implement the module. Your=
 comment about newly installed routers supports my understanding however.=
=0A=
>=0A=
>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to m=
odules is exactly the point of pre-defined tags, but you questioned their v=
alue at the top of your mail.=0A=
>=0A=
> The problem with pre-defined tags is that they are never complete. I can =
always find a useful tag that is not pre-defined.=0A=
>=0A=
>> Either way configuring a newly installed router is a given, I don't thin=
k this is the place to solve the "forgot to add all the config to my new ro=
uter install" issue. :) If one is using tags in ones network then making su=
re the newly installed router has tags configured the way you expect is no =
different from making sure that you configured IS-IS correctly.=0A=
>=0A=
> The reason I find this problematic is the same as above - that the router=
 has no use for the tag data.=0A=
> It's as if my PC were to download its keyboard mapping table from my home=
 router. Then I change ISPs and have to swap the router, and suddenly my ke=
yboard doesn't work correctly.=0A=
> It would be much better to store the keyboard mapping table for my PC *on=
 my PC* instead of adding needless external dependencies.=0A=
>=0A=
> Alex=0A=
>=0A=
>=0A=
> ________________________________________=0A=
> From: Christian Hopps =0A=
> Sent: Wednesday, 17 October 2018 9:56 p.m.=0A=
> To: Alex Campbell=0A=
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - =
10/16/18=0A=
>=0A=
> The point is to keep this open to however the community might end up choo=
sing to use it. The act of pre-defining tags doesn't disallow other tags be=
ing defined, in fact at this point I've sent a bunch of email defending lea=
ving things as open as possible. They both can co-exist. :)=0A=
>=0A=
> Thanks,=0A=
> Chris.=0A=
>=0A=
>> On Oct 16, 2018, at 7:32 PM, Alex Campbell  =
wrote:=0A=
>>=0A=
>> I have no issue with systems using tags to classify or organize modules,=
 however this seems to me like something that would be specific to the syst=
em doing the classifying.=0A=
>=0A=
> Sure we support this. That's what user tag configuration is there for.=0A=
>=0A=
>> It would not be something that needs to be specified in the module itsel=
f (except perhaps as freeform description text), and it certainly would not=
 need to involve the NETCONF server.=0A=
>> What would a server do with module classification data? (unless it is al=
so implementing some kind of module browsing interface, in which case it mi=
ght be used to supply the browser with data)=0A=
>=0A=
> The server implements the tags (at least the predefined ones), and the us=
e cases that come to my mind at least involve clients not servers. I'm not =
saying there wouldn't be a server use case, but it's not as obvious to me.=
=0A=
>=0A=
> And yes implementing some kind of module browsing interface (which could =
group modules by tags) is a fine example of how tags can be used.=0A=
>=0A=
>>=0A=
>> Hashtags - all types, that I'm aware of - are inherently freeform and fl=
uid, changing quickly according to the desires of users. I don't think it m=
akes sense to "hard-code" them in published RFCs or even published vendor m=
odules or firmware.=0A=
>>=0A=
>> Tomorrow, I might want to list all modules for management plane protocol=
s. As a network operator, should I go and update the ietf-module-tags on al=
l of my network elements? That seems silly. This should be client-side data=
. (And if I did, what happens when I add a new router and forget to update =
its tag data? Will that confuse the client?)=0A=
>=0A=
> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to mo=
dules is exactly the point of pre-defined tags, but you questioned their va=
lue at the top of your mail.=0A=
>=0A=
> Either way configuring a newly installed router is a given, I don't think=
 this is the place to solve the "forgot to add all the config to my new rou=
ter install" issue. :) If one is using tags in ones network then making sur=
e the newly installed router has tags configured the way you expect is no d=
ifferent from making sure that you configured IS-IS correctly.=0A=
>=0A=
> Thanks,=0A=
> Chris.=0A=
>=0A=
>>=0A=
>> Regards, Alex=0A=
>>=0A=
>> ________________________________________=0A=
>> From: Christian Hopps =0A=
>> Sent: Wednesday, 17 October 2018 1:04 a.m.=0A=
>> To: Alex Campbell=0A=
>> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group=0A=
>> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 -=
 10/16/18=0A=
>>=0A=
>>>=0A=
>>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  =
wrote:=0A=
>>>=0A=
>>> The introduction does not explain what they are useful for=0A=
>>=0A=
>> The second sentence of the abstract: "The expectation is for such tags t=
o be used to help classify and organize modules." The introduction repeats =
this in the first sentence. I'm not sure how much differently we could say =
"Tags are useful for organizing and classifying modules". Are you asking fo=
r justification on the usefulness of organizing and classifying things? I t=
hink this concept is rather widely accepted.=0A=
>>=0A=
>>=0A=
>>> , it just makes a comparison to #hashtags (which is something I would e=
xpect to see in an April 1st RFC).=0A=
>>=0A=
>> Using tags to help organize collections of data is literally ubiquitous:=
 Movies/music/media, IP routes, and yes even social media are just a few ex=
amples.  Regarding April 1st, are you are unfairly restricting your perspec=
tive to only the ironic use of hashtags? Hashtags organically developed as =
a useful and widely used way for people and groups to add meta-data to thei=
r messages which then allowed other services to collect and present them in=
 useful ways. Indeed businesses and other groups use hashtags for this purp=
ose to great success. It was hardly a joke, and for many folks it is immedi=
ately useful to understand what is being proposed.=0A=
>>=0A=
>> Thanks,=0A=
>> Chris.=0A=
>>=0A=
=0A=


From nobody Thu Oct 18 17:56:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA389130E3B; Thu, 18 Oct 2018 17:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EvHSaZMX-W71; Thu, 18 Oct 2018 17:56:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 15DED130E2F; Thu, 18 Oct 2018 17:56:29 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6BF51D82B239F; Fri, 19 Oct 2018 01:56:26 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 01:56:27 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0399.000; Fri, 19 Oct 2018 08:56:15 +0800
From: Qin Wu 
To: 'NetMod WG' , "netconf@ietf.org" 
CC: =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= , Niuye 
Thread-Topic: I-D Action: draft-wu-netmod-factory-default-00.txt
Thread-Index: AQHUZ0SBg+sS1/+AGEip7AFWkirR8KUluv/w
Date: Fri, 19 Oct 2018 00:56:14 +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.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-wu-netmod-factory-default-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 00:56:32 -0000

VGFsa2luZyB3aXRoIE5FVENPTkYgYW5kIE5FVE1PRCBjaGFpcnMgYWJvdXQgdGhlIHJlbGF0aW9u
IHdpdGggbmV0bW9kIGFuZCBuZXRjb25mLCB3ZSBhZ3JlZSB0byBtb3ZlIGRyYWZ0LXd1LW5ldGNv
bmYtcmVzdGNvbmYtZmFjdG9yeS1yZXN0b3JlDQpUbyBuZXRtb2Qgd2l0aCBkcmFmdCBuYW1lIGNo
YW5nZSBhbmQgcmVmZXJlbmNlIGNoYW5nZXMsIGkuZS4sDQoxLlRoZSBkcmFmdCBuYW1lIGlzIGNo
YW5nZWQgaW50byBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAwDQoyLlRoZSByZWZl
cmVuY2VzIHRvIG5ldGNvbmYgYW5kIHJlc3Rjb25mIGFyZSByZW1vdmVkLg0KaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDANCldlIHdp
bGwgYWxzbyBwcmVzZW50IHRoZSB1cGRhdGUgb2YgdGhpcyB3b3JrIGluIG5ldG1vZC4NCg0KLVFp
biAob24gYmVoYWxmIG9mIGF1dGhvcnMpDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSS1E
LUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG85DogMjAxOMTqMTDUwjE5yNUgODo0MQ0KytW8
/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCtb3zOI6IEktRCBBY3Rpb246IGRyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg
YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K
DQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRmFjdG9yeSBkZWZhdWx0IFNldHRpbmcNCiAg
ICAgICAgQXV0aG9ycyAgICAgICAgIDogUWluIFd1DQogICAgICAgICAgICAgICAgICAgICAgICAg
IEJhbGF6cyBMZW5neWVsDQogICAgICAgICAgICAgICAgICAgICAgICAgIFllIE5pdQ0KCUZpbGVu
YW1lICAgICAgICA6IGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDAudHh0DQoJUGFn
ZXMgICAgICAgICAgIDogOQ0KCURhdGUgICAgICAgICAgICA6IDIwMTgtMTAtMTgNCg0KQWJzdHJh
Y3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBZQU5HIGRh
dGFzdG9yZSB0byBpdCdzDQogICBmYWN0b3J5LWRlZmF1bHQgY29udGVudC4gIFRoZSByZXNldCBv
cGVyYXRpb24gbWF5IGJlIHVzZWQgZS5nLiBkdXJpbmcNCiAgIGluaXRpYWwgemVyby10b3VjaCBj
b25maWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24NCiAgIGdvdCBt
YWpvciBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5nIHRoZSBjb25maWd1cmF0aW9uIHByb2Nlc3MgZnJv
bQ0KICAgc2NyYXRjaCBpcyB0aGUgYmVzdCBvcHRpb24uDQoNCiAgIEEgbmV3IHJlc2V0LWRhdGFz
dG9yZSBSUEMgaXMgZGVmaW5lZC4gIFNldmVyYWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZw0KICAg
dGhlIGZhY3RvcnktZGVmYXVsdCBjb250ZW50IGFyZSBzcGVjaWZpZWQuDQoNCiAgIE9wdGlvbmFs
bHkgYSBuZXcgImZhY3RvcnktZGVmYXVsdC1ydW5uaW5nIiByZWFkLW9ubHkgZGF0YXN0b3JlIGlz
DQogICBkZWZpbmVkLCB0aGF0IGNvbnRhaW5zIHRoZSBkYXRhIHRoYXQgd2lsbCBiZSBjb3BpZWQg
b3ZlciB0byB0aGUNCiAgIHJ1bm5pbmcgZGF0YXN0b3JlIGF0IHJlc2V0Lg0KDQoNClRoZSBJRVRG
IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC8NCg0K
VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDANCmh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3Rv
cnktZGVmYXVsdC0wMA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg
b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50
ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRw
Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkkt
RC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3Lmll
dGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0
ZXMudHh0DQo=


From nobody Fri Oct 19 01:12:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD8127AC2 for ; Fri, 19 Oct 2018 01:11:59 -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, 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 eoOaLSWTz56H for ; Fri, 19 Oct 2018 01:11:56 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 08AB8127B92 for ; Fri, 19 Oct 2018 01:11:54 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 1BEA5182113A; Fri, 19 Oct 2018 10:19:41 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 013CC1821137; Fri, 19 Oct 2018 10:19:25 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , netmod@ietf.org
In-Reply-To: <20181018.123036.731934458688841323.mbj@tail-f.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
Date: Fri, 19 Oct 2018 10:11:37 +0200
Message-ID: <87bm7q4apy.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 08:11:59 -0000

Martin Bjorklund  writes:

> Hi,
>
> Going back to the most urgent issue, what is this WG's recommendation
> for the subscribed-notifications draft in NETCONF wrt/ their usage of
> yang:xpath1.0 in filters?
>
> To summarize:
>
> We already have
>
>   o  instance-identifier in XML uses prefixes from the XML document
>   o  instance-identifier in JSON uses module names as prefixes
>   o  XPath in NETCONF filter uses prefixes from the XML document
>   o  XPath in JSON query filter uses module names as prefixes
>
>
> Alternative A:
> --------------
>
> Use different encodings for "stream-xpath-filter" as well, depending
> on if it is XML or JSON.
>
> We would do in SN:
>
>     o  If the node is encoded in XML, the set of namespace
>        declarations are those in scope on the
>        'stream-xpath-filter' leaf element.
>
>     o  If the node is encoded in JSON, the set of namespace
>        declarations is the set of prefix and namespace pairs
>        for all supported YANG modules, where the prefix is

Is "supported" the same as "implemented", or something else?

>        the YANG module name and the namespace is as defined
>        by the "namespace" statement in the YANG module.
>
> Pro: the format is consistent within each encoding.
>
> Con: unclear how to handle other encodings.
> Con: we keep using context-depending encodings.

  Con: XPath expressions in JSON can get pretty long (I assume it's not
  just an instance identifier but may contain predicates etc.). We
  cannot use the trick with the default namespace as in YANG, so all
  data node names will have to carry the prefix.

>
> We could probably add that CBOR uses the same representation as JSON.
>
> Example in XML:
>
>          xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>     /if:interfaces/if:interface/ip:ipv4
>   
>
> Example in JSON:
>
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
>
> Alternative B:
> --------------
>
> Use a non-context depending encoding, with the module name as prefix.
>
> We would do in SN:
>
>     o  The set of namespace
>        declarations is the set of prefix and namespace pairs
>        for all supported YANG modules, where the prefix is
>        the YANG module name and the namespace is as defined
>        by the "namespace" statement in the YANG module.
>
> Pro: the format is independent from the protocol encoding
>
> Con: in XML, this leaf is treated differently from other XPath
>      expressions, such as get-config filter and nacm rules.
>
> Example in XML:
>
>   
>     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>   
>
> Example in JSON:
>
>   "stream-xpath-filter":
>     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>
>
> My proposal is A.  I think it is more important with consistency
> within each encoding than across encodings.

I would suggest to consider declaring prefixes & namespaces explicitly
in the data, as in the schema mount document. It is independent of
encoding and the expressions can be kept short. In fact, one of the
namespaces can be declared as default, so this use of XPath would then
be very similar to YANG.

Lada

>
> (This said, I would like to have a context-independent encoding of all
> YANG types in the future.  But not now.)
>
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Oct 19 02:05:01 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D1128BAC; Fri, 19 Oct 2018 02:05:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <153993990027.32042.849326339822015499@ietfa.amsl.com>
Date: Fri, 19 Oct 2018 02:05:00 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-lengyel-netmod-yang-instance-data-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 09:05:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : YANG Based Instance Data Files Format
        Authors         : Balazs Lengyel
                          Benoit Claise
	Filename        : draft-lengyel-netmod-yang-instance-data-05.txt
	Pages           : 14
	Date            : 2018-10-19

Abstract:
   There is a need to document data defined in YANG models without the
   need to fetch it from a live YANG server.  Data is often needed
   already in design time or needed by groups that do not have a live
   running YANG server available.  This document specifies a standard
   file format for YANG Based Instance data, that is data that could be
   stored in a datastore and whose syntax and semantics is defined by
   YANG models.  Most important use cases foreseen include documenting
   server capabilities, factory-default settings, or vendor provided
   default configurations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-05
https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-lengyel-netmod-yang-instance-data-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 Fri Oct 19 02:45:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C88130E92 for ; Fri, 19 Oct 2018 02:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Xjh9BQ1T; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZPnm7+Jl
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 dH5rYyxYU6z7 for ; Fri, 19 Oct 2018 02:45:05 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27199130E89 for ; Fri, 19 Oct 2018 02:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539942303; x=1542534303; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7KdGh2/OBVPm3tKIoe+/Oi2dzWsf56J7O/fHdwVyiJE=; b=Xjh9BQ1TZok4B5vQkcPl9+xxqQgh0C4fXrt8xY2kvmPv0Xjb901P/mK6s/Zz1FMH S9u8H9/OYfFxFQ1hv6OqAiQRo0nJl42J4a4aWvEfoP2u9J7ra03VPDJdE4hb1+n3 GSNxZZxd1c1blU/Zw+5zzyaD9YsowwDpntBcX6OpcHw=;
X-AuditID: c1b4fb2d-fb3d09e000003a27-e1-5bc9a79fb586
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.38.14887.F97A9CB5; Fri, 19 Oct 2018 11:45:03 +0200 (CEST)
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 11:44:44 +0200
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 11:44:44 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/UOTlS3ZWuFpXjjQHaf8YOZmKuuaAAPDnmpGD6Htdq4=; b=ZPnm7+Jl4V9lD3Ayzl+OFe2Rj+gbCX2cwQ1N5w8OWpEycgZ7X/HG0TpmCZx6R8g1IGeCFvihb5gm4NBZFzYSVB09jDtkYvep+A8L3r/jWQ33DOq+LZKIcWxOugAvzZfYJ94t7OjJEMhw3ZNypwaJPi7VY8IJ6zf/0pCzGwO+unA=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2638.eurprd07.prod.outlook.com (10.173.78.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.20; Fri, 19 Oct 2018 09:44:42 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1250.022; Fri, 19 Oct 2018 09:44:42 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-lengyel-netmod-yang-instance-data-05.txt
Thread-Index: AQHUZ4rV6LroJxQVPkOwPKwAHf81zaUmUZ0A
Date: Fri, 19 Oct 2018 09:44:42 +0000
Message-ID: <1dbb839f-d15e-197a-c476-63727a8c3a61@ericsson.com>
References: <153993990043.32042.4122595940368221766.idtracker@ietfa.amsl.com>
In-Reply-To: <153993990043.32042.4122595940368221766.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
x-forwarded-message-id: <153993990043.32042.4122595940368221766.idtracker@ietfa.amsl.com>
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: AM6P193CA0083.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::24) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2638; 6:QevrkDfm7kfxGC+Nhrj+69lnrPteQBzbgqrYGq+EioCQ/c7C7FGZANfziwNf3EabOZSakq7Sxf6boU19p0UwZSn1leAF7mXQWZLQGwQL3Yimo9iSwKa5BqTiBm/bGE0NJ2uUUAIdM2DUepppIpmypDWNfdm2TV57Qs2V0uImtCY5y0Ro11ikrywhLdC+PMT50HLp+BQfp37Z1cPcTDtj/jx/BdxwDAtK/bDqjlcPZNQrvVEiyfQzHYg00TY7RkYxJoMJDBR2rx5w+mFscJbx6CNdKNx7A+BYO2nHJ/k8+0BkyxEaodF7dcXegHEPB1ldAOzYHObyjOVbccEq3nojki49qFusSr4q834TDjBv2qHYEjBRmlgYb3e2nRen+K1Hj7uJWlUofN62RMektYOyPt0MqmJUZh9ErckxJyuapLsz04PAPwgTk3XzxgkRE9lJ0Lf40yRZseJraKzziUqW8Q==; 5:0V6RsmjTmL4fGq2rIaGr/nbjYbYGzHPDyzrtkeHxsugN+lb2evF4nITufgz+n0O+FgXrUpSeXEGhgmOpSCtTacjv87Jn199HEVwFpm2CfDWK8WMeozPdxnQiZIjBb/kq0eGuh76ihRyP2y4TpNa7/nxtLGkv5/HgcOcIeymuvTQ=; 7:b/FBNL1XWbKI+021YgKlOzT6hywOqv55W3ZGw8vwVC+KitSuw5vbBKPnpHXpNXCnAto5UMetEm/wMZIbpcrcMQN+JmG6cACpNmS3/SW1mUd1VhoTzpa16s/T5ZDrh3vhP1lgjaDayDEyOIMwsatYNb67My2otI1lS2XlhVxG4uKignHnjQhv3S4QFczSl1/zG5vynP2yKPrCA+78jXkt5DlIlZIstYEAh1MiD/HcTPjxlwkVJaL+1mRZC7QmiMXd
x-ms-office365-filtering-correlation-id: 3a48d5b7-2868-451c-b51e-08d635a77df0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2638; 
x-ms-traffictypediagnostic: VI1PR0701MB2638:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(248295561703944)(37575265505322)(120809045254105);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231355)(944501410)(4983020)(52105095)(10201501046)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2638; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2638; 
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(346002)(376002)(366004)(252514010)(189003)(199004)(6306002)(6512007)(7736002)(2473003)(606006)(8936002)(76176011)(14444005)(2906002)(386003)(52116002)(6506007)(99286004)(2900100001)(256004)(99936001)(102836004)(316002)(36756003)(66066001)(68736007)(186003)(26005)(65806001)(65956001)(2351001)(8676002)(81166006)(3260700006)(81156014)(1730700003)(11346002)(446003)(31696002)(6916009)(85202003)(236005)(106356001)(486006)(4001150100001)(105586002)(6116002)(15650500001)(3846002)(53936002)(25786009)(2616005)(478600001)(229853002)(58126008)(5660300001)(64126003)(6486002)(71190400001)(85182001)(97736004)(5250100002)(71200400001)(65826007)(2501003)(476003)(86362001)(966005)(5640700003)(14454004)(54896002)(6436002)(31686004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2638; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: A61FWOJcWkYH4efG1pMPvyt8nulppVnibR1TpIJH9JMuotndwduOevXnIUG1HYB6I03dC7IXR6fK+XhYo49zug7DOumCdAM3ZghjOcrkvUtaFm1Gik1atQ+4ew3wbBo6Wy8VWDhXkQpa6ehDkIzhn/TCz7mRQqJcNbXnLZ87OGJWwRQN44fvQS/7xRn7vnHkGvtPRHqocmtfXPsmM8vHL2u0YogADcgBN2cm3EGTxzj23RtmHCPCj01sdlM4vq0mwKxy5ZNjbWSTQfLu1VQtBmmHDp7LlnXEXEmJOqk+xm/easmmQBec3yz8kBj5y6TE4VyA0AjNRW8PwqDgUMmgCbmWYB6lZMWpheZgZlBxSl8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070501080004020101000001"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a48d5b7-2868-451c-b51e-08d635a77df0
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 09:44:42.6756 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2638
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHeXfO5nG1fFuajysJV2poWmmWZqRFRhSGX0Lzkg096GputuMl S2x5IVMqqYVukJcQBbU00UqRTMtoitkKU/xgecnIoSR2wXlr2zlCffv93+f//J/3eXkpQmzk Syi5Mo1WK2UKqUBI6qKeZfpU1Bpi9sw/dQisMF7nh6IT1dULvAgULTyUSCvkGbR69+HzwmRN axdK1cRe1rbdJjRIG1GE7CnA+6CzUsMvQkJKjHsQfHrbx4nfCHSaz5yo5sHKjzyeVZC4hICW ZhPJVkp5MJM3iFgxgaCh6jVhTRbgY3BjtpNnZUfsCbq2RoGVN+EYWB7u585jYHFpHrHsB/eb ZvlWJrE7rOYabR4RDoGhol5brxiHw9f6dxYPRdnj05CrOWU9Rngz/OltsNkJ7AwjkxU8djlH GDP2CVh2gu8TK3yWpVA2PcLxWaguLLd5nHAc5Bv0tpUBlyLonJ0j2AHnoGO0kAvaBf1Dk4hl V/hQUYzYhpd2MGXq5SaHw3TTGy7pI4JWXTux1l043s4lqaB2YJIsQX76f26ut/QQ+CaCkqUC vt72AhvBoJsk9ZatCewBNQXS//1W9oaaKhPBcjCUmbsELLuBtnjMjuUAMPXMIZb9oebxsqAS CeuQE0MzTEqSn78vrZYnMIxK6auk05qR5XN1tSz6PEf1piPdCFNIul60qDfEiPmyDCYrpRvt sOSMN9W/RxJSqVLSUkeRW7qlLEqUZV2h1ap4dbqCZrrRFoqUOot86zqixThJlkZfpOlUWr1W 5VH2Eg3aPzE1ExmUHL8gTwhep+7bVhLp6pHpcmv1IA3Dv9xVcc7lVdSBtruZj7wvBYYej8QX 6BeFib33GnxMVzdkDyr1NXdCKBzwamHAO4f5clTyxJy/PSqlzivWJbvRYA7yUSmM18xZdtpR k/lB2Lf2hw4nFTmpnmfo5p8DW3eGjQSDlGSSZXu9CDUj+wtqx1+qZAMAAA==
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-lengyel-netmod-yang-instance-data-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 09:45:09 -0000

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


  

    
  
  
    
Hello,

    
I have updated the yang instance data draft. 

    

    

      
    
        
  • Changed title and introduction to clarify that this draft is
          only about the file format and documenting server capabilities
          is just=C2=A0 a use case.=C2=A0=C2=A0 
    
        
    • 
        
  • Added reference to
          draft-wu-netconf-restconf-factory-restore=C2=A0=C2=A0 
    
        
    • 
        
  • Added new open issues.
    • 
      

    

    
I anticipate that a separate IET=
F
      document will define in detail how and which set of server
      capabilities should be documented. I might even write that draft
      once this one has progressed forward.

    


    

    
I hope this covers the concern o=
f
      Martin and others about the scope, and helps the adoption of the
      draft.

    

    
regards Balazs

    


    

    
-------- Forwarded Message
      --------
      

        
          

            Sub=
ject:
            
            New Version Notification for
              draft-lengyel-netmod-yang-instance-data-05.txt
          

          

            Dat=
e: 
            Fri, 19 Oct 2018 02:05:00 -0700
          

          

            Fro=
m: 
            internet-drafts@ietf.org
          

          

            To:=
 
            Benoit Claise <bclaise@cisco.com>, Balazs Lengyel
              <balazs.lengyel@ericsson.com>
          

        
      

      

      

      

      A new version of I-D,
      draft-lengyel-netmod-yang-instance-data-05.txt

      has been successfully submitted by Balazs Lengyel and posted to
      the

      IETF repository.

      

      Name: draft-lengyel-netmod-yang-instance-data

      Revision: 05

      Title: YANG Based Instance Data Files Format

      Document date: 2018-10-19

      Group: netmod

      Pages: 14

      URL:
https://www.ietf.o=
rg/internet-drafts/draft-lengyel-netmod-yang-instance-data-05.txt
=

      Status:
https://datatracker.ietf.org=
/doc/draft-lengyel-netmod-yang-instance-data/

      Htmlized:
      https://tools.ietf.org/ht=
ml/draft-lengyel-netmod-yang-instance-data-05

      Htmlized:
https://datatracker.ietf=
=2Eorg/doc/html/draft-lengyel-netmod-yang-instance-data

      Diff:
https://www.ietf.org/rf=
cdiff?url2=3Ddraft-lengyel-netmod-yang-instance-data-05

      

      Abstract:

      There is a need to document data defined in YANG models without
      the

      need to fetch it from a live YANG server. Data is often needed

      already in design time or needed by groups that do not have a live<=
br>
      running YANG server available. This document specifies a standard
      file format for YANG Based Instance data, that is data that could
      be

      stored in a datastore and whose syntax and semantics is defined by<=
br>
      YANG models. Most important use cases foreseen include documenting<=
br>
      server capabilities, factory-default settings, or vendor provided
      default configurations.

      

      

      

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

      until the htmlized version and diff are available at
      tools.ietf.org.

      

      The IETF Secretariat

      

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms070501080004020101000001
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAxOTA5NDQzOFow
LwYJKoZIhvcNAQkEMSIEIPNWkzR+q9Y+VgJGnt4KimlgUiljawjvyqCPD0xcRq9UMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAIqLYAcPadg/gY7R5gVIJqnthMbdAfHEoBDVx2hs4aMud8Ps
njNwaKux0/VLBj+CkJO3XhS45B7Ph1Nnqy2iIQ8RXBeQu4+V0QeMhY2kcYiQrY2kxj75QjCd
iFklxnfhvNAcBXSS1FoUjhwdSGsP4kT4+fOxqJvBO38SWYhHK2o4YaCoHWMs65D/Kq0YJffM
iuWlglF5QxhJ7ZZ3apCBmM5WSwZ92UwlHqAFR0cGap7ARugF0zUtcCe5Gs0zOvPYx7GD6YNO
369PbvYZ7XaKDtQg1kGUglIA3m+w/VuK5fIdvTWMFLt9SjUEb/VuMaVRKuwqeOiVrIXdIFzs
FlbTpLMAAAAAAAA=

--------------ms070501080004020101000001--


From nobody Fri Oct 19 03:12:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F55130DC5; Fri, 19 Oct 2018 03:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NTIaJvgOIFd; Fri, 19 Oct 2018 03:12:36 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 F2F0A12D4EF; Fri, 19 Oct 2018 03:12:35 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9JACTcD007856; Fri, 19 Oct 2018 11:12:33 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59F7E22183; Fri, 19 Oct 2018 11:12:33 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 4DB5622193; Fri, 19 Oct 2018 11:12:33 +0100 (BST)
Received: from 950129200 (4.43.114.87.dyn.plus.net [87.114.43.4]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9JACSFr003602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2018 11:12:29 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Lou Berger'" , "'NetMod WG'" 
Cc: "'NetMod WG Chairs'" 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Date: Fri, 19 Oct 2018 11:12:28 +0100
Message-ID: <09fa01d46794$3ed5b280$bc811780$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQFJ9dTTZRWTPaErQM7R2SR8msbsJ6Y7O+2Q
X-Originating-IP: 87.114.43.4
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24164.006
X-TM-AS-Result: No--7.665-10.0-31-10
X-imss-scan-details: No--7.665-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24164.006
X-TMASE-Result: 10--7.664700-10.000000
X-TMASE-MatchedRID: scwq2vQP8OHxIbpQ8BhdbHuzDvI75j0s6fJcVqdnpZYaQhwHZingDO6Z n+QZcsxtV71IDlHPDpOZUbMadVuNrjgcoj/JqpGbzNY33yIEF4YtHoY2SuDzHeoWVODXAWfczv0 +UmYCZcNP7j/aVCTKPGTfvaWtCHRxePs/Cx1DJd2prpImTnz4ti4tncCojEfcuqWf6Nh7tmF5nf tuVZELM7FadroYgOc/kZOl7WKIImq0P2qkGU0XykY41YX/o/8KtHIYYgLGbjZQSFbL1bvQAVgXe pbcl7r7g1PwvXVqs9W8rdOZO1fY5D0xACSIiW2MtUtb0/dmLALca2SGeqWsXGvWH9nJoxcm9Ckq GHQQwBciZJeucCbJmB5tDeHPbgLK6Hq9RCTLxvsstHmcXeW1eBVSGW4LjW40FYnPSoXfG8eN3TS 5lTtZ8n7cGd19dSFd
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 10:12:38 -0000

Hey Lou,

As an author, I support adoption and would particularly welcome feedback from
the WG to know whether this approach addresses the needs of those writing drafts
for YANG models.

Thanks,
Adrian

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 18 October 2018 14:04
> To: NetMod WG
> Cc: NetMod WG Chairs
> Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)


From nobody Fri Oct 19 03:41:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF981130EBF; Fri, 19 Oct 2018 03:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.563
X-Spam-Level: 
X-Spam-Status: No, score=-14.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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 UBZ_rDuuB8xq; Fri, 19 Oct 2018 03:41:08 -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 5FC99130EED; Fri, 19 Oct 2018 03:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8956; q=dns/txt; s=iport; t=1539945667; x=1541155267; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4wq5i7B+Kq7Wr9RBxocLXL1JsCa/38SpVR370m455EE=; b=MTiSVOsIVlvoc6stI/3d1+24biVGf98+3BIqYcvrtRkb+gz+tspnXr21 n8dU599jh1/WrEpVt73XLrzonoi1X8lcEfrIV+MqaKzmTwLSLKkVAXDYM qxJgRC2nGq8vtR0nbpvOSsSP5ibTGtN5JvKgKps39SZcY0uMowFt2Yp9g c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAACUs8lb/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEOSIEVbRIog3WId40kJZFHhVyBZg0YAQqBdYIORgKFJzg?= =?us-ascii?q?WAQMBAQIBAQJtHAyFOQEBAQEDAQEhSwsMBAsRBAEBAScDAgInHwkIBgEMBgI?= =?us-ascii?q?BAReDBgGCAQ+mVYEuH4UchGAFi2aBQT+BEScMgl+DGwEBgS4BCwcBgyKCVwK?= =?us-ascii?q?eQQmQZgYXgU+Ec4JuJoZTkBWGPYFaIWRxMxoIGxU7gmyLGYU/PjCJJw8Xgic?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,399,1534809600"; d="scan'208,217";a="7361855"
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; 19 Oct 2018 10:41:05 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9JAf4Nl009102; Fri, 19 Oct 2018 10:41:04 GMT
To: adrian@olddog.co.uk, "'Lou Berger'" , "'NetMod WG'" 
Cc: "'NetMod WG Chairs'" 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <09fa01d46794$3ed5b280$bc811780$@olddog.co.uk>
From: Robert Wilton 
Message-ID: <1dbbb6ae-d660-6047-68ac-116dccbe21c4@cisco.com>
Date: Fri, 19 Oct 2018 11:41:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <09fa01d46794$3ed5b280$bc811780$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------B32A31832BED323DDA14A535"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 10:41:13 -0000

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

Hi Adrian, all,

What is the intended scope?

1) Is it just for examples of YANG requests/replies, or in future, 
instance data.  If so, then I think that the solution is useful for this.

2) Or should the WG consider allowing a longer line length for YANG 
modules?  Currently they are limited to something like 69 characters so 
that they can be inserted into the RFC, but possibly with line folding 
we could possibly consider increasing that, but perhaps that would make 
them harder to read/review.

3) I think that there are also cases where tree diagrams wrap and need 
to be constrained to 69 characters.  Although I don't think that 
applying the folding algorithm to tree diagrams directly is necessarily 
a great idea, it might be that tools like pyang could be modified with 
an option to generate output that is consistent with the definition of 
the folded output so that it can be unfolded if required.

To give an example of 3:

Rather than this:

    module: ietf-if-l3-vlan
      augment /if:interfaces/if:interface/if-cmn:encapsulation/
                                                     if-cmn:encaps-type:
        +--:(dot1q-vlan)
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid

the tooling could be modified to optionally generate this instead:

========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
  
   module: ietf-if-l3-vlan
      augment /if:interfaces/if:interface/if-cmn:encapsulation/\
                                                    \if-cmn:encaps-type:
        +--:(dot1q-vlan)
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid

One other question:

How does the algorithm know it has reached the end of the artwork?  I.e. 
should there also be an end line marker?

Thanks,
Rob


On 19/10/2018 11:12, Adrian Farrel wrote:
> Hey Lou,
>
> As an author, I support adoption and would particularly welcome feedback from
> the WG to know whether this approach addresses the needs of those writing drafts
> for YANG models.
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
>> Sent: 18 October 2018 14:04
>> To: NetMod WG
>> Cc: NetMod WG Chairs
>> Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
>>
>> All,
>>
>> This is start of a two week poll on making
>> draft-kwatsen-netmod-artwork-folding-08 a working group
>> document. Please send email to the list indicating "yes/support" or
>> "no/do not support".  If indicating no, please state your reservations
>> with the document.  If yes, please also feel free to provide comments
>> you'd like to see addressed once the document is a WG document.
>>
>> The poll ends Oct 1.
>>
>> Thanks,
>>
>> Lou (and co-chairs)
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------B32A31832BED323DDA14A535
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Adrian, all,

    

    
What is the intended scope?

    
1) Is it just for examples of YANG requests/replies, or in
      future, instance data.  If so, then I think that the solution is
      useful for this.

    
2) Or should the WG consider allowing a longer line length for
      YANG modules?  Currently they are limited to something like 69
      characters so that they can be inserted into the RFC, but possibly
      with line folding we could possibly consider increasing that, but
      perhaps that would make them harder to read/review.

    
3) I think that there are also cases where tree diagrams wrap and
      need to be constrained to 69 characters.  Although I don't think
      that applying the folding algorithm to tree diagrams directly is
      necessarily a great idea, it might be that tools like pyang could
      be modified with an option to generate output that is consistent
      with the definition of the folded output so that it can be
      unfolded if required.

    
To give an example of 3:

    
Rather than this:

    
   module: ietf-if-l3-vlan
     augment /if:interfaces/if:interface/if-cmn:encapsulation/
                                                    if-cmn:encaps-type:
       +--:(dot1q-vlan)
          +--rw dot1q-vlan
             +--rw outer-tag!
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     ieee:vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     ieee:vlanid

    
the tooling could be modified to optionally generate this
      instead:

    
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
 
  module: ietf-if-l3-vlan
     augment /if:interfaces/if:interface/if-cmn:encapsulation/\
                                                   \if-cmn:encaps-type:
       +--:(dot1q-vlan)
          +--rw dot1q-vlan
             +--rw outer-tag!
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     ieee:vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     ieee:vlanid

    
One other question:

    
How does the algorithm know it has reached the end of the
      artwork?  I.e. should there also be an end line marker?

    

    
Thanks,

      Rob

    

    

    
On 19/10/2018 11:12, Adrian Farrel
      wrote:

    

    

      
Hey Lou,

As an author, I support adoption and would particularly welcome feedback from
the WG to know whether this approach addresses the needs of those writing drafts
for YANG models.

Thanks,
Adrian



      

        
-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
Sent: 18 October 2018 14:04
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)


      

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



    

    

  


--------------B32A31832BED323DDA14A535--


From nobody Fri Oct 19 05:44:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855B6130F1C; Fri, 19 Oct 2018 05:44:37 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 Y3yKB47t8q6a; Fri, 19 Oct 2018 05:44:31 -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 75C82130F0F; Fri, 19 Oct 2018 05:44:31 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 42c5G60gskz2y7c; Fri, 19 Oct 2018 14:44:30 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 42c5G572Hfz5vMv; Fri, 19 Oct 2018 14:44:29 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0415.000; Fri, 19 Oct 2018 14:44:29 +0200
From: 
To: Softwires WG , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-boucadair-netmod-softwire-iftunnel-00.txt
Thread-Index: AQHUZ6kQq6f/tBiocEGgdfBYlt5QkaUmgt5A
Date: Fri, 19 Oct 2018 12:44:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E015B0B@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <153995288896.31766.849394504898095624.idtracker@ietfa.amsl.com>
In-Reply-To: <153995288896.31766.849394504898095624.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: [netmod] TR: New Version Notification for draft-boucadair-netmod-softwire-iftunnel-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 12:44:46 -0000

RGVhciBhbGwsDQoNClRoaXMgZHJhZnQgYWRkcyBhbiBleHRlbnNpb24gdG8gdGhlIGludGVyZmFj
ZSBtb2R1bGUgdG8gaWRlbnRpZnkgdGhlIHR1bm5lbCB0eXBlLiANCg0KQ29tbWVudHMgYXJlIG1v
cmUgdGhhbiB3ZWxjb21lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp
Z2luZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxOSBvY3RvYnJlIDIw
MTggMTQ6NDENCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiBPYmpldMKgOiBO
ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvdWNhZGFpci1uZXRtb2Qtc29mdHdp
cmUtDQo+IGlmdHVubmVsLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk
cmFmdC1ib3VjYWRhaXItbmV0bW9kLXNvZnR3aXJlLWlmdHVubmVsLTAwLnR4dA0KPiBoYXMgYmVl
biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWlyIGFuZCBwb3N0ZWQg
dG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC1ib3VjYWRhaXIt
bmV0bW9kLXNvZnR3aXJlLWlmdHVubmVsDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCUEgVHVu
bmVsIEV4dGVuc2lvbiB0byB0aGUgSW50ZXJmYWNlIE1hbmFnZW1lbnQgWUFORyBNb2R1bGUNCj4g
RG9jdW1lbnQgZGF0ZToJMjAxOC0xMC0xOQ0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lv
bg0KPiBQYWdlczoJCTEzDQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p
bnRlcm5ldC1kcmFmdHMvZHJhZnQtYm91Y2FkYWlyLW5ldG1vZC0NCj4gc29mdHdpcmUtaWZ0dW5u
ZWwtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1ib3VjYWRhaXItbmV0bW9kLQ0KPiBzb2Z0d2lyZS1pZnR1bm5lbC8NCj4gSHRt
bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXIt
bmV0bW9kLXNvZnR3aXJlLQ0KPiBpZnR1bm5lbC0wMA0KPiBIdG1saXplZDogICAgICAgaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1ib3VjYWRhaXItbmV0bW9kLQ0K
PiBzb2Z0d2lyZS1pZnR1bm5lbA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3Vt
ZW50IHNwZWNpZmllcyBhbiBleHRlbnNpb24gdGhlIEludGVyZmFjZSBNYW5hZ2VtZW50IFlBTkcN
Cj4gICAgbW9kdWxlLg0KPiANCj4gRWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkgUkZD
IEVkaXRvcikNCj4gDQo+ICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyBpbiB0aGUg
ZG9jdW1lbnQgd2l0aCB0aGUgUkZDIG51bWJlciB0bw0KPiAgICBiZSBhc3NpZ25lZCB0byB0aGlz
IGRvY3VtZW50Og0KPiANCj4gICAgbyAgIlRoaXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9kdWxl
IGlzIHBhcnQgb2YgUkZDIFhYWFg7Ig0KPiANCj4gICAgbyAgIlJGQyBYWFhYOiBBIFR1bm5lbCBF
eHRlbnNpb24gdG8gdGhlIEludGVyZmFjZSBNYW5hZ2VtZW50IFlBTkcNCj4gICAgICAgTW9kdWxl
IjsNCj4gDQo+ICAgIG8gICJyZWZlcmVuY2U6IFJGQyBYWFhYIg0KPiANCj4gICAgUGxlYXNlIHVw
ZGF0ZSB0aGUgInJldmlzaW9uIiBkYXRlIG9mIHRoZSBZQU5HIG1vZHVsZS4NCj4gDQo+IA0KPiAN
Cj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm
cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g
YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRG
IFNlY3JldGFyaWF0DQoNCg==


From nobody Fri Oct 19 05:46:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E579130F19 for ; Fri, 19 Oct 2018 05:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=cyCNlEkU; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ol7Gp8/v
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 Fed9s1rMHvg4 for ; Fri, 19 Oct 2018 05:46:49 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B6D46130F07 for ; Fri, 19 Oct 2018 05:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1539953206; x=1542545206; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+BKdqn50OXGJmVNGzpTLru9G+lTJpW2qQ1VLwZ67+m8=; b=cyCNlEkU/n61U0MJnC/KD3mwJjkpv5+cYsBz+iIVKUNG+EstqAMy7kRzsmhRH9HP JOPlGy03MFRpcJQXnqnLEybc755NDKRGCPzUZjrl85ipA/hAVx6qjzXZtuNeyxVp DSauhdKpVcolQdkm586nWvhCVSTrs7T1czn+tXk9OxU=;
X-AuditID: c1b4fb3a-159ff700000012ff-a6-5bc9d236254c
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.A4.04863.632D9CB5; Fri, 19 Oct 2018 14:46:46 +0200 (CEST)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB504.ericsson.se (153.88.183.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 14:46:46 +0200
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 14:46:46 +0200
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 19 Oct 2018 14:46:46 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/yHqjjZx+7BjwDeQp8Xo0Czo6z9L9pqCeOM4FNvGRQg=; b=Ol7Gp8/v1dg9CrhFRluwWM5jmJNfgLMErVHqG4Gdop6NDRGUf1dWm/oYwR5jDZXvGn+x5YERWN29FIiUDvmrtBw555f90DjXoMYdJZPpJqcVjbDw7BEAH7jycP6pU234kuuNutS4Gef3EZjsfjZo/1+VOg2mH0D5sLErcrTKVUE=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2191.eurprd07.prod.outlook.com (10.169.137.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.13; Fri, 19 Oct 2018 12:46:44 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1250.022; Fri, 19 Oct 2018 12:46:44 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6edTUJh1sqnT0SD+ZwzekOYOaUmhEAA
Date: Fri, 19 Oct 2018 12:46:44 +0000
Message-ID: 
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>
In-Reply-To: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
x-forwarded-message-id: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: HE1PR1001CA0021.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::31) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2191; 6:ghtsxwjRKEfG+dZdOH6WAK92RH6RGo07eVNorn6d9vceyJT0bTKDNWSW6JE4eujYsKXL4PsOXdPzKMr8pf7r9KQvNQOi1IZ51nBE0ikoeben41Agz/LqnkWWUYBDh4GQQ4KybM8fv8IA8LE9YgWpmXGjc9jEwQ3cJBbykXTv/Z2XtAsKM0q+IUqpZYzPxcvVAo9ZzeJnt+Mc3x01n1toZsjg+YYuPzIFuIVBwzbILZzAU9vybUhv2QCZzk21AaTg5AQ7zEAT3wBX/Ho5xWvvQRIT1V9xVFTFQMQJZDFBLB/913+XseXKnHyKTE+SzR7MsV1zVmaxNQ1ogXiHCFTmZKPUfQ8Bi1rkw9gbhb7QrTSEh7CA70cU4qSXUrJLgqM+B4HnRnFsebI53CyR7NIeSP5vVGJoMEaxN6AD+k31QWPMhFOZNll+8F3/aAupmDgQQ1kX542TS3VYivnXl9KM4w==; 5:48AG2UPW4kCSGeYa/K9fJMCCgj/85U7im+OvyK+RY7V688thBapHB3nb8c44UddT1i51KDLdYo8wm7AHvDretHIR6oxACmSHT+jaRXZlyV1aVFmc/16FTJ/KXgBWgXU542ru2XpmPHyQ8J5BZNkkr0MTVrTqmlcwcstGlCKIGdM=; 7:2kBa2alDAtc1mpCuId968wUZ/IZKxc2YqNyYAQeLnFpg4wvQDSmJWmo8Pi9CNEpnGBF8cLkJzBswlRTsXlYo0EdSY6CUE8e1z3upZw1xzDz8VpgjXCDmccieRnPoFGG09mgSrgzrFads/Mn3hvnU6A==
x-ms-office365-filtering-correlation-id: 602c96ce-5c1c-4c31-f2b2-08d635c0ecc5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2191; 
x-ms-traffictypediagnostic: VI1PR0701MB2191:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(50582790962513)(37575265505322)(248295561703944)(120809045254105); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231355)(944501410)(4983020)(52105095)(3002001)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2191; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2191; 
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(39860400002)(366004)(136003)(252514010)(189003)(199004)(31686004)(2501003)(31696002)(86362001)(65826007)(6436002)(97736004)(6486002)(99286004)(105586002)(229853002)(76176011)(106356001)(85202003)(386003)(5660300001)(15650500001)(52116002)(102836004)(25786009)(3260700006)(26005)(5640700003)(85182001)(186003)(5250100002)(6506007)(7736002)(476003)(4001150100001)(486006)(2351001)(68736007)(36756003)(966005)(11346002)(478600001)(2616005)(58126008)(71190400001)(446003)(54896002)(6512007)(2906002)(6306002)(71200400001)(2473003)(236005)(14454004)(606006)(99936001)(3846002)(6116002)(65806001)(6916009)(14444005)(256004)(64126003)(1730700003)(81156014)(53936002)(316002)(81166006)(65956001)(8676002)(66066001)(2900100001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2191; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: e3Rie/l9W3z0OXtVttPoLro09QOsA7z7+b746NdDY8aqx2DR4VagVqUpEfDXrixyjIic2cxwk00698NlUct4AjE5YDqC62YzyAshBWtR52zn3egHjTF+SkB3Hu4vBT9LcyLSjfyjqsp6ZNDG2ON+tT4Gncp2HEQPn19A4YsjKrHidhMtEe389IkRaP8Ats+/xCkGQAEFbX0gaCz+qD3ya95Pof6OuPq8sOWLwKQ4/70G00sEtj8lhDI70P/grsOWzc5N9F75nmCdMpMnW1B4FM1wdFGaYkCgsjuAumgpb0vIZQo6jB35azd8tq8IuxIe8j/7DTehzrrRiaPTWtkMgawkU52PGh5LaXPtZzqSKeo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040303060208010502050800"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 602c96ce-5c1c-4c31-f2b2-08d635c0ecc5
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 12:46:44.4274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2191
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHe7ez49lo8La8PBh+cN3oZqmlQ6OLdCNaBVKaZjbypOKcsjOl SZmllumXYTdnxCaIli01UZwiqBODGd4pU0xQJ5mmYIqXWdbZzoz69nv+///zPO/78lJ8SZfA m0pUaWi1SqGUkiJCH1mfti+ozxp9wD7vLzP03hMcQ2dKS1d4F1GU6HAcrUxMp9X7j1wXJQwb zLxUW8StqsLbWShXno+EFOCDsNjyk8xHIkqC2xE8657hccUigsa+GuJv0VZvdBWlPJi0zztj BNbxwTRpFXDOcx4Y2ldcsXEEuqdzpGMNiU/Aw9lmnoPd8U7QN1Q59c04HDpMP9w4PRyGSgys TrEcAA/MyQ6ZwNvhd325m0MW46Pw6bWPAyVYDqumTEdCiM/DxNtB50CEPWGpw+RcxMdeMGQz 8Lh7usNo7weSYw/4Nr4m4FgKRVNDLr4C3QUfnXkPHAM51mLntQAXIVgoz+NzC65B00iea9Be 6BywIY59oM9QgLiGzySUTOe7NstBN1VJcNyPYOJL5Hrz2ONaUocCi/85bDHbz8eP2LdvtBMO Q4w3gVVvY5lijR1Qliv9P+/gPVBWMs3nOBSK7K0kx77wpGDUjeNDMN0+hzgOhLLKX6QRiSqQ B0MzTHJ8QIAfrU68wTApKj8VralB7M9qrV0NMaPWr8ctCFNIulHcVWuNlggU6Yw22YK2sXPG qt/0IG9ClaKipe5i3zTWFscptBm0OiVWnaakGQvaQhFSL3HYTVmUBMcrNHQSTafS6nWXRwm9 s5AoI/YVNeu5Nefk/djgqyGaO2cjRhpn3auN6Xe/qyt8jDP50oVCodb0rnPX8lJS7otOhZvE 5pkZYa6Tt0j8evqgK2hxQ1tT2Vq8JSosW3c5ezDGa2DZdKrhZU1ds/ICEoYifalN8F5GxUja hkYvyfxOtwxHds4G95/TTnbU9UsJJkHhv5uvZhR/ABfD2F1hAwAA
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 12:46:55 -0000

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


  

    
  
  
    
Hello,

    
A new version of I-D, draft-wu-netmod-factory-default-01.txt has
      been uploaded. Changes include:

    

    
Removed impacts to
      <copy-config> as the reset-datastore=C2=A0 RPC can anyway do =
the
      same thing. 

      Explained the difference between startup and factory-default
      datastores

    
Small corrections.

    


    

    
regards Balazs

      

      -------- Forwarded Message --------
      

        
          

            Sub=
ject:
            
            New Version Notification for
              draft-wu-netmod-factory-default-01.txt
          

          

            Dat=
e: 
            Fri, 19 Oct 2018 05:30:05 -0700
          

          

            Fro=
m: 
            internet-drafts@ietf.org
          

          

            To:=
 
            Ye Niu <niuye@huawei.com>, Qin Wu
              <bill.wu@huawei.com>, Balazs Lengyel
              <balazs.lengyel@ericsson.com>
          

        
      

      

      

      

      A new version of I-D, draft-wu-netmod-factory-default-01.txt

      has been successfully submitted by Balazs Lengyel and posted to
      the

      IETF repository.

      

      Name: draft-wu-netmod-factory-default

      Revision: 01

      Title: Factory default Setting

      Document date: 2018-10-19

      Group: Individual Submission

      Pages: 10

      URL:
https://www.ietf.org/inter=
net-drafts/draft-wu-netmod-factory-default-01.txt

      Status:
      https://datatracker.ietf.org=
/doc/draft-wu-netmod-factory-default/

      Htmlized:
      https://tools.ietf.org/html/draft=
-wu-netmod-factory-default-01

      Htmlized:
      https://datatracker.ietf=
=2Eorg/doc/html/draft-wu-netmod-factory-default

      Diff:
      https://www.ietf.org/rfcd=
iff?url2=3Ddraft-wu-netmod-factory-default-01

      

      Abstract:

      This document defines a method to reset a YANG datastore to its
=

      factory-default content. The reset operation may be used e.g.
      during

      initial zero-touch configuration or when the existing
      configuration

      has major errors, so re-starting the configuration process from
=

      scratch is the best option.

      

      A new reset-datastore RPC is defined. Several methods of
      documenting

      the factory-default content are specified.

      

      Optionally a new "factory-default-running" read-only datastore is
      defined, that contains the data that will be copied over to the
=

      running datastore at reset.

      

      

      

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

      until the htmlized version and diff are available at
      tools.ietf.org.

      

      The IETF Secretariat

      

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20


  



--------------ms040303060208010502050800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTAxOTEyNDY0MFow
LwYJKoZIhvcNAQkEMSIEIP8QDw6QNzhAWThoqXF4XXPw6AoYoz588L9uTrWJcahyMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAGX7gW/iauWUHpTGu6zUbJebsN2aCA7mpOvBAVSFROkUgUec
krDkLqxBrXc3CbLUPJW5nfF1GBuBa3UE9UbGgj48+y4VrC4/GSGDuPAfh1qPXy3m7e4wwbID
IQw02JtjKy6BKwoQyYtAkizDA18r/jx1nIkQEtoEjIXtMXRSaNH1IFpkwIsgQLID6C+1DN4w
Nta2T4wqOXCSaUPW5RbcojefsxDS6A6KDXcB1pZnS791uq151fP4RJE0A2HtDzIbzVJGD5j2
tWSDE2CBzeBpUDhHYt8meXmQLDMDWASpLh5b8+aPq/GwazStOM/oiR0PF3gtH+rPsjJEkBLS
U/8yIz0AAAAAAAA=

--------------ms040303060208010502050800--


From nobody Fri Oct 19 06:57:29 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4D2130F3E for ; Fri, 19 Oct 2018 06:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96iO55ZuyLsN for ; Fri, 19 Oct 2018 06:57:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 DB69B130F39 for ; Fri, 19 Oct 2018 06:57:13 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CCF8B7520DEB2; Fri, 19 Oct 2018 14:57:08 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 14:57:09 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0399.000; Fri, 19 Oct 2018 21:57:04 +0800
From: Qin Wu 
To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AdRnsv6aZPOZiCYmTZm5eOCE2Od9jA==
Date: Fri, 19 Oct 2018 13:57:04 +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.45.95.193]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0B500Cnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 13:57:26 -0000

--_000_B8F9A780D330094D99AF023C5877DABA9B0B500Cnkgeml513mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIEJhbGF6cyBmb3IgdGhlIHVwZGF0ZSwNClRvIG5ldG1vZCBjaGFpcnM6DQpNYXkgSSBy
ZXF1ZXN0ICB0aGUgY2hhaXJzIHRvIHNldCB1cCB0aGUgInJlcGxhY2VkIGJ5IiBpbmZvcm1hdGlv
biBmb3IgdGhpcyBkcmFmdHMgc28gdGhhdCBwZW9wbGUga25vdyB0aGUgbGluayByZWxhdGlvbiBi
ZXR3ZWVuIE5ldGNvbmYgZHJhZnQgYW5kIHRoaXMgbmV0bW9kIG9uZS4NCk1hbnkgdGhhbmtzIQ0K
DQotUWluDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
XSDku6PooaggQmFsw6F6cyBMZW5neWVsDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQxMOaciDE55pel
IDIwOjQ3DQrmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBbbmV0bW9kXSBGd2Q6
IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdC0wMS50eHQNCg0KDQpIZWxsbywNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1
LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0IGhhcyBiZWVuIHVwbG9hZGVkLiBDaGFuZ2Vz
IGluY2x1ZGU6DQpSZW1vdmVkIGltcGFjdHMgdG8gPGNvcHktY29uZmlnPiBhcyB0aGUgcmVzZXQt
ZGF0YXN0b3JlICBSUEMgY2FuIGFueXdheSBkbyB0aGUgc2FtZSB0aGluZy4NCkV4cGxhaW5lZCB0
aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVmYXVsdCBkYXRhc3Rv
cmVzDQpTbWFsbCBjb3JyZWN0aW9ucy4NCg0KcmVnYXJkcyBCYWxhenMNCg0KLS0tLS0tLS0gRm9y
d2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNh
dGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCg0KRGF0ZToN
Cg0KRnJpLCAxOSBPY3QgMjAxOCAwNTozMDowNSAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoN
ClllIE5pdSA8bml1eWVAaHVhd2VpLmNvbT48bWFpbHRvOm5pdXllQGh1YXdlaS5jb20+LCBRaW4g
V3UgPGJpbGwud3VAaHVhd2VpLmNvbT48bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4sIEJhbGF6
cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PG1haWx0bzpiYWxhenMubGVu
Z3llbEBlcmljc3Nvbi5jb20+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13
dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1
Ym1pdHRlZCBieSBCYWxhenMgTGVuZ3llbCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0
b3J5Lg0KDQpOYW1lOiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0DQpSZXZpc2lvbjog
MDENClRpdGxlOiBGYWN0b3J5IGRlZmF1bHQgU2V0dGluZw0KRG9jdW1lbnQgZGF0ZTogMjAxOC0x
MC0xOQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEwDQpVUkw6IGh0dHBz
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1k
ZWZhdWx0LTAxLnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0Lw0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxDQpIdG1saXpl
ZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1uZXRtb2Qt
ZmFjdG9yeS1kZWZhdWx0DQpEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9
ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMQ0KDQpBYnN0cmFjdDoNClRoaXMgZG9j
dW1lbnQgZGVmaW5lcyBhIG1ldGhvZCB0byByZXNldCBhIFlBTkcgZGF0YXN0b3JlIHRvIGl0cw0K
ZmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQuIFRoZSByZXNldCBvcGVyYXRpb24gbWF5IGJlIHVzZWQg
ZS5nLiBkdXJpbmcNCmluaXRpYWwgemVyby10b3VjaCBjb25maWd1cmF0aW9uIG9yIHdoZW4gdGhl
IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24NCmhhcyBtYWpvciBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5n
IHRoZSBjb25maWd1cmF0aW9uIHByb2Nlc3MgZnJvbQ0Kc2NyYXRjaCBpcyB0aGUgYmVzdCBvcHRp
b24uDQoNCkEgbmV3IHJlc2V0LWRhdGFzdG9yZSBSUEMgaXMgZGVmaW5lZC4gU2V2ZXJhbCBtZXRo
b2RzIG9mIGRvY3VtZW50aW5nDQp0aGUgZmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQgYXJlIHNwZWNp
ZmllZC4NCg0KT3B0aW9uYWxseSBhIG5ldyAiZmFjdG9yeS1kZWZhdWx0LXJ1bm5pbmciIHJlYWQt
b25seSBkYXRhc3RvcmUgaXMNCmRlZmluZWQsIHRoYXQgY29udGFpbnMgdGhlIGRhdGEgdGhhdCB3
aWxsIGJlIGNvcGllZCBvdmVyIHRvIHRoZQ0KcnVubmluZyBkYXRhc3RvcmUgYXQgcmVzZXQuDQoN
Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv
bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg
ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh
cmlhdA0KDQotLQ0KDQpCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nz
b24gSHVuZ2FyeSBMdGQuDQoNClNlbmlvciBTcGVjaWFsaXN0DQoNCk1vYmlsZTogKzM2LTcwLTMz
MC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1h
aWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20+DQo=

--_000_B8F9A780D330094D99AF023C5877DABA9B0B500Cnkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x
OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/p
m4Xpu5E7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiXEDlvq7ova/pm4Xpu5EiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIg
MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byP
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRN
TENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw
dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PlRoYW5rcyBCYWxhenMgZm9yIHRoZSB1cGRhdGUsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlRvIG5ldG1vZCBjaGFpcnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N
YXkgSSByZXF1ZXN0ICZuYnNwO3RoZSBjaGFpcnMgdG8gc2V0IHVwIHRoZSAmcXVvdDtyZXBsYWNl
ZCBieSZxdW90OyBpbmZvcm1hdGlvbiBmb3IgdGhpcyBkcmFmdHMgc28gdGhhdCBwZW9wbGUga25v
dyB0aGUgbGluayByZWxhdGlvbiBiZXR3ZWVuIE5ldGNvbmYgZHJhZnQgYW5kDQogdGhpcyBuZXRt
b2Qgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MhPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4
dCI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7
kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPuS7o+ihqA0KPC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+QmFsPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9
r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPsOhPHNwYW4gbGFuZz0i
RU4tVVMiPnpzIExlbmd5ZWw8YnI+DQo8L3NwYW4+PGI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0i
RU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gMjAxODwvc3Bhbj7lubQ8c3Bh
biBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE5PC9zcGFuPuaX
pTxzcGFuIGxhbmc9IkVOLVVTIj4gMjA6NDc8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g
bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kQGlldGYu
b3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyI+IFtuZXRtb2RdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u
IGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxvOnA+PC9vOnA+PC9z
cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh
bmc9IkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF
Ti1VUyI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1
bHQtMDEudHh0IGhhcyBiZWVuIHVwbG9hZGVkLiBDaGFuZ2VzIGluY2x1ZGU6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5SZW1vdmVkIGltcGFjdHMgdG8gJmx0O2NvcHktY29uZmlnJmd0OyBhcyB0aGUgcmVzZXQtZGF0
YXN0b3JlJm5ic3A7IFJQQyBjYW4gYW55d2F5IGRvIHRoZSBzYW1lIHRoaW5nLg0KPGJyPg0KRXhw
bGFpbmVkIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gc3RhcnR1cCBhbmQgZmFjdG9yeS1kZWZhdWx0
IGRhdGFzdG9yZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U21hbGwgY29ycmVjdGlvbnMuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWdhcmRzIEJhbGF6
czxicj4NCjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg
Y2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dy
YXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48
Yj48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+
DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv
ciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5
bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5E
YXRlOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp
bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj5GcmksIDE5IE9jdCAyMDE4IDA1OjMwOjA1IC0wNzAwPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0i
cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp
Z2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow
Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N
Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu
OnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+VG86DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+
PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllIE5pdSA8YSBocmVmPSJtYWlsdG86
bml1eWVAaHVhd2VpLmNvbSI+DQombHQ7bml1eWVAaHVhd2VpLmNvbSZndDs8L2E+LCBRaW4gV3Ug
PGEgaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+Jmx0O2JpbGwud3VAaHVhd2VpLmNv
bSZndDs8L2E+LCBCYWxhenMgTGVuZ3llbA0KPGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVs
QGVyaWNzc29uLmNvbSI+Jmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZndDs8L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13
dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs
eSBzdWJtaXR0ZWQgYnkgQmFsYXpzIExlbmd5ZWwgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRG
IHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdDxicj4NClJldmlzaW9uOiAwMTxicj4NClRpdGxlOiBGYWN0b3J5IGRlZmF1bHQgU2V0dGlu
Zzxicj4NCkRvY3VtZW50IGRhdGU6IDIwMTgtMTAtMTk8YnI+DQpHcm91cDogSW5kaXZpZHVhbCBT
dWJtaXNzaW9uPGJyPg0KUGFnZXM6IDEwPGJyPg0KVVJMOiA8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0w
MS50eHQiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PC9hPjxicj4NClN0YXR1czogPGEgaHJlZj0iaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdC8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9k
LWZhY3RvcnktZGVmYXVsdC88L2E+PGJyPg0KSHRtbGl6ZWQ6IDxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxIj4NCmh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0
LTAxPC9hPjxicj4NCkh0bWxpemVkOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQiPg0KaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZh
dWx0PC9hPjxicj4NCkRpZmY6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/
dXJsMj1kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxIj4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxPC9h
Pjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhv
ZCB0byByZXNldCBhIFlBTkcgZGF0YXN0b3JlIHRvIGl0czxicj4NCmZhY3RvcnktZGVmYXVsdCBj
b250ZW50LiBUaGUgcmVzZXQgb3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nPGJyPg0K
aW5pdGlhbCB6ZXJvLXRvdWNoIGNvbmZpZ3VyYXRpb24gb3Igd2hlbiB0aGUgZXhpc3RpbmcgY29u
ZmlndXJhdGlvbjxicj4NCmhhcyBtYWpvciBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5nIHRoZSBjb25m
aWd1cmF0aW9uIHByb2Nlc3MgZnJvbTxicj4NCnNjcmF0Y2ggaXMgdGhlIGJlc3Qgb3B0aW9uLjxi
cj4NCjxicj4NCkEgbmV3IHJlc2V0LWRhdGFzdG9yZSBSUEMgaXMgZGVmaW5lZC4gU2V2ZXJhbCBt
ZXRob2RzIG9mIGRvY3VtZW50aW5nPGJyPg0KdGhlIGZhY3RvcnktZGVmYXVsdCBjb250ZW50IGFy
ZSBzcGVjaWZpZWQuPGJyPg0KPGJyPg0KT3B0aW9uYWxseSBhIG5ldyAmcXVvdDtmYWN0b3J5LWRl
ZmF1bHQtcnVubmluZyZxdW90OyByZWFkLW9ubHkgZGF0YXN0b3JlIGlzPGJyPg0KZGVmaW5lZCwg
dGhhdCBjb250YWlucyB0aGUgZGF0YSB0aGF0IHdpbGwgYmUgY29waWVkIG92ZXIgdG8gdGhlPGJy
Pg0KcnVubmluZyBkYXRhc3RvcmUgYXQgcmVzZXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxl
YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp
bWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhlIElFVEYgU2Vj
cmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0i
RU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V
UyI+QmFsYXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24gSHVuZ2FyeSBMdGQu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW5pb3Ig
U3BlY2lhbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V
UyI+TW9iaWxlOiAmIzQzOzM2LTcwLTMzMC03OTA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVtYWls
OiA8YSBocmVmPSJtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tIj5CYWxhenMuTGVu
Z3llbEBlcmljc3Nvbi5jb208L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B8F9A780D330094D99AF023C5877DABA9B0B500Cnkgeml513mbxchi_--


From nobody Fri Oct 19 11:57:58 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B97131056; Fri, 19 Oct 2018 11:56:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: ibagdona@gmail.com, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153997538693.6592.2897211631795121762.idtracker@ietfa.amsl.com>
Date: Fri, 19 Oct 2018 11:56:26 -0700
Archived-At: 
Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 103
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 18:56:34 -0000

Dear Lou Berger,

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


    netmod Session 1 (2:00 requested)
    Tuesday, 6 November 2018, Morning Session I 0900-1100
    Room Name: Chitlada 2 size: 250
    ---------------------------------------------
    netmod Session 2 (2:00 requested)
    Thursday, 8 November 2018, Afternoon Session II 1610-1810
    Room Name: Chitlada 2 size: 250
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/103/sessions/netmod.ics

Request Information:


---------------------------------------------------------
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf
 Second Priority: teas i2rs anima rtgwg
 Third Priority: saag


People who must be present:
  Lou Berger
  Joel Jaeggli
  Kent Watsen
  Ignas Bagdonas

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Fri Oct 19 12:25:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646C7130DD1 for ; Fri, 19 Oct 2018 12:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.235
X-Spam-Level: *
X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq1Jp-PYH4H7 for ; Fri, 19 Oct 2018 12:25:30 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 52EA0130FF3 for ; Fri, 19 Oct 2018 12:25:30 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9JJOA3S016545; Fri, 19 Oct 2018 12:25:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=5mO2BB7lD8sLeYujrD0A9Mgqa/PISo0SD7dJIRZoMsg=; b=PMqTfsJhd01qRnMHy/t9V7b33bhr5fEc1B95giaNRVhgqMiEZx7iIYU2EIjVVVaXV9IT UQzaEeO10RghqglTzJ/0uLRXCsixy5ZAKaam+ZmO6rKNd2nPPT62A96o90Xith4tkxhT 3iEDncGhR65iC8S1Gq6d+CU1DxLtf2x87RAaHJHIs6B+cbvH5hAjYCABr9QPK7+SeqR7 gG697nyREkusWC7FnnglxuQo+4Lm/MrSe+FuqLrQRgQPxeOH9eRkU4AMRR3qGG/HBUj9 jKq+qbFDX/yvv83AKmqvxIbiy66NCrwLSMGlvnZ3M5O0EpKuLA2iKQFUpSE+UE6l9rSz 1Q== 
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0081.outbound.protection.outlook.com [216.32.180.81]) by mx0a-00273201.pphosted.com with ESMTP id 2n7jkng9ah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Oct 2018 12:25:23 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4330.namprd05.prod.outlook.com (20.176.78.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.15; Fri, 19 Oct 2018 19:25:21 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%4]) with mapi id 15.20.1250.020; Fri, 19 Oct 2018 19:25:21 +0000
From: Kent Watsen 
To: Qin Wu , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ+F5NXwiySyZjU+/Mcm5DTxHNQ==
Date: Fri, 19 Oct 2018 19:25:21 +0000
Message-ID: <0E11B85E-97AA-49FD-96BC-088625F0100E@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4330; 6:yQG1WJSSPgs2S3WriDwRU/XJVRKdKzdWU4DNW9MUBK/vNgRaQ/pmxl8azjYvjvLAn1j1BvhwtGI8Az0XDMynqb9yqMDaLrvaXgvuTMNpm8ZkEL20xZV25e+sxNdQ5OyxRFMG8N/LJ0IWBMAVUR122nI67DyWsnozrUbI4LIcolBFnT2sXNlnBer96Agai5IJyFJkw1AQxc7UScFTdsnxJZv0ggrCyo2nbftlaP/an0kn729505HUwMIbs402kHil2p2unXixOIaJt3jm7ri9vFNQt00c0QYLlXo2DFl6hs1Lm0NyRhfnycBcUi6CgwJIzLAayEIwWZgMrtVXoIpEa2ob0Ten+3PZlWbfiqlEgptX9Cqc3jzY3EGgAaqQcJpEKjkzQpe0fMd9OHQYjPnqQR3Gck4TR0b8pXUfF6ur7MSBDYU3HD3iZmACCuT+Sir6Sku+7SxsIb3sQoHlErICDQ==; 5:0lakxUNVozic9mUPY/5XADloMVZ3qZmThG3fyN+J2tgOc+DeAEB9uV6j6fTppR1yJ7Ae2yv4bLCOQ+RGIZxhVPmDz5lny2k+1ovm/scLyb3flzsP5v8rb2WnjXnoCbLbTRmp+LKrgnG36TY+kBboAfsCjARe7ixwiOJOhPqpt04=; 7:Ag1J11J2u/vvYWPwDJsrpzNfwkqPIl83v3PL9BJxfWIIX7u8Wp1l/0p8k7BFkDOqxneCjmw43TtoxfHMWTTLUhf/L/LlnM/Rsd583enVH+QoJAylGAwB5FhJXCZIfdbRwQJs2tqoI1QaeE4EySG2dmKAblNRl4Ied6iI9AD7OEQHfBzDCc21KjX4m1pgiVcw6ba5vwXC2HY1tc7p6LjatVPHD1v7DZE9HYa6s0UF9AJ8rlgRA/q3DcZW3hpMYmqz
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b9073d34-0c18-4dba-f59e-08d635f89c75
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4330; 
x-ms-traffictypediagnostic: DM6PR05MB4330:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(50582790962513)(248295561703944)(37575265505322)(120809045254105)(21748063052155)(28532068793085)(190501279198761)(227612066756510)(10436049006162)(163750095850);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4330; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4330; 
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(39860400002)(396003)(366004)(189003)(199004)(252514010)(71190400001)(2906002)(83716004)(81156014)(81166006)(97736004)(4001150100001)(2900100001)(606006)(9326002)(966005)(14454004)(478600001)(26005)(66574009)(6346003)(71200400001)(3846002)(8676002)(186003)(6116002)(82746002)(6506007)(15650500001)(8936002)(54896002)(6306002)(2420400007)(6246003)(58126008)(110136005)(14444005)(53936002)(256004)(316002)(53546011)(102836004)(2501003)(68736007)(5250100002)(66066001)(6512007)(236005)(36756003)(6486002)(106356001)(7110500001)(6436002)(5660300001)(33656002)(105586002)(86362001)(99286004)(229853002)(25786009)(7736002)(476003)(486006)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4330; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: WrrMQCPdG/BDYEer7Qcii+hlOW90kqv1GYKX92RsjBgWh0X+CvrKbORrHjXWoqUG3m/nzU+MKm36pTxhTG3W9FrpFMGSZcwByFLG1kx/wUEvdpDMMg5TF+561Nm3yHrxvtQsVgHNT/vtUyfIKXk16r5DqZFvT7Wan59b3g0KR5RnSwZjPXgaph1FvhgoEc0VXj5VMUXv5V2NaHBXWb7XeMmDvha9BzhkQ2bmNWgzEWbKV09HJVmJq45ehSd5+Q7vDeUvZTFDKicykUkA2nbOrGrObh6FgP2Ek4k+HqEin8QIUG9vgXtcEPxC0RLar8HD7s69Gps+TM2Cu0gpP3RKu9TIXHtZR9goCkCQOGRewT0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0E11B85E97AA49FD96BC088625F0100Ejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b9073d34-0c18-4dba-f59e-08d635f89c75
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 19:25:21.1235 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4330
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810190172
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 19:25:32 -0000

--_000_0E11B85E97AA49FD96BC088625F0100Ejunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUWluLA0KDQpBRklBQ1QsIHRoZSDigJxyZXBsYWNlc+KAnSBidXR0b24gaXMgb25seSBhdmFp
bGFibGUgZm9yIGFkb3B0ZWQgKGkuZS4sIOKAnC1pZXRm4oCdKSBkb2N1bWVudHMuDQoNCktlbnQN
Cg0KDQpPbiAxMC8xOS8xOCwgOTo1NyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUWluIFd1IiA8
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBv
biBiZWhhbGYgb2YgYmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+
PiB3cm90ZToNCg0KVGhhbmtzIEJhbGF6cyBmb3IgdGhlIHVwZGF0ZSwNClRvIG5ldG1vZCBjaGFp
cnM6DQpNYXkgSSByZXF1ZXN0ICB0aGUgY2hhaXJzIHRvIHNldCB1cCB0aGUgInJlcGxhY2VkIGJ5
IiBpbmZvcm1hdGlvbiBmb3IgdGhpcyBkcmFmdHMgc28gdGhhdCBwZW9wbGUga25vdyB0aGUgbGlu
ayByZWxhdGlvbiBiZXR3ZWVuIE5ldGNvbmYgZHJhZnQgYW5kIHRoaXMgbmV0bW9kIG9uZS4NCk1h
bnkgdGhhbmtzIQ0KDQotUWluDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnXSDku6PooaggQmFsw6F6cyBMZW5neWVsDQrlj5HpgIHml7bpl7Q6IDIwMTjl
ubQxMOaciDE55pelIDIwOjQ3DQrmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBb
bmV0bW9kXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9k
LWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCg0KDQpIZWxsbywNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0IGhhcyBiZWVuIHVwbG9h
ZGVkLiBDaGFuZ2VzIGluY2x1ZGU6DQpSZW1vdmVkIGltcGFjdHMgdG8gPGNvcHktY29uZmlnPiBh
cyB0aGUgcmVzZXQtZGF0YXN0b3JlICBSUEMgY2FuIGFueXdheSBkbyB0aGUgc2FtZSB0aGluZy4N
CkV4cGxhaW5lZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVm
YXVsdCBkYXRhc3RvcmVzDQpTbWFsbCBjb3JyZWN0aW9ucy4NCg0KcmVnYXJkcyBCYWxhenMNCg0K
LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50
eHQNCg0KRGF0ZToNCg0KRnJpLCAxOSBPY3QgMjAxOCAwNTozMDowNSAtMDcwMA0KDQpGcm9tOg0K
DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
Zz4NCg0KVG86DQoNClllIE5pdSA8bml1eWVAaHVhd2VpLmNvbT48bWFpbHRvOm5pdXllQGh1YXdl
aS5jb20+LCBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT48bWFpbHRvOmJpbGwud3VAaHVhd2Vp
LmNvbT4sIEJhbGF6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PG1haWx0
bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KaGFzIGJlZW4gc3Vj
Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCYWxhenMgTGVuZ3llbCBhbmQgcG9zdGVkIHRvIHRoZQ0K
SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0
DQpSZXZpc2lvbjogMDENClRpdGxlOiBGYWN0b3J5IGRlZmF1bHQgU2V0dGluZw0KRG9jdW1lbnQg
ZGF0ZTogMjAxOC0xMC0xOQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEw
DQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRt
b2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pbnRlcm5ldC0yRGRyYWZ0c19kcmFm
dC0yRHd1LTJEbmV0bW9kLTJEZmFjdG9yeS0yRGRlZmF1bHQtMkQwMS50eHQmZD1Ed01HYVEmYz1I
QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpH
SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWxONE9uNnRkZFNKdUQ3RmhoRTRaXzV3
aXlPaGJuR0tXdW9UdVpZWFpvVWMmcz1hY0JsOGlGN0txUFJYZkhXTXRaX2d5Y1NSYkRnR1pzNHVk
TEtCWjhoWWdBJmU9Pg0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFm
dC0yRHd1LTJEbmV0bW9kLTJEZmFjdG9yeS0yRGRlZmF1bHRfJmQ9RHdNR2FRJmM9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1sTjRPbjZ0ZGRTSnVEN0ZoaEU0Wl81d2l5T2hibkdL
V3VvVHVaWVhab1VjJnM9aExfUG9meW9jTVZUak1fM2RPRWxJbnNrcXFydVR6SmJfUl9NY0dNcy15
WSZlPT4NCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkR3dS0yRG5ldG1v
ZC0yRGZhY3RvcnktMkRkZWZhdWx0LTJEMDEmZD1Ed01HYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh
R1R2aklTbGFKZGNabyZtPWxONE9uNnRkZFNKdUQ3RmhoRTRaXzV3aXlPaGJuR0tXdW9UdVpZWFpv
VWMmcz1KMUltQkJPSDB3ZkJqMy1ubGprVGRvQThvdWFrcHVHS194blR1LVNEWmRnJmU9Pg0KSHRt
bGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0LTJEd3Ut
MkRuZXRtb2QtMkRmYWN0b3J5LTJEZGVmYXVsdCZkPUR3TUdhUSZjPUhBa1l1aDYzcnN1aHI2U2Ni
ZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJm09bE40T242dGRkU0p1RDdGaGhFNFpfNXdpeU9oYm5HS1d1b1R1WllY
Wm9VYyZzPXNsXzdCbE1mT3VqOXdyZUxER25OdUJuWWN0cldIdE1NblYzNTgxMFhGNjgmZT0+DQpE
aWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdC0wMTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0zRGRyYWZ0LTJEd3UtMkRu
ZXRtb2QtMkRmYWN0b3J5LTJEZGVmYXVsdC0yRDAxJmQ9RHdNR2FRJmM9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mbT1sTjRPbjZ0ZGRTSnVEN0ZoaEU0Wl81d2l5T2hibkdLV3VvVHVa
WVhab1VjJnM9WlBMVUlBZm5NeHZXdTZYcEQxOVpPYUlqOTE5clBqeUFFVzVOT3h6TnVDUSZlPT4N
Cg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBZ
QU5HIGRhdGFzdG9yZSB0byBpdHMNCmZhY3RvcnktZGVmYXVsdCBjb250ZW50LiBUaGUgcmVzZXQg
b3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nDQppbml0aWFsIHplcm8tdG91Y2ggY29u
ZmlndXJhdGlvbiBvciB3aGVuIHRoZSBleGlzdGluZyBjb25maWd1cmF0aW9uDQpoYXMgbWFqb3Ig
ZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlvbiBwcm9jZXNzIGZyb20NCnNj
cmF0Y2ggaXMgdGhlIGJlc3Qgb3B0aW9uLg0KDQpBIG5ldyByZXNldC1kYXRhc3RvcmUgUlBDIGlz
IGRlZmluZWQuIFNldmVyYWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZw0KdGhlIGZhY3RvcnktZGVm
YXVsdCBjb250ZW50IGFyZSBzcGVjaWZpZWQuDQoNCk9wdGlvbmFsbHkgYSBuZXcgImZhY3Rvcnkt
ZGVmYXVsdC1ydW5uaW5nIiByZWFkLW9ubHkgZGF0YXN0b3JlIGlzDQpkZWZpbmVkLCB0aGF0IGNv
bnRhaW5zIHRoZSBkYXRhIHRoYXQgd2lsbCBiZSBjb3BpZWQgb3ZlciB0byB0aGUNCnJ1bm5pbmcg
ZGF0YXN0b3JlIGF0IHJlc2V0Lg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhl
IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y
Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KLS0NCg0KQmFsYXpzIExlbmd5ZWwgICAgICAg
ICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KDQpTZW5pb3IgU3BlY2lhbGlz
dA0KDQpNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5M
ZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPg0K

--_000_0E11B85E97AA49FD96BC088625F0100Ejunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <810FF3928D65E04580A9DCCCDBB9D28F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg
NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K
CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx
IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7DQoJcGFub3NlLTE6
MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47
DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7fQ0KcC5t
c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt
ZTptc29ub3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2lt
U3VuOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv
bnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNv
LXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDp
ooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu
vuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpz
cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls
ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv
cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v
bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEu
MGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjp3aW5kb3d0ZXh0Ij5IaSBRaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkFGSUFDVCwgdGhlIOKA
nHJlcGxhY2Vz4oCdIGJ1dHRvbiBpcyBvbmx5IGF2YWlsYWJsZSBmb3IgYWRvcHRlZCAoaS5lLiwg
4oCcLWlldGbigJ0pIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+S2VudDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIDEwLzE5LzE4LCA5OjU3IEFNLCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmIG9m
IFFpbiBXdSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
Ij5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWls
dG86YmlsbC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPlRoYW5rcyBCYWxhenMgZm9yIHRoZSB1cGRhdGUsDQo8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+VG8gbmV0bW9kIGNoYWlyczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWF5IEkgcmVxdWVzdCAmbmJz
cDt0aGUgY2hhaXJzIHRvIHNldCB1cCB0aGUgJnF1b3Q7cmVwbGFjZWQgYnkmcXVvdDsgaW5mb3Jt
YXRpb24gZm9yIHRoaXMgZHJhZnRzIHNvIHRoYXQgcGVvcGxlIGtub3cgdGhlIGxpbmsgcmVsYXRp
b24gYmV0d2VlbiBOZXRjb25mIGRyYWZ0IGFuZCB0aGlzIG5ldG1vZA0KIG9uZS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+TWFueSB0aGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4tUWluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2NvbG9yOndp
bmRvd3RleHQiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OuW+rui9r+mbhem7kTtjb2xvcjp3aW5kb3d0ZXh0Ij4gbmV0bW9kIFttYWlsdG86bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Luj6KGoPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7Y29sb3I6d2luZG93dGV4
dCI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OuW+rui9r+mbhem7kTtjb2xvcjp3aW5kb3d0ZXh0Ij5CYWzDoXpzIExlbmd5ZWw8YnI+DQo8L3Nw
YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R
6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTrlvq7ova/pm4Xpu5E7Y29sb3I6d2luZG93dGV4dCI+Ojwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2NvbG9yOndp
bmRvd3RleHQiPiAyMDE4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y
OndpbmRvd3RleHQiPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTrlvq7ova/pm4Xpu5E7Y29sb3I6d2luZG93dGV4dCI+MTA8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5pyIPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTtjb2xvcjp3aW5k
b3d0ZXh0Ij4xOTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjp3aW5k
b3d0ZXh0Ij7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk65b6u6L2v6ZuF6buRO2NvbG9yOndpbmRvd3RleHQiPg0KIDIwOjQ3PGJyPg0KPC9zcGFuPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPuaUtuS7tuS6
ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
5b6u6L2v6ZuF6buRO2NvbG9yOndpbmRvd3RleHQiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTtjb2xvcjp3aW5kb3d0ZXh0
Ij4gbmV0bW9kQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2NvbG9yOndpbmRvd3Rl
eHQiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OuW+rui9r+mbhem7kTtjb2xvcjp3aW5kb3d0ZXh0Ij4gW25ldG1vZF0gRndkOiBOZXcgVmVyc2lv
biBOb3RpZmljYXRpb24gZm9yDQogZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50
eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxw
PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAx
LnR4dCBoYXMgYmVlbiB1cGxvYWRlZC4gQ2hhbmdlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbW92ZWQgaW1wYWN0cyB0byAmbHQ7Y29weS1j
b25maWcmZ3Q7IGFzIHRoZSByZXNldC1kYXRhc3RvcmUmbmJzcDsgUlBDIGNhbiBhbnl3YXkgZG8g
dGhlIHNhbWUgdGhpbmcuDQo8YnI+DQpFeHBsYWluZWQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBz
dGFydHVwIGFuZCBmYWN0b3J5LWRlZmF1bHQgZGF0YXN0b3JlczxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U21hbGwgY29ycmVjdGlvbnMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlZ2FyZHMg
QmFsYXpzPGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0gPG86
cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl
bGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFw
PSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+
U3ViamVjdDogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzow
aW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3IFZlcnNpb24gTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBz
dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPC9iPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+RnJpLCAxOSBPY3QgMjAxOCAwNTozMDowNSAtMDcwMDxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBz
dHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp
Z249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPC9iPjxvOnA+PC9v
OnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwv
dHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4g
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i
dGV4dC1hbGlnbjpyaWdodCI+PGI+VG86IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQg
c3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlll
IE5pdSA8YSBocmVmPSJtYWlsdG86bml1eWVAaHVhd2VpLmNvbSI+Jmx0O25pdXllQGh1YXdlaS5j
b20mZ3Q7PC9hPiwgUWluIFd1DQo8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj4m
bHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0OzwvYT4sIEJhbGF6cyBMZW5neWVsIDxhIGhyZWY9Im1h
aWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20iPg0KJmx0O2JhbGF6cy5sZW5neWVsQGVy
aWNzc29uLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+
DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi
bWl0dGVkIGJ5IEJhbGF6cyBMZW5neWVsIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBv
c2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6IGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQ8
YnI+DQpSZXZpc2lvbjogMDE8YnI+DQpUaXRsZTogRmFjdG9yeSBkZWZhdWx0IFNldHRpbmc8YnI+
DQpEb2N1bWVudCBkYXRlOiAyMDE4LTEwLTE5PGJyPg0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlz
c2lvbjxicj4NClBhZ2VzOiAxMDxicj4NClVSTDogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQt
MkRkcmFmdHNfZHJhZnQtMkR3dS0yRG5ldG1vZC0yRGZhY3RvcnktMkRkZWZhdWx0LTJEMDEudHh0
JmFtcDtkPUR3TUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY
Y1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8m
YW1wO209bE40T242dGRkU0p1RDdGaGhFNFpfNXdpeU9oYm5HS1d1b1R1WllYWm9VYyZhbXA7cz1h
Y0JsOGlGN0txUFJYZkhXTXRaX2d5Y1NSYkRnR1pzNHVkTEtCWjhoWWdBJmFtcDtlPSI+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9kLWZhY3Rvcnkt
ZGVmYXVsdC0wMS50eHQ8L2E+PGJyPg0KU3RhdHVzOiA8YSBocmVmPSJodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3Jn
X2RvY19kcmFmdC0yRHd1LTJEbmV0bW9kLTJEZmFjdG9yeS0yRGRlZmF1bHRfJmFtcDtkPUR3TUdh
USZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDty
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209bE40T242
dGRkU0p1RDdGaGhFNFpfNXdpeU9oYm5HS1d1b1R1WllYWm9VYyZhbXA7cz1oTF9Qb2Z5b2NNVlRq
TV8zZE9FbEluc2txcXJ1VHpKYl9SX01jR01zLXlZJmFtcDtlPSI+DQpodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LzwvYT48YnI+
DQpIdG1saXplZDogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEd3UtMkRuZXRtb2Qt
MkRmYWN0b3J5LTJEZGVmYXVsdC0yRDAxJmFtcDtkPUR3TUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhy
NlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209bE40T242dGRkU0p1RDdGaGhFNFpfNXdpeU9o
Ym5HS1d1b1R1WllYWm9VYyZhbXA7cz1KMUltQkJPSDB3ZkJqMy1ubGprVGRvQThvdWFrcHVHS194
blR1LVNEWmRnJmFtcDtlPSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3Ut
bmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMTwvYT48YnI+DQpIdG1saXplZDogPGEgaHJlZj0iaHR0
cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJh
Y2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRHd1LTJEbmV0bW9kLTJEZmFjdG9yeS0yRGRl
ZmF1bHQmYW1wO2Q9RHdNR2FRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZhbXA7bT1sTjRPbjZ0ZGRTSnVEN0ZoaEU0Wl81d2l5T2hibkdLV3VvVHVaWVhab1VjJmFt
cDtzPXNsXzdCbE1mT3VqOXdyZUxER25OdUJuWWN0cldIdE1NblYzNTgxMFhGNjgmYW1wO2U9Ij4N
Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdDwvYT48YnI+DQpEaWZmOiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNG
dXJsMi0zRGRyYWZ0LTJEd3UtMkRuZXRtb2QtMkRmYWN0b3J5LTJEZGVmYXVsdC0yRDAxJmFtcDtk
PUR3TUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJ
JmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209
bE40T242dGRkU0p1RDdGaGhFNFpfNXdpeU9oYm5HS1d1b1R1WllYWm9VYyZhbXA7cz1aUExVSUFm
bk14dld1NlhwRDE5Wk9hSWo5MTlyUGp5QUVXNU5PeHpOdUNRJmFtcDtlPSI+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0w
MTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBt
ZXRob2QgdG8gcmVzZXQgYSBZQU5HIGRhdGFzdG9yZSB0byBpdHM8YnI+DQpmYWN0b3J5LWRlZmF1
bHQgY29udGVudC4gVGhlIHJlc2V0IG9wZXJhdGlvbiBtYXkgYmUgdXNlZCBlLmcuIGR1cmluZzxi
cj4NCmluaXRpYWwgemVyby10b3VjaCBjb25maWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5n
IGNvbmZpZ3VyYXRpb248YnI+DQpoYXMgbWFqb3IgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUg
Y29uZmlndXJhdGlvbiBwcm9jZXNzIGZyb208YnI+DQpzY3JhdGNoIGlzIHRoZSBiZXN0IG9wdGlv
bi48YnI+DQo8YnI+DQpBIG5ldyByZXNldC1kYXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuIFNldmVy
YWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZzxicj4NCnRoZSBmYWN0b3J5LWRlZmF1bHQgY29udGVu
dCBhcmUgc3BlY2lmaWVkLjxicj4NCjxicj4NCk9wdGlvbmFsbHkgYSBuZXcgJnF1b3Q7ZmFjdG9y
eS1kZWZhdWx0LXJ1bm5pbmcmcXVvdDsgcmVhZC1vbmx5IGRhdGFzdG9yZSBpczxicj4NCmRlZmlu
ZWQsIHRoYXQgY29udGFpbnMgdGhlIGRhdGEgdGhhdCB3aWxsIGJlIGNvcGllZCBvdmVyIHRvIHRo
ZTxicj4NCnJ1bm5pbmcgZGF0YXN0b3JlIGF0IHJlc2V0Ljxicj4NCjxicj4NCjxicj4NCjxicj4N
ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo
ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg
ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCjxicj4NClRoZSBJRVRG
IFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmU+LS0gPG86cD48L286cD48
L3ByZT4NCjxwcmU+QmFsYXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24gSHVu
Z2FyeSBMdGQuPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5Nb2JpbGU6ICYjNDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5j
b20iPkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTwvYT4gPG86cD48L286cD48L3ByZT4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_0E11B85E97AA49FD96BC088625F0100Ejunipernet_--


From nobody Fri Oct 19 12:34:19 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAB5130F88; Fri, 19 Oct 2018 12:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.765
X-Spam-Level: 
X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXVyx8cDqynW; Fri, 19 Oct 2018 12:34:16 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC4130DD1; Fri, 19 Oct 2018 12:34:15 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9JJYFYA025974; Fri, 19 Oct 2018 12:34:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ZDz5XrmDUNtjpye5KXq0UAPLxagbTQwJDSYU7D0ksak=; b=uGD7/oVAy6ql2pYX2raaB6IwPmj48Kh17EsobBoBikEKeZHfg8C4MQ1UHwcpWIPf/91+ ud0bBr6nzemKn+3ocy6wAWL2cOf7ri2DOv77OVS1pWHytBAC2A4Rxw2Qnm81jvzXZF+T 4YG0aA14EY165aHJ5PtuNPv5tkLyEG6uG2DJEDuq7iDIcFckTLD6XJESX4VzGEsV8UYY A4RuP4pdgV3VT3xODW4aw/F+mQqTgDSeMG5ccVRZZhexsiLEghoqrLsXanNjlknoaCzh IeVmK0chFcDhW41o1qDV0ng72hb1NzmugBgPJ8yZdBcW7yJIBZJeHPw7Awa0HPUJKkQC qw== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0020.outbound.protection.outlook.com [216.32.181.20]) by mx0b-00273201.pphosted.com with ESMTP id 2n7fbp0mbk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Oct 2018 12:34:15 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4876.namprd05.prod.outlook.com (20.176.112.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.18; Fri, 19 Oct 2018 19:34:13 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%4]) with mapi id 15.20.1250.020; Fri, 19 Oct 2018 19:34:13 +0000
From: Kent Watsen 
To: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Cutoff date for requesting remote presentations at IETF103
Thread-Index: AQHUZKRC+rs2FWosaUK9T1d8NtQZM6UmuT2A
Date: Fri, 19 Oct 2018 19:34:12 +0000
Message-ID: <2483461D-83CC-412B-BE36-E1857D3068FD@juniper.net>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4876; 6:0jin8rgOmQzbYrUzVbGoP9/xTpcf3foqqBvCJ/k5WODyourtpRNCIpazdo8FaYGUPIEOqjBc2KHVsQciYNtJzdm9l7G7svJFZhpHGmBMiDetISUJvliVPb3S3YiQowBwTxeIGC41iJcRku4Wnmw2YuIlWyRLgzc5QecgtP1G4KR7fmpiyG5MUPuAzDme9/dJtwo7YATX4VkuDWJTY0Q0GssxOlMVB6gs4Ud7gZI+G5OjHTAcSn8uP87ro/OPvmwmYEcWmrgjnd0UyCCVhBBNPitaFWQvbx2e7dSPFf1aoid7cATKQ8D7+iosr+YDLTiOYmraB/gR/1ZvEy8gF/RpngTXvoKZNMKlxxJYgNKd+cnFjiKIW1tH1OaRyfNC8gsbGpYud3QtqIbRoKGxcjSOVsBtAXQGgTYZuP3nBvVJBo6dg1PO4tniHsH5HGF95JkH6ToHXfIw10+tHPOs9H6zEw==; 5:bYgEsY32dLmgtHeV/W8vP2WaLaU2oM13sHC0MM1ke7OUzn1CZmWMmrj9u2VwRqcks0TcmV1ygNp0HsV+c2oE9Lq77VMQrY6m95efuIalf+G5n0lChjEAOcyhwZ/PCmqpdglTDYqDnkMaYVSKLo+a2Xm0uRG8GosWZJhMJ7UyT2A=; 7:k1YXnpQgPn76/cd1wVbO38KVGzpXZ+lelkjiIK89g+7kaAyC299RfZcfgIRaPigBbCmZ6kuPgqoKkbu0QB/Ilz3zUYBfJ/+kb6XtqxiO5jWQqNSuvqchRhNBu0WksiI4DN+avn1auPPQYncr2KNbB8vWLzDgQ3+g1+nvUMUrdYz3TOD0RoLReyXmq7iDJvuDQkG6de2Hd4o2A4dW6VAYevlZlTaXl4aeZ5JfJjVnYRV5teFXfajUnyXiXQSQ9YpX
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b59430eb-4245-4290-8e8c-08d635f9d977
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4876; 
x-ms-traffictypediagnostic: DM6PR05MB4876:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231355)(944501410)(52105095)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4876; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4876; 
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(136003)(346002)(396003)(199004)(189003)(13464003)(6116002)(186003)(58126008)(8936002)(450100002)(446003)(2900100001)(14454004)(305945005)(2616005)(476003)(25786009)(68736007)(53936002)(6306002)(102836004)(26005)(8676002)(478600001)(86362001)(575784001)(81156014)(6512007)(2473003)(6436002)(110136005)(99286004)(966005)(5660300001)(316002)(36756003)(105586002)(6486002)(2906002)(83716004)(33656002)(97736004)(81166006)(66066001)(106356001)(82746002)(2501003)(11346002)(6506007)(16799955002)(229853002)(7736002)(71190400001)(256004)(486006)(3846002)(5250100002)(76176011)(53546011)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4876; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: nfHJTjppMYLmZOi2PnktjX+jWBo/ddhc4FT/fX6k/7F6636MttLZjheOQJX5k6SKtfhsyuUr/b47kc+LgKC/x9CadodrDiuzjmwaUpp2zx94I4a5AtoRcMbdaJX979bU0zYYCIUxN2TfkSqDsavD4akrvbNCRyzxkW+WxKU+lFbcYPwTk39+o0PqrLZTCa5WLjH23ln9ADo0txr71v9t+TVqHwIPjcmWkxBu7PhzjXmbKD20NjVJyRlz6XRQWeEo7CzUgfoM34DWrG7see3xdBYHCj5brdwRFxqycuGvArf60/QiJ5ZDUANUf9X766Ch43WCiICbMdAfKBk3ZpuMjOjRHzL0WI7sIerE3vL/zzE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9CE440567F56B945AE3641B47F446E20@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b59430eb-4245-4290-8e8c-08d635f9d977
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 19:34:12.9717 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4876
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810190173
Archived-At: 
Subject: [netmod] FW: Cutoff date for requesting remote presentations at IETF103
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 19:34:18 -0000

DQpQcmVzZW50ZXJzLA0KDQoxKSBpbiBjYXNlIHlvdSBoYXZlbid0IGRvbmUgc28gYWxyZWFkeSwg
cGxlYXNlIHNlbmQgeW91ciBwcmVzZW50YXRpb24gcmVxdWVzdHMgdG8gdGhlIGNoYWlycyBiZWZv
cmUgTW9uZGF5IQ0KDQoyKSBpZiBuZWVkaW5nIHRvIHByZXNlbnQgcmVtb3RlbHksIHBsZWFzZSBu
b3RpZnkgdGhlIGNoYWlycyBhYm91dCB0aGlzIGJ5IE1vbmRheSBhcyB3ZWxsLg0KDQpUaGFua3Ms
DQpLZW50DQoNClBTOiBwbGVhc2UgZXhjdXNlIG15IGNvbXBhbnkncyBVUkwtbWFuZ2xlciBiZWxv
dy4NCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV0dDaGFpcnMgPHdn
Y2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNZWV0ZWNobyBJRVRGIHN1cHBv
cnQgPGlldGZAbWVldGVjaG8uY29tPg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDE1LCAyMDE4IGF0
IDEyOjI5IFBNDQpUbzogIndnY2hhaXJzQGlldGYub3JnIiA8d2djaGFpcnNAaWV0Zi5vcmc+DQpT
dWJqZWN0OiBDdXRvZmYgZGF0ZSBmb3IgcmVxdWVzdGluZyByZW1vdGUgcHJlc2VudGF0aW9ucyBh
dCBJRVRGMTAzDQoNCkRlYXIgY2hhaXJzLA0KDQphcyB1c3VhbCwgcGxlYXNlIGJvb2sgeW91ciBy
ZW1vdGUgKnByZXNlbnRhdGlvbiogc2xvdHMgYXQgSUVURjEwMyBieSANCmZpbGxpbmcgb3V0IHRo
ZSBmb2xsb3dpbmcgZm9ybToNCg0KICAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX2lldGYxMDMuY29uZi5tZWV0ZWNoby5jb21faW5kZXgucGhw
X1JlbW90ZS01RnByZXNlbnRhdGlvbnMmZD1Ed0lDYkEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZtPU5IQ3JXTlhsUmVjX3JjVzEyaVFrNmk2aGZUcWVJSDMyNDZiY2hrMW12YkEm
cz1IODhjLUpjcHpFaHRucGdXUlpSTUZMdENrNkpsZmV2dklUVTNNQVlEQktBJmU9DQoNCipUaGUg
Y3V0b2ZmIGRhdGUgaXMgTm92ZW1iZXIgMiwgMjAxOC4qDQoNCllvdSBjYW4gYWxzbyBjaGVjayBz
Y2hlZHVsZWQgcmVtb3RlIHByZXNlbnRhdGlvbnMgaGVyZToNCg0KICAgICBodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2lldGYxMDMuY29uZi5tZWV0
ZWNoby5jb21fbGlzdC5waHAmZD1Ed0lDYkEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst
bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPU5IQ3JXTlhsUmVjX3JjVzEyaVFrNmk2aGZUcWVJSDMyNDZiY2hrMW12YkEmcz03RVV3
WlZ0M0FGbjh4NTZ0aGhSVkZvQV9reC03SW1MTU9SdWMyWXJNbGVZJmU9DQoNClRoYW5rcywNCnRo
ZSBNZWV0ZWNobyB0ZWFtDQoNCg0K


From nobody Fri Oct 19 12:58:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93D5130DFB for ; Fri, 19 Oct 2018 12:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0pYIz9rkcQRu for ; Fri, 19 Oct 2018 12:58:26 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 33350130DD8 for ; Fri, 19 Oct 2018 12:58:26 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8AAB1D734A940 for ; Fri, 19 Oct 2018 20:58:22 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 19 Oct 2018 20:58:23 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.88]) by SJCEML702-CHM.china.huawei.com ([169.254.4.193]) with mapi id 14.03.0415.000;  Fri, 19 Oct 2018 12:58:20 -0700
From: Alexander Clemm 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
Thread-Index: AQHUZyMbFOAyAfEluEavLs3BrdOyu6Um/ZDQ
Date: Fri, 19 Oct 2018 19:58:19 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EB841C7@sjceml521-mbx.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.35.101]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2018 19:58:29 -0000

VGhhbmsgeW91IC0gd2Ugd2lsbCBzdWJtaXQgaXQgc2hvcnRseS4NCkxvb2tpbmcgZm9yd2FyZCB0
byBkaXNjdXNzaW9ucyBpbiBCYW5na29rDQotLS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTgs
IDIwMTggMTo0MyBQTQ0KPiBUbzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZmLTAw
DQo+IA0KPiBUaGlzIG1lc3NhZ2UgY29uY2x1ZGVzIHRoZSBzdWNjZXNzZnVsIGFkb3B0aW9uIG9m
IGRyYWZ0LWNsZW1tLW5ldG1vZC1ubWRhLQ0KPiBkaWZmLTAwLg0KPiANCj4gQXV0aG9ycywgcGxl
YXNlIHJlc3VibWl0IHRoaXMgZHJhZnQsIHVuY2hhbmdlZCwgb3RoZXIgdGhhbiB0byByZW5hbWUg
aXQgYXMgZHJhZnQtDQo+IGlldGYtbmV0bW9kLW5tZGEtZGlmZi0wMC4NCj4gDQo+IEFzIGlzIGdl
bmVyYWxseSB0aGUgY2FzZSwgdGhpcyBhcHByb3ZhbCBzaWduYWxzIHRoYXQgdGhlIHdvcmtpbmcg
Z3JvdXAgaXMgd2lsbGluZyB0bw0KPiB3b3JrIG9uIHRoZSBwcm9ibGVtLCBub3QgdGhhdCB0aGUg
c3BlY2lmaWMgc29sdXRpb24gZGVzY3JpYmVkIGluIHRoZSBpcyBpdHNlbGYNCj4gYXBwcm92ZWQu
ICBJbiBwYXJ0aWN1bGFyLCB0aGUgY2hhaXJzIHJlcXVlc3QgdGhhdCB0aGUgdXNlIGNhc2VzIGFy
ZSByZWV4YW1pbmVkIGluDQo+IG9yZGVyIHRvIGRldGVybWluZSB3aGF0IGZvcm1hdCBhbmQvb3Ig
Zm9ybWF0cyBhcmUgbmVlZGVkIGFuZCwgaWYgbW9yZSB0aGFuDQo+IG9uZSwgd2hpY2ggaXMgdGhl
IGRlZmF1bHQuDQo+IA0KPiBUaGFua3MsDQo+IEtlbnQgKGFuZCBMb3UgYW5kIEpvZWwpDQo+IA0K
PiANCj4g77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIDxuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuDQo+IDxrd2F0c2Vu
QGp1bmlwZXIubmV0Pg0KPiBEYXRlOiBNb25kYXksIE9jdG9iZXIgMSwgMjAxOCBhdCAyOjQ4IFBN
DQo+IFRvOiAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPg0KPiBTdWJqZWN0OiBb
bmV0bW9kXSBXRyBhZG9wdGlvbiBwb2xsIGZvciBkcmFmdC1jbGVtbS1uZXRtb2Qtbm1kYS1kaWZm
LTAwDQo+IA0KPiBUaGUgSUVURiAxMDIgaW4tcm9vbSBwb2xsIHNob3VsZCByZWFsbHkgZ29vZCBz
dXBwb3J0IHRvIGFkb3B0IHRoaXMgZHJhZnQsIGFuZCBubw0KPiBvYmplY3Rpb25zLg0KPiANCj4g
VGhpcyBlbWFpbCBzdGFydHMgYW4gYWRvcHRpb24gcG9sbCBmb3I6DQo+IA0KPiAgIGh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3Rvb2xzLmll
dGYub3JnX2h0bWxfZHJhZnQtMkRjbGVtbS0yRG5ldG1vZC0yRG5tZGEtMkRkaWZmLQ0KPiAyRDAw
JmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pv
Q0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Z3MNCj4g
S2VySy0NCj4gRGpvazZsVEwwQThTbThQYVNKcDZGaVIwUzE1NFE0bmd4aW5nJnM9dTg4UDhJODF6
c2ltS2dCVFpnNnJKZVNKQk1SOGQNCj4gay1Ec2hGdXVlaEJrVk0mZT0NCj4gDQo+IFBsZWFzZSBp
bmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBhZG9wdGlvbiBwb2xsLg0K
PiBJZiBvYmplY3RpbmcsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMgb24gdGhpcyB0aHJlYWQu
DQo+IA0KPiBLZW50IChhbmQgTG91IGFuZCBKb2VsKQ0KPiANCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBu
ZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9
RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTYw0KPiBiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWdzDQo+
IEtlckstDQo+IERqb2s2bFRMMEE4U204UGFTSnA2RmlSMFMxNTRRNG5neGluZyZzPVBTT01IUlBT
VlVaSExCbEZkaG14V2p3UmM0DQo+IFZIRzQ1ay12aDJjSkpqcUk4JmU9DQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0K


From nobody Sat Oct 20 06:21:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E43312D4EC for ; Sat, 20 Oct 2018 06:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.766
X-Spam-Level: 
X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMjYJAmP7zL1 for ; Sat, 20 Oct 2018 06:21:53 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 58F95124C04 for ; Sat, 20 Oct 2018 06:21:52 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9KCmxTM024531 for ; Sat, 20 Oct 2018 05:48:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=+VgCTnkX8UYVksqjvn/QHI3mlC/EmPfUZUxDLfXGF7E=; b=i5dW6G6bN7Xe8PLsrVWM9MrFkbvFUvwaVTSVlKVQyGgv7FFiIPgOvlzWjjPPUuQ5km4q 1yD6gRXKFvPKYruOhxGaa+Xh6HpUYEjXzcOBqCHZ8InYygeMS6g5k/4G3jKdPU8R6//x c2fT3RZClfS0h9miYW/V4u5CpTWQpi/StoyPXQ7dnqviTPoUAxy2Q1H/9DnBqHAgAwAv ew/mmczyr74xaZ/YqB0v/4xdR2ttl9wb5DZ/d45FRfohcZE0HLZbSVFEccSs/yIe8iuQ f61d35uUgXHLwoHtAZvDfiRoczYG1J3b7u9wqnUEBz408dGwo2HIsu+IVkKu8AMfjoZ6 4w== 
Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0085.outbound.protection.outlook.com [216.32.181.85]) by mx0a-00273201.pphosted.com with ESMTP id 2n802pg92w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 20 Oct 2018 05:48:59 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5724.namprd05.prod.outlook.com (20.176.123.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Sat, 20 Oct 2018 12:48:57 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%4]) with mapi id 15.20.1250.020; Sat, 20 Oct 2018 12:48:57 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] yang-data issues
Thread-Index: AQHUSau5B5i+EaWC00yMolsTDnC0e6UoEEkA
Date: Sat, 20 Oct 2018 12:48:56 +0000
Message-ID: 
References: <20180911.104447.2165943059473950359.mbj@tail-f.com>
In-Reply-To: <20180911.104447.2165943059473950359.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5724; 6:emkqvM/hxti4A/FuehLPsyRhfhNzGdb37KCG8jLdBsmHDJnMEFgZ3c9AaGMQ42JcrlZLOJPSa2Rwo09yyQzGiDXJ+dPNZyD2C/l80HWsRfk+l8sIsRqYqsG6zHrxZd3FbtFihGFaJZt+lebPwAcypGQuU3dMX2hPJVcjrCLDzZDm4GgVBxXEDrGzBbyjGiL159PCQcU9ixvH9mkjUW0sWXCds2QKfoI9L6UI/DLC6mI0kqoYrBNALU8J2m+jiuP87H5aRlcJFj/Bh4t1n6aEk0syzYhOjNayQLyUh6MUU8S/GG8DmtdZ2Zp83GfQ1PNdBSG7oXjhfOz/8GaqswlGGTeQ+0yWF1QmEdnFFUjprxIhMAqBXm2ZqdOplNBroN692Q183kg+jIxeH1m/uLujRQPPdgI/acMn4/gK7Yfi2pxQ4Ixk/EDLQuyxqNAsPpikFckgbBb0EG5vu/we1DLr1Q==; 5:FUAKHbUAb1q4uyKxLrffnN662qTnw2HqFK3sjHyKaUYTvxn+tMlnortFeWPbUBqTJOoxDrp/+v6uBzEKNIFhXtWmDQfzSGyp61CI7qIhTVSithX+mU0e7go7we/TliBbeXdz8ifPVSlW0D0OLlXco6EjWep+bSRPh0p07XAAqI4=; 7:p7KesHFuMdb+VHgSt3Vc36H+7sDvglw79VuhJqb60YAFlnXbs2W/6E+Z6RduOs2IcrFnoIRrfEnJGo+ccQeJk/2hkLkFP5lcetXedMI0PxNcen+H9qvXJbvwx962oOxWJAGKceLWZzqezFfkJCAsRFM38jumaJQIO72pihSY3m+dgI6obYMQTFbBsSF6TBh5ehRfgQmd5DFQHQbeuVZG/CrthfS9vYfQ6r83bnp3fKqRl8G3z9dtzB4Q218Ua8Ci
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4c3e191d-57cf-4154-7480-08d6368a6667
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5724; 
x-ms-traffictypediagnostic: DM6PR05MB5724:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5724; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5724; 
x-forefront-prvs: 0831C25939
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(366004)(376002)(39860400002)(136003)(13464003)(189003)(199004)(14444005)(99286004)(6116002)(3846002)(2906002)(486006)(58126008)(53546011)(305945005)(6506007)(11346002)(476003)(446003)(2616005)(7736002)(256004)(8936002)(82746002)(186003)(2351001)(81166006)(1730700003)(86362001)(575784001)(76176011)(8676002)(106356001)(36756003)(81156014)(105586002)(229853002)(26005)(71200400001)(71190400001)(2900100001)(68736007)(97736004)(5660300001)(966005)(2501003)(6436002)(66066001)(316002)(6916009)(5250100002)(83716004)(478600001)(33656002)(5640700003)(561944003)(6486002)(102836004)(14454004)(25786009)(53936002)(6306002)(6512007)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5724; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: K4fjMzESEeO4Eb0ZjRvWGHeloW8Z8lQLiZJpEGBMdCmTHhux8Hu3/42kJZgJFCZTnWjYm2l5JSVUkPcvGDM94Ao8PIY3RPFOucbMpJZTGeXbuUb4iWMpKk0eJziPD7i4TxEvt3mDcGs5vlm7fH44JZmF3jkTM2jXCQSA2yeCfCBvXgef2vad2tVehJMQPHrSQzJb6/XigYkbyuQe/fUmwQbrv1HVUKx9ENTBVGFnJi3IMkFGGkc+JHMmtO0oSgz5r9i0Ceu5Lc7kPEspWNkz46X/XOSwVr485syWRP5wg2qYfv0AAY3c9NppkxQ4j46esudQLO+UmcQtWbwl51LL4dLZCYAMtoyZfkuXzKdfqBs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3AFDC66C6B1FD7428DC48D69579B6FF6@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c3e191d-57cf-4154-7480-08d6368a6667
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2018 12:48:56.9384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5724
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-20_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810200121
Archived-At: 
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Oct 2018 13:21:55 -0000

Rm9sa3MsDQoNCkNhbiB3ZSBnZXQgc29tZSBxdWljayByZXBsaWVzIHRvIHRoaXMgZW1haWw/DQoN
CktlbnQgLy8gYWxsIGhhdHMNCg0KDQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNYXJ0
aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCkRhdGU6IFR1ZXNkYXksIFNlcHRlbWJlciAx
MSwgMjAxOCBhdCA0OjQ1IEFNDQpUbzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRmLm9y
Zz4NClN1YmplY3Q6IFtuZXRtb2RdIHlhbmctZGF0YSBpc3N1ZXMNCg0KSGksDQoNClRoZSBhdXRo
b3JzIG9mIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctZGF0YS1leHQgaGF2ZSBiZWVuIGRpc2N1c3Np
bmcNCnRoZSB0d28gcmVtYWluaW5nIGlzc3VlcyBvbiB0aGlzIGRyYWZ0OyB0aGUgaXNzdWUgb2Yg
d2hldGhlciBhDQp5YW5nLWRhdGEgc3RydWN0dXJlIG11c3QgaGF2ZSB1bmlxdWUgdG9wLWxldmVs
IG5vZGUgbmFtZXMgb3Igbm90LCBhbmQNCnRoZSBpc3N1ZSBvZiB0aGUgc3ludGF4IGZvciBhdWdt
ZW50LXlhbmctZGF0YS4gIFdlIGhhdmVuJ3QgYmVlbiBhYmxlDQp0byBmaW5kIGFncmVlbWVudCB3
aXRoIHRoZSBjdXJyZW50IHByb3Bvc2FsLCBzbyBJIGhhdmUgYSBzdWdnZXN0aW9uDQpmb3IgYSBz
bGlnaHRseSBtb2RpZmllZCB5YW5nLWRhdGEgc3RhdGVtZW50ICh3aGljaCBtYXkgaGF2ZSBiZWVu
DQpkaXNjdXNzZWQgYmVmb3JlKToNCg0KVGhlIGlkZWEgaXMgdG8gZW5jb2RlIGEgeWFuZy1kYXRh
IGV4dGVuc2lvbiB0aGUgc2FtZSB3YXkgYXMgYW55ZGF0YSwNCmkuZS4sIGFzIGEgY29udGFpbmVy
LiAgRm9yIGV4YW1wbGU6DQoNCiAgeWQ6eWFuZy1kYXRhIG1vZGlmeS1zdWJzY3JpcHRpb24tZGF0
YXN0b3JlLWVycm9yLWluZm8gew0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIlRoaXMgeWFu
Zy1kYXRhIE1BWSBiZSBwcm92aWRlZCBhcyBwYXJ0IG9mIGEgc3Vic2NyaXB0aW9uJ3MgUlBDDQog
ICAgICAgIGVycm9yIHJlc3BvbnNlIHdoZW4gdGhlcmUgaXMgYSBmYWlsdXJlIG9mIGENCiAgICAg
ICAgJ21vZGlmeS1zdWJzY3JpcHRpb24nIFJQQyB3aGljaCBoYXMgYmVlbiBtYWRlIGFnYWluc3Qg
YQ0KICAgICAgICBkYXRhc3RvcmUuICBUaGlzIHlhbmctZGF0YSBNVVNUIGJlIHVzZWQgaWYgaGlu
dHMgYXJlIHRvIGJlDQogICAgICAgIHByb3ZpZGVzIGJhY2sgdG8gdGhlIHN1YnNjcmliZXIuIjsN
CiAgICAgIGxlYWYgcmVhc29uIHsNCiAgICAgICAgdHlwZSBpZGVudGl0eXJlZiB7DQogICAgICAg
ICAgYmFzZSBzbjptb2RpZnktc3Vic2NyaXB0aW9uLWVycm9yOw0KICAgICAgICB9DQogICAgICAg
IGRlc2NyaXB0aW9uDQogICAgICAgICAgIkluZGljYXRlcyB0aGUgcmVhc29uIHdoeSB0aGUgc3Vi
c2NyaXB0aW9uIGhhcyBmYWlsZWQgdG8NCiAgICAgICAgICBiZSBtb2RpZmllZC4iOw0KICAgICAg
fQ0KICAgICAgdXNlcyBoaW50czsNCiAgICB9DQoNClRoaXMgd291bGQgYmUgZW5jb2RlZCBhczoN
Cg0KICA8bW9kaWZ5LXN1YnNjcmlwdGlvbi1kYXRhc3RvcmUtZXJyb3ItaW5mbz4NCiAgICA8cmVh
c29uPmZvbzwvcmVhc29uPg0KICAgIDxwZXJpb2QtaGludD40MjwvcGVyaW9kLWhpbnQ+DQogICAg
Li4uDQogIDwvbW9kaWZ5LXN1YnNjcmlwdGlvbi1kYXRhc3RvcmUtZXJyb3ItaW5mbz4NCg0KDQpT
aW5jZSB0aGUgc3RydWN0dXJlIGlzIGFsd2F5cyBlbmNvZGVkIGFzIGEgY29udGFpbmVyLCBpdCBm
b2xsb3dzIHRoYXQNCml0IGNhbiBoYXZlIGFueSBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50IGFz
IHN1YnN0YXRlbWVudCwgd2l0aCBubw0KcmVzdHJpY3Rpb24gb24gbmFtaW5nIGFuZCB0eXBlIG9m
IHN0YXRlbWVudC4gIEFuIGluc3RhbmNlIG9mIHRoaXMgY2FuDQp0cml2aWFsbHkgYmUgYSBjb21w
bGV0ZSBpbnN0YW5jZSBkb2N1bWVudCBpbiBYTUwgdy9vIGFkZGl0aW9uYWwNCmNvbnRleHQsIHdv
cmtzIHdlbGwgd2l0aCBKU09OLCBhbmQgY2FuIGFwcGVhciBpbiBhbiBlcnJvci1pbmZvDQpzdHJ1
Y3R1cmUuDQoNClN1Y2ggYSBzdHJ1Y3R1cmUgY2FuIGJlIGF1Z2VtZW50ZWQgYXM6DQoNCiAgeWQ6
YXVnbWVudC15YW5nLWRhdGEgL3NuOm1vZGlmeS1zdWJzY3JpcHRpb24tZGF0YXN0b3JlLWVycm9y
LWluZm8gew0KICAgIGxlYWYgZm9vIHsgLi4uIH0NCiAgfQ0KDQpUaGUgZHJhd2JhY2sgaXMgdGhh
dCBpdCBmb3JjZXMgdGhlIHVzZSBvZiBhbiBleHRyYSBjb250YWluZXIgaW4gdGhlDQplbmNvZGlu
Zy4gIE9UT0gsIG1vc3QgdXNhZ2VzIG9mIGN1cnJlbnQgcmM6eWFuZy1kYXRhIGZvbGxvd3MgdGhp
cw0KcGF0dGVybjoNCg0KICByYzp5YW5nLWRhdGEgbW9kaWZ5LXN1YnNjcmlwdGlvbi1kYXRhc3Rv
cmUtZXJyb3ItaW5mbyB7DQogICAgY29udGFpbmVyIG1vZGlmeS1zdWJzY3JpcHRpb24tZGF0YXN0
b3JlLWVycm9yLWluZm8gew0KICAgICAgLi4uDQogICAgfQ0KICB9DQogIA0KDQoNCg0KL21hcnRp
bg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0
bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp
bmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09
N25sVnU1ZEphYThYc0QwTFJkMFZUSDMwMWNhVlJVWEdzYTZMLVVnWFZSRSZzPTFvN3ZYSC1qOEhh
NnhiSkZURzFqak56eTlKUXc3ay1VV0lxcGVDcjhxcmsmZT0NCg0K


From nobody Sat Oct 20 08:16:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58564129BBF for ; Sat, 20 Oct 2018 08:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 kIGjvKr9JD1T for ; Sat, 20 Oct 2018 08:16:01 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 1C2E01277D2 for ; Sat, 20 Oct 2018 08:16:01 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id u21-v6so33283332lja.8 for ; Sat, 20 Oct 2018 08:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fbAp3X19qAJB4yr+aeMVy9Ah7BVqOwkglYMpSQqwktg=; b=mtr3dqnx1IulgTHrbYHeKIObXQ8RoGp047rfG17ziPVYGrxCtObP2bYRql7qThYr3M zdSh+4cwPN20Gk64Vg6u4s+sSlsjvGbrOLSqFadgQEF+mrD/J5Pj4eJl35DkEgawghft zzry63MoaN4uDWTX06ojoGFDjfBR19hIGCU/iCpIMLtrsgc7W+ZN18MU/SDCci0nl2Zm l+yWm81fkUt4PD2TmM473v6rdhzZ4hZjaz5F5pYjUQWi25b4VBOpY8MYC3OyYRMP4Y8W fHV2aQ0kMu0ynI9Z1cD5D6nctPkBS0I4v6hqtpcOIYcFx3d41rZgMm95fr+jAQBAXGgg lg/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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fbAp3X19qAJB4yr+aeMVy9Ah7BVqOwkglYMpSQqwktg=; b=WbtznV1GmGJsJjW2XODiToaCw7q6Sj4R3LBSPmiYwjTjDnWuvS8B9PU+GG+eOwvfhz O31E/JdZK/l3Fp1inJibcLMo8f7J3ZIaCRjSxVTQlWj3C3HJ9iGjOr6EwWibqdSMVEqE RrsarQuzFNm/CA55KNmgo8t4P8amchGxO4+S6p4JbNs2IdhVm03jKoGw7uyISaxTZ6J7 p7bdeZ2x/kI3lzG4nfuF81k2MUa92Qqez/pWuaQ0sy6MoFWjvdxigty0cTXYb+dpd3lB lsIG1nL3H9W/5rJ19Pydwre1MP2nHlfQcco+oQDugg9HhdpqOO8LZpXiIUL79ivuMTHJ E9gQ==
X-Gm-Message-State: ABuFfoh62LdMxpn1ksXLD6tivAyNkLpepAYgBzKywnT2HB7w0Qnxecta cQZOfmbLaRqAqsWWDkqRvaPFdYixyR3LK08m3a231Q2d
X-Google-Smtp-Source: AJdET5e4TnDP5uK2zkFW/HmF6msO7O/HM3/H/1A0+Tvr4J2E1Tuc0S4TeZlVS6JEDzj4VOPgtt/06eyCc/qTPM8AETE=
X-Received: by 2002:a2e:8945:: with SMTP id b5-v6mr1004785ljk.20.1540048559183;  Sat, 20 Oct 2018 08:15:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Sat, 20 Oct 2018 08:15:58 -0700 (PDT)
In-Reply-To: <828a5858-f12e-aa7f-40af-c39679fd2cc9@hq.sk>
References: <152029421633.12842.1970354425067689893@ietfa.amsl.com> <828a5858-f12e-aa7f-40af-c39679fd2cc9@hq.sk>
From: Andy Bierman 
Date: Sat, 20 Oct 2018 08:15:58 -0700
Message-ID: 
To: Robert Varga 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000004eabe00578aa7f22"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Oct 2018 15:16:04 -0000

--0000000000004eabe00578aa7f22
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 15, 2018 at 1:28 PM, Robert Varga  wrote:

> On 06/03/2018 00:56, internet-drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Network Modeling WG of the IETF.
> >
> >         Title           : YANG Data Extensions
> >         Authors         : Andy Bierman
> >                           Martin Bjorklund
> >                           Kent Watsen
> >       Filename        : draft-ietf-netmod-yang-data-ext-01.txt
> >       Pages           : 11
> >       Date            : 2018-03-05
> >
> > Abstract:
> >    This document describes YANG mechanisms for defining abstract data
> >    structures with YANG.  It is intended to replace and extend the
> >    "yang-data" extension statement defined in RFC 8040.
>
> Sorry to be a late reviewer on this.
>
> To me "augment-yang-data" feels really like "augment a particular
> instance of a schema tree", i.e. increasing specificity of augment
> target node with knowledge on which tree instantiation it operates.
>
> RFC7950 already does this (implicitly) for notification, rpc and action
> statements by making them members of the schema tree and the same
> "augment" and "deviation" mechanics for them being defined shared with
> the data tree.
>
> I would argue this problem from a different point of view.
>
> I think the purpose of "augment-yang-data" would be much better
> addressed with an extension usable within augment (and deviate) to
> reference a particular schema tree instantiation.
>
>

I do not agree that the scope of this work should be expanded.
If there are specific language features that need to be standardized, then
a new
version of YANG should be standardized instead.


Andy



What that means in terms of YANG metamodel is two-fold:
>
> 1) an extension statement can define a conceptual schema tree
> instantiation -- very much like NMDA does, but applied not to datastore,
> but to schema tree.
>
> 2) an augment (or deviation) statement can be restricted to operate on a
> schema tree instantiation defined by an extension statement
>
> Rough example:
>
>     extension augmentable-statement;
>     extension schematree-instance;
>
>     extension yang-data {
>         as:augmentable-statement;
>     }
>
>     yd:yang-data foo;
>
>     augment /foo {
>         // i.e. interpret argument as a target valid in the schema tree
>         // as defined by yang-data, with the semantics specified therein
>         si:schematree-instance "yd:yang-data";
>     }
>
> Note how as:schematree-instance is completely unnecessary here:
> yang-data's use of as:augmentable-statement is already indicating that
> the statement is augmentable, thus bridging it to RFC7950 section 7.19:
>
>    An extension can allow refinement (see Section 7.13.2) and deviations
>    (Section 7.20.3.2), but the mechanism for how this is defined is
>    outside the scope of this specification.
>
> hence the only extension that is needed for yang-data and future similar
> extensions is augmentable-statement, simply because as soon as "augment"
> argument touches an extension statement, you have to know something
> about it. If an augment argument crosses an extension statement, it must
> share fate with the parser's handling of the extension: if the parser
> chooses to ignore the extension, it should reasonably also ignore the
> augment statement.
>
> Unless "augment" is not allowed to touch extension statements (i.e.
> extensions must never define a schema tree member) -- if that is the
> case, that should be normatively defined somewhere, too.
>
> Regards,
> Robert
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Mon, Oct 15, 2018 at 1:28 PM, Robert Varga <nite@hq.sk> wrot=
e:
On 06/03/2018 00:56, internet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> This draft is a work item of the Network Modeling WG of the IETF.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0: YANG Data Extensions

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0: Andy Bierman

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Martin Bjorklund

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Kent Watsen

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-netmod-yang-data-ext-01.txt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 11

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2018-03-05

> 

> Abstract:

>=C2=A0 =C2=A0 This document describes YANG mechanisms for defining abst=
ract data

>=C2=A0 =C2=A0 structures with YANG.=C2=A0 It is intended to replace and=
 extend the

>=C2=A0 =C2=A0 "yang-data" extension statement defined in RFC =
8040.



Sorry to be a late reviewer on this.



To me "augment-yang-data" feels really like "augment a parti=
cular

instance of a schema tree", i.e. increasing specificity of augment

target node with knowledge on which tree instantiation it operates.



RFC7950 already does this (implicitly) for notification, rpc and action

statements by making them members of the schema tree and the same

"augment" and "deviation" mechanics for them being defi=
ned shared with

the data tree.



I would argue this problem from a different point of view.



I think the purpose of "augment-yang-data" would be much better
addressed with an extension usable within augment (and deviate) to

reference a particular schema tree instantiation.




I do not agree that the=
 scope of this work should be expanded.
If there are specific lan=
guage features that need to be standardized, then a new
version o=
f YANG should be standardized instead.=C2=A0


<=
/div>
Andy




What that means in terms of YANG metamodel is two-fold:



1) an extension statement can define a conceptual schema tree

instantiation -- very much like NMDA does, but applied not to datastore,
but to schema tree.



2) an augment (or deviation) statement can be restricted to operate on a
schema tree instantiation defined by an extension statement



Rough example:



=C2=A0 =C2=A0 extension augmentable-statement;

=C2=A0 =C2=A0 extension schematree-instance;



=C2=A0 =C2=A0 extension yang-data {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 as:augmentable-statement;

=C2=A0 =C2=A0 }



=C2=A0 =C2=A0 yd:yang-data foo;



=C2=A0 =C2=A0 augment /foo {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // i.e. interpret argument as a target valid in=
 the schema tree

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // as defined by yang-data, with the semantics =
specified therein

=C2=A0 =C2=A0 =C2=A0 =C2=A0 si:schematree-instance "yd:yang-data"=
;

=C2=A0 =C2=A0 }



Note how as:schematree-instance is completely unnecessary here:

yang-data's use of as:augmentable-statement is already indicating that<=
br>
the statement is augmentable, thus bridging it to RFC7950 section 7.19:



=C2=A0 =C2=A0An extension can allow refinement (see Section 7.13.2) and dev=
iations

=C2=A0 =C2=A0(Section 7.20.3.2), but the mechanism for how this is defined =
is

=C2=A0 =C2=A0outside the scope of this specification.



hence the only extension that is needed for yang-data and future similar
extensions is augmentable-statement, simply because as soon as "augmen=
t"

argument touches an extension statement, you have to know something

about it. If an augment argument crosses an extension statement, it must
share fate with the parser's handling of the extension: if the parser
chooses to ignore the extension, it should reasonably also ignore the

augment statement.



Unless "augment" is not allowed to touch extension statements (i.=
e.

extensions must never define a schema tree member) -- if that is the

case, that should be normatively defined somewhere, too.



Regards,

Robert




_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--0000000000004eabe00578aa7f22--


From nobody Sat Oct 20 10:55:23 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF7A130E7C; Sat, 20 Oct 2018 10:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 fydEfsG_8yKk; Sat, 20 Oct 2018 10:55:14 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CB2126CC7; Sat, 20 Oct 2018 10:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1540058113; x=1541267713; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=96GH1tHCgsXD0DbKQQRS73+NaYdkRhKUz3+TgeuEaCU=; b=IxBGfjFyRDFC5Y+y6QbfULskQLXqcT++FaXDEtlA4/J66kt7YVDN0fND BO1z0lbfJzt8jJsGm6DOiMPwwa+a+jfdyMKHlepm2xeK3fLWjDmNg90xR VotXI/XIcQiQLNx9OjW1pi1yLwE5pdEPonTpQAdJiVbB3z17x5uTMIF5q g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAACBa8tb/5NdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggRmfyiDdZQzgg2ZDw0lgVKCdQKFCCE?= =?us-ascii?q?3Cg0BAwEBAgEBAm0cAQuFOgEGI1QCEBwDAQIDAiYCAk0CCAYNBgIBAReDBgG?= =?us-ascii?q?CAQ+lV4EuhDACDECFHIELikcXgUE/gTiCa4MbAQECAQEWhEqCVwKISk6FMkK?= =?us-ascii?q?PPAmGYooKBheBUkyEJ4JuhnuJJYMzigWBWSKBVU0jFRqDDQmCRohKhVojMAG?= =?us-ascii?q?LbgEB?=
X-IronPort-AV: E=Sophos;i="5.54,405,1534809600"; d="scan'208";a="469362341"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2018 17:55:12 +0000
Received: from [10.118.87.91] (rtp-jclarke-nitro10.cisco.com [10.118.87.91]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTP id w9KHtCI1004205; Sat, 20 Oct 2018 17:55:12 GMT
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" 
Cc: "netmod-ver-dt@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
X-Forwarded-Message-Id: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com>
Message-ID: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
Date: Sat, 20 Oct 2018 13:55:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.91, rtp-jclarke-nitro10.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Oct 2018 17:55:16 -0000

The netmod YANG versioning design team has updated the requirements
draft based on comments received at IETF 102 as well as some individual
discussions.  Highlights include:

* Definition of "non-backwards-compatible"

* Clarification on what clients should do with backwards-compatibly
changed instance data

* Reworded requirement 1.2 to avoid needless client work for unchanged
nodes or nodes that were changed in backwards-compatible ways

* New requirement 1.4 for supporting over-arching software releases

Joe (on behalf of the DT)


-------- Forwarded Message --------
Subject: New Version Notification for
draft-verdt-netmod-yang-versioning-reqs-01.txt
Date: Sat, 20 Oct 2018 10:50:23 -0700
From: internet-drafts@ietf.org
To: Joe Clarke 


A new version of I-D, draft-verdt-netmod-yang-versioning-reqs-01.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Name:		draft-verdt-netmod-yang-versioning-reqs
Revision:	01
Title:		YANG Module Versioning Requirements
Document date:	2018-10-20
Group:		Individual Submission
Pages:		12
URL:
https://www.ietf.org/internet-drafts/draft-verdt-netmod-yang-versioning-reqs-01.txt
Status:
https://datatracker.ietf.org/doc/draft-verdt-netmod-yang-versioning-reqs/
Htmlized:
https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-verdt-netmod-yang-versioning-reqs
Diff:
https://www.ietf.org/rfcdiff?url2=draft-verdt-netmod-yang-versioning-reqs-01

Abstract:
   This document describes the problems that can arise because of the
   YANG language module update rules, that require all updates to YANG
   module preserve strict backwards compatibility.  It also defines the
   requirements on any solution designed to solve the stated problems.
   This document does not consider possible solutions, nor endorse any
   particular solution.




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


From nobody Sun Oct 21 19:23:28 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9586312D4E6; Sun, 21 Oct 2018 19:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9h5g9ltiG52; Sun, 21 Oct 2018 19:23:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2889012958B; Sun, 21 Oct 2018 19:23:24 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 09858EB5A1FBF; Mon, 22 Oct 2018 03:23:20 +0100 (IST)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 03:23:21 +0100
Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.234]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0399.000; Mon, 22 Oct 2018 10:23:18 +0800
From: wangzitao 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AdRprg2JSVIsNvFyRSGcoWmz7SeFvA==
Date: Mon, 22 Oct 2018 02:23:18 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.245]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 02:23:26 -0000

WWVzL3N1cHBvcnQuDQoNCkJSLg0KTWljaGFlbA0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7I
yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTG91IEJlcmdl
cg0Kt6LLzcqxvOQ6IDIwMTjE6jEw1MIxOMjVIDIxOjA0DQrK1bz+yMs6IE5ldE1vZCBXRyA8bmV0
bW9kQGlldGYub3JnPg0Ks63LzTogTmV0TW9kIFdHIENoYWlycyA8bmV0bW9kLWNoYWlyc0BpZXRm
Lm9yZz4NCtb3zOI6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZHJhZnQta3dhdHNlbi1uZXRt
b2QtYXJ0d29yay1mb2xkaW5nLTA4DQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3byB3
ZWVrIHBvbGwgb24gbWFraW5nDQpkcmFmdC1rd2F0c2VuLW5ldG1vZC1hcnR3b3JrLWZvbGRpbmct
MDggYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlz
dCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4gIElmIGlu
ZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBkb2N1
bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMg
eW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9j
dW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgT2N0IDEuDQoNClRoYW5rcywNCg0KTG91IChhbmQgY28t
Y2hhaXJzKQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Sun Oct 21 22:00:21 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759C0130DC0 for ; Sun, 21 Oct 2018 22:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 cSSJJJa8SERL for ; Sun, 21 Oct 2018 22:00:15 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 90D6912F1AC for ; Sun, 21 Oct 2018 22:00:14 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D5FD839ADD2DE; Mon, 22 Oct 2018 05:59:59 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 05:59:28 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0399.000; Mon, 22 Oct 2018 12:59:17 +0800
From: Rohit R Ranade 
To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6edTUJh1sqnT0SD+ZwzekOYOaUmhEAAgAQuqKA=
Date: Mon, 22 Oct 2018 04:59:17 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.china.huawei.com>
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BC6988Fdggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 05:00:19 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC6988Fdggeml510mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U29tZSBzdWdnZXN0aW9ucywNCg0KDQoNCjEuICAgICAgIEluIFlBTkcgbW9kdWxlLCB0aGUgaWRl
bnRpdHkgaGFzIG5hbWUgYXMg4oCcZmFjdG9yeS1kZWZhdWx04oCdLCBidXQgbWFueSBwbGFjZXMg
IHRoZSBuYW1lICJmYWN0b3J5LWRlZmF1bHQtcnVubmluZyIgaXMgdXNlZC4gSSBzdWdnZXN0IHdl
IHVzZWQg4oCcZmFjdG9yeS1kZWZhdWx04oCdaW4gYWxsIHBsYWNlcy4NCg0KMi4gICAgICAgVGhp
cyBZQU5HIG1vZHVsZSBpcyBpbXBvcnRpbmcgaWV0Zi1uZXRjb25mIG1vZHVsZS4gSSBzdWdnZXN0
IHRoYXQgdGhpcyBpbXBvcnQgc2hvdWxkIGJlIHJlbW92ZWQgYXMgdGhpcyBtb2R1bGUgc2hvdWxk
IG5vdCBoYXZlIGRlcGVuZGVuY2llcyBvbiBORVRDT05GLg0KDQozLiAgICAgICBUaGUgZGVzY3Jp
cHRpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSwgc3RpbGwgaGFzIHRoZSByZWZlcmVuY2UgdG8gPGNv
cHktY29uZmlnPi4gIFdoZXRoZXIgdGhpcyBjYW4gYmUgcmVtb3ZlZCA/DQoNCjQuICAgICAgIFRo
ZSBkZXNjcmlwdGlvbiBvZiB0aGUgaW5kZW50aXR5IOKAnGZhY3RvcnktZGVmYXVsdOKAnSwgc3Vn
Z2VzdCB0byBkZXNjcmliZSB0aGUgaWRlbnRpdHkgcmF0aGVyIHRoYW4gdGVsbCDigJxob3figJ0g
aXQgY2FuIGJlIHVzZWQuDQoNCjUuICAgICAgIFdoZXRoZXIgd2UgY2FuIGFsc28gYWRkIHRoZSBz
dGF0ZW1lbnQgdGhhdCBpZiB0aGUg4oCcdGFyZ2V0LWRhdGFzdG9yZeKAnSwgaGF2ZSBiZWVuIGxv
Y2tlZCAsIHRoZW4gdGhlIHJlc2V0LWRhdGFzdG9yZSB3aWxsIGZhaWwgd2l0aCB0aGUgPGVycm9y
LXRhZz4gdmFsdWUgYXMg4oCcaW4tdXNl4oCdID8NCg0KNi4gICAgICAgU2luY2Ugd2UgaGF2ZSBz
Y2VuYXJpbyBvZiBjb3B5IHRvIG11bHRpcGxlIHRhcmdldHMsIHdoZXRoZXIgd2UgY2FuIGFkZCBh
IGxlYWYgY2FsbGVkIHRoZSBlcnJvci1vcHRpb24gd2l0aCBwb3NzaWJsZSB2YWx1ZXMgb2Yg4oCc
c3RvcC1vbi1lcnJvci9jb250aW51ZS1vbi1lcnJvci9yb2xsYmFjay1vbi1lcnJvcuKAnSAgID8N
Cg0KDQoNCldpdGggUmVnYXJkcywNCg0KUm9oaXQgUg0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhbMOhenMgTGVuZ3llbA0KU2Vu
dDogMTkgT2N0b2JlciAyMDE4IDE4OjE3DQpUbzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBb
bmV0bW9kXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9k
LWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCg0KDQpIZWxsbywNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0IGhhcyBiZWVuIHVwbG9h
ZGVkLiBDaGFuZ2VzIGluY2x1ZGU6DQpSZW1vdmVkIGltcGFjdHMgdG8gPGNvcHktY29uZmlnPiBh
cyB0aGUgcmVzZXQtZGF0YXN0b3JlICBSUEMgY2FuIGFueXdheSBkbyB0aGUgc2FtZSB0aGluZy4N
CkV4cGxhaW5lZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVm
YXVsdCBkYXRhc3RvcmVzDQpTbWFsbCBjb3JyZWN0aW9ucy4NCg0KcmVnYXJkcyBCYWxhenMNCg0K
LS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50
eHQNCg0KRGF0ZToNCg0KRnJpLCAxOSBPY3QgMjAxOCAwNTozMDowNSAtMDcwMA0KDQpGcm9tOg0K
DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
Zz4NCg0KVG86DQoNClllIE5pdSA8bml1eWVAaHVhd2VpLmNvbT48bWFpbHRvOm5pdXllQGh1YXdl
aS5jb20+LCBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT48bWFpbHRvOmJpbGwud3VAaHVhd2Vp
LmNvbT4sIEJhbGF6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PG1haWx0
bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KaGFzIGJlZW4gc3Vj
Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCYWxhenMgTGVuZ3llbCBhbmQgcG9zdGVkIHRvIHRoZQ0K
SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0
DQpSZXZpc2lvbjogMDENClRpdGxlOiBGYWN0b3J5IGRlZmF1bHQgU2V0dGluZw0KRG9jdW1lbnQg
ZGF0ZTogMjAxOC0xMC0xOQ0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEw
DQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRt
b2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0Lw0KSHRtbGl6ZWQ6IGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0
LTAxDQpIdG1saXplZDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm
dC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0DQpEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9y
ZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMQ0KDQpBYnN0cmFj
dDoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhvZCB0byByZXNldCBhIFlBTkcgZGF0YXN0
b3JlIHRvIGl0cw0KZmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQuIFRoZSByZXNldCBvcGVyYXRpb24g
bWF5IGJlIHVzZWQgZS5nLiBkdXJpbmcNCmluaXRpYWwgemVyby10b3VjaCBjb25maWd1cmF0aW9u
IG9yIHdoZW4gdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24NCmhhcyBtYWpvciBlcnJvcnMsIHNv
IHJlLXN0YXJ0aW5nIHRoZSBjb25maWd1cmF0aW9uIHByb2Nlc3MgZnJvbQ0Kc2NyYXRjaCBpcyB0
aGUgYmVzdCBvcHRpb24uDQoNCkEgbmV3IHJlc2V0LWRhdGFzdG9yZSBSUEMgaXMgZGVmaW5lZC4g
U2V2ZXJhbCBtZXRob2RzIG9mIGRvY3VtZW50aW5nDQp0aGUgZmFjdG9yeS1kZWZhdWx0IGNvbnRl
bnQgYXJlIHNwZWNpZmllZC4NCg0KT3B0aW9uYWxseSBhIG5ldyAiZmFjdG9yeS1kZWZhdWx0LXJ1
bm5pbmciIHJlYWQtb25seSBkYXRhc3RvcmUgaXMNCmRlZmluZWQsIHRoYXQgY29udGFpbnMgdGhl
IGRhdGEgdGhhdCB3aWxsIGJlIGNvcGllZCBvdmVyIHRvIHRoZQ0KcnVubmluZyBkYXRhc3RvcmUg
YXQgcmVzZXQuDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m
IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQg
dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg
SUVURiBTZWNyZXRhcmlhdA0KDQotLQ0KDQpCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAg
ICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQoNClNlbmlvciBTcGVjaWFsaXN0DQoNCk1vYmls
ZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJp
Y3Nzb24uY29tPG1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20+DQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC6988Fdggeml510mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs
IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh
bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj
azt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt
c28tbGlzdC1pZDo0ODY1NDU3NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6LTE4MTg0NzAxMjAgLTEwNDQ1ODA4ODYgNjc2OTg3MTMgNjc2OTg3MTUgNjc2
OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxp
c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4
LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt
bG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUyXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi4wcHQ7
DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDo2My4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojg0
LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTVcKSI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCW1hcmdpbi1sZWZ0OjEwNS4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCglt
YXJnaW4tbGVmdDoxMjYuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2
ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDcuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0K
QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10ZXh0OiIlOFwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY4LjBwdDsNCgl0ZXh0
LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjE4OS4wcHQ7DQoJdGV4dC1pbmRl
bnQ6LTIxLjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoyMDE2ODA2NjkxOw0KCW1zby1s
aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjcyMjM4MjcyIC0xNTM5
NTU2NTc0IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4
NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl
ZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjVwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgltc28tYXNjaWkt
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTrlrovkvZM7DQoJ
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUyXCki
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgltYXJnaW4tbGVmdDo0Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlz
dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN
CgltYXJnaW4tbGVmdDo2My4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMTps
ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojg0LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30N
CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN
Cgltc28tbGV2ZWwtdGV4dDoiJTVcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEwNS4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTIxLjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0Ow0KCXRleHQtaW5k
ZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDcuMHB0
Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlOFwpIjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
bWFyZ2luLWxlZnQ6MTY4LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwxOmxl
dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdp
bi1sZWZ0OjE4OS4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9DQpvbA0KCXttYXJnaW4tYm90
dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi
Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U29tZSBzdWdnZXN0aW9ucyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6
LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv
LWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48
L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPkluIFlBTkcgbW9kdWxlLCB0aGUgaWRlbnRpdHkgaGFzIG5hbWUgYXMg4oCcPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ZmFjdG9yeS1k
ZWZhdWx0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
4oCdLCBidXQgbWFueSBwbGFjZXMgJm5ic3A7dGhlIG5hbWUgPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7ZmFjdG9yeS1kZWZhdWx0LXJ1bm5p
bmcmcXVvdDsgaXMgdXNlZC4gSSBzdWdnZXN0IHdlIHVzZWQg4oCcZmFjdG9yeS1kZWZhdWx04oCd
aW4gYWxsIHBsYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp
bi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8y
Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZv
bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBZQU5HIG1vZHVsZSBpcyBp
bXBvcnRpbmcgaWV0Zi1uZXRjb25mIG1vZHVsZS4gSSBzdWdnZXN0IHRoYXQgdGhpcyBpbXBvcnQg
c2hvdWxkIGJlIHJlbW92ZWQgYXMgdGhpcyBtb2R1bGUgc2hvdWxkIG5vdCBoYXZlIGRlcGVuZGVu
Y2llcyBvbiBORVRDT05GLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwh
W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3
LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVzY3JpcHRpb24gb2YgdGhpcyBZ
QU5HIG1vZHVsZSwgc3RpbGwgaGFzIHRoZSByZWZlcmVuY2UgdG8gJmx0O2NvcHktY29uZmlnJmd0
Oy4gJm5ic3A7V2hldGhlciB0aGlzIGNhbiBiZSByZW1vdmVkID88L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s
aXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi
PjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl
IGRlc2NyaXB0aW9uIG9mIHRoZSBpbmRlbnRpdHkg4oCcZmFjdG9yeS1kZWZhdWx04oCdLCBzdWdn
ZXN0IHRvIGRlc2NyaWJlIHRoZSBpZGVudGl0eSByYXRoZXIgdGhhbiB0ZWxsIOKAnGhvd+KAnSBp
dCBjYW4gYmUgdXNlZC4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm
dDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFb
aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250Ojcu
MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZXRoZXIgd2UgY2FuIGFsc28gYWRkIHRo
ZSBzdGF0ZW1lbnQgdGhhdCBpZiB0aGUg4oCcdGFyZ2V0LWRhdGFzdG9yZeKAnSwgaGF2ZSBiZWVu
IGxvY2tlZCAsIHRoZW4gdGhlIHJlc2V0LWRhdGFzdG9yZSB3aWxsIGZhaWwgd2l0aCB0aGUgJmx0
O2Vycm9yLXRhZyZndDsgdmFsdWUgYXMg4oCcaW4tdXNl4oCdID88L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s
aXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi
PjYuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2lu
Y2Ugd2UgaGF2ZSBzY2VuYXJpbyBvZiBjb3B5IHRvIG11bHRpcGxlIHRhcmdldHMsIHdoZXRoZXIg
d2UgY2FuIGFkZCBhIGxlYWYgY2FsbGVkIHRoZSBlcnJvci1vcHRpb24gd2l0aCBwb3NzaWJsZSB2
YWx1ZXMgb2Yg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+c3RvcC1vbi1lcnJvci9j
b250aW51ZS1vbi1lcnJvci9yb2xsYmFjay1vbi1lcnJvcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnSAmbmJzcDsmbmJzcDs/PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJv
aGl0IFI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJv
bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4
dCI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5CYWzDoXpzIExlbmd5ZWw8YnI+DQo8Yj5TZW50OjwvYj4gMTkgT2N0b2JlciAyMDE4
IDE4OjE3PGJyPg0KPGI+VG86PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gW25ldG1vZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8sPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dCBoYXMgYmVlbiB1cGxv
YWRlZC4gQ2hhbmdlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVtb3ZlZCBpbXBhY3RzIHRvICZs
dDtjb3B5LWNvbmZpZyZndDsgYXMgdGhlIHJlc2V0LWRhdGFzdG9yZSZuYnNwOyBSUEMgY2FuIGFu
eXdheSBkbyB0aGUgc2FtZSB0aGluZy4NCjxicj4NCkV4cGxhaW5lZCB0aGUgZGlmZmVyZW5jZSBi
ZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVmYXVsdCBkYXRhc3RvcmVzPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPlNtYWxsIGNvcnJlY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyBCYWxhenM8YnI+DQo8YnI+DQotLS0tLS0tLSBG
b3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUg
Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk
ZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHls
ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249
InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1
YmplY3Q6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFk
ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3Rv
cnktZGVmYXVsdC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0
cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFs
aWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RGF0ZToNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJpLCAxOSBPY3QgMjAxOCAw
NTozMDowNSAtMDcwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0K
PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246
cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOg0KPG86cD48L286cD48L3NwYW4+PC9i
PjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86aW50ZXJu
ZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i
dG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0i
RU4tVVMiPlRvOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9
InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj5ZZSBOaXUgPGEgaHJlZj0ibWFpbHRvOm5pdXllQGh1YXdlaS5jb20iPg0KJmx0
O25pdXllQGh1YXdlaS5jb20mZ3Q7PC9hPiwgUWluIFd1IDxhIGhyZWY9Im1haWx0bzpiaWxsLnd1
QGh1YXdlaS5jb20iPiZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PC9hPiwgQmFsYXpzIExlbmd5
ZWwNCjxhIGhyZWY9Im1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20iPiZsdDtiYWxh
enMubGVuZ3llbEBlcmljc3Nvbi5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8
YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVs
dC0wMS50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJhbGF6cyBM
ZW5neWVsIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4N
Ck5hbWU6IGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQ8YnI+DQpSZXZpc2lvbjogMDE8
YnI+DQpUaXRsZTogRmFjdG9yeSBkZWZhdWx0IFNldHRpbmc8YnI+DQpEb2N1bWVudCBkYXRlOiAy
MDE4LTEwLTE5PGJyPg0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiAx
MDxicj4NClVSTDogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0Ij4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAx
LnR4dDwvYT48YnI+DQpTdGF0dXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQvIj4NCmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQvPC9hPjxi
cj4NCkh0bWxpemVkOiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
d3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMTwvYT48YnI+DQpIdG1saXplZDog
PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1u
ZXRtb2QtZmFjdG9yeS1kZWZhdWx0Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdDwvYT48YnI+DQpEaWZmOiA8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdC0wMSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh
ZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8
YnI+DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBZQU5HIGRhdGFz
dG9yZSB0byBpdHM8YnI+DQpmYWN0b3J5LWRlZmF1bHQgY29udGVudC4gVGhlIHJlc2V0IG9wZXJh
dGlvbiBtYXkgYmUgdXNlZCBlLmcuIGR1cmluZzxicj4NCmluaXRpYWwgemVyby10b3VjaCBjb25m
aWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb248YnI+DQpoYXMgbWFq
b3IgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlvbiBwcm9jZXNzIGZyb208
YnI+DQpzY3JhdGNoIGlzIHRoZSBiZXN0IG9wdGlvbi48YnI+DQo8YnI+DQpBIG5ldyByZXNldC1k
YXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuIFNldmVyYWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZzxi
cj4NCnRoZSBmYWN0b3J5LWRlZmF1bHQgY29udGVudCBhcmUgc3BlY2lmaWVkLjxicj4NCjxicj4N
Ck9wdGlvbmFsbHkgYSBuZXcgJnF1b3Q7ZmFjdG9yeS1kZWZhdWx0LXJ1bm5pbmcmcXVvdDsgcmVh
ZC1vbmx5IGRhdGFzdG9yZSBpczxicj4NCmRlZmluZWQsIHRoYXQgY29udGFpbnMgdGhlIGRhdGEg
dGhhdCB3aWxsIGJlIGNvcGllZCBvdmVyIHRvIHRoZTxicj4NCnJ1bm5pbmcgZGF0YXN0b3JlIGF0
IHJlc2V0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh
a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1
bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz
LmlldGYub3JnLjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJhbGF6cyBMZW5neWVsJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IEVyaWNzc29uIEh1bmdhcnkgTHRkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk1vYmlsZTogJiM0MzszNi03MC0z
MzAtNzkwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOkJhbGF6
cy5MZW5neWVsQGVyaWNzc29uLmNvbSI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC6988Fdggeml510mbxchi_--


From nobody Sun Oct 21 23:55:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A758130DDB for ; Sun, 21 Oct 2018 23:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 Y_zQhGA_RpAo for ; Sun, 21 Oct 2018 23:55:07 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2B441120072 for ; Sun, 21 Oct 2018 23:55:07 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 293125903F30E; Mon, 22 Oct 2018 07:55:03 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 07:55:04 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 14:54:54 +0800
From: Qin Wu 
To: Rohit R Ranade , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6d7+UoVtpxo7UuDBzpJ3BD45aUl/ikAgAQ0ZICAAKK+MA==
Date: Mon, 22 Oct 2018 06:54:54 +0000
Message-ID: 
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.china.huawei.com>
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.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.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0B9095nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 06:55:12 -0000

--_000_B8F9A780D330094D99AF023C5877DABA9B0B9095nkgeml513mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIFJvaGl0LCBzZWUgcmVwbHkgaW5saW5lIGJlbG93Lg0KDQrlj5Hku7bkuro6IG5ldG1v
ZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9oaXQgUiBSYW5hZGUN
CuWPkemAgeaXtumXtDogMjAxOOW5tDEw5pyIMjLml6UgMTI6NTkNCuaUtuS7tuS6ujogQmFsw6F6
cyBMZW5neWVsOyBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRtb2RdIE5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50
eHQNCg0KU29tZSBzdWdnZXN0aW9ucywNCg0KDQoNCjEuICAgICAgIEluIFlBTkcgbW9kdWxlLCB0
aGUgaWRlbnRpdHkgaGFzIG5hbWUgYXMg4oCcZmFjdG9yeS1kZWZhdWx04oCdLCBidXQgbWFueSBw
bGFjZXMgIHRoZSBuYW1lICJmYWN0b3J5LWRlZmF1bHQtcnVubmluZyIgaXMgdXNlZC4gSSBzdWdn
ZXN0IHdlIHVzZWQg4oCcZmFjdG9yeS1kZWZhdWx04oCdaW4gYWxsIHBsYWNlcy4NCg0KW1Fpbl06
IHdvcmtzIGZvciBtZS4NCg0KMi4gICAgICAgVGhpcyBZQU5HIG1vZHVsZSBpcyBpbXBvcnRpbmcg
aWV0Zi1uZXRjb25mIG1vZHVsZS4gSSBzdWdnZXN0IHRoYXQgdGhpcyBpbXBvcnQgc2hvdWxkIGJl
IHJlbW92ZWQgYXMgdGhpcyBtb2R1bGUgc2hvdWxkIG5vdCBoYXZlIGRlcGVuZGVuY2llcyBvbiBO
RVRDT05GLg0KDQpbUWluXTogR29vZCBjYXRjaCwgdGhhbmtzLg0KDQozLiAgICAgICBUaGUgZGVz
Y3JpcHRpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSwgc3RpbGwgaGFzIHRoZSByZWZlcmVuY2UgdG8g
PGNvcHktY29uZmlnPi4gIFdoZXRoZXIgdGhpcyBjYW4gYmUgcmVtb3ZlZCA/DQoNCltRaW5dOiBH
b29kIGNhdGNoLCB0aGFua3MuDQoNCjQuICAgICAgIFRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgaW5k
ZW50aXR5IOKAnGZhY3RvcnktZGVmYXVsdOKAnSwgc3VnZ2VzdCB0byBkZXNjcmliZSB0aGUgaWRl
bnRpdHkgcmF0aGVyIHRoYW4gdGVsbCDigJxob3figJ0gaXQgY2FuIGJlIHVzZWQuDQoNCltRaW5d
OiBPa2F5Lg0KDQo1LiAgICAgICBXaGV0aGVyIHdlIGNhbiBhbHNvIGFkZCB0aGUgc3RhdGVtZW50
IHRoYXQgaWYgdGhlIOKAnHRhcmdldC1kYXRhc3RvcmXigJ0sIGhhdmUgYmVlbiBsb2NrZWQgLCB0
aGVuIHRoZSByZXNldC1kYXRhc3RvcmUgd2lsbCBmYWlsIHdpdGggdGhlIDxlcnJvci10YWc+IHZh
bHVlIGFzIOKAnGluLXVzZeKAnSA/DQoNCltRaW5dOiBJIHRoaW5rIHdlIGNhbiByZXVzZSA8ZXJy
b3ItdGFnPiBpbiB0aGUgcnBjLWVycm9yIGVsZW1lbnQsIHNpbWlsYXIgdG8gZXhhbXBsZSBpbiBz
ZWN0aW9uIDcuNSBvZiBSRkM2MjQxLg0KDQo2LiAgICAgICBTaW5jZSB3ZSBoYXZlIHNjZW5hcmlv
IG9mIGNvcHkgdG8gbXVsdGlwbGUgdGFyZ2V0cywgd2hldGhlciB3ZSBjYW4gYWRkIGEgbGVhZiBj
YWxsZWQgdGhlIGVycm9yLW9wdGlvbiB3aXRoIHBvc3NpYmxlIHZhbHVlcyBvZiDigJxzdG9wLW9u
LWVycm9yL2NvbnRpbnVlLW9uLWVycm9yL3JvbGxiYWNrLW9uLWVycm9y4oCdICAgPw0KDQogICBb
UWluXTogU2FtZSBhcyBhYm92ZS4gU2hvdWxkIHRoZXNlIGVycm9yLW9wdGlvbiB2YWx1ZXMgYmUg
cGFydCBvZiBycGMtcmVwbHkgb3IgcGFydCBvZiBvcGVyYXRpb24gcmVxdWVzdD8gQnkgcmVhZGlu
ZyBlZGl0LWNvbmZpZyxpdCBpcyBhbHNvIG5vdCBjbGVhciB0byBtZSB3aGV0aGVyDQoNCiAgICAg
ICBFcnJvci1vcHRpb24gc2hvdWxkIGJlIHBhcnQgb2YgZWRpdC1jb25maWcgb3BlcmF0aW9uIHRo
YXQgaXMgc2VudCBpbiBycGMtcmVxdWVzdCBtZXNzYWdlLg0KDQpXaXRoIFJlZ2FyZHMsDQoNClJv
aGl0IFINCg0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBCYWzDoXpzIExlbmd5ZWwNClNlbnQ6IDE5IE9jdG9iZXIgMjAxOCAxODoxNw0K
VG86IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogW25l
dG1vZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1vZC1m
YWN0b3J5LWRlZmF1bHQtMDEudHh0DQoNCg0KSGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E
LCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dCBoYXMgYmVlbiB1cGxvYWRl
ZC4gQ2hhbmdlcyBpbmNsdWRlOg0KUmVtb3ZlZCBpbXBhY3RzIHRvIDxjb3B5LWNvbmZpZz4gYXMg
dGhlIHJlc2V0LWRhdGFzdG9yZSAgUlBDIGNhbiBhbnl3YXkgZG8gdGhlIHNhbWUgdGhpbmcuDQpF
eHBsYWluZWQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzdGFydHVwIGFuZCBmYWN0b3J5LWRlZmF1
bHQgZGF0YXN0b3Jlcw0KU21hbGwgY29ycmVjdGlvbnMuDQoNCnJlZ2FyZHMgQmFsYXpzDQoNCi0t
LS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lv
biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0
DQoNCkRhdGU6DQoNCkZyaSwgMTkgT2N0IDIwMTggMDU6MzA6MDUgLTA3MDANCg0KRnJvbToNCg0K
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+
DQoNClRvOg0KDQpZZSBOaXUgPG5pdXllQGh1YXdlaS5jb20+PG1haWx0bzpuaXV5ZUBodWF3ZWku
Y29tPiwgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+PG1haWx0bzpiaWxsLnd1QGh1YXdlaS5j
b20+LCBCYWxhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPjxtYWlsdG86
YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt
RCwgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl
c3NmdWxseSBzdWJtaXR0ZWQgYnkgQmFsYXpzIExlbmd5ZWwgYW5kIHBvc3RlZCB0byB0aGUNCklF
VEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdA0K
UmV2aXNpb246IDAxDQpUaXRsZTogRmFjdG9yeSBkZWZhdWx0IFNldHRpbmcNCkRvY3VtZW50IGRh
dGU6IDIwMTgtMTAtMTkNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAxMA0K
VVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9k
LWZhY3RvcnktZGVmYXVsdC0wMS50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC8NCkh0bWxpemVkOiBodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0w
MQ0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt
d3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdA0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj
ZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDENCg0KQWJzdHJhY3Q6
DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBZQU5HIGRhdGFzdG9y
ZSB0byBpdHMNCmZhY3RvcnktZGVmYXVsdCBjb250ZW50LiBUaGUgcmVzZXQgb3BlcmF0aW9uIG1h
eSBiZSB1c2VkIGUuZy4gZHVyaW5nDQppbml0aWFsIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiBv
ciB3aGVuIHRoZSBleGlzdGluZyBjb25maWd1cmF0aW9uDQpoYXMgbWFqb3IgZXJyb3JzLCBzbyBy
ZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlvbiBwcm9jZXNzIGZyb20NCnNjcmF0Y2ggaXMgdGhl
IGJlc3Qgb3B0aW9uLg0KDQpBIG5ldyByZXNldC1kYXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuIFNl
dmVyYWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZw0KdGhlIGZhY3RvcnktZGVmYXVsdCBjb250ZW50
IGFyZSBzcGVjaWZpZWQuDQoNCk9wdGlvbmFsbHkgYSBuZXcgImZhY3RvcnktZGVmYXVsdC1ydW5u
aW5nIiByZWFkLW9ubHkgZGF0YXN0b3JlIGlzDQpkZWZpbmVkLCB0aGF0IGNvbnRhaW5zIHRoZSBk
YXRhIHRoYXQgd2lsbCBiZSBjb3BpZWQgb3ZlciB0byB0aGUNCnJ1bm5pbmcgZGF0YXN0b3JlIGF0
IHJlc2V0Lg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl
cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF
VEYgU2VjcmV0YXJpYXQNCg0KLS0NCg0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAg
ICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KDQpTZW5pb3IgU3BlY2lhbGlzdA0KDQpNb2JpbGU6
ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNz
c29uLmNvbTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B0B9095nkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0
YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG
5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u
dC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1M
UHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRN
TCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy
IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm
b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNv
LXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9
kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg
Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM0OTk5MzcwNTsNCgltc28tbGlzdC10eXBlOmh5
YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTkwNTE1ODg4IC0xMzI4NjU4MjIyIDY3Njk4
NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz
IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTguNzVwdDsN
Cgl0ZXh0LWluZGVudDotMTguNzVwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuNXB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpvbA0K
CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+VGhhbmtzIFJvaGl0LCBzZWUgcmVwbHkgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6
ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPiBuZXRtb2QgW21haWx0
bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+Um9oaXQg
UiBSYW5hZGU8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s
b3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6
d2luZG93dGV4dCI+IDIwMTg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s
b3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxh
bmc9IkVOLVVTIj4yMjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTI6NTk8YnI+DQo8
L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIj4gQmFsPC9zcGFuPsOhPHNwYW4gbGFuZz0iRU4tVVMiPnpzIExlbmd5ZWw7IG5l
dG1vZEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv
c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90
aWZpY2F0aW9uIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxvOnA+
PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+U29tZSBzdWdnZXN0aW9ucyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0O3RleHQtaW5kZW50Oi0xOC43NXB0O21zby1saXN0
OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz
dDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh
bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SW4gWUFORyBtb2R1bGUsIHRoZSBpZGVudGl0eSBoYXMgbmFtZSBh
cyDigJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5m
YWN0b3J5LWRlZmF1bHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj7igJ0sIGJ1dCBtYW55IHBsYWNlcyAmbmJzcDt0aGUgbmFtZSA8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDtm
YWN0b3J5LWRlZmF1bHQtcnVubmluZyZxdW90OyBpcyB1c2VkLiBJIHN1Z2dlc3Qgd2UgdXNlZCA8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuKAnDxzcGFuIGxhbmc9IkVOLVVT
Ij5mYWN0b3J5LWRlZmF1bHQ8L3NwYW4+4oCdPHNwYW4gbGFuZz0iRU4tVVMiPmluIGFsbCBwbGFj
ZXMuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MTguNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5bUWluXTogd29ya3MgZm9yIG1lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0O3RleHQtaW5kZW50Oi0xOC43
NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0
eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBZQU5HIG1vZHVsZSBpcyBpbXBvcnRp
bmcgaWV0Zi1uZXRjb25mIG1vZHVsZS4gSSBzdWdnZXN0IHRoYXQgdGhpcyBpbXBvcnQgc2hvdWxk
IGJlIHJlbW92ZWQgYXMgdGhpcyBtb2R1bGUgc2hvdWxkIG5vdCBoYXZlIGRlcGVuZGVuY2llcyBv
biBORVRDT05GLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1
cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+W1Fpbl06IEdvb2QgY2F0Y2gsIHRoYW5rcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguNzVwdDt0ZXh0LWluZGVudDotMTguNzVw
dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls
ZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv
c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIFlBTkcg
bW9kdWxlLCBzdGlsbCBoYXMgdGhlIHJlZmVyZW5jZSB0byAmbHQ7Y29weS1jb25maWcmZ3Q7LiAm
bmJzcDtXaGV0aGVyIHRoaXMgY2FuIGJlIHJlbW92ZWQgPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IEdvb2QgY2F0Y2gsIHRoYW5rcy48L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu
NzVwdDt0ZXh0LWluZGVudDotMTguNzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg
IXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxl
PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBk
ZXNjcmlwdGlvbiBvZiB0aGUgaW5kZW50aXR5IOKAnGZhY3RvcnktZGVmYXVsdOKAnSwgc3VnZ2Vz
dCB0byBkZXNjcmliZSB0aGUgaWRlbnRpdHkgcmF0aGVyIHRoYW4gdGVsbCDigJxob3figJ0gaXQg
Y2FuIGJlIHVzZWQuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4
Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+W1Fpbl06IE9rYXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg
c3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4Ljc1cHQ7bXNvLWxpc3Q6
bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0
Oklnbm9yZSI+NS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu
Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5XaGV0aGVyIHdlIGNhbiBhbHNvIGFkZCB0aGUgc3RhdGVtZW50IHRo
YXQgaWYgdGhlIOKAnHRhcmdldC1kYXRhc3RvcmXigJ0sIGhhdmUgYmVlbiBsb2NrZWQgLCB0aGVu
IHRoZSByZXNldC1kYXRhc3RvcmUgd2lsbCBmYWlsIHdpdGggdGhlICZsdDtlcnJvci10YWcmZ3Q7
IHZhbHVlIGFzIOKAnGluLXVzZeKAnSA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luLWxlZnQ6MTguNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5bUWluXTogSSB0aGluayB3ZSBjYW4gcmV1c2UgJmx0O2Vycm9yLXRh
ZyZndDsgaW4gdGhlIHJwYy1lcnJvciBlbGVtZW50LCBzaW1pbGFyIHRvIGV4YW1wbGUgaW4gc2Vj
dGlvbiA3LjUgb2YgUkZDNjI0MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Ni48L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSB3ZSBoYXZl
IHNjZW5hcmlvIG9mIGNvcHkgdG8gbXVsdGlwbGUgdGFyZ2V0cywgd2hldGhlciB3ZSBjYW4gYWRk
IGEgbGVhZiBjYWxsZWQgdGhlIGVycm9yLW9wdGlvbiB3aXRoIHBvc3NpYmxlIHZhbHVlcyBvZiDi
gJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5zdG9wLW9uLWVycm9yL2NvbnRpbnVlLW9u
LWVycm9yL3JvbGxiYWNrLW9uLWVycm9yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdICZuYnNwOyZuYnNwOz88L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTogU2FtZSBhcyBhYm92ZS4g
U2hvdWxkIHRoZXNlIGVycm9yLW9wdGlvbiB2YWx1ZXMgYmUgcGFydCBvZiBycGMtcmVwbHkgb3Ig
cGFydCBvZiBvcGVyYXRpb24gcmVxdWVzdD8gQnkgcmVhZGluZyBlZGl0LWNvbmZpZyxpdCBpcyBh
bHNvIG5vdCBjbGVhciB0byBtZSB3aGV0aGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVycm9yLW9wdGlvbiBzaG91bGQg
YmUgcGFydCBvZiBlZGl0LWNvbmZpZyBvcGVyYXRpb24gdGhhdCBpcyBzZW50IGluIHJwYy1yZXF1
ZXN0IG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvaGl0IFI8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
d2luZG93dGV4dCI+IG5ldG1vZCBbPGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m
IDwvYj5CYWzDoXpzIExlbmd5ZWw8YnI+DQo8Yj5TZW50OjwvYj4gMTkgT2N0b2JlciAyMDE4IDE4
OjE3PGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRtb2RdIEZ3ZDogTmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAx
LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz
cGFuIGxhbmc9IkVOLVVTIj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0bW9kLWZh
Y3RvcnktZGVmYXVsdC0wMS50eHQgaGFzIGJlZW4gdXBsb2FkZWQuIENoYW5nZXMgaW5jbHVkZTo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPlJlbW92ZWQgaW1wYWN0cyB0byAmbHQ7Y29weS1jb25maWcmZ3Q7IGFzIHRo
ZSByZXNldC1kYXRhc3RvcmUmbmJzcDsgUlBDIGNhbiBhbnl3YXkgZG8gdGhlIHNhbWUgdGhpbmcu
DQo8YnI+DQpFeHBsYWluZWQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzdGFydHVwIGFuZCBmYWN0
b3J5LWRlZmF1bHQgZGF0YXN0b3JlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TbWFsbCBjb3JyZWN0
aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJl
Z2FyZHMgQmFsYXpzPGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0t
LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg
Ym9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRy
Pg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g
MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxp
Z246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0Og0KPG86cD48L286cD48L3Nw
YW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OZXcgVmVyc2lvbiBOb3Rp
ZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGln
bj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiPkRhdGU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBz
dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPkZyaSwgMTkgT2N0IDIwMTggMDU6MzA6MDUgLTA3MDA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0
b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJF
Ti1VUyI+RnJvbToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl
PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNt
IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9
InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbzoNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WWUgTml1IDxhIGhy
ZWY9Im1haWx0bzpuaXV5ZUBodWF3ZWkuY29tIj4NCiZsdDtuaXV5ZUBodWF3ZWkuY29tJmd0Ozwv
YT4sIFFpbiBXdSA8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIj4mbHQ7YmlsbC53
dUBodWF3ZWkuY29tJmd0OzwvYT4sIEJhbGF6cyBMZW5neWVsDQo8YSBocmVmPSJtYWlsdG86YmFs
YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIj4mbHQ7YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t
Jmd0OzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8
L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PGJyPg0KaGFzIGJlZW4g
c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCYWxhenMgTGVuZ3llbCBhbmQgcG9zdGVkIHRvIHRo
ZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiBkcmFmdC13dS1uZXRtb2Qt
ZmFjdG9yeS1kZWZhdWx0PGJyPg0KUmV2aXNpb246IDAxPGJyPg0KVGl0bGU6IEZhY3RvcnkgZGVm
YXVsdCBTZXR0aW5nPGJyPg0KRG9jdW1lbnQgZGF0ZTogMjAxOC0xMC0xOTxicj4NCkdyb3VwOiBJ
bmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczogMTA8YnI+DQpVUkw6IDxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QtZmFjdG9y
eS1kZWZhdWx0LTAxLnR4dCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQ8L2E+PGJyPg0KU3RhdHVzOiA8
YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1uZXRtb2Qt
ZmFjdG9yeS1kZWZhdWx0LyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LzwvYT48YnI+DQpIdG1saXplZDogPGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1
bHQtMDEiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1mYWN0
b3J5LWRlZmF1bHQtMDE8L2E+PGJyPg0KSHRtbGl6ZWQ6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdCI+
DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1LW5ldG1vZC1m
YWN0b3J5LWRlZmF1bHQ8L2E+PGJyPg0KRGlmZjogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEiPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRl
ZmF1bHQtMDE8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KVGhpcyBkb2N1bWVudCBkZWZp
bmVzIGEgbWV0aG9kIHRvIHJlc2V0IGEgWUFORyBkYXRhc3RvcmUgdG8gaXRzPGJyPg0KZmFjdG9y
eS1kZWZhdWx0IGNvbnRlbnQuIFRoZSByZXNldCBvcGVyYXRpb24gbWF5IGJlIHVzZWQgZS5nLiBk
dXJpbmc8YnI+DQppbml0aWFsIHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiBvciB3aGVuIHRoZSBl
eGlzdGluZyBjb25maWd1cmF0aW9uPGJyPg0KaGFzIG1ham9yIGVycm9ycywgc28gcmUtc3RhcnRp
bmcgdGhlIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyBmcm9tPGJyPg0Kc2NyYXRjaCBpcyB0aGUgYmVz
dCBvcHRpb24uPGJyPg0KPGJyPg0KQSBuZXcgcmVzZXQtZGF0YXN0b3JlIFJQQyBpcyBkZWZpbmVk
LiBTZXZlcmFsIG1ldGhvZHMgb2YgZG9jdW1lbnRpbmc8YnI+DQp0aGUgZmFjdG9yeS1kZWZhdWx0
IGNvbnRlbnQgYXJlIHNwZWNpZmllZC48YnI+DQo8YnI+DQpPcHRpb25hbGx5IGEgbmV3ICZxdW90
O2ZhY3RvcnktZGVmYXVsdC1ydW5uaW5nJnF1b3Q7IHJlYWQtb25seSBkYXRhc3RvcmUgaXM8YnI+
DQpkZWZpbmVkLCB0aGF0IGNvbnRhaW5zIHRoZSBkYXRhIHRoYXQgd2lsbCBiZSBjb3BpZWQgb3Zl
ciB0byB0aGU8YnI+DQpydW5uaW5nIGRhdGFzdG9yZSBhdCByZXNldC48YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg
ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp
b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpU
aGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj5CYWxhenMgTGVuZ3llbCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFcmljc3NvbiBI
dW5nYXJ5IEx0ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t
VVMiPlNlbmlvciBTcGVjaWFsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
IGxhbmc9IkVOLVVTIj5Nb2JpbGU6ICYjNDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20i
PkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTwvYT4gPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B8F9A780D330094D99AF023C5877DABA9B0B9095nkgeml513mbxchi_--


From nobody Mon Oct 22 02:39:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E24130EA0 for ; Mon, 22 Oct 2018 02:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 zM-MWCc8CWlq for ; Mon, 22 Oct 2018 02:39:35 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 477C4130E4D for ; Mon, 22 Oct 2018 02:39:35 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CD67CC6C2F5D5; Mon, 22 Oct 2018 10:39:31 +0100 (IST)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 10:39:32 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.196]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0399.000; Mon, 22 Oct 2018 17:39:18 +0800
From: Rohit R Ranade 
To: Qin Wu , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6edTUJh1sqnT0SD+ZwzekOYOaUmhEAAgAQuqKD//5/yAIAAsCNw
Date: Mon, 22 Oct 2018 09:39:18 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BC69A29@dggeml510-mbx.china.huawei.com>
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BC69A29dggeml510mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 09:39:47 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC69A29dggeml510mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Ni4gICAgICAgU2luY2Ugd2UgaGF2ZSBzY2VuYXJpbyBvZiBjb3B5IHRvIG11bHRpcGxlIHRhcmdl
dHMsIHdoZXRoZXIgd2UgY2FuIGFkZCBhIGxlYWYgY2FsbGVkIHRoZSBlcnJvci1vcHRpb24gd2l0
aCBwb3NzaWJsZSB2YWx1ZXMgb2Yg4oCcc3RvcC1vbi1lcnJvci9jb250aW51ZS1vbi1lcnJvci9y
b2xsYmFjay1vbi1lcnJvcuKAnSAgID8NCg0KICAgW1Fpbl06IFNhbWUgYXMgYWJvdmUuIFNob3Vs
ZCB0aGVzZSBlcnJvci1vcHRpb24gdmFsdWVzIGJlIHBhcnQgb2YgcnBjLXJlcGx5IG9yIHBhcnQg
b2Ygb3BlcmF0aW9uIHJlcXVlc3Q/IEJ5IHJlYWRpbmcgZWRpdC1jb25maWcsaXQgaXMgYWxzbyBu
b3QgY2xlYXIgdG8gbWUgd2hldGhlcg0KDQogICAgICAgRXJyb3Itb3B0aW9uIHNob3VsZCBiZSBw
YXJ0IG9mIGVkaXQtY29uZmlnIG9wZXJhdGlvbiB0aGF0IGlzIHNlbnQgaW4gcnBjLXJlcXVlc3Qg
bWVzc2FnZS4NCg0KDQpbUm9oaXRdIDxlcnJvci1vcHRpb24+IGlzIGFuIGlucHV0IHRvIHRoZSBl
ZGl0LWNvbmZpZyBycGMtcmVxdWVzdC4gICBTbyBJIHN1Z2dlc3RlZCB0byBoYXZlIGEgc2ltaWxh
ciBhcHByb2FjaC4gQnV0IHRoaXMgbXVsdGktZGF0YXN0b3JlIGNvcHkgd2lsbCBiZSB0cmlja3kg
YmVjYXVzZSBpZiB3ZSBnaXZlIHR3byB0YXJnZXRzIHNheSA8cnVubmluZz4gLyA8c3RhcnR1cD4g
YW5kIGlmIGFmdGVyIGNvcHkgdG8gPHJ1bm5pbmc+LCBjb3B5IHRvIDxzdGFydHVwPiBmYWlscywg
IHRoZW4gaG93IHRvIGhhbmRsZSB0aGlzID8gIFJldmVydCA8cnVubmluZz4gY29uZmlnID8NCg0K
SSBzdWdnZXN0IHRvIHJlc3RyaWN0IHRoZSBjb3B5IG9mIGZhY3RvcnkgZGF0YXN0b3JlIHRvIGEg
c2luZ2xlIHRhcmdldCBkYXRhc3RvcmUgZm9yIG5vdy4NCldpdGggUmVnYXJkcywNClJvaGl0IFIN
Cg0KDQpGcm9tOiBRaW4gV3UNClNlbnQ6IDIyIE9jdG9iZXIgMjAxOCAxMjoyNQ0KVG86IFJvaGl0
IFIgUmFuYWRlIDxyb2hpdHJyYW5hZGVAaHVhd2VpLmNvbT47IEJhbMOhenMgTGVuZ3llbCA8YmFs
YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPjsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSRTog
TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZh
dWx0LTAxLnR4dA0KDQpUaGFua3MgUm9oaXQsIHNlZSByZXBseSBpbmxpbmUgYmVsb3cuDQoNCuWP
keS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBS
b2hpdCBSIFJhbmFkZQ0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDmnIgyMuaXpSAxMjo1OQ0K5pS2
5Lu25Lq6OiBCYWzDoXpzIExlbmd5ZWw7IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll
dGYub3JnPg0K5Li76aKYOiBSZTogW25ldG1vZF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv
ciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KDQpTb21lIHN1Z2dlc3Rp
b25zLA0KDQoNCg0KMS4gICAgICAgSW4gWUFORyBtb2R1bGUsIHRoZSBpZGVudGl0eSBoYXMgbmFt
ZSBhcyDigJxmYWN0b3J5LWRlZmF1bHTigJ0sIGJ1dCBtYW55IHBsYWNlcyAgdGhlIG5hbWUgImZh
Y3RvcnktZGVmYXVsdC1ydW5uaW5nIiBpcyB1c2VkLiBJIHN1Z2dlc3Qgd2UgdXNlZCDigJxmYWN0
b3J5LWRlZmF1bHTigJ1pbiBhbGwgcGxhY2VzLg0KDQpbUWluXTogd29ya3MgZm9yIG1lLg0KDQoy
LiAgICAgICBUaGlzIFlBTkcgbW9kdWxlIGlzIGltcG9ydGluZyBpZXRmLW5ldGNvbmYgbW9kdWxl
LiBJIHN1Z2dlc3QgdGhhdCB0aGlzIGltcG9ydCBzaG91bGQgYmUgcmVtb3ZlZCBhcyB0aGlzIG1v
ZHVsZSBzaG91bGQgbm90IGhhdmUgZGVwZW5kZW5jaWVzIG9uIE5FVENPTkYuDQoNCltRaW5dOiBH
b29kIGNhdGNoLCB0aGFua3MuDQoNCjMuICAgICAgIFRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIFlB
TkcgbW9kdWxlLCBzdGlsbCBoYXMgdGhlIHJlZmVyZW5jZSB0byA8Y29weS1jb25maWc+LiAgV2hl
dGhlciB0aGlzIGNhbiBiZSByZW1vdmVkID8NCg0KW1Fpbl06IEdvb2QgY2F0Y2gsIHRoYW5rcy4N
Cg0KNC4gICAgICAgVGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBpbmRlbnRpdHkg4oCcZmFjdG9yeS1k
ZWZhdWx04oCdLCBzdWdnZXN0IHRvIGRlc2NyaWJlIHRoZSBpZGVudGl0eSByYXRoZXIgdGhhbiB0
ZWxsIOKAnGhvd+KAnSBpdCBjYW4gYmUgdXNlZC4NCg0KW1Fpbl06IE9rYXkuDQoNCjUuICAgICAg
IFdoZXRoZXIgd2UgY2FuIGFsc28gYWRkIHRoZSBzdGF0ZW1lbnQgdGhhdCBpZiB0aGUg4oCcdGFy
Z2V0LWRhdGFzdG9yZeKAnSwgaGF2ZSBiZWVuIGxvY2tlZCAsIHRoZW4gdGhlIHJlc2V0LWRhdGFz
dG9yZSB3aWxsIGZhaWwgd2l0aCB0aGUgPGVycm9yLXRhZz4gdmFsdWUgYXMg4oCcaW4tdXNl4oCd
ID8NCg0KW1Fpbl06IEkgdGhpbmsgd2UgY2FuIHJldXNlIDxlcnJvci10YWc+IGluIHRoZSBycGMt
ZXJyb3IgZWxlbWVudCwgc2ltaWxhciB0byBleGFtcGxlIGluIHNlY3Rpb24gNy41IG9mIFJGQzYy
NDEuDQoNCjYuICAgICAgIFNpbmNlIHdlIGhhdmUgc2NlbmFyaW8gb2YgY29weSB0byBtdWx0aXBs
ZSB0YXJnZXRzLCB3aGV0aGVyIHdlIGNhbiBhZGQgYSBsZWFmIGNhbGxlZCB0aGUgZXJyb3Itb3B0
aW9uIHdpdGggcG9zc2libGUgdmFsdWVzIG9mIOKAnHN0b3Atb24tZXJyb3IvY29udGludWUtb24t
ZXJyb3Ivcm9sbGJhY2stb24tZXJyb3LigJ0gICA/DQoNCiAgIFtRaW5dOiBTYW1lIGFzIGFib3Zl
LiBTaG91bGQgdGhlc2UgZXJyb3Itb3B0aW9uIHZhbHVlcyBiZSBwYXJ0IG9mIHJwYy1yZXBseSBv
ciBwYXJ0IG9mIG9wZXJhdGlvbiByZXF1ZXN0PyBCeSByZWFkaW5nIGVkaXQtY29uZmlnLGl0IGlz
IGFsc28gbm90IGNsZWFyIHRvIG1lIHdoZXRoZXINCg0KICAgICAgIEVycm9yLW9wdGlvbiBzaG91
bGQgYmUgcGFydCBvZiBlZGl0LWNvbmZpZyBvcGVyYXRpb24gdGhhdCBpcyBzZW50IGluIHJwYy1y
ZXF1ZXN0IG1lc3NhZ2UuDQoNCldpdGggUmVnYXJkcywNCg0KUm9oaXQgUg0KDQpGcm9tOiBuZXRt
b2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhbMOhenMg
TGVuZ3llbA0KU2VudDogMTkgT2N0b2JlciAyMDE4IDE4OjE3DQpUbzogbmV0bW9kQGlldGYub3Jn
PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbmV0bW9kXSBGd2Q6IE5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50
eHQNCg0KDQpIZWxsbywNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW5ldG1vZC1m
YWN0b3J5LWRlZmF1bHQtMDEudHh0IGhhcyBiZWVuIHVwbG9hZGVkLiBDaGFuZ2VzIGluY2x1ZGU6
DQpSZW1vdmVkIGltcGFjdHMgdG8gPGNvcHktY29uZmlnPiBhcyB0aGUgcmVzZXQtZGF0YXN0b3Jl
ICBSUEMgY2FuIGFueXdheSBkbyB0aGUgc2FtZSB0aGluZy4NCkV4cGxhaW5lZCB0aGUgZGlmZmVy
ZW5jZSBiZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVmYXVsdCBkYXRhc3RvcmVzDQpTbWFs
bCBjb3JyZWN0aW9ucy4NCg0KcmVnYXJkcyBCYWxhenMNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1l
c3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig
ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCg0KRGF0ZToNCg0KRnJpLCAx
OSBPY3QgMjAxOCAwNTozMDowNSAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNClllIE5pdSA8
bml1eWVAaHVhd2VpLmNvbT48bWFpbHRvOm5pdXllQGh1YXdlaS5jb20+LCBRaW4gV3UgPGJpbGwu
d3VAaHVhd2VpLmNvbT48bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4sIEJhbGF6cyBMZW5neWVs
IDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmlj
c3Nvbi5jb20+DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13dS1uZXRtb2Qt
ZmFjdG9yeS1kZWZhdWx0LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi
eSBCYWxhenMgTGVuZ3llbCBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpO
YW1lOiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0DQpSZXZpc2lvbjogMDENClRpdGxl
OiBGYWN0b3J5IGRlZmF1bHQgU2V0dGluZw0KRG9jdW1lbnQgZGF0ZTogMjAxOC0xMC0xOQ0KR3Jv
dXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEwDQpVUkw6IGh0dHBzOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAx
LnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1u
ZXRtb2QtZmFjdG9yeS1kZWZhdWx0Lw0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxDQpIdG1saXplZDogaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1k
ZWZhdWx0DQpEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3Ut
bmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMQ0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVm
aW5lcyBhIG1ldGhvZCB0byByZXNldCBhIFlBTkcgZGF0YXN0b3JlIHRvIGl0cw0KZmFjdG9yeS1k
ZWZhdWx0IGNvbnRlbnQuIFRoZSByZXNldCBvcGVyYXRpb24gbWF5IGJlIHVzZWQgZS5nLiBkdXJp
bmcNCmluaXRpYWwgemVyby10b3VjaCBjb25maWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5n
IGNvbmZpZ3VyYXRpb24NCmhhcyBtYWpvciBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5nIHRoZSBjb25m
aWd1cmF0aW9uIHByb2Nlc3MgZnJvbQ0Kc2NyYXRjaCBpcyB0aGUgYmVzdCBvcHRpb24uDQoNCkEg
bmV3IHJlc2V0LWRhdGFzdG9yZSBSUEMgaXMgZGVmaW5lZC4gU2V2ZXJhbCBtZXRob2RzIG9mIGRv
Y3VtZW50aW5nDQp0aGUgZmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQgYXJlIHNwZWNpZmllZC4NCg0K
T3B0aW9uYWxseSBhIG5ldyAiZmFjdG9yeS1kZWZhdWx0LXJ1bm5pbmciIHJlYWQtb25seSBkYXRh
c3RvcmUgaXMNCmRlZmluZWQsIHRoYXQgY29udGFpbnMgdGhlIGRhdGEgdGhhdCB3aWxsIGJlIGNv
cGllZCBvdmVyIHRvIHRoZQ0KcnVubmluZyBkYXRhc3RvcmUgYXQgcmVzZXQuDQoNCg0KDQpQbGVh
c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt
ZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg
YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQot
LQ0KDQpCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2Fy
eSBMdGQuDQoNClNlbmlvciBTcGVjaWFsaXN0DQoNCk1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAg
ICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpCYWxh
enMuTGVuZ3llbEBlcmljc3Nvbi5jb20+DQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC69A29dggeml510mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0
YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU
ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29M
aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K
CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJdGV4dC1pbmRlbnQ6MjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6
5a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnAuSFRNTCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNv
LXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDp
ooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu
vuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpz
cGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnAuYSwgbGkuYSwgZGl2
LmENCgl7bXNvLXN0eWxlLW5hbWU65om55rOo5qGG5paH5pysOw0KCW1zby1zdHlsZS1saW5rOiLm
ibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6Ymxh
Y2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+ac
rDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu
aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNDk5OTM3MDU7DQoJbXNvLWxpc3Qt
dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU5MDUxNTg4OCAtMTMyODY1ODIy
MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2
NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4
Ljc1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4Ljc1cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjVw
dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N
CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww
OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQN
Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s
ZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFi
LXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1
Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N
CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXtt
YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg
c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi
IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+
DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJw
dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjYuPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5TaW5jZSB3ZSBoYXZlIHNjZW5hcmlvIG9mIGNvcHkgdG8gbXVsdGlwbGUgdGFyZ2V0
cywgd2hldGhlciB3ZSBjYW4gYWRkIGEgbGVhZiBjYWxsZWQgdGhlIGVycm9yLW9wdGlvbiB3aXRo
IHBvc3NpYmxlIHZhbHVlcyBvZiDigJw8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+c3RvcC1vbi1lcnJvci9jb250aW51ZS1vbi1lcnJvci9yb2xsYmFjay1vbi1lcnJvcjwvc3Bh
bj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJ0g
Jm5ic3A7Jm5ic3A7Pzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wcmU+DQo8cHJlPjxpPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz
cDsmbmJzcDsgPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPltRaW5dOiBTYW1lIGFzIGFib3ZlLiBTaG91bGQgdGhlc2UgZXJyb3Itb3B0aW9u
IHZhbHVlcyBiZSBwYXJ0IG9mIHJwYy1yZXBseSBvciBwYXJ0IG9mIG9wZXJhdGlvbiByZXF1ZXN0
PyBCeSByZWFkaW5nIGVkaXQtY29uZmlnLGl0IGlzIGFsc28gbm90IGNsZWFyIHRvIG1lIHdoZXRo
ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wcmU+DQo8cHJlPjxpPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IEVycm9yLW9wdGlvbiBzaG91bGQgYmUgcGFydCBvZiBlZGl0LWNvbmZpZyBvcGVyYXRp
b24gdGhhdCBpcyBzZW50IGluIHJwYy1yZXF1ZXN0IG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+
PC9pPjwvcHJlPg0KPHByZT48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3ByZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvaGl0
XSAmbHQ7ZXJyb3Itb3B0aW9uJmd0OyBpcyBhbiBpbnB1dCB0byB0aGUgZWRpdC1jb25maWcgcnBj
LXJlcXVlc3QuICZuYnNwOyZuYnNwO1NvIEkgc3VnZ2VzdGVkIHRvIGhhdmUgYSBzaW1pbGFyIGFw
cHJvYWNoLiBCdXQgdGhpcyBtdWx0aS1kYXRhc3RvcmUgY29weSB3aWxsDQogYmUgdHJpY2t5IGJl
Y2F1c2UgaWYgd2UgZ2l2ZSB0d28gdGFyZ2V0cyBzYXkgJmx0O3J1bm5pbmcmZ3Q7IC8gJmx0O3N0
YXJ0dXAmZ3Q7IGFuZCBpZiBhZnRlciBjb3B5IHRvICZsdDtydW5uaW5nJmd0OywgY29weSB0byAm
bHQ7c3RhcnR1cCZndDsgZmFpbHMsJm5ic3A7IHRoZW4gaG93IHRvIGhhbmRsZSB0aGlzID8gJm5i
c3A7UmV2ZXJ0ICZsdDtydW5uaW5nJmd0OyBjb25maWcgPyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBz
dWdnZXN0IHRvIHJlc3RyaWN0IHRoZSBjb3B5IG9mIGZhY3RvcnkgZGF0YXN0b3JlIHRvIGEgc2lu
Z2xlIHRhcmdldCBkYXRhc3RvcmUgZm9yIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRzLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9oaXQgUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k
b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjp3aW5kb3d0ZXh0Ij4gUWluIFd1DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjIgT2N0b2JlciAyMDE4
IDEyOjI1PGJyPg0KPGI+VG86PC9iPiBSb2hpdCBSIFJhbmFkZSAmbHQ7cm9oaXRycmFuYWRlQGh1
YXdlaS5jb20mZ3Q7OyBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29u
LmNvbSZndDs7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogTmV3IFZl
cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAx
LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5UaGFua3MgUm9oaXQsIHNlZSByZXBseSBpbmxpbmUgYmVsb3cuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4g
bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IG5ldG1vZCBbPGEgaHJlZj0ibWFp
bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndp
bmRvd3RleHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij5Sb2hpdCBSIFJhbmFkZTxicj4NCjwvc3Bh
bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hp
gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gMjAxODwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij7lubQ8
c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIyPC9zcGFu
PuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAxMjo1OTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8
c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBCYWw8L3Nw
YW4+w6E8c3BhbiBsYW5nPSJFTi1VUyI+enMgTGVuZ3llbDsNCjxhIGhyZWY9Im1haWx0bzpuZXRt
b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNw
YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtuZXRt
b2RdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3Rvcnkt
ZGVmYXVsdC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvbWUgc3VnZ2VzdGlvbnMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguNzVwdDt0ZXh0LWluZGVudDotMTguNzVwdDtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu
b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z
cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PkluIFlBTkcgbW9kdWxlLCB0aGUgaWRlbnRpdHkgaGFzIG5hbWUgYXMg4oCcPC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ZmFjdG9yeS1kZWZhdWx0PC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCdLCBidXQg
bWFueSBwbGFjZXMgJm5ic3A7dGhlIG5hbWUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7ZmFjdG9yeS1kZWZhdWx0LXJ1bm5pbmcmcXVvdDsg
aXMgdXNlZC4gSSBzdWdnZXN0IHdlIHVzZWQgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij7igJw8c3BhbiBsYW5nPSJFTi1VUyI+ZmFjdG9yeS1kZWZhdWx0PC9zcGFuPuKAnTxz
cGFuIGxhbmc9IkVOLVVTIj5pbiBhbGwgcGxhY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IHdvcmtzIGZvciBtZS48L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguNzVwdDt0
ZXh0LWluZGVudDotMTguNzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv
cnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3Bh
biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90
O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgWUFORyBtb2R1bGUgaXMgaW1wb3J0aW5nIGlldGYt
bmV0Y29uZiBtb2R1bGUuIEkgc3VnZ2VzdCB0aGF0IHRoaXMgaW1wb3J0IHNob3VsZCBiZSByZW1v
dmVkIGFzIHRoaXMgbW9kdWxlIHNob3VsZCBub3QgaGF2ZSBkZXBlbmRlbmNpZXMgb24gTkVUQ09O
Ri48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBHb29kIGNhdGNoLCB0aGFua3MuPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0
OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4
Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4Ljc1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm
ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBw
dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZGVzY3JpcHRpb24gb2YgdGhpcyBZQU5H
IG1vZHVsZSwgc3RpbGwgaGFzIHRoZSByZWZlcmVuY2UgdG8gJmx0O2NvcHktY29uZmlnJmd0Oy4g
Jm5ic3A7V2hldGhlciB0aGlzIGNhbiBiZSByZW1vdmVkID88L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW4tbGVmdDoxOC43NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPltRaW5dOiBHb29kIGNhdGNoLCB0aGFua3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4Ljc1
cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0
Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu
Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5UaGUgZGVzY3JpcHRpb24gb2YgdGhlIGluZGVudGl0eSDigJxmYWN0b3J5LWRlZmF1bHTi
gJ0sIHN1Z2dlc3QgdG8gZGVzY3JpYmUgdGhlIGlkZW50aXR5IHJhdGhlciB0aGFuIHRlbGwg4oCc
aG934oCdIGl0IGNhbiBiZSB1c2VkLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43
NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBP
a2F5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s
b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
bGVmdDoxOC43NXB0O3RleHQtaW5kZW50Oi0xOC43NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8y
Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjUuPHNwYW4gc3R5bGU9ImZv
bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hldGhlciB3ZSBjYW4gYWxzbyBh
ZGQgdGhlIHN0YXRlbWVudCB0aGF0IGlmIHRoZSDigJx0YXJnZXQtZGF0YXN0b3Jl4oCdLCBoYXZl
IGJlZW4gbG9ja2VkICwgdGhlbiB0aGUgcmVzZXQtZGF0YXN0b3JlIHdpbGwgZmFpbCB3aXRoIHRo
ZSAmbHQ7ZXJyb3ItdGFnJmd0OyB2YWx1ZSBhcyDigJxpbi11c2XigJ0gPzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+W1Fpbl06IEkgdGhpbmsgd2UgY2FuIHJldXNlICZsdDtlcnJvci10YWcmZ3Q7
IGluIHRoZSBycGMtZXJyb3IgZWxlbWVudCwgc2ltaWxhciB0byBleGFtcGxlIGluIHNlY3Rpb24g
Ny41IG9mIFJGQzYyNDEuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjYuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+U2luY2Ugd2UgaGF2ZSBzY2VuYXJpbyBvZiBjb3B5IHRvIG11bHRpcGxlIHRhcmdldHMsIHdo
ZXRoZXIgd2UgY2FuIGFkZCBhIGxlYWYgY2FsbGVkIHRoZSBlcnJvci1vcHRpb24gd2l0aCBwb3Nz
aWJsZSB2YWx1ZXMgb2Yg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+c3RvcC1vbi1l
cnJvci9jb250aW51ZS1vbi1lcnJvci9yb2xsYmFjay1vbi1lcnJvcjwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnSAmbmJzcDsmbmJzcDs/PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl06IFNhbWUgYXMgYWJvdmUuIFNob3VsZCB0
aGVzZSBlcnJvci1vcHRpb24gdmFsdWVzIGJlIHBhcnQgb2YgcnBjLXJlcGx5IG9yIHBhcnQgb2Yg
b3BlcmF0aW9uIHJlcXVlc3Q/IEJ5IHJlYWRpbmcgZWRpdC1jb25maWcsaXQgaXMgYWxzbyBub3Qg
Y2xlYXIgdG8gbWUgd2hldGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBFcnJvci1vcHRpb24gc2hvdWxkIGJlIHBhcnQgb2YgZWRpdC1jb25m
aWcgb3BlcmF0aW9uIHRoYXQgaXMgc2VudCBpbiBycGMtcmVxdWVzdCBtZXNzYWdlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPldpdGggUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb2hpdCBSPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBuZXRtb2QgWzxh
IGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmFsw6F6cyBMZW5neWVsPGJy
Pg0KPGI+U2VudDo8L2I+IDE5IE9jdG9iZXIgMjAxOCAxODoxNzxicj4NCjxiPlRvOjwvYj4gPGEg
aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBbbmV0bW9kXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig
ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5I
ZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+QSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0IGhh
cyBiZWVuIHVwbG9hZGVkLiBDaGFuZ2VzIGluY2x1ZGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZW1vdmVkIGlt
cGFjdHMgdG8gJmx0O2NvcHktY29uZmlnJmd0OyBhcyB0aGUgcmVzZXQtZGF0YXN0b3JlJm5ic3A7
IFJQQyBjYW4gYW55d2F5IGRvIHRoZSBzYW1lIHRoaW5nLg0KPGJyPg0KRXhwbGFpbmVkIHRoZSBk
aWZmZXJlbmNlIGJldHdlZW4gc3RhcnR1cCBhbmQgZmFjdG9yeS1kZWZhdWx0IGRhdGFzdG9yZXM8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+U21hbGwgY29ycmVjdGlvbnMuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWdhcmRzIEJhbGF6czxicj4NCjxicj4N
Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9
IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu
PSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5n
PSJFTi1VUyI+U3ViamVjdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRk
IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1u
ZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+
DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6
MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5
bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5EYXRlOg0KPG86cD48
L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GcmksIDE5
IE9jdCAyMDE4IDA1OjMwOjA1IC0wNzAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv
dHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20g
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0i
dGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206DQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1h
aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9
IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48
c3BhbiBsYW5nPSJFTi1VUyI+VG86DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4N
Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllIE5pdSA8YSBocmVmPSJtYWlsdG86bml1eWVAaHVhd2Vp
LmNvbSI+DQombHQ7bml1eWVAaHVhd2VpLmNvbSZndDs8L2E+LCBRaW4gV3UgPGEgaHJlZj0ibWFp
bHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+Jmx0O2JpbGwud3VAaHVhd2VpLmNvbSZndDs8L2E+LCBC
YWxhenMgTGVuZ3llbA0KPGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bSI+Jmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZndDs8L2E+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi
cj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13dS1uZXRtb2QtZmFj
dG9yeS1kZWZhdWx0LTAxLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg
YnkgQmFsYXpzIExlbmd5ZWwgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnku
PGJyPg0KPGJyPg0KTmFtZTogZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdDxicj4NClJl
dmlzaW9uOiAwMTxicj4NClRpdGxlOiBGYWN0b3J5IGRlZmF1bHQgU2V0dGluZzxicj4NCkRvY3Vt
ZW50IGRhdGU6IDIwMTgtMTAtMTk8YnI+DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJy
Pg0KUGFnZXM6IDEwPGJyPg0KVVJMOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQiPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5
LWRlZmF1bHQtMDEudHh0PC9hPjxicj4NClN0YXR1czogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC8iPg0KaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdC88L2E+PGJyPg0KSHRtbGl6ZWQ6IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxIj4NCmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxPC9hPjxicj4N
Ckh0bWxpemVkOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s
L2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0PC9hPjxicj4N
CkRpZmY6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13
dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMj1kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxPC9hPjxicj4NCjxicj4N
CkFic3RyYWN0Ojxicj4NClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhvZCB0byByZXNldCBh
IFlBTkcgZGF0YXN0b3JlIHRvIGl0czxicj4NCmZhY3RvcnktZGVmYXVsdCBjb250ZW50LiBUaGUg
cmVzZXQgb3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nPGJyPg0KaW5pdGlhbCB6ZXJv
LXRvdWNoIGNvbmZpZ3VyYXRpb24gb3Igd2hlbiB0aGUgZXhpc3RpbmcgY29uZmlndXJhdGlvbjxi
cj4NCmhhcyBtYWpvciBlcnJvcnMsIHNvIHJlLXN0YXJ0aW5nIHRoZSBjb25maWd1cmF0aW9uIHBy
b2Nlc3MgZnJvbTxicj4NCnNjcmF0Y2ggaXMgdGhlIGJlc3Qgb3B0aW9uLjxicj4NCjxicj4NCkEg
bmV3IHJlc2V0LWRhdGFzdG9yZSBSUEMgaXMgZGVmaW5lZC4gU2V2ZXJhbCBtZXRob2RzIG9mIGRv
Y3VtZW50aW5nPGJyPg0KdGhlIGZhY3RvcnktZGVmYXVsdCBjb250ZW50IGFyZSBzcGVjaWZpZWQu
PGJyPg0KPGJyPg0KT3B0aW9uYWxseSBhIG5ldyAmcXVvdDtmYWN0b3J5LWRlZmF1bHQtcnVubmlu
ZyZxdW90OyByZWFkLW9ubHkgZGF0YXN0b3JlIGlzPGJyPg0KZGVmaW5lZCwgdGhhdCBjb250YWlu
cyB0aGUgZGF0YSB0aGF0IHdpbGwgYmUgY29waWVkIG92ZXIgdG8gdGhlPGJyPg0KcnVubmluZyBk
YXRhc3RvcmUgYXQgcmVzZXQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh
dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz
c2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi
bGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QmFsYXpzIExl
bmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW5pb3IgU3BlY2lhbGlzdDxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TW9iaWxlOiAm
IzQzOzM2LTcwLTMzMC03OTA5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVtYWlsOiA8YSBocmVmPSJt
YWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tIj5CYWxhenMuTGVuZ3llbEBlcmljc3Nv
bi5jb208L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0
bWw+DQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6BC69A29dggeml510mbxchi_--


From nobody Mon Oct 22 05:28:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D76130DFB for ; Mon, 22 Oct 2018 05:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 fXY4ThuyrBwA for ; Mon, 22 Oct 2018 05:28:08 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5301B130E05 for ; Mon, 22 Oct 2018 05:28:08 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E77DC1692C5FB; Mon, 22 Oct 2018 13:28:03 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 13:28:04 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 20:27:52 +0800
From: Qin Wu 
To: Rohit R Ranade , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6d7+UoVtpxo7UuDBzpJ3BD45aUl/ikAgAQ0ZICAAKK+MP//q34AgACz8yA=
Date: Mon, 22 Oct 2018 12:27:52 +0000
Message-ID: 
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.china.huawei.com>  <991B70D8B4112A4699D5C00DDBBF878A6BC69A29@dggeml510-mbx.china.huawei.com>
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC69A29@dggeml510-mbx.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.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0BAD6Bnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 12:28:12 -0000

--_000_B8F9A780D330094D99AF023C5877DABA9B0BAD6Bnkgeml513mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

5Y+R5Lu25Lq6OiBSb2hpdCBSIFJhbmFkZQ0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDmnIgyMuaX
pSAxNzozOQ0K5pS25Lu25Lq6OiBRaW4gV3U7IEJhbMOhenMgTGVuZ3llbDsgbmV0bW9kQGlldGYu
b3JnDQrkuLvpopg6IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0DQoNCg0KNi4gICAgICAgU2luY2Ugd2UgaGF2ZSBz
Y2VuYXJpbyBvZiBjb3B5IHRvIG11bHRpcGxlIHRhcmdldHMsIHdoZXRoZXIgd2UgY2FuIGFkZCBh
IGxlYWYgY2FsbGVkIHRoZSBlcnJvci1vcHRpb24gd2l0aCBwb3NzaWJsZSB2YWx1ZXMgb2Yg4oCc
c3RvcC1vbi1lcnJvci9jb250aW51ZS1vbi1lcnJvci9yb2xsYmFjay1vbi1lcnJvcuKAnSAgID8N
Cg0KICAgW1Fpbl06IFNhbWUgYXMgYWJvdmUuIFNob3VsZCB0aGVzZSBlcnJvci1vcHRpb24gdmFs
dWVzIGJlIHBhcnQgb2YgcnBjLXJlcGx5IG9yIHBhcnQgb2Ygb3BlcmF0aW9uIHJlcXVlc3Q/IEJ5
IHJlYWRpbmcgZWRpdC1jb25maWcsaXQgaXMgYWxzbyBub3QgY2xlYXIgdG8gbWUgd2hldGhlcg0K
DQogICAgICAgRXJyb3Itb3B0aW9uIHNob3VsZCBiZSBwYXJ0IG9mIGVkaXQtY29uZmlnIG9wZXJh
dGlvbiB0aGF0IGlzIHNlbnQgaW4gcnBjLXJlcXVlc3QgbWVzc2FnZS4NCg0KDQpbUm9oaXRdIDxl
cnJvci1vcHRpb24+IGlzIGFuIGlucHV0IHRvIHRoZSBlZGl0LWNvbmZpZyBycGMtcmVxdWVzdC4g
ICBTbyBJIHN1Z2dlc3RlZCB0byBoYXZlIGEgc2ltaWxhciBhcHByb2FjaC4gQnV0IHRoaXMgbXVs
dGktZGF0YXN0b3JlIGNvcHkgd2lsbCBiZSB0cmlja3kgYmVjYXVzZSBpZiB3ZSBnaXZlIHR3byB0
YXJnZXRzIHNheSA8cnVubmluZz4gLyA8c3RhcnR1cD4gYW5kIGlmIGFmdGVyIGNvcHkgdG8gPHJ1
bm5pbmc+LCBjb3B5IHRvIDxzdGFydHVwPiBmYWlscywgIHRoZW4gaG93IHRvIGhhbmRsZSB0aGlz
ID8gIFJldmVydCA8cnVubmluZz4gY29uZmlnID8NCg0KW1Fpbl06IFVuZGVyc3RhbmQgeW91ciBj
b25jZXJuLCBidXQgSSB0aGluayB0aGUgbmV3IG9wZXJhdGlvbiBjYW4gYmUgaGFuZGxlZCBpbiB0
aGUgc2FtZSB3YXkgYXMgPGRpc2NhcmQtY2hhbmdlcz4gaW4gUkZDNjI0MSwgSSBzZWUgbm8gZXJy
b3IgaGFuZGxpbmcgdG8gYmUgc3BlY2lmaWVkIGZvciA8ZGlzY2FyZC1jaGFuZ2VzPi4NCkluIGFk
ZGl0aW9uLCBycGMtcmVwbHkgY2FuIGJlIHVzZWQgdG8gY2FycnkgdGhlc2UgZXJyb3Itb3B0aW9u
IGluZm9ybWF0aW9uIGFuZCBpbmRpY2F0ZSBmYWlsdXJlIHJlYXNvbi4NCg0KV2l0aCBSZWdhcmRz
LA0KUm9oaXQgUg0KDQoNCkZyb206IFFpbiBXdQ0KU2VudDogMjIgT2N0b2JlciAyMDE4IDEyOjI1
DQpUbzogUm9oaXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWkuY29tPG1haWx0bzpyb2hp
dHJyYW5hZGVAaHVhd2VpLmNvbT4+OyBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVy
aWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPj47IG5ldG1vZEBp
ZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUkU6IE5ldyBWZXJzaW9u
IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQN
Cg0KVGhhbmtzIFJvaGl0LCBzZWUgcmVwbHkgaW5saW5lIGJlbG93Lg0KDQrlj5Hku7bkuro6IG5l
dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9oaXQgUiBSYW5h
ZGUNCuWPkemAgeaXtumXtDogMjAxOOW5tDEw5pyIMjLml6UgMTI6NTkNCuaUtuS7tuS6ujogQmFs
w6F6cyBMZW5neWVsOyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCuS4
u+mimDogUmU6IFtuZXRtb2RdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3Ut
bmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQNCg0KU29tZSBzdWdnZXN0aW9ucywNCg0KDQoN
CjEuICAgICAgIEluIFlBTkcgbW9kdWxlLCB0aGUgaWRlbnRpdHkgaGFzIG5hbWUgYXMg4oCcZmFj
dG9yeS1kZWZhdWx04oCdLCBidXQgbWFueSBwbGFjZXMgIHRoZSBuYW1lICJmYWN0b3J5LWRlZmF1
bHQtcnVubmluZyIgaXMgdXNlZC4gSSBzdWdnZXN0IHdlIHVzZWQg4oCcZmFjdG9yeS1kZWZhdWx0
4oCdaW4gYWxsIHBsYWNlcy4NCg0KW1Fpbl06IHdvcmtzIGZvciBtZS4NCg0KMi4gICAgICAgVGhp
cyBZQU5HIG1vZHVsZSBpcyBpbXBvcnRpbmcgaWV0Zi1uZXRjb25mIG1vZHVsZS4gSSBzdWdnZXN0
IHRoYXQgdGhpcyBpbXBvcnQgc2hvdWxkIGJlIHJlbW92ZWQgYXMgdGhpcyBtb2R1bGUgc2hvdWxk
IG5vdCBoYXZlIGRlcGVuZGVuY2llcyBvbiBORVRDT05GLg0KDQpbUWluXTogR29vZCBjYXRjaCwg
dGhhbmtzLg0KDQozLiAgICAgICBUaGUgZGVzY3JpcHRpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSwg
c3RpbGwgaGFzIHRoZSByZWZlcmVuY2UgdG8gPGNvcHktY29uZmlnPi4gIFdoZXRoZXIgdGhpcyBj
YW4gYmUgcmVtb3ZlZCA/DQoNCltRaW5dOiBHb29kIGNhdGNoLCB0aGFua3MuDQoNCjQuICAgICAg
IFRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgaW5kZW50aXR5IOKAnGZhY3RvcnktZGVmYXVsdOKAnSwg
c3VnZ2VzdCB0byBkZXNjcmliZSB0aGUgaWRlbnRpdHkgcmF0aGVyIHRoYW4gdGVsbCDigJxob3fi
gJ0gaXQgY2FuIGJlIHVzZWQuDQoNCltRaW5dOiBPa2F5Lg0KDQo1LiAgICAgICBXaGV0aGVyIHdl
IGNhbiBhbHNvIGFkZCB0aGUgc3RhdGVtZW50IHRoYXQgaWYgdGhlIOKAnHRhcmdldC1kYXRhc3Rv
cmXigJ0sIGhhdmUgYmVlbiBsb2NrZWQgLCB0aGVuIHRoZSByZXNldC1kYXRhc3RvcmUgd2lsbCBm
YWlsIHdpdGggdGhlIDxlcnJvci10YWc+IHZhbHVlIGFzIOKAnGluLXVzZeKAnSA/DQoNCltRaW5d
OiBJIHRoaW5rIHdlIGNhbiByZXVzZSA8ZXJyb3ItdGFnPiBpbiB0aGUgcnBjLWVycm9yIGVsZW1l
bnQsIHNpbWlsYXIgdG8gZXhhbXBsZSBpbiBzZWN0aW9uIDcuNSBvZiBSRkM2MjQxLg0KDQo2LiAg
ICAgICBTaW5jZSB3ZSBoYXZlIHNjZW5hcmlvIG9mIGNvcHkgdG8gbXVsdGlwbGUgdGFyZ2V0cywg
d2hldGhlciB3ZSBjYW4gYWRkIGEgbGVhZiBjYWxsZWQgdGhlIGVycm9yLW9wdGlvbiB3aXRoIHBv
c3NpYmxlIHZhbHVlcyBvZiDigJxzdG9wLW9uLWVycm9yL2NvbnRpbnVlLW9uLWVycm9yL3JvbGxi
YWNrLW9uLWVycm9y4oCdICAgPw0KDQogICBbUWluXTogU2FtZSBhcyBhYm92ZS4gU2hvdWxkIHRo
ZXNlIGVycm9yLW9wdGlvbiB2YWx1ZXMgYmUgcGFydCBvZiBycGMtcmVwbHkgb3IgcGFydCBvZiBv
cGVyYXRpb24gcmVxdWVzdD8gQnkgcmVhZGluZyBlZGl0LWNvbmZpZyxpdCBpcyBhbHNvIG5vdCBj
bGVhciB0byBtZSB3aGV0aGVyDQoNCiAgICAgICBFcnJvci1vcHRpb24gc2hvdWxkIGJlIHBhcnQg
b2YgZWRpdC1jb25maWcgb3BlcmF0aW9uIHRoYXQgaXMgc2VudCBpbiBycGMtcmVxdWVzdCBtZXNz
YWdlLg0KDQpXaXRoIFJlZ2FyZHMsDQoNClJvaGl0IFINCg0KRnJvbTogbmV0bW9kIFttYWlsdG86
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCYWzDoXpzIExlbmd5ZWwNClNl
bnQ6IDE5IE9jdG9iZXIgMjAxOCAxODoxNw0KVG86IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KU3ViamVjdDogW25ldG1vZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj
YXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0DQoNCg0KSGVs
bG8sDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZh
dWx0LTAxLnR4dCBoYXMgYmVlbiB1cGxvYWRlZC4gQ2hhbmdlcyBpbmNsdWRlOg0KUmVtb3ZlZCBp
bXBhY3RzIHRvIDxjb3B5LWNvbmZpZz4gYXMgdGhlIHJlc2V0LWRhdGFzdG9yZSAgUlBDIGNhbiBh
bnl3YXkgZG8gdGhlIHNhbWUgdGhpbmcuDQpFeHBsYWluZWQgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl
biBzdGFydHVwIGFuZCBmYWN0b3J5LWRlZmF1bHQgZGF0YXN0b3Jlcw0KU21hbGwgY29ycmVjdGlv
bnMuDQoNCnJlZ2FyZHMgQmFsYXpzDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0t
LS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0DQoNCkRhdGU6DQoNCkZyaSwgMTkgT2N0IDIwMTgg
MDU6MzA6MDUgLTA3MDANCg0KRnJvbToNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoNClRvOg0KDQpZZSBOaXUgPG5pdXllQGh1YXdl
aS5jb20+PG1haWx0bzpuaXV5ZUBodWF3ZWkuY29tPiwgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5j
b20+PG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+LCBCYWxhenMgTGVuZ3llbCA8YmFsYXpzLmxl
bmd5ZWxAZXJpY3Nzb24uY29tPjxtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPg0K
DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVm
YXVsdC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmFsYXpzIExl
bmd5ZWwgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQt
d3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdA0KUmV2aXNpb246IDAxDQpUaXRsZTogRmFjdG9yeSBk
ZWZhdWx0IFNldHRpbmcNCkRvY3VtZW50IGRhdGU6IDIwMTgtMTAtMTkNCkdyb3VwOiBJbmRpdmlk
dWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAxMA0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQNClN0YXR1
czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbmV0bW9kLWZhY3Rv
cnktZGVmYXVsdC8NCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
d3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMQ0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdA0KRGlm
ZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LW5ldG1vZC1mYWN0
b3J5LWRlZmF1bHQtMDENCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRo
b2QgdG8gcmVzZXQgYSBZQU5HIGRhdGFzdG9yZSB0byBpdHMNCmZhY3RvcnktZGVmYXVsdCBjb250
ZW50LiBUaGUgcmVzZXQgb3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nDQppbml0aWFs
IHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiBvciB3aGVuIHRoZSBleGlzdGluZyBjb25maWd1cmF0
aW9uDQpoYXMgbWFqb3IgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlvbiBw
cm9jZXNzIGZyb20NCnNjcmF0Y2ggaXMgdGhlIGJlc3Qgb3B0aW9uLg0KDQpBIG5ldyByZXNldC1k
YXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuIFNldmVyYWwgbWV0aG9kcyBvZiBkb2N1bWVudGluZw0K
dGhlIGZhY3RvcnktZGVmYXVsdCBjb250ZW50IGFyZSBzcGVjaWZpZWQuDQoNCk9wdGlvbmFsbHkg
YSBuZXcgImZhY3RvcnktZGVmYXVsdC1ydW5uaW5nIiByZWFkLW9ubHkgZGF0YXN0b3JlIGlzDQpk
ZWZpbmVkLCB0aGF0IGNvbnRhaW5zIHRoZSBkYXRhIHRoYXQgd2lsbCBiZSBjb3BpZWQgb3ZlciB0
byB0aGUNCnJ1bm5pbmcgZGF0YXN0b3JlIGF0IHJlc2V0Lg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhh
dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz
c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh
dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KLS0NCg0KQmFsYXpz
IExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KDQpT
ZW5pb3IgU3BlY2lhbGlzdA0KDQpNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAg
ZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxA
ZXJpY3Nzb24uY29tPg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B0BAD6Bnkgeml513mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0
YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG
5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJsYWNrO30NCnAu
TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh
cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9y
OmJsYWNrO30NCnAuSFRNTFByZWZvcm1hdHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhU
TUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglt
c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl
rovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t
c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29u
VGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0K
CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk
vZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWNvbG9yOmJs
YWNrO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu
LkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu
MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi
Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IFJvaGl0IFIgUmFuYWRlDQo8YnI+DQo8L3NwYW4+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe2
6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTg8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4g
bGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMjwvc3Bhbj7ml6U8
c3BhbiBsYW5nPSJFTi1VUyI+DQogMTc6Mzk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g
bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUWluIFd1OyBCYWw8
L3NwYW4+w6E8c3BhbiBsYW5nPSJFTi1VUyI+enMgTGVuZ3llbDsgbmV0bW9kQGlldGYub3JnPGJy
Pg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJFTi1VUyI+IFJFOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5l
dG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu
MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Ni48L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHdlIGhhdmUgc2NlbmFy
aW8gb2YgY29weSB0byBtdWx0aXBsZSB0YXJnZXRzLCB3aGV0aGVyIHdlIGNhbiBhZGQgYSBsZWFm
IGNhbGxlZCB0aGUgZXJyb3Itb3B0aW9uIHdpdGggcG9zc2libGUgdmFsdWVzIG9mIOKAnDwvc3Bh
bj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5zdG9wLW9uLWVycm9yL2NvbnRpbnVlLW9u
LWVycm9yL3JvbGxiYWNrLW9uLWVycm9yPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnSAmbmJzcDsmbmJzcDs/PC9z
cGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvaT48L3ByZT4NCjxwcmU+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyA8L3NwYW4+
PC9pPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+W1Fpbl06IFNhbWUgYXMgYWJvdmUuIFNob3VsZCB0aGVzZSBlcnJvci1vcHRpb24gdmFs
dWVzIGJlIHBhcnQgb2YgcnBjLXJlcGx5IG9yIHBhcnQgb2Ygb3BlcmF0aW9uIHJlcXVlc3Q/IEJ5
IHJlYWRpbmcgZWRpdC1jb25maWcsaXQgaXMgYWxzbyBub3QgY2xlYXIgdG8gbWUgd2hldGhlcjxv
OnA+PC9vOnA+PC9zcGFuPjwvaT48L3ByZT4NCjxwcmU+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgRXJyb3Itb3B0aW9uIHNob3VsZCBiZSBwYXJ0IG9mIGVkaXQtY29uZmln
IG9wZXJhdGlvbiB0aGF0IGlzIHNlbnQgaW4gcnBjLXJlcXVlc3QgbWVzc2FnZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L2k+PC9wcmU+DQo8cHJlPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwv
cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUm9oaXRdICZsdDtlcnJvci1vcHRpb24mZ3Q7IGlz
IGFuIGlucHV0IHRvIHRoZSBlZGl0LWNvbmZpZyBycGMtcmVxdWVzdC4gJm5ic3A7Jm5ic3A7U28g
SSBzdWdnZXN0ZWQgdG8gaGF2ZSBhIHNpbWlsYXIgYXBwcm9hY2guIEJ1dCB0aGlzIG11bHRpLWRh
dGFzdG9yZSBjb3B5IHdpbGwNCiBiZSB0cmlja3kgYmVjYXVzZSBpZiB3ZSBnaXZlIHR3byB0YXJn
ZXRzIHNheSAmbHQ7cnVubmluZyZndDsgLyAmbHQ7c3RhcnR1cCZndDsgYW5kIGlmIGFmdGVyIGNv
cHkgdG8gJmx0O3J1bm5pbmcmZ3Q7LCBjb3B5IHRvICZsdDtzdGFydHVwJmd0OyBmYWlscywmbmJz
cDsgdGhlbiBob3cgdG8gaGFuZGxlIHRoaXMgPyAmbmJzcDtSZXZlcnQgJmx0O3J1bm5pbmcmZ3Q7
IGNvbmZpZyA/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWlu
XTogVW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4sIGJ1dCBJIHRoaW5rIHRoZSBuZXcgb3BlcmF0aW9u
IGNhbiBiZSBoYW5kbGVkIGluIHRoZSBzYW1lIHdheSBhcyAmbHQ7ZGlzY2FyZC1jaGFuZ2VzJmd0
OyBpbiBSRkM2MjQxLCBJIHNlZSBubyBlcnJvciBoYW5kbGluZw0KIHRvIGJlIHNwZWNpZmllZCBm
b3IgJmx0O2Rpc2NhcmQtY2hhbmdlcyZndDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JbiBhZGRpdGlvbiwgcnBjLXJlcGx5IGNhbiBiZSB1c2VkIHRvIGNhcnJ5
IHRoZXNlIGVycm9yLW9wdGlvbiBpbmZvcm1hdGlvbiBhbmQgaW5kaWNhdGUgZmFpbHVyZSByZWFz
b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggUmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvaGl0IFI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4
dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6d2luZG93dGV4dCI+IFFpbiBXdQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIyIE9jdG9i
ZXIgMjAxOCAxMjoyNTxicj4NCjxiPlRvOjwvYj4gUm9oaXQgUiBSYW5hZGUgJmx0OzxhIGhyZWY9
Im1haWx0bzpyb2hpdHJyYW5hZGVAaHVhd2VpLmNvbSI+cm9oaXRycmFuYWRlQGh1YXdlaS5jb208
L2E+Jmd0OzsgQmFsw6F6cyBMZW5neWVsICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5
ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OzsNCjxh
IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3Ut
bmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIFJvaGl0
LCBzZWUgcmVwbHkgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVO
LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPiBuZXRtb2QgWzxhIGhyZWY9Im1haWx0bzpuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPl0N
Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0
Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+Um9oaXQgUiBSYW5hZGU8YnI+DQo8L3NwYW4+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0
PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTg8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFu
Zz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yMjwvc3Bhbj7ml6U8c3Bh
biBsYW5nPSJFTi1VUyI+DQogMTI6NTk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFu
Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQmFsPC9zcGFuPsOhPHNw
YW4gbGFuZz0iRU4tVVMiPnpzIExlbmd5ZWw7DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu
b3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9
IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0bW9kXSBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQt
MDEudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb21lIHN1Z2dlc3Rpb25zLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4Ljc1
cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
biBZQU5HIG1vZHVsZSwgdGhlIGlkZW50aXR5IGhhcyBuYW1lIGFzIOKAnDwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmZhY3RvcnktZGVmYXVsdDwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PuKAnSwgYnV0IG1hbnkgcGxhY2VzICZuYnNwO3RoZSBuYW1lIDwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O2ZhY3RvcnktZGVmYXVsdC1ydW5u
aW5nJnF1b3Q7IGlzIHVzZWQuIEkgc3VnZ2VzdCB3ZSB1c2VkIDwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+4oCcPHNwYW4gbGFuZz0iRU4tVVMiPmZhY3RvcnktZGVmYXVsdDwv
c3Bhbj7igJ08c3BhbiBsYW5nPSJFTi1VUyI+aW4gYWxsIHBsYWNlcy48bzpwPjwvbzpwPjwvc3Bh
bj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltRaW5dOiB3
b3JrcyBmb3IgbWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi1sZWZ0OjE4Ljc1cHQ7dGV4dC1pbmRlbnQ6LTE4Ljc1cHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi48L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIFlBTkcgbW9kdWxlIGlz
IGltcG9ydGluZyBpZXRmLW5ldGNvbmYgbW9kdWxlLiBJIHN1Z2dlc3QgdGhhdCB0aGlzIGltcG9y
dCBzaG91bGQgYmUgcmVtb3ZlZCBhcyB0aGlzIG1vZHVsZSBzaG91bGQgbm90IGhhdmUgZGVwZW5k
ZW5jaWVzIG9uIE5FVENPTkYuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MTguNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5bUWluXTogR29vZCBjYXRjaCwgdGhhbmtzLjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0O3RleHQtaW5kZW50
Oi0xOC43NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+VGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgWUFORyBtb2R1bGUsIHN0aWxsIGhhcyB0aGUg
cmVmZXJlbmNlIHRvICZsdDtjb3B5LWNvbmZpZyZndDsuICZuYnNwO1doZXRoZXIgdGhpcyBjYW4g
YmUgcmVtb3ZlZCA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu
NzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5bUWluXTogR29vZCBjYXRjaCwgdGhhbmtzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0O3RleHQtaW5kZW50Oi0xOC43
NXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBpbmRlbnRpdHkg4oCcZmFjdG9yeS1kZWZhdWx04oCdLCBz
dWdnZXN0IHRvIGRlc2NyaWJlIHRoZSBpZGVudGl0eSByYXRoZXIgdGhhbiB0ZWxsIOKAnGhvd+KA
nSBpdCBjYW4gYmUgdXNlZC4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MTguNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5bUWluXTogT2theS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguNzVwdDt0ZXh0LWluZGVudDotMTguNzVwdCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj41Ljwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls
eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZXRoZXIg
d2UgY2FuIGFsc28gYWRkIHRoZSBzdGF0ZW1lbnQgdGhhdCBpZiB0aGUg4oCcdGFyZ2V0LWRhdGFz
dG9yZeKAnSwgaGF2ZSBiZWVuIGxvY2tlZCAsIHRoZW4gdGhlIHJlc2V0LWRhdGFzdG9yZSB3aWxs
IGZhaWwgd2l0aCB0aGUgJmx0O2Vycm9yLXRhZyZndDsgdmFsdWUgYXMg4oCcaW4tdXNl4oCdID88
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC43NXB0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJ
IHRoaW5rIHdlIGNhbiByZXVzZSAmbHQ7ZXJyb3ItdGFnJmd0OyBpbiB0aGUgcnBjLWVycm9yIGVs
ZW1lbnQsIHNpbWlsYXIgdG8gZXhhbXBsZSBpbiBzZWN0aW9uIDcuNSBvZiBSRkM2MjQxLjwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w
cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj42Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss
JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHdlIGhhdmUgc2NlbmFyaW8gb2YgY29weSB0byBtdWx0
aXBsZSB0YXJnZXRzLCB3aGV0aGVyIHdlIGNhbiBhZGQgYSBsZWFmIGNhbGxlZCB0aGUgZXJyb3It
b3B0aW9uIHdpdGggcG9zc2libGUgdmFsdWVzIG9mIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPnN0b3Atb24tZXJyb3IvY29udGludWUtb24tZXJyb3Ivcm9sbGJhY2stb24tZXJyb3I8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj7igJ0gJm5ic3A7Jm5ic3A7Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i
c3A7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPltRaW5dOiBTYW1lIGFzIGFib3ZlLiBTaG91bGQgdGhlc2UgZXJyb3Itb3B0aW9u
IHZhbHVlcyBiZSBwYXJ0IG9mIHJwYy1yZXBseSBvciBwYXJ0IG9mIG9wZXJhdGlvbiByZXF1ZXN0
PyBCeSByZWFkaW5nIGVkaXQtY29uZmlnLGl0IGlzIGFsc28gbm90IGNsZWFyIHRvIG1lIHdoZXRo
ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgRXJyb3Itb3B0aW9uIHNob3VsZCBiZSBwYXJ0IG9mIGVkaXQtY29uZmlnIG9w
ZXJhdGlvbiB0aGF0IGlzIHNlbnQgaW4gcnBjLXJlcXVlc3QgbWVzc2FnZS48bzpwPjwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5XaXRoIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Um9oaXQgUjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gbmV0bW9kIFs8YSBo
cmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJhbMOhenMgTGVuZ3llbDxicj4N
CjxiPlNlbnQ6PC9iPiAxOSBPY3RvYmVyIDIwMTggMTg6MTc8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy
ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gW25ldG1vZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SGVs
bG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZl
cnNpb24gb2YgSS1ELCBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAxLnR4dCBoYXMg
YmVlbiB1cGxvYWRlZC4gQ2hhbmdlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVtb3ZlZCBpbXBh
Y3RzIHRvICZsdDtjb3B5LWNvbmZpZyZndDsgYXMgdGhlIHJlc2V0LWRhdGFzdG9yZSZuYnNwOyBS
UEMgY2FuIGFueXdheSBkbyB0aGUgc2FtZSB0aGluZy4NCjxicj4NCkV4cGxhaW5lZCB0aGUgZGlm
ZmVyZW5jZSBiZXR3ZWVuIHN0YXJ0dXAgYW5kIGZhY3RvcnktZGVmYXVsdCBkYXRhc3RvcmVzPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPlNtYWxsIGNvcnJlY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVnYXJkcyBCYWxhenM8YnI+DQo8YnI+DQot
LS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIw
IiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i
dG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNwYW4gbGFuZz0i
RU4tVVMiPlN1YmplY3Q6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCBz
dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtbmV0
bW9kLWZhY3RvcnktZGVmYXVsdC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K
PC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBj
bSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl
PSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RGF0ZToNCjxvOnA+PC9v
OnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt
IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJpLCAxOSBP
Y3QgMjAxOCAwNTozMDowNSAtMDcwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry
Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBj
bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRl
eHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOg0KPG86cD48L286cD48
L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWls
dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIi
IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiPlRvOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8
dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj5ZZSBOaXUgPGEgaHJlZj0ibWFpbHRvOm5pdXllQGh1YXdlaS5j
b20iPg0KJmx0O25pdXllQGh1YXdlaS5jb20mZ3Q7PC9hPiwgUWluIFd1IDxhIGhyZWY9Im1haWx0
bzpiaWxsLnd1QGh1YXdlaS5jb20iPiZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PC9hPiwgQmFs
YXpzIExlbmd5ZWwNCjxhIGhyZWY9Im1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20i
PiZsdDtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+
DQo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtbmV0bW9kLWZhY3Rv
cnktZGVmYXVsdC0wMS50eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5
IEJhbGF6cyBMZW5neWVsIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxi
cj4NCjxicj4NCk5hbWU6IGRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQ8YnI+DQpSZXZp
c2lvbjogMDE8YnI+DQpUaXRsZTogRmFjdG9yeSBkZWZhdWx0IFNldHRpbmc8YnI+DQpEb2N1bWVu
dCBkYXRlOiAyMDE4LTEwLTE5PGJyPg0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4N
ClBhZ2VzOiAxMDxicj4NClVSTDogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDEudHh0Ij4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1k
ZWZhdWx0LTAxLnR4dDwvYT48YnI+DQpTdGF0dXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQvIj4NCmh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1
bHQvPC9hPjxicj4NCkh0bWxpemVkOiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMSI+DQpodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMTwvYT48YnI+DQpI
dG1saXplZDogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k
cmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdDwvYT48YnI+DQpE
aWZmOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3Ut
bmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm
P3VybDI9ZHJhZnQtd3UtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0wMTwvYT48YnI+DQo8YnI+DQpB
YnN0cmFjdDo8YnI+DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8gcmVzZXQgYSBZ
QU5HIGRhdGFzdG9yZSB0byBpdHM8YnI+DQpmYWN0b3J5LWRlZmF1bHQgY29udGVudC4gVGhlIHJl
c2V0IG9wZXJhdGlvbiBtYXkgYmUgdXNlZCBlLmcuIGR1cmluZzxicj4NCmluaXRpYWwgemVyby10
b3VjaCBjb25maWd1cmF0aW9uIG9yIHdoZW4gdGhlIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb248YnI+
DQpoYXMgbWFqb3IgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlvbiBwcm9j
ZXNzIGZyb208YnI+DQpzY3JhdGNoIGlzIHRoZSBiZXN0IG9wdGlvbi48YnI+DQo8YnI+DQpBIG5l
dyByZXNldC1kYXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuIFNldmVyYWwgbWV0aG9kcyBvZiBkb2N1
bWVudGluZzxicj4NCnRoZSBmYWN0b3J5LWRlZmF1bHQgY29udGVudCBhcmUgc3BlY2lmaWVkLjxi
cj4NCjxicj4NCk9wdGlvbmFsbHkgYSBuZXcgJnF1b3Q7ZmFjdG9yeS1kZWZhdWx0LXJ1bm5pbmcm
cXVvdDsgcmVhZC1vbmx5IGRhdGFzdG9yZSBpczxicj4NCmRlZmluZWQsIHRoYXQgY29udGFpbnMg
dGhlIGRhdGEgdGhhdCB3aWxsIGJlIGNvcGllZCBvdmVyIHRvIHRoZTxicj4NCnJ1bm5pbmcgZGF0
YXN0b3JlIGF0IHJlc2V0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQg
aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np
b248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl
IGF0IHRvb2xzLmlldGYub3JnLjxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLSA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJhbGF6cyBMZW5n
eWVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVyaWNzc29uIEh1bmdhcnkgTHRkLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+U2VuaW9yIFNwZWNpYWxpc3Q8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk1vYmlsZTogJiM0
MzszNi03MC0zMzAtNzkwOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFp
bHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbSI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24u
Y29tPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B0BAD6Bnkgeml513mbxchi_--


From nobody Mon Oct 22 05:36:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3434130E05 for ; Mon, 22 Oct 2018 05:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY1Z4ixYWn5m for ; Mon, 22 Oct 2018 05:36:02 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 EE8C4130E21 for ; Mon, 22 Oct 2018 05:36:01 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 61F62175BF6 for ; Mon, 22 Oct 2018 06:36:00 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EZRAgIERXE0jMEZRAghxDQ; Mon, 22 Oct 2018 06:36:00 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bSmfJWwituLmOQz9lkueLS75yIWguS9z+FWRJjDR9d4=; b=QyXK8B/Auju1C+qVg04FuTi+dU l4EUzyLSh8ore+nuaCBck+h0YkK9cazYdDKAnvf178qyJMXKYiEGfhTYYgS2jhrz1GI1zU2xbAOBU pnRjvZJ3qdoj8aGpP85s9kGYm;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:50956 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gEZRA-004CSa-1S; Mon, 22 Oct 2018 06:36:00 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
References: 
Message-ID: <81215e65-ed5a-c3b5-e191-90d72ccea7c4@labn.net>
Date: Mon, 22 Oct 2018 08:35:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gEZRA-004CSa-1S
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:50956
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG adoption poll (draft-lengyel-netmod-yang-instance-data)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 12:36:05 -0000

This poll is now closed and the draft is adopted.  As usual, this draft 
will now be progressed through normal working group process, including 
addressing issues raised during and after adoption.

Authors,

Please submit draft-lengyel-netmod-yang-instance-data-05.txt with only 
the date updated and the file name changed to 
draft-ietf-netmod-yang-instance-file-format-00.txt.  Please note the 
file name change.  If you object to this change please propose an 
alternative.

Thank you,

Lou (and co-chairs)


On 10/8/2018 7:38 AM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-lengyel-netmod-yang-instance-data-04 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 22.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Oct 22 05:56:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283F6130DFB for ; Mon, 22 Oct 2018 05:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCj1cg2bNxhH for ; Mon, 22 Oct 2018 05:56:07 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F1E9F128D0C for ; Mon, 22 Oct 2018 05:56:06 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 3570E1AE039A; Mon, 22 Oct 2018 14:56:06 +0200 (CEST)
Date: Mon, 22 Oct 2018 14:56:05 +0200 (CEST)
Message-Id: <20181022.145605.1533686864301630023.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87bm7q4apy.fsf@nic.cz>
References: <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <87bm7q4apy.fsf@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 12:56:11 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > Going back to the most urgent issue, what is this WG's recommendation
> > for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > yang:xpath1.0 in filters?
> >
> > To summarize:
> >
> > We already have
> >
> >   o  instance-identifier in XML uses prefixes from the XML document
> >   o  instance-identifier in JSON uses module names as prefixes
> >   o  XPath in NETCONF filter uses prefixes from the XML document
> >   o  XPath in JSON query filter uses module names as prefixes
> >
> >
> > Alternative A:
> > --------------
> >
> > Use different encodings for "stream-xpath-filter" as well, depending
> > on if it is XML or JSON.
> >
> > We would do in SN:
> >
> >     o  If the node is encoded in XML, the set of namespace
> >        declarations are those in scope on the
> >        'stream-xpath-filter' leaf element.
> >
> >     o  If the node is encoded in JSON, the set of namespace
> >        declarations is the set of prefix and namespace pairs
> >        for all supported YANG modules, where the prefix is
> 
> Is "supported" the same as "implemented", or something else?

It should be "implemented".

> >        the YANG module name and the namespace is as defined
> >        by the "namespace" statement in the YANG module.
> >
> > Pro: the format is consistent within each encoding.
> >
> > Con: unclear how to handle other encodings.
> > Con: we keep using context-depending encodings.
> 
>   Con: XPath expressions in JSON can get pretty long (I assume it's not
>   just an instance identifier but may contain predicates etc.). We
>   cannot use the trick with the default namespace as in YANG, so all
>   data node names will have to carry the prefix.

Yes.

> > We could probably add that CBOR uses the same representation as JSON.
> >
> > Example in XML:
> >
> >    >       xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> >     /if:interfaces/if:interface/ip:ipv4
> >   
> >
> > Example in JSON:
> >
> >   "stream-xpath-filter":
> >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> >
> >
> >
> > Alternative B:
> > --------------
> >
> > Use a non-context depending encoding, with the module name as prefix.
> >
> > We would do in SN:
> >
> >     o  The set of namespace
> >        declarations is the set of prefix and namespace pairs
> >        for all supported YANG modules, where the prefix is
> >        the YANG module name and the namespace is as defined
> >        by the "namespace" statement in the YANG module.
> >
> > Pro: the format is independent from the protocol encoding
> >
> > Con: in XML, this leaf is treated differently from other XPath
> >      expressions, such as get-config filter and nacm rules.
> >
> > Example in XML:
> >
> >   
> >     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> >   
> >
> > Example in JSON:
> >
> >   "stream-xpath-filter":
> >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> >
> >
> > My proposal is A.  I think it is more important with consistency
> > within each encoding than across encodings.
> 
> I would suggest to consider declaring prefixes & namespaces explicitly
> in the data, as in the schema mount document. It is independent of
> encoding and the expressions can be kept short. In fact, one of the
> namespaces can be declared as default, so this use of XPath would then
> be very similar to YANG.

Ok, so this is another alternative that works today, and achieves the
goal of being encoding-independent.  It is still context-dependent
though.

BTW, when used in filters, it is nice to let an unprefixed name to
match any namespace; i.e., treat "foo" as syntactic sugar for
"local-name(.) = 'foo'".  ("*:foo" is not legal...)


/martin





> 
> Lada
> 
> >
> > (This said, I would like to have a context-independent encoding of all
> > YANG types in the future.  But not now.)
> >
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Mon Oct 22 06:11:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A907128D0C for ; Mon, 22 Oct 2018 06:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 3zKZV5kvqzyb for ; Mon, 22 Oct 2018 06:11:32 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 EBD8C12D7F8 for ; Mon, 22 Oct 2018 06:11:31 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:b4a2:ccff:fe4c:cec4]) by mail.nic.cz (Postfix) with ESMTPSA id 31E536011C; Mon, 22 Oct 2018 15:11:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540213890; bh=pDZwDW1przechAS56AA4rwL6TYQkbJ2kMGN7eiTGnVk=; h=From:To:Date; b=VOrfo6cw4funA6K8Bk8c7j7oRz3AppbftmTkjl1ZxJdljvwO3JIj9kXOPo1w6yraj 3ym2rFmJImDAASG0NG9vBo1B22S2HR5SQ7xYfAlLjVA6LX0X2fe3Jtfo82KWQ/V39Y i4RQpG10pSSf1Eh7OnmOzopKX6LRXbPveN1+Gfvg=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Date: Mon, 22 Oct 2018 15:11:30 +0200
In-Reply-To: <20181022.145605.1533686864301630023.mbj@tail-f.com>
References: <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <87bm7q4apy.fsf@nic.cz> <20181022.145605.1533686864301630023.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 13:11:36 -0000

On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > Hi,
> > >
> > > Going back to the most urgent issue, what is this WG's recommendation
> > > for the subscribed-notifications draft in NETCONF wrt/ their usage of
> > > yang:xpath1.0 in filters?
> > >
> > > To summarize:
> > >
> > > We already have
> > >
> > >   o  instance-identifier in XML uses prefixes from the XML document
> > >   o  instance-identifier in JSON uses module names as prefixes
> > >   o  XPath in NETCONF filter uses prefixes from the XML document
> > >   o  XPath in JSON query filter uses module names as prefixes
> > >
> > >
> > > Alternative A:
> > > --------------
> > >
> > > Use different encodings for "stream-xpath-filter" as well, depending
> > > on if it is XML or JSON.
> > >
> > > We would do in SN:
> > >
> > >     o  If the node is encoded in XML, the set of namespace
> > >        declarations are those in scope on the
> > >        'stream-xpath-filter' leaf element.
> > >
> > >     o  If the node is encoded in JSON, the set of namespace
> > >        declarations is the set of prefix and namespace pairs
> > >        for all supported YANG modules, where the prefix is
> > 
> > Is "supported" the same as "implemented", or something else?
> 
> It should be "implemented".
> 
> > >        the YANG module name and the namespace is as defined
> > >        by the "namespace" statement in the YANG module.
> > >
> > > Pro: the format is consistent within each encoding.
> > >
> > > Con: unclear how to handle other encodings.
> > > Con: we keep using context-depending encodings.
> > 
> >   Con: XPath expressions in JSON can get pretty long (I assume it's not
> >   just an instance identifier but may contain predicates etc.). We
> >   cannot use the trick with the default namespace as in YANG, so all
> >   data node names will have to carry the prefix.
> 
> Yes.
> 
> > > We could probably add that CBOR uses the same representation as JSON.
> > >
> > > Example in XML:
> > >
> > >    > >       xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > >       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > >     /if:interfaces/if:interface/ip:ipv4
> > >   
> > >
> > > Example in JSON:
> > >
> > >   "stream-xpath-filter":
> > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> > >
> > >
> > >
> > > Alternative B:
> > > --------------
> > >
> > > Use a non-context depending encoding, with the module name as prefix.
> > >
> > > We would do in SN:
> > >
> > >     o  The set of namespace
> > >        declarations is the set of prefix and namespace pairs
> > >        for all supported YANG modules, where the prefix is
> > >        the YANG module name and the namespace is as defined
> > >        by the "namespace" statement in the YANG module.
> > >
> > > Pro: the format is independent from the protocol encoding
> > >
> > > Con: in XML, this leaf is treated differently from other XPath
> > >      expressions, such as get-config filter and nacm rules.
> > >
> > > Example in XML:
> > >
> > >   
> > >     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
> > >   
> > >
> > > Example in JSON:
> > >
> > >   "stream-xpath-filter":
> > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
> > >
> > >
> > > My proposal is A.  I think it is more important with consistency
> > > within each encoding than across encodings.
> > 
> > I would suggest to consider declaring prefixes & namespaces explicitly
> > in the data, as in the schema mount document. It is independent of
> > encoding and the expressions can be kept short. In fact, one of the
> > namespaces can be declared as default, so this use of XPath would then
> > be very similar to YANG.
> 
> Ok, so this is another alternative that works today, and achieves the
> goal of being encoding-independent.  It is still context-dependent
> though.

Yes, every module that uses XPath in data will have to deal with this. There may
potentially be multiple independent prefix declarations (this is actually a
con). 

> 
> BTW, when used in filters, it is nice to let an unprefixed name to
> match any namespace; i.e., treat "foo" as syntactic sugar for
> "local-name(.) = 'foo'".  ("*:foo" is not legal...)

Hmm, I think this is a bad idea because it departs even further from the
original XPath semantics. Such chameleon names should IMO be pretty rare, and if
they are needed, local-name() is always available.

Lada

> 
> 
> /martin
> 
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > > (This said, I would like to have a context-independent encoding of all
> > > YANG types in the future.  But not now.)
> > >
> > >
> > >
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Oct 22 09:23:07 2018
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6DE130E41; Mon, 22 Oct 2018 09:22:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <154022537695.5543.10640123215591406211@ietfa.amsl.com>
Date: Mon, 22 Oct 2018 09:22:57 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 16:22:59 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Comparison of NMDA datastores
        Authors         : Alexander Clemm
                          Yingzhen Qu
                          Jeff Tantsura
                          Andy Bierman
	Filename        : draft-ietf-netmod-nmda-diff-00.txt
	Pages           : 14
	Date            : 2018-10-21

Abstract:
   This document defines an RPC operation to compare management
   datastores that comply with the NMDA architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-nmda-diff-00


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

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


From nobody Mon Oct 22 10:41:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB641252B7 for ; Mon, 22 Oct 2018 10:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 2yYPwHVS8tRa for ; Mon, 22 Oct 2018 10:41:53 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 8EFA3124BE5 for ; Mon, 22 Oct 2018 10:41:52 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id t22-v6so313647lji.7 for ; Mon, 22 Oct 2018 10:41:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2hEE1ygU2+ggztYLFtKnCRGpFUi2lv++nJAuA6akNgk=; b=D52u+AVxsKeMvo4PebBWDDNBygsBozWDneTA+G/4vyT8kNld1JwYrqntoqULvgojIY 0H+8k3ZUyj5KS97D5MU+F2GUVHOcdx11Tvq0sAIG8oMvXettZV9G5yNtETI+MS+CUqfC nS3j5ZKROpsWKbznIYMjNqOI8fEAZE5h5cv0LS7Dwn6U4FyI0hwtpAoCkGmBBXkZ6svU vzJ4P3ef9ROTJGpfndwtZ9FIHFx1a0917NCJNihn8uududgBctAkD1tUIF50GRxR+ekg JdbPMz2F0xF8wfJ6rPCqD5DyVnZJQhPahpPd6bQC18nea6fT1mIvp+7LZcSkhNTwGKbK GSiA==
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=2hEE1ygU2+ggztYLFtKnCRGpFUi2lv++nJAuA6akNgk=; b=mmyZVIuAi5HujdNrJVL7TaY8cJ6lymBz01+bBV1QKjBInP+h90CPCcJ9Odue/+g+Js PiuWQqiZaE2thuDzyqU7SieqW/I2nQoQF5RZ+pt16SxKUrEy+LS8H7YRsYkxRzg9cJPm 7y87nM64aLLM7uL7PmdvXh3I91vfONgesN9bYo7lbjq7vyuYuRkWWMDdIVyFk2jLbwlB +92PxBR0D5k8FfUkEyt8gY+lJAYsFLWNC5o4yOpUeQY/cimkcyj4UVN92scZXs0VREPV Wplgef/6jQirdrVZWe/o2EgKrvu15B80z0MWiRfK3IjS0Vz+imTtrZ7ZWlLXIHg97O7w c/fA==
X-Gm-Message-State: ABuFfojrjrD7YSfmel3Aw89NTtlFRS3377mRfhLlBiqZMwyRC+iWoI8w RMsFldSBjWH+hGtw+CQSsAC5Ov5025vcmDjQ4BMD6kgf
X-Google-Smtp-Source: ACcGV61xHpF9aXn0FEKiByTcB5enbRdVlWB9nvEHyk6uoWTvTMRA4n9fJr3sai0KuGHIYXdBXx4L01dv2XVJlZnwsLY=
X-Received: by 2002:a2e:2205:: with SMTP id i5-v6mr26298639lji.15.1540230110547;  Mon, 22 Oct 2018 10:41:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Mon, 22 Oct 2018 10:41:49 -0700 (PDT)
In-Reply-To: 
References: <20180911.104447.2165943059473950359.mbj@tail-f.com> 
From: Andy Bierman 
Date: Mon, 22 Oct 2018 10:41:49 -0700
Message-ID: 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000009ca8030578d4c4f6"
Archived-At: 
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 17:41:56 -0000

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

On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen  wrote:

> Folks,
>
> Can we get some quick replies to this email?
>
>

At the last IETF there were people that said both yang-data and
augment-yang-data extensions
were needed and they wanted this work to be completed quickly.  Is that
still the case?


IMO, NMDA and yang-library-bis offer a better solution path (which has been
brought up before).
If there is a need for specialized datastores like "factory-default" then
why not have
an abstract datastore or abstract module-set?  I do not think current YANG
supports this
approach very well (because modules used outside a server do not have
yang-library)
but that could probably be fixed with yang-instance-data


Kent // all hats
>
>
>

Andy


>
>
> =EF=BB=BF-----Original Message-----
> From: netmod  on behalf of Martin Bjorklund <
> mbj@tail-f.com>
> Date: Tuesday, September 11, 2018 at 4:45 AM
> To: "netmod@ietf.org" 
> Subject: [netmod] yang-data issues
>
> Hi,
>
> The authors of draft-ietf-netmod-yang-data-ext have been discussing
> the two remaining issues on this draft; the issue of whether a
> yang-data structure must have unique top-level node names or not, and
> the issue of the syntax for augment-yang-data.  We haven't been able
> to find agreement with the current proposal, so I have a suggestion
> for a slightly modified yang-data statement (which may have been
> discussed before):
>
> The idea is to encode a yang-data extension the same way as anydata,
> i.e., as a container.  For example:
>
>   yd:yang-data modify-subscription-datastore-error-info {
>       description
>         "This yang-data MAY be provided as part of a subscription's RPC
>         error response when there is a failure of a
>         'modify-subscription' RPC which has been made against a
>         datastore.  This yang-data MUST be used if hints are to be
>         provides back to the subscriber.";
>       leaf reason {
>         type identityref {
>           base sn:modify-subscription-error;
>         }
>         description
>           "Indicates the reason why the subscription has failed to
>           be modified.";
>       }
>       uses hints;
>     }
>
> This would be encoded as:
>
>   
>     foo
>     42
>     ...
>   
>
>
> Since the structure is always encoded as a container, it follows that
> it can have any data definition statement as substatement, with no
> restriction on naming and type of statement.  An instance of this can
> trivially be a complete instance document in XML w/o additional
> context, works well with JSON, and can appear in an error-info
> structure.
>
> Such a structure can be augemented as:
>
>   yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
>     leaf foo { ... }
>   }
>
> The drawback is that it forces the use of an extra container in the
> encoding.  OTOH, most usages of current rc:yang-data follows this
> pattern:
>
>   rc:yang-data modify-subscription-datastore-error-info {
>     container modify-subscription-datastore-error-info {
>       ...
>     }
>   }
>
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.
> ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXe=
MK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D
> 7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=3D1o7vXH-
> j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=3D
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen <kwatsen@juniper.net> wrote:
Folks,



Can we get some quick replies to this email?




At the last IETF there =
were people that said both yang-data and augment-yang-data extensions
=

were needed and they wanted this work to be completed quickly.=C2=A0 I=
s that still the case?


IMO, NMDA an=
d yang-library-bis offer a better solution path (which has been brought up =
before).
If there is a need for specialized datastores like "=
;factory-default" then why not have
an abstract datastore or=
 abstract module-set?=C2=A0 I do not think current YANG supports this
=

approach very well (because modules used outside a server do not have =
yang-library)
but that could probably be fixed with yang-instance=
-data



Kent // all hats






Andy
=C2=A0





=EF=BB=BF-----Original Message-----

From: netmod <netmod-bounces@=
ietf.org> on behalf of Martin Bjorklund <mbj@tail-f.com>

Date: Tuesday, September 11, 2018 at 4:45 AM

To: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: [netmod] yang-data issues



Hi,



The authors of draft-ietf-netmod-yang-data-ext have been discussing
the two remaining issues on this draft; the issue of whether a

yang-data structure must have unique top-level node names or not, and

the issue of the syntax for augment-yang-data.=C2=A0 We haven't been ab=
le

to find agreement with the current proposal, so I have a suggestion

for a slightly modified yang-data statement (which may have been

discussed before):



The idea is to encode a yang-data extension the same way as anydata,

i.e., as a container.=C2=A0 For example:



=C2=A0 yd:yang-data modify-subscription-datastore-error-info {

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This yang-data MAY be provided as part of=
 a subscription's RPC

=C2=A0 =C2=A0 =C2=A0 =C2=A0 error response when there is a failure of a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 'modify-subscription' RPC which has bee=
n made against a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 datastore.=C2=A0 This yang-data MUST be used if=
 hints are to be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 provides back to the subscriber.";

=C2=A0 =C2=A0 =C2=A0 leaf reason {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityref {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base sn:modify-subscription-error;

=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 "Indicates the reason why the subsc=
ription has failed to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be modified.";

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 uses hints;

=C2=A0 =C2=A0 }



This would be encoded as:



=C2=A0 <modify-subscription-datastore-error-info>

=C2=A0 =C2=A0 <reason>foo</reason>

=C2=A0 =C2=A0 <period-hint>42</period-hint>

=C2=A0 =C2=A0 ...

=C2=A0 </modify-subscription-datastore-error-info>





Since the structure is always encoded as a container, it follows that

it can have any data definition statement as substatement, with no

restriction on naming and type of statement.=C2=A0 An instance of this can<=
br>
trivially be a complete instance document in XML w/o additional

context, works well with JSON, and can appear in an error-info

structure.



Such a structure can be augemented as:



=C2=A0 yd:augment-yang-data /sn:modify-subscription-datastore-error-in=
fo {

=C2=A0 =C2=A0 leaf foo { ... }

=C2=A0 }



The drawback is that it forces the use of an extra container in the

encoding.=C2=A0 OTOH, most usages of current rc:yang-data follows this

pattern:



=C2=A0 rc:yang-data modify-subscription-datastore-error-info {

=C2=A0 =C2=A0 container modify-subscription-datastore-error-info {

=C2=A0 =C2=A0 =C2=A0 ...

=C2=A0 =C2=A0 }

=C2=A0 }









/martin



_______________________________________________

netmod mailing list

netmod@ietf.org

ht=
tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org=
_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb=
fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa=
GTvjISlaJdcZo&m=3D7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-U=
gXVRE&s=3D1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=
=3D



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--0000000000009ca8030578d4c4f6--


From nobody Mon Oct 22 13:01:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208DD130E61 for ; Mon, 22 Oct 2018 13:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 E1dsNNZvs150 for ; Mon, 22 Oct 2018 13:01:23 -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 CF7EF130E64 for ; Mon, 22 Oct 2018 13:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5275; q=dns/txt; s=iport; t=1540238482; x=1541448082; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NCYmzF2iSM3gwMT590yRy5DDF5DGD5IjwmWaAKuj8WY=; b=CyTJj5L+D29zAyTfdDHGRlFqajMsXqpZRFfFheVT0PacopKaXJXhsK7u gtPsPrZT5F7Z5GgTlarI6/N+LCXwh1sgpYeZOQP9sF5saHJkpGxoYtbXJ szulGSK0llmGFyVSakTpnXaQyEN/l0ZAyQvbKj72vwJehD/Kfe0JoCnON Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAAD0K85b/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYFbKmZ/KIN1lDOBYC2XKYFmDRgLhANGAoUVITgWAQM?= =?us-ascii?q?BAQIBAQJtHAyFOgEBAQMBAQEhDwE7CwwECQIRAwECAQICCRoDAgInHwkIBgE?= =?us-ascii?q?MBgIBAReDBgGBeQgPizCbTYEuih6BC4pHF4FBP4ERJ4JrgxsBAYEtAQESAQk?= =?us-ascii?q?WgwOCVwKIZIcojWlTCYZiigoGF4IehxWGe5ZdgVohZHFNIxU7gmwJgh0XfQE?= =?us-ascii?q?IAYJBhRSFWiMwihiCPgEB?=
X-IronPort-AV: E=Sophos;i="5.54,413,1534809600"; d="scan'208";a="468138728"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 20:01:21 +0000
Received: from [10.118.87.91] (rtp-jclarke-nitro10.cisco.com [10.118.87.91]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w9MK1DjP011429; Mon, 22 Oct 2018 20:01:13 GMT
To: Andy Bierman , Kent Watsen 
Cc: "netmod@ietf.org" 
References: <20180911.104447.2165943059473950359.mbj@tail-f.com>  
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: 
Date: Mon, 22 Oct 2018 16:01:13 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.91, rtp-jclarke-nitro10.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2018 20:01:36 -0000

On 10/22/18 13:41, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen  > wrote:
> 
>     Folks,
> 
>     Can we get some quick replies to this email?
> 
> 
> 
> At the last IETF there were people that said both yang-data and
> augment-yang-data extensions
> were needed and they wanted this work to be completed quickly.  Is that
> still the case?

Yes.  We're now seeing people that want to augment the ANIMA voucher
artifact (draft just proposed by Eliot Lear).  I have some non-IETF work
that would also benefit.

Joe

> 
> 
> IMO, NMDA and yang-library-bis offer a better solution path (which has
> been brought up before).
> If there is a need for specialized datastores like "factory-default"
> then why not have
> an abstract datastore or abstract module-set?  I do not think current
> YANG supports this
> approach very well (because modules used outside a server do not have
> yang-library)
> but that could probably be fixed with yang-instance-data
> 
> 
>     Kent // all hats
> 
> 
> 
> 
> Andy
>  
> 
> 
> 
>     -----Original Message-----
>     From: netmod      > on behalf of Martin Bjorklund
>     >
>     Date: Tuesday, September 11, 2018 at 4:45 AM
>     To: "netmod@ietf.org "      >
>     Subject: [netmod] yang-data issues
> 
>     Hi,
> 
>     The authors of draft-ietf-netmod-yang-data-ext have been discussing
>     the two remaining issues on this draft; the issue of whether a
>     yang-data structure must have unique top-level node names or not, and
>     the issue of the syntax for augment-yang-data.  We haven't been able
>     to find agreement with the current proposal, so I have a suggestion
>     for a slightly modified yang-data statement (which may have been
>     discussed before):
> 
>     The idea is to encode a yang-data extension the same way as anydata,
>     i.e., as a container.  For example:
> 
>       yd:yang-data modify-subscription-datastore-error-info {
>           description
>             "This yang-data MAY be provided as part of a subscription's RPC
>             error response when there is a failure of a
>             'modify-subscription' RPC which has been made against a
>             datastore.  This yang-data MUST be used if hints are to be
>             provides back to the subscriber.";
>           leaf reason {
>             type identityref {
>               base sn:modify-subscription-error;
>             }
>             description
>               "Indicates the reason why the subscription has failed to
>               be modified.";
>           }
>           uses hints;
>         }
> 
>     This would be encoded as:
> 
>       
>         foo
>         42
>         ...
>       
> 
> 
>     Since the structure is always encoded as a container, it follows that
>     it can have any data definition statement as substatement, with no
>     restriction on naming and type of statement.  An instance of this can
>     trivially be a complete instance document in XML w/o additional
>     context, works well with JSON, and can appear in an error-info
>     structure.
> 
>     Such a structure can be augemented as:
> 
>       yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
>         leaf foo { ... }
>       }
> 
>     The drawback is that it forces the use of an extra container in the
>     encoding.  OTOH, most usages of current rc:yang-data follows this
>     pattern:
> 
>       rc:yang-data modify-subscription-datastore-error-info {
>         container modify-subscription-datastore-error-info {
>           ...
>         }
>       }
> 
> 
> 
> 
>     /martin
> 
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=
>     
> 
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Oct 22 18:06:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87E9130DD9; Mon, 22 Oct 2018 18:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ziMMzXLeAA-7; Mon, 22 Oct 2018 18:06:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 634081293FB; Mon, 22 Oct 2018 18:06:04 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 24F0029C73EF4; Tue, 23 Oct 2018 02:05:59 +0100 (IST)
Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 02:06:00 +0100
Received: from DGGEMI526-MBX.china.huawei.com ([169.254.8.122]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0399.000; Tue, 23 Oct 2018 09:05:57 +0800
From: "Wubo (lana)" 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AdRqbH4Quq4SxaUUT/+K1DArLgW/xA==
Date: Tue, 23 Oct 2018 01:05:56 +0000
Message-ID: <520ECC8D9CA1724BA1CE492DF898F6A3396BD5@DGGEMI526-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.189.23]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 01:06:07 -0000

WWVzL3N1cHBvcnQuDQoNCkJvDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbmV0
bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gTG91IEJlcmdlcg0K
PiC3osvNyrG85DogMjAxOMTqMTDUwjE4yNUgMjE6MTMNCj4gytW8/sjLOiBOZXRNb2QgV0cgPG5l
dG1vZEBpZXRmLm9yZz4NCj4gs63LzTogTmV0TW9kIFdHIENoYWlycyA8bmV0bW9kLWNoYWlyc0Bp
ZXRmLm9yZz4NCj4g1vfM4jogUmU6IFtuZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZHJhZnQta3dh
dHNlbi0NCj4gbmV0bW9kLWFydHdvcmstZm9sZGluZy0wOA0KPiANCj4gUG9sbCBlbmRzIE5vdiAx
IC0gc29ycnkgYWJvdXQgdGhhdC4uLg0KPiANCj4gDQo+IE9uIDEwLzE4LzIwMTggOTowMyBBTSwg
TG91IEJlcmdlciB3cm90ZToNCj4gPiBBbGwsDQo+ID4NCj4gPiBUaGlzIGlzIHN0YXJ0IG9mIGEg
dHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCj4gPiBkcmFmdC1rd2F0c2VuLW5ldG1vZC1hcnR3b3Jr
LWZvbGRpbmctMDggYSB3b3JraW5nDQo+IGdyb3VwIGRvY3VtZW50Lg0KPiA+IFBsZWFzZSBzZW5k
IGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9zdXBwb3J0IiBvcg0KPiAibm8vZG8g
bm90DQo+ID4gc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciBy
ZXNlcnZhdGlvbnMNCj4gd2l0aCB0aGUNCj4gPiBkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFs
c28gZmVlbCBmcmVlIHRvIHByb3ZpZGUNCj4gY29tbWVudHMgeW91J2QNCj4gPiBsaWtlIHRvIHNl
ZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRw0KPiBkb2N1bWVudC4NCj4gPg0K
PiA+IFRoZSBwb2xsIGVuZHMgT2N0IDEuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBMb3Ug
KGFuZCBjby1jaGFpcnMpDQo+ID4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IF8NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0
bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2QNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBfDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Mon Oct 22 18:37:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC72130DEB for ; Mon, 22 Oct 2018 18:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Iia6pT8BxND0 for ; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 60356130DD9 for ; Mon, 22 Oct 2018 18:37:34 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A8149BCB18676 for ; Tue, 23 Oct 2018 02:37:29 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 02:37:30 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 09:37:24 +0800
From: Qin Wu 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] yang-data issues
Thread-Index: AQHUSavF2bweVYawaEOu4z2U70td9KUnzRIAgAR+tvA=
Date: Tue, 23 Oct 2018 01:37:24 +0000
Message-ID: 
References: <20180911.104447.2165943059473950359.mbj@tail-f.com> 
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.138.33.244]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 01:37:37 -0000

LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEtlbnQgV2F0c2VuDQrlj5HpgIHml7bpl7Q6IDIwMTjl
ubQxMOaciDIw5pelIDIwOjQ5DQrmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBS
ZTogW25ldG1vZF0geWFuZy1kYXRhIGlzc3Vlcw0KDQpGb2xrcywNCg0KQ2FuIHdlIGdldCBzb21l
IHF1aWNrIHJlcGxpZXMgdG8gdGhpcyBlbWFpbD8NCg0KW1Fpbl06IEkgYmVsaWV2ZSByZXN0Y29u
ZiBjb2xsZWN0aW9uIHdvcmsgbWlnaHQgYmVuZWZpdCBmcm9tIHRoaXMgd29yayBhcyB3ZWxsLiBJ
dCBmb2xsb3dzIHRyYWRpdGlvbmFsIHVzYWdlcyBvZiByYzp5YW5nLWRhdGEsDQpIb3dldmVyIEkg
YW0gbm90IHN1cmUgdGhlIGJlbmVmaXQgdG8gcmVtb3ZlIGNvbnRhaW5lciBkZWZpbmVkIHdpdGhp
biB5YW5nLWRhdGEgZXh0ZW5zaW9uLCB0aGUgcmVzdHJpY3QgaW9uIEkgc2VlIHRoaXMsDQpJbiB0
cmFkaXRpb25hbCB1c2FnZSBvZiB5YW5nLWRhdGEsIHdlIGNhbiBhZGQgbW9yZSB0aGFuIG9uZSBj
b250YWluZXJzLCB0aGVuIGF1Z21lbnQteWFuZy1kYXRhIGNhbiBhdWdtZW50IGZyb20gYW55IG9m
IHRoZXNlIGNvbnRhaW5lcnMgDQpkZWZpbmVkIHdpdGhpbiB5YW5nLWRhdGEgZXh0ZW5zaW9uLg0K
QnV0IHdpdGggYmVsb3cgcHJvcG9zYWwsIHdlIGxvc2Ugc3VjaCBmbGV4aWJpbGl0eSwgaW4gbXkg
b3Bpbmlvbi4NCg0KS2VudCAvLyBhbGwgaGF0cw0KDQoNCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo
YWxmIG9mIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KRGF0ZTogVHVlc2RheSwg
U2VwdGVtYmVyIDExLCAyMDE4IGF0IDQ6NDUgQU0NClRvOiAibmV0bW9kQGlldGYub3JnIiA8bmV0
bW9kQGlldGYub3JnPg0KU3ViamVjdDogW25ldG1vZF0geWFuZy1kYXRhIGlzc3Vlcw0KDQpIaSwN
Cg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1kYXRhLWV4dCBoYXZlIGJl
ZW4gZGlzY3Vzc2luZyB0aGUgdHdvIHJlbWFpbmluZyBpc3N1ZXMgb24gdGhpcyBkcmFmdDsgdGhl
IGlzc3VlIG9mIHdoZXRoZXIgYSB5YW5nLWRhdGEgc3RydWN0dXJlIG11c3QgaGF2ZSB1bmlxdWUg
dG9wLWxldmVsIG5vZGUgbmFtZXMgb3Igbm90LCBhbmQgdGhlIGlzc3VlIG9mIHRoZSBzeW50YXgg
Zm9yIGF1Z21lbnQteWFuZy1kYXRhLiAgV2UgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZmluZCBhZ3Jl
ZW1lbnQgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NhbCwgc28gSSBoYXZlIGEgc3VnZ2VzdGlvbiBm
b3IgYSBzbGlnaHRseSBtb2RpZmllZCB5YW5nLWRhdGEgc3RhdGVtZW50ICh3aGljaCBtYXkgaGF2
ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUpOg0KDQpUaGUgaWRlYSBpcyB0byBlbmNvZGUgYSB5YW5n
LWRhdGEgZXh0ZW5zaW9uIHRoZSBzYW1lIHdheSBhcyBhbnlkYXRhLCBpLmUuLCBhcyBhIGNvbnRh
aW5lci4gIEZvciBleGFtcGxlOg0KDQogIHlkOnlhbmctZGF0YSBtb2RpZnktc3Vic2NyaXB0aW9u
LWRhdGFzdG9yZS1lcnJvci1pbmZvIHsNCiAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJUaGlz
IHlhbmctZGF0YSBNQVkgYmUgcHJvdmlkZWQgYXMgcGFydCBvZiBhIHN1YnNjcmlwdGlvbidzIFJQ
Qw0KICAgICAgICBlcnJvciByZXNwb25zZSB3aGVuIHRoZXJlIGlzIGEgZmFpbHVyZSBvZiBhDQog
ICAgICAgICdtb2RpZnktc3Vic2NyaXB0aW9uJyBSUEMgd2hpY2ggaGFzIGJlZW4gbWFkZSBhZ2Fp
bnN0IGENCiAgICAgICAgZGF0YXN0b3JlLiAgVGhpcyB5YW5nLWRhdGEgTVVTVCBiZSB1c2VkIGlm
IGhpbnRzIGFyZSB0byBiZQ0KICAgICAgICBwcm92aWRlcyBiYWNrIHRvIHRoZSBzdWJzY3JpYmVy
LiI7DQogICAgICBsZWFmIHJlYXNvbiB7DQogICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAg
ICAgICAgIGJhc2Ugc246bW9kaWZ5LXN1YnNjcmlwdGlvbi1lcnJvcjsNCiAgICAgICAgfQ0KICAg
ICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICJJbmRpY2F0ZXMgdGhlIHJlYXNvbiB3aHkgdGhl
IHN1YnNjcmlwdGlvbiBoYXMgZmFpbGVkIHRvDQogICAgICAgICAgYmUgbW9kaWZpZWQuIjsNCiAg
ICAgIH0NCiAgICAgIHVzZXMgaGludHM7DQogICAgfQ0KDQpUaGlzIHdvdWxkIGJlIGVuY29kZWQg
YXM6DQoNCiAgPG1vZGlmeS1zdWJzY3JpcHRpb24tZGF0YXN0b3JlLWVycm9yLWluZm8+DQogICAg
PHJlYXNvbj5mb288L3JlYXNvbj4NCiAgICA8cGVyaW9kLWhpbnQ+NDI8L3BlcmlvZC1oaW50Pg0K
ICAgIC4uLg0KICA8L21vZGlmeS1zdWJzY3JpcHRpb24tZGF0YXN0b3JlLWVycm9yLWluZm8+DQoN
Cg0KU2luY2UgdGhlIHN0cnVjdHVyZSBpcyBhbHdheXMgZW5jb2RlZCBhcyBhIGNvbnRhaW5lciwg
aXQgZm9sbG93cyB0aGF0IGl0IGNhbiBoYXZlIGFueSBkYXRhIGRlZmluaXRpb24gc3RhdGVtZW50
IGFzIHN1YnN0YXRlbWVudCwgd2l0aCBubyByZXN0cmljdGlvbiBvbiBuYW1pbmcgYW5kIHR5cGUg
b2Ygc3RhdGVtZW50LiAgQW4gaW5zdGFuY2Ugb2YgdGhpcyBjYW4gdHJpdmlhbGx5IGJlIGEgY29t
cGxldGUgaW5zdGFuY2UgZG9jdW1lbnQgaW4gWE1MIHcvbyBhZGRpdGlvbmFsIGNvbnRleHQsIHdv
cmtzIHdlbGwgd2l0aCBKU09OLCBhbmQgY2FuIGFwcGVhciBpbiBhbiBlcnJvci1pbmZvIHN0cnVj
dHVyZS4NCg0KU3VjaCBhIHN0cnVjdHVyZSBjYW4gYmUgYXVnZW1lbnRlZCBhczoNCg0KICB5ZDph
dWdtZW50LXlhbmctZGF0YSAvc246bW9kaWZ5LXN1YnNjcmlwdGlvbi1kYXRhc3RvcmUtZXJyb3It
aW5mbyB7DQogICAgbGVhZiBmb28geyAuLi4gfQ0KICB9DQoNClRoZSBkcmF3YmFjayBpcyB0aGF0
IGl0IGZvcmNlcyB0aGUgdXNlIG9mIGFuIGV4dHJhIGNvbnRhaW5lciBpbiB0aGUgZW5jb2Rpbmcu
ICBPVE9ILCBtb3N0IHVzYWdlcyBvZiBjdXJyZW50IHJjOnlhbmctZGF0YSBmb2xsb3dzIHRoaXMN
CnBhdHRlcm46DQoNCiAgcmM6eWFuZy1kYXRhIG1vZGlmeS1zdWJzY3JpcHRpb24tZGF0YXN0b3Jl
LWVycm9yLWluZm8gew0KICAgIGNvbnRhaW5lciBtb2RpZnktc3Vic2NyaXB0aW9uLWRhdGFzdG9y
ZS1lcnJvci1pbmZvIHsNCiAgICAgIC4uLg0KICAgIH0NCiAgfQ0KICANCg0KDQoNCi9tYXJ0aW4N
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1v
ZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m
b19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY
Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTdu
bFZ1NWRKYWE4WHNEMExSZDBWVEgzMDFjYVZSVVhHc2E2TC1VZ1hWUkUmcz0xbzd2WEgtajhIYTZ4
YkpGVEcxampOenk5SlF3N2stVVdJcXBlQ3I4cXJrJmU9DQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA
aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Mon Oct 22 19:12:13 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4A130DEE for ; Mon, 22 Oct 2018 19:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cyBnQdDQCn6s for ; Mon, 22 Oct 2018 19:12:10 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AF057130DE0 for ; Mon, 22 Oct 2018 19:12:09 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B6C96F1130531; Tue, 23 Oct 2018 03:12:06 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Oct 2018 03:12:07 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Tue, 23 Oct 2018 10:12:01 +0800
From: Qin Wu 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIq7R7zgxnWZykmBF8fDuM0qB6UX5bGAgAAV+YCAAMlcgIAABpwAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHbgIAAB16AgABShQCAAAlqgIABCfeAgAmNmgCAAWuAgIAFBnmAgAAETwCAAVkTsA==
Date: Tue, 23 Oct 2018 02:12:00 +0000
Message-ID: 
References: <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <87bm7q4apy.fsf@nic.cz> <20181022.145605.1533686864301630023.mbj@tail-f.com> 
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.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 02:12:12 -0000

LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnXSC0+rHtIExhZGlzbGF2IExob3RrYQ0Kt6LLzcqxvOQ6IDIwMTjE6jEw1MIyMsjV
IDIxOjEyDQrK1bz+yMs6IE1hcnRpbiBCam9ya2x1bmQNCrOty806IG5ldG1vZEBpZXRmLm9yZw0K
1vfM4jogUmU6IFtuZXRtb2RdIHhwYXRoIGV4cHJlc3Npb25zIGluIEpTT04NCg0KT24gTW9uLCAy
MDE4LTEwLTIyIGF0IDE0OjU2ICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiBMYWRp
c2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+IE1hcnRpbiBCam9ya2x1bmQg
PG1iakB0YWlsLWYuY29tPiB3cml0ZXM6DQo+ID4gDQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBH
b2luZyBiYWNrIHRvIHRoZSBtb3N0IHVyZ2VudCBpc3N1ZSwgd2hhdCBpcyB0aGlzIFdHJ3MgDQo+
ID4gPiByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkcmFm
dCBpbiBORVRDT05GIA0KPiA+ID4gd3J0LyB0aGVpciB1c2FnZSBvZg0KPiA+ID4geWFuZzp4cGF0
aDEuMCBpbiBmaWx0ZXJzPw0KPiA+ID4NCj4gPiA+IFRvIHN1bW1hcml6ZToNCj4gPiA+DQo+ID4g
PiBXZSBhbHJlYWR5IGhhdmUNCj4gPiA+DQo+ID4gPiAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIg
aW4gWE1MIHVzZXMgcHJlZml4ZXMgZnJvbSB0aGUgWE1MIGRvY3VtZW50DQo+ID4gPiAgIG8gIGlu
c3RhbmNlLWlkZW50aWZpZXIgaW4gSlNPTiB1c2VzIG1vZHVsZSBuYW1lcyBhcyBwcmVmaXhlcw0K
PiA+ID4gICBvICBYUGF0aCBpbiBORVRDT05GIGZpbHRlciB1c2VzIHByZWZpeGVzIGZyb20gdGhl
IFhNTCBkb2N1bWVudA0KPiA+ID4gICBvICBYUGF0aCBpbiBKU09OIHF1ZXJ5IGZpbHRlciB1c2Vz
IG1vZHVsZSBuYW1lcyBhcyBwcmVmaXhlcw0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBbHRlcm5hdGl2
ZSBBOg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0NCj4gPiA+DQo+ID4gPiBVc2UgZGlmZmVyZW50IGVu
Y29kaW5ncyBmb3IgInN0cmVhbS14cGF0aC1maWx0ZXIiIGFzIHdlbGwsIA0KPiA+ID4gZGVwZW5k
aW5nIG9uIGlmIGl0IGlzIFhNTCBvciBKU09OLg0KPiA+ID4NCj4gPiA+IFdlIHdvdWxkIGRvIGlu
IFNOOg0KPiA+ID4NCj4gPiA+ICAgICBvICBJZiB0aGUgbm9kZSBpcyBlbmNvZGVkIGluIFhNTCwg
dGhlIHNldCBvZiBuYW1lc3BhY2UNCj4gPiA+ICAgICAgICBkZWNsYXJhdGlvbnMgYXJlIHRob3Nl
IGluIHNjb3BlIG9uIHRoZQ0KPiA+ID4gICAgICAgICdzdHJlYW0teHBhdGgtZmlsdGVyJyBsZWFm
IGVsZW1lbnQuDQo+ID4gPg0KPiA+ID4gICAgIG8gIElmIHRoZSBub2RlIGlzIGVuY29kZWQgaW4g
SlNPTiwgdGhlIHNldCBvZiBuYW1lc3BhY2UNCj4gPiA+ICAgICAgICBkZWNsYXJhdGlvbnMgaXMg
dGhlIHNldCBvZiBwcmVmaXggYW5kIG5hbWVzcGFjZSBwYWlycw0KPiA+ID4gICAgICAgIGZvciBh
bGwgc3VwcG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhlIHByZWZpeCBpcw0KPiA+IA0KPiA+
IElzICJzdXBwb3J0ZWQiIHRoZSBzYW1lIGFzICJpbXBsZW1lbnRlZCIsIG9yIHNvbWV0aGluZyBl
bHNlPw0KPiANCj4gSXQgc2hvdWxkIGJlICJpbXBsZW1lbnRlZCIuDQo+IA0KPiA+ID4gICAgICAg
IHRoZSBZQU5HIG1vZHVsZSBuYW1lIGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmluZWQNCj4g
PiA+ICAgICAgICBieSB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVs
ZS4NCj4gPiA+DQo+ID4gPiBQcm86IHRoZSBmb3JtYXQgaXMgY29uc2lzdGVudCB3aXRoaW4gZWFj
aCBlbmNvZGluZy4NCj4gPiA+DQo+ID4gPiBDb246IHVuY2xlYXIgaG93IHRvIGhhbmRsZSBvdGhl
ciBlbmNvZGluZ3MuDQo+ID4gPiBDb246IHdlIGtlZXAgdXNpbmcgY29udGV4dC1kZXBlbmRpbmcg
ZW5jb2RpbmdzLg0KPiA+IA0KPiA+ICAgQ29uOiBYUGF0aCBleHByZXNzaW9ucyBpbiBKU09OIGNh
biBnZXQgcHJldHR5IGxvbmcgKEkgYXNzdW1lIGl0J3Mgbm90DQo+ID4gICBqdXN0IGFuIGluc3Rh
bmNlIGlkZW50aWZpZXIgYnV0IG1heSBjb250YWluIHByZWRpY2F0ZXMgZXRjLikuIFdlDQo+ID4g
ICBjYW5ub3QgdXNlIHRoZSB0cmljayB3aXRoIHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBhcyBpbiBZ
QU5HLCBzbyBhbGwNCj4gPiAgIGRhdGEgbm9kZSBuYW1lcyB3aWxsIGhhdmUgdG8gY2FycnkgdGhl
IHByZWZpeC4NCj4gDQo+IFllcy4NCj4gDQo+ID4gPiBXZSBjb3VsZCBwcm9iYWJseSBhZGQgdGhh
dCBDQk9SIHVzZXMgdGhlIHNhbWUgcmVwcmVzZW50YXRpb24gYXMgSlNPTi4NCj4gPiA+DQo+ID4g
PiBFeGFtcGxlIGluIFhNTDoNCj4gPiA+DQo+ID4gPiAgIDxzdHJlYW0teHBhdGgtZmlsdGVyDQo+
ID4gPiAgICAgICB4bWxuczppZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaW50
ZXJmYWNlcyINCj4gPiA+ICAgICAgIHhtbG5zOmlwPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlh
bmc6aWV0Zi1pcCI+DQo+ID4gPiAgICAgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2lwOmlw
djQNCj4gPiA+ICAgPC9zdHJlYW0teHBhdGgtZmlsdGVyPg0KPiA+ID4NCj4gPiA+IEV4YW1wbGUg
aW4gSlNPTjoNCj4gPiA+DQo+ID4gPiAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoNCj4gPiA+ICAg
ICAiL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2Uv
aWV0Zi1pcDppcHY0Ig0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQWx0ZXJuYXRpdmUgQjoN
Cj4gPiA+IC0tLS0tLS0tLS0tLS0tDQo+ID4gPg0KPiA+ID4gVXNlIGEgbm9uLWNvbnRleHQgZGVw
ZW5kaW5nIGVuY29kaW5nLCB3aXRoIHRoZSBtb2R1bGUgbmFtZSBhcyBwcmVmaXguDQo+ID4gPg0K
PiA+ID4gV2Ugd291bGQgZG8gaW4gU046DQo+ID4gPg0KPiA+ID4gICAgIG8gIFRoZSBzZXQgb2Yg
bmFtZXNwYWNlDQo+ID4gPiAgICAgICAgZGVjbGFyYXRpb25zIGlzIHRoZSBzZXQgb2YgcHJlZml4
IGFuZCBuYW1lc3BhY2UgcGFpcnMNCj4gPiA+ICAgICAgICBmb3IgYWxsIHN1cHBvcnRlZCBZQU5H
IG1vZHVsZXMsIHdoZXJlIHRoZSBwcmVmaXggaXMNCj4gPiA+ICAgICAgICB0aGUgWUFORyBtb2R1
bGUgbmFtZSBhbmQgdGhlIG5hbWVzcGFjZSBpcyBhcyBkZWZpbmVkDQo+ID4gPiAgICAgICAgYnkg
dGhlICJuYW1lc3BhY2UiIHN0YXRlbWVudCBpbiB0aGUgWUFORyBtb2R1bGUuDQo+ID4gPg0KPiA+
ID4gUHJvOiB0aGUgZm9ybWF0IGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHByb3RvY29sIGVuY29k
aW5nDQo+ID4gPg0KPiA+ID4gQ29uOiBpbiBYTUwsIHRoaXMgbGVhZiBpcyB0cmVhdGVkIGRpZmZl
cmVudGx5IGZyb20gb3RoZXIgWFBhdGgNCj4gPiA+ICAgICAgZXhwcmVzc2lvbnMsIHN1Y2ggYXMg
Z2V0LWNvbmZpZyBmaWx0ZXIgYW5kIG5hY20gcnVsZXMuDQo+ID4gPg0KPiA+ID4gRXhhbXBsZSBp
biBYTUw6DQo+ID4gPg0KPiA+ID4gICA8c3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPiA+ICAgICAv
aWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRm
LWlwOmlwdjQNCj4gPiA+ICAgPC9zdHJlYW0teHBhdGgtZmlsdGVyPg0KPiA+ID4NCj4gPiA+IEV4
YW1wbGUgaW4gSlNPTjoNCj4gPiA+DQo+ID4gPiAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoNCj4g
PiA+ICAgICAiL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRl
cmZhY2UvaWV0Zi1pcDppcHY0Ig0KPiA+ID4NCj4gPiA+DQo+ID4gPiBNeSBwcm9wb3NhbCBpcyBB
LiAgSSB0aGluayBpdCBpcyBtb3JlIGltcG9ydGFudCB3aXRoIGNvbnNpc3RlbmN5IA0KPiA+ID4g
d2l0aGluIGVhY2ggZW5jb2RpbmcgdGhhbiBhY3Jvc3MgZW5jb2RpbmdzLg0KPiA+IA0KPiA+IEkg
d291bGQgc3VnZ2VzdCB0byBjb25zaWRlciBkZWNsYXJpbmcgcHJlZml4ZXMgJiBuYW1lc3BhY2Vz
IA0KPiA+IGV4cGxpY2l0bHkgaW4gdGhlIGRhdGEsIGFzIGluIHRoZSBzY2hlbWEgbW91bnQgZG9j
dW1lbnQuIEl0IGlzIA0KPiA+IGluZGVwZW5kZW50IG9mIGVuY29kaW5nIGFuZCB0aGUgZXhwcmVz
c2lvbnMgY2FuIGJlIGtlcHQgc2hvcnQuIEluIA0KPiA+IGZhY3QsIG9uZSBvZiB0aGUgbmFtZXNw
YWNlcyBjYW4gYmUgZGVjbGFyZWQgYXMgZGVmYXVsdCwgc28gdGhpcyB1c2UgDQo+ID4gb2YgWFBh
dGggd291bGQgdGhlbiBiZSB2ZXJ5IHNpbWlsYXIgdG8gWUFORy4NCj4gDQo+IE9rLCBzbyB0aGlz
IGlzIGFub3RoZXIgYWx0ZXJuYXRpdmUgdGhhdCB3b3JrcyB0b2RheSwgYW5kIGFjaGlldmVzIHRo
ZSANCj4gZ29hbCBvZiBiZWluZyBlbmNvZGluZy1pbmRlcGVuZGVudC4gIEl0IGlzIHN0aWxsIGNv
bnRleHQtZGVwZW5kZW50IA0KPiB0aG91Z2guDQoNClllcywgZXZlcnkgbW9kdWxlIHRoYXQgdXNl
cyBYUGF0aCBpbiBkYXRhIHdpbGwgaGF2ZSB0byBkZWFsIHdpdGggdGhpcy4gVGhlcmUgbWF5IHBv
dGVudGlhbGx5IGJlIG11bHRpcGxlIGluZGVwZW5kZW50IHByZWZpeCBkZWNsYXJhdGlvbnMgKHRo
aXMgaXMgYWN0dWFsbHkgYSBjb24pLiANCg0KPiANCj4gQlRXLCB3aGVuIHVzZWQgaW4gZmlsdGVy
cywgaXQgaXMgbmljZSB0byBsZXQgYW4gdW5wcmVmaXhlZCBuYW1lIHRvIA0KPiBtYXRjaCBhbnkg
bmFtZXNwYWNlOyBpLmUuLCB0cmVhdCAiZm9vIiBhcyBzeW50YWN0aWMgc3VnYXIgZm9yDQo+ICJs
b2NhbC1uYW1lKC4pID0gJ2ZvbyciLiAgKCIqOmZvbyIgaXMgbm90IGxlZ2FsLi4uKQ0KDQpIbW0s
IEkgdGhpbmsgdGhpcyBpcyBhIGJhZCBpZGVhIGJlY2F1c2UgaXQgZGVwYXJ0cyBldmVuIGZ1cnRo
ZXIgZnJvbSB0aGUgb3JpZ2luYWwgWFBhdGggc2VtYW50aWNzLiBTdWNoIGNoYW1lbGVvbiBuYW1l
cyBzaG91bGQgSU1PIGJlIHByZXR0eSByYXJlLCBhbmQgaWYgdGhleSBhcmUgbmVlZGVkLCBsb2Nh
bC1uYW1lKCkgaXMgYWx3YXlzIGF2YWlsYWJsZS4NCg0KW1Fpbl06IEFncmVlIHdpdGggTGFkYSwg
UmVmZXJlbmNpbmcgUkZDODQwNywgc2VjdGlvbiA0LjYuMiwgSSB0aGluayB0aGUgYmVsb3cgZ3Vp
ZGVsaW5lIGlzIHJlbGV2YW50Lg0KIg0KVGhlICJsb2NhbC1uYW1lIiBmdW5jdGlvbiBTSE9VTEQg
Tk9UIGJlIHVzZWQgdG8gcmVmZXJlbmNlIGxvY2FsIG5hbWVzDQogICBvdXRzaWRlIG9mIHRoZSBZ
QU5HIG1vZHVsZSB0aGF0IGRlZmluZXMgdGhlIG11c3Qgb3Igd2hlbiBleHByZXNzaW9uDQogICBj
b250YWluaW5nIHRoZSAibG9jYWwtbmFtZSIgZnVuY3Rpb24uICBFeGFtcGxlIG9mIGEgImxvY2Fs
LW5hbWUiDQogICBmdW5jdGlvbiB0aGF0IHNob3VsZCBub3QgYmUgdXNlZDoNCg0KICAgICAgLypb
bG9jYWwtbmFtZSgpPSdmb28nXQ0KDQoiDQpMYWRhDQoNCj4gDQo+IA0KPiAvbWFydGluDQo+IA0K
PiANCj4gDQo+IA0KPiANCj4gPiANCj4gPiBMYWRhDQo+ID4gDQo+ID4gPg0KPiA+ID4gKFRoaXMg
c2FpZCwgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBjb250ZXh0LWluZGVwZW5kZW50IGVuY29kaW5n
IG9mIA0KPiA+ID4gYWxsIFlBTkcgdHlwZXMgaW4gdGhlIGZ1dHVyZS4gIEJ1dCBub3Qgbm93LikN
Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAvbWFydGluDQo+ID4gPg0KPiA+ID4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiANCj4gPiAtLQ0KPiA+IExh
ZGlzbGF2IExob3RrYQ0KPiA+IEhlYWQsIENaLk5JQyBMYWJzDQo+ID4gUEdQIEtleSBJRDogMHhC
OEY5MkIwOEE5Rjc2QzY3DQo+ID4gDQotLQ0KTGFkaXNsYXYgTGhvdGthDQpIZWFkLCBDWi5OSUMg
TGFicw0KUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt
b2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
DQo=


From nobody Mon Oct 22 23:43:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A026130E03 for ; Mon, 22 Oct 2018 23:43:01 -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, 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 5vD2MmDtAQfv for ; Mon, 22 Oct 2018 23:42:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A1722130DF7 for ; Mon, 22 Oct 2018 23:42:58 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 003BF1AE0187; Tue, 23 Oct 2018 08:42:54 +0200 (CEST)
Date: Tue, 23 Oct 2018 08:42:54 +0200 (CEST)
Message-Id: <20181023.084254.2257754077098127031.mbj@tail-f.com>
To: bill.wu@huawei.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 06:43:02 -0000

UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiAtLS0tLemCruS7tuWOn+S7ti0t
LS0tDQo+IOWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd
IOS7o+ihqCBMYWRpc2xhdiBMaG90a2ENCj4g5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDmnIgyMuaX
pSAyMToxMg0KPiDmlLbku7bkuro6IE1hcnRpbiBCam9ya2x1bmQNCj4g5oqE6YCBOiBuZXRtb2RA
aWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW25ldG1vZF0geHBhdGggZXhwcmVzc2lvbnMgaW4gSlNP
Tg0KPiANCj4gT24gTW9uLCAyMDE4LTEwLTIyIGF0IDE0OjU2ICswMjAwLCBNYXJ0aW4gQmpvcmts
dW5kIHdyb3RlOg0KPiA+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+
ID4gPiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0KPiA+ID4gDQo+
ID4gPiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBHb2luZyBiYWNrIHRvIHRoZSBtb3N0IHVyZ2Vu
dCBpc3N1ZSwgd2hhdCBpcyB0aGlzIFdHJ3MgDQo+ID4gPiA+IHJlY29tbWVuZGF0aW9uIGZvciB0
aGUgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGRyYWZ0IGluIE5FVENPTkYgDQo+ID4gPiA+IHdy
dC8gdGhlaXIgdXNhZ2Ugb2YNCj4gPiA+ID4geWFuZzp4cGF0aDEuMCBpbiBmaWx0ZXJzPw0KPiA+
ID4gPg0KPiA+ID4gPiBUbyBzdW1tYXJpemU6DQo+ID4gPiA+DQo+ID4gPiA+IFdlIGFscmVhZHkg
aGF2ZQ0KPiA+ID4gPg0KPiA+ID4gPiAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIgaW4gWE1MIHVz
ZXMgcHJlZml4ZXMgZnJvbSB0aGUgWE1MIGRvY3VtZW50DQo+ID4gPiA+ICAgbyAgaW5zdGFuY2Ut
aWRlbnRpZmllciBpbiBKU09OIHVzZXMgbW9kdWxlIG5hbWVzIGFzIHByZWZpeGVzDQo+ID4gPiA+
ICAgbyAgWFBhdGggaW4gTkVUQ09ORiBmaWx0ZXIgdXNlcyBwcmVmaXhlcyBmcm9tIHRoZSBYTUwg
ZG9jdW1lbnQNCj4gPiA+ID4gICBvICBYUGF0aCBpbiBKU09OIHF1ZXJ5IGZpbHRlciB1c2VzIG1v
ZHVsZSBuYW1lcyBhcyBwcmVmaXhlcw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBbHRlcm5h
dGl2ZSBBOg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPg0KPiA+ID4gPiBVc2UgZGlm
ZmVyZW50IGVuY29kaW5ncyBmb3IgInN0cmVhbS14cGF0aC1maWx0ZXIiIGFzIHdlbGwsIA0KPiA+
ID4gPiBkZXBlbmRpbmcgb24gaWYgaXQgaXMgWE1MIG9yIEpTT04uDQo+ID4gPiA+DQo+ID4gPiA+
IFdlIHdvdWxkIGRvIGluIFNOOg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgbyAgSWYgdGhlIG5vZGUg
aXMgZW5jb2RlZCBpbiBYTUwsIHRoZSBzZXQgb2YgbmFtZXNwYWNlDQo+ID4gPiA+ICAgICAgICBk
ZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluIHNjb3BlIG9uIHRoZQ0KPiA+ID4gPiAgICAgICAgJ3N0
cmVhbS14cGF0aC1maWx0ZXInIGxlYWYgZWxlbWVudC4NCj4gPiA+ID4NCj4gPiA+ID4gICAgIG8g
IElmIHRoZSBub2RlIGlzIGVuY29kZWQgaW4gSlNPTiwgdGhlIHNldCBvZiBuYW1lc3BhY2UNCj4g
PiA+ID4gICAgICAgIGRlY2xhcmF0aW9ucyBpcyB0aGUgc2V0IG9mIHByZWZpeCBhbmQgbmFtZXNw
YWNlIHBhaXJzDQo+ID4gPiA+ICAgICAgICBmb3IgYWxsIHN1cHBvcnRlZCBZQU5HIG1vZHVsZXMs
IHdoZXJlIHRoZSBwcmVmaXggaXMNCj4gPiA+IA0KPiA+ID4gSXMgInN1cHBvcnRlZCIgdGhlIHNh
bWUgYXMgImltcGxlbWVudGVkIiwgb3Igc29tZXRoaW5nIGVsc2U/DQo+ID4gDQo+ID4gSXQgc2hv
dWxkIGJlICJpbXBsZW1lbnRlZCIuDQo+ID4gDQo+ID4gPiA+ICAgICAgICB0aGUgWUFORyBtb2R1
bGUgbmFtZSBhbmQgdGhlIG5hbWVzcGFjZSBpcyBhcyBkZWZpbmVkDQo+ID4gPiA+ICAgICAgICBi
eSB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1vZHVsZS4NCj4gPiA+ID4N
Cj4gPiA+ID4gUHJvOiB0aGUgZm9ybWF0IGlzIGNvbnNpc3RlbnQgd2l0aGluIGVhY2ggZW5jb2Rp
bmcuDQo+ID4gPiA+DQo+ID4gPiA+IENvbjogdW5jbGVhciBob3cgdG8gaGFuZGxlIG90aGVyIGVu
Y29kaW5ncy4NCj4gPiA+ID4gQ29uOiB3ZSBrZWVwIHVzaW5nIGNvbnRleHQtZGVwZW5kaW5nIGVu
Y29kaW5ncy4NCj4gPiA+IA0KPiA+ID4gICBDb246IFhQYXRoIGV4cHJlc3Npb25zIGluIEpTT04g
Y2FuIGdldCBwcmV0dHkgbG9uZyAoSSBhc3N1bWUgaXQncyBub3QNCj4gPiA+ICAganVzdCBhbiBp
bnN0YW5jZSBpZGVudGlmaWVyIGJ1dCBtYXkgY29udGFpbiBwcmVkaWNhdGVzIGV0Yy4pLiBXZQ0K
PiA+ID4gICBjYW5ub3QgdXNlIHRoZSB0cmljayB3aXRoIHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBh
cyBpbiBZQU5HLCBzbyBhbGwNCj4gPiA+ICAgZGF0YSBub2RlIG5hbWVzIHdpbGwgaGF2ZSB0byBj
YXJyeSB0aGUgcHJlZml4Lg0KPiA+IA0KPiA+IFllcy4NCj4gPiANCj4gPiA+ID4gV2UgY291bGQg
cHJvYmFibHkgYWRkIHRoYXQgQ0JPUiB1c2VzIHRoZSBzYW1lIHJlcHJlc2VudGF0aW9uIGFzIEpT
T04uDQo+ID4gPiA+DQo+ID4gPiA+IEV4YW1wbGUgaW4gWE1MOg0KPiA+ID4gPg0KPiA+ID4gPiAg
IDxzdHJlYW0teHBhdGgtZmlsdGVyDQo+ID4gPiA+ICAgICAgIHhtbG5zOmlmPSJ1cm46aWV0Zjpw
YXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pbnRlcmZhY2VzIg0KPiA+ID4gPiAgICAgICB4bWxuczpp
cD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaXAiPg0KPiA+ID4gPiAgICAgL2lm
OmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2lwOmlwdjQNCj4gPiA+ID4gICA8L3N0cmVhbS14cGF0
aC1maWx0ZXI+DQo+ID4gPiA+DQo+ID4gPiA+IEV4YW1wbGUgaW4gSlNPTjoNCj4gPiA+ID4NCj4g
PiA+ID4gICAic3RyZWFtLXhwYXRoLWZpbHRlciI6DQo+ID4gPiA+ICAgICAiL2lldGYtaW50ZXJm
YWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2UvaWV0Zi1pcDppcHY0Ig0K
PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBbHRlcm5hdGl2ZSBCOg0KPiA+ID4g
PiAtLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPg0KPiA+ID4gPiBVc2UgYSBub24tY29udGV4dCBkZXBl
bmRpbmcgZW5jb2RpbmcsIHdpdGggdGhlIG1vZHVsZSBuYW1lIGFzIHByZWZpeC4NCj4gPiA+ID4N
Cj4gPiA+ID4gV2Ugd291bGQgZG8gaW4gU046DQo+ID4gPiA+DQo+ID4gPiA+ICAgICBvICBUaGUg
c2V0IG9mIG5hbWVzcGFjZQ0KPiA+ID4gPiAgICAgICAgZGVjbGFyYXRpb25zIGlzIHRoZSBzZXQg
b2YgcHJlZml4IGFuZCBuYW1lc3BhY2UgcGFpcnMNCj4gPiA+ID4gICAgICAgIGZvciBhbGwgc3Vw
cG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhlIHByZWZpeCBpcw0KPiA+ID4gPiAgICAgICAg
dGhlIFlBTkcgbW9kdWxlIG5hbWUgYW5kIHRoZSBuYW1lc3BhY2UgaXMgYXMgZGVmaW5lZA0KPiA+
ID4gPiAgICAgICAgYnkgdGhlICJuYW1lc3BhY2UiIHN0YXRlbWVudCBpbiB0aGUgWUFORyBtb2R1
bGUuDQo+ID4gPiA+DQo+ID4gPiA+IFBybzogdGhlIGZvcm1hdCBpcyBpbmRlcGVuZGVudCBmcm9t
IHRoZSBwcm90b2NvbCBlbmNvZGluZw0KPiA+ID4gPg0KPiA+ID4gPiBDb246IGluIFhNTCwgdGhp
cyBsZWFmIGlzIHRyZWF0ZWQgZGlmZmVyZW50bHkgZnJvbSBvdGhlciBYUGF0aA0KPiA+ID4gPiAg
ICAgIGV4cHJlc3Npb25zLCBzdWNoIGFzIGdldC1jb25maWcgZmlsdGVyIGFuZCBuYWNtIHJ1bGVz
Lg0KPiA+ID4gPg0KPiA+ID4gPiBFeGFtcGxlIGluIFhNTDoNCj4gPiA+ID4NCj4gPiA+ID4gICA8
c3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPiA+ID4gICAgIC9pZXRmLWludGVyZmFjZXM6aW50ZXJm
YWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXA6aXB2NA0KPiA+ID4gPiAgIDwv
c3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPiA+ID4NCj4gPiA+ID4gRXhhbXBsZSBpbiBKU09OOg0K
PiA+ID4gPg0KPiA+ID4gPiAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoNCj4gPiA+ID4gICAgICIv
aWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZS9pZXRm
LWlwOmlwdjQiDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IE15IHByb3Bvc2FsIGlzIEEuICBJ
IHRoaW5rIGl0IGlzIG1vcmUgaW1wb3J0YW50IHdpdGggY29uc2lzdGVuY3kgDQo+ID4gPiA+IHdp
dGhpbiBlYWNoIGVuY29kaW5nIHRoYW4gYWNyb3NzIGVuY29kaW5ncy4NCj4gPiA+IA0KPiA+ID4g
SSB3b3VsZCBzdWdnZXN0IHRvIGNvbnNpZGVyIGRlY2xhcmluZyBwcmVmaXhlcyAmIG5hbWVzcGFj
ZXMgDQo+ID4gPiBleHBsaWNpdGx5IGluIHRoZSBkYXRhLCBhcyBpbiB0aGUgc2NoZW1hIG1vdW50
IGRvY3VtZW50LiBJdCBpcyANCj4gPiA+IGluZGVwZW5kZW50IG9mIGVuY29kaW5nIGFuZCB0aGUg
ZXhwcmVzc2lvbnMgY2FuIGJlIGtlcHQgc2hvcnQuIEluIA0KPiA+ID4gZmFjdCwgb25lIG9mIHRo
ZSBuYW1lc3BhY2VzIGNhbiBiZSBkZWNsYXJlZCBhcyBkZWZhdWx0LCBzbyB0aGlzIHVzZSANCj4g
PiA+IG9mIFhQYXRoIHdvdWxkIHRoZW4gYmUgdmVyeSBzaW1pbGFyIHRvIFlBTkcuDQo+ID4gDQo+
ID4gT2ssIHNvIHRoaXMgaXMgYW5vdGhlciBhbHRlcm5hdGl2ZSB0aGF0IHdvcmtzIHRvZGF5LCBh
bmQgYWNoaWV2ZXMgdGhlIA0KPiA+IGdvYWwgb2YgYmVpbmcgZW5jb2RpbmctaW5kZXBlbmRlbnQu
ICBJdCBpcyBzdGlsbCBjb250ZXh0LWRlcGVuZGVudCANCj4gPiB0aG91Z2guDQo+IA0KPiBZZXMs
IGV2ZXJ5IG1vZHVsZSB0aGF0IHVzZXMgWFBhdGggaW4gZGF0YSB3aWxsIGhhdmUgdG8gZGVhbCB3
aXRoIHRoaXMuIFRoZXJlIG1heSBwb3RlbnRpYWxseSBiZSBtdWx0aXBsZSBpbmRlcGVuZGVudCBw
cmVmaXggZGVjbGFyYXRpb25zICh0aGlzIGlzIGFjdHVhbGx5IGEgY29uKS4gDQo+IA0KPiA+IA0K
PiA+IEJUVywgd2hlbiB1c2VkIGluIGZpbHRlcnMsIGl0IGlzIG5pY2UgdG8gbGV0IGFuIHVucHJl
Zml4ZWQgbmFtZSB0byANCj4gPiBtYXRjaCBhbnkgbmFtZXNwYWNlOyBpLmUuLCB0cmVhdCAiZm9v
IiBhcyBzeW50YWN0aWMgc3VnYXIgZm9yDQo+ID4gImxvY2FsLW5hbWUoLikgPSAnZm9vJyIuICAo
Iio6Zm9vIiBpcyBub3QgbGVnYWwuLi4pDQo+IA0KPiBIbW0sIEkgdGhpbmsgdGhpcyBpcyBhIGJh
ZCBpZGVhIGJlY2F1c2UgaXQgZGVwYXJ0cyBldmVuIGZ1cnRoZXIgZnJvbSB0aGUgb3JpZ2luYWwg
WFBhdGggc2VtYW50aWNzLiBTdWNoIGNoYW1lbGVvbiBuYW1lcyBzaG91bGQgSU1PIGJlIHByZXR0
eSByYXJlLCBhbmQgaWYgdGhleSBhcmUgbmVlZGVkLCBsb2NhbC1uYW1lKCkgaXMgYWx3YXlzIGF2
YWlsYWJsZS4NCj4gDQo+IFtRaW5dOiBBZ3JlZSB3aXRoIExhZGEsIFJlZmVyZW5jaW5nIFJGQzg0
MDcsIHNlY3Rpb24gNC42LjIsIEkgdGhpbmsgdGhlIGJlbG93IGd1aWRlbGluZSBpcyByZWxldmFu
dC4NCj4gIg0KPiBUaGUgImxvY2FsLW5hbWUiIGZ1bmN0aW9uIFNIT1VMRCBOT1QgYmUgdXNlZCB0
byByZWZlcmVuY2UgbG9jYWwgbmFtZXMNCj4gICAgb3V0c2lkZSBvZiB0aGUgWUFORyBtb2R1bGUg
dGhhdCBkZWZpbmVzIHRoZSBtdXN0IG9yIHdoZW4gZXhwcmVzc2lvbg0KPiAgICBjb250YWluaW5n
IHRoZSAibG9jYWwtbmFtZSIgZnVuY3Rpb24uICBFeGFtcGxlIG9mIGEgImxvY2FsLW5hbWUiDQo+
ICAgIGZ1bmN0aW9uIHRoYXQgc2hvdWxkIG5vdCBiZSB1c2VkOg0KPiANCj4gICAgICAgLypbbG9j
YWwtbmFtZSgpPSdmb28nXQ0KDQpUaGlzIGd1aWRlbGluZSBpcyBmb3IgbXVzdC93aGVuIGV4cHJl
c3Npb25zICp3aXRoaW4qIFlBTkcgbW9kdWxlcy4NCg0KSSdtIHRhbGtpbmcgYWJvdXQgYSBkaWZm
ZXJlbnQgdXNlIGNhc2UsIG5hbWVseSBmaWx0ZXJpbmcuICBJdCBpcw0KcHJldHR5IGNvbnZlbmll
bnQgZm9yIHVzZXJzIHRvIHNlbmQgYSBmaWx0ZXI6DQoNCiAgL2ludGVyZmFjZXMvaW50ZXJmYWNl
W25hbWU9J2V0aDAnL2lwdjQNCg0KYW5kIGdldCBiYWNrIHdoYXQgdGhleSBleHBlY3QuICBFdmVu
IGluIHRoZSByYXJlIGNhc2Ugb2YgbG9jYWwgbmFtZQ0KY2xhc2hlcywgdGhpcyBmaWx0ZXIgd29y
a3MgYW5kIGdpdmVzIGJhY2sgd2hhdCB3YXMgZXhwZWN0ZWQgKCsNCmFkZGl0aW9uYWwgbm9kZXMp
Lg0KDQpJIGhhdmUgbm8gcGxhbnMgb24gd3JpdGluZyB1cCB0aGlzIGFzIGEgcHJvcG9zYWw7IEkn
bSBqdXN0IHBvaW50aW5nDQpvdXQgdGhhdCB3aGVuIFhQYXRoIGlzIHVzZWQgaW4gZmlsdGVycywg
dGhpcyBpcyBjb252ZW5pZW50Lg0KDQoNCi9tYXJ0aW4NCg==


From nobody Tue Oct 23 00:07:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19403130EE3 for ; Tue, 23 Oct 2018 00:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 CGpSyYoQRfP0 for ; Tue, 23 Oct 2018 00:07:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 D2FF4130EA0 for ; Tue, 23 Oct 2018 00:07:46 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 86DF16060F; Tue, 23 Oct 2018 09:07:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540278463; bh=/MUCzFWrgv3ZXsTgGPducZfVKL2fflSm1N4TffDM2cc=; h=From:To:Date; b=r01qmNHDxv3LZ4KOSWYsbwSTUvMxBAQe8mUdWzjCHuQHUNHMyNjuW75Zna823QpmP T9vywHq+YI83rmHQnNt4Gx228JFOr+Yw4q3AcCt3U5grEHeC5+k+8xX0xF8muDjaer BynNUiJMLsX9FDKC2eqFYISMg1OAIPooOHb7BgjQ=
Message-ID: <9636de74e2a088fa87dab9cadd43d09db23a2d89.camel@nic.cz>
From: Ladislav Lhotka 
To: Andy Bierman , Kent Watsen 
Cc: "netmod@ietf.org" 
Date: Tue, 23 Oct 2018 09:07:43 +0200
In-Reply-To: 
References: <20180911.104447.2165943059473950359.mbj@tail-f.com>  
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] yang-data issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 07:07:50 -0000

On Mon, 2018-10-22 at 10:41 -0700, Andy Bierman wrote:
> 
> 
> On Sat, Oct 20, 2018 at 5:48 AM, Kent Watsen  wrote:
> > Folks,
> > 
> > Can we get some quick replies to this email?
> > 
> 
> 
> At the last IETF there were people that said both yang-data and augment-yang-
> data extensions
> were needed and they wanted this work to be completed quickly.  Is that still
> the case?
> 
> 
> IMO, NMDA and yang-library-bis offer a better solution path (which has been
> brought up before).
> If there is a need for specialized datastores like "factory-default" then why
> not have
> an abstract datastore or abstract module-set? 

I agree, this has been my proposal all along. YANG should be able to cover such
uses out of the box. Extensions like yang-data only make the whole thing more
complicated.

Sometimes it it not even necessary to introduce an ad hoc datastore, a "schema"
entry from yang-library-bis could be sufficient.

> I do not think current YANG supports this
> approach very well (because modules used outside a server do not have yang-
> library)
> but that could probably be fixed with yang-instance-data

In many cases yang-library(-bis) can be used without the metadata provided by
yang-instance-data. For example, my yangson library uses YANG library data
(JSON) for specifying the complete data model:

https://yangson.labs.nic.cz/cmdline.html

Pyang uses NETCONF hello (XML) for the same purpose.

Lada

> 
> 
> > Kent // all hats
> > 
> > 
> 
> 
> Andy
>  
> > 
> > -----Original Message-----
> > From: netmod  on behalf of Martin Bjorklund <
> > mbj@tail-f.com>
> > Date: Tuesday, September 11, 2018 at 4:45 AM
> > To: "netmod@ietf.org" 
> > Subject: [netmod] yang-data issues
> > 
> > Hi,
> > 
> > The authors of draft-ietf-netmod-yang-data-ext have been discussing
> > the two remaining issues on this draft; the issue of whether a
> > yang-data structure must have unique top-level node names or not, and
> > the issue of the syntax for augment-yang-data.  We haven't been able
> > to find agreement with the current proposal, so I have a suggestion
> > for a slightly modified yang-data statement (which may have been
> > discussed before):
> > 
> > The idea is to encode a yang-data extension the same way as anydata,
> > i.e., as a container.  For example:
> > 
> >   yd:yang-data modify-subscription-datastore-error-info {
> >       description
> >         "This yang-data MAY be provided as part of a subscription's RPC
> >         error response when there is a failure of a
> >         'modify-subscription' RPC which has been made against a
> >         datastore.  This yang-data MUST be used if hints are to be
> >         provides back to the subscriber.";
> >       leaf reason {
> >         type identityref {
> >           base sn:modify-subscription-error;
> >         }
> >         description
> >           "Indicates the reason why the subscription has failed to
> >           be modified.";
> >       }
> >       uses hints;
> >     }
> > 
> > This would be encoded as:
> > 
> >   
> >     foo
> >     42
> >     ...
> >   
> > 
> > 
> > Since the structure is always encoded as a container, it follows that
> > it can have any data definition statement as substatement, with no
> > restriction on naming and type of statement.  An instance of this can
> > trivially be a complete instance document in XML w/o additional
> > context, works well with JSON, and can appear in an error-info
> > structure.
> > 
> > Such a structure can be augemented as:
> > 
> >   yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
> >     leaf foo { ... }
> >   }
> > 
> > The drawback is that it forces the use of an extra container in the
> > encoding.  OTOH, most usages of current rc:yang-data follows this
> > pattern:
> > 
> >   rc:yang-data modify-subscription-datastore-error-info {
> >     container modify-subscription-datastore-error-info {
> >       ...
> >     }
> >   }
> > 
> > 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 00:37:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8180130EF1 for ; Tue, 23 Oct 2018 00:37:07 -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, 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 tGGlBz5YNTZc for ; Tue, 23 Oct 2018 00:37:00 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 19A29130EEF for ; Tue, 23 Oct 2018 00:37:00 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 70D89182113A; Tue, 23 Oct 2018 09:44:21 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 802AF1820053; Tue, 23 Oct 2018 09:44:19 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , bill.wu@huawei.com
Cc: netmod@ietf.org
In-Reply-To: <20181023.084254.2257754077098127031.mbj@tail-f.com>
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , bill.wu@huawei.com, netmod@ietf.org
Date: Tue, 23 Oct 2018 09:36:55 +0200
Message-ID: <87d0s1azc8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 07:37:08 -0000

Martin Bjorklund  writes:

> Qin Wu  wrote:
>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=
=BB=A3=E8=A1=A8 Ladislav Lhotka
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B410=E6=9C=8822=E6=97=
=A5 21:12
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Martin Bjorklund
>> =E6=8A=84=E9=80=81: netmod@ietf.org
>> =E4=B8=BB=E9=A2=98: Re: [netmod] xpath expressions in JSON
>>=20
>> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
>> > Ladislav Lhotka  wrote:
>> > > Martin Bjorklund  writes:
>> > >=20
>> > > > Hi,
>> > > >
>> > > > Going back to the most urgent issue, what is this WG's=20
>> > > > recommendation for the subscribed-notifications draft in NETCONF=20
>> > > > wrt/ their usage of
>> > > > yang:xpath1.0 in filters?
>> > > >
>> > > > To summarize:
>> > > >
>> > > > We already have
>> > > >
>> > > >   o  instance-identifier in XML uses prefixes from the XML document
>> > > >   o  instance-identifier in JSON uses module names as prefixes
>> > > >   o  XPath in NETCONF filter uses prefixes from the XML document
>> > > >   o  XPath in JSON query filter uses module names as prefixes
>> > > >
>> > > >
>> > > > Alternative A:
>> > > > --------------
>> > > >
>> > > > Use different encodings for "stream-xpath-filter" as well,=20
>> > > > depending on if it is XML or JSON.
>> > > >
>> > > > We would do in SN:
>> > > >
>> > > >     o  If the node is encoded in XML, the set of namespace
>> > > >        declarations are those in scope on the
>> > > >        'stream-xpath-filter' leaf element.
>> > > >
>> > > >     o  If the node is encoded in JSON, the set of namespace
>> > > >        declarations is the set of prefix and namespace pairs
>> > > >        for all supported YANG modules, where the prefix is
>> > >=20
>> > > Is "supported" the same as "implemented", or something else?
>> >=20
>> > It should be "implemented".
>> >=20
>> > > >        the YANG module name and the namespace is as defined
>> > > >        by the "namespace" statement in the YANG module.
>> > > >
>> > > > Pro: the format is consistent within each encoding.
>> > > >
>> > > > Con: unclear how to handle other encodings.
>> > > > Con: we keep using context-depending encodings.
>> > >=20
>> > >   Con: XPath expressions in JSON can get pretty long (I assume it's =
not
>> > >   just an instance identifier but may contain predicates etc.). We
>> > >   cannot use the trick with the default namespace as in YANG, so all
>> > >   data node names will have to carry the prefix.
>> >=20
>> > Yes.
>> >=20
>> > > > We could probably add that CBOR uses the same representation as JS=
ON.
>> > > >
>> > > > Example in XML:
>> > > >
>> > > >   > > > >       xmlns:if=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces"
>> > > >       xmlns:ip=3D"urn:ietf:params:xml:ns:yang:ietf-ip">
>> > > >     /if:interfaces/if:interface/ip:ipv4
>> > > >   
>> > > >
>> > > > Example in JSON:
>> > > >
>> > > >   "stream-xpath-filter":
>> > > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip=
:ipv4"
>> > > >
>> > > >
>> > > >
>> > > > Alternative B:
>> > > > --------------
>> > > >
>> > > > Use a non-context depending encoding, with the module name as pref=
ix.
>> > > >
>> > > > We would do in SN:
>> > > >
>> > > >     o  The set of namespace
>> > > >        declarations is the set of prefix and namespace pairs
>> > > >        for all supported YANG modules, where the prefix is
>> > > >        the YANG module name and the namespace is as defined
>> > > >        by the "namespace" statement in the YANG module.
>> > > >
>> > > > Pro: the format is independent from the protocol encoding
>> > > >
>> > > > Con: in XML, this leaf is treated differently from other XPath
>> > > >      expressions, such as get-config filter and nacm rules.
>> > > >
>> > > > Example in XML:
>> > > >
>> > > >   
>> > > >     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:=
ipv4
>> > > >   
>> > > >
>> > > > Example in JSON:
>> > > >
>> > > >   "stream-xpath-filter":
>> > > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip=
:ipv4"
>> > > >
>> > > >
>> > > > My proposal is A.  I think it is more important with consistency=20
>> > > > within each encoding than across encodings.
>> > >=20
>> > > I would suggest to consider declaring prefixes & namespaces=20
>> > > explicitly in the data, as in the schema mount document. It is=20
>> > > independent of encoding and the expressions can be kept short. In=20
>> > > fact, one of the namespaces can be declared as default, so this use=
=20
>> > > of XPath would then be very similar to YANG.
>> >=20
>> > Ok, so this is another alternative that works today, and achieves the=
=20
>> > goal of being encoding-independent.  It is still context-dependent=20
>> > though.
>>=20
>> Yes, every module that uses XPath in data will have to deal with this. T=
here may potentially be multiple independent prefix declarations (this is a=
ctually a con).=20
>>=20
>> >=20
>> > BTW, when used in filters, it is nice to let an unprefixed name to=20
>> > match any namespace; i.e., treat "foo" as syntactic sugar for
>> > "local-name(.) =3D 'foo'".  ("*:foo" is not legal...)
>>=20
>> Hmm, I think this is a bad idea because it departs even further from the=
 original XPath semantics. Such chameleon names should IMO be pretty rare, =
and if they are needed, local-name() is always available.
>>=20
>> [Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the =
below guideline is relevant.
>> "
>> The "local-name" function SHOULD NOT be used to reference local names
>>    outside of the YANG module that defines the must or when expression
>>    containing the "local-name" function.  Example of a "local-name"
>>    function that should not be used:
>>=20
>>       /*[local-name()=3D'foo']
>
> This guideline is for must/when expressions *within* YANG modules.
>
> I'm talking about a different use case, namely filtering.  It is
> pretty convenient for users to send a filter:
>
>   /interfaces/interface[name=3D'eth0'/ipv4

This is impossible if we want to call it XPath. With an explicit
namespace/prefix declaration, for example

  "namespace": [
    {
      "prefix": "if",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
      "default": true
    },
    {
      "prefix": "ip",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
    }
  ]

it would be

  /interfaces/interface[name=3D'eth0']/ip:ipv4

which is not too bad either.

Lada


>
> and get back what they expect.  Even in the rare case of local name
> clashes, this filter works and gives back what was expected (+
> additional nodes).
>
> I have no plans on writing up this as a proposal; I'm just pointing
> out that when XPath is used in filters, this is convenient.
>
>
> /martin

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 01:16:11 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB4130DC2; Tue, 23 Oct 2018 01:16:09 -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, 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 3j0F5iUg_IHn; Tue, 23 Oct 2018 01:16:07 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4B127148; Tue, 23 Oct 2018 01:16:07 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 4284C1AE0187; Tue, 23 Oct 2018 10:16:06 +0200 (CEST)
Date: Tue, 23 Oct 2018 10:16:05 +0200 (CEST)
Message-Id: <20181023.101605.216102708295807418.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org, netmod-chairs@ietf.org
From: Martin Bjorklund 
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 08:16:09 -0000

Hi,

I support the adoption of this document, and I intend to help by
reviewing it.

(one quick comment; the header used in the examples in section 8 isn't
equal to the header defined in section 5.1)


/martin


Lou Berger  wrote:
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 23 01:30:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4457130F0F for ; Tue, 23 Oct 2018 01:30:09 -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, 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 C1wXlgYEnwhm for ; Tue, 23 Oct 2018 01:30:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF85A130F08 for ; Tue, 23 Oct 2018 01:29:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E9191AE0187; Tue, 23 Oct 2018 10:29:50 +0200 (CEST)
Date: Tue, 23 Oct 2018 10:29:50 +0200 (CEST)
Message-Id: <20181023.102950.1091826807488104231.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: bill.wu@huawei.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87d0s1azc8.fsf@nic.cz>
References:  <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 08:30:10 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3JrbHVu
ZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gDQo+ID4gUWluIFd1IDxiaWxsLnd1QGh1YXdl
aS5jb20+IHdyb3RlOg0KPiA+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+IOWPkeS7tuS6
ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMYWRpc2xh
diBMaG90a2ENCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDmnIgyMuaXpSAyMToxMg0KPiA+
PiDmlLbku7bkuro6IE1hcnRpbiBCam9ya2x1bmQNCj4gPj4g5oqE6YCBOiBuZXRtb2RAaWV0Zi5v
cmcNCj4gPj4g5Li76aKYOiBSZTogW25ldG1vZF0geHBhdGggZXhwcmVzc2lvbnMgaW4gSlNPTg0K
PiA+PiANCj4gPj4gT24gTW9uLCAyMDE4LTEwLTIyIGF0IDE0OjU2ICswMjAwLCBNYXJ0aW4gQmpv
cmtsdW5kIHdyb3RlOg0KPiA+PiA+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3Jv
dGU6DQo+ID4+ID4gPiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0K
PiA+PiA+ID4gDQo+ID4+ID4gPiA+IEhpLA0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPiBHb2luZyBi
YWNrIHRvIHRoZSBtb3N0IHVyZ2VudCBpc3N1ZSwgd2hhdCBpcyB0aGlzIFdHJ3MgDQo+ID4+ID4g
PiA+IHJlY29tbWVuZGF0aW9uIGZvciB0aGUgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGRyYWZ0
IGluIE5FVENPTkYgDQo+ID4+ID4gPiA+IHdydC8gdGhlaXIgdXNhZ2Ugb2YNCj4gPj4gPiA+ID4g
eWFuZzp4cGF0aDEuMCBpbiBmaWx0ZXJzPw0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPiBUbyBzdW1t
YXJpemU6DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+IFdlIGFscmVhZHkgaGF2ZQ0KPiA+PiA+ID4g
Pg0KPiA+PiA+ID4gPiAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIgaW4gWE1MIHVzZXMgcHJlZml4
ZXMgZnJvbSB0aGUgWE1MIGRvY3VtZW50DQo+ID4+ID4gPiA+ICAgbyAgaW5zdGFuY2UtaWRlbnRp
ZmllciBpbiBKU09OIHVzZXMgbW9kdWxlIG5hbWVzIGFzIHByZWZpeGVzDQo+ID4+ID4gPiA+ICAg
byAgWFBhdGggaW4gTkVUQ09ORiBmaWx0ZXIgdXNlcyBwcmVmaXhlcyBmcm9tIHRoZSBYTUwgZG9j
dW1lbnQNCj4gPj4gPiA+ID4gICBvICBYUGF0aCBpbiBKU09OIHF1ZXJ5IGZpbHRlciB1c2VzIG1v
ZHVsZSBuYW1lcyBhcyBwcmVmaXhlcw0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4g
PiBBbHRlcm5hdGl2ZSBBOg0KPiA+PiA+ID4gPiAtLS0tLS0tLS0tLS0tLQ0KPiA+PiA+ID4gPg0K
PiA+PiA+ID4gPiBVc2UgZGlmZmVyZW50IGVuY29kaW5ncyBmb3IgInN0cmVhbS14cGF0aC1maWx0
ZXIiIGFzIHdlbGwsIA0KPiA+PiA+ID4gPiBkZXBlbmRpbmcgb24gaWYgaXQgaXMgWE1MIG9yIEpT
T04uDQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+IFdlIHdvdWxkIGRvIGluIFNOOg0KPiA+PiA+ID4g
Pg0KPiA+PiA+ID4gPiAgICAgbyAgSWYgdGhlIG5vZGUgaXMgZW5jb2RlZCBpbiBYTUwsIHRoZSBz
ZXQgb2YgbmFtZXNwYWNlDQo+ID4+ID4gPiA+ICAgICAgICBkZWNsYXJhdGlvbnMgYXJlIHRob3Nl
IGluIHNjb3BlIG9uIHRoZQ0KPiA+PiA+ID4gPiAgICAgICAgJ3N0cmVhbS14cGF0aC1maWx0ZXIn
IGxlYWYgZWxlbWVudC4NCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gICAgIG8gIElmIHRoZSBub2Rl
IGlzIGVuY29kZWQgaW4gSlNPTiwgdGhlIHNldCBvZiBuYW1lc3BhY2UNCj4gPj4gPiA+ID4gICAg
ICAgIGRlY2xhcmF0aW9ucyBpcyB0aGUgc2V0IG9mIHByZWZpeCBhbmQgbmFtZXNwYWNlIHBhaXJz
DQo+ID4+ID4gPiA+ICAgICAgICBmb3IgYWxsIHN1cHBvcnRlZCBZQU5HIG1vZHVsZXMsIHdoZXJl
IHRoZSBwcmVmaXggaXMNCj4gPj4gPiA+IA0KPiA+PiA+ID4gSXMgInN1cHBvcnRlZCIgdGhlIHNh
bWUgYXMgImltcGxlbWVudGVkIiwgb3Igc29tZXRoaW5nIGVsc2U/DQo+ID4+ID4gDQo+ID4+ID4g
SXQgc2hvdWxkIGJlICJpbXBsZW1lbnRlZCIuDQo+ID4+ID4gDQo+ID4+ID4gPiA+ICAgICAgICB0
aGUgWUFORyBtb2R1bGUgbmFtZSBhbmQgdGhlIG5hbWVzcGFjZSBpcyBhcyBkZWZpbmVkDQo+ID4+
ID4gPiA+ICAgICAgICBieSB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IGluIHRoZSBZQU5HIG1v
ZHVsZS4NCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gUHJvOiB0aGUgZm9ybWF0IGlzIGNvbnNpc3Rl
bnQgd2l0aGluIGVhY2ggZW5jb2RpbmcuDQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+IENvbjogdW5j
bGVhciBob3cgdG8gaGFuZGxlIG90aGVyIGVuY29kaW5ncy4NCj4gPj4gPiA+ID4gQ29uOiB3ZSBr
ZWVwIHVzaW5nIGNvbnRleHQtZGVwZW5kaW5nIGVuY29kaW5ncy4NCj4gPj4gPiA+IA0KPiA+PiA+
ID4gICBDb246IFhQYXRoIGV4cHJlc3Npb25zIGluIEpTT04gY2FuIGdldCBwcmV0dHkgbG9uZyAo
SSBhc3N1bWUgaXQncyBub3QNCj4gPj4gPiA+ICAganVzdCBhbiBpbnN0YW5jZSBpZGVudGlmaWVy
IGJ1dCBtYXkgY29udGFpbiBwcmVkaWNhdGVzIGV0Yy4pLiBXZQ0KPiA+PiA+ID4gICBjYW5ub3Qg
dXNlIHRoZSB0cmljayB3aXRoIHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBhcyBpbiBZQU5HLCBzbyBh
bGwNCj4gPj4gPiA+ICAgZGF0YSBub2RlIG5hbWVzIHdpbGwgaGF2ZSB0byBjYXJyeSB0aGUgcHJl
Zml4Lg0KPiA+PiA+IA0KPiA+PiA+IFllcy4NCj4gPj4gPiANCj4gPj4gPiA+ID4gV2UgY291bGQg
cHJvYmFibHkgYWRkIHRoYXQgQ0JPUiB1c2VzIHRoZSBzYW1lIHJlcHJlc2VudGF0aW9uIGFzIEpT
T04uDQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+IEV4YW1wbGUgaW4gWE1MOg0KPiA+PiA+ID4gPg0K
PiA+PiA+ID4gPiAgIDxzdHJlYW0teHBhdGgtZmlsdGVyDQo+ID4+ID4gPiA+ICAgICAgIHhtbG5z
OmlmPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1pbnRlcmZhY2VzIg0KPiA+PiA+
ID4gPiAgICAgICB4bWxuczppcD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaXAi
Pg0KPiA+PiA+ID4gPiAgICAgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2lwOmlwdjQNCj4g
Pj4gPiA+ID4gICA8L3N0cmVhbS14cGF0aC1maWx0ZXI+DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+
IEV4YW1wbGUgaW4gSlNPTjoNCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gICAic3RyZWFtLXhwYXRo
LWZpbHRlciI6DQo+ID4+ID4gPiA+ICAgICAiL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2ll
dGYtaW50ZXJmYWNlczppbnRlcmZhY2UvaWV0Zi1pcDppcHY0Ig0KPiA+PiA+ID4gPg0KPiA+PiA+
ID4gPg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPiBBbHRlcm5hdGl2ZSBCOg0KPiA+PiA+ID4gPiAt
LS0tLS0tLS0tLS0tLQ0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPiBVc2UgYSBub24tY29udGV4dCBk
ZXBlbmRpbmcgZW5jb2RpbmcsIHdpdGggdGhlIG1vZHVsZSBuYW1lIGFzIHByZWZpeC4NCj4gPj4g
PiA+ID4NCj4gPj4gPiA+ID4gV2Ugd291bGQgZG8gaW4gU046DQo+ID4+ID4gPiA+DQo+ID4+ID4g
PiA+ICAgICBvICBUaGUgc2V0IG9mIG5hbWVzcGFjZQ0KPiA+PiA+ID4gPiAgICAgICAgZGVjbGFy
YXRpb25zIGlzIHRoZSBzZXQgb2YgcHJlZml4IGFuZCBuYW1lc3BhY2UgcGFpcnMNCj4gPj4gPiA+
ID4gICAgICAgIGZvciBhbGwgc3VwcG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhlIHByZWZp
eCBpcw0KPiA+PiA+ID4gPiAgICAgICAgdGhlIFlBTkcgbW9kdWxlIG5hbWUgYW5kIHRoZSBuYW1l
c3BhY2UgaXMgYXMgZGVmaW5lZA0KPiA+PiA+ID4gPiAgICAgICAgYnkgdGhlICJuYW1lc3BhY2Ui
IHN0YXRlbWVudCBpbiB0aGUgWUFORyBtb2R1bGUuDQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+IFBy
bzogdGhlIGZvcm1hdCBpcyBpbmRlcGVuZGVudCBmcm9tIHRoZSBwcm90b2NvbCBlbmNvZGluZw0K
PiA+PiA+ID4gPg0KPiA+PiA+ID4gPiBDb246IGluIFhNTCwgdGhpcyBsZWFmIGlzIHRyZWF0ZWQg
ZGlmZmVyZW50bHkgZnJvbSBvdGhlciBYUGF0aA0KPiA+PiA+ID4gPiAgICAgIGV4cHJlc3Npb25z
LCBzdWNoIGFzIGdldC1jb25maWcgZmlsdGVyIGFuZCBuYWNtIHJ1bGVzLg0KPiA+PiA+ID4gPg0K
PiA+PiA+ID4gPiBFeGFtcGxlIGluIFhNTDoNCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gICA8c3Ry
ZWFtLXhwYXRoLWZpbHRlcj4NCj4gPj4gPiA+ID4gICAgIC9pZXRmLWludGVyZmFjZXM6aW50ZXJm
YWNlcy9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtaXA6aXB2NA0KPiA+PiA+ID4gPiAg
IDwvc3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gRXhhbXBsZSBp
biBKU09OOg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPiAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoN
Cj4gPj4gPiA+ID4gICAgICIvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZh
Y2VzOmludGVyZmFjZS9pZXRmLWlwOmlwdjQiDQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+DQo+ID4+
ID4gPiA+IE15IHByb3Bvc2FsIGlzIEEuICBJIHRoaW5rIGl0IGlzIG1vcmUgaW1wb3J0YW50IHdp
dGggY29uc2lzdGVuY3kgDQo+ID4+ID4gPiA+IHdpdGhpbiBlYWNoIGVuY29kaW5nIHRoYW4gYWNy
b3NzIGVuY29kaW5ncy4NCj4gPj4gPiA+IA0KPiA+PiA+ID4gSSB3b3VsZCBzdWdnZXN0IHRvIGNv
bnNpZGVyIGRlY2xhcmluZyBwcmVmaXhlcyAmIG5hbWVzcGFjZXMgDQo+ID4+ID4gPiBleHBsaWNp
dGx5IGluIHRoZSBkYXRhLCBhcyBpbiB0aGUgc2NoZW1hIG1vdW50IGRvY3VtZW50LiBJdCBpcyAN
Cj4gPj4gPiA+IGluZGVwZW5kZW50IG9mIGVuY29kaW5nIGFuZCB0aGUgZXhwcmVzc2lvbnMgY2Fu
IGJlIGtlcHQgc2hvcnQuIEluIA0KPiA+PiA+ID4gZmFjdCwgb25lIG9mIHRoZSBuYW1lc3BhY2Vz
IGNhbiBiZSBkZWNsYXJlZCBhcyBkZWZhdWx0LCBzbyB0aGlzIHVzZSANCj4gPj4gPiA+IG9mIFhQ
YXRoIHdvdWxkIHRoZW4gYmUgdmVyeSBzaW1pbGFyIHRvIFlBTkcuDQo+ID4+ID4gDQo+ID4+ID4g
T2ssIHNvIHRoaXMgaXMgYW5vdGhlciBhbHRlcm5hdGl2ZSB0aGF0IHdvcmtzIHRvZGF5LCBhbmQg
YWNoaWV2ZXMgdGhlIA0KPiA+PiA+IGdvYWwgb2YgYmVpbmcgZW5jb2RpbmctaW5kZXBlbmRlbnQu
ICBJdCBpcyBzdGlsbCBjb250ZXh0LWRlcGVuZGVudCANCj4gPj4gPiB0aG91Z2guDQo+ID4+IA0K
PiA+PiBZZXMsIGV2ZXJ5IG1vZHVsZSB0aGF0IHVzZXMgWFBhdGggaW4gZGF0YSB3aWxsIGhhdmUg
dG8gZGVhbCB3aXRoIHRoaXMuIFRoZXJlIG1heSBwb3RlbnRpYWxseSBiZSBtdWx0aXBsZSBpbmRl
cGVuZGVudCBwcmVmaXggZGVjbGFyYXRpb25zICh0aGlzIGlzIGFjdHVhbGx5IGEgY29uKS4gDQo+
ID4+IA0KPiA+PiA+IA0KPiA+PiA+IEJUVywgd2hlbiB1c2VkIGluIGZpbHRlcnMsIGl0IGlzIG5p
Y2UgdG8gbGV0IGFuIHVucHJlZml4ZWQgbmFtZSB0byANCj4gPj4gPiBtYXRjaCBhbnkgbmFtZXNw
YWNlOyBpLmUuLCB0cmVhdCAiZm9vIiBhcyBzeW50YWN0aWMgc3VnYXIgZm9yDQo+ID4+ID4gImxv
Y2FsLW5hbWUoLikgPSAnZm9vJyIuICAoIio6Zm9vIiBpcyBub3QgbGVnYWwuLi4pDQo+ID4+IA0K
PiA+PiBIbW0sIEkgdGhpbmsgdGhpcyBpcyBhIGJhZCBpZGVhIGJlY2F1c2UgaXQgZGVwYXJ0cyBl
dmVuIGZ1cnRoZXIgZnJvbSB0aGUgb3JpZ2luYWwgWFBhdGggc2VtYW50aWNzLiBTdWNoIGNoYW1l
bGVvbiBuYW1lcyBzaG91bGQgSU1PIGJlIHByZXR0eSByYXJlLCBhbmQgaWYgdGhleSBhcmUgbmVl
ZGVkLCBsb2NhbC1uYW1lKCkgaXMgYWx3YXlzIGF2YWlsYWJsZS4NCj4gPj4gDQo+ID4+IFtRaW5d
OiBBZ3JlZSB3aXRoIExhZGEsIFJlZmVyZW5jaW5nIFJGQzg0MDcsIHNlY3Rpb24gNC42LjIsIEkg
dGhpbmsgdGhlIGJlbG93IGd1aWRlbGluZSBpcyByZWxldmFudC4NCj4gPj4gIg0KPiA+PiBUaGUg
ImxvY2FsLW5hbWUiIGZ1bmN0aW9uIFNIT1VMRCBOT1QgYmUgdXNlZCB0byByZWZlcmVuY2UgbG9j
YWwgbmFtZXMNCj4gPj4gICAgb3V0c2lkZSBvZiB0aGUgWUFORyBtb2R1bGUgdGhhdCBkZWZpbmVz
IHRoZSBtdXN0IG9yIHdoZW4gZXhwcmVzc2lvbg0KPiA+PiAgICBjb250YWluaW5nIHRoZSAibG9j
YWwtbmFtZSIgZnVuY3Rpb24uICBFeGFtcGxlIG9mIGEgImxvY2FsLW5hbWUiDQo+ID4+ICAgIGZ1
bmN0aW9uIHRoYXQgc2hvdWxkIG5vdCBiZSB1c2VkOg0KPiA+PiANCj4gPj4gICAgICAgLypbbG9j
YWwtbmFtZSgpPSdmb28nXQ0KPiA+DQo+ID4gVGhpcyBndWlkZWxpbmUgaXMgZm9yIG11c3Qvd2hl
biBleHByZXNzaW9ucyAqd2l0aGluKiBZQU5HIG1vZHVsZXMuDQo+ID4NCj4gPiBJJ20gdGFsa2lu
ZyBhYm91dCBhIGRpZmZlcmVudCB1c2UgY2FzZSwgbmFtZWx5IGZpbHRlcmluZy4gIEl0IGlzDQo+
ID4gcHJldHR5IGNvbnZlbmllbnQgZm9yIHVzZXJzIHRvIHNlbmQgYSBmaWx0ZXI6DQo+ID4NCj4g
PiAgIC9pbnRlcmZhY2VzL2ludGVyZmFjZVtuYW1lPSdldGgwJy9pcHY0DQo+IA0KPiBUaGlzIGlz
IGltcG9zc2libGUgaWYgd2Ugd2FudCB0byBjYWxsIGl0IFhQYXRoLiBXaXRoIGFuIGV4cGxpY2l0
DQo+IG5hbWVzcGFjZS9wcmVmaXggZGVjbGFyYXRpb24sIGZvciBleGFtcGxlDQo+IA0KPiAgICJu
YW1lc3BhY2UiOiBbDQo+ICAgICB7DQo+ICAgICAgICJwcmVmaXgiOiAiaWYiLA0KPiAgICAgICAi
dXJpIjogInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWludGVyZmFjZXMiLA0KPiAg
ICAgICAiZGVmYXVsdCI6IHRydWUNCj4gICAgIH0sDQo+ICAgICB7DQo+ICAgICAgICJwcmVmaXgi
OiAiaXAiLA0KPiAgICAgICAidXJpIjogInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRm
LWlwIg0KPiAgICAgfQ0KPiAgIF0NCj4gDQo+IGl0IHdvdWxkIGJlDQo+IA0KPiAgIC9pbnRlcmZh
Y2VzL2ludGVyZmFjZVtuYW1lPSdldGgwJ10vaXA6aXB2NA0KPiANCj4gd2hpY2ggaXMgbm90IHRv
byBiYWQgZWl0aGVyLg0KDQpXZWxsLCAibmNjIG15aG9zdCAtLWdldCAteCAvaW50ZXJmYWNlcy9p
bnRlcmZhY2VbbmFtZT0nZXRoMCddL2lwdjQiIGlzDQphIG9uZS1saW5lcjsgaWYgSSBhbHNvIGhh
dmUgdG8gc3BlY2lmeSB0aGUgbmFtZXNwYWNlIGxpc3QgZm9yIGV2ZXJ5DQpmaWx0ZXIsIGl0IHN1
ZGRlbmx5IGlzIG5vdCB0aGF0IGNvbnZlbmllbnQuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IExh
ZGENCj4gDQo+IA0KPiA+DQo+ID4gYW5kIGdldCBiYWNrIHdoYXQgdGhleSBleHBlY3QuICBFdmVu
IGluIHRoZSByYXJlIGNhc2Ugb2YgbG9jYWwgbmFtZQ0KPiA+IGNsYXNoZXMsIHRoaXMgZmlsdGVy
IHdvcmtzIGFuZCBnaXZlcyBiYWNrIHdoYXQgd2FzIGV4cGVjdGVkICgrDQo+ID4gYWRkaXRpb25h
bCBub2RlcykuDQo+ID4NCj4gPiBJIGhhdmUgbm8gcGxhbnMgb24gd3JpdGluZyB1cCB0aGlzIGFz
IGEgcHJvcG9zYWw7IEknbSBqdXN0IHBvaW50aW5nDQo+ID4gb3V0IHRoYXQgd2hlbiBYUGF0aCBp
cyB1c2VkIGluIGZpbHRlcnMsIHRoaXMgaXMgY29udmVuaWVudC4NCj4gPg0KPiA+DQo+ID4gL21h
cnRpbg0KPiANCj4gLS0gDQo+IExhZGlzbGF2IExob3RrYQ0KPiBIZWFkLCBDWi5OSUMgTGFicw0K
PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gDQo=


From nobody Tue Oct 23 01:35:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9B130EEA for ; Tue, 23 Oct 2018 01:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 hEKX5JQTYMwQ for ; Tue, 23 Oct 2018 01:35:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 71B6D130EE7 for ; Tue, 23 Oct 2018 01:35:51 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id B8BCE6088F; Tue, 23 Oct 2018 10:35:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540283749; bh=AWNqZcDK09YFqEBClH4IeMtLY/r3d//PYb1K+iFWKwE=; h=From:To:Date; b=E3lERG8pE4pRi5nhm5Qs0/dakMgci21t+Z01ELW0YVQ0x9I0cflItI7HGS3HSb0IO +iSfTDMsoamMYWWJcYMI9KLahzKst4ydtks5v3/mza6OQ/PIkqQcVDNBYh7UacAvFK gEx9izisrSjZe794OcWbqwOo5ItNRx2QUt72W+OU=
Message-ID: <356c8c17ccb4028d854039d6843aab9c15137442.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: bill.wu@huawei.com, netmod@ietf.org
Date: Tue, 23 Oct 2018 10:35:49 +0200
In-Reply-To: <20181023.102335.1716554595193005306.mbjorklu@cisco.com>
References:  <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz> <20181023.102335.1716554595193005306.mbjorklu@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 08:35:55 -0000

On Tue, 2018-10-23 at 10:23 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> 
> > 
> 
> > > Qin Wu  wrote:
> 
> > >> -----邮件原件-----
> 
> > >> å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Ladislav Lhotka
> 
> > >> å‘é€æ—¶é—´: 2018å¹´10月22æ—¥ 21:12
> 
> > >> 收件人: Martin Bjorklund
> 
> > >> 抄é€: netmod@ietf.org
> 
> > >> 主题: Re: [netmod] xpath expressions in JSON
> 
> > >> 
> 
> > >> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> 
> > >> > Ladislav Lhotka  wrote:
> 
> > >> > > Martin Bjorklund  writes:
> 
> > >> > > 
> 
> > >> > > > Hi,
> 
> > >> > > >
> 
> > >> > > > Going back to the most urgent issue, what is this WG's 
> 
> > >> > > > recommendation for the subscribed-notifications draft in NETCONF 
> 
> > >> > > > wrt/ their usage of
> 
> > >> > > > yang:xpath1.0 in filters?
> 
> > >> > > >
> 
> > >> > > > To summarize:
> 
> > >> > > >
> 
> > >> > > > We already have
> 
> > >> > > >
> 
> > >> > > >   o  instance-identifier in XML uses prefixes from the XML document
> 
> > >> > > >   o  instance-identifier in JSON uses module names as prefixes
> 
> > >> > > >   o  XPath in NETCONF filter uses prefixes from the XML document
> 
> > >> > > >   o  XPath in JSON query filter uses module names as prefixes
> 
> > >> > > >
> 
> > >> > > >
> 
> > >> > > > Alternative A:
> 
> > >> > > > --------------
> 
> > >> > > >
> 
> > >> > > > Use different encodings for "stream-xpath-filter" as well, 
> 
> > >> > > > depending on if it is XML or JSON.
> 
> > >> > > >
> 
> > >> > > > We would do in SN:
> 
> > >> > > >
> 
> > >> > > >     o  If the node is encoded in XML, the set of namespace
> 
> > >> > > >        declarations are those in scope on the
> 
> > >> > > >        'stream-xpath-filter' leaf element.
> 
> > >> > > >
> 
> > >> > > >     o  If the node is encoded in JSON, the set of namespace
> 
> > >> > > >        declarations is the set of prefix and namespace pairs
> 
> > >> > > >        for all supported YANG modules, where the prefix is
> 
> > >> > > 
> 
> > >> > > Is "supported" the same as "implemented", or something else?
> 
> > >> > 
> 
> > >> > It should be "implemented".
> 
> > >> > 
> 
> > >> > > >        the YANG module name and the namespace is as defined
> 
> > >> > > >        by the "namespace" statement in the YANG module.
> 
> > >> > > >
> 
> > >> > > > Pro: the format is consistent within each encoding.
> 
> > >> > > >
> 
> > >> > > > Con: unclear how to handle other encodings.
> 
> > >> > > > Con: we keep using context-depending encodings.
> 
> > >> > > 
> 
> > >> > >   Con: XPath expressions in JSON can get pretty long (I assume it's
> not
> 
> > >> > >   just an instance identifier but may contain predicates etc.). We
> 
> > >> > >   cannot use the trick with the default namespace as in YANG, so all
> 
> > >> > >   data node names will have to carry the prefix.
> 
> > >> > 
> 
> > >> > Yes.
> 
> > >> > 
> 
> > >> > > > We could probably add that CBOR uses the same representation as
> JSON.
> 
> > >> > > >
> 
> > >> > > > Example in XML:
> 
> > >> > > >
> 
> > >> > > >    
> > >> > > >       xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> 
> > >> > > >       xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> 
> > >> > > >     /if:interfaces/if:interface/ip:ipv4
> 
> > >> > > >   
> 
> > >> > > >
> 
> > >> > > > Example in JSON:
> 
> > >> > > >
> 
> > >> > > >   "stream-xpath-filter":
> 
> > >> > > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> ip:ipv4"
> 
> > >> > > >
> 
> > >> > > >
> 
> > >> > > >
> 
> > >> > > > Alternative B:
> 
> > >> > > > --------------
> 
> > >> > > >
> 
> > >> > > > Use a non-context depending encoding, with the module name as
> prefix.
> 
> > >> > > >
> 
> > >> > > > We would do in SN:
> 
> > >> > > >
> 
> > >> > > >     o  The set of namespace
> 
> > >> > > >        declarations is the set of prefix and namespace pairs
> 
> > >> > > >        for all supported YANG modules, where the prefix is
> 
> > >> > > >        the YANG module name and the namespace is as defined
> 
> > >> > > >        by the "namespace" statement in the YANG module.
> 
> > >> > > >
> 
> > >> > > > Pro: the format is independent from the protocol encoding
> 
> > >> > > >
> 
> > >> > > > Con: in XML, this leaf is treated differently from other XPath
> 
> > >> > > >      expressions, such as get-config filter and nacm rules.
> 
> > >> > > >
> 
> > >> > > > Example in XML:
> 
> > >> > > >
> 
> > >> > > >   
> 
> > >> > > >     /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> ip:ipv4
> 
> > >> > > >   
> 
> > >> > > >
> 
> > >> > > > Example in JSON:
> 
> > >> > > >
> 
> > >> > > >   "stream-xpath-filter":
> 
> > >> > > >     "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> ip:ipv4"
> 
> > >> > > >
> 
> > >> > > >
> 
> > >> > > > My proposal is A.  I think it is more important with consistency 
> 
> > >> > > > within each encoding than across encodings.
> 
> > >> > > 
> 
> > >> > > I would suggest to consider declaring prefixes & namespaces 
> 
> > >> > > explicitly in the data, as in the schema mount document. It is 
> 
> > >> > > independent of encoding and the expressions can be kept short. In 
> 
> > >> > > fact, one of the namespaces can be declared as default, so this use 
> 
> > >> > > of XPath would then be very similar to YANG.
> 
> > >> > 
> 
> > >> > Ok, so this is another alternative that works today, and achieves the 
> 
> > >> > goal of being encoding-independent.  It is still context-dependent 
> 
> > >> > though.
> 
> > >> 
> 
> > >> Yes, every module that uses XPath in data will have to deal with this.
> There may potentially be multiple independent prefix declarations (this is
> actually a con). 
> 
> > >> 
> 
> > >> > 
> 
> > >> > BTW, when used in filters, it is nice to let an unprefixed name to 
> 
> > >> > match any namespace; i.e., treat "foo" as syntactic sugar for
> 
> > >> > "local-name(.) = 'foo'".  ("*:foo" is not legal...)
> 
> > >> 
> 
> > >> Hmm, I think this is a bad idea because it departs even further from the
> original XPath semantics. Such chameleon names should IMO be pretty rare, and
> if they are needed, local-name() is always available.
> 
> > >> 
> 
> > >> [Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the
> below guideline is relevant.
> 
> > >> "
> 
> > >> The "local-name" function SHOULD NOT be used to reference local names
> 
> > >>    outside of the YANG module that defines the must or when expression
> 
> > >>    containing the "local-name" function.  Example of a "local-name"
> 
> > >>    function that should not be used:
> 
> > >> 
> 
> > >>       /*[local-name()='foo']
> 
> > >
> 
> > > This guideline is for must/when expressions *within* YANG modules.
> 
> > >
> 
> > > I'm talking about a different use case, namely filtering.  It is
> 
> > > pretty convenient for users to send a filter:
> 
> > >
> 
> > >   /interfaces/interface[name='eth0'/ipv4
> 
> > 
> 
> > This is impossible if we want to call it XPath. With an explicit
> 
> > namespace/prefix declaration, for example
> 
> > 
> 
> >   "namespace": [
> 
> >     {
> 
> >       "prefix": "if",
> 
> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
> 
> >       "default": true
> 
> >     },
> 
> >     {
> 
> >       "prefix": "ip",
> 
> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
> 
> >     }
> 
> >   ]
> 
> > 
> 
> > it would be
> 
> > 
> 
> >   /interfaces/interface[name='eth0']/ip:ipv4
> 
> > 
> 
> > which is not too bad either.
> 
> 
> Well, "ncc myhost --get -x /interfaces/interface[name='eth0']/ipv4" is
> a one-liner; if I also have to specify the namespace list for every
> filter, it suddenly is not that convenient.

But this is an UI issue. I am not against any aid provided by client tools, what
I am talking about is the "oficial" lexical representation of that data type,
that is also exchanged in protocols. The above expression breaks XPath rules.

Lada

> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 01:42:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69589130DC2 for ; Tue, 23 Oct 2018 01:42:53 -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, 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 sf4cFtH2gipf for ; Tue, 23 Oct 2018 01:42:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 260D3127148 for ; Tue, 23 Oct 2018 01:42:50 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 07F921AE0187; Tue, 23 Oct 2018 10:42:48 +0200 (CEST)
Date: Tue, 23 Oct 2018 10:42:48 +0200 (CEST)
Message-Id: <20181023.104248.384669434369597273.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <356c8c17ccb4028d854039d6843aab9c15137442.camel@nic.cz>
References: <87d0s1azc8.fsf@nic.cz> <20181023.102335.1716554595193005306.mbjorklu@cisco.com> <356c8c17ccb4028d854039d6843aab9c15137442.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 08:42:53 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gT24gVHVlLCAyMDE4LTEw
LTIzIGF0IDEwOjIzICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+IExhZGlzbGF2
IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gPiBNYXJ0aW4gQmpvcmtsdW5kIDxt
YmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0KPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiA+IFFpbiBX
dSA8YmlsbC53dUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiANCj4gPiA+ID4+IC0tLS0t6YKu5Lu2
5Y6f5Lu2LS0tLS0NCj4gPiANCj4gPiA+ID4+IOWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBMYWRpc2xhdiBMaG90a2ENCj4gPiANCj4gPiA+
ID4+IOWPkemAgeaXtumXtDogMjAxOOW5tDEw5pyIMjLml6UgMjE6MTINCj4gPiANCj4gPiA+ID4+
IOaUtuS7tuS6ujogTWFydGluIEJqb3JrbHVuZA0KPiA+IA0KPiA+ID4gPj4g5oqE6YCBOiBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiANCj4gPiA+ID4+IOS4u+mimDogUmU6IFtuZXRtb2RdIHhwYXRoIGV4
cHJlc3Npb25zIGluIEpTT04NCj4gPiANCj4gPiA+ID4+IA0KPiA+IA0KPiA+ID4gPj4gT24gTW9u
LCAyMDE4LTEwLTIyIGF0IDE0OjU2ICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+
IA0KPiA+ID4gPj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+
IA0KPiA+ID4gPj4gPiA+IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cml0ZXM6
DQo+ID4gDQo+ID4gPiA+PiA+ID4gDQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBIaSwNCj4gPiANCj4g
PiA+ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBHb2luZyBiYWNrIHRvIHRoZSBtb3N0
IHVyZ2VudCBpc3N1ZSwgd2hhdCBpcyB0aGlzIFdHJ3MgDQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBy
ZWNvbW1lbmRhdGlvbiBmb3IgdGhlIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyBkcmFmdCBpbiBO
RVRDT05GIA0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gd3J0LyB0aGVpciB1c2FnZSBvZg0KPiA+IA0K
PiA+ID4gPj4gPiA+ID4geWFuZzp4cGF0aDEuMCBpbiBmaWx0ZXJzPw0KPiA+IA0KPiA+ID4gPj4g
PiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+IFRvIHN1bW1hcml6ZToNCj4gPiANCj4gPiA+ID4+
ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBXZSBhbHJlYWR5IGhhdmUNCj4gPiANCj4gPiA+
ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIg
aW4gWE1MIHVzZXMgcHJlZml4ZXMgZnJvbSB0aGUgWE1MIGRvY3VtZW50DQo+ID4gDQo+ID4gPiA+
PiA+ID4gPiAgIG8gIGluc3RhbmNlLWlkZW50aWZpZXIgaW4gSlNPTiB1c2VzIG1vZHVsZSBuYW1l
cyBhcyBwcmVmaXhlcw0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gICBvICBYUGF0aCBpbiBORVRDT05G
IGZpbHRlciB1c2VzIHByZWZpeGVzIGZyb20gdGhlIFhNTCBkb2N1bWVudA0KPiA+IA0KPiA+ID4g
Pj4gPiA+ID4gICBvICBYUGF0aCBpbiBKU09OIHF1ZXJ5IGZpbHRlciB1c2VzIG1vZHVsZSBuYW1l
cyBhcyBwcmVmaXhlcw0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+
DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBBbHRlcm5hdGl2ZSBBOg0KPiA+IA0KPiA+ID4gPj4gPiA+
ID4gLS0tLS0tLS0tLS0tLS0NCj4gPiANCj4gPiA+ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+
ID4gPiBVc2UgZGlmZmVyZW50IGVuY29kaW5ncyBmb3IgInN0cmVhbS14cGF0aC1maWx0ZXIiIGFz
IHdlbGwsIA0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gZGVwZW5kaW5nIG9uIGlmIGl0IGlzIFhNTCBv
ciBKU09OLg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+IFdlIHdv
dWxkIGRvIGluIFNOOg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+
ICAgICBvICBJZiB0aGUgbm9kZSBpcyBlbmNvZGVkIGluIFhNTCwgdGhlIHNldCBvZiBuYW1lc3Bh
Y2UNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAgICBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGlu
IHNjb3BlIG9uIHRoZQ0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gICAgICAgICdzdHJlYW0teHBhdGgt
ZmlsdGVyJyBsZWFmIGVsZW1lbnQuDQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4g
Pj4gPiA+ID4gICAgIG8gIElmIHRoZSBub2RlIGlzIGVuY29kZWQgaW4gSlNPTiwgdGhlIHNldCBv
ZiBuYW1lc3BhY2UNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAgICBkZWNsYXJhdGlvbnMgaXMg
dGhlIHNldCBvZiBwcmVmaXggYW5kIG5hbWVzcGFjZSBwYWlycw0KPiA+IA0KPiA+ID4gPj4gPiA+
ID4gICAgICAgIGZvciBhbGwgc3VwcG9ydGVkIFlBTkcgbW9kdWxlcywgd2hlcmUgdGhlIHByZWZp
eCBpcw0KPiA+IA0KPiA+ID4gPj4gPiA+IA0KPiA+IA0KPiA+ID4gPj4gPiA+IElzICJzdXBwb3J0
ZWQiIHRoZSBzYW1lIGFzICJpbXBsZW1lbnRlZCIsIG9yIHNvbWV0aGluZyBlbHNlPw0KPiA+IA0K
PiA+ID4gPj4gPiANCj4gPiANCj4gPiA+ID4+ID4gSXQgc2hvdWxkIGJlICJpbXBsZW1lbnRlZCIu
DQo+ID4gDQo+ID4gPiA+PiA+IA0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gICAgICAgIHRoZSBZQU5H
IG1vZHVsZSBuYW1lIGFuZCB0aGUgbmFtZXNwYWNlIGlzIGFzIGRlZmluZWQNCj4gPiANCj4gPiA+
ID4+ID4gPiA+ICAgICAgICBieSB0aGUgIm5hbWVzcGFjZSIgc3RhdGVtZW50IGluIHRoZSBZQU5H
IG1vZHVsZS4NCj4gPiANCj4gPiA+ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBQcm86
IHRoZSBmb3JtYXQgaXMgY29uc2lzdGVudCB3aXRoaW4gZWFjaCBlbmNvZGluZy4NCj4gPiANCj4g
PiA+ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBDb246IHVuY2xlYXIgaG93IHRvIGhh
bmRsZSBvdGhlciBlbmNvZGluZ3MuDQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBDb246IHdlIGtlZXAg
dXNpbmcgY29udGV4dC1kZXBlbmRpbmcgZW5jb2RpbmdzLg0KPiA+IA0KPiA+ID4gPj4gPiA+IA0K
PiA+IA0KPiA+ID4gPj4gPiA+ICAgQ29uOiBYUGF0aCBleHByZXNzaW9ucyBpbiBKU09OIGNhbiBn
ZXQgcHJldHR5IGxvbmcgKEkgYXNzdW1lIGl0J3MNCj4gPiBub3QNCj4gPiANCj4gPiA+ID4+ID4g
PiAgIGp1c3QgYW4gaW5zdGFuY2UgaWRlbnRpZmllciBidXQgbWF5IGNvbnRhaW4gcHJlZGljYXRl
cyBldGMuKS4gV2UNCj4gPiANCj4gPiA+ID4+ID4gPiAgIGNhbm5vdCB1c2UgdGhlIHRyaWNrIHdp
dGggdGhlIGRlZmF1bHQgbmFtZXNwYWNlIGFzIGluIFlBTkcsIHNvIGFsbA0KPiA+IA0KPiA+ID4g
Pj4gPiA+ICAgZGF0YSBub2RlIG5hbWVzIHdpbGwgaGF2ZSB0byBjYXJyeSB0aGUgcHJlZml4Lg0K
PiA+IA0KPiA+ID4gPj4gPiANCj4gPiANCj4gPiA+ID4+ID4gWWVzLg0KPiA+IA0KPiA+ID4gPj4g
PiANCj4gPiANCj4gPiA+ID4+ID4gPiA+IFdlIGNvdWxkIHByb2JhYmx5IGFkZCB0aGF0IENCT1Ig
dXNlcyB0aGUgc2FtZSByZXByZXNlbnRhdGlvbiBhcw0KPiA+IEpTT04uDQo+ID4gDQo+ID4gPiA+
PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gRXhhbXBsZSBpbiBYTUw6DQo+ID4gDQo+ID4g
PiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gICA8c3RyZWFtLXhwYXRoLWZpbHRlcg0K
PiA+IA0KPiA+ID4gPj4gPiA+ID4gICAgICAgeG1sbnM6aWY9InVybjppZXRmOnBhcmFtczp4bWw6
bnM6eWFuZzppZXRmLWludGVyZmFjZXMiDQo+ID4gDQo+ID4gPiA+PiA+ID4gPiAgICAgICB4bWxu
czppcD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaXAiPg0KPiA+IA0KPiA+ID4g
Pj4gPiA+ID4gICAgIC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZS9pcDppcHY0DQo+ID4gDQo+
ID4gPiA+PiA+ID4gPiAgIDwvc3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPiANCj4gPiA+ID4+ID4g
PiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBFeGFtcGxlIGluIEpTT046DQo+ID4gDQo+ID4gPiA+
PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gICAic3RyZWFtLXhwYXRoLWZpbHRlciI6DQo+
ID4gDQo+ID4gPiA+PiA+ID4gPiAgICAgIi9pZXRmLWludGVyZmFjZXM6aW50ZXJmYWNlcy9pZXRm
LWludGVyZmFjZXM6aW50ZXJmYWNlL2lldGYtDQo+ID4gaXA6aXB2NCINCj4gPiANCj4gPiA+ID4+
ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiAN
Cj4gPiA+ID4+ID4gPiA+IEFsdGVybmF0aXZlIEI6DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiAtLS0t
LS0tLS0tLS0tLQ0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+IFVz
ZSBhIG5vbi1jb250ZXh0IGRlcGVuZGluZyBlbmNvZGluZywgd2l0aCB0aGUgbW9kdWxlIG5hbWUg
YXMNCj4gPiBwcmVmaXguDQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+
ID4gV2Ugd291bGQgZG8gaW4gU046DQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4g
Pj4gPiA+ID4gICAgIG8gIFRoZSBzZXQgb2YgbmFtZXNwYWNlDQo+ID4gDQo+ID4gPiA+PiA+ID4g
PiAgICAgICAgZGVjbGFyYXRpb25zIGlzIHRoZSBzZXQgb2YgcHJlZml4IGFuZCBuYW1lc3BhY2Ug
cGFpcnMNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAgICBmb3IgYWxsIHN1cHBvcnRlZCBZQU5H
IG1vZHVsZXMsIHdoZXJlIHRoZSBwcmVmaXggaXMNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAg
ICB0aGUgWUFORyBtb2R1bGUgbmFtZSBhbmQgdGhlIG5hbWVzcGFjZSBpcyBhcyBkZWZpbmVkDQo+
ID4gDQo+ID4gPiA+PiA+ID4gPiAgICAgICAgYnkgdGhlICJuYW1lc3BhY2UiIHN0YXRlbWVudCBp
biB0aGUgWUFORyBtb2R1bGUuDQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4g
PiA+ID4gUHJvOiB0aGUgZm9ybWF0IGlzIGluZGVwZW5kZW50IGZyb20gdGhlIHByb3RvY29sIGVu
Y29kaW5nDQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4gQ29uOiBp
biBYTUwsIHRoaXMgbGVhZiBpcyB0cmVhdGVkIGRpZmZlcmVudGx5IGZyb20gb3RoZXIgWFBhdGgN
Cj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAgZXhwcmVzc2lvbnMsIHN1Y2ggYXMgZ2V0LWNvbmZp
ZyBmaWx0ZXIgYW5kIG5hY20gcnVsZXMuDQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0KPiA+
ID4gPj4gPiA+ID4gRXhhbXBsZSBpbiBYTUw6DQo+ID4gDQo+ID4gPiA+PiA+ID4gPg0KPiA+IA0K
PiA+ID4gPj4gPiA+ID4gICA8c3RyZWFtLXhwYXRoLWZpbHRlcj4NCj4gPiANCj4gPiA+ID4+ID4g
PiA+ICAgICAvaWV0Zi1pbnRlcmZhY2VzOmludGVyZmFjZXMvaWV0Zi1pbnRlcmZhY2VzOmludGVy
ZmFjZS9pZXRmLQ0KPiA+IGlwOmlwdjQNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgPC9zdHJlYW0t
eHBhdGgtZmlsdGVyPg0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4gPiA+
IEV4YW1wbGUgaW4gSlNPTjoNCj4gPiANCj4gPiA+ID4+ID4gPiA+DQo+ID4gDQo+ID4gPiA+PiA+
ID4gPiAgICJzdHJlYW0teHBhdGgtZmlsdGVyIjoNCj4gPiANCj4gPiA+ID4+ID4gPiA+ICAgICAi
L2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzL2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2UvaWV0
Zi0NCj4gPiBpcDppcHY0Ig0KPiA+IA0KPiA+ID4gPj4gPiA+ID4NCj4gPiANCj4gPiA+ID4+ID4g
PiA+DQo+ID4gDQo+ID4gPiA+PiA+ID4gPiBNeSBwcm9wb3NhbCBpcyBBLiAgSSB0aGluayBpdCBp
cyBtb3JlIGltcG9ydGFudCB3aXRoIGNvbnNpc3RlbmN5IA0KPiA+IA0KPiA+ID4gPj4gPiA+ID4g
d2l0aGluIGVhY2ggZW5jb2RpbmcgdGhhbiBhY3Jvc3MgZW5jb2RpbmdzLg0KPiA+IA0KPiA+ID4g
Pj4gPiA+IA0KPiA+IA0KPiA+ID4gPj4gPiA+IEkgd291bGQgc3VnZ2VzdCB0byBjb25zaWRlciBk
ZWNsYXJpbmcgcHJlZml4ZXMgJiBuYW1lc3BhY2VzIA0KPiA+IA0KPiA+ID4gPj4gPiA+IGV4cGxp
Y2l0bHkgaW4gdGhlIGRhdGEsIGFzIGluIHRoZSBzY2hlbWEgbW91bnQgZG9jdW1lbnQuIEl0IGlz
IA0KPiA+IA0KPiA+ID4gPj4gPiA+IGluZGVwZW5kZW50IG9mIGVuY29kaW5nIGFuZCB0aGUgZXhw
cmVzc2lvbnMgY2FuIGJlIGtlcHQgc2hvcnQuIEluIA0KPiA+IA0KPiA+ID4gPj4gPiA+IGZhY3Qs
IG9uZSBvZiB0aGUgbmFtZXNwYWNlcyBjYW4gYmUgZGVjbGFyZWQgYXMgZGVmYXVsdCwgc28gdGhp
cyB1c2UgDQo+ID4gDQo+ID4gPiA+PiA+ID4gb2YgWFBhdGggd291bGQgdGhlbiBiZSB2ZXJ5IHNp
bWlsYXIgdG8gWUFORy4NCj4gPiANCj4gPiA+ID4+ID4gDQo+ID4gDQo+ID4gPiA+PiA+IE9rLCBz
byB0aGlzIGlzIGFub3RoZXIgYWx0ZXJuYXRpdmUgdGhhdCB3b3JrcyB0b2RheSwgYW5kIGFjaGll
dmVzIHRoZSANCj4gPiANCj4gPiA+ID4+ID4gZ29hbCBvZiBiZWluZyBlbmNvZGluZy1pbmRlcGVu
ZGVudC4gIEl0IGlzIHN0aWxsIGNvbnRleHQtZGVwZW5kZW50IA0KPiA+IA0KPiA+ID4gPj4gPiB0
aG91Z2guDQo+ID4gDQo+ID4gPiA+PiANCj4gPiANCj4gPiA+ID4+IFllcywgZXZlcnkgbW9kdWxl
IHRoYXQgdXNlcyBYUGF0aCBpbiBkYXRhIHdpbGwgaGF2ZSB0byBkZWFsIHdpdGggdGhpcy4NCj4g
PiBUaGVyZSBtYXkgcG90ZW50aWFsbHkgYmUgbXVsdGlwbGUgaW5kZXBlbmRlbnQgcHJlZml4IGRl
Y2xhcmF0aW9ucyAodGhpcyBpcw0KPiA+IGFjdHVhbGx5IGEgY29uKS4gDQo+ID4gDQo+ID4gPiA+
PiANCj4gPiANCj4gPiA+ID4+ID4gDQo+ID4gDQo+ID4gPiA+PiA+IEJUVywgd2hlbiB1c2VkIGlu
IGZpbHRlcnMsIGl0IGlzIG5pY2UgdG8gbGV0IGFuIHVucHJlZml4ZWQgbmFtZSB0byANCj4gPiAN
Cj4gPiA+ID4+ID4gbWF0Y2ggYW55IG5hbWVzcGFjZTsgaS5lLiwgdHJlYXQgImZvbyIgYXMgc3lu
dGFjdGljIHN1Z2FyIGZvcg0KPiA+IA0KPiA+ID4gPj4gPiAibG9jYWwtbmFtZSguKSA9ICdmb28n
Ii4gICgiKjpmb28iIGlzIG5vdCBsZWdhbC4uLikNCj4gPiANCj4gPiA+ID4+IA0KPiA+IA0KPiA+
ID4gPj4gSG1tLCBJIHRoaW5rIHRoaXMgaXMgYSBiYWQgaWRlYSBiZWNhdXNlIGl0IGRlcGFydHMg
ZXZlbiBmdXJ0aGVyIGZyb20gdGhlDQo+ID4gb3JpZ2luYWwgWFBhdGggc2VtYW50aWNzLiBTdWNo
IGNoYW1lbGVvbiBuYW1lcyBzaG91bGQgSU1PIGJlIHByZXR0eSByYXJlLCBhbmQNCj4gPiBpZiB0
aGV5IGFyZSBuZWVkZWQsIGxvY2FsLW5hbWUoKSBpcyBhbHdheXMgYXZhaWxhYmxlLg0KPiA+IA0K
PiA+ID4gPj4gDQo+ID4gDQo+ID4gPiA+PiBbUWluXTogQWdyZWUgd2l0aCBMYWRhLCBSZWZlcmVu
Y2luZyBSRkM4NDA3LCBzZWN0aW9uIDQuNi4yLCBJIHRoaW5rIHRoZQ0KPiA+IGJlbG93IGd1aWRl
bGluZSBpcyByZWxldmFudC4NCj4gPiANCj4gPiA+ID4+ICINCj4gPiANCj4gPiA+ID4+IFRoZSAi
bG9jYWwtbmFtZSIgZnVuY3Rpb24gU0hPVUxEIE5PVCBiZSB1c2VkIHRvIHJlZmVyZW5jZSBsb2Nh
bCBuYW1lcw0KPiA+IA0KPiA+ID4gPj4gICAgb3V0c2lkZSBvZiB0aGUgWUFORyBtb2R1bGUgdGhh
dCBkZWZpbmVzIHRoZSBtdXN0IG9yIHdoZW4gZXhwcmVzc2lvbg0KPiA+IA0KPiA+ID4gPj4gICAg
Y29udGFpbmluZyB0aGUgImxvY2FsLW5hbWUiIGZ1bmN0aW9uLiAgRXhhbXBsZSBvZiBhICJsb2Nh
bC1uYW1lIg0KPiA+IA0KPiA+ID4gPj4gICAgZnVuY3Rpb24gdGhhdCBzaG91bGQgbm90IGJlIHVz
ZWQ6DQo+ID4gDQo+ID4gPiA+PiANCj4gPiANCj4gPiA+ID4+ICAgICAgIC8qW2xvY2FsLW5hbWUo
KT0nZm9vJ10NCj4gPiANCj4gPiA+ID4NCj4gPiANCj4gPiA+ID4gVGhpcyBndWlkZWxpbmUgaXMg
Zm9yIG11c3Qvd2hlbiBleHByZXNzaW9ucyAqd2l0aGluKiBZQU5HIG1vZHVsZXMuDQo+ID4gDQo+
ID4gPiA+DQo+ID4gDQo+ID4gPiA+IEknbSB0YWxraW5nIGFib3V0IGEgZGlmZmVyZW50IHVzZSBj
YXNlLCBuYW1lbHkgZmlsdGVyaW5nLiAgSXQgaXMNCj4gPiANCj4gPiA+ID4gcHJldHR5IGNvbnZl
bmllbnQgZm9yIHVzZXJzIHRvIHNlbmQgYSBmaWx0ZXI6DQo+ID4gDQo+ID4gPiA+DQo+ID4gDQo+
ID4gPiA+ICAgL2ludGVyZmFjZXMvaW50ZXJmYWNlW25hbWU9J2V0aDAnL2lwdjQNCj4gPiANCj4g
PiA+IA0KPiA+IA0KPiA+ID4gVGhpcyBpcyBpbXBvc3NpYmxlIGlmIHdlIHdhbnQgdG8gY2FsbCBp
dCBYUGF0aC4gV2l0aCBhbiBleHBsaWNpdA0KPiA+IA0KPiA+ID4gbmFtZXNwYWNlL3ByZWZpeCBk
ZWNsYXJhdGlvbiwgZm9yIGV4YW1wbGUNCj4gPiANCj4gPiA+IA0KPiA+IA0KPiA+ID4gICAibmFt
ZXNwYWNlIjogWw0KPiA+IA0KPiA+ID4gICAgIHsNCj4gPiANCj4gPiA+ICAgICAgICJwcmVmaXgi
OiAiaWYiLA0KPiA+IA0KPiA+ID4gICAgICAgInVyaSI6ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z
Onlhbmc6aWV0Zi1pbnRlcmZhY2VzIiwNCj4gPiANCj4gPiA+ICAgICAgICJkZWZhdWx0IjogdHJ1
ZQ0KPiA+IA0KPiA+ID4gICAgIH0sDQo+ID4gDQo+ID4gPiAgICAgew0KPiA+IA0KPiA+ID4gICAg
ICAgInByZWZpeCI6ICJpcCIsDQo+ID4gDQo+ID4gPiAgICAgICAidXJpIjogInVybjppZXRmOnBh
cmFtczp4bWw6bnM6eWFuZzppZXRmLWlwIg0KPiA+IA0KPiA+ID4gICAgIH0NCj4gPiANCj4gPiA+
ICAgXQ0KPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiBpdCB3b3VsZCBiZQ0KPiA+IA0KPiA+ID4g
DQo+ID4gDQo+ID4gPiAgIC9pbnRlcmZhY2VzL2ludGVyZmFjZVtuYW1lPSdldGgwJ10vaXA6aXB2
NA0KPiA+IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiB3aGljaCBpcyBub3QgdG9vIGJhZCBlaXRoZXIu
DQo+ID4gDQo+ID4gDQo+ID4gV2VsbCwgIm5jYyBteWhvc3QgLS1nZXQgLXggL2ludGVyZmFjZXMv
aW50ZXJmYWNlW25hbWU9J2V0aDAnXS9pcHY0IiBpcw0KPiA+IGEgb25lLWxpbmVyOyBpZiBJIGFs
c28gaGF2ZSB0byBzcGVjaWZ5IHRoZSBuYW1lc3BhY2UgbGlzdCBmb3IgZXZlcnkNCj4gPiBmaWx0
ZXIsIGl0IHN1ZGRlbmx5IGlzIG5vdCB0aGF0IGNvbnZlbmllbnQuDQo+IA0KPiBCdXQgdGhpcyBp
cyBhbiBVSSBpc3N1ZS4gSSBhbSBub3QgYWdhaW5zdCBhbnkgYWlkIHByb3ZpZGVkIGJ5IGNsaWVu
dCB0b29scywgd2hhdA0KPiBJIGFtIHRhbGtpbmcgYWJvdXQgaXMgdGhlICJvZmljaWFsIiBsZXhp
Y2FsIHJlcHJlc2VudGF0aW9uIG9mIHRoYXQgZGF0YSB0eXBlLA0KPiB0aGF0IGlzIGFsc28gZXhj
aGFuZ2VkIGluIHByb3RvY29scy4NCg0KDQo+IFRoZSBhYm92ZSBleHByZXNzaW9uIGJyZWFrcyBY
UGF0aCBydWxlcy4NCg0KVGhpcyBJIGFncmVlIHdpdGghDQoNCg0KL21hcnRpbg0KDQoNCg==


From nobody Tue Oct 23 02:10:55 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0E1130E23 for ; Tue, 23 Oct 2018 02:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 F8YRIhQgiwBq for ; Tue, 23 Oct 2018 02:10:51 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBCC130DE7 for ; Tue, 23 Oct 2018 02:10:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6727; q=dns/txt; s=iport; t=1540285851; x=1541495451; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+1JYnPVGaILd92bqZoAztfZgCI8/pm4IjZ/ktj/u+Wo=; b=Ojeg8hArEj75WP9XtaMz7b8xmHGXG1n6UWhS7/kwSrMxJ/YRsygD9z16 n7v6Iq2s1PT/8n2kJDfzxBhBKeEnl9MDJdP+0lBS1TbcEk1c3CPuaSWtI 85QUs7RAg6R+hA+cWpK2qrBEjDHbaRtbYF7BdNb3owSGF2w2jCSWP2gE1 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAACX5M5b/xbLJq0ZA0cZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFlAgGBWIF9EiiDdYh3jUuZDw2EbAKFSTgWAQMBAQI?= =?us-ascii?q?BAQJtKEIBEAGEZwEFIw8BBVEJAg4KAgIjAwICRhEGAQwGAgEBgx2CAokZgRK?= =?us-ascii?q?bTYEuhTuEaoELim2BQT+BESeCa4gBglcCiGsELIUxjzBUCZBuBheJNIZ8kCO?= =?us-ascii?q?GSIFaIYFVMxoIGxWDJ4M6AQuNEj4whQSIdwEB?=
X-IronPort-AV: E=Sophos;i="5.54,415,1534809600";  d="scan'208";a="7405630"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 09:10:48 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9N9AmTa016838; Tue, 23 Oct 2018 09:10:48 GMT
To: Martin Bjorklund , bill.wu@huawei.com, netmod@ietf.org
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Tue, 23 Oct 2018 10:10:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87d0s1azc8.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 09:10:54 -0000

On 23/10/2018 08:36, Ladislav Lhotka wrote:
> Martin Bjorklund  writes:
>
>> Qin Wu  wrote:
>>> -----邮件原件-----
>>> å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Ladislav Lhotka
>>> å‘é€æ—¶é—´: 2018å¹´10月22æ—¥ 21:12
>>> 收件人: Martin Bjorklund
>>> 抄é€: netmod@ietf.org
>>> 主题: Re: [netmod] xpath expressions in JSON
>>>
>>> On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
>>>> Ladislav Lhotka  wrote:
>>>>> Martin Bjorklund  writes:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Going back to the most urgent issue, what is this WG's
>>>>>> recommendation for the subscribed-notifications draft in NETCONF
>>>>>> wrt/ their usage of
>>>>>> yang:xpath1.0 in filters?
>>>>>>
>>>>>> To summarize:
>>>>>>
>>>>>> We already have
>>>>>>
>>>>>>    o  instance-identifier in XML uses prefixes from the XML document
>>>>>>    o  instance-identifier in JSON uses module names as prefixes
>>>>>>    o  XPath in NETCONF filter uses prefixes from the XML document
>>>>>>    o  XPath in JSON query filter uses module names as prefixes
>>>>>>
>>>>>>
>>>>>> Alternative A:
>>>>>> --------------
>>>>>>
>>>>>> Use different encodings for "stream-xpath-filter" as well,
>>>>>> depending on if it is XML or JSON.
>>>>>>
>>>>>> We would do in SN:
>>>>>>
>>>>>>      o  If the node is encoded in XML, the set of namespace
>>>>>>         declarations are those in scope on the
>>>>>>         'stream-xpath-filter' leaf element.
>>>>>>
>>>>>>      o  If the node is encoded in JSON, the set of namespace
>>>>>>         declarations is the set of prefix and namespace pairs
>>>>>>         for all supported YANG modules, where the prefix is
>>>>> Is "supported" the same as "implemented", or something else?
>>>> It should be "implemented".
>>>>
>>>>>>         the YANG module name and the namespace is as defined
>>>>>>         by the "namespace" statement in the YANG module.
>>>>>>
>>>>>> Pro: the format is consistent within each encoding.
>>>>>>
>>>>>> Con: unclear how to handle other encodings.
>>>>>> Con: we keep using context-depending encodings.
>>>>>    Con: XPath expressions in JSON can get pretty long (I assume it's not
>>>>>    just an instance identifier but may contain predicates etc.). We
>>>>>    cannot use the trick with the default namespace as in YANG, so all
>>>>>    data node names will have to carry the prefix.
>>>> Yes.
>>>>
>>>>>> We could probably add that CBOR uses the same representation as JSON.
>>>>>>
>>>>>> Example in XML:
>>>>>>
>>>>>>    >>>>>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>>>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>>>>>>      /if:interfaces/if:interface/ip:ipv4
>>>>>>    
>>>>>>
>>>>>> Example in JSON:
>>>>>>
>>>>>>    "stream-xpath-filter":
>>>>>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alternative B:
>>>>>> --------------
>>>>>>
>>>>>> Use a non-context depending encoding, with the module name as prefix.
>>>>>>
>>>>>> We would do in SN:
>>>>>>
>>>>>>      o  The set of namespace
>>>>>>         declarations is the set of prefix and namespace pairs
>>>>>>         for all supported YANG modules, where the prefix is
>>>>>>         the YANG module name and the namespace is as defined
>>>>>>         by the "namespace" statement in the YANG module.
>>>>>>
>>>>>> Pro: the format is independent from the protocol encoding
>>>>>>
>>>>>> Con: in XML, this leaf is treated differently from other XPath
>>>>>>       expressions, such as get-config filter and nacm rules.
>>>>>>
>>>>>> Example in XML:
>>>>>>
>>>>>>    
>>>>>>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>>>>>>    
>>>>>>
>>>>>> Example in JSON:
>>>>>>
>>>>>>    "stream-xpath-filter":
>>>>>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>>>>>
>>>>>>
>>>>>> My proposal is A.  I think it is more important with consistency
>>>>>> within each encoding than across encodings.
>>>>> I would suggest to consider declaring prefixes & namespaces
>>>>> explicitly in the data, as in the schema mount document. It is
>>>>> independent of encoding and the expressions can be kept short. In
>>>>> fact, one of the namespaces can be declared as default, so this use
>>>>> of XPath would then be very similar to YANG.
>>>> Ok, so this is another alternative that works today, and achieves the
>>>> goal of being encoding-independent.  It is still context-dependent
>>>> though.
>>> Yes, every module that uses XPath in data will have to deal with this. There may potentially be multiple independent prefix declarations (this is actually a con).
>>>
>>>> BTW, when used in filters, it is nice to let an unprefixed name to
>>>> match any namespace; i.e., treat "foo" as syntactic sugar for
>>>> "local-name(.) = 'foo'".  ("*:foo" is not legal...)
>>> Hmm, I think this is a bad idea because it departs even further from the original XPath semantics. Such chameleon names should IMO be pretty rare, and if they are needed, local-name() is always available.
>>>
>>> [Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the below guideline is relevant.
>>> "
>>> The "local-name" function SHOULD NOT be used to reference local names
>>>     outside of the YANG module that defines the must or when expression
>>>     containing the "local-name" function.  Example of a "local-name"
>>>     function that should not be used:
>>>
>>>        /*[local-name()='foo']
>> This guideline is for must/when expressions *within* YANG modules.
>>
>> I'm talking about a different use case, namely filtering.  It is
>> pretty convenient for users to send a filter:
>>
>>    /interfaces/interface[name='eth0'/ipv4
> This is impossible if we want to call it XPath. With an explicit
> namespace/prefix declaration, for example
>
>    "namespace": [
>      {
>        "prefix": "if",
>        "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
>        "default": true
>      },
>      {
>        "prefix": "ip",
>        "uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
>      }
>    ]
>
> it would be
>
>    /interfaces/interface[name='eth0']/ip:ipv4
>
> which is not too bad either.
This looks verbose to me.

I would still prefer using separate encodings for XML vs JSON/CBOR 
(alternative A) in the short term.

Longer term, I think that we should look at something similar to the 
JSON path encoding scheme.

Thanks,
Rob


From nobody Tue Oct 23 02:21:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4612F1AB for ; Tue, 23 Oct 2018 02:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 zpb-JZQOTWZP for ; Tue, 23 Oct 2018 02:20:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 5D3F512777C for ; Tue, 23 Oct 2018 02:20:57 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 84AE06011C; Tue, 23 Oct 2018 11:20:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540286455; bh=WRkK/oK5lPvlqYQlrtgKTbIkAxqBq/+6JnNJL9s50lk=; h=From:To:Date; b=HFozIOvaaJjcYA8gFjmMKZE80LIwAXGwgyew+4slfsbd4GB5SWblA9AMI3OONYqM8 48yxAQh1nV0owQzQqixhFpjL3LLjgQBWjUe3uUDwnzOaaAwiUVY1BNJZVkcXVX/U7s Hgt90BgFiRu/B+Md5VQgUB3cOy1X7MkIoCyRfcBI=
Message-ID: <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , Martin Bjorklund ,  bill.wu@huawei.com, netmod@ietf.org
Date: Tue, 23 Oct 2018 11:20:54 +0200
In-Reply-To: 
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 09:21:01 -0000

On Tue, 2018-10-23 at 10:10 +0100, Robert Wilton wrote:
> 
> On 23/10/2018 08:36, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Qin Wu  wrote:
> > > > -----邮件原件-----
> > > > å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Ladislav Lhotka
> > > > å‘é€æ—¶é—´: 2018å¹´10月22æ—¥ 21:12
> > > > 收件人: Martin Bjorklund
> > > > 抄é€: netmod@ietf.org
> > > > 主题: Re: [netmod] xpath expressions in JSON
> > > > 
> > > > On Mon, 2018-10-22 at 14:56 +0200, Martin Bjorklund wrote:
> > > > > Ladislav Lhotka  wrote:
> > > > > > Martin Bjorklund  writes:
> > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Going back to the most urgent issue, what is this WG's
> > > > > > > recommendation for the subscribed-notifications draft in NETCONF
> > > > > > > wrt/ their usage of
> > > > > > > yang:xpath1.0 in filters?
> > > > > > > 
> > > > > > > To summarize:
> > > > > > > 
> > > > > > > We already have
> > > > > > > 
> > > > > > >    o  instance-identifier in XML uses prefixes from the XML
> > > > > > > document
> > > > > > >    o  instance-identifier in JSON uses module names as prefixes
> > > > > > >    o  XPath in NETCONF filter uses prefixes from the XML document
> > > > > > >    o  XPath in JSON query filter uses module names as prefixes
> > > > > > > 
> > > > > > > 
> > > > > > > Alternative A:
> > > > > > > --------------
> > > > > > > 
> > > > > > > Use different encodings for "stream-xpath-filter" as well,
> > > > > > > depending on if it is XML or JSON.
> > > > > > > 
> > > > > > > We would do in SN:
> > > > > > > 
> > > > > > >      o  If the node is encoded in XML, the set of namespace
> > > > > > >         declarations are those in scope on the
> > > > > > >         'stream-xpath-filter' leaf element.
> > > > > > > 
> > > > > > >      o  If the node is encoded in JSON, the set of namespace
> > > > > > >         declarations is the set of prefix and namespace pairs
> > > > > > >         for all supported YANG modules, where the prefix is
> > > > > > Is "supported" the same as "implemented", or something else?
> > > > > It should be "implemented".
> > > > > 
> > > > > > >         the YANG module name and the namespace is as defined
> > > > > > >         by the "namespace" statement in the YANG module.
> > > > > > > 
> > > > > > > Pro: the format is consistent within each encoding.
> > > > > > > 
> > > > > > > Con: unclear how to handle other encodings.
> > > > > > > Con: we keep using context-depending encodings.
> > > > > >    Con: XPath expressions in JSON can get pretty long (I assume it's
> > > > > > not
> > > > > >    just an instance identifier but may contain predicates etc.). We
> > > > > >    cannot use the trick with the default namespace as in YANG, so
> > > > > > all
> > > > > >    data node names will have to carry the prefix.
> > > > > Yes.
> > > > > 
> > > > > > > We could probably add that CBOR uses the same representation as
> > > > > > > JSON.
> > > > > > > 
> > > > > > > Example in XML:
> > > > > > > 
> > > > > > >     > > > > > >        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
> > > > > > >        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
> > > > > > >      /if:interfaces/if:interface/ip:ipv4
> > > > > > >    
> > > > > > > 
> > > > > > > Example in JSON:
> > > > > > > 
> > > > > > >    "stream-xpath-filter":
> > > > > > >      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> > > > > > > ip:ipv4"
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Alternative B:
> > > > > > > --------------
> > > > > > > 
> > > > > > > Use a non-context depending encoding, with the module name as
> > > > > > > prefix.
> > > > > > > 
> > > > > > > We would do in SN:
> > > > > > > 
> > > > > > >      o  The set of namespace
> > > > > > >         declarations is the set of prefix and namespace pairs
> > > > > > >         for all supported YANG modules, where the prefix is
> > > > > > >         the YANG module name and the namespace is as defined
> > > > > > >         by the "namespace" statement in the YANG module.
> > > > > > > 
> > > > > > > Pro: the format is independent from the protocol encoding
> > > > > > > 
> > > > > > > Con: in XML, this leaf is treated differently from other XPath
> > > > > > >       expressions, such as get-config filter and nacm rules.
> > > > > > > 
> > > > > > > Example in XML:
> > > > > > > 
> > > > > > >    
> > > > > > >      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> > > > > > > ip:ipv4
> > > > > > >    
> > > > > > > 
> > > > > > > Example in JSON:
> > > > > > > 
> > > > > > >    "stream-xpath-filter":
> > > > > > >      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-
> > > > > > > ip:ipv4"
> > > > > > > 
> > > > > > > 
> > > > > > > My proposal is A.  I think it is more important with consistency
> > > > > > > within each encoding than across encodings.
> > > > > > I would suggest to consider declaring prefixes & namespaces
> > > > > > explicitly in the data, as in the schema mount document. It is
> > > > > > independent of encoding and the expressions can be kept short. In
> > > > > > fact, one of the namespaces can be declared as default, so this use
> > > > > > of XPath would then be very similar to YANG.
> > > > > Ok, so this is another alternative that works today, and achieves the
> > > > > goal of being encoding-independent.  It is still context-dependent
> > > > > though.
> > > > Yes, every module that uses XPath in data will have to deal with this.
> > > > There may potentially be multiple independent prefix declarations (this
> > > > is actually a con).
> > > > 
> > > > > BTW, when used in filters, it is nice to let an unprefixed name to
> > > > > match any namespace; i.e., treat "foo" as syntactic sugar for
> > > > > "local-name(.) = 'foo'".  ("*:foo" is not legal...)
> > > > Hmm, I think this is a bad idea because it departs even further from the
> > > > original XPath semantics. Such chameleon names should IMO be pretty
> > > > rare, and if they are needed, local-name() is always available.
> > > > 
> > > > [Qin]: Agree with Lada, Referencing RFC8407, section 4.6.2, I think the
> > > > below guideline is relevant.
> > > > "
> > > > The "local-name" function SHOULD NOT be used to reference local names
> > > >     outside of the YANG module that defines the must or when expression
> > > >     containing the "local-name" function.  Example of a "local-name"
> > > >     function that should not be used:
> > > > 
> > > >        /*[local-name()='foo']
> > > This guideline is for must/when expressions *within* YANG modules.
> > > 
> > > I'm talking about a different use case, namely filtering.  It is
> > > pretty convenient for users to send a filter:
> > > 
> > >    /interfaces/interface[name='eth0'/ipv4
> > This is impossible if we want to call it XPath. With an explicit
> > namespace/prefix declaration, for example
> > 
> >    "namespace": [
> >      {
> >        "prefix": "if",
> >        "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
> >        "default": true
> >      },
> >      {
> >        "prefix": "ip",
> >        "uri": "urn:ietf:params:xml:ns:yang:ietf-ip"
> >      }
> >    ]
> > 
> > it would be
> > 
> >    /interfaces/interface[name='eth0']/ip:ipv4
> > 
> > which is not too bad either.
> This looks verbose to me.

Note that the namespace information needn't be sent along with every XPath
expression as it would probably be the case in the XML encoding of option A.
Only if a new namespace is being used, the "namespace" list has to be updated. 

> 
> I would still prefer using separate encodings for XML vs JSON/CBOR 
> (alternative A) in the short term.

Sure, this is another decent option.

Lada

> 
> Longer term, I think that we should look at something similar to the 
> JSON path encoding scheme.
> 
> Thanks,
> Rob
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 02:28:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE8912777C for ; Tue, 23 Oct 2018 02:28:07 -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 GUL5c-9E3HOm for ; Tue, 23 Oct 2018 02:28:04 -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 4DAF0130DF4 for ; Tue, 23 Oct 2018 02:28:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 62E0AFC9 for ; Tue, 23 Oct 2018 11:28:02 +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 6ek-3OtqNVqw for ; Tue, 23 Oct 2018 11:28:01 +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 for ; Tue, 23 Oct 2018 11:28:02 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4760320039 for ; Tue, 23 Oct 2018 11:28:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1yUrBJDnfOGz for ; Tue, 23 Oct 2018 11:28:01 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F37932003A for ; Tue, 23 Oct 2018 11:28:01 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 23 Oct 2018 11:28:00 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 843D930027B7F4; Tue, 23 Oct 2018 11:28:00 +0200 (CEST)
Date: Tue, 23 Oct 2018 11:28:00 +0200
From: Juergen Schoenwaelder 
To: 
Message-ID: <20181023092800.mhu4kntxhjycsol4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>  <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 09:28:07 -0000

On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:
> 
> Note that the namespace information needn't be sent along with every XPath
> expression as it would probably be the case in the XML encoding of option A.
> Only if a new namespace is being used, the "namespace" list has to be updated. 
>

Can we pre-populate the context with namespaces, for example,
controlled via an extension of yang library? Perhaps we can simply
pre-polutate contexts with all module names? Yes, I know this makes
xpath expressions rather verbose but on the other hand it takes away
guesswork and (client) tools may do expansion of an unprefixed
expression into a proper namespace prefixed expression.

/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 23 02:39:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61862130E3E for ; Tue, 23 Oct 2018 02:39:33 -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, DKIMWL_WL_MED=-0.001, 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 dlotVYEHQHgH for ; Tue, 23 Oct 2018 02:39:31 -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 D752B130E1E for ; Tue, 23 Oct 2018 02:39:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21554; q=dns/txt; s=iport; t=1540287571; x=1541497171; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=VrzFKVMN0eKF5evZRyopLu+ViSgMXN2SnlXp4XxY8O4=; b=OjsspADdl0GiMhtmr8/J+t8sbigGeYR87XsVyS/G6F2yLiruQOTsPJtV zjneiF3KG7FRfQP2P8RsofFrl7cPE7cPEmjWr4E5KnayIWM1fpkuzMep3 PZS097AFWdXBDQiWm7LKVsDr2PdHaYIaJyEqyyPubZftuZ+2mUbRHXbwR k=;
X-Files: : None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAC/685b/xbLJq1jGgEBAQICAQE?= =?us-ascii?q?BCAIBAQGBZoFWBYEQbRIog3WId41MmQ8NGAuEA0YChUk4FgEDAQECAQECbRw?= =?us-ascii?q?MhTsBAQEDAQEhSxsLGCoCAicwEwYCAQGDHQGCAQ+lcYEuhTuEWgoFi3iBQT+?= =?us-ascii?q?BESeCa4MbAQGCDYJXglcCiGsEhV1Cjm5UCYQQgW6KcAYXiTSGfJAjhkiBWiE?= =?us-ascii?q?ngS4zGggbFTuCbIImF30BC4dThT8+MI17AQE?=
X-IronPort-AV: E=Sophos;i="5.54,415,1534809600";  d="scan'208";a="7405016"
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; 23 Oct 2018 09:39:28 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9N9dM4K021126 for ; Tue, 23 Oct 2018 09:39:22 GMT
To: netmod@ietf.org
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>  <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz> <20181023092800.mhu4kntxhjycsol4@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Tue, 23 Oct 2018 10:39:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181023092800.mhu4kntxhjycsol4@anna.jacobs.jacobs-university.de>
Content-Type: multipart/mixed; boundary="------------4DD3D6B374730FEC6ED00AB0"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 09:39:33 -0000

This is a multi-part message in MIME format.
--------------4DD3D6B374730FEC6ED00AB0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Juergen,

Is this the same as Martin's alternative B proposed previously 
(attached)?  Or are you suggesting a different alternative?

Thanks,
Rob


On 23/10/2018 10:28, Juergen Schoenwaelder wrote:
> On Tue, Oct 23, 2018 at 11:20:54AM +0200, Ladislav Lhotka wrote:
>> Note that the namespace information needn't be sent along with every XPath
>> expression as it would probably be the case in the XML encoding of option A.
>> Only if a new namespace is being used, the "namespace" list has to be updated.
>>
> Can we pre-populate the context with namespaces, for example,
> controlled via an extension of yang library? Perhaps we can simply
> pre-polutate contexts with all module names? Yes, I know this makes
> xpath expressions rather verbose but on the other hand it takes away
> guesswork and (client) tools may do expansion of an unprefixed
> expression into a proper namespace prefixed expression.
>
> /js
>


--------------4DD3D6B374730FEC6ED00AB0
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message"

X-Account-Key: account2
X-Mozilla-Keys: 
Received: from xch-rcd-009.cisco.com (173.37.102.19) by xch-rcd-007.cisco.com
 (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via
 Mailbox Transport; Thu, 18 Oct 2018 05:30:54 -0500
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-009.cisco.com
 (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Oct
 2018 05:30:53 -0500
Received: from alln-iport-6.cisco.com (173.37.142.93) by mail.cisco.com
 (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend
 Transport; Thu, 18 Oct 2018 05:30:53 -0500
Received: from rcdn-core-11.cisco.com ([173.37.93.147])
 by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 18 Oct 2018 10:30:53 +0000
Received: from alln-inbound-c.cisco.com (alln-inbound-c.cisco.com
 [173.37.147.233])
 by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w9IAUolu002973
 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Thu, 18 Oct 2018 10:30:51 GMT
Received-SPF: Pass (alln-inbound-c.cisco.com: domain of
 netmod-bounces@ietf.org designates 2001:1900:3001:11::2c as
 permitted sender) identity=mailfrom;
 client-ip=2001:1900:3001:11::2c;
 receiver=alln-inbound-c.cisco.com;
 envelope-from="netmod-bounces@ietf.org";
 x-sender="netmod-bounces@ietf.org"; x-conformance=spf_only;
 x-record-type="v=spf1"; x-record-text="v=spf1
 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
 ip4:66.70.182.38 ip4:158.69.166.16/29
 ip6:2607:5300:203:1b26::0/64 ip4:158.69.229.207
 ip4:192.95.54.40/29 ip6:2607:5300:0060:9ccf::0/64 -all"
Received-SPF: None (alln-inbound-c.cisco.com: no sender
 authenticity information available from domain of
 postmaster@mail.ietf.org) identity=helo;
 client-ip=2001:1900:3001:11::2c;
 receiver=alln-inbound-c.cisco.com;
 envelope-from="netmod-bounces@ietf.org";
 x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only
Authentication-Results: alln-inbound-c.cisco.com;
 spf=Pass smtp.mailfrom=netmod-bounces@ietf.org;
 spf=None smtp.helo=postmaster@mail.ietf.org;
 dkim=pass (signature verified) header.i=@ietf.org
X-from-outside-Cisco: 2001:1900:3001:11::2c
IronPort-PHdr: =?us-ascii?q?9a23=3A3mOHZh0duQJl1JNcsmDT+DRfVm0co7zxezQtwd?=
 =?us-ascii?q?8ZsekVKPrxwZ3uMQTl6Ol3ixeRBMOHs60C07KempujcFRI2YyGvnEGfc4EfD?=
 =?us-ascii?q?4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFA?=
 =?us-ascii?q?nhOgppPOT1HZPZg9iq2+yo9JDffwdFiCChbb9uMR67sRjfus4KjIV4N60/0A?=
 =?us-ascii?q?HJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L2?=
 =?us-ascii?q?81/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUj?=
 =?us-ascii?q?qg8qhrUgflhikEOTAn8G/YiMJwgqVUrxy8vxxywYzabY6IOPdwYq/SYdwUSn?=
 =?us-ascii?q?RaXstKSyxMAJmxY5cVAuYdI+pVqZT2qVsUrRu5AAmhHOThxSVShn/q3K061f?=
 =?us-ascii?q?kqHBzE3AwnBdIOs3DUrMjzNKgPTOu4y6zIwi7Bb/5NxTfy8onIchQ4rfGCR7?=
 =?us-ascii?q?5/bc3RyUw2Gg7Dk16ep4vlPzaP2eQMtWiW9+tgWvyzi24psQ1xpSKvxsgqh4?=
 =?us-ascii?q?LUhYwV0kjJ+TtlzIopONG1TVN3bNq4HJdMsiyXOZd6Tt8/T2xtpSo217gLtJ?=
 =?us-ascii?q?ulcCcW0Jgr2hzSZvKdf4WG4R/vTvidLSlkiH5/eb+zmhC/+lW6xOLmTMm7yl?=
 =?us-ascii?q?NKozJFktbSsnAN0ATe6s2dRft8+ketwzeP2B7P6uFKO0w0krDbK5E5zr4xkJ?=
 =?us-ascii?q?ocr1jDEzfolEnqkKOaa0Ap9vWs5uj7frnro5GRO5Nohg3jN6kih9GzDOE9Pw?=
 =?us-ascii?q?QQQ2eX4eG826fi/U39TrVKlPo2kqzBvZDcO8sbuqu5AwhI3Yo68Bm/CCqm0N?=
 =?us-ascii?q?IEknYZN1JIYxOHgJb1O1HAOvz4Cu2/g1u0nDdx2//GJqHhAonKLnXbirjuYa?=
 =?us-ascii?q?hy5FBHxQUvzNBf/I5bCrYbLP3vXU/xscTSDgUlPAys3+bnFNJ925sEVmKMGK?=
 =?us-ascii?q?+UK7/dsV6T5u0zJOmAfpMauDH4K/I9/f7hkWc5mUMBfamuxZYYcnS4Ee94LE?=
 =?us-ascii?q?WDfXrsjdABHHwWsQo/V+zllFqCXSRPaHa1WqI2/is7B56+DYffWoCth6SM0z?=
 =?us-ascii?q?2/Hp1SZmFGDEuBHmvpd4WfR/gMbzieLdNmkjwBTbKhUZMu1QmytA/mzLpqNv?=
 =?us-ascii?q?Db+igDupL/zth15vXTmgsp+DNoDsSdyH2CT2ZukmwUQD822bh1oVZhxVebza?=
 =?us-ascii?q?h4n/tYGMRJ6PNMTgg6MYTTwPB6C9D2QQ/OYtaJSE26TdWhGz0+UtUxw9oWaU?=
 =?us-ascii?q?ZnB9qilgzD3zatA7INjbOLH4I7/b7c33j2OsZy1m3L27Ugj1k9XsRPMneqib?=
 =?us-ascii?q?J49wjWH4TJiVmWl762daQA2y7A7H2MzGuOvE5FSgFwV6bFXXEEa0TKrNT5/V?=
 =?us-ascii?q?/NT7i0Bbs7NQtBzNaIKrFWZd3xkVVGWPDjNczFbG2tn2e/HxeIxqiSY4fxZ2?=
 =?us-ascii?q?od3T7dB1QDkwwJ4XmGMg0+DD+7o23CFDxuCU7vY0T0/OZisny7S0g0wBqUYE?=
 =?us-ascii?q?172Lq44QIahf2HS/wP2bIIojsuqzJxHFylxdLZF8KApxZ9fKVbed4y/FlG1W?=
 =?us-ascii?q?PdtwNgIJOgNLtviUIfcwRso0zu0A97BZlHkcgvtHkq1hZ9KbqE0FNdcDOVxY?=
 =?us-ascii?q?3/NabTKmbo/RCvcbXb1U3f0NaN5qgP7+40pEnkvAGsDkAi6Wlo08FJ03uA4Z?=
 =?us-ascii?q?XHFBcdUZLzUkkt9hh6oarXbTU854PPyXJsNrO4vSPF29IsHOEl0Aqvf89DMK?=
 =?us-ascii?q?OYEw//C9AVB8y0J+wkgVepcw4LPOFJ+aEoPsOmbOeJ2KmxMOl8mzKmiHxN4J?=
 =?us-ascii?q?ph3UKU6yp8VunI0o4bzPGZ2AuITS38jFGnss3shY9EZCoSEXa4yST+GIFRYa?=
 =?us-ascii?q?hyd54RCWiyO8232sl+h5n1VnFG6l6jAFIG2NOydBWOblz9xhFf1UMNrXO7ni?=
 =?us-ascii?q?u4yiR+kys1oaqHwCzO3+PieQIJOmFVQWltl0rsIZKqgNAAR0WncwkplAC56k?=
 =?us-ascii?q?b93aRUuKN/L2zLS0dSYyf2N31iUre3treabM5A8okosCVZUeShel2VVr/9ow?=
 =?us-ascii?q?AG3CPkBWdR2Dc7dzSysJXjgxN6kH6dLGp0rHfBdsFwyg3Q5NjdRf5UxTUJWj?=
 =?us-ascii?q?J1hiXWBlinI9ap+s+YmIvEsuC7T2ihTIFccTH3zYOcsyu2/WJqARy4n/C2gN?=
 =?us-ascii?q?LnCxQ60S7g2tZ2VCXItwrzYo7x26umNuJne1FiBEXg5MpiBoF+jowwiYkf2X?=
 =?us-ascii?q?gAnZqa52AHkXv3MdpFwq/xcHsNRSUXzN7S+gTqxEpjLneRzYLjSnqd2tdhZ8?=
 =?us-ascii?q?W9Ym4O2iI94N1KCKKO47xfgSt6vEG1oh7QYfhmgjgdzuEi52Idg+EMoAAt1D?=
 =?us-ascii?q?mSAqgOHUlEOizhjxaI4My6rKpNfmavcqa/2VFiktCgF7GNvgZcVGzldZclGC?=
 =?us-ascii?q?969t9/P07U0H3v9oHkf8HdbdAWthKKjhjAkfZaJ48qm/UWhCpnIn7yvXo/x+?=
 =?us-ascii?q?Enihxu2ImwvJKbJGV14KK5HhlYOyX3Z8MU/zHil6JekdqR34CrBZhuBjQLXI?=
 =?us-ascii?q?D0QvKvCj4dqfPnNwOWGj0mtnibAabfHROY6Ep+rHLADo6kOG+JJHkY1thtWB?=
 =?us-ascii?q?idJFdDjwATRjk1gpk5FgWyzsz7bEh5/iwR5kL/qhZUzuJnKQPwUn3EqQi0az?=
 =?us-ascii?q?c0U4SQLB1M4g5e4EfVNNSU7vhvECFA4p2hsAuNJ3SeZwtSEW4JW1KLB1P4M7?=
 =?us-ascii?q?ay5NnA6PSXBu2kI/TSZrWOrPRUV+2UypK3zotm4zGMO92KPnZ4E/071FBMUm?=
 =?us-ascii?q?t4G8vDgDgAVy0XlznRYM6cvhuz5ip3rsWn+vTxRA3v/ZePC6dVMdh3/hC5n7?=
 =?us-ascii?q?2MOPOXhCZjJjZVzY8DxX7TyLcD214ekT1hdz6oEb4Yry7CULrQmrNLDx4ccy?=
 =?us-ascii?q?5zMcRI77gm0QZQOM/bidL126Vkgf40EFdKSVvhltu1aswNJmG3LEnHC1qTNL?=
 =?us-ascii?q?SaOT3LxNn6Yaa8SbJKluVUqxmwtiibEkL4IjuDliLpWAyoMe1WkC6bOxlesp?=
 =?us-ascii?q?mnchlxEWjjUM7mahqjPd9yij02wqc7hnbNNW4ANjhxaF9CrryL7SxEhfVzAX?=
 =?us-ascii?q?BO7n1gLeOcgSaW8/HYKooKsftsGil0kuVa4Gk+y7RJ7CFLXvp1lTDOod5vuF?=
 =?us-ascii?q?Gpju6PxiB7XxpJrzZBnJiLsll6OaXF6plAXm7J/BcQ7WWKERsKo9plCsP0tq?=
 =?us-ascii?q?9My9jPj778KDBY/93I+sscAtDeKNibP3o5LRrpBDnUARMATT62KWHfh1Fdne?=
 =?us-ascii?q?qO+X2UtZg1tp/slIASRb9cUVw/DukaBVh9HNwePJd3WSspkbubjcEW+Hq+qh?=
 =?us-ascii?q?bRSd5GsZDGTfKdHfLvJCyFgrlDYhsC2an4IpgLNo3nx0xibUF3nJzFG0rRWd?=
 =?us-ascii?q?BNozZsYRM1oEVW7Hd+SXc/1F7iagOo+HUTD+K7ngYqigtiZuQg7C/s41QtKV?=
 =?us-ascii?q?rIvys/ilI8lsnkgTCKbDHxK728Up1RCyrxr0IxKI/0Qx5pbQ2umkxpLC/ER7?=
 =?us-ascii?q?Vfjrtkb29klQ7ctIBTFv5dVq1LfBgQyeuLaPUv1FRWsj+nylNf5evZFZtikx?=
 =?us-ascii?q?MncYa2r3JP3AJjbN81JbDOK6dS0ldQh7mOsTOv1uwr3AAeIEMN+nuIeCEUoE?=
 =?us-ascii?q?wIKqUmJy2w8+x08wyCniFMeG4KV/Uwuf9l6kI9O/+cwCLnybJMNkexN+mHJa?=
 =?us-ascii?q?ODp2fAjdKIQk831k4Qj0lE/aZ50cMnc0WOVkAi16eeFxUSNcXeLgFZddZd9H?=
 =?us-ascii?q?/WfSyWq+XC3Yp1P5mhFuDvVeKOrrwbgkClHAY3BYsB9dgOHpi30E7EKsfrNq?=
 =?us-ascii?q?IKyRIo5A7zPlWKEOxJeA6XkDcAu8y/1pF33ZRHJjEbH2p9Kj63663LqQ8rm/?=
 =?us-ascii?q?qMQNA2bm0GUYsDM3I8QNe6lDJBv3RcEDm31foUyBKF7z/zvCvQAz38b9t5a/?=
 =?us-ascii?q?qPeRxsCcq29ik486SslVHX9ZDeLXngNdt+ot/P9f8ap5GfBvNOV7lyqUfcm4?=
 =?us-ascii?q?xCSHysSGPADd+1J4PsZIkrd9D7FnG6UlmngTIvU8jxJMqtLrSPgQzwX4ZVvo?=
 =?us-ascii?q?ib3DQ/Nc+6EDETAAt/p+AY5K1gYg0PeYY0YRnttw4mLaywPB+Y0smyQ2aqMT?=
 =?us-ascii?q?ZWVOJQwv+1Z7NNyyosc/W6xWA8QZE71Om47UkNSIsWgRHZwPapf5NeXjTrGn?=
 =?us-ascii?q?xBZwXPojI0l3NhNuYv2ucw2g7HsVkcMj2QaONpaXdEsM07BV+IPXp2DW84FB?=
 =?us-ascii?q?ehi5He6Fusw6wK5Hka2MlLzqtEvWTw+JjFb3WpUa2vrJzT9C04cdkhpbY2N4?=
 =?us-ascii?q?H/J8yK567YhSHVGZzZswmZV3y8GuZfndQVOi9BXfRThUkkNNAI/41b5h0qS8?=
 =?us-ascii?q?08KrdTXbQqva2gcjF+DCQfnhMeAoWNwDkFjs+91qfU0BCKf8cMKhsB5bBLmM?=
 =?us-ascii?q?ccVWZcYCQEp6u+UYmew2qOSEAXKQYXqAoK7wUFwNwjNtv56ZbFGccfgwVdpO?=
 =?us-ascii?q?h5B3OSS8tE1HreD0yIiFzlQemglOr1gFIA0qe1gZESDQRkAA1Gx+8MyxV7YL?=
 =?us-ascii?q?oiMaQUt57HvniTdEbiuG++gOfzJVRNx4vTbVKrRJGQtGfgXHRPnB91WdoWlS?=
 =?us-ascii?q?qORclCzVYpO+4hpABmJo+lZEij/CN1w6hLQ4mocJGb4n09qkY5ZxaaFdQfLs?=
 =?us-ascii?q?Niq2zVCBFUP4uW/caAWfRSF0NZ5JDPl1ALvl9qNnyYz99mJtlJ83swW2p1rD?=
 =?us-ascii?q?uQpta0Q8BYi/RrBZ0BKcstn3bmBOZlNMr0wRx+nr301jrk/Sshukyx3jS5Fv?=
 =?us-ascii?q?2cTvlFukQEEQUoOWnMjkg0E64U9XzOoHTMqUwx3+pfHuqrjF5t5Q1gFItFHD?=
 =?us-ascii?q?dD2CPATTV5GXZhucNBA/nNVf1WH/VtYxS/ZDJgEO5221aD5UVVgm3nORF/tR?=
 =?us-ascii?q?BU+wSNTzUOfigni7LSvX4UkPiEBy4+RYtFTTszCkWkY1iioX5av0ZGW19pC7?=
 =?us-ascii?q?EQPuZooeoQ9oV/pc6eb0GgLx8Xf0ZhOzIK6/YCzkBss2qJenvnJg6XcPvOsR?=
 =?us-ascii?q?xeXNfLl5LyDZGbnU99qt3bjroC2LgeYkP8nAmUYo2Z85S/6YeOrmqIVbriLN?=
 =?us-ascii?q?abbHP+Shj12EP4lfIlFZ7M5y/JLE9BJoJnzWZxeZH6Ej2SYEZqBIM+YmdFXK?=
 =?us-ascii?q?RnYMlHpeYGN5M2ZvNQqudkUwicT1b0GIX18acVZl2GXznaJjWM/qukoIfL6b?=
 =?us-ascii?q?GOAeS1Z8GQyTDAWa0kdowv6DTnFe65tO0/5h+vh6w8ph4qFwSYYGiLrIHLIA?=
 =?us-ascii?q?wI+sf/bVSzurELQQPGJcZAtVH1wXF/V/snRSP01bYc061buFrBFflFhxuW0o?=
 =?us-ascii?q?xSopVt9YRl37c7592zIPXzL7FgvFdjE12oAVdQ+5sgGmV5TG1KMNQMIvXcdr?=
 =?us-ascii?q?hLqcH1t6XWG/5yinzd3+1CdZ76IVrckNK0EDCWRE5gnRwd7BcAJQudyfPXv6?=
 =?us-ascii?q?5vVYOdovPliGYs+ET7DhMC1OJJ5JyYv5GVrvTcdRrbwOthOMngE9/ogoUOmW?=
 =?us-ascii?q?+23M0oxbMTa3ZKPSGcStITXI0Bl0PN17kF4AspLvL/QOzLqNtYWF0Gxi7Gmb?=
 =?us-ascii?q?tUJnsoGPQqTb7Q4KEO+wVZ07P0BvsbYJt8oEKlDxeETbA/yXON2iusK3ldgj?=
 =?us-ascii?q?re3SDLHGi00gX4kTFYHSXHxMnbzXVyV7WSHB1vWw+0B3FAoDGpM2+K1ZLale?=
 =?us-ascii?q?dozmsJFTfOusuShXexYqtvLtfTPuPBLjMPmwtK1rkBXvy94ocmTIn1MJIQ6n?=
 =?us-ascii?q?Z4dvzE9yaxnjRcp7sSgYfD/tuc/qafDTyhlaqcs7KX2HVV0GI/pwQZ7datZa?=
 =?us-ascii?q?uUtfSXX/Sl0XoQRC5jugzHGiS4saHfs0tNZxzZ2UPPnskLONtewH80k0qg7+?=
 =?us-ascii?q?k4S9V1/wJbRc7bf/1XnTnoI3PvxEqHJdc+Vy2QyTxSS1T4DVx/FO0233/2t8?=
 =?us-ascii?q?/SvXbd51NuQZN/JAT8nRIiKYI+JAo27UQPhCoOFQ9YcReAELShHljoN6MBXE?=
 =?us-ascii?q?kHLxWKwLb8fb04jgV/wbKqsffadvc0R7EMOfBUkhOUkRBFF4gXv6wTTPM0e1?=
 =?us-ascii?q?JU+KPN4Am3I4nqQ/agkmA/bKfneM1R/MEHundn2T6RGkX/u69K9K1TyJmMcq?=
 =?us-ascii?q?gBYJ7Gu9164wJsozUObSdKxhN4ikHxXecZreHlqt/V1fjgouCjSKMqS6Ad8A?=
 =?us-ascii?q?UyDGllp5r9nF5lpsvYn+tRUYzaj43j/RsFeSbS4dSDgkEke7FWc9v5Je8ypS?=
 =?us-ascii?q?8MbyEFQhBGdcKbcfw9/zNgPH3I6lpOD9lNLdIUMczRmBxF30jgWbVd7M3eST?=
 =?us-ascii?q?r6Q894c8El6XayyShgq8NkC7S5uWfud8uHtwgfZqoR3n9nx7eg7KAPzPHfCT?=
 =?us-ascii?q?Ya+yyQbxxzhyKEwZ6QDfq19qOHycrfUBUNGStlNuUVbDeE5wGjQfK40ZvzVQ?=
 =?us-ascii?q?bBoMn+nJc5eAeaQWG3l6kemqdBDeAGjT/0lGs7dMi9l7eOvtyg5XEC/FtKDI?=
 =?us-ascii?q?N04VjPH7hZNZhgERX1isftQVJzTHi3aITfcRwgv/CTz+EH7rBlL0XJYokfM0?=
 =?us-ascii?q?Fhqfqy+T9PQwBpUrKzokeBULdbeo59UP2d5CMd+cd6JqQIJlTYuJH6smICtg?=
 =?us-ascii?q?UtGAFwDd145j1CKhuS2lYMHf+l6Phb0ExGDpZ4oREeQzroYTBntmKfB/8N1P?=
 =?us-ascii?q?DDUKRMq2fBFutQDyAKemt/W0/nhssoJOPvxKAd9DgW1iJl/KpzjmwgGkr64H?=
 =?us-ascii?q?Oy4ftTnmhxndPw/DQZ5y4fEL3BwXqTUQ0RlqxR3/4WUSiwuwT7PiVLbZOusu?=
 =?us-ascii?q?A6dYK+pM97uSV5O018Gk9OFeW4V3Op3vnOU9HJ7Y4a2EbK4pSGbKftf3JMbu?=
 =?us-ascii?q?tvlEm7HyolilaGzkdj+2VZEG3nsoNsYYy5PYx8nHiSFGPWdUgB7uZyiOWq7A?=
 =?us-ascii?q?9ZauwwZBshyWFn1I2GQCcKWcrDXm1zhQk/YmICe5VGu1ccEOEzjzCEs7MjnE?=
 =?us-ascii?q?lcaSrIEomj5ojbnNvZkXg7Q9Bww2vKp6qDzpo02Xxhktlw42aAonMXP+DfVs?=
 =?us-ascii?q?ZtBDD02OI9gaTmYO6xt+kcVIZ84LGoUftEM8S/9y2xwporEk6py7ICHkaoZe?=
 =?us-ascii?q?8OwrCINkXtAWacWOmNby2Nh2Njahart0D5dgVlM58S9h1ka7mQ3JUP8m+pGa?=
 =?us-ascii?q?l5TSiRu1LBmWUnNeVfdgQ8v5qhd0kBCuUQfOObY+Mpxa5bahNEYnnXEC9xE+?=
 =?us-ascii?q?Lzv0Sqmd0xPXh85EL2JO7q7wbtPcC6GxQYH8jdtJE7qpnYDiqRfGRtyhF/Jh?=
 =?us-ascii?q?w+7+DEC1E4rfNRab6UlNnUwdV2zeBDcO1ie351qpsYnYRt7pOR2cGBfETK1p?=
 =?us-ascii?q?jFItfRs6HJUc2a9FwjfyRhapRcZAr044sgOdtgA+/SEKdX+xMGCvpjGcFzBy?=
 =?us-ascii?q?LK7KhxaThLXEvRabCz25S4o+uKYt1VqmPYqFUqI3WEtg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8EtCQA3YMhbfQAZASCDgISAEQAsYxw?=
 =?us-ascii?q?BAQEfBAEBBQEBgUwCgS8lBSdpcAQzjGuNIoktjgmBcRYYCwkCg3iFRxkHATQ?=
 =?us-ascii?q?NDQEBAgEBAQEBAQEBAQECEAEBCxQITAyCNgUCAxgICS8cPgEBAQEBAScBAQE?=
 =?us-ascii?q?BAQEjAkQtAQIDAQEBNwYBAQQKHgwCAwECBgEBCjYICAMBIzAZBYMcgXQNAQI?=
 =?us-ascii?q?BAQqlIIIdgnYBAQWCPoRhAwWLTReBQT+BEYMSgxsBAYIuhQ2IZwSFWUCPNgm?=
 =?us-ascii?q?QfpAnjEeJfYElHjgogS5NIxU7gmyCJhd8AQuHU4VAbYECBSETh1uBdwEB?=
X-IPAS-Result: =?us-ascii?q?A8EtCQA3YMhbfQAZASCDgISAEQAsYxwBAQEfBAEBBQEBg?=
 =?us-ascii?q?UwCgS8lBSdpcAQzjGuNIoktjgmBcRYYCwkCg3iFRxkHATQNDQEBAgEBAQEBA?=
 =?us-ascii?q?QEBAQECEAEBCxQITAyCNgUCAxgICS8cPgEBAQEBAScBAQEBAQEjAkQtAQIDA?=
 =?us-ascii?q?QEBNwYBAQQKHgwCAwECBgEBCjYICAMBIzAZBYMcgXQNAQIBAQqlIIIdgnYBA?=
 =?us-ascii?q?QWCPoRhAwWLTReBQT+BEYMSgxsBAYIuhQ2IZwSFWUCPNgmQfpAnjEeJfYElH?=
 =?us-ascii?q?jgogS5NIxU7gmyCJhd8AQuHU4VAbYECBSETh1uBdwEB?=
X-IronPort-AV: E=Sophos;i="5.54,396,1534809600"; d="scan'208";a="117396438"
X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown
Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c])
 by alln-inbound-c.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 18 Oct 2018 10:30:48 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1])
 by ietfa.amsl.com (Postfix) with ESMTP id 40047130E9A;
 Thu, 18 Oct 2018 03:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
 t=1539858648; bh=Bngkvf5sw9lDJ4XxM9XMCpoXWHYXnf6MJlsVj8DY4sU=;
 h=Date:To:From:In-Reply-To:References:Subject:List-Id:
 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;
 b=gObNsC5pNYb4d7ncx7F6mx8lrbplIwrv2UeksfhL8xTRCiZamWL+bRQKVyLfqeHfz
 2QP6ek8qXvk8IaTXE23cCfC3l4NodnVzK2keXZRd53fGkGyk3RClWmeikiAIx2S43I
 RH6TV2RGuuMV2mlQK5/4s+72lpInIurwSOedWnHQ=
X-Mailbox-Line: From netmod-bounces@ietf.org  Thu Oct 18 03:30:46 2018
Received: from ietfa.amsl.com (localhost [IPv6:::1])
 by ietfa.amsl.com (Postfix) with ESMTP id 183C9130E4D;
 Thu, 18 Oct 2018 03:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
 t=1539858646; bh=Bngkvf5sw9lDJ4XxM9XMCpoXWHYXnf6MJlsVj8DY4sU=;
 h=Date:To:From:In-Reply-To:References:Subject:List-Id:
 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;
 b=tsDYJJDLQXd9euyrW6DS2Rfb+t9LErqGEAmUYT76C8MsgGW0tNjCAQFVjoV8l3uM8
 7EXNezSVRLBraH7gUheNYhScxPhCxfYS5coV2fTvH4fccvP7WOidMq2UlMuVVPxjNg
 ED+5JBWO3Bfqwytx2pPYrDrW5grSW152LXpHzSoU=
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 47F4F12D7F8
 for ; Thu, 18 Oct 2018 03:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HPWLS2y2chh9 for ;
 Thu, 18 Oct 2018 03:30:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45])
 by ietfa.amsl.com (Postfix) with ESMTP id 2DDF4130E4D
 for ; Thu, 18 Oct 2018 03:30:38 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61])
 by mail.tail-f.com (Postfix) with ESMTPSA id 208821AE033A
 for ; Thu, 18 Oct 2018 12:30:37 +0200 (CEST)
Date: Thu, 18 Oct 2018 12:30:36 +0200 (CEST)
Message-ID: <20181018.123036.731934458688841323.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181012.103727.731509761734796510.mbj@tail-f.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com>
 <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com>
 <20181012.103727.731509761734796510.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: netmod-bounces@ietf.org
Sender: netmod 
X-Outbound-SMTP-Client: 173.37.147.233, alln-inbound-c.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Return-Path: netmod-bounces@ietf.org
X-MS-Exchange-Organization-AuthSource: XCH-ALN-015.cisco.com
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 10
X-MS-Exchange-Organization-Network-Message-Id: 41d9e9e0-4385-4165-04d7-08d634e4c825
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
MIME-Version: 1.0

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--------------

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

    o  If the node is encoded in XML, the set of namespace
       declarations are those in scope on the
       'stream-xpath-filter' leaf element.

    o  If the node is encoded in JSON, the set of namespace
       declarations is the set of prefix and namespace pairs
       for all supported YANG modules, where the prefix is
       the YANG module name and the namespace is as defined
       by the "namespace" statement in the YANG module.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  
    /if:interfaces/if:interface/ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--------------

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

    o  The set of namespace
       declarations is the set of prefix and namespace pairs
       for all supported YANG modules, where the prefix is
       the YANG module name and the namespace is as defined
       by the "namespace" statement in the YANG module.

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
     expressions, such as get-config filter and nacm rules.

Example in XML:

  
    /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
    "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/martin

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


--------------4DD3D6B374730FEC6ED00AB0--


From nobody Tue Oct 23 03:16:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30111130E25 for ; Tue, 23 Oct 2018 03:16:35 -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 K5lF2eyo-Yly for ; Tue, 23 Oct 2018 03:16:33 -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 6F365127332 for ; Tue, 23 Oct 2018 03:16:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2437BF94; Tue, 23 Oct 2018 12:16:32 +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 SWibgtjUMF6g; Tue, 23 Oct 2018 12:16:31 +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, 23 Oct 2018 12:16:32 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F237D2003A; Tue, 23 Oct 2018 12:16:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id brJ8bj-8722I; Tue, 23 Oct 2018 12:16:31 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 9790820039; Tue, 23 Oct 2018 12:16:31 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 23 Oct 2018 12:16:31 +0200
Received: by anna.localdomain (Postfix, from userid 501) id E767830027BA33; Tue, 23 Oct 2018 12:16:30 +0200 (CEST)
Date: Tue, 23 Oct 2018 12:16:30 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: 
Message-ID: <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , netmod@ietf.org
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>  <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz> <20181023092800.mhu4kntxhjycsol4@anna.jacobs.jacobs-university.de> 
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/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 10:16:35 -0000

On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> Is this the same as Martin's alternative B proposed previously (attached)? 
> Or are you suggesting a different alternative?
>

Likely the same, but I admit that I do not understand Martin's
comment:

  Con: in XML, this leaf is treated differently from other XPath
       expressions, such as get-config filter and nacm rules.

If the context has ietf-interfaces pre-populated and you receive
if:ietf-interfaces with proper XML namespace bindings, one could add
the prefix if to the namespace declarations. One might even use (if
the server signals that it supports prepopulated namespaces) the
module name prefixed xpath expressions in say get-data.

The only downside really is the verbosity but I value compatibility
with xpath and no ambiguity or corner cases where things can clash
higher than compactness. And a client that is capable to parse xpath
and yang-library aware may do the expansion locally or if we work out
the details, a server may signal its ability to do the expansion as
well (not sure though that all this is effort well invested since N
different ways to send around xpath expressions increases costs on all
sides and is asking for interoperability problems. Hence, I rather go
with longish xpath expressions for the sake of simplicity and
interoperability.

/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 23 03:28:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B1130DFE for ; Tue, 23 Oct 2018 03:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 xd2FJdAn14qN for ; Tue, 23 Oct 2018 03:28:16 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 88C6F12F1AB for ; Tue, 23 Oct 2018 03:28:16 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 62351600D8; Tue, 23 Oct 2018 12:28:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540290494; bh=cudxfVF7T9rHXkFTOPUrmb5Gx4nYvV9uZfi57Jj6NV4=; h=From:To:Date; b=ZanwP33FhDrvbNY6Eh6eNoR/PNnn75tQxrLOYMKNokMM8Nop2XhV65ws4wdx3MwVm dJl9VNYY0Jl6U8xFSNgnC10UfHUaSVV7l+98higiMYvipQAWY7GdPPKUlMRnAJwf7M e4oX3l5ZqJOqGx3NikZ/ziu/PSbDjGZBvcBdAL5Y=
Message-ID: 
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Robert Wilton 
Cc: netmod@ietf.org
Date: Tue, 23 Oct 2018 12:28:13 +0200
In-Reply-To: <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de>
References: <20181022.145605.1533686864301630023.mbj@tail-f.com>   <20181023.084254.2257754077098127031.mbj@tail-f.com> <87d0s1azc8.fsf@nic.cz>  <8ef79f3002b77b8be59d667b656e776c80a80531.camel@nic.cz> <20181023092800.mhu4kntxhjycsol4@anna.jacobs.jacobs-university.de>  <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 10:28:19 -0000

On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> > Hi Juergen,
> > 
> > Is this the same as Martin's alternative B proposed previously (attached)? 
> > Or are you suggesting a different alternative?
> > 
> 
> Likely the same, but I admit that I do not understand Martin's
> comment:
> 
>   Con: in XML, this leaf is treated differently from other XPath
>        expressions, such as get-config filter and nacm rules.
> 
> If the context has ietf-interfaces pre-populated and you receive
> if:ietf-interfaces with proper XML namespace bindings, one could add
> the prefix if to the namespace declarations. One might even use (if
> the server signals that it supports prepopulated namespaces) the
> module name prefixed xpath expressions in say get-data.

This may be the best option: the "verbose" prefix/namespace bindings will be
available in all encodings, which doesn't prevent users of the XML encoding to
define additional ones.

I would suggest to extend the definition of the "xpath1.0" type with the
corresponding specification of the default XPath context.

Lada

> 
> The only downside really is the verbosity but I value compatibility
> with xpath and no ambiguity or corner cases where things can clash
> higher than compactness. And a client that is capable to parse xpath
> and yang-library aware may do the expansion locally or if we work out
> the details, a server may signal its ability to do the expansion as
> well (not sure though that all this is effort well invested since N
> different ways to send around xpath expressions increases costs on all
> sides and is asking for interoperability problems. Hence, I rather go
> with longish xpath expressions for the sake of simplicity and
> interoperability.
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 05:41:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF2130E6F; Tue, 23 Oct 2018 05:41:05 -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, 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 HJErJ1W1YiDE; Tue, 23 Oct 2018 05:41:02 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A21D0128CF3; Tue, 23 Oct 2018 05:41:02 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 258D0182113B; Tue, 23 Oct 2018 14:48:23 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BA6C21820051; Tue, 23 Oct 2018 14:48:20 +0200 (CEST)
From: Ladislav Lhotka 
To: Lou Berger , NetMod WG 
Cc: NetMod WG Chairs 
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Mail-Followup-To: Lou Berger , NetMod WG ,  NetMod WG Chairs 
Date: Tue, 23 Oct 2018 14:40:57 +0200
Message-ID: <874ldcbzty.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 12:41:06 -0000

Hi,

I support the adoption.

Comments:

1. My general feeling is that such technicalities should be handled by
   the RFC editor and/or tools rather than YANG module and RFC authors.

2. xml2rfc v3 introduced a new element, , that is intended
   for source code inclusion. This document should therefore cover this
   element as well (primarily?). One problem with it is that the xml2rfc
   tool automatically adds the  and  markers,
   which interferes with YANG convention specified in RFC 8407,
   sec. 3.2. I have already raised a question about this in the
   xml2rfc-dev mailing list.

Lada

Lou Berger  writes:

> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 06:24:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582F8130E43 for ; Tue, 23 Oct 2018 06:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 OikxUr5nHsZR for ; Tue, 23 Oct 2018 06:24:01 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 4E880130F0F for ; Tue, 23 Oct 2018 06:23:55 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id B1F4B60AD3 for ; Tue, 23 Oct 2018 15:23:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540301033; bh=Rt7bGGiiMTlGjnzu+2QUzlf8H8xPeDpFdGYKlPeNHes=; h=From:To:Date; b=xoCiWQ/Nlxgn+n22ZDl9pqogL6LEy6gv6A1UeYlOFJLBhefQcSkY6OtNXYrDK5Af+ IkuPXACtqZHp9r9oUdLj5DDu+NeInbaNQBQja6ctJ7CmnO9yNW+41pVXivAY6QopTO 5jG8/sijAosSTGo8yFmKH18AVbtYhzGx20B2Kzcc=
Message-ID: <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 23 Oct 2018 15:23:53 +0200
In-Reply-To: <874ldcbzty.fsf@nic.cz>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <874ldcbzty.fsf@nic.cz>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 13:24:03 -0000

On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I support the adoption.
> 
> Comments:
> 
> 1. My general feeling is that such technicalities should be handled by
>    the RFC editor and/or tools rather than YANG module and RFC authors.
> 
> 2. xml2rfc v3 introduced a new element, , that is intended
>    for source code inclusion. This document should therefore cover this
>    element as well (primarily?). One problem with it is that the xml2rfc
>    tool automatically adds the  and  markers,
>    which interferes with YANG convention specified in RFC 8407,
>    sec. 3.2. I have already raised a question about this in the
>    xml2rfc-dev mailing list.

Update: using the "name" attribute with  does the right thing.

    
    ...
    

results in

     file "ietf-foo@2016-03-20.yang"
    ...
    

Lada 

> 
> Lada
> 
> Lou Berger  writes:
> 
> > All,
> > 
> > This is start of a two week poll on making
> > draft-kwatsen-netmod-artwork-folding-08 a working group
> > document. Please send email to the list indicating "yes/support" or
> > "no/do not support".  If indicating no, please state your reservations
> > with the document.  If yes, please also feel free to provide comments
> > you'd like to see addressed once the document is a WG document.
> > 
> > The poll ends Oct 1.
> > 
> > Thanks,
> > 
> > Lou (and co-chairs)
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 06:42:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3433130F50 for ; Tue, 23 Oct 2018 06:42:51 -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, 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 ZNybLDozHCg9 for ; Tue, 23 Oct 2018 06:42:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 027DF130F8E for ; Tue, 23 Oct 2018 06:42:37 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 5949F1AE0187; Tue, 23 Oct 2018 15:42:36 +0200 (CEST)
Date: Tue, 23 Oct 2018 15:42:35 +0200 (CEST)
Message-Id: <20181023.154235.539454463558274229.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: j.schoenwaelder@jacobs-university.de, rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 13:42:58 -0000

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 12:16 +0200, Juergen Schoenwaelder wrote:
> > On Tue, Oct 23, 2018 at 10:39:22AM +0100, Robert Wilton wrote:
> > > Hi Juergen,
> > > 
> > > Is this the same as Martin's alternative B proposed previously (attached)? 
> > > Or are you suggesting a different alternative?
> > > 
> > 
> > Likely the same, but I admit that I do not understand Martin's
> > comment:
> > 
> >   Con: in XML, this leaf is treated differently from other XPath
> >        expressions, such as get-config filter and nacm rules.
> > 
> > If the context has ietf-interfaces pre-populated and you receive
> > if:ietf-interfaces with proper XML namespace bindings, one could add
> > the prefix if to the namespace declarations. One might even use (if
> > the server signals that it supports prepopulated namespaces) the
> > module name prefixed xpath expressions in say get-data.
> 
> This may be the best option: the "verbose" prefix/namespace bindings will be
> available in all encodings, which doesn't prevent users of the XML encoding to
> define additional ones.

Yes, and we can define a canonical format (with module names), and it
is backwards compatible.  The only problem is verbosity, but I think
that is unavoidable.

> I would suggest to extend the definition of the "xpath1.0" type with the
> corresponding specification of the default XPath context.

Yes, something for 6991bis.

Meanwhile, for SN, we can add this already there for stream-xpath-filter.


/martin



> 
> Lada
> 
> > 
> > The only downside really is the verbosity but I value compatibility
> > with xpath and no ambiguity or corner cases where things can clash
> > higher than compactness. And a client that is capable to parse xpath
> > and yang-library aware may do the expansion locally or if we work out
> > the details, a server may signal its ability to do the expansion as
> > well (not sure though that all this is effort well invested since N
> > different ways to send around xpath expressions increases costs on all
> > sides and is asking for interoperability problems. Hence, I rather go
> > with longish xpath expressions for the sake of simplicity and
> > interoperability.
> > 
> > /js
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 23 06:46:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC91130E43 for ; Tue, 23 Oct 2018 06:46:00 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 QGQlUWZgMbwy for ; Tue, 23 Oct 2018 06:45:58 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 A6DD5130E05 for ; Tue, 23 Oct 2018 06:45:57 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9NDjsBu029024; Tue, 23 Oct 2018 14:45:55 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 361FF2203A; Tue, 23 Oct 2018 14:45:55 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 2AEC22204A; Tue, 23 Oct 2018 14:45:55 +0100 (BST)
Received: from 950129200 (93.238.180.159.in-addr.arpa.celeste.fr [159.180.238.93] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9NDjnw6011256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2018 14:45:50 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Ladislav Lhotka'" , 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <874ldcbzty.fsf@nic.cz> <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz>
In-Reply-To: <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz>
Date: Tue, 23 Oct 2018 14:45:49 +0100
Message-ID: <075901d46ad6$b5e89050$21b9b0f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQFJ9dTTZRWTPaErQM7R2SR8msbsJwHliuuVAmUAYGemH2vX0A==
X-Originating-IP: 159.180.238.93
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24176.000
X-TM-AS-Result: No--21.750-10.0-31-10
X-imss-scan-details: No--21.750-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24176.000
X-TMASE-Result: 10--21.749900-10.000000
X-TMASE-MatchedRID: gjZGo2H/wj/xIbpQ8BhdbNxajlW+zwxCwLlnHU0okA2dI/DikZ1UPJ5I w5sIUwAGpOcctvmyXpIMo1U+ogv8V+/Wpw43SxoPgW5/KXM36b7AWTziWGaDPPgnJH5vm2+g7rP 0DPT/N1cIKceUaqtrLfr/wDm3k0pdOByiP8mqkZvM1jffIgQXhvDfYikgJILntXl9IxEPXOpEto xJECF47jZMBH4YYyYkN5PbzyayxNSl98O/igNkvqDH6drx3JPVwx0jRRxcQfMNmPMcsvd5Fv4ZA Usty2ENg2AJ83NyWTfo6D2NnoSDSPEaH+OhzKD5ww5lzZPqy6V579SS+Zr4D41Oeo4wEgnhlX++ QXsSDxB3I1qXcZvalO/7OzGFceIVpGc/XTagXZ4hqqcE0HbjQl+U6kGoEdO3FRv37Hu2zzyYZ/E djXR3OxBIrvkNJsHO5saoGwUzKRBD22D6nfxmiWZUc2jtcaSd6I7Cfs2GijV3pEVETu8p8ThdTI Dkpb54CIb9sC5y3aBicArG/2fGpU1+zyfzlN7y/sToY2qzpx7af1N18C+ZArDszp3K5gqDjoczm uoPCq2UTGVAhB5EbQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 13:46:01 -0000

Hi,

1. I think you miss the point. While example XML/JSON YANG is included in
drafts, and while the authors are allowed to produce those drafts as txt files,
or while the authors want to achieve pretty-to-read formatting, this work falls
into the scope of those authors.

2. Yes, the authors discussed the  element and agreed that it will
be in scope.

However, we are all sort of waiting for xml2rfc v3 and pending completion, we
want to move this forward for v2 that is in use today.

(More than) Happy to come back and revisit this issue when v3 is deployed.

Thanks,
Adrian

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> Sent: 23 October 2018 14:24
> To: netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > Hi,
> >
> > I support the adoption.
> >
> > Comments:
> >
> > 1. My general feeling is that such technicalities should be handled by
> >    the RFC editor and/or tools rather than YANG module and RFC authors.
> >
> > 2. xml2rfc v3 introduced a new element, , that is intended
> >    for source code inclusion. This document should therefore cover this
> >    element as well (primarily?). One problem with it is that the xml2rfc
> >    tool automatically adds the  and  markers,
> >    which interferes with YANG convention specified in RFC 8407,
> >    sec. 3.2. I have already raised a question about this in the
> >    xml2rfc-dev mailing list.
> 
> Update: using the "name" attribute with  does the right thing.
> 
>     
>     ...
>     
> 
> results in
> 
>      file "ietf-foo@2016-03-20.yang"
>     ...
>     
> 
> Lada
> 
> >
> > Lada
> >
> > Lou Berger  writes:
> >
> > > All,
> > >
> > > This is start of a two week poll on making
> > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > document. Please send email to the list indicating "yes/support" or
> > > "no/do not support".  If indicating no, please state your reservations
> > > with the document.  If yes, please also feel free to provide comments
> > > you'd like to see addressed once the document is a WG document.
> > >
> > > The poll ends Oct 1.
> > >
> > > Thanks,
> > >
> > > Lou (and co-chairs)
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 23 07:00:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4936130DCB for ; Tue, 23 Oct 2018 07:00:18 -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 ekdZ3uMWxNad for ; Tue, 23 Oct 2018 07:00:11 -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 B22FC123FFD for ; Tue, 23 Oct 2018 07:00:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1841FFA8; Tue, 23 Oct 2018 16:00:10 +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 dkfSsFyiZCkX; Tue, 23 Oct 2018 16:00:09 +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, 23 Oct 2018 16:00:10 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F5A42003F; Tue, 23 Oct 2018 16:00:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Is21-DO_qtTs; Tue, 23 Oct 2018 16:00:09 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5673D20039; Tue, 23 Oct 2018 16:00:09 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 23 Oct 2018 16:00:08 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 364BF30027C28B; Tue, 23 Oct 2018 16:00:08 +0200 (CEST)
Date: Tue, 23 Oct 2018 16:00:08 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , , 
Message-ID: <20181023140008.mmnjluk7cm2kcnq6@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, rwilton@cisco.com, netmod@ietf.org
References:  <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de>  <20181023.154235.539454463558274229.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181023.154235.539454463558274229.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 14:00:19 -0000

On Tue, Oct 23, 2018 at 03:42:35PM +0200, Martin Bjorklund wrote:

> > I would suggest to extend the definition of the "xpath1.0" type with the
> > corresponding specification of the default XPath context.
> 
> Yes, something for 6991bis.
> 
> Meanwhile, for SN, we can add this already there for stream-xpath-filter.

I am not sure whether a new type definition is needed or just some
clarification of the current xpath1.0 definition. Perhaps a new
definition plus deprecation of the xpath1.0 definition is the right
thing to do. I have added this to my list of possible changes to
RFC 6991.

/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 23 07:00:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3928B130DCB for ; Tue, 23 Oct 2018 07:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level: 
X-Spam-Status: No, score=-0.601 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_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=mg-soft.si
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 cw7VuYn1HP11 for ; Tue, 23 Oct 2018 07:00:33 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id BB42E123FFD for ; Tue, 23 Oct 2018 07:00:32 -0700 (PDT)
Received: from [10.0.3.146] (dhcp-146.mg-soft.si [10.0.3.146]) by galileo.mg-soft.si (Postfix) with ESMTP id 9CF82C41D7FA for ; Tue, 23 Oct 2018 16:00:31 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 9CF82C41D7FA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1540303231; bh=OhbOWKqw3KYUqauOvKpV3Jtf/zewAX4Mzeis+0bIMuk=; h=From:Subject:To:Date:From; b=NgSrqpIcL7z68GpOvxyyOspG3+5/mJ++B/2LEmY+FYwIHYhDkOI+Vgl2h/wH84TUS w5Jq1rE+zo3RwB7GNVq+j0QucA+8I9ymYf0iZ8tg4vBWTQhSwOa6nwXlLY0FMmf6h2 Uhcuxgtj3uwNFYkWaeROwpINgZ3kXuSMTYqJt8H6TwUDKYpjnZbLFG9trJkJLojcBQ P5yyv48rm4bnQbmFPvJ31dVG92OF3nVnk6scx/wmvxfQ02hHJs3HMHLBTPUIcrhHRd vvy1p/F6wc28LnNoFaZMR6a2m2mYk4uvmkWQ6KV6BR4hq7bb2NtSnymTCN7iRSynu1 YCBW1T2NYBN+g==
From: Jernej Tuljak 
To: NETMOD Working Group 
Message-ID: 
Date: Tue, 23 Oct 2018 16:00:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] "input"/"output" in tree diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 14:00:36 -0000

Hi,

am I reading RFC8340 correctly by assuming "input" and "output" nodes 
are not to be part of tree diagrams and that instead input/output 
parameters are now children to the "rpc" or "action" node, distinguished 
solely via -w/ro flags?

   rpcs:
     +---x get-schema
        +---w identifier! string
        +---w version?    string
        +---w format?     identityref
        +--ro data?

Only "input parameters" and "output parameters" are mentioned, which 
seems to suggest data node children of "input" and "output", but not 
themselves. It also says nothing about which flag they receive, if they 
are intended to appear.

Jernej


From nobody Tue Oct 23 07:12:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70364130EA3 for ; Tue, 23 Oct 2018 07:12:04 -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, 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 pDWnjqIj-EPf for ; Tue, 23 Oct 2018 07:12:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29AF1130EF7 for ; Tue, 23 Oct 2018 07:12:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 49E1D1AE0187; Tue, 23 Oct 2018 16:11:59 +0200 (CEST)
Date: Tue, 23 Oct 2018 16:11:58 +0200 (CEST)
Message-Id: <20181023.161158.1837797983440028086.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] "input"/"output" in tree diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 14:12:04 -0000

Hi,

Jernej Tuljak  wrote:
> Hi,
> =

> am I reading RFC8340 correctly by assuming "input" and "output" nodes=

> are not to be part of tree diagrams and that instead input/output
> parameters are now children to the "rpc" or "action" node,
> distinguished solely via -w/ro flags?

I hope not, or that was not the intention anyway.

> =A0 rpcs:
> =A0=A0=A0 +---x get-schema
> =A0=A0=A0=A0=A0=A0 +---w identifier! string
> =A0=A0=A0=A0=A0=A0 +---w version?=A0=A0=A0 string
> =A0=A0=A0=A0=A0=A0 +---w format?=A0=A0=A0=A0 identityref
> =A0=A0=A0=A0=A0=A0 +--ro data?

pyang outputs

    +---x get-schema
       +---w input
       |  +---w identifier    string
       |  +---w version?      string
       |  +---w format?       identityref
       +--ro output
          +--ro data?   


> Only "input parameters" and "output parameters" are mentioned, which
> seems to suggest data node children of "input" and "output", but not
> themselves. It also says nothing about which flag they receive, if
> they are intended to appear.

Yes I can see how this could be clarified.


/martin


From nobody Tue Oct 23 07:19:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11A130EA3 for ; Tue, 23 Oct 2018 07:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 y4GVaEnew4Bc for ; Tue, 23 Oct 2018 07:19:20 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 9E4A8130DD4 for ; Tue, 23 Oct 2018 07:19:19 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 72EFF60636; Tue, 23 Oct 2018 16:19:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540304357; bh=NmJoAnqSQUTdB1z4y3NfnzXwlpVWOm37cNv637lj1y4=; h=From:To:Date; b=Nqy3IY5HX5SoTMVkQvg7VvlobsDadkbMWoEuUZKUT4x4CNfxtvPRKmJ8Vv25blISj 6Kb7tT/rly/FvggrTh4RKupygN8Oz9Buy7DuuY3Uyfmgq4Pu/a8UrmxIeRMP64CfY8 n1ZDnF61vUj+1a2jYjZZsSuTnbesSC5tIfsRhS3M=
Message-ID: <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz>
From: Ladislav Lhotka 
To: adrian@olddog.co.uk, netmod@ietf.org
Date: Tue, 23 Oct 2018 16:19:17 +0200
In-Reply-To: <075901d46ad6$b5e89050$21b9b0f0$@olddog.co.uk>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <874ldcbzty.fsf@nic.cz> <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz> <075901d46ad6$b5e89050$21b9b0f0$@olddog.co.uk>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 14:19:23 -0000

On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> Hi,
> 
> 1. I think you miss the point. While example XML/JSON YANG is included in
> drafts, and while the authors are allowed to produce those drafts as txt
> files,
> or while the authors want to achieve pretty-to-read formatting, this work
> falls
> into the scope of those authors.

The folding of long lines should be done as the very last (automatic) step
before the document gets published. Doing it earlier means that the source code
in this folded form can be (accidentally) further edited, which can lead to
inconsistencies.

As long as the document is being moved around and edited, it would be better to
keep the source code untouched.

Lada

> 
> 2. Yes, the authors discussed the  element and agreed that it will
> be in scope.
> 
> However, we are all sort of waiting for xml2rfc v3 and pending completion, we
> want to move this forward for v2 that is in use today.
> 
> (More than) Happy to come back and revisit this issue when v3 is deployed.
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > Sent: 23 October 2018 14:24
> > To: netmod@ietf.org
> > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> > 08
> > 
> > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > Hi,
> > > 
> > > I support the adoption.
> > > 
> > > Comments:
> > > 
> > > 1. My general feeling is that such technicalities should be handled by
> > >    the RFC editor and/or tools rather than YANG module and RFC authors.
> > > 
> > > 2. xml2rfc v3 introduced a new element, , that is intended
> > >    for source code inclusion. This document should therefore cover this
> > >    element as well (primarily?). One problem with it is that the xml2rfc
> > >    tool automatically adds the  and  markers,
> > >    which interferes with YANG convention specified in RFC 8407,
> > >    sec. 3.2. I have already raised a question about this in the
> > >    xml2rfc-dev mailing list.
> > 
> > Update: using the "name" attribute with  does the right thing.
> > 
> >     
> >     ...
> >     
> > 
> > results in
> > 
> >      file "ietf-foo@2016-03-20.yang"
> >     ...
> >     
> > 
> > Lada
> > 
> > > Lada
> > > 
> > > Lou Berger  writes:
> > > 
> > > > All,
> > > > 
> > > > This is start of a two week poll on making
> > > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > > document. Please send email to the list indicating "yes/support" or
> > > > "no/do not support".  If indicating no, please state your reservations
> > > > with the document.  If yes, please also feel free to provide comments
> > > > you'd like to see addressed once the document is a WG document.
> > > > 
> > > > The poll ends Oct 1.
> > > > 
> > > > Thanks,
> > > > 
> > > > Lou (and co-chairs)
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 07:27:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B086812D7F8 for ; Tue, 23 Oct 2018 07:27:51 -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, 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 TBABr9AI_MWC for ; Tue, 23 Oct 2018 07:27:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 672D912D4E8 for ; Tue, 23 Oct 2018 07:27:49 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E76E1AE0187; Tue, 23 Oct 2018 16:27:48 +0200 (CEST)
Date: Tue, 23 Oct 2018 16:27:48 +0200 (CEST)
Message-Id: <20181023.162748.209178731500337122.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: adrian@olddog.co.uk, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz>
References: <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz> <075901d46ad6$b5e89050$21b9b0f0$@olddog.co.uk> <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 14:27:52 -0000

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > Hi,
> > 
> > 1. I think you miss the point. While example XML/JSON YANG is included in
> > drafts, and while the authors are allowed to produce those drafts as txt
> > files,
> > or while the authors want to achieve pretty-to-read formatting, this work
> > falls
> > into the scope of those authors.
> 
> The folding of long lines should be done as the very last (automatic) step
> before the document gets published. Doing it earlier means that the source code
> in this folded form can be (accidentally) further edited, which can lead to
> inconsistencies.

I will use folding e.g. for instance document examples in XML and
JSON.

My plan is to keep the example files with manually added breaks in my
repo, and as part of validation run a script that unfolds the
examples, and then validate the result.  The reason for this is that I
think readbility of the examples is important.


/martin



> 
> As long as the document is being moved around and edited, it would be better to
> keep the source code untouched.
> 
> Lada
> 
> > 
> > 2. Yes, the authors discussed the  element and agreed that it will
> > be in scope.
> > 
> > However, we are all sort of waiting for xml2rfc v3 and pending completion, we
> > want to move this forward for v2 that is in use today.
> > 
> > (More than) Happy to come back and revisit this issue when v3 is deployed.
> > 
> > Thanks,
> > Adrian
> > 
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
> > > Sent: 23 October 2018 14:24
> > > To: netmod@ietf.org
> > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> > > 08
> > > 
> > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > Hi,
> > > > 
> > > > I support the adoption.
> > > > 
> > > > Comments:
> > > > 
> > > > 1. My general feeling is that such technicalities should be handled by
> > > >    the RFC editor and/or tools rather than YANG module and RFC authors.
> > > > 
> > > > 2. xml2rfc v3 introduced a new element, , that is intended
> > > >    for source code inclusion. This document should therefore cover this
> > > >    element as well (primarily?). One problem with it is that the xml2rfc
> > > >    tool automatically adds the  and  markers,
> > > >    which interferes with YANG convention specified in RFC 8407,
> > > >    sec. 3.2. I have already raised a question about this in the
> > > >    xml2rfc-dev mailing list.
> > > 
> > > Update: using the "name" attribute with  does the right thing.
> > > 
> > >     
> > >     ...
> > >     
> > > 
> > > results in
> > > 
> > >      file "ietf-foo@2016-03-20.yang"
> > >     ...
> > >     
> > > 
> > > Lada
> > > 
> > > > Lada
> > > > 
> > > > Lou Berger  writes:
> > > > 
> > > > > All,
> > > > > 
> > > > > This is start of a two week poll on making
> > > > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > > > document. Please send email to the list indicating "yes/support" or
> > > > > "no/do not support".  If indicating no, please state your reservations
> > > > > with the document.  If yes, please also feel free to provide comments
> > > > > you'd like to see addressed once the document is a WG document.
> > > > > 
> > > > > The poll ends Oct 1.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Lou (and co-chairs)
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 23 08:51:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D091286E7 for ; Tue, 23 Oct 2018 08:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 o2lpIemzgxfC for ; Tue, 23 Oct 2018 08:51:17 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 08B05124408 for ; Tue, 23 Oct 2018 08:51:17 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 4EF6362AC4; Tue, 23 Oct 2018 17:51:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1540309875; bh=jmrL0X8G4VbNWm2Z1gur99DL8ILhZVRCRmNJZb3MB6A=; h=From:To:Date; b=qnLw7jJfFZedJ4ljCySLErlbo0jfArdh/U3AReyw47XcwktXjZGT35tYv070A7G26 ZZWQU7pK9MBPBU21W9+vtNJLEoVLYE3F5fLzkOjv00zRWELScePIklRUL8rJiaiG3L FO7cgSV4NgiCQI3E3N1lqlihR4O6ItJMin+TLFcY=
Message-ID: <27cbd2fe3dd114e981fce2abb1723c5115550142.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: adrian@olddog.co.uk, netmod@ietf.org
Date: Tue, 23 Oct 2018 17:51:15 +0200
In-Reply-To: <20181023.162748.209178731500337122.mbj@tail-f.com>
References: <3a3714170c5cf1828203f5109d8791f6fed4478e.camel@nic.cz> <075901d46ad6$b5e89050$21b9b0f0$@olddog.co.uk> <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz> <20181023.162748.209178731500337122.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 15:51:20 -0000

On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > Hi,
> > > 
> > > 1. I think you miss the point. While example XML/JSON YANG is included in
> > > drafts, and while the authors are allowed to produce those drafts as txt
> > > files,
> > > or while the authors want to achieve pretty-to-read formatting, this work
> > > falls
> > > into the scope of those authors.
> > 
> > The folding of long lines should be done as the very last (automatic) step
> > before the document gets published. Doing it earlier means that the source
> code
> > in this folded form can be (accidentally) further edited, which can lead to
> > inconsistencies.
> 
> I will use folding e.g. for instance document examples in XML and
> JSON.
> 
> My plan is to keep the example files with manually added breaks in my
> repo, and as part of validation run a script that unfolds the
> examples, and then validate the result.  The reason for this is that I
> think readbility of the examples is important.

This seems backwards to me. If you need to edit such an example, you may have to
remove the backslashes, reformat and insert them again.

If it's not possible to fold lines according to the syntax of a given language,
I'd prefer to keep the original lines as long as possible and rely on an
automatic procedure just before the final document is rolled out. 

Lada  

> 
> 
> /martin
> 
> 
> 
> > 
> > As long as the document is being moved around and edited, it would be better
> to
> > keep the source code untouched.
> > 
> > Lada
> > 
> > > 
> > > 2. Yes, the authors discussed the  element and agreed that it
> will
> > > be in scope.
> > > 
> > > However, we are all sort of waiting for xml2rfc v3 and pending completion,
> we
> > > want to move this forward for v2 that is in use today.
> > > 
> > > (More than) Happy to come back and revisit this issue when v3 is deployed.
> > > 
> > > Thanks,
> > > Adrian
> > > 
> > > > -----Original Message-----
> > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> Lhotka
> > > > Sent: 23 October 2018 14:24
> > > > To: netmod@ietf.org
> > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-
> folding-
> > > > 08
> > > > 
> > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > Hi,
> > > > > 
> > > > > I support the adoption.
> > > > > 
> > > > > Comments:
> > > > > 
> > > > > 1. My general feeling is that such technicalities should be handled by
> > > > >    the RFC editor and/or tools rather than YANG module and RFC
> authors.
> > > > > 
> > > > > 2. xml2rfc v3 introduced a new element, , that is intended
> > > > >    for source code inclusion. This document should therefore cover
> this
> > > > >    element as well (primarily?). One problem with it is that the
> xml2rfc
> > > > >    tool automatically adds the  and  markers,
> > > > >    which interferes with YANG convention specified in RFC 8407,
> > > > >    sec. 3.2. I have already raised a question about this in the
> > > > >    xml2rfc-dev mailing list.
> > > > 
> > > > Update: using the "name" attribute with  does the right
> thing.
> > > > 
> > > >     
> > > >     ...
> > > >     
> > > > 
> > > > results in
> > > > 
> > > >      file "ietf-foo@2016-03-20.yang"
> > > >     ...
> > > >     
> > > > 
> > > > Lada
> > > > 
> > > > > Lada
> > > > > 
> > > > > Lou Berger  writes:
> > > > > 
> > > > > > All,
> > > > > > 
> > > > > > This is start of a two week poll on making
> > > > > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > > > > document. Please send email to the list indicating "yes/support" or
> > > > > > "no/do not support".  If indicating no, please state your
> reservations
> > > > > > with the document.  If yes, please also feel free to provide
> comments
> > > > > > you'd like to see addressed once the document is a WG document.
> > > > > > 
> > > > > > The poll ends Oct 1.
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Lou (and co-chairs)
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Oct 23 09:03:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B733130F0F for ; Tue, 23 Oct 2018 09:03:38 -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, 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 k4FqrnVMxAOK for ; Tue, 23 Oct 2018 09:03:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E613E130F03 for ; Tue, 23 Oct 2018 09:03:35 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C32861AE0187; Tue, 23 Oct 2018 18:03:34 +0200 (CEST)
Date: Tue, 23 Oct 2018 18:03:34 +0200 (CEST)
Message-Id: <20181023.180334.1196557244986533615.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: adrian@olddog.co.uk, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <27cbd2fe3dd114e981fce2abb1723c5115550142.camel@nic.cz>
References: <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz> <20181023.162748.209178731500337122.mbj@tail-f.com> <27cbd2fe3dd114e981fce2abb1723c5115550142.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 16:03:38 -0000

Ladislav Lhotka  wrote:
> On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > Hi,
> > > > 
> > > > 1. I think you miss the point. While example XML/JSON YANG is included in
> > > > drafts, and while the authors are allowed to produce those drafts as txt
> > > > files,
> > > > or while the authors want to achieve pretty-to-read formatting, this work
> > > > falls
> > > > into the scope of those authors.
> > > 
> > > The folding of long lines should be done as the very last (automatic) step
> > > before the document gets published. Doing it earlier means that the source
> > code
> > > in this folded form can be (accidentally) further edited, which can lead to
> > > inconsistencies.
> > 
> > I will use folding e.g. for instance document examples in XML and
> > JSON.
> > 
> > My plan is to keep the example files with manually added breaks in my
> > repo, and as part of validation run a script that unfolds the
> > examples, and then validate the result.  The reason for this is that I
> > think readbility of the examples is important.
> 
> This seems backwards to me. If you need to edit such an example, you may have to
> remove the backslashes, reformat and insert them again.
> 
> If it's not possible to fold lines according to the syntax of a given language,
> I'd prefer to keep the original lines as long as possible and rely on an
> automatic procedure just before the final document is rolled out. 

Fortunately, the draft allows us both to work the way we prefer.


/martin


> 
> Lada  
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > As long as the document is being moved around and edited, it would be better
> > to
> > > keep the source code untouched.
> > > 
> > > Lada
> > > 
> > > > 
> > > > 2. Yes, the authors discussed the  element and agreed that it
> > will
> > > > be in scope.
> > > > 
> > > > However, we are all sort of waiting for xml2rfc v3 and pending completion,
> > we
> > > > want to move this forward for v2 that is in use today.
> > > > 
> > > > (More than) Happy to come back and revisit this issue when v3 is deployed.
> > > > 
> > > > Thanks,
> > > > Adrian
> > > > 
> > > > > -----Original Message-----
> > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> > Lhotka
> > > > > Sent: 23 October 2018 14:24
> > > > > To: netmod@ietf.org
> > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-
> > folding-
> > > > > 08
> > > > > 
> > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I support the adoption.
> > > > > > 
> > > > > > Comments:
> > > > > > 
> > > > > > 1. My general feeling is that such technicalities should be handled by
> > > > > >    the RFC editor and/or tools rather than YANG module and RFC
> > authors.
> > > > > > 
> > > > > > 2. xml2rfc v3 introduced a new element, , that is intended
> > > > > >    for source code inclusion. This document should therefore cover
> > this
> > > > > >    element as well (primarily?). One problem with it is that the
> > xml2rfc
> > > > > >    tool automatically adds the  and  markers,
> > > > > >    which interferes with YANG convention specified in RFC 8407,
> > > > > >    sec. 3.2. I have already raised a question about this in the
> > > > > >    xml2rfc-dev mailing list.
> > > > > 
> > > > > Update: using the "name" attribute with  does the right
> > thing.
> > > > > 
> > > > >     
> > > > >     ...
> > > > >     
> > > > > 
> > > > > results in
> > > > > 
> > > > >      file "ietf-foo@2016-03-20.yang"
> > > > >     ...
> > > > >     
> > > > > 
> > > > > Lada
> > > > > 
> > > > > > Lada
> > > > > > 
> > > > > > Lou Berger  writes:
> > > > > > 
> > > > > > > All,
> > > > > > > 
> > > > > > > This is start of a two week poll on making
> > > > > > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > > > > > document. Please send email to the list indicating "yes/support" or
> > > > > > > "no/do not support".  If indicating no, please state your
> > reservations
> > > > > > > with the document.  If yes, please also feel free to provide
> > comments
> > > > > > > you'd like to see addressed once the document is a WG document.
> > > > > > > 
> > > > > > > The poll ends Oct 1.
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 
> > > > > > > Lou (and co-chairs)
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Tue Oct 23 09:15:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11298124C04 for ; Tue, 23 Oct 2018 09:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 1cdVIC9CSSdI for ; Tue, 23 Oct 2018 09:15:07 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::71f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D88124408 for ; Tue, 23 Oct 2018 09:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jJVwYL80siQsIDnR1EXA4Ie7jfrPXuow8xiYCf35An4=; b=iA30I0TMMRXnm6osrKtRARR46s6q/Se9KXRGUj+1hcmenqW2rzAYL6QoxNzaICf7KTxX9VOO2O21kmhNS5WTPu+AWgQqtJ+M5iLC34G215o6as+Rib6z7VWKrzANJ8f4JT4MkB2ygLXpOTBrbRY4igsJD9DaCuP7v1Y9TvDva50=
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com (10.161.107.154) by VI1PR07MB3422.eurprd07.prod.outlook.com (10.175.244.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.13; Tue, 23 Oct 2018 16:15:04 +0000
Received: from VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db]) by VI1PR07MB0831.eurprd07.prod.outlook.com ([fe80::8d94:d86b:1a6e:b5db%12]) with mapi id 15.20.1250.028; Tue, 23 Oct 2018 16:15:04 +0000
From: tom petch 
To: "netmod@ietf.org" 
Thread-Topic: IANA Considerations
Thread-Index: AQHUauuOqDJX+hZs/U6t1hrw/uyjRA==
Date: Tue, 23 Oct 2018 16:15:04 +0000
Message-ID: <02f701d46aeb$65533e00$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0005.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::17) To VI1PR07MB0831.eurprd07.prod.outlook.com (2a01:111:e400:508e::26)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [81.131.229.47]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3422; 6:3qb7itpiILeH9gmUI2Da0OWm0jqwgOzbxdHMmYrBgEsaxZK2he8oYux6KdTpxn5fIELNaopkizUCQc8vcboqiJ2otCtl5HipNdQyrKRQ33WKAe1tnRtebXdTBwhrdnPUolfzqIBu5TPvlumSQ4KUAGtCh9lUtmbY8Rt/7cpyM/7XOp82RmYYfqoF/qQncR5SUq8dSbwAFntf7ajCS53e2bnQ6sxWt+qV2DhnWjGvsGEp6SF8KB+Ipx1elXqg1JLQYMx2081nOwFTMtVmj+3E+1sVElpbeCdXXEszM38T0j1qHvx1lskqQRe5UFO6QnkdgBaNYHO0YVzHkK7UNcxn9R19fyugaz4+Mw17Bq8ewRK1smbO1yllktGKkwXyrJjIHeQf/aaA0XPCoJAPSoJJ/xo5c55JAPKF4T+T2QnhvT++z4+RGP0pHl5BSOvr54krtShfH42cm95+v5GH6A961Q==; 5:M1Bm+j1mTKTSmFCLINdBdPUVqHKOl7RYU1udMxd/MneLRHe0FFUM5SeD/Y2qihnuUyvDLG52y73/3hUC2yaRb9FtsNp54z/9MebMUxX0ws8BAridFu+pyjxvEPAv3pWkAV+7mnroyKzrtoCr7ixBT93j/WYlxge5vox0YJiroD8=; 7:LF/uwfHBePBgGLnXvM+0yXeKTo7oe9iQ4uCnujF3AkV8+5VkcgEkllhmk1Hr43x2THf+1drvVvUn0kw0DpqbIKaMyxwffsKwgJqQIFnzxcXiUvRc6zEz4e21sys7/kxxHxJDCuIoesxAB9MMBcDKGQ==
x-ms-office365-filtering-correlation-id: 9b60b747-5074-42e1-ffd8-08d63902b0c7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB3422; 
x-ms-traffictypediagnostic: VI1PR07MB3422:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB3422; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3422; 
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(136003)(346002)(396003)(199004)(189003)(5640700003)(2501003)(81166006)(25786009)(2900100001)(221733001)(8676002)(14454004)(1730700003)(99286004)(106356001)(3480700004)(8936002)(102836004)(476003)(2351001)(316002)(81156014)(1556002)(386003)(6116002)(26005)(86362001)(6346003)(33896004)(84392002)(305945005)(14496001)(7736002)(7116003)(478600001)(68736007)(6916009)(97736004)(52116002)(6506007)(3846002)(105586002)(2906002)(71190400001)(186003)(5660300001)(6436002)(53936002)(486006)(6486002)(256004)(44736005)(71200400001)(66066001)(86152003)(9686003)(6512007)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3422; H:VI1PR07MB0831.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-microsoft-antispam-message-info: E2g02K6ADQgsFFaExSFmu5wucY8F+c+s2hZux812rOuuRKzc9LW43sU98oB3A2Xj2NcqcdVmrtxx9aRoEtNyMz6TilntefoZZ983VI9I5sDkzGgRQkxKmMlS83NeTYNYsm11bi0MuenzeuepffDONFbx58RzjZtaoczdCTsaFCp6UUC9m4AXLi7fGmPvVLFBPwrG6HP5MsM/eDhGuGMTK5eY6l0erz8/awHI+lRWqeCFkMt8UodDui5Fom53xrhHjtFhPxGwltx939nOCGnmorGPcw5CkuCPZGa75+To9c/Y6FSYlfMXfUNN25NFZYNeBvqiPGoyV3ziFBomTvpDbmYeJqwHCiVCLFNmn7tDEjc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8496FB3E32EF8B439F2A6ACDDE9D2961@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b60b747-5074-42e1-ffd8-08d63902b0c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 16:15:04.1041 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3422
Archived-At: 
Subject: [netmod] IANA Considerations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 16:15:09 -0000

draft-ietf-ccamp-mw-yang-10
has, in IANA Considerations,
      Name: ietf-microwave-radio-link
      Maintained by IANA?: N
      Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
      Prefix: mrl
      Reference: RFC XXXX
which adds a line I have not seen before, not mentioned - naturally - in
RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.

It seems like 'A Good Thing' but where has it come from, what is the
basis for it and is there a reference for it?  It could be construed as
a breach of RFC6020.

Tom Petch


From nobody Tue Oct 23 09:57:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B471277D2 for ; Tue, 23 Oct 2018 09:57:34 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 XK_RDVq3ALfB for ; Tue, 23 Oct 2018 09:57:32 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 DC651124C04 for ; Tue, 23 Oct 2018 09:57:31 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9NGvTiJ006174; Tue, 23 Oct 2018 17:57:29 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1955D2203C; Tue, 23 Oct 2018 17:57:29 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 0401B2203A; Tue, 23 Oct 2018 17:57:29 +0100 (BST)
Received: from 950129200 (93.238.180.159.in-addr.arpa.celeste.fr [159.180.238.93] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w9NGvR0a020573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2018 17:57:28 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Martin Bjorklund'" , 
Cc: 
References: <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz>	<20181023.162748.209178731500337122.mbj@tail-f.com>	<27cbd2fe3dd114e981fce2abb1723c5115550142.camel@nic.cz> <20181023.180334.1196557244986533615.mbj@tail-f.com>
In-Reply-To: <20181023.180334.1196557244986533615.mbj@tail-f.com>
Date: Tue, 23 Oct 2018 17:57:27 +0100
Message-ID: <07d201d46af1$7b3e73a0$71bb5ae0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQHFLrQQRZs9sV6HgZ8otnhosGF7lQCluF6MAUfbku4BrHbt8aUuszFg
X-Originating-IP: 159.180.238.93
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24176.001
X-TM-AS-Result: No--29.014-10.0-31-10
X-imss-scan-details: No--29.014-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24176.001
X-TMASE-Result: 10--29.014000-10.000000
X-TMASE-MatchedRID: gTucSmrmRMPxIbpQ8BhdbKfXIl6Cf6VrGSqdEmeD/nXb6Y+fnTZUL6oK U9R7erGEXSjU4/YC0T3xTwx4UJIMcsSsicU7ThvNlVHM/F6YkvTp8lxWp2elloehsWfaDKtkL3P LMlQSdmQHG4nQZY11VsD0U79tKMTN2krzNcCKFT60sO72q2op4V4UPVYgPLUua0TOsL14A2nn0L pDrddNEq4FOedMHR6MEp+NNlyzaQoBpTIFsSiyLWivjLE8DPtZGFwEGDRX5uwQRik6+J7XSbnnq KtFdBFdsDgwFBBNhzyVWH1eq874X48iv1am7RhcV6iWWmDPLECz5LIh2+IOfB0bKcI3i70lr0pc boGSwNfIU5qoQRkBH3jPHbHXDRMc/0j7XSCRjJCM29hkek7XdyseSAhqf1rRqPm/sjj9KBiy1Vq a24VemeoitjXqQyUzeVO+e3Uxwfrw2L2r2UxibLttJwl7IC+WGK57kZ/2makPVb41Wr4BJ8it/e CfvDyi+D4/c8pyvfr5fIu2trOcXXyvvbPeypnpIaqnBNB240JflOpBqBHTtxUb9+x7ts88mGfxH Y10dzsQSK75DSbBzubGqBsFMykQQ9tg+p38ZolmVHNo7XGkneiOwn7Nhoo1d6RFRE7vKfE4XUyA 5KW+eAiG/bAuct2gYnAKxv9nxqVNfs8n85Te8v7E6GNqs6ce/W9MYGK5mu1TZDOrzlZ+cHQdJ7X fU86e4kYXbobxJbLnIzRzWS2P0w==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 16:57:35 -0000

Nicely said, Martin.
The intention is that if, like Ladislav, you like to work in some long-line
format, then it works as documented and the tools can wrap.
If, like me, and maybe like Martin, you think pretty formatting is something
that improves readability, the draft also lets you do that.

A

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 23 October 2018 17:04
> To: lhotka@nic.cz
> Cc: adrian@olddog.co.uk; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > > Hi,
> > > > >
> > > > > 1. I think you miss the point. While example XML/JSON YANG is included
> in
> > > > > drafts, and while the authors are allowed to produce those drafts as
txt
> > > > > files,
> > > > > or while the authors want to achieve pretty-to-read formatting, this
work
> > > > > falls
> > > > > into the scope of those authors.
> > > >
> > > > The folding of long lines should be done as the very last (automatic)
step
> > > > before the document gets published. Doing it earlier means that the
source
> > > code
> > > > in this folded form can be (accidentally) further edited, which can lead
to
> > > > inconsistencies.
> > >
> > > I will use folding e.g. for instance document examples in XML and
> > > JSON.
> > >
> > > My plan is to keep the example files with manually added breaks in my
> > > repo, and as part of validation run a script that unfolds the
> > > examples, and then validate the result.  The reason for this is that I
> > > think readbility of the examples is important.
> >
> > This seems backwards to me. If you need to edit such an example, you may
> have to
> > remove the backslashes, reformat and insert them again.
> >
> > If it's not possible to fold lines according to the syntax of a given
language,
> > I'd prefer to keep the original lines as long as possible and rely on an
> > automatic procedure just before the final document is rolled out.
> 
> Fortunately, the draft allows us both to work the way we prefer.
> 
> 
> /martin
> 
> 
> >
> > Lada
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > As long as the document is being moved around and edited, it would be
> better
> > > to
> > > > keep the source code untouched.
> > > >
> > > > Lada
> > > >
> > > > >
> > > > > 2. Yes, the authors discussed the  element and agreed that
> it
> > > will
> > > > > be in scope.
> > > > >
> > > > > However, we are all sort of waiting for xml2rfc v3 and pending
completion,
> > > we
> > > > > want to move this forward for v2 that is in use today.
> > > > >
> > > > > (More than) Happy to come back and revisit this issue when v3 is
> deployed.
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> > > Lhotka
> > > > > > Sent: 23 October 2018 14:24
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-
> artwork-
> > > folding-
> > > > > > 08
> > > > > >
> > > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I support the adoption.
> > > > > > >
> > > > > > > Comments:
> > > > > > >
> > > > > > > 1. My general feeling is that such technicalities should be
handled by
> > > > > > >    the RFC editor and/or tools rather than YANG module and RFC
> > > authors.
> > > > > > >
> > > > > > > 2. xml2rfc v3 introduced a new element, , that is
> intended
> > > > > > >    for source code inclusion. This document should therefore cover
> > > this
> > > > > > >    element as well (primarily?). One problem with it is that the
> > > xml2rfc
> > > > > > >    tool automatically adds the  and 
> markers,
> > > > > > >    which interferes with YANG convention specified in RFC 8407,
> > > > > > >    sec. 3.2. I have already raised a question about this in the
> > > > > > >    xml2rfc-dev mailing list.
> > > > > >
> > > > > > Update: using the "name" attribute with  does the right
> > > thing.
> > > > > >
> > > > > >     
> > > > > >     ...
> > > > > >     
> > > > > >
> > > > > > results in
> > > > > >
> > > > > >      file "ietf-foo@2016-03-20.yang"
> > > > > >     ...
> > > > > >     
> > > > > >
> > > > > > Lada
> > > > > >
> > > > > > > Lada
> > > > > > >
> > > > > > > Lou Berger  writes:
> > > > > > >
> > > > > > > > All,
> > > > > > > >
> > > > > > > > This is start of a two week poll on making
> > > > > > > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > > > > > > document. Please send email to the list indicating "yes/support"
or
> > > > > > > > "no/do not support".  If indicating no, please state your
> > > reservations
> > > > > > > > with the document.  If yes, please also feel free to provide
> > > comments
> > > > > > > > you'd like to see addressed once the document is a WG document.
> > > > > > > >
> > > > > > > > The poll ends Oct 1.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Lou (and co-chairs)
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > netmod mailing list
> > > > > > > > netmod@ietf.org
> > > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > --
> > > > > > Ladislav Lhotka
> > > > > > Head, CZ.NIC Labs
> > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > >
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >


From nobody Tue Oct 23 11:04:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE82B12D4F0 for ; Tue, 23 Oct 2018 11:04:44 -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 l-lML7h_wzej for ; Tue, 23 Oct 2018 11:04:42 -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 22777130E4D for ; Tue, 23 Oct 2018 11:04:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C0E41FB4; Tue, 23 Oct 2018 20:04:40 +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 DEuFIqwJELiv; Tue, 23 Oct 2018 20:04:40 +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, 23 Oct 2018 20:04:40 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAD062003A; Tue, 23 Oct 2018 20:04:40 +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 iMrvU07jCoaD; Tue, 23 Oct 2018 20:04:40 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5629B20039; Tue, 23 Oct 2018 20:04:40 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1415.2; Tue, 23 Oct 2018 20:04:39 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 9346830027CB6C; Tue, 23 Oct 2018 20:04:38 +0200 (CEST)
Date: Tue, 23 Oct 2018 20:04:38 +0200
From: Juergen Schoenwaelder 
To: tom petch 
CC: "netmod@ietf.org" 
Message-ID: <20181023180438.b5yvycioj77mrjkt@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: tom petch , "netmod@ietf.org" 
References: <02f701d46aeb$65533e00$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <02f701d46aeb$65533e00$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] IANA Considerations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:04:45 -0000

Tom,

the IANA registry has this field, I assume it got introduced when IANA
started to maintain their own modules and needed a flag to distinguish
them from other modules. Martin may know more. If you think this is a
problem, the authors can remove 'Maintained by IANA?: N' strictly
following RFC 6020 and IANA will then add this bit later during the
IANA processing.

/js

On Tue, Oct 23, 2018 at 04:15:04PM +0000, tom petch wrote:
> draft-ietf-ccamp-mw-yang-10
> has, in IANA Considerations,
>       Name: ietf-microwave-radio-link
>       Maintained by IANA?: N
>       Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
>       Prefix: mrl
>       Reference: RFC XXXX
> which adds a line I have not seen before, not mentioned - naturally - in
> RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.
> 
> It seems like 'A Good Thing' but where has it come from, what is the
> basis for it and is there a reference for it?  It could be construed as
> a breach of RFC6020.
> 
> Tom Petch
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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 23 11:06:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF4C130E50 for ; Tue, 23 Oct 2018 11:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level: 
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFxAMzOOvgOZ for ; Tue, 23 Oct 2018 11:06:39 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50970130E4D for ; Tue, 23 Oct 2018 11:06:39 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9NI3vmv015016; Tue, 23 Oct 2018 11:06:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=oNzqK4IkbWfGaynCuy/CoSXzL7Sizj9awE/RPfGe/uE=; b=g2krEwY3ZizQ5OQnF/YvOzJ5ZQ1obSPJltcZ1q2u03zSM0UliBaJskOUotnDJe0i2g/w 7WkGWGCRI4ZDyLf77ANB/+gjFy9iRviYanFp83suviAW7Cef5z7thSC7mcsMjEjA0Gn0 ksxhRa04ZwFs2fb7W/jCG/o3FDcl4D9uMP/4AqnRSgK6zg1UhQEXrVmlAgG6ngI/meIa W8Pw1lWn9lm7cCDwjIMPurw+mTyMrrbQfhykQvGY1VxKY8WocqOFptqLEft+n92hlTVv HgZp5A4XruWmeFGy/zGyupyywcm2OJxiKDLWmS0OmA52Uw2UxFsHvFy+zJTHtxsX6Gn1 hQ== 
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0021.outbound.protection.outlook.com [216.32.181.21]) by mx0b-00273201.pphosted.com with ESMTP id 2na86ng2mk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 11:06:37 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4235.namprd05.prod.outlook.com (20.176.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.11; Tue, 23 Oct 2018 18:06:35 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 18:06:35 +0000
From: Kent Watsen 
To: "adrian@olddog.co.uk" , 'Martin Bjorklund' , "lhotka@nic.cz" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZuQVidlHv6+/gECDyKpE/4pPA6UszYGAgAAL/4CAAAYhgIAACVqAgAACYQCAABdRgIAAA3EAgAAPDoD//9BxAA==
Date: Tue, 23 Oct 2018 18:06:35 +0000
Message-ID: <6E57629A-BE33-428D-9117-883189ED3FB2@juniper.net>
References: <326034f9a137b0489137bc39616d166f221e02a2.camel@nic.cz> <20181023.162748.209178731500337122.mbj@tail-f.com> <27cbd2fe3dd114e981fce2abb1723c5115550142.camel@nic.cz> <20181023.180334.1196557244986533615.mbj@tail-f.com> <07d201d46af1$7b3e73a0$71bb5ae0$@olddog.co.uk>
In-Reply-To: <07d201d46af1$7b3e73a0$71bb5ae0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4235; 6:gMo4ycgq9dBNUOc6GzYb+UbsxSGrEiETgm0nOdiKOqlYLXIXjUfwIk2lDGWTsIvEg7kM/ZggfkEL0kMOTczJ3fYEeVMn4iESgrOhc3bHwPTyhScNQ444BSAIkWT681ANa3xdYUYfWWnb2jedBorQOkoE+s2JKExalD2ncZ2PSQppJ59xDS/1Znxg+Wi//p9i1IcM0YbsRhDA7JIoAxrl87sl/IrvK0RO44ZtgYAU5T3AHY8JReKjSg40hu9VanmXrl6o6Wrq/l6ETql2nA5wYKA4vjMj5o+T5WoBaRzvYc3hkERErUPGI6qUpZfV4YSF+2IwX5Ju8z3ONxC6uIFl2qHRw/MTnt8Dw/1QISKWJldk4hMaxaqEp33EoNwqcxF49iEuGseLtHGHVhJEidBG7gaxtVscy5HYxR3vnoPYgnKuNgMjbwBT2YvtO411FlUHt4IWtN14cFAdxKAcemjkbA==; 5:QKn2P11MTfNQxE4xNHIJEnT4JLPWxsEfV5D1E940fz+XRpcwzGQW+ZLiYFjHosCmCyw7QlN1uX8ukKecHv6ptlO/imyVNArC7/opnHp3Mhz9+9VjSSX4Ot1u/D8TPAJkCti5b3T09+Z3LSGsO8GBgnJaIX72CqyavSBgFNo1Le4=; 7:1XxW6UQdsM02tbZ/VMgzv8as07cy6ceBPwe0UmRn6jCaC3r9805JxOSOZYaiHarID3awI4FCZxylTDNSa3dVgFUssTqXgSI1RT6oEHnr7Hu+8oW0tM1AMKmJzo2WS7Yc/YmAcz6vmye1vM5uBUogpg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 203973db-50d9-40b9-0ac7-08d639124553
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4235; 
x-ms-traffictypediagnostic: DM6PR05MB4235:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4235; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4235; 
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(39860400002)(366004)(189003)(199004)(13464003)(86362001)(33656002)(25786009)(36756003)(8936002)(6436002)(316002)(6486002)(71190400001)(71200400001)(83716004)(97736004)(4326008)(256004)(4001150100001)(93886005)(575784001)(99286004)(2501003)(81166006)(14444005)(966005)(5250100002)(81156014)(14454004)(53936002)(66066001)(476003)(478600001)(2616005)(76176011)(486006)(6246003)(2906002)(8676002)(446003)(186003)(5660300001)(58126008)(53546011)(110136005)(6116002)(3846002)(26005)(114624004)(6346003)(102836004)(229853002)(6306002)(6506007)(6512007)(68736007)(106356001)(305945005)(105586002)(82746002)(2900100001)(7736002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4235; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: BOmgE/ciCyJq7kt/M8LL2MOORVmMNwEB8rd5IxezGopGxc/VSpwTJjm7TYikPiZWkrALfi41O2aSmJJQ0BZJqwIDyRck6/UDIL+E+p1gL/PPjoEuXcjf+wzztX2FMPpG4xbbxophJorX3wiQB0/ILXmn8Lre9qos/Vl36sKVAQRKOperR3FJXtTNj7eSPfs9pYPp4VU/YXq+tu9zKEBWFRz14g6MalR9ngFUGh57mTJVCfEo+jjhbFDB6D8EPSUO+aEil2S6qP2N8yBXP+idwtkFyEJZ6hncV3eY7/b5Tsy3gO63eOcbrpAy4b0P+1DEnlylRX0ZABJsj8caSfSy3YsKmxPuarNYkVtA6nCyycU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 203973db-50d9-40b9-0ac7-08d639124553
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 18:06:35.2827 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4235
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230146
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:06:41 -0000

Q29ycmVjdCwgdGhpcyBkb2N1bWVudCBvbmx5IGRlZmluZXMgYSBmaWxlIGZvcm1hdC4NCg0KQSBz
ZXBhcmF0ZSBlZmZvcnQgd2lsbCBiZSBuZWVkZWQgdG8gZXh0ZW5kIGB4bWwycmZjYCBhbmQgYHh5
bWAgYW5kIHRoZSBsaWtlLg0KDQpGb3IgdGhvc2UgdGhhdCB3aXNoIHRvIHByZS1mb2xkIHRoZWly
IGFydHdvcmsgcHJpb3IgdG8gc3VibWl0dGluZyB0aGUgWE1MIChoYW5kLWNyYWZ0ZWQgZm9sZGlu
ZyAtLT4gbWF4IHJlYWRhYmlsaXR5KSwgdGhlIGB4bWwycmZjYCB3aWxsIG5vdCBmb2xkIGl0IGFn
YWluLg0KDQpGb3IgdGhvc2UgdGhhdCBwcmVmZXIgdG8gc3VibWl0IHRoZSBvcmlnaW5hbCBhcnR3
b3JrIGluIHRoZSBYTUwgKHdoaWNoIGFsbG93cyB0aGUgdW5mb2xkZWQgYXJ0d29yayBpbiBvdGhl
ciBmb3JtYXRzLCBlLmcuLCBIVE1MKSwgYHhtbDJyZmNgIHdpbGwgdXNlIGFuIGF1dG9tYXRlZGx5
IGZvbGRpbmcgc29sdXRpb24gKGZvciBwbGFpbi10ZXh0IG91dHB1dCBvbmx5KSwgbW9zdCBsaWtl
bHkgdXNpbmcgdGhlIHNjcmlwdCBpbiB0aGUgYXBwZW5kaXguDQoNCksuDQoNCg0K77u/LS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmc+IG9uIGJlaGFsZiBvZiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KUmVw
bHktVG86ICJhZHJpYW5Ab2xkZG9nLmNvLnVrIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCkRhdGU6
IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTggYXQgMTI6NTcgUE0NClRvOiAnTWFydGluIEJqb3Jr
bHVuZCcgPG1iakB0YWlsLWYuY29tPiwgImxob3RrYUBuaWMuY3oiIDxsaG90a2FAbmljLmN6Pg0K
Q2M6ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25l
dG1vZF0gV0cgYWRvcHRpb24gcG9sbCBkcmFmdC1rd2F0c2VuLW5ldG1vZC1hcnR3b3JrLWZvbGRp
bmctMDgNCg0KTmljZWx5IHNhaWQsIE1hcnRpbi4NClRoZSBpbnRlbnRpb24gaXMgdGhhdCBpZiwg
bGlrZSBMYWRpc2xhdiwgeW91IGxpa2UgdG8gd29yayBpbiBzb21lIGxvbmctbGluZQ0KZm9ybWF0
LCB0aGVuIGl0IHdvcmtzIGFzIGRvY3VtZW50ZWQgYW5kIHRoZSB0b29scyBjYW4gd3JhcC4NCklm
LCBsaWtlIG1lLCBhbmQgbWF5YmUgbGlrZSBNYXJ0aW4sIHlvdSB0aGluayBwcmV0dHkgZm9ybWF0
dGluZyBpcyBzb21ldGhpbmcNCnRoYXQgaW1wcm92ZXMgcmVhZGFiaWxpdHksIHRoZSBkcmFmdCBh
bHNvIGxldHMgeW91IGRvIHRoYXQuDQoNCkENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21dDQo+IFNl
bnQ6IDIzIE9jdG9iZXIgMjAxOCAxNzowNA0KPiBUbzogbGhvdGthQG5pYy5jeg0KPiBDYzogYWRy
aWFuQG9sZGRvZy5jby51azsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9k
XSBXRyBhZG9wdGlvbiBwb2xsIGRyYWZ0LWt3YXRzZW4tbmV0bW9kLWFydHdvcmstZm9sZGluZy0N
Cj4gMDgNCj4gDQo+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4g
T24gVHVlLCAyMDE4LTEwLTIzIGF0IDE2OjI3ICswMjAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3Rl
Og0KPiA+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPiA+ID4g
T24gVHVlLCAyMDE4LTEwLTIzIGF0IDE0OjQ1ICswMTAwLCBBZHJpYW4gRmFycmVsIHdyb3RlOg0K
PiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gMS4gSSB0aGluayB5b3UgbWlzcyB0
aGUgcG9pbnQuIFdoaWxlIGV4YW1wbGUgWE1ML0pTT04gWUFORyBpcyBpbmNsdWRlZA0KPiBpbg0K
PiA+ID4gPiA+IGRyYWZ0cywgYW5kIHdoaWxlIHRoZSBhdXRob3JzIGFyZSBhbGxvd2VkIHRvIHBy
b2R1Y2UgdGhvc2UgZHJhZnRzIGFzDQp0eHQNCj4gPiA+ID4gPiBmaWxlcywNCj4gPiA+ID4gPiBv
ciB3aGlsZSB0aGUgYXV0aG9ycyB3YW50IHRvIGFjaGlldmUgcHJldHR5LXRvLXJlYWQgZm9ybWF0
dGluZywgdGhpcw0Kd29yaw0KPiA+ID4gPiA+IGZhbGxzDQo+ID4gPiA+ID4gaW50byB0aGUgc2Nv
cGUgb2YgdGhvc2UgYXV0aG9ycy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGZvbGRpbmcgb2YgbG9u
ZyBsaW5lcyBzaG91bGQgYmUgZG9uZSBhcyB0aGUgdmVyeSBsYXN0IChhdXRvbWF0aWMpDQpzdGVw
DQo+ID4gPiA+IGJlZm9yZSB0aGUgZG9jdW1lbnQgZ2V0cyBwdWJsaXNoZWQuIERvaW5nIGl0IGVh
cmxpZXIgbWVhbnMgdGhhdCB0aGUNCnNvdXJjZQ0KPiA+ID4gY29kZQ0KPiA+ID4gPiBpbiB0aGlz
IGZvbGRlZCBmb3JtIGNhbiBiZSAoYWNjaWRlbnRhbGx5KSBmdXJ0aGVyIGVkaXRlZCwgd2hpY2gg
Y2FuIGxlYWQNCnRvDQo+ID4gPiA+IGluY29uc2lzdGVuY2llcy4NCj4gPiA+DQo+ID4gPiBJIHdp
bGwgdXNlIGZvbGRpbmcgZS5nLiBmb3IgaW5zdGFuY2UgZG9jdW1lbnQgZXhhbXBsZXMgaW4gWE1M
IGFuZA0KPiA+ID4gSlNPTi4NCj4gPiA+DQo+ID4gPiBNeSBwbGFuIGlzIHRvIGtlZXAgdGhlIGV4
YW1wbGUgZmlsZXMgd2l0aCBtYW51YWxseSBhZGRlZCBicmVha3MgaW4gbXkNCj4gPiA+IHJlcG8s
IGFuZCBhcyBwYXJ0IG9mIHZhbGlkYXRpb24gcnVuIGEgc2NyaXB0IHRoYXQgdW5mb2xkcyB0aGUN
Cj4gPiA+IGV4YW1wbGVzLCBhbmQgdGhlbiB2YWxpZGF0ZSB0aGUgcmVzdWx0LiAgVGhlIHJlYXNv
biBmb3IgdGhpcyBpcyB0aGF0IEkNCj4gPiA+IHRoaW5rIHJlYWRiaWxpdHkgb2YgdGhlIGV4YW1w
bGVzIGlzIGltcG9ydGFudC4NCj4gPg0KPiA+IFRoaXMgc2VlbXMgYmFja3dhcmRzIHRvIG1lLiBJ
ZiB5b3UgbmVlZCB0byBlZGl0IHN1Y2ggYW4gZXhhbXBsZSwgeW91IG1heQ0KPiBoYXZlIHRvDQo+
ID4gcmVtb3ZlIHRoZSBiYWNrc2xhc2hlcywgcmVmb3JtYXQgYW5kIGluc2VydCB0aGVtIGFnYWlu
Lg0KPiA+DQo+ID4gSWYgaXQncyBub3QgcG9zc2libGUgdG8gZm9sZCBsaW5lcyBhY2NvcmRpbmcg
dG8gdGhlIHN5bnRheCBvZiBhIGdpdmVuDQpsYW5ndWFnZSwNCj4gPiBJJ2QgcHJlZmVyIHRvIGtl
ZXAgdGhlIG9yaWdpbmFsIGxpbmVzIGFzIGxvbmcgYXMgcG9zc2libGUgYW5kIHJlbHkgb24gYW4N
Cj4gPiBhdXRvbWF0aWMgcHJvY2VkdXJlIGp1c3QgYmVmb3JlIHRoZSBmaW5hbCBkb2N1bWVudCBp
cyByb2xsZWQgb3V0Lg0KPiANCj4gRm9ydHVuYXRlbHksIHRoZSBkcmFmdCBhbGxvd3MgdXMgYm90
aCB0byB3b3JrIHRoZSB3YXkgd2UgcHJlZmVyLg0KPiANCj4gDQo+IC9tYXJ0aW4NCj4gDQo+IA0K
PiA+DQo+ID4gTGFkYQ0KPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IC9tYXJ0aW4NCj4gPiA+DQo+
ID4gPg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gQXMgbG9uZyBhcyB0aGUgZG9jdW1lbnQgaXMg
YmVpbmcgbW92ZWQgYXJvdW5kIGFuZCBlZGl0ZWQsIGl0IHdvdWxkIGJlDQo+IGJldHRlcg0KPiA+
ID4gdG8NCj4gPiA+ID4ga2VlcCB0aGUgc291cmNlIGNvZGUgdW50b3VjaGVkLg0KPiA+ID4gPg0K
PiA+ID4gPiBMYWRhDQo+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAyLiBZZXMsIHRoZSBh
dXRob3JzIGRpc2N1c3NlZCB0aGUgPHNvdXJjZWNvZGU+IGVsZW1lbnQgYW5kIGFncmVlZCB0aGF0
DQo+IGl0DQo+ID4gPiB3aWxsDQo+ID4gPiA+ID4gYmUgaW4gc2NvcGUuDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiBIb3dldmVyLCB3ZSBhcmUgYWxsIHNvcnQgb2Ygd2FpdGluZyBmb3IgeG1sMnJmYyB2
MyBhbmQgcGVuZGluZw0KY29tcGxldGlvbiwNCj4gPiA+IHdlDQo+ID4gPiA+ID4gd2FudCB0byBt
b3ZlIHRoaXMgZm9yd2FyZCBmb3IgdjIgdGhhdCBpcyBpbiB1c2UgdG9kYXkuDQo+ID4gPiA+ID4N
Cj4gPiA+ID4gPiAoTW9yZSB0aGFuKSBIYXBweSB0byBjb21lIGJhY2sgYW5kIHJldmlzaXQgdGhp
cyBpc3N1ZSB3aGVuIHYzIGlzDQo+IGRlcGxveWVkLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhh
bmtzLA0KPiA+ID4gPiA+IEFkcmlhbg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMYWRpc2xhdg0KPiA+ID4gTGhvdGthDQo+
ID4gPiA+ID4gPiBTZW50OiAyMyBPY3RvYmVyIDIwMTggMTQ6MjQNCj4gPiA+ID4gPiA+IFRvOiBu
ZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBXRyBhZG9w
dGlvbiBwb2xsIGRyYWZ0LWt3YXRzZW4tbmV0bW9kLQ0KPiBhcnR3b3JrLQ0KPiA+ID4gZm9sZGlu
Zy0NCj4gPiA+ID4gPiA+IDA4DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gT24gVHVlLCAyMDE4
LTEwLTIzIGF0IDE0OjQwICswMjAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gPiA+ID4g
PiA+IEhpLA0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBJIHN1cHBvcnQgdGhlIGFkb3B0
aW9uLg0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBDb21tZW50czoNCj4gPiA+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+ID4gMS4gTXkgZ2VuZXJhbCBmZWVsaW5nIGlzIHRoYXQgc3VjaCB0ZWNo
bmljYWxpdGllcyBzaG91bGQgYmUNCmhhbmRsZWQgYnkNCj4gPiA+ID4gPiA+ID4gICAgdGhlIFJG
QyBlZGl0b3IgYW5kL29yIHRvb2xzIHJhdGhlciB0aGFuIFlBTkcgbW9kdWxlIGFuZCBSRkMNCj4g
PiA+IGF1dGhvcnMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IDIuIHhtbDJyZmMgdjMg
aW50cm9kdWNlZCBhIG5ldyBlbGVtZW50LCA8c291cmNlY29kZT4sIHRoYXQgaXMNCj4gaW50ZW5k
ZWQNCj4gPiA+ID4gPiA+ID4gICAgZm9yIHNvdXJjZSBjb2RlIGluY2x1c2lvbi4gVGhpcyBkb2N1
bWVudCBzaG91bGQgdGhlcmVmb3JlIGNvdmVyDQo+ID4gPiB0aGlzDQo+ID4gPiA+ID4gPiA+ICAg
IGVsZW1lbnQgYXMgd2VsbCAocHJpbWFyaWx5PykuIE9uZSBwcm9ibGVtIHdpdGggaXQgaXMgdGhh
dCB0aGUNCj4gPiA+IHhtbDJyZmMNCj4gPiA+ID4gPiA+ID4gICAgdG9vbCBhdXRvbWF0aWNhbGx5
IGFkZHMgdGhlIDxDT0RFIEJFR0lOUz4gYW5kIDxDT0RFIEVORFM+DQo+IG1hcmtlcnMsDQo+ID4g
PiA+ID4gPiA+ICAgIHdoaWNoIGludGVyZmVyZXMgd2l0aCBZQU5HIGNvbnZlbnRpb24gc3BlY2lm
aWVkIGluIFJGQyA4NDA3LA0KPiA+ID4gPiA+ID4gPiAgICBzZWMuIDMuMi4gSSBoYXZlIGFscmVh
ZHkgcmFpc2VkIGEgcXVlc3Rpb24gYWJvdXQgdGhpcyBpbiB0aGUNCj4gPiA+ID4gPiA+ID4gICAg
eG1sMnJmYy1kZXYgbWFpbGluZyBsaXN0Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFVwZGF0
ZTogdXNpbmcgdGhlICJuYW1lIiBhdHRyaWJ1dGUgd2l0aCA8c291cmNlY29kZT4gZG9lcyB0aGUg
cmlnaHQNCj4gPiA+IHRoaW5nLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgICA8c291cmNl
Y29kZSBuYW1lPSJpZXRmLWZvb0AyMDE2LTAzLTIwLnlhbmciPg0KPiA+ID4gPiA+ID4gICAgIC4u
Lg0KPiA+ID4gPiA+ID4gICAgIDwvc291cmNlY29kZT4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g
PiByZXN1bHRzIGluDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgIDxDT0RFIEJFR0lOUz4g
ZmlsZSAiaWV0Zi1mb29AMjAxNi0wMy0yMC55YW5nIg0KPiA+ID4gPiA+ID4gICAgIC4uLg0KPiA+
ID4gPiA+ID4gICAgIDxDT0RFIEVORFM+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTGFkYQ0K
PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gTGFkYQ0KPiA+ID4gPiA+ID4gPg0KPiA+ID4gPiA+
ID4gPiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cml0ZXM6DQo+ID4gPiA+ID4gPiA+
DQo+ID4gPiA+ID4gPiA+ID4gQWxsLA0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
VGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQo+ID4gPiA+ID4gPiA+
ID4gZHJhZnQta3dhdHNlbi1uZXRtb2QtYXJ0d29yay1mb2xkaW5nLTA4IGEgd29ya2luZyBncm91
cA0KPiA+ID4gPiA+ID4gPiA+IGRvY3VtZW50LiBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlz
dCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCINCm9yDQo+ID4gPiA+ID4gPiA+ID4gIm5vL2RvIG5v
dCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyDQo+ID4gPiBy
ZXNlcnZhdGlvbnMNCj4gPiA+ID4gPiA+ID4gPiB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHllcywg
cGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUNCj4gPiA+IGNvbW1lbnRzDQo+ID4gPiA+
ID4gPiA+ID4geW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlz
IGEgV0cgZG9jdW1lbnQuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gPiBUaGUgcG9s
bCBlbmRzIE9jdCAxLg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gVGhhbmtzLA0K
PiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gTG91IChhbmQgY28tY2hhaXJzKQ0KPiA+
ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0
DQo+ID4gPiA+ID4gPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiA+ID4gPiA+ID4gaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v
cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh
R1R2aklTbGFKZGNabyZtPUtyWlBPM1RtLUNqZWF6dk9sTUNCUDEzeWt2NkVtZVZXZmFJbVJpc1Rh
SjQmcz1NX0lrbHl0SWg2U01oU1FQSU9zcWR5d0N4d3VNZ0l0NXRVSjd3WGhkeXNNJmU9DQo+ID4g
PiA+ID4gPiAtLQ0KPiA+ID4gPiA+ID4gTGFkaXNsYXYgTGhvdGthDQo+ID4gPiA+ID4gPiBIZWFk
LCBDWi5OSUMgTGFicw0KPiA+ID4gPiA+ID4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3
DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+
ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0
aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv
RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt
PUtyWlBPM1RtLUNqZWF6dk9sTUNCUDEzeWt2NkVtZVZXZmFJbVJpc1RhSjQmcz1NX0lrbHl0SWg2
U01oU1FQSU9zcWR5d0N4d3VNZ0l0NXRVSjd3WGhkeXNNJmU9DQo+ID4gPiA+IC0tDQo+ID4gPiA+
IExhZGlzbGF2IExob3RrYQ0KPiA+ID4gPiBIZWFkLCBDWi5OSUMgTGFicw0KPiA+ID4gPiBQR1Ag
S2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gbmV0bW9kIG1haWxp
bmcgbGlzdA0KPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h
bl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst
bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPUtyWlBPM1RtLUNqZWF6dk9sTUNCUDEzeWt2NkVtZVZXZmFJbVJpc1RhSjQmcz1NX0lr
bHl0SWg2U01oU1FQSU9zcWR5d0N4d3VNZ0l0NXRVSjd3WGhkeXNNJmU9DQo+ID4gPiA+DQo+ID4g
LS0NCj4gPiBMYWRpc2xhdiBMaG90a2ENCj4gPiBIZWFkLCBDWi5OSUMgTGFicw0KPiA+IFBHUCBL
ZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0
Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVo
NjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1LclpQTzNUbS1DamVhenZPbE1DQlAxM3lrdjZF
bWVWV2ZhSW1SaXNUYUo0JnM9TV9Ja2x5dEloNlNNaFNRUElPc3FkeXdDeHd1TWdJdDV0VUo3d1ho
ZHlzTSZlPQ0KDQo=


From nobody Tue Oct 23 11:13:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6DE13102F; Tue, 23 Oct 2018 11:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMebDSXQ4EXu; Tue, 23 Oct 2018 11:13:44 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25928131030; Tue, 23 Oct 2018 11:13:44 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9NI9E8s021923; Tue, 23 Oct 2018 11:13:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=U1TLiV8X2X318+ar7VXxxgacYhL73fR7tvVuHQQwVRk=; b=cOlLG64wHT509zkjm1lZ6POAJTgVgPcrtjzH+04l6wKLQYYH+L4sw7QBqbFN/m+hdUF+ eYh0wq0C8oXgMcVkvb5fSufnAXOvl9HeGCnAPE5zFqT+qPY8tu0UnT8UY8J+h2+8vlGE 5V8OzfBVXn3XFEt6RiYUD1guM4WoZlm9p7kpK7HCVJclIUTr++gwKpDF9eNkwh4A8/i6 vq8SSJU9tyKX0oFqZIEio1Ubckst1ymC0YF27Up9aAXakl+QVq1OHFvr20Nr/XOORo7P U/YVjZPz4fGnTrGOIAV0/FWhLciTOuq5JCrBVB47TONdkaRrWFGytQeVeQ8tnZjkA1IQ MQ== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0051.outbound.protection.outlook.com [207.46.163.51]) by mx0b-00273201.pphosted.com with ESMTP id 2na6h2rayk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 11:13:43 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4698.namprd05.prod.outlook.com (20.176.109.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.16; Tue, 23 Oct 2018 18:13:41 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1273.014; Tue, 23 Oct 2018 18:13:41 +0000
From: Kent Watsen 
To: Martin Bjorklund , "lberger@labn.net" 
CC: "netmod@ietf.org" , "netmod-chairs@ietf.org" 
Thread-Topic: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZuQVidlHv6+/gECDyKpE/4pPA6Usg4GAgABkGAA=
Date: Tue, 23 Oct 2018 18:13:41 +0000
Message-ID: 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <20181023.101605.216102708295807418.mbj@tail-f.com>
In-Reply-To: <20181023.101605.216102708295807418.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4698; 6:8B+0AWUaJsVeig7a3V4n3IreKbk784jKT0i9HIRJhfZAEEE5LoOn7Bcnc7FcGvLZOhoOp2DGAWIbp2yD7DruYYbzNMjhRim71zQ5HMLmQmPmfO9IeS5jMS90mPzwKTKdx1ZKXzuw8o/QXTvjj1Yt5clrp+jOIUSSbvqyKxS+UfBbs3Uk70k2EVm3i0xi8G4/GqZxP9nxvBx6APs1fzUFxUcLpa39l5j30KeHN5D2n32RMtberO6DVfCtAL4SV0lUegFQwE1tfNdyjZQbWMcQiZD3ke4xgvFmx/xQ+Xe0nrwlP4y5m10r2eWPigK2QYjVF97gG2hrie2AkJS2GRaqiBl792R4+T0GZMoBbksOk1ulY2MPAJ4iNViyMGpJbgKdeFH+OB7HDwMRGSzgiD4dFqoHiwqAV54oYsRX9KLwciTz8KDzxNygvvmZfdQw/t6w6nF4K86PW8iQKoNu53UFBQ==; 5:SuoN/j2XIpeZ6BLAy90yxAYhax0r7niZVB97iy3RDytaXgvP8xJSMZleL5aZcCP2hvv4L8WSGAxGSx9wdwlw3aO3lIbgkArBP9KXva0WD3JXEHp5KXpDZnrfZc9u6lZqg+TB96nIQ6QMhQmDPITRu2avi5V5QmYB1t9F+QNQOgA=; 7:Ucd7Fuw1xzQ3bzEbETRafdarYlBkfK4ym2i/ZpZ6Or0LkNI8GXAn1u6izSiycMTnKo4BKfDZ3zUzRJtwphvMUBJQwANQXt0kDsharpI6wBdbIRI16mACgfmwwWEhymjZkPCfwXTem2zRJEEZwlDZ7g==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 32e5a280-066b-4d85-b7fd-08d63913434a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4698; 
x-ms-traffictypediagnostic: DM6PR05MB4698:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4698; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4698; 
x-forefront-prvs: 0834BAF534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(39860400002)(396003)(376002)(199004)(189003)(81166006)(25786009)(53936002)(11346002)(66066001)(6506007)(2616005)(68736007)(36756003)(186003)(8936002)(99286004)(478600001)(76176011)(81156014)(8676002)(4326008)(305945005)(316002)(102836004)(6436002)(7736002)(476003)(6246003)(71200400001)(2900100001)(86362001)(106356001)(6512007)(71190400001)(2906002)(33656002)(83716004)(54906003)(58126008)(110136005)(105586002)(82746002)(229853002)(5660300001)(2501003)(256004)(446003)(14454004)(5250100002)(97736004)(3846002)(486006)(26005)(6116002)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4698; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bEr7NZjuQmBzOM8np57p2o9odbC/828WeVVaixthoxvYSujpClT9fF9A1CI9Gbo5G7VAe83RfAJMdoatdg0MfqT+s1Evuw9o6NW0uUjbUzJPN4pwbDuvoZe90rmOmyMzJM0ynxp5HNbjAvSj9AKWwPH+Y3o8l+EedT5UZq63TWBNpOdKOGwzui8bGb/AmrLiV5TWh+mc9uXBl7kqZhLxVLvfksbAL1inxdpU/m/V3q6B/zaANsrQAWn/AExGeQu9DU+DqP/7xhezWZG4C64u/FLx2xQNKTtdE5LOzXpC5tPBvPNGFz5UYRyPpL/axHGz1VV3H5t52R6aiH35Dt9CQ4ZBMSeBKkdKGgaLAMv/Eko=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1DFC87BC40F8F14B974CFABB378DB4A9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 32e5a280-066b-4d85-b7fd-08d63913434a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 18:13:41.3944 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4698
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230147
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:13:51 -0000

DQpIaSBNYXJ0aW4sDQoNCj4gb25lIHF1aWNrIGNvbW1lbnQ7IHRoZSBoZWFkZXIgdXNlZCBpbiB0
aGUgZXhhbXBsZXMgaW4NCj4gc2VjdGlvbiA4IGlzbid0IGVxdWFsIHRvIHRoZSBoZWFkZXIgZGVm
aW5lZCBpbiBzZWN0aW9uIDUuMQ0KDQoNClRoaXMgaXMgaW50ZW50aW9uYWwuICBTZWN0aW9uIDUu
MSBzYXlzOg0KDQogICBUaGUgZmlyc3QgbGluZSBpcyB0aGUgZm9sbG93aW5nIDQ2LWNoYXJhY3Rl
ciBzdHJpbmcgdGhhdCBNQVkgYmUNCiAgIHN1cnJvdW5kZWQgYnkgYW55IG51bWJlciBvZiBwcmlu
dGFibGUgY2hhcmFjdGVycy4NCg0KVGhlIHJhdGlvbmFsaXphdGlvbiBoZXJlIGlzOg0KDQogIC0g
c2NyaXB0cyBjYW4gZWFzaWx5IGNlbnRlciB0aGUgdGV4dCB3aXRoIGVxdWFsIGFtb3VudHMgb2Yg
c29tZQ0KICAgIGNob3NlbiBjaGFyYWN0ZXIuICBUaGUgc2NyaXB0IGluIHRoZSBBcHBlbmRpeCwg
d2hpY2ggd2FzIHVzZWQNCiAgICB0byBmb2xkIGV4YW1wbGVzIDguMSB0aHJ1IDguNCwgdXNlcyAn
PScgY2hhcmFjdGVycy4NCg0KICAtIG1hbnVhbCBmb2xkaW5nIGlzIGRpZmZpY3VsdCB0byBjZW50
ZXIsIGFuZCBoZW5jZSBvdGhlciBmcmFtaW5nDQogICAgaXMgbW9yZSBzdWl0YWJsZS4gIEZvciBp
bnN0YW5jZSwgdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA4LjUuDQoNCktlbnQgLy8gY29udHJpYnV0
b3INCg0KDQoNCg==


From nobody Tue Oct 23 11:39:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD81130F17; Tue, 23 Oct 2018 11:39:28 -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, 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 RZG1FhMydJr8; Tue, 23 Oct 2018 11:39:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF8130F0F; Tue, 23 Oct 2018 11:39:27 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 61F451AE0187; Tue, 23 Oct 2018 20:39:22 +0200 (CEST)
Date: Tue, 23 Oct 2018 20:39:22 +0200 (CEST)
Message-Id: <20181023.203922.2119478315839780523.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <20181023.101605.216102708295807418.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:39:29 -0000

Kent Watsen  wrote:
> 
> Hi Martin,
> 
> > one quick comment; the header used in the examples in
> > section 8 isn't equal to the header defined in section 5.1
> 
> 
> This is intentional.  Section 5.1 says:
> 
>    The first line is the following 46-character string that MAY be
>    surrounded by any number of printable characters.

Ok.

> The rationalization here is:
> 
>   - scripts can easily center the text with equal amounts of some
>     chosen character.  The script in the Appendix, which was used
>     to fold examples 8.1 thru 8.4, uses '=' characters.
> 
>   - manual folding is difficult to center, and hence other framing
>     is more suitable.  For instance, the example in Section 8.5.

Ok, but what's the point?  Why not use a fixed header?  IMO it might
also improve readability by have a common well-known header.


/martin


From nobody Tue Oct 23 11:45:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4975130EEC for ; Tue, 23 Oct 2018 11:45:35 -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, 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 gL00wS5jcnlJ for ; Tue, 23 Oct 2018 11:45:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B97E7130E1D for ; Tue, 23 Oct 2018 11:45:33 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 07A641AE0187; Tue, 23 Oct 2018 20:45:33 +0200 (CEST)
Date: Tue, 23 Oct 2018 20:45:32 +0200 (CEST)
Message-Id: <20181023.204532.775277363389220964.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: ietfc@btconnect.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181023180438.b5yvycioj77mrjkt@anna.jacobs.jacobs-university.de>
References: <02f701d46aeb$65533e00$4001a8c0@gateway.2wire.net> <20181023180438.b5yvycioj77mrjkt@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] IANA Considerations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:45:36 -0000

Juergen Schoenwaelder  wrote:
> Tom,
> 
> the IANA registry has this field, I assume it got introduced when IANA
> started to maintain their own modules and needed a flag to distinguish
> them from other modules. Martin may know more. If you think this is a
> problem, the authors can remove 'Maintained by IANA?: N' strictly
> following RFC 6020 and IANA will then add this bit later during the
> IANA processing.

I don't know more.  I will check with IANA.


/martin


> 
> /js
> 
> On Tue, Oct 23, 2018 at 04:15:04PM +0000, tom petch wrote:
> > draft-ietf-ccamp-mw-yang-10
> > has, in IANA Considerations,
> >       Name: ietf-microwave-radio-link
> >       Maintained by IANA?: N
> >       Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-radio-link
> >       Prefix: mrl
> >       Reference: RFC XXXX
> > which adds a line I have not seen before, not mentioned - naturally - in
> > RFC6020 or RFC7950 nor does it appear in e.g. RFC8407.
> > 
> > It seems like 'A Good Thing' but where has it come from, what is the
> > basis for it and is there a reference for it?  It could be construed as
> > a breach of RFC6020.
> > 
> > Tom Petch
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 23 11:56:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404CC1311D4; Tue, 23 Oct 2018 11:55:55 -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 Z6HyD6YEUo9m; Tue, 23 Oct 2018 11:55:52 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 235361310DA; Tue, 23 Oct 2018 11:55:36 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id l6-v6so1089997pgp.3; Tue, 23 Oct 2018 11:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=uI1sk+IBdXyd3v28x4uhhChNgcYQNrmnTUZgJLssBWY=; b=CCO9QD42PyHq7ogvpHwfhQPK4qFpSw8bWKqkWlnu6DaprQ6OeQkB6YolDApeMlu0fg y+oJSHbNjUgdfNCOvwLTuz+BmCxVEDCD11zy9cNY1F/264JjCJuzlepMcRLQxpE+DB4k 3OzM6KbMaBHCnyyW3iwBv5tx5gWxb4czSD0MBaxUrNvg6RWIt5uahEAoTGlVQfB1l/2G zV5SzwCobtTsL8H9BSVapI9pKXHCik95VNeox1OZa7dgKQTGvNiQPIoTo4QNNQYQplNa FMUDNf7uDNNoQttoCl8Ks5+8t12/U7sEBPtCJk5NdbS+OXPOBcfHtbu0DIb3ppcvie0u T3Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=uI1sk+IBdXyd3v28x4uhhChNgcYQNrmnTUZgJLssBWY=; b=kiiWwCDX3OgFu5ikmTBOWlX1Tgk+aTDef+z6B4wzwFezTx153Wx9r4iLsCPLni8IeS XoFdV3+aExSuwE7elQLPsEcVk2sH56KRYWFevo0snrBn86rogSViTB46SKUHW711K2yK R7TCvOUaP4ta5QcoWyfmZ9LrrsC9YlnEtzExMwsPJR8L2bST9gVZtUWrhpJjb21PPUQE q/LszzOMiV/w5st/gNhxy3jUm1gzbiTUjFq3e1FoKoAZGt51q9rr8pn9CPoyKp2U2HWz Uqvvj/v3fh7rp54l3ahML0ZFX0mAS7uUp07JXcBT21lmZLRyhkMm/6dL/QoFaZyPlMWK KIeQ==
X-Gm-Message-State: ABuFfoiI/zmCAlBrLH0ZQDpZGAIiz7tG9zmGyAAXdXuzvulPzQ0mXGtd 6lBOumrUGHdhql331wGuLcwlJCiA
X-Google-Smtp-Source: ACcGV60vzr0TEKH/4wqVkj6zEg+6ObiI+7svX++EKVbZc72fk0yI8V76cFiR1OKoDOErkH5+9EAnZQ==
X-Received: by 2002:a62:ed04:: with SMTP id u4-v6mr52119593pfh.2.1540320935211;  Tue, 23 Oct 2018 11:55:35 -0700 (PDT)
Received: from [192.168.241.189] (soln-sr3455.solutionip.com. [70.233.112.2]) by smtp.gmail.com with ESMTPSA id a16-v6sm6995700pgb.6.2018.10.23.11.55.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Oct 2018 11:55:34 -0700 (PDT)
Date: Tue, 23 Oct 2018 11:55:16 -0700
From: Jeff Tantsura 
To: NetMod WG , Lou Berger 
Cc: NetMod WG Chairs 
Message-ID: <0ccfb1eb-0cd5-4c96-ae32-32aaf1dfc787@Spark>
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
X-Readdle-Message-ID: 0ccfb1eb-0cd5-4c96-ae32-32aaf1dfc787@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5bcf6ea3_4fa0d2e3_1491"
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2018 18:55:59 -0000

--5bcf6ea3_4fa0d2e3_1491
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Yes/support

Cheers,
Jeff
On Oct 18, 2018, 6:12 AM -0700, Lou Berger , wrote:
> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support". If indicating no, please state your reservations
> with the document. If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--5bcf6ea3_4fa0d2e3_1491
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline







Yes/support



Cheers,

Jeff




On Oct 18, 2018=
, 6:12 AM -0700, Lou Berger <lberger=40labn.net>, wrote:


All,



This is start of a two week poll on making

draft-kwatsen-netmod-artwork-folding-08 a working group

document. Please send email to the list indicating =22yes/support=22 or
=22no/do not support=22. If indicating no, please state your reservations=


with the document. If yes, please also feel free to provide comments

you'd like to see addressed once the document is a WG document.



The poll ends Oct 1.



Thanks,



Lou (and co-chairs)



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

netmod mailing list

netmod=40ietf.org

https://www.ietf.org/mailman/listinfo/netmod






--5bcf6ea3_4fa0d2e3_1491--


From nobody Tue Oct 23 22:53:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525FF130DEB for ; Tue, 23 Oct 2018 22:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr59dWPeAlRJ for ; Tue, 23 Oct 2018 22:53:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B6443130DE5 for ; Tue, 23 Oct 2018 22:53:03 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EAAC01AE03B5; Wed, 24 Oct 2018 07:53:02 +0200 (CEST)
Date: Wed, 24 Oct 2018 07:53:02 +0200 (CEST)
Message-Id: <20181024.075302.1468424400755212306.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181023.204532.775277363389220964.mbj@tail-f.com>
References: <02f701d46aeb$65533e00$4001a8c0@gateway.2wire.net> <20181023180438.b5yvycioj77mrjkt@anna.jacobs.jacobs-university.de> <20181023.204532.775277363389220964.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] IANA Considerations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2018 05:53:05 -0000

Martin Bjorklund  wrote:
> Juergen Schoenwaelder  wrote:
> > Tom,
> > 
> > the IANA registry has this field, I assume it got introduced when IANA
> > started to maintain their own modules and needed a flag to distinguish
> > them from other modules. Martin may know more. If you think this is a
> > problem, the authors can remove 'Maintained by IANA?: N' strictly
> > following RFC 6020 and IANA will then add this bit later during the
> > IANA processing.
> 
> I don't know more.  I will check with IANA.

This column was apparanently added by IANA after being requested by
Benoit.  IANA does not require draft authors to include this column;
they will populate it themselves (if the module is intended to be
maintained by IANA this will be described in the IANA Considerations
section, and the module is probably called iana-something).


/martin


From nobody Wed Oct 24 01:40:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D8F130DEB; Wed, 24 Oct 2018 01:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 xBKfHnRp62ZJ; Wed, 24 Oct 2018 01:40: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 9718112870E; Wed, 24 Oct 2018 01:40:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5891; q=dns/txt; s=iport; t=1540370431; x=1541580031; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=z2QjShVo3avM9vrCNgajEEPIh9p+htM+Xae7vAO32WE=; b=j5KskfE82f2VIWsPeUrTSy2HoL1hWQljQMcnt5TrykRle7RyNXpBHMSY igxs88Ab8jYAHxJTOnS7klFnRCwaf8oLUV4UgvMMWow6MY+nMMBnMYVEY TJd92Cu00hO9RW1bAkSOMqBpEEYcZx1DWKvEEjHZpRNIXgrgW1vAVHrC6 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AADYLtBb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYEOTYEQbRIog3WId40mJZFOh0QNGAEKhANGAoMqOBY?= =?us-ascii?q?BAwEBAgEBAm0cDIU7AQEEAQEhSwsQCw4KKgICJzAGAQwGAgEBgx0BggEPp1+?= =?us-ascii?q?BLh+FHIRmBYt5gUE/gREnDIJfgxsBAYRkglcCjxSPSgmQcgYXiTeGf5Athki?= =?us-ascii?q?BWiGBVTMaCBsVO4JsgzoBCIdWhT8+MIxCAQE?=
X-IronPort-AV: E=Sophos;i="5.54,419,1534809600"; d="scan'208,217";a="7493740"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 08:40:29 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9O8eSPR006846; Wed, 24 Oct 2018 08:40:29 GMT
To: Martin Bjorklund , kwatsen@juniper.net
Cc: netmod-chairs@ietf.org, netmod@ietf.org
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <20181023.101605.216102708295807418.mbj@tail-f.com>  <20181023.203922.2119478315839780523.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <98d3d29f-1048-7ebe-2f29-8513e4f87965@cisco.com>
Date: Wed, 24 Oct 2018 09:40:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181023.203922.2119478315839780523.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------05F7445D4804A31091FD6344"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2018 08:40:39 -0000

This is a multi-part message in MIME format.
--------------05F7445D4804A31091FD6344
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 23/10/2018 19:39, Martin Bjorklund wrote:
> Kent Watsen  wrote:
>> Hi Martin,
>>
>>> one quick comment; the header used in the examples in
>>> section 8 isn't equal to the header defined in section 5.1
>>
>> This is intentional.  Section 5.1 says:
>>
>>     The first line is the following 46-character string that MAY be
>>     surrounded by any number of printable characters.
> Ok.
>
>> The rationalization here is:
>>
>>    - scripts can easily center the text with equal amounts of some
>>      chosen character.  The script in the Appendix, which was used
>>      to fold examples 8.1 thru 8.4, uses '=' characters.
>>
>>    - manual folding is difficult to center, and hence other framing
>>      is more suitable.  For instance, the example in Section 8.5.
> Ok, but what's the point?  Why not use a fixed header?  IMO it might
> also improve readability by have a common well-known header.
I'm on the fence on this one. I like the idea of having a fixed header 
(and perhaps footer as well), but if they are padded to 72 characters 
then the header may be quite jarring to the surrounding text (e.g. the 
YANG tree diagram example that I provided previously, and reproduced below):

========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
  
   module: ietf-if-l3-vlan
      augment /if:interfaces/if:interface/if-cmn:encapsulation/\
                                                    \if-cmn:encaps-type:
        +--:(dot1q-vlan)
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid


Thanks,
Rob

>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------05F7445D4804A31091FD6344
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 23/10/2018 19:39, Martin Bjorklund
      wrote:

    

    

      
Kent Watsen <kwatsen@juniper.net> wrote:


      

        
Hi Martin,



        

          
one quick comment; the header used in the examples in
section 8 isn't equal to the header defined in section 5.1


        

        

This is intentional.  Section 5.1 says:

   The first line is the following 46-character string that MAY be
   surrounded by any number of printable characters.


      

      
Ok.



      

        
The rationalization here is:

  - scripts can easily center the text with equal amounts of some
    chosen character.  The script in the Appendix, which was used
    to fold examples 8.1 thru 8.4, uses '=' characters.

  - manual folding is difficult to center, and hence other framing
    is more suitable.  For instance, the example in Section 8.5.


      

      
Ok, but what's the point?  Why not use a fixed header?  IMO it might
also improve readability by have a common well-known header.

    

    I'm on the fence on this one. I like the idea of having a fixed
    header (and perhaps footer as well), but if they are padded to 72
    characters then the header may be quite jarring to the surrounding
    text (e.g. the YANG tree diagram example that I provided previously,
    and reproduced below):

    

    
========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
 
  module: ietf-if-l3-vlan
     augment /if:interfaces/if:interface/if-cmn:encapsulation/\
                                                   \if-cmn:encaps-type:
       +--:(dot1q-vlan)
          +--rw dot1q-vlan
             +--rw outer-tag!
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     ieee:vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     ieee:vlanid

    

    Thanks,

    Rob

    

    

      


/martin

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



    

    

  


--------------05F7445D4804A31091FD6344--


From nobody Wed Oct 24 15:45:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF06C130E1A for ; Wed, 24 Oct 2018 15:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWWxhS5-zQ2g for ; Wed, 24 Oct 2018 15:45:12 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 0714612F18C for ; Wed, 24 Oct 2018 15:45:11 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9OM9Thl012061 for ; Wed, 24 Oct 2018 15:16:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=QEka2fqAccFRTLGrGDiFBbqWTc4UBqs4fnx/twJLjTY=; b=yoxbYmHmpfTyHemZ0iwfqiL8zimzRHiYs3E1cFZk4aeWgC/6hxPfjqSsRWi7iDu9JEge 3QZQUo7WTtNQHMG58sbLJI8a8xx/XzU+c17GoGXqX2uGiiO6XsYzHE7Gmp1+GDDwk3zf tuLJZnx0yJYmepFLWtZjhjFzWhJT+5y+JMKnymvVWOL5XVsoc8IwnL4GkkiYZiuIV6xv gzDKDx7fYwTgeXLe6SrjqTN990WcphdKvQbHb4hOVBx1TOHgQpN7P5GjDRJVrB20bmgT GyfhN6Es2hpi3H27GTbh5AZWfJzl+DQqte2LntJ9Tjom/EwTq2mhguYPSxJ99CDNwhjN Fg== 
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp0056.outbound.protection.outlook.com [216.32.181.56]) by mx0a-00273201.pphosted.com with ESMTP id 2nanb1se5w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 24 Oct 2018 15:16:14 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4986.namprd05.prod.outlook.com (20.177.223.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.9; Wed, 24 Oct 2018 22:16:12 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1273.014; Wed, 24 Oct 2018 22:16:12 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] xpath expressions in JSON
Thread-Index: AQHUYIquQFIwRf+9g0iqyReyfwJN+aUYa86AgAAV+ICAAMlcgIAABpwAgABHYACAAC1hgIAAEM2AgAAGGwCAAAHcgIAAB16AgABShQCAAAlpgIABCfiAgAmNmgCAAWuAgIAFBnmAgAAETgCAANoSAIAAS7AAgAAPGICAABo7AIAAAtIAgAAB/ACAAAMtAIAACmAAgAADRoCAADZPgIAABOcAgAHaEYA=
Date: Wed, 24 Oct 2018 22:16:12 +0000
Message-ID: 
References:  <20181023101630.7m52ctd3wb3nq2t3@anna.jacobs.jacobs-university.de>  <20181023.154235.539454463558274229.mbj@tail-f.com> <20181023140008.mmnjluk7cm2kcnq6@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181023140008.mmnjluk7cm2kcnq6@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4986; 6:xA474f+nBnJxhMHs2uqvL0+Quvmv1AAV/NtNRfwCF46FqJr9KiPYQLFfz1YtcZos0dLkEywG/YbXSIWG63aL1R9XYNCRuklgjVjkczpbv9z2FQ+AwZb+z1KuAqpmL2FMlaB8ID9Jb0vWtKy7YnpIaFJ1IOO8HkpqJbN2mE7VclZeBFReRi5dRH1ekxwLQpxiNrqDYqut+b17Sv3TVLAXIB/kRSEppnoEvMOz2h5Bn8LxSFDTkOq2PJOJb0a6FK9e7MPapE5g2lKQOfN9IcGz7OgbqeVf4bV/jnc+8S8umOcJHTJR2iRO5w6wwChdvMFO4KPI1qxLor0iQThq/X8zqLZBi7kaava+dqBVF5RYImcHXby5/QAQfzcv54Dc/CqRtuRo62K1o92kH4NWP3Ou/fb3RlDrLytbyITZqmhvN7vVeCWljOlI0yPchZGRNcD5ujUsc4hZEflGAyMsXjAQLw==; 5:SfSX4LJuEbWV+jYj0jtZwaCAj2ejCcxJTIQgW2BzqjEwRsYarQVwQ5q1e5iBIJM+0sKV+oih/19Z7iMYwz89hhxF5okYLJK8ah1l87JGY8FQ45OUNRR9RaOT4ZK0CkFhDpZeMtQJ08FzwLeF/R2vqpfI88BGkw19hqLiJSq4504=; 7:u5K0u3PxaW6Xi+1WBEUfyrZvyU5iwYGI4jURHpGnx2CG0MXNkBRvkeUmifbp+y/6AtsgxSN91Jxne0Qpf9yQgqSpS9/fUr6NxdQK/ZLskOLrwtRoJWWDFhVqDDvoCf5AvqlZUx1QR5ZFowVShsngCg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f0f6c497-d792-4e95-47aa-08d639fe4ed1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4986; 
x-ms-traffictypediagnostic: DM6PR05MB4986:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(10436049006162);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4986; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4986; 
x-forefront-prvs: 083526BF8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(136003)(346002)(376002)(189003)(199004)(13464003)(5640700003)(105586002)(8936002)(229853002)(11346002)(36756003)(6246003)(6116002)(446003)(2900100001)(316002)(6916009)(97736004)(478600001)(99286004)(6486002)(3846002)(305945005)(6436002)(58126008)(25786009)(66066001)(33656002)(2351001)(486006)(82746002)(7736002)(2616005)(93886005)(256004)(53936002)(81166006)(81156014)(14454004)(102836004)(86362001)(1730700003)(575784001)(2906002)(476003)(5660300001)(5250100002)(8676002)(76176011)(6506007)(53546011)(966005)(68736007)(6306002)(83716004)(6512007)(71190400001)(186003)(106356001)(71200400001)(26005)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4986; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: PIhEH+VYRu5YSpXzKLLACYWkIfQcPZxK3imWbUVW3B2LuLk9irqbF1Qo+Oq2w1rqjLQ9jFuuL72WeMpmt9VizS4Ir4hl37h/pQrISE63t7kuzOofL/xDmQVdwiogZdiNBnnLbCGAMzi7timRv7iFxNwnqCL343wk9A4S00u77jheG5QjLrLlpM3e6zx4yeTjpctejqjSShMNFc/ahrd45uIIGJulWrBnWSSYoSVPrkxPnsLuGAFI2ti4WJmF7F8rHu6b1egT4GaIMyUi7B1a8K/VU+ew81jYi/N/G38P79beInsIVAyEukgil7Bfn4ltqlkBxNIny+sHRjZihe/wUOAb3DN2JZZBorO9Y+J9r9o=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9E23BE03D3DABD439D147DE2FD24275C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f0f6c497-d792-4e95-47aa-08d639fe4ed1
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 22:16:12.5577 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4986
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-24_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810240184
Archived-At: 
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2018 22:45:14 -0000

SSBzdWJtaXR0ZWQgeWFuZy1uZXh0IGlzc3VlICM1NSB0byB0cmFjayB0aGUgbG9uZy10ZXJtIHNv
bHV0aW9uLg0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMv
NTUNCg0KSy4NCg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9k
IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KUmVwbHktVG86IEp1
ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl
Pg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAyMywgMjAxOCBhdCAxMDowMCBBTQ0KVG86IE1hcnRp
biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPg0KQ2M6ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRt
b2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0geHBhdGggZXhwcmVzc2lvbnMgaW4g
SlNPTg0KDQpPbiBUdWUsIE9jdCAyMywgMjAxOCBhdCAwMzo0MjozNVBNICswMjAwLCBNYXJ0aW4g
QmpvcmtsdW5kIHdyb3RlOg0KDQo+ID4gSSB3b3VsZCBzdWdnZXN0IHRvIGV4dGVuZCB0aGUgZGVm
aW5pdGlvbiBvZiB0aGUgInhwYXRoMS4wIiB0eXBlIHdpdGggdGhlDQo+ID4gY29ycmVzcG9uZGlu
ZyBzcGVjaWZpY2F0aW9uIG9mIHRoZSBkZWZhdWx0IFhQYXRoIGNvbnRleHQuDQo+IA0KPiBZZXMs
IHNvbWV0aGluZyBmb3IgNjk5MWJpcy4NCj4gDQo+IE1lYW53aGlsZSwgZm9yIFNOLCB3ZSBjYW4g
YWRkIHRoaXMgYWxyZWFkeSB0aGVyZSBmb3Igc3RyZWFtLXhwYXRoLWZpbHRlci4NCg0KSSBhbSBu
b3Qgc3VyZSB3aGV0aGVyIGEgbmV3IHR5cGUgZGVmaW5pdGlvbiBpcyBuZWVkZWQgb3IganVzdCBz
b21lDQpjbGFyaWZpY2F0aW9uIG9mIHRoZSBjdXJyZW50IHhwYXRoMS4wIGRlZmluaXRpb24uIFBl
cmhhcHMgYSBuZXcNCmRlZmluaXRpb24gcGx1cyBkZXByZWNhdGlvbiBvZiB0aGUgeHBhdGgxLjAg
ZGVmaW5pdGlvbiBpcyB0aGUgcmlnaHQNCnRoaW5nIHRvIGRvLiBJIGhhdmUgYWRkZWQgdGhpcyB0
byBteSBsaXN0IG9mIHBvc3NpYmxlIGNoYW5nZXMgdG8NClJGQyA2OTkxLg0KDQovanMNCg0KLS0g
DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l
biBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwg
Mjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu
amFjb2JzLTJEdW5pdmVyc2l0eS5kZV8mZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZtPU9ZR19meGZmd0NKT1d1ZUFUTWU5YjczVk1FQVBKb1pXLUxja0RDd3ctelEm
cz1oNElfYWZxUXh2NTlZakNwbVFvTVNNRWFGU0NJTnVvc3A4NERURklnWVM4JmU9Pg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp
bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1v
ZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09T1lHX2Z4ZmZ3
Q0pPV3VlQVRNZTliNzNWTUVBUEpvWlctTGNrREN3dy16USZzPWJOcFZtTHR3NmNya214QjNGRmVC
QzhHY3FOM0NjSjkydWcyX2hDRkQzajAmZT0NCg0K


From nobody Wed Oct 24 19:34:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2304130DEC for ; Wed, 24 Oct 2018 19:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNqHAI9yHUaT for ; Wed, 24 Oct 2018 19:34:17 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 1B725130DDF for ; Wed, 24 Oct 2018 19:34:17 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C55EE1E08F1 for ; Wed, 24 Oct 2018 20:34:16 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id FVTUgO2jGE0jMFVTUgnIRS; Wed, 24 Oct 2018 20:34:16 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=P1YnwRB7sJPBEmsXZt4K+PnCZZ7uPmPd5ZndT+YZ1pk=; b=qdW3YEGGXc/I/4HR2HaZGXFpeH maGfIctWZi2ovoj0Hhc8REL5QKeUFrsmkmjTfWyALvIE04lJFrdSud8UU9sI33atejqjxavXnkalW y8OGAF9xTtHrhEOrx0GNvoU7Y;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:49678 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gFVTU-000Nat-J6; Wed, 24 Oct 2018 20:34:16 -0600
From: Lou Berger 
To: NetMod WG Chairs , NetMod WG 
Message-ID: <842302b3-7d1d-a6b9-2d75-88626d32bd53@labn.net>
Date: Wed, 24 Oct 2018 22:34:14 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gFVTU-000Nat-J6
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:49678
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Draft IETF103 agenda uploaded
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 02:34:19 -0000

Hi,

     A draft agenda is available at: 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-netmod

Please take a look and send any question/comments/corrections you may have.
Thank you,

Lou (Kent and Joel)



From nobody Thu Oct 25 00:05:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20512D4F2 for ; Thu, 25 Oct 2018 00:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level: 
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 H7NvXZQAlHKC for ; Thu, 25 Oct 2018 00:05:04 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 1DEDB12F18C for ; Thu, 25 Oct 2018 00:05:04 -0700 (PDT)
Received: from [IPv6:2601:647:4201:4561:6502:25ec:21ee:cd18] ([IPv6:2601:647:4201:4561:6502:25ec:21ee:cd18]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9P752uG033394 for ; Thu, 25 Oct 2018 07:05:03 GMT (envelope-from joelja@bogus.com)
From: Joel Jaeggli 
Content-Type: multipart/alternative; boundary="Apple-Mail=_225DFFBC-1197-4B32-AC23-913590F37413"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Thu, 25 Oct 2018 00:05:02 -0700
References: 
To: NETMOD Working Group 
In-Reply-To: 
Message-Id: <69F1E71B-CD7C-453A-AB78-C4F74AD0CC5E@bogus.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 07:05:07 -0000

--Apple-Mail=_225DFFBC-1197-4B32-AC23-913590F37413
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This WG LC closed on the 16th.=20

Working group last calls serve a useful forcing function even for drafts =
that may end up looking unready as a result due to the attention. If I =
am making a judgement call here based on the feedback received during =
this period and the prior one.

I will try and summarize the major concerns that  see expressed with =
this draft.

Jurgen had a significant list of comments and edits

https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg =
=


Followed up by Christian

One detail teased out there and in other comments bears revisting

            Juergen
> I do not like this. YANG has extension statements and having to

> parse stuff out of free text description statements seems to be a

> movement backwards.


Christian
This is used by the human implementer of the module (i.e., they need to =
write code to implement the module). As such it was not intended for =
machine parsing.

Juergon
I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.

Andy=20

It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag =
conformance,
in addition to the module-tag mappings.

Alex

I have no issue with systems using tags to classify or organize modules, =
however this seems to me like something that would be specific to the =
system doing the classifying. It would not be something that needs to be =
specified in the module itself (except perhaps as freeform description =
text), and it certainly would not need to involve the NETCONF server. =
What would a server do with module classification data? (unless it is =
also implementing some kind of module browsing interface, in which case =
it might be used to supply the browser with data)

Wether or not this is intended for or will be parsed by machines remains =
a significant unresolved concern. The actual mechanics of restricting =
what goes into them however seems fairly straight forward.

Absent consensus on the above concern this document cannot probably =
advance, we do have the opportunity for significant face to face =
discussion in the near future so using that to arrive at a conclusion =
would probably allow this work to progress or stop.

Thanks
Joel

> On Oct 2, 2018, at 13:21, joel jaeggli  wrote:
>=20
> This is start of a two week working group last-call for
> draft-ietf-netmod-module-tags-02 a current netmod working group
> document.
>=20
> You may review at:
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>=20
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd =
like
> to see addressed once the document is a WG document.
>=20
> The prior discussion of my mistaken WG adoption call is here
>=20
> commences here:
>=20
> https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html
>=20
> In particular Andy's concerns expressed in that thread here:
>=20
> https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html
>=20
> are probably important to tease out in considering this for last call.
>=20
> so that we are clear on dates. This last call timing resets and runs
> from 10/2/18 - 10/16/18
>=20
> Joel
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_225DFFBC-1197-4B32-AC23-913590F37413
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This =
WG LC closed on the 16th. 

Working group last calls serve a useful forcing function even =
for drafts that may end up looking unready as a result due to the =
attention. If I am making a judgement call here based on the feedback =
received during this period and the prior one.

I will try and summarize the major =
concerns that  see expressed with this draft.

Jurgen had a significant =
list of comments and edits

https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r=
3P7R0nirg

Followed up by Christian

One detail teased out there and in =
other comments bears revisting

            =
Juergen
I do not like this. YANG has extension statements and having =
to
parse stuff out of free text description statements seems to =
be a
movement =
backwards.

Christian
This is =
used by the human implementer of the module (i.e., they need to write =
code to implement the module). As such it was not intended for machine =
parsing.

Juergon
I am =
personally not convinced. The whole reason why we have YANG =
is
automation and I believe people will =
go and write tools to extract
tags and =
having to extract them out of free form text looks like =
a
step backwards.

Andy 

It is more than a step backwards.
There =
is an unexplained procedure for declaring the  module-tag =
conformance,
in addition to the module-tag =
mappings.

Alex

I have no issue with systems using tags to classify or =
organize modules, however this seems to me like something that would be =
specific to the system doing the classifying. It would not be =
something that needs to be specified in the module itself (except =
perhaps as freeform description text), and it certainly would not need =
to involve the NETCONF server. What would a server do with module =
classification data? (unless it is also implementing some kind of module =
browsing interface, in which case it might be used to supply the browser =
with data)

Wether or not this is intended for or will be =
parsed by machines remains a significant unresolved concern. The actual =
mechanics of restricting what goes into them however seems fairly =
straight forward.

Absent consensus =
on the above concern this document cannot probably advance, we do have =
the opportunity for significant face to face discussion in the near =
future so using that to arrive at a conclusion would probably allow this =
work to progress or stop.

Thanks
Joel

On Oct =
2, 2018, at 13:21, joel jaeggli <joelja@bogus.Jcom> wrote:

This =
is start of a two week working group last-call for
draft-ietf-netmod-module-tags-02 a current netmod working =
group
document.

You may =
review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating =
"yes/support" or "no/do not
support".  If indicating =
no, please state your reservations with the
document. =
 If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

The prior discussion of my mistaken WG =
adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.h=
tml

In particular Andy's concerns expressed =
in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.h=
tml

are probably important to tease out in =
considering this for last call.

so that we =
are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel

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

=

--Apple-Mail=_225DFFBC-1197-4B32-AC23-913590F37413--


From nobody Thu Oct 25 00:11:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18025130DDC for ; Thu, 25 Oct 2018 00:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level: 
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 hiO7sYDw0XWe for ; Thu, 25 Oct 2018 00:11:47 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 1238D12F18C for ; Thu, 25 Oct 2018 00:11:47 -0700 (PDT)
Received: from [192.168.0.110] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9P7BjvV033441; Thu, 25 Oct 2018 07:11:46 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.110]
From: Joel Jaeggli 
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB20FB28-C269-494F-B6AF-4915FFD732C9"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Thu, 25 Oct 2018 00:11:39 -0700
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
To: Lou Berger , NETMOD Working Group 
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Message-Id: <94A13A85-AD76-4C18-9425-144105AE5ED4@bogus.com>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 07:11:49 -0000

--Apple-Mail=_AB20FB28-C269-494F-B6AF-4915FFD732C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Suupport

   Scan the artwork for horizontal tab characters.  If any horizontal
   tab characters appear, either resolve them to space characters or
   exit, forcing the input provider to convert them to space characters
   themselves first.

Support this only more strongly, e.g.  the general prohibition against =
tabs is fine. it is hard if not impossible to get 4 implementers in a =
room  to agree  how many spaces a tab should be.

> On Oct 18, 2018, at 06:03, Lou Berger  wrote:
>=20
> All,
>=20
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>=20
> The poll ends Oct 1.
>=20
> Thanks,
>=20
> Lou (and co-chairs)
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20


--Apple-Mail=_AB20FB28-C269-494F-B6AF-4915FFD732C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Suupport

   Scan the artwork for horizontal tab characters.  If any =
horizontal
   tab characters appear, either resolve them to space characters or
   exit, forcing the input provider to convert them to space characters
   themselves first.


Support this =
only more strongly, e.g.  the general prohibition against tabs is =
fine. it is hard if not impossible to get 4 implementers in a room =
 to agree  how many spaces a tab should be.

On Oct 18, 2018, at 06:03, Lou Berger <lberger@labn.net> =
wrote:

All,

This is start of a two week =
poll on making
draft-kwatsen-netmod-artwork-folding-08 a =
working group
document. Please send email to the list =
indicating "yes/support" or
"no/do not support".  If =
indicating no, please state your reservations
with the =
document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG =
document.

The poll ends Oct 1.

Thanks,

Lou (and =
co-chairs)

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


=

--Apple-Mail=_AB20FB28-C269-494F-B6AF-4915FFD732C9--


From nobody Thu Oct 25 01:01:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278A8128CF2 for ; Thu, 25 Oct 2018 01:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mg-soft.si
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 o6oshsWC3C7z for ; Thu, 25 Oct 2018 01:01:10 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 12C8B12D4F2 for ; Thu, 25 Oct 2018 01:01:08 -0700 (PDT)
Received: from [10.0.3.146] (dhcp-146.mg-soft.si [10.0.3.146]) by galileo.mg-soft.si (Postfix) with ESMTP id DE9B2C4175C2; Thu, 25 Oct 2018 10:01:07 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si DE9B2C4175C2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1540454467; bh=VRxjoL5s0yIapgAMOgCIUa+BPVQ4mxIFxngw8tIaCUM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ESuoBvIhdbRS9Og7LNHoDSCP6VbPkjXVToPwRKRVDznaay7ZAUpn/NWnYx5wRVr3F UPaut3b+27SygTwcUtBEAkTjLmvbaGCTnKVfH7PdoKwEui8toRiDXZ1aarPhOgOuaT cIpI+tUT3+j8BLbrJ+XNstHArWKthkHc+N76Kl0TFdCHAD4Cqwoc4SD1b15IX3W5ID MtSFyysnOSXXfNQ5xy6f4HxxLKGwFWN1Sj2SyyC5Zvf7X6WGZ72Gt8RBNTLPPcSN6g t9ZfWvQ6iGgY/TOs2sFoA2xUDhPeTg3IbNL8Dkk6Txq42/mDARvummqBhqkwPk7nrS MDRHMayie+KTg==
To: Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20181023.161158.1837797983440028086.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <5b521a81-98cb-8af4-f093-f514f035fcc4@mg-soft.si>
Date: Thu, 25 Oct 2018 10:01:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20181023.161158.1837797983440028086.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] Quirky tree diagrams [was: Re: "input"/"output" in tree diagrams]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 08:01:13 -0000

What about inner groupings? Are inner groupings supposed to be displayed 
if top-level ones are? If so, how? RFC7895 (YANG library module) is an 
example - if you choose to display but not to expand groupings, you may 
get "+---u"'s that refer to groupings which may never be part of the 
diagram.

Jernej


On 23/10/2018 16:11, Martin Bjorklund wrote:
> Hi,
>
> Jernej Tuljak  wrote:
>> Hi,
>>
>> am I reading RFC8340 correctly by assuming "input" and "output" nodes
>> are not to be part of tree diagrams and that instead input/output
>> parameters are now children to the "rpc" or "action" node,
>> distinguished solely via -w/ro flags?
> I hope not, or that was not the intention anyway.
>
>>    rpcs:
>>      +---x get-schema
>>         +---w identifier! string
>>         +---w version?    string
>>         +---w format?     identityref
>>         +--ro data?
> pyang outputs
>
>      +---x get-schema
>         +---w input
>         |  +---w identifier    string
>         |  +---w version?      string
>         |  +---w format?       identityref
>         +--ro output
>            +--ro data?   
>
>
>> Only "input parameters" and "output parameters" are mentioned, which
>> seems to suggest data node children of "input" and "output", but not
>> themselves. It also says nothing about which flag they receive, if
>> they are intended to appear.
> Yes I can see how this could be clarified.
>
>
> /martin


From nobody Thu Oct 25 06:12:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07540130E3E for ; Thu, 25 Oct 2018 06:12:38 -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, 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 kQBq7iTDhfzr for ; Thu, 25 Oct 2018 06:12:35 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id CD624130E3D for ; Thu, 25 Oct 2018 06:12:34 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 21B6760064; Thu, 25 Oct 2018 13:12:33 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps 
In-Reply-To: <69F1E71B-CD7C-453A-AB78-C4F74AD0CC5E@bogus.com>
Date: Thu, 25 Oct 2018 09:12:32 -0400
Cc: Christian Hopps , NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <69F1E71B-CD7C-453A-AB78-C4F74AD0CC5E@bogus.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 13:12:38 -0000

Hi Joel, WG,

I published a new draft some days ago covering the specific concerns and =
editorial changes requested during WGLC. This included the addition of =
an extension statement which covered machine parsing of pre-defined tags =
which was mentioned by multiple people, and is the only significant =
change made. I would think we'd have rough consensus (at least) at this =
point.

I do not agree that we should restrict the usefulness of this work by =
removing the ability of the module author or the vendor/implementer to =
add tags due to a single persons view of how they might use the =
technology. There's nothing gained, and there's obvious loss of =
functionality.

Thanks,
Chris.

> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli  wrote:
>=20
> This WG LC closed on the 16th.=20
>=20
> Working group last calls serve a useful forcing function even for =
drafts that may end up looking unready as a result due to the attention. =
If I am making a judgement call here based on the feedback received =
during this period and the prior one.
>=20
> I will try and summarize the major concerns that  see expressed with =
this draft.
>=20
> Jurgen had a significant list of comments and edits
>=20
> =
https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
>=20
> Followed up by Christian
>=20
> One detail teased out there and in other comments bears revisting
>=20
>             Juergen
>> I do not like this. YANG has extension statements and having to
>> parse stuff out of free text description statements seems to be a
>> movement backwards.
>=20
> Christian
> This is used by the human implementer of the module (i.e., they need =
to write code to implement the module). As such it was not intended for =
machine parsing.
>=20
> Juergon
> I am personally not convinced. The whole reason why we have YANG is
> automation and I believe people will go and write tools to extract
> tags and having to extract them out of free form text looks like a
> step backwards.
>=20
> Andy=20
>=20
> It is more than a step backwards.
> There is an unexplained procedure for declaring the  module-tag =
conformance,
> in addition to the module-tag mappings.
>=20
> Alex
>=20
> I have no issue with systems using tags to classify or organize =
modules, however this seems to me like something that would be specific =
to the system doing the classifying. It would not be something that =
needs to be specified in the module itself (except perhaps as freeform =
description text), and it certainly would not need to involve the =
NETCONF server. What would a server do with module classification data? =
(unless it is also implementing some kind of module browsing interface, =
in which case it might be used to supply the browser with data)
>=20
> Wether or not this is intended for or will be parsed by machines =
remains a significant unresolved concern. The actual mechanics of =
restricting what goes into them however seems fairly straight forward.
>=20
> Absent consensus on the above concern this document cannot probably =
advance, we do have the opportunity for significant face to face =
discussion in the near future so using that to arrive at a conclusion =
would probably allow this work to progress or stop.
>=20
> Thanks
> Joel
>=20
>> On Oct 2, 2018, at 13:21, joel jaeggli  wrote:
>>=20
>> This is start of a two week working group last-call for
>> draft-ietf-netmod-module-tags-02 a current netmod working group
>> document.
>>=20
>> You may review at:
>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>>=20
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd =
like
>> to see addressed once the document is a WG document.
>>=20
>> The prior discussion of my mistaken WG adoption call is here
>>=20
>> commences here:
>>=20
>> https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html
>>=20
>> In particular Andy's concerns expressed in that thread here:
>>=20
>> https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html
>>=20
>> are probably important to tease out in considering this for last =
call.
>>=20
>> so that we are clear on dates. This last call timing resets and runs
>> from 10/2/18 - 10/16/18
>>=20
>> Joel
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Oct 25 07:02:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D072130E65 for ; Thu, 25 Oct 2018 07:02:54 -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, 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 c3dg-K7nilNE for ; Thu, 25 Oct 2018 07:02:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B938B130E63 for ; Thu, 25 Oct 2018 07:02:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 5450C1AE0365; Thu, 25 Oct 2018 16:02:48 +0200 (CEST)
Date: Thu, 25 Oct 2018 16:02:47 +0200 (CEST)
Message-Id: <20181025.160247.188082468679637970.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5b521a81-98cb-8af4-f093-f514f035fcc4@mg-soft.si>
References:  <20181023.161158.1837797983440028086.mbj@tail-f.com> <5b521a81-98cb-8af4-f093-f514f035fcc4@mg-soft.si>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Quirky tree diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 14:02:54 -0000

Jernej Tuljak  wrote:
> What about inner groupings? Are inner groupings supposed to be
> displayed if top-level ones are?

RFC 8340 only specifies the format for top-level groupings; i.e.,
inline groupings are not displayed separately in the tree diagram.


/martin


> If so, how? RFC7895 (YANG library
> module) is an example - if you choose to display but not to expand
> groupings, you may get "+---u"'s that refer to groupings which may
> never be part of the diagram.
> =

> Jernej
> =

> =

> On 23/10/2018 16:11, Martin Bjorklund wrote:
> > Hi,
> >
> > Jernej Tuljak  wrote:
> >> Hi,
> >>
> >> am I reading RFC8340 correctly by assuming "input" and "output" no=
des
> >> are not to be part of tree diagrams and that instead input/output
> >> parameters are now children to the "rpc" or "action" node,
> >> distinguished solely via -w/ro flags?
> > I hope not, or that was not the intention anyway.
> >
> >>  =A0 rpcs:
> >>  =A0=A0=A0 +---x get-schema
> >>  =A0=A0=A0=A0=A0=A0 +---w identifier! string
> >>  =A0=A0=A0=A0=A0=A0 +---w version?=A0=A0=A0 string
> >>  =A0=A0=A0=A0=A0=A0 +---w format?=A0=A0=A0=A0 identityref
> >>  =A0=A0=A0=A0=A0=A0 +--ro data?
> > pyang outputs
> >
> >      +---x get-schema
> >         +---w input
> >         |  +---w identifier    string
> >         |  +---w version?      string
> >         |  +---w format?       identityref
> >         +--ro output
> >            +--ro data?   
> >
> >
> >> Only "input parameters" and "output parameters" are mentioned, whi=
ch
> >> seems to suggest data node children of "input" and "output", but n=
ot
> >> themselves. It also says nothing about which flag they receive, if=

> >> they are intended to appear.
> > Yes I can see how this could be clarified.
> >
> >
> > /martin
> =


From nobody Thu Oct 25 08:26:29 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EE9130E7C; Thu, 25 Oct 2018 08:26:28 -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, 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 iYVRZDU8aMg5; Thu, 25 Oct 2018 08:26:27 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0E03130E76; Thu, 25 Oct 2018 08:26:26 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 3231060068; Thu, 25 Oct 2018 15:26:26 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Christian Hopps 
In-Reply-To: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
Date: Thu, 25 Oct 2018 11:26:25 -0400
Cc: Christian Hopps , "netmod@ietf.org" ,  "netmod-ver-dt@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
To: Joe Clarke 
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 15:26:28 -0000

> On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
>=20
> * New requirement 1.4 for supporting over-arching software releases

[ I read this as supporting various different module versions based on a =
vendor's different software release trains. If this is wrong then the =
rest of this doesn't apply and I would just ask for the text to be =
update to clarify what it means. ]

How many operators/users have asked for this or indicated it's a =
requirement for them?

What problem is intractable without this requirement being met, and what =
is the cost of this requirement on the actual users?

I have pushed back multiple times on this b/c I believe this =
"requirement" is really being pushed to make it easier for vendors (a =
small affected group) to develop their software at the cost of their =
users (the much larger affected group) who would then have to deal with =
multiple trains of the same module.

Here is what I am afraid the vendors want here: A developer on release =
train X can easily change some data structure and then push the change =
into an automated system which generates a new YANG module definition =
and revs a version number -- all done! They don't have to deal with the =
inertia of making this change in their release train Y or Z and they =
don't have to treat modules as a stable API they are exporting, b/c they =
now have these new wonderful versions from this work. Meanwhile we the =
users now have to deal with N forks with all the various little =
incompatible changes random developers at the company wanted to make =
without having to coordinate with their coworkers/other internal teams. =
Now multiply this by M vendors. It's a nightmare. It shouldn't be what =
we are optimizing for, let alone making a requirement.

We already have features and deviations why are they not enough to deal =
with functionality that is present or not in various software =
release/devices?

FWIW I'm not against making it easier to develop software, but we have =
to be mindful if we are just pushing the cost (and magnifying it =
greatly) to other people in the community.

Thanks,
Chris.


From nobody Thu Oct 25 09:29:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A01130E6A; Thu, 25 Oct 2018 09:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 MEGs7A7CKKjW; Thu, 25 Oct 2018 09:29: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 7C6C6128BCC; Thu, 25 Oct 2018 09:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4193; q=dns/txt; s=iport; t=1540484979; x=1541694579; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+HGUMolZGhrNEKv0vy7zdD2BMse7wzEmU843IZZ0rnw=; b=Ffx7A86M4g1q1+GUpikHNmXysW6/MuDRFlsVQI51+cF8y/OZoxkECsAp f7B/S2CHzo8E4ZCGjewGyDg/dw99shACqafN5Uau34q8G2o69TY3X441n +bpZylxhag2ym4ueSS0lVVhYj1T1hHIn9B8OKAfJXf1nc9skKrb+3fFbX w=;
X-IronPort-AV: E=Sophos;i="5.54,424,1534809600";  d="scan'208";a="7530775"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 16:29:37 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w9PGTbil023728; Thu, 25 Oct 2018 16:29:37 GMT
To: Christian Hopps 
Cc: Joe Clarke , "netmod-ver-dt@ietf.org" , "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
From: Robert Wilton 
Message-ID: 
Date: Thu, 25 Oct 2018 17:29:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 16:29:42 -0000

Hi Chris,

I think that there are two things driving this requirement:

What I regard as the key one, is that we want to be able to support the 
software that we have shipped.  In particular, we may need to fix bugs 
(perhaps at the operators request) to a YANG model that has already been 
released.  I.e. I think that there are some scenarios, where forking a 
YANG module, although undesirable is the right thing to do to include a 
fix.  I don't believe that features or deviations help solve this problem.

The two alternative solutions to being able to fix bugs, neither of 
which I think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they ship 
in a release.
(ii) If a bug is reported, operators are happy to wait until the bug has 
been fixed in the current development release, and will migrate to that 
latest release to pick up the fix.

The second thing driving this requirement is that vendors sometimes get 
asked for enhancements to existing releases, perhaps because the latest 
development release is too far out, or ask for an enhancement on the 
current train to be back ported to an older release.

So, aiming to have stable YANG modules, trying a lot harder to avoid 
non-backwards-compatible changes, and keeping new functionality to the 
head of the development I completely agree with you on.  But I still 
believe that there are some valid scenarios, that should be limited as 
much as possible, where it is necessary to make changes that sometimes 
break these rules, and having a limited scheme that clearly indicates 
where such breakages have occurred is probably better that the status 
quo of where the modules get changed, but the operator doesn't get any 
useful indication of what type of changes are being made.

Thanks,
Rob


On 25/10/2018 16:26, Christian Hopps wrote:
>
>> On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
>>
>> * New requirement 1.4 for supporting over-arching software releases
> [ I read this as supporting various different module versions based on a vendor's different software release trains. If this is wrong then the rest of this doesn't apply and I would just ask for the text to be update to clarify what it means. ]
>
> How many operators/users have asked for this or indicated it's a requirement for them?
>
> What problem is intractable without this requirement being met, and what is the cost of this requirement on the actual users?
>
> I have pushed back multiple times on this b/c I believe this "requirement" is really being pushed to make it easier for vendors (a small affected group) to develop their software at the cost of their users (the much larger affected group) who would then have to deal with multiple trains of the same module.
>
> Here is what I am afraid the vendors want here: A developer on release train X can easily change some data structure and then push the change into an automated system which generates a new YANG module definition and revs a version number -- all done! They don't have to deal with the inertia of making this change in their release train Y or Z and they don't have to treat modules as a stable API they are exporting, b/c they now have these new wonderful versions from this work. Meanwhile we the users now have to deal with N forks with all the various little incompatible changes random developers at the company wanted to make without having to coordinate with their coworkers/other internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't be what we are optimizing for, let alone making a requirement.
>
> We already have features and deviations why are they not enough to deal with functionality that is present or not in various software release/devices?
>
> FWIW I'm not against making it easier to develop software, but we have to be mindful if we are just pushing the cost (and magnifying it greatly) to other people in the community.
>
> Thanks,
> Chris.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Oct 25 10:08:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91A130EC9 for ; Thu, 25 Oct 2018 10:07:59 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 Quenb4Fc5LmJ for ; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 670D0130EC7 for ; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id s15-v6so8951221lji.3 for ; Thu, 25 Oct 2018 10:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JuyI4uDur2JN1Q+HiE7cTQ/9M+8ZzsTQXGvpAv4nO2E=; b=YHwK6s73nsmU9bOtqn6evSvuZSWiPyVFJWYjPctfNEZypnNaSzuQYO9KHUjweRmYBO RJhgZNvHPTrJFTxVMJsPrmbSdVjA2/Q+kswWq3VLOX9f+/lqRUryOA+fmbGcUhn0Ll5Y SYl3Q+1KSWte64wHONEKI05raPSt+0yMPTwU8WXS4oQOeir6Ivypu7X1VTXLuLCcGKyE qyi7fJ7l44nBGoxIHMb6XaemIpYOkmCBpngvBQuVgtWTLdVRsjxFPoBH1ixRuUSmp16i dROilHeJZrDHib8Ox9QXLU5CyXMMHzLV8lUbJ90fYudNPsWm1CqmTG+OJGh2AoDVXzNX 0Tdg==
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=JuyI4uDur2JN1Q+HiE7cTQ/9M+8ZzsTQXGvpAv4nO2E=; b=XD9fux0QWOEYh5nLsrfSR9IdFtOYvBo1b9mIGhOsfhd9lWWQ+RK5y6TmtPqfobdLEl fGhgeivYqdUb7vMq9StcPwmabuEzS1/ZXmIOoSgO5PCwiI90qkR+9xI/TLM35a0VP0KH n+0ja0M7Zxa5eDicMLnZauk3SqFOxFx67f549A2m+n6nopxGP7Xw2AyOVNEqHkGE99Zu kWU8KmgB2BoGyb90Ztwmnq0Bx1o6JvwQaD7ACscX8+CWZf+BPGH1x02a1KUORm1RkWFY 5n/IBnurTuA4m9UKR+1kz4zi/nqoHR+u69Ba2V3YHVODV/JervHRhvDIZqeiWw7Y7HJs 5qzQ==
X-Gm-Message-State: AGRZ1gKvlIKNroX5sRt/bWsunXaPxG2ROFI1OqYWYIbuuPA8ZkBUA2XS zEckTZ+W3DNUkbgfLEeTDubFFiRLO9Re8lfyNU48QA==
X-Google-Smtp-Source: AJdET5co7htbJUH6QrN9zxUunzC4BWgIVOkbCz3DoSbPcYcVmjLdYA+QXsJmxbolYV4xf95axlr9bQpnLbcco2q+xQ8=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr43818lja.21.1540487275310;  Thu, 25 Oct 2018 10:07:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 25 Oct 2018 10:07:54 -0700 (PDT)
In-Reply-To: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>
From: Andy Bierman 
Date: Thu, 25 Oct 2018 10:07:54 -0700
Message-ID: 
To: Christian Hopps 
Cc: Joe Clarke , "netmod-ver-dt@ietf.org" ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d3832f057910a471"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 17:08:00 -0000

--000000000000d3832f057910a471
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 25, 2018 at 8:26 AM, Christian Hopps  wrote:

>
>
> > On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
> >
> > * New requirement 1.4 for supporting over-arching software releases
>
>
This text?

       1.4  The solution MUST allow for modules to be versioned by
            software release.  In particular, backwards-compatible
            enhancements and bug fixes MUST be allowed in any non-latest
            release.



IMO these requirements are mostly intended to legitimize bad practices be
server vendors,
entirely at the expense of client developers.

It is clear that SEMVER is required to support this requirement to
treat every platform as an isolated release of what are supposed to be
shared modules.
The revision date no longer identifies the latest (e.g, 1.6.1 could have a
newer date than 1.9.0)
However, SEMVER becomes less useful if 1.6.1 actually has more features
than 1.9.0.

YANG clients already have to deal with different variants (revision,
features, deviations) on every server,
so it would be easy to think that all these server variants are not a new
problem.
However, this only applies to parsing incoming data.  A client that is
designed to
formulate requests against specific data models is greatly harmed by a lack
of server
consistency.

If YANG is ever going to grow up, the 3rd party client development needs to
be taken more seriously.


Andy


[ I read this as supporting various different module versions based on a
> vendor's different software release trains. If this is wrong then the rest
> of this doesn't apply and I would just ask for the text to be update to
> clarify what it means. ]
>
> How many operators/users have asked for this or indicated it's a
> requirement for them?
>
> What problem is intractable without this requirement being met, and what
> is the cost of this requirement on the actual users?
>
> I have pushed back multiple times on this b/c I believe this "requirement"
> is really being pushed to make it easier for vendors (a small affected
> group) to develop their software at the cost of their users (the much
> larger affected group) who would then have to deal with multiple trains of
> the same module.
>
> Here is what I am afraid the vendors want here: A developer on release
> train X can easily change some data structure and then push the change into
> an automated system which generates a new YANG module definition and revs a
> version number -- all done! They don't have to deal with the inertia of
> making this change in their release train Y or Z and they don't have to
> treat modules as a stable API they are exporting, b/c they now have these
> new wonderful versions from this work. Meanwhile we the users now have to
> deal with N forks with all the various little incompatible changes random
> developers at the company wanted to make without having to coordinate with
> their coworkers/other internal teams. Now multiply this by M vendors. It's
> a nightmare. It shouldn't be what we are optimizing for, let alone making a
> requirement.
>
> We already have features and deviations why are they not enough to deal
> with functionality that is present or not in various software
> release/devices?
>
> FWIW I'm not against making it easier to develop software, but we have to
> be mindful if we are just pushing the cost (and magnifying it greatly) to
> other people in the community.
>
> Thanks,
> Chris.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Thu, Oct 25, 2018 at 8:26 AM, Christian Hopps <cho=
pps@chopps.org> wrote:




> On Oct 20, 2018, at 1:55 PM, Joe Clarke <jclarke@cisco.com> wrote:

> 

> * New requirement 1.4 for supporting over-arching software releases


This text?

       1.4  The solution =
MUST allow for modules to be versioned by
            software release.  In particular, backwards-compatible
            enhancements and bug fixes MUST be allowed in any non-latest
            release.


=C2=A0
IMO these requirements are=
 mostly intended to legitimize bad practices be server vendors,
e=
ntirely at the expense of client developers.

It is=
 clear that SEMVER is required to support this requirement to
tre=
at every platform as an isolated release of what are supposed to be shared =
modules.
The revision date no longer identifies the latest (e.g, =
1.6.1 could have a newer date than 1.9.0)
However, SEMVER becomes=
 less useful if 1.6.1 actually has more features than 1.9.0.

=

YANG clients already have to deal with different variants (revis=
ion, features, deviations) on every server,
so it would be easy t=
o think that all these server variants are not a new problem.
How=
ever, this only applies to parsing incoming data.=C2=A0 A client that is de=
signed to
formulate requests against specific data models is grea=
tly harmed by a lack of server
consistency.

<=
div>If YANG is ever going to grow up, the 3rd party client development need=
s to be taken more seriously.


Andy<=
/div>



[ I read this as supporting various different module versions based on a ve=
ndor's different software release trains. If this is wrong then the res=
t of this doesn't apply and I would just ask for the text to be update =
to clarify what it means. ]



How many operators/users have asked for this or indicated it's a requir=
ement for them?



What problem is intractable without this requirement being met, and what is=
 the cost of this requirement on the actual users?



I have pushed back multiple times on this b/c I believe this "requirem=
ent" is really being pushed to make it easier for vendors (a small aff=
ected group) to develop their software at the cost of their users (the much=
 larger affected group) who would then have to deal with multiple trains of=
 the same module.



Here is what I am afraid the vendors want here: A developer on release trai=
n X can easily change some data structure and then push the change into an =
automated system which generates a new YANG module definition and revs a ve=
rsion number -- all done! They don't have to deal with the inertia of m=
aking this change in their release train Y or Z and they don't have to =
treat modules as a stable API they are exporting, b/c they now have these n=
ew wonderful versions from this work. Meanwhile we the users now have to de=
al with N forks with all the various little incompatible changes random dev=
elopers at the company wanted to make without having to coordinate with the=
ir coworkers/other internal teams. Now multiply this by M vendors. It's=
 a nightmare. It shouldn't be what we are optimizing for, let alone mak=
ing a requirement.



We already have features and deviations why are they not enough to deal wit=
h functionality that is present or not in various software release/devices?=




FWIW I'm not against making it easier to develop software, but we have =
to be mindful if we are just pushing the cost (and magnifying it greatly) t=
o other people in the community.



Thanks,

Chris.



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--000000000000d3832f057910a471--


From nobody Thu Oct 25 10:43:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174D6130DFC; Thu, 25 Oct 2018 10:42:53 -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, 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 0SwpZVt1WOpR; Thu, 25 Oct 2018 10:42:50 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DC30C130F55; Thu, 25 Oct 2018 10:42:45 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 118626007B; Thu, 25 Oct 2018 17:42:44 +0000 (UTC)
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org> 
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Robert Wilton 
Cc: Christian Hopps , Joe Clarke , "netmod-ver-dt\@ietf.org" , "netmod\@ietf.org" 
In-reply-to: 
Date: Thu, 25 Oct 2018 13:42:44 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 17:42:53 -0000

Hi Rob,

We've more privately discussed the bug-fix scenario and I'm sympathetic to it; however, the requirement as written does not restrict itself to fixing module definition bugs (e.g., a pattern or other value constraint) in some small but incompatible way -- instead it's wide open and it will be [ab]used that way.

For example:

> Here is what I am afraid the vendors want here: A developer on release train X can easily change some data structure and then push the change into an automated system which generates a new YANG module definition and revs a version number -- all done! They don't have to deal with the inertia of making this change in their release train Y or Z and they don't have to treat modules as a stable API they are exporting, b/c they now have these new wonderful versions from this work. Meanwhile we the users now have to deal with N forks with all the various little incompatible changes random developers at the company wanted to make without having to coordinate with their coworkers/other internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't be what we are optimizing for, let alone making a requirement.

Regarding enhancements, these are features, and are naturally augmentative. I find it hard to believe we have a pressing need/requirement to support non-backward compatible changes to existing modules in order to support enhancements.

Thanks,
Chris.


Robert Wilton  writes:

> Hi Chris,
>
> I think that there are two things driving this requirement:
>
> What I regard as the key one, is that we want to be able to support the software
> that we have shipped. In particular, we may need to fix bugs (perhaps at the
> operators request) to a YANG model that has already been released. I.e. I think
> that there are some scenarios, where forking a YANG module, although undesirable
> is the right thing to do to include a fix. I don't believe that features or
> deviations help solve this problem.
> The two alternative solutions to being able to fix bugs, neither of which I
> think is pragmatic, that I can think of are:
> (i) Vendors ensure that their YANG modules are perfect before they ship in a
> release.
> (ii) If a bug is reported, operators are happy to wait until the bug has been
> fixed in the current development release, and will migrate to that latest
> release to pick up the fix.
>
> The second thing driving this requirement is that vendors sometimes get asked
> for enhancements to existing releases, perhaps because the latest development
> release is too far out, or ask for an enhancement on the current train to be
> back ported to an older release.
>
> So, aiming to have stable YANG modules, trying a lot harder to avoid
> non-backwards-compatible changes, and keeping new functionality to the head of
> the development I completely agree with you on. But I still believe that there
> are some valid scenarios, that should be limited as much as possible, where it
> is necessary to make changes that sometimes break these rules, and having a
> limited scheme that clearly indicates where such breakages have occurred is
> probably better that the status quo of where the modules get changed, but the
> operator doesn't get any useful indication of what type of changes are being
> made.
>
> Thanks,
> Rob
>
>
> On 25/10/2018 16:26, Christian Hopps wrote:
>>
>>> On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
>>>
>>> * New requirement 1.4 for supporting over-arching software releases
>> [ I read this as supporting various different module versions based on a vendor's different software release trains. If this is wrong then the rest of this doesn't apply and I would just ask for the text to be update to clarify what it means. ]
>>
>> How many operators/users have asked for this or indicated it's a requirement for them?
>>
>> What problem is intractable without this requirement being met, and what is the cost of this requirement on the actual users?
>>
>> I have pushed back multiple times on this b/c I believe this "requirement" is really being pushed to make it easier for vendors (a small affected group) to develop their software at the cost of their users (the much larger affected group) who would then have to deal with multiple trains of the same module.
>>
>>
>> We already have features and deviations why are they not enough to deal with functionality that is present or not in various software release/devices?
>>
>> FWIW I'm not against making it easier to develop software, but we have to be mindful if we are just pushing the cost (and magnifying it greatly) to other people in the community.
>>
>> Thanks,
>> Chris.
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>


From nobody Thu Oct 25 15:57:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89AC128D0C for ; Thu, 25 Oct 2018 15:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 PPXayMZ8tLuy for ; Thu, 25 Oct 2018 15:57:33 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 6F8D1127B92 for ; Thu, 25 Oct 2018 15:57:33 -0700 (PDT)
Received: from [IPv6:2601:647:4201:4561:9d71:513b:3d3d:8dbc] ([IPv6:2601:647:4201:4561:9d71:513b:3d3d:8dbc]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9PMvUNL039005; Thu, 25 Oct 2018 22:57:31 GMT (envelope-from joelja@bogus.com)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Joel Jaeggli 
In-Reply-To: 
Date: Thu, 25 Oct 2018 15:57:30 -0700
Cc: NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E5893DF-2CA4-4E2A-9CF5-ABCF78620707@bogus.com>
References:  <69F1E71B-CD7C-453A-AB78-C4F74AD0CC5E@bogus.com> 
To: Christian Hopps 
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2018 22:57:36 -0000

> On Oct 25, 2018, at 06:12, Christian Hopps  wrote:
>=20
> Hi Joel, WG,
>=20
> I published a new draft some days ago covering the specific concerns =
and editorial changes requested during WGLC. This included the addition =
of an extension statement which covered machine parsing of pre-defined =
tags which was mentioned by multiple people, and is the only significant =
change made. I would think we'd have rough consensus (at least) at this =
point.

Yes, I don=E2=80=99t think we need to belabor the edits since I think =
that discussion tailed of to a reasonable conclusion.

>=20
> I do not agree that we should restrict the usefulness of this work by =
removing the ability of the module author or the vendor/implementer to =
add tags due to a single persons view of how they might use the =
technology. There's nothing gained, and there's obvious loss of =
functionality.

I=E2=80=99m trying not to inject my own opinion into prejudging an =
outcome here.=20

I do see it as significant point of contention in the working group last =
call. If I were asking for consensus on the point specifically I do not =
believe that we have arrived at a point of rough consensus yet.

> Thanks,

Thanks for getting us to this point.

Joel

> Chris.
>=20
>> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli  wrote:
>>=20
>> This WG LC closed on the 16th.=20
>>=20
>> Working group last calls serve a useful forcing function even for =
drafts that may end up looking unready as a result due to the attention. =
If I am making a judgement call here based on the feedback received =
during this period and the prior one.
>>=20
>> I will try and summarize the major concerns that  see expressed with =
this draft.
>>=20
>> Jurgen had a significant list of comments and edits
>>=20
>> =
https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
>>=20
>> Followed up by Christian
>>=20
>> One detail teased out there and in other comments bears revisting
>>=20
>>            Juergen
>>> I do not like this. YANG has extension statements and having to
>>> parse stuff out of free text description statements seems to be a
>>> movement backwards.
>>=20
>> Christian
>> This is used by the human implementer of the module (i.e., they need =
to write code to implement the module). As such it was not intended for =
machine parsing.
>>=20
>> Juergon
>> I am personally not convinced. The whole reason why we have YANG is
>> automation and I believe people will go and write tools to extract
>> tags and having to extract them out of free form text looks like a
>> step backwards.
>>=20
>> Andy=20
>>=20
>> It is more than a step backwards.
>> There is an unexplained procedure for declaring the  module-tag =
conformance,
>> in addition to the module-tag mappings.
>>=20
>> Alex
>>=20
>> I have no issue with systems using tags to classify or organize =
modules, however this seems to me like something that would be specific =
to the system doing the classifying. It would not be something that =
needs to be specified in the module itself (except perhaps as freeform =
description text), and it certainly would not need to involve the =
NETCONF server. What would a server do with module classification data? =
(unless it is also implementing some kind of module browsing interface, =
in which case it might be used to supply the browser with data)
>>=20
>> Wether or not this is intended for or will be parsed by machines =
remains a significant unresolved concern. The actual mechanics of =
restricting what goes into them however seems fairly straight forward.
>>=20
>> Absent consensus on the above concern this document cannot probably =
advance, we do have the opportunity for significant face to face =
discussion in the near future so using that to arrive at a conclusion =
would probably allow this work to progress or stop.
>>=20
>> Thanks
>> Joel
>>=20
>>> On Oct 2, 2018, at 13:21, joel jaeggli  wrote:
>>>=20
>>> This is start of a two week working group last-call for
>>> draft-ietf-netmod-module-tags-02 a current netmod working group
>>> document.
>>>=20
>>> You may review at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>>>=20
>>> Please send email to the list indicating "yes/support" or "no/do not
>>> support".  If indicating no, please state your reservations with the
>>> document.  If yes, please also feel free to provide comments you'd =
like
>>> to see addressed once the document is a WG document.
>>>=20
>>> The prior discussion of my mistaken WG adoption call is here
>>>=20
>>> commences here:
>>>=20
>>> https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html
>>>=20
>>> In particular Andy's concerns expressed in that thread here:
>>>=20
>>> https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html
>>>=20
>>> are probably important to tease out in considering this for last =
call.
>>>=20
>>> so that we are clear on dates. This last call timing resets and runs
>>> from 10/2/18 - 10/16/18
>>>=20
>>> Joel
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20


From nobody Thu Oct 25 21:38:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0645D130934 for ; Thu, 25 Oct 2018 21:38:45 -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] 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 oO-CqVCJQeSA for ; Thu, 25 Oct 2018 21:38:43 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA99128D68 for ; Thu, 25 Oct 2018 21:38:43 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B360C60084; Fri, 26 Oct 2018 04:38:42 +0000 (UTC)
References:  <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com> <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org> <1539813344223.22743@Aviatnet.com>  <1539899498556.81453@Aviatnet.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps 
To: Alex Campbell 
Cc: Christian Hopps , NETMOD Working Group 
In-reply-to: <1539899498556.81453@Aviatnet.com>
Date: Fri, 26 Oct 2018 00:38:41 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 04:38:46 -0000

Alex Campbell  writes:

> Capabilities, features and deviations indicate the type of requests the router can respond to.
>
> The capability advertisement may not affect the router, but the capability itself directly does.
> The capability advertisement tells the client that the router can answer requests involving the capability in question.
>
> Will clients base their behaviour on module tags, such as fetching all modules with a particular tag?

It depends on what the tag/meta-data is! This is a way to add meta-data, but we aren't restricting or strictly defining how one will *use* the meta-data on purpose. Tags are meant to be a tool that can be used in many ways even some yet unimagined ways.

> In that case, as a vendor, I do not understand the implications of adding or removing a tag and I would prefer if the RFC was clearer on that point.

So as a vendor don't add or remove tags you don't understand.

This is a general purpose tool we are adding here, the ability to associate tag/meta-data with a module. There are some uses that we can think of now (e.g., from the definition side classifying the origin of a module as IETF or OpenConfig, or from the client side marking a module as "dontuse" for an NMS b/c they found bugs with it on a given device. And there will be uses that are dreamt up later.

The point here is to put in place a way to associate tags with modules, not to restrict how they are used.

Thanks,
Chris.

> ________________________________________
> From: Christian Hopps 
> Sent: Thursday, 18 October 2018 11:16 p.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>
> A router has no use for it's capability/feature/deviation advertisements either; module-tags are no different in this respect.
>
> Thanks,
> Chris.
>
> Alex Campbell  writes:
>
>> Hi,
>>
>>> The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers.
>>
>> I assume that the server here is a network element implementing ietf-module-tags.
>>
>> I still don't see why network elements should implement ietf-module-tags.
>> What benefit is gained from storing the tags on the server instead of the client? It seems backwards.
>>
>> Have I misunderstood? I assumed that ietf-module-tags was meant to be implemented by network elements that are NETCONF servers - but now I see the document doesn't actually specify who is meant to implement the module. Your comment about newly installed routers supports my understanding however.
>>
>>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.
>>
>> The problem with pre-defined tags is that they are never complete. I can always find a useful tag that is not pre-defined.
>>
>>> Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in ones network then making sure the newly installed router has tags configured the way you expect is no different from making sure that you configured IS-IS correctly.
>>
>> The reason I find this problematic is the same as above - that the router has no use for the tag data.
>> It's as if my PC were to download its keyboard mapping table from my home router. Then I change ISPs and have to swap the router, and suddenly my keyboard doesn't work correctly.
>> It would be much better to store the keyboard mapping table for my PC *on my PC* instead of adding needless external dependencies.
>>
>> Alex
>>
>>
>> ________________________________________
>> From: Christian Hopps 
>> Sent: Wednesday, 17 October 2018 9:56 p.m.
>> To: Alex Campbell
>> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
>> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>>
>> The point is to keep this open to however the community might end up choosing to use it. The act of pre-defining tags doesn't disallow other tags being defined, in fact at this point I've sent a bunch of email defending leaving things as open as possible. They both can co-exist. :)
>>
>> Thanks,
>> Chris.
>>
>>> On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:
>>>
>>> I have no issue with systems using tags to classify or organize modules, however this seems to me like something that would be specific to the system doing the classifying.
>>
>> Sure we support this. That's what user tag configuration is there for.
>>
>>> It would not be something that needs to be specified in the module itself (except perhaps as freeform description text), and it certainly would not need to involve the NETCONF server.
>>> What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data)
>>
>> The server implements the tags (at least the predefined ones), and the use cases that come to my mind at least involve clients not servers. I'm not saying there wouldn't be a server use case, but it's not as obvious to me.
>>
>> And yes implementing some kind of module browsing interface (which could group modules by tags) is a fine example of how tags can be used.
>>
>>>
>>> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, changing quickly according to the desires of users. I don't think it makes sense to "hard-code" them in published RFCs or even published vendor modules or firmware.
>>>
>>> Tomorrow, I might want to list all modules for management plane protocols. As a network operator, should I go and update the ietf-module-tags on all of my network elements? That seems silly. This should be client-side data. (And if I did, what happens when I add a new router and forget to update its tag data? Will that confuse the client?)
>>
>> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules is exactly the point of pre-defined tags, but you questioned their value at the top of your mail.
>>
>> Either way configuring a newly installed router is a given, I don't think this is the place to solve the "forgot to add all the config to my new router install" issue. :) If one is using tags in ones network then making sure the newly installed router has tags configured the way you expect is no different from making sure that you configured IS-IS correctly.
>>
>> Thanks,
>> Chris.
>>
>>>
>>> Regards, Alex
>>>
>>> ________________________________________
>>> From: Christian Hopps 
>>> Sent: Wednesday, 17 October 2018 1:04 a.m.
>>> To: Alex Campbell
>>> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
>>> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>>>
>>>>
>>>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wrote:
>>>>
>>>> The introduction does not explain what they are useful for
>>>
>>> The second sentence of the abstract: "The expectation is for such tags to be used to help classify and organize modules." The introduction repeats this in the first sentence. I'm not sure how much differently we could say "Tags are useful for organizing and classifying modules". Are you asking for justification on the usefulness of organizing and classifying things? I think this concept is rather widely accepted.
>>>
>>>
>>>> , it just makes a comparison to #hashtags (which is something I would expect to see in an April 1st RFC).
>>>
>>> Using tags to help organize collections of data is literally ubiquitous: Movies/music/media, IP routes, and yes even social media are just a few examples.  Regarding April 1st, are you are unfairly restricting your perspective to only the ironic use of hashtags? Hashtags organically developed as a useful and widely used way for people and groups to add meta-data to their messages which then allowed other services to collect and present them in useful ways. Indeed businesses and other groups use hashtags for this purpose to great success. It was hardly a joke, and for many folks it is immediately useful to understand what is being proposed.
>>>
>>> Thanks,
>>> Chris.
>>>


From nobody Fri Oct 26 01:38:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA35128CE4 for ; Fri, 26 Oct 2018 01:38:03 -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, DKIMWL_WL_MED=-0.001, 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 FgJ_HBbZvXAI for ; Fri, 26 Oct 2018 01:38: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 B2946127AC2 for ; Fri, 26 Oct 2018 01:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2754; q=dns/txt; s=iport; t=1540543081; x=1541752681; h=from:subject:to:message-id:date:mime-version; bh=X2FnZLuSa9oxtKW7YKkuUOKyDHoIYpMtkFnKWZBZtXs=; b=ILxtLHyzKGuI9QHsf5ju5o1gthC1AFylOg4U1L75giBtDJyo+rHovS58 5ce+Kevc1ASOwjne3y4Ssp+V7BXC2BS4wQJOshT2l40Ozj2AJJndnLEMb OqJ9FIWcuQIk8viWoIklESr0vEv5ZXC+eOspCraI3ZkNDJEntCzVcesLA Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAgDP0NJb/xbLJq1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYJrbRKEHYh3jSCRd4dEDSOHfzgWAQMBAQIBAQJtHAELhWR1AT0CXw0?= =?us-ascii?q?IAQEXgwYBggEPl0+OZYEuFAuEH0A9hF0Fi36BQT+BOAyFegIDAYRhglcCiSK?= =?us-ascii?q?VWQmGaYoQBgIWiT6HBoxrg1mGTIFaIYFVMxoIGxWDKIsYhT8+jVkBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,427,1534809600"; d="scan'208,217";a="7546491"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 08:37:59 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9Q8bxwk027904 for ; Fri, 26 Oct 2018 08:37:59 GMT
From: Robert Wilton 
To: "netmod@ietf.org" 
Message-ID: <15467555-2244-9cd1-f47e-97271450c750@cisco.com>
Date: Fri, 26 Oct 2018 09:37:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------712C7D35E55E894961220410"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [netmod] YANG versioning solution comparison draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 08:38:03 -0000

This is a multi-part message in MIME format.
--------------712C7D35E55E894961220410
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

The YANG versioning design team has spent the last few months refining 
some of the requirements and discussing and debating various solutions.  
I would like to thank everyone on the design team who has spent time on 
this and participated in this effort.

To this end we have produced an interim draft, 
draft-verdt-netmod-yang-solutions 
, 
that describes some of the solutions to the key problems that we have 
been discussing.

The draft is quite rough around the edges, but is only expected be a 
transient working document.  I shall be presenting some of the content 
to the WG in the Thursday Netmod session.  The draft itself purposely 
does not recommend any particular solution at this time, but the design 
team would welcome feedback from the working group on their thoughts and 
views of the various potential solutions, particularly if their are 
additional pros/cons of those solutions that are not captured in the draft.

Thanks,
Rob


--------------712C7D35E55E894961220410
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
The YANG versioning design team has spent the last few months
      refining some of the requirements and discussing and debating
      various solutions.  I would like to thank everyone on the design
      team who has spent time on this and participated in this effort.

    

    
To this end we have produced an interim draft, draft-verdt-netmod-yang-solutions,
      that describes some of the solutions to the key problems that we
      have been discussing.

    

    
The draft is quite rough around the edges, but is only expected
      be a transient working document.  I shall be presenting some of
      the content to the WG in the Thursday Netmod session.  The draft
      itself purposely does not recommend any particular solution at
      this time, but the design team would welcome feedback from the
      working group on their thoughts and views of the various potential
      solutions, particularly if their are additional pros/cons of those
      solutions that are not captured in the draft.

    

    
Thanks,

      Rob

    

  


--------------712C7D35E55E894961220410--


From nobody Fri Oct 26 02:02:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F812D4F2 for ; Fri, 26 Oct 2018 02:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwJ0np2boHMQ for ; Fri, 26 Oct 2018 02:02:43 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2A6931293FB for ; Fri, 26 Oct 2018 02:02:43 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 838C4A3EC527E for ; Fri, 26 Oct 2018 10:02:37 +0100 (IST)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 26 Oct 2018 10:02:39 +0100
Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.234]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0399.000; Fri, 26 Oct 2018 17:02:19 +0800
From: wangzitao 
To: NetMod WG 
Thread-Topic: solicit comments on event management yang 
Thread-Index: AdRtCmhrWJdtDe9eTeSkjQXwLRP8nQ==
Date: Fri, 26 Oct 2018 09:02:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.245]
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2C3457E5DGGEMM527MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] solicit comments on event management yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 09:02:45 -0000

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2C3457E5DGGEMM527MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi WG,

We are seeking feedback for an event management yang data model: https://to=
ols.ietf.org/html/draft-wwx-netmod-event-yang-00
This model provide an ability to monitor yang instance on local or remote s=
ystem via netconf/restconf, and it can trigger simple actions such as notif=
ication or reconfiguration when a trigger condition is met. The event yang =
model also can map to corresponding event MIB [RFC2981].

In addition, this model can be used as a supplement and enhancement to YANG=
 Push. It can:
o specifies a mechanism that provides three trigger conditions: 1) Existenc=
e; 2) Boolean; 3) Threshold.
o not only trigger notification but also provide a method to allow automati=
c reconfiguration.
o inform the client that one Event is related to other events, and allow on=
e event to trigger another event or generate a new event when corresponding=
 trigger condition is met.

Best Regards!
-Michael


--_000_E6BC9BBCBCACC246846FC685F9FF41EA2C3457E5DGGEMM527MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi WG,


 


We are seeking feedback for an event management yang=
 data model:
http=
s://tools.ietf.org/html/draft-wwx-netmod-event-yang-00


This model provide an ability to monitor yang instan=
ce on local or remote system via netconf/restconf, and it can trigger simpl=
e actions such as notification or reconfiguration when a trigger condition =
is met. The event yang model also
 can map to corresponding event MIB [RFC2981].


 


In addition, this model can be used as a supplement =
and enhancement to YANG Push. It can:


o specifies a mechanism that provides three trigger =
conditions: 1) Existence; 2) Boolean; 3) Threshold.


o not only trigger notification but also provide a m=
ethod to allow automatic reconfiguration.


o inform the client that one Event is related to oth=
er events, and allow one event to trigger another event or generate a new e=
vent when corresponding trigger condition is met.


 


Best Regards!


-Michael


 






--_000_E6BC9BBCBCACC246846FC685F9FF41EA2C3457E5DGGEMM527MBXchi_--


From nobody Fri Oct 26 02:17:55 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896221293FB for ; Fri, 26 Oct 2018 02:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 GZtY9Xabdq0X for ; Fri, 26 Oct 2018 02:17:51 -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 ED18E128CF2 for ; Fri, 26 Oct 2018 02:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8162; q=dns/txt; s=iport; t=1540545471; x=1541755071; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6kjm4Iw++SwVqeHUJiU6NSUwsAXd0wgNF2RDV+9fFvQ=; b=hQRitoy8C2HO6OA2naePI3cCaIYX240knK+vTH0s1Kmcs/BeGMfPjP2h BDWqT1NF/ayEkpdl5u2aN3lIYylcrxk2AGOsfk4cgc6Hn0ixcFyD8CDQR 2EDCp5FyC9NI2gCSIf3ep9vfnBcBppcIeCP1DlJdmWAl+ULEKi0d5oT+B U=;
X-IronPort-AV: E=Sophos;i="5.54,427,1534809600";  d="scan'208";a="7547419"
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; 26 Oct 2018 09:17:49 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w9Q9HmcS004368; Fri, 26 Oct 2018 09:17:49 GMT
To: Christian Hopps 
Cc: Joe Clarke , "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>  
From: Robert Wilton 
Message-ID: <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com>
Date: Fri, 26 Oct 2018 10:17:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.63, dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 09:17:53 -0000

Hi Chris,


On 25/10/2018 18:42, Christian Hopps wrote:
>
> Hi Rob,
>
> We've more privately discussed the bug-fix scenario and I'm 
> sympathetic to it; however, the requirement as written does not 
> restrict itself to fixing module definition bugs (e.g., a pattern or 
> other value constraint) in some small but incompatible way -- instead 
> it's wide open and it will be [ab]used that way.
I think that everyone on design team agrees that 
non-backwards-compatible changes should be minimized and should really 
only to used for bug fixes where it is anticipated that clients should 
not be affected.

We want to allow non-backwards-compatible changes at the head of the 
development tree, but again, I think that everyone agrees that keeping 
it backwards compatible where possible is a good goal.

However, I think that there will be cases where a vendor decides that it 
is right for an enhancement or non backwards compatible change to be 
made to an already released module.  I agree that this is highly 
undesirable and an abuse of the rules, but I don't believe that whatever 
versioning scheme we come up with will prevent vendors from doing this.  
So then the question becomes: Is it better to pretend that this scenario 
will never happen, design the versioning scheme so that it cannot be 
expressed, which probably just means that clients will not be able to 
detect when vendors do this by cheating the rules!  Or is it better to 
accept that this will sometimes occur, provide strong guidance as to why 
this is bad practice and should be avoided, but have a versioning scheme 
that still allows this to be expressed (in a bounded way)?  I.e. even if 
the vendors are doing something that is less than ideal, at least the 
clients can spot where they have done this.

---

A separate concern that we had about ties this strictly to bug fixes is 
that some one will ask for a definition of a bug fix.  The design team 
tried this but we couldn't even agree what a bug fix is, let alone agree 
with a single definition of a bug fix as it related to a YANG module.  
So our conclusion was that perhaps it is better not to tie the 
requirements themselves to bug fix vs enhancement, because the boundary 
between the two is too vague, and module writers will bend the rules.

So I see that the rules should be:
  - backwards compatible bug fix  - this is fine.
  - non backwards compatible bug fix - this is fine if it is 
pragmatically expected to not impact any clients, but careful 
consideration is required if it might break clients.
  - backwards compatible enhancement - not ideal, but pragmatically OK.
  - non backwards compatible enhancement - this is bad and should be 
avoided.

But if we don't want to define the difference between a bug fix vs 
enhancement then I think that you end up with the most general 
requirement being that we do want to allow for non-backwards-compatible 
changes in released modules to accommodate the bug fix scenario, but the 
expectation (and guidance) will be that they should only be used for bug 
fixes.


>
> For example:
>
>> Here is what I am afraid the vendors want here: A developer on 
>> release train X can easily change some data structure and then push 
>> the change into an automated system which generates a new YANG module 
>> definition and revs a version number -- all done! They don't have to 
>> deal with the inertia of making this change in their release train Y 
>> or Z and they don't have to treat modules as a stable API they are 
>> exporting, b/c they now have these new wonderful versions from this 
>> work. Meanwhile we the users now have to deal with N forks with all 
>> the various little incompatible changes random developers at the 
>> company wanted to make without having to coordinate with their 
>> coworkers/other internal teams. Now multiply this by M vendors. It's 
>> a nightmare. It shouldn't be what we are optimizing for, let alone 
>> making a requirement.
>
> Regarding enhancements, these are features, and are naturally 
> augmentative. I find it hard to believe we have a pressing 
> need/requirement to support non-backward compatible changes to 
> existing modules in order to support enhancements.
I agree.  It was a backwards compatible enhancement that I was considering.

Thanks,
Rob


>
> Thanks,
> Chris.
>
>
> Robert Wilton  writes:
>
>> Hi Chris,
>>
>> I think that there are two things driving this requirement:
>>
>> What I regard as the key one, is that we want to be able to support 
>> the software
>> that we have shipped. In particular, we may need to fix bugs (perhaps 
>> at the
>> operators request) to a YANG model that has already been released. 
>> I.e. I think
>> that there are some scenarios, where forking a YANG module, although 
>> undesirable
>> is the right thing to do to include a fix. I don't believe that 
>> features or
>> deviations help solve this problem.
>> The two alternative solutions to being able to fix bugs, neither of 
>> which I
>> think is pragmatic, that I can think of are:
>> (i) Vendors ensure that their YANG modules are perfect before they 
>> ship in a
>> release.
>> (ii) If a bug is reported, operators are happy to wait until the bug 
>> has been
>> fixed in the current development release, and will migrate to that 
>> latest
>> release to pick up the fix.
>>
>> The second thing driving this requirement is that vendors sometimes 
>> get asked
>> for enhancements to existing releases, perhaps because the latest 
>> development
>> release is too far out, or ask for an enhancement on the current 
>> train to be
>> back ported to an older release.
>>
>> So, aiming to have stable YANG modules, trying a lot harder to avoid
>> non-backwards-compatible changes, and keeping new functionality to 
>> the head of
>> the development I completely agree with you on. But I still believe 
>> that there
>> are some valid scenarios, that should be limited as much as possible, 
>> where it
>> is necessary to make changes that sometimes break these rules, and 
>> having a
>> limited scheme that clearly indicates where such breakages have 
>> occurred is
>> probably better that the status quo of where the modules get changed, 
>> but the
>> operator doesn't get any useful indication of what type of changes 
>> are being
>> made.
>>
>> Thanks,
>> Rob
>>
>>
>> On 25/10/2018 16:26, Christian Hopps wrote:
>>>
>>>> On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
>>>>
>>>> * New requirement 1.4 for supporting over-arching software releases
>>> [ I read this as supporting various different module versions based 
>>> on a vendor's different software release trains. If this is wrong 
>>> then the rest of this doesn't apply and I would just ask for the 
>>> text to be update to clarify what it means. ]
>>>
>>> How many operators/users have asked for this or indicated it's a 
>>> requirement for them?
>>>
>>> What problem is intractable without this requirement being met, and 
>>> what is the cost of this requirement on the actual users?
>>>
>>> I have pushed back multiple times on this b/c I believe this 
>>> "requirement" is really being pushed to make it easier for vendors 
>>> (a small affected group) to develop their software at the cost of 
>>> their users (the much larger affected group) who would then have to 
>>> deal with multiple trains of the same module.
>>>
>>>
>>> We already have features and deviations why are they not enough to 
>>> deal with functionality that is present or not in various software 
>>> release/devices?
>>>
>>> FWIW I'm not against making it easier to develop software, but we 
>>> have to be mindful if we are just pushing the cost (and magnifying 
>>> it greatly) to other people in the community.
>>>
>>> Thanks,
>>> Chris.
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>
> .
>


From nobody Fri Oct 26 02:33:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08B012D4F2 for ; Fri, 26 Oct 2018 02:33:55 -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 jDYWhQ11ph-2 for ; Fri, 26 Oct 2018 02:33:52 -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 606451252B7 for ; Fri, 26 Oct 2018 02:33:52 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 92A8CEF3 for ; Fri, 26 Oct 2018 11:33:50 +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 9FQUVa8H5FTZ for ; Fri, 26 Oct 2018 11:33:48 +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 for ; Fri, 26 Oct 2018 11:33:50 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CA112003A for ; Fri, 26 Oct 2018 11:33:50 +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 yVTkUdHYazZk for ; Fri, 26 Oct 2018 11:33:49 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 227A520039 for ; Fri, 26 Oct 2018 11:33:49 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 26 Oct 2018 11:33:48 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 17E9530029EBAF; Fri, 26 Oct 2018 11:33:47 +0200 (CEST)
Date: Fri, 26 Oct 2018 11:33:47 +0200
From: Juergen Schoenwaelder 
To: "netmod@ietf.org" 
Message-ID: <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.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: <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 09:33:56 -0000

Let me add that there was large disagreement what a bug fix is in the
design team. Hence, any text that talks about 'bug fixes' is ambiguous
and of limited value to achieve consensus. (Or we may find consensus
but then not agree on what we have found consensus on.)

To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for
having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing something where the
correct intention was clear but the model did not properly capture the
intention correctly, i.e., roughly what we can do with errata in the
IETF. I think Rob understands bug fixes in a much broader sense,
including fixes to what essentially are in my view module design
errors.

With my narrow definition of bug fixes, bug fixes are essentially
backwards compatible (even if they may violate RFC 7950 rules - but as
long as the original intention was clear, we can be flexible).

With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.

/js

On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> Hi Chris,
> 
> 
> On 25/10/2018 18:42, Christian Hopps wrote:
> > 
> > Hi Rob,
> > 
> > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > to it; however, the requirement as written does not restrict itself to
> > fixing module definition bugs (e.g., a pattern or other value
> > constraint) in some small but incompatible way -- instead it's wide open
> > and it will be [ab]used that way.
> I think that everyone on design team agrees that non-backwards-compatible
> changes should be minimized and should really only to used for bug fixes
> where it is anticipated that clients should not be affected.
> 
> We want to allow non-backwards-compatible changes at the head of the
> development tree, but again, I think that everyone agrees that keeping it
> backwards compatible where possible is a good goal.
> 
> However, I think that there will be cases where a vendor decides that it is
> right for an enhancement or non backwards compatible change to be made to an
> already released module.  I agree that this is highly undesirable and an
> abuse of the rules, but I don't believe that whatever versioning scheme we
> come up with will prevent vendors from doing this.  So then the question
> becomes: Is it better to pretend that this scenario will never happen,
> design the versioning scheme so that it cannot be expressed, which probably
> just means that clients will not be able to detect when vendors do this by
> cheating the rules!  Or is it better to accept that this will sometimes
> occur, provide strong guidance as to why this is bad practice and should be
> avoided, but have a versioning scheme that still allows this to be expressed
> (in a bounded way)?  I.e. even if the vendors are doing something that is
> less than ideal, at least the clients can spot where they have done this.
> 
> ---
> 
> A separate concern that we had about ties this strictly to bug fixes is that
> some one will ask for a definition of a bug fix.  The design team tried this
> but we couldn't even agree what a bug fix is, let alone agree with a single
> definition of a bug fix as it related to a YANG module.  So our conclusion
> was that perhaps it is better not to tie the requirements themselves to bug
> fix vs enhancement, because the boundary between the two is too vague, and
> module writers will bend the rules.
> 
> So I see that the rules should be:
>  - backwards compatible bug fix  - this is fine.
>  - non backwards compatible bug fix - this is fine if it is pragmatically
> expected to not impact any clients, but careful consideration is required if
> it might break clients.
>  - backwards compatible enhancement - not ideal, but pragmatically OK.
>  - non backwards compatible enhancement - this is bad and should be avoided.
> 
> But if we don't want to define the difference between a bug fix vs
> enhancement then I think that you end up with the most general requirement
> being that we do want to allow for non-backwards-compatible changes in
> released modules to accommodate the bug fix scenario, but the expectation
> (and guidance) will be that they should only be used for bug fixes.
> 
> 
> > 
> > For example:
> > 
> > > Here is what I am afraid the vendors want here: A developer on
> > > release train X can easily change some data structure and then push
> > > the change into an automated system which generates a new YANG
> > > module definition and revs a version number -- all done! They don't
> > > have to deal with the inertia of making this change in their release
> > > train Y or Z and they don't have to treat modules as a stable API
> > > they are exporting, b/c they now have these new wonderful versions
> > > from this work. Meanwhile we the users now have to deal with N forks
> > > with all the various little incompatible changes random developers
> > > at the company wanted to make without having to coordinate with
> > > their coworkers/other internal teams. Now multiply this by M
> > > vendors. It's a nightmare. It shouldn't be what we are optimizing
> > > for, let alone making a requirement.
> > 
> > Regarding enhancements, these are features, and are naturally
> > augmentative. I find it hard to believe we have a pressing
> > need/requirement to support non-backward compatible changes to existing
> > modules in order to support enhancements.
> I agree.  It was a backwards compatible enhancement that I was considering.
> 
> Thanks,
> Rob
> 
> 
> > 
> > Thanks,
> > Chris.
> > 
> > 
> > Robert Wilton  writes:
> > 
> > > Hi Chris,
> > > 
> > > I think that there are two things driving this requirement:
> > > 
> > > What I regard as the key one, is that we want to be able to support
> > > the software
> > > that we have shipped. In particular, we may need to fix bugs
> > > (perhaps at the
> > > operators request) to a YANG model that has already been released.
> > > I.e. I think
> > > that there are some scenarios, where forking a YANG module, although
> > > undesirable
> > > is the right thing to do to include a fix. I don't believe that
> > > features or
> > > deviations help solve this problem.
> > > The two alternative solutions to being able to fix bugs, neither of
> > > which I
> > > think is pragmatic, that I can think of are:
> > > (i) Vendors ensure that their YANG modules are perfect before they
> > > ship in a
> > > release.
> > > (ii) If a bug is reported, operators are happy to wait until the bug
> > > has been
> > > fixed in the current development release, and will migrate to that
> > > latest
> > > release to pick up the fix.
> > > 
> > > The second thing driving this requirement is that vendors sometimes
> > > get asked
> > > for enhancements to existing releases, perhaps because the latest
> > > development
> > > release is too far out, or ask for an enhancement on the current
> > > train to be
> > > back ported to an older release.
> > > 
> > > So, aiming to have stable YANG modules, trying a lot harder to avoid
> > > non-backwards-compatible changes, and keeping new functionality to
> > > the head of
> > > the development I completely agree with you on. But I still believe
> > > that there
> > > are some valid scenarios, that should be limited as much as
> > > possible, where it
> > > is necessary to make changes that sometimes break these rules, and
> > > having a
> > > limited scheme that clearly indicates where such breakages have
> > > occurred is
> > > probably better that the status quo of where the modules get
> > > changed, but the
> > > operator doesn't get any useful indication of what type of changes
> > > are being
> > > made.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > On 25/10/2018 16:26, Christian Hopps wrote:
> > > > 
> > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke  wrote:
> > > > > 
> > > > > * New requirement 1.4 for supporting over-arching software releases
> > > > [ I read this as supporting various different module versions
> > > > based on a vendor's different software release trains. If this
> > > > is wrong then the rest of this doesn't apply and I would just
> > > > ask for the text to be update to clarify what it means. ]
> > > > 
> > > > How many operators/users have asked for this or indicated it's a
> > > > requirement for them?
> > > > 
> > > > What problem is intractable without this requirement being met,
> > > > and what is the cost of this requirement on the actual users?
> > > > 
> > > > I have pushed back multiple times on this b/c I believe this
> > > > "requirement" is really being pushed to make it easier for
> > > > vendors (a small affected group) to develop their software at
> > > > the cost of their users (the much larger affected group) who
> > > > would then have to deal with multiple trains of the same module.
> > > > 
> > > > 
> > > > We already have features and deviations why are they not enough
> > > > to deal with functionality that is present or not in various
> > > > software release/devices?
> > > > 
> > > > FWIW I'm not against making it easier to develop software, but
> > > > we have to be mindful if we are just pushing the cost (and
> > > > magnifying it greatly) to other people in the community.
> > > > 
> > > > Thanks,
> > > > Chris.
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > .
> > > > 
> > 
> > .
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Oct 26 09:35:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537B7130DD3 for ; Fri, 26 Oct 2018 09:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 V87FL5TAq97n for ; Fri, 26 Oct 2018 09:35:43 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D9C19127133 for ; Fri, 26 Oct 2018 09:35:42 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id o2-v6so1361478lfl.13 for ; Fri, 26 Oct 2018 09:35:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HN0wzsWN3qz62vgA0b3KybH1EiQZdlvlDXT8Sb0Eu+s=; b=dbiwTfBQFMTEg9GFy+omb5xuNORQd9xoQmakfe3K175qpd1FyKsraXL6TQllrCifz1 9OnUt3tcpdMUd7PKPAo2TuIP0OykzuFp3AqLsFP5LcLioTFHjfwEBbluQVcQrmWjg8dN Xc1XVITvye5wTND8DHrBNrkFs+1C0Mxcwp1B08zK6PYShVlc5K+KW5KLNIMl5n7WX579 GEw69SUzpzrh3BvrG4nQo3zQ8Bcrrrk+YsdBcm3NkQVEn563WC1BZa6METSvkuAk7yvt 12iZOGioUiy2ZrYIrjZQLmEy3keIUf7vngmmWBkMFK9y3Jj8l1tIw7kATAv3GAue2Kei dptg==
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=HN0wzsWN3qz62vgA0b3KybH1EiQZdlvlDXT8Sb0Eu+s=; b=nnMnPyYeRuv0f71FtWUdJLR85Fj66Ff1dcLjg9rLTfEZAOJ7uDRI+M4kb0WGdVbEJ2 I5F/sB3CVKEUrD0/k5Q0vS0g2BGwv72IWgBdPSLHrOKTLZ9jLKK8FAoNHl8soI9FEFZ6 KSZ4gH9Lw+2Lv2QjBcgvZ8P+fmIiyeeAdtImMpnJG85kEFn1QqtikEkbkrJIDnzmHs5K JDRokZpVD/9/XAZJHX5z9DooCdBIg2v6R4o89i3xX0JL8R6CuEtr0iUotIXxqofulASv fSXk2bCHIo5oEFLenJmHYSHFk4nbq434vMi03bApp+HufhLJh1G1Y3HNWUXJ/h0yTSBO a4Fg==
X-Gm-Message-State: AGRZ1gLGYD7JflUzQZbQ2j3pboeSa7gbwCAuqi7ypFPQVCwRPXOrBqle ND17u0UDBBy3yan/OYYecOP8j3BStgDpBd52bWgb1w==
X-Google-Smtp-Source: AJdET5d402m00awWBL0Ypk+qQdvDvoZlJyj/7HGZpiVJUAGOv3vMLjnOH7IzRczfq9hJCPw8vLAZD/u854Vxr6i8cMQ=
X-Received: by 2002:a19:d58e:: with SMTP id m136mr2891931lfg.70.1540571740773;  Fri, 26 Oct 2018 09:35:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 26 Oct 2018 09:35:39 -0700 (PDT)
In-Reply-To: <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 26 Oct 2018 09:35:39 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005c3f460579244f9a"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 16:35:48 -0000

--0000000000005c3f460579244f9a
Content-Type: text/plain; charset="UTF-8"

On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Let me add that there was large disagreement what a bug fix is in the
> design team. Hence, any text that talks about 'bug fixes' is ambiguous
> and of limited value to achieve consensus. (Or we may find consensus
> but then not agree on what we have found consensus on.)
>
> To be more concrete, I learned that Rob's notion of a bug fix is very
> different from my notion of a bug fix. I think it is important for
> having a productive discussion to be aware of this.
>
> For me, a bug fix is rather limited, i.e., fixing something where the
> correct intention was clear but the model did not properly capture the
> intention correctly, i.e., roughly what we can do with errata in the
> IETF. I think Rob understands bug fixes in a much broader sense,
> including fixes to what essentially are in my view module design
> errors.
>
> With my narrow definition of bug fixes, bug fixes are essentially
> backwards compatible (even if they may violate RFC 7950 rules - but as
> long as the original intention was clear, we can be flexible).
>
> With Rob's notion of bug fixes, we have to handle them as part of the
> versioning system since they may be non-backwards compatible.
>
>

IMO requirements 3.1 and 3.2 are the most  important and have the most
impact
on the solution space. I do not agree with either of these requirements.

Implementing multiple non-compatible revisions of a module on a server
sounds hard,
not to mention that it breaks RFC 7950 rules. The current protocols do not
support the
ability to specify different versions of the same QName. This change makes
YANG validation
much to difficult to specify and implement (as that has to be rewritten as
well).

It is one thing to deploy rapidly changing, buggy YANG modules in order to
gain experience quickly.  It is quite another to complicate YANG and the
protocols
to preserve these interim mistakes, and bake into the standards the notion
that this
is good engineering.


/js
>

Andy


>
> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > Hi Chris,
> >
> >
> > On 25/10/2018 18:42, Christian Hopps wrote:
> > >
> > > Hi Rob,
> > >
> > > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > > to it; however, the requirement as written does not restrict itself to
> > > fixing module definition bugs (e.g., a pattern or other value
> > > constraint) in some small but incompatible way -- instead it's wide
> open
> > > and it will be [ab]used that way.
> > I think that everyone on design team agrees that non-backwards-compatible
> > changes should be minimized and should really only to used for bug fixes
> > where it is anticipated that clients should not be affected.
> >
> > We want to allow non-backwards-compatible changes at the head of the
> > development tree, but again, I think that everyone agrees that keeping it
> > backwards compatible where possible is a good goal.
> >
> > However, I think that there will be cases where a vendor decides that it
> is
> > right for an enhancement or non backwards compatible change to be made
> to an
> > already released module.  I agree that this is highly undesirable and an
> > abuse of the rules, but I don't believe that whatever versioning scheme
> we
> > come up with will prevent vendors from doing this.  So then the question
> > becomes: Is it better to pretend that this scenario will never happen,
> > design the versioning scheme so that it cannot be expressed, which
> probably
> > just means that clients will not be able to detect when vendors do this
> by
> > cheating the rules!  Or is it better to accept that this will sometimes
> > occur, provide strong guidance as to why this is bad practice and should
> be
> > avoided, but have a versioning scheme that still allows this to be
> expressed
> > (in a bounded way)?  I.e. even if the vendors are doing something that is
> > less than ideal, at least the clients can spot where they have done this.
> >
> > ---
> >
> > A separate concern that we had about ties this strictly to bug fixes is
> that
> > some one will ask for a definition of a bug fix.  The design team tried
> this
> > but we couldn't even agree what a bug fix is, let alone agree with a
> single
> > definition of a bug fix as it related to a YANG module.  So our
> conclusion
> > was that perhaps it is better not to tie the requirements themselves to
> bug
> > fix vs enhancement, because the boundary between the two is too vague,
> and
> > module writers will bend the rules.
> >
> > So I see that the rules should be:
> >  - backwards compatible bug fix  - this is fine.
> >  - non backwards compatible bug fix - this is fine if it is pragmatically
> > expected to not impact any clients, but careful consideration is
> required if
> > it might break clients.
> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
> >  - non backwards compatible enhancement - this is bad and should be
> avoided.
> >
> > But if we don't want to define the difference between a bug fix vs
> > enhancement then I think that you end up with the most general
> requirement
> > being that we do want to allow for non-backwards-compatible changes in
> > released modules to accommodate the bug fix scenario, but the expectation
> > (and guidance) will be that they should only be used for bug fixes.
> >
> >
> > >
> > > For example:
> > >
> > > > Here is what I am afraid the vendors want here: A developer on
> > > > release train X can easily change some data structure and then push
> > > > the change into an automated system which generates a new YANG
> > > > module definition and revs a version number -- all done! They don't
> > > > have to deal with the inertia of making this change in their release
> > > > train Y or Z and they don't have to treat modules as a stable API
> > > > they are exporting, b/c they now have these new wonderful versions
> > > > from this work. Meanwhile we the users now have to deal with N forks
> > > > with all the various little incompatible changes random developers
> > > > at the company wanted to make without having to coordinate with
> > > > their coworkers/other internal teams. Now multiply this by M
> > > > vendors. It's a nightmare. It shouldn't be what we are optimizing
> > > > for, let alone making a requirement.
> > >
> > > Regarding enhancements, these are features, and are naturally
> > > augmentative. I find it hard to believe we have a pressing
> > > need/requirement to support non-backward compatible changes to existing
> > > modules in order to support enhancements.
> > I agree.  It was a backwards compatible enhancement that I was
> considering.
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > > Thanks,
> > > Chris.
> > >
> > >
> > > Robert Wilton  writes:
> > >
> > > > Hi Chris,
> > > >
> > > > I think that there are two things driving this requirement:
> > > >
> > > > What I regard as the key one, is that we want to be able to support
> > > > the software
> > > > that we have shipped. In particular, we may need to fix bugs
> > > > (perhaps at the
> > > > operators request) to a YANG model that has already been released.
> > > > I.e. I think
> > > > that there are some scenarios, where forking a YANG module, although
> > > > undesirable
> > > > is the right thing to do to include a fix. I don't believe that
> > > > features or
> > > > deviations help solve this problem.
> > > > The two alternative solutions to being able to fix bugs, neither of
> > > > which I
> > > > think is pragmatic, that I can think of are:
> > > > (i) Vendors ensure that their YANG modules are perfect before they
> > > > ship in a
> > > > release.
> > > > (ii) If a bug is reported, operators are happy to wait until the bug
> > > > has been
> > > > fixed in the current development release, and will migrate to that
> > > > latest
> > > > release to pick up the fix.
> > > >
> > > > The second thing driving this requirement is that vendors sometimes
> > > > get asked
> > > > for enhancements to existing releases, perhaps because the latest
> > > > development
> > > > release is too far out, or ask for an enhancement on the current
> > > > train to be
> > > > back ported to an older release.
> > > >
> > > > So, aiming to have stable YANG modules, trying a lot harder to avoid
> > > > non-backwards-compatible changes, and keeping new functionality to
> > > > the head of
> > > > the development I completely agree with you on. But I still believe
> > > > that there
> > > > are some valid scenarios, that should be limited as much as
> > > > possible, where it
> > > > is necessary to make changes that sometimes break these rules, and
> > > > having a
> > > > limited scheme that clearly indicates where such breakages have
> > > > occurred is
> > > > probably better that the status quo of where the modules get
> > > > changed, but the
> > > > operator doesn't get any useful indication of what type of changes
> > > > are being
> > > > made.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > On 25/10/2018 16:26, Christian Hopps wrote:
> > > > >
> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke 
> wrote:
> > > > > >
> > > > > > * New requirement 1.4 for supporting over-arching software
> releases
> > > > > [ I read this as supporting various different module versions
> > > > > based on a vendor's different software release trains. If this
> > > > > is wrong then the rest of this doesn't apply and I would just
> > > > > ask for the text to be update to clarify what it means. ]
> > > > >
> > > > > How many operators/users have asked for this or indicated it's a
> > > > > requirement for them?
> > > > >
> > > > > What problem is intractable without this requirement being met,
> > > > > and what is the cost of this requirement on the actual users?
> > > > >
> > > > > I have pushed back multiple times on this b/c I believe this
> > > > > "requirement" is really being pushed to make it easier for
> > > > > vendors (a small affected group) to develop their software at
> > > > > the cost of their users (the much larger affected group) who
> > > > > would then have to deal with multiple trains of the same module.
> > > > >
> > > > >
> > > > > We already have features and deviations why are they not enough
> > > > > to deal with functionality that is present or not in various
> > > > > software release/devices?
> > > > >
> > > > > FWIW I'm not against making it easier to develop software, but
> > > > > we have to be mindful if we are just pushing the cost (and
> > > > > magnifying it greatly) to other people in the community.
> > > > >
> > > > > Thanks,
> > > > > Chris.
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > .
> > > > >
> > >
> > > .
> > >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder=
 <j.schoenwaelder@jacobs-university.de> w=
rote:
Let me add that =
there was large disagreement what a bug fix is in the

design team. Hence, any text that talks about 'bug fixes' is ambigu=
ous

and of limited value to achieve consensus. (Or we may find consensus

but then not agree on what we have found consensus on.)



To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for

having a productive discussion to be aware of this.



For me, a bug fix is rather limited, i.e., fixing something where the

correct intention was clear but the model did not properly capture the

intention correctly, i.e., roughly what we can do with errata in the

IETF. I think Rob understands bug fixes in a much broader sense,

including fixes to what essentially are in my view module design

errors.



With my narrow definition of bug fixes, bug fixes are essentially

backwards compatible (even if they may violate RFC 7950 rules - but as

long as the original intention was clear, we can be flexible).



With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.




IMO requirements 3.1 an=
d 3.2 are the most =C2=A0important and have the most impact
on th=
e solution space. I do not agree with either of these requirements.

Implementing multiple non-compatible revisions of a modul=
e on a server sounds hard,
not to mention that it breaks RFC 7950=
 rules. The current protocols do not support the
ability to speci=
fy different versions of the same QName. This change makes YANG validation<=
/div>
much to difficult to specify and implement (as that has to be rew=
ritten as well).

It is one thing to deploy rapidly=
 changing, buggy YANG modules in order to
gain experience quickly=
.=C2=A0 It is quite another to complicate YANG and the protocols
=
to preserve these interim mistakes, and bake into the standards the notion =
that this
is good engineering.



/js

Andy
=C2=A0



On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:

> Hi Chris,

> 

> 

> On 25/10/2018 18:42, Christian Hopps wrote:

> > 

> > Hi Rob,

> > 

> > We've more privately discussed the bug-fix scenario and I'=
;m sympathetic

> > to it; however, the requirement as written does not restrict itse=
lf to

> > fixing module definition bugs (e.g., a pattern or other value

> > constraint) in some small but incompatible way -- instead it'=
s wide open

> > and it will be [ab]used that way.

> I think that everyone on design team agrees that non-backwards-compati=
ble

> changes should be minimized and should really only to used for bug fix=
es

> where it is anticipated that clients should not be affected.

> 

> We want to allow non-backwards-compatible changes at the head of the
> development tree, but again, I think that everyone agrees that keeping=
 it

> backwards compatible where possible is a good goal.

> 

> However, I think that there will be cases where a vendor decides that =
it is

> right for an enhancement or non backwards compatible change to be made=
 to an

> already released module.=C2=A0 I agree that this is highly undesirable=
 and an

> abuse of the rules, but I don't believe that whatever versioning s=
cheme we

> come up with will prevent vendors from doing this.=C2=A0 So then the q=
uestion

> becomes: Is it better to pretend that this scenario will never happen,=


> design the versioning scheme so that it cannot be expressed, which pro=
bably

> just means that clients will not be able to detect when vendors do thi=
s by

> cheating the rules!=C2=A0 Or is it better to accept that this will som=
etimes

> occur, provide strong guidance as to why this is bad practice and shou=
ld be

> avoided, but have a versioning scheme that still allows this to be exp=
ressed

> (in a bounded way)?=C2=A0 I.e. even if the vendors are doing something=
 that is

> less than ideal, at least the clients can spot where they have done th=
is.

> 

> ---

> 

> A separate concern that we had about ties this strictly to bug fixes i=
s that

> some one will ask for a definition of a bug fix.=C2=A0 The design team=
 tried this

> but we couldn't even agree what a bug fix is, let alone agree with=
 a single

> definition of a bug fix as it related to a YANG module.=C2=A0 So our c=
onclusion

> was that perhaps it is better not to tie the requirements themselves t=
o bug

> fix vs enhancement, because the boundary between the two is too vague,=
 and

> module writers will bend the rules.

> 

> So I see that the rules should be:

> =C2=A0- backwards compatible bug fix=C2=A0 - this is fine.

> =C2=A0- non backwards compatible bug fix - this is fine if it is pragm=
atically

> expected to not impact any clients, but careful consideration is requi=
red if

> it might break clients.

> =C2=A0- backwards compatible enhancement - not ideal, but pragmaticall=
y OK.

> =C2=A0- non backwards compatible enhancement - this is bad and should =
be avoided.

> 

> But if we don't want to define the difference between a bug fix vs=


> enhancement then I think that you end up with the most general require=
ment

> being that we do want to allow for non-backwards-compatible changes in=


> released modules to accommodate the bug fix scenario, but the expectat=
ion

> (and guidance) will be that they should only be used for bug fixes.
> 

> 

> > 

> > For example:

> > 

> > > Here is what I am afraid the vendors want here: A developer =
on

> > > release train X can easily change some data structure and th=
en push

> > > the change into an automated system which generates a new YA=
NG

> > > module definition and revs a version number -- all done! The=
y don't

> > > have to deal with the inertia of making this change in their=
 release

> > > train Y or Z and they don't have to treat modules as a s=
table API

> > > they are exporting, b/c they now have these new wonderful ve=
rsions

> > > from this work. Meanwhile we the users now have to deal with=
 N forks

> > > with all the various little incompatible changes random deve=
lopers

> > > at the company wanted to make without having to coordinate w=
ith

> > > their coworkers/other internal teams. Now multiply this by M=


> > > vendors. It's a nightmare. It shouldn't be what we a=
re optimizing

> > > for, let alone making a requirement.

> > 

> > Regarding enhancements, these are features, and are naturally

> > augmentative. I find it hard to believe we have a pressing

> > need/requirement to support non-backward compatible changes to ex=
isting

> > modules in order to support enhancements.

> I agree.=C2=A0 It was a backwards compatible enhancement that I was co=
nsidering.

> 

> Thanks,

> Rob

> 

> 

> > 

> > Thanks,

> > Chris.

> > 

> > 

> > Robert Wilton <rwilton@ci=
sco.com> writes:

> > 

> > > Hi Chris,

> > > 

> > > I think that there are two things driving this requirement:<=
br>
> > > 

> > > What I regard as the key one, is that we want to be able to =
support

> > > the software

> > > that we have shipped. In particular, we may need to fix bugs=


> > > (perhaps at the

> > > operators request) to a YANG model that has already been rel=
eased.

> > > I.e. I think

> > > that there are some scenarios, where forking a YANG module, =
although

> > > undesirable

> > > is the right thing to do to include a fix. I don't belie=
ve that

> > > features or

> > > deviations help solve this problem.

> > > The two alternative solutions to being able to fix bugs, nei=
ther of

> > > which I

> > > think is pragmatic, that I can think of are:

> > > (i) Vendors ensure that their YANG modules are perfect befor=
e they

> > > ship in a

> > > release.

> > > (ii) If a bug is reported, operators are happy to wait until=
 the bug

> > > has been

> > > fixed in the current development release, and will migrate t=
o that

> > > latest

> > > release to pick up the fix.

> > > 

> > > The second thing driving this requirement is that vendors so=
metimes

> > > get asked

> > > for enhancements to existing releases, perhaps because the l=
atest

> > > development

> > > release is too far out, or ask for an enhancement on the cur=
rent

> > > train to be

> > > back ported to an older release.

> > > 

> > > So, aiming to have stable YANG modules, trying a lot harder =
to avoid

> > > non-backwards-compatible changes, and keeping new functional=
ity to

> > > the head of

> > > the development I completely agree with you on. But I still =
believe

> > > that there

> > > are some valid scenarios, that should be limited as much as<=
br>
> > > possible, where it

> > > is necessary to make changes that sometimes break these rule=
s, and

> > > having a

> > > limited scheme that clearly indicates where such breakages h=
ave

> > > occurred is

> > > probably better that the status quo of where the modules get=


> > > changed, but the

> > > operator doesn't get any useful indication of what type =
of changes

> > > are being

> > > made.

> > > 

> > > Thanks,

> > > Rob

> > > 

> > > 

> > > On 25/10/2018 16:26, Christian Hopps wrote:

> > > > 

> > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <jclarke@cisco.com> wrote:

> > > > > 

> > > > > * New requirement 1.4 for supporting over-arching =
software releases

> > > > [ I read this as supporting various different module ve=
rsions

> > > > based on a vendor's different software release trai=
ns. If this

> > > > is wrong then the rest of this doesn't apply and I =
would just

> > > > ask for the text to be update to clarify what it means.=
 ]

> > > > 

> > > > How many operators/users have asked for this or indicat=
ed it's a

> > > > requirement for them?

> > > > 

> > > > What problem is intractable without this requirement be=
ing met,

> > > > and what is the cost of this requirement on the actual =
users?

> > > > 

> > > > I have pushed back multiple times on this b/c I believe=
 this

> > > > "requirement" is really being pushed to make =
it easier for

> > > > vendors (a small affected group) to develop their softw=
are at

> > > > the cost of their users (the much larger affected group=
) who

> > > > would then have to deal with multiple trains of the sam=
e module.

> > > > 

> > > > 

> > > > We already have features and deviations why are they no=
t enough

> > > > to deal with functionality that is present or not in va=
rious

> > > > software release/devices?

> > > > 

> > > > FWIW I'm not against making it easier to develop so=
ftware, but

> > > > we have to be mindful if we are just pushing the cost (=
and

> > > > magnifying it greatly) to other people in the community=
.

> > > > 

> > > > Thanks,

> > > > Chris.

> > > > 

> > > > _______________________________________________
> > > > netmod mailing list

> > > > netmod@ietf.org<=
br>
> > > > https://www.ietf.org/mailman/li=
stinfo/netmod

> > > > .

> > > > 

> > 

> > .

> > 

> 

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--0000000000005c3f460579244f9a--


From nobody Fri Oct 26 11:15:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA4F12D4E8 for ; Fri, 26 Oct 2018 11:15: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, DKIMWL_WL_MED=-0.001, 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 Zo3wO_eUkeVo for ; Fri, 26 Oct 2018 11:15:22 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4AC126CB6 for ; Fri, 26 Oct 2018 11:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42430; q=dns/txt; s=iport; t=1540577721; x=1541787321; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=oADpQuihG/f2ac8AMoA8nqOn1lsd5ObBRwoS9ZYHVlI=; b=NvK21BaJjT1Joe7mAKKZHbJB/SsVW/7XhoRdV8Bpix2QM5xpTqUbEd4S o8RzRzK86oEPY0Yrc6Go5GR74Pqbe8JtSB4tmMzghJwXgqEQ/0o2S/8vR OjknKWrakyu1SWzyYyc/wbbAy8BHcZwRLGhduyn4ayqmBR2JQp7VgAwus E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AABRWNNb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWBW4EQfyiDdYh3jRktmRQDDRgBCoFUgT5xRgKDOTg?= =?us-ascii?q?WAQMBAQIBAQJtHAyFOgEBAQMBAQEYCUkCCAEHCQIJAhAIIAEGAwICGwwfEQY?= =?us-ascii?q?BDAYCAQEQB4MGAYF5CA+KX5tNgS4fhRyEXgUFi3mBQT+BESeBbX6DGwEBgTo?= =?us-ascii?q?RNyaCPYJXAohUBxkuAgOLP4lFVAmJTTuEUoIfBhiBUodsJoZhiTKHFIZMgVo?= =?us-ascii?q?hgVUzGggbFTuCbIF2MBcSawEJgnSEYYU/PjCKcQIkB4IgAQE?=
X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208,217";a="7504066"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 18:15:18 +0000
Received: from [10.61.110.207] (dhcp-10-61-110-207.cisco.com [10.61.110.207]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w9QIFIYr023415;  Fri, 26 Oct 2018 18:15:18 GMT
To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de> 
From: Robert Wilton 
Message-ID: <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com>
Date: Fri, 26 Oct 2018 19:15:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5009699E5FBE683C4A6DDF7D"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.110.207, dhcp-10-61-110-207.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 18:15:25 -0000

This is a multi-part message in MIME format.
--------------5009699E5FBE683C4A6DDF7D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 26/10/2018 17:35, Andy Bierman wrote:
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     Let me add that there was large disagreement what a bug fix is in the
>     design team. Hence, any text that talks about 'bug fixes' is ambiguous
>     and of limited value to achieve consensus. (Or we may find consensus
>     but then not agree on what we have found consensus on.)
>
>     To be more concrete, I learned that Rob's notion of a bug fix is very
>     different from my notion of a bug fix. I think it is important for
>     having a productive discussion to be aware of this.
>
>     For me, a bug fix is rather limited, i.e., fixing something where the
>     correct intention was clear but the model did not properly capture the
>     intention correctly, i.e., roughly what we can do with errata in the
>     IETF. I think Rob understands bug fixes in a much broader sense,
>     including fixes to what essentially are in my view module design
>     errors.
>
>     With my narrow definition of bug fixes, bug fixes are essentially
>     backwards compatible (even if they may violate RFC 7950 rules - but as
>     long as the original intention was clear, we can be flexible).
>
>     With Rob's notion of bug fixes, we have to handle them as part of the
>     versioning system since they may be non-backwards compatible.
>
>
>
> IMO requirements 3.1 and 3.2 are the most  important and have the most 
> impact
> on the solution space. I do not agree with either of these requirements.
OK.

For 3.1, I think that just means that the solution has to be backwards 
compatible with existing clients (e.g. don't change the protocols in a 
non backwards compatible way).

>
> Implementing multiple non-compatible revisions of a module on a server 
> sounds hard,
> not to mention that it breaks RFC 7950 rules.
Completely agree that it will be hard.  I envisage that it will optional 
for servers to implement this.

> The current protocols do not support the
> ability to specify different versions of the same QName. This change 
> makes YANG validation
> much to difficult to specify and implement (as that has to be 
> rewritten as well).
The way that I think of one solution for this problem is using datastore 
schema (as per the NMDA definition):

Say for release X, the server natively supports Module A@ver1.0.0 and 
ModuleB@ver1.0.0, call this schema X.
For release Y, the server natively supports Module A@ver1.1.0 and 
ModuleB@ver2.0.0, call this schema Y.

When a client connects it chooses which schema it wants to use, X, Y, or 
latest.  If it doesn't specify then perhaps it uses the earliest schema 
(to handle requirement 3.1).

If the client wants to use X, then the server has to translate the 
request into the equivalent request using schema Y instead.  Perhaps the 
server has to validate the config both in the context of X and Y.

If the clients wants to use Y then it just talks to the server normally, 
i.e. as it does today.

I think that this is logically the equivalent model mapping that clients 
would have to do to support multiple server revisions.  Yes, I think 
that it is complex.  No, I'm not sure how many vendors will decide to 
implement this, but I think that it is OK to require the solution to 
specify how this is done, so that servers that do want to support this, 
and clients that want to use this, can do so.

But all the QNames, validations, etc, I think would be constrained to a 
particular schema.

>
> It is one thing to deploy rapidly changing, buggy YANG modules in order to
> gain experience quickly..  It is quite another to complicate YANG and 
> the protocols
> to preserve these interim mistakes, and bake into the standards the 
> notion that this
> is good engineering.
Thanks,
Rob

>
>
>     /js
>
>
> Andy
>
>
>     On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
>     > Hi Chris,
>     >
>     >
>     > On 25/10/2018 18:42, Christian Hopps wrote:
>     > >
>     > > Hi Rob,
>     > >
>     > > We've more privately discussed the bug-fix scenario and I'm
>     sympathetic
>     > > to it; however, the requirement as written does not restrict
>     itself to
>     > > fixing module definition bugs (e.g., a pattern or other value
>     > > constraint) in some small but incompatible way -- instead it's
>     wide open
>     > > and it will be [ab]used that way.
>     > I think that everyone on design team agrees that
>     non-backwards-compatible
>     > changes should be minimized and should really only to used for
>     bug fixes
>     > where it is anticipated that clients should not be affected.
>     >
>     > We want to allow non-backwards-compatible changes at the head of the
>     > development tree, but again, I think that everyone agrees that
>     keeping it
>     > backwards compatible where possible is a good goal.
>     >
>     > However, I think that there will be cases where a vendor decides
>     that it is
>     > right for an enhancement or non backwards compatible change to
>     be made to an
>     > already released module.  I agree that this is highly
>     undesirable and an
>     > abuse of the rules, but I don't believe that whatever versioning
>     scheme we
>     > come up with will prevent vendors from doing this. So then the
>     question
>     > becomes: Is it better to pretend that this scenario will never
>     happen,
>     > design the versioning scheme so that it cannot be expressed,
>     which probably
>     > just means that clients will not be able to detect when vendors
>     do this by
>     > cheating the rules!  Or is it better to accept that this will
>     sometimes
>     > occur, provide strong guidance as to why this is bad practice
>     and should be
>     > avoided, but have a versioning scheme that still allows this to
>     be expressed
>     > (in a bounded way)?  I.e. even if the vendors are doing
>     something that is
>     > less than ideal, at least the clients can spot where they have
>     done this.
>     >
>     > ---
>     >
>     > A separate concern that we had about ties this strictly to bug
>     fixes is that
>     > some one will ask for a definition of a bug fix. The design team
>     tried this
>     > but we couldn't even agree what a bug fix is, let alone agree
>     with a single
>     > definition of a bug fix as it related to a YANG module.  So our
>     conclusion
>     > was that perhaps it is better not to tie the requirements
>     themselves to bug
>     > fix vs enhancement, because the boundary between the two is too
>     vague, and
>     > module writers will bend the rules.
>     >
>     > So I see that the rules should be:
>     >  - backwards compatible bug fix  - this is fine.
>     >  - non backwards compatible bug fix - this is fine if it is
>     pragmatically
>     > expected to not impact any clients, but careful consideration is
>     required if
>     > it might break clients.
>     >  - backwards compatible enhancement - not ideal, but
>     pragmatically OK.
>     >  - non backwards compatible enhancement - this is bad and should
>     be avoided.
>     >
>     > But if we don't want to define the difference between a bug fix vs
>     > enhancement then I think that you end up with the most general
>     requirement
>     > being that we do want to allow for non-backwards-compatible
>     changes in
>     > released modules to accommodate the bug fix scenario, but the
>     expectation
>     > (and guidance) will be that they should only be used for bug fixes.
>     >
>     >
>     > >
>     > > For example:
>     > >
>     > > > Here is what I am afraid the vendors want here: A developer on
>     > > > release train X can easily change some data structure and
>     then push
>     > > > the change into an automated system which generates a new YANG
>     > > > module definition and revs a version number -- all done!
>     They don't
>     > > > have to deal with the inertia of making this change in their
>     release
>     > > > train Y or Z and they don't have to treat modules as a
>     stable API
>     > > > they are exporting, b/c they now have these new wonderful
>     versions
>     > > > from this work. Meanwhile we the users now have to deal with
>     N forks
>     > > > with all the various little incompatible changes random
>     developers
>     > > > at the company wanted to make without having to coordinate with
>     > > > their coworkers/other internal teams. Now multiply this by M
>     > > > vendors. It's a nightmare. It shouldn't be what we are
>     optimizing
>     > > > for, let alone making a requirement.
>     > >
>     > > Regarding enhancements, these are features, and are naturally
>     > > augmentative. I find it hard to believe we have a pressing
>     > > need/requirement to support non-backward compatible changes to
>     existing
>     > > modules in order to support enhancements.
>     > I agree.  It was a backwards compatible enhancement that I was
>     considering.
>     >
>     > Thanks,
>     > Rob
>     >
>     >
>     > >
>     > > Thanks,
>     > > Chris.
>     > >
>     > >
>     > > Robert Wilton >
>     writes:
>     > >
>     > > > Hi Chris,
>     > > >
>     > > > I think that there are two things driving this requirement:
>     > > >
>     > > > What I regard as the key one, is that we want to be able to
>     support
>     > > > the software
>     > > > that we have shipped. In particular, we may need to fix bugs
>     > > > (perhaps at the
>     > > > operators request) to a YANG model that has already been
>     released.
>     > > > I.e. I think
>     > > > that there are some scenarios, where forking a YANG module,
>     although
>     > > > undesirable
>     > > > is the right thing to do to include a fix. I don't believe that
>     > > > features or
>     > > > deviations help solve this problem.
>     > > > The two alternative solutions to being able to fix bugs,
>     neither of
>     > > > which I
>     > > > think is pragmatic, that I can think of are:
>     > > > (i) Vendors ensure that their YANG modules are perfect
>     before they
>     > > > ship in a
>     > > > release.
>     > > > (ii) If a bug is reported, operators are happy to wait until
>     the bug
>     > > > has been
>     > > > fixed in the current development release, and will migrate
>     to that
>     > > > latest
>     > > > release to pick up the fix.
>     > > >
>     > > > The second thing driving this requirement is that vendors
>     sometimes
>     > > > get asked
>     > > > for enhancements to existing releases, perhaps because the
>     latest
>     > > > development
>     > > > release is too far out, or ask for an enhancement on the current
>     > > > train to be
>     > > > back ported to an older release.
>     > > >
>     > > > So, aiming to have stable YANG modules, trying a lot harder
>     to avoid
>     > > > non-backwards-compatible changes, and keeping new
>     functionality to
>     > > > the head of
>     > > > the development I completely agree with you on. But I still
>     believe
>     > > > that there
>     > > > are some valid scenarios, that should be limited as much as
>     > > > possible, where it
>     > > > is necessary to make changes that sometimes break these
>     rules, and
>     > > > having a
>     > > > limited scheme that clearly indicates where such breakages have
>     > > > occurred is
>     > > > probably better that the status quo of where the modules get
>     > > > changed, but the
>     > > > operator doesn't get any useful indication of what type of
>     changes
>     > > > are being
>     > > > made.
>     > > >
>     > > > Thanks,
>     > > > Rob
>     > > >
>     > > >
>     > > > On 25/10/2018 16:26, Christian Hopps wrote:
>     > > > >
>     > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke
>     > wrote:
>     > > > > >
>     > > > > > * New requirement 1.4 for supporting over-arching
>     software releases
>     > > > > [ I read this as supporting various different module versions
>     > > > > based on a vendor's different software release trains. If this
>     > > > > is wrong then the rest of this doesn't apply and I would just
>     > > > > ask for the text to be update to clarify what it means. ]
>     > > > >
>     > > > > How many operators/users have asked for this or indicated
>     it's a
>     > > > > requirement for them?
>     > > > >
>     > > > > What problem is intractable without this requirement being
>     met,
>     > > > > and what is the cost of this requirement on the actual users?
>     > > > >
>     > > > > I have pushed back multiple times on this b/c I believe this
>     > > > > "requirement" is really being pushed to make it easier for
>     > > > > vendors (a small affected group) to develop their software at
>     > > > > the cost of their users (the much larger affected group) who
>     > > > > would then have to deal with multiple trains of the same
>     module.
>     > > > >
>     > > > >
>     > > > > We already have features and deviations why are they not
>     enough
>     > > > > to deal with functionality that is present or not in various
>     > > > > software release/devices?
>     > > > >
>     > > > > FWIW I'm not against making it easier to develop software, but
>     > > > > we have to be mindful if we are just pushing the cost (and
>     > > > > magnifying it greatly) to other people in the community..
>     > > > >
>     > > > > Thanks,
>     > > > > Chris.
>     > > > >
>     > > > > _______________________________________________
>     > > > > netmod mailing list
>     > > > > netmod@ietf.org 
>     > > > > https://www.ietf.org/mailman/listinfo/netmod
>     
>     > > > > .
>     > > > >
>     > >
>     > > .
>     > >
>     >
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/netmod
>     
>
>     -- 
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------5009699E5FBE683C4A6DDF7D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 26/10/2018 17:35, Andy Bierman
      wrote:

    

    

      
      

        


          


            
On Fri, Oct 26, 2018 at 2:33 AM,
              Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
              wrote:

              
Let me add that there
                was large disagreement what a bug fix is in the

                design team. Hence, any text that talks about 'bug
                fixes' is ambiguous

                and of limited value to achieve consensus. (Or we may
                find consensus

                but then not agree on what we have found consensus on.)

                

                To be more concrete, I learned that Rob's notion of a
                bug fix is very

                different from my notion of a bug fix. I think it is
                important for

                having a productive discussion to be aware of this.

                

                For me, a bug fix is rather limited, i.e., fixing
                something where the

                correct intention was clear but the model did not
                properly capture the

                intention correctly, i.e., roughly what we can do with
                errata in the

                IETF. I think Rob understands bug fixes in a much
                broader sense,

                including fixes to what essentially are in my view
                module design

                errors.

                

                With my narrow definition of bug fixes, bug fixes are
                essentially

                backwards compatible (even if they may violate RFC 7950
                rules - but as

                long as the original intention was clear, we can be
                flexible).

                

                With Rob's notion of bug fixes, we have to handle them
                as part of the

                versioning system since they may be non-backwards
                compatible.

                

              

              


              

              


              

              
IMO requirements 3.1 and 3.2 are the most  important
                and have the most impact

              
on the solution space. I do not agree with either of
                these requirements.

            

          

        

      

    

    OK.

    

    For 3.1, I think that just means that the solution has to be
    backwards compatible with existing clients (e.g. don't change the
    protocols in a non backwards compatible way).

    

    

      

        

          

            

              


              

              
Implementing multiple non-compatible revisions of a
                module on a server sounds hard,

              
not to mention that it breaks RFC 7950 rules. 

            

          

        

      

    

    Completely agree that it will be hard.  I envisage that it will
    optional for servers to implement this.

    

    

      

        

          

            

              
The current protocols do not support the

              
ability to specify different versions of the same
                QName. This change makes YANG validation

              
much to difficult to specify and implement (as that
                has to be rewritten as well).

            

          

        

      

    

    The way that I think of one solution for this problem is using
    datastore schema (as per the NMDA definition):

    

    Say for release X, the server natively supports Module A@ver1.0.0
    and ModuleB@ver1.0.0, call this schema X.

    For release Y, the server natively supports Module A@ver1.1.0 and
    ModuleB@ver2.0.0, call this schema Y.

    

    When a client connects it chooses which schema it wants to use, X,
    Y, or latest.  If it doesn't specify then perhaps it uses the
    earliest schema (to handle requirement 3.1).

    

    If the client wants to use X, then the server has to translate the
    request into the equivalent request using schema Y instead.  Perhaps
    the server has to validate the config both in the context of X and
    Y.

    

    If the clients wants to use Y then it just talks to the server
    normally, i.e. as it does today.

    

    I think that this is logically the equivalent model mapping that
    clients would have to do to support multiple server revisions.  Yes,
    I think that it is complex.  No, I'm not sure how many vendors will
    decide to implement this, but I think that it is OK to require the
    solution to specify how this is done, so that servers that do want
    to support this, and clients that want to use this, can do so.

    

    But all the QNames, validations, etc, I think would be constrained
    to a particular schema.

    

    

      

        

          

            

              


              

              
It is one thing to deploy rapidly changing, buggy
                YANG modules in order to

              
gain experience quickly..  It is quite another to
                complicate YANG and the protocols

              
to preserve these interim mistakes, and bake into the
                standards the notion that this

              
is good engineering.

            

          

        

      

    

    Thanks,

    Rob

    

    

      

        

          

            

              


              

              


              

              

                /js

              

              


              

              
Andy

              
 

              

                

                On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton
                wrote:

                > Hi Chris,

                > 

                > 

                > On 25/10/2018 18:42, Christian Hopps wrote:

                > > 

                > > Hi Rob,

                > > 

                > > We've more privately discussed the bug-fix
                scenario and I'm sympathetic

                > > to it; however, the requirement as written
                does not restrict itself to

                > > fixing module definition bugs (e.g., a pattern
                or other value

                > > constraint) in some small but incompatible way
                -- instead it's wide open

                > > and it will be [ab]used that way.

                > I think that everyone on design team agrees that
                non-backwards-compatible

                > changes should be minimized and should really only
                to used for bug fixes

                > where it is anticipated that clients should not be
                affected.

                > 

                > We want to allow non-backwards-compatible changes
                at the head of the

                > development tree, but again, I think that everyone
                agrees that keeping it

                > backwards compatible where possible is a good goal.

                > 

                > However, I think that there will be cases where a
                vendor decides that it is

                > right for an enhancement or non backwards
                compatible change to be made to an

                > already released module.  I agree that this is
                highly undesirable and an

                > abuse of the rules, but I don't believe that
                whatever versioning scheme we

                > come up with will prevent vendors from doing this. 
                So then the question

                > becomes: Is it better to pretend that this scenario
                will never happen,

                > design the versioning scheme so that it cannot be
                expressed, which probably

                > just means that clients will not be able to detect
                when vendors do this by

                > cheating the rules!  Or is it better to accept that
                this will sometimes

                > occur, provide strong guidance as to why this is
                bad practice and should be

                > avoided, but have a versioning scheme that still
                allows this to be expressed

                > (in a bounded way)?  I.e. even if the vendors are
                doing something that is

                > less than ideal, at least the clients can spot
                where they have done this.

                > 

                > ---

                > 

                > A separate concern that we had about ties this
                strictly to bug fixes is that

                > some one will ask for a definition of a bug fix. 
                The design team tried this

                > but we couldn't even agree what a bug fix is, let
                alone agree with a single

                > definition of a bug fix as it related to a YANG
                module.  So our conclusion

                > was that perhaps it is better not to tie the
                requirements themselves to bug

                > fix vs enhancement, because the boundary between
                the two is too vague, and

                > module writers will bend the rules.

                > 

                > So I see that the rules should be:

                >  - backwards compatible bug fix  - this is fine.

                >  - non backwards compatible bug fix - this is fine
                if it is pragmatically

                > expected to not impact any clients, but careful
                consideration is required if

                > it might break clients.

                >  - backwards compatible enhancement - not ideal,
                but pragmatically OK.

                >  - non backwards compatible enhancement - this is
                bad and should be avoided.

                > 

                > But if we don't want to define the difference
                between a bug fix vs

                > enhancement then I think that you end up with the
                most general requirement

                > being that we do want to allow for
                non-backwards-compatible changes in

                > released modules to accommodate the bug fix
                scenario, but the expectation

                > (and guidance) will be that they should only be
                used for bug fixes.

                > 

                > 

                > > 

                > > For example:

                > > 

                > > > Here is what I am afraid the vendors want
                here: A developer on

                > > > release train X can easily change some
                data structure and then push

                > > > the change into an automated system which
                generates a new YANG

                > > > module definition and revs a version
                number -- all done! They don't

                > > > have to deal with the inertia of making
                this change in their release

                > > > train Y or Z and they don't have to treat
                modules as a stable API

                > > > they are exporting, b/c they now have
                these new wonderful versions

                > > > from this work. Meanwhile we the users
                now have to deal with N forks

                > > > with all the various little incompatible
                changes random developers

                > > > at the company wanted to make without
                having to coordinate with

                > > > their coworkers/other internal teams. Now
                multiply this by M

                > > > vendors. It's a nightmare. It shouldn't
                be what we are optimizing

                > > > for, let alone making a requirement.

                > > 

                > > Regarding enhancements, these are features,
                and are naturally

                > > augmentative. I find it hard to believe we
                have a pressing

                > > need/requirement to support non-backward
                compatible changes to existing

                > > modules in order to support enhancements.

                > I agree.  It was a backwards compatible enhancement
                that I was considering.

                > 

                > Thanks,

                > Rob

                > 

                > 

                > > 

                > > Thanks,

                > > Chris.

                > > 

                > > 

                > > Robert Wilton <rwilton@cisco.com>
                writes:

                > > 

                > > > Hi Chris,

                > > > 

                > > > I think that there are two things driving
                this requirement:

                > > > 

                > > > What I regard as the key one, is that we
                want to be able to support

                > > > the software

                > > > that we have shipped. In particular, we
                may need to fix bugs

                > > > (perhaps at the

                > > > operators request) to a YANG model that
                has already been released.

                > > > I.e. I think

                > > > that there are some scenarios, where
                forking a YANG module, although

                > > > undesirable

                > > > is the right thing to do to include a
                fix. I don't believe that

                > > > features or

                > > > deviations help solve this problem.

                > > > The two alternative solutions to being
                able to fix bugs, neither of

                > > > which I

                > > > think is pragmatic, that I can think of
                are:

                > > > (i) Vendors ensure that their YANG
                modules are perfect before they

                > > > ship in a

                > > > release.

                > > > (ii) If a bug is reported, operators are
                happy to wait until the bug

                > > > has been

                > > > fixed in the current development release,
                and will migrate to that

                > > > latest

                > > > release to pick up the fix.

                > > > 

                > > > The second thing driving this requirement
                is that vendors sometimes

                > > > get asked

                > > > for enhancements to existing releases,
                perhaps because the latest

                > > > development

                > > > release is too far out, or ask for an
                enhancement on the current

                > > > train to be

                > > > back ported to an older release.

                > > > 

                > > > So, aiming to have stable YANG modules,
                trying a lot harder to avoid

                > > > non-backwards-compatible changes, and
                keeping new functionality to

                > > > the head of

                > > > the development I completely agree with
                you on. But I still believe

                > > > that there

                > > > are some valid scenarios, that should be
                limited as much as

                > > > possible, where it

                > > > is necessary to make changes that
                sometimes break these rules, and

                > > > having a

                > > > limited scheme that clearly indicates
                where such breakages have

                > > > occurred is

                > > > probably better that the status quo of
                where the modules get

                > > > changed, but the

                > > > operator doesn't get any useful
                indication of what type of changes

                > > > are being

                > > > made.

                > > > 

                > > > Thanks,

                > > > Rob

                > > > 

                > > > 

                > > > On 25/10/2018 16:26, Christian Hopps
                wrote:

                > > > > 

                > > > > > On Oct 20, 2018, at 1:55 PM,
                Joe Clarke <jclarke@cisco.com>
                wrote:

                > > > > > 

                > > > > > * New requirement 1.4 for
                supporting over-arching software releases

                > > > > [ I read this as supporting various
                different module versions

                > > > > based on a vendor's different
                software release trains. If this

                > > > > is wrong then the rest of this
                doesn't apply and I would just

                > > > > ask for the text to be update to
                clarify what it means. ]

                > > > > 

                > > > > How many operators/users have asked
                for this or indicated it's a

                > > > > requirement for them?

                > > > > 

                > > > > What problem is intractable without
                this requirement being met,

                > > > > and what is the cost of this
                requirement on the actual users?

                > > > > 

                > > > > I have pushed back multiple times on
                this b/c I believe this

                > > > > "requirement" is really being pushed
                to make it easier for

                > > > > vendors (a small affected group) to
                develop their software at

                > > > > the cost of their users (the much
                larger affected group) who

                > > > > would then have to deal with
                multiple trains of the same module.

                > > > > 

                > > > > 

                > > > > We already have features and
                deviations why are they not enough

                > > > > to deal with functionality that is
                present or not in various

                > > > > software release/devices?

                > > > > 

                > > > > FWIW I'm not against making it
                easier to develop software, but

                > > > > we have to be mindful if we are just
                pushing the cost (and

                > > > > magnifying it greatly) to other
                people in the community..

                > > > > 

                > > > > Thanks,

                > > > > Chris.

                > > > > 

                > > > > _______________________________________________

                > > > > netmod mailing list

                > > > > netmod@ietf.org

                > > > > https://www.ietf.org/mailman/listinfo/netmod

                > > > > .

                > > > > 

                > > 

                > > .

                > > 

                > 

                > _______________________________________________

                > netmod mailing list

                > netmod@ietf.org

                > https://www.ietf.org/mailman/listinfo/netmod

                

                    -- 

                    Juergen Schoenwaelder           Jacobs University
                    Bremen gGmbH

                    Phone: +49 421 200 3587         Campus Ring 1 |
                    28759 Bremen | Germany

                    Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

                    

                    _______________________________________________

                    netmod mailing list

                    netmod@ietf.org

                    https://www.ietf.org/mailman/listinfo/netmod

                  

            

            

          

        

      

      

      

      

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


    

    

  


--------------5009699E5FBE683C4A6DDF7D--


From nobody Fri Oct 26 16:01:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5531F124C04 for ; Fri, 26 Oct 2018 16:01:54 -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 PJx7dAwm6dHg for ; Fri, 26 Oct 2018 16:01:52 -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 DA10412008A for ; Fri, 26 Oct 2018 16:01:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CF423EE7; Sat, 27 Oct 2018 01:01:49 +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 a8PY0U1ZtgVg; Sat, 27 Oct 2018 01:01:47 +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; Sat, 27 Oct 2018 01:01:49 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90AFE2003B; Sat, 27 Oct 2018 01:01:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lUziYh6Couc3; Sat, 27 Oct 2018 01:01:49 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 31AAA2003A; Sat, 27 Oct 2018 01:01:49 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 27 Oct 2018 01:01:48 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 878E43002A0984; Sat, 27 Oct 2018 01:01:48 +0200 (CEST)
Date: Sat, 27 Oct 2018 01:01:48 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: "netmod@ietf.org" 
Message-ID: <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 23:01:54 -0000

On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> 
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
> 
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> not to mention that it breaks RFC 7950 rules. The current protocols do not
> support the
> ability to specify different versions of the same QName. This change makes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten as
> well).
> 
> It is one thing to deploy rapidly changing, buggy YANG modules in order to
> gain experience quickly.  It is quite another to complicate YANG and the
> protocols
> to preserve these interim mistakes, and bake into the standards the notion
> that this
> is good engineering.
>

So how do you think this conflict between more agility and client
stability should be handled? It seems you can't easily have both at
the same time. Are you saying that backwards compatibility to support
existing clients is not important?

/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 Fri Oct 26 16:36:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7675127148 for ; Fri, 26 Oct 2018 16:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 oNRCwaq0SlAI for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4382912008A for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id c21-v6so2655862ljj.1 for ; Fri, 26 Oct 2018 16:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iVW8Pb/LuZyCJvaS2FaN7IRzenXQm+uPDVGgjwmIdVk=; b=R9Kd7SULFPc9X8u7zGdiJaCC3muOUbb5ZDkvwwFMq6zpQ77LXiXeP/oEaiIh6bSMCm Eomvux/voejVqaz/d+RjUWmqN9f8fCpYFBR0DMKSyEP6YWl+DqhgPGx1dYYpuaUXe7Qt RySHK49+vxXjV8emIhH9jux4ayw08RFE1YTzQ12GRoLLYvFjjnfbn3dbBIlV8s2jvtia RiaIR95c9ZQTKyULrHWagKDdsFKA8cDvS9NGXxqNzuaOsJTQBtx3XTg3NNzloUuWJ5GD 8LRbLVbfaAlQ61ryRPiWPdgLuOeE3Iou+4HEOC2eeueYn6XMjK0tzAVvWDslc16QSxRw 6VEg==
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=iVW8Pb/LuZyCJvaS2FaN7IRzenXQm+uPDVGgjwmIdVk=; b=CHrx5VnsWYqZtoIxEpBZBevb/AYJfK6MnpGqPBjM3RTS48RsHb+fNMBuGkI4P38Q2p 2XugyJn/wVVpSmkt3AAqgbG+RMZ9mA9L/wmni/VLKjEwcY8/uLuNHPC72TOkPcUTh07p mhiYSUHSsv3rnSiTuxtsaC90+bgC1F3vr07oqsR36IDaGD/8tiHfRoRTZYWVYcLtGB9b fcS1XHetsW72rLhepw8D/erW0KdBRUaKP8FNur2Fjo9R7jdY/+2DEmLooLovUja+3ZDA aEPCKOYhqPHgRjMWs+Xim58qi5BJlrLjm2PexCaJaW3XMg7EiLkPXU+CftTZvn5hBXlT x4Dw==
X-Gm-Message-State: AGRZ1gJ5tuRgopdfSZtg1/aubil0yyiRlLRdcOg2iTsyMYQGeuP+yjwV f28uWytd7lWGmjYEz+FllGHqHsSdvMCoX58IrZHhbg==
X-Google-Smtp-Source: AJdET5cB1W8tBBebSkI7M5voP36Z155w3iyLiGeBl4jvJ4+EBY2p+/YjTkH4yxFrzROdN2OKjega7rr5FOOyzd5n98Y=
X-Received: by 2002:a2e:4408:: with SMTP id r8-v6mr3978803lja.21.1540596989042;  Fri, 26 Oct 2018 16:36:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 26 Oct 2018 16:36:26 -0700 (PDT)
In-Reply-To: <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 26 Oct 2018 16:36:26 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000462faf05792a30ce"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2018 23:36:34 -0000

--000000000000462faf05792a30ce
Content-Type: text/plain; charset="UTF-8"

On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> >
> > IMO requirements 3.1 and 3.2 are the most  important and have the most
> > impact
> > on the solution space. I do not agree with either of these requirements.
> >
> > Implementing multiple non-compatible revisions of a module on a server
> > sounds hard,
> > not to mention that it breaks RFC 7950 rules. The current protocols do
> not
> > support the
> > ability to specify different versions of the same QName. This change
> makes
> > YANG validation
> > much to difficult to specify and implement (as that has to be rewritten
> as
> > well).
> >
> > It is one thing to deploy rapidly changing, buggy YANG modules in order
> to
> > gain experience quickly.  It is quite another to complicate YANG and the
> > protocols
> > to preserve these interim mistakes, and bake into the standards the
> notion
> > that this
> > is good engineering.
> >
>
> So how do you think this conflict between more agility and client
> stability should be handled? It seems you can't easily have both at
> the same time. Are you saying that backwards compatibility to support
> existing clients is not important?
>
>
It depends on the data model and how broken it is in the replaced version.
YANG validation is slow and complicated enough without pretending there
are 8 or 10 separate schema trees within a datastore. It might be impossible
for all constraints to be true in all schema trees at once.  It is a burden
on operators
and client developers to understand and properly manage multiple
incompatible revisions
of the same module

yang-library is a good example of a clean break.
The /yang-library tree completely replaces the /modules-state tree.
A server can easily support both subtrees.
No new YANG or protocol features are needed at all.
This was not a bugfix, just the normal instability in the IETF.

Even with this clean break, there could be external modules that have
leafref
or must/when that point at the /modules-state subtree.  They have to be
rewritten
to use /yang-library instead. But this can happen as needed since the old
tree is unchanged.

For truly broken changes (e.g. change a node from a container to a list;
change a leaf from type boolean to an enumerated type w/ 6 enums;
remove or rename lots of existing nodes) the cross-references from external
modules can easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
not needed.
Another - just the opposite.


Andy



/js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierm=
an wrote:

> 

> IMO requirements 3.1 and 3.2 are the most=C2=A0 important and have the=
 most

> impact

> on the solution space. I do not agree with either of these requirement=
s.

> 

> Implementing multiple non-compatible revisions of a module on a server=


> sounds hard,

> not to mention that it breaks RFC 7950 rules. The current protocols do=
 not

> support the

> ability to specify different versions of the same QName. This change m=
akes

> YANG validation

> much to difficult to specify and implement (as that has to be rewritte=
n as

> well).

> 

> It is one thing to deploy rapidly changing, buggy YANG modules in orde=
r to

> gain experience quickly.=C2=A0 It is quite another to complicate YANG =
and the

> protocols

> to preserve these interim mistakes, and bake into the standards the no=
tion

> that this

> is good engineering.

>



So how do you think this conflict between more agility and client

stability should be handled? It seems you can't easily have both at

the same time. Are you saying that backwards compatibility to support

existing clients is not important?



It depends on the data model and how broken it is in=
 the replaced version.
YANG validation is slow and complicated en=
ough without pretending there
are 8 or 10 separate schema trees w=
ithin a datastore. It might be impossible
for all constraints to =
be true in all schema trees at once.=C2=A0 It is a burden on operators
and client developers to understand and properly manage multiple inco=
mpatible revisions
of the same module

ya=
ng-library is a good example of a clean break.
The /yang-library =
tree completely replaces the /modules-state tree.
A server can ea=
sily support both subtrees.
No new YANG or protocol features are =
needed at all.
This was not a bugfix, just the normal instability=
 in the IETF.

Even with this clean break, there co=
uld be external modules that have leafref
or must/when that point=
 at the /modules-state subtree.=C2=A0 They have to be rewritten
to use /yang-library instead. But this can happen as needed since the ol=
d tree is unchanged.

For truly broken changes (e.g=
. change a node from a container to a list;
change a leaf from ty=
pe boolean to an enumerated type w/ 6 enums;
remove or rename lot=
s of existing nodes) the cross-references from external
modules c=
an easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2=
 not needed.
Another - just the opposite.


Andy




/js



-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--000000000000462faf05792a30ce--


From nobody Sat Oct 27 01:36:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBACE12F1A6 for ; Sat, 27 Oct 2018 01:36:36 -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 rAy9nQ4KB9ZB for ; Sat, 27 Oct 2018 01:36:34 -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 D11AF12D4E6 for ; Sat, 27 Oct 2018 01:36:32 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 91D77F79; Sat, 27 Oct 2018 10:36:30 +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 mz2V6kSU1IUW; Sat, 27 Oct 2018 10:36: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; Sat, 27 Oct 2018 10:36:30 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BBE42003B; Sat, 27 Oct 2018 10:36:30 +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 w1t2kk4TX2L9; Sat, 27 Oct 2018 10:36:29 +0200 (CEST)
Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B4C3B2003A; Sat, 27 Oct 2018 10:36:29 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 27 Oct 2018 10:36:29 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 067D53002A1166; Sat, 27 Oct 2018 10:36:28 +0200 (CEST)
Date: Sat, 27 Oct 2018 10:36:28 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: "netmod@ietf.org" 
Message-ID: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "netmod@ietf.org" 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Oct 2018 08:36:37 -0000

On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierman wrote:
> On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO requirements 3.1 and 3.2 are the most  important and have the most
> > > impact
> > > on the solution space. I do not agree with either of these requirements.
> > >
> > > Implementing multiple non-compatible revisions of a module on a server
> > > sounds hard,
> > > not to mention that it breaks RFC 7950 rules. The current protocols do
> > not
> > > support the
> > > ability to specify different versions of the same QName. This change
> > makes
> > > YANG validation
> > > much to difficult to specify and implement (as that has to be rewritten
> > as
> > > well).
> > >
> > > It is one thing to deploy rapidly changing, buggy YANG modules in order
> > to
> > > gain experience quickly.  It is quite another to complicate YANG and the
> > > protocols
> > > to preserve these interim mistakes, and bake into the standards the
> > notion
> > > that this
> > > is good engineering.
> > >
> >
> > So how do you think this conflict between more agility and client
> > stability should be handled? It seems you can't easily have both at
> > the same time. Are you saying that backwards compatibility to support
> > existing clients is not important?
> >
> >
> It depends on the data model and how broken it is in the replaced version.
> YANG validation is slow and complicated enough without pretending there
> are 8 or 10 separate schema trees within a datastore. It might be impossible
> for all constraints to be true in all schema trees at once.  It is a burden
> on operators
> and client developers to understand and properly manage multiple
> incompatible revisions
> of the same module
> 
> yang-library is a good example of a clean break.
> The /yang-library tree completely replaces the /modules-state tree.
> A server can easily support both subtrees.
> No new YANG or protocol features are needed at all.
> This was not a bugfix, just the normal instability in the IETF.
> 
> Even with this clean break, there could be external modules that have
> leafref
> or must/when that point at the /modules-state subtree.  They have to be
> rewritten
> to use /yang-library instead. But this can happen as needed since the old
> tree is unchanged.
> 
> For truly broken changes (e.g. change a node from a container to a list;
> change a leaf from type boolean to an enumerated type w/ 6 enums;
> remove or rename lots of existing nodes) the cross-references from external
> modules can easily be incorrect if used with the new version.
> 
> The NETMOD WG chose to add a new /yang-library tree instead of
> mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
> not needed.
>

       3.1  The solution MUST provide a mechanism to allow servers to
            support existing clients in a backwards-compatible way.

I believe 3.1 is exactly what we have today. If it is necessary to
make incompatible changes, you create new definitions. This allows
servers to support existing clients in a backwards-compatible way (as
long as the old and new definitions are not conflicting.)

       3.2  The solution MUST provide a mechanism to allow servers to
            simultaneously support clients using different revisions of
            modules.  A client's choice of particular revision of one or
            more modules may restrict the particular revision of other
            modules that may be used in the same request or session.

Today, the version number is effectively an (implicit) part of the
module name (plus the revision date for backwards compatible changes).
Hence, my understanding is that today's model does satisfy 3.2 as
well.

If we want to increase 'agility' in an attempt to make it easier to
deliver early designs and to fix them on the go, the costs will go up
somewhere. The extreme cases are:

1) The server can make changes to YANG modules in arbitrary ways and
   the clients have to adapt, i.e., clients have to pay the bill.

2) The server has to provide strict backwards compatibility in order
   to not break clients, i.e., servers have to pay the bill.

The question is whether there is a solution somewhere in the middle
that balances the costs and eases the process of adapting clients to
servers and vice versa. It might very well be that there is no sweet
point.

Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
important requirements.

/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 Sat Oct 27 06:51:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB67127333 for ; Sat, 27 Oct 2018 06:51: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 fss9_YeK_ClB for ; Sat, 27 Oct 2018 06:51:03 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 A81CC124D68 for ; Sat, 27 Oct 2018 06:51:02 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id h192so2958617lfg.3 for ; Sat, 27 Oct 2018 06:51:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Kp80oZyL/D7Xv6L4U2qNOWbcrYRQLIMow6yvyQ24iJ0=; b=SQr6MMO+ofJ03lMSu1IWK9R/RWPFen6HnLbI7paHXbP8M4Y4U+QRgeQfF/7rS3/ELH K0v36jR1kco0iUgkiwc5/x4ldms60EnUpuLhCxF8ytrnGJ0w+u3ecScxxjc5p0n9iyQs 6A9fCe7FBy7AAtiPK/h2u//4666VPcjKYchXcmK99nWVTqiw1W6zje3hkqZs/u7ZVyFX bNR5/Sv/uiU6PpDn/JfW66Hbbk6evvHKiVNsyfntRLSVjNw3EzbEJVXZSbFBmXCZYPEL XPFueGu9eLSQ56RKGnIrAUqqyj0o+cJ4Yt+wV3b8eqCmT0KJtpRAX4buN1CIgKEVaQRc 84mw==
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=Kp80oZyL/D7Xv6L4U2qNOWbcrYRQLIMow6yvyQ24iJ0=; b=BrrPWE8XU6plQ7/xadXBUFfOWs/gozgWNi8taHYYQqKROkjr5Qzj3/AWJJberA8S/9 5dpnNN7AQOEnnCdDkXDXmbqcc97G/5Hbs1sjMcz7pp2XE856qA9MRUUYWOiOZtqWrRL9 Bhztixl3MkFsrJoU+Z+fHc8D7Ejf8f3quA9VAurxCs4X4TF3xX6272QUja3MQ49AUald cWaQ1FV/ouFkJGm/viRr5I9ll017acwXr+FRHVZiiFtBGz8Oic8BaKd95iooWsvXfnxS t0SD0FosFdiqY0GE7x41T5B2ZikOLogKzuTE3J9Ni7vdiPFnIYEwcoWw6VugV5nBP9hK VeoA==
X-Gm-Message-State: AGRZ1gJDQ9NNUZVQpOswu6srSteYBDJW8rEXB4iBnVznpNLRT3kHbXgZ 8oa5d8nyh15D9UpdSc3jOZjpyI/2l+cq4ZycxycnPA==
X-Google-Smtp-Source: AJdET5e74L6KyFvuDGMsYKk6q/P0T3MEXhnqF6fPaiAWlLoMff0u4HnfP+1PZK5JKpU+dScpWoMe83FUgjGSkvh7MOY=
X-Received: by 2002:a19:750a:: with SMTP id y10mr4376277lfe.43.1540648260632;  Sat, 27 Oct 2018 06:51:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Sat, 27 Oct 2018 06:50:58 -0700 (PDT)
In-Reply-To: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>  <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Sat, 27 Oct 2018 06:50:58 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004c9ec705793620fd"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Oct 2018 13:51:06 -0000

--0000000000004c9ec705793620fd
Content-Type: text/plain; charset="UTF-8"

On Sat, Oct 27, 2018 at 1:36 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierman wrote:
> > On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> > > >
> > > > IMO requirements 3.1 and 3.2 are the most  important and have the
> most
> > > > impact
> > > > on the solution space. I do not agree with either of these
> requirements.
> > > >
> > > > Implementing multiple non-compatible revisions of a module on a
> server
> > > > sounds hard,
> > > > not to mention that it breaks RFC 7950 rules. The current protocols
> do
> > > not
> > > > support the
> > > > ability to specify different versions of the same QName. This change
> > > makes
> > > > YANG validation
> > > > much to difficult to specify and implement (as that has to be
> rewritten
> > > as
> > > > well).
> > > >
> > > > It is one thing to deploy rapidly changing, buggy YANG modules in
> order
> > > to
> > > > gain experience quickly.  It is quite another to complicate YANG and
> the
> > > > protocols
> > > > to preserve these interim mistakes, and bake into the standards the
> > > notion
> > > > that this
> > > > is good engineering.
> > > >
> > >
> > > So how do you think this conflict between more agility and client
> > > stability should be handled? It seems you can't easily have both at
> > > the same time. Are you saying that backwards compatibility to support
> > > existing clients is not important?
> > >
> > >
> > It depends on the data model and how broken it is in the replaced
> version.
> > YANG validation is slow and complicated enough without pretending there
> > are 8 or 10 separate schema trees within a datastore. It might be
> impossible
> > for all constraints to be true in all schema trees at once.  It is a
> burden
> > on operators
> > and client developers to understand and properly manage multiple
> > incompatible revisions
> > of the same module
> >
> > yang-library is a good example of a clean break.
> > The /yang-library tree completely replaces the /modules-state tree.
> > A server can easily support both subtrees.
> > No new YANG or protocol features are needed at all.
> > This was not a bugfix, just the normal instability in the IETF.
> >
> > Even with this clean break, there could be external modules that have
> > leafref
> > or must/when that point at the /modules-state subtree.  They have to be
> > rewritten
> > to use /yang-library instead. But this can happen as needed since the old
> > tree is unchanged.
> >
> > For truly broken changes (e.g. change a node from a container to a list;
> > change a leaf from type boolean to an enumerated type w/ 6 enums;
> > remove or rename lots of existing nodes) the cross-references from
> external
> > modules can easily be incorrect if used with the new version.
> >
> > The NETMOD WG chose to add a new /yang-library tree instead of
> > mangling the existing nodes. One design choice makes req. 3.1 easy and
> 3.2
> > not needed.
> >
>
>        3.1  The solution MUST provide a mechanism to allow servers to
>             support existing clients in a backwards-compatible way.
>
> I believe 3.1 is exactly what we have today. If it is necessary to
> make incompatible changes, you create new definitions. This allows
> servers to support existing clients in a backwards-compatible way (as
> long as the old and new definitions are not conflicting.)
>


This is what we have today only if modules are updated in legal ways.
The 3.1 requirement says this backward compatibility is maintained even
if the module is updated in violation of the module update rules.

How would 3.1 be met if the WG decided to just add a new 'datastore' key
leaf
to the /modules-state/module list?

IMO the current "deprecate and start over" is actually the easiest and most
robust
solution path, and it requires no changes to YANG or the protocols.




>        3.2  The solution MUST provide a mechanism to allow servers to
>             simultaneously support clients using different revisions of
>             modules.  A client's choice of particular revision of one or
>             more modules may restrict the particular revision of other
>             modules that may be used in the same request or session.
>
> Today, the version number is effectively an (implicit) part of the
> module name (plus the revision date for backwards compatible changes).
> Hence, my understanding is that today's model does satisfy 3.2 as
> well.
>
>

This is not what we have at all. RFC 7950 says a server can only implement
one revision of a module.



> If we want to increase 'agility' in an attempt to make it easier to
> deliver early designs and to fix them on the go, the costs will go up
> somewhere. The extreme cases are:
>
> 1) The server can make changes to YANG modules in arbitrary ways and
>    the clients have to adapt, i.e., clients have to pay the bill.
>
> 2) The server has to provide strict backwards compatibility in order
>    to not break clients, i.e., servers have to pay the bill.
>
>
This is not correct. Implementing multiple incompatible revisions of a
module
(e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
server developer.


The question is whether there is a solution somewhere in the middle
> that balances the costs and eases the process of adapting clients to
> servers and vice versa. It might very well be that there is no sweet
> point.
>
> Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> important requirements.
>


I do not agree with the premise that non-compatible data model updates are
required.
3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
a new(much more complicated) version of YANG



>
> /js
>
>
Andy



> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Sat, Oct 27, 2018 at 1:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierm=
an wrote:

> On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

> 

> > On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:

> > >

> > > IMO requirements 3.1 and 3.2 are the most=C2=A0 important an=
d have the most

> > > impact

> > > on the solution space. I do not agree with either of these r=
equirements.

> > >

> > > Implementing multiple non-compatible revisions of a module o=
n a server

> > > sounds hard,

> > > not to mention that it breaks RFC 7950 rules. The current pr=
otocols do

> > not

> > > support the

> > > ability to specify different versions of the same QName. Thi=
s change

> > makes

> > > YANG validation

> > > much to difficult to specify and implement (as that has to b=
e rewritten

> > as

> > > well).

> > >

> > > It is one thing to deploy rapidly changing, buggy YANG modul=
es in order

> > to

> > > gain experience quickly.=C2=A0 It is quite another to compli=
cate YANG and the

> > > protocols

> > > to preserve these interim mistakes, and bake into the standa=
rds the

> > notion

> > > that this

> > > is good engineering.

> > >

> >

> > So how do you think this conflict between more agility and client=


> > stability should be handled? It seems you can't easily have b=
oth at

> > the same time. Are you saying that backwards compatibility to sup=
port

> > existing clients is not important?

> >

> >

> It depends on the data model and how broken it is in the replaced vers=
ion.

> YANG validation is slow and complicated enough without pretending ther=
e

> are 8 or 10 separate schema trees within a datastore. It might be impo=
ssible

> for all constraints to be true in all schema trees at once.=C2=A0 It i=
s a burden

> on operators

> and client developers to understand and properly manage multiple

> incompatible revisions

> of the same module

> 

> yang-library is a good example of a clean break.

> The /yang-library tree completely replaces the /modules-state tree.
> A server can easily support both subtrees.

> No new YANG or protocol features are needed at all.

> This was not a bugfix, just the normal instability in the IETF.

> 

> Even with this clean break, there could be external modules that have<=
br>
> leafref

> or must/when that point at the /modules-state subtree.=C2=A0 They have=
 to be

> rewritten

> to use /yang-library instead. But this can happen as needed since the =
old

> tree is unchanged.

> 

> For truly broken changes (e.g. change a node from a container to a lis=
t;

> change a leaf from type boolean to an enumerated type w/ 6 enums;

> remove or rename lots of existing nodes) the cross-references from ext=
ernal

> modules can easily be incorrect if used with the new version.

> 

> The NETMOD WG chose to add a new /yang-library tree instead of

> mangling the existing nodes. One design choice makes req. 3.1 easy and=
 3.2

> not needed.

>



=C2=A0 =C2=A0 =C2=A0 =C2=A03.1=C2=A0 The solution MUST provide a mechanism =
to allow servers to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 support existing clients in a bac=
kwards-compatible way.



I believe 3.1 is exactly what we have today. If it is necessary to

make incompatible changes, you create new definitions. This allows

servers to support existing clients in a backwards-compatible way (as

long as the old and new definitions are not conflicting.)
<=
div>

This is what we have today only if module=
s are updated in legal ways.
The 3.1 requirement says this backwa=
rd compatibility is maintained even
if the module is updated in v=
iolation of the module update rules.

How would 3.1=
 be met if the WG decided to just add a new 'datastore' key leaf=C2=
=A0
to the /modules-state/module list?

I=
MO the current "deprecate and start over" is actually the easiest=
 and most robust
solution path, and it requires no changes to YAN=
G or the protocols.






=C2=A0 =C2=A0 =C2=A0 =C2=A03.2=C2=A0 The solution MUST provide a mechanism =
to allow servers to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 simultaneously support clients us=
ing different revisions of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 modules.=C2=A0 A client's cho=
ice of particular revision of one or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more modules may restrict the par=
ticular revision of other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 modules that may be used in the s=
ame request or session.



Today, the version number is effectively an (implicit) part of the

module name (plus the revision date for backwards compatible changes).

Hence, my understanding is that today's model does satisfy 3.2 as

well.




This is not what we hav=
e at all. RFC 7950 says a server can only implement
one revision =
of a module.

=C2=A0

If we want to increase 'agility' in an attempt to make it easier to=


deliver early designs and to fix them on the go, the costs will go up

somewhere. The extreme cases are:



1) The server can make changes to YANG modules in arbitrary ways and

=C2=A0 =C2=A0the clients have to adapt, i.e., clients have to pay the bill.=




2) The server has to provide strict backwards compatibility in order

=C2=A0 =C2=A0to not break clients, i.e., servers have to pay the bill.



This is not correct. Implementing mult=
iple incompatible revisions of a module
(e.g, "module" =
list keyed 2 different ways) is a huge bill to pay for the server developer=
.



The question is whether there is a solution somewhere in the middle

that balances the costs and eases the process of adapting clients to

servers and vice versa. It might very well be that there is no sweet

point.



Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and

important requirements.


=
I do not agree with the premise that non-compatible data model updates are =
required.
3.1 can be achieved without such changes. 3.2 violates =
RFC 7950, requiring
a new(much more complicated) version of YANG<=
/div>

=C2=A0



/js



Andy

=C2=A0

-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>





--0000000000004c9ec705793620fd--


From nobody Sat Oct 27 14:14:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2701277D2 for ; Sat, 27 Oct 2018 14:14:01 -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 w9nI60ERSH4c for ; Sat, 27 Oct 2018 14:13:59 -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 E98AF130DE8 for ; Sat, 27 Oct 2018 14:13:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7F81BE50; Sat, 27 Oct 2018 23:13:57 +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 wBbxwPX_yTlt; Sat, 27 Oct 2018 23:13:54 +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; Sat, 27 Oct 2018 23:13:57 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 425F12003C; Sat, 27 Oct 2018 23:13:57 +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 lqdHNKPJvsS3; Sat, 27 Oct 2018 23:13:56 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A46EE2003B; Sat, 27 Oct 2018 23:13:56 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 27 Oct 2018 23:13:56 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 024123002AC391; Sat, 27 Oct 2018 23:13:55 +0200 (CEST)
Date: Sat, 27 Oct 2018 23:13:55 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: "netmod@ietf.org" 
Message-ID: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "netmod@ietf.org" 
References: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>  <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Oct 2018 21:14:02 -0000

On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> 
> This is what we have today only if modules are updated in legal ways.
> The 3.1 requirement says this backward compatibility is maintained even
> if the module is updated in violation of the module update rules.
>

It is stating a requirement. How solutions meet the requirement is for
the solutions to figure out.

> How would 3.1 be met if the WG decided to just add a new 'datastore'
> key leaf to the /modules-state/module list?

Depends on the solution I guess.
 
> IMO the current "deprecate and start over" is actually the easiest
> and most robust solution path, and it requires no changes to YANG or
> the protocols.

Yep. But there are people who think that other solutions can do
better. The challenge is to find out whether they actually do better
or for whom they do better (and if someone has to pay a price for it).
For having this discussions, it is good to write down requirements.

> >        3.2  The solution MUST provide a mechanism to allow servers to
> >             simultaneously support clients using different revisions of
> >             modules.  A client's choice of particular revision of one or
> >             more modules may restrict the particular revision of other
> >             modules that may be used in the same request or session.
> >
> > Today, the version number is effectively an (implicit) part of the
> > module name (plus the revision date for backwards compatible changes).
> > Hence, my understanding is that today's model does satisfy 3.2 as
> > well.
> 
> This is not what we have at all. RFC 7950 says a server can only implement
> one revision of a module.
>

A new version today essentially means a new module name and I do not
see a conflict with what I wrote.

> > If we want to increase 'agility' in an attempt to make it easier to
> > deliver early designs and to fix them on the go, the costs will go up
> > somewhere. The extreme cases are:
> >
> > 1) The server can make changes to YANG modules in arbitrary ways and
> >    the clients have to adapt, i.e., clients have to pay the bill.
> >
> > 2) The server has to provide strict backwards compatibility in order
> >    to not break clients, i.e., servers have to pay the bill.
> >
> >
> This is not correct. Implementing multiple incompatible revisions of a
> module
> (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> server developer.

Depends on the details and the developer will decide based on the
impact on the clients and whether a transition period is possible. You
seem to read that the requirement says one has to implement backwards
compatibility. This is not what the text says. The text says it must
be possible.

> > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > important requirements.
> 
> I do not agree with the premise that non-compatible data model updates are
> required.
> 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> a new(much more complicated) version of YANG

I think you misread the requirements text.

/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 Mon Oct 29 04:01:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E45130E8D for ; Mon, 29 Oct 2018 04:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 aCXeogwQd-2v for ; Mon, 29 Oct 2018 04:01:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7D86B130E89 for ; Mon, 29 Oct 2018 04:01:18 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 68F29F2AA9F8F; Mon, 29 Oct 2018 11:01:12 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml705-cah.china.huawei.com ([10.201.108.46]) with mapi id 14.03.0415.000;  Mon, 29 Oct 2018 11:01:10 +0000
From: Italo Busi 
To: Lou Berger , NetMod WG 
Thread-Topic: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
Thread-Index: AQHUZvWup+vMAgs//0q5oxWlqREjoKU2HtEQ
Date: Mon, 29 Oct 2018 11:01:09 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B1590CECD@lhreml504-mbs>
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net> <41a696e4-9658-95b1-5f37-b736d9af02ca@labn.net>
In-Reply-To: <41a696e4-9658-95b1-5f37-b736d9af02ca@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.203.246.81]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2018 11:01:20 -0000

WWVzL3N1cHBvcnQNCg0KV2UgaGF2ZSBhcHByZWNpYXRlZCB0aGlzIHRvb2wgYW5kIHVzZWQgaXQg
dG8gZm9sZCBKU09OIGNvZGUgZXhhbXBsZXMgaW4gb3VyIGRyYWZ0Og0KDQpodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC10cmFuc3BvcnQtbmJpLWFwcC1zdGF0ZW1l
bnQtMDMNCg0KSXRhbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBC
ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy
IDE4LCAyMDE4IDM6MTMgUE0NClRvOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NCkNjOiBO
ZXRNb2QgV0cgQ2hhaXJzIDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtu
ZXRtb2RdIFdHIGFkb3B0aW9uIHBvbGwgZHJhZnQta3dhdHNlbi1uZXRtb2QtYXJ0d29yay1mb2xk
aW5nLTA4DQoNClBvbGwgZW5kcyBOb3YgMSAtIHNvcnJ5IGFib3V0IHRoYXQuLi4NCg0KDQpPbiAx
MC8xOC8yMDE4IDk6MDMgQU0sIExvdSBCZXJnZXIgd3JvdGU6DQo+IEFsbCwNCj4NCj4gVGhpcyBp
cyBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQo+IGRyYWZ0LWt3YXRzZW4tbmV0
bW9kLWFydHdvcmstZm9sZGluZy0wOCBhIHdvcmtpbmcgZ3JvdXANCj4gZG9jdW1lbnQuIFBsZWFz
ZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgInllcy9zdXBwb3J0IiBvcg0KPiAi
bm8vZG8gbm90IHN1cHBvcnQiLiAgSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIg
cmVzZXJ2YXRpb25zDQo+IHdpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBm
ZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cw0KPiB5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNz
ZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBkb2N1bWVudC4NCj4NCj4gVGhlIHBvbGwgZW5k
cyBPY3QgMS4NCj4NCj4gVGhhbmtzLA0KPg0KPiBMb3UgKGFuZCBjby1jaGFpcnMpDQo+DQo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBt
YWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQoNCg0K


From nobody Mon Oct 29 13:35:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59B131074 for ; Mon, 29 Oct 2018 13:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level: 
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b921RSkj3bhq for ; Mon, 29 Oct 2018 13:35:03 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32233131001 for ; Mon, 29 Oct 2018 13:35:03 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9TKXqa4020730 for ; Mon, 29 Oct 2018 13:35:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=YFxcDWhmsKX+esPBsfk0vSy0utD1EVtyUYBcV16SRm4=; b=mye9mDpWytDew8OJQv9ZJzR+9pV+JdestpxECpAQLq08PSkmmGXOHvWepouBIsA/yO09 2bbJ7+6ydJrbx59FWzUT9dcYtHlROYGrlS5rXY8JCCIYInuD6RfLxk3ci2PFvrBQB9Df lwkbBcgT1dhgZl4buoJUtWiC2zEVT1vH6EL1M3Nqdlut+AQsBxpuXJMoPPNM/Izt1ktk iXUPkURrkvdDqezHggI/s4B3POXqUxwJUgjGvCuyaBbX3TDz2bIARzhtoMLja84EhWfO KF3/BR2z95Xgh5ExqzlIq6IfsMaGBF3y5fjKoy/q5BMdtIxqk2w8AXvMZRY/ysMP0w9i FA== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0051.outbound.protection.outlook.com [216.32.180.51]) by mx0b-00273201.pphosted.com with ESMTP id 2ne4uf0rac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 29 Oct 2018 13:35:02 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5723.namprd05.prod.outlook.com (20.176.123.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.9; Mon, 29 Oct 2018 20:34:57 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1294.015; Mon, 29 Oct 2018 20:34:57 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: for a future rfc6991bis
Thread-Index: AQHUb8bb5pZToCjlLEK5aT+9YAPiFw==
Date: Mon, 29 Oct 2018 20:34:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5723; 6:dUdI5xvljTX0bbs5DBhK4gdj49FjMf9MSvH0Bl0x9JcSdQbmMUWOdPrk9ilDhAgib4QoJFPemKcIklHJmWlPNTHvXhVVpGkumqfUZLmmqPU92j0mw/x4P6nltZ0I8toIktAkPCXOd5t4HAePMWaR84bhOWF6bc8tC34uiSPoctJ9KVmZsjV4cBW+UMQphHwwtFvCowa4LSPE9Cg1AdFZ8ajCAkAfYwfgse/XKIeptjt/NWtX46BKs1uyA5tGJMfKdTm0DgF/RW+WG58wmOgqnihflu7nBBBNlLW9oRuJKnUAw3OJE4e+EuINY1YmAdKY6GY6Vjn8fzvGEAs73om4/3DrU3pc7gfpg63Q5lxG2eJMU1HURhAV7qluaypzw3KpxPmp1c/ab/eO2rK4B/QSLXmdRYAZnnh2CbpSxfgHGMiF6E4jqamRlORR5/pylNJSEZ5qNEB7XTe9mxw+SbKQFg==; 5:gdGJd9TJpBJR8x/IMx/unJM62iurnh8GhzYny5x+rhI2YMiOfpgQKkl/AVB1UoJ7J0hNTpeC+U23oJcmmi0kVXBdm+ADrn53fZmDyfp+OrEychbjkJ48RnK+Uwh6EKEk3AJX1O1HVPaZ4GW1LtCgsfop6HZhBpWyH/m8BugsuZ4=; 7:5pl9zBi9wHQWKxdHqyT+5CjqC0Zi9AGLQEh0MDttHBT7FDeYgwLX8KJqj4K2KcaybKMgLbmpU7E1z6T7GLm4I9sbKtxopcmJoThNvmPSl1PgJEEf7MGPdobGLC/5PvRxY0rn0+/S+8YZs3UvaGWo1w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 450fb73d-d279-44a2-7ad9-08d63dddfd90
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5723; 
x-ms-traffictypediagnostic: DM6PR05MB5723:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5723; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5723; 
x-forefront-prvs: 084080FC15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(346002)(366004)(376002)(189003)(199004)(86362001)(6116002)(2900100001)(71190400001)(83716004)(71200400001)(3846002)(97736004)(82746002)(105586002)(36756003)(33656002)(2501003)(106356001)(5250100002)(2351001)(478600001)(14454004)(966005)(25786009)(53936002)(99286004)(6436002)(26005)(5660300001)(305945005)(7736002)(316002)(6306002)(6512007)(66066001)(256004)(14444005)(102836004)(186003)(5640700003)(2906002)(2616005)(8936002)(476003)(8676002)(6506007)(486006)(81156014)(1730700003)(58126008)(6486002)(6916009)(81166006)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5723; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: emo0J4y/Mu9+5XSjbs32PBkCoDj2L1RAdEjUWgXOvu2fmwGW3KO0q34QehA44GiRnYVByJaktlufINIm635mQWn0Ej1vaU+grnoc0L4ba7iVkIiAYN2nFpovJdXTwlKPgTecDEeBwnO866TNf1keLI3Ywjt9LSECrN30U6VMnHUXcOnMEh/8DVOD/ix8IQGTJ1fH5yFDRb+xnsG2VuAPcXSlAIBbbP4TF59mZti6PyikpqeXI16/B7kLewLHE2zLEYcctflZ7u+aJbUDMmrNQDreaZ2JwnD1sfF+7fIYwP2G3/vtcsCynviDN+u8FQ7L39BnOvWS+F0SmKtCWjVLjxykcnG0ySMU8FqFO3Q/Wm8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 450fb73d-d279-44a2-7ad9-08d63dddfd90
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2018 20:34:57.0094 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5723
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-29_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=1 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810290185
Archived-At: 
Subject: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2018 20:35:06 -0000

TkVUTU9EIFdHLA0KDQpBIGNvbnZlcnNhdGlvbiBpbiBORVRDT05GIFdHIHJlZ2FyZGluZyB0aGUg
eWFuZy1wdXNoIG5vdGVkIHRoYXQgaXQgbWlnaHQgYmUgDQp0aW1lIHRvIHVwZGF0ZSBSRkMgNjk5
MSwgaW4gcGFydGljdWxhciB0byBpbnRyb2R1Y2UgYSB0eXBlIGZvciB0aW1lLWR1cmF0aW9uLg0K
DQogIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi9LYVVKbG9J
U2hrTE5JWFR1SFpOd0ItU1lCblENCg0KSW4gYWRkaXRpb24sIGl0IG1pZ2h0IGJlIGdvb2QgdG8g
aW50cm9kdWNlIFtpbmV0P10gdHlwZXMgZm9yIFJGQyA1MzIyIA0KKEludGVybmV0IE1lc3NhZ2Ug
Rm9ybWF0KSBpbmNsdWRpbmcgcGVyaGFwczoNCg0KICAtIGVtYWlsLWFkZHJlc3MgICAgICAgIChh
ZGRyLXNwZWMsIHBlciBTZWN0aW9uIDMuNC4xKQ0KICAtIG5hbWVkLWVtYWlsLWFkZHJlc3MgIChu
YW1lLWFkZHIsIHBlciBTZWN0aW9uIDMuNCkNCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K
DQo=


From nobody Mon Oct 29 16:01:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43B4131028 for ; Mon, 29 Oct 2018 16:01:44 -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 QbNNSO6KonLI for ; Mon, 29 Oct 2018 16:01:42 -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 43B7F131021 for ; Mon, 29 Oct 2018 16:01:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 77764E19; Tue, 30 Oct 2018 00:01:40 +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 0p5T85y1kTzB; Tue, 30 Oct 2018 00:01:36 +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; Tue, 30 Oct 2018 00:01:40 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61D772003C; Tue, 30 Oct 2018 00:01:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7WWg_JSj33eD; Tue, 30 Oct 2018 00:01:40 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2221C2003B; Tue, 30 Oct 2018 00:01:40 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 30 Oct 2018 00:01:39 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 6CB983002B1FD9; Tue, 30 Oct 2018 00:01:38 +0100 (CET)
Date: Tue, 30 Oct 2018 00:01:38 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: "netmod@ietf.org" 
Message-ID: <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2018 23:01:45 -0000

On Mon, Oct 29, 2018 at 08:34:56PM +0000, Kent Watsen wrote:
> 
> In addition, it might be good to introduce [inet?] types for RFC 5322 
> (Internet Message Format) including perhaps:
> 
>   - email-address        (addr-spec, per Section 3.4.1)
>   - named-email-address  (name-addr, per Section 3.4)
>

Where are these used? Or have these already been used somewhere?

/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 Mon Oct 29 17:05:23 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9731E13102A for ; Mon, 29 Oct 2018 17:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhE_b-IxvUUL for ; Mon, 29 Oct 2018 17:05:19 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 5F112131001 for ; Mon, 29 Oct 2018 17:05:19 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9U05IMi030754; Mon, 29 Oct 2018 17:05:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=hvqzwyhASUahTlAL9pDBrTpuo3P50zQTwK3BfPd0kOM=; b=HKl6XyR0vc+/mwO6J0wG0bVP8z0GdnXxismoUrVotoZA2SjdhC4hDqeTpe7om486EvPQ 1j6rBHQ/Apt73hX6whum5GP8e8V53lk7quLzkpZIQSYhuzCbemuxrEuYERiQ0ZUsGK/s vyyGhKCg4QaBugq37Qm1plpkjcDWx593V+zmgnZsWLWu1pCorSGNTYCAgVpmiLEOeoGH C+Nbn+HFQyc1TvKwJxLlqpT2yZ9wsCqyXqiRsPqZpBPiMpHGsNM1snnCKxj18KnilGuu QGlMxQGlhzQm1pGvSZ2tQ/6njWvlxlc2avzsceXafVPE3hhiHwt403GUTm6d9aeqHhzS 7A== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0175.outbound.protection.outlook.com [216.32.181.175]) by mx0a-00273201.pphosted.com with ESMTP id 2ne9sbg7bt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 29 Oct 2018 17:05:18 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5081.namprd05.prod.outlook.com (20.177.223.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Tue, 30 Oct 2018 00:05:17 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1294.015; Tue, 30 Oct 2018 00:05:17 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUb8bb5pZToCjlLEK5aT+9YAPiF6U21yQA///O84A=
Date: Tue, 30 Oct 2018 00:05:17 +0000
Message-ID: <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net>
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB5081; 6:8WpXNoL5OW10dfP1NcmVOlbBLvQlFCunuRZUwXRmlyDRgEklckTuPFCG8NvbQA1UhZH+2jX1XFQ/xg6dINx/v+DaKuqa4C1vkKrGc1/QDmsMu1Nmq9LL1dwbbnv8EctRl+cVdxLh7+lU4Y/SSYfBnTDgA8YapaZ5ZMWRqDJw8T8ktdSsuVaOlBCMDHfHhCXL/f+qMWowHy5LztUy46OCX3mE5maxJ8Z6wb0DV8fTsyHAVHDPKRLRKvpb7NFO8+6RIMhfdjzHDJM5iFBEyB/6h3FSdIafDJu8aPIX4GQtv+d5mRtkABPFdU8r2YhAvLQoVnIGxckAaXC9Ht3ApsmuRqhDmu0OoUOv2lMnDAPgXp/uOc8/h8fMoB+Z/gQ1ea7+M9cDimnbC36lMHABYDJsZZKlp0eEcf3GSg3pa3zHFCSe1yBw3Ek9UO6Q52OUhSPqtn9+ey7dva0HlMflZBHUug==; 5:ifBcI6HMad8dp20SSqPu7164Zwgb3BuY7YF7cL+E3HLPyiDlRuBnfpg/3XpFH5RM3Bt8Sto4A2nUr/TmiNt4q5vQpOsSnVlol3/I1JybqT2M6pesf5qdrS4hTqJLd5BSN7yMIXtO4/ncG0fN4pKM4U1znaAjeAC+GDp0dsjEwJs=; 7:LOZPn9lJflN4NlUytj5uN19mARtMyxYH2od2CMCdNBwRJKIT1g4cUZJjSH0SpMvGFaA+XyCE+otFg9lBUAjIP5SjMs/UTlfD1xfoLdslZGDc8O6i8pLcbk1lPUfjSyVW6qE/Z6dTiig23QQ8oAirPw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: da130f91-050e-4904-c35a-08d63dfb5fbc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5081; 
x-ms-traffictypediagnostic: DM6PR05MB5081:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5081; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5081; 
x-forefront-prvs: 08417837C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(136003)(366004)(199004)(189003)(66066001)(106356001)(256004)(97736004)(81166006)(33656002)(486006)(11346002)(229853002)(8676002)(446003)(71190400001)(5660300001)(105586002)(8936002)(82746002)(58126008)(83716004)(71200400001)(6916009)(6486002)(81156014)(2616005)(476003)(6246003)(14454004)(86362001)(4326008)(36756003)(316002)(186003)(76176011)(6506007)(6436002)(102836004)(26005)(2906002)(6116002)(2900100001)(478600001)(99286004)(305945005)(68736007)(3846002)(5250100002)(6512007)(7736002)(25786009)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5081; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 1WyjsmSaxtTxncgxLHsU/RuzIGf0ds6itpNrqikZAZL/wS7hWzYcg8i1Rtrxgxv0zLyGbsq9V/TEW5IhxRYIUg/U2gHFvkJG4eRK9lU5rYg/IxjDSegIBWEyI+ep71PWy5gqp/ClN5mi9VBmNHzg33knfTm87cWU12qsbydmllvMIj+AVC1ESkB8CqtrGROFBegZedALsBNnieAogIsK6jV1IVylwBpo+X8LnCN94+Y90sduYxV1DHKGs/KsxMWDRWDMtclNDkbnpP6RvPWH0jWFrIv2HltcOIAdA+/W/C4mfx8hUHHhwJ8rFRK3luE62AdtC4vX49heI6sjelhawTlfzVegtQoRD181BEdcLCs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <62DDADF2D0D0AE4785D2B492461675BA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: da130f91-050e-4904-c35a-08d63dfb5fbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 00:05:17.1555 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5081
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-29_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=914 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810300000
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2018 00:05:22 -0000

DQoNCj4+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9d
IHR5cGVzIGZvciBSRkMgNTMyMiANCj4+IChJbnRlcm5ldCBNZXNzYWdlIEZvcm1hdCkgaW5jbHVk
aW5nIHBlcmhhcHM6DQo+PiANCj4+ICAgLSBlbWFpbC1hZGRyZXNzICAgICAgICAoYWRkci1zcGVj
LCBwZXIgU2VjdGlvbiAzLjQuMSkNCj4+ICAgLSBuYW1lZC1lbWFpbC1hZGRyZXNzICAobmFtZS1h
ZGRyLCBwZXIgU2VjdGlvbiAzLjQpDQo+Pg0KPg0KPiBXaGVyZSBhcmUgdGhlc2UgdXNlZD8gT3Ig
aGF2ZSB0aGVzZSBhbHJlYWR5IGJlZW4gdXNlZCBzb21ld2hlcmU/DQoNCkknbSB1bmF3YXJlIG9m
IHRoZXNlIGV2ZXIgaGF2aW5nIGJlZW4gdXNlZCBiZWZvcmUuICBJIGFtIHdvcmtpbmcgb24gYSBw
cml2YXRlIG1vZHVsZSBmb3Igd2hpY2ggSSB3YW50IHRvIGNvbmZpZ3VyZSBhbiBlbWFpbCBhZGRy
ZXNzLiAgQWZ0ZXIgc29tZSBzZWFyY2hpbmcsIEkgY29uY2x1ZGVkIHRoYXQgbm8gc3VjaCB0eXBl
cyBoYXZlIGJlZW4gZGVmaW5lZCwgYW5kIHRodXMgdGhvdWdodCB0aGF0IHRoZXkgbWlnaHQgYmUg
Z29vZCBjYW5kaWRhdGVzIGZvciBhZGRpdGlvbi4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoN
Cg==


From nobody Tue Oct 30 03:14:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455812F1AB for ; Tue, 30 Oct 2018 03:14:55 -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 HUYLp96bdCtk for ; Tue, 30 Oct 2018 03:14:51 -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 6FFB3128DFD for ; Tue, 30 Oct 2018 03:14:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 117FEE71; Tue, 30 Oct 2018 11:14:50 +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 8cD_5T2sdphB; Tue, 30 Oct 2018 11:14:46 +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; Tue, 30 Oct 2018 11:14:50 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF2662003C; Tue, 30 Oct 2018 11:14:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8s1BpZhjC3zX; Tue, 30 Oct 2018 11:14:49 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 9E2B82003B; Tue, 30 Oct 2018 11:14:49 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 30 Oct 2018 11:14:49 +0100
Received: by anna.localdomain (Postfix, from userid 501) id EFEF43002B3C05; Tue, 30 Oct 2018 11:14:48 +0100 (CET)
Date: Tue, 30 Oct 2018 11:14:48 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
CC: "netmod@ietf.org" 
Message-ID: <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2018 10:14:55 -0000

On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> 
> 
> >> In addition, it might be good to introduce [inet?] types for RFC 5322 
> >> (Internet Message Format) including perhaps:
> >> 
> >>   - email-address        (addr-spec, per Section 3.4.1)
> >>   - named-email-address  (name-addr, per Section 3.4)
> >>
> >
> > Where are these used? Or have these already been used somewhere?
> 
> I'm unaware of these ever having been used before.  I am working on a private module for which I want to configure an email address.  After some searching, I concluded that no such types have been defined, and thus thought that they might be good candidates for addition.
>

It would be good to have strong use cases. I fear that defining this
type won't be easy given that we also have internationalized email
addresses (RFC 6530 provides an overview) and we might have to create
a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".

/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 30 13:02:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD3130DE6 for ; Tue, 30 Oct 2018 13:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 1X6IGt0L8AsQ for ; Tue, 30 Oct 2018 13:02:52 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::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 D4B4B12D4F0 for ; Tue, 30 Oct 2018 13:02:52 -0700 (PDT)
Received: from [IPv6:2607:fb90:f35:bf71:5596:3038:5b78:7735] ([IPv6:2607:fb90:f35:bf71:5596:3038:5b78:7735]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9UK2nB2010260; Tue, 30 Oct 2018 20:02:51 GMT (envelope-from joelja@bogus.com)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Joel Jaeggli 
In-Reply-To: <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de>
Date: Tue, 30 Oct 2018 13:02:48 -0700
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2018 20:02:55 -0000

> On Oct 30, 2018, at 03:14, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>>=20
>>=20
>>>> In addition, it might be good to introduce [inet?] types for RFC =
5322=20
>>>> (Internet Message Format) including perhaps:
>>>>=20
>>>>  - email-address        (addr-spec, per Section 3.4.1)
>>>>  - named-email-address  (name-addr, per Section 3.4)
>>>>=20
>>>=20
>>> Where are these used? Or have these already been used somewhere?
>>=20
>> I'm unaware of these ever having been used before.  I am working on a =
private module for which I want to configure an email address.  After =
some searching, I concluded that no such types have been defined, and =
thus thought that they might be good candidates for addition.
>>=20
>=20
> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email
> addresses (RFC 6530 provides an overview) and we might have to create
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses=E2=80=9D=
.

It would be slightly unfortunate I think if we were to define something =
that was obsolete at the time of definition. So yeah the union of =
all-ascii addresses and non-ascii addresses is in fact SMTPUTF8. To my =
mind that would be what you would specify, and that probably requires =
discussion.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20


From nobody Wed Oct 31 05:26:21 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493A0130DC6 for ; Wed, 31 Oct 2018 05:26:19 -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, 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 5BQ7USYttJKT for ; Wed, 31 Oct 2018 05:26:16 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AD088130DC3 for ; Wed, 31 Oct 2018 05:26:16 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id E9B38182113A; Wed, 31 Oct 2018 13:32:47 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id DDE401820053; Wed, 31 Oct 2018 13:32:34 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , "netmod\@ietf.org" 
In-Reply-To: 
References: 
Mail-Followup-To: Kent Watsen , "netmod\@ietf.org" 
Date: Wed, 31 Oct 2018 13:26:01 +0100
Message-ID: <87y3aejo9y.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2018 12:26:19 -0000

Hi,

another update that was discussed recently is a clarification of the
XPath context for the xpath1.0 type.

Lada

Kent Watsen  writes:

> NETMOD WG,
>
> A conversation in NETCONF WG regarding the yang-push noted that it might be 
> time to update RFC 6991, in particular to introduce a type for time-duration.
>
>   https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-SYBnQ
>
> In addition, it might be good to introduce [inet?] types for RFC 5322 
> (Internet Message Format) including perhaps:
>
>   - email-address        (addr-spec, per Section 3.4.1)
>   - named-email-address  (name-addr, per Section 3.4)
>
>
> Kent // contributor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Oct 31 05:46:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88A7130E01 for ; Wed, 31 Oct 2018 05:46: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 qvR17_bU6fXo for ; Wed, 31 Oct 2018 05:46:49 -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 C680212D4E7 for ; Wed, 31 Oct 2018 05:46:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 35E79E2A for ; Wed, 31 Oct 2018 13:46:47 +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 QDLedUyZ1Oqa for ; Wed, 31 Oct 2018 13:46:46 +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 for ; Wed, 31 Oct 2018 13:46:47 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA3D92003C for ; Wed, 31 Oct 2018 13:46:46 +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 pyn8JLH4NU6A for ; Wed, 31 Oct 2018 13:46:46 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5980A2003B for ; Wed, 31 Oct 2018 13:46:46 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 31 Oct 2018 13:46:45 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3BCB13003505D8; Wed, 31 Oct 2018 13:46:43 +0100 (CET)
Date: Wed, 31 Oct 2018 13:46:43 +0100
From: Juergen Schoenwaelder 
To: "netmod@ietf.org" 
Message-ID: <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "netmod@ietf.org" 
References:  <87y3aejo9y.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bsmilrf7tlzfw6p7"
Content-Disposition: inline
In-Reply-To: <87y3aejo9y.fsf@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Oct 2018 12:46:52 -0000

--bsmilrf7tlzfw6p7
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline

Here is my list of possible additions. I might have lost some items on
a computer that meanwhile is not used anymore, I will have to dig a
bit to see what I can recover.

/js

On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> another update that was discussed recently is a clarification of the
> XPath context for the xpath1.0 type.
> 
> Lada
> 
> Kent Watsen  writes:
> 
> > NETMOD WG,
> >
> > A conversation in NETCONF WG regarding the yang-push noted that it might be 
> > time to update RFC 6991, in particular to introduce a type for time-duration.
> >
> >   https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-SYBnQ
> >
> > In addition, it might be good to introduce [inet?] types for RFC 5322 
> > (Internet Message Format) including perhaps:
> >
> >   - email-address        (addr-spec, per Section 3.4.1)
> >   - named-email-address  (name-addr, per Section 3.4)
> >
> >
> > Kent // contributor
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         

--bsmilrf7tlzfw6p7
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="YANG-TYPES-ADDITIONS.txt"

* simple time period types such as

  typedef minutes {
      type uint32;
      units "minutes"
      description
        "A period of time, measured in units of minutes."
  }

  typedef seconds {
      type uint32;
      units "seconds"
      description
        "A period of time, measured in units of seconds."
  }

  typedef centiseconds {
      type uint32;
      units "centiseconds"
      description
        "A period of time, measured in units of 0.01 seconds."
  }

  typedef milliseconds {
      type uint32;
      units "milliseconds"
      description
        "A period of time, measured in units of 10^-3 seconds."
  }

  typedef microseconds {
      type uint32;
      units "microseconds"
      description
        "A period of time, measured in units of 10^-6 seconds."
  }

  typedef nanoseconds {
      type uint32;
      units "nanoseconds"
      description
        "A period of time, measured in units of 10^-9 seconds."
  }

  // do we need (nano|micro|milli)seconds with 64 bits?

  // the equivalent to SMIv2 TimeInterval would then be centiseconds
  // or do we need an alias type for backwards naming consistency?

* date type (right now we only have date-and-time)

  // does a date type include a time zone? (likely no)

* time type (right now we only have date-and-time)

  // does a time type include a time zone? (likely yes)

* xpath1.0 clarification

  There was some discussion about xpath expressions in JSON and the
  idea to have an xpath context populated with module names such that
  module names can be used to qualify path expressions. This may need
  discussion and/or a new definition.

* email address types (Kent Watsen)

  In addition, it might be good to introduce [inet?] types for RFC 5322
  (Internet Message Format) including perhaps:

   - email-address        (addr-spec, per Section 3.4.1)
   - named-email-address  (name-addr, per Section 3.4)

  Note that there are also internationalized email addresses and hence
  this is not as simple has it may look at first sight.

--bsmilrf7tlzfw6p7--