From nobody Wed Nov 1 12:30:43 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5143B139A2F for ; Wed, 1 Nov 2017 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.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 rlBIpM2iMeuD for ; Wed, 1 Nov 2017 12:30:39 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222821389C1 for ; Wed, 1 Nov 2017 12:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WGe25EmZfu/d5wxDpIZhN5B1kSlYKHJTNEbKXSbqLcA=; b=VS0yauC5xivBIl03si3Z3ZZsD8lraomekw4V9Ba7kVB0hIfWSiq+oF04T0Y+M13OuBjjMChNNSGTOl3n9hTykWLqkgEzH4lwIdlyN2nt78IDq6qgfRmGU8nBiNUy1zfF6RJgpk+xWeWu/2PQebsR/9acUPXT6Z7D+JsUlsfH2ks= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0865.namprd02.prod.outlook.com (10.160.154.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Wed, 1 Nov 2017 19:30:37 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.20.0178.014; Wed, 1 Nov 2017 19:30:37 +0000 From: Xufeng Liu To: "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQ== Date: Wed, 1 Nov 2017 19:30:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWYzMzYxMzhiLWJmM2EtMTFlNy05YzJlLTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxmMzM2MTM4Yy1iZjNhLTExZTctOWMyZS0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjM0OTQiIHQ9IjEzMTU0MDM4MTU5NTAwNTcyNyIgaD0iRlg2QU5RUlpXSkdPY09vMDVoNThYbVQ2SUlrPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0865; 6:oZCqE2rPeOBpMAwmifKXd+cl1R9mRTm6ImiD3lDoVlbMo8mIc3BWnd6I9nJxk2xSuQNYFQOoQ3qBFBvcnhamUeNMwRIYgs9BRxadLm6OYRXzlgn6PFaDpzit6/0kgfatIVa0R2Px236U1FbFUKqWJ3L9nBuwqmUT+Y7SxGuFTh9Bmhn5kc1naqmXvxgEgf0PKIB6HuimgsKzcsl+8KrdMelYQukkcd1d4lE2bcryYuKWhOLSBF4/1xp0oJqpgM2W/XP51ZFHrKklODWhEmxNuQKBXj5PRnvUb4g6NBtzadNCRiDXIUHSY6DkZjH5FiZ6vvTUW22bz+G/IX9rp82J5enWzbPd2l3N4TCjU6LUwvg=; 5:0tKdJSBzY33cRzHZ2YdkcDjCn5LQg5L5EwaE801rd/xeJduTPXNJZ0zf13DOFyPh6dgsrswG5pZ1FBklnkYcGYuQf5e2fgErOeXPbZh0j3V5Y5ajiq0xHQ63JR1KqucTjS1965BPuXQ6mWFI308Twf06LH6snmpqREuEEAWgzj8=; 24:YcFCLGV6m/9DYj7DMuLPH2ydj3k9sX8Y8pZYPLRX9Ysv/Uhvu+fn73//pshRq+lgiBNYqBGC/5+Si5CG5MUBaByTx+Ax7Hqymhs+If9cHlY=; 7:2k04ngiy7hpUITVzlVb3qSgsXTB8XYn+pwhInxntGkIkY4FepSBoHVUOOck178SMqwyCll5YZsNYH8HBjYnPTmPE54tRcfiWNNBkfZtf6QWYDOEpsKgCisChhksYCxsf/fjmv73mezvlKCVLOlj0szFC87QZpP6v1rZTpww9IHiyVYuDD4LSVHVCW3xMXiiSi5vppLu4hmEQpl/Oyz56RqbZHn65w2WviSxmvasLwy5r826j6JsE1xWVwvjnC9oI x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5d59d13f-0c65-4361-846a-08d5215f0793 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:BN3PR0201MB0865; x-ms-traffictypediagnostic: BN3PR0201MB0865: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0865; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0865; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(189002)(66066001)(55016002)(9686003)(53936002)(72206003)(413944005)(102836003)(6116002)(50986999)(54356999)(478600001)(3846002)(106356001)(105586002)(6506006)(77096006)(2906002)(189998001)(5640700003)(101416001)(3660700001)(99286004)(6916009)(6436002)(3280700002)(5660300001)(7696004)(25786009)(33656002)(551934003)(14454004)(8936002)(2351001)(74316002)(68736007)(305945005)(2900100001)(316002)(97736004)(2501003)(80792005)(86362001)(81166006)(8676002)(81156014)(1730700003)(7736002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0865; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d59d13f-0c65-4361-846a-08d5215f0793 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 19:30:37.3323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0865 Archived-At: Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:30:41 -0000 RGVhciBXRywNCg0KVGhlIFlhbmctcHVzaCBEZXppZ24gVGVhbSBoYXMgYmVlbiB3b3JraW5nIG9u IHRoZSBZYW5nIHB1c2ggZW5oYW5jZW1lbnQuIFdlIGhhdmUgcG9zdGVkIGEgZHJhZnQgb24gdGhl IHByb2JsZW0gc3RhdGVtZW50IHRvIGV4dGVuZCBZYW5nIHB1c2ggdG8gYSBtb3JlIGdlbmVyYWxp emVkIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIGZyYW1ld29yay4NCg0KVGhlIGZvbGxvd2lu ZyBpcyB0aGUgc3VtbWFyeSBvZiB0aGlzIHRvcGljLiBBbnkgY29tbWVudHMsIHRob3VnaHRzLCBh bmQgc3VnZ2VzdGlvbnMgYXJlIGFwcHJlY2lhdGVkLg0KDQpUaGFua3MsDQotIFh1ZmVuZw0KDQo9 PT09PT09PT09PT09PT09DQpZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250 cm9sIEF1dG9tYXRpb24gDQpkcmFmdC1icnlza2luLW5ldGNvbmYtYXV0b21hdGlvbi1mcmFtZXdv cmstMDANCg0KRXZvbHV0aW9uIG9mIFlBTkcgQmFzZWQgTmV0d29yayBBdXRvbWF0aW9uDQoqICJD dXN0b20gU3Vic2NyaXB0aW9uIHRvIEV2ZW50IE5vdGlmaWNhdGlvbnMiIG1vZGVsIDoNCgktIGFs bG93cyBmb3IgYSBjbGllbnQgdG8gc3Vic2NyaWJlIHRvIHVuc29saWNpdGVkIGV2ZW50IG5vdGlm aWNhdGlvbnMgIGRlZmluZWQgYnkgc3VwcG9ydGVkIFlBTkcgbW9kZWxzOw0KDQoqICJTdWJzY3Jp YmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMiIG1vZGVsOg0KCS0gYWxsb3dzIGZv ciBhIGNsaWVudCB0byBkZWZpbmUgc3Vic2NyaWJhYmxlIGV2ZW50cyBhbmQgY29udGVudHMgb2Yg ZXZlbnQgbm90aWZpY2F0aW9ucyBhcyB0YXJnZXQtdHJpZ2dlci1ub3RpZnkgdHJpcGxldHMNCg0K KiAiU21hcnQgZmlsdGVycyBmb3IgUHVzaCBVcGRhdGVzIiBtb2RlbDoNCgktIGFsbG93cyBmb3Ig YSBjbGllbnQgdG8gZmlsdGVyIGV2ZW50IHRyaWdnZXJzIGFuZCBub3RpZmljYXRpb25zIG9uIHB1 c2ggb2JqZWN0IHZhbHVlcyBhbmQgdGhlaXIgY2hhbmdlIGhpc3RvcnksIGZvY3VzZXMgb24gIm91 dGxpZXJzIg0KDQpPYmplY3RpdmVzIG9mICBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0 d29yayBDb250cm9sIEF1dG9tYXRpb24gIA0KMSkgVG8gZ2VuZXJhbGl6ZSB0YXJnZXQtdHJpZ2dl ci1ub3RpZnkgY29uY2VwdCBpbnRvIGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gY29uY2VwdCwgd2hl cmU6DQoNCglldmVudCAtIGEgcGFydGljdWxhciBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgc3RhdGUg ZXhwbGljaXRseSBkZWZpbmVkIGJ5IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5 IHRoZSBuZXR3b3JrIG9yIGltcGxpY2l0bHkgZGVmaW5lZCBieSB0aGUgY2xpZW50LCB3aGljaCBp cyBjb25zdGFudGx5IG1vbml0b3JlZCBieSB0aGUgbmV0d29yazsNCg0KCWNvbmRpdGlvbiAtIGEg bG9naWNhbCBleHByZXNzaW9uIHRoYXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlciB0aGUg YXNzb2NpYXRlZCBldmVudCBpcyBkZXRlY3RlZDsNCg0KCWFjdGlvbiAtIGFuIG9wZXJhdGlvbiB0 byBiZSBjYXJyaWVkIG91dCBieSB0aGUgbmV0d29yayB3aGVuIHRoZSBhc3NvY2lhdGVkIGV2ZW50 IGlzIGRldGVjdGVkIGFuZCB0aGUgYXNzb2NpYXRlZCBjb25kaXRpb24gaXMgbWV0DQoNCjIpIFRv IHByb3ZpZGUgZm9yIGEgY2xpZW50IGEgY2FwYWJpbGl0eSB0byBjb25maWd1cmUgdGhlIGV2ZW50 LWNvbmRpdGlvbi1hY3Rpb24gdHJpcGxldHMgYXMgcG9saWN5IHJ1bGVzIGFoZWFkIG9mIHRpbWUg b3IvYW5kIGR1cmluZyBuZXR3b3JrIG9wZXJhdGlvbnMNCg0KR2VuZXJhbGl6ZWQgQWN0aW9uDQoq IFNlbmQgbm90aWZpY2F0aW9uDQoqIFBlcmZvcm0gaW1tZWRpYXRlIG5ldHdvcmsgcmVjb25maWd1 cmF0aW9uIChlLmcuIG1vZGlmeSBvbmUgb3IgbW9yZSBhdHRyaWJ1dGVzIG9mIG9uZSBvciBtb3Jl IENPTkZJRz1UUlVFIGRhdGEgc3RvcmUgbm9kZXMpOw0KKiBTY2hlZHVsZSBvbmUgdGltZSBvciBw ZXJpb2RpYyByZWNvbmZpZ3VyYXRpb24gaW4gdGhlIGZ1dHVyZTsNCiogQ2FsbCBSUEMgZGVmaW5l ZCBieSBvbmUgb2YgdGhlIFlBTkcgbW9kZWxzIHN1cHBvcnRlZCBieSB0aGUgbmV0d29yayAoIGUu Zy4gY2FsbCBuZXR3b3JrJ3MgcGF0aCBjb21wdXRlciB0byBldmFsdWF0ZSB3aGV0aGVyIGFuIGFs dGVybmF0aXZlL21vcmUgb3B0aW1hbCBwYXRoIGlzIGF2YWlsYWJsZSBmb3IgYSBnaXZlbiBjb25u ZWN0aW9uKQ0KKiBMaW5rL3VubGluayBkYXRhIHN0b3JlIGR5bmFtaWMgc3ViLXRyZWVzOw0KKiBF dGMuDQoNClJlbGF0aW9uc2hpcCB3aXRoIFBvbGljeSBGcmFtZXdvcmsNCiogVGhlIGZyYW1ld29y ayBzaG91bGQgd29yayBhdXRvbm9tb3VzbHkNCg0KKiBUaGUgZnJhbWV3b3JrIHNob3VsZCBmaXQg d2VsbCB3aXRoaW4gYSBoaWdoZXIgbGV2ZWwgcG9saWN5IGZyYW1ld29yaywgd2l0aCB0aGUgbGF0 dGVyIHBvc3NpYmx5IHByb3ZpZGluZyBhIGdyZWF0ZXIgbGV2ZWwgb2YgYXV0b21hdGlvbjoNCiAg LSBtdWx0aXBsZSBtaWNyby1jb25kaXRpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBzaW5n bGUgbWFjcm8tY29uZGl0aW9uIHZpYSBhIG51bWJlciBvZiBsb2dpY2FsIG9wZXJhdGlvbnM7DQog IC0gbXVsdGlwbGUgbWljcm8tYWN0aW9ucyBjb3VsZCBiZSBjb21iaW5lZCBpbnRvIGEgc2luZ2xl IHRyYW5zYWN0aW9uIHdpdGggYSBwb3NzaWJpbGl0eSBvZiBzcGVjaWZ5aW5nIHBvbGljaWVzIHdp dGggcmVzcGVjdCB0byBoYW5kbGluZyBlcnJvcnMvZXhjZXB0aW9ucyBvZiBlYWNoIG9mIHRoZSB0 cmFuc2FjdGlvbiBjb21wb25lbnRzDQoNCkZyYW1ld29yayBCZW5lZml0cw0KKiBsb3dlciBsYXRl bmN5LCBmYXN0ZXIgcmVzcG9uc2l2ZW5lc3Mgb2YgdGhlIG5ldHdvcmsgdG8gdmFyaW91cyBldmVu dHMvY29uZGl0aW9uczsNCiogYmV0dGVyIHNjYWxlIChlLmcuIHRoZSBjbGllbnQgbWF5IGNvbnRy b2wgbW9yZSBuZXR3b3JrcyBiZWNhdXNlIGl0IGRvZXMgbm90IGhhdmUgdG8gbW9uaXRvci9taWNy by1tYW5hZ2UgYW55IG9mIHRoZW0pOw0KKiBDUFUgYW5kIGJhbmR3aWR0aCBzYXZpbmdzIGR1ZSB0 byB0aGUgcmVkdWNlZCBhbW91bnQgb2YgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZSBuZXR3b3JrDQoqIFRoZSBjbGllbnQgY2FuIHRha2UgaXRzZWxmIG91dCBvZiB0aGUg bmV0d29yayBjb250cm9sIGxvb3AsICBjaGFuZ2UgaXRzIHJvbGUgZnJvbSBiZWluZyBuZXR3b3Jr J3MgIm1pY3JvLW1hbmFnZXIiIHRvIGJlaW5nIG5ldHdvcmsncyAicG9saWNlIG9mZmljZXIiLCB3 aG8gaW50ZXJmZXJlcyBpbnRvIG5ldHdvcmsgb3BlcmF0aW9ucyBvbmx5IGluIGV4Y2VwdGlvbmFs L3VucHJlZGljdGVkIHNpdHVhdGlvbnMNCg0KDQo= From nobody Wed Nov 1 20:31:06 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921E813FC88 for ; Wed, 1 Nov 2017 20:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdqztXdX3LIn for ; Wed, 1 Nov 2017 20:31:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C09013F843 for ; Wed, 1 Nov 2017 20:31:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRW36065; Thu, 02 Nov 2017 03:31:01 +0000 (GMT) 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.361.1; Thu, 2 Nov 2017 03:31:00 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 11:30:54 +0800 From: Tianran Zhou To: Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00Jg Date: Thu, 2 Nov 2017 03:30:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59FA9175.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 391c2aaf4a7339387475bd207c66fbec Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 03:31:05 -0000 Hi Xufeng, On the smart filters (also relates to https://tools.ietf.org/html/draft-cle= mm-netconf-push-smart-filters-ps-00), I think we need criteria to carefully= select "conditions". While there are many benefit, say save the bandwidth = and relief the collector, it will add computation burden to network devices= . Network devices are not good at this as servers. So maybe: 1. should not too complex to implement. 2. must help to mitigate the export volume. If so, for example, the average value should be out of scope, IMHO. Best, Tianran > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, November 02, 2017 3:31 AM > To: netconf@ietf.org > Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation > Problem Statement >=20 > Dear WG, >=20 > The Yang-push Dezign Team has been working on the Yang push enhancement. > We have posted a draft on the problem statement to extend Yang push to a > more generalized network control automation framework. >=20 > The following is the summary of this topic. Any comments, thoughts, and > suggestions are appreciated. >=20 > Thanks, > - Xufeng >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > YANG PUSH Based Generalized Network Control Automation > draft-bryskin-netconf-automation-framework-00 >=20 > Evolution of YANG Based Network Automation > * "Custom Subscription to Event Notifications" model : > - allows for a client to subscribe to unsolicited event notifications > defined by supported YANG models; >=20 > * "Subscribing to YANG datastore push updates" model: > - allows for a client to define subscribable events and contents of even= t > notifications as target-trigger-notify triplets >=20 > * "Smart filters for Push Updates" model: > - allows for a client to filter event triggers and notifications on push > object values and their change history, focuses on "outliers" >=20 > Objectives of YANG PUSH Based Generalized Network Control Automation > 1) To generalize target-trigger-notify concept into event-condition-actio= n > concept, where: >=20 > event - a particular change in the network state explicitly defined by > one of the YANG models supported by the network or implicitly defined by > the client, which is constantly monitored by the network; >=20 > condition - a logical expression that is evaluated only once after the > associated event is detected; >=20 > action - an operation to be carried out by the network when the associat= ed > event is detected and the associated condition is met >=20 > 2) To provide for a client a capability to configure the > event-condition-action triplets as policy rules ahead of time or/and duri= ng > network operations >=20 > Generalized Action > * Send notification > * Perform immediate network reconfiguration (e.g. modify one or more > attributes of one or more CONFIG=3DTRUE data store nodes); > * Schedule one time or periodic reconfiguration in the future; > * Call RPC defined by one of the YANG models supported by the network ( e= .g. > call network's path computer to evaluate whether an alternative/more opti= mal > path is available for a given connection) > * Link/unlink data store dynamic sub-trees; > * Etc. >=20 > Relationship with Policy Framework > * The framework should work autonomously >=20 > * The framework should fit well within a higher level policy framework, > with the latter possibly providing a greater level of automation: > - multiple micro-conditions could be combined into a single > macro-condition via a number of logical operations; > - multiple micro-actions could be combined into a single transaction wi= th > a possibility of specifying policies with respect to handling > errors/exceptions of each of the transaction components >=20 > Framework Benefits > * lower latency, faster responsiveness of the network to various > events/conditions; > * better scale (e.g. the client may control more networks because it does > not have to monitor/micro-manage any of them); > * CPU and bandwidth savings due to the reduced amount of communication be= tween > the client and the network > * The client can take itself out of the network control loop, change its > role from being network's "micro-manager" to being network's "police > officer", who interferes into network operations only in > exceptional/unpredicted situations >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 2 03:55:06 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4DD13F6E6 for ; Thu, 2 Nov 2017 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8hLvrl8TQOA for ; Thu, 2 Nov 2017 03:55:03 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AEA13F6C4 for ; Thu, 2 Nov 2017 03:54:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2GJBQCh299Z/xoBYJleHgYMgy8uZG4ug3OZUYFLmGwKJYlXVwECAQEBAQECA2gdC4JqRlgBAQEBAQEjAj4uBCQPAQVGFBwCJgJJFgoDCAEBF4l7BwEEDI16nWeCJ4tIIQWBDoEpdoIHgVGCFYRQhkeCYQWhRIEIgSaFMJhpBYculT4CBAYFAhkBgTlYgQ5TJod7izsBgRABAQE X-IPAS-Result: A2GJBQCh299Z/xoBYJleHgYMgy8uZG4ug3OZUYFLmGwKJYlXVwECAQEBAQECA2gdC4JqRlgBAQEBAQEjAj4uBCQPAQVGFBwCJgJJFgoDCAEBF4l7BwEEDI16nWeCJ4tIIQWBDoEpdoIHgVGCFYRQhkeCYQWhRIEIgSaFMJhpBYculT4CBAYFAhkBgTlYgQ5TJod7izsBgRABAQE X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208";a="53978888" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2017 11:54:32 +0100 X-IronPort-AV: E=Sophos;i="5.44,333,1505772000"; d="scan'208";a="267553220" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 11:54:05 +0100 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id vA2As4hu008130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 2 Nov 2017 11:54:05 +0100 Received: from [134.102.166.140] (134.102.166.140) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 11:53:59 +0100 To: "netconf@ietf.org" From: Henk Birkholz Message-ID: <6f54944c-82a4-062a-1f0a-ed9eb5aa2a0a@sit.fraunhofer.de> Date: Thu, 2 Nov 2017 11:53:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.166.140] Archived-At: Subject: [Netconf] YANG Push via the CoAP Management Interface (CoMI) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:55:05 -0000 Hello all, the YANG Push Dezign Team has started to work on augmenting CoMI with YANG Push capabilities. The scope consolidated while working on Yang push enhancements, in general. The problem statement is submitted as an I-D: > https://datatracker.ietf.org/doc/draft-birkholz-yang-push-coap-problemstatement/ and is also discussed in the CORE WG and T2T RG. Viele Grüße, Henk # tl;dr The I-D referenced above provides a problem statement, derives an initial gap analysis and illustrates a first set of solution approaches in regard to augmenting YANG data stores based on the CoAP Management Interface with YANG Push capabilities. A binary transfer mechanism for YANG Subscribed Notifications addresses both the requirements of constrained-node networks and the need for semantic interoperability via self-descriptiveness of the corresponding data in motion. From nobody Thu Nov 2 06:57:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44972138BCD for ; Thu, 2 Nov 2017 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d_xL_xo6sW5 for ; Thu, 2 Nov 2017 06:57:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AA30413A415 for ; Thu, 2 Nov 2017 06:57:12 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 27C8C1AE01AA; Thu, 2 Nov 2017 14:57:11 +0100 (CET) Date: Thu, 02 Nov 2017 14:55:46 +0100 (CET) Message-Id: <20171102.145546.466862355235662064.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netconf@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] WGLC on zerotouch draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:57:14 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB2ZXJzaW9uIC0xOSwgYW5kIGNoZWNrZWQgdGhhdCBteSBw cmV2aW91cyBjb21tZW50cyBhcmUNCmFkZHJlc3NlZC4gIEhlcmUgYXJlIG15IGNvbW1lbnRzIG9u IHRoaXMgdmVyc2lvbjoNCg0KDQpvICBTZWN0aW9uIDIuMg0KDQogIFRyZWUgZGlhZ3JhbSBpcyBv dXQgb2YgZGF0ZS4NCg0KDQpvICBTZWN0aW9uIDUuMSwgaXRlbSAxDQoNCiAgQWRkIHJlZmVyZW5j ZSB0byB0aGUgbmV3IG1vZHVsZSBpZXRmLXplcm90b3VjaC1kZXZpY2UsIG1heWJlIHR3ZWFrDQog IHRoZSB0ZXh0Pw0KDQoNCm8gIFNlY3Rpb24gNi4yDQoNCiAgVGhlIGV4YW1wbGUgaGFzOg0KDQog ICAgICAgICAiaWV0Zi1kZXZpY2U6emVyb3RvdWNoIiA6IHsNCiAgICAgICAgICAgImVuYWJsZWQi IDogZmFsc2UNCiAgICAgICAgIH0NCg0KICBUaGlzIHNob3VsZCBiZToNCg0KICAgICAgICAgImll dGYtemVyb3RvdWNoLWRldmljZTp6ZXJvdG91Y2giIDogew0KICAgICAgICAgICAiZW5hYmxlZCIg OiBmYWxzZQ0KICAgICAgICAgfQ0KDQoNCg0KbyAgaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNl cnZlci55YW5nDQoNCiAgSW4gdGhlIGRlc2NyaXB0aW9uIGZvciAic2NyaXB0IiwgeW91IG1lbnRp b24gJ3NjcmlwdC13YXJuaW5nJyBhbmQNCiAgJ3NjcmlwdC1lcnJvcicuICBCdXQgdGhleSBhcmUg Y2FsbGVkICdwcmUtc2NyaXB0LXdhcm5pbmcnLA0KICAncG9zdC1zY3JpcHQtd2FybmluZycsIGV0 Yy4NCg0KICBbSSBtYWRlIHRoaXMgY29tbWVudCBlYXJsaWVyLCB0byB3aGljaCB5b3UgcmVwbGll ZCAiV2lsbCBmaXgiLCBzbyBJDQogIGFzc3VtZSB5b3Ugc2ltcGx5IGZvcmdvdCB0aGlzIG9uZS5d DQoNCg0KbyAgaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZlci55YW5nDQoNCiAgVGhlIGRl c2NyaXB0aW9uIG9mIHRoZSAic2NyaXB0IiB0eXBlZGVmIHNheXM6DQoNCiAgICAgICBObyBhdHRl bXB0IGlzIG1hZGUgdG8gc3RhbmRhcmRpemUgdGhlIGNvbnRlbnRzLCBydW5uaW5nIGNvbnRleHQs DQogICAgICAgb3IgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugb2YgdGhlIHNjcmlwdC4NCiAgICAgICBb Li4uXQ0KICAgICAgIFRoZSBzY3JpcHQgcmV0dXJucyBleGl0IHN0YXR1cyBjb2RlICcwJyBvbiBz dWNjZXNzIGFuZCBub24temVybw0KICAgICAgIG9uIGVycm9yLCB3aXRoIGFjY29tcGFueWluZyBz dGRlcnIvc3Rkb3V0IGZvciBsb2dnaW5nIHB1cnBvc2VzLg0KDQogICAgIEkgdGhpbmsgdGhlIGxh c3QgcXVvdGVkIHNlbnRlbmNlIGNvbnRyYWRpY3RzIHRoZSBmaXJzdCAtIGl0IGRvZXMgaW4NCiAg ICAgZmFjdCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBydW5uaW5nIGNvbnRleHQgb2YgdGhl IHNjcmlwdC4NCg0KICAgICBJIHN1Z2dlc3QgdGhlIGxhdHRlciBzZW50ZW5jZSBpcyByZW1vdmVk LCBhbmQgdGhlIHJlc3Qgb2YgdGhlIHRlc3QNCiAgICAgYWRqdXN0ZWQuICBEb24ndCB0YWxrIGFi b3V0IGV4aXQgY29kZXMsIGJ1dCBpbnN0ZWFkIHRhbGsgYWJvdXQNCiAgICAgInN1Y2Nlc3MiIG9y ICJlcnJvciIgZXRjLg0KDQogIFtJIG1hZGUgdGhpcyBjb21tZW50IGVhcmxpZXIsIHRvIHdoaWNo IHlvdSByZXBsaWVkICJXaWxsIGRvIiwgc28gSQ0KICBhc3N1bWUgeW91IHNpbXBseSBmb3Jnb3Qg dGhpcyBvbmUuXQ0KDQoNCm8gIGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXIueWFuZw0K DQogICAgICAgICAgICAgICAgZW51bSAic3NoLWRzcyIgew0KICAgICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgInNzaC1kc3MiOw0KDQogIERpZCB5b3UgZ2V0 IGEgd2FybmluZyBmb3IgYSBtaXNzaW5nIGRlc2NyaXB0aW9uIDstKQ0KDQoNCm8gIGlldGYtemVy b3RvdWNoLWluZm9ybWF0aW9uLnlhbmcNCg0KICBJIHN0aWxsIHRoaW5rIHRoYXQgd2hlbiByYzp5 YW5nLWRhdGEgaXMgdXNlZCwgaXQgbmVlZHMgdG8gaGF2ZSBhDQogIHNpbmdsZSBjb250YWluZXIu DQoNCiAgWW91IGNhbiBlYXNpbHkgZml4IHRoaXMgYnkgZGVmaW5pbmcgdHdvIHNlcGFyYXRlIHN0 cnVjdHVyZXMsDQogICJyZWRpcmVjdC1pbmZvcm1hdGlvbiIgYW5kICJvbmJvYXJkaW5nLWluZm9y bWF0aW9uIiwgdGhlbiBkZWZpbmUgYQ0KICAiemVyb3RvdWNoLWluZm9ybWF0aW9uIiBhcnRpZmFj dCBhcyBiZWluZyBvbmUgb2YgdGhlc2UgdHdvDQogIHN0cnVjdHVyZXMuDQoNCg0KbyAgaWV0Zi16 ZXJvdG91Y2gtZGV2aWNlLnlhbmcNCg0KICAgIGxlYWYgZGV2aWQtY2VydGlmaWNhdGUNCg0KICBT aG91bGQgaXQgYmUgY2FsbGVkIGlkZXZpZC1jZXJ0aWZpY2F0ZT8NCg0KDQpvICBpZXRmLXplcm90 b3VjaC1kZXZpY2UueWFuZw0KDQogICAgY29udGFpbmVyIGJvb3RzdHJhcC1zZXJ2ZXJzIHsNCiAg ICAgICAgY29uZmlnIGZhbHNlOw0KICAgICAgICAuLi4NCiAgICAgICAgIkRlZmF1bHQgbGlzdCBv ZiBib290c3RyYXAgc2VydmVycyB0aGlzIGRldmljZSBpcw0KICAgICAgICAgY29uZmlndXJlZCB0 byByZWFjaCBvdXQgdG8gd2hlbiBib290c3RyYXBwaW5nLiI7DQoNCiAgSSBoYWQgdG8gdGhpbmsg aGFyZCBhYm91dCB0aGlzIG9uZS4gIEkgKnRoaW5rKiB0aGF0IHRoZSBpZGVhIGlzIHRoYXQNCiAg dGhpcyBsaXN0IGNvbnRhaW5zIHRoZSBmYWN0b3J5LWluc3RhbGxlZCBsaXN0IG9mIGJvb3RzdHJh cCBzZXJ2ZXJzDQogIGRlZmluZWQgaW4gc2VjdGlvbiA1LjEsIGJ1bGxldCAzPw0KDQogIE1heWJl IHJlcGhyYXNlLCB3L28gdXNpbmcgdGhlIHdvcmRzICJkZWZhdWx0IGxpc3QiIGFuZCAiY29uZmln dXJlZCIuDQoNCg0KbyAgaWV0Zi16ZXJvdG91Y2gtZGV2aWNlLnlhbmcNCg0KDQogICAgbGVhZiBi b290c3RyYXAtc2VydmVyLXRhLWNlcnRpZmljYXRlcyB7DQoNCiAgV2hhdCBkb2VzICJ0YSIgc3Rh bmQgZm9yPw0KDQoNCg0KRWRpdG9yaWFsIG5pdA0KLS0tLS0tLS0tLS0tLQ0KDQpvICB1c2UgIiIg aW5zdGVhZCBvZiAnJyBjb25zaXN0ZW50bHkgIChleGNlcHQgaW4gWUFORyBzdHJpbmdzKQ0KICAo eW91IGZpeGVkIHNvbWUsIGFuZCB0aGVuIGFkZGVkIHNvbWUgbmV3IHVzYWdlcyBvZiAnJyA6KQ0K DQoNCg0KDQovbWFydGluDQoNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5p QGdtYWlsLmNvbT4gd3JvdGU6DQo+IFRoZSB6ZXJvdG91Y2ggZHJhZnQgaGFzIGhhZCBhIGNvdXBs ZSBvZiBjYWxscyBmb3IgY29uc2lkZXJhdGlvbiBvZiBMQywNCj4gYW5kIGhhcyBvdmVyIHRoYXQg cGVyaW9kIGN1bXVsYXRpdmVseSBwaWNrZWQgdXAgdm90ZXMgb2Ygc3VwcG9ydC4gVGhlDQo+IGxh c3QgYXR0ZW1wdCByZXN1bHRlZCBpbiBhIGZldyBtb3JlIGlzc3VlcyBiZWluZyByYWlzZWQgYnkg TWFydGluLA0KPiB3aGljaCBLZW50IGhhcyBhZGRyZXNzZWQuIFRoYXQgbGVhdmVzIHRoZSBxdWVz dGlvbiBvZiB0aGUgZGVmaW5pdGlvbg0KPiBvZiDigJxoYXNoLWFsZ29yaXRobeKAnSBhcyBhIGJh c2UgaWRlbnRpdHkgaW4gdGhlIG1vZHVsZSBhbmQgdGhlDQo+IOKAmHlhbmctZGF0YeKAmSBleHRl bnNpb24gc3RhdGVtZW50IGFzIGl0IGFwcGxpZXMgdG8gYSBkcmFmdCdzIHVzZSBvZg0KPiAnY2hv aWNlJyBzdGF0ZW1lbnQuIFNpbmNlIHRoZXJlIGlzIG5vIGNyeXB0byBtb2R1bGUgd2l0aA0KPiDi gJxoYXNoLWFsZ29yaXRobSIgaWRlbnRpdGllcywgS2VudCBpcyBsZWF2aW5nIHRoZSBkZWZpbml0 aW9uIGluIHRoaXMNCj4gZHJhZnQuIFdoZW4gYW5kIGlmLCBzdWNoIGEgbW9kZWwvaWRlbnRpdHkg aXMgZGVmaW5lZCwgd2Ugd2lsbA0KPiBkZXByZWNhdGUgdGhlIGRlZmluaXRpb24gaW4gdGhpcyBk cmFmdC4gRm9yIOKAmHlhbmctZGF0YeKAmSBleHRlbnNpb24NCj4gc3RhdGVtZW50LCB3ZSB3aWxs IGdvIHdpdGggTWFydGlu4oCZcyBzdWdnZXN0aW9uIHRvIGFkZCB0aGlzIGluIHRoZQ0KPiB5YW5n LWRhdGEtYXVnbWVudGF0aW9uIGRyYWZ0LiBQbGVhc2Ugbm90ZSB0aGF0IHRoYXQgZHJhZnQgaXMg YW4NCj4gaW5kaXZpZHVhbCBkcmFmdCwgYnV0IHNpbmNlIGl0IGlzIGEgdGVjaG5pY2FsIGRldGFp bCwgd2hvc2Ugc29sdXRpb24NCj4gaGFzIGdlbmVyYWxseSBiZWVuIGFncmVlZCB1cG9uLCB3ZSBm ZWVsIGl0IHNob3VsZCBub3QgaG9sZCB1cCB0aGUgTEMuDQo+IA0KPiBTaW5jZSB3ZSBhcmUgZGVh bGluZyB3aXRoIGFuIHVwZGF0ZWQgZHJhZnQsIGEgbmV3IExDIGhhcyB0byBiZQ0KPiBpc3N1ZWQu IFdlIHdpbGwgY291bnQgdGhlIHByZXZpb3VzIHZvdGVzIG9mIHN1cHBvcnQgZm9yIHRoaXMgZHJh ZnQgaW4NCj4gYWRkaXRpb24gdG8gYW55IG5ldyBvbmVzIHRvIG1vdmUgdGhlIGRyYWZ0IGZvcndh cmQuIFRoaXMgZS1tYWlsIHN0YXJ0cw0KPiB0aGF0IExDIGFuZCB3aWxsIGxhc3QgMiB3ZWVrcy4g UGxlYXNlIGluZGljYXRlIHN1cHBvcnQgZm9yIHRoZSBkcmFmdA0KPiBieSByZXNwb25kaW5nIHRv IHRoZSBlLW1haWxzLCBhbmQgaWYgeW91IGhhdmUgb2JqZWN0aW9ucywgaW5kaWNhdGUNCj4gd2h5 LiBGb3IgdGhvc2UgdGhhdCBwcm92aWRlZCBmZWVkYmFjayBiZWZvcmUsIHBsZWFzZSBlbnN1cmUg eW91cg0KPiBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2VkIGJ5IHRoaXMgdmVyc2lvbiBvZiB0 aGUgZHJhZnQuDQo+IA0KPiBUaGFua3MuIA0KPiANCj4gTWFoZXNoIEpldGhhbmFuZGFuaSAoYXMg Y28tY2hhaXIpDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo= From nobody Thu Nov 2 07:18:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5E13F41B; Thu, 2 Nov 2017 07:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.441 X-Spam-Level: X-Spam-Status: No, score=-12.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_12=2.059, 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 xIYxCHxHU4rv; Thu, 2 Nov 2017 07:18:48 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7391A138BCD; Thu, 2 Nov 2017 07:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61910; q=dns/txt; s=iport; t=1509632327; x=1510841927; h=to:cc:from:subject:message-id:date:mime-version; bh=J9Hmp8RC7z/kXevvd1kph+PSUyE+DUEiXgwv5SxD0/I=; b=TeIlDp3f6Ym+ggheru36NyMY6wkIi8aNxNeys4vOKycD1XFDVRhOqyrv JJi4/fnlx3WqRWsb39WzvY1ZdyDMVirvAMnM96YQLMWUlGW5mygdBP/// hgHxojX5Lis7XUNn908MLqPP+j385Sbz4/5QcOku+1DZKZTbb5xhtWVe1 g=; X-Files: dfpcfioondggippe.png : 43605 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AQDIKPtZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkcDgU5uJ4N9ixOTFI4OhUYQggEHAQIlhRaFEBcBAQEBAQEBAQF?= =?us-ascii?q?rKIUUFR5WHAEBARkBAQEiAgQVAQ43DQUBAgEBAoodEKhggicminEBAQEBAQEBA?= =?us-ascii?q?wEBAQEBAQEBARAKBYMug1qBaSmGP4EbBINJgmIFoGuBIoZlAYEAjRaLeIc6jGG?= =?us-ascii?q?BSIdtgTkgATaBbDQhCB0Vgy2EYEA2AYsALIIWAQEB?= X-IronPort-AV: E=Sophos;i="5.44,334,1505779200"; d="png'150?scan'150,208,217,150";a="656738489" 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; 02 Nov 2017 14:18:45 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA2EIida004544; Thu, 2 Nov 2017 14:18:44 GMT To: NETCONF Cc: "sec-ads@ietf.org" From: Benoit Claise Message-ID: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> Date: Thu, 2 Nov 2017 15:18:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AE5AAAC3A42D4844F4BF3B4B" Content-Language: en-US Archived-At: Subject: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:18:50 -0000 This is a multi-part message in MIME format. --------------AE5AAAC3A42D4844F4BF3B4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt The NETCONF WG was cc'ed for the entire discussion. What do you think? I will draw the conclusions by Friday Nov 10th. Note: If the WG is fine, the next step is to approve this document. Regards, Benoit --------------AE5AAAC3A42D4844F4BF3B4B Content-Type: multipart/related; boundary="------------0F74EA4A356EE693CBF6A911" --------------0F74EA4A356EE693CBF6A911 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt


The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit
--------------0F74EA4A356EE693CBF6A911 Content-Type: image/png; name="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dfpcfioondggippe.png" iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC +YHGlxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL 54BA95WpYrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIg iN2ClI8gCIIgCIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU 1budlnGWW9Ei1mf45fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluG nFMMK91+zhv/yNjzT4Gdo4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pd bo6buif+9eeWtPnXv6CR/FPYc+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJX x1+/P6TX1qbAn3/+DWvTKfuX9bC2S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi6 7wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4jlgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNX ud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllFnBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Y gfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvSS/v9L9HPMFFl8D5zbEGSizUDcgokCKIH 5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrfX8TtVh6W9yB1MxV/iBt3fOpwlw7v XD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbfwKXq6se7Lj//Sj6DlcJB+9FI FUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60IyDIBZ0CCIHpwvuN8FzTL +Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omknOhYrqi1hzNqj2od3 bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyrz1EzN0EQxL84 30WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt4qmnrDDA nL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB+Y7z XTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUj YtyTWcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35 KV73CFvrJiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX 7+JJ7+0z04ZX/O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz +95YmLPx+1/yMeRf4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV0 8idquf+lP/67/LhW/5k2PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE 7PAZOI49IrPfJ0V5TphipXuRygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWR MVfPIN/X+Z9//k1OMc9Qy8DwPJQgCGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/h E8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN 5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggbpHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIR BEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQpH0EQBLErrD2xEgRBEMS2QMpHEARB7Apr T6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjNa2EZnE+HzC6sB2G8LZmOIAhioxiZ 9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZkOoIgiJdH8fl5IxV3NnE+HcYZ UFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw81P7SxDEnpCa9NqqZxOX +jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw81P7SxDEeyJK7IQU Q1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEqyJ0AIcWQVSRJ CimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hCFmMqFlg1 urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1Eu5mm D0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL 3CW0ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YI Wu/yWetq1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/U NHcDNc3Zrp5a5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeI o4gGND27y1MLZvIPuQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t 8ln99duTIAhigLHKlxsiuxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl 1nzKp+Ujaq04WI5YRfkC1crmE9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rr P8E3YwZKFrZvMInH3uVDHQxlDPXk0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+Wb Zk+CIIgB8SYNeZRMve/lwsyUD6sDyNKbUD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPm UTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GDyXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7e C4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht0n0cLKoF63cIZ6B86kCoJV4MtQTbn29p SiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJsQL28FwT1Rv1Afhi4+9NJTcTLV2Ch S5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/SVkpCT7lSubom5cNqpuw8ws0z 7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PBd/P0Ke6NCIUUa39CuSOi 3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3PsSRDEmyA97eGP8seU LP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LPtyT0FMNYVceB kbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIlsPbESiyL J6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST9xEE sW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6C IAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhd Ye2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAI Ylsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGU jyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAI YldYe2IlCIIgiG3h+ZSvKYuiKJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G 0ZRFhxXNtdqM2lZFUVTtau0TPnC8HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5t c2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoOp7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8 XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZ xXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJWVXs7IOu11QsEyzPgUh9ze4nHa46R3CIe 6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62nqaX+mg3/dTr4hHMSfnKjo/d5vwh tJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+fpHwuZFGRuUDKNyb71Sjf+XTw rYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43PBYfEc+bhIX1bHY99vUt9 FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6hTkZi4gcoIxJ/r5K dxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebhdA4T6GBCXa/m 4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjPqJ5hsH0/ 4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+eccfX V9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eT q8ryNyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIg BcgOwM5jqseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCo yc3Yg+mb4O4sGQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqM nJpG051AgFBBv6gExusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3 q5PsRvuI/RbYTUoUbUXOpNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D951McnPo+4BKT5w0x1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82 v7StiIFUJKP+OPY80jwO+yt+UI+40fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olS QvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7 mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yL HfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFpBHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/ t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78FtkNU75gaTX4E61wKzuM2tmCZZ/U uHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTGk+dNAYvyWaGheKR9x8jsrpcP 9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fBAkNsw2smbXDqadsT6e/2 E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/RCreyw6idLVj2SY27 R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFwamQEojxnRP5N zPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9mpPy9d3P 6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRiRVxI /k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+u OW8IKOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnS rUTWXMqXWtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUU egQn2iG9uptBm9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6 FDqO+qs6IE5Gx1NwUD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M 6AmCbeO7RgDYb4Hd5Nu6hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk9 7vNQvuSNAC+Gzo5ZKZ9OTQrynvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBf GylLFahJ+UH0Zh23+2uaLXF8XE11AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQN qCb83Eja0uWpe70K2XlKv5BfWXomxrf/PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOI xz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUv w+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGb xBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq716uQnaf0C/mVpWdifPvfcykJaBfZ TVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7YITnuLn92jTu+voCjO+8/14Ve 4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbEDLLqLxPU6LdOReHOsd/8h 5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/kPK9M0TOFZf4dgaV T7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRBELvCWhMqQRAE QWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q 8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88dwDXu b41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW 38x2fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4Dk Uh+3EeYmNiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tb PMbXnzDyl7pawky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz 9XdGymcJIeWbqAkp33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+ eiIWmT3b6hYgXerjNmb1Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7 Nz4XHBL0eFjcbqvjsa93qY/ir01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP 6o2fLGoR1b5nb5bdL7JfsL/QPPl6Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl 2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3vgm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidw xhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0tedYYCyOZ860qfavR8efv1MPrY6deeeT4fhj6di kdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1 xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmrqm2tcbHGEfVXtdE55O0nLD/dqWw9 TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmWu1+zwvRD+z5g2WfCdQSvCyE+ 5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplThr0U6PiVrUrFWQKbOIiL/ bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0ZvdbmpcXMB2MPVH+vR5 tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbakQfl8/ZoZNgW1 /AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8tUjHVbIm FWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3mxoX F7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDy hWFPP+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+ SH88jjn1pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb 9vSBZ07p6y6CHkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMF rWEA64FfzwTlg3GTRfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3C OMoGosroOhq4wmTK5+rX3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNY l/KZsWIyprFDWBiZb4nyTdFzJsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxh T/N6eTApN9O9HqV83n7NDQfl03VGVvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUb Uz4zVkzGNHYICyPzLVG+KXrORPlAR72Ub54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xp Xi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/ZKN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1 sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq/Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQ ZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3taErw5ucqeS1I+Z7/6mvN8LTib8iXs 47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6FpAReGEmQaWSjkZCWPUFAf1b +NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2KpT/SB1EyOI6gv1ChKZTP pWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj1/9mue6ME2Rv+6+u wHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/tq5eN+r8fTj1z 9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpLWR76wBzK z+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJZI1f R/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq 2NHWxxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNo N4LORLQuu+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p 9mZm2J3hb33R9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa 2NpX2YmpMD7q8ap45F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOr AVK+veCRz3duC3He4lrgZn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4j iHUgUt5WD6FV0h+vDYJ4LtZc5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUW vu+o0H3scW/feUT9erf+EhOwwesUYXzcz3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3 /hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+dtuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W 2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPHzmx467Q1N1UD2x0+dce5JfqLtnFcY3vH Nfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xSvgfwUpTvyW2S8s3fxktTvlVAyrcc ZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVsondpEOogG513UpQgVwfNinPRA0 /KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZrSlFc+IXdFzaKDsB0m3n tPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0YVjPtgBP/oD3LMryO gvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8IR9LTJ5iF+kg GpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO20jalZdmt rURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y4z56 XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK 4E7H1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6Zcp B/sPGHdgh8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f 9egZnpEL+xGVfV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17Zt xU9RyCVU0C8GtZUM7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k 9Hf1F/t50j6efplysP+Acb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6O UD6Z+Zj9Lp/tz+77qkfP8Ixc2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkY ZOgwRodKKCRyUj7TbhHt6YSi40B/3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19Q DuhvYtyBsnhcPJQP91deO+o6msUP8XU6rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1Fnz Dv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPyMMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtD WP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/ gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1n/JlPsY2q2V+DWAy5ZMhyDyUD9kN KjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJlE/VnuqH6Dqd2i9DtfJ0Pp9O t5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2g4qMxNL5lO8RO4eyH6d8 0A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu57E/dHuXzXu+kfE7o lCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6Xz855fRi6oBsc XeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8uP4SUb1q/ YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzdfkLH jaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8 c93f4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+ rqY6Ifr+gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTL RqbdFHNH0p39BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9 cfk5KGw3lXd5GnudL+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0d H1dTnRB9f8BS/1hVfd7WUKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+ 2ci0m2LuSLqzv8DPzfrufqF2kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yh Py4/B4XtpvIu67HX+RL+7L3enXr67AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnz vfD8p849trQrwR7wbnZ7t/4SxASQ8vmQmTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/e zW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Budnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd 3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKV8Gug928tuHxGxoygW//7o1 nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Giw1v7yRLYCeVrShgUzbaTHrc5 Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqKta7TGGtPrM9FW8GgaLad 9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go1rpOH8H+Kd+MbWwn tHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hpMuSQ8j1R/lPk PBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/HhFJyQKfdW L2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9VLsvu l7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fg hEy5t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5 rXJVdb+MxaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI 7eMZFy9GKJ/lJzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18 OgxCz6eDmUB1Ph3GKZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfp GYx1TtButgvlO+V8NmVh6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJd gZ/0vyaO5FzXqD7qL7x/rnedxnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9TH QeilPpoJVJf6OE753HraAHKQnuh4G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw 1jlBu9kulO+Uc22rwtInZTeXfKd/ijpqSBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/ 6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZRUx8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fy oUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgo X9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8fa3rNMZTZ8079IPeHMqn6vTxQkIO SAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIcx4Q+oBPYnp7xhXqqMY3H15Yd V8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGPyxRYlM93X/Jd16g+6m/K 39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+MI4JgXZIDe35XpTP v65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+cmRrEAEk5G6J8 U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM877nn3Ge3P 81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR45DF r6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wq p/S2ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKH YByTuW8jIXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo 2yfRwdua2Bzs5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISN Ph8SfU9AJaSZcvrD8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuX jfp/7tjI8NS2g09OJ0O5WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+O cUzYJzEuc1A+swPQT6D/e69rXB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBB CBt9PiT6noBKSDPl9Ifl5yugnCl6Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZ V69a9f80jHahHXxyOhnKxWLPKvK+FGLp6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87 xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P 9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRqgFRhH+A47g/eV8AI4kWxGuVz7GxGbBgc xx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5ykcQBEEQs2PtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h 7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3/c3UF7JnGmL/8D10Z6dY dhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N33h7PW+U7n8pFI9B4 J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9JL3W1aAQa7yT2 9P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRDIOWbV84W rebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAmljKXk ntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xO hWf4/RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9 ofsfbgeP9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMq BdXN8cLH3fZ3jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nw DL/fIsR2TtoHyrf9E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatw KuKC91+bRtOsiPIVOpbuTnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7o uNv+3nH5dPtJp4J+4QzY+ROPi09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzU fSY8beSo+cuI/BgvdH1tHs+fOmVmk3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp 7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQrq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fA zlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9uOW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1 I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aCPhgysB3C6zDc7VW+/dDFvfClINTCeLu+ fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om6mnbE/ktPA76pY/l5Vlb/YL+7JQz wW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx4GCCCiV+TIXy97+rdoI+GDKw HcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gkGr/GfqJtrENky87xOVP1 tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRFKF/msgxYDUu2YjWI DvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy5ZPUzk35XHoi e0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd6ENAnz4Y Tsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBacduu ndzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgX p56JZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586 VVAcJFyZ8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6 lZNDB8QIZfB4oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQ n5Hd0JosvM+EzYwcNX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2Iosuf LA6nk/ndCbc+BrraZSPkWblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ 0MKhLA994AztbI2LW09oz6aUfqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyM XNfjuFu+vl4DS0yeKj+oFrRGZyypd2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5a Ic/KVVNMwXzfJsukoZZWu95+2fXHdSmOVXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6 Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328RsJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaC eEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKyXrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQx YAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5IOUjJoCUjyDk9marL/F1moTfIrGP Q6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1zIbd9COJ6vZLyEQRBEDvD2hMr QRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH7bA+xI7aa5trY+g+ XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jpxgeQWAU7oXyJ zce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9sT4Xic3H trDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8Mc6n g281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b 5bLsflGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl 01jjgvRP43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusO uwlZ+T6y1/vY+2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5V rqruFxV7DfWrKidyNOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1 rTUuSP80bmflyAF2MP0qZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6w m5CV7yN7vY8RMeakfE2pgzsVLfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anW ORoVSJpVIFB9qaVIxMP2gcdt/T+B3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYH J9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4SpzBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97 Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+ 1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJhzgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTL iwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a9d12645kUr7d3scICzNSvjBc6ZdF wmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7YLsh/cM/cJ/v4i37hxLGY0ak vzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZcRUbiXG3OpfyW9s/7fp+ u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VRFF2RDec8NQf1MeWz 7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj2yIT/BNoY/+i 5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583Z6jk/YqC rA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7x/On zkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU 0u/s6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQW krfEh/TMXR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12 s5pP9muf97Fe7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUz KB+sP/ygcsQS9gHHgf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA 8OaXRfXH/RNqA35JXUh4MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xd d0p84CD4YfRrFEVRHMpSB+7Db8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7A Psj+QV7qKf063/3tuEHPqKp69WoMsZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5 /6EsdaKsgwwA/0z4oX1/wHaD9R12S48X6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIri WFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqLb5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fj Bj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jOEHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD +/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6QfXZit+wlPmIFPJD4txP/zMa79fel seKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/Kx63Gtgzvq6kS+/DPfLxbf18a K86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN5aO9aB/2Crmt3eQlvvca 23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQqH0EQBEEshrUnVoIg CILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8g CILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC 2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDl IwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8ST cD4dbk7ZlEVRHE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9 H9SfIJ6ES328OWVbFUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrS qmwfnRdIT5/+CIkenE8HhnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte 4s63Lywwd3YRixn4XOqjIxBqK6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTU dq0+b9X/L3WVo9Y894fr1WbDS9z53hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfD oktEE9udjx4tgEzKN9+yJSnfHFhuCrUf4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ 7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZsyrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0 y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3le85g0yskpaTG8XA6h3Y17eAdF6Bnl+VY Wv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717IczfSMrnu2/Y/iYS1O+/B5YL7p8J /yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH7YpTqupmj0S/zIQu2dGw087+ iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4AD27LMfK8k+AHPlZdutX yNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw/0z4JzEHXmyVT1IB QUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH1V10HKApdWSs WJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S3Kz6hJCM VL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T1iy1 unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQX o3xWqCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5 gL/NQ/mIFJabQpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBM vPKUjGzT6xFH11Wb1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1P pF4VDHf/xCPVrkn5gL/NQ/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGv cyQon8m5kvoYnUB2sNrW5y1O+ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK 51sGSdf3UD675pyU735QxYX+/hZmhOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTp XzWZi/LNm0r46Crfkz/2maB8vvsG9jdSvi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2v VMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOoDL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCA Pl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgEY899A/vb8Iu184xN+bB/EhaWm0LnoXzq /TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/pVzVKNITHUftKsXFyeh4jqIy9Jb5 vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgdb+T6Ndf9VKLvqHrqNiMTjD33 Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9+sN2ZRKY6m7cr9F3coxI 09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx9JQ+Gfrn2LBoSX67 JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmbmmUHwz+JFBaY O/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0BfpCY7b7eqM NxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhlk8Il 9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+ z3oSuwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhY WFhcZXVuw2IW7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GW aIGU7+nl8uNLURRV/b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp 0mVBPduPpzrq6tyG5b//qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+ u3iltV/F3s9rm/Qlys3+S4z4qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTg p1/1l6eF5vXHLe6//PiyKF+C7f6qvzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3 q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodKW31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71 EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5O SfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198iy2TFgY3X5agQKR8fj29hZTvtQop3zLl iSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjcfFmCApHy+fX0FlK+vZYlWliF8tXD RqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJETp04iH6KQ/NYzy5b8qNTKSeG /vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4CfADm2PpP8QZji46P68uOi Egjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61zrxfndX3PKvxW/XGv rzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt+kP8hI6jgvQx +ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0oimN9uv1n OOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/EuKBi jlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b 11Zfi6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QG llJXIvZtP1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkr xiof1BONC7QDHC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jn NL8FLmGv8hWu68VzXXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef 1VBH6PbvfxwHfdDxBN+z2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7 VYXU/etq139fr9/b9nbwe3sZ2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGB doDjhTQ3/SQlB+jj8odL/dtgWz0WQ1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpX uK4Xz3UtfKLPmW6/tzePFFeCNOil/S7Irnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDI qT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvVFAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5d fnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZPKkp2fVYkpnxYTzQuCTuA8UKaW36SlAP0 8fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjEWGJnzvVi98sud34iKVBHVP7oD96Z UjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF/bXtM0L5/tDrnOP23Drl+17p 2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHleNtN2wcXFaDnjFoYOWE9 0bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6GeE/0WuMRYYmfO9WL3 yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb4bqSbxh3/x8f fcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdD lG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8ZGyTf IjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevow LkVOTMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4 g/6G568fx67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6d YAmZkknV2j8KldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KA YcZvK/VmSh/GpciJSfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/ TD9JyoGUz+EPOpo91cc+Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQ cdjuPJTPeHE28oP2q722aCVGRqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5 VX34VVdffohfgvB6wPCOkFrW7eWIb2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3G Ws9eY8GfbzHHEY5LhvxovKyC/ATISerj8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7v tL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87resjG/Naq/3c0podJwwIq1avyx7ejPGX4bImW A47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo/Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A 0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V/71GSMnxtmvaZ6z17DUW/PkWcxzh uGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVRVN/61+Sc/u+0v9dvsZ4Jv73U v/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVVj77O9706fhOBl/39oqFd U09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4rEP5cCi/3AYGb138 +/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz1rVyWbHtfe6X AsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ55avXWZZo YSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhYWFhe pazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVg YWFheZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv /ShytvOep/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+ LXK27Z6nnMQ+2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/H SVTw8vdv45Tv57fq5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnw uphdzrPL3Hpuxg/bD7tf6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyPar l1rYcjLtWo2H2g/In6tk6TlD6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdG y3qU78GyGOWbWkj55pU/V1mO8n3cIvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76 d1K+efWcofR+0Y3CsFO8f1xYsstm/JCUb137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+K ojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H//jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrj fljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yoHegpjs+fDThC+VLj8sh1MaOcX/WXm5Db f4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrPuCjDbz2UL243sNX9z7RWWJ/OkkVR fHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3WwswyXhpWUr22XY9lWRZc5eZfT x9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLar1XbtyBiLHHKUDkhB5ZB /aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJul8uxPkXXDbLb4OlV 2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+rarj/gePwukD+ 4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t80fGf3wRd /GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsYUb9D 5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+ 4/erJeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2 PCpykxVuGIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE 7ddOH6incoT2a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYL xAnOJjVytIv9EBfTD4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0f LZuifGKVIFi9iUu8UCYpX///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739U f//Pw4mdMtTWD9plqOSgfP0q1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZA jutiZjmh9RJ20/a//PhyfIjy5bab8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue 6HjiukD+4/arJeyfVxajfFFcI5ba7rjFIDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cRO GWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTdhFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu 2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5JtdSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9 Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUoX/0hwrJf9RcZKs1B+bzyU/Whb8xC +Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/qjx+XXz/q+lf98eMSVsvWx0/5 Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v/FR91PQ8lG+ZTzvOQPl0 3yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq2fr4KV/m8i8Yjhy/ WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2ehQxc0Nb2/EzgW Qqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TPdV3MLMeg XtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrUR38T 9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4G u611zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtB u5dvdf2tqk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH8 49uxkJTpH4Ms8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK7 27EVv1b1/9Q3G758VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtV itxdHzgu81wXz5MjBgXYLbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z 6RMOvewXOG7bGfmP06+ebX9feT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plw u2PhGP58i8odFe8lGvqMGHA4SbHdsOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/ gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI36VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2 c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0yccev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8Zco qxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4urLLUZBgvLUwop34uU1Q3OwuIppHwsL1BI +dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQcbfMB3JYWKaWLVO+IQ9pv5scr90+ C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30WFhaW9ymkfC9SVjc4CwsLy84K Kd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2hbUnVoIgCILYFkj5CIIg iF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnPp8MrqUu8JF7vung9 rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF62H79/k1V/ma EoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix6+L1sIqB 155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqTRvBi 18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlD s3r9AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvO WA5WsXefRtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjf m9VuF1F/8ZVNn1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/ Vd0nepHoeF8v6KLctjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV 1fZNi5g+IaeqjPojuuZ0SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68f Yj/XwroGkHwsx+//c6Ebi7sLDZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ 7Onyw6T/GP6J9fTYH9oN62/dGpPds+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+z YhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9Upk vOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA 7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7Qf21T46uVKP7/FP9donJUwRPl/ooI9Ih ernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9VolU/GouFZNvXC9Q1N21YEfbnrREa7 WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQndwPgqsZCD2nX6+QRcTMLUVpqg xY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/4503UH7Qb11z45ulKN7vPP 99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDIbsqRdeL6MfQC0QOU D8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+tu1Itf9xH9G/K 4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67yOwpVy5A UKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmWscQX S8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9e F3O/QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9 /VWp0d5GlVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX67 9EQq12wg5QtjrYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9 LftPtU9/Qt4q34Yo39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2 G7k/dJVci+iywa284jcn5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvji t0tsymfp+WzKp1/mmU75EnJsO9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5q N+nnzf01LfR7FuxR1A6l6zjGHesvkkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylf Uv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19Vt hS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x 5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+ pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W9x8+zbeHwu9dqDQm+dMgCR1P9CDm GfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/haR1mCxLPeEgk5GZqWp552p/pr vWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb15H6ZIgaX1G7e3WsZ2dN Ke8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9PzuwwNypM3WC7Kwbhs9+ 3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1VH0J+VaGqRkNQ qD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4fy/qkdBa CQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6S9lt RH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CL bCk5DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASx K6w9sRIEQRDEtkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ 7UJswg2+KrilXQXFTtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb 2lVQ7LS9uE7vYYdxf7Dqv/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6 mPzBYjouP5nPbquSrnexw5g/gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptW vYqeTrTVLVy91EeTP1hMx+Un89ltVdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTl LbI/nw7WSsXjyYzz2W3NxMq3scOIPzxPo+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZ cT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsECyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQO E7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10EBvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ /s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv4bhlGMC/kR2S/oAQMx6c8GnYOXkf gE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+UFsQuvUOwIBI177+rPwbIU6q2 T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9z6suAoP9Rfqb45LSE9lh XMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1Nf0iMl3DcKgzg38gO SX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QUe2ZhXsrXNILo SSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn00GHv1H4 rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i9a03 ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9Mfj AvUEcqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa 5ErdT0I7u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/ KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T 6hh6DiqF5yfsBgfTpDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/Y jJTPvA/g++TGKJ96EPsI5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hc kJ5IDlYGyYf1ZTjbjy9o96akeB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4reww CfmUD9vZQ1GS16/D/vdqppEG3TMenISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXoby oRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9Ot5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8 OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKBLVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH 2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MU CxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXLQTkroFBBTeYHIMx+pfS3EEXpKgSO zwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmU D9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XPPVHGkBFC972E8JdwBwad zlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwuUE/X+khKvg0QwsJ2 L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l7Ya fx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y6/+QcsSx IP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaHJdmH lnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgW pH8lvm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1o Kcc+GfhJSk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJf URTHuja/N+W5n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB 7fDeePDzR7sDKR9BEMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAI glgJKt9z3g/dvDZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdae WAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu8 7c7XwDlrP3fiUeTZufuYIQeEIPaBZ0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFu mHOVrylXi5ntzaZm3YLqfDrM2r2sHZFfZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18Qm sMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URrw3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFi IOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5g XvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzOYaIfSvwT3dItoP4Ox8tmjIok+gX0 zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz3IdhTJjgcGp6aZFBwfDm+sOt UlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXdIWT83B/MS54TuwYP1UWi 5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLoF9A/T1hVddQG9hfp b45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ulqgqvr6T+Y5YI O2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a5Rv0EUo0 pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hPHJcQ 0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQi zf7KDLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXN YBiBYMlYhEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq +oH9I5TPqh/WVcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9 wgFJ1Z+jv6hdJP9TD8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvD cOoefwVrYcX4R1X0A/tHKJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenp G/ep4zLSo97OY/qEA5KqP0d/UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+ cnzz/ZPYGJ75Ll9P+XyJTipSVRHdFilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8 ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRF DHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOi yekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+P e16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgOYbMKp+w1MHHSEjuFflnyS/DogKXR iVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmdLBUxriYcR4892KGXNB8VNPtU 7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y87TNmxDcETeO+27cWfOF fDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHrekEdI7FTLZ+mv1q5e Px/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE94rwzKqUZ8/m ok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+Hk5Y+SC/Y 6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+GqGK7 kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86 vpb8GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6c u3wAgHoo+NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYA rkTphRUAcB7eLzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+s AAAAQF0g5AMAAHApSi+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/z Z9On77XHrvmru1fzBWPy/eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso8 8Pf82fTpe+2xa/5+Pqr5gjH5/vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJM yPfq7sy/6ZvR4Xl1d9EPljz2sA6TvsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a3 5hqXMzjpvsqra07tdiH7r2V8T11F388H82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2 eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51 f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5ENV7O5upuLhnwurjCOnDMX0cjtHdrRE30/ H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc 6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yIO7aUblbXUW6XnaDFLf0cH/NF Lq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1Ln79p/Q25YaBXr8yLmr9 ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU5cjQxpsQ8b6ImHA1 Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yRy2vu/kUY+h/a dhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5hCfmm0mNJ 9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKBM7w8 /vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6X bj/a/N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9i njz7Y7pSbZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU +lV55PrpzRr+LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it 8QlSRk2zEl12diN8denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz2 6V/CK49cvy6PWH9YQxC43RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6 UFd1w20it8YnSBk1zUp02dmN8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob 1t/1mrRx2ad/Ca88cv26PGL9YQ1B4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f 5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9Wvy KPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvbD4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwl B8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNu P9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITgCSO73fDDFUlK0sqN9/5zeE95Qj5B /0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1M03FiZF9Q57v2+iAogeSACDk AkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM7HbDD1ckKUkrN977z+E9 5Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80FSdGDi15vm+jA4oe SAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3bLAT9O0MTXOn l9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLelP7uGBef /jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1PYPRA lsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7 ZdqPNI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6 qw0/xDEh33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MU pRdWAAD4eVj+I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEF AAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0Epezit XfIFa9acdhx8O+xL6AnHJfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zB mjWnHQffDvsSesJxiaHN9wLPsd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNf R9tDbe3qH4jP8+F4owev7n69ewsV9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT /thUvk9QlfqY1QftJn1xOVe/avvY19H2UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5 vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd49ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGO dvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pvZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6 U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+TkTR5jHZV1nqanoR8opz+fvEGmsln MuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe4AQ7YXXQjoaddo9vbD9T7l6/ SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLowak3TR6pXVNKNsDkCufv lcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4DnMykiaP0a7KWk87 kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9oll8wDnGAnrA7a 0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RBTxQ9OPWm ySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto5hd/ lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiG tTEBbXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PF eoaWhT1CWBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2S vbnnhdANS06n/YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJ jdjt4iDki9IqeR3Us9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXT HX+tHisT2BfykfLkQn9/FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz 90GeF77fK5kMa2MC2wl1qxtKbhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDg iOsJjzEBRf34x0Ujjz3Q0CXt2Z8j7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNi PvcIJppm5077GSsiz6XxC44M+dz6dCHrwau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9N nhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uvXd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55 sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ffCvn8iTlySHOTqp//3gj50uTJEfJZcrr7 RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl+furhnxizGXWL99icM2L9dxBId/7 2T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdOkFQ/dRpIo3NzsYugXWDII/dL hjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiWdyV2yvXwIWVpnpYdyi2/ uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedlauzuPCwX5g6e3BH26 UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI/ZJhTiXJjbLk dPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/nY3ncM0X+ TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev3rLJ EzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO 4KF7+yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZD HmteeH+vBPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zc RkVOb7+CzKrwlvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQj eOje/or28ze0j+cz4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68essh jzUvvL9XH3H8p9grJ23XCPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/5 9ZDvdcUPWB9G1pQu8OUg5APVUnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOg EkovrFVBcoQQwgDgR/xyGgBfx2+GfAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAA AC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQ A7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI94ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC 4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5JpWz9ZWzqogRr19tt2tfIbevDOo/kFwAiG v5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yln5y8uuYjD1cZlyr19ut2ZTV+RT3s mkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p68t72SQt4xxv6Scn72f7kYer jEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F50lk+l6hIAtyGfrLyacin UKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYokwG3oJyufhnwKNert 5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdNfPM9vu8vJlxN WVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32NORzjqOS CKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/BHL5y ks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf0 4JlHRHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0 +S05l8d+/v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69 EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9 n92AVjO9ZFdMkOdPkd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJp cy9RVGH6OMq7Ip69EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye 2Lm6EeQW9cQnPpfu2osuKXWPNtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDv OGYI+UR9WuPrB3alt6ud+Xo97CI95NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lc op74xOfSXXvRJaXu0YZbY8qppjeKLim70b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+o T2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9TMVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4 pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5 +nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqu pId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+TzXCqhUlMmoXjoEgnyW3K6XFKW Lsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6symRF+uh50kh3zG/JV/P9UG lQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ8ltyulxSli7J9laC J5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyVfz/VBpUCTv2P xbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+Vc6Ut0iw E/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2kHpxo 9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3 KyL6tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1 Aj38Ngd9jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/ hHwAAAA4LE/zlMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIK AAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+L fL/7G+sHAABQO6UX1pE3+X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+ 2ff9fMQx2gcfg7r6l4MBAABkonzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYn Idn8tV9Wln0CODjrrB8AAMDvccrqObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xse nU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM +cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06yBbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbG kG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNeuvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3 y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWPe4O7XwYDAADgsuR9fQt/9co9fE3L 7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1Lbfb7dY+58ftove00MBsPUkD OFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78 nUyiDns+ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnw dzKJOuy5DnKGfLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnD DrOMy7fMU4367Nb3O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf3 81G//H9/m3p+P9s6uiHJucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQ b6S+kfHzYyFfJlm+Y55q1CfpabMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6Wmz HSHfxBkhn7n7FxGWJvlHfdP0S9oTrYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywf XtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbqQU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOt pum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV 7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F5EJtOUxDe7vdHs9haWW9YGz58XzHCXRr A8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9EVHVZ9tK4ysw1T2Xmv5kveb1k4TD 4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz 5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0fT+VYMEZa01oTCv/6u5r U6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+VuunUsYJdGGLNLMv +dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVVe/bqRyuv2bPz d3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7+Vibej8f 8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3Jzz7J 9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7X We8vDW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxq v8TCqj179aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0i q/7xfOotfKUepb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz 6F9tN888NbdVXXquy27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+ sb9mvbLLpUYiRUK+V9d0r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv2 6ietXf72mzwhn8d+ciyOaZwf8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/k S9werGGX79CQzzdP/SGfXH9tdpsr5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2E pKag8puadCT5mVx0VkKUUyvPvaA1bc2oPz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7r mnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNrkId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXn uyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn5GPPbwjOPPE1vDk+NO8sqFX0M7norIQo p1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2vN+R4P5/PZzvu8LEnfpT61xPSlwSE xE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1XZ7fmfPeEfHq/JDR79upHLa/a s/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IXARhispwiJn4sp1mentiq P3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8PhtmTOYINN3W43yG /cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wjltft2fU76R5f kfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUfvfdgW3Fy u0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJM9VE M0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUi fi0E+rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABA XSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClK L6wAAABAXVQS8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0e ll5Ybd5b37mur92hTfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/ V9cU8T2T2u0byZmRj34ppfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/ h8fN1NIL6ybvZ1vE90xqd2glZ0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTn qkev/sCBzfV7WMMvKEI+hHwjCPk+p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O 0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuSTmLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7 UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hye/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7 oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VUu6WoQeyXftxtP+l2NeWo9kvDtHT6fBln 42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23GTh85Zyyxdo5nYit5coHwdfD7UBD DpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjbPjb0M17+eL5nkdPalvSwOV5B 3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeeyfjT5VTnVbilqEPulH3fb T7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u7Pg9dNvtqWTd5aOb Bj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0sj2n9+/fvX99b LRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvtav3Sjrvt x2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ5002Bg jh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd 8afJ1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmf tpPC3bXFRyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02ra YSfiORtNn5qdkCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Q b5/8YT26/cvzxUYKTPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu /PJ/tV2L7UQm2l+v/FrIxzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQ CCf1dhPkT6rH3wOpXa1f2vEd9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGnd nt9Dr92eTZUhny/FR92wKRbyeVOU1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/k k9u15JdDvjzya+36Q75P7CfBrpQYyjtfdoR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJ DfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xorqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ 3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvocfP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43p jbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru4eNin+RCBlUHqZxUvHi8lHYt+UX9 ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb88od86b+HbrvNwhmLp+KacO9j cS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7XDdD/+J4qe1qcia1vG0n wSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7TjXvvx2hXNK/xjO7eu +eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7GM4G2XD36doCm mZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63dBmPi2wn 9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7RwfswtLC9b 7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNx ke2EXhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3ML y8tWuy2/Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAu CkI+AMAVQMgHFkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --------------0F74EA4A356EE693CBF6A911-- --------------AE5AAAC3A42D4844F4BF3B4B-- From nobody Thu Nov 2 07:54:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6413A214; Thu, 2 Nov 2017 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.406 X-Spam-Level: X-Spam-Status: No, score=0.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 btwrZUAPURh8; Thu, 2 Nov 2017 07:54:47 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6649C13F66C; Thu, 2 Nov 2017 07:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6+a9yYgNzkT/XC+/NCaIe5WXkpr5fnSvhIc98g0KthM=; b=a9yTkkNWV41hp8pVqcYXz4C/2uBMZij2obuH2hA4Tc71g0VFykvfqgRn7Dk/5TFuXcDkSdelMwViUJQom/86fxrlgF2EeUuNgZR5AOkLyehzCUBroPBqMA1R1dDlIY8/A8UJS4i5Ny2Am+hP49Ov3/DeVRpmwld7uP40YctD2ZM= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.218.6; Thu, 2 Nov 2017 14:54:44 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0197.013; Thu, 2 Nov 2017 14:54:44 +0000 From: Kent Watsen To: Benoit Claise , NETCONF CC: "sec-ads@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change Thread-Index: AQHTU+WEqWTUwuRRwk2BCItTgThGr6MA6jIA Date: Thu, 2 Nov 2017 14:54:44 +0000 Message-ID: References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> In-Reply-To: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:CRWrJOr1rP2KYbbSh23zKVbT8LwkU0A/ePqk9X3EOkyRzHccguLRst5DxNvVeE7gtzvEsGwmeA4l0JIEXhpSbKWI9Dy+UPqvGTPG1JOEiGCjHKSRnOQkAX0UVyA/pGe3mJMXC/2BYvbmsDmkk1DutnJf57uBazj83RpzSQcTy/Jm4meTop0V9fgmgiecnm5tjb6TFP7wUOBaEnkncpnFJWqxipY0gnXjvVrcIcpSS1ERf4+GgtqrGVbEkmsy0Ml5PIrwQk+jeWP/au6VYBoEeCRVPG8K4Rko+bkUEyF0o+S70pZoP0neYsDKoW1aIZMDYlL21K9fMGS81g8tdNwb9hF/i3SXu7C07QFAb0HZF5c=; 5:2P5j+Dy8qXvIMo+6n1Ez/sJDKnk1Z6VTe5q/NqNykTwfK2lMH9y7JAFrikJN4fHE158pJhHB1Zx51Sk1sNB3bDFj4dOFJrlO96+DL6i+4PCo16WOQHhEETQsgJLq7dQpkhaNmZgicDo2L1pbAetUD/1K7cTZJUYJ5yqN5ow07BE=; 24:nRnFhVW9S4Kd5Vbd36fhOcPlm0gtX8J8g8VfXFaQumEY29lAZJt+Go6eI76d2Gnc15vSMK2iTP5H1pz39VHPFhZq+19gpLu4ETqU0c3RVAU=; 7:anj7jjK9ToFFNSDi2nM2s4YANEnur6AtMPdFhmZG81DQPY+gDyLmDH7mLFv6jV1qyOZ5TBIluoLg76lnPkkDy6zzy84L4XrZ/jEwQDh9WloilWOnG1zq3nARxU6hcfEIoCaFKGXYXZGcH5n85iHPrsOv7+g2lhpy88XHX0ASZjl9dCYRwj8VknyaZImnYak2Ql/BsqYnOBQcWbMfnODkrYhzak3uQ/CJ4ANMoPSlSTJTzFYWg7E+lR3VP9PpQkCC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d12ceebe-1015-49f9-a431-08d52201a7c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238)(49563074); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(95692535739014)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231020)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(76104003)(199003)(189002)(24454002)(83506002)(110136005)(316002)(81166006)(81156014)(58126008)(8936002)(2906002)(2950100002)(8676002)(25786009)(53936002)(99286004)(6306002)(236005)(54896002)(6512007)(66066001)(54556002)(4326008)(83716003)(7736002)(5660300001)(68736007)(102836003)(6116002)(3846002)(6246003)(101416001)(36756003)(33656002)(3280700002)(2900100001)(3660700001)(189998001)(606006)(53546010)(6506006)(77096006)(6486002)(733005)(6436002)(478600001)(14454004)(76176999)(82746002)(966005)(54356999)(86362001)(50986999)(229853002)(230783001)(99936001)(106356001)(97736004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_A58B56719F3B414A8CDE20F397177074junipernet_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d12ceebe-1015-49f9-a431-08d52201a7c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 14:54:44.6488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:54:49 -0000 --_004_A58B56719F3B414A8CDE20F397177074junipernet_ Content-Type: multipart/alternative; boundary="_000_A58B56719F3B414A8CDE20F397177074junipernet_" --_000_A58B56719F3B414A8CDE20F397177074junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3Mgb2theS4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCk9uIDExLzIvMTcsIDEwOjE4 IEFNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSIgPG5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6DQoNCkRl YXIgYWxsLA0KDQpIZXJlIGlzIGEgbWFqb3IgY2hhbmdlIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1y ZmM2NTM2YmlzLCBzdWdnZXN0ZWQgYnkgdGhlIFNlY3VyaXR5IEFEIEVyaWMgUmVzY29sYSBwYXJ0 IG9mIHRoZSBJRVNHIHJldmlldywgd2hpY2ggSSB3b3VsZCBsaWtlIHRvIHZhbGlkYXRlIHdpdGgg dGhlIFdHLiBTZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDItM0Rk cmFmdC0yRGlldGYtMkRuZXRjb25mLTJEcmZjNjUzNmJpcy0yRDA4LnR4dCZkPUR3TUNhUSZjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Njl1ZjN3NDBwUXhLOUdmWUR6dS1kMVM2 V3d2LVZUb2JySUM3R1k3YXV3OCZzPUtnMTdYMWkybmZEV2dvRVl1RDR1aHEzNTk1cTNKSk01ZmRT TUFtYmFVZ3cmZT0+DQoNCltjaWQ6aW1hZ2UwMDEucG5nQDAxRDM1M0M4LkZFRkJCNjMwXQ0KVGhl IE5FVENPTkYgV0cgd2FzIGNjJ2VkIGZvciB0aGUgZW50aXJlIGRpc2N1c3Npb24uDQpXaGF0IGRv IHlvdSB0aGluaz8gSSB3aWxsIGRyYXcgdGhlIGNvbmNsdXNpb25zIGJ5IEZyaWRheSBOb3YgMTB0 aC4NCg0KTm90ZTogSWYgdGhlIFdHIGlzIGZpbmUsIHRoZSBuZXh0IHN0ZXAgaXMgdG8gYXBwcm92 ZSB0aGlzIGRvY3VtZW50Lg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0K --_000_A58B56719F3B414A8CDE20F397177074junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <55238817F374494B98E7F7B8EBA87BE3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZv bnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQt dHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNv bG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkxvb2tzIG9rYXkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50IC8vIGNvbnRyaWJ1dG9yPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExLzIv MTcsIDEwOjE4IEFNLCAmcXVvdDtOZXRjb25mIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmJjbGFp c2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPGJy Pg0KPGJyPg0KSGVyZSBpcyBhIG1ham9yIGNoYW5nZSBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZj NjUzNmJpcywgc3VnZ2VzdGVkIGJ5IHRoZSBTZWN1cml0eSBBRCBFcmljIFJlc2NvbGEgcGFydCBv ZiB0aGUgSUVTRyByZXZpZXcsIHdoaWNoIEkgd291bGQgbGlrZSB0byB2YWxpZGF0ZSB3aXRoIHRo ZSBXRy4gU2VlDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX3JmY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRp ZXRmLTJEbmV0Y29uZi0yRHJmYzY1MzZiaXMtMkQwOC50eHQmYW1wO2Q9RHdNQ2FRJmFtcDtjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpV dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT02OXVmM3c0MHBReEs5R2ZZ RHp1LWQxUzZXd3YtVlRvYnJJQzdHWTdhdXc4JmFtcDtzPUtnMTdYMWkybmZEV2dvRVl1RDR1aHEz NTk1cTNKSk01ZmRTTUFtYmFVZ3cmYW1wO2U9Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2YmlzLTA4LnR4dDwvYT48YnI+DQo8 YnI+DQo8aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjExOTAiIGhlaWdodD0iNDEyIiBpZD0iX3gwMDAw X2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFEMzUzQzguRkVGQkI2MzAiPjxicj4NClRo ZSBORVRDT05GIFdHIHdhcyBjYydlZCBmb3IgdGhlIGVudGlyZSBkaXNjdXNzaW9uLiA8YnI+DQpX aGF0IGRvIHlvdSB0aGluaz8gSSB3aWxsIGRyYXcgdGhlIGNvbmNsdXNpb25zIGJ5IEZyaWRheSBO b3YgMTB0aC48YnI+DQo8YnI+DQpOb3RlOiBJZiB0aGUgV0cgaXMgZmluZSwgdGhlIG5leHQgc3Rl cCBpcyB0byBhcHByb3ZlIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0 PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A58B56719F3B414A8CDE20F397177074junipernet_-- --_004_A58B56719F3B414A8CDE20F397177074junipernet_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=43606; creation-date="Thu, 02 Nov 2017 14:54:44 GMT"; modification-date="Thu, 02 Nov 2017 14:54:44 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC+YHG lxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL54BA95Wp YrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIgiN2ClI8gCIIg CIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU1budlnGWW9Ei1mf4 5fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluGnFMMK91+zhv/yNjzT4Gd o4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pdbo6buif+9eeWtPnXv6CR/FPY c+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJXx1+/P6TX1qbAn3/+DWvTKfuX9bC2 S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi67wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4j lgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNXud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllF nBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Ygfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvS S/v9L9HPMFFl8D5zbEGSizUDcgokCKIH5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrf X8TtVh6W9yB1MxV/iBt3fOpwlw7vXD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbf wKXq6se7Lj//Sj6DlcJB+9FIFUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60I yDIBZ0CCIHpwvuN8FzTL+Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omkn OhYrqi1hzNqj2od3bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyr z1EzN0EQxL8430WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt 4qmnrDDAnL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB +Y7zXTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUjYtyT WcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35KV73CFvr JiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX7+JJ7+0z04ZX /O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz+95YmLPx+1/yMeRf 4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV08idquf+lP/67/LhW/5k2 PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE7PAZOI49IrPfJ0V5TphipXuR ygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWRMVfPIN/X+Z9//k1OMc9Qy8DwPJQg CGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/hE8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53 d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggb pHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIRBEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQp H0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjN a2EZnE+HzC6sB2G8LZmOIAhioxiZ9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZk OoIgiJdH8fl5IxV3NnE+HcYZUFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw 81P7SxDEnpCa9NqqZxOX+jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw 81P7SxDEeyJK7IQUQ1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEq yJ0AIcWQVSRJCimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hC FmMqFlg1urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1E u5mmD0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL3CW0 ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YIWu/yWetq 1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/UNHcDNc3Zrp5a 5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeIo4gGND27y1MLZvIP uQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t8ln99duTIAhigLHKlxsi uxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl1nzKp+Ujaq04WI5YRfkC1crm E9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rrP8E3YwZKFrZvMInH3uVDHQxlDPXk 0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+WbZk+CIIgB8SYNeZRMve/lwsyUD6sDyNKb UD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPmUTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GD yXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7eC4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht 0n0cLKoF63cIZ6B86kCoJV4MtQTbn29pSiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJs QL28FwT1Rv1Afhi4+9NJTcTLV2ChS5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/S VkpCT7lSubom5cNqpuw8ws0z7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PB d/P0Ke6NCIUUa39CuSOi3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3Ps SRDEmyA97eGP8seULP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LP tyT0FMNYVceBkbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIl sPbESiyLJ6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST 9xEEsW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhi V1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAI giC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkI giCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUn VoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG3h+ZSvKYui KJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G0ZRFhxXNtdqM2lZFUVTtau0TPnC8 HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5tc2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoO p7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7 A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZxXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJW VXs7IOu11QsEyzPgUh9ze4nHa46R3CIe6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62 nqaX+mg3/dTr4hHMSfnKjo/d5vwhtJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+f pHwuZFGRuUDKNyb71Sjf+XTwrYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43P BYfEc+bhIX1bHY99vUt9FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6 hTkZi4gcoIxJ/r5KdxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebh dA4T6GBCXa/m4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjP qJ5hsH0/4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+e ccfXV9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eTq8ry NyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIgBcgOwM5j qseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCoyc3Yg+mb4O4s GQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqMnJpG051AgFBBv6gE xusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3q5PsRvuI/RbYTUoUbUXO pNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D951McnPo+4BKT5w0x 1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82v7StiIFUJKP+OPY80jwO+yt+UI+4 0fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olSQvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z 0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yLHfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFp BHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78 FtkNU75gaTX4E61wKzuM2tmCZZ/UuHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTG k+dNAYvyWaGheKR9x8jsrpcP9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fB AkNsw2smbXDqadsT6e/2E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/R Creyw6idLVj2SY27R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFw amQEojxnRP5NzPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9 mpPy9d3P6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRi RVxI/k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+uOW8I KOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnSrUTWXMqX Wtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUUegQn2iG9uptB m9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6FDqO+qs6IE5Gx1Nw UD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M6AmCbeO7RgDYb4Hd5Nu6 hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk97vNQvuSNAC+Gzo5ZKZ9OTQry nvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBfGylLFahJ+UH0Zh23+2uaLXF8XE11 AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQNqCb83Eja0uWpe70K2XlKv5BfWXomxrf/ PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOIxz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77 z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUvw+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8 IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGbxBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq7 16uQnaf0C/mVpWdifPvfcykJaBfZTVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7Y ITnuLn92jTu+voCjO+8/14Ve4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbED LLqLxPU6LdOReHOsd/8h5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/ kPK9M0TOFZf4dgaVT7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRB ELvCWhMqQRAEQWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wE QRAEsS2Q8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88d wDXub41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW38x2 fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4DkUh+3EeYm NiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tbPMbXnzDyl7pa wky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz9XdGymcJIeWbqAkp 33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+eiIWmT3b6hYgXerjNmb1 Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7Nz4XHBL0eFjcbqvjsa93qY/i r01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP6o2fLGoR1b5nb5bdL7JfsL/QPPl6 Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3v gm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidwxhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0ted YYCyOZ860qfavR8efv1MPrY6deeeT4fhj6dikdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+ dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmr qm2tcbHGEfVXtdE55O0nLD/dqWw9TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmW u1+zwvRD+z5g2WfCdQSvCyE+5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplTh r0U6PiVrUrFWQKbOIiL/bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0Zvd bmpcXMB2MPVH+vR5tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbak Qfl8/ZoZNgW1/AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8 tUjHVbImFWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3 mxoXF7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDyhWFP P+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+SH88jjn1 pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb9vSBZ07p6y6C Hkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMFrWEA64FfzwTlg3GT RfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3COMoGosroOhq4wmTK5+rX 3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNYl/KZsWIyprFDWBiZb4nyTdFz JsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxhT/N6eTApN9O9HqV83n7NDQfl03VG Vvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUbUz4zVkzGNHYICyPzLVG+KXrORPlAR72U b54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xpXi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/Z KN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq /Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3ta Erw5ucqeS1I+Z7/6mvN8LTib8iXs47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6 FpAReGEmQaWSjkZCWPUFAf1b+NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2K pT/SB1EyOI6gv1ChKZTPpWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj 1/9mue6ME2Rv+6+uwHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/t q5eN+r8fTj1z9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpL WR76wBzKz+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJ ZI1fR/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq2NHW xxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNoN4LORLQu u+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p9mZm2J3hb33R 9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa2NpX2YmpMD7q8ap4 5F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOrAVK+veCRz3duC3He4lrg Zn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4jiHUgUt5WD6FV0h+vDYJ4LtZc 5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7 wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUWvu+o0H3scW/feUT9erf+EhOwwesUYXzc z3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3/hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+d tuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPH zmx467Q1N1UD2x0+dce5JfqLtnFcY3vHNfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xS vgfwUpTvyW2S8s3fxktTvlVAyrccZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVson dpEOogG513UpQgVwfNinPRA0/KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZ rSlFc+IXdFzaKDsB0m3ntPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0Y VjPtgBP/oD3LMryOgvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8 IR9LTJ5iF+kgGpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO2 0jalZdmtrURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y 4z56XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK4E7H 1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6ZcpB/sPGHdg h8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f9egZnpEL+xGV fV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17ZtxU9RyCVU0C8GtZUM 7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k9Hf1F/t50j6efplysP+A cb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6OUD6Z+Zj9Lp/tz+77qkfP8Ixc 2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkYZOgwRodKKCRyUj7TbhHt6YSi40B/ 3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19QDuhvYtyBsnhcPJQP91deO+o6msUP8XU6 rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1FnzDv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPy MMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtDWP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ 38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1 n/JlPsY2q2V+DWAy5ZMhyDyUD9kNKjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJ lE/VnuqH6Dqd2i9DtfJ0Pp9Ot5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2 g4qMxNL5lO8RO4eyH6d80A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu5 7E/dHuXzXu+kfE7olCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6X z855fRi6oBscXeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8u P4SUb1q/YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzd fkLHjaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8c93f 4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+rqY6Ifr+ gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTLRqbdFHNH0p39 BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9cfk5KGw3lXd5Gnud L+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0dH1dTnRB9f8BS/1hVfd7W UKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+2ci0m2LuSLqzv8DPzfrufqF2 kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yhPy4/B4XtpvIu67HX+RL+7L3enXr6 7AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnzvfD8p849trQrwR7wbnZ7t/4SxASQ8vmQ mTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/ezW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Bu dnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLEr rD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARB ENsCKV8Gug928tuHxGxoygW//7o1nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Gi w1v7yRLYCeVrShgUzbaTHrc5Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqK ta7TGGtPrM9FW8GgaLad9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go 1rpOH8H+Kd+MbWwntHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hp MuSQ8j1R/lPkPBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/Hh FJyQKfdWL2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9V Lsvul7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fghEy5 t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5rXJVdb+M xaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI7eMZFy9GKJ/l Jzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18OgxCz6eDmUB1Ph3G KZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfpGYx1TtButgvlO+V8NmVh 6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJdgZ/0vyaO5FzXqD7qL7x/rned xnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9THQeilPpoJVJf6OE753HraAHKQnuh4 G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw1jlBu9kulO+Uc22rwtInZTeXfKd/ijpq SBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZR Ux8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fyoUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8 bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgoX9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8 fa3rNMZTZ8079IPeHMqn6vTxQkIOSAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIc x4Q+oBPYnp7xhXqqMY3H15YdV8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGP yxRYlM93X/Jd16g+6m/K39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+ MI4JgXZIDe35XpTPv65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+c mRrEAEk5G6J8U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM87 7nn3Ge3P81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR 45DFr6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wqp/S2 ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKHYByTuW8j IXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo2yfRwdua2Bzs 5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISNPh8SfU9AJaSZcvrD 8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuXjfp/7tjI8NS2g09OJ0O5 WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+OcUzYJzEuc1A+swPQT6D/e69r XB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBBCBt9PiT6noBKSDPl9Ifl5yugnCl6 Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZV69a9f80jHahHXxyOhnKxWLPKvK+FGLp 6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06 fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRq gFRhH+A47g/eV8AI4kWxGuVz7GxGbBgcxx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5 ykcQBEEQs2PtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3 /c3UF7JnGmL/8D10Z6dYdhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N3 3h7PW+U7n8pFI9B4J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9J L3W1aAQa7yT29P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRD IOWbV84WrebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAml jKXkntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xOhWf4 /RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9ofsfbgeP 9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMqBdXN8cLH3fZ3 jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nwDL/fIsR2TtoHyrf9 E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatwKuKC91+bRtOsiPIVOpbu TnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7ouNv+3nH5dPtJp4J+4QzY+ROP i09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzUfSY8beSo+cuI/BgvdH1tHs+fOmVm k3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQ rq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fAzlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9u OW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aC PhgysB3C6zDc7VW+/dDFvfClINTCeLu+fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om 6mnbE/ktPA76pY/l5Vlb/YL+7JQzwW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx 4GCCCiV+TIXy97+rdoI+GDKwHcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gk Gr/GfqJtrENky87xOVP1tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRF KF/msgxYDUu2YjWIDvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy 5ZPUzk35XHoie0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd 6ENAnz4YTsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBa cduundzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgXp56J ZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586VVAcJFyZ 8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6lZNDB8QIZfB4 oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQn5Hd0JosvM+EzYwc NX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2IosufLA6nk/ndCbc+BrraZSPk WblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ0MKhLA994AztbI2LW09oz6aU fqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyMXNfjuFu+vl4DS0yeKj+oFrRGZyyp d2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5aIc/KVVNMwXzfJsukoZZWu95+2fXHdSmO VXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328R sJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaCeEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKy XrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQxYAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5 IOUjJoCUjyDk9marL/F1moTfIrGPQ6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1z Ibd9COJ6vZLyEQRBEDvD2hMrQRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2 QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH 7bA+xI7aa5trY+g+XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jp xgeQWAU7oXyJzce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9 sT4Xic3HtrDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8 Mc6ng281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b5bLs flGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl01jjgvRP 43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusOuwlZ+T6y1/vY +2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5VrqruFxV7DfWrKidy NOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1rTUuSP80bmflyAF2MP0q ZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6wm5CV7yN7vY8RMeakfE2pgzsV LfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anWORoVSJpVIFB9qaVIxMP2gcdt/T+B 3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYHJ9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4Sp zBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73 iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJh zgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTLiwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a 9d12645kUr7d3scICzNSvjBc6ZdFwmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7 YLsh/cM/cJ/v4i37hxLGY0akvzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZ cRUbiXG3OpfyW9s/7fp+u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VR FF2RDec8NQf1MeWz7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj 2yIT/BNoY/+i5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583 Z6jk/YqCrA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7 x/OnzkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU0u/s 6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQWkrfEh/TM XR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12s5pP9muf97Fe 7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUzKB+sP/ygcsQS9gHH gf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA8OaXRfXH/RNqA35JXUh4 MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xdd0p84CD4YfRrFEVRHMpSB+7D b8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7APsj+QV7qKf063/3tuEHPqKp69WoM sZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5/6EsdaKsgwwA/0z4oX1/wHaD9R12S48X 6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIriWFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqL b5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fjBj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jO EHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD+/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6Q fXZit+wlPmIFPJD4txP/zMa79felseKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/K x63Gtgzvq6kS+/DPfLxbf18aK86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN 5aO9aB/2Crmt3eQlvvca23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQq H0EQBEEshrUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV 1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIg iG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI +QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaF tSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8STcD4dbk7ZlEVR HE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9H9SfIJ6ES328OWVb FUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrSqmwfnRdIT5/+CIkenE8H hnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte4s63Lywwd3YRixn4XOqjIxBq K6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTUdq0+b9X/L3WVo9Y894fr1WbDS9z5 3hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfDoktEE9udjx4tgEzKN9+yJSnfHFhuCrUf 4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZs yrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3l e85g0yskpaTG8XA6h3Y17eAdF6Bnl+VYWv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717 IczfSMrnu2/Y/iYS1O+/B5YL7p8J/yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH 7YpTqupmj0S/zIQu2dGw087+iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4 AD27LMfK8k+AHPlZdutXyNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw /0z4JzEHXmyVT1IBQUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH 1V10HKApdWSsWJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S 3Kz6hJCMVL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T 1iy1unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQXo3xW qCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT1gd0wraD 1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5gL/NQ/mIFJab QpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBMvPKUjGzT6xFH11Wb 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4VDHf/xCPVrkn5gL/N Q/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGvcyQon8m5kvoYnUB2sNrW5y1O +ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK51sGSdf3UD675pyU735QxYX+/hZm hOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTpXzWZi/LNm0r46Crfkz/2maB8vvsG9jdS vi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2vVMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOo DL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCAPl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgE Y899A/vb8Iu184xN+bB/EhaWm0LnoXzq/TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/ pVzVKNITHUftKsXFyeh4jqIy9Jb5vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgd b+T6Ndf9VKLvqHrqNiMTjD33Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9 +sN2ZRKY6m7cr9F3coxI09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx 9JQ+Gfrn2LBoSX67JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmb mmUHwz+JFBaYO/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0Bfp CY7b7eqMNxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhl k8Il9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+z3oS uwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiC IIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhYWFhcZXVuw2IW 7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GWaIGU7+nl8uNLURRV /b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp0mVBPduPpzrq6tyG5b// qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+u3iltV/F3s9rm/Qlys3+S4z4 qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTgp1/1l6eF5vXHLe6//PiyKF+C7f6q vzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodK W31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9 ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5OSfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198 iy2TFgY3X5agQKR8fj29hZTvtQop3zLliSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjc fFmCApHy+fX0FlK+vZYlWliF8tXDRqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJE Tp04iH6KQ/NYzy5b8qNTKSeG/vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4Cf ADm2PpP8QZji46P68uOiEgjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61z rxfndX3PKvxW/XGvrzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt +kP8hI6jgvQx+ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0o imN9uv1nOOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/E uKBijlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b11Zf i6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QGllJXIvZt P1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkrxiof1BONC7QD HC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jnNL8FLmGv8hWu68Vz XXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef1VBH6PbvfxwHfdDxBN+z 2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7VYXU/etq139fr9/b9nbwe3sZ 2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGBdoDjhTQ3/SQlB+jj8odL/dtgWz0W Q1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpXuK4Xz3UtfKLPmW6/tzePFFeCNOil/S7I rnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDIqT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvV FAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5dfnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZP Kkp2fVYkpnxYTzQuCTuA8UKaW36SlAP08fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjE WGJnzvVi98sud34iKVBHVP7oD96ZUjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF /bXtM0L5/tDrnOP23Drl+17p2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHl eNtN2wcXFaDnjFoYOWE90bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6Ge E/0WuMRYYmfO9WL3yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb 4bqSbxh3/x8ffcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/Klxgto DvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8Z GyTfIjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevowLkVO TMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4g/6G568f x67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6dYAmZkknV2j8K ldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KAYcZvK/VmSh/GpciJ SfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/TD9JyoGUz+EPOpo91cc+ Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQcdjuPJTPeHE28oP2q722aCVG RqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5VX34VVdffohfgvB6wPCOkFrW7eWI b2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3GWs9eY8GfbzHHEY5LhvxovKyC/ATISerj 8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7vtL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87r esjG/Naq/3c0podJwwIq1avyx7ejPGX4bImWA47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo /Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V /71GSMnxtmvaZ6z17DUW/PkWcxzhuGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVR VN/61+Sc/u+0v9dvsZ4Jv73Uv/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVV j77O9706fhOBl/39oqFdU09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4 rEP5cCi/3AYGb138+/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz 1rVyWbHtfe6XAsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ5 5avXWZZoYSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhY WFhepazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVgYWFh eZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv/ShytvOe p/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+LXK27Z6nnMQ+ 2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/HSVTw8vdv45Tv57fq 5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnwuphdzrPL3Hpuxg/bD7tf 6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyParl1rYcjLtWo2H2g/In6tk6TlD 6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdGy3qU78GyGOWbWkj55pU/V1mO8n3c IvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76d1K+efWcofR+0Y3CsFO8f1xYsstm/JCU b137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+Kojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H //jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrjfljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yo Hegpjs+fDThC+VLj8sh1MaOcX/WXm5Dbf4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrP uCjDbz2UL243sNX9z7RWWJ/OkkVRfHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3Ww swyXhpWUr22XY9lWRZc5eZfTx9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLa r1XbtyBiLHHKUDkhB5ZB/aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJu l8uxPkXXDbLb4OlV2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+r arj/gePwukD+4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t8 0fGf3wRd/GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsY Ub9D5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+4/er JeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2PCpykxVu GIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE7ddOH6incoT2 a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYLxAnOJjVytIv9EBfT D4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0fLZuifGKVIFi9iUu8UCYp X///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739Uf//Pw4mdMtTWD9plqOSgfP0q 1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZAjutiZjmh9RJ20/a//PhyfIjy5bab 8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue6HjiukD+4/arJeyfVxajfFFcI5ba7rjF IDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cROGWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTd hFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5Jt dSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUo X/0hwrJf9RcZKs1B+bzyU/Whb8xC+Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/q jx+XXz/q+lf98eMSVsvWx0/5Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v /FR91PQ8lG+ZTzvOQPl03yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq 2fr4KV/m8i8Yjhy/WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2eh Qxc0Nb2/EzgWQqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TP dV3MLMegXtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrU R38T9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4Gu611 zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtBu5dvdf2t qk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH849uxkJTpH4Ms 8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK727EVv1b1/9Q3G758 VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtVitxdHzgu81wXz5MjBgXY LbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z6RMOvewXOG7bGfmP06+ebX9f eT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plwu2PhGP58i8odFe8lGvqMGHA4SbHd sOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI3 6VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0ycc ev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8ZcoqxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4ur LLUZBgvLUwop34uU1Q3OwuIppHwsL1BI+dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQ cbfMB3JYWKaWLVO+IQ9pv5scr90+C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30W FhaW9ymkfC9SVjc4CwsLy84KKd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnP p8MrqUu8JF7vung9rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF 62H79/k1V/maEoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix 6+L1sIqB155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqT RvBi18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlDs3r9 AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvOWA5WsXef RtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjfm9VuF1F/8ZVN n1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/Vd0nepHoeF8v6KLc tjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV1fZNi5g+IaeqjPojuuZ0 SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68fYj/XwroGkHwsx+//c6Ebi7sL DZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ7Onyw6T/GP6J9fTYH9oN62/dGpPd s+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+zYhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8 y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9UpkvOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos 5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7 Qf21T46uVKP7/FP9donJUwRPl/ooI9IhernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9Vo lU/GouFZNvXC9Q1N21YEfbnrREa7WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQnd wPgqsZCD2nX6+QRcTMLUVpqgxY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/45 03UH7Qb11z45ulKN7vPP99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDI bsqRdeL6MfQC0QOUD8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+t u1Itf9xH9G/K4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67 yOwpVy5AUKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmW scQXS8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9eF3O/ QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9/VWp0d5G lVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX679EQq12wg5Qtj rYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9LftPtU9/Qt4q34Yo 39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2G7k/dJVci+iywa284jcn 5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvjit0tsymfp+WzKp1/mmU75EnJs O9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5qN+nnzf01LfR7FuxR1A6l6zjGHesv kkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylfUv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0 Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19VthS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O 0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8 qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W 9x8+zbeHwu9dqDQm+dMgCR1P9CDmGfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/ha R1mCxLPeEgk5GZqWp552p/prvWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb 15H6ZIgaX1G7e3WsZ2dNKe8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9Pzuw wNypM3WC7Kwbhs9+3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1V H0J+VaGqRkNQqD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4 fy/qkdBaCQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6 S9ltRH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CLbCk5 DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspHEARB7Apr T6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASxK6w9sRIEQRDE tkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ7UJswg2+KrilXQXF TtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb2lVQ7LS9uE7vYYdxf7Dq v/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6mPzBYjouP5nPbquSrnexw5g/ gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptWvYqeTrTVLVy91EeTP1hMx+Un89lt VdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTlLbI/nw7WSsXjyYzz2W3NxMq3scOIPzxP o+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZcT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsE CyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQOE7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10E BvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ/s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv 4bhlGMC/kR2S/oAQMx6c8GnYOXkfgE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+U FsQuvUOwIBI177+rPwbIU6q2T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9 z6suAoP9Rfqb45LSE9lhXMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1N f0iMl3DcKgzg38gOSX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QU e2ZhXsrXNILoSSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn 00GHv1H4rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i 9a03ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9MfjAvUE cqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa5ErdT0I7 u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/KWBdwdpf14NQ cla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T6hh6DiqF5yfsBgfT pDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/YjJTPvA/g++TGKJ96EPsI 5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hckJ5IDlYGyYf1ZTjbjy9o96ak eB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4rewwCfmUD9vZQ1GS16/D/vdqppEG3TMe nISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXobyoRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9O t5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKB LVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5 Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MUCxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXL QTkroFBBTeYHIMx+pfS3EEXpKgSOzwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3m ojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XP PVHGkBFC972E8JdwBwadzlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwu UE/X+khKvg0QwsJ2L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/ Xfa/VUN3l7Yafx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y 6/+QcsSxIP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaH JdmHlnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgWpH8l vm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1oKcc+GfhJ Sk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJfURTHuja/N+W5 n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB7fDeePDzR7sDKR9B EMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAIglgJKt9z3g/dvDZI+QiC IIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu87c7XwDlrP3fiUeTZufuYIQeEIPaB Z0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFumHOVrylXi5ntzaZm3YLqfDrM2r2sHZFf ZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18QmsMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URr w3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFiIOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8 y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5gXvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzO YaIfSvwT3dItoP4Ox8tmjIok+gX0zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz 3IdhTJjgcGp6aZFBwfDm+sOtUlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXd IWT83B/MS54TuwYP1UWi5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLo F9A/T1hVddQG9hfpb45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ul qgqvr6T+Y5YIO2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a 5Rv0EUo0pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hP HJcQ0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQizf7K DLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXNYBiBYMlY hEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq+oH9I5TPqh/W VcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9wgFJ1Z+jv6hdJP9T D8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvDcOoefwVrYcX4R1X0A/tH KJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenpG/ep4zLSo97OY/qEA5KqP0d/ UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+cnzz/ZPYGJ75Ll9P+XyJTipSVRHd FilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy 7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRFDHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7 zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOiyekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs 4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+Pe16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgO YbMKp+w1MHHSEjuFflnyS/DogKXRiVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmd LBUxriYcR4892KGXNB8VNPtU7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y 87TNmxDcETeO+27cWfOFfDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHre kEdI7FTLZ+mv1q5ePx/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE 94rwzKqUZ8/mok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+H k5Y+SC/Y6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+G qGK7kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86vpb8 GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6cu3wAgHoo +NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYArkTphRUAcB7e LzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHAp Si+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/zZ9On77XHrvmru1fzBWPy /eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso88Pf82fTpe+2xa/5+Pqr5gjH5 /vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJMyPfq7sy/6ZvR4Xl1d9EPljz2sA6T vsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a35hqXMzjpvsqra07tdiH7r2V8T11F388H 82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf 5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5EN V7O5upuLhnwurjCOnDMX0cjtHdrRE30/H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy 4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yI O7aUblbXUW6XnaDFLf0cH/NFLq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1 Ln79p/Q25YaBXr8yLmr9ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU 5cjQxpsQ8b6ImHA1Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yR y2vu/kUY+h/adhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5h Cfmm0mNJ9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKB M7w8/vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6Xbj/a /N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9injz7Y7pS bZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU+lV55PrpzRr+ LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it8QlSRk2zEl12diN8 denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz26V/CK49cvy6PWH9YQxC4 3RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6UFd1w20it8YnSBk1zUp02dmN 8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob1t/1mrRx2ad/Ca88cv26PGL9YQ1B 4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f5QB87rIbQYvDZWf31UmzuuucEiwlB8Zf vcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvb D4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI 9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITg CSO73fDDFUlK0sqN9/5zeE95Qj5B/0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1 M03FiZF9Q57v2+iAogeSACDkAkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM 7HbDD1ckKUkrN977z+E95Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80 FSdGDi15vm+jA4oeSAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3 bLAT9O0MTXOnl9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLe lP7uGBef/jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1P YPRAlsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7ZdqP NI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6qw0/xDEh 33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MUpRdWAAD4eVj+ I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtR emEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0EpezitXfIFa9acdhx8O+xL6AnH Jfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zBmjWnHQffDvsSesJxiaHN9wLP sd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNfR9tDbe3qH4jP8+F4owev7n69ewsV 9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT/thUvk9QlfqY1QftJn1xOVe/avvY19H2 UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd4 9ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGOdvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pv ZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+T kTR5jHZV1nqanoR8opz+fvEGmslnMuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe 4AQ7YXXQjoaddo9vbD9T7l6/SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLo wak3TR6pXVNKNsDkCufvlcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4 DnMykiaP0a7KWk87kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9ol l8wDnGAnrA7a0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RB TxQ9OPWmySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto 5hd/lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiGtTEB bXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PFeoaWhT1C WBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2SvbnnhdANS06n /YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJjdjt4iDki9IqeR3U s9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXTHX+tHisT2BfykfLkQn9/ FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz90GeF77fK5kMa2MC2wl1qxtK bhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDgiOsJjzEBRf34x0Ujjz3Q0CXt2Z8j 7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNiPvcIJppm5077GSsiz6XxC44M+dz6dCHr wau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9NnhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uv Xd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ff Cvn8iTlySHOTqp//3gj50uTJEfJZcrr7RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl +furhnxizGXWL99icM2L9dxBId/72T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdO kFQ/dRpIo3NzsYugXWDII/dLhjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiW dyV2yvXwIWVpnpYdyi2/uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedla uzuPCwX5g6e3BH26UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI /ZJhTiXJjbLkdPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/n Y3ncM0X+TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev 3rLJEzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO4KF7 +yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZDHmteeH+v BPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zcRkVOb7+CzKrw lvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQjeOje/or28ze0j+cz 4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68esshjzUvvL9XH3H8p9grJ23X CPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/59ZDvdcUPWB9G1pQu8OUg5APV UnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOgEkovrFVBcoQQwgDgR/xyGgBfx2+G fAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAA qIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQA7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI9 4ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5Jp Wz9ZWzqogRr19tt2tfIbevDOo/kFwAiGv5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yl n5y8uuYjD1cZlyr19ut2ZTV+RT3smkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p 68t72SQt4xxv6Scn72f7kYerjEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F5 0lk+l6hIAtyGfrLyacinUKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYok wG3oJyufhnwKNert5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdN fPM9vu8vJlxNWVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32 NORzjqOSCKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/B HL5yks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf04JlH RHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0+S05l8d+ /v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69EkWfxvjuAHa1 HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9n92AVjO9ZFdMkOdP kd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJpcy9RVGH6OMq7Ip69EkWf xvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye2Lm6EeQW9cQnPpfu2osuKXWP NtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDvOGYI+UR9WuPrB3alt6ud+Xo97CI9 5NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lcop74xOfSXXvRJaXu0YZbY8qppjeKLim7 0b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+oT2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9T MVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6ja hPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+cku X5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+Tz XCqhUlMmoXjoEgnyW3K6XFKWLsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6sym RF+uh50kh3zG/JV/P9UGlQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ 8ltyulxSli7J9laCJ5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyV fz/VBpUCTv2PxbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+ Vc6Ut0iwE/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2k Hpxo9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3KyL6 tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1Aj38Ngd9 jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/hHwAAAA4LE/z lMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei 9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+LfL/7G+sHAABQO6UX1pE3 +X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+2ff9fMQx2gcfg7r6l4MBAABk onzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYnIdn8tV9Wln0CODjrrB8AAMDvccrq ObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xsenU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4 Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM+cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06y Bbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbGkG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNe uvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWP e4O7XwYDAADgsuR9fQt/9co9fE3L7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1 Lbfb7dY+58ftove00MBsPUkDOFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78nUyiDns+ ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnwdzKJOuy5DnKG fLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnDDrOMy7fMU4367Nb3 O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf381G//H9/m3p+P9s6uiHJ ucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQb6S+kfHzYyFfJlm+Y55q1Cfp abMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6WmzHSHfxBkhn7n7FxGWJvlHfdP0S9oT rYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywfXtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbq QU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOtpum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89 T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F 5EJtOUxDe7vdHs9haWW9YGz58XzHCXRrA8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9 EVHVZ9tK4ysw1T2Xmv5kveb1k4TD4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG 1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0 fT+VYMEZa01oTCv/6u5rU6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+ VuunUsYJdGGLNLMv+dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVV e/bqRyuv2bPzd3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7 +Vibej8f8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3J zz7J9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7XWe8v DW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxqv8TCqj17 9aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0iq/7xfOotfKUe pb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz6F9tN888NbdVXXqu y27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+sb9mvbLLpUYiRUK+V9d0 r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv26ietXf72mzwhn8d+ciyOaZwf 8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/kS9werGGX79CQzzdP/SGfXH9tdpsr 5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2EpKag8puadCT5mVx0VkKUUyvPvaA1bc2o Pz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7rmnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNr kId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXnuyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn 5GPPbwjOPPE1vDk+NO8sqFX0M7norIQop1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2v N+R4P5/PZzvu8LEnfpT61xPSlwSExE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1X Z7fmfPeEfHq/JDR79upHLa/as/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IX ARhispwiJn4sp1mentiqP3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8 PhtmTOYINN3W43yG/cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wj ltft2fU76R5fkfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUf vfdgW3Fyu0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJ M9VEM0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUifi0E +rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABAXSDkAwAA cClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXVQS 8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0ell5Ybd5b37mur92h Tfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/V9cU8T2T2u0byZmRj34p pfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/h8fN1NIL6ybvZ1vE90xqd2gl Z0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTnqkev/sCBzfV7WMMvKEI+hHwjCPk+ p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuST mLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hy e/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VU u6WoQeyXftxtP+l2NeWo9kvDtHT6fBln42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23 GTh85Zyyxdo5nYit5coHwdfD7UBDDpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjb Pjb0M17+eL5nkdPalvSwOV5B3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeey fjT5VTnVbilqEPulH3fbT7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u 7Pg9dNvtqWTd5aObBj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0s j2n9+/fvX99bLRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvt av3Sjrvtx2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ50 02Bgjh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd8afJ 1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmftpPC3bXF RyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02raYSfiORtNn5qd kCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Qb5/8YT26/cvzxUYK TPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu/PJ/tV2L7UQm2l+v/FrI xzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQCCf1dhPkT6rH3wOpXa1f2vEd 9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGndnt9Dr92eTZUhny/FR92wKRbyeVOU 1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/kk9u15JdDvjzya+36Q75P7CfBrpQYyjtf doR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJDfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xo rqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvoc fP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43pjbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru 4eNin+RCBlUHqZxUvHi8lHYt+UX9ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb8 8od86b+HbrvNwhmLp+KacO9jcS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7 XDdD/+J4qe1qcia1vG0nwSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7Tj Xvvx2hXNK/xjO7eu+eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7G M4G2XD36doCmmZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63 dBmPi2wn9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7Rwfswt LC9b7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNxke2E XhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3MLy8tWuy2/ Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAuCkI+AMAVQMgH FkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC AA== --_004_A58B56719F3B414A8CDE20F397177074junipernet_-- From nobody Thu Nov 2 09:54:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD313F58F for ; Thu, 2 Nov 2017 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYmuJFMj5aVJ for ; Thu, 2 Nov 2017 09:54:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C45213F550 for ; Thu, 2 Nov 2017 09:54:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRX36891; Thu, 02 Nov 2017 16:54:11 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 16:54:10 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 09:53:56 -0700 From: Igor Bryskin To: Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAA= Date: Thu, 2 Nov 2017 16:53:55 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@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.155.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59FB4DB4.010B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 391c2aaf4a7339387475bd207c66fbec Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:54:17 -0000 Hi Tianran, Thanks for your comments. Please, note that we see smart filters as a significant step from current p= ush machinery in evolution of network control automation, because it empowe= rs the client to instruct the network to identify and focus on "outliers", = rather than on routine changes in the network State. I agree, this will imp= ose more complexity on the network, but the benefits are obvious. For examp= le, instead of receiving tons of largely useless information, 99% of which = to be discarded after the processing, the client will be able to receive on= ly "interesting" information WRT actionable events. The network control aut= omation framework intends to make one step further in this evolution. We ar= e basically asking "Why sending notifications is the only action that could= be triggered by model defined events and/or push subscriptions and/or smar= t filters"? Why, for example, pre-defined network re-configurations could n= ot be triggered by smart filters? Why it is not possible for the client to = pre-configure desired actions ahead of time?" =20 Think about a battleship that just has been torpedoed. The crew members are= not expected to just identify holes/leaks in the ship's bottom, report the= "telemetry" to the captain and wait for instructions on what to do next, r= ight? Each crew member not only knows his/her pre-defined actions, (s)he is= meticulously trained on a daily basis on how to carry out them in the most= efficient way. This is how ships survive problems like that. Also this is = how the same authority can control big and multiple ships. Cheers, Igor =20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Wednesday, November 01, 2017 11:31 PM To: Xufeng Liu; netconf@ietf.org Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automati= on Problem Statement Hi Xufeng, On the smart filters (also relates to https://tools.ietf.org/html/draft-cle= mm-netconf-push-smart-filters-ps-00), I think we need criteria to carefully= select "conditions". While there are many benefit, say save the bandwidth = and relief the collector, it will add computation burden to network devices= . Network devices are not good at this as servers. So maybe: 1. should not too complex to implement. 2. must help to mitigate the export volume. If so, for example, the average value should be out of scope, IMHO. Best, Tianran > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, November 02, 2017 3:31 AM > To: netconf@ietf.org > Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation > Problem Statement=20 >=20 > Dear WG, >=20 > The Yang-push Dezign Team has been working on the Yang push enhancement. > We have posted a draft on the problem statement to extend Yang push to a > more generalized network control automation framework. >=20 > The following is the summary of this topic. Any comments, thoughts, and > suggestions are appreciated. >=20 > Thanks, > - Xufeng >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > YANG PUSH Based Generalized Network Control Automation > draft-bryskin-netconf-automation-framework-00 >=20 > Evolution of YANG Based Network Automation > * "Custom Subscription to Event Notifications" model : > - allows for a client to subscribe to unsolicited event notifications > defined by supported YANG models; >=20 > * "Subscribing to YANG datastore push updates" model: > - allows for a client to define subscribable events and contents of even= t > notifications as target-trigger-notify triplets >=20 > * "Smart filters for Push Updates" model: > - allows for a client to filter event triggers and notifications on push > object values and their change history, focuses on "outliers" >=20 > Objectives of YANG PUSH Based Generalized Network Control Automation > 1) To generalize target-trigger-notify concept into event-condition-actio= n > concept, where: >=20 > event - a particular change in the network state explicitly defined by > one of the YANG models supported by the network or implicitly defined by > the client, which is constantly monitored by the network; >=20 > condition - a logical expression that is evaluated only once after the > associated event is detected; >=20 > action - an operation to be carried out by the network when the associat= ed > event is detected and the associated condition is met >=20 > 2) To provide for a client a capability to configure the > event-condition-action triplets as policy rules ahead of time or/and duri= ng > network operations >=20 > Generalized Action > * Send notification > * Perform immediate network reconfiguration (e.g. modify one or more > attributes of one or more CONFIG=3DTRUE data store nodes); > * Schedule one time or periodic reconfiguration in the future; > * Call RPC defined by one of the YANG models supported by the network ( e= .g. > call network's path computer to evaluate whether an alternative/more opti= mal > path is available for a given connection) > * Link/unlink data store dynamic sub-trees; > * Etc. >=20 > Relationship with Policy Framework > * The framework should work autonomously >=20 > * The framework should fit well within a higher level policy framework, > with the latter possibly providing a greater level of automation: > - multiple micro-conditions could be combined into a single > macro-condition via a number of logical operations; > - multiple micro-actions could be combined into a single transaction wi= th > a possibility of specifying policies with respect to handling > errors/exceptions of each of the transaction components >=20 > Framework Benefits > * lower latency, faster responsiveness of the network to various > events/conditions; > * better scale (e.g. the client may control more networks because it does > not have to monitor/micro-manage any of them); > * CPU and bandwidth savings due to the reduced amount of communication be= tween > the client and the network > * The client can take itself out of the network control loop, change its > role from being network's "micro-manager" to being network's "police > officer", who interferes into network operations only in > exceptional/unpredicted situations >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 2 10:15:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB91213F550 for ; Thu, 2 Nov 2017 10:14:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 QVzDEhaYKn6u for ; Thu, 2 Nov 2017 10:14:56 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 47E1A13F503 for ; Thu, 2 Nov 2017 10:14:56 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id a132so268496lfa.7 for ; Thu, 02 Nov 2017 10:14:56 -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=1cL4MxhA6zjGAUCB11IQ6bUeBQhE8j3UwVeGdi4IZL0=; b=D4l+sB9O9+6JUsNIAQXAJiXUAYKc+/2wuXjIdtWVC+3xwaad378tfim+tOsmdWlhyS jJ6y/QB/YuAtqWojZ7lYSdUdUjfcpLrHrgoClLoLw6uVSQUHyQJlva1P0X4eR99vXKrY rhPfJPrcn+op85/XhbRTc0yYdLepSMVQPn84pFYoOl8qQ2H+CRnH++noo8PNocS/8ryc J0CMS1S7a5EJUP/NDB2YQJPMe78K1l2ZMT1G9PGmuOydH8PyqDhmjz9uidvYEaycbMF1 rmhZFEp6FdVfdRbXr52+w1MOfhPcerTN1RJCD8WrstP0CovmKnTlOhvQKwtoElDn1/5u Vi7g== 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=1cL4MxhA6zjGAUCB11IQ6bUeBQhE8j3UwVeGdi4IZL0=; b=TP0aJWwyWLYZ0oeOyIu3XdcZGhvuOfPOhIaIJTsCUrWaGUE7hSRBSoNW5T2RNdFIRP vfgUYhaIrpC5CGrjkU3i8mvAHhcHDk2wh/8cBDcNeb1adGof7tiFoggAd30zT2r/LQ47 6Y4M+RBRkiwm70oSL16sSE6tm/OyGmK/uKAIVXZ30ApajO7RpmnpJpu0scerM+ex2KJo VI+F/gg/24oRyUuo2iJrmfiYGhv30dX/sCPutY+f1apoaZMEdM0FPSdJ/1+QUgxZzUV3 yyOMK7zQyiW+ec4GWWRnHUHElCJZ5xEYsWzDaJX5UzJrzN0piJyHL0VPRsJM1nHAzxVZ SwaA== X-Gm-Message-State: AMCzsaWMquXWQN9fuxqNGwZ1lcMi9vPvmjzZIw9a+Ie51MGHtcflxnE+ FLJfSOGcK3FqwM3cufzLOcEt3z/6XfTgriyy4Rrwwg== X-Google-Smtp-Source: ABhQp+Sp5u9oRslK59+PrOx6nPzUv+GcKOGE/i9D6gJEx6BA+vju4Y74BYmn21ej2vD+npEuS0CW+K1fcAGpQSdkfGA= X-Received: by 10.25.23.165 with SMTP id 37mr1542962lfx.202.1509642894401; Thu, 02 Nov 2017 10:14:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 10:14:53 -0700 (PDT) In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Thu, 2 Nov 2017 10:14:53 -0700 Message-ID: To: Igor Bryskin Cc: Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="001a11401a047578f4055d032023" Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:15:00 -0000 --001a11401a047578f4055d032023 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017 at 9:53 AM, Igor Bryskin wrote: > Hi Tianran, > > Thanks for your comments. > > Please, note that we see smart filters as a significant step from current > push machinery in evolution of network control automation, because it > empowers the client to instruct the network to identify and focus on > "outliers", rather than on routine changes in the network State. I agree, > this will impose more complexity on the network, but the benefits are > obvious. For example, instead of receiving tons of largely useless > information, 99% of which to be discarded after the processing, the client > will be able to receive only "interesting" information WRT actionable > events. The network control automation framework intends to make one step > further in this evolution. We are basically asking "Why sending > notifications is the only action that could be triggered by model defined > events and/or push subscriptions and/or smart filters"? Why, for example, > pre-defined network re-configurations could not be triggered by smart > filters? Why it is not possible for the client to pre-configure desired a > ctions ahead of time?" > > Think about a battleship that just has been torpedoed. The crew members > are not expected to just identify holes/leaks in the ship's bottom, report > the "telemetry" to the captain and wait for instructions on what to do > next, right? Each crew member not only knows his/her pre-defined actions, > (s)he is meticulously trained on a daily basis on how to carry out them in > the most efficient way. This is how ships survive problems like that. Also > this is how the same authority can control big and multiple ships. > > This issue has come up in the IETF many times. The general problem is how to execute application business logic on the server in order to eliminate a relatively lengthy control loop. We have a Script MIB (RFC 3165) that was never useful because there was no standard script execution environment. There was a tightly controlled environment called the Policy Based Management MIB (RFC 4011) that nobody implemented (for various reasons). IMO YANG XPath does a good job of providing all the components required to evaluate a boolean expression, which is important but insufficient. A full-blown script engine with various library functions might be over-kill or it might be the only real-world solution path. Cheers, > Igor > > Andy > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Wednesday, November 01, 2017 11:31 PM > To: Xufeng Liu; netconf@ietf.org > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > Automation Problem Statement > > Hi Xufeng, > > On the smart filters (also relates to https://tools.ietf.org/html/ > draft-clemm-netconf-push-smart-filters-ps-00), I think we need criteria > to carefully select "conditions". While there are many benefit, say save > the bandwidth and relief the collector, it will add computation burden to > network devices. Network devices are not good at this as servers. > So maybe: > 1. should not too complex to implement. > 2. must help to mitigate the export volume. > > If so, for example, the average value should be out of scope, IMHO. > > Best, > Tianran > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng Liu > > Sent: Thursday, November 02, 2017 3:31 AM > > To: netconf@ietf.org > > Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation > > Problem Statement > > > > Dear WG, > > > > The Yang-push Dezign Team has been working on the Yang push enhancement. > > We have posted a draft on the problem statement to extend Yang push to a > > more generalized network control automation framework. > > > > The following is the summary of this topic. Any comments, thoughts, and > > suggestions are appreciated. > > > > Thanks, > > - Xufeng > > > > ================ > > YANG PUSH Based Generalized Network Control Automation > > draft-bryskin-netconf-automation-framework-00 > > > > Evolution of YANG Based Network Automation > > * "Custom Subscription to Event Notifications" model : > > - allows for a client to subscribe to unsolicited event > notifications > > defined by supported YANG models; > > > > * "Subscribing to YANG datastore push updates" model: > > - allows for a client to define subscribable events and contents > of event > > notifications as target-trigger-notify triplets > > > > * "Smart filters for Push Updates" model: > > - allows for a client to filter event triggers and notifications > on push > > object values and their change history, focuses on "outliers" > > > > Objectives of YANG PUSH Based Generalized Network Control Automation > > 1) To generalize target-trigger-notify concept into > event-condition-action > > concept, where: > > > > event - a particular change in the network state explicitly > defined by > > one of the YANG models supported by the network or implicitly defined by > > the client, which is constantly monitored by the network; > > > > condition - a logical expression that is evaluated only once after > the > > associated event is detected; > > > > action - an operation to be carried out by the network when the > associated > > event is detected and the associated condition is met > > > > 2) To provide for a client a capability to configure the > > event-condition-action triplets as policy rules ahead of time or/and > during > > network operations > > > > Generalized Action > > * Send notification > > * Perform immediate network reconfiguration (e.g. modify one or more > > attributes of one or more CONFIG=TRUE data store nodes); > > * Schedule one time or periodic reconfiguration in the future; > > * Call RPC defined by one of the YANG models supported by the network ( > e.g. > > call network's path computer to evaluate whether an alternative/more > optimal > > path is available for a given connection) > > * Link/unlink data store dynamic sub-trees; > > * Etc. > > > > Relationship with Policy Framework > > * The framework should work autonomously > > > > * The framework should fit well within a higher level policy framework, > > with the latter possibly providing a greater level of automation: > > - multiple micro-conditions could be combined into a single > > macro-condition via a number of logical operations; > > - multiple micro-actions could be combined into a single transaction > with > > a possibility of specifying policies with respect to handling > > errors/exceptions of each of the transaction components > > > > Framework Benefits > > * lower latency, faster responsiveness of the network to various > > events/conditions; > > * better scale (e.g. the client may control more networks because it does > > not have to monitor/micro-manage any of them); > > * CPU and bandwidth savings due to the reduced amount of communication > between > > the client and the network > > * The client can take itself out of the network control loop, change its > > role from being network's "micro-manager" to being network's "police > > officer", who interferes into network operations only in > > exceptional/unpredicted situations > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11401a047578f4055d032023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 2, 2017 at 9:53 AM, Igor Bryskin <Igor.Bryskin@huawe= i.com> wrote:
Hi Tianran,
Thanks for your comments.

Please, note that we see smart filters as a significant step from current p= ush machinery in evolution of network control automation, because it empowe= rs the client to instruct the network to identify and focus on "outlie= rs", rather than on routine changes in the network State. I agree, thi= s will impose more complexity on the network, but the benefits are obvious.= For example, instead of receiving tons of largely useless information, 99%= of which to be discarded after the processing, the client will be able to = receive only "interesting" information WRT actionable events. The= network control automation framework intends to make one step further in t= his evolution. We are basically asking "Why sending notifications is t= he only action that could be triggered by model defined events and/or push = subscriptions and/or smart filters"? Why, for example, pre-defined net= work re-configurations could not be triggered by smart filters? Why it is n= ot possible for the client to pre-configure desired a
=C2=A0ctions ahead of time?"

Think about a battleship that just has been torpedoed. The crew members are= not expected to just identify holes/leaks in the ship's bottom, report= the "telemetry" to the captain and wait for instructions on what= to do next, right? Each crew member not only knows his/her pre-defined act= ions, (s)he is meticulously trained on a daily basis on how to carry out th= em in the most efficient way. This is how ships survive problems like that.= Also this is how the same authority can control big and multiple ships.


This issue has come up = in the IETF many times.
The general problem is how to execute app= lication business logic on the server
in order to eliminate a rel= atively lengthy control loop.

We have a Script MIB= (RFC 3165) that was never useful because there was no
standard s= cript execution environment.

There was a tightly c= ontrolled environment called the Policy Based Management MIB (RFC 4011)
that nobody implemented (for various reasons).

<= div>IMO YANG XPath does a good job of providing all the components required= to
evaluate a boolean expression, which is important but insuffi= cient.
A full-blown script engine with various library functions = might be over-kill
or it might be the only real-world solution pa= th.


Cheers,
Igor



Andy
=C2=A0

-----Original Message-----
From: Netconf [mailto:netconf-b= ounces@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, November 01, 2017 11:31 PM
To: Xufeng Liu; netconf@ietf.org Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automati= on Problem Statement

Hi Xufeng,

On the smart filters (also relates to https://tools.ietf.org/html/draft-clemm-netconf-push-= smart-filters-ps-00), I think we need criteria to carefully select &quo= t;conditions". While there are many benefit, say save the bandwidth an= d relief the collector, it will add computation burden to network devices. = Network devices are not good at this as servers.
So maybe:
1. should not too complex to implement.
2. must help to mitigate the export volume.

If so, for example, the average value should be out of scope, IMHO.

Best,
Tianran

> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, November 02, 2017 3:31 AM
> To: netconf@ietf.org
> Subject: [Netconf] YANG PUSH Based Generalized Network Control Automat= ion
> Problem Statement
>
> Dear WG,
>
> The Yang-push Dezign Team has been working on the Yang push enhancemen= t.
> We have posted a draft on the problem statement to extend Yang push to= a
> more generalized network control automation framework.
>
> The following is the summary of this topic. Any comments, thoughts, an= d
> suggestions are appreciated.
>
> Thanks,
> - Xufeng
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> YANG PUSH Based Generalized Network Control Automation
> draft-bryskin-netconf-automation-framework-00
>
> Evolution of YANG Based Network Automation
> * "Custom Subscription to Event Notifications" model :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- allows for a client to subscribe to unsoli= cited event notifications
> defined by supported YANG models;
>
> * "Subscribing to YANG datastore push updates" model:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- allows for a client to define subscribable= events and contents of event
> notifications as target-trigger-notify triplets
>
> * "Smart filters for Push Updates" model:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- allows for a client to filter event trigge= rs and notifications on push
> object values and their change history, focuses on "outliers"= ;
>
> Objectives of=C2=A0 YANG PUSH Based Generalized Network Control Automa= tion
> 1) To generalize target-trigger-notify concept into event-condition-ac= tion
> concept, where:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0event - a particular change in the network s= tate explicitly defined by
> one of the YANG models supported by the network or implicitly defined = by
> the client, which is constantly monitored by the network;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0condition - a logical expression that is eva= luated only once after the
> associated event is detected;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0action - an operation to be carried out by t= he network when the associated
> event is detected and the associated condition is met
>
> 2) To provide for a client a capability to configure the
> event-condition-action triplets as policy rules ahead of time or/and d= uring
> network operations
>
> Generalized Action
> * Send notification
> * Perform immediate network reconfiguration (e.g. modify one or more > attributes of one or more CONFIG=3DTRUE data store nodes);
> * Schedule one time or periodic reconfiguration in the future;
> * Call RPC defined by one of the YANG models supported by the network = ( e.g.
> call network's path computer to evaluate whether an alternative/mo= re optimal
> path is available for a given connection)
> * Link/unlink data store dynamic sub-trees;
> * Etc.
>
> Relationship with Policy Framework
> * The framework should work autonomously
>
> * The framework should fit well within a higher level policy framework= ,
> with the latter possibly providing a greater level of automation:
>=C2=A0 =C2=A0- multiple micro-conditions could be combined into a singl= e
> macro-condition via a number of logical operations;
>=C2=A0 =C2=A0- multiple micro-actions could be combined into a single t= ransaction with
> a possibility of specifying policies with respect to handling
> errors/exceptions of each of the transaction components
>
> Framework Benefits
> * lower latency, faster responsiveness of the network to various
> events/conditions;
> * better scale (e.g. the client may control more networks because it d= oes
> not have to monitor/micro-manage any of them);
> * CPU and bandwidth savings due to the reduced amount of communication= between
> the client and the network
> * The client can take itself out of the network control loop,=C2=A0 ch= ange its
> role from being network's "micro-manager" to being netwo= rk's "police
> officer", who interferes into network operations only in
> exceptional/unpredicted situations
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a11401a047578f4055d032023-- From nobody Thu Nov 2 10:39:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BE513F69F for ; Thu, 2 Nov 2017 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpKgRIAmkjsh for ; Thu, 2 Nov 2017 10:39:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6067213F474 for ; Thu, 2 Nov 2017 10:39:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRX41133; Thu, 02 Nov 2017 17:39:06 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 17:39:05 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 10:38:49 -0700 From: Igor Bryskin To: Andy Bierman CC: Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAEhTFgAAOPl/w Date: Thu, 2 Nov 2017 17:38:49 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C19345B@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@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.47.155.217] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD00786391C19345Bsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59FB583B.0040, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3baf5dab68cc22605088df5df1b66727 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:39:13 -0000 --_000_0C72C38E7EBC34499E8A9E7DD00786391C19345Bsjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KV2UgYXNzdW1lIHRoYXQgYSBuZXR3b3JrIGNvdWxkIGJlIGNvbnRyb2xsZWQg dmlhIGEgc2V0IG9mIFlBTkcgZGF0YSBzdG9yZXMuIFRoaXMgaXMgYSBwb3dlcmZ1bCBlbnZpcm9u bWVudHMgdGhhdCB3ZSBuZXZlciBoYWQgaW4gdGhlIHBhc3QuIFRoZSBZQU5HIG1vZGVsIHdlIGhh dmUgaW4gbWluZCB3aWxsIGFsbG93IGZvciBjb25maWd1cmluZyBzY3JpcHRzIHlvdSBtZW50aW9u ZWQgYXMgc2V0cyBvZiBldmVudC1jb25kaXRpb24tYWN0aW9uIChFQ0EpIHRyaXBsZXRzLiBTbWFy dCBmaWx0ZXJzIHdpbGwgdGFrZSBjYXJlIG9mIGV2ZW50LWNvbmRpdGlvbiBwYXJ0LiBXZSB3aWxs IGZvY3VzIG9uIFlBTkcgYmFzZWQgYWN0aW9uIGdlbmVyYWxpemF0aW9uLg0KDQpJZ29yDQoNCkZy b206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAxOjE1IFBNDQpUbzogSWdvciBCcnlza2luDQpDYzogVGlh bnJhbiBaaG91OyBYdWZlbmcgTGl1OyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW05l dGNvbmZdIFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21h dGlvbiBQcm9ibGVtIFN0YXRlbWVudA0KDQoNCg0KT24gVGh1LCBOb3YgMiwgMjAxNyBhdCA5OjUz IEFNLCBJZ29yIEJyeXNraW4gPElnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPG1haWx0bzpJZ29yLkJy eXNraW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgVGlhbnJhbiwNCg0KVGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzLg0KDQpQbGVhc2UsIG5vdGUgdGhhdCB3ZSBzZWUgc21hcnQgZmlsdGVycyBhcyBh IHNpZ25pZmljYW50IHN0ZXAgZnJvbSBjdXJyZW50IHB1c2ggbWFjaGluZXJ5IGluIGV2b2x1dGlv biBvZiBuZXR3b3JrIGNvbnRyb2wgYXV0b21hdGlvbiwgYmVjYXVzZSBpdCBlbXBvd2VycyB0aGUg Y2xpZW50IHRvIGluc3RydWN0IHRoZSBuZXR3b3JrIHRvIGlkZW50aWZ5IGFuZCBmb2N1cyBvbiAi b3V0bGllcnMiLCByYXRoZXIgdGhhbiBvbiByb3V0aW5lIGNoYW5nZXMgaW4gdGhlIG5ldHdvcmsg U3RhdGUuIEkgYWdyZWUsIHRoaXMgd2lsbCBpbXBvc2UgbW9yZSBjb21wbGV4aXR5IG9uIHRoZSBu ZXR3b3JrLCBidXQgdGhlIGJlbmVmaXRzIGFyZSBvYnZpb3VzLiBGb3IgZXhhbXBsZSwgaW5zdGVh ZCBvZiByZWNlaXZpbmcgdG9ucyBvZiBsYXJnZWx5IHVzZWxlc3MgaW5mb3JtYXRpb24sIDk5JSBv ZiB3aGljaCB0byBiZSBkaXNjYXJkZWQgYWZ0ZXIgdGhlIHByb2Nlc3NpbmcsIHRoZSBjbGllbnQg d2lsbCBiZSBhYmxlIHRvIHJlY2VpdmUgb25seSAiaW50ZXJlc3RpbmciIGluZm9ybWF0aW9uIFdS VCBhY3Rpb25hYmxlIGV2ZW50cy4gVGhlIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIGZyYW1l d29yayBpbnRlbmRzIHRvIG1ha2Ugb25lIHN0ZXAgZnVydGhlciBpbiB0aGlzIGV2b2x1dGlvbi4g V2UgYXJlIGJhc2ljYWxseSBhc2tpbmcgIldoeSBzZW5kaW5nIG5vdGlmaWNhdGlvbnMgaXMgdGhl IG9ubHkgYWN0aW9uIHRoYXQgY291bGQgYmUgdHJpZ2dlcmVkIGJ5IG1vZGVsIGRlZmluZWQgZXZl bnRzIGFuZC9vciBwdXNoIHN1YnNjcmlwdGlvbnMgYW5kL29yIHNtYXJ0IGZpbHRlcnMiPyBXaHks IGZvciBleGFtcGxlLCBwcmUtZGVmaW5lZCBuZXR3b3JrIHJlLWNvbmZpZ3VyYXRpb25zIGNvdWxk IG5vdCBiZSB0cmlnZ2VyZWQgYnkgc21hcnQgZmlsdGVycz8gV2h5IGl0IGlzIG5vdCBwb3NzaWJs ZSBmb3IgdGhlIGNsaWVudCB0byBwcmUtY29uZmlndXJlIGRlc2lyZWQgYQ0KIGN0aW9ucyBhaGVh ZCBvZiB0aW1lPyINCg0KVGhpbmsgYWJvdXQgYSBiYXR0bGVzaGlwIHRoYXQganVzdCBoYXMgYmVl biB0b3JwZWRvZWQuIFRoZSBjcmV3IG1lbWJlcnMgYXJlIG5vdCBleHBlY3RlZCB0byBqdXN0IGlk ZW50aWZ5IGhvbGVzL2xlYWtzIGluIHRoZSBzaGlwJ3MgYm90dG9tLCByZXBvcnQgdGhlICJ0ZWxl bWV0cnkiIHRvIHRoZSBjYXB0YWluIGFuZCB3YWl0IGZvciBpbnN0cnVjdGlvbnMgb24gd2hhdCB0 byBkbyBuZXh0LCByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qgb25seSBrbm93cyBoaXMvaGVy IHByZS1kZWZpbmVkIGFjdGlvbnMsIChzKWhlIGlzIG1ldGljdWxvdXNseSB0cmFpbmVkIG9uIGEg ZGFpbHkgYmFzaXMgb24gaG93IHRvIGNhcnJ5IG91dCB0aGVtIGluIHRoZSBtb3N0IGVmZmljaWVu dCB3YXkuIFRoaXMgaXMgaG93IHNoaXBzIHN1cnZpdmUgcHJvYmxlbXMgbGlrZSB0aGF0LiBBbHNv IHRoaXMgaXMgaG93IHRoZSBzYW1lIGF1dGhvcml0eSBjYW4gY29udHJvbCBiaWcgYW5kIG11bHRp cGxlIHNoaXBzLg0KDQoNClRoaXMgaXNzdWUgaGFzIGNvbWUgdXAgaW4gdGhlIElFVEYgbWFueSB0 aW1lcy4NClRoZSBnZW5lcmFsIHByb2JsZW0gaXMgaG93IHRvIGV4ZWN1dGUgYXBwbGljYXRpb24g YnVzaW5lc3MgbG9naWMgb24gdGhlIHNlcnZlcg0KaW4gb3JkZXIgdG8gZWxpbWluYXRlIGEgcmVs YXRpdmVseSBsZW5ndGh5IGNvbnRyb2wgbG9vcC4NCg0KV2UgaGF2ZSBhIFNjcmlwdCBNSUIgKFJG QyAzMTY1KSB0aGF0IHdhcyBuZXZlciB1c2VmdWwgYmVjYXVzZSB0aGVyZSB3YXMgbm8NCnN0YW5k YXJkIHNjcmlwdCBleGVjdXRpb24gZW52aXJvbm1lbnQuDQoNClRoZXJlIHdhcyBhIHRpZ2h0bHkg Y29udHJvbGxlZCBlbnZpcm9ubWVudCBjYWxsZWQgdGhlIFBvbGljeSBCYXNlZCBNYW5hZ2VtZW50 IE1JQiAoUkZDIDQwMTEpDQp0aGF0IG5vYm9keSBpbXBsZW1lbnRlZCAoZm9yIHZhcmlvdXMgcmVh c29ucykuDQoNCklNTyBZQU5HIFhQYXRoIGRvZXMgYSBnb29kIGpvYiBvZiBwcm92aWRpbmcgYWxs IHRoZSBjb21wb25lbnRzIHJlcXVpcmVkIHRvDQpldmFsdWF0ZSBhIGJvb2xlYW4gZXhwcmVzc2lv biwgd2hpY2ggaXMgaW1wb3J0YW50IGJ1dCBpbnN1ZmZpY2llbnQuDQpBIGZ1bGwtYmxvd24gc2Ny aXB0IGVuZ2luZSB3aXRoIHZhcmlvdXMgbGlicmFyeSBmdW5jdGlvbnMgbWlnaHQgYmUgb3Zlci1r aWxsDQpvciBpdCBtaWdodCBiZSB0aGUgb25seSByZWFsLXdvcmxkIHNvbHV0aW9uIHBhdGguDQoN Cg0KQ2hlZXJzLA0KSWdvcg0KDQoNCkFuZHkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRpYW5yYW4gWmhvdQ0KU2Vu dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxNyAxMTozMSBQTQ0KVG86IFh1ZmVuZyBMaXU7 IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W05ldGNvbmZdIFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0 b21hdGlvbiBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSBYdWZlbmcsDQoNCk9uIHRoZSBzbWFydCBm aWx0ZXJzIChhbHNvIHJlbGF0ZXMgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWNsZW1tLW5ldGNvbmYtcHVzaC1zbWFydC1maWx0ZXJzLXBzLTAwKSwgSSB0aGluayB3ZSBuZWVk IGNyaXRlcmlhIHRvIGNhcmVmdWxseSBzZWxlY3QgImNvbmRpdGlvbnMiLiBXaGlsZSB0aGVyZSBh cmUgbWFueSBiZW5lZml0LCBzYXkgc2F2ZSB0aGUgYmFuZHdpZHRoIGFuZCByZWxpZWYgdGhlIGNv bGxlY3RvciwgaXQgd2lsbCBhZGQgY29tcHV0YXRpb24gYnVyZGVuIHRvIG5ldHdvcmsgZGV2aWNl cy4gTmV0d29yayBkZXZpY2VzIGFyZSBub3QgZ29vZCBhdCB0aGlzIGFzIHNlcnZlcnMuDQpTbyBt YXliZToNCjEuIHNob3VsZCBub3QgdG9vIGNvbXBsZXggdG8gaW1wbGVtZW50Lg0KMi4gbXVzdCBo ZWxwIHRvIG1pdGlnYXRlIHRoZSBleHBvcnQgdm9sdW1lLg0KDQpJZiBzbywgZm9yIGV4YW1wbGUs IHRoZSBhdmVyYWdlIHZhbHVlIHNob3VsZCBiZSBvdXQgb2Ygc2NvcGUsIElNSE8uDQoNCkJlc3Qs DQpUaWFucmFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29u ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFh1ZmVuZyBMaXUNCj4gU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDAyLCAyMDE3IDM6MzEgQU0NCj4gVG86IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5l dGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtOZXRjb25mXSBZQU5HIFBVU0ggQmFzZWQgR2Vu ZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24NCj4gUHJvYmxlbSBTdGF0ZW1lbnQN Cj4NCj4gRGVhciBXRywNCj4NCj4gVGhlIFlhbmctcHVzaCBEZXppZ24gVGVhbSBoYXMgYmVlbiB3 b3JraW5nIG9uIHRoZSBZYW5nIHB1c2ggZW5oYW5jZW1lbnQuDQo+IFdlIGhhdmUgcG9zdGVkIGEg ZHJhZnQgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IHRvIGV4dGVuZCBZYW5nIHB1c2ggdG8gYQ0K PiBtb3JlIGdlbmVyYWxpemVkIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIGZyYW1ld29yay4N Cj4NCj4gVGhlIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBvZiB0aGlzIHRvcGljLiBBbnkgY29t bWVudHMsIHRob3VnaHRzLCBhbmQNCj4gc3VnZ2VzdGlvbnMgYXJlIGFwcHJlY2lhdGVkLg0KPg0K PiBUaGFua3MsDQo+IC0gWHVmZW5nDQo+DQo+ID09PT09PT09PT09PT09PT0NCj4gWUFORyBQVVNI IEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uDQo+IGRyYWZ0LWJy eXNraW4tbmV0Y29uZi1hdXRvbWF0aW9uLWZyYW1ld29yay0wMA0KPg0KPiBFdm9sdXRpb24gb2Yg WUFORyBCYXNlZCBOZXR3b3JrIEF1dG9tYXRpb24NCj4gKiAiQ3VzdG9tIFN1YnNjcmlwdGlvbiB0 byBFdmVudCBOb3RpZmljYXRpb25zIiBtb2RlbCA6DQo+ICAgICAgIC0gYWxsb3dzIGZvciBhIGNs aWVudCB0byBzdWJzY3JpYmUgdG8gdW5zb2xpY2l0ZWQgZXZlbnQgbm90aWZpY2F0aW9ucw0KPiBk ZWZpbmVkIGJ5IHN1cHBvcnRlZCBZQU5HIG1vZGVsczsNCj4NCj4gKiAiU3Vic2NyaWJpbmcgdG8g WUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzIiBtb2RlbDoNCj4gICAgICAgLSBhbGxvd3MgZm9y IGEgY2xpZW50IHRvIGRlZmluZSBzdWJzY3JpYmFibGUgZXZlbnRzIGFuZCBjb250ZW50cyBvZiBl dmVudA0KPiBub3RpZmljYXRpb25zIGFzIHRhcmdldC10cmlnZ2VyLW5vdGlmeSB0cmlwbGV0cw0K Pg0KPiAqICJTbWFydCBmaWx0ZXJzIGZvciBQdXNoIFVwZGF0ZXMiIG1vZGVsOg0KPiAgICAgICAt IGFsbG93cyBmb3IgYSBjbGllbnQgdG8gZmlsdGVyIGV2ZW50IHRyaWdnZXJzIGFuZCBub3RpZmlj YXRpb25zIG9uIHB1c2gNCj4gb2JqZWN0IHZhbHVlcyBhbmQgdGhlaXIgY2hhbmdlIGhpc3Rvcnks IGZvY3VzZXMgb24gIm91dGxpZXJzIg0KPg0KPiBPYmplY3RpdmVzIG9mICBZQU5HIFBVU0ggQmFz ZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24NCj4gMSkgVG8gZ2VuZXJh bGl6ZSB0YXJnZXQtdHJpZ2dlci1ub3RpZnkgY29uY2VwdCBpbnRvIGV2ZW50LWNvbmRpdGlvbi1h Y3Rpb24NCj4gY29uY2VwdCwgd2hlcmU6DQo+DQo+ICAgICAgIGV2ZW50IC0gYSBwYXJ0aWN1bGFy IGNoYW5nZSBpbiB0aGUgbmV0d29yayBzdGF0ZSBleHBsaWNpdGx5IGRlZmluZWQgYnkNCj4gb25l IG9mIHRoZSBZQU5HIG1vZGVscyBzdXBwb3J0ZWQgYnkgdGhlIG5ldHdvcmsgb3IgaW1wbGljaXRs eSBkZWZpbmVkIGJ5DQo+IHRoZSBjbGllbnQsIHdoaWNoIGlzIGNvbnN0YW50bHkgbW9uaXRvcmVk IGJ5IHRoZSBuZXR3b3JrOw0KPg0KPiAgICAgICBjb25kaXRpb24gLSBhIGxvZ2ljYWwgZXhwcmVz c2lvbiB0aGF0IGlzIGV2YWx1YXRlZCBvbmx5IG9uY2UgYWZ0ZXIgdGhlDQo+IGFzc29jaWF0ZWQg ZXZlbnQgaXMgZGV0ZWN0ZWQ7DQo+DQo+ICAgICAgIGFjdGlvbiAtIGFuIG9wZXJhdGlvbiB0byBi ZSBjYXJyaWVkIG91dCBieSB0aGUgbmV0d29yayB3aGVuIHRoZSBhc3NvY2lhdGVkDQo+IGV2ZW50 IGlzIGRldGVjdGVkIGFuZCB0aGUgYXNzb2NpYXRlZCBjb25kaXRpb24gaXMgbWV0DQo+DQo+IDIp IFRvIHByb3ZpZGUgZm9yIGEgY2xpZW50IGEgY2FwYWJpbGl0eSB0byBjb25maWd1cmUgdGhlDQo+ IGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gdHJpcGxldHMgYXMgcG9saWN5IHJ1bGVzIGFoZWFkIG9m IHRpbWUgb3IvYW5kIGR1cmluZw0KPiBuZXR3b3JrIG9wZXJhdGlvbnMNCj4NCj4gR2VuZXJhbGl6 ZWQgQWN0aW9uDQo+ICogU2VuZCBub3RpZmljYXRpb24NCj4gKiBQZXJmb3JtIGltbWVkaWF0ZSBu ZXR3b3JrIHJlY29uZmlndXJhdGlvbiAoZS5nLiBtb2RpZnkgb25lIG9yIG1vcmUNCj4gYXR0cmli dXRlcyBvZiBvbmUgb3IgbW9yZSBDT05GSUc9VFJVRSBkYXRhIHN0b3JlIG5vZGVzKTsNCj4gKiBT Y2hlZHVsZSBvbmUgdGltZSBvciBwZXJpb2RpYyByZWNvbmZpZ3VyYXRpb24gaW4gdGhlIGZ1dHVy ZTsNCj4gKiBDYWxsIFJQQyBkZWZpbmVkIGJ5IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9y dGVkIGJ5IHRoZSBuZXR3b3JrICggZS5nLg0KPiBjYWxsIG5ldHdvcmsncyBwYXRoIGNvbXB1dGVy IHRvIGV2YWx1YXRlIHdoZXRoZXIgYW4gYWx0ZXJuYXRpdmUvbW9yZSBvcHRpbWFsDQo+IHBhdGgg aXMgYXZhaWxhYmxlIGZvciBhIGdpdmVuIGNvbm5lY3Rpb24pDQo+ICogTGluay91bmxpbmsgZGF0 YSBzdG9yZSBkeW5hbWljIHN1Yi10cmVlczsNCj4gKiBFdGMuDQo+DQo+IFJlbGF0aW9uc2hpcCB3 aXRoIFBvbGljeSBGcmFtZXdvcmsNCj4gKiBUaGUgZnJhbWV3b3JrIHNob3VsZCB3b3JrIGF1dG9u b21vdXNseQ0KPg0KPiAqIFRoZSBmcmFtZXdvcmsgc2hvdWxkIGZpdCB3ZWxsIHdpdGhpbiBhIGhp Z2hlciBsZXZlbCBwb2xpY3kgZnJhbWV3b3JrLA0KPiB3aXRoIHRoZSBsYXR0ZXIgcG9zc2libHkg cHJvdmlkaW5nIGEgZ3JlYXRlciBsZXZlbCBvZiBhdXRvbWF0aW9uOg0KPiAgIC0gbXVsdGlwbGUg bWljcm8tY29uZGl0aW9ucyBjb3VsZCBiZSBjb21iaW5lZCBpbnRvIGEgc2luZ2xlDQo+IG1hY3Jv LWNvbmRpdGlvbiB2aWEgYSBudW1iZXIgb2YgbG9naWNhbCBvcGVyYXRpb25zOw0KPiAgIC0gbXVs dGlwbGUgbWljcm8tYWN0aW9ucyBjb3VsZCBiZSBjb21iaW5lZCBpbnRvIGEgc2luZ2xlIHRyYW5z YWN0aW9uIHdpdGgNCj4gYSBwb3NzaWJpbGl0eSBvZiBzcGVjaWZ5aW5nIHBvbGljaWVzIHdpdGgg cmVzcGVjdCB0byBoYW5kbGluZw0KPiBlcnJvcnMvZXhjZXB0aW9ucyBvZiBlYWNoIG9mIHRoZSB0 cmFuc2FjdGlvbiBjb21wb25lbnRzDQo+DQo+IEZyYW1ld29yayBCZW5lZml0cw0KPiAqIGxvd2Vy IGxhdGVuY3ksIGZhc3RlciByZXNwb25zaXZlbmVzcyBvZiB0aGUgbmV0d29yayB0byB2YXJpb3Vz DQo+IGV2ZW50cy9jb25kaXRpb25zOw0KPiAqIGJldHRlciBzY2FsZSAoZS5nLiB0aGUgY2xpZW50 IG1heSBjb250cm9sIG1vcmUgbmV0d29ya3MgYmVjYXVzZSBpdCBkb2VzDQo+IG5vdCBoYXZlIHRv IG1vbml0b3IvbWljcm8tbWFuYWdlIGFueSBvZiB0aGVtKTsNCj4gKiBDUFUgYW5kIGJhbmR3aWR0 aCBzYXZpbmdzIGR1ZSB0byB0aGUgcmVkdWNlZCBhbW91bnQgb2YgY29tbXVuaWNhdGlvbiBiZXR3 ZWVuDQo+IHRoZSBjbGllbnQgYW5kIHRoZSBuZXR3b3JrDQo+ICogVGhlIGNsaWVudCBjYW4gdGFr ZSBpdHNlbGYgb3V0IG9mIHRoZSBuZXR3b3JrIGNvbnRyb2wgbG9vcCwgIGNoYW5nZSBpdHMNCj4g cm9sZSBmcm9tIGJlaW5nIG5ldHdvcmsncyAibWljcm8tbWFuYWdlciIgdG8gYmVpbmcgbmV0d29y aydzICJwb2xpY2UNCj4gb2ZmaWNlciIsIHdobyBpbnRlcmZlcmVzIGludG8gbmV0d29yayBvcGVy YXRpb25zIG9ubHkgaW4NCj4gZXhjZXB0aW9uYWwvdW5wcmVkaWN0ZWQgc2l0dWF0aW9ucw0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBO ZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNv bmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxp bmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo= --_000_0C72C38E7EBC34499E8A9E7DD00786391C19345Bsjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYXNzdW1lIHRoYXQg YSBuZXR3b3JrIGNvdWxkIGJlIGNvbnRyb2xsZWQgdmlhIGEgc2V0IG9mIFlBTkcgZGF0YSBzdG9y ZXMuIFRoaXMgaXMgYSBwb3dlcmZ1bCBlbnZpcm9ubWVudHMgdGhhdCB3ZSBuZXZlciBoYWQgaW4g dGhlIHBhc3QuIFRoZSBZQU5HIG1vZGVsIHdlDQogaGF2ZSBpbiBtaW5kIHdpbGwgYWxsb3cgZm9y IGNvbmZpZ3VyaW5nIHNjcmlwdHMgeW91IG1lbnRpb25lZCBhcyBzZXRzIG9mIGV2ZW50LWNvbmRp dGlvbi1hY3Rpb24gKEVDQSkgdHJpcGxldHMuIFNtYXJ0IGZpbHRlcnMgd2lsbCB0YWtlIGNhcmUg b2YgZXZlbnQtY29uZGl0aW9uIHBhcnQuIFdlIHdpbGwgZm9jdXMgb24gWUFORyBiYXNlZCBhY3Rp b24gZ2VuZXJhbGl6YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZ29yPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJt YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIE5vdmVtYmVyIDAyLCAyMDE3IDE6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IElnb3IgQnJ5c2tp bjxicj4NCjxiPkNjOjwvYj4gVGlhbnJhbiBaaG91OyBYdWZlbmcgTGl1OyBuZXRjb25mQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdl bmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAyLCAyMDE3IGF0IDk6 NTMgQU0sIElnb3IgQnJ5c2tpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3 ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+SWdvci5Ccnlza2luQGh1YXdlaS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+SGkgVGlhbnJhbiw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgY29t bWVudHMuPGJyPg0KPGJyPg0KUGxlYXNlLCBub3RlIHRoYXQgd2Ugc2VlIHNtYXJ0IGZpbHRlcnMg YXMgYSBzaWduaWZpY2FudCBzdGVwIGZyb20gY3VycmVudCBwdXNoIG1hY2hpbmVyeSBpbiBldm9s dXRpb24gb2YgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24sIGJlY2F1c2UgaXQgZW1wb3dlcnMg dGhlIGNsaWVudCB0byBpbnN0cnVjdCB0aGUgbmV0d29yayB0byBpZGVudGlmeSBhbmQgZm9jdXMg b24gJnF1b3Q7b3V0bGllcnMmcXVvdDssIHJhdGhlciB0aGFuIG9uIHJvdXRpbmUgY2hhbmdlcyBp bg0KIHRoZSBuZXR3b3JrIFN0YXRlLiBJIGFncmVlLCB0aGlzIHdpbGwgaW1wb3NlIG1vcmUgY29t cGxleGl0eSBvbiB0aGUgbmV0d29yaywgYnV0IHRoZSBiZW5lZml0cyBhcmUgb2J2aW91cy4gRm9y IGV4YW1wbGUsIGluc3RlYWQgb2YgcmVjZWl2aW5nIHRvbnMgb2YgbGFyZ2VseSB1c2VsZXNzIGlu Zm9ybWF0aW9uLCA5OSUgb2Ygd2hpY2ggdG8gYmUgZGlzY2FyZGVkIGFmdGVyIHRoZSBwcm9jZXNz aW5nLCB0aGUgY2xpZW50IHdpbGwgYmUgYWJsZSB0bw0KIHJlY2VpdmUgb25seSAmcXVvdDtpbnRl cmVzdGluZyZxdW90OyBpbmZvcm1hdGlvbiBXUlQgYWN0aW9uYWJsZSBldmVudHMuIFRoZSBuZXR3 b3JrIGNvbnRyb2wgYXV0b21hdGlvbiBmcmFtZXdvcmsgaW50ZW5kcyB0byBtYWtlIG9uZSBzdGVw IGZ1cnRoZXIgaW4gdGhpcyBldm9sdXRpb24uIFdlIGFyZSBiYXNpY2FsbHkgYXNraW5nICZxdW90 O1doeSBzZW5kaW5nIG5vdGlmaWNhdGlvbnMgaXMgdGhlIG9ubHkgYWN0aW9uIHRoYXQgY291bGQg YmUgdHJpZ2dlcmVkIGJ5IG1vZGVsDQogZGVmaW5lZCBldmVudHMgYW5kL29yIHB1c2ggc3Vic2Ny aXB0aW9ucyBhbmQvb3Igc21hcnQgZmlsdGVycyZxdW90Oz8gV2h5LCBmb3IgZXhhbXBsZSwgcHJl LWRlZmluZWQgbmV0d29yayByZS1jb25maWd1cmF0aW9ucyBjb3VsZCBub3QgYmUgdHJpZ2dlcmVk IGJ5IHNtYXJ0IGZpbHRlcnM/IFdoeSBpdCBpcyBub3QgcG9zc2libGUgZm9yIHRoZSBjbGllbnQg dG8gcHJlLWNvbmZpZ3VyZSBkZXNpcmVkIGE8YnI+DQombmJzcDtjdGlvbnMgYWhlYWQgb2YgdGlt ZT8mcXVvdDs8YnI+DQo8YnI+DQpUaGluayBhYm91dCBhIGJhdHRsZXNoaXAgdGhhdCBqdXN0IGhh cyBiZWVuIHRvcnBlZG9lZC4gVGhlIGNyZXcgbWVtYmVycyBhcmUgbm90IGV4cGVjdGVkIHRvIGp1 c3QgaWRlbnRpZnkgaG9sZXMvbGVha3MgaW4gdGhlIHNoaXAncyBib3R0b20sIHJlcG9ydCB0aGUg JnF1b3Q7dGVsZW1ldHJ5JnF1b3Q7IHRvIHRoZSBjYXB0YWluIGFuZCB3YWl0IGZvciBpbnN0cnVj dGlvbnMgb24gd2hhdCB0byBkbyBuZXh0LCByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qgb25s eQ0KIGtub3dzIGhpcy9oZXIgcHJlLWRlZmluZWQgYWN0aW9ucywgKHMpaGUgaXMgbWV0aWN1bG91 c2x5IHRyYWluZWQgb24gYSBkYWlseSBiYXNpcyBvbiBob3cgdG8gY2Fycnkgb3V0IHRoZW0gaW4g dGhlIG1vc3QgZWZmaWNpZW50IHdheS4gVGhpcyBpcyBob3cgc2hpcHMgc3Vydml2ZSBwcm9ibGVt cyBsaWtlIHRoYXQuIEFsc28gdGhpcyBpcyBob3cgdGhlIHNhbWUgYXV0aG9yaXR5IGNhbiBjb250 cm9sIGJpZyBhbmQgbXVsdGlwbGUgc2hpcHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXNzdWUgaGFzIGNvbWUgdXAgaW4gdGhlIElFVEYgbWFu eSB0aW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBnZW5lcmFsIHByb2JsZW0gaXMgaG93IHRvIGV4ZWN1dGUgYXBwbGljYXRpb24gYnVz aW5lc3MgbG9naWMgb24gdGhlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gb3JkZXIgdG8gZWxpbWluYXRlIGEgcmVsYXRpdmVseSBs ZW5ndGh5IGNvbnRyb2wgbG9vcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBhIFNjcmlwdCBNSUIgKFJGQyAzMTY1KSB0aGF0IHdh cyBuZXZlciB1c2VmdWwgYmVjYXVzZSB0aGVyZSB3YXMgbm88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YW5kYXJkIHNjcmlwdCBleGVjdXRpb24g ZW52aXJvbm1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIHdhcyBhIHRpZ2h0bHkgY29udHJvbGxlZCBlbnZpcm9ubWVudCBjYWxs ZWQgdGhlIFBvbGljeSBCYXNlZCBNYW5hZ2VtZW50IE1JQiAoUkZDIDQwMTEpPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGF0IG5vYm9keSBpbXBs ZW1lbnRlZCAoZm9yIHZhcmlvdXMgcmVhc29ucykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyBZQU5HIFhQYXRoIGRvZXMgYSBnb29kIGpv YiBvZiBwcm92aWRpbmcgYWxsIHRoZSBjb21wb25lbnRzIHJlcXVpcmVkIHRvPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ldmFsdWF0ZSBhIGJvb2xl YW4gZXhwcmVzc2lvbiwgd2hpY2ggaXMgaW1wb3J0YW50IGJ1dCBpbnN1ZmZpY2llbnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZ1bGwtYmxv d24gc2NyaXB0IGVuZ2luZSB3aXRoIHZhcmlvdXMgbGlicmFyeSBmdW5jdGlvbnMgbWlnaHQgYmUg b3Zlci1raWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5vciBpdCBtaWdodCBiZSB0aGUgb25seSByZWFsLXdvcmxkIHNvbHV0aW9uIHBhdGguPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5DaGVlcnMsPGJyPg0KSWdvcjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogTmV0Y29u ZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3U8YnI+DQpT ZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDAxLCAyMDE3IDExOjMxIFBNPGJyPg0KVG86IFh1ZmVu ZyBMaXU7IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3Jn PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxp emVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50PGJyPg0KPGJy Pg0KSGkgWHVmZW5nLDxicj4NCjxicj4NCk9uIHRoZSBzbWFydCBmaWx0ZXJzIChhbHNvIHJlbGF0 ZXMgdG8gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5l dGNvbmYtcHVzaC1zbWFydC1maWx0ZXJzLXBzLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xlbW0tbmV0Y29uZi1wdXNoLXNtYXJ0LWZpbHRl cnMtcHMtMDA8L2E+KSwgSSB0aGluayB3ZSBuZWVkIGNyaXRlcmlhIHRvIGNhcmVmdWxseSBzZWxl Y3QgJnF1b3Q7Y29uZGl0aW9ucyZxdW90Oy4gV2hpbGUgdGhlcmUgYXJlIG1hbnkgYmVuZWZpdCwg c2F5IHNhdmUgdGhlIGJhbmR3aWR0aCBhbmQgcmVsaWVmIHRoZSBjb2xsZWN0b3IsIGl0IHdpbGwg YWRkIGNvbXB1dGF0aW9uIGJ1cmRlbiB0byBuZXR3b3JrDQogZGV2aWNlcy4gTmV0d29yayBkZXZp Y2VzIGFyZSBub3QgZ29vZCBhdCB0aGlzIGFzIHNlcnZlcnMuPGJyPg0KU28gbWF5YmU6PGJyPg0K MS4gc2hvdWxkIG5vdCB0b28gY29tcGxleCB0byBpbXBsZW1lbnQuPGJyPg0KMi4gbXVzdCBoZWxw IHRvIG1pdGlnYXRlIHRoZSBleHBvcnQgdm9sdW1lLjxicj4NCjxicj4NCklmIHNvLCBmb3IgZXhh bXBsZSwgdGhlIGF2ZXJhZ2UgdmFsdWUgc2hvdWxkIGJlIG91dCBvZiBzY29wZSwgSU1ITy48YnI+ DQo8YnI+DQpCZXN0LDxicj4NClRpYW5yYW48YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBOZXRjb25mIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIFh1ZmVuZyBMaXU8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAwMiwgMjAxNyAzOjMxIEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbTmV0 Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0 aW9uPGJyPg0KJmd0OyBQcm9ibGVtIFN0YXRlbWVudDxicj4NCiZndDs8YnI+DQomZ3Q7IERlYXIg V0csPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIFlhbmctcHVzaCBEZXppZ24gVGVhbSBoYXMgYmVl biB3b3JraW5nIG9uIHRoZSBZYW5nIHB1c2ggZW5oYW5jZW1lbnQuPGJyPg0KJmd0OyBXZSBoYXZl IHBvc3RlZCBhIGRyYWZ0IG9uIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0byBleHRlbmQgWWFuZyBw dXNoIHRvIGE8YnI+DQomZ3Q7IG1vcmUgZ2VuZXJhbGl6ZWQgbmV0d29yayBjb250cm9sIGF1dG9t YXRpb24gZnJhbWV3b3JrLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBmb2xsb3dpbmcgaXMgdGhl IHN1bW1hcnkgb2YgdGhpcyB0b3BpYy4gQW55IGNvbW1lbnRzLCB0aG91Z2h0cywgYW5kPGJyPg0K Jmd0OyBzdWdnZXN0aW9ucyBhcmUgYXBwcmVjaWF0ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhh bmtzLDxicj4NCiZndDsgLSBYdWZlbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyA9PT09PT09PT09PT09 PT09PGJyPg0KJmd0OyBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9s IEF1dG9tYXRpb248YnI+DQomZ3Q7IGRyYWZ0LWJyeXNraW4tbmV0Y29uZi1hdXRvbWF0aW9uLWZy YW1ld29yay0wMDxicj4NCiZndDs8YnI+DQomZ3Q7IEV2b2x1dGlvbiBvZiBZQU5HIEJhc2VkIE5l dHdvcmsgQXV0b21hdGlvbjxicj4NCiZndDsgKiAmcXVvdDtDdXN0b20gU3Vic2NyaXB0aW9uIHRv IEV2ZW50IE5vdGlmaWNhdGlvbnMmcXVvdDsgbW9kZWwgOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDstIGFsbG93cyBmb3IgYSBjbGllbnQgdG8gc3Vic2NyaWJlIHRvIHVuc29s aWNpdGVkIGV2ZW50IG5vdGlmaWNhdGlvbnM8YnI+DQomZ3Q7IGRlZmluZWQgYnkgc3VwcG9ydGVk IFlBTkcgbW9kZWxzOzxicj4NCiZndDs8YnI+DQomZ3Q7ICogJnF1b3Q7U3Vic2NyaWJpbmcgdG8g WUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzJnF1b3Q7IG1vZGVsOjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDstIGFsbG93cyBmb3IgYSBjbGllbnQgdG8gZGVmaW5lIHN1YnNj cmliYWJsZSBldmVudHMgYW5kIGNvbnRlbnRzIG9mIGV2ZW50PGJyPg0KJmd0OyBub3RpZmljYXRp b25zIGFzIHRhcmdldC10cmlnZ2VyLW5vdGlmeSB0cmlwbGV0czxicj4NCiZndDs8YnI+DQomZ3Q7 ICogJnF1b3Q7U21hcnQgZmlsdGVycyBmb3IgUHVzaCBVcGRhdGVzJnF1b3Q7IG1vZGVsOjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIGFsbG93cyBmb3IgYSBjbGllbnQgdG8g ZmlsdGVyIGV2ZW50IHRyaWdnZXJzIGFuZCBub3RpZmljYXRpb25zIG9uIHB1c2g8YnI+DQomZ3Q7 IG9iamVjdCB2YWx1ZXMgYW5kIHRoZWlyIGNoYW5nZSBoaXN0b3J5LCBmb2N1c2VzIG9uICZxdW90 O291dGxpZXJzJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT2JqZWN0aXZlcyBvZiZuYnNwOyBZ QU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb248YnI+ DQomZ3Q7IDEpIFRvIGdlbmVyYWxpemUgdGFyZ2V0LXRyaWdnZXItbm90aWZ5IGNvbmNlcHQgaW50 byBldmVudC1jb25kaXRpb24tYWN0aW9uPGJyPg0KJmd0OyBjb25jZXB0LCB3aGVyZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V2ZW50IC0gYSBwYXJ0aWN1 bGFyIGNoYW5nZSBpbiB0aGUgbmV0d29yayBzdGF0ZSBleHBsaWNpdGx5IGRlZmluZWQgYnk8YnI+ DQomZ3Q7IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrIG9y IGltcGxpY2l0bHkgZGVmaW5lZCBieTxicj4NCiZndDsgdGhlIGNsaWVudCwgd2hpY2ggaXMgY29u c3RhbnRseSBtb25pdG9yZWQgYnkgdGhlIG5ldHdvcms7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25kaXRpb24gLSBhIGxvZ2ljYWwgZXhwcmVzc2lvbiB0 aGF0IGlzIGV2YWx1YXRlZCBvbmx5IG9uY2UgYWZ0ZXIgdGhlPGJyPg0KJmd0OyBhc3NvY2lhdGVk IGV2ZW50IGlzIGRldGVjdGVkOzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YWN0aW9uIC0gYW4gb3BlcmF0aW9uIHRvIGJlIGNhcnJpZWQgb3V0IGJ5IHRoZSBu ZXR3b3JrIHdoZW4gdGhlIGFzc29jaWF0ZWQ8YnI+DQomZ3Q7IGV2ZW50IGlzIGRldGVjdGVkIGFu ZCB0aGUgYXNzb2NpYXRlZCBjb25kaXRpb24gaXMgbWV0PGJyPg0KJmd0Ozxicj4NCiZndDsgMikg VG8gcHJvdmlkZSBmb3IgYSBjbGllbnQgYSBjYXBhYmlsaXR5IHRvIGNvbmZpZ3VyZSB0aGU8YnI+ DQomZ3Q7IGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gdHJpcGxldHMgYXMgcG9saWN5IHJ1bGVzIGFo ZWFkIG9mIHRpbWUgb3IvYW5kIGR1cmluZzxicj4NCiZndDsgbmV0d29yayBvcGVyYXRpb25zPGJy Pg0KJmd0Ozxicj4NCiZndDsgR2VuZXJhbGl6ZWQgQWN0aW9uPGJyPg0KJmd0OyAqIFNlbmQgbm90 aWZpY2F0aW9uPGJyPg0KJmd0OyAqIFBlcmZvcm0gaW1tZWRpYXRlIG5ldHdvcmsgcmVjb25maWd1 cmF0aW9uIChlLmcuIG1vZGlmeSBvbmUgb3IgbW9yZTxicj4NCiZndDsgYXR0cmlidXRlcyBvZiBv bmUgb3IgbW9yZSBDT05GSUc9VFJVRSBkYXRhIHN0b3JlIG5vZGVzKTs8YnI+DQomZ3Q7ICogU2No ZWR1bGUgb25lIHRpbWUgb3IgcGVyaW9kaWMgcmVjb25maWd1cmF0aW9uIGluIHRoZSBmdXR1cmU7 PGJyPg0KJmd0OyAqIENhbGwgUlBDIGRlZmluZWQgYnkgb25lIG9mIHRoZSBZQU5HIG1vZGVscyBz dXBwb3J0ZWQgYnkgdGhlIG5ldHdvcmsgKCBlLmcuPGJyPg0KJmd0OyBjYWxsIG5ldHdvcmsncyBw YXRoIGNvbXB1dGVyIHRvIGV2YWx1YXRlIHdoZXRoZXIgYW4gYWx0ZXJuYXRpdmUvbW9yZSBvcHRp bWFsPGJyPg0KJmd0OyBwYXRoIGlzIGF2YWlsYWJsZSBmb3IgYSBnaXZlbiBjb25uZWN0aW9uKTxi cj4NCiZndDsgKiBMaW5rL3VubGluayBkYXRhIHN0b3JlIGR5bmFtaWMgc3ViLXRyZWVzOzxicj4N CiZndDsgKiBFdGMuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmVsYXRpb25zaGlwIHdpdGggUG9saWN5 IEZyYW1ld29yazxicj4NCiZndDsgKiBUaGUgZnJhbWV3b3JrIHNob3VsZCB3b3JrIGF1dG9ub21v dXNseTxicj4NCiZndDs8YnI+DQomZ3Q7ICogVGhlIGZyYW1ld29yayBzaG91bGQgZml0IHdlbGwg d2l0aGluIGEgaGlnaGVyIGxldmVsIHBvbGljeSBmcmFtZXdvcmssPGJyPg0KJmd0OyB3aXRoIHRo ZSBsYXR0ZXIgcG9zc2libHkgcHJvdmlkaW5nIGEgZ3JlYXRlciBsZXZlbCBvZiBhdXRvbWF0aW9u Ojxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBtdWx0aXBsZSBtaWNyby1jb25kaXRpb25zIGNvdWxk IGJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGU8YnI+DQomZ3Q7IG1hY3JvLWNvbmRpdGlvbiB2aWEg YSBudW1iZXIgb2YgbG9naWNhbCBvcGVyYXRpb25zOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBt dWx0aXBsZSBtaWNyby1hY3Rpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGUgdHJh bnNhY3Rpb24gd2l0aDxicj4NCiZndDsgYSBwb3NzaWJpbGl0eSBvZiBzcGVjaWZ5aW5nIHBvbGlj aWVzIHdpdGggcmVzcGVjdCB0byBoYW5kbGluZzxicj4NCiZndDsgZXJyb3JzL2V4Y2VwdGlvbnMg b2YgZWFjaCBvZiB0aGUgdHJhbnNhY3Rpb24gY29tcG9uZW50czxicj4NCiZndDs8YnI+DQomZ3Q7 IEZyYW1ld29yayBCZW5lZml0czxicj4NCiZndDsgKiBsb3dlciBsYXRlbmN5LCBmYXN0ZXIgcmVz cG9uc2l2ZW5lc3Mgb2YgdGhlIG5ldHdvcmsgdG8gdmFyaW91czxicj4NCiZndDsgZXZlbnRzL2Nv bmRpdGlvbnM7PGJyPg0KJmd0OyAqIGJldHRlciBzY2FsZSAoZS5nLiB0aGUgY2xpZW50IG1heSBj b250cm9sIG1vcmUgbmV0d29ya3MgYmVjYXVzZSBpdCBkb2VzPGJyPg0KJmd0OyBub3QgaGF2ZSB0 byBtb25pdG9yL21pY3JvLW1hbmFnZSBhbnkgb2YgdGhlbSk7PGJyPg0KJmd0OyAqIENQVSBhbmQg YmFuZHdpZHRoIHNhdmluZ3MgZHVlIHRvIHRoZSByZWR1Y2VkIGFtb3VudCBvZiBjb21tdW5pY2F0 aW9uIGJldHdlZW48YnI+DQomZ3Q7IHRoZSBjbGllbnQgYW5kIHRoZSBuZXR3b3JrPGJyPg0KJmd0 OyAqIFRoZSBjbGllbnQgY2FuIHRha2UgaXRzZWxmIG91dCBvZiB0aGUgbmV0d29yayBjb250cm9s IGxvb3AsJm5ic3A7IGNoYW5nZSBpdHM8YnI+DQomZ3Q7IHJvbGUgZnJvbSBiZWluZyBuZXR3b3Jr J3MgJnF1b3Q7bWljcm8tbWFuYWdlciZxdW90OyB0byBiZWluZyBuZXR3b3JrJ3MgJnF1b3Q7cG9s aWNlPGJyPg0KJmd0OyBvZmZpY2VyJnF1b3Q7LCB3aG8gaW50ZXJmZXJlcyBpbnRvIG5ldHdvcmsg b3BlcmF0aW9ucyBvbmx5IGluPGJyPg0KJmd0OyBleGNlcHRpb25hbC91bnByZWRpY3RlZCBzaXR1 YXRpb25zPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBOZXRjb25mIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_0C72C38E7EBC34499E8A9E7DD00786391C19345Bsjceml521mbxchi_-- From nobody Thu Nov 2 10:44:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A7813F551 for ; Thu, 2 Nov 2017 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 i58HYbdbdRCk for ; Thu, 2 Nov 2017 10:44:47 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0106.outbound.protection.outlook.com [104.47.38.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E3313F474 for ; Thu, 2 Nov 2017 10:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/SmYt8KslsVnez5OpUpF+SRKC9JrmBaSYQ+smZuoKiA=; b=IwGWdtesjfrdCwU1vDk9KpYOqEqZuWB0HvWgDmQjtSpR3ep8+Jm+K1pxQjzYs1C+HPvK5ps7IerfGoseX9lRg0nYxFvGYEkIvdCIgHrLfln6+czUn7n7/nOm2glQHMr2b1Jr8VrOQ0uk+FK5E133shmUeb1rWtu6Td66J5RHGHo= Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 17:44:40 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0197.013; Thu, 2 Nov 2017 17:44:39 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: draft agenda posted Thread-Index: AQHTVAJBO9TjobP/REm4MZxNlqG9Zg== Date: Thu, 2 Nov 2017 17:44:39 +0000 Message-ID: <89977C01-0388-4834-9918-DDF5F7E0F88B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:rsSj1AGxm2T2FAzi3Jb2YvFLkzslBmwCO9zW7lW8aljxMo8UUkj4IlFaozzk7x6TNgIIm1KjULIz2VUHZI9s6TqVHDEIaH/YanIX55x453Q1HVsJMGOFrOkVgUDfSj+9joRDSRw5ZyRNwJ3Lte6rM5WeJP4MM+nbSL3wiRD3JlYMWaHJUrvRifuyuOJv/Km0gLObt8ZAUXX7vQtySRaTlfJi0SAnXYkOhIqhqc8qS0fQwLHXv8Kw88H8c77gG8rCmQuEx8xnsHSvM1sjALYRpvt1S0dhtsPTXB4aN5jGBnyKRo9iuyewFE9xHhi67Yc8QtOmHMj+S9qzieZyuZKqlmJc5n8zQQ7WcDb1JkMrIfs=; 5:cw6z09QyYT+3U52u1Nmff3yyQpjGjiRuo1qc4pbiw+xjA6wO/1RbhMWNkBTuvKJQzE8oeSywePpF8k7KuXPGZBuECPxl/Wd9NgoFivRLastkVR19rEfaHlII4HS/s3jkFTMKTdVTy8Ywlb9NTcYJtpIcCtcH/o3uD63gjpfFeXY=; 24:cYBJ6wKNz162lQeMij+ZOWdLaL97IpkzHjfhOeFoYkT+lxeNUKtpHFq4JblcPsBgYAcRUb3A5qZQZngBQ0WRqMdJL1bVxuLoXf66Dp/oA7g=; 7:vmEs2gKw/5jqqkmbxeXT1F3yFHzhV6wZT/EfVOaw+LMfIer+7OEYZtL8mZ+NVx1wQQbNU+eAnnzDMXHhaFuUW9LK7Ba44PfWosFpNH1l6FcWt7owSQXHdmcLW/uO3QHFClh6PZZ1S7FKYOAMwhfhu+0i3Xh2HVyy1YAN25AhWN+T83LxB951NV/xqY6TLsaDmVIug2ZHn8BGD07kEY3wqDKp7D03VZnYTiKHXacDJ/cYq5qdYYGWdWN1qcauLJCP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: df410970-3fdc-4a93-95fb-08d52219648b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(77096006)(105586002)(6486002)(6512007)(106356001)(6306002)(66066001)(6436002)(86362001)(2501003)(53936002)(6506006)(54356999)(50986999)(558084003)(3280700002)(36756003)(189998001)(2906002)(14454004)(2900100001)(478600001)(305945005)(101416001)(2351001)(5640700003)(966005)(3660700001)(68736007)(7736002)(25786009)(58126008)(316002)(3480700004)(7116003)(81156014)(81166006)(1730700003)(82746002)(6916009)(83506002)(83716003)(8676002)(5660300001)(6116002)(99286004)(8936002)(33656002)(3846002)(102836003)(97736004)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: df410970-3fdc-4a93-95fb-08d52219648b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 17:44:39.8564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275 Archived-At: Subject: [Netconf] draft agenda posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:44:49 -0000 DQpUaGUgZHJhZnQgYWdlbmRhIGZvciB0aGUgTkVUQ09ORiBzZXNzaW9uIGhhcyBiZWVuIHBvc3Rl ZDoNCg0KICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFs cy9hZ2VuZGEtMTAwLW5ldGNvbmYvDQoNCkl0J3MgYSB0aWdodCBzY2hlZHVsZTsgYXV0aG9ycyBh cmUgcmVxdWVzdGVkIHRvIHBsYW4gYWNjb3JkaW5nbHkuDQoNCkNoZWVycywNCktlbnQgKGFuZCBN YWhlc2gpDQoNCg0K From nobody Thu Nov 2 11:00:16 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA613F5A9 for ; Thu, 2 Nov 2017 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhFYz0_BX582 for ; Thu, 2 Nov 2017 11:00:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366DA1394E4 for ; Thu, 2 Nov 2017 11:00:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZD35110; Thu, 02 Nov 2017 18:00:09 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 18:00:08 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 10:59:49 -0700 From: Alexander Clemm To: Igor Bryskin , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAA96CMA== Date: Thu, 2 Nov 2017 17:59:48 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59FB5D29.030F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a19e6a6149ac33c98f289bbe0730ca1 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:00:15 -0000 Hi, Clearly there is a case to be made for the ability of simple automation / c= losed control loops on the server. =20 Just a few comments regarding the role of YANG Push smart filters in this, = and where I view the boundary between them: - A smart filter allows to send updates only when certain filter conditions= regarding its values are met, possibly involving state. Example: A thresh= old has been crossed, a high-water mark has been breached. These updates c= learly constitute "events" that can feed into an event/condition/action rul= e. =20 - That said, the focus on smart filters is to be smart-yet-simple, applying= 90/10 rule. It is not the intention to make this assume the role of a gen= eral "Event + Expression MIB". For examples, events that would require cr= oss-correlation comparing values across data items, processing entire lists= , computing aggregates over time, etc, would be outside the scope. =20 - The assessment of any conditions would be left for the automation framewo= rk. In other words, a smart filter will just assess the update itself agai= nst a smart filter. It will not make additional checks with regards to oth= er data or take other actions as a result of the filter before sending an e= vent. That would be precisely left for the automation stages. There is a = reason that it's "event-condition-action", not simply "trigger-action". = =20 --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: Thursday, November 02, 2017 9:54 AM > To: Tianran Zhou ; Xufeng Liu > ; netconf@ietf.org > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > Automation Problem Statement >=20 > Hi Tianran, >=20 > Thanks for your comments. >=20 > Please, note that we see smart filters as a significant step from current= push > machinery in evolution of network control automation, because it empowers > the client to instruct the network to identify and focus on "outliers", r= ather > than on routine changes in the network State. I agree, this will impose m= ore > complexity on the network, but the benefits are obvious. For example, > instead of receiving tons of largely useless information, 99% of which to= be > discarded after the processing, the client will be able to receive only > "interesting" information WRT actionable events. The network control > automation framework intends to make one step further in this evolution. > We are basically asking "Why sending notifications is the only action tha= t > could be triggered by model defined events and/or push subscriptions > and/or smart filters"? Why, for example, pre-defined network re- > configurations could not be triggered by smart filters? Why it is not pos= sible > for the client to pre-configure d esired a ctions ahead of time?" >=20 > Think about a battleship that just has been torpedoed. The crew members > are not expected to just identify holes/leaks in the ship's bottom, repor= t the > "telemetry" to the captain and wait for instructions on what to do next, > right? Each crew member not only knows his/her pre-defined actions, (s)he > is meticulously trained on a daily basis on how to carry out them in the = most > efficient way. This is how ships survive problems like that. Also this is= how the > same authority can control big and multiple ships. >=20 > Cheers, > Igor >=20 >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Wednesday, November 01, 2017 11:31 PM > To: Xufeng Liu; netconf@ietf.org > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > Automation Problem Statement >=20 > Hi Xufeng, >=20 > On the smart filters (also relates to https://tools.ietf.org/html/draft-c= lemm- > netconf-push-smart-filters-ps-00), I think we need criteria to carefully = select > "conditions". While there are many benefit, say save the bandwidth and > relief the collector, it will add computation burden to network devices. > Network devices are not good at this as servers. > So maybe: > 1. should not too complex to implement. > 2. must help to mitigate the export volume. >=20 > If so, for example, the average value should be out of scope, IMHO. >=20 > Best, > Tianran >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng > > Liu > > Sent: Thursday, November 02, 2017 3:31 AM > > To: netconf@ietf.org > > Subject: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Dear WG, > > > > The Yang-push Dezign Team has been working on the Yang push > enhancement. > > We have posted a draft on the problem statement to extend Yang push to > > a more generalized network control automation framework. > > > > The following is the summary of this topic. Any comments, thoughts, > > and suggestions are appreciated. > > > > Thanks, > > - Xufeng > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > YANG PUSH Based Generalized Network Control Automation > > draft-bryskin-netconf-automation-framework-00 > > > > Evolution of YANG Based Network Automation > > * "Custom Subscription to Event Notifications" model : > > - allows for a client to subscribe to unsolicited event notifications > > defined by supported YANG models; > > > > * "Subscribing to YANG datastore push updates" model: > > - allows for a client to define subscribable events and contents of > > event notifications as target-trigger-notify triplets > > > > * "Smart filters for Push Updates" model: > > - allows for a client to filter event triggers and notifications on > > push object values and their change history, focuses on "outliers" > > > > Objectives of YANG PUSH Based Generalized Network Control Automation > > 1) To generalize target-trigger-notify concept into > > event-condition-action concept, where: > > > > event - a particular change in the network state explicitly defined > > by one of the YANG models supported by the network or implicitly > > defined by the client, which is constantly monitored by the network; > > > > condition - a logical expression that is evaluated only once after > > the associated event is detected; > > > > action - an operation to be carried out by the network when the > > associated event is detected and the associated condition is met > > > > 2) To provide for a client a capability to configure the > > event-condition-action triplets as policy rules ahead of time or/and > > during network operations > > > > Generalized Action > > * Send notification > > * Perform immediate network reconfiguration (e.g. modify one or more > > attributes of one or more CONFIG=3DTRUE data store nodes); > > * Schedule one time or periodic reconfiguration in the future; > > * Call RPC defined by one of the YANG models supported by the network ( > e.g. > > call network's path computer to evaluate whether an alternative/more > > optimal path is available for a given connection) > > * Link/unlink data store dynamic sub-trees; > > * Etc. > > > > Relationship with Policy Framework > > * The framework should work autonomously > > > > * The framework should fit well within a higher level policy > > framework, with the latter possibly providing a greater level of automa= tion: > > - multiple micro-conditions could be combined into a single > > macro-condition via a number of logical operations; > > - multiple micro-actions could be combined into a single transaction > > with a possibility of specifying policies with respect to handling > > errors/exceptions of each of the transaction components > > > > Framework Benefits > > * lower latency, faster responsiveness of the network to various > > events/conditions; > > * better scale (e.g. the client may control more networks because it > > does not have to monitor/micro-manage any of them); > > * CPU and bandwidth savings due to the reduced amount of > communication > > between the client and the network > > * The client can take itself out of the network control loop, change > > its role from being network's "micro-manager" to being network's > > "police officer", who interferes into network operations only in > > exceptional/unpredicted situations > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 2 11:08:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4D13871A for ; Thu, 2 Nov 2017 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_s7_rK_D_ga for ; Thu, 2 Nov 2017 11:08:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DEE12711D for ; Thu, 2 Nov 2017 11:08:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZD35690; Thu, 02 Nov 2017 18:08:48 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 18:08:47 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 11:08:39 -0700 From: Alexander Clemm To: Igor Bryskin , Andy Bierman CC: Xufeng Liu , "netconf@ietf.org" Thread-Topic: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAEhTFgAAOPl/wABtPh3A= Date: Thu, 2 Nov 2017 18:08:38 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB867@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> <0C72C38E7EBC34499E8A9E7DD00786391C19345B@sjceml521-mbx.china.huawei.com> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786391C19345B@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.40] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB867sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59FB5F31.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0b7b6a4b944968d194322c5e2bc6ecde Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:08:54 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB867sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGp1c3QgdG8gYWRkIG9uOg0KDQpJIGRvIHRoaW5rIHRoZSBpbnRlbnQgb2YgdGhpcyBpcyB0 byBiZSByZWFzb25hYmx5IHNpbXBsZS4gIFRvIHByb3ZpZGUgc29tZXRoaW5nIGxpa2UgYSBnZW5l cmFsaXplZCBmb2cgcHJvZ3JhbW1pbmcgZnJhbWV3b3JrIHdvdWxkIG5vdCBiZSB0aGUgaWRlYSBo ZXJlLCBqdXN0IHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgc29tZSB2ZXJ5IGJhc2ljIGF1dG9tYXRp b24gKHN1Y2ggYXMgdGhlIGFiaWxpdHkgdG8gY29sbGVjdCBtb3JlIGluZm9ybWF0aW9uIHdoZW4g Y2VydGFpbiBldmVudHMgb2NjdXIsIG1heWJlIHJ1biBhIHRlc3QgdGhhdCBjYW4gYmUgaW52b2tl ZCB2aWEgUlBDLCBldGMpLg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhhdCBzbWFydCBmaWx0ZXJzIHdp bGwgcHJvdmlkZSBhIGNvbXByZWhlbnNpdmUgc291cmNlIG9mIGV2ZW50cyBlaXRoZXIuICBUaGUg Zm9jdXMgdGhlcmUgaXMgb24gZmFpcmx5IHNpbXBsZSBjb25kaXRpb25zLCBzdWNoIGFzIHZhbHVl IGluIG9yIG91dCBvZiByYW5nZSwgaGlnaCB3YXRlciBtYXJrLCBldGMuICBUaGlzIGRvZXMgZ28g YmV5b25kIHhwYXRoIGluIHRoYXQgc29tZSBzdGF0ZSBmb3IgdGhlc2UgaXMgbmVlZGVkLiAgU3Rp bGwsIEkgd291bGQgdGhpbmsgdGhhdCBzbWFydCBmaWx0ZXJzIHdpbGwgYmUgb25lIHNvdXJjZSBi dXQgbm90IHRoZSBvbmx5IHNvdXJjZSBvZiBldmVudHMg4oCTIHRoZXJlIHdpbGwgYmUgb3RoZXIg bm90aWZpY2F0aW9ucyAoYmV5b25kIHB1c2ggdXBkYXRlcyksIGFuZCBwZXJoYXBzIGF0IHNvbWUg cG9pbnQgc29tZW9uZSB3aWxsIGluZGVlZCBwcm9kdWNlIHRoZSBlcXVpdmFsZW50IG9mIGFuIGV2 ZW50IGFuZCBleHByZXNzaW9uIE1JQi4gKFRoZSBhbWJpdGlvbiB3aXRoIHNtYXJ0IGZpbHRlcnMg aXMgdG8gYmUgYSBsaXR0bGUgbGVzcyB0aGFuIHRoYXQsIGxldCBhbG9uZSBhIHNjcmlwdCBNSUIu KQ0KDQotLS0gQWxleA0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSWdvciBCcnlza2luDQpTZW50OiBUaHVyc2RheSwgTm92ZW1i ZXIgMDIsIDIwMTcgMTA6MzkgQU0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bT4NCkNjOiBYdWZlbmcgTGl1IDxYdWZlbmdfTGl1QGphYmlsLmNvbT47IG5ldGNvbmZAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5l dHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIEFuZHksDQoN CldlIGFzc3VtZSB0aGF0IGEgbmV0d29yayBjb3VsZCBiZSBjb250cm9sbGVkIHZpYSBhIHNldCBv ZiBZQU5HIGRhdGEgc3RvcmVzLiBUaGlzIGlzIGEgcG93ZXJmdWwgZW52aXJvbm1lbnRzIHRoYXQg d2UgbmV2ZXIgaGFkIGluIHRoZSBwYXN0LiBUaGUgWUFORyBtb2RlbCB3ZSBoYXZlIGluIG1pbmQg d2lsbCBhbGxvdyBmb3IgY29uZmlndXJpbmcgc2NyaXB0cyB5b3UgbWVudGlvbmVkIGFzIHNldHMg b2YgZXZlbnQtY29uZGl0aW9uLWFjdGlvbiAoRUNBKSB0cmlwbGV0cy4gU21hcnQgZmlsdGVycyB3 aWxsIHRha2UgY2FyZSBvZiBldmVudC1jb25kaXRpb24gcGFydC4gV2Ugd2lsbCBmb2N1cyBvbiBZ QU5HIGJhc2VkIGFjdGlvbiBnZW5lcmFsaXphdGlvbi4NCg0KSWdvcg0KDQpGcm9tOiBBbmR5IEJp ZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1i ZXIgMDIsIDIwMTcgMToxNSBQTQ0KVG86IElnb3IgQnJ5c2tpbg0KQ2M6IFRpYW5yYW4gWmhvdTsg WHVmZW5nIExpdTsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsg Q29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCg0KDQpPbiBUaHUsIE5vdiAy LCAyMDE3IGF0IDk6NTMgQU0sIElnb3IgQnJ5c2tpbiA8SWdvci5Ccnlza2luQGh1YXdlaS5jb208 bWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBUaWFucmFuLA0KDQpU aGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNClBsZWFzZSwgbm90ZSB0aGF0IHdlIHNlZSBzbWFy dCBmaWx0ZXJzIGFzIGEgc2lnbmlmaWNhbnQgc3RlcCBmcm9tIGN1cnJlbnQgcHVzaCBtYWNoaW5l cnkgaW4gZXZvbHV0aW9uIG9mIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uLCBiZWNhdXNlIGl0 IGVtcG93ZXJzIHRoZSBjbGllbnQgdG8gaW5zdHJ1Y3QgdGhlIG5ldHdvcmsgdG8gaWRlbnRpZnkg YW5kIGZvY3VzIG9uICJvdXRsaWVycyIsIHJhdGhlciB0aGFuIG9uIHJvdXRpbmUgY2hhbmdlcyBp biB0aGUgbmV0d29yayBTdGF0ZS4gSSBhZ3JlZSwgdGhpcyB3aWxsIGltcG9zZSBtb3JlIGNvbXBs ZXhpdHkgb24gdGhlIG5ldHdvcmssIGJ1dCB0aGUgYmVuZWZpdHMgYXJlIG9idmlvdXMuIEZvciBl eGFtcGxlLCBpbnN0ZWFkIG9mIHJlY2VpdmluZyB0b25zIG9mIGxhcmdlbHkgdXNlbGVzcyBpbmZv cm1hdGlvbiwgOTklIG9mIHdoaWNoIHRvIGJlIGRpc2NhcmRlZCBhZnRlciB0aGUgcHJvY2Vzc2lu ZywgdGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gcmVjZWl2ZSBvbmx5ICJpbnRlcmVzdGluZyIg aW5mb3JtYXRpb24gV1JUIGFjdGlvbmFibGUgZXZlbnRzLiBUaGUgbmV0d29yayBjb250cm9sIGF1 dG9tYXRpb24gZnJhbWV3b3JrIGludGVuZHMgdG8gbWFrZSBvbmUgc3RlcCBmdXJ0aGVyIGluIHRo aXMgZXZvbHV0aW9uLiBXZSBhcmUgYmFzaWNhbGx5IGFza2luZyAiV2h5IHNlbmRpbmcgbm90aWZp Y2F0aW9ucyBpcyB0aGUgb25seSBhY3Rpb24gdGhhdCBjb3VsZCBiZSB0cmlnZ2VyZWQgYnkgbW9k ZWwgZGVmaW5lZCBldmVudHMgYW5kL29yIHB1c2ggc3Vic2NyaXB0aW9ucyBhbmQvb3Igc21hcnQg ZmlsdGVycyI/IFdoeSwgZm9yIGV4YW1wbGUsIHByZS1kZWZpbmVkIG5ldHdvcmsgcmUtY29uZmln dXJhdGlvbnMgY291bGQgbm90IGJlIHRyaWdnZXJlZCBieSBzbWFydCBmaWx0ZXJzPyBXaHkgaXQg aXMgbm90IHBvc3NpYmxlIGZvciB0aGUgY2xpZW50IHRvIHByZS1jb25maWd1cmUgZGVzaXJlZCBh DQogY3Rpb25zIGFoZWFkIG9mIHRpbWU/Ig0KDQpUaGluayBhYm91dCBhIGJhdHRsZXNoaXAgdGhh dCBqdXN0IGhhcyBiZWVuIHRvcnBlZG9lZC4gVGhlIGNyZXcgbWVtYmVycyBhcmUgbm90IGV4cGVj dGVkIHRvIGp1c3QgaWRlbnRpZnkgaG9sZXMvbGVha3MgaW4gdGhlIHNoaXAncyBib3R0b20sIHJl cG9ydCB0aGUgInRlbGVtZXRyeSIgdG8gdGhlIGNhcHRhaW4gYW5kIHdhaXQgZm9yIGluc3RydWN0 aW9ucyBvbiB3aGF0IHRvIGRvIG5leHQsIHJpZ2h0PyBFYWNoIGNyZXcgbWVtYmVyIG5vdCBvbmx5 IGtub3dzIGhpcy9oZXIgcHJlLWRlZmluZWQgYWN0aW9ucywgKHMpaGUgaXMgbWV0aWN1bG91c2x5 IHRyYWluZWQgb24gYSBkYWlseSBiYXNpcyBvbiBob3cgdG8gY2Fycnkgb3V0IHRoZW0gaW4gdGhl IG1vc3QgZWZmaWNpZW50IHdheS4gVGhpcyBpcyBob3cgc2hpcHMgc3Vydml2ZSBwcm9ibGVtcyBs aWtlIHRoYXQuIEFsc28gdGhpcyBpcyBob3cgdGhlIHNhbWUgYXV0aG9yaXR5IGNhbiBjb250cm9s IGJpZyBhbmQgbXVsdGlwbGUgc2hpcHMuDQoNCg0KVGhpcyBpc3N1ZSBoYXMgY29tZSB1cCBpbiB0 aGUgSUVURiBtYW55IHRpbWVzLg0KVGhlIGdlbmVyYWwgcHJvYmxlbSBpcyBob3cgdG8gZXhlY3V0 ZSBhcHBsaWNhdGlvbiBidXNpbmVzcyBsb2dpYyBvbiB0aGUgc2VydmVyDQppbiBvcmRlciB0byBl bGltaW5hdGUgYSByZWxhdGl2ZWx5IGxlbmd0aHkgY29udHJvbCBsb29wLg0KDQpXZSBoYXZlIGEg U2NyaXB0IE1JQiAoUkZDIDMxNjUpIHRoYXQgd2FzIG5ldmVyIHVzZWZ1bCBiZWNhdXNlIHRoZXJl IHdhcyBubw0Kc3RhbmRhcmQgc2NyaXB0IGV4ZWN1dGlvbiBlbnZpcm9ubWVudC4NCg0KVGhlcmUg d2FzIGEgdGlnaHRseSBjb250cm9sbGVkIGVudmlyb25tZW50IGNhbGxlZCB0aGUgUG9saWN5IEJh c2VkIE1hbmFnZW1lbnQgTUlCIChSRkMgNDAxMSkNCnRoYXQgbm9ib2R5IGltcGxlbWVudGVkIChm b3IgdmFyaW91cyByZWFzb25zKS4NCg0KSU1PIFlBTkcgWFBhdGggZG9lcyBhIGdvb2Qgam9iIG9m IHByb3ZpZGluZyBhbGwgdGhlIGNvbXBvbmVudHMgcmVxdWlyZWQgdG8NCmV2YWx1YXRlIGEgYm9v bGVhbiBleHByZXNzaW9uLCB3aGljaCBpcyBpbXBvcnRhbnQgYnV0IGluc3VmZmljaWVudC4NCkEg ZnVsbC1ibG93biBzY3JpcHQgZW5naW5lIHdpdGggdmFyaW91cyBsaWJyYXJ5IGZ1bmN0aW9ucyBt aWdodCBiZSBvdmVyLWtpbGwNCm9yIGl0IG1pZ2h0IGJlIHRoZSBvbmx5IHJlYWwtd29ybGQgc29s dXRpb24gcGF0aC4NCg0KDQpDaGVlcnMsDQpJZ29yDQoNCg0KQW5keQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGlh bnJhbiBaaG91DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDAxLCAyMDE3IDExOjMxIFBNDQpU bzogWHVmZW5nIExpdTsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdv cmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIFh1ZmVuZywNCg0K T24gdGhlIHNtYXJ0IGZpbHRlcnMgKGFsc28gcmVsYXRlcyB0byBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2xlbW0tbmV0Y29uZi1wdXNoLXNtYXJ0LWZpbHRlcnMtcHMtMDApLCBJ IHRoaW5rIHdlIG5lZWQgY3JpdGVyaWEgdG8gY2FyZWZ1bGx5IHNlbGVjdCAiY29uZGl0aW9ucyIu IFdoaWxlIHRoZXJlIGFyZSBtYW55IGJlbmVmaXQsIHNheSBzYXZlIHRoZSBiYW5kd2lkdGggYW5k IHJlbGllZiB0aGUgY29sbGVjdG9yLCBpdCB3aWxsIGFkZCBjb21wdXRhdGlvbiBidXJkZW4gdG8g bmV0d29yayBkZXZpY2VzLiBOZXR3b3JrIGRldmljZXMgYXJlIG5vdCBnb29kIGF0IHRoaXMgYXMg c2VydmVycy4NClNvIG1heWJlOg0KMS4gc2hvdWxkIG5vdCB0b28gY29tcGxleCB0byBpbXBsZW1l bnQuDQoyLiBtdXN0IGhlbHAgdG8gbWl0aWdhdGUgdGhlIGV4cG9ydCB2b2x1bWUuDQoNCklmIHNv LCBmb3IgZXhhbXBsZSwgdGhlIGF2ZXJhZ2UgdmFsdWUgc2hvdWxkIGJlIG91dCBvZiBzY29wZSwg SU1ITy4NCg0KQmVzdCwNClRpYW5yYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgWHVmZW5nIExpdQ0KPiBTZW50 OiBUaHVyc2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgMzozMSBBTQ0KPiBUbzogbmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCj4gU3ViamVjdDogW05ldGNvbmZdIFlBTkcg UFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbg0KPiBQcm9i bGVtIFN0YXRlbWVudA0KPg0KPiBEZWFyIFdHLA0KPg0KPiBUaGUgWWFuZy1wdXNoIERlemlnbiBU ZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gdGhlIFlhbmcgcHVzaCBlbmhhbmNlbWVudC4NCj4gV2Ug aGF2ZSBwb3N0ZWQgYSBkcmFmdCBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gZXh0ZW5kIFlh bmcgcHVzaCB0byBhDQo+IG1vcmUgZ2VuZXJhbGl6ZWQgbmV0d29yayBjb250cm9sIGF1dG9tYXRp b24gZnJhbWV3b3JrLg0KPg0KPiBUaGUgZm9sbG93aW5nIGlzIHRoZSBzdW1tYXJ5IG9mIHRoaXMg dG9waWMuIEFueSBjb21tZW50cywgdGhvdWdodHMsIGFuZA0KPiBzdWdnZXN0aW9ucyBhcmUgYXBw cmVjaWF0ZWQuDQo+DQo+IFRoYW5rcywNCj4gLSBYdWZlbmcNCj4NCj4gPT09PT09PT09PT09PT09 PQ0KPiBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRp b24NCj4gZHJhZnQtYnJ5c2tpbi1uZXRjb25mLWF1dG9tYXRpb24tZnJhbWV3b3JrLTAwDQo+DQo+ IEV2b2x1dGlvbiBvZiBZQU5HIEJhc2VkIE5ldHdvcmsgQXV0b21hdGlvbg0KPiAqICJDdXN0b20g U3Vic2NyaXB0aW9uIHRvIEV2ZW50IE5vdGlmaWNhdGlvbnMiIG1vZGVsIDoNCj4gICAgICAgLSBh bGxvd3MgZm9yIGEgY2xpZW50IHRvIHN1YnNjcmliZSB0byB1bnNvbGljaXRlZCBldmVudCBub3Rp ZmljYXRpb25zDQo+IGRlZmluZWQgYnkgc3VwcG9ydGVkIFlBTkcgbW9kZWxzOw0KPg0KPiAqICJT dWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMiIG1vZGVsOg0KPiAgICAg ICAtIGFsbG93cyBmb3IgYSBjbGllbnQgdG8gZGVmaW5lIHN1YnNjcmliYWJsZSBldmVudHMgYW5k IGNvbnRlbnRzIG9mIGV2ZW50DQo+IG5vdGlmaWNhdGlvbnMgYXMgdGFyZ2V0LXRyaWdnZXItbm90 aWZ5IHRyaXBsZXRzDQo+DQo+ICogIlNtYXJ0IGZpbHRlcnMgZm9yIFB1c2ggVXBkYXRlcyIgbW9k ZWw6DQo+ICAgICAgIC0gYWxsb3dzIGZvciBhIGNsaWVudCB0byBmaWx0ZXIgZXZlbnQgdHJpZ2dl cnMgYW5kIG5vdGlmaWNhdGlvbnMgb24gcHVzaA0KPiBvYmplY3QgdmFsdWVzIGFuZCB0aGVpciBj aGFuZ2UgaGlzdG9yeSwgZm9jdXNlcyBvbiAib3V0bGllcnMiDQo+DQo+IE9iamVjdGl2ZXMgb2Yg IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbg0K PiAxKSBUbyBnZW5lcmFsaXplIHRhcmdldC10cmlnZ2VyLW5vdGlmeSBjb25jZXB0IGludG8gZXZl bnQtY29uZGl0aW9uLWFjdGlvbg0KPiBjb25jZXB0LCB3aGVyZToNCj4NCj4gICAgICAgZXZlbnQg LSBhIHBhcnRpY3VsYXIgY2hhbmdlIGluIHRoZSBuZXR3b3JrIHN0YXRlIGV4cGxpY2l0bHkgZGVm aW5lZCBieQ0KPiBvbmUgb2YgdGhlIFlBTkcgbW9kZWxzIHN1cHBvcnRlZCBieSB0aGUgbmV0d29y ayBvciBpbXBsaWNpdGx5IGRlZmluZWQgYnkNCj4gdGhlIGNsaWVudCwgd2hpY2ggaXMgY29uc3Rh bnRseSBtb25pdG9yZWQgYnkgdGhlIG5ldHdvcms7DQo+DQo+ICAgICAgIGNvbmRpdGlvbiAtIGEg bG9naWNhbCBleHByZXNzaW9uIHRoYXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlciB0aGUN Cj4gYXNzb2NpYXRlZCBldmVudCBpcyBkZXRlY3RlZDsNCj4NCj4gICAgICAgYWN0aW9uIC0gYW4g b3BlcmF0aW9uIHRvIGJlIGNhcnJpZWQgb3V0IGJ5IHRoZSBuZXR3b3JrIHdoZW4gdGhlIGFzc29j aWF0ZWQNCj4gZXZlbnQgaXMgZGV0ZWN0ZWQgYW5kIHRoZSBhc3NvY2lhdGVkIGNvbmRpdGlvbiBp cyBtZXQNCj4NCj4gMikgVG8gcHJvdmlkZSBmb3IgYSBjbGllbnQgYSBjYXBhYmlsaXR5IHRvIGNv bmZpZ3VyZSB0aGUNCj4gZXZlbnQtY29uZGl0aW9uLWFjdGlvbiB0cmlwbGV0cyBhcyBwb2xpY3kg cnVsZXMgYWhlYWQgb2YgdGltZSBvci9hbmQgZHVyaW5nDQo+IG5ldHdvcmsgb3BlcmF0aW9ucw0K Pg0KPiBHZW5lcmFsaXplZCBBY3Rpb24NCj4gKiBTZW5kIG5vdGlmaWNhdGlvbg0KPiAqIFBlcmZv cm0gaW1tZWRpYXRlIG5ldHdvcmsgcmVjb25maWd1cmF0aW9uIChlLmcuIG1vZGlmeSBvbmUgb3Ig bW9yZQ0KPiBhdHRyaWJ1dGVzIG9mIG9uZSBvciBtb3JlIENPTkZJRz1UUlVFIGRhdGEgc3RvcmUg bm9kZXMpOw0KPiAqIFNjaGVkdWxlIG9uZSB0aW1lIG9yIHBlcmlvZGljIHJlY29uZmlndXJhdGlv biBpbiB0aGUgZnV0dXJlOw0KPiAqIENhbGwgUlBDIGRlZmluZWQgYnkgb25lIG9mIHRoZSBZQU5H IG1vZGVscyBzdXBwb3J0ZWQgYnkgdGhlIG5ldHdvcmsgKCBlLmcuDQo+IGNhbGwgbmV0d29yaydz IHBhdGggY29tcHV0ZXIgdG8gZXZhbHVhdGUgd2hldGhlciBhbiBhbHRlcm5hdGl2ZS9tb3JlIG9w dGltYWwNCj4gcGF0aCBpcyBhdmFpbGFibGUgZm9yIGEgZ2l2ZW4gY29ubmVjdGlvbikNCj4gKiBM aW5rL3VubGluayBkYXRhIHN0b3JlIGR5bmFtaWMgc3ViLXRyZWVzOw0KPiAqIEV0Yy4NCj4NCj4g UmVsYXRpb25zaGlwIHdpdGggUG9saWN5IEZyYW1ld29yaw0KPiAqIFRoZSBmcmFtZXdvcmsgc2hv dWxkIHdvcmsgYXV0b25vbW91c2x5DQo+DQo+ICogVGhlIGZyYW1ld29yayBzaG91bGQgZml0IHdl bGwgd2l0aGluIGEgaGlnaGVyIGxldmVsIHBvbGljeSBmcmFtZXdvcmssDQo+IHdpdGggdGhlIGxh dHRlciBwb3NzaWJseSBwcm92aWRpbmcgYSBncmVhdGVyIGxldmVsIG9mIGF1dG9tYXRpb246DQo+ ICAgLSBtdWx0aXBsZSBtaWNyby1jb25kaXRpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBz aW5nbGUNCj4gbWFjcm8tY29uZGl0aW9uIHZpYSBhIG51bWJlciBvZiBsb2dpY2FsIG9wZXJhdGlv bnM7DQo+ICAgLSBtdWx0aXBsZSBtaWNyby1hY3Rpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8g YSBzaW5nbGUgdHJhbnNhY3Rpb24gd2l0aA0KPiBhIHBvc3NpYmlsaXR5IG9mIHNwZWNpZnlpbmcg cG9saWNpZXMgd2l0aCByZXNwZWN0IHRvIGhhbmRsaW5nDQo+IGVycm9ycy9leGNlcHRpb25zIG9m IGVhY2ggb2YgdGhlIHRyYW5zYWN0aW9uIGNvbXBvbmVudHMNCj4NCj4gRnJhbWV3b3JrIEJlbmVm aXRzDQo+ICogbG93ZXIgbGF0ZW5jeSwgZmFzdGVyIHJlc3BvbnNpdmVuZXNzIG9mIHRoZSBuZXR3 b3JrIHRvIHZhcmlvdXMNCj4gZXZlbnRzL2NvbmRpdGlvbnM7DQo+ICogYmV0dGVyIHNjYWxlIChl LmcuIHRoZSBjbGllbnQgbWF5IGNvbnRyb2wgbW9yZSBuZXR3b3JrcyBiZWNhdXNlIGl0IGRvZXMN Cj4gbm90IGhhdmUgdG8gbW9uaXRvci9taWNyby1tYW5hZ2UgYW55IG9mIHRoZW0pOw0KPiAqIENQ VSBhbmQgYmFuZHdpZHRoIHNhdmluZ3MgZHVlIHRvIHRoZSByZWR1Y2VkIGFtb3VudCBvZiBjb21t dW5pY2F0aW9uIGJldHdlZW4NCj4gdGhlIGNsaWVudCBhbmQgdGhlIG5ldHdvcmsNCj4gKiBUaGUg Y2xpZW50IGNhbiB0YWtlIGl0c2VsZiBvdXQgb2YgdGhlIG5ldHdvcmsgY29udHJvbCBsb29wLCAg Y2hhbmdlIGl0cw0KPiByb2xlIGZyb20gYmVpbmcgbmV0d29yaydzICJtaWNyby1tYW5hZ2VyIiB0 byBiZWluZyBuZXR3b3JrJ3MgInBvbGljZQ0KPiBvZmZpY2VyIiwgd2hvIGludGVyZmVyZXMgaW50 byBuZXR3b3JrIG9wZXJhdGlvbnMgb25seSBpbg0KPiBleGNlcHRpb25hbC91bnByZWRpY3RlZCBz aXR1YXRpb25zDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5l dGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoN Cg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB867sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MzYxMzY3OTY0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo1Mjk5NDAxMjIgLTE0MjIyMzkzODYgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo2Ow0KCW1zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvga47DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2Vy aWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBqdXN0IHRvIGFkZCBvbjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG8gdGhpbmsgdGhlIGludGVudCBvZiB0 aGlzIGlzIHRvIGJlIHJlYXNvbmFibHkgc2ltcGxlLiZuYnNwOyBUbyBwcm92aWRlIHNvbWV0aGlu ZyBsaWtlIGEgZ2VuZXJhbGl6ZWQgZm9nIHByb2dyYW1taW5nIGZyYW1ld29yayB3b3VsZCBub3Qg YmUgdGhlIGlkZWEgaGVyZSwganVzdA0KIHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgc29tZSB2ZXJ5 IGJhc2ljIGF1dG9tYXRpb24gKHN1Y2ggYXMgdGhlIGFiaWxpdHkgdG8gY29sbGVjdCBtb3JlIGlu Zm9ybWF0aW9uIHdoZW4gY2VydGFpbiBldmVudHMgb2NjdXIsIG1heWJlIHJ1biBhIHRlc3QgdGhh dCBjYW4gYmUgaW52b2tlZCB2aWEgUlBDLCBldGMpLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhhdCBzbWFydCBmaWx0 ZXJzIHdpbGwgcHJvdmlkZSBhIGNvbXByZWhlbnNpdmUgc291cmNlIG9mIGV2ZW50cyBlaXRoZXIu Jm5ic3A7IFRoZSBmb2N1cyB0aGVyZSBpcyBvbiBmYWlybHkgc2ltcGxlIGNvbmRpdGlvbnMsIHN1 Y2ggYXMgdmFsdWUgaW4gb3Igb3V0DQogb2YgcmFuZ2UsIGhpZ2ggd2F0ZXIgbWFyaywgZXRjLiZu YnNwOyBUaGlzIGRvZXMgZ28gYmV5b25kIHhwYXRoIGluIHRoYXQgc29tZSBzdGF0ZSBmb3IgdGhl c2UgaXMgbmVlZGVkLiZuYnNwOyBTdGlsbCwgSSB3b3VsZCB0aGluayB0aGF0IHNtYXJ0IGZpbHRl cnMgd2lsbCBiZSBvbmUgc291cmNlIGJ1dCBub3QgdGhlIG9ubHkgc291cmNlIG9mIGV2ZW50cyDi gJMgdGhlcmUgd2lsbCBiZSBvdGhlciBub3RpZmljYXRpb25zIChiZXlvbmQgcHVzaCB1cGRhdGVz KSwgYW5kDQogcGVyaGFwcyBhdCBzb21lIHBvaW50IHNvbWVvbmUgd2lsbCBpbmRlZWQgcHJvZHVj ZSB0aGUgZXF1aXZhbGVudCBvZiBhbiBldmVudCBhbmQgZXhwcmVzc2lvbiBNSUIuIChUaGUgYW1i aXRpb24gd2l0aCBzbWFydCBmaWx0ZXJzIGlzIHRvIGJlIGEgbGl0dGxlIGxlc3MgdGhhbiB0aGF0 LCBsZXQgYWxvbmUgYSBzY3JpcHQgTUlCLikmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZXRjb25mIFttYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5JZ29yIEJyeXNr aW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDEwOjM5IEFN PGJyPg0KPGI+VG86PC9iPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IFh1ZmVuZyBMaXUgJmx0O1h1ZmVuZ19MaXVAamFiaWwuY29tJmd0Ozsg bmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFlBTkcg UFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbiBQcm9ibGVt IFN0YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgYXNzdW1lIHRoYXQgYSBuZXR3b3JrIGNvdWxk IGJlIGNvbnRyb2xsZWQgdmlhIGEgc2V0IG9mIFlBTkcgZGF0YSBzdG9yZXMuIFRoaXMgaXMgYSBw b3dlcmZ1bCBlbnZpcm9ubWVudHMgdGhhdCB3ZSBuZXZlciBoYWQgaW4gdGhlIHBhc3QuIFRoZSBZ QU5HIG1vZGVsIHdlIGhhdmUNCiBpbiBtaW5kIHdpbGwgYWxsb3cgZm9yIGNvbmZpZ3VyaW5nIHNj cmlwdHMgeW91IG1lbnRpb25lZCBhcyBzZXRzIG9mIGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gKEVD QSkgdHJpcGxldHMuIFNtYXJ0IGZpbHRlcnMgd2lsbCB0YWtlIGNhcmUgb2YgZXZlbnQtY29uZGl0 aW9uIHBhcnQuIFdlIHdpbGwgZm9jdXMgb24gWUFORyBiYXNlZCBhY3Rpb24gZ2VuZXJhbGl6YXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZ29yPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gWzxhIGhyZWY9Im1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20iPm1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAxOjE1IFBNPGJyPg0K PGI+VG86PC9iPiBJZ29yIEJyeXNraW48YnI+DQo8Yj5DYzo8L2I+IFRpYW5yYW4gWmhvdTsgWHVm ZW5nIExpdTsgPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2Vk IEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAyLCAyMDE3IGF0 IDk6NTMgQU0sIElnb3IgQnJ5c2tpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOklnb3IuQnJ5c2tpbkBo dWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+SWdvci5Ccnlza2luQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SGkgVGlhbnJhbiw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIg Y29tbWVudHMuPGJyPg0KPGJyPg0KUGxlYXNlLCBub3RlIHRoYXQgd2Ugc2VlIHNtYXJ0IGZpbHRl cnMgYXMgYSBzaWduaWZpY2FudCBzdGVwIGZyb20gY3VycmVudCBwdXNoIG1hY2hpbmVyeSBpbiBl dm9sdXRpb24gb2YgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24sIGJlY2F1c2UgaXQgZW1wb3dl cnMgdGhlIGNsaWVudCB0byBpbnN0cnVjdCB0aGUgbmV0d29yayB0byBpZGVudGlmeSBhbmQgZm9j dXMgb24gJnF1b3Q7b3V0bGllcnMmcXVvdDssIHJhdGhlciB0aGFuIG9uIHJvdXRpbmUgY2hhbmdl cyBpbg0KIHRoZSBuZXR3b3JrIFN0YXRlLiBJIGFncmVlLCB0aGlzIHdpbGwgaW1wb3NlIG1vcmUg Y29tcGxleGl0eSBvbiB0aGUgbmV0d29yaywgYnV0IHRoZSBiZW5lZml0cyBhcmUgb2J2aW91cy4g Rm9yIGV4YW1wbGUsIGluc3RlYWQgb2YgcmVjZWl2aW5nIHRvbnMgb2YgbGFyZ2VseSB1c2VsZXNz IGluZm9ybWF0aW9uLCA5OSUgb2Ygd2hpY2ggdG8gYmUgZGlzY2FyZGVkIGFmdGVyIHRoZSBwcm9j ZXNzaW5nLCB0aGUgY2xpZW50IHdpbGwgYmUgYWJsZSB0bw0KIHJlY2VpdmUgb25seSAmcXVvdDtp bnRlcmVzdGluZyZxdW90OyBpbmZvcm1hdGlvbiBXUlQgYWN0aW9uYWJsZSBldmVudHMuIFRoZSBu ZXR3b3JrIGNvbnRyb2wgYXV0b21hdGlvbiBmcmFtZXdvcmsgaW50ZW5kcyB0byBtYWtlIG9uZSBz dGVwIGZ1cnRoZXIgaW4gdGhpcyBldm9sdXRpb24uIFdlIGFyZSBiYXNpY2FsbHkgYXNraW5nICZx dW90O1doeSBzZW5kaW5nIG5vdGlmaWNhdGlvbnMgaXMgdGhlIG9ubHkgYWN0aW9uIHRoYXQgY291 bGQgYmUgdHJpZ2dlcmVkIGJ5IG1vZGVsDQogZGVmaW5lZCBldmVudHMgYW5kL29yIHB1c2ggc3Vi c2NyaXB0aW9ucyBhbmQvb3Igc21hcnQgZmlsdGVycyZxdW90Oz8gV2h5LCBmb3IgZXhhbXBsZSwg cHJlLWRlZmluZWQgbmV0d29yayByZS1jb25maWd1cmF0aW9ucyBjb3VsZCBub3QgYmUgdHJpZ2dl cmVkIGJ5IHNtYXJ0IGZpbHRlcnM/IFdoeSBpdCBpcyBub3QgcG9zc2libGUgZm9yIHRoZSBjbGll bnQgdG8gcHJlLWNvbmZpZ3VyZSBkZXNpcmVkIGE8YnI+DQombmJzcDtjdGlvbnMgYWhlYWQgb2Yg dGltZT8mcXVvdDs8YnI+DQo8YnI+DQpUaGluayBhYm91dCBhIGJhdHRsZXNoaXAgdGhhdCBqdXN0 IGhhcyBiZWVuIHRvcnBlZG9lZC4gVGhlIGNyZXcgbWVtYmVycyBhcmUgbm90IGV4cGVjdGVkIHRv IGp1c3QgaWRlbnRpZnkgaG9sZXMvbGVha3MgaW4gdGhlIHNoaXAncyBib3R0b20sIHJlcG9ydCB0 aGUgJnF1b3Q7dGVsZW1ldHJ5JnF1b3Q7IHRvIHRoZSBjYXB0YWluIGFuZCB3YWl0IGZvciBpbnN0 cnVjdGlvbnMgb24gd2hhdCB0byBkbyBuZXh0LCByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qg b25seQ0KIGtub3dzIGhpcy9oZXIgcHJlLWRlZmluZWQgYWN0aW9ucywgKHMpaGUgaXMgbWV0aWN1 bG91c2x5IHRyYWluZWQgb24gYSBkYWlseSBiYXNpcyBvbiBob3cgdG8gY2Fycnkgb3V0IHRoZW0g aW4gdGhlIG1vc3QgZWZmaWNpZW50IHdheS4gVGhpcyBpcyBob3cgc2hpcHMgc3Vydml2ZSBwcm9i bGVtcyBsaWtlIHRoYXQuIEFsc28gdGhpcyBpcyBob3cgdGhlIHNhbWUgYXV0aG9yaXR5IGNhbiBj b250cm9sIGJpZyBhbmQgbXVsdGlwbGUgc2hpcHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXNzdWUgaGFzIGNvbWUgdXAgaW4gdGhlIElFVEYg bWFueSB0aW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBnZW5lcmFsIHByb2JsZW0gaXMgaG93IHRvIGV4ZWN1dGUgYXBwbGljYXRpb24g YnVzaW5lc3MgbG9naWMgb24gdGhlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gb3JkZXIgdG8gZWxpbWluYXRlIGEgcmVsYXRpdmVs eSBsZW5ndGh5IGNvbnRyb2wgbG9vcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBhIFNjcmlwdCBNSUIgKFJGQyAzMTY1KSB0aGF0 IHdhcyBuZXZlciB1c2VmdWwgYmVjYXVzZSB0aGVyZSB3YXMgbm88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YW5kYXJkIHNjcmlwdCBleGVjdXRp b24gZW52aXJvbm1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIHdhcyBhIHRpZ2h0bHkgY29udHJvbGxlZCBlbnZpcm9ubWVudCBj YWxsZWQgdGhlIFBvbGljeSBCYXNlZCBNYW5hZ2VtZW50IE1JQiAoUkZDIDQwMTEpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGF0IG5vYm9keSBp bXBsZW1lbnRlZCAoZm9yIHZhcmlvdXMgcmVhc29ucykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyBZQU5HIFhQYXRoIGRvZXMgYSBnb29k IGpvYiBvZiBwcm92aWRpbmcgYWxsIHRoZSBjb21wb25lbnRzIHJlcXVpcmVkIHRvPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ldmFsdWF0ZSBhIGJv b2xlYW4gZXhwcmVzc2lvbiwgd2hpY2ggaXMgaW1wb3J0YW50IGJ1dCBpbnN1ZmZpY2llbnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGZ1bGwt Ymxvd24gc2NyaXB0IGVuZ2luZSB3aXRoIHZhcmlvdXMgbGlicmFyeSBmdW5jdGlvbnMgbWlnaHQg YmUgb3Zlci1raWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5vciBpdCBtaWdodCBiZSB0aGUgb25seSByZWFsLXdvcmxkIHNvbHV0aW9uIHBhdGgu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+Q2hlZXJzLDxicj4NCklnb3I8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQpGcm9tOiBOZXRjb25mIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IFRpYW5yYW4gWmhvdTxicj4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDEsIDIwMTcgMTE6 MzEgUE08YnI+DQpUbzogWHVmZW5nIExpdTsgPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBZQU5H IFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24gUHJvYmxl bSBTdGF0ZW1lbnQ8YnI+DQo8YnI+DQpIaSBYdWZlbmcsPGJyPg0KPGJyPg0KT24gdGhlIHNtYXJ0 IGZpbHRlcnMgKGFsc28gcmVsYXRlcyB0byA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtY2xlbW0tbmV0Y29uZi1wdXNoLXNtYXJ0LWZpbHRlcnMtcHMtMDAiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jbGVtbS1uZXRj b25mLXB1c2gtc21hcnQtZmlsdGVycy1wcy0wMDwvYT4pLCBJIHRoaW5rIHdlIG5lZWQgY3JpdGVy aWEgdG8gY2FyZWZ1bGx5IHNlbGVjdCAmcXVvdDtjb25kaXRpb25zJnF1b3Q7LiBXaGlsZSB0aGVy ZSBhcmUgbWFueSBiZW5lZml0LCBzYXkgc2F2ZSB0aGUgYmFuZHdpZHRoIGFuZCByZWxpZWYgdGhl IGNvbGxlY3RvciwgaXQgd2lsbCBhZGQgY29tcHV0YXRpb24gYnVyZGVuIHRvIG5ldHdvcmsNCiBk ZXZpY2VzLiBOZXR3b3JrIGRldmljZXMgYXJlIG5vdCBnb29kIGF0IHRoaXMgYXMgc2VydmVycy48 YnI+DQpTbyBtYXliZTo8YnI+DQoxLiBzaG91bGQgbm90IHRvbyBjb21wbGV4IHRvIGltcGxlbWVu dC48YnI+DQoyLiBtdXN0IGhlbHAgdG8gbWl0aWdhdGUgdGhlIGV4cG9ydCB2b2x1bWUuPGJyPg0K PGJyPg0KSWYgc28sIGZvciBleGFtcGxlLCB0aGUgYXZlcmFnZSB2YWx1ZSBzaG91bGQgYmUgb3V0 IG9mIHNjb3BlLCBJTUhPLjxicj4NCjxicj4NCkJlc3QsPGJyPg0KVGlhbnJhbjxicj4NCjxicj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE5ldGNvbmYg W21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgWHVmZW5nIExpdTxicj4NCiZndDsg U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDM6MzEgQU08YnI+DQomZ3Q7IFRvOiA8 YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IFN1YmplY3Q6IFtOZXRjb25mXSBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0 d29yayBDb250cm9sIEF1dG9tYXRpb248YnI+DQomZ3Q7IFByb2JsZW0gU3RhdGVtZW50PGJyPg0K Jmd0Ozxicj4NCiZndDsgRGVhciBXRyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgWWFuZy1wdXNo IERlemlnbiBUZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gdGhlIFlhbmcgcHVzaCBlbmhhbmNlbWVu dC48YnI+DQomZ3Q7IFdlIGhhdmUgcG9zdGVkIGEgZHJhZnQgb24gdGhlIHByb2JsZW0gc3RhdGVt ZW50IHRvIGV4dGVuZCBZYW5nIHB1c2ggdG8gYTxicj4NCiZndDsgbW9yZSBnZW5lcmFsaXplZCBu ZXR3b3JrIGNvbnRyb2wgYXV0b21hdGlvbiBmcmFtZXdvcmsuPGJyPg0KJmd0Ozxicj4NCiZndDsg VGhlIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBvZiB0aGlzIHRvcGljLiBBbnkgY29tbWVudHMs IHRob3VnaHRzLCBhbmQ8YnI+DQomZ3Q7IHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAtIFh1ZmVuZzxicj4NCiZndDs8YnI+ DQomZ3Q7ID09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFs aXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbjxicj4NCiZndDsgZHJhZnQtYnJ5c2tpbi1u ZXRjb25mLWF1dG9tYXRpb24tZnJhbWV3b3JrLTAwPGJyPg0KJmd0Ozxicj4NCiZndDsgRXZvbHV0 aW9uIG9mIFlBTkcgQmFzZWQgTmV0d29yayBBdXRvbWF0aW9uPGJyPg0KJmd0OyAqICZxdW90O0N1 c3RvbSBTdWJzY3JpcHRpb24gdG8gRXZlbnQgTm90aWZpY2F0aW9ucyZxdW90OyBtb2RlbCA6PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gYWxsb3dzIGZvciBhIGNsaWVudCB0 byBzdWJzY3JpYmUgdG8gdW5zb2xpY2l0ZWQgZXZlbnQgbm90aWZpY2F0aW9uczxicj4NCiZndDsg ZGVmaW5lZCBieSBzdXBwb3J0ZWQgWUFORyBtb2RlbHM7PGJyPg0KJmd0Ozxicj4NCiZndDsgKiAm cXVvdDtTdWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMmcXVvdDsgbW9k ZWw6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gYWxsb3dzIGZvciBhIGNs aWVudCB0byBkZWZpbmUgc3Vic2NyaWJhYmxlIGV2ZW50cyBhbmQgY29udGVudHMgb2YgZXZlbnQ8 YnI+DQomZ3Q7IG5vdGlmaWNhdGlvbnMgYXMgdGFyZ2V0LXRyaWdnZXItbm90aWZ5IHRyaXBsZXRz PGJyPg0KJmd0Ozxicj4NCiZndDsgKiAmcXVvdDtTbWFydCBmaWx0ZXJzIGZvciBQdXNoIFVwZGF0 ZXMmcXVvdDsgbW9kZWw6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gYWxs b3dzIGZvciBhIGNsaWVudCB0byBmaWx0ZXIgZXZlbnQgdHJpZ2dlcnMgYW5kIG5vdGlmaWNhdGlv bnMgb24gcHVzaDxicj4NCiZndDsgb2JqZWN0IHZhbHVlcyBhbmQgdGhlaXIgY2hhbmdlIGhpc3Rv cnksIGZvY3VzZXMgb24gJnF1b3Q7b3V0bGllcnMmcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBP YmplY3RpdmVzIG9mJm5ic3A7IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENv bnRyb2wgQXV0b21hdGlvbjxicj4NCiZndDsgMSkgVG8gZ2VuZXJhbGl6ZSB0YXJnZXQtdHJpZ2dl ci1ub3RpZnkgY29uY2VwdCBpbnRvIGV2ZW50LWNvbmRpdGlvbi1hY3Rpb248YnI+DQomZ3Q7IGNv bmNlcHQsIHdoZXJlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZXZlbnQgLSBhIHBhcnRpY3VsYXIgY2hhbmdlIGluIHRoZSBuZXR3b3JrIHN0YXRlIGV4cGxp Y2l0bHkgZGVmaW5lZCBieTxicj4NCiZndDsgb25lIG9mIHRoZSBZQU5HIG1vZGVscyBzdXBwb3J0 ZWQgYnkgdGhlIG5ldHdvcmsgb3IgaW1wbGljaXRseSBkZWZpbmVkIGJ5PGJyPg0KJmd0OyB0aGUg Y2xpZW50LCB3aGljaCBpcyBjb25zdGFudGx5IG1vbml0b3JlZCBieSB0aGUgbmV0d29yazs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmRpdGlvbiAtIGEg bG9naWNhbCBleHByZXNzaW9uIHRoYXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlciB0aGU8 YnI+DQomZ3Q7IGFzc29jaWF0ZWQgZXZlbnQgaXMgZGV0ZWN0ZWQ7PGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthY3Rpb24gLSBhbiBvcGVyYXRpb24gdG8gYmUg Y2FycmllZCBvdXQgYnkgdGhlIG5ldHdvcmsgd2hlbiB0aGUgYXNzb2NpYXRlZDxicj4NCiZndDsg ZXZlbnQgaXMgZGV0ZWN0ZWQgYW5kIHRoZSBhc3NvY2lhdGVkIGNvbmRpdGlvbiBpcyBtZXQ8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAyKSBUbyBwcm92aWRlIGZvciBhIGNsaWVudCBhIGNhcGFiaWxpdHkg dG8gY29uZmlndXJlIHRoZTxicj4NCiZndDsgZXZlbnQtY29uZGl0aW9uLWFjdGlvbiB0cmlwbGV0 cyBhcyBwb2xpY3kgcnVsZXMgYWhlYWQgb2YgdGltZSBvci9hbmQgZHVyaW5nPGJyPg0KJmd0OyBu ZXR3b3JrIG9wZXJhdGlvbnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBHZW5lcmFsaXplZCBBY3Rpb248 YnI+DQomZ3Q7ICogU2VuZCBub3RpZmljYXRpb248YnI+DQomZ3Q7ICogUGVyZm9ybSBpbW1lZGlh dGUgbmV0d29yayByZWNvbmZpZ3VyYXRpb24gKGUuZy4gbW9kaWZ5IG9uZSBvciBtb3JlPGJyPg0K Jmd0OyBhdHRyaWJ1dGVzIG9mIG9uZSBvciBtb3JlIENPTkZJRz1UUlVFIGRhdGEgc3RvcmUgbm9k ZXMpOzxicj4NCiZndDsgKiBTY2hlZHVsZSBvbmUgdGltZSBvciBwZXJpb2RpYyByZWNvbmZpZ3Vy YXRpb24gaW4gdGhlIGZ1dHVyZTs8YnI+DQomZ3Q7ICogQ2FsbCBSUEMgZGVmaW5lZCBieSBvbmUg b2YgdGhlIFlBTkcgbW9kZWxzIHN1cHBvcnRlZCBieSB0aGUgbmV0d29yayAoIGUuZy48YnI+DQom Z3Q7IGNhbGwgbmV0d29yaydzIHBhdGggY29tcHV0ZXIgdG8gZXZhbHVhdGUgd2hldGhlciBhbiBh bHRlcm5hdGl2ZS9tb3JlIG9wdGltYWw8YnI+DQomZ3Q7IHBhdGggaXMgYXZhaWxhYmxlIGZvciBh IGdpdmVuIGNvbm5lY3Rpb24pPGJyPg0KJmd0OyAqIExpbmsvdW5saW5rIGRhdGEgc3RvcmUgZHlu YW1pYyBzdWItdHJlZXM7PGJyPg0KJmd0OyAqIEV0Yy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWxh dGlvbnNoaXAgd2l0aCBQb2xpY3kgRnJhbWV3b3JrPGJyPg0KJmd0OyAqIFRoZSBmcmFtZXdvcmsg c2hvdWxkIHdvcmsgYXV0b25vbW91c2x5PGJyPg0KJmd0Ozxicj4NCiZndDsgKiBUaGUgZnJhbWV3 b3JrIHNob3VsZCBmaXQgd2VsbCB3aXRoaW4gYSBoaWdoZXIgbGV2ZWwgcG9saWN5IGZyYW1ld29y ayw8YnI+DQomZ3Q7IHdpdGggdGhlIGxhdHRlciBwb3NzaWJseSBwcm92aWRpbmcgYSBncmVhdGVy IGxldmVsIG9mIGF1dG9tYXRpb246PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDstIG11bHRpcGxlIG1p Y3JvLWNvbmRpdGlvbnMgY291bGQgYmUgY29tYmluZWQgaW50byBhIHNpbmdsZTxicj4NCiZndDsg bWFjcm8tY29uZGl0aW9uIHZpYSBhIG51bWJlciBvZiBsb2dpY2FsIG9wZXJhdGlvbnM7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDstIG11bHRpcGxlIG1pY3JvLWFjdGlvbnMgY291bGQgYmUgY29tYmlu ZWQgaW50byBhIHNpbmdsZSB0cmFuc2FjdGlvbiB3aXRoPGJyPg0KJmd0OyBhIHBvc3NpYmlsaXR5 IG9mIHNwZWNpZnlpbmcgcG9saWNpZXMgd2l0aCByZXNwZWN0IHRvIGhhbmRsaW5nPGJyPg0KJmd0 OyBlcnJvcnMvZXhjZXB0aW9ucyBvZiBlYWNoIG9mIHRoZSB0cmFuc2FjdGlvbiBjb21wb25lbnRz PGJyPg0KJmd0Ozxicj4NCiZndDsgRnJhbWV3b3JrIEJlbmVmaXRzPGJyPg0KJmd0OyAqIGxvd2Vy IGxhdGVuY3ksIGZhc3RlciByZXNwb25zaXZlbmVzcyBvZiB0aGUgbmV0d29yayB0byB2YXJpb3Vz PGJyPg0KJmd0OyBldmVudHMvY29uZGl0aW9uczs8YnI+DQomZ3Q7ICogYmV0dGVyIHNjYWxlIChl LmcuIHRoZSBjbGllbnQgbWF5IGNvbnRyb2wgbW9yZSBuZXR3b3JrcyBiZWNhdXNlIGl0IGRvZXM8 YnI+DQomZ3Q7IG5vdCBoYXZlIHRvIG1vbml0b3IvbWljcm8tbWFuYWdlIGFueSBvZiB0aGVtKTs8 YnI+DQomZ3Q7ICogQ1BVIGFuZCBiYW5kd2lkdGggc2F2aW5ncyBkdWUgdG8gdGhlIHJlZHVjZWQg YW1vdW50IG9mIGNvbW11bmljYXRpb24gYmV0d2Vlbjxicj4NCiZndDsgdGhlIGNsaWVudCBhbmQg dGhlIG5ldHdvcms8YnI+DQomZ3Q7ICogVGhlIGNsaWVudCBjYW4gdGFrZSBpdHNlbGYgb3V0IG9m IHRoZSBuZXR3b3JrIGNvbnRyb2wgbG9vcCwmbmJzcDsgY2hhbmdlIGl0czxicj4NCiZndDsgcm9s ZSBmcm9tIGJlaW5nIG5ldHdvcmsncyAmcXVvdDttaWNyby1tYW5hZ2VyJnF1b3Q7IHRvIGJlaW5n IG5ldHdvcmsncyAmcXVvdDtwb2xpY2U8YnI+DQomZ3Q7IG9mZmljZXImcXVvdDssIHdobyBpbnRl cmZlcmVzIGludG8gbmV0d29yayBvcGVyYXRpb25zIG9ubHkgaW48YnI+DQomZ3Q7IGV4Y2VwdGlv bmFsL3VucHJlZGljdGVkIHNpdHVhdGlvbnM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBp ZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5l dGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmci Pk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB867sjceml521mbxchi_-- From nobody Thu Nov 2 12:20:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B102813F59F for ; Thu, 2 Nov 2017 12:20: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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 vVDFzmlRGYzy for ; Thu, 2 Nov 2017 12:20:17 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 6E8EF137832 for ; Thu, 2 Nov 2017 12:20:16 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id r129so641499lff.8 for ; Thu, 02 Nov 2017 12:20:16 -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=rd9oYJgDKDQWSUaegJs/4FPVeEpmaPHfdeDsqOr7eO0=; b=X91USJTGejoL4YXNDRo1nVvvcFd994mA0ZkAKbB2Zu01pXl8gqjMnY7Yq/PRl1M+TL /lgIWWWLXUbDzCLPKYhi84if/pn8RbZmgjpHmRvoGDJ7RaQ4ApG5zfnvdaVBXmPXpduZ rwnQUHGuTfQY6UXZGN4rr+7Rb0MRmyGglphvtngKqAmqebGnl3yqf6b8B05JIA/BO0Ne 51npHcTQpqzORo5CKzTA+Dk3aF5c7mD+gZaM+jgSpXM/7t4rOdz6OVEBAoye0NKaNlbU DuXBj8ZVLrjV6vbh4i80rAYpfJ8D6cTxDCAzy7by7O/7Lr7zVVHHW78YyzWXM13nmmFr qkbA== 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=rd9oYJgDKDQWSUaegJs/4FPVeEpmaPHfdeDsqOr7eO0=; b=mDvLHmgNlQQe+KLSUemPjHdH6d0Iz0+TvfsLCibmIEbIyCQsNAsPaG1DpeiGacWONh J4JzzKUeIFJ2S8HIpkmVHNLpUiDqkVM7h7TlGTdWTONrkVdnldKCDqAqjeT/XJXoqbXc bg+X14Rljg97k0B0YkJHfnpSo/cQLCziSM+XKdUFGtW96HnsPpOpl6jrjCRjNxx+rIMl W/OIL0b22QNCGEaH/EOdh2i0dGUzrj246zcQXnQwdj5hnnVW5FWhO0VauyO4xja9TSgK zAkF3lwR90w2hHe7guR60TvWbIT2muUdpAJJQVdzkfByg9dZ3Sp5j6VmQuRp8mwuQhkI ioXg== X-Gm-Message-State: AJaThX7C1FIl0KUYe99jVASr+Q3W6tZFQCQS1r/ipzseKYVsPI6ca2Aw KenszE18pDBk8AoJu//bELGTwChOd29PGnULN0wWOg== X-Google-Smtp-Source: ABhQp+Qq7ya9r5cuuCcs5I27DEoIqeP4VYoJRabyKJk6cK1BHp+JNhtrGyAbllXgFy9uXkghPA+D29G2UoqLrKkb8i0= X-Received: by 10.25.22.194 with SMTP id 63mr1623277lfw.205.1509650414582; Thu, 02 Nov 2017 12:20:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 12:20:13 -0700 (PDT) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Thu, 2 Nov 2017 12:20:13 -0700 Message-ID: To: Alexander Clemm Cc: Igor Bryskin , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="001a113f2092b2535c055d04e068" Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 19:20:21 -0000 --001a113f2092b2535c055d04e068 Content-Type: text/plain; charset="UTF-8" Hi, I do not want to imply the IETF should work on a general-purpose scripting engine for YANG. IMO NETCONF and NETMOD have too many unfinished work items to start new ones right now. It would be prudent to get the chartered notification work finished before adding more features. Spot solutions that are intentionally incomplete and non-reusable are too expensive in the IETF. Andy On Thu, Nov 2, 2017 at 10:59 AM, Alexander Clemm wrote: > Hi, > > Clearly there is a case to be made for the ability of simple automation / > closed control loops on the server. > > Just a few comments regarding the role of YANG Push smart filters in this, > and where I view the boundary between them: > > - A smart filter allows to send updates only when certain filter > conditions regarding its values are met, possibly involving state. > Example: A threshold has been crossed, a high-water mark has been > breached. These updates clearly constitute "events" that can feed into an > event/condition/action rule. > - That said, the focus on smart filters is to be smart-yet-simple, > applying 90/10 rule. It is not the intention to make this assume the role > of a general "Event + Expression MIB". For examples, events that would > require cross-correlation comparing values across data items, processing > entire lists, computing aggregates over time, etc, would be outside the > scope. > - The assessment of any conditions would be left for the automation > framework. In other words, a smart filter will just assess the update > itself against a smart filter. It will not make additional checks with > regards to other data or take other actions as a result of the filter > before sending an event. That would be precisely left for the automation > stages. There is a reason that it's "event-condition-action", not simply > "trigger-action". > > --- Alex > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Igor > Bryskin > > Sent: Thursday, November 02, 2017 9:54 AM > > To: Tianran Zhou ; Xufeng Liu > > ; netconf@ietf.org > > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Hi Tianran, > > > > Thanks for your comments. > > > > Please, note that we see smart filters as a significant step from > current push > > machinery in evolution of network control automation, because it empowers > > the client to instruct the network to identify and focus on "outliers", > rather > > than on routine changes in the network State. I agree, this will impose > more > > complexity on the network, but the benefits are obvious. For example, > > instead of receiving tons of largely useless information, 99% of which > to be > > discarded after the processing, the client will be able to receive only > > "interesting" information WRT actionable events. The network control > > automation framework intends to make one step further in this evolution. > > We are basically asking "Why sending notifications is the only action > that > > could be triggered by model defined events and/or push subscriptions > > and/or smart filters"? Why, for example, pre-defined network re- > > configurations could not be triggered by smart filters? Why it is not > possible > > for the client to pre-configure d esired a ctions ahead of time?" > > > > Think about a battleship that just has been torpedoed. The crew members > > are not expected to just identify holes/leaks in the ship's bottom, > report the > > "telemetry" to the captain and wait for instructions on what to do next, > > right? Each crew member not only knows his/her pre-defined actions, (s)he > > is meticulously trained on a daily basis on how to carry out them in the > most > > efficient way. This is how ships survive problems like that. Also this > is how the > > same authority can control big and multiple ships. > > > > Cheers, > > Igor > > > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran > Zhou > > Sent: Wednesday, November 01, 2017 11:31 PM > > To: Xufeng Liu; netconf@ietf.org > > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Hi Xufeng, > > > > On the smart filters (also relates to https://tools.ietf.org/html/ > draft-clemm- > > netconf-push-smart-filters-ps-00), I think we need criteria to > carefully select > > "conditions". While there are many benefit, say save the bandwidth and > > relief the collector, it will add computation burden to network devices. > > Network devices are not good at this as servers. > > So maybe: > > 1. should not too complex to implement. > > 2. must help to mitigate the export volume. > > > > If so, for example, the average value should be out of scope, IMHO. > > > > Best, > > Tianran > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng > > > Liu > > > Sent: Thursday, November 02, 2017 3:31 AM > > > To: netconf@ietf.org > > > Subject: [Netconf] YANG PUSH Based Generalized Network Control > > > Automation Problem Statement > > > > > > Dear WG, > > > > > > The Yang-push Dezign Team has been working on the Yang push > > enhancement. > > > We have posted a draft on the problem statement to extend Yang push to > > > a more generalized network control automation framework. > > > > > > The following is the summary of this topic. Any comments, thoughts, > > > and suggestions are appreciated. > > > > > > Thanks, > > > - Xufeng > > > > > > ================ > > > YANG PUSH Based Generalized Network Control Automation > > > draft-bryskin-netconf-automation-framework-00 > > > > > > Evolution of YANG Based Network Automation > > > * "Custom Subscription to Event Notifications" model : > > > - allows for a client to subscribe to unsolicited event > notifications > > > defined by supported YANG models; > > > > > > * "Subscribing to YANG datastore push updates" model: > > > - allows for a client to define subscribable events and contents of > > > event notifications as target-trigger-notify triplets > > > > > > * "Smart filters for Push Updates" model: > > > - allows for a client to filter event triggers and notifications on > > > push object values and their change history, focuses on "outliers" > > > > > > Objectives of YANG PUSH Based Generalized Network Control Automation > > > 1) To generalize target-trigger-notify concept into > > > event-condition-action concept, where: > > > > > > event - a particular change in the network state explicitly defined > > > by one of the YANG models supported by the network or implicitly > > > defined by the client, which is constantly monitored by the network; > > > > > > condition - a logical expression that is evaluated only once after > > > the associated event is detected; > > > > > > action - an operation to be carried out by the network when the > > > associated event is detected and the associated condition is met > > > > > > 2) To provide for a client a capability to configure the > > > event-condition-action triplets as policy rules ahead of time or/and > > > during network operations > > > > > > Generalized Action > > > * Send notification > > > * Perform immediate network reconfiguration (e.g. modify one or more > > > attributes of one or more CONFIG=TRUE data store nodes); > > > * Schedule one time or periodic reconfiguration in the future; > > > * Call RPC defined by one of the YANG models supported by the network ( > > e.g. > > > call network's path computer to evaluate whether an alternative/more > > > optimal path is available for a given connection) > > > * Link/unlink data store dynamic sub-trees; > > > * Etc. > > > > > > Relationship with Policy Framework > > > * The framework should work autonomously > > > > > > * The framework should fit well within a higher level policy > > > framework, with the latter possibly providing a greater level of > automation: > > > - multiple micro-conditions could be combined into a single > > > macro-condition via a number of logical operations; > > > - multiple micro-actions could be combined into a single transaction > > > with a possibility of specifying policies with respect to handling > > > errors/exceptions of each of the transaction components > > > > > > Framework Benefits > > > * lower latency, faster responsiveness of the network to various > > > events/conditions; > > > * better scale (e.g. the client may control more networks because it > > > does not have to monitor/micro-manage any of them); > > > * CPU and bandwidth savings due to the reduced amount of > > communication > > > between the client and the network > > > * The client can take itself out of the network control loop, change > > > its role from being network's "micro-manager" to being network's > > > "police officer", who interferes into network operations only in > > > exceptional/unpredicted situations > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113f2092b2535c055d04e068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


I do not want to imp= ly the IETF should work on a general-purpose scripting engine for YANG.
IMO NETCONF and NETMOD have too many unfinished work items to start = new ones right now.
It would be prudent to get the chartered noti= fication work finished before adding more features.

Spot solutions that are intentionally incomplete and non-reusable are too= expensive in the IETF.


Andy
<= div>

On Thu, Nov 2, 2017 at 10:59 AM, Alexander Clemm <<= a href=3D"mailto:alexander.clemm@huawei.com" target=3D"_blank">alexander.cl= emm@huawei.com> wrote:
Hi,<= br>
Clearly there is a case to be made for the ability of simple automation / c= losed control loops on the server.

Just a few comments regarding the role of YANG Push smart filters in this, = and where I view the boundary between them:

- A smart filter allows to send updates only when certain filter conditions= regarding its values are met, possibly involving state.=C2=A0 Example: A t= hreshold has been crossed, a high-water mark has been breached.=C2=A0 These= updates clearly constitute "events" that can feed into an event/= condition/action rule.
- That said, the focus on smart filters is to be smart-yet-simple, applying= 90/10 rule.=C2=A0 It is not the intention to make this assume the role of = a general "Event + Expression MIB".=C2=A0 =C2=A0For examples, eve= nts that would require cross-correlation comparing values across data items= , processing entire lists, computing aggregates over time, etc, would be ou= tside the scope.
- The assessment of any conditions would be left for the automation framewo= rk.=C2=A0 In other words, a smart filter will just assess the update itself= against a smart filter.=C2=A0 It will not make additional checks with rega= rds to other data or take other actions as a result of the filter before se= nding an event.=C2=A0 That would be precisely left for the automation stage= s.=C2=A0 There is a reason that it's "event-condition-action"= , not simply "trigger-action".

--- Alex


> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Igor Bryskin
> Sent: Thursday, November 02, 2017 9:54 AM
> To: Tianran Zhou <zhoutia= nran@huawei.com>; Xufeng Liu
> <Xufeng_Liu@jabil.com&g= t;; netconf@ietf.org
> Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control
> Automation Problem Statement
>
> Hi Tianran,
>
> Thanks for your comments.
>
> Please, note that we see smart filters as a significant step from curr= ent push
> machinery in evolution of network control automation, because it empow= ers
> the client to instruct the network to identify and focus on "outl= iers", rather
> than on routine changes in the network State. I agree, this will impos= e more
> complexity on the network, but the benefits are obvious. For example,<= br> > instead of receiving tons of largely useless information, 99% of which= to be
> discarded after the processing, the client will be able to receive onl= y
> "interesting" information WRT actionable events. The network= control
> automation framework intends to make one step further in this evolutio= n.
> We are basically asking "Why sending notifications is the only ac= tion that
> could be triggered by model defined events and/or push subscriptions > and/or smart filters"? Why, for example, pre-defined network re-<= br> > configurations could not be triggered by smart filters? Why it is not = possible
> for the client to pre-configure d=C2=A0 esired a=C2=A0 ctions ahead of= time?"
>
> Think about a battleship that just has been torpedoed. The crew member= s
> are not expected to just identify holes/leaks in the ship's bottom= , report the
> "telemetry" to the captain and wait for instructions on what= to do next,
> right? Each crew member not only knows his/her pre-defined actions, (s= )he
> is meticulously trained on a daily basis on how to carry out them in t= he most
> efficient way. This is how ships survive problems like that. Also this= is how the
> same authority can control big and multiple ships.
>
> Cheers,
> Igor
>
>
> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Tianran Zhou
> Sent: Wednesday, November 01, 2017 11:31 PM
> To: Xufeng Liu; netconf@ietf.org
> Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control
> Automation Problem Statement
>
> Hi Xufeng,
>
> On the smart filters (also relates to https://tools.iet= f.org/html/draft-clemm-
> netconf-push-smart-filters-ps-00), I think we need criteria to ca= refully select
> "conditions". While there are many benefit, say save the ban= dwidth and
> relief the collector, it will add computation burden to network device= s.
> Network devices are not good at this as servers.
> So maybe:
> 1. should not too complex to implement.
> 2. must help to mitigate the export volume.
>
> If so, for example, the average value should be out of scope, IMHO. >
> Best,
> Tianran
>
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng
> > Liu
> > Sent: Thursday, November 02, 2017 3:31 AM
> > To: netconf@ietf.org
> > Subject: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement
> >
> > Dear WG,
> >
> > The Yang-push Dezign Team has been working on the Yang push
> enhancement.
> > We have posted a draft on the problem statement to extend Yang pu= sh to
> > a more generalized network control automation framework.
> >
> > The following is the summary of this topic. Any comments, thought= s,
> > and suggestions are appreciated.
> >
> > Thanks,
> > - Xufeng
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > YANG PUSH Based Generalized Network Control Automation
> > draft-bryskin-netconf-automation-framework-00
> >
> > Evolution of YANG Based Network Automation
> > * "Custom Subscription to Event Notifications" model :<= br> > >=C2=A0 =C2=A0 =C2=A0- allows for a client to subscribe to unsolici= ted event notifications
> > defined by supported YANG models;
> >
> > * "Subscribing to YANG datastore push updates" model: > >=C2=A0 =C2=A0 =C2=A0- allows for a client to define subscribable e= vents and contents of
> > event notifications as target-trigger-notify triplets
> >
> > * "Smart filters for Push Updates" model:
> >=C2=A0 =C2=A0 =C2=A0- allows for a client to filter event triggers= and notifications on
> > push object values and their change history, focuses on "out= liers"
> >
> > Objectives of=C2=A0 YANG PUSH Based Generalized Network Control A= utomation
> > 1) To generalize target-trigger-notify concept into
> > event-condition-action concept, where:
> >
> >=C2=A0 =C2=A0 =C2=A0event - a particular change in the network sta= te explicitly defined
> > by one of the YANG models supported by the network or implicitly<= br> > > defined by the client, which is constantly monitored by the netwo= rk;
> >
> >=C2=A0 =C2=A0 =C2=A0condition - a logical expression that is evalu= ated only once after
> > the associated event is detected;
> >
> >=C2=A0 =C2=A0 =C2=A0action - an operation to be carried out by the= network when the
> > associated event is detected and the associated condition is met<= br> > >
> > 2) To provide for a client a capability to configure the
> > event-condition-action triplets as policy rules ahead of time or/= and
> > during network operations
> >
> > Generalized Action
> > * Send notification
> > * Perform immediate network reconfiguration (e.g. modify one or m= ore
> > attributes of one or more CONFIG=3DTRUE data store nodes);
> > * Schedule one time or periodic reconfiguration in the future; > > * Call RPC defined by one of the YANG models supported by the net= work (
> e.g.
> > call network's path computer to evaluate whether an alternati= ve/more
> > optimal path is available for a given connection)
> > * Link/unlink data store dynamic sub-trees;
> > * Etc.
> >
> > Relationship with Policy Framework
> > * The framework should work autonomously
> >
> > * The framework should fit well within a higher level policy
> > framework, with the latter possibly providing a greater level of = automation:
> >=C2=A0 =C2=A0- multiple micro-conditions could be combined into a = single
> > macro-condition via a number of logical operations;
> >=C2=A0 =C2=A0- multiple micro-actions could be combined into a sin= gle transaction
> > with a possibility of specifying policies with respect to handlin= g
> > errors/exceptions of each of the transaction components
> >
> > Framework Benefits
> > * lower latency, faster responsiveness of the network to various<= br> > > events/conditions;
> > * better scale (e.g. the client may control more networks because= it
> > does not have to monitor/micro-manage any of them);
> > * CPU and bandwidth savings due to the reduced amount of
> communication
> > between the client and the network
> > * The client can take itself out of the network control loop,=C2= =A0 change
> > its role from being network's "micro-manager" to be= ing network's
> > "police officer", who interferes into network operation= s only in
> > exceptional/unpredicted situations
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ne= tconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a113f2092b2535c055d04e068-- From nobody Thu Nov 2 12:42:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59FF13F8E4 for ; Thu, 2 Nov 2017 12:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHGLHHX40TZW for ; Thu, 2 Nov 2017 12:42:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BAA13F8E3 for ; Thu, 2 Nov 2017 12:42:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZD40946; Thu, 02 Nov 2017 19:42:10 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 19:42:09 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 12:41:59 -0700 From: Igor Bryskin To: Alexander Clemm , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAA96CMAADyeoA Date: Thu, 2 Nov 2017 19:41:59 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C19355F@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59FB7512.02F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a19e6a6149ac33c98f289bbe0730ca1 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 19:42:16 -0000 Hi Alex, Thanks for your thoughtful comments. Please, see in-line. Igor -----Original Message----- From: Alexander Clemm=20 Sent: Thursday, November 02, 2017 2:00 PM To: Igor Bryskin; Tianran Zhou; Xufeng Liu; netconf@ietf.org Subject: RE: YANG PUSH Based Generalized Network Control Automation Problem= Statement Hi, Clearly there is a case to be made for the ability of simple automation / c= losed control loops on the server. =20 Just a few comments regarding the role of YANG Push smart filters in this, = and where I view the boundary between them: - A smart filter allows to send updates only when certain filter conditions= regarding its values are met, possibly involving state. Example: A thresh= old has been crossed, a high-water mark has been breached. These updates c= learly constitute "events" that can feed into an event/condition/action rul= e.=20 IB>> Exactly. For example, consider the logic: if(link's bandwidth utilization > 80% threshold) /* smart filter */ configure parallel link /* generalized action */ If the client knows that this is what needs to be done in such an event, wh= y not to say that ahead of time instead of processing the link's telemetry = and asking for the action reactively? =20 =20 - That said, the focus on smart filters is to be smart-yet-simple, applying= 90/10 rule. It is not the intention to make this assume the role of a gen= eral "Event + Expression MIB". For examples, events that would require cr= oss-correlation comparing values across data items, processing entire lists= , computing aggregates over time, etc, would be outside the scope. =20 IB>> Fair enough. But sending notification and relying on a higher (client'= s) intelligence is one of the actions, but it is not the only one. How the = client's and network's intelligences are split could be optimized and best = compromises found =20 =20 - The assessment of any conditions would be left for the automation framewo= rk. In other words, a smart filter will just assess the update itself agai= nst a smart filter. It will not make additional checks with regards to oth= er data or take other actions as a result of the filter before sending an e= vent. That would be precisely left for the automation stages. There is a = reason that it's "event-condition-action", not simply "trigger-action".=20 IB>> agree =20 --- Alex > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Igor Bryskin > Sent: Thursday, November 02, 2017 9:54 AM > To: Tianran Zhou ; Xufeng Liu > ; netconf@ietf.org > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > Automation Problem Statement >=20 > Hi Tianran, >=20 > Thanks for your comments. >=20 > Please, note that we see smart filters as a significant step from current= push > machinery in evolution of network control automation, because it empowers > the client to instruct the network to identify and focus on "outliers", r= ather > than on routine changes in the network State. I agree, this will impose m= ore > complexity on the network, but the benefits are obvious. For example, > instead of receiving tons of largely useless information, 99% of which to= be > discarded after the processing, the client will be able to receive only > "interesting" information WRT actionable events. The network control > automation framework intends to make one step further in this evolution. > We are basically asking "Why sending notifications is the only action tha= t > could be triggered by model defined events and/or push subscriptions > and/or smart filters"? Why, for example, pre-defined network re- > configurations could not be triggered by smart filters? Why it is not pos= sible > for the client to pre-configure d esired a ctions ahead of time?" >=20 > Think about a battleship that just has been torpedoed. The crew members > are not expected to just identify holes/leaks in the ship's bottom, repor= t the > "telemetry" to the captain and wait for instructions on what to do next, > right? Each crew member not only knows his/her pre-defined actions, (s)he > is meticulously trained on a daily basis on how to carry out them in the = most > efficient way. This is how ships survive problems like that. Also this is= how the > same authority can control big and multiple ships. >=20 > Cheers, > Igor >=20 >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Wednesday, November 01, 2017 11:31 PM > To: Xufeng Liu; netconf@ietf.org > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > Automation Problem Statement >=20 > Hi Xufeng, >=20 > On the smart filters (also relates to https://tools.ietf.org/html/draft-c= lemm- > netconf-push-smart-filters-ps-00), I think we need criteria to carefully = select > "conditions". While there are many benefit, say save the bandwidth and > relief the collector, it will add computation burden to network devices. > Network devices are not good at this as servers. > So maybe: > 1. should not too complex to implement. > 2. must help to mitigate the export volume. >=20 > If so, for example, the average value should be out of scope, IMHO. >=20 > Best, > Tianran >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng > > Liu > > Sent: Thursday, November 02, 2017 3:31 AM > > To: netconf@ietf.org > > Subject: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Dear WG, > > > > The Yang-push Dezign Team has been working on the Yang push > enhancement. > > We have posted a draft on the problem statement to extend Yang push to > > a more generalized network control automation framework. > > > > The following is the summary of this topic. Any comments, thoughts, > > and suggestions are appreciated. > > > > Thanks, > > - Xufeng > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > YANG PUSH Based Generalized Network Control Automation > > draft-bryskin-netconf-automation-framework-00 > > > > Evolution of YANG Based Network Automation > > * "Custom Subscription to Event Notifications" model : > > - allows for a client to subscribe to unsolicited event notifications > > defined by supported YANG models; > > > > * "Subscribing to YANG datastore push updates" model: > > - allows for a client to define subscribable events and contents of > > event notifications as target-trigger-notify triplets > > > > * "Smart filters for Push Updates" model: > > - allows for a client to filter event triggers and notifications on > > push object values and their change history, focuses on "outliers" > > > > Objectives of YANG PUSH Based Generalized Network Control Automation > > 1) To generalize target-trigger-notify concept into > > event-condition-action concept, where: > > > > event - a particular change in the network state explicitly defined > > by one of the YANG models supported by the network or implicitly > > defined by the client, which is constantly monitored by the network; > > > > condition - a logical expression that is evaluated only once after > > the associated event is detected; > > > > action - an operation to be carried out by the network when the > > associated event is detected and the associated condition is met > > > > 2) To provide for a client a capability to configure the > > event-condition-action triplets as policy rules ahead of time or/and > > during network operations > > > > Generalized Action > > * Send notification > > * Perform immediate network reconfiguration (e.g. modify one or more > > attributes of one or more CONFIG=3DTRUE data store nodes); > > * Schedule one time or periodic reconfiguration in the future; > > * Call RPC defined by one of the YANG models supported by the network ( > e.g. > > call network's path computer to evaluate whether an alternative/more > > optimal path is available for a given connection) > > * Link/unlink data store dynamic sub-trees; > > * Etc. > > > > Relationship with Policy Framework > > * The framework should work autonomously > > > > * The framework should fit well within a higher level policy > > framework, with the latter possibly providing a greater level of automa= tion: > > - multiple micro-conditions could be combined into a single > > macro-condition via a number of logical operations; > > - multiple micro-actions could be combined into a single transaction > > with a possibility of specifying policies with respect to handling > > errors/exceptions of each of the transaction components > > > > Framework Benefits > > * lower latency, faster responsiveness of the network to various > > events/conditions; > > * better scale (e.g. the client may control more networks because it > > does not have to monitor/micro-manage any of them); > > * CPU and bandwidth savings due to the reduced amount of > communication > > between the client and the network > > * The client can take itself out of the network control loop, change > > its role from being network's "micro-manager" to being network's > > "police officer", who interferes into network operations only in > > exceptional/unpredicted situations > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 2 15:18:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043E013FA0D for ; Thu, 2 Nov 2017 15:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 ihuanvBZEVdN for ; Thu, 2 Nov 2017 15:18:47 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.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 6937F13F9E1 for ; Thu, 2 Nov 2017 15:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5NSn9CXUmp+nM7yUcBXq9pY6M0wNubRI8Y1n+N1F1RY=; b=WhIGZQDo91EeGfHmjadtSzIKg14BX2xbf51kiYHxeuDNtzIZ3fXAp84qEDCEPvKZpEeyy0rdfKCpVAybOdj5gvMUXY3bz13PLgW1PysGGdTY9RFR8uStASAEDJPGprE5HZ/Ne9Lu0A7iX9jbV2Sw3JqLrOtthuWN9hYH7G55LlM= Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB277.namprd05.prod.outlook.com (10.141.64.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 22:18:46 +0000 Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2166:7ba5:2c5:271a]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2166:7ba5:2c5:271a%14]) with mapi id 15.20.0197.013; Thu, 2 Nov 2017 22:18:46 +0000 From: Kent Watsen To: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [Netconf] WGLC on zerotouch draft Thread-Index: AQHTSo2X/9y7wRXxl0KFrYdSEL3me6MBeO6A Date: Thu, 2 Nov 2017 22:18:45 +0000 Message-ID: <3DD3AB41-F3DD-41DC-AB4F-ADD0C9B9E2BF@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/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN1PR05MB277; 6:LZ7/01Kk7l7WlB984TjW1/JkIw0Hemn+RhIix81boAc64IyQN8ILuRl85BidcBiXWS8jCgGWJFgEAUZrlpaH9aAJ7USAA9lyJ3cDe3nF6LvVJ2Qs8Njdedd5pK4KrjLPq1zPO1sJFj49JelPD28DMuVILbXsRErbLZEOOeKBuYxeQVAKRa/oxaq5ugAIHc4Gg8Pwm6dVFwfbnMZAEBjzlo1jpThrN+S+Wbr3kmcQcgCTi+EUuLHb122snp4F3VGPP1ztqBJ2fgjeDA/aDbviCywmCyBZFZO3Fgaa4HRuh/OM6ZvW/O3oTcbsxrN1dlHMtz9hcdy6FUaQAjf8llWt/EuIAVOnWdsA92ngBqeZLn8=; 5:oxf4dbnfdQQU4hXmo1DGXTB2Sw46Q0ZSwx10rnwy3PUL2jvgBGgcDbireWoKu+Dzb+LjSD4MeUqe+daktfyDq1W6zIAF7xR9Rl99sDDgvBLXrL5rWAbSCgmOAuyS0hwYTbSB3t6Uns//OhkJEfNKbBtMGpr7yvZEkXVqqSlcOyI=; 24:OVptfR00JmM/qclugPcYji/5D8mNEjyAiilKgk28xL5xe1H/KiCVhhFwsgy7DOPDnd1eF4AZPJUE17FlXawLWempRgxcSF9LXR3/GQaE0Ts=; 7:ON7xeypkJxpOjfAHSyiIWmRVS2IBiw1+0ayVare1Mf9G59dP4MjeIXfkU3cUdR6A9edwiL/51h1DdANZ3RLRs3/yZSYM2Oy9webKqT5tKxntNUTm1ehnqHrjU4QfCEGSZxLSsPlTn5bA6ZcjHSXIGhvb4wYEh0ffmVs8i8uOIpmAS3lYUI5RZ6l8XrAZAeQ6KlG1hbfE7BC3seLqelEnCV7wqtqViVc+meo0p1C5d1l0lf6ePYw0Cp55pRU9qe/X x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8616bf2c-6530-4482-71df-08d5223faf30 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:BN1PR05MB277; x-ms-traffictypediagnostic: BN1PR05MB277: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB277; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(53754006)(2900100001)(58126008)(110136005)(189998001)(83716003)(86362001)(316002)(106356001)(2950100002)(39060400002)(3280700002)(2501003)(97736004)(6486002)(66066001)(6506006)(99286004)(229853002)(5250100002)(14454004)(6436002)(76176999)(54356999)(6512007)(83506002)(5660300001)(68736007)(36756003)(305945005)(101416001)(7736002)(53936002)(50986999)(478600001)(8936002)(3660700001)(33656002)(6246003)(105586002)(81156014)(81166006)(82746002)(8676002)(3846002)(102836003)(2906002)(6116002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB277; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 8616bf2c-6530-4482-71df-08d5223faf30 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 22:18:45.8546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB277 Archived-At: Subject: Re: [Netconf] WGLC on zerotouch draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 22:18:49 -0000 DQpIaSBBbGwsDQoNCk9uZSBvZiBvdXIgZGV2ZWxvcG1lbnQgdGVhbXMganVzdCByZWNlaXZlZCBh IHJlcXVlc3QgZnJvbSBhbiBvcGVyYXRvciB0aGF0IGlzbid0IHVzaW5nIGEgcHJpdmF0ZSBQS0ks IGFuZCB0aGVyZWZvcmUgYXJlIHVzaW5nIGEgcHVibGljIENBIChlLmcuLCBHb0RhZGR5KS4gIFNv LCBmb3IgdGhlbSwgdGhlIGNlcnRpZmljYXRlIGNoYWluIG1pZ2h0IGxvb2sgbGlrZToNCg0KICAg R29EYWRkeSBDQQ0KICAgICBeDQogICAgIHwNCiAgICBPcmcgQ0ENCiAgICAgXg0KICAgICB8DQog ICAgWlRQIENBDQogICAgIF4NCiAgICAgfA0KICBCb290c3RyYXAgc2VydmVyJ3MgVExTIGNlcnQN Cg0KSnVzdCBwdXR0aW5nIHRoZSAiT3JnIENBIiBhcyB0aGUgcGlubmVkIGRvbWFpbiBjZXJ0IGRv ZXNuJ3Qgd29yayB3aXRoIHNvbWUgY29tbW9uIG9wZW4gc291cmNlIHV0aWxpdGllcywgYmVjYXVz ZSB0aGV5IGRvbid0IHN1cHBvcnQgd2hhdCBPcGVuU1NMIGNhbGxzICJwYXJ0aWFsIGNoYWluIiB2 ZXJpZmljYXRpb24uICBBbmQsIG9mIGNvdXJzZSwgcHV0dGluZyAiR29EYWRkeSBDQSIgYXMgdGhl IHBpbm5lZCBkb21haW4gY2VydCB3b3VsZCBiZSBvdmVybHkgcGVybWlzc2l2ZS4gIFdoYXQncyBu ZWVkZWQgaXMgYSB3YXkgZm9yIHRoZW0gdG8gc3BlY2lmeSB0aGUgcGFydGlhbCBjaGFpbiBsZWFk aW5nIHVwIHRvIGFuZCBpbmNsdWRpbmcgdGhlIHJvb3QgY2VydGlmaWNhdGUuICBTbywgZm9yIGlu c3RhbmNlLCBpbiB0aGlzIGNhc2UsIHRoZXknZCBsaWtlIHRoZSByZWRpcmVjdCBzZXJ2ZXIgdG8g cmV0dXJuIHRoZSBjaGFpbjoNCg0KICBHb0RhZGR5IENBDQogICAgIF4NCiAgICAgfA0KICAgT3Jn IENBDQoNCmFuZCB0aGUgYm9vdHN0cmFwIHNlcnZlcidzIFRMUyBoYW5kc2hha2UgdG8gcmV0dXJu Og0KDQogICBaVFAgQ0ENCiAgICAgXg0KICAgICB8DQogIEJvb3RzdHJhcCBzZXJ2ZXIncyBUTFMg Y2VydA0KDQp3aGljaCBwcm92aWRlcyB0aGUgVExTIGNsaWVudCBldmVyeXRoaW5nIGl0IG5lZWRz IHRvIHZlcmlmeSB0aGUgY2hhaW4uDQpGcm9tIGEgdHJlZS1kaWFncmFtIHBlcnNwZWN0aXZlLCB0 aGUgY2hhbmdlIGxvb2tzIGxpa2UgdGhpczoNCg0KT0xEDQoNCiAgICstLToocmVkaXJlY3QtaW5m b3JtYXRpb24pDQogICAgICArLS0tLSByZWRpcmVjdC1pbmZvcm1hdGlvbg0KICAgICAgICAgKy0t LS0gYm9vdHN0cmFwLXNlcnZlciogW2FkZHJlc3NdDQogICAgICAgICAgICArLS0tLSBhZGRyZXNz ICAgICAgICAgaW5ldDpob3N0DQogICAgICAgICAgICArLS0tLSBwb3J0PyAgICAgICAgICAgaW5l dDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgKy0tLS0gdHJ1c3QtYW5jaG9yPyAgIGJpbmFyeSAg IDwtLSBhIHNpbmdsZSBYLjUwOSBjZXJ0aWZpY2F0ZXMNCg0KTkVXDQoNCiAgICstLToocmVkaXJl Y3QtaW5mb3JtYXRpb24pDQogICAgICArLS0tLSByZWRpcmVjdC1pbmZvcm1hdGlvbg0KICAgICAg ICAgKy0tLS0gYm9vdHN0cmFwLXNlcnZlciogW2FkZHJlc3NdDQogICAgICAgICAgICArLS0tLSBh ZGRyZXNzICAgICAgICAgaW5ldDpob3N0DQogICAgICAgICAgICArLS0tLSBwb3J0PyAgICAgICAg ICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgKy0tLS0gdHJ1c3QtYW5jaG9yPyAgIHBr Y3M3ICA8LS0gYSBjaGFpbiBvZiBYLjUwOSBjZXJ0aWZpY2F0ZQ0KCQ0KDQpIZXJlJ3Mgd2hhdCB0 aGUgZGlmZiBsb29rcyBsaWtlOg0KDQogICAgICAgICAgIGxlYWYgdHJ1c3QtYW5jaG9yIHsNCi0g ICAgICAgICAgICB0eXBlIGJpbmFyeTsNCisgICAgICAgICAgICB0eXBlIHBrY3M3Ow0KICAgICAg ICAgICAgIGRlc2NyaXB0aW9uDQotICAgICAgICAgICAgICAiQW4gWC41MDkgdjMgY2VydGlmaWNh dGUgc3RydWN0dXJlIGFzIHNwZWNpZmllZCBieSBSRkMNCi0gICAgICAgICAgICAgICA1MjgwLCBT ZWN0aW9uIDQsIGVuY29kZWQgdXNpbmcgQVNOLjEgZGlzdGluZ3Vpc2hlZA0KLSAgICAgICAgICAg ICAgIGVuY29kaW5nIHJ1bGVzIChERVIpLCBhcyBzcGVjaWZpZWQgaW4gSVRVLVQgWC42OTAuICBB DQotICAgICAgICAgICAgICAgY2VydGlmaWNhdGUgdGhhdCB0aGUgZGV2aWNlIGNhbiB1c2UgYXMg dGhlIHRydXN0IGFuY2hvcg0KLSAgICAgICAgICAgICAgIHRvIGF1dGhlbnRpY2F0ZSB0aGUgYm9v dHN0cmFwIHNlcnZlciB0aGUgZGV2aWNlIGlzDQotICAgICAgICAgICAgICAgYmVpbmcgcmVkaXJl Y3RlZCB0by4gIElmIG5vdCBzcGVjaWZpZWQsIHRoZSBkZXZpY2UgbWF5DQotICAgICAgICAgICAg ICAgZXN0YWJsaXNoIGEgcHJvdmlzaW9uYWwgY29ubmVjdGlvbiB0byB0aGUgYm9vdHN0cmFwDQot ICAgICAgICAgICAgICAgc2VydmVyLCBhcyBkZXNjcmliZWQgaW4gUkZDIFhYWFguIjsNCisgICAg ICAgICAgICAgICJUaGlzIFBLQ1MjNyBzdHJ1Y3R1cmUgTVVTVCBjb250YWluIHRoZSBwaW5uZWQg ZG9tYWluDQorICAgICAgICAgICAgICAgY2VydGlmaWNhdGUgYW5kIGFsbCBpbnRlcm1lZGlhdGUg Y2VydGlmaWNhdGVzIGxlYWRpbmcNCisgICAgICAgICAgICAgICB1cCB0byB0aGUgcm9vdCBjZXJ0 aWZpY2F0ZSwgYW5kIHRoZSByb290IGNlcnRpZmljYXRlDQorICAgICAgICAgICAgICAgaXRzZWxm LiAgSW4gY2FzZXMgd2hlcmUgdGhlIHBpbm5lZCBkb21haW4gY2VydGlmaWNhdGUNCisgICAgICAg ICAgICAgICBpcyBhIHJvb3QgY2VydGlmaWNhdGUsIG9ubHkgb25lIFguNTA5IGNlcnRpZmljYXRl IGlzDQorICAgICAgICAgICAgICAgcHJlc2VudC4gIEFkZGl0aW9uYWxseSwgaWYgbmVlZGVkIGJ5 IHRoZSBkZXZpY2UsIHRoaXMNCisgICAgICAgICAgICAgICBzdHJ1Y3R1cmUgTUFZIGFsc28gY29u dGFpbiBzdWl0YWJseSBmcmVzaCBDUkwgYW5kL29yDQorICAgICAgICAgICAgICAgT0NTUCBSZXNw b25zZXMgd2l0aCB3aGljaCB0byB2ZXJpZnkgdGhlIHJldm9jYXRpb24NCisgICAgICAgICAgICAg ICBzdGF0dXMgb2YgdGhlIGNlcnRpZmljYXRlcy4NCisgICAgICANCisgICAgICAgICAgICAgICBY LjUwOSBjZXJ0aWZpY2F0ZXMgYW5kIENSTHMgYXJlIGRlc2NyaWJlZCBpbiBSRkMgNTI4MC4NCisg ICAgICAgICAgICAgICBPQ1NQIFJlc3BvbnNlcyBhcmUgZGVzY3JpYmVkIGluIFJGQyA2OTYwLiI7 DQoNCg0KV2UgY2FuIGRpc2N1c3MgbW9yZSBpbiBTaW5nYXBvcmUuDQoNClRoYW5rcywNCktlbnQN Cg0KDQoNCg== From nobody Thu Nov 2 15:37:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A9B13F719 for ; Thu, 2 Nov 2017 15:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx0zU0vxKklb for ; Thu, 2 Nov 2017 15:37:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111FB13F679 for ; Thu, 2 Nov 2017 15:37:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZD49756; Thu, 02 Nov 2017 22:37:14 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 2 Nov 2017 22:37:12 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Thu, 2 Nov 2017 15:36:59 -0700 From: Alexander Clemm To: Andy Bierman CC: Igor Bryskin , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAA96CMAASltWAAAgNJbA= Date: Thu, 2 Nov 2017 22:36:59 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABBAB1@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@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.213.48.40] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABBAB1sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59FB9E1B.0074, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0b7b6a4b944968d194322c5e2bc6ecde Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 22:37:21 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABBAB1sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2Ugc2hvdWxkIGZpbmlzaCB0aGUgY2hhcnRlcmVkIHdvcmsgZmlyc3QuICBIb3BlZnVs bHkgdGhpcyBpcyBub3QgdG9vIGZhciBvZmYuLi4gIENsZWFybHkgd2UgZG9u4oCZdCB3YW50IHRv IGRlbGF5LCBidXQgSSBkb27igJl0IHRoaW5rIGl0IGlzIHRvbyBlYXJseSB0byBzdGFydCB0aGlu a2luZyBhYm91dCB3aGF0IHNob3VsZCBiZSBwdXQgaW4gdGhlIHBpcGVsaW5lIG5leHQ/ICBUaGUg ZmFjdCB0aGF0IHRoZXJlIGlzIG1vcmUgZGVtYW5kIHRvIGJ1aWxkIG9uIHRoZSBleGlzdGluZyBw bGF0Zm9ybSBhbmQgYWRkIHRvIGl0IHNob3VsZCBiZSBhIGdvb2QgdGhpbmcuICBOZXRjb25mIGhh cyBiZWVuIHZlcnkgY29uZmlndXJhdGlvbiAvIGZ1bGZpbGxtZW50IG9yaWVudGVkIHNvIGZhci4g IFRoZSBub3RpZmljYXRpb24vc3Vic2NyaXB0aW9uL3B1c2ggd29yayBvcGVucyB1cCB0aGUgZG9v ciBmb3IgYW5vdGhlciBmaWVsZCwgYXNzdXJhbmNlLiAgVGhpcyBpcyBhIGJpZyBvcHBvcnR1bml0 eS4NCi0tLSBBbGV4DQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAxMjoyMCBQTQ0KVG86IEFs ZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+DQpDYzogSWdvciBCcnlz a2luIDxJZ29yLkJyeXNraW5AaHVhd2VpLmNvbT47IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5A aHVhd2VpLmNvbT47IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPjsgbmV0Y29uZkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6 ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24gUHJvYmxlbSBTdGF0ZW1lbnQNCg0KSGksDQoN Cg0KSSBkbyBub3Qgd2FudCB0byBpbXBseSB0aGUgSUVURiBzaG91bGQgd29yayBvbiBhIGdlbmVy YWwtcHVycG9zZSBzY3JpcHRpbmcgZW5naW5lIGZvciBZQU5HLg0KSU1PIE5FVENPTkYgYW5kIE5F VE1PRCBoYXZlIHRvbyBtYW55IHVuZmluaXNoZWQgd29yayBpdGVtcyB0byBzdGFydCBuZXcgb25l cyByaWdodCBub3cuDQpJdCB3b3VsZCBiZSBwcnVkZW50IHRvIGdldCB0aGUgY2hhcnRlcmVkIG5v dGlmaWNhdGlvbiB3b3JrIGZpbmlzaGVkIGJlZm9yZSBhZGRpbmcgbW9yZSBmZWF0dXJlcy4NCg0K U3BvdCBzb2x1dGlvbnMgdGhhdCBhcmUgaW50ZW50aW9uYWxseSBpbmNvbXBsZXRlIGFuZCBub24t cmV1c2FibGUgYXJlIHRvbyBleHBlbnNpdmUgaW4gdGhlIElFVEYuDQoNCg0KQW5keQ0KDQoNCk9u IFRodSwgTm92IDIsIDIwMTcgYXQgMTA6NTkgQU0sIEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVy LmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSwNCg0KQ2xlYXJseSB0aGVyZSBpcyBhIGNhc2UgdG8gYmUgbWFkZSBmb3IgdGhlIGFi aWxpdHkgb2Ygc2ltcGxlIGF1dG9tYXRpb24gLyBjbG9zZWQgY29udHJvbCBsb29wcyBvbiB0aGUg c2VydmVyLg0KDQpKdXN0IGEgZmV3IGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgcm9sZSBvZiBZQU5H IFB1c2ggc21hcnQgZmlsdGVycyBpbiB0aGlzLCBhbmQgd2hlcmUgSSB2aWV3IHRoZSBib3VuZGFy eSBiZXR3ZWVuIHRoZW06DQoNCi0gQSBzbWFydCBmaWx0ZXIgYWxsb3dzIHRvIHNlbmQgdXBkYXRl cyBvbmx5IHdoZW4gY2VydGFpbiBmaWx0ZXIgY29uZGl0aW9ucyByZWdhcmRpbmcgaXRzIHZhbHVl cyBhcmUgbWV0LCBwb3NzaWJseSBpbnZvbHZpbmcgc3RhdGUuICBFeGFtcGxlOiBBIHRocmVzaG9s ZCBoYXMgYmVlbiBjcm9zc2VkLCBhIGhpZ2gtd2F0ZXIgbWFyayBoYXMgYmVlbiBicmVhY2hlZC4g IFRoZXNlIHVwZGF0ZXMgY2xlYXJseSBjb25zdGl0dXRlICJldmVudHMiIHRoYXQgY2FuIGZlZWQg aW50byBhbiBldmVudC9jb25kaXRpb24vYWN0aW9uIHJ1bGUuDQotIFRoYXQgc2FpZCwgdGhlIGZv Y3VzIG9uIHNtYXJ0IGZpbHRlcnMgaXMgdG8gYmUgc21hcnQteWV0LXNpbXBsZSwgYXBwbHlpbmcg OTAvMTAgcnVsZS4gIEl0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIG1ha2UgdGhpcyBhc3N1bWUg dGhlIHJvbGUgb2YgYSBnZW5lcmFsICJFdmVudCArIEV4cHJlc3Npb24gTUlCIi4gICBGb3IgZXhh bXBsZXMsIGV2ZW50cyB0aGF0IHdvdWxkIHJlcXVpcmUgY3Jvc3MtY29ycmVsYXRpb24gY29tcGFy aW5nIHZhbHVlcyBhY3Jvc3MgZGF0YSBpdGVtcywgcHJvY2Vzc2luZyBlbnRpcmUgbGlzdHMsIGNv bXB1dGluZyBhZ2dyZWdhdGVzIG92ZXIgdGltZSwgZXRjLCB3b3VsZCBiZSBvdXRzaWRlIHRoZSBz Y29wZS4NCi0gVGhlIGFzc2Vzc21lbnQgb2YgYW55IGNvbmRpdGlvbnMgd291bGQgYmUgbGVmdCBm b3IgdGhlIGF1dG9tYXRpb24gZnJhbWV3b3JrLiAgSW4gb3RoZXIgd29yZHMsIGEgc21hcnQgZmls dGVyIHdpbGwganVzdCBhc3Nlc3MgdGhlIHVwZGF0ZSBpdHNlbGYgYWdhaW5zdCBhIHNtYXJ0IGZp bHRlci4gIEl0IHdpbGwgbm90IG1ha2UgYWRkaXRpb25hbCBjaGVja3Mgd2l0aCByZWdhcmRzIHRv IG90aGVyIGRhdGEgb3IgdGFrZSBvdGhlciBhY3Rpb25zIGFzIGEgcmVzdWx0IG9mIHRoZSBmaWx0 ZXIgYmVmb3JlIHNlbmRpbmcgYW4gZXZlbnQuICBUaGF0IHdvdWxkIGJlIHByZWNpc2VseSBsZWZ0 IGZvciB0aGUgYXV0b21hdGlvbiBzdGFnZXMuICBUaGVyZSBpcyBhIHJlYXNvbiB0aGF0IGl0J3Mg ImV2ZW50LWNvbmRpdGlvbi1hY3Rpb24iLCBub3Qgc2ltcGx5ICJ0cmlnZ2VyLWFjdGlvbiIuDQoN Ci0tLSBBbGV4DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSWdvciBCcnlza2luDQo+IFNlbnQ6IFRodXJzZGF5 LCBOb3ZlbWJlciAwMiwgMjAxNyA5OjU0IEFNDQo+IFRvOiBUaWFucmFuIFpob3UgPHpob3V0aWFu cmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PjsgWHVmZW5nIExp dQ0KPiA8WHVmZW5nX0xpdUBqYWJpbC5jb208bWFpbHRvOlh1ZmVuZ19MaXVAamFiaWwuY29tPj47 IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJl OiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbA0K PiBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQo+DQo+IEhpIFRpYW5yYW4sDQo+DQo+IFRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4NCj4NCj4gUGxlYXNlLCBub3RlIHRoYXQgd2Ugc2VlIHNt YXJ0IGZpbHRlcnMgYXMgYSBzaWduaWZpY2FudCBzdGVwIGZyb20gY3VycmVudCBwdXNoDQo+IG1h Y2hpbmVyeSBpbiBldm9sdXRpb24gb2YgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24sIGJlY2F1 c2UgaXQgZW1wb3dlcnMNCj4gdGhlIGNsaWVudCB0byBpbnN0cnVjdCB0aGUgbmV0d29yayB0byBp ZGVudGlmeSBhbmQgZm9jdXMgb24gIm91dGxpZXJzIiwgcmF0aGVyDQo+IHRoYW4gb24gcm91dGlu ZSBjaGFuZ2VzIGluIHRoZSBuZXR3b3JrIFN0YXRlLiBJIGFncmVlLCB0aGlzIHdpbGwgaW1wb3Nl IG1vcmUNCj4gY29tcGxleGl0eSBvbiB0aGUgbmV0d29yaywgYnV0IHRoZSBiZW5lZml0cyBhcmUg b2J2aW91cy4gRm9yIGV4YW1wbGUsDQo+IGluc3RlYWQgb2YgcmVjZWl2aW5nIHRvbnMgb2YgbGFy Z2VseSB1c2VsZXNzIGluZm9ybWF0aW9uLCA5OSUgb2Ygd2hpY2ggdG8gYmUNCj4gZGlzY2FyZGVk IGFmdGVyIHRoZSBwcm9jZXNzaW5nLCB0aGUgY2xpZW50IHdpbGwgYmUgYWJsZSB0byByZWNlaXZl IG9ubHkNCj4gImludGVyZXN0aW5nIiBpbmZvcm1hdGlvbiBXUlQgYWN0aW9uYWJsZSBldmVudHMu IFRoZSBuZXR3b3JrIGNvbnRyb2wNCj4gYXV0b21hdGlvbiBmcmFtZXdvcmsgaW50ZW5kcyB0byBt YWtlIG9uZSBzdGVwIGZ1cnRoZXIgaW4gdGhpcyBldm9sdXRpb24uDQo+IFdlIGFyZSBiYXNpY2Fs bHkgYXNraW5nICJXaHkgc2VuZGluZyBub3RpZmljYXRpb25zIGlzIHRoZSBvbmx5IGFjdGlvbiB0 aGF0DQo+IGNvdWxkIGJlIHRyaWdnZXJlZCBieSBtb2RlbCBkZWZpbmVkIGV2ZW50cyBhbmQvb3Ig cHVzaCBzdWJzY3JpcHRpb25zDQo+IGFuZC9vciBzbWFydCBmaWx0ZXJzIj8gV2h5LCBmb3IgZXhh bXBsZSwgcHJlLWRlZmluZWQgbmV0d29yayByZS0NCj4gY29uZmlndXJhdGlvbnMgY291bGQgbm90 IGJlIHRyaWdnZXJlZCBieSBzbWFydCBmaWx0ZXJzPyBXaHkgaXQgaXMgbm90IHBvc3NpYmxlDQo+ IGZvciB0aGUgY2xpZW50IHRvIHByZS1jb25maWd1cmUgZCAgZXNpcmVkIGEgIGN0aW9ucyBhaGVh ZCBvZiB0aW1lPyINCj4NCj4gVGhpbmsgYWJvdXQgYSBiYXR0bGVzaGlwIHRoYXQganVzdCBoYXMg YmVlbiB0b3JwZWRvZWQuIFRoZSBjcmV3IG1lbWJlcnMNCj4gYXJlIG5vdCBleHBlY3RlZCB0byBq dXN0IGlkZW50aWZ5IGhvbGVzL2xlYWtzIGluIHRoZSBzaGlwJ3MgYm90dG9tLCByZXBvcnQgdGhl DQo+ICJ0ZWxlbWV0cnkiIHRvIHRoZSBjYXB0YWluIGFuZCB3YWl0IGZvciBpbnN0cnVjdGlvbnMg b24gd2hhdCB0byBkbyBuZXh0LA0KPiByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qgb25seSBr bm93cyBoaXMvaGVyIHByZS1kZWZpbmVkIGFjdGlvbnMsIChzKWhlDQo+IGlzIG1ldGljdWxvdXNs eSB0cmFpbmVkIG9uIGEgZGFpbHkgYmFzaXMgb24gaG93IHRvIGNhcnJ5IG91dCB0aGVtIGluIHRo ZSBtb3N0DQo+IGVmZmljaWVudCB3YXkuIFRoaXMgaXMgaG93IHNoaXBzIHN1cnZpdmUgcHJvYmxl bXMgbGlrZSB0aGF0LiBBbHNvIHRoaXMgaXMgaG93IHRoZQ0KPiBzYW1lIGF1dGhvcml0eSBjYW4g Y29udHJvbCBiaWcgYW5kIG11bHRpcGxlIHNoaXBzLg0KPg0KPiBDaGVlcnMsDQo+IElnb3INCj4N Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29uZiBbbWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIFRpYW5yYW4gWmhvdQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVy IDAxLCAyMDE3IDExOjMxIFBNDQo+IFRvOiBYdWZlbmcgTGl1OyBuZXRjb25mQGlldGYub3JnPG1h aWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFlBTkcgUFVT SCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wNCj4gQXV0b21hdGlvbiBQcm9ibGVt IFN0YXRlbWVudA0KPg0KPiBIaSBYdWZlbmcsDQo+DQo+IE9uIHRoZSBzbWFydCBmaWx0ZXJzIChh bHNvIHJlbGF0ZXMgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLQ0K PiBuZXRjb25mLXB1c2gtc21hcnQtZmlsdGVycy1wcy0wMCksIEkgdGhpbmsgd2UgbmVlZCBjcml0 ZXJpYSB0byBjYXJlZnVsbHkgc2VsZWN0DQo+ICJjb25kaXRpb25zIi4gV2hpbGUgdGhlcmUgYXJl IG1hbnkgYmVuZWZpdCwgc2F5IHNhdmUgdGhlIGJhbmR3aWR0aCBhbmQNCj4gcmVsaWVmIHRoZSBj b2xsZWN0b3IsIGl0IHdpbGwgYWRkIGNvbXB1dGF0aW9uIGJ1cmRlbiB0byBuZXR3b3JrIGRldmlj ZXMuDQo+IE5ldHdvcmsgZGV2aWNlcyBhcmUgbm90IGdvb2QgYXQgdGhpcyBhcyBzZXJ2ZXJzLg0K PiBTbyBtYXliZToNCj4gMS4gc2hvdWxkIG5vdCB0b28gY29tcGxleCB0byBpbXBsZW1lbnQuDQo+ IDIuIG11c3QgaGVscCB0byBtaXRpZ2F0ZSB0aGUgZXhwb3J0IHZvbHVtZS4NCj4NCj4gSWYgc28s IGZvciBleGFtcGxlLCB0aGUgYXZlcmFnZSB2YWx1ZSBzaG91bGQgYmUgb3V0IG9mIHNjb3BlLCBJ TUhPLg0KPg0KPiBCZXN0LA0KPiBUaWFucmFuDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgWHVmZW5nDQo+ ID4gTGl1DQo+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDM6MzEgQU0NCj4g PiBUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiBTdWJq ZWN0OiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJv bA0KPiA+IEF1dG9tYXRpb24gUHJvYmxlbSBTdGF0ZW1lbnQNCj4gPg0KPiA+IERlYXIgV0csDQo+ ID4NCj4gPiBUaGUgWWFuZy1wdXNoIERlemlnbiBUZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gdGhl IFlhbmcgcHVzaA0KPiBlbmhhbmNlbWVudC4NCj4gPiBXZSBoYXZlIHBvc3RlZCBhIGRyYWZ0IG9u IHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0byBleHRlbmQgWWFuZyBwdXNoIHRvDQo+ID4gYSBtb3Jl IGdlbmVyYWxpemVkIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIGZyYW1ld29yay4NCj4gPg0K PiA+IFRoZSBmb2xsb3dpbmcgaXMgdGhlIHN1bW1hcnkgb2YgdGhpcyB0b3BpYy4gQW55IGNvbW1l bnRzLCB0aG91Z2h0cywNCj4gPiBhbmQgc3VnZ2VzdGlvbnMgYXJlIGFwcHJlY2lhdGVkLg0KPiA+ DQo+ID4gVGhhbmtzLA0KPiA+IC0gWHVmZW5nDQo+ID4NCj4gPiA9PT09PT09PT09PT09PT09DQo+ ID4gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9u DQo+ID4gZHJhZnQtYnJ5c2tpbi1uZXRjb25mLWF1dG9tYXRpb24tZnJhbWV3b3JrLTAwDQo+ID4N Cj4gPiBFdm9sdXRpb24gb2YgWUFORyBCYXNlZCBOZXR3b3JrIEF1dG9tYXRpb24NCj4gPiAqICJD dXN0b20gU3Vic2NyaXB0aW9uIHRvIEV2ZW50IE5vdGlmaWNhdGlvbnMiIG1vZGVsIDoNCj4gPiAg ICAgLSBhbGxvd3MgZm9yIGEgY2xpZW50IHRvIHN1YnNjcmliZSB0byB1bnNvbGljaXRlZCBldmVu dCBub3RpZmljYXRpb25zDQo+ID4gZGVmaW5lZCBieSBzdXBwb3J0ZWQgWUFORyBtb2RlbHM7DQo+ ID4NCj4gPiAqICJTdWJzY3JpYmluZyB0byBZQU5HIGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMiIG1v ZGVsOg0KPiA+ICAgICAtIGFsbG93cyBmb3IgYSBjbGllbnQgdG8gZGVmaW5lIHN1YnNjcmliYWJs ZSBldmVudHMgYW5kIGNvbnRlbnRzIG9mDQo+ID4gZXZlbnQgbm90aWZpY2F0aW9ucyBhcyB0YXJn ZXQtdHJpZ2dlci1ub3RpZnkgdHJpcGxldHMNCj4gPg0KPiA+ICogIlNtYXJ0IGZpbHRlcnMgZm9y IFB1c2ggVXBkYXRlcyIgbW9kZWw6DQo+ID4gICAgIC0gYWxsb3dzIGZvciBhIGNsaWVudCB0byBm aWx0ZXIgZXZlbnQgdHJpZ2dlcnMgYW5kIG5vdGlmaWNhdGlvbnMgb24NCj4gPiBwdXNoIG9iamVj dCB2YWx1ZXMgYW5kIHRoZWlyIGNoYW5nZSBoaXN0b3J5LCBmb2N1c2VzIG9uICJvdXRsaWVycyIN Cj4gPg0KPiA+IE9iamVjdGl2ZXMgb2YgIFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3 b3JrIENvbnRyb2wgQXV0b21hdGlvbg0KPiA+IDEpIFRvIGdlbmVyYWxpemUgdGFyZ2V0LXRyaWdn ZXItbm90aWZ5IGNvbmNlcHQgaW50bw0KPiA+IGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gY29uY2Vw dCwgd2hlcmU6DQo+ID4NCj4gPiAgICAgZXZlbnQgLSBhIHBhcnRpY3VsYXIgY2hhbmdlIGluIHRo ZSBuZXR3b3JrIHN0YXRlIGV4cGxpY2l0bHkgZGVmaW5lZA0KPiA+IGJ5IG9uZSBvZiB0aGUgWUFO RyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrIG9yIGltcGxpY2l0bHkNCj4gPiBkZWZp bmVkIGJ5IHRoZSBjbGllbnQsIHdoaWNoIGlzIGNvbnN0YW50bHkgbW9uaXRvcmVkIGJ5IHRoZSBu ZXR3b3JrOw0KPiA+DQo+ID4gICAgIGNvbmRpdGlvbiAtIGEgbG9naWNhbCBleHByZXNzaW9uIHRo YXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlcg0KPiA+IHRoZSBhc3NvY2lhdGVkIGV2ZW50 IGlzIGRldGVjdGVkOw0KPiA+DQo+ID4gICAgIGFjdGlvbiAtIGFuIG9wZXJhdGlvbiB0byBiZSBj YXJyaWVkIG91dCBieSB0aGUgbmV0d29yayB3aGVuIHRoZQ0KPiA+IGFzc29jaWF0ZWQgZXZlbnQg aXMgZGV0ZWN0ZWQgYW5kIHRoZSBhc3NvY2lhdGVkIGNvbmRpdGlvbiBpcyBtZXQNCj4gPg0KPiA+ IDIpIFRvIHByb3ZpZGUgZm9yIGEgY2xpZW50IGEgY2FwYWJpbGl0eSB0byBjb25maWd1cmUgdGhl DQo+ID4gZXZlbnQtY29uZGl0aW9uLWFjdGlvbiB0cmlwbGV0cyBhcyBwb2xpY3kgcnVsZXMgYWhl YWQgb2YgdGltZSBvci9hbmQNCj4gPiBkdXJpbmcgbmV0d29yayBvcGVyYXRpb25zDQo+ID4NCj4g PiBHZW5lcmFsaXplZCBBY3Rpb24NCj4gPiAqIFNlbmQgbm90aWZpY2F0aW9uDQo+ID4gKiBQZXJm b3JtIGltbWVkaWF0ZSBuZXR3b3JrIHJlY29uZmlndXJhdGlvbiAoZS5nLiBtb2RpZnkgb25lIG9y IG1vcmUNCj4gPiBhdHRyaWJ1dGVzIG9mIG9uZSBvciBtb3JlIENPTkZJRz1UUlVFIGRhdGEgc3Rv cmUgbm9kZXMpOw0KPiA+ICogU2NoZWR1bGUgb25lIHRpbWUgb3IgcGVyaW9kaWMgcmVjb25maWd1 cmF0aW9uIGluIHRoZSBmdXR1cmU7DQo+ID4gKiBDYWxsIFJQQyBkZWZpbmVkIGJ5IG9uZSBvZiB0 aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrICgNCj4gZS5nLg0KPiA+IGNh bGwgbmV0d29yaydzIHBhdGggY29tcHV0ZXIgdG8gZXZhbHVhdGUgd2hldGhlciBhbiBhbHRlcm5h dGl2ZS9tb3JlDQo+ID4gb3B0aW1hbCBwYXRoIGlzIGF2YWlsYWJsZSBmb3IgYSBnaXZlbiBjb25u ZWN0aW9uKQ0KPiA+ICogTGluay91bmxpbmsgZGF0YSBzdG9yZSBkeW5hbWljIHN1Yi10cmVlczsN Cj4gPiAqIEV0Yy4NCj4gPg0KPiA+IFJlbGF0aW9uc2hpcCB3aXRoIFBvbGljeSBGcmFtZXdvcmsN Cj4gPiAqIFRoZSBmcmFtZXdvcmsgc2hvdWxkIHdvcmsgYXV0b25vbW91c2x5DQo+ID4NCj4gPiAq IFRoZSBmcmFtZXdvcmsgc2hvdWxkIGZpdCB3ZWxsIHdpdGhpbiBhIGhpZ2hlciBsZXZlbCBwb2xp Y3kNCj4gPiBmcmFtZXdvcmssIHdpdGggdGhlIGxhdHRlciBwb3NzaWJseSBwcm92aWRpbmcgYSBn cmVhdGVyIGxldmVsIG9mIGF1dG9tYXRpb246DQo+ID4gICAtIG11bHRpcGxlIG1pY3JvLWNvbmRp dGlvbnMgY291bGQgYmUgY29tYmluZWQgaW50byBhIHNpbmdsZQ0KPiA+IG1hY3JvLWNvbmRpdGlv biB2aWEgYSBudW1iZXIgb2YgbG9naWNhbCBvcGVyYXRpb25zOw0KPiA+ICAgLSBtdWx0aXBsZSBt aWNyby1hY3Rpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGUgdHJhbnNhY3Rpb24N Cj4gPiB3aXRoIGEgcG9zc2liaWxpdHkgb2Ygc3BlY2lmeWluZyBwb2xpY2llcyB3aXRoIHJlc3Bl Y3QgdG8gaGFuZGxpbmcNCj4gPiBlcnJvcnMvZXhjZXB0aW9ucyBvZiBlYWNoIG9mIHRoZSB0cmFu c2FjdGlvbiBjb21wb25lbnRzDQo+ID4NCj4gPiBGcmFtZXdvcmsgQmVuZWZpdHMNCj4gPiAqIGxv d2VyIGxhdGVuY3ksIGZhc3RlciByZXNwb25zaXZlbmVzcyBvZiB0aGUgbmV0d29yayB0byB2YXJp b3VzDQo+ID4gZXZlbnRzL2NvbmRpdGlvbnM7DQo+ID4gKiBiZXR0ZXIgc2NhbGUgKGUuZy4gdGhl IGNsaWVudCBtYXkgY29udHJvbCBtb3JlIG5ldHdvcmtzIGJlY2F1c2UgaXQNCj4gPiBkb2VzIG5v dCBoYXZlIHRvIG1vbml0b3IvbWljcm8tbWFuYWdlIGFueSBvZiB0aGVtKTsNCj4gPiAqIENQVSBh bmQgYmFuZHdpZHRoIHNhdmluZ3MgZHVlIHRvIHRoZSByZWR1Y2VkIGFtb3VudCBvZg0KPiBjb21t dW5pY2F0aW9uDQo+ID4gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgbmV0d29yaw0KPiA+ICog VGhlIGNsaWVudCBjYW4gdGFrZSBpdHNlbGYgb3V0IG9mIHRoZSBuZXR3b3JrIGNvbnRyb2wgbG9v cCwgIGNoYW5nZQ0KPiA+IGl0cyByb2xlIGZyb20gYmVpbmcgbmV0d29yaydzICJtaWNyby1tYW5h Z2VyIiB0byBiZWluZyBuZXR3b3JrJ3MNCj4gPiAicG9saWNlIG9mZmljZXIiLCB3aG8gaW50ZXJm ZXJlcyBpbnRvIG5ldHdvcmsgb3BlcmF0aW9ucyBvbmx5IGluDQo+ID4gZXhjZXB0aW9uYWwvdW5w cmVkaWN0ZWQgc2l0dWF0aW9ucw0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4g TmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj4gTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+IE5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABBAB1sjceml521mbxchi_ 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 b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZ3JlZSB3ZSBzaG91bGQgZmluaXNoIHRoZSBjaGFydGVy ZWQgd29yayBmaXJzdC4mbmJzcDsgSG9wZWZ1bGx5IHRoaXMgaXMgbm90IHRvbyBmYXIgb2ZmLi4u Jm5ic3A7IENsZWFybHkgd2UgZG9u4oCZdCB3YW50IHRvIGRlbGF5LCBidXQgSSBkb27igJl0IHRo aW5rIGl0IGlzIHRvbyBlYXJseSB0byBzdGFydA0KIHRoaW5raW5nIGFib3V0IHdoYXQgc2hvdWxk IGJlIHB1dCBpbiB0aGUgcGlwZWxpbmUgbmV4dD8mbmJzcDsgVGhlIGZhY3QgdGhhdCB0aGVyZSBp cyBtb3JlIGRlbWFuZCB0byBidWlsZCBvbiB0aGUgZXhpc3RpbmcgcGxhdGZvcm0gYW5kIGFkZCB0 byBpdCBzaG91bGQgYmUgYSBnb29kIHRoaW5nLiZuYnNwOyBOZXRjb25mIGhhcyBiZWVuIHZlcnkg Y29uZmlndXJhdGlvbiAvIGZ1bGZpbGxtZW50IG9yaWVudGVkIHNvIGZhci4mbmJzcDsgVGhlIG5v dGlmaWNhdGlvbi9zdWJzY3JpcHRpb24vcHVzaA0KIHdvcmsgb3BlbnMgdXAgdGhlIGRvb3IgZm9y IGFub3RoZXIgZmllbGQsIGFzc3VyYW5jZS4mbmJzcDsgVGhpcyBpcyBhIGJpZyBvcHBvcnR1bml0 eS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmll cm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgMTI6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFsZXhhbmRl ciBDbGVtbSAmbHQ7YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBJZ29yIEJyeXNraW4gJmx0O0lnb3IuQnJ5c2tpbkBodWF3ZWkuY29tJmd0OzsgVGlhbnJhbiBa aG91ICZsdDt6aG91dGlhbnJhbkBodWF3ZWkuY29tJmd0OzsgWHVmZW5nIExpdSAmbHQ7WHVmZW5n X0xpdUBqYWJpbC5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJv bCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB3YW50IHRvIGltcGx5IHRoZSBJRVRGIHNo b3VsZCB3b3JrIG9uIGEgZ2VuZXJhbC1wdXJwb3NlIHNjcmlwdGluZyBlbmdpbmUgZm9yIFlBTkcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8g TkVUQ09ORiBhbmQgTkVUTU9EIGhhdmUgdG9vIG1hbnkgdW5maW5pc2hlZCB3b3JrIGl0ZW1zIHRv IHN0YXJ0IG5ldyBvbmVzIHJpZ2h0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIHBydWRlbnQgdG8gZ2V0IHRoZSBjaGFy dGVyZWQgbm90aWZpY2F0aW9uIHdvcmsgZmluaXNoZWQgYmVmb3JlIGFkZGluZyBtb3JlIGZlYXR1 cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TcG90IHNvbHV0aW9ucyB0aGF0IGFyZSBpbnRlbnRpb25hbGx5IGluY29tcGxldGUgYW5kIG5v bi1yZXVzYWJsZSBhcmUgdG9vIGV4cGVuc2l2ZSBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3Yg MiwgMjAxNyBhdCAxMDo1OSBBTSwgQWxleGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86 YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGV4YW5kZXIuY2xl bW1AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCkNsZWFybHkgdGhlcmUgaXMgYSBj YXNlIHRvIGJlIG1hZGUgZm9yIHRoZSBhYmlsaXR5IG9mIHNpbXBsZSBhdXRvbWF0aW9uIC8gY2xv c2VkIGNvbnRyb2wgbG9vcHMgb24gdGhlIHNlcnZlci48YnI+DQo8YnI+DQpKdXN0IGEgZmV3IGNv bW1lbnRzIHJlZ2FyZGluZyB0aGUgcm9sZSBvZiBZQU5HIFB1c2ggc21hcnQgZmlsdGVycyBpbiB0 aGlzLCBhbmQgd2hlcmUgSSB2aWV3IHRoZSBib3VuZGFyeSBiZXR3ZWVuIHRoZW06PGJyPg0KPGJy Pg0KLSBBIHNtYXJ0IGZpbHRlciBhbGxvd3MgdG8gc2VuZCB1cGRhdGVzIG9ubHkgd2hlbiBjZXJ0 YWluIGZpbHRlciBjb25kaXRpb25zIHJlZ2FyZGluZyBpdHMgdmFsdWVzIGFyZSBtZXQsIHBvc3Np Ymx5IGludm9sdmluZyBzdGF0ZS4mbmJzcDsgRXhhbXBsZTogQSB0aHJlc2hvbGQgaGFzIGJlZW4g Y3Jvc3NlZCwgYSBoaWdoLXdhdGVyIG1hcmsgaGFzIGJlZW4gYnJlYWNoZWQuJm5ic3A7IFRoZXNl IHVwZGF0ZXMgY2xlYXJseSBjb25zdGl0dXRlICZxdW90O2V2ZW50cyZxdW90OyB0aGF0DQogY2Fu IGZlZWQgaW50byBhbiBldmVudC9jb25kaXRpb24vYWN0aW9uIHJ1bGUuPGJyPg0KLSBUaGF0IHNh aWQsIHRoZSBmb2N1cyBvbiBzbWFydCBmaWx0ZXJzIGlzIHRvIGJlIHNtYXJ0LXlldC1zaW1wbGUs IGFwcGx5aW5nIDkwLzEwIHJ1bGUuJm5ic3A7IEl0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIG1h a2UgdGhpcyBhc3N1bWUgdGhlIHJvbGUgb2YgYSBnZW5lcmFsICZxdW90O0V2ZW50ICYjNDM7IEV4 cHJlc3Npb24gTUlCJnF1b3Q7LiZuYnNwOyAmbmJzcDtGb3IgZXhhbXBsZXMsIGV2ZW50cyB0aGF0 IHdvdWxkIHJlcXVpcmUgY3Jvc3MtY29ycmVsYXRpb24gY29tcGFyaW5nIHZhbHVlcw0KIGFjcm9z cyBkYXRhIGl0ZW1zLCBwcm9jZXNzaW5nIGVudGlyZSBsaXN0cywgY29tcHV0aW5nIGFnZ3JlZ2F0 ZXMgb3ZlciB0aW1lLCBldGMsIHdvdWxkIGJlIG91dHNpZGUgdGhlIHNjb3BlLjxicj4NCi0gVGhl IGFzc2Vzc21lbnQgb2YgYW55IGNvbmRpdGlvbnMgd291bGQgYmUgbGVmdCBmb3IgdGhlIGF1dG9t YXRpb24gZnJhbWV3b3JrLiZuYnNwOyBJbiBvdGhlciB3b3JkcywgYSBzbWFydCBmaWx0ZXIgd2ls bCBqdXN0IGFzc2VzcyB0aGUgdXBkYXRlIGl0c2VsZiBhZ2FpbnN0IGEgc21hcnQgZmlsdGVyLiZu YnNwOyBJdCB3aWxsIG5vdCBtYWtlIGFkZGl0aW9uYWwgY2hlY2tzIHdpdGggcmVnYXJkcyB0byBv dGhlciBkYXRhIG9yIHRha2Ugb3RoZXIgYWN0aW9ucyBhcw0KIGEgcmVzdWx0IG9mIHRoZSBmaWx0 ZXIgYmVmb3JlIHNlbmRpbmcgYW4gZXZlbnQuJm5ic3A7IFRoYXQgd291bGQgYmUgcHJlY2lzZWx5 IGxlZnQgZm9yIHRoZSBhdXRvbWF0aW9uIHN0YWdlcy4mbmJzcDsgVGhlcmUgaXMgYSByZWFzb24g dGhhdCBpdCdzICZxdW90O2V2ZW50LWNvbmRpdGlvbi1hY3Rpb24mcXVvdDssIG5vdCBzaW1wbHkg JnF1b3Q7dHJpZ2dlci1hY3Rpb24mcXVvdDsuPGJyPg0KPGJyPg0KLS0tIEFsZXg8YnI+DQo8YnI+ DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBO ZXRjb25mIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+ bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIElnb3IgQnJ5c2tpbjxi cj4NCiZndDsgU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDk6NTQgQU08YnI+DQom Z3Q7IFRvOiBUaWFucmFuIFpob3UgJmx0OzxhIGhyZWY9Im1haWx0bzp6aG91dGlhbnJhbkBodWF3 ZWkuY29tIj56aG91dGlhbnJhbkBodWF3ZWkuY29tPC9hPiZndDs7IFh1ZmVuZyBMaXU8YnI+DQom Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86WHVmZW5nX0xpdUBqYWJpbC5jb20iPlh1ZmVuZ19MaXVA amFiaWwuY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj4NCm5l dGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFlBTkcg UFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2w8YnI+DQomZ3Q7IEF1dG9tYXRp b24gUHJvYmxlbSBTdGF0ZW1lbnQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBUaWFucmFuLDxicj4N CiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBQbGVhc2UsIG5vdGUgdGhhdCB3ZSBzZWUgc21hcnQgZmlsdGVycyBhcyBhIHNpZ25pZmlj YW50IHN0ZXAgZnJvbSBjdXJyZW50IHB1c2g8YnI+DQomZ3Q7IG1hY2hpbmVyeSBpbiBldm9sdXRp b24gb2YgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24sIGJlY2F1c2UgaXQgZW1wb3dlcnM8YnI+ DQomZ3Q7IHRoZSBjbGllbnQgdG8gaW5zdHJ1Y3QgdGhlIG5ldHdvcmsgdG8gaWRlbnRpZnkgYW5k IGZvY3VzIG9uICZxdW90O291dGxpZXJzJnF1b3Q7LCByYXRoZXI8YnI+DQomZ3Q7IHRoYW4gb24g cm91dGluZSBjaGFuZ2VzIGluIHRoZSBuZXR3b3JrIFN0YXRlLiBJIGFncmVlLCB0aGlzIHdpbGwg aW1wb3NlIG1vcmU8YnI+DQomZ3Q7IGNvbXBsZXhpdHkgb24gdGhlIG5ldHdvcmssIGJ1dCB0aGUg YmVuZWZpdHMgYXJlIG9idmlvdXMuIEZvciBleGFtcGxlLDxicj4NCiZndDsgaW5zdGVhZCBvZiBy ZWNlaXZpbmcgdG9ucyBvZiBsYXJnZWx5IHVzZWxlc3MgaW5mb3JtYXRpb24sIDk5JSBvZiB3aGlj aCB0byBiZTxicj4NCiZndDsgZGlzY2FyZGVkIGFmdGVyIHRoZSBwcm9jZXNzaW5nLCB0aGUgY2xp ZW50IHdpbGwgYmUgYWJsZSB0byByZWNlaXZlIG9ubHk8YnI+DQomZ3Q7ICZxdW90O2ludGVyZXN0 aW5nJnF1b3Q7IGluZm9ybWF0aW9uIFdSVCBhY3Rpb25hYmxlIGV2ZW50cy4gVGhlIG5ldHdvcmsg Y29udHJvbDxicj4NCiZndDsgYXV0b21hdGlvbiBmcmFtZXdvcmsgaW50ZW5kcyB0byBtYWtlIG9u ZSBzdGVwIGZ1cnRoZXIgaW4gdGhpcyBldm9sdXRpb24uPGJyPg0KJmd0OyBXZSBhcmUgYmFzaWNh bGx5IGFza2luZyAmcXVvdDtXaHkgc2VuZGluZyBub3RpZmljYXRpb25zIGlzIHRoZSBvbmx5IGFj dGlvbiB0aGF0PGJyPg0KJmd0OyBjb3VsZCBiZSB0cmlnZ2VyZWQgYnkgbW9kZWwgZGVmaW5lZCBl dmVudHMgYW5kL29yIHB1c2ggc3Vic2NyaXB0aW9uczxicj4NCiZndDsgYW5kL29yIHNtYXJ0IGZp bHRlcnMmcXVvdDs/IFdoeSwgZm9yIGV4YW1wbGUsIHByZS1kZWZpbmVkIG5ldHdvcmsgcmUtPGJy Pg0KJmd0OyBjb25maWd1cmF0aW9ucyBjb3VsZCBub3QgYmUgdHJpZ2dlcmVkIGJ5IHNtYXJ0IGZp bHRlcnM/IFdoeSBpdCBpcyBub3QgcG9zc2libGU8YnI+DQomZ3Q7IGZvciB0aGUgY2xpZW50IHRv IHByZS1jb25maWd1cmUgZCZuYnNwOyBlc2lyZWQgYSZuYnNwOyBjdGlvbnMgYWhlYWQgb2YgdGlt ZT8mcXVvdDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGluayBhYm91dCBhIGJhdHRsZXNoaXAgdGhh dCBqdXN0IGhhcyBiZWVuIHRvcnBlZG9lZC4gVGhlIGNyZXcgbWVtYmVyczxicj4NCiZndDsgYXJl IG5vdCBleHBlY3RlZCB0byBqdXN0IGlkZW50aWZ5IGhvbGVzL2xlYWtzIGluIHRoZSBzaGlwJ3Mg Ym90dG9tLCByZXBvcnQgdGhlPGJyPg0KJmd0OyAmcXVvdDt0ZWxlbWV0cnkmcXVvdDsgdG8gdGhl IGNhcHRhaW4gYW5kIHdhaXQgZm9yIGluc3RydWN0aW9ucyBvbiB3aGF0IHRvIGRvIG5leHQsPGJy Pg0KJmd0OyByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qgb25seSBrbm93cyBoaXMvaGVyIHBy ZS1kZWZpbmVkIGFjdGlvbnMsIChzKWhlPGJyPg0KJmd0OyBpcyBtZXRpY3Vsb3VzbHkgdHJhaW5l ZCBvbiBhIGRhaWx5IGJhc2lzIG9uIGhvdyB0byBjYXJyeSBvdXQgdGhlbSBpbiB0aGUgbW9zdDxi cj4NCiZndDsgZWZmaWNpZW50IHdheS4gVGhpcyBpcyBob3cgc2hpcHMgc3Vydml2ZSBwcm9ibGVt cyBsaWtlIHRoYXQuIEFsc28gdGhpcyBpcyBob3cgdGhlPGJyPg0KJmd0OyBzYW1lIGF1dGhvcml0 eSBjYW4gY29udHJvbCBiaWcgYW5kIG11bHRpcGxlIHNoaXBzLjxicj4NCiZndDs8YnI+DQomZ3Q7 IENoZWVycyw8YnI+DQomZ3Q7IElnb3I8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE5ldGNvbmYgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVGlhbnJhbiBaaG91PGJyPg0KJmd0OyBTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDAxLCAyMDE3IDExOjMxIFBNPGJyPg0KJmd0OyBUbzogWHVmZW5n IExpdTsgPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFlBTkcgUFVTSCBCYXNlZCBHZW5l cmFsaXplZCBOZXR3b3JrIENvbnRyb2w8YnI+DQomZ3Q7IEF1dG9tYXRpb24gUHJvYmxlbSBTdGF0 ZW1lbnQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBYdWZlbmcsPGJyPg0KJmd0Ozxicj4NCiZndDsg T24gdGhlIHNtYXJ0IGZpbHRlcnMgKGFsc28gcmVsYXRlcyB0byA8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xlbW0tIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xlbW0tPC9hPjxicj4NCiZndDsgbmV0Y29uZi1w dXNoLXNtYXJ0LWZpbHRlcnMtcHMtMDApLCBJIHRoaW5rIHdlIG5lZWQgY3JpdGVyaWEgdG8gY2Fy ZWZ1bGx5IHNlbGVjdDxicj4NCiZndDsgJnF1b3Q7Y29uZGl0aW9ucyZxdW90Oy4gV2hpbGUgdGhl cmUgYXJlIG1hbnkgYmVuZWZpdCwgc2F5IHNhdmUgdGhlIGJhbmR3aWR0aCBhbmQ8YnI+DQomZ3Q7 IHJlbGllZiB0aGUgY29sbGVjdG9yLCBpdCB3aWxsIGFkZCBjb21wdXRhdGlvbiBidXJkZW4gdG8g bmV0d29yayBkZXZpY2VzLjxicj4NCiZndDsgTmV0d29yayBkZXZpY2VzIGFyZSBub3QgZ29vZCBh dCB0aGlzIGFzIHNlcnZlcnMuPGJyPg0KJmd0OyBTbyBtYXliZTo8YnI+DQomZ3Q7IDEuIHNob3Vs ZCBub3QgdG9vIGNvbXBsZXggdG8gaW1wbGVtZW50Ljxicj4NCiZndDsgMi4gbXVzdCBoZWxwIHRv IG1pdGlnYXRlIHRoZSBleHBvcnQgdm9sdW1lLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHNvLCBm b3IgZXhhbXBsZSwgdGhlIGF2ZXJhZ2UgdmFsdWUgc2hvdWxkIGJlIG91dCBvZiBzY29wZSwgSU1I Ty48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXN0LDxicj4NCiZndDsgVGlhbnJhbjxicj4NCiZndDs8 YnI+DQomZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsg RnJvbTogTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBYdWZlbmc8 YnI+DQomZ3Q7ICZndDsgTGl1PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAwMiwgMjAxNyAzOjMxIEFNPGJyPg0KJmd0OyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bmV0 Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVj dDogW05ldGNvbmZdIFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2w8 YnI+DQomZ3Q7ICZndDsgQXV0b21hdGlvbiBQcm9ibGVtIFN0YXRlbWVudDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBEZWFyIFdHLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBU aGUgWWFuZy1wdXNoIERlemlnbiBUZWFtIGhhcyBiZWVuIHdvcmtpbmcgb24gdGhlIFlhbmcgcHVz aDxicj4NCiZndDsgZW5oYW5jZW1lbnQuPGJyPg0KJmd0OyAmZ3Q7IFdlIGhhdmUgcG9zdGVkIGEg ZHJhZnQgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IHRvIGV4dGVuZCBZYW5nIHB1c2ggdG88YnI+ DQomZ3Q7ICZndDsgYSBtb3JlIGdlbmVyYWxpemVkIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9u IGZyYW1ld29yay48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGZvbGxvd2luZyBp cyB0aGUgc3VtbWFyeSBvZiB0aGlzIHRvcGljLiBBbnkgY29tbWVudHMsIHRob3VnaHRzLDxicj4N CiZndDsgJmd0OyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGFwcHJlY2lhdGVkLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7IC0gWHVmZW5nPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ID09PT09PT09PT09PT09PT08YnI+DQomZ3Q7ICZndDsgWUFO RyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uPGJyPg0K Jmd0OyAmZ3Q7IGRyYWZ0LWJyeXNraW4tbmV0Y29uZi1hdXRvbWF0aW9uLWZyYW1ld29yay0wMDxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBFdm9sdXRpb24gb2YgWUFORyBCYXNlZCBOZXR3 b3JrIEF1dG9tYXRpb248YnI+DQomZ3Q7ICZndDsgKiAmcXVvdDtDdXN0b20gU3Vic2NyaXB0aW9u IHRvIEV2ZW50IE5vdGlmaWNhdGlvbnMmcXVvdDsgbW9kZWwgOjxicj4NCiZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7LSBhbGxvd3MgZm9yIGEgY2xpZW50IHRvIHN1YnNjcmliZSB0byB1bnNv bGljaXRlZCBldmVudCBub3RpZmljYXRpb25zPGJyPg0KJmd0OyAmZ3Q7IGRlZmluZWQgYnkgc3Vw cG9ydGVkIFlBTkcgbW9kZWxzOzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAqICZxdW90 O1N1YnNjcmliaW5nIHRvIFlBTkcgZGF0YXN0b3JlIHB1c2ggdXBkYXRlcyZxdW90OyBtb2RlbDo8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOy0gYWxsb3dzIGZvciBhIGNsaWVudCB0 byBkZWZpbmUgc3Vic2NyaWJhYmxlIGV2ZW50cyBhbmQgY29udGVudHMgb2Y8YnI+DQomZ3Q7ICZn dDsgZXZlbnQgbm90aWZpY2F0aW9ucyBhcyB0YXJnZXQtdHJpZ2dlci1ub3RpZnkgdHJpcGxldHM8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKiAmcXVvdDtTbWFydCBmaWx0ZXJzIGZvciBQ dXNoIFVwZGF0ZXMmcXVvdDsgbW9kZWw6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDstIGFsbG93cyBmb3IgYSBjbGllbnQgdG8gZmlsdGVyIGV2ZW50IHRyaWdnZXJzIGFuZCBub3Rp ZmljYXRpb25zIG9uPGJyPg0KJmd0OyAmZ3Q7IHB1c2ggb2JqZWN0IHZhbHVlcyBhbmQgdGhlaXIg Y2hhbmdlIGhpc3RvcnksIGZvY3VzZXMgb24gJnF1b3Q7b3V0bGllcnMmcXVvdDs8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgT2JqZWN0aXZlcyBvZiZuYnNwOyBZQU5HIFBVU0ggQmFzZWQg R2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb248YnI+DQomZ3Q7ICZndDsgMSkg VG8gZ2VuZXJhbGl6ZSB0YXJnZXQtdHJpZ2dlci1ub3RpZnkgY29uY2VwdCBpbnRvPGJyPg0KJmd0 OyAmZ3Q7IGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gY29uY2VwdCwgd2hlcmU6PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtldmVudCAtIGEgcGFydGljdWxh ciBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgc3RhdGUgZXhwbGljaXRseSBkZWZpbmVkPGJyPg0KJmd0 OyAmZ3Q7IGJ5IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3Jr IG9yIGltcGxpY2l0bHk8YnI+DQomZ3Q7ICZndDsgZGVmaW5lZCBieSB0aGUgY2xpZW50LCB3aGlj aCBpcyBjb25zdGFudGx5IG1vbml0b3JlZCBieSB0aGUgbmV0d29yazs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmRpdGlvbiAtIGEgbG9naWNhbCBl eHByZXNzaW9uIHRoYXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlcjxicj4NCiZndDsgJmd0 OyB0aGUgYXNzb2NpYXRlZCBldmVudCBpcyBkZXRlY3RlZDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2FjdGlvbiAtIGFuIG9wZXJhdGlvbiB0byBiZSBj YXJyaWVkIG91dCBieSB0aGUgbmV0d29yayB3aGVuIHRoZTxicj4NCiZndDsgJmd0OyBhc3NvY2lh dGVkIGV2ZW50IGlzIGRldGVjdGVkIGFuZCB0aGUgYXNzb2NpYXRlZCBjb25kaXRpb24gaXMgbWV0 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDIpIFRvIHByb3ZpZGUgZm9yIGEgY2xpZW50 IGEgY2FwYWJpbGl0eSB0byBjb25maWd1cmUgdGhlPGJyPg0KJmd0OyAmZ3Q7IGV2ZW50LWNvbmRp dGlvbi1hY3Rpb24gdHJpcGxldHMgYXMgcG9saWN5IHJ1bGVzIGFoZWFkIG9mIHRpbWUgb3IvYW5k PGJyPg0KJmd0OyAmZ3Q7IGR1cmluZyBuZXR3b3JrIG9wZXJhdGlvbnM8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgR2VuZXJhbGl6ZWQgQWN0aW9uPGJyPg0KJmd0OyAmZ3Q7ICogU2VuZCBu b3RpZmljYXRpb248YnI+DQomZ3Q7ICZndDsgKiBQZXJmb3JtIGltbWVkaWF0ZSBuZXR3b3JrIHJl Y29uZmlndXJhdGlvbiAoZS5nLiBtb2RpZnkgb25lIG9yIG1vcmU8YnI+DQomZ3Q7ICZndDsgYXR0 cmlidXRlcyBvZiBvbmUgb3IgbW9yZSBDT05GSUc9VFJVRSBkYXRhIHN0b3JlIG5vZGVzKTs8YnI+ DQomZ3Q7ICZndDsgKiBTY2hlZHVsZSBvbmUgdGltZSBvciBwZXJpb2RpYyByZWNvbmZpZ3VyYXRp b24gaW4gdGhlIGZ1dHVyZTs8YnI+DQomZ3Q7ICZndDsgKiBDYWxsIFJQQyBkZWZpbmVkIGJ5IG9u ZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrICg8YnI+DQomZ3Q7 IGUuZy48YnI+DQomZ3Q7ICZndDsgY2FsbCBuZXR3b3JrJ3MgcGF0aCBjb21wdXRlciB0byBldmFs dWF0ZSB3aGV0aGVyIGFuIGFsdGVybmF0aXZlL21vcmU8YnI+DQomZ3Q7ICZndDsgb3B0aW1hbCBw YXRoIGlzIGF2YWlsYWJsZSBmb3IgYSBnaXZlbiBjb25uZWN0aW9uKTxicj4NCiZndDsgJmd0OyAq IExpbmsvdW5saW5rIGRhdGEgc3RvcmUgZHluYW1pYyBzdWItdHJlZXM7PGJyPg0KJmd0OyAmZ3Q7 ICogRXRjLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWxhdGlvbnNoaXAgd2l0aCBQ b2xpY3kgRnJhbWV3b3JrPGJyPg0KJmd0OyAmZ3Q7ICogVGhlIGZyYW1ld29yayBzaG91bGQgd29y ayBhdXRvbm9tb3VzbHk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKiBUaGUgZnJhbWV3 b3JrIHNob3VsZCBmaXQgd2VsbCB3aXRoaW4gYSBoaWdoZXIgbGV2ZWwgcG9saWN5PGJyPg0KJmd0 OyAmZ3Q7IGZyYW1ld29yaywgd2l0aCB0aGUgbGF0dGVyIHBvc3NpYmx5IHByb3ZpZGluZyBhIGdy ZWF0ZXIgbGV2ZWwgb2YgYXV0b21hdGlvbjo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7LSBt dWx0aXBsZSBtaWNyby1jb25kaXRpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGU8 YnI+DQomZ3Q7ICZndDsgbWFjcm8tY29uZGl0aW9uIHZpYSBhIG51bWJlciBvZiBsb2dpY2FsIG9w ZXJhdGlvbnM7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOy0gbXVsdGlwbGUgbWljcm8tYWN0 aW9ucyBjb3VsZCBiZSBjb21iaW5lZCBpbnRvIGEgc2luZ2xlIHRyYW5zYWN0aW9uPGJyPg0KJmd0 OyAmZ3Q7IHdpdGggYSBwb3NzaWJpbGl0eSBvZiBzcGVjaWZ5aW5nIHBvbGljaWVzIHdpdGggcmVz cGVjdCB0byBoYW5kbGluZzxicj4NCiZndDsgJmd0OyBlcnJvcnMvZXhjZXB0aW9ucyBvZiBlYWNo IG9mIHRoZSB0cmFuc2FjdGlvbiBjb21wb25lbnRzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IEZyYW1ld29yayBCZW5lZml0czxicj4NCiZndDsgJmd0OyAqIGxvd2VyIGxhdGVuY3ksIGZh c3RlciByZXNwb25zaXZlbmVzcyBvZiB0aGUgbmV0d29yayB0byB2YXJpb3VzPGJyPg0KJmd0OyAm Z3Q7IGV2ZW50cy9jb25kaXRpb25zOzxicj4NCiZndDsgJmd0OyAqIGJldHRlciBzY2FsZSAoZS5n LiB0aGUgY2xpZW50IG1heSBjb250cm9sIG1vcmUgbmV0d29ya3MgYmVjYXVzZSBpdDxicj4NCiZn dDsgJmd0OyBkb2VzIG5vdCBoYXZlIHRvIG1vbml0b3IvbWljcm8tbWFuYWdlIGFueSBvZiB0aGVt KTs8YnI+DQomZ3Q7ICZndDsgKiBDUFUgYW5kIGJhbmR3aWR0aCBzYXZpbmdzIGR1ZSB0byB0aGUg cmVkdWNlZCBhbW91bnQgb2Y8YnI+DQomZ3Q7IGNvbW11bmljYXRpb248YnI+DQomZ3Q7ICZndDsg YmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgbmV0d29yazxicj4NCiZndDsgJmd0OyAqIFRoZSBj bGllbnQgY2FuIHRha2UgaXRzZWxmIG91dCBvZiB0aGUgbmV0d29yayBjb250cm9sIGxvb3AsJm5i c3A7IGNoYW5nZTxicj4NCiZndDsgJmd0OyBpdHMgcm9sZSBmcm9tIGJlaW5nIG5ldHdvcmsncyAm cXVvdDttaWNyby1tYW5hZ2VyJnF1b3Q7IHRvIGJlaW5nIG5ldHdvcmsnczxicj4NCiZndDsgJmd0 OyAmcXVvdDtwb2xpY2Ugb2ZmaWNlciZxdW90Oywgd2hvIGludGVyZmVyZXMgaW50byBuZXR3b3Jr IG9wZXJhdGlvbnMgb25seSBpbjxicj4NCiZndDsgJmd0OyBleGNlcHRpb25hbC91bnByZWRpY3Rl ZCBzaXR1YXRpb25zPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmY8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29uZiBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABBAB1sjceml521mbxchi_-- From nobody Thu Nov 2 19:44:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C6013FB19 for ; Thu, 2 Nov 2017 19:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgICA08hr_eG for ; Thu, 2 Nov 2017 19:44:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6808813FB17 for ; Thu, 2 Nov 2017 19:44:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRX72083; Fri, 03 Nov 2017 02:44:45 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 3 Nov 2017 02:44:43 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Fri, 3 Nov 2017 10:44:25 +0800 From: Tianran Zhou To: Alexander Clemm , Igor Bryskin , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNTRcP+8IRW4X7BQLWoDi7NxZEQlQAQ00JgABnYUAAAA96CMAATYieQ Date: Fri, 3 Nov 2017 02:44:24 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD00786391C1933D2@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB84D@sjceml521-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.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59FBD81D.014A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 391c2aaf4a7339387475bd207c66fbec Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 02:44:50 -0000 Hi Alex, I do agree with your perspective on the scope considerations. And I like the 90/10 rule. Cheers, Tianran > -----Original Message----- > From: Alexander Clemm > Sent: Friday, November 03, 2017 2:00 AM > To: Igor Bryskin; Tianran Zhou; Xufeng Liu; netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation Probl= em > Statement >=20 > Hi, >=20 > Clearly there is a case to be made for the ability of simple automation > / closed control loops on the server. >=20 > Just a few comments regarding the role of YANG Push smart filters in this= , > and where I view the boundary between them: >=20 > - A smart filter allows to send updates only when certain filter conditio= ns > regarding its values are met, possibly involving state. Example: A > threshold has been crossed, a high-water mark has been breached. These > updates clearly constitute "events" that can feed into an > event/condition/action rule. > - That said, the focus on smart filters is to be smart-yet-simple, applyi= ng > 90/10 rule. It is not the intention to make this assume the role of a ge= neral > "Event + Expression MIB". For examples, events that would require > cross-correlation comparing values across data items, processing entire > lists, computing aggregates over time, etc, would be outside the scope. > - The assessment of any conditions would be left for the automation frame= work. > In other words, a smart filter will just assess the update itself against > a smart filter. It will not make additional checks with regards to other > data or take other actions as a result of the filter before sending an ev= ent. > That would be precisely left for the automation stages. There is a reaso= n > that it's "event-condition-action", not simply "trigger-action". >=20 > --- Alex >=20 >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Igor > > Bryskin > > Sent: Thursday, November 02, 2017 9:54 AM > > To: Tianran Zhou ; Xufeng Liu > > ; netconf@ietf.org > > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Hi Tianran, > > > > Thanks for your comments. > > > > Please, note that we see smart filters as a significant step from > > current push machinery in evolution of network control automation, > > because it empowers the client to instruct the network to identify and > > focus on "outliers", rather than on routine changes in the network > > State. I agree, this will impose more complexity on the network, but > > the benefits are obvious. For example, instead of receiving tons of > > largely useless information, 99% of which to be discarded after the > > processing, the client will be able to receive only "interesting" > > information WRT actionable events. The network control automation > framework intends to make one step further in this evolution. > > We are basically asking "Why sending notifications is the only action > > that could be triggered by model defined events and/or push > > subscriptions and/or smart filters"? Why, for example, pre-defined > > network re- configurations could not be triggered by smart filters? > > Why it is not possible for the client to pre-configure d esired a cti= ons > ahead of time?" > > > > Think about a battleship that just has been torpedoed. The crew > > members are not expected to just identify holes/leaks in the ship's > > bottom, report the "telemetry" to the captain and wait for > > instructions on what to do next, right? Each crew member not only > > knows his/her pre-defined actions, (s)he is meticulously trained on a > > daily basis on how to carry out them in the most efficient way. This > > is how ships survive problems like that. Also this is how the same auth= ority > can control big and multiple ships. > > > > Cheers, > > Igor > > > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Tianran > > Zhou > > Sent: Wednesday, November 01, 2017 11:31 PM > > To: Xufeng Liu; netconf@ietf.org > > Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control > > Automation Problem Statement > > > > Hi Xufeng, > > > > On the smart filters (also relates to > > https://tools.ietf.org/html/draft-clemm- > > netconf-push-smart-filters-ps-00), I think we need criteria to > > carefully select "conditions". While there are many benefit, say save > > the bandwidth and relief the collector, it will add computation burden > to network devices. > > Network devices are not good at this as servers. > > So maybe: > > 1. should not too complex to implement. > > 2. must help to mitigate the export volume. > > > > If so, for example, the average value should be out of scope, IMHO. > > > > Best, > > Tianran > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xufeng > > > Liu > > > Sent: Thursday, November 02, 2017 3:31 AM > > > To: netconf@ietf.org > > > Subject: [Netconf] YANG PUSH Based Generalized Network Control > > > Automation Problem Statement > > > > > > Dear WG, > > > > > > The Yang-push Dezign Team has been working on the Yang push > > enhancement. > > > We have posted a draft on the problem statement to extend Yang push > > > to a more generalized network control automation framework. > > > > > > The following is the summary of this topic. Any comments, thoughts, > > > and suggestions are appreciated. > > > > > > Thanks, > > > - Xufeng > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > YANG PUSH Based Generalized Network Control Automation > > > draft-bryskin-netconf-automation-framework-00 > > > > > > Evolution of YANG Based Network Automation > > > * "Custom Subscription to Event Notifications" model : > > > - allows for a client to subscribe to unsolicited event > > > notifications defined by supported YANG models; > > > > > > * "Subscribing to YANG datastore push updates" model: > > > - allows for a client to define subscribable events and contents of > > > event notifications as target-trigger-notify triplets > > > > > > * "Smart filters for Push Updates" model: > > > - allows for a client to filter event triggers and notifications on > > > push object values and their change history, focuses on "outliers" > > > > > > Objectives of YANG PUSH Based Generalized Network Control > > > Automation > > > 1) To generalize target-trigger-notify concept into > > > event-condition-action concept, where: > > > > > > event - a particular change in the network state explicitly defined > > > by one of the YANG models supported by the network or implicitly > > > defined by the client, which is constantly monitored by the network; > > > > > > condition - a logical expression that is evaluated only once after > > > the associated event is detected; > > > > > > action - an operation to be carried out by the network when the > > > associated event is detected and the associated condition is met > > > > > > 2) To provide for a client a capability to configure the > > > event-condition-action triplets as policy rules ahead of time or/and > > > during network operations > > > > > > Generalized Action > > > * Send notification > > > * Perform immediate network reconfiguration (e.g. modify one or more > > > attributes of one or more CONFIG=3DTRUE data store nodes); > > > * Schedule one time or periodic reconfiguration in the future; > > > * Call RPC defined by one of the YANG models supported by the > > > network ( > > e.g. > > > call network's path computer to evaluate whether an alternative/more > > > optimal path is available for a given connection) > > > * Link/unlink data store dynamic sub-trees; > > > * Etc. > > > > > > Relationship with Policy Framework > > > * The framework should work autonomously > > > > > > * The framework should fit well within a higher level policy > > > framework, with the latter possibly providing a greater level of > automation: > > > - multiple micro-conditions could be combined into a single > > > macro-condition via a number of logical operations; > > > - multiple micro-actions could be combined into a single > > > transaction with a possibility of specifying policies with respect > > > to handling errors/exceptions of each of the transaction components > > > > > > Framework Benefits > > > * lower latency, faster responsiveness of the network to various > > > events/conditions; > > > * better scale (e.g. the client may control more networks because it > > > does not have to monitor/micro-manage any of them); > > > * CPU and bandwidth savings due to the reduced amount of > > communication > > > between the client and the network > > > * The client can take itself out of the network control loop, > > > change its role from being network's "micro-manager" to being > > > network's "police officer", who interferes into network operations > > > only in exceptional/unpredicted situations > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 2 20:43:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D632F13FB49 for ; Thu, 2 Nov 2017 20:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, RCVD_IN_SORBS_SPAM=0.5, RCVD_IN_SORBS_WEB=1.5, 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=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 s-Yiazw9Bh60 for ; Thu, 2 Nov 2017 20:43:12 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 907AF13FB35 for ; Thu, 2 Nov 2017 20:43:12 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id d28so1262965pfe.2 for ; Thu, 02 Nov 2017 20:43:12 -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=vlUiovbig6PVWrud4cWLbLG4NMsrxjya9btNzTX2ySk=; b=liJzZGfLK6v912YbpuayE/mqgRd+ZFYG7AQhcRzb3dwrFb14o6boc7surxWWkzskpb bKewogxNwhnEaWT1Hsd5DUas4GFYkEIjVYIHjL4i9MrGG7YbLo1X/mWDt+FkHYGWKexr 6Oa7d+VEptg5unGgYuufBmWcNbkqRD7FQxGfQoc14TxuQGNA4VrTbbusc2frNq6STVl/ 9r0Yewy/Q0wLNPZbJWgHEORQfjvudI3eWZ+viH/x1YruX6RtJ9AQQyBvzjgL2fqEi1p+ mOaznSTBoj2l5QDW/uvMejTcFOZiGDHRNGqa8UdMtDiOxY3oMOtIvq9ek0t6eoX9QUCi afZA== 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=vlUiovbig6PVWrud4cWLbLG4NMsrxjya9btNzTX2ySk=; b=mBmqSUy7tJZHuKFPY4zu6eh+OS/bEazsLxaIHP7RL+aPjGWluwB9vLNXKpTVMeItFa Ipdu5FOAJVeOdg9zQKOss3RH6q5c9EIqcWoYpzkVh1OhE8CgBUmxNCz7EGZAKWmGfuhb 8gW+thkywoYOreV6oU/W6RGTOj56Mkwyxhfwi84xhgJ1NmTkN5O42tOseSlmkcH6gxzI cl8IylrrFc9gzreO4B0YFQjS4FcFsOh1CPLQJX4Z9Pwknzg0L4r9Pv2vrOcsydtr2Xff r2YRnaxLd/km5Q8BeGQBRLflsZTUXiGmha7g3NTE4vhzNuzqil3tHjkBt4rEMr+i+YZ6 7B+A== X-Gm-Message-State: AMCzsaVbuSHuayVJgvBX11aHsF6ub+OrfFOyxfl85ENDT8Ez7FFns5xC m4ZuV0HHdezRu0xNGHjunNqlYsy+ X-Google-Smtp-Source: ABhQp+Tc3HiMLTxL3pWqHjR8B2B2bEHa5OORiziK+CfdL609FeA3udFJbnXgrP/eVWj3JW64GOkaWA== X-Received: by 10.101.70.201 with SMTP id n9mr2407714pgr.197.1509680591826; Thu, 02 Nov 2017 20:43:11 -0700 (PDT) Received: from [172.20.0.37] ([203.143.24.34]) by smtp.gmail.com with ESMTPSA id e6sm9011643pfg.42.2017.11.02.20.43.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 20:43:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <89977C01-0388-4834-9918-DDF5F7E0F88B@juniper.net> Date: Fri, 3 Nov 2017 11:43:07 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <49B14A49-49A3-4222-8FAE-77047F77C81A@gmail.com> References: <89977C01-0388-4834-9918-DDF5F7E0F88B@juniper.net> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] draft agenda posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 03:43:14 -0000 Also, presenters, please have a draft version of your slides to us = latest by Sunday, Nov. 12.=20 > On Nov 3, 2017, at 1:44 AM, Kent Watsen wrote: >=20 >=20 > The draft agenda for the NETCONF session has been posted: >=20 > = https://datatracker.ietf.org/meeting/100/materials/agenda-100-netconf/ >=20 > It's a tight schedule; authors are requested to plan accordingly. >=20 > Cheers, > Kent (and Mahesh) Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Nov 6 01:26:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653B13FB6C for ; Mon, 6 Nov 2017 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH0NDBl0ZqGR for ; Mon, 6 Nov 2017 01:26:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ABB13F963 for ; Mon, 6 Nov 2017 01:26:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSC03066; Mon, 06 Nov 2017 09:26:13 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 6 Nov 2017 09:26:13 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Mon, 6 Nov 2017 17:26:09 +0800 From: Tianran Zhou To: "netconf@ietf.org" Thread-Topic: new draft on Subscription to Multiple Stream Originators Thread-Index: AdNW4UbmC/eSCpDzQX+VdwRoPCQb1w== Date: Mon, 6 Nov 2017 09:26:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5A002AB6.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1630591e77eb1e27f8f50bd6f739e357 Archived-At: Subject: [Netconf] new draft on Subscription to Multiple Stream Originators X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 09:26:18 -0000 Hi WG, The draft-ietf-netconf-udp-pub-channel-00(https://tools.ietf.org/html/draft= -ietf-netconf-udp-pub-channel-00) was adopted with two parts content, one r= egards to the distributed data collection and the other regards to the UDP = publication channel. During the DT discussion, we decided to extract the distributed data collec= tion part, generalize this topic and generate a new draft: draft-zhou-netco= nf-multi-stream-originators-00 (https://tools.ietf.org/html/draft-zhou-netc= onf-multi-stream-originators-00). While preparing the new revision, we look forward to your comments and sugg= estions on this new draft. Abstraction: This document describes the distributed data collection mechanism that allo= ws multiple data streams to be managed using a single subscription. Specifi= cally, multiple data streams are pushed directly to the collector without p= assing through a broker for internal consolidation. Issues Being Worked: *Subscription Decomposition --Keep track of resources and the associated publisher --Make decision on decomposing the global subscription into multiple compon= ent subscriptions. *Publication Composition --Compose the component notifications into one. *Subscription Management --Error codes related to the Subscription Decomposition and Component Subsc= ription *Notifications on Subscription State Changes --Each component subscription maintains its own subscription state and is r= esponsible for sending its own OAM notifications. *Potential Issues --Synchronization --Configured Subscription and Call Home Thanks, Tianran From nobody Tue Nov 7 17:40:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452712EAB7 for ; Tue, 7 Nov 2017 17:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z2geEl4TzvO2 for ; Tue, 7 Nov 2017 17:40:47 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 AD65E12EA24 for ; Tue, 7 Nov 2017 17:40:47 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id l24so829328pgu.11 for ; Tue, 07 Nov 2017 17:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=xYJzkaRctREIEtHg2UVkYBBSz+Ty3Egg0HrooeW+i3k=; b=vCaglPGCPMNeTAkmCWqF65hJ9Cq3byi6bvnBylbjINOcBaDzJg+jmoRRy3qivrD7gD Prv/PMhDmqXh6lYofX+rxPpqs2PmaSMDld5SwefbpBmccH5wq4pdFkNsVkzz2M+ydbua kifpmTCuSw8bzo7j2kzcu+uIcfZKDwfnnr1akiyAZ0Mg67XvFg0WVmXsD4PsTauKWCPI CESleyeMccB/A3YUfv42qh5mOFeDJdvs/1iKkhQbUE9/T1JeXhlBiEOzNYQpIIv84k0T x7v2/TbYNIAWxrM5wF9zOt6pE8x+9LHw4dA1TJ2vfXMMKDoZormJW7QzgiqMf/DFOgV8 Xd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=xYJzkaRctREIEtHg2UVkYBBSz+Ty3Egg0HrooeW+i3k=; b=eLY4b2040vOgxNsdc4XdTWDhuTkqcABzuDAmCgg9pfLA3CepVCNhmJ+AoEwa9lCpsK jlJlJJkZmFnIXwVJanAChcCI7P5bLqpQBBJN/sVGBM69xmFkeEKtUAoQGDWsNEvDAn4T KfXlmX1yonKYj5zuL2B/wCzBD7uEp03rn8UrlR5+CyCaWMs4PCarSVxFB0yweZ/dyulx nKhA9JgxxnoJeRRQk1omMy1wglLWJC2io29j4XdVKYK71IEmrGX0F3t2xyL3R+NrUDFS CWa2OqTSCAwO3dUttIRSs6hQljS8VZKPbvsf0PHKu2/KbI6uY3rrtt1oJJf2REiJ1+9s 2/bw== X-Gm-Message-State: AJaThX4OKBs4/I6/mJmESVpEKSb9dZhXNPZt6MTQuTH/9vw/jlPYvpKA FBiCSsV6b/BoTGEb8bk/Phc6bQum X-Google-Smtp-Source: ABhQp+QY0JOT3c2MEVQ0w9tkSnfNAdeDO4uuF4qenNMylAeM0XoYDJ1F82kpnD1lfnV2jXCQEOg5Sw== X-Received: by 10.99.171.6 with SMTP id p6mr672383pgf.30.1510105246802; Tue, 07 Nov 2017 17:40:46 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1001::3fb? ([2001:420:c0c8:1001::3fb]) by smtp.gmail.com with ESMTPSA id t18sm5044928pfi.98.2017.11.07.17.40.43 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Nov 2017 17:40:45 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_EC9F3D26-F10B-4467-830A-DCCBF60845AC" Message-Id: Date: Wed, 8 Nov 2017 07:10:41 +0530 To: netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Review of subscribed notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 01:40:50 -0000 --Apple-Mail=_EC9F3D26-F10B-4467-830A-DCCBF60845AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed -05 version of the subscribed notifications draft. I = know the authors have published a more updated version. If the comments = in this review have been addressed in the later version of the draft, = authors can indicate it so. As some reviewers have already indicated, the document is hard to read. = It would help if the authors could work on sentence construction and = consistency in usage of terms. The other, and this has been conveyed to = the authors by the chairs is the desire to see = draft-ietf-netconf-netconf-event-notifications and = draft-ietf-netconf-restconf-notif be reviewed and published along with = this draft. We think they make for a nice fit together. Comments. Section 1.3 Why is configured subscription optional but dynamic subscription is not? = At least it does not say so for dynamic subscription. "For connection less or stateless transport like HTTP, =E2=80=A6 that = will terminate dynamic subscriptions" - Do not understand this = statement. When is this session terminated if it is connection less = and/or stateless? Configured subscriptions can be modified by any configuration client. Is = it not the case that that subscription is controlled by user/NACM more = than whether the client has the write permission? Same is true for = dynamic subscription. Is there a graceful termination of a dynamic subscription? Does not seem = apparent reading the paragraph. Section 2.1 Are there no notifications over RESTCONF? If so, why are they not = mentioned over here. And are notifications always encoded using XML? = There is a reference to other forms of encoding in Section 4.1, under = Dynamic Subscriptions. If it is true for configured subscriptions also, = could it be stated up front? Are publisher and system the same entity? If not, what is the = difference? If they are the same, can we be consistent in the = nomenclature? Doesn't NACM define notification permissions on the publisher? The = receiver may not have permission for every event generated by the = publisher. Section 2.2 Isn't the definition of filter just that. Do not understand the = implication of the definition of Event Filter and how it is different = from other filters. Section 2.3 What constitutes an "asserted subscription to be externally visible"? If the state machine is from the perspective of the publisher, then can = the publisher unilaterally "start" a subscription? Or is that it sits in = init state, waiting for a subscription request to be received? Can a receiver suspend subscription to an event stream? Section 3 Note the recent discussion around size of the tree traversing multiple = pages. In general if a tree diagram spans multiple pages, it loses its = readability. Consider breaking up the tree into multiple parts, = particularly rpc and notifications parts of the tree. An explanation at = the top of each part of the tree will go a long way towards readability.=20= What does it mean to have a =E2=80=9Cfilter inline for each = subscription=E2=80=9D? Could it be that =E2=80=9CFilters=E2=80=9D are = just pre-defined set of filters, while everything else is specified at = the time of subscription? Section 4 This section repeats the fact how subscriptions can be modified, = deleted, killed using the session that was used to establish the = subscription. What happens if the session itself goes away? Section 4.1=20 Isn=E2=80=99t replay subscription and notification a function of the = capability of the publisher in how many historical events it can hold? = Would it not be simpler for the publisher all the events it has in its = history buffer and let the subscriber throw away whatever it is not = interested in? What happens if the subscription time is older than the = oldest event in the history buffer? Section 4.2 Can we use =E2=80=9Cconfigured subscriptions=E2=80=9D consistently, = instead of sometimes saying =E2=80=9CSubscriptions created by = configuration=E2=80=9D. The term =E2=80=9Cconfigured subscriptions=E2=80=9D= seems to be re-introduced in Section 5, when it is defined in Section = 1.2. Suggest removing the section definition. Also if configured subscriptions cannot be modified, which BTW is not = obvious why, then it would help to say that the configured subscription = needs to be terminated by (??), and a new = subscription be created. More later. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EC9F3D26-F10B-4467-830A-DCCBF60845AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed -05 version of the subscribed notifications = draft. I know the authors have published a more updated version. If the = comments in this review have been addressed in the later version of the = draft, authors can indicate it so.

As some reviewers have already = indicated, the document is hard to read. It would help if the authors = could work on sentence construction and consistency in usage of terms. = The other, and this has been conveyed to the authors by the chairs is = the desire to see draft-ietf-netconf-netconf-event-notifications and = draft-ietf-netconf-restconf-notif be reviewed and published along with = this draft. We think they make for a nice fit together.

Comments.

Section = 1.3
  • Why is configured subscription = optional but dynamic subscription is not? At least it does not say so = for dynamic subscription.
  • "For connection less or = stateless transport like HTTP,  =E2=80=A6 that will terminate = dynamic subscriptions" - Do not understand this statement. When is this = session terminated if it is connection less and/or stateless?
  • Configured subscriptions can be modified by any configuration = client. Is it not the case that that subscription is controlled by = user/NACM more than whether the client has the write permission? Same is = true for dynamic subscription.
  • Is there a graceful = termination of a dynamic subscription? Does not seem apparent reading = the paragraph.
Section 2.1
  • Are there no notifications over = RESTCONF? If so, why are they not mentioned over here. And are = notifications always encoded using XML? There is a reference to other = forms of encoding in Section 4.1, under Dynamic Subscriptions. If it is = true for configured subscriptions also, could it be stated up = front?
  • Are publisher and system the same entity? If = not, what is the difference? If they are the same, can we be consistent = in the nomenclature?
  • Doesn't NACM define notification = permissions on the publisher? The receiver may not have permission for = every event generated by the publisher.
Section = 2.2
  • Isn't the definition of filter = just that. Do not understand the implication of the definition of Event = Filter and how it is different from other filters.
Section 2.3
  • What = constitutes an "asserted subscription to be externally visible"?
  • If the state machine is from the perspective of the = publisher, then can the publisher unilaterally "start" a subscription? = Or is that it sits in init state, waiting for a subscription request to = be received?
  • Can a receiver suspend subscription to = an event stream?
Section 3
  • Note the recent discussion around size of the tree traversing = multiple pages. In general if a tree diagram spans multiple pages, it = loses its readability. Consider breaking up the tree into multiple = parts, particularly rpc and notifications parts of the tree. An = explanation at the top of each part of the tree will go a long way = towards readability. 
  • What does it mean to have = a =E2=80=9Cfilter inline for each subscription=E2=80=9D? Could it be = that =E2=80=9CFilters=E2=80=9D are just pre-defined set of filters, = while everything else is specified at the time of = subscription?

Section 4
  • This section repeats the fact how subscriptions can = be modified, deleted, killed using the session that was used to = establish the subscription. What happens if the session itself goes = away?

Section = 4.1 
  • Isn=E2=80=99t replay = subscription and notification a function of the capability of the = publisher in how many historical events it can hold? Would it not be = simpler for the publisher all the events it has in its history buffer = and let the subscriber throw away whatever it is not interested in? What = happens if the subscription time is older than the oldest event in the = history buffer?

Section 4.2
  • Can we use =E2=80=9Cconfigured = subscriptions=E2=80=9D consistently, instead of sometimes = saying =E2=80=9CSubscriptions created by configuration=E2=80=9D. = The term =E2=80=9Cconfigured subscriptions=E2=80=9D seems to = be re-introduced in Section 5, when it is defined in Section 1.2. = Suggest removing the section definition.
  • Also if configured subscriptions = cannot be modified, which BTW is not obvious why, then it would help to = say that the configured subscription needs to be terminated by = <delete-subscription> (??), and a new subscription be = created.

More later. Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_EC9F3D26-F10B-4467-830A-DCCBF60845AC-- From nobody Wed Nov 8 07:21:32 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C51274A5 for ; Wed, 8 Nov 2017 07:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFYqorSxLPQX for ; Wed, 8 Nov 2017 07:21:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73F512711B for ; Wed, 8 Nov 2017 07:21:25 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK43666; Wed, 08 Nov 2017 15:21:23 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 15:21:23 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 23:21:09 +0800 From: Qin Wu To: Igor Bryskin , Alexander Clemm , Tianran Zhou , "Xufeng Liu" , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNYozCctBUDrHqNQFassZLcA0NQKA== Date: Wed, 8 Nov 2017 15:21:08 +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.3.229] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5A0320F4.0057, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.198, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a19e6a6149ac33c98f289bbe0730ca1 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 15:21:30 -0000 SW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZG9lcyBzbWFydCBmaWx0ZXIgbWVhbiB0aGF0IG5ldGNv bmYgc2VydmVyIHNob3VsZCBiZSBzdGF0ZWZ1bCBzaW5jZSBpdCBrZWVwIGEgZmV3IHN0YXRlIHdo aWxlIHRyYWRpdGlvbmFsIHlhbmcgcHVzaCBkb2Vzbid0IHJlcXVpcmUgbmV0Y29uZiBzZXZlciB0 byBiZSBzdGF0ZWZ1bCwgaS5lLiwgc2hvdWxkIGJlIHN0YXRlbGVzcz8NCkkgdGhpbmsgc2V0IHRo cmVzaG9sZCBmb3IgcGFja2V0IGxvc3Mgb3IgbGF0ZW5jeSBpcyBwcmV0dHkgbXVjaCBjb21tb24g aW4gbmV0d29yayB0cm91YmxlIHNob290aW5nLCBzdWNoIHRocmVzaG9sZCBjYW4gYmUgYWxzbyBt b3ZlZCBkb3duIG92ZXIgdGltZS4NCldoYXQga2luZCBvZiB0aHJlc2hvbGQgY2FuIGJlIHNldCBt b3JlIGRlcGVuZHMgb24gZW1waXJpY2FsIGV4cGVyaWVuY2UuIEkgYW0gd29uZGVyaW5nIGhvdyB0 aGlzIGNhbiBiZSBtb2RlbGVkIHVzaW5nIFhQQVRIIHN0YXRlbWVudCBvciBzb21lIG90aGVyIG1l Y2hhbmlzbS4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSWdvciBCcnlza2luDQq3osvNyrG8 5DogMjAxN8TqMTHUwjPI1SAzOjQyDQrK1bz+yMs6IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVy LmNsZW1tQGh1YXdlaS5jb20+OyBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+ OyBYdWZlbmcgTGl1IDxYdWZlbmdfTGl1QGphYmlsLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNCtb3 zOI6IFJlOiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29u dHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIEFsZXgsDQoNClRoYW5rcyBm b3IgeW91ciB0aG91Z2h0ZnVsIGNvbW1lbnRzLiBQbGVhc2UsIHNlZSBpbi1saW5lLg0KDQpJZ29y DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5kZXIgQ2xlbW0NClNl bnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAyOjAwIFBNDQpUbzogSWdvciBCcnlza2lu OyBUaWFucmFuIFpob3U7IFh1ZmVuZyBMaXU7IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24g UHJvYmxlbSBTdGF0ZW1lbnQNCg0KSGksDQoNCkNsZWFybHkgdGhlcmUgaXMgYSBjYXNlIHRvIGJl IG1hZGUgZm9yIHRoZSBhYmlsaXR5IG9mIHNpbXBsZSBhdXRvbWF0aW9uIC8gY2xvc2VkIGNvbnRy b2wgbG9vcHMgb24gdGhlIHNlcnZlci4gIA0KDQpKdXN0IGEgZmV3IGNvbW1lbnRzIHJlZ2FyZGlu ZyB0aGUgcm9sZSBvZiBZQU5HIFB1c2ggc21hcnQgZmlsdGVycyBpbiB0aGlzLCBhbmQgd2hlcmUg SSB2aWV3IHRoZSBib3VuZGFyeSBiZXR3ZWVuIHRoZW06DQoNCi0gQSBzbWFydCBmaWx0ZXIgYWxs b3dzIHRvIHNlbmQgdXBkYXRlcyBvbmx5IHdoZW4gY2VydGFpbiBmaWx0ZXIgY29uZGl0aW9ucyBy ZWdhcmRpbmcgaXRzIHZhbHVlcyBhcmUgbWV0LCBwb3NzaWJseSBpbnZvbHZpbmcgc3RhdGUuICBF eGFtcGxlOiBBIHRocmVzaG9sZCBoYXMgYmVlbiBjcm9zc2VkLCBhIGhpZ2gtd2F0ZXIgbWFyayBo YXMgYmVlbiBicmVhY2hlZC4gIFRoZXNlIHVwZGF0ZXMgY2xlYXJseSBjb25zdGl0dXRlICJldmVu dHMiIHRoYXQgY2FuIGZlZWQgaW50byBhbiBldmVudC9jb25kaXRpb24vYWN0aW9uIHJ1bGUuIA0K DQpJQj4+IEV4YWN0bHkuIEZvciBleGFtcGxlLCBjb25zaWRlciB0aGUgbG9naWM6DQoNCmlmKGxp bmsncyBiYW5kd2lkdGggdXRpbGl6YXRpb24gPiA4MCUgdGhyZXNob2xkKSAvKiBzbWFydCBmaWx0 ZXIgKi8NCiAgIGNvbmZpZ3VyZSBwYXJhbGxlbCBsaW5rIC8qIGdlbmVyYWxpemVkIGFjdGlvbiAq Lw0KDQpJZiB0aGUgY2xpZW50IGtub3dzIHRoYXQgdGhpcyBpcyB3aGF0IG5lZWRzIHRvIGJlIGRv bmUgaW4gc3VjaCBhbiBldmVudCwgd2h5IG5vdCB0byBzYXkgdGhhdCBhaGVhZCBvZiB0aW1lIGlu c3RlYWQgb2YgcHJvY2Vzc2luZyB0aGUgbGluaydzIHRlbGVtZXRyeSBhbmQgYXNraW5nIGZvciB0 aGUgYWN0aW9uIHJlYWN0aXZlbHk/ICAgDQogDQotIFRoYXQgc2FpZCwgdGhlIGZvY3VzIG9uIHNt YXJ0IGZpbHRlcnMgaXMgdG8gYmUgc21hcnQteWV0LXNpbXBsZSwgYXBwbHlpbmcgOTAvMTAgcnVs ZS4gIEl0IGlzIG5vdCB0aGUgaW50ZW50aW9uIHRvIG1ha2UgdGhpcyBhc3N1bWUgdGhlIHJvbGUg b2YgYSBnZW5lcmFsICJFdmVudCArIEV4cHJlc3Npb24gTUlCIi4gICBGb3IgZXhhbXBsZXMsIGV2 ZW50cyB0aGF0IHdvdWxkIHJlcXVpcmUgY3Jvc3MtY29ycmVsYXRpb24gY29tcGFyaW5nIHZhbHVl cyBhY3Jvc3MgZGF0YSBpdGVtcywgcHJvY2Vzc2luZyBlbnRpcmUgbGlzdHMsIGNvbXB1dGluZyBh Z2dyZWdhdGVzIG92ZXIgdGltZSwgZXRjLCB3b3VsZCBiZSBvdXRzaWRlIHRoZSBzY29wZS4gIA0K SUI+PiBGYWlyIGVub3VnaC4gQnV0IHNlbmRpbmcgbm90aWZpY2F0aW9uIGFuZCByZWx5aW5nIG9u IGEgaGlnaGVyIChjbGllbnQncykgaW50ZWxsaWdlbmNlIGlzIG9uZSBvZiB0aGUgYWN0aW9ucywg YnV0IGl0IGlzIG5vdCB0aGUgb25seSBvbmUuIEhvdyB0aGUgY2xpZW50J3MgYW5kIG5ldHdvcmsn cyBpbnRlbGxpZ2VuY2VzIGFyZSBzcGxpdCBjb3VsZCBiZSBvcHRpbWl6ZWQgYW5kIGJlc3QgY29t cHJvbWlzZXMgZm91bmQgICANCiANCi0gVGhlIGFzc2Vzc21lbnQgb2YgYW55IGNvbmRpdGlvbnMg d291bGQgYmUgbGVmdCBmb3IgdGhlIGF1dG9tYXRpb24gZnJhbWV3b3JrLiAgSW4gb3RoZXIgd29y ZHMsIGEgc21hcnQgZmlsdGVyIHdpbGwganVzdCBhc3Nlc3MgdGhlIHVwZGF0ZSBpdHNlbGYgYWdh aW5zdCBhIHNtYXJ0IGZpbHRlci4gIEl0IHdpbGwgbm90IG1ha2UgYWRkaXRpb25hbCBjaGVja3Mg d2l0aCByZWdhcmRzIHRvIG90aGVyIGRhdGEgb3IgdGFrZSBvdGhlciBhY3Rpb25zIGFzIGEgcmVz dWx0IG9mIHRoZSBmaWx0ZXIgYmVmb3JlIHNlbmRpbmcgYW4gZXZlbnQuICBUaGF0IHdvdWxkIGJl IHByZWNpc2VseSBsZWZ0IGZvciB0aGUgYXV0b21hdGlvbiBzdGFnZXMuICBUaGVyZSBpcyBhIHJl YXNvbiB0aGF0IGl0J3MgImV2ZW50LWNvbmRpdGlvbi1hY3Rpb24iLCBub3Qgc2ltcGx5ICJ0cmln Z2VyLWFjdGlvbiIuIA0KDQpJQj4+IGFncmVlICAgIA0KDQotLS0gQWxleA0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElnb3IgDQo+IEJyeXNraW4NCj4gU2VudDogVGh1 cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDk6NTQgQU0NCj4gVG86IFRpYW5yYW4gWmhvdSA8emhv dXRpYW5yYW5AaHVhd2VpLmNvbT47IFh1ZmVuZyBMaXUgDQo+IDxYdWZlbmdfTGl1QGphYmlsLmNv bT47IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBZQU5HIFBVU0gg QmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIA0KPiBBdXRvbWF0aW9uIFByb2JsZW0g U3RhdGVtZW50DQo+IA0KPiBIaSBUaWFucmFuLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLg0KPiANCj4gUGxlYXNlLCBub3RlIHRoYXQgd2Ugc2VlIHNtYXJ0IGZpbHRlcnMgYXMgYSBz aWduaWZpY2FudCBzdGVwIGZyb20gDQo+IGN1cnJlbnQgcHVzaCBtYWNoaW5lcnkgaW4gZXZvbHV0 aW9uIG9mIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uLCANCj4gYmVjYXVzZSBpdCBlbXBvd2Vy cyB0aGUgY2xpZW50IHRvIGluc3RydWN0IHRoZSBuZXR3b3JrIHRvIGlkZW50aWZ5IGFuZCANCj4g Zm9jdXMgb24gIm91dGxpZXJzIiwgcmF0aGVyIHRoYW4gb24gcm91dGluZSBjaGFuZ2VzIGluIHRo ZSBuZXR3b3JrIA0KPiBTdGF0ZS4gSSBhZ3JlZSwgdGhpcyB3aWxsIGltcG9zZSBtb3JlIGNvbXBs ZXhpdHkgb24gdGhlIG5ldHdvcmssIGJ1dCANCj4gdGhlIGJlbmVmaXRzIGFyZSBvYnZpb3VzLiBG b3IgZXhhbXBsZSwgaW5zdGVhZCBvZiByZWNlaXZpbmcgdG9ucyBvZiANCj4gbGFyZ2VseSB1c2Vs ZXNzIGluZm9ybWF0aW9uLCA5OSUgb2Ygd2hpY2ggdG8gYmUgZGlzY2FyZGVkIGFmdGVyIHRoZSAN Cj4gcHJvY2Vzc2luZywgdGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gcmVjZWl2ZSBvbmx5ICJp bnRlcmVzdGluZyIgDQo+IGluZm9ybWF0aW9uIFdSVCBhY3Rpb25hYmxlIGV2ZW50cy4gVGhlIG5l dHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIGZyYW1ld29yayBpbnRlbmRzIHRvIG1ha2Ugb25lIHN0 ZXAgZnVydGhlciBpbiB0aGlzIGV2b2x1dGlvbi4NCj4gV2UgYXJlIGJhc2ljYWxseSBhc2tpbmcg IldoeSBzZW5kaW5nIG5vdGlmaWNhdGlvbnMgaXMgdGhlIG9ubHkgYWN0aW9uIA0KPiB0aGF0IGNv dWxkIGJlIHRyaWdnZXJlZCBieSBtb2RlbCBkZWZpbmVkIGV2ZW50cyBhbmQvb3IgcHVzaCANCj4g c3Vic2NyaXB0aW9ucyBhbmQvb3Igc21hcnQgZmlsdGVycyI/IFdoeSwgZm9yIGV4YW1wbGUsIHBy ZS1kZWZpbmVkIA0KPiBuZXR3b3JrIHJlLSBjb25maWd1cmF0aW9ucyBjb3VsZCBub3QgYmUgdHJp Z2dlcmVkIGJ5IHNtYXJ0IGZpbHRlcnM/IA0KPiBXaHkgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0 aGUgY2xpZW50IHRvIHByZS1jb25maWd1cmUgZCAgZXNpcmVkIGEgIGN0aW9ucyBhaGVhZCBvZiB0 aW1lPyINCj4gDQo+IFRoaW5rIGFib3V0IGEgYmF0dGxlc2hpcCB0aGF0IGp1c3QgaGFzIGJlZW4g dG9ycGVkb2VkLiBUaGUgY3JldyANCj4gbWVtYmVycyBhcmUgbm90IGV4cGVjdGVkIHRvIGp1c3Qg aWRlbnRpZnkgaG9sZXMvbGVha3MgaW4gdGhlIHNoaXAncyANCj4gYm90dG9tLCByZXBvcnQgdGhl ICJ0ZWxlbWV0cnkiIHRvIHRoZSBjYXB0YWluIGFuZCB3YWl0IGZvciANCj4gaW5zdHJ1Y3Rpb25z IG9uIHdoYXQgdG8gZG8gbmV4dCwgcmlnaHQ/IEVhY2ggY3JldyBtZW1iZXIgbm90IG9ubHkgDQo+ IGtub3dzIGhpcy9oZXIgcHJlLWRlZmluZWQgYWN0aW9ucywgKHMpaGUgaXMgbWV0aWN1bG91c2x5 IHRyYWluZWQgb24gYSANCj4gZGFpbHkgYmFzaXMgb24gaG93IHRvIGNhcnJ5IG91dCB0aGVtIGlu IHRoZSBtb3N0IGVmZmljaWVudCB3YXkuIFRoaXMgDQo+IGlzIGhvdyBzaGlwcyBzdXJ2aXZlIHBy b2JsZW1zIGxpa2UgdGhhdC4gQWxzbyB0aGlzIGlzIGhvdyB0aGUgc2FtZSBhdXRob3JpdHkgY2Fu IGNvbnRyb2wgYmlnIGFuZCBtdWx0aXBsZSBzaGlwcy4NCj4gDQo+IENoZWVycywNCj4gSWdvcg0K PiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFucmFuIA0KPiBa aG91DQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDEsIDIwMTcgMTE6MzEgUE0NCj4gVG86 IFh1ZmVuZyBMaXU7IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBZ QU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIA0KPiBBdXRvbWF0aW9u IFByb2JsZW0gU3RhdGVtZW50DQo+IA0KPiBIaSBYdWZlbmcsDQo+IA0KPiBPbiB0aGUgc21hcnQg ZmlsdGVycyAoYWxzbyByZWxhdGVzIHRvIA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2xlbW0tDQo+IG5ldGNvbmYtcHVzaC1zbWFydC1maWx0ZXJzLXBzLTAwKSwgSSB0aGlu ayB3ZSBuZWVkIGNyaXRlcmlhIHRvIA0KPiBjYXJlZnVsbHkgc2VsZWN0ICJjb25kaXRpb25zIi4g V2hpbGUgdGhlcmUgYXJlIG1hbnkgYmVuZWZpdCwgc2F5IHNhdmUgDQo+IHRoZSBiYW5kd2lkdGgg YW5kIHJlbGllZiB0aGUgY29sbGVjdG9yLCBpdCB3aWxsIGFkZCBjb21wdXRhdGlvbiBidXJkZW4g dG8gbmV0d29yayBkZXZpY2VzLg0KPiBOZXR3b3JrIGRldmljZXMgYXJlIG5vdCBnb29kIGF0IHRo aXMgYXMgc2VydmVycy4NCj4gU28gbWF5YmU6DQo+IDEuIHNob3VsZCBub3QgdG9vIGNvbXBsZXgg dG8gaW1wbGVtZW50Lg0KPiAyLiBtdXN0IGhlbHAgdG8gbWl0aWdhdGUgdGhlIGV4cG9ydCB2b2x1 bWUuDQo+IA0KPiBJZiBzbywgZm9yIGV4YW1wbGUsIHRoZSBhdmVyYWdlIHZhbHVlIHNob3VsZCBi ZSBvdXQgb2Ygc2NvcGUsIElNSE8uDQo+IA0KPiBCZXN0LA0KPiBUaWFucmFuDQo+IA0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1ZmVuZyANCj4gPiBMaXUNCj4gPiBT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgMzozMSBBTQ0KPiA+IFRvOiBuZXRjb25m QGlldGYub3JnDQo+ID4gU3ViamVjdDogW05ldGNvbmZdIFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFs aXplZCBOZXR3b3JrIENvbnRyb2wgDQo+ID4gQXV0b21hdGlvbiBQcm9ibGVtIFN0YXRlbWVudA0K PiA+DQo+ID4gRGVhciBXRywNCj4gPg0KPiA+IFRoZSBZYW5nLXB1c2ggRGV6aWduIFRlYW0gaGFz IGJlZW4gd29ya2luZyBvbiB0aGUgWWFuZyBwdXNoDQo+IGVuaGFuY2VtZW50Lg0KPiA+IFdlIGhh dmUgcG9zdGVkIGEgZHJhZnQgb24gdGhlIHByb2JsZW0gc3RhdGVtZW50IHRvIGV4dGVuZCBZYW5n IHB1c2ggDQo+ID4gdG8gYSBtb3JlIGdlbmVyYWxpemVkIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0 aW9uIGZyYW1ld29yay4NCj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcgaXMgdGhlIHN1bW1hcnkgb2Yg dGhpcyB0b3BpYy4gQW55IGNvbW1lbnRzLCB0aG91Z2h0cywgDQo+ID4gYW5kIHN1Z2dlc3Rpb25z IGFyZSBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAtIFh1ZmVuZw0KPiA+DQo+ ID4gPT09PT09PT09PT09PT09PQ0KPiA+IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3 b3JrIENvbnRyb2wgQXV0b21hdGlvbg0KPiA+IGRyYWZ0LWJyeXNraW4tbmV0Y29uZi1hdXRvbWF0 aW9uLWZyYW1ld29yay0wMA0KPiA+DQo+ID4gRXZvbHV0aW9uIG9mIFlBTkcgQmFzZWQgTmV0d29y ayBBdXRvbWF0aW9uDQo+ID4gKiAiQ3VzdG9tIFN1YnNjcmlwdGlvbiB0byBFdmVudCBOb3RpZmlj YXRpb25zIiBtb2RlbCA6DQo+ID4gCS0gYWxsb3dzIGZvciBhIGNsaWVudCB0byBzdWJzY3JpYmUg dG8gdW5zb2xpY2l0ZWQgZXZlbnQgDQo+ID4gbm90aWZpY2F0aW9ucyBkZWZpbmVkIGJ5IHN1cHBv cnRlZCBZQU5HIG1vZGVsczsNCj4gPg0KPiA+ICogIlN1YnNjcmliaW5nIHRvIFlBTkcgZGF0YXN0 b3JlIHB1c2ggdXBkYXRlcyIgbW9kZWw6DQo+ID4gCS0gYWxsb3dzIGZvciBhIGNsaWVudCB0byBk ZWZpbmUgc3Vic2NyaWJhYmxlIGV2ZW50cyBhbmQgY29udGVudHMgb2YgDQo+ID4gZXZlbnQgbm90 aWZpY2F0aW9ucyBhcyB0YXJnZXQtdHJpZ2dlci1ub3RpZnkgdHJpcGxldHMNCj4gPg0KPiA+ICog IlNtYXJ0IGZpbHRlcnMgZm9yIFB1c2ggVXBkYXRlcyIgbW9kZWw6DQo+ID4gCS0gYWxsb3dzIGZv ciBhIGNsaWVudCB0byBmaWx0ZXIgZXZlbnQgdHJpZ2dlcnMgYW5kIG5vdGlmaWNhdGlvbnMgb24g DQo+ID4gcHVzaCBvYmplY3QgdmFsdWVzIGFuZCB0aGVpciBjaGFuZ2UgaGlzdG9yeSwgZm9jdXNl cyBvbiAib3V0bGllcnMiDQo+ID4NCj4gPiBPYmplY3RpdmVzIG9mICBZQU5HIFBVU0ggQmFzZWQg R2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIA0KPiA+IEF1dG9tYXRpb24NCj4gPiAxKSBUbyBn ZW5lcmFsaXplIHRhcmdldC10cmlnZ2VyLW5vdGlmeSBjb25jZXB0IGludG8gDQo+ID4gZXZlbnQt Y29uZGl0aW9uLWFjdGlvbiBjb25jZXB0LCB3aGVyZToNCj4gPg0KPiA+IAlldmVudCAtIGEgcGFy dGljdWxhciBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgc3RhdGUgZXhwbGljaXRseSBkZWZpbmVkIA0K PiA+IGJ5IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrIG9y IGltcGxpY2l0bHkgDQo+ID4gZGVmaW5lZCBieSB0aGUgY2xpZW50LCB3aGljaCBpcyBjb25zdGFu dGx5IG1vbml0b3JlZCBieSB0aGUgbmV0d29yazsNCj4gPg0KPiA+IAljb25kaXRpb24gLSBhIGxv Z2ljYWwgZXhwcmVzc2lvbiB0aGF0IGlzIGV2YWx1YXRlZCBvbmx5IG9uY2UgYWZ0ZXIgDQo+ID4g dGhlIGFzc29jaWF0ZWQgZXZlbnQgaXMgZGV0ZWN0ZWQ7DQo+ID4NCj4gPiAJYWN0aW9uIC0gYW4g b3BlcmF0aW9uIHRvIGJlIGNhcnJpZWQgb3V0IGJ5IHRoZSBuZXR3b3JrIHdoZW4gdGhlIA0KPiA+ IGFzc29jaWF0ZWQgZXZlbnQgaXMgZGV0ZWN0ZWQgYW5kIHRoZSBhc3NvY2lhdGVkIGNvbmRpdGlv biBpcyBtZXQNCj4gPg0KPiA+IDIpIFRvIHByb3ZpZGUgZm9yIGEgY2xpZW50IGEgY2FwYWJpbGl0 eSB0byBjb25maWd1cmUgdGhlIA0KPiA+IGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gdHJpcGxldHMg YXMgcG9saWN5IHJ1bGVzIGFoZWFkIG9mIHRpbWUgb3IvYW5kIA0KPiA+IGR1cmluZyBuZXR3b3Jr IG9wZXJhdGlvbnMNCj4gPg0KPiA+IEdlbmVyYWxpemVkIEFjdGlvbg0KPiA+ICogU2VuZCBub3Rp ZmljYXRpb24NCj4gPiAqIFBlcmZvcm0gaW1tZWRpYXRlIG5ldHdvcmsgcmVjb25maWd1cmF0aW9u IChlLmcuIG1vZGlmeSBvbmUgb3IgbW9yZSANCj4gPiBhdHRyaWJ1dGVzIG9mIG9uZSBvciBtb3Jl IENPTkZJRz1UUlVFIGRhdGEgc3RvcmUgbm9kZXMpOw0KPiA+ICogU2NoZWR1bGUgb25lIHRpbWUg b3IgcGVyaW9kaWMgcmVjb25maWd1cmF0aW9uIGluIHRoZSBmdXR1cmU7DQo+ID4gKiBDYWxsIFJQ QyBkZWZpbmVkIGJ5IG9uZSBvZiB0aGUgWUFORyBtb2RlbHMgc3VwcG9ydGVkIGJ5IHRoZSANCj4g PiBuZXR3b3JrICgNCj4gZS5nLg0KPiA+IGNhbGwgbmV0d29yaydzIHBhdGggY29tcHV0ZXIgdG8g ZXZhbHVhdGUgd2hldGhlciBhbiBhbHRlcm5hdGl2ZS9tb3JlIA0KPiA+IG9wdGltYWwgcGF0aCBp cyBhdmFpbGFibGUgZm9yIGEgZ2l2ZW4gY29ubmVjdGlvbikNCj4gPiAqIExpbmsvdW5saW5rIGRh dGEgc3RvcmUgZHluYW1pYyBzdWItdHJlZXM7DQo+ID4gKiBFdGMuDQo+ID4NCj4gPiBSZWxhdGlv bnNoaXAgd2l0aCBQb2xpY3kgRnJhbWV3b3JrDQo+ID4gKiBUaGUgZnJhbWV3b3JrIHNob3VsZCB3 b3JrIGF1dG9ub21vdXNseQ0KPiA+DQo+ID4gKiBUaGUgZnJhbWV3b3JrIHNob3VsZCBmaXQgd2Vs bCB3aXRoaW4gYSBoaWdoZXIgbGV2ZWwgcG9saWN5IA0KPiA+IGZyYW1ld29yaywgd2l0aCB0aGUg bGF0dGVyIHBvc3NpYmx5IHByb3ZpZGluZyBhIGdyZWF0ZXIgbGV2ZWwgb2YgYXV0b21hdGlvbjoN Cj4gPiAgIC0gbXVsdGlwbGUgbWljcm8tY29uZGl0aW9ucyBjb3VsZCBiZSBjb21iaW5lZCBpbnRv IGEgc2luZ2xlIA0KPiA+IG1hY3JvLWNvbmRpdGlvbiB2aWEgYSBudW1iZXIgb2YgbG9naWNhbCBv cGVyYXRpb25zOw0KPiA+ICAgLSBtdWx0aXBsZSBtaWNyby1hY3Rpb25zIGNvdWxkIGJlIGNvbWJp bmVkIGludG8gYSBzaW5nbGUgDQo+ID4gdHJhbnNhY3Rpb24gd2l0aCBhIHBvc3NpYmlsaXR5IG9m IHNwZWNpZnlpbmcgcG9saWNpZXMgd2l0aCByZXNwZWN0IA0KPiA+IHRvIGhhbmRsaW5nIGVycm9y cy9leGNlcHRpb25zIG9mIGVhY2ggb2YgdGhlIHRyYW5zYWN0aW9uIGNvbXBvbmVudHMNCj4gPg0K PiA+IEZyYW1ld29yayBCZW5lZml0cw0KPiA+ICogbG93ZXIgbGF0ZW5jeSwgZmFzdGVyIHJlc3Bv bnNpdmVuZXNzIG9mIHRoZSBuZXR3b3JrIHRvIHZhcmlvdXMgDQo+ID4gZXZlbnRzL2NvbmRpdGlv bnM7DQo+ID4gKiBiZXR0ZXIgc2NhbGUgKGUuZy4gdGhlIGNsaWVudCBtYXkgY29udHJvbCBtb3Jl IG5ldHdvcmtzIGJlY2F1c2UgaXQgDQo+ID4gZG9lcyBub3QgaGF2ZSB0byBtb25pdG9yL21pY3Jv LW1hbmFnZSBhbnkgb2YgdGhlbSk7DQo+ID4gKiBDUFUgYW5kIGJhbmR3aWR0aCBzYXZpbmdzIGR1 ZSB0byB0aGUgcmVkdWNlZCBhbW91bnQgb2YNCj4gY29tbXVuaWNhdGlvbg0KPiA+IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlIG5ldHdvcmsNCj4gPiAqIFRoZSBjbGllbnQgY2FuIHRha2UgaXRz ZWxmIG91dCBvZiB0aGUgbmV0d29yayBjb250cm9sIGxvb3AsICANCj4gPiBjaGFuZ2UgaXRzIHJv bGUgZnJvbSBiZWluZyBuZXR3b3JrJ3MgIm1pY3JvLW1hbmFnZXIiIHRvIGJlaW5nIA0KPiA+IG5l dHdvcmsncyAicG9saWNlIG9mZmljZXIiLCB3aG8gaW50ZXJmZXJlcyBpbnRvIG5ldHdvcmsgb3Bl cmF0aW9ucyANCj4gPiBvbmx5IGluIGV4Y2VwdGlvbmFsL3VucHJlZGljdGVkIHNpdHVhdGlvbnMN Cj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYg bWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25m QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0 Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Wed Nov 8 08:33:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C020F12871F; Wed, 8 Nov 2017 08:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 kE3TNsQN5TNv; Wed, 8 Nov 2017 08:33:13 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FBC128796; Wed, 8 Nov 2017 08:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68140; q=dns/txt; s=iport; t=1510158793; x=1511368393; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=cGRvNcyZIiibbziowse8Zb0zHBiOuyoNWnymJnkII70=; b=V9tuSNs5uufWFe76qmVnrsJRQLHGTxDtkxmMolE68RAE1vrr0TXB6wgJ h/xZdfMRamH8JyRoJ2mhoSxS7Micz5Iq9QjkcP8IbdfT+qZJAhIUsAdAH YOhMB+sZ6o4F8OefPTf1pR0V6UoqDMfjaTqxcfx8k8bn7b1/sA9hCnWeD 4=; X-Files: dfpcfioondggippe.png : 43605 X-IronPort-AV: E=Sophos;i="5.44,364,1505779200"; d="png'150?scan'150,208,217,150";a="145297" 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; 08 Nov 2017 16:33:11 +0000 Received: from [10.63.23.122] (dhcp-ensft1-uk-vla370-10-63-23-122.cisco.com [10.63.23.122]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA8GXAFX032116; Wed, 8 Nov 2017 16:33:10 GMT To: Benoit Claise , NETCONF , Andy Bierman , Martin Bjorklund Cc: "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> From: Robert Wilton Message-ID: <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> Date: Wed, 8 Nov 2017 16:33:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> Content-Type: multipart/alternative; boundary="------------35CF9CC8F241C0B429963D68" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 16:33:16 -0000 This is a multi-part message in MIME format. --------------35CF9CC8F241C0B429963D68 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm not sure about this change. I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4) With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better: E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:                  A                  |         --------------------         |      |     |     |         B      C     D     E         |    -----------    |   |  |  |    F   G  H  J              |             ... In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):    "read/write 'A/B/J' In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):    "read/write 'A/B/J'    "read A"    "deny C"    "deny D"    "deny E"    "deny F"    "deny G"    "deny H" Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified. If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given. But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-) Thanks, Rob On 02/11/2017 14:18, Benoit Claise wrote: > Dear all, > > Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by > the Security AD Eric Rescola part of the IESG review, which I would > like to validate with the WG. See > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt > > > The NETCONF WG was cc'ed for the entire discussion. > What do you think? I will draw the conclusions by Friday Nov 10th. > > Note: If the WG is fine, the next step is to approve this document. > > Regards, Benoit > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------35CF9CC8F241C0B429963D68 Content-Type: multipart/related; boundary="------------D55810C738922F667EAD62FC" --------------D55810C738922F667EAD62FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:

                 A
                 |
        --------------------
        |      |     |     |
        B      C     D     E
        |
   -----------
   |   |  |  |
   F   G  H  J
             |
            ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
   "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
   "read/write 'A/B/J'
   "read A"
   "deny C"
   "deny D"
   "deny E"
   "deny F"
   "deny G"
   "deny H"

Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:18, Benoit Claise wrote:
Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt


The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


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

--------------D55810C738922F667EAD62FC Content-Type: image/png; name="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dfpcfioondggippe.png" iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC +YHGlxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL 54BA95WpYrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIg iN2ClI8gCIIgCIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU 1budlnGWW9Ei1mf45fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluG nFMMK91+zhv/yNjzT4Gdo4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pd bo6buif+9eeWtPnXv6CR/FPYc+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJX x1+/P6TX1qbAn3/+DWvTKfuX9bC2S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi6 7wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4jlgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNX ud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllFnBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Y gfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvSS/v9L9HPMFFl8D5zbEGSizUDcgokCKIH 5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrfX8TtVh6W9yB1MxV/iBt3fOpwlw7v XD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbfwKXq6se7Lj//Sj6DlcJB+9FI FUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60IyDIBZ0CCIHpwvuN8FzTL +Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omknOhYrqi1hzNqj2od3 bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyrz1EzN0EQxL84 30WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt4qmnrDDA nL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB+Y7z XTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUj YtyTWcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35 KV73CFvrJiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX 7+JJ7+0z04ZX/O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz +95YmLPx+1/yMeRf4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV0 8idquf+lP/67/LhW/5k2PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE 7PAZOI49IrPfJ0V5TphipXuRygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWR MVfPIN/X+Z9//k1OMc9Qy8DwPJQgCGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/h E8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN 5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggbpHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIR BEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQpH0EQBLErrD2xEgRBEMS2QMpHEARB7Apr T6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjNa2EZnE+HzC6sB2G8LZmOIAhioxiZ 9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZkOoIgiJdH8fl5IxV3NnE+HcYZ UFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw81P7SxDEnpCa9NqqZxOX +jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw81P7SxDEeyJK7IQU Q1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEqyJ0AIcWQVSRJ CimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hCFmMqFlg1 urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1Eu5mm D0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL 3CW0ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YI Wu/yWetq1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/U NHcDNc3Zrp5a5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeI o4gGND27y1MLZvIPuQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t 8ln99duTIAhigLHKlxsiuxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl 1nzKp+Ujaq04WI5YRfkC1crmE9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rr P8E3YwZKFrZvMInH3uVDHQxlDPXk0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+Wb Zk+CIIgB8SYNeZRMve/lwsyUD6sDyNKbUD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPm UTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GDyXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7e C4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht0n0cLKoF63cIZ6B86kCoJV4MtQTbn29p SiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJsQL28FwT1Rv1Afhi4+9NJTcTLV2Ch S5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/SVkpCT7lSubom5cNqpuw8ws0z 7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PBd/P0Ke6NCIUUa39CuSOi 3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3PsSRDEmyA97eGP8seU LP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LPtyT0FMNYVceB kbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIlsPbESiyL J6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST9xEE sW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6C IAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhd Ye2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAI Ylsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGU jyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAI YldYe2IlCIIgiG3h+ZSvKYuiKJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G 0ZRFhxXNtdqM2lZFUVTtau0TPnC8HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5t c2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoOp7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8 XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZ xXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJWVXs7IOu11QsEyzPgUh9ze4nHa46R3CIe 6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62nqaX+mg3/dTr4hHMSfnKjo/d5vwh tJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+fpHwuZFGRuUDKNyb71Sjf+XTw rYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43PBYfEc+bhIX1bHY99vUt9 FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6hTkZi4gcoIxJ/r5K dxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebhdA4T6GBCXa/m 4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjPqJ5hsH0/ 4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+eccfX V9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eT q8ryNyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIg BcgOwM5jqseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCo yc3Yg+mb4O4sGQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqM nJpG051AgFBBv6gExusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3 q5PsRvuI/RbYTUoUbUXOpNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D951McnPo+4BKT5w0x1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82 v7StiIFUJKP+OPY80jwO+yt+UI+40fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olS QvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7 mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yL HfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFpBHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/ t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78FtkNU75gaTX4E61wKzuM2tmCZZ/U uHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTGk+dNAYvyWaGheKR9x8jsrpcP 9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fBAkNsw2smbXDqadsT6e/2 E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/RCreyw6idLVj2SY27 R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFwamQEojxnRP5N zPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9mpPy9d3P 6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRiRVxI /k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+u OW8IKOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnS rUTWXMqXWtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUU egQn2iG9uptBm9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6 FDqO+qs6IE5Gx1NwUD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M 6AmCbeO7RgDYb4Hd5Nu6hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk9 7vNQvuSNAC+Gzo5ZKZ9OTQrynvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBf GylLFahJ+UH0Zh23+2uaLXF8XE11AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQN qCb83Eja0uWpe70K2XlKv5BfWXomxrf/PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOI xz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUv w+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGb xBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq716uQnaf0C/mVpWdifPvfcykJaBfZ TVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7YITnuLn92jTu+voCjO+8/14Ve 4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbEDLLqLxPU6LdOReHOsd/8h 5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/kPK9M0TOFZf4dgaV T7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRBELvCWhMqQRAE QWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q 8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88dwDXu b41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW 38x2fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4Dk Uh+3EeYmNiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tb PMbXnzDyl7pawky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz 9XdGymcJIeWbqAkp33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+ eiIWmT3b6hYgXerjNmb1Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7 Nz4XHBL0eFjcbqvjsa93qY/ir01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP 6o2fLGoR1b5nb5bdL7JfsL/QPPl6Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl 2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3vgm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidw xhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0tedYYCyOZ860qfavR8efv1MPrY6deeeT4fhj6di kdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1 xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmrqm2tcbHGEfVXtdE55O0nLD/dqWw9 TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmWu1+zwvRD+z5g2WfCdQSvCyE+ 5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplThr0U6PiVrUrFWQKbOIiL/ bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0ZvdbmpcXMB2MPVH+vR5 tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbakQfl8/ZoZNgW1 /AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8tUjHVbIm FWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3mxoX F7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDy hWFPP+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+ SH88jjn1pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb 9vSBZ07p6y6CHkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMF rWEA64FfzwTlg3GTRfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3C OMoGosroOhq4wmTK5+rX3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNY l/KZsWIyprFDWBiZb4nyTdFzJsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxh T/N6eTApN9O9HqV83n7NDQfl03VGVvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUb Uz4zVkzGNHYICyPzLVG+KXrORPlAR72Ub54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xp Xi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/ZKN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1 sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq/Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQ ZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3taErw5ucqeS1I+Z7/6mvN8LTib8iXs 47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6FpAReGEmQaWSjkZCWPUFAf1b +NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2KpT/SB1EyOI6gv1ChKZTP pWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj1/9mue6ME2Rv+6+u wHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/tq5eN+r8fTj1z 9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpLWR76wBzK z+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJZI1f R/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq 2NHWxxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNo N4LORLQuu+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p 9mZm2J3hb33R9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa 2NpX2YmpMD7q8ap45F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOr AVK+veCRz3duC3He4lrgZn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4j iHUgUt5WD6FV0h+vDYJ4LtZc5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUW vu+o0H3scW/feUT9erf+EhOwwesUYXzcz3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3 /hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+dtuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W 2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPHzmx467Q1N1UD2x0+dce5JfqLtnFcY3vH Nfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xSvgfwUpTvyW2S8s3fxktTvlVAyrcc ZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVsondpEOogG513UpQgVwfNinPRA0 /KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZrSlFc+IXdFzaKDsB0m3n tPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0YVjPtgBP/oD3LMryO gvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8IR9LTJ5iF+kg GpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO20jalZdmt rURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y4z56 XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK 4E7H1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6Zcp B/sPGHdgh8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f 9egZnpEL+xGVfV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17Zt xU9RyCVU0C8GtZUM7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k 9Hf1F/t50j6efplysP+Acb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6O UD6Z+Zj9Lp/tz+77qkfP8Ixc2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkY ZOgwRodKKCRyUj7TbhHt6YSi40B/3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19Q DuhvYtyBsnhcPJQP91deO+o6msUP8XU6rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1Fnz Dv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPyMMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtD WP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/ gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1n/JlPsY2q2V+DWAy5ZMhyDyUD9kN KjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJlE/VnuqH6Dqd2i9DtfJ0Pp9O t5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2g4qMxNL5lO8RO4eyH6d8 0A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu57E/dHuXzXu+kfE7o lCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6Xz855fRi6oBsc XeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8uP4SUb1q/ YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzdfkLH jaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8 c93f4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+ rqY6Ifr+gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTL RqbdFHNH0p39BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9 cfk5KGw3lXd5GnudL+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0d H1dTnRB9f8BS/1hVfd7WUKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+ 2ci0m2LuSLqzv8DPzfrufqF2kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yh Py4/B4XtpvIu67HX+RL+7L3enXr67AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnz vfD8p849trQrwR7wbnZ7t/4SxASQ8vmQmTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/e zW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Budnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd 3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKV8Gug928tuHxGxoygW//7o1 nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Giw1v7yRLYCeVrShgUzbaTHrc5 Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqKta7TGGtPrM9FW8GgaLad 9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go1rpOH8H+Kd+MbWwn tHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hpMuSQ8j1R/lPk PBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/HhFJyQKfdW L2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9VLsvu l7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fg hEy5t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5 rXJVdb+MxaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI 7eMZFy9GKJ/lJzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18 OgxCz6eDmUB1Ph3GKZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfp GYx1TtButgvlO+V8NmVh6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJd gZ/0vyaO5FzXqD7qL7x/rnedxnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9TH QeilPpoJVJf6OE753HraAHKQnuh4G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw 1jlBu9kulO+Uc22rwtInZTeXfKd/ijpqSBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/ 6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZRUx8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fy oUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgo X9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8fa3rNMZTZ8079IPeHMqn6vTxQkIO SAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIcx4Q+oBPYnp7xhXqqMY3H15Yd V8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGPyxRYlM93X/Jd16g+6m/K 39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+MI4JgXZIDe35XpTP v65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+cmRrEAEk5G6J8 U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM877nn3Ge3P 81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR45DF r6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wq p/S2ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKH YByTuW8jIXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo 2yfRwdua2Bzs5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISN Ph8SfU9AJaSZcvrD8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuX jfp/7tjI8NS2g09OJ0O5WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+O cUzYJzEuc1A+swPQT6D/e69rXB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBB CBt9PiT6noBKSDPl9Ifl5yugnCl6Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZ V69a9f80jHahHXxyOhnKxWLPKvK+FGLp6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87 xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P 9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRqgFRhH+A47g/eV8AI4kWxGuVz7GxGbBgc xx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5ykcQBEEQs2PtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h 7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3/c3UF7JnGmL/8D10Z6dY dhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N33h7PW+U7n8pFI9B4 J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9JL3W1aAQa7yT2 9P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRDIOWbV84W rebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAmljKXk ntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xO hWf4/RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9 ofsfbgeP9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMq BdXN8cLH3fZ3jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nw DL/fIsR2TtoHyrf9E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatw KuKC91+bRtOsiPIVOpbuTnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7o uNv+3nH5dPtJp4J+4QzY+ROPi09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzU fSY8beSo+cuI/BgvdH1tHs+fOmVmk3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp 7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQrq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fA zlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9uOW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1 I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aCPhgysB3C6zDc7VW+/dDFvfClINTCeLu+ fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om6mnbE/ktPA76pY/l5Vlb/YL+7JQz wW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx4GCCCiV+TIXy97+rdoI+GDKw HcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gkGr/GfqJtrENky87xOVP1 tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRFKF/msgxYDUu2YjWI DvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy5ZPUzk35XHoi e0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd6ENAnz4Y Tsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBacduu ndzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgX p56JZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586 VVAcJFyZ8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6 lZNDB8QIZfB4oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQ n5Hd0JosvM+EzYwcNX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2Iosuf LA6nk/ndCbc+BrraZSPkWblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ 0MKhLA994AztbI2LW09oz6aUfqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyM XNfjuFu+vl4DS0yeKj+oFrRGZyypd2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5a Ic/KVVNMwXzfJsukoZZWu95+2fXHdSmOVXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6 Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328RsJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaC eEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKyXrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQx YAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5IOUjJoCUjyDk9marL/F1moTfIrGP Q6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1zIbd9COJ6vZLyEQRBEDvD2hMr QRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH7bA+xI7aa5trY+g+ XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jpxgeQWAU7oXyJ zce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9sT4Xic3H trDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8Mc6n g281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b 5bLsflGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl 01jjgvRP43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusO uwlZ+T6y1/vY+2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5V rqruFxV7DfWrKidyNOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1 rTUuSP80bmflyAF2MP0qZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6w m5CV7yN7vY8RMeakfE2pgzsVLfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anW ORoVSJpVIFB9qaVIxMP2gcdt/T+B3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYH J9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4SpzBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97 Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+ 1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJhzgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTL iwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a9d12645kUr7d3scICzNSvjBc6ZdF wmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7YLsh/cM/cJ/v4i37hxLGY0ak vzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZcRUbiXG3OpfyW9s/7fp+ u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VRFF2RDec8NQf1MeWz 7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj2yIT/BNoY/+i 5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583Z6jk/YqC rA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7x/On zkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU 0u/s6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQW krfEh/TMXR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12 s5pP9muf97Fe7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUz KB+sP/ygcsQS9gHHgf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA 8OaXRfXH/RNqA35JXUh4MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xd d0p84CD4YfRrFEVRHMpSB+7Db8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7A Psj+QV7qKf063/3tuEHPqKp69WoMsZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5 /6EsdaKsgwwA/0z4oX1/wHaD9R12S48X6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIri WFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqLb5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fj Bj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jOEHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD +/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6QfXZit+wlPmIFPJD4txP/zMa79fel seKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/Kx63Gtgzvq6kS+/DPfLxbf18a K86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN5aO9aB/2Crmt3eQlvvca 23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQqH0EQBEEshrUnVoIg CILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8g CILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC 2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDl IwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8ST cD4dbk7ZlEVRHE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9 H9SfIJ6ES328OWVbFUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrS qmwfnRdIT5/+CIkenE8HhnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte 4s63Lywwd3YRixn4XOqjIxBqK6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTU dq0+b9X/L3WVo9Y894fr1WbDS9z53hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfD oktEE9udjx4tgEzKN9+yJSnfHFhuCrUf4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ 7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZsyrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0 y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3le85g0yskpaTG8XA6h3Y17eAdF6Bnl+VY Wv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717IczfSMrnu2/Y/iYS1O+/B5YL7p8J /yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH7YpTqupmj0S/zIQu2dGw087+ iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4AD27LMfK8k+AHPlZdutX yNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw/0z4JzEHXmyVT1IB QUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH1V10HKApdWSs WJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S3Kz6hJCM VL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T1iy1 unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQX o3xWqCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5 gL/NQ/mIFJabQpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBM vPKUjGzT6xFH11Wb1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1P pF4VDHf/xCPVrkn5gL/NQ/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGv cyQon8m5kvoYnUB2sNrW5y1O+ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK 51sGSdf3UD675pyU735QxYX+/hZmhOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTp XzWZi/LNm0r46Crfkz/2maB8vvsG9jdSvi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2v VMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOoDL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCA Pl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgEY899A/vb8Iu184xN+bB/EhaWm0LnoXzq /TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/pVzVKNITHUftKsXFyeh4jqIy9Jb5 vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgdb+T6Ndf9VKLvqHrqNiMTjD33 Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9+sN2ZRKY6m7cr9F3coxI 09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx9JQ+Gfrn2LBoSX67 JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmbmmUHwz+JFBaY O/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0BfpCY7b7eqM NxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhlk8Il 9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+ z3oSuwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhY WFhcZXVuw2IW7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GW aIGU7+nl8uNLURRV/b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp 0mVBPduPpzrq6tyG5b//qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+ u3iltV/F3s9rm/Qlys3+S4z4qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTg p1/1l6eF5vXHLe6//PiyKF+C7f6qvzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3 q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodKW31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71 EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5O SfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198iy2TFgY3X5agQKR8fj29hZTvtQop3zLl iSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjcfFmCApHy+fX0FlK+vZYlWliF8tXD RqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJETp04iH6KQ/NYzy5b8qNTKSeG /vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4CfADm2PpP8QZji46P68uOi Egjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61zrxfndX3PKvxW/XGv rzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt+kP8hI6jgvQx +ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0oimN9uv1n OOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/EuKBi jlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b 11Zfi6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QG llJXIvZtP1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkr xiof1BONC7QDHC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jn NL8FLmGv8hWu68VzXXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef 1VBH6PbvfxwHfdDxBN+z2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7 VYXU/etq139fr9/b9nbwe3sZ2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGB doDjhTQ3/SQlB+jj8odL/dtgWz0WQ1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpX uK4Xz3UtfKLPmW6/tzePFFeCNOil/S7Irnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDI qT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvVFAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5d fnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZPKkp2fVYkpnxYTzQuCTuA8UKaW36SlAP0 8fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjEWGJnzvVi98sud34iKVBHVP7oD96Z UjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF/bXtM0L5/tDrnOP23Drl+17p 2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHleNtN2wcXFaDnjFoYOWE9 0bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6GeE/0WuMRYYmfO9WL3 yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb4bqSbxh3/x8f fcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdD lG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8ZGyTf IjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevow LkVOTMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4 g/6G568fx67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6d YAmZkknV2j8KldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KA YcZvK/VmSh/GpciJSfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/ TD9JyoGUz+EPOpo91cc+Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQ cdjuPJTPeHE28oP2q722aCVGRqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5 VX34VVdffohfgvB6wPCOkFrW7eWIb2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3G Ws9eY8GfbzHHEY5LhvxovKyC/ATISerj8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7v tL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87resjG/Naq/3c0podJwwIq1avyx7ejPGX4bImW A47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo/Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A 0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V/71GSMnxtmvaZ6z17DUW/PkWcxzh uGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVRVN/61+Sc/u+0v9dvsZ4Jv73U v/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVVj77O9706fhOBl/39oqFd U09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4rEP5cCi/3AYGb138 +/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz1rVyWbHtfe6X AsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ55avXWZZo YSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhYWFhe pazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVg YWFheZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv /ShytvOep/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+ LXK27Z6nnMQ+2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/H SVTw8vdv45Tv57fq5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnw uphdzrPL3Hpuxg/bD7tf6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyPar l1rYcjLtWo2H2g/In6tk6TlD6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdG y3qU78GyGOWbWkj55pU/V1mO8n3cIvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76 d1K+efWcofR+0Y3CsFO8f1xYsstm/JCUb137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+K ojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H//jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrj fljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yoHegpjs+fDThC+VLj8sh1MaOcX/WXm5Db f4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrPuCjDbz2UL243sNX9z7RWWJ/OkkVR fHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3WwswyXhpWUr22XY9lWRZc5eZfT x9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLar1XbtyBiLHHKUDkhB5ZB /aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJul8uxPkXXDbLb4OlV 2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+rarj/gePwukD+ 4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t80fGf3wRd /GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsYUb9D 5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+ 4/erJeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2 PCpykxVuGIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE 7ddOH6incoT2a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYL xAnOJjVytIv9EBfTD4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0f LZuifGKVIFi9iUu8UCYpX///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739U f//Pw4mdMtTWD9plqOSgfP0q1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZA jutiZjmh9RJ20/a//PhyfIjy5bab8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue 6HjiukD+4/arJeyfVxajfFFcI5ba7rjFIDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cRO GWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTdhFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu 2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5JtdSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9 Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUoX/0hwrJf9RcZKs1B+bzyU/Whb8xC +Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/qjx+XXz/q+lf98eMSVsvWx0/5 Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v/FR91PQ8lG+ZTzvOQPl0 3yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq2fr4KV/m8i8Yjhy/ WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2ehQxc0Nb2/EzgW Qqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TPdV3MLMeg XtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrUR38T 9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4G u611zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtB u5dvdf2tqk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH8 49uxkJTpH4Ms8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK7 27EVv1b1/9Q3G758VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtV itxdHzgu81wXz5MjBgXYLbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z 6RMOvewXOG7bGfmP06+ebX9feT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plw u2PhGP58i8odFe8lGvqMGHA4SbHdsOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/ gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI36VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2 c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0yccev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8Zco qxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4urLLUZBgvLUwop34uU1Q3OwuIppHwsL1BI +dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQcbfMB3JYWKaWLVO+IQ9pv5scr90+ C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30WFhaW9ymkfC9SVjc4CwsLy84K Kd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2hbUnVoIgCILYFkj5CIIg iF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnPp8MrqUu8JF7vung9 rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF62H79/k1V/ma EoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix6+L1sIqB 155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqTRvBi 18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlD s3r9AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvO WA5WsXefRtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjf m9VuF1F/8ZVNn1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/ Vd0nepHoeF8v6KLctjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV 1fZNi5g+IaeqjPojuuZ0SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68f Yj/XwroGkHwsx+//c6Ebi7sLDZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ 7Onyw6T/GP6J9fTYH9oN62/dGpPds+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+z YhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9Upk vOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA 7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7Qf21T46uVKP7/FP9donJUwRPl/ooI9Ih ernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9VolU/GouFZNvXC9Q1N21YEfbnrREa7 WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQndwPgqsZCD2nX6+QRcTMLUVpqg xY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/4503UH7Qb11z45ulKN7vPP 99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDIbsqRdeL6MfQC0QOU D8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+tu1Itf9xH9G/K 4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67yOwpVy5A UKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmWscQX S8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9e F3O/QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9 /VWp0d5GlVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX67 9EQq12wg5QtjrYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9 LftPtU9/Qt4q34Yo39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2 G7k/dJVci+iywa284jcn5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvji t0tsymfp+WzKp1/mmU75EnJsO9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5q N+nnzf01LfR7FuxR1A6l6zjGHesvkkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylf Uv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19Vt hS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x 5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+ pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W9x8+zbeHwu9dqDQm+dMgCR1P9CDm GfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/haR1mCxLPeEgk5GZqWp552p/pr vWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb15H6ZIgaX1G7e3WsZ2dN Ke8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9PzuwwNypM3WC7Kwbhs9+ 3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1VH0J+VaGqRkNQ qD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4fy/qkdBa CQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6S9lt RH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CL bCk5DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASx K6w9sRIEQRDEtkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ 7UJswg2+KrilXQXFTtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb 2lVQ7LS9uE7vYYdxf7Dqv/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6 mPzBYjouP5nPbquSrnexw5g/gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptW vYqeTrTVLVy91EeTP1hMx+Un89ltVdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTl LbI/nw7WSsXjyYzz2W3NxMq3scOIPzxPo+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZ cT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsECyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQO E7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10EBvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ /s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv4bhlGMC/kR2S/oAQMx6c8GnYOXkf gE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+UFsQuvUOwIBI177+rPwbIU6q2 T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9z6suAoP9Rfqb45LSE9lh XMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1Nf0iMl3DcKgzg38gO SX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QUe2ZhXsrXNILo SSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn00GHv1H4 rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i9a03 ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9Mfj AvUEcqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa 5ErdT0I7u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/ KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T 6hh6DiqF5yfsBgfTpDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/Y jJTPvA/g++TGKJ96EPsI5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hc kJ5IDlYGyYf1ZTjbjy9o96akeB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4reww CfmUD9vZQ1GS16/D/vdqppEG3TMenISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXoby oRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9Ot5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8 OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKBLVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH 2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MU CxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXLQTkroFBBTeYHIMx+pfS3EEXpKgSO zwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmU D9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XPPVHGkBFC972E8JdwBwad zlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwuUE/X+khKvg0QwsJ2 L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l7Ya fx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y6/+QcsSx IP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaHJdmH lnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgW pH8lvm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1o Kcc+GfhJSk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJf URTHuja/N+W5n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB 7fDeePDzR7sDKR9BEMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAI glgJKt9z3g/dvDZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdae WAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu8 7c7XwDlrP3fiUeTZufuYIQeEIPaBZ0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFu mHOVrylXi5ntzaZm3YLqfDrM2r2sHZFfZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18Qm sMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URrw3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFi IOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5g XvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzOYaIfSvwT3dItoP4Ox8tmjIok+gX0 zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz3IdhTJjgcGp6aZFBwfDm+sOt UlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXdIWT83B/MS54TuwYP1UWi 5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLoF9A/T1hVddQG9hfp b45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ulqgqvr6T+Y5YI O2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a5Rv0EUo0 pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hPHJcQ 0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQi zf7KDLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXN YBiBYMlYhEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq +oH9I5TPqh/WVcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9 wgFJ1Z+jv6hdJP9TD8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvD cOoefwVrYcX4R1X0A/tHKJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenp G/ep4zLSo97OY/qEA5KqP0d/UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+ cnzz/ZPYGJ75Ll9P+XyJTipSVRHdFilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8 ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRF DHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOi yekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+P e16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgOYbMKp+w1MHHSEjuFflnyS/DogKXR iVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmdLBUxriYcR4892KGXNB8VNPtU 7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y87TNmxDcETeO+27cWfOF fDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHrekEdI7FTLZ+mv1q5e Px/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE94rwzKqUZ8/m ok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+Hk5Y+SC/Y 6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+GqGK7 kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86 vpb8GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6c u3wAgHoo+NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYA rkTphRUAcB7eLzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+s AAAAQF0g5AMAAHApSi+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/z Z9On77XHrvmru1fzBWPy/eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso8 8Pf82fTpe+2xa/5+Pqr5gjH5/vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJM yPfq7sy/6ZvR4Xl1d9EPljz2sA6TvsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a3 5hqXMzjpvsqra07tdiH7r2V8T11F388H82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2 eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51 f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5ENV7O5upuLhnwurjCOnDMX0cjtHdrRE30/ H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc 6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yIO7aUblbXUW6XnaDFLf0cH/NF Lq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1Ln79p/Q25YaBXr8yLmr9 ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU5cjQxpsQ8b6ImHA1 Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yRy2vu/kUY+h/a dhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5hCfmm0mNJ 9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKBM7w8 /vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6X bj/a/N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9i njz7Y7pSbZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU +lV55PrpzRr+LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it 8QlSRk2zEl12diN8denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz2 6V/CK49cvy6PWH9YQxC43RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6 UFd1w20it8YnSBk1zUp02dmN8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob 1t/1mrRx2ad/Ca88cv26PGL9YQ1B4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f 5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9Wvy KPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvbD4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwl B8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNu P9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITgCSO73fDDFUlK0sqN9/5zeE95Qj5B /0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1M03FiZF9Q57v2+iAogeSACDk AkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM7HbDD1ckKUkrN977z+E9 5Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80FSdGDi15vm+jA4oe SAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3bLAT9O0MTXOn l9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLelP7uGBef /jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1PYPRA lsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7 ZdqPNI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6 qw0/xDEh33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MU pRdWAAD4eVj+I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEF AAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0Epezit XfIFa9acdhx8O+xL6AnHJfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zB mjWnHQffDvsSesJxiaHN9wLPsd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNf R9tDbe3qH4jP8+F4owev7n69ewsV9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT /thUvk9QlfqY1QftJn1xOVe/avvY19H2UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5 vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd49ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGO dvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pvZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6 U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+TkTR5jHZV1nqanoR8opz+fvEGmsln MuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe4AQ7YXXQjoaddo9vbD9T7l6/ SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLowak3TR6pXVNKNsDkCufv lcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4DnMykiaP0a7KWk87 kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9oll8wDnGAnrA7a 0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RBTxQ9OPWm ySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto5hd/ lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiG tTEBbXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PF eoaWhT1CWBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2S vbnnhdANS06n/YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJ jdjt4iDki9IqeR3Us9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXT HX+tHisT2BfykfLkQn9/FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz 90GeF77fK5kMa2MC2wl1qxtKbhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDg iOsJjzEBRf34x0Ujjz3Q0CXt2Z8j7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNi PvcIJppm5077GSsiz6XxC44M+dz6dCHrwau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9N nhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uvXd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55 sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ffCvn8iTlySHOTqp//3gj50uTJEfJZcrr7 RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl+furhnxizGXWL99icM2L9dxBId/7 2T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdOkFQ/dRpIo3NzsYugXWDII/dL hjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiWdyV2yvXwIWVpnpYdyi2/ uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedlauzuPCwX5g6e3BH26 UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI/ZJhTiXJjbLk dPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/nY3ncM0X+ TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev3rLJ EzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO 4KF7+yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZD HmteeH+vBPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zc RkVOb7+CzKrwlvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQj eOje/or28ze0j+cz4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68essh jzUvvL9XH3H8p9grJ23XCPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/5 9ZDvdcUPWB9G1pQu8OUg5APVUnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOg EkovrFVBcoQQwgDgR/xyGgBfx2+GfAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAA AC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQ A7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI94ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC 4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5JpWz9ZWzqogRr19tt2tfIbevDOo/kFwAiG v5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yln5y8uuYjD1cZlyr19ut2ZTV+RT3s mkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p68t72SQt4xxv6Scn72f7kYer jEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F50lk+l6hIAtyGfrLyacin UKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYokwG3oJyufhnwKNert 5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdNfPM9vu8vJlxN WVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32NORzjqOS CKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/BHL5y ks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf0 4JlHRHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0 +S05l8d+/v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69 EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9 n92AVjO9ZFdMkOdPkd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJp cy9RVGH6OMq7Ip69EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye 2Lm6EeQW9cQnPpfu2osuKXWPNtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDv OGYI+UR9WuPrB3alt6ud+Xo97CI95NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lc op74xOfSXXvRJaXu0YZbY8qppjeKLim70b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+o T2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9TMVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4 pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5 +nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqu pId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+TzXCqhUlMmoXjoEgnyW3K6XFKW Lsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6symRF+uh50kh3zG/JV/P9UG lQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ8ltyulxSli7J9laC J5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyVfz/VBpUCTv2P xbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+Vc6Ut0iw E/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2kHpxo 9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3 KyL6tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1 Aj38Ngd9jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/ hHwAAAA4LE/zlMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIK AAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+L fL/7G+sHAABQO6UX1pE3+X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+ 2ff9fMQx2gcfg7r6l4MBAABkonzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYn Idn8tV9Wln0CODjrrB8AAMDvccrqObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xse nU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM +cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06yBbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbG kG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNeuvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3 y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWPe4O7XwYDAADgsuR9fQt/9co9fE3L 7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1Lbfb7dY+58ftove00MBsPUkD OFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78 nUyiDns+ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnw dzKJOuy5DnKGfLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnD DrOMy7fMU4367Nb3O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf3 81G//H9/m3p+P9s6uiHJucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQ b6S+kfHzYyFfJlm+Y55q1CfpabMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6Wmz HSHfxBkhn7n7FxGWJvlHfdP0S9oTrYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywf XtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbqQU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOt pum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV 7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F5EJtOUxDe7vdHs9haWW9YGz58XzHCXRr A8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9EVHVZ9tK4ysw1T2Xmv5kveb1k4TD 4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz 5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0fT+VYMEZa01oTCv/6u5r U6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+VuunUsYJdGGLNLMv +dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVVe/bqRyuv2bPz d3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7+Vibej8f 8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3Jzz7J 9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7X We8vDW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxq v8TCqj179aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0i q/7xfOotfKUepb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz 6F9tN888NbdVXXquy27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+ sb9mvbLLpUYiRUK+V9d0r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv2 6ietXf72mzwhn8d+ciyOaZwf8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/k S9werGGX79CQzzdP/SGfXH9tdpsr5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2E pKag8puadCT5mVx0VkKUUyvPvaA1bc2oPz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7r mnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNrkId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXn uyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn5GPPbwjOPPE1vDk+NO8sqFX0M7norIQo p1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2vN+R4P5/PZzvu8LEnfpT61xPSlwSE xE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1XZ7fmfPeEfHq/JDR79upHLa/a s/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IXARhispwiJn4sp1mentiq P3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8PhtmTOYINN3W43yG /cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wjltft2fU76R5f kfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUfvfdgW3Fy u0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJM9VE M0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUi fi0E+rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABA XSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClK L6wAAABAXVQS8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0e ll5Ybd5b37mur92hTfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/ V9cU8T2T2u0byZmRj34ppfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/ h8fN1NIL6ybvZ1vE90xqd2glZ0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTn qkev/sCBzfV7WMMvKEI+hHwjCPk+p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O 0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuSTmLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7 UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hye/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7 oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VUu6WoQeyXftxtP+l2NeWo9kvDtHT6fBln 42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23GTh85Zyyxdo5nYit5coHwdfD7UBD DpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjbPjb0M17+eL5nkdPalvSwOV5B 3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeeyfjT5VTnVbilqEPulH3fb T7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u7Pg9dNvtqWTd5aOb Bj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0sj2n9+/fvX99b LRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvtav3Sjrvt x2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ5002Bg jh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd 8afJ1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmf tpPC3bXFRyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02ra YSfiORtNn5qdkCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Q b5/8YT26/cvzxUYKTPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu /PJ/tV2L7UQm2l+v/FrIxzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQ CCf1dhPkT6rH3wOpXa1f2vEd9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGnd nt9Dr92eTZUhny/FR92wKRbyeVOU1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/k k9u15JdDvjzya+36Q75P7CfBrpQYyjtfdoR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJ DfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xorqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ 3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvocfP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43p jbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru4eNin+RCBlUHqZxUvHi8lHYt+UX9 ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb88od86b+HbrvNwhmLp+KacO9j cS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7XDdD/+J4qe1qcia1vG0n wSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7TjXvvx2hXNK/xjO7eu +eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7GM4G2XD36doCm mZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63dBmPi2wn 9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7RwfswtLC9b 7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNx ke2EXhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3ML y8tWuy2/Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAu CkI+AMAVQMgHFkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --------------D55810C738922F667EAD62FC-- --------------35CF9CC8F241C0B429963D68-- From nobody Wed Nov 8 09:00:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3701212922E for ; Wed, 8 Nov 2017 09:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCpSHIoMRHwz for ; Wed, 8 Nov 2017 09:00:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF26A128DF2 for ; Wed, 8 Nov 2017 09:00:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK54006; Wed, 08 Nov 2017 17:00:13 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 17:00:12 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 09:00:03 -0800 From: Igor Bryskin To: Qin Wu , Alexander Clemm , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNYozCctBUDrHqNQFassZLcA0NQKAADd8mA Date: Wed, 8 Nov 2017 17:00:02 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@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.155.246] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5A03381E.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a19e6a6149ac33c98f289bbe0730ca1 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:00:23 -0000 SGkgUWluLA0KDQpQbGVhc2UsIHNlZSBpbi1saW5lLg0KDQpJZ29yDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBRaW4gV3UgDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4 LCAyMDE3IDEwOjIxIEFNDQpUbzogSWdvciBCcnlza2luOyBBbGV4YW5kZXIgQ2xlbW07IFRpYW5y YW4gWmhvdTsgWHVmZW5nIExpdTsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFlBTkcg UFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbiBQcm9ibGVt IFN0YXRlbWVudA0KDQpJbnRlcmVzdGluZyBkaXNjdXNzaW9uLCBkb2VzIHNtYXJ0IGZpbHRlciBt ZWFuIHRoYXQgbmV0Y29uZiBzZXJ2ZXIgc2hvdWxkIGJlIHN0YXRlZnVsIHNpbmNlIGl0IGtlZXAg YSBmZXcgc3RhdGUgd2hpbGUgdHJhZGl0aW9uYWwgeWFuZyBwdXNoIGRvZXNuJ3QgcmVxdWlyZSBu ZXRjb25mIHNldmVyIHRvIGJlIHN0YXRlZnVsLCBpLmUuLCBzaG91bGQgYmUgc3RhdGVsZXNzPw0K DQpJQj4+IFllcy4gRm9yIGV4YW1wbGUsIGFuIFJQQyAob25lIG9mIHBvc3NpYmxlIGdlbmVyYWxp emVkIGFjdGlvbnMpIG91dHB1dCBjb3VsZCBiZSBzdG9yZWQgdG8gYmUgdXNlZCBpbiBzdWJzZXF1 ZW50IEVDQXMgKGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24pLiBUaGUgbW9kZWxzIHdlIGhhdmUgaW4g bWluZCB3aWxsIGFsbG93IGZvciBtYW5hZ2luZyBhbmQgYWNjZXNzaW5nIHN1Y2ggc3RhdGUuDQoN Cg0KSSB0aGluayBzZXQgdGhyZXNob2xkIGZvciBwYWNrZXQgbG9zcyBvciBsYXRlbmN5IGlzIHBy ZXR0eSBtdWNoIGNvbW1vbiBpbiBuZXR3b3JrIHRyb3VibGUgc2hvb3RpbmcsIHN1Y2ggdGhyZXNo b2xkIGNhbiBiZSBhbHNvIG1vdmVkIGRvd24gb3ZlciB0aW1lLg0KV2hhdCBraW5kIG9mIHRocmVz aG9sZCBjYW4gYmUgc2V0IG1vcmUgZGVwZW5kcyBvbiBlbXBpcmljYWwgZXhwZXJpZW5jZS4gSSBh bSB3b25kZXJpbmcgaG93IHRoaXMgY2FuIGJlIG1vZGVsZWQgdXNpbmcgWFBBVEggc3RhdGVtZW50 IG9yIHNvbWUgb3RoZXIgbWVjaGFuaXNtLg0KDQpJQj4+IEkgbGV0IEFsZXggYW5zd2VyIHRoaXMs IGJ1dCBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBzbWFydC1maWx0ZXJzIG1vZGVsIHdpbGwgYWxs b3cgZm9yIGNvbXBhcmluZyBhIGRhdGEgc3RhdGUgcG9pbnRlZCBieSBYUGF0aCB3aXRoIGNvbmZp Z3VyZWQgdGhyZXNob2xkIHZhbHVlIHRvIGV2YWx1YXRlIHRyaWdnZXIgY29uZGl0aW9uIChhbmQg bXVjaCBtb3JlKQ0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTmV0Y29uZiBb bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBJZ29yIEJyeXNraW4NCreiy83K sbzkOiAyMDE3xOoxMdTCM8jVIDM6NDINCsrVvP7IyzogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5k ZXIuY2xlbW1AaHVhd2VpLmNvbT47IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNv bT47IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0K 1vfM4jogUmU6IFtOZXRjb25mXSBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBD b250cm9sIEF1dG9tYXRpb24gUHJvYmxlbSBTdGF0ZW1lbnQNCg0KSGkgQWxleCwNCg0KVGhhbmtz IGZvciB5b3VyIHRob3VnaHRmdWwgY29tbWVudHMuIFBsZWFzZSwgc2VlIGluLWxpbmUuDQoNCkln b3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFsZXhhbmRlciBDbGVtbQ0K U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDAyLCAyMDE3IDI6MDAgUE0NClRvOiBJZ29yIEJyeXNr aW47IFRpYW5yYW4gWmhvdTsgWHVmZW5nIExpdTsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlv biBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSwNCg0KQ2xlYXJseSB0aGVyZSBpcyBhIGNhc2UgdG8g YmUgbWFkZSBmb3IgdGhlIGFiaWxpdHkgb2Ygc2ltcGxlIGF1dG9tYXRpb24gLyBjbG9zZWQgY29u dHJvbCBsb29wcyBvbiB0aGUgc2VydmVyLiAgDQoNCkp1c3QgYSBmZXcgY29tbWVudHMgcmVnYXJk aW5nIHRoZSByb2xlIG9mIFlBTkcgUHVzaCBzbWFydCBmaWx0ZXJzIGluIHRoaXMsIGFuZCB3aGVy ZSBJIHZpZXcgdGhlIGJvdW5kYXJ5IGJldHdlZW4gdGhlbToNCg0KLSBBIHNtYXJ0IGZpbHRlciBh bGxvd3MgdG8gc2VuZCB1cGRhdGVzIG9ubHkgd2hlbiBjZXJ0YWluIGZpbHRlciBjb25kaXRpb25z IHJlZ2FyZGluZyBpdHMgdmFsdWVzIGFyZSBtZXQsIHBvc3NpYmx5IGludm9sdmluZyBzdGF0ZS4g IEV4YW1wbGU6IEEgdGhyZXNob2xkIGhhcyBiZWVuIGNyb3NzZWQsIGEgaGlnaC13YXRlciBtYXJr IGhhcyBiZWVuIGJyZWFjaGVkLiAgVGhlc2UgdXBkYXRlcyBjbGVhcmx5IGNvbnN0aXR1dGUgImV2 ZW50cyIgdGhhdCBjYW4gZmVlZCBpbnRvIGFuIGV2ZW50L2NvbmRpdGlvbi9hY3Rpb24gcnVsZS4g DQoNCklCPj4gRXhhY3RseS4gRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBsb2dpYzoNCg0KaWYo bGluaydzIGJhbmR3aWR0aCB1dGlsaXphdGlvbiA+IDgwJSB0aHJlc2hvbGQpIC8qIHNtYXJ0IGZp bHRlciAqLw0KICAgY29uZmlndXJlIHBhcmFsbGVsIGxpbmsgLyogZ2VuZXJhbGl6ZWQgYWN0aW9u ICovDQoNCklmIHRoZSBjbGllbnQga25vd3MgdGhhdCB0aGlzIGlzIHdoYXQgbmVlZHMgdG8gYmUg ZG9uZSBpbiBzdWNoIGFuIGV2ZW50LCB3aHkgbm90IHRvIHNheSB0aGF0IGFoZWFkIG9mIHRpbWUg aW5zdGVhZCBvZiBwcm9jZXNzaW5nIHRoZSBsaW5rJ3MgdGVsZW1ldHJ5IGFuZCBhc2tpbmcgZm9y IHRoZSBhY3Rpb24gcmVhY3RpdmVseT8gICANCiANCi0gVGhhdCBzYWlkLCB0aGUgZm9jdXMgb24g c21hcnQgZmlsdGVycyBpcyB0byBiZSBzbWFydC15ZXQtc2ltcGxlLCBhcHBseWluZyA5MC8xMCBy dWxlLiAgSXQgaXMgbm90IHRoZSBpbnRlbnRpb24gdG8gbWFrZSB0aGlzIGFzc3VtZSB0aGUgcm9s ZSBvZiBhIGdlbmVyYWwgIkV2ZW50ICsgRXhwcmVzc2lvbiBNSUIiLiAgIEZvciBleGFtcGxlcywg ZXZlbnRzIHRoYXQgd291bGQgcmVxdWlyZSBjcm9zcy1jb3JyZWxhdGlvbiBjb21wYXJpbmcgdmFs dWVzIGFjcm9zcyBkYXRhIGl0ZW1zLCBwcm9jZXNzaW5nIGVudGlyZSBsaXN0cywgY29tcHV0aW5n IGFnZ3JlZ2F0ZXMgb3ZlciB0aW1lLCBldGMsIHdvdWxkIGJlIG91dHNpZGUgdGhlIHNjb3BlLiAg DQpJQj4+IEZhaXIgZW5vdWdoLiBCdXQgc2VuZGluZyBub3RpZmljYXRpb24gYW5kIHJlbHlpbmcg b24gYSBoaWdoZXIgKGNsaWVudCdzKSBpbnRlbGxpZ2VuY2UgaXMgb25lIG9mIHRoZSBhY3Rpb25z LCBidXQgaXQgaXMgbm90IHRoZSBvbmx5IG9uZS4gSG93IHRoZSBjbGllbnQncyBhbmQgbmV0d29y aydzIGludGVsbGlnZW5jZXMgYXJlIHNwbGl0IGNvdWxkIGJlIG9wdGltaXplZCBhbmQgYmVzdCBj b21wcm9taXNlcyBmb3VuZCAgIA0KIA0KLSBUaGUgYXNzZXNzbWVudCBvZiBhbnkgY29uZGl0aW9u cyB3b3VsZCBiZSBsZWZ0IGZvciB0aGUgYXV0b21hdGlvbiBmcmFtZXdvcmsuICBJbiBvdGhlciB3 b3JkcywgYSBzbWFydCBmaWx0ZXIgd2lsbCBqdXN0IGFzc2VzcyB0aGUgdXBkYXRlIGl0c2VsZiBh Z2FpbnN0IGEgc21hcnQgZmlsdGVyLiAgSXQgd2lsbCBub3QgbWFrZSBhZGRpdGlvbmFsIGNoZWNr cyB3aXRoIHJlZ2FyZHMgdG8gb3RoZXIgZGF0YSBvciB0YWtlIG90aGVyIGFjdGlvbnMgYXMgYSBy ZXN1bHQgb2YgdGhlIGZpbHRlciBiZWZvcmUgc2VuZGluZyBhbiBldmVudC4gIFRoYXQgd291bGQg YmUgcHJlY2lzZWx5IGxlZnQgZm9yIHRoZSBhdXRvbWF0aW9uIHN0YWdlcy4gIFRoZXJlIGlzIGEg cmVhc29uIHRoYXQgaXQncyAiZXZlbnQtY29uZGl0aW9uLWFjdGlvbiIsIG5vdCBzaW1wbHkgInRy aWdnZXItYWN0aW9uIi4gDQoNCklCPj4gYWdyZWUgICAgDQoNCi0tLSBBbGV4DQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWdvciANCj4gQnJ5c2tpbg0KPiBTZW50OiBU aHVyc2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgOTo1NCBBTQ0KPiBUbzogVGlhbnJhbiBaaG91IDx6 aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgWHVmZW5nIExpdSANCj4gPFh1ZmVuZ19MaXVAamFiaWwu Y29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFlBTkcgUFVT SCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgDQo+IEF1dG9tYXRpb24gUHJvYmxl bSBTdGF0ZW1lbnQNCj4gDQo+IEhpIFRpYW5yYW4sDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29t bWVudHMuDQo+IA0KPiBQbGVhc2UsIG5vdGUgdGhhdCB3ZSBzZWUgc21hcnQgZmlsdGVycyBhcyBh IHNpZ25pZmljYW50IHN0ZXAgZnJvbSANCj4gY3VycmVudCBwdXNoIG1hY2hpbmVyeSBpbiBldm9s dXRpb24gb2YgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24sIA0KPiBiZWNhdXNlIGl0IGVtcG93 ZXJzIHRoZSBjbGllbnQgdG8gaW5zdHJ1Y3QgdGhlIG5ldHdvcmsgdG8gaWRlbnRpZnkgYW5kIA0K PiBmb2N1cyBvbiAib3V0bGllcnMiLCByYXRoZXIgdGhhbiBvbiByb3V0aW5lIGNoYW5nZXMgaW4g dGhlIG5ldHdvcmsgDQo+IFN0YXRlLiBJIGFncmVlLCB0aGlzIHdpbGwgaW1wb3NlIG1vcmUgY29t cGxleGl0eSBvbiB0aGUgbmV0d29yaywgYnV0IA0KPiB0aGUgYmVuZWZpdHMgYXJlIG9idmlvdXMu IEZvciBleGFtcGxlLCBpbnN0ZWFkIG9mIHJlY2VpdmluZyB0b25zIG9mIA0KPiBsYXJnZWx5IHVz ZWxlc3MgaW5mb3JtYXRpb24sIDk5JSBvZiB3aGljaCB0byBiZSBkaXNjYXJkZWQgYWZ0ZXIgdGhl IA0KPiBwcm9jZXNzaW5nLCB0aGUgY2xpZW50IHdpbGwgYmUgYWJsZSB0byByZWNlaXZlIG9ubHkg ImludGVyZXN0aW5nIiANCj4gaW5mb3JtYXRpb24gV1JUIGFjdGlvbmFibGUgZXZlbnRzLiBUaGUg bmV0d29yayBjb250cm9sIGF1dG9tYXRpb24gZnJhbWV3b3JrIGludGVuZHMgdG8gbWFrZSBvbmUg c3RlcCBmdXJ0aGVyIGluIHRoaXMgZXZvbHV0aW9uLg0KPiBXZSBhcmUgYmFzaWNhbGx5IGFza2lu ZyAiV2h5IHNlbmRpbmcgbm90aWZpY2F0aW9ucyBpcyB0aGUgb25seSBhY3Rpb24gDQo+IHRoYXQg Y291bGQgYmUgdHJpZ2dlcmVkIGJ5IG1vZGVsIGRlZmluZWQgZXZlbnRzIGFuZC9vciBwdXNoIA0K PiBzdWJzY3JpcHRpb25zIGFuZC9vciBzbWFydCBmaWx0ZXJzIj8gV2h5LCBmb3IgZXhhbXBsZSwg cHJlLWRlZmluZWQgDQo+IG5ldHdvcmsgcmUtIGNvbmZpZ3VyYXRpb25zIGNvdWxkIG5vdCBiZSB0 cmlnZ2VyZWQgYnkgc21hcnQgZmlsdGVycz8gDQo+IFdoeSBpdCBpcyBub3QgcG9zc2libGUgZm9y IHRoZSBjbGllbnQgdG8gcHJlLWNvbmZpZ3VyZSBkICBlc2lyZWQgYSAgY3Rpb25zIGFoZWFkIG9m IHRpbWU/Ig0KPiANCj4gVGhpbmsgYWJvdXQgYSBiYXR0bGVzaGlwIHRoYXQganVzdCBoYXMgYmVl biB0b3JwZWRvZWQuIFRoZSBjcmV3IA0KPiBtZW1iZXJzIGFyZSBub3QgZXhwZWN0ZWQgdG8ganVz dCBpZGVudGlmeSBob2xlcy9sZWFrcyBpbiB0aGUgc2hpcCdzIA0KPiBib3R0b20sIHJlcG9ydCB0 aGUgInRlbGVtZXRyeSIgdG8gdGhlIGNhcHRhaW4gYW5kIHdhaXQgZm9yIA0KPiBpbnN0cnVjdGlv bnMgb24gd2hhdCB0byBkbyBuZXh0LCByaWdodD8gRWFjaCBjcmV3IG1lbWJlciBub3Qgb25seSAN Cj4ga25vd3MgaGlzL2hlciBwcmUtZGVmaW5lZCBhY3Rpb25zLCAocyloZSBpcyBtZXRpY3Vsb3Vz bHkgdHJhaW5lZCBvbiBhIA0KPiBkYWlseSBiYXNpcyBvbiBob3cgdG8gY2Fycnkgb3V0IHRoZW0g aW4gdGhlIG1vc3QgZWZmaWNpZW50IHdheS4gVGhpcyANCj4gaXMgaG93IHNoaXBzIHN1cnZpdmUg cHJvYmxlbXMgbGlrZSB0aGF0LiBBbHNvIHRoaXMgaXMgaG93IHRoZSBzYW1lIGF1dGhvcml0eSBj YW4gY29udHJvbCBiaWcgYW5kIG11bHRpcGxlIHNoaXBzLg0KPiANCj4gQ2hlZXJzLA0KPiBJZ29y DQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29uZiBb bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpYW5yYW4gDQo+ IFpob3UNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxNyAxMTozMSBQTQ0KPiBU bzogWHVmZW5nIExpdTsgbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZd IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgDQo+IEF1dG9tYXRp b24gUHJvYmxlbSBTdGF0ZW1lbnQNCj4gDQo+IEhpIFh1ZmVuZywNCj4gDQo+IE9uIHRoZSBzbWFy dCBmaWx0ZXJzIChhbHNvIHJlbGF0ZXMgdG8gDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jbGVtbS0NCj4gbmV0Y29uZi1wdXNoLXNtYXJ0LWZpbHRlcnMtcHMtMDApLCBJIHRo aW5rIHdlIG5lZWQgY3JpdGVyaWEgdG8gDQo+IGNhcmVmdWxseSBzZWxlY3QgImNvbmRpdGlvbnMi LiBXaGlsZSB0aGVyZSBhcmUgbWFueSBiZW5lZml0LCBzYXkgc2F2ZSANCj4gdGhlIGJhbmR3aWR0 aCBhbmQgcmVsaWVmIHRoZSBjb2xsZWN0b3IsIGl0IHdpbGwgYWRkIGNvbXB1dGF0aW9uIGJ1cmRl biB0byBuZXR3b3JrIGRldmljZXMuDQo+IE5ldHdvcmsgZGV2aWNlcyBhcmUgbm90IGdvb2QgYXQg dGhpcyBhcyBzZXJ2ZXJzLg0KPiBTbyBtYXliZToNCj4gMS4gc2hvdWxkIG5vdCB0b28gY29tcGxl eCB0byBpbXBsZW1lbnQuDQo+IDIuIG11c3QgaGVscCB0byBtaXRpZ2F0ZSB0aGUgZXhwb3J0IHZv bHVtZS4NCj4gDQo+IElmIHNvLCBmb3IgZXhhbXBsZSwgdGhlIGF2ZXJhZ2UgdmFsdWUgc2hvdWxk IGJlIG91dCBvZiBzY29wZSwgSU1ITy4NCj4gDQo+IEJlc3QsDQo+IFRpYW5yYW4NCj4gDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHVmZW5nIA0KPiA+IExpdQ0KPiA+ IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAzOjMxIEFNDQo+ID4gVG86IG5ldGNv bmZAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbTmV0Y29uZl0gWUFORyBQVVNIIEJhc2VkIEdlbmVy YWxpemVkIE5ldHdvcmsgQ29udHJvbCANCj4gPiBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50 DQo+ID4NCj4gPiBEZWFyIFdHLA0KPiA+DQo+ID4gVGhlIFlhbmctcHVzaCBEZXppZ24gVGVhbSBo YXMgYmVlbiB3b3JraW5nIG9uIHRoZSBZYW5nIHB1c2gNCj4gZW5oYW5jZW1lbnQuDQo+ID4gV2Ug aGF2ZSBwb3N0ZWQgYSBkcmFmdCBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gZXh0ZW5kIFlh bmcgcHVzaCANCj4gPiB0byBhIG1vcmUgZ2VuZXJhbGl6ZWQgbmV0d29yayBjb250cm9sIGF1dG9t YXRpb24gZnJhbWV3b3JrLg0KPiA+DQo+ID4gVGhlIGZvbGxvd2luZyBpcyB0aGUgc3VtbWFyeSBv ZiB0aGlzIHRvcGljLiBBbnkgY29tbWVudHMsIHRob3VnaHRzLCANCj4gPiBhbmQgc3VnZ2VzdGlv bnMgYXJlIGFwcHJlY2lhdGVkLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IC0gWHVmZW5nDQo+ID4N Cj4gPiA9PT09PT09PT09PT09PT09DQo+ID4gWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5l dHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uDQo+ID4gZHJhZnQtYnJ5c2tpbi1uZXRjb25mLWF1dG9t YXRpb24tZnJhbWV3b3JrLTAwDQo+ID4NCj4gPiBFdm9sdXRpb24gb2YgWUFORyBCYXNlZCBOZXR3 b3JrIEF1dG9tYXRpb24NCj4gPiAqICJDdXN0b20gU3Vic2NyaXB0aW9uIHRvIEV2ZW50IE5vdGlm aWNhdGlvbnMiIG1vZGVsIDoNCj4gPiAJLSBhbGxvd3MgZm9yIGEgY2xpZW50IHRvIHN1YnNjcmli ZSB0byB1bnNvbGljaXRlZCBldmVudCANCj4gPiBub3RpZmljYXRpb25zIGRlZmluZWQgYnkgc3Vw cG9ydGVkIFlBTkcgbW9kZWxzOw0KPiA+DQo+ID4gKiAiU3Vic2NyaWJpbmcgdG8gWUFORyBkYXRh c3RvcmUgcHVzaCB1cGRhdGVzIiBtb2RlbDoNCj4gPiAJLSBhbGxvd3MgZm9yIGEgY2xpZW50IHRv IGRlZmluZSBzdWJzY3JpYmFibGUgZXZlbnRzIGFuZCBjb250ZW50cyBvZiANCj4gPiBldmVudCBu b3RpZmljYXRpb25zIGFzIHRhcmdldC10cmlnZ2VyLW5vdGlmeSB0cmlwbGV0cw0KPiA+DQo+ID4g KiAiU21hcnQgZmlsdGVycyBmb3IgUHVzaCBVcGRhdGVzIiBtb2RlbDoNCj4gPiAJLSBhbGxvd3Mg Zm9yIGEgY2xpZW50IHRvIGZpbHRlciBldmVudCB0cmlnZ2VycyBhbmQgbm90aWZpY2F0aW9ucyBv biANCj4gPiBwdXNoIG9iamVjdCB2YWx1ZXMgYW5kIHRoZWlyIGNoYW5nZSBoaXN0b3J5LCBmb2N1 c2VzIG9uICJvdXRsaWVycyINCj4gPg0KPiA+IE9iamVjdGl2ZXMgb2YgIFlBTkcgUFVTSCBCYXNl ZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgDQo+ID4gQXV0b21hdGlvbg0KPiA+IDEpIFRv IGdlbmVyYWxpemUgdGFyZ2V0LXRyaWdnZXItbm90aWZ5IGNvbmNlcHQgaW50byANCj4gPiBldmVu dC1jb25kaXRpb24tYWN0aW9uIGNvbmNlcHQsIHdoZXJlOg0KPiA+DQo+ID4gCWV2ZW50IC0gYSBw YXJ0aWN1bGFyIGNoYW5nZSBpbiB0aGUgbmV0d29yayBzdGF0ZSBleHBsaWNpdGx5IGRlZmluZWQg DQo+ID4gYnkgb25lIG9mIHRoZSBZQU5HIG1vZGVscyBzdXBwb3J0ZWQgYnkgdGhlIG5ldHdvcmsg b3IgaW1wbGljaXRseSANCj4gPiBkZWZpbmVkIGJ5IHRoZSBjbGllbnQsIHdoaWNoIGlzIGNvbnN0 YW50bHkgbW9uaXRvcmVkIGJ5IHRoZSBuZXR3b3JrOw0KPiA+DQo+ID4gCWNvbmRpdGlvbiAtIGEg bG9naWNhbCBleHByZXNzaW9uIHRoYXQgaXMgZXZhbHVhdGVkIG9ubHkgb25jZSBhZnRlciANCj4g PiB0aGUgYXNzb2NpYXRlZCBldmVudCBpcyBkZXRlY3RlZDsNCj4gPg0KPiA+IAlhY3Rpb24gLSBh biBvcGVyYXRpb24gdG8gYmUgY2FycmllZCBvdXQgYnkgdGhlIG5ldHdvcmsgd2hlbiB0aGUgDQo+ ID4gYXNzb2NpYXRlZCBldmVudCBpcyBkZXRlY3RlZCBhbmQgdGhlIGFzc29jaWF0ZWQgY29uZGl0 aW9uIGlzIG1ldA0KPiA+DQo+ID4gMikgVG8gcHJvdmlkZSBmb3IgYSBjbGllbnQgYSBjYXBhYmls aXR5IHRvIGNvbmZpZ3VyZSB0aGUgDQo+ID4gZXZlbnQtY29uZGl0aW9uLWFjdGlvbiB0cmlwbGV0 cyBhcyBwb2xpY3kgcnVsZXMgYWhlYWQgb2YgdGltZSBvci9hbmQgDQo+ID4gZHVyaW5nIG5ldHdv cmsgb3BlcmF0aW9ucw0KPiA+DQo+ID4gR2VuZXJhbGl6ZWQgQWN0aW9uDQo+ID4gKiBTZW5kIG5v dGlmaWNhdGlvbg0KPiA+ICogUGVyZm9ybSBpbW1lZGlhdGUgbmV0d29yayByZWNvbmZpZ3VyYXRp b24gKGUuZy4gbW9kaWZ5IG9uZSBvciBtb3JlIA0KPiA+IGF0dHJpYnV0ZXMgb2Ygb25lIG9yIG1v cmUgQ09ORklHPVRSVUUgZGF0YSBzdG9yZSBub2Rlcyk7DQo+ID4gKiBTY2hlZHVsZSBvbmUgdGlt ZSBvciBwZXJpb2RpYyByZWNvbmZpZ3VyYXRpb24gaW4gdGhlIGZ1dHVyZTsNCj4gPiAqIENhbGwg UlBDIGRlZmluZWQgYnkgb25lIG9mIHRoZSBZQU5HIG1vZGVscyBzdXBwb3J0ZWQgYnkgdGhlIA0K PiA+IG5ldHdvcmsgKA0KPiBlLmcuDQo+ID4gY2FsbCBuZXR3b3JrJ3MgcGF0aCBjb21wdXRlciB0 byBldmFsdWF0ZSB3aGV0aGVyIGFuIGFsdGVybmF0aXZlL21vcmUgDQo+ID4gb3B0aW1hbCBwYXRo IGlzIGF2YWlsYWJsZSBmb3IgYSBnaXZlbiBjb25uZWN0aW9uKQ0KPiA+ICogTGluay91bmxpbmsg ZGF0YSBzdG9yZSBkeW5hbWljIHN1Yi10cmVlczsNCj4gPiAqIEV0Yy4NCj4gPg0KPiA+IFJlbGF0 aW9uc2hpcCB3aXRoIFBvbGljeSBGcmFtZXdvcmsNCj4gPiAqIFRoZSBmcmFtZXdvcmsgc2hvdWxk IHdvcmsgYXV0b25vbW91c2x5DQo+ID4NCj4gPiAqIFRoZSBmcmFtZXdvcmsgc2hvdWxkIGZpdCB3 ZWxsIHdpdGhpbiBhIGhpZ2hlciBsZXZlbCBwb2xpY3kgDQo+ID4gZnJhbWV3b3JrLCB3aXRoIHRo ZSBsYXR0ZXIgcG9zc2libHkgcHJvdmlkaW5nIGEgZ3JlYXRlciBsZXZlbCBvZiBhdXRvbWF0aW9u Og0KPiA+ICAgLSBtdWx0aXBsZSBtaWNyby1jb25kaXRpb25zIGNvdWxkIGJlIGNvbWJpbmVkIGlu dG8gYSBzaW5nbGUgDQo+ID4gbWFjcm8tY29uZGl0aW9uIHZpYSBhIG51bWJlciBvZiBsb2dpY2Fs IG9wZXJhdGlvbnM7DQo+ID4gICAtIG11bHRpcGxlIG1pY3JvLWFjdGlvbnMgY291bGQgYmUgY29t YmluZWQgaW50byBhIHNpbmdsZSANCj4gPiB0cmFuc2FjdGlvbiB3aXRoIGEgcG9zc2liaWxpdHkg b2Ygc3BlY2lmeWluZyBwb2xpY2llcyB3aXRoIHJlc3BlY3QgDQo+ID4gdG8gaGFuZGxpbmcgZXJy b3JzL2V4Y2VwdGlvbnMgb2YgZWFjaCBvZiB0aGUgdHJhbnNhY3Rpb24gY29tcG9uZW50cw0KPiA+ DQo+ID4gRnJhbWV3b3JrIEJlbmVmaXRzDQo+ID4gKiBsb3dlciBsYXRlbmN5LCBmYXN0ZXIgcmVz cG9uc2l2ZW5lc3Mgb2YgdGhlIG5ldHdvcmsgdG8gdmFyaW91cyANCj4gPiBldmVudHMvY29uZGl0 aW9uczsNCj4gPiAqIGJldHRlciBzY2FsZSAoZS5nLiB0aGUgY2xpZW50IG1heSBjb250cm9sIG1v cmUgbmV0d29ya3MgYmVjYXVzZSBpdCANCj4gPiBkb2VzIG5vdCBoYXZlIHRvIG1vbml0b3IvbWlj cm8tbWFuYWdlIGFueSBvZiB0aGVtKTsNCj4gPiAqIENQVSBhbmQgYmFuZHdpZHRoIHNhdmluZ3Mg ZHVlIHRvIHRoZSByZWR1Y2VkIGFtb3VudCBvZg0KPiBjb21tdW5pY2F0aW9uDQo+ID4gYmV0d2Vl biB0aGUgY2xpZW50IGFuZCB0aGUgbmV0d29yaw0KPiA+ICogVGhlIGNsaWVudCBjYW4gdGFrZSBp dHNlbGYgb3V0IG9mIHRoZSBuZXR3b3JrIGNvbnRyb2wgbG9vcCwgIA0KPiA+IGNoYW5nZSBpdHMg cm9sZSBmcm9tIGJlaW5nIG5ldHdvcmsncyAibWljcm8tbWFuYWdlciIgdG8gYmVpbmcgDQo+ID4g bmV0d29yaydzICJwb2xpY2Ugb2ZmaWNlciIsIHdobyBpbnRlcmZlcmVzIGludG8gbmV0d29yayBv cGVyYXRpb25zIA0KPiA+IG9ubHkgaW4gZXhjZXB0aW9uYWwvdW5wcmVkaWN0ZWQgc2l0dWF0aW9u cw0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNv bmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpO ZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== From nobody Wed Nov 8 11:00:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AE2129B42 for ; Wed, 8 Nov 2017 11:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oxhu6Pi7jEf for ; Wed, 8 Nov 2017 11:00:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C412A129B3A for ; Wed, 8 Nov 2017 11:00:29 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSF77147; Wed, 08 Nov 2017 19:00:28 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 19:00:27 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 11:00:18 -0800 From: Alexander Clemm To: Igor Bryskin , Qin Wu , Tianran Zhou , Xufeng Liu , "netconf@ietf.org" Thread-Topic: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNYozCctBUDrHqNQFassZLcA0NQKAADd8mAAAN0HoA= Date: Wed, 8 Nov 2017 19:00:17 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD721@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@sjceml521-mbx.china.huawei.com> In-Reply-To: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5A03544C.0185, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 391c2aaf4a7339387475bd207c66fbec Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:00:32 -0000 Hi, A few additional comments inline, Thanks --- Alex > -----Original Message----- > From: Igor Bryskin > Sent: Wednesday, November 08, 2017 9:00 AM > To: Qin Wu ; Alexander Clemm > ; Tianran Zhou > ; Xufeng Liu ; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement >=20 > Hi Qin, >=20 > Please, see in-line. >=20 > Igor >=20 > -----Original Message----- > From: Qin Wu > Sent: Wednesday, November 08, 2017 10:21 AM > To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement >=20 > Interesting discussion, does smart filter mean that netconf server should= be > stateful since it keep a few state while traditional yang push doesn't re= quire > netconf sever to be stateful, i.e., should be stateless? >=20 > IB>> Yes. For example, an RPC (one of possible generalized actions) outpu= t > could be stored to be used in subsequent ECAs (event-condition-action). T= he > models we have in mind will allow for managing and accessing such state. Yes. Just how much state we want to allow is one of the items that = need to be discussed. I am of the opinion that this should be limited to a= few frequently used scenarios such as threshold crossing alerts and in-ran= ge/out-of-range monitors. By its nature, a threshold monitor _has_ to be s= tateful (it is not sufficient to simply compare the current value of a data= item against the threshold, you also need to know if you already reported = this earlier without clearing the counter threshold in the meantime). This= will be simply part of the feature of the smart filter that is configured = via Netconf/Restconf. However, I don't think the state in those cases shou= ld have to be externally exposed - it is simply part of how the filter cons= truct works. =20 The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you keep track o= f the high water mark for some amount of time after which it is cleared. (= The analogy is that of a graphic equalizer.) =20 With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one. The intent here is not to p= rovide a general programming framework to define any type of events - as me= ntioned earlier, this is not intended as an event+expression MIB or any suc= h thing, just frequently needed filters/categories of events that are fairl= y broadly applicable and useful. Obviously, where the "sweet spot" lies is= subject to discussion. We would love to hear feedback about what other fi= lters are deemed useful. =20 >=20 >=20 > I think set threshold for packet loss or latency is pretty much common in > network trouble shooting, such threshold can be also moved down over > time. > What kind of threshold can be set more depends on empirical experience. I > am wondering how this can be modeled using XPATH statement or some > other mechanism. >=20 > IB>> I let Alex answer this, but I would assume that the smart-filters > IB>> model will allow for comparing a data state pointed by XPath with > IB>> configured threshold value to evaluate trigger condition (and much > IB>> more) We need to figure out the details of the filter construct. In addit= ion to node selection and value/range comparison against a threshold/range = expression (so far, so straightforward), you need to be able to specify a c= omparison against a state, to update the state (e.g. threshold crossing sen= t vs cleared, current high water mark etc), to specify a counter / clear th= reshold, etc. I don't think this can be accomplished with XPATH alone. =20 --- Alex (remainder of message thread deleted) From nobody Wed Nov 8 11:12:41 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AF9128990 for ; Wed, 8 Nov 2017 11:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiK1Jpdw3TT9 for ; Wed, 8 Nov 2017 11:12:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27BA129B4C for ; Wed, 8 Nov 2017 11:12:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK63576; Wed, 08 Nov 2017 19:12:32 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 19:12:30 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 11:12:20 -0800 From: Igor Bryskin To: Alexander Clemm , Igor Bryskin , Qin Wu , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AQHTWMV/P1IQx6kSW02L2Q8DtmodTg== Date: Wed, 8 Nov 2017 19:12:19 +0000 Message-ID: References: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@sjceml521-mbx.china.huawei.com>, <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD721@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD721@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_etPan5a03572a731111203b08localhost_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A035720.0109, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 817a78a082de0834cb664e2568d8cd69 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:12:40 -0000 --_000_etPan5a03572a731111203b08localhost_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex, I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server. Igor From:Alexander Clemm To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org, Date:2017-11-08 14:00:25 Subject:RE: YANG PUSH Based Generalized Network Control Automation Problem = Statement Hi, A few additional comments inline, Thanks --- Alex > -----Original Message----- > From: Igor Bryskin > Sent: Wednesday, November 08, 2017 9:00 AM > To: Qin Wu ; Alexander Clemm > ; Tianran Zhou > ; Xufeng Liu ; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Hi Qin, > > Please, see in-line. > > Igor > > -----Original Message----- > From: Qin Wu > Sent: Wednesday, November 08, 2017 10:21 AM > To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Interesting discussion, does smart filter mean that netconf server should= be > stateful since it keep a few state while traditional yang push doesn't re= quire > netconf sever to be stateful, i.e., should be stateless? > > IB>> Yes. For example, an RPC (one of possible generalized actions) outpu= t > could be stored to be used in subsequent ECAs (event-condition-action). T= he > models we have in mind will allow for managing and accessing such state. Yes. Just how much state we want to allow is one of the items that = need to be discussed. I am of the opinion that this should be limited to a= few frequently used scenarios such as threshold crossing alerts and in-ran= ge/out-of-range monitors. By its nature, a threshold monitor _has_ to be s= tateful (it is not sufficient to simply compare the current value of a data= item against the threshold, you also need to know if you already reported = this earlier without clearing the counter threshold in the meantime). This= will be simply part of the feature of the smart filter that is configured = via Netconf/Restconf. However, I don't think the state in those cases shou= ld have to be externally exposed - it is simply part of how the filter cons= truct works. The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you keep track o= f the high water mark for some amount of time after which it is cleared. (= The analogy is that of a graphic equalizer.) With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one. The intent here is not to p= rovide a general programming framework to define any type of events - as me= ntioned earlier, this is not intended as an event+expression MIB or any suc= h thing, just frequently needed filters/categories of events that are fairl= y broadly applicable and useful. Obviously, where the "sweet spot" lies is= subject to discussion. We would love to hear feedback about what other fi= lters are deemed useful. > > > I think set threshold for packet loss or latency is pretty much common in > network trouble shooting, such threshold can be also moved down over > time. > What kind of threshold can be set more depends on empirical experience. I > am wondering how this can be modeled using XPATH statement or some > other mechanism. > > IB>> I let Alex answer this, but I would assume that the smart-filters > IB>> model will allow for comparing a data state pointed by XPath with > IB>> configured threshold value to evaluate trigger condition (and much > IB>> more) We need to figure out the details of the filter construct. In addit= ion to node selection and value/range comparison against a threshold/range = expression (so far, so straightforward), you need to be able to specify a c= omparison against a state, to update the state (e.g. threshold crossing sen= t vs cleared, current high water mark etc), to specify a counter / clear th= reshold, etc. I don't think this can be accomplished with XPATH alone. --- Alex (remainder of message thread deleted) --_000_etPan5a03572a731111203b08localhost_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor
From:Alexander Clemm
To:Igor Bryskin,Qin Wu,Tianran Z= hou,Xufeng Liu,netconf@ietf.org,
Date:2017-11-08 14:00:25
Subject:RE: YANG PUSH Based Gene= ralized Network Control Automation Problem Statement

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.com>; Alexander Clemm
> <alexander.clemm@huawei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@jabil.com>= ;;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

 --_000_etPan5a03572a731111203b08localhost_-- From nobody Wed Nov 8 11:23:54 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC27B129B59 for ; Wed, 8 Nov 2017 11:23:52 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 Y7ZwhQ8kHQFp for ; Wed, 8 Nov 2017 11:23:50 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF6A124207 for ; Wed, 8 Nov 2017 11:23:49 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id a132so4442889lfa.7 for ; Wed, 08 Nov 2017 11:23:49 -0800 (PST) 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=qsu2qQ9j087XTJYMOsvWHG/xLBmuHQngUbeL44WAI5A=; b=c2Ks2E3REXlfckKOxVAmmEc02OUaUsq9QjTjYxiBvf7QmEkWY/JghuYoGhurpAxDee Fli9/UMIuPfjzrZ9h0bj1zIIEqr3NjBPFEMyBk8UsRRhDb+40pdo93ZUb2jeTE2id1/7 HWzKANr9dyJkAjYIg8ginhcNiM0qbG9XhnM46fRd+f5Arjz1gKWhxCxxxUgyu0CRwEkk GfxoNhxuKG55sR5uH7e9x4+GmHm/HCmAxL4JG5oLjvBWZFD50VM8cRtB2xUpQvqlyxPg XR87YQ5z+M5p6Fhl6ivM4uxW3+ax6I1d/ssvFj37UY/2sT73Y13t+W6qkJHQSfJTEVCR iy0A== 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=qsu2qQ9j087XTJYMOsvWHG/xLBmuHQngUbeL44WAI5A=; b=t272XufcfISDVmV++wSeviwv9DrZb5tZs7H0+WsSNg1dlgqiyt3vObIUpDVA6eV9HX sVAGBpF6PMXfNDIbXskidb3CQpJTNHeW73er+ye4A62suAEskkHbIQkF73FLyPbhUXee HxhsAHYzD+NKDD9aa0MP4k2Tqw71o+fM8OcI/H9tZ24GcY2xWg1H59RoFmh7ckP442AD BQ1V87RbtY/LHunOXyNFuqYF23/r6aHqZqy1PRsRcsUU5JtQaSTjvu/WR3lCe6VYccUu miM/uN1ilTSj2stD2QG6nc3NERSZv8d4T73NL3CYuOhUbLcM6OvLmKMOBqC6ZaYLjDn3 NcZg== X-Gm-Message-State: AJaThX4epH0aWRkQp9NJLmtBRDjKy+20uaG3RmFjsNghOeZ2WYKiv1Rn dTWl+CgbfzwkA8Q3lJ5/q25ZVNM2EDY9SjdqgdWFhw== X-Google-Smtp-Source: AGs4zMbjHTIBwRNQM3nJv2lwTJ3t5YbPPsQNKB8wy6bmlJhJXUJ26WxVl3irIIRZ5NlKQI//R2vgDuas+Yy2cTNPFHs= X-Received: by 10.25.204.81 with SMTP id c78mr616272lfg.49.1510169027644; Wed, 08 Nov 2017 11:23:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.214.9 with HTTP; Wed, 8 Nov 2017 11:23:45 -0800 (PST) In-Reply-To: <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> From: Andy Bierman Date: Wed, 8 Nov 2017 11:23:45 -0800 Message-ID: To: Robert Wilton Cc: Benoit Claise , NETCONF , Martin Bjorklund , "sec-ads@ietf.org" Content-Type: multipart/related; boundary="94eb2c1a17c47224b1055d7da02d" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:23:53 -0000 --94eb2c1a17c47224b1055d7da02d Content-Type: multipart/alternative; boundary="94eb2c1a17c47224ad055d7da02c" --94eb2c1a17c47224ad055d7da02c Content-Type: text/plain; charset="UTF-8" Hi, On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton wrote: > Hi, > > I'm not sure about this change. > > I'm not that familiar with NACM, but if you want to give a particular set > of users read/write access to a subtree, but not allow them to have any > other access to the configuration in the running datastore then with the > existing RFC, that could be expressed with a single rule (example in > 6536bis, appendix B.4) > > With this new change, I think that you may need to configure many more > rules to achieve the same thing. I think that you would need to give read > access to the top node in the desired path, and then separate explicit > "deny" rules for every sibling child node walking from the top of the tree > down to the data node that read/write access is actually being given to. > The example below may explain my understanding better: > > E.g. For a tree of data nodes, rooted at A, if we wanted to give > read/write access only to "J" subtree, and no access for the rest of the > tree then: > > A > | > -------------------- > | | | | > B C D E > | > ----------- > | | | | > F G H J > | > ... > > > In the old model, I think that the ACL rules would be 1 rules long > (assuming default deny all): > "read/write 'A/B/J' > > In the new model, I think that the equivalent ACL rules would need to be 8 > rules long (assuming default deny all): > "read/write 'A/B/J' > "read A" > "deny C" > "deny D" > "deny E" > "deny F" > "deny G" > "deny H" > If the /nacm/read-default is "permit" then these deny rules might be needed. In the current NACM, you only need a rule allowing write-access to J. This could be via a module rule, not just data rule (e.g. J is from augment and the user has write access to the module defining J) In the new NACM, (assuming default-read="deny") you would need rules allowing a read on /A and /A/B, even though the access operation is "none" for these nodes. Note, I am assuming that a "path" rule matches for the given path and all > descendant nodes. The draft doesn't seem to be particularly clear on this > point (it states that the rule applies when the path matches, but this > would seem to be counter intuitive), and perhaps it could be clarified. > > If this change is allowed, then the example in appendix B.4 looks like it > would need to be fixed, since the "limited-acl" probably wouldn't give any > access at all, unless default read access had been given. > > limited-acl (permit-exec rule) would only allow exec access to actions if the group has read permission on the ancestor nodes. The 'comment' field could be updated to point that out. There is no affect on executing operations, just . But, possibly I'm misunderstanding how this all works! If so, apologies > for the noise :-) > > Thanks, > Rob > > Andy > > On 02/11/2017 14:18, Benoit Claise wrote: > > Dear all, > > Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the > Security AD Eric Rescola part of the IESG review, which I would like to > validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf- > netconf-rfc6536bis-08.txt > > > The NETCONF WG was cc'ed for the entire discussion. > What do you think? I will draw the conclusions by Friday Nov 10th. > > Note: If the WG is fine, the next step is to approve this document. > > Regards, Benoit > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > --94eb2c1a17c47224ad055d7da02c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.c= om> wrote:
=20 =20 =20

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I think that you would ne= ed to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for th= e rest of the tree then:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0=C2=A0 | =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0 D=C2=A0=C2=A0=C2=A0=C2=A0 E
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 -----------
=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |
=C2=A0=C2=A0 F=C2=A0=C2=A0 G=C2=A0 H=C2=A0 J
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'
=C2=A0=C2=A0 "read A"
=C2=A0=C2=A0 "deny C"
=C2=A0=C2=A0 "deny D"
=C2=A0=C2=A0 "deny E"
=C2=A0=C2=A0 "deny F"
=C2=A0=C2=A0 "deny G"
=C2=A0=C2=A0 "deny H"



If the /nacm/read-default is "permit" the= n these deny rules might be needed.

In the current= NACM, you only need a rule allowing write-access to J.
This coul= d be via a module rule, not just data rule (e.g. J is from augment
and the user has write access to the module defining J)

In the new NACM, (assuming default-read=3D"deny") you wou= ld need rules allowing
a read on /A and /A/B, even though the acc= ess operation is "none" for these nodes.



Note, I am assuming that a "path" rule matches for the given = path and all descendant nodes.=C2=A0 The draft doesn't seem to be partic= ularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" proba= bly wouldn't give any access at all, unless default read access had bee= n given.



limited-acl (= permit-exec rule) would only allow exec access to actions if the group has<= /div>
read permission on the ancestor nodes.=C2=A0 The 'comment'= ; field could be updated to point that out.
There is no affect on= executing <rpc> operations, just <action>.

But, possibly I'm misunderstanding how this all works!=C2=A0 If so, apologies for the noise :-)

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

On 02/11/2017 14:1= 8, Benoit Claise wrote:
=20 Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt

3D""
The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.
Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


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


--94eb2c1a17c47224ad055d7da02c-- --94eb2c1a17c47224b1055d7da02d Content-Type: image/png; name="dfpcfioondggippe.png" Content-Disposition: inline; filename="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a85fc09ca1ef0005_0.1.1 iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC+YHG lxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL54BA95Wp YrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIgiN2ClI8gCIIg CIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU1budlnGWW9Ei1mf4 5fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluGnFMMK91+zhv/yNjzT4Gd o4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pdbo6buif+9eeWtPnXv6CR/FPY c+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJXx1+/P6TX1qbAn3/+DWvTKfuX9bC2 S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi67wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4j lgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNXud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllF nBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Ygfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvS S/v9L9HPMFFl8D5zbEGSizUDcgokCKIH5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrf X8TtVh6W9yB1MxV/iBt3fOpwlw7vXD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbf wKXq6se7Lj//Sj6DlcJB+9FIFUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60I yDIBZ0CCIHpwvuN8FzTL+Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omkn OhYrqi1hzNqj2od3bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyr z1EzN0EQxL8430WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt 4qmnrDDAnL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB +Y7zXTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUjYtyT WcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35KV73CFvr JiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX7+JJ7+0z04ZX /O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz+95YmLPx+1/yMeRf 4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV08idquf+lP/67/LhW/5k2 PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE7PAZOI49IrPfJ0V5TphipXuR ygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWRMVfPIN/X+Z9//k1OMc9Qy8DwPJQg CGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/hE8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53 d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggb pHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIRBEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQp H0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjN a2EZnE+HzC6sB2G8LZmOIAhioxiZ9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZk OoIgiJdH8fl5IxV3NnE+HcYZUFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw 81P7SxDEnpCa9NqqZxOX+jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw 81P7SxDEeyJK7IQUQ1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEq yJ0AIcWQVSRJCimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hC FmMqFlg1urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1E u5mmD0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL3CW0 ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YIWu/yWetq 1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/UNHcDNc3Zrp5a 5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeIo4gGND27y1MLZvIP uQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t8ln99duTIAhigLHKlxsi uxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl1nzKp+Ujaq04WI5YRfkC1crm E9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rrP8E3YwZKFrZvMInH3uVDHQxlDPXk 0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+WbZk+CIIgB8SYNeZRMve/lwsyUD6sDyNKb UD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPmUTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GD yXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7eC4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht 0n0cLKoF63cIZ6B86kCoJV4MtQTbn29pSiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJs QL28FwT1Rv1Afhi4+9NJTcTLV2ChS5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/S VkpCT7lSubom5cNqpuw8ws0z7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PB d/P0Ke6NCIUUa39CuSOi3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3Ps SRDEmyA97eGP8seULP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LP tyT0FMNYVceBkbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIl sPbESiyLJ6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST 9xEEsW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhi V1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAI giC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkI giCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUn VoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG3h+ZSvKYui KJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G0ZRFhxXNtdqM2lZFUVTtau0TPnC8 HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5tc2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoO p7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7 A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZxXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJW VXs7IOu11QsEyzPgUh9ze4nHa46R3CIe6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62 nqaX+mg3/dTr4hHMSfnKjo/d5vwhtJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+f pHwuZFGRuUDKNyb71Sjf+XTwrYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43P BYfEc+bhIX1bHY99vUt9FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6 hTkZi4gcoIxJ/r5KdxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebh dA4T6GBCXa/m4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjP qJ5hsH0/4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+e ccfXV9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eTq8ry NyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIgBcgOwM5j qseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCoyc3Yg+mb4O4s GQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqMnJpG051AgFBBv6gE xusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3q5PsRvuI/RbYTUoUbUXO pNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D951McnPo+4BKT5w0x 1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82v7StiIFUJKP+OPY80jwO+yt+UI+4 0fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olSQvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z 0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yLHfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFp BHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78 FtkNU75gaTX4E61wKzuM2tmCZZ/UuHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTG k+dNAYvyWaGheKR9x8jsrpcP9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fB AkNsw2smbXDqadsT6e/2E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/R Creyw6idLVj2SY27R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFw amQEojxnRP5NzPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9 mpPy9d3P6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRi RVxI/k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+uOW8I KOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnSrUTWXMqX Wtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUUegQn2iG9uptB m9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6FDqO+qs6IE5Gx1Nw UD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M6AmCbeO7RgDYb4Hd5Nu6 hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk97vNQvuSNAC+Gzo5ZKZ9OTQry nvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBfGylLFahJ+UH0Zh23+2uaLXF8XE11 AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQNqCb83Eja0uWpe70K2XlKv5BfWXomxrf/ PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOIxz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77 z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUvw+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8 IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGbxBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq7 16uQnaf0C/mVpWdifPvfcykJaBfZTVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7Y ITnuLn92jTu+voCjO+8/14Ve4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbED LLqLxPU6LdOReHOsd/8h5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/ kPK9M0TOFZf4dgaVT7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRB ELvCWhMqQRAEQWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wE QRAEsS2Q8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88d wDXub41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW38x2 fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4DkUh+3EeYm NiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tbPMbXnzDyl7pa wky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz9XdGymcJIeWbqAkp 33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+eiIWmT3b6hYgXerjNmb1 Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7Nz4XHBL0eFjcbqvjsa93qY/i r01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP6o2fLGoR1b5nb5bdL7JfsL/QPPl6 Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3v gm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidwxhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0ted YYCyOZ860qfavR8efv1MPrY6deeeT4fhj6dikdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+ dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmr qm2tcbHGEfVXtdE55O0nLD/dqWw9TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmW u1+zwvRD+z5g2WfCdQSvCyE+5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplTh r0U6PiVrUrFWQKbOIiL/bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0Zvd bmpcXMB2MPVH+vR5tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbak Qfl8/ZoZNgW1/AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8 tUjHVbImFWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3 mxoXF7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDyhWFP P+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+SH88jjn1 pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb9vSBZ07p6y6C Hkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMFrWEA64FfzwTlg3GT RfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3COMoGosroOhq4wmTK5+rX 3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNYl/KZsWIyprFDWBiZb4nyTdFz JsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxhT/N6eTApN9O9HqV83n7NDQfl03VG Vvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUbUz4zVkzGNHYICyPzLVG+KXrORPlAR72U b54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xpXi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/Z KN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq /Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3ta Erw5ucqeS1I+Z7/6mvN8LTib8iXs47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6 FpAReGEmQaWSjkZCWPUFAf1b+NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2K pT/SB1EyOI6gv1ChKZTPpWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj 1/9mue6ME2Rv+6+uwHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/t q5eN+r8fTj1z9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpL WR76wBzKz+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJ ZI1fR/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq2NHW xxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNoN4LORLQu u+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p9mZm2J3hb33R 9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa2NpX2YmpMD7q8ap4 5F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOrAVK+veCRz3duC3He4lrg Zn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4jiHUgUt5WD6FV0h+vDYJ4LtZc 5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7 wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUWvu+o0H3scW/feUT9erf+EhOwwesUYXzc z3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3/hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+d tuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPH zmx467Q1N1UD2x0+dce5JfqLtnFcY3vHNfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xS vgfwUpTvyW2S8s3fxktTvlVAyrccZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVson dpEOogG513UpQgVwfNinPRA0/KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZ rSlFc+IXdFzaKDsB0m3ntPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0Y VjPtgBP/oD3LMryOgvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8 IR9LTJ5iF+kgGpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO2 0jalZdmtrURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y 4z56XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK4E7H 1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6ZcpB/sPGHdg h8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f9egZnpEL+xGV fV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17ZtxU9RyCVU0C8GtZUM 7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k9Hf1F/t50j6efplysP+A cb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6OUD6Z+Zj9Lp/tz+77qkfP8Ixc 2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkYZOgwRodKKCRyUj7TbhHt6YSi40B/ 3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19QDuhvYtyBsnhcPJQP91deO+o6msUP8XU6 rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1FnzDv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPy MMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtDWP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ 38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1 n/JlPsY2q2V+DWAy5ZMhyDyUD9kNKjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJ lE/VnuqH6Dqd2i9DtfJ0Pp9Ot5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2 g4qMxNL5lO8RO4eyH6d80A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu5 7E/dHuXzXu+kfE7olCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6X z855fRi6oBscXeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8u P4SUb1q/YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzd fkLHjaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8c93f 4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+rqY6Ifr+ gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTLRqbdFHNH0p39 BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9cfk5KGw3lXd5Gnud L+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0dH1dTnRB9f8BS/1hVfd7W UKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+2ci0m2LuSLqzv8DPzfrufqF2 kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yhPy4/B4XtpvIu67HX+RL+7L3enXr6 7AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnzvfD8p849trQrwR7wbnZ7t/4SxASQ8vmQ mTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/ezW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Bu dnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLEr rD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARB ENsCKV8Gug928tuHxGxoygW//7o1nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Gi w1v7yRLYCeVrShgUzbaTHrc5Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqK ta7TGGtPrM9FW8GgaLad9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go 1rpOH8H+Kd+MbWwntHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hp MuSQ8j1R/lPkPBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/Hh FJyQKfdWL2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9V Lsvul7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fghEy5 t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5rXJVdb+M xaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI7eMZFy9GKJ/l Jzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18OgxCz6eDmUB1Ph3G KZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfpGYx1TtButgvlO+V8NmVh 6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJdgZ/0vyaO5FzXqD7qL7x/rned xnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9THQeilPpoJVJf6OE753HraAHKQnuh4 G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw1jlBu9kulO+Uc22rwtInZTeXfKd/ijpq SBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZR Ux8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fyoUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8 bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgoX9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8 fa3rNMZTZ8079IPeHMqn6vTxQkIOSAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIc x4Q+oBPYnp7xhXqqMY3H15YdV8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGP yxRYlM93X/Jd16g+6m/K39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+ MI4JgXZIDe35XpTPv65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+c mRrEAEk5G6J8U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM87 7nn3Ge3P81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR 45DFr6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wqp/S2 ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKHYByTuW8j IXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo2yfRwdua2Bzs 5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISNPh8SfU9AJaSZcvrD 8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuXjfp/7tjI8NS2g09OJ0O5 WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+OcUzYJzEuc1A+swPQT6D/e69r XB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBBCBt9PiT6noBKSDPl9Ifl5yugnCl6 Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZV69a9f80jHahHXxyOhnKxWLPKvK+FGLp 6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06 fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRq gFRhH+A47g/eV8AI4kWxGuVz7GxGbBgcxx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5 ykcQBEEQs2PtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3 /c3UF7JnGmL/8D10Z6dYdhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N3 3h7PW+U7n8pFI9B4J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9J L3W1aAQa7yT29P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRD IOWbV84WrebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAml jKXkntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xOhWf4 /RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9ofsfbgeP 9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMqBdXN8cLH3fZ3 jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nwDL/fIsR2TtoHyrf9 E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatwKuKC91+bRtOsiPIVOpbu TnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7ouNv+3nH5dPtJp4J+4QzY+ROP i09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzUfSY8beSo+cuI/BgvdH1tHs+fOmVm k3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQ rq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fAzlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9u OW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aC PhgysB3C6zDc7VW+/dDFvfClINTCeLu+fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om 6mnbE/ktPA76pY/l5Vlb/YL+7JQzwW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx 4GCCCiV+TIXy97+rdoI+GDKwHcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gk Gr/GfqJtrENky87xOVP1tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRF KF/msgxYDUu2YjWIDvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy 5ZPUzk35XHoie0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd 6ENAnz4YTsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBa cduundzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgXp56J ZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586VVAcJFyZ 8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6lZNDB8QIZfB4 oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQn5Hd0JosvM+EzYwc NX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2IosufLA6nk/ndCbc+BrraZSPk WblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ0MKhLA994AztbI2LW09oz6aU fqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyMXNfjuFu+vl4DS0yeKj+oFrRGZyyp d2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5aIc/KVVNMwXzfJsukoZZWu95+2fXHdSmO VXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328R sJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaCeEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKy XrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQxYAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5 IOUjJoCUjyDk9marL/F1moTfIrGPQ6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1z Ibd9COJ6vZLyEQRBEDvD2hMrQRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2 QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH 7bA+xI7aa5trY+g+XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jp xgeQWAU7oXyJzce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9 sT4Xic3HtrDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8 Mc6ng281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b5bLs flGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl01jjgvRP 43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusOuwlZ+T6y1/vY +2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5VrqruFxV7DfWrKidy NOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1rTUuSP80bmflyAF2MP0q ZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6wm5CV7yN7vY8RMeakfE2pgzsV LfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anWORoVSJpVIFB9qaVIxMP2gcdt/T+B 3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYHJ9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4Sp zBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73 iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJh zgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTLiwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a 9d12645kUr7d3scICzNSvjBc6ZdFwmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7 YLsh/cM/cJ/v4i37hxLGY0akvzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZ cRUbiXG3OpfyW9s/7fp+u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VR FF2RDec8NQf1MeWz7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj 2yIT/BNoY/+i5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583 Z6jk/YqCrA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7 x/OnzkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU0u/s 6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQWkrfEh/TM XR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12s5pP9muf97Fe 7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUzKB+sP/ygcsQS9gHH gf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA8OaXRfXH/RNqA35JXUh4 MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xdd0p84CD4YfRrFEVRHMpSB+7D b8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7APsj+QV7qKf063/3tuEHPqKp69WoM sZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5/6EsdaKsgwwA/0z4oX1/wHaD9R12S48X 6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIriWFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqL b5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fjBj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jO EHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD+/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6Q fXZit+wlPmIFPJD4txP/zMa79felseKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/K x63Gtgzvq6kS+/DPfLxbf18aK86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN 5aO9aB/2Crmt3eQlvvca23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQq H0EQBEEshrUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV 1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIg iG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI +QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaF tSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8STcD4dbk7ZlEVR HE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9H9SfIJ6ES328OWVb FUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrSqmwfnRdIT5/+CIkenE8H hnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte4s63Lywwd3YRixn4XOqjIxBq K6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTUdq0+b9X/L3WVo9Y894fr1WbDS9z5 3hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfDoktEE9udjx4tgEzKN9+yJSnfHFhuCrUf 4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZs yrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3l e85g0yskpaTG8XA6h3Y17eAdF6Bnl+VYWv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717 IczfSMrnu2/Y/iYS1O+/B5YL7p8J/yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH 7YpTqupmj0S/zIQu2dGw087+iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4 AD27LMfK8k+AHPlZdutXyNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw /0z4JzEHXmyVT1IBQUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH 1V10HKApdWSsWJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S 3Kz6hJCMVL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T 1iy1unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQXo3xW qCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT1gd0wraD 1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5gL/NQ/mIFJab QpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBMvPKUjGzT6xFH11Wb 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4VDHf/xCPVrkn5gL/N Q/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGvcyQon8m5kvoYnUB2sNrW5y1O +ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK51sGSdf3UD675pyU735QxYX+/hZm hOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTpXzWZi/LNm0r46Crfkz/2maB8vvsG9jdS vi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2vVMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOo DL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCAPl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgE Y899A/vb8Iu184xN+bB/EhaWm0LnoXzq/TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/ pVzVKNITHUftKsXFyeh4jqIy9Jb5vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgd b+T6Ndf9VKLvqHrqNiMTjD33Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9 +sN2ZRKY6m7cr9F3coxI09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx 9JQ+Gfrn2LBoSX67JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmb mmUHwz+JFBaYO/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0Bfp CY7b7eqMNxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhl k8Il9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+z3oS uwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiC IIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhYWFhcZXVuw2IW 7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GWaIGU7+nl8uNLURRV /b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp0mVBPduPpzrq6tyG5b// qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+u3iltV/F3s9rm/Qlys3+S4z4 qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTgp1/1l6eF5vXHLe6//PiyKF+C7f6q vzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodK W31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9 ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5OSfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198 iy2TFgY3X5agQKR8fj29hZTvtQop3zLliSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjc fFmCApHy+fX0FlK+vZYlWliF8tXDRqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJE Tp04iH6KQ/NYzy5b8qNTKSeG/vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4Cf ADm2PpP8QZji46P68uOiEgjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61z rxfndX3PKvxW/XGvrzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt +kP8hI6jgvQx+ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0o imN9uv1nOOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/E uKBijlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b11Zf i6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QGllJXIvZt P1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkrxiof1BONC7QD HC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jnNL8FLmGv8hWu68Vz XXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef1VBH6PbvfxwHfdDxBN+z 2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7VYXU/etq139fr9/b9nbwe3sZ 2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGBdoDjhTQ3/SQlB+jj8odL/dtgWz0W Q1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpXuK4Xz3UtfKLPmW6/tzePFFeCNOil/S7I rnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDIqT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvV FAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5dfnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZP Kkp2fVYkpnxYTzQuCTuA8UKaW36SlAP08fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjE WGJnzvVi98sud34iKVBHVP7oD96ZUjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF /bXtM0L5/tDrnOP23Drl+17p2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHl eNtN2wcXFaDnjFoYOWE90bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6Ge E/0WuMRYYmfO9WL3yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb 4bqSbxh3/x8ffcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/Klxgto DvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8Z GyTfIjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevowLkVO TMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4g/6G568f x67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6dYAmZkknV2j8K ldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KAYcZvK/VmSh/GpciJ SfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/TD9JyoGUz+EPOpo91cc+ Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQcdjuPJTPeHE28oP2q722aCVG RqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5VX34VVdffohfgvB6wPCOkFrW7eWI b2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3GWs9eY8GfbzHHEY5LhvxovKyC/ATISerj 8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7vtL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87r esjG/Naq/3c0podJwwIq1avyx7ejPGX4bImWA47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo /Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V /71GSMnxtmvaZ6z17DUW/PkWcxzhuGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVR VN/61+Sc/u+0v9dvsZ4Jv73Uv/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVV j77O9706fhOBl/39oqFdU09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4 rEP5cCi/3AYGb138+/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz 1rVyWbHtfe6XAsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ5 5avXWZZoYSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhY WFhepazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVgYWFh eZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv/ShytvOe p/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+LXK27Z6nnMQ+ 2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/HSVTw8vdv45Tv57fq 5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnwuphdzrPL3Hpuxg/bD7tf 6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyParl1rYcjLtWo2H2g/In6tk6TlD 6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdGy3qU78GyGOWbWkj55pU/V1mO8n3c IvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76d1K+efWcofR+0Y3CsFO8f1xYsstm/JCU b137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+Kojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H //jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrjfljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yo Hegpjs+fDThC+VLj8sh1MaOcX/WXm5Dbf4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrP uCjDbz2UL243sNX9z7RWWJ/OkkVRfHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3Ww swyXhpWUr22XY9lWRZc5eZfTx9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLa r1XbtyBiLHHKUDkhB5ZB/aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJu l8uxPkXXDbLb4OlV2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+r arj/gePwukD+4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t8 0fGf3wRd/GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsY Ub9D5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+4/er JeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2PCpykxVu GIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE7ddOH6incoT2 a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYLxAnOJjVytIv9EBfT D4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0fLZuifGKVIFi9iUu8UCYp X///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739Uf//Pw4mdMtTWD9plqOSgfP0q 1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZAjutiZjmh9RJ20/a//PhyfIjy5bab 8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue6HjiukD+4/arJeyfVxajfFFcI5ba7rjF IDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cROGWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTd hFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5Jt dSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUo X/0hwrJf9RcZKs1B+bzyU/Whb8xC+Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/q jx+XXz/q+lf98eMSVsvWx0/5Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v /FR91PQ8lG+ZTzvOQPl03yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq 2fr4KV/m8i8Yjhy/WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2eh Qxc0Nb2/EzgWQqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TP dV3MLMegXtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrU R38T9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4Gu611 zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtBu5dvdf2t qk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH849uxkJTpH4Ms 8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK727EVv1b1/9Q3G758 VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtVitxdHzgu81wXz5MjBgXY LbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z6RMOvewXOG7bGfmP06+ebX9f eT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plwu2PhGP58i8odFe8lGvqMGHA4SbHd sOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI3 6VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0ycc ev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8ZcoqxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4ur LLUZBgvLUwop34uU1Q3OwuIppHwsL1BI+dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQ cbfMB3JYWKaWLVO+IQ9pv5scr90+C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30W FhaW9ymkfC9SVjc4CwsLy84KKd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnP p8MrqUu8JF7vung9rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF 62H79/k1V/maEoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix 6+L1sIqB155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqT RvBi18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlDs3r9 AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvOWA5WsXef RtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjfm9VuF1F/8ZVN n1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/Vd0nepHoeF8v6KLc tjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV1fZNi5g+IaeqjPojuuZ0 SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68fYj/XwroGkHwsx+//c6Ebi7sL DZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ7Onyw6T/GP6J9fTYH9oN62/dGpPd s+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+zYhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8 y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9UpkvOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos 5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7 Qf21T46uVKP7/FP9donJUwRPl/ooI9IhernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9Vo lU/GouFZNvXC9Q1N21YEfbnrREa7WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQnd wPgqsZCD2nX6+QRcTMLUVpqgxY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/45 03UH7Qb11z45ulKN7vPP99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDI bsqRdeL6MfQC0QOUD8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+t u1Itf9xH9G/K4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67 yOwpVy5AUKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmW scQXS8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9eF3O/ QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9/VWp0d5G lVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX679EQq12wg5Qtj rYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9LftPtU9/Qt4q34Yo 39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2G7k/dJVci+iywa284jcn 5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvjit0tsymfp+WzKp1/mmU75EnJs O9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5qN+nnzf01LfR7FuxR1A6l6zjGHesv kkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylfUv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0 Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19VthS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O 0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8 qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W 9x8+zbeHwu9dqDQm+dMgCR1P9CDmGfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/ha R1mCxLPeEgk5GZqWp552p/prvWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb 15H6ZIgaX1G7e3WsZ2dNKe8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9Pzuw wNypM3WC7Kwbhs9+3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1V H0J+VaGqRkNQqD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4 fy/qkdBaCQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6 S9ltRH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CLbCk5 DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspHEARB7Apr T6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASxK6w9sRIEQRDE tkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ7UJswg2+KrilXQXF TtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb2lVQ7LS9uE7vYYdxf7Dq v/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6mPzBYjouP5nPbquSrnexw5g/ gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptWvYqeTrTVLVy91EeTP1hMx+Un89lt VdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTlLbI/nw7WSsXjyYzz2W3NxMq3scOIPzxP o+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZcT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsE CyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQOE7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10E BvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ/s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv 4bhlGMC/kR2S/oAQMx6c8GnYOXkfgE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+U FsQuvUOwIBI177+rPwbIU6q2T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9 z6suAoP9Rfqb45LSE9lhXMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1N f0iMl3DcKgzg38gOSX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QU e2ZhXsrXNILoSSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn 00GHv1H4rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i 9a03ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9MfjAvUE cqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa5ErdT0I7 u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/KWBdwdpf14NQ cla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T6hh6DiqF5yfsBgfT pDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/YjJTPvA/g++TGKJ96EPsI 5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hckJ5IDlYGyYf1ZTjbjy9o96ak eB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4rewwCfmUD9vZQ1GS16/D/vdqppEG3TMe nISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXobyoRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9O t5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKB LVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5 Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MUCxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXL QTkroFBBTeYHIMx+pfS3EEXpKgSOzwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3m ojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XP PVHGkBFC972E8JdwBwadzlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwu UE/X+khKvg0QwsJ2L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/ Xfa/VUN3l7Yafx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y 6/+QcsSxIP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaH JdmHlnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgWpH8l vm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1oKcc+GfhJ Sk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJfURTHuja/N+W5 n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB7fDeePDzR7sDKR9B EMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAIglgJKt9z3g/dvDZI+QiC IIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu87c7XwDlrP3fiUeTZufuYIQeEIPaB Z0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFumHOVrylXi5ntzaZm3YLqfDrM2r2sHZFf ZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18QmsMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URr w3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFiIOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8 y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5gXvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzO YaIfSvwT3dItoP4Ox8tmjIok+gX0zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz 3IdhTJjgcGp6aZFBwfDm+sOtUlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXd IWT83B/MS54TuwYP1UWi5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLo F9A/T1hVddQG9hfpb45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ul qgqvr6T+Y5YIO2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a 5Rv0EUo0pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hP HJcQ0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQizf7K DLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXNYBiBYMlY hEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq+oH9I5TPqh/W VcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9wgFJ1Z+jv6hdJP9T D8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvDcOoefwVrYcX4R1X0A/tH KJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenpG/ep4zLSo97OY/qEA5KqP0d/ UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+cnzz/ZPYGJ75Ll9P+XyJTipSVRHd FilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy 7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRFDHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7 zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOiyekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs 4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+Pe16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgO YbMKp+w1MHHSEjuFflnyS/DogKXRiVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmd LBUxriYcR4892KGXNB8VNPtU7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y 87TNmxDcETeO+27cWfOFfDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHre kEdI7FTLZ+mv1q5ePx/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE 94rwzKqUZ8/mok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+H k5Y+SC/Y6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+G qGK7kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86vpb8 GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6cu3wAgHoo +NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYArkTphRUAcB7e LzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHAp Si+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/zZ9On77XHrvmru1fzBWPy /eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso88Pf82fTpe+2xa/5+Pqr5gjH5 /vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJMyPfq7sy/6ZvR4Xl1d9EPljz2sA6T vsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a35hqXMzjpvsqra07tdiH7r2V8T11F388H 82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf 5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5EN V7O5upuLhnwurjCOnDMX0cjtHdrRE30/H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy 4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yI O7aUblbXUW6XnaDFLf0cH/NFLq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1 Ln79p/Q25YaBXr8yLmr9ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU 5cjQxpsQ8b6ImHA1Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yR y2vu/kUY+h/adhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5h Cfmm0mNJ9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKB M7w8/vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6Xbj/a /N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9injz7Y7pS bZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU+lV55PrpzRr+ LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it8QlSRk2zEl12diN8 denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz26V/CK49cvy6PWH9YQxC4 3RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6UFd1w20it8YnSBk1zUp02dmN 8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob1t/1mrRx2ad/Ca88cv26PGL9YQ1B 4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f5QB87rIbQYvDZWf31UmzuuucEiwlB8Zf vcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvb D4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI 9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITg CSO73fDDFUlK0sqN9/5zeE95Qj5B/0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1 M03FiZF9Q57v2+iAogeSACDkAkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM 7HbDD1ckKUkrN977z+E95Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80 FSdGDi15vm+jA4oeSAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3 bLAT9O0MTXOnl9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLe lP7uGBef/jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1P YPRAlsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7ZdqP NI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6qw0/xDEh 33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MUpRdWAAD4eVj+ I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtR emEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0EpezitXfIFa9acdhx8O+xL6AnH Jfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zBmjWnHQffDvsSesJxiaHN9wLP sd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNfR9tDbe3qH4jP8+F4owev7n69ewsV 9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT/thUvk9QlfqY1QftJn1xOVe/avvY19H2 UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd4 9ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGOdvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pv ZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+T kTR5jHZV1nqanoR8opz+fvEGmslnMuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe 4AQ7YXXQjoaddo9vbD9T7l6/SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLo wak3TR6pXVNKNsDkCufvlcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4 DnMykiaP0a7KWk87kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9ol l8wDnGAnrA7a0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RB TxQ9OPWmySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto 5hd/lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiGtTEB bXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PFeoaWhT1C WBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2SvbnnhdANS06n /YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJjdjt4iDki9IqeR3U s9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXTHX+tHisT2BfykfLkQn9/ FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz90GeF77fK5kMa2MC2wl1qxtK bhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDgiOsJjzEBRf34x0Ujjz3Q0CXt2Z8j 7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNiPvcIJppm5077GSsiz6XxC44M+dz6dCHr wau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9NnhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uv Xd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ff Cvn8iTlySHOTqp//3gj50uTJEfJZcrr7RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl +furhnxizGXWL99icM2L9dxBId/72T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdO kFQ/dRpIo3NzsYugXWDII/dLhjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiW dyV2yvXwIWVpnpYdyi2/uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedla uzuPCwX5g6e3BH26UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI /ZJhTiXJjbLkdPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/n Y3ncM0X+TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev 3rLJEzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO4KF7 +yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZDHmteeH+v BPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zcRkVOb7+CzKrw lvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQjeOje/or28ze0j+cz 4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68esshjzUvvL9XH3H8p9grJ23X CPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/59ZDvdcUPWB9G1pQu8OUg5APV UnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOgEkovrFVBcoQQwgDgR/xyGgBfx2+G fAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAA qIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQA7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI9 4ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5Jp Wz9ZWzqogRr19tt2tfIbevDOo/kFwAiGv5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yl n5y8uuYjD1cZlyr19ut2ZTV+RT3smkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p 68t72SQt4xxv6Scn72f7kYerjEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F5 0lk+l6hIAtyGfrLyacinUKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYok wG3oJyufhnwKNert5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdN fPM9vu8vJlxNWVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32 NORzjqOSCKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/B HL5yks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf04JlH RHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0+S05l8d+ /v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69EkWfxvjuAHa1 HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9n92AVjO9ZFdMkOdP kd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJpcy9RVGH6OMq7Ip69EkWf xvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye2Lm6EeQW9cQnPpfu2osuKXWP NtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDvOGYI+UR9WuPrB3alt6ud+Xo97CI9 5NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lcop74xOfSXXvRJaXu0YZbY8qppjeKLim7 0b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+oT2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9T MVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6ja hPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+cku X5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+Tz XCqhUlMmoXjoEgnyW3K6XFKWLsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6sym RF+uh50kh3zG/JV/P9UGlQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ 8ltyulxSli7J9laCJ5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyV fz/VBpUCTv2PxbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+ Vc6Ut0iwE/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2k Hpxo9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3KyL6 tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1Aj38Ngd9 jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/hHwAAAA4LE/z lMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei 9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+LfL/7G+sHAABQO6UX1pE3 +X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+2ff9fMQx2gcfg7r6l4MBAABk onzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYnIdn8tV9Wln0CODjrrB8AAMDvccrq ObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xsenU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4 Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM+cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06y Bbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbGkG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNe uvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWP e4O7XwYDAADgsuR9fQt/9co9fE3L7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1 Lbfb7dY+58ftove00MBsPUkDOFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78nUyiDns+ ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnwdzKJOuy5DnKG fLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnDDrOMy7fMU4367Nb3 O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf381G//H9/m3p+P9s6uiHJ ucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQb6S+kfHzYyFfJlm+Y55q1Cfp abMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6WmzHSHfxBkhn7n7FxGWJvlHfdP0S9oT rYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywfXtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbq QU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOtpum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89 T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F 5EJtOUxDe7vdHs9haWW9YGz58XzHCXRrA8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9 EVHVZ9tK4ysw1T2Xmv5kveb1k4TD4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG 1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0 fT+VYMEZa01oTCv/6u5rU6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+ VuunUsYJdGGLNLMv+dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVV e/bqRyuv2bPzd3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7 +Vibej8f8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3J zz7J9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7XWe8v DW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxqv8TCqj17 9aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0iq/7xfOotfKUe pb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz6F9tN888NbdVXXqu y27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+sb9mvbLLpUYiRUK+V9d0 r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv26ietXf72mzwhn8d+ciyOaZwf 8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/kS9werGGX79CQzzdP/SGfXH9tdpsr 5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2EpKag8puadCT5mVx0VkKUUyvPvaA1bc2o Pz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7rmnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNr kId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXnuyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn 5GPPbwjOPPE1vDk+NO8sqFX0M7norIQop1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2v N+R4P5/PZzvu8LEnfpT61xPSlwSExE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1X Z7fmfPeEfHq/JDR79upHLa/as/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IX ARhispwiJn4sp1mentiqP3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8 PhtmTOYINN3W43yG/cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wj ltft2fU76R5fkfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUf vfdgW3Fyu0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJ M9VEM0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUifi0E +rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABAXSDkAwAA cClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXVQS 8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0ell5Ybd5b37mur92h Tfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/V9cU8T2T2u0byZmRj34p pfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/h8fN1NIL6ybvZ1vE90xqd2gl Z0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTnqkev/sCBzfV7WMMvKEI+hHwjCPk+ p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuST mLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hy e/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VU u6WoQeyXftxtP+l2NeWo9kvDtHT6fBln42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23 GTh85Zyyxdo5nYit5coHwdfD7UBDDpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjb Pjb0M17+eL5nkdPalvSwOV5B3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeey fjT5VTnVbilqEPulH3fbT7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u 7Pg9dNvtqWTd5aObBj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0s j2n9+/fvX99bLRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvt av3Sjrvtx2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ50 02Bgjh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd8afJ 1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmftpPC3bXF RyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02raYSfiORtNn5qd kCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Qb5/8YT26/cvzxUYK TPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu/PJ/tV2L7UQm2l+v/FrI xzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQCCf1dhPkT6rH3wOpXa1f2vEd 9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGndnt9Dr92eTZUhny/FR92wKRbyeVOU 1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/kk9u15JdDvjzya+36Q75P7CfBrpQYyjtf doR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJDfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xo rqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvoc fP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43pjbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru 4eNin+RCBlUHqZxUvHi8lHYt+UX9ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb8 8od86b+HbrvNwhmLp+KacO9jcS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7 XDdD/+J4qe1qcia1vG0nwSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7Tj Xvvx2hXNK/xjO7eu+eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7G M4G2XD36doCmmZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63 dBmPi2wn9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7Rwfswt LC9b7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNxke2E XhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3MLy8tWuy2/ Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAuCkI+AMAVQMgH FkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --94eb2c1a17c47224b1055d7da02d-- From nobody Wed Nov 8 12:05:36 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D547129BA8 for ; Wed, 8 Nov 2017 12:05:35 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 SmRKNc5Tnh24 for ; Wed, 8 Nov 2017 12:05:33 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 6DCAD129BA3 for ; Wed, 8 Nov 2017 12:05:32 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id r129so4558487lff.8 for ; Wed, 08 Nov 2017 12:05:32 -0800 (PST) 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=jWiB3QK2FlsIXh4Y3IPp0+eTJ5wj1P8J+sefQ+Qw9cU=; b=n4PcyNx7MWqlezjysxY6565OKrkEH9aeTBnKAP2Oqc/CUBkRtyyEiAPO4fdjy4R4Je LrkwGgA+eijuJop6dT3i0Wx0XcQN1mfbP97eUNAt/KJUpGlMq/60vTcWbb/JtgVHAmSj 48Nohoqcmw8fHip9Yc+q0K8I1yCq1tshyfnjID3zNW8wXOrc5BcQS2kPyYOr/3ZoTAJw jlInoAFqwqJ2bCXWWFn201RkAzGWFnf69w+SHgIN+QuTeHVYBIBYthh0FFl+mQEQRh+U RBlX8zzAo02GIpvBGca0Ae0PF2QxIO5C60dDX7ciX5OIt6wioCbrgyix7erJWhytxIRy Xyig== 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=jWiB3QK2FlsIXh4Y3IPp0+eTJ5wj1P8J+sefQ+Qw9cU=; b=LouCj2f7IAS6qv2vMMIqNeeb4rm572UbsdQ1qZUuUzUqyVICoapoVGZVC2EEcEef50 T/L72UjNn0Y41aKzyv1+fawyMnIMRADdFSj2uPND/u5nhgoh1NtF9qHq8BFJnUWcS1zE a+vdhLOKdVViSzyprYqE7Ggjn7WiSHPLB7s8r75i1h/YBDM2VFsmkPbvNCz9Cr60OS9S HbRV8bYTxgvsUUnsQoFeLHuf8pIQHHAy9ecSo/IRdD8A+Qj9+ZWudHEMl6GihqIIirEA py3EV5hcL++lsNGdPsat7/EJnxNS3MlEs2X9IXYshk1SZANuYB8bUGYMiKR01SHCInC3 IVQQ== X-Gm-Message-State: AJaThX4X2S9+bxHX3j4NLZKmF9RS1nHHhZDcoRhhr9wqJbEW5ScvAcaL 7Ddu25Qr9mQmLfZm/3uVrh4HPMe9HfrJv6iQc/Mpug== X-Google-Smtp-Source: ABhQp+TYi92Pe4PtYeoi+MCi4JtoQ5Pb4Mt8otsRm8r66pVMW/v2QHV2azC0NKRWegbsBGnO6VdK0r9VifhX+gNYNSo= X-Received: by 10.46.117.24 with SMTP id q24mr728412ljc.14.1510171530399; Wed, 08 Nov 2017 12:05:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.214.9 with HTTP; Wed, 8 Nov 2017 12:05:29 -0800 (PST) In-Reply-To: <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> From: Andy Bierman Date: Wed, 8 Nov 2017 12:05:29 -0800 Message-ID: To: Robert Wilton Cc: Benoit Claise , NETCONF , Martin Bjorklund , "sec-ads@ietf.org" Content-Type: multipart/related; boundary="089e082f63e0a1ecf4055d7e35d5" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:05:35 -0000 --089e082f63e0a1ecf4055d7e35d5 Content-Type: multipart/alternative; boundary="089e082f63e0a1ecee055d7e35d4" --089e082f63e0a1ecee055d7e35d4 Content-Type: text/plain; charset="UTF-8" Hi, This change has no impact on the server if /nacm/read-default is "permit". In that case, the extra read rules for /A and /A/B are not needed. An operator worried about read access should set read-default to "deny". In that case, explicit rules to read /A and /A/B would be needed in the new NACM. The deny rules would not be needed. Andy On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton wrote: > Hi, > > I'm not sure about this change. > > I'm not that familiar with NACM, but if you want to give a particular set > of users read/write access to a subtree, but not allow them to have any > other access to the configuration in the running datastore then with the > existing RFC, that could be expressed with a single rule (example in > 6536bis, appendix B.4) > > With this new change, I think that you may need to configure many more > rules to achieve the same thing. I think that you would need to give read > access to the top node in the desired path, and then separate explicit > "deny" rules for every sibling child node walking from the top of the tree > down to the data node that read/write access is actually being given to. > The example below may explain my understanding better: > > E.g. For a tree of data nodes, rooted at A, if we wanted to give > read/write access only to "J" subtree, and no access for the rest of the > tree then: > > A > | > -------------------- > | | | | > B C D E > | > ----------- > | | | | > F G H J > | > ... > > > In the old model, I think that the ACL rules would be 1 rules long > (assuming default deny all): > "read/write 'A/B/J' > > In the new model, I think that the equivalent ACL rules would need to be 8 > rules long (assuming default deny all): > "read/write 'A/B/J' > "read A" > "deny C" > "deny D" > "deny E" > "deny F" > "deny G" > "deny H" > Note, I am assuming that a "path" rule matches for the given path and all > descendant nodes. The draft doesn't seem to be particularly clear on this > point (it states that the rule applies when the path matches, but this > would seem to be counter intuitive), and perhaps it could be clarified. > > If this change is allowed, then the example in appendix B.4 looks like it > would need to be fixed, since the "limited-acl" probably wouldn't give any > access at all, unless default read access had been given. > > But, possibly I'm misunderstanding how this all works! If so, apologies > for the noise :-) > > Thanks, > Rob > > > On 02/11/2017 14:18, Benoit Claise wrote: > > Dear all, > > Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the > Security AD Eric Rescola part of the IESG review, which I would like to > validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf- > netconf-rfc6536bis-08.txt > > > The NETCONF WG was cc'ed for the entire discussion. > What do you think? I will draw the conclusions by Friday Nov 10th. > > Note: If the WG is fine, the next step is to approve this document. > > Regards, Benoit > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > --089e082f63e0a1ecee055d7e35d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This change has no impact on the se= rver if /nacm/read-default is "permit".
In that case, t= he extra read rules for /A and /A/B are not needed.
An operator w= orried about read access should set read-default to "deny".
=
In that case, explicit rules to read /A and /A/B would be needed
=
in the new NACM.=C2=A0 The deny rules would not be needed.
<= br>

Andy

=
On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilto= n <rwilton@cisco.com> wrote:
=20 =20 =20

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I think that you would ne= ed to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for th= e rest of the tree then:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0=C2=A0 | =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0 D=C2=A0=C2=A0=C2=A0=C2=A0 E
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 -----------
=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |
=C2=A0=C2=A0 F=C2=A0=C2=A0 G=C2=A0 H=C2=A0 J
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'
=C2=A0=C2=A0 "read A"
=C2=A0=C2=A0 "deny C"
=C2=A0=C2=A0 "deny D"
=C2=A0=C2=A0 "deny E"
=C2=A0=C2=A0 "deny F"
=C2=A0=C2=A0 "deny G"
=C2=A0=C2=A0 "deny H"

Note, I am assuming that a "path" rule matches for the given = path and all descendant nodes.=C2=A0 The draft doesn't seem to be partic= ularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" proba= bly wouldn't give any access at all, unless default read access had bee= n given.

But, possibly I'm misunderstanding how this all works!=C2=A0 If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:1= 8, Benoit Claise wrote:
=20 Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt

3D""
The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.
Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


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


--089e082f63e0a1ecee055d7e35d4-- --089e082f63e0a1ecf4055d7e35d5 Content-Type: image/png; name="dfpcfioondggippe.png" Content-Disposition: inline; filename="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a85fc09ca1ef0005_0.1.1 iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC+YHG lxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL54BA95Wp YrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIgiN2ClI8gCIIg CIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU1budlnGWW9Ei1mf4 5fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluGnFMMK91+zhv/yNjzT4Gd o4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pdbo6buif+9eeWtPnXv6CR/FPY c+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJXx1+/P6TX1qbAn3/+DWvTKfuX9bC2 S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi67wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4j lgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNXud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllF nBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Ygfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvS S/v9L9HPMFFl8D5zbEGSizUDcgokCKIH5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrf X8TtVh6W9yB1MxV/iBt3fOpwlw7vXD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbf wKXq6se7Lj//Sj6DlcJB+9FIFUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60I yDIBZ0CCIHpwvuN8FzTL+Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omkn OhYrqi1hzNqj2od3bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyr z1EzN0EQxL8430WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt 4qmnrDDAnL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB +Y7zXTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUjYtyT WcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35KV73CFvr JiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX7+JJ7+0z04ZX /O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz+95YmLPx+1/yMeRf 4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV08idquf+lP/67/LhW/5k2 PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE7PAZOI49IrPfJ0V5TphipXuR ygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWRMVfPIN/X+Z9//k1OMc9Qy8DwPJQg CGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/hE8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53 d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggb pHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIRBEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQp H0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjN a2EZnE+HzC6sB2G8LZmOIAhioxiZ9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZk OoIgiJdH8fl5IxV3NnE+HcYZUFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw 81P7SxDEnpCa9NqqZxOX+jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw 81P7SxDEeyJK7IQUQ1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEq yJ0AIcWQVSRJCimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hC FmMqFlg1urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1E u5mmD0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL3CW0 ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YIWu/yWetq 1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/UNHcDNc3Zrp5a 5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeIo4gGND27y1MLZvIP uQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t8ln99duTIAhigLHKlxsi uxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl1nzKp+Ujaq04WI5YRfkC1crm E9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rrP8E3YwZKFrZvMInH3uVDHQxlDPXk 0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+WbZk+CIIgB8SYNeZRMve/lwsyUD6sDyNKb UD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPmUTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GD yXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7eC4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht 0n0cLKoF63cIZ6B86kCoJV4MtQTbn29pSiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJs QL28FwT1Rv1Afhi4+9NJTcTLV2ChS5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/S VkpCT7lSubom5cNqpuw8ws0z7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PB d/P0Ke6NCIUUa39CuSOi3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3Ps SRDEmyA97eGP8seULP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LP tyT0FMNYVceBkbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIl sPbESiyLJ6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST 9xEEsW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhi V1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAI giC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkI giCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUn VoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG3h+ZSvKYui KJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G0ZRFhxXNtdqM2lZFUVTtau0TPnC8 HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5tc2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoO p7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7 A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZxXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJW VXs7IOu11QsEyzPgUh9ze4nHa46R3CIe6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62 nqaX+mg3/dTr4hHMSfnKjo/d5vwhtJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+f pHwuZFGRuUDKNyb71Sjf+XTwrYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43P BYfEc+bhIX1bHY99vUt9FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6 hTkZi4gcoIxJ/r5KdxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebh dA4T6GBCXa/m4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjP qJ5hsH0/4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+e ccfXV9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eTq8ry NyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIgBcgOwM5j qseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCoyc3Yg+mb4O4s GQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqMnJpG051AgFBBv6gE xusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3q5PsRvuI/RbYTUoUbUXO pNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D951McnPo+4BKT5w0x 1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82v7StiIFUJKP+OPY80jwO+yt+UI+4 0fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olSQvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z 0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yLHfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFp BHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78 FtkNU75gaTX4E61wKzuM2tmCZZ/UuHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTG k+dNAYvyWaGheKR9x8jsrpcP9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fB AkNsw2smbXDqadsT6e/2E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/R Creyw6idLVj2SY27R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFw amQEojxnRP5NzPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9 mpPy9d3P6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRi RVxI/k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+uOW8I KOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnSrUTWXMqX Wtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUUegQn2iG9uptB m9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6FDqO+qs6IE5Gx1Nw UD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M6AmCbeO7RgDYb4Hd5Nu6 hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk97vNQvuSNAC+Gzo5ZKZ9OTQry nvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBfGylLFahJ+UH0Zh23+2uaLXF8XE11 AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQNqCb83Eja0uWpe70K2XlKv5BfWXomxrf/ PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOIxz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77 z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUvw+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8 IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGbxBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq7 16uQnaf0C/mVpWdifPvfcykJaBfZTVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7Y ITnuLn92jTu+voCjO+8/14Ve4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbED LLqLxPU6LdOReHOsd/8h5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/ kPK9M0TOFZf4dgaVT7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRB ELvCWhMqQRAEQWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wE QRAEsS2Q8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88d wDXub41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW38x2 fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4DkUh+3EeYm NiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tbPMbXnzDyl7pa wky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz9XdGymcJIeWbqAkp 33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+eiIWmT3b6hYgXerjNmb1 Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7Nz4XHBL0eFjcbqvjsa93qY/i r01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP6o2fLGoR1b5nb5bdL7JfsL/QPPl6 Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3v gm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidwxhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0ted YYCyOZ860qfavR8efv1MPrY6deeeT4fhj6dikdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+ dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmr qm2tcbHGEfVXtdE55O0nLD/dqWw9TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmW u1+zwvRD+z5g2WfCdQSvCyE+5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplTh r0U6PiVrUrFWQKbOIiL/bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0Zvd bmpcXMB2MPVH+vR5tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbak Qfl8/ZoZNgW1/AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8 tUjHVbImFWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3 mxoXF7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDyhWFP P+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+SH88jjn1 pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb9vSBZ07p6y6C Hkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMFrWEA64FfzwTlg3GT RfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3COMoGosroOhq4wmTK5+rX 3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNYl/KZsWIyprFDWBiZb4nyTdFz JsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxhT/N6eTApN9O9HqV83n7NDQfl03VG Vvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUbUz4zVkzGNHYICyPzLVG+KXrORPlAR72U b54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xpXi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/Z KN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq /Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3ta Erw5ucqeS1I+Z7/6mvN8LTib8iXs47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6 FpAReGEmQaWSjkZCWPUFAf1b+NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2K pT/SB1EyOI6gv1ChKZTPpWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj 1/9mue6ME2Rv+6+uwHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/t q5eN+r8fTj1z9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpL WR76wBzKz+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJ ZI1fR/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq2NHW xxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNoN4LORLQu u+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p9mZm2J3hb33R 9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa2NpX2YmpMD7q8ap4 5F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOrAVK+veCRz3duC3He4lrg Zn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4jiHUgUt5WD6FV0h+vDYJ4LtZc 5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7 wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUWvu+o0H3scW/feUT9erf+EhOwwesUYXzc z3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3/hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+d tuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPH zmx467Q1N1UD2x0+dce5JfqLtnFcY3vHNfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xS vgfwUpTvyW2S8s3fxktTvlVAyrccZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVson dpEOogG513UpQgVwfNinPRA0/KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZ rSlFc+IXdFzaKDsB0m3ntPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0Y VjPtgBP/oD3LMryOgvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8 IR9LTJ5iF+kgGpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO2 0jalZdmtrURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y 4z56XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK4E7H 1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6ZcpB/sPGHdg h8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f9egZnpEL+xGV fV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17ZtxU9RyCVU0C8GtZUM 7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k9Hf1F/t50j6efplysP+A cb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6OUD6Z+Zj9Lp/tz+77qkfP8Ixc 2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkYZOgwRodKKCRyUj7TbhHt6YSi40B/ 3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19QDuhvYtyBsnhcPJQP91deO+o6msUP8XU6 rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1FnzDv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPy MMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtDWP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ 38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1 n/JlPsY2q2V+DWAy5ZMhyDyUD9kNKjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJ lE/VnuqH6Dqd2i9DtfJ0Pp9Ot5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2 g4qMxNL5lO8RO4eyH6d80A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu5 7E/dHuXzXu+kfE7olCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6X z855fRi6oBscXeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8u P4SUb1q/YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzd fkLHjaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8c93f 4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+rqY6Ifr+ gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTLRqbdFHNH0p39 BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9cfk5KGw3lXd5Gnud L+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0dH1dTnRB9f8BS/1hVfd7W UKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+2ci0m2LuSLqzv8DPzfrufqF2 kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yhPy4/B4XtpvIu67HX+RL+7L3enXr6 7AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnzvfD8p849trQrwR7wbnZ7t/4SxASQ8vmQ mTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/ezW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Bu dnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLEr rD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARB ENsCKV8Gug928tuHxGxoygW//7o1nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Gi w1v7yRLYCeVrShgUzbaTHrc5Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqK ta7TGGtPrM9FW8GgaLad9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go 1rpOH8H+Kd+MbWwntHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hp MuSQ8j1R/lPkPBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/Hh FJyQKfdWL2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9V Lsvul7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fghEy5 t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5rXJVdb+M xaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI7eMZFy9GKJ/l Jzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18OgxCz6eDmUB1Ph3G KZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfpGYx1TtButgvlO+V8NmVh 6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJdgZ/0vyaO5FzXqD7qL7x/rned xnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9THQeilPpoJVJf6OE753HraAHKQnuh4 G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw1jlBu9kulO+Uc22rwtInZTeXfKd/ijpq SBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZR Ux8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fyoUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8 bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgoX9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8 fa3rNMZTZ8079IPeHMqn6vTxQkIOSAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIc x4Q+oBPYnp7xhXqqMY3H15YdV8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGP yxRYlM93X/Jd16g+6m/K39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+ MI4JgXZIDe35XpTPv65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+c mRrEAEk5G6J8U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM87 7nn3Ge3P81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR 45DFr6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wqp/S2 ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKHYByTuW8j IXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo2yfRwdua2Bzs 5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISNPh8SfU9AJaSZcvrD 8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuXjfp/7tjI8NS2g09OJ0O5 WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+OcUzYJzEuc1A+swPQT6D/e69r XB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBBCBt9PiT6noBKSDPl9Ifl5yugnCl6 Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZV69a9f80jHahHXxyOhnKxWLPKvK+FGLp 6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06 fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRq gFRhH+A47g/eV8AI4kWxGuVz7GxGbBgcxx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5 ykcQBEEQs2PtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3 /c3UF7JnGmL/8D10Z6dYdhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N3 3h7PW+U7n8pFI9B4J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9J L3W1aAQa7yT29P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRD IOWbV84WrebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAml jKXkntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xOhWf4 /RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9ofsfbgeP 9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMqBdXN8cLH3fZ3 jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nwDL/fIsR2TtoHyrf9 E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatwKuKC91+bRtOsiPIVOpbu TnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7ouNv+3nH5dPtJp4J+4QzY+ROP i09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzUfSY8beSo+cuI/BgvdH1tHs+fOmVm k3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQ rq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fAzlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9u OW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aC PhgysB3C6zDc7VW+/dDFvfClINTCeLu+fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om 6mnbE/ktPA76pY/l5Vlb/YL+7JQzwW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx 4GCCCiV+TIXy97+rdoI+GDKwHcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gk Gr/GfqJtrENky87xOVP1tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRF KF/msgxYDUu2YjWIDvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy 5ZPUzk35XHoie0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd 6ENAnz4YTsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBa cduundzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgXp56J ZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586VVAcJFyZ 8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6lZNDB8QIZfB4 oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQn5Hd0JosvM+EzYwc NX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2IosufLA6nk/ndCbc+BrraZSPk WblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ0MKhLA994AztbI2LW09oz6aU fqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyMXNfjuFu+vl4DS0yeKj+oFrRGZyyp d2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5aIc/KVVNMwXzfJsukoZZWu95+2fXHdSmO VXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328R sJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaCeEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKy XrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQxYAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5 IOUjJoCUjyDk9marL/F1moTfIrGPQ6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1z Ibd9COJ6vZLyEQRBEDvD2hMrQRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2 QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH 7bA+xI7aa5trY+g+XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jp xgeQWAU7oXyJzce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9 sT4Xic3HtrDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8 Mc6ng281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b5bLs flGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl01jjgvRP 43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusOuwlZ+T6y1/vY +2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5VrqruFxV7DfWrKidy NOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1rTUuSP80bmflyAF2MP0q ZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6wm5CV7yN7vY8RMeakfE2pgzsV LfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anWORoVSJpVIFB9qaVIxMP2gcdt/T+B 3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYHJ9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4Sp zBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73 iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJh zgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTLiwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a 9d12645kUr7d3scICzNSvjBc6ZdFwmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7 YLsh/cM/cJ/v4i37hxLGY0akvzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZ cRUbiXG3OpfyW9s/7fp+u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VR FF2RDec8NQf1MeWz7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj 2yIT/BNoY/+i5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583 Z6jk/YqCrA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7 x/OnzkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU0u/s 6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQWkrfEh/TM XR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12s5pP9muf97Fe 7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUzKB+sP/ygcsQS9gHH gf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA8OaXRfXH/RNqA35JXUh4 MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xdd0p84CD4YfRrFEVRHMpSB+7D b8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7APsj+QV7qKf063/3tuEHPqKp69WoM sZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5/6EsdaKsgwwA/0z4oX1/wHaD9R12S48X 6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIriWFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqL b5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fjBj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jO EHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD+/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6Q fXZit+wlPmIFPJD4txP/zMa79felseKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/K x63Gtgzvq6kS+/DPfLxbf18aK86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN 5aO9aB/2Crmt3eQlvvca23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQq H0EQBEEshrUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV 1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIg iG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI +QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaF tSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8STcD4dbk7ZlEVR HE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9H9SfIJ6ES328OWVb FUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrSqmwfnRdIT5/+CIkenE8H hnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte4s63Lywwd3YRixn4XOqjIxBq K6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTUdq0+b9X/L3WVo9Y894fr1WbDS9z5 3hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfDoktEE9udjx4tgEzKN9+yJSnfHFhuCrUf 4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZs yrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3l e85g0yskpaTG8XA6h3Y17eAdF6Bnl+VYWv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717 IczfSMrnu2/Y/iYS1O+/B5YL7p8J/yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH 7YpTqupmj0S/zIQu2dGw087+iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4 AD27LMfK8k+AHPlZdutXyNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw /0z4JzEHXmyVT1IBQUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH 1V10HKApdWSsWJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S 3Kz6hJCMVL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T 1iy1unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQXo3xW qCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT1gd0wraD 1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5gL/NQ/mIFJab QpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBMvPKUjGzT6xFH11Wb 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4VDHf/xCPVrkn5gL/N Q/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGvcyQon8m5kvoYnUB2sNrW5y1O +ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK51sGSdf3UD675pyU735QxYX+/hZm hOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTpXzWZi/LNm0r46Crfkz/2maB8vvsG9jdS vi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2vVMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOo DL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCAPl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgE Y899A/vb8Iu184xN+bB/EhaWm0LnoXzq/TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/ pVzVKNITHUftKsXFyeh4jqIy9Jb5vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgd b+T6Ndf9VKLvqHrqNiMTjD33Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9 +sN2ZRKY6m7cr9F3coxI09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx 9JQ+Gfrn2LBoSX67JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmb mmUHwz+JFBaYO/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0Bfp CY7b7eqMNxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhl k8Il9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+z3oS uwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiC IIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhYWFhcZXVuw2IW 7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GWaIGU7+nl8uNLURRV /b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp0mVBPduPpzrq6tyG5b// qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+u3iltV/F3s9rm/Qlys3+S4z4 qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTgp1/1l6eF5vXHLe6//PiyKF+C7f6q vzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodK W31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9 ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5OSfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198 iy2TFgY3X5agQKR8fj29hZTvtQop3zLliSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjc fFmCApHy+fX0FlK+vZYlWliF8tXDRqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJE Tp04iH6KQ/NYzy5b8qNTKSeG/vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4Cf ADm2PpP8QZji46P68uOiEgjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61z rxfndX3PKvxW/XGvrzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt +kP8hI6jgvQx+ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0o imN9uv1nOOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/E uKBijlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b11Zf i6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QGllJXIvZt P1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkrxiof1BONC7QD HC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jnNL8FLmGv8hWu68Vz XXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef1VBH6PbvfxwHfdDxBN+z 2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7VYXU/etq139fr9/b9nbwe3sZ 2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGBdoDjhTQ3/SQlB+jj8odL/dtgWz0W Q1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpXuK4Xz3UtfKLPmW6/tzePFFeCNOil/S7I rnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDIqT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvV FAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5dfnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZP Kkp2fVYkpnxYTzQuCTuA8UKaW36SlAP08fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjE WGJnzvVi98sud34iKVBHVP7oD96ZUjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF /bXtM0L5/tDrnOP23Drl+17p2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHl eNtN2wcXFaDnjFoYOWE90bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6Ge E/0WuMRYYmfO9WL3yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb 4bqSbxh3/x8ffcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/Klxgto DvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8Z GyTfIjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevowLkVO TMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4g/6G568f x67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6dYAmZkknV2j8K ldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KAYcZvK/VmSh/GpciJ SfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/TD9JyoGUz+EPOpo91cc+ Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQcdjuPJTPeHE28oP2q722aCVG RqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5VX34VVdffohfgvB6wPCOkFrW7eWI b2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3GWs9eY8GfbzHHEY5LhvxovKyC/ATISerj 8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7vtL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87r esjG/Naq/3c0podJwwIq1avyx7ejPGX4bImWA47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo /Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V /71GSMnxtmvaZ6z17DUW/PkWcxzhuGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVR VN/61+Sc/u+0v9dvsZ4Jv73Uv/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVV j77O9706fhOBl/39oqFdU09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4 rEP5cCi/3AYGb138+/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz 1rVyWbHtfe6XAsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ5 5avXWZZoYSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhY WFhepazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVgYWFh eZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv/ShytvOe p/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+LXK27Z6nnMQ+ 2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/HSVTw8vdv45Tv57fq 5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnwuphdzrPL3Hpuxg/bD7tf 6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyParl1rYcjLtWo2H2g/In6tk6TlD 6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdGy3qU78GyGOWbWkj55pU/V1mO8n3c IvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76d1K+efWcofR+0Y3CsFO8f1xYsstm/JCU b137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+Kojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H //jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrjfljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yo Hegpjs+fDThC+VLj8sh1MaOcX/WXm5Dbf4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrP uCjDbz2UL243sNX9z7RWWJ/OkkVRfHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3Ww swyXhpWUr22XY9lWRZc5eZfTx9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLa r1XbtyBiLHHKUDkhB5ZB/aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJu l8uxPkXXDbLb4OlV2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+r arj/gePwukD+4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t8 0fGf3wRd/GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsY Ub9D5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+4/er JeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2PCpykxVu GIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE7ddOH6incoT2 a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYLxAnOJjVytIv9EBfT D4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0fLZuifGKVIFi9iUu8UCYp X///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739Uf//Pw4mdMtTWD9plqOSgfP0q 1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZAjutiZjmh9RJ20/a//PhyfIjy5bab 8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue6HjiukD+4/arJeyfVxajfFFcI5ba7rjF IDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cROGWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTd hFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5Jt dSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUo X/0hwrJf9RcZKs1B+bzyU/Whb8xC+Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/q jx+XXz/q+lf98eMSVsvWx0/5Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v /FR91PQ8lG+ZTzvOQPl03yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq 2fr4KV/m8i8Yjhy/WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2eh Qxc0Nb2/EzgWQqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TP dV3MLMegXtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrU R38T9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4Gu611 zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtBu5dvdf2t qk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH849uxkJTpH4Ms 8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK727EVv1b1/9Q3G758 VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtVitxdHzgu81wXz5MjBgXY LbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z6RMOvewXOG7bGfmP06+ebX9f eT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plwu2PhGP58i8odFe8lGvqMGHA4SbHd sOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI3 6VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0ycc ev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8ZcoqxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4ur LLUZBgvLUwop34uU1Q3OwuIppHwsL1BI+dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQ cbfMB3JYWKaWLVO+IQ9pv5scr90+C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30W FhaW9ymkfC9SVjc4CwsLy84KKd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnP p8MrqUu8JF7vung9rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF 62H79/k1V/maEoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix 6+L1sIqB155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqT RvBi18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlDs3r9 AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvOWA5WsXef RtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjfm9VuF1F/8ZVN n1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/Vd0nepHoeF8v6KLc tjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV1fZNi5g+IaeqjPojuuZ0 SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68fYj/XwroGkHwsx+//c6Ebi7sL DZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ7Onyw6T/GP6J9fTYH9oN62/dGpPd s+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+zYhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8 y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9UpkvOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos 5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7 Qf21T46uVKP7/FP9donJUwRPl/ooI9IhernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9Vo lU/GouFZNvXC9Q1N21YEfbnrREa7WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQnd wPgqsZCD2nX6+QRcTMLUVpqgxY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/45 03UH7Qb11z45ulKN7vPP99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDI bsqRdeL6MfQC0QOUD8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+t u1Itf9xH9G/K4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67 yOwpVy5AUKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmW scQXS8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9eF3O/ QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9/VWp0d5G lVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX679EQq12wg5Qtj rYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9LftPtU9/Qt4q34Yo 39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2G7k/dJVci+iywa284jcn 5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvjit0tsymfp+WzKp1/mmU75EnJs O9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5qN+nnzf01LfR7FuxR1A6l6zjGHesv kkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylfUv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0 Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19VthS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O 0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8 qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W 9x8+zbeHwu9dqDQm+dMgCR1P9CDmGfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/ha R1mCxLPeEgk5GZqWp552p/prvWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb 15H6ZIgaX1G7e3WsZ2dNKe8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9Pzuw wNypM3WC7Kwbhs9+3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1V H0J+VaGqRkNQqD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4 fy/qkdBaCQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6 S9ltRH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CLbCk5 DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspHEARB7Apr T6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASxK6w9sRIEQRDE tkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ7UJswg2+KrilXQXF TtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb2lVQ7LS9uE7vYYdxf7Dq v/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6mPzBYjouP5nPbquSrnexw5g/ gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptWvYqeTrTVLVy91EeTP1hMx+Un89lt VdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTlLbI/nw7WSsXjyYzz2W3NxMq3scOIPzxP o+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZcT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsE CyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQOE7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10E BvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ/s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv 4bhlGMC/kR2S/oAQMx6c8GnYOXkfgE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+U FsQuvUOwIBI177+rPwbIU6q2T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9 z6suAoP9Rfqb45LSE9lhXMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1N f0iMl3DcKgzg38gOSX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QU e2ZhXsrXNILoSSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn 00GHv1H4rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i 9a03ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9MfjAvUE cqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa5ErdT0I7 u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/KWBdwdpf14NQ cla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T6hh6DiqF5yfsBgfT pDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/YjJTPvA/g++TGKJ96EPsI 5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hckJ5IDlYGyYf1ZTjbjy9o96ak eB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4rewwCfmUD9vZQ1GS16/D/vdqppEG3TMe nISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXobyoRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9O t5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKB LVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5 Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MUCxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXL QTkroFBBTeYHIMx+pfS3EEXpKgSOzwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3m ojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XP PVHGkBFC972E8JdwBwadzlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwu UE/X+khKvg0QwsJ2L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/ Xfa/VUN3l7Yafx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y 6/+QcsSxIP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaH JdmHlnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgWpH8l vm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1oKcc+GfhJ Sk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJfURTHuja/N+W5 n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB7fDeePDzR7sDKR9B EMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAIglgJKt9z3g/dvDZI+QiC IIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu87c7XwDlrP3fiUeTZufuYIQeEIPaB Z0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFumHOVrylXi5ntzaZm3YLqfDrM2r2sHZFf ZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18QmsMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URr w3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFiIOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8 y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5gXvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzO YaIfSvwT3dItoP4Ox8tmjIok+gX0zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz 3IdhTJjgcGp6aZFBwfDm+sOtUlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXd IWT83B/MS54TuwYP1UWi5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLo F9A/T1hVddQG9hfpb45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ul qgqvr6T+Y5YIO2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a 5Rv0EUo0pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hP HJcQ0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQizf7K DLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXNYBiBYMlY hEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq+oH9I5TPqh/W VcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9wgFJ1Z+jv6hdJP9T D8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvDcOoefwVrYcX4R1X0A/tH KJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenpG/ep4zLSo97OY/qEA5KqP0d/ UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+cnzz/ZPYGJ75Ll9P+XyJTipSVRHd FilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy 7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRFDHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7 zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOiyekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs 4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+Pe16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgO YbMKp+w1MHHSEjuFflnyS/DogKXRiVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmd LBUxriYcR4892KGXNB8VNPtU7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y 87TNmxDcETeO+27cWfOFfDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHre kEdI7FTLZ+mv1q5ePx/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE 94rwzKqUZ8/mok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+H k5Y+SC/Y6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+G qGK7kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86vpb8 GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6cu3wAgHoo +NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYArkTphRUAcB7e LzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHAp Si+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/zZ9On77XHrvmru1fzBWPy /eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso88Pf82fTpe+2xa/5+Pqr5gjH5 /vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJMyPfq7sy/6ZvR4Xl1d9EPljz2sA6T vsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a35hqXMzjpvsqra07tdiH7r2V8T11F388H 82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf 5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5EN V7O5upuLhnwurjCOnDMX0cjtHdrRE30/H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy 4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yI O7aUblbXUW6XnaDFLf0cH/NFLq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1 Ln79p/Q25YaBXr8yLmr9ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU 5cjQxpsQ8b6ImHA1Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yR y2vu/kUY+h/adhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5h Cfmm0mNJ9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKB M7w8/vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6Xbj/a /N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9injz7Y7pS bZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU+lV55PrpzRr+ LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it8QlSRk2zEl12diN8 denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz26V/CK49cvy6PWH9YQxC4 3RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6UFd1w20it8YnSBk1zUp02dmN 8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob1t/1mrRx2ad/Ca88cv26PGL9YQ1B 4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f5QB87rIbQYvDZWf31UmzuuucEiwlB8Zf vcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvb D4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI 9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITg CSO73fDDFUlK0sqN9/5zeE95Qj5B/0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1 M03FiZF9Q57v2+iAogeSACDkAkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM 7HbDD1ckKUkrN977z+E95Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80 FSdGDi15vm+jA4oeSAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3 bLAT9O0MTXOnl9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLe lP7uGBef/jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1P YPRAlsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7ZdqP NI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6qw0/xDEh 33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MUpRdWAAD4eVj+ I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtR emEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0EpezitXfIFa9acdhx8O+xL6AnH Jfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zBmjWnHQffDvsSesJxiaHN9wLP sd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNfR9tDbe3qH4jP8+F4owev7n69ewsV 9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT/thUvk9QlfqY1QftJn1xOVe/avvY19H2 UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd4 9ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGOdvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pv ZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+T kTR5jHZV1nqanoR8opz+fvEGmslnMuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe 4AQ7YXXQjoaddo9vbD9T7l6/SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLo wak3TR6pXVNKNsDkCufvlcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4 DnMykiaP0a7KWk87kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9ol l8wDnGAnrA7a0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RB TxQ9OPWmySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto 5hd/lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiGtTEB bXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PFeoaWhT1C WBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2SvbnnhdANS06n /YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJjdjt4iDki9IqeR3U s9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXTHX+tHisT2BfykfLkQn9/ FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz90GeF77fK5kMa2MC2wl1qxtK bhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDgiOsJjzEBRf34x0Ujjz3Q0CXt2Z8j 7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNiPvcIJppm5077GSsiz6XxC44M+dz6dCHr wau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9NnhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uv Xd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ff Cvn8iTlySHOTqp//3gj50uTJEfJZcrr7RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl +furhnxizGXWL99icM2L9dxBId/72T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdO kFQ/dRpIo3NzsYugXWDII/dLhjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiW dyV2yvXwIWVpnpYdyi2/uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedla uzuPCwX5g6e3BH26UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI /ZJhTiXJjbLkdPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/n Y3ncM0X+TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev 3rLJEzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO4KF7 +yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZDHmteeH+v BPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zcRkVOb7+CzKrw lvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQjeOje/or28ze0j+cz 4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68esshjzUvvL9XH3H8p9grJ23X CPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/59ZDvdcUPWB9G1pQu8OUg5APV UnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOgEkovrFVBcoQQwgDgR/xyGgBfx2+G fAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAA qIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQA7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI9 4ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5Jp Wz9ZWzqogRr19tt2tfIbevDOo/kFwAiGv5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yl n5y8uuYjD1cZlyr19ut2ZTV+RT3smkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p 68t72SQt4xxv6Scn72f7kYerjEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F5 0lk+l6hIAtyGfrLyacinUKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYok wG3oJyufhnwKNert5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdN fPM9vu8vJlxNWVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32 NORzjqOSCKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/B HL5yks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf04JlH RHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0+S05l8d+ /v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69EkWfxvjuAHa1 HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9n92AVjO9ZFdMkOdP kd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJpcy9RVGH6OMq7Ip69EkWf xvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye2Lm6EeQW9cQnPpfu2osuKXWP NtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDvOGYI+UR9WuPrB3alt6ud+Xo97CI9 5NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lcop74xOfSXXvRJaXu0YZbY8qppjeKLim7 0b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+oT2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9T MVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6ja hPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+cku X5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+Tz XCqhUlMmoXjoEgnyW3K6XFKWLsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6sym RF+uh50kh3zG/JV/P9UGlQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ 8ltyulxSli7J9laCJ5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyV fz/VBpUCTv2PxbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+ Vc6Ut0iwE/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2k Hpxo9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3KyL6 tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1Aj38Ngd9 jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/hHwAAAA4LE/z lMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei 9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+LfL/7G+sHAABQO6UX1pE3 +X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+2ff9fMQx2gcfg7r6l4MBAABk onzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYnIdn8tV9Wln0CODjrrB8AAMDvccrq ObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xsenU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4 Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM+cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06y Bbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbGkG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNe uvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWP e4O7XwYDAADgsuR9fQt/9co9fE3L7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1 Lbfb7dY+58ftove00MBsPUkDOFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78nUyiDns+ ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnwdzKJOuy5DnKG fLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnDDrOMy7fMU4367Nb3 O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf381G//H9/m3p+P9s6uiHJ ucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQb6S+kfHzYyFfJlm+Y55q1Cfp abMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6WmzHSHfxBkhn7n7FxGWJvlHfdP0S9oT rYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywfXtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbq QU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOtpum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89 T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F 5EJtOUxDe7vdHs9haWW9YGz58XzHCXRrA8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9 EVHVZ9tK4ysw1T2Xmv5kveb1k4TD4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG 1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0 fT+VYMEZa01oTCv/6u5rU6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+ VuunUsYJdGGLNLMv+dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVV e/bqRyuv2bPzd3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7 +Vibej8f8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3J zz7J9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7XWe8v DW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxqv8TCqj17 9aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0iq/7xfOotfKUe pb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz6F9tN888NbdVXXqu y27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+sb9mvbLLpUYiRUK+V9d0 r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv26ietXf72mzwhn8d+ciyOaZwf 8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/kS9werGGX79CQzzdP/SGfXH9tdpsr 5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2EpKag8puadCT5mVx0VkKUUyvPvaA1bc2o Pz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7rmnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNr kId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXnuyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn 5GPPbwjOPPE1vDk+NO8sqFX0M7norIQop1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2v N+R4P5/PZzvu8LEnfpT61xPSlwSExE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1X Z7fmfPeEfHq/JDR79upHLa/as/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IX ARhispwiJn4sp1mentiqP3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8 PhtmTOYINN3W43yG/cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wj ltft2fU76R5fkfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUf vfdgW3Fyu0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJ M9VEM0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUifi0E +rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABAXSDkAwAA cClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXVQS 8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0ell5Ybd5b37mur92h Tfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/V9cU8T2T2u0byZmRj34p pfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/h8fN1NIL6ybvZ1vE90xqd2gl Z0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTnqkev/sCBzfV7WMMvKEI+hHwjCPk+ p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuST mLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hy e/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VU u6WoQeyXftxtP+l2NeWo9kvDtHT6fBln42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23 GTh85Zyyxdo5nYit5coHwdfD7UBDDpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjb Pjb0M17+eL5nkdPalvSwOV5B3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeey fjT5VTnVbilqEPulH3fbT7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u 7Pg9dNvtqWTd5aObBj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0s j2n9+/fvX99bLRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvt av3Sjrvtx2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ50 02Bgjh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd8afJ 1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmftpPC3bXF RyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02raYSfiORtNn5qd kCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Qb5/8YT26/cvzxUYK TPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu/PJ/tV2L7UQm2l+v/FrI xzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQCCf1dhPkT6rH3wOpXa1f2vEd 9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGndnt9Dr92eTZUhny/FR92wKRbyeVOU 1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/kk9u15JdDvjzya+36Q75P7CfBrpQYyjtf doR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJDfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xo rqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvoc fP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43pjbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru 4eNin+RCBlUHqZxUvHi8lHYt+UX9ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb8 8od86b+HbrvNwhmLp+KacO9jcS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7 XDdD/+J4qe1qcia1vG0nwSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7Tj Xvvx2hXNK/xjO7eu+eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7G M4G2XD36doCmmZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63 dBmPi2wn9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7Rwfswt LC9b7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNxke2E XhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3MLy8tWuy2/ Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAuCkI+AMAVQMgH FkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --089e082f63e0a1ecf4055d7e35d5-- From nobody Wed Nov 8 13:44:03 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D831279EB for ; Wed, 8 Nov 2017 13:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd0JqOtwqBso for ; Wed, 8 Nov 2017 13:43:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3055C124BFA for ; Wed, 8 Nov 2017 13:43:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSF86605; Wed, 08 Nov 2017 21:43:55 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 21:43:54 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 13:43:43 -0800 From: Alexander Clemm To: Igor Bryskin , Qin Wu , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNYozCctBUDrHqNQFassZLcA0NQKAADd8mAAAN0HoAAEmtIgAALrqJg Date: Wed, 8 Nov 2017 21:43:43 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CB@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@sjceml521-mbx.china.huawei.com>, <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD721@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.213.48.40] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CBsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.5A037A9C.009F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac6f249a67cc060ff4292c9a64136255 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:44:02 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CBsjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, But I don't think we will assess conditions as part of smart filters. IMH= O this should be part of the automation framework. Just to clarify termino= logy, to me an event is some kind of "occurrence" that you are notified of = (such as "threshold has just been crossed", "an update that meets a smart f= ilter has just been observed", "some YANG notification has just been emitte= d", etc), whereas the condition is a "check" that is actively conducted (to= see if the condition holds when the event was observed). Smart filters on= YANG-push updates will provide for many of the events that the automation = framework would utilize, but they may not be the only source, that's all. Best --- Alex From: Igor Bryskin Sent: Wednesday, November 08, 2017 11:12 AM To: Alexander Clemm ; Igor Bryskin ; Qin Wu ; Tianran Zhou ; Xufeng_Liu@jabil.com; netconf@ietf.org Subject: Re: RE: YANG PUSH Based Generalized Network Control Automation Pro= blem Statement Hi Alex, I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server. Igor From:Alexander Clemm To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org, Date:2017-11-08 14:00:25 Subject:RE: YANG PUSH Based Generalized Network Control Automation Problem = Statement Hi, A few additional comments inline, Thanks --- Alex > -----Original Message----- > From: Igor Bryskin > Sent: Wednesday, November 08, 2017 9:00 AM > To: Qin Wu >; Alexander Cle= mm > >; Tianran = Zhou > >; Xufeng Liu >; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Hi Qin, > > Please, see in-line. > > Igor > > -----Original Message----- > From: Qin Wu > Sent: Wednesday, November 08, 2017 10:21 AM > To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Interesting discussion, does smart filter mean that netconf server should= be > stateful since it keep a few state while traditional yang push doesn't re= quire > netconf sever to be stateful, i.e., should be stateless? > > IB>> Yes. For example, an RPC (one of possible generalized actions) outpu= t > could be stored to be used in subsequent ECAs (event-condition-action). T= he > models we have in mind will allow for managing and accessing such state. Yes. Just how much state we want to allow is one of the items that = need to be discussed. I am of the opinion that this should be limited to a= few frequently used scenarios such as threshold crossing alerts and in-ran= ge/out-of-range monitors. By its nature, a threshold monitor _has_ to be s= tateful (it is not sufficient to simply compare the current value of a data= item against the threshold, you also need to know if you already reported = this earlier without clearing the counter threshold in the meantime). This= will be simply part of the feature of the smart filter that is configured = via Netconf/Restconf. However, I don't think the state in those cases shou= ld have to be externally exposed - it is simply part of how the filter cons= truct works. The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you keep track o= f the high water mark for some amount of time after which it is cleared. (= The analogy is that of a graphic equalizer.) With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one. The intent here is not to p= rovide a general programming framework to define any type of events - as me= ntioned earlier, this is not intended as an event+expression MIB or any suc= h thing, just frequently needed filters/categories of events that are fairl= y broadly applicable and useful. Obviously, where the "sweet spot" lies is= subject to discussion. We would love to hear feedback about what other fi= lters are deemed useful. > > > I think set threshold for packet loss or latency is pretty much common in > network trouble shooting, such threshold can be also moved down over > time. > What kind of threshold can be set more depends on empirical experience. I > am wondering how this can be modeled using XPATH statement or some > other mechanism. > > IB>> I let Alex answer this, but I would assume that the smart-filters > IB>> model will allow for comparing a data state pointed by XPath with > IB>> configured threshold value to evaluate trigger condition (and much > IB>> more) We need to figure out the details of the filter construct. In addit= ion to node selection and value/range comparison against a threshold/range = expression (so far, so straightforward), you need to be able to specify a c= omparison against a state, to update the state (e.g. threshold crossing sen= t vs cleared, current high water mark etc), to specify a counter / clear th= reshold, etc. I don't think this can be accomplished with XPATH alone. --- Alex (remainder of message thread deleted) --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CBsjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

But I don’t think we will asses= s conditions as part of smart filters.   IMHO this should be part= of the automation framework.  Just to clarify terminology, to me an event is some kind of “occurrence” that you are notified= of (such as “threshold has just been crossed”, “an updat= e that meets a smart filter has just been observed”, “some YANG= notification has just been emitted”, etc), whereas the condition is = a “check” that is actively conducted (to see if the condition holds when the event w= as observed).  Smart filters on YANG-push updates will provide for man= y of the events that the automation framework would utilize, but they may n= ot be the only source, that’s all. 

 

Best

--- Alex

 

From: Igor Bryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin= <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@huawei.com>; Tianra= n Zhou <zhoutianran@huawei.com>; Xufeng_Liu@jabil.com; netconf@ietf.o= rg
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor

From:Alexander Clemm

To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org,

Date:2017-11-08 14:00:25

Subject:RE: YANG PUSH Based Generalized Network Control Automation Probl= em Statement

 

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.co= m>; Alexander Clemm
> <alexander.clemm@huaw= ei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@j= abil.com>;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CBsjceml521mbxchi_-- From nobody Wed Nov 8 14:53:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D431A126D46 for ; Wed, 8 Nov 2017 14:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn03a7Y1h0pB for ; Wed, 8 Nov 2017 14:53:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BE8126C19 for ; Wed, 8 Nov 2017 14:53:18 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSF90265; Wed, 08 Nov 2017 22:53:15 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 22:53:14 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 14:53:03 -0800 From: Igor Bryskin To: Alexander Clemm , Qin Wu , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AQHTWMV/P1IQx6kSW02L2Q8DtmodTqMLidyA//+GcxA= Date: Wed, 8 Nov 2017 22:53:03 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C19FA14@sjceml521-mbx.china.huawei.com> References: <0C72C38E7EBC34499E8A9E7DD00786391C19E264@sjceml521-mbx.china.huawei.com>, <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD721@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CB@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABD7CB@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.246] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD00786391C19FA14sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5A038ADC.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac6f249a67cc060ff4292c9a64136255 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:53:22 -0000 --_000_0C72C38E7EBC34499E8A9E7DD00786391C19FA14sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, If I understand you correctly, from the automation framework's point of vie= w a smart filter could be a (part of) event of an event-condition-action th= at may or may not trigger an action depending on associated with the event = conditions (which could be, for example. one-time check(s) of data store = node(s) or RPC output(s) against some constant or variable value(s)). I ag= ree. What I meant to say is that events may be explicitly defined, not be = necessarily smart filters, because constant evaluation of smart filters ma= y be too demanding for the server. On the other hand, evaluating smart filt= ers once in an event's context is much simpler proposition. Igor From: Alexander Clemm Sent: Wednesday, November 08, 2017 4:44 PM To: Igor Bryskin; Qin Wu; Tianran Zhou; Xufeng_Liu@jabil.com; netconf@ietf.= org Subject: RE: RE: YANG PUSH Based Generalized Network Control Automation Pro= blem Statement Hi Igor, But I don't think we will assess conditions as part of smart filters. IMH= O this should be part of the automation framework. Just to clarify termino= logy, to me an event is some kind of "occurrence" that you are notified of = (such as "threshold has just been crossed", "an update that meets a smart f= ilter has just been observed", "some YANG notification has just been emitte= d", etc), whereas the condition is a "check" that is actively conducted (to= see if the condition holds when the event was observed). Smart filters on= YANG-push updates will provide for many of the events that the automation = framework would utilize, but they may not be the only source, that's all. Best --- Alex From: Igor Bryskin Sent: Wednesday, November 08, 2017 11:12 AM To: Alexander Clemm ; Igor Bryskin ; Qin Wu ; Tianran Zhou ; Xufeng_Liu@jabil.com; netconf@ietf.org Subject: Re: RE: YANG PUSH Based Generalized Network Control Automation Pro= blem Statement Hi Alex, I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server. Igor From:Alexander Clemm To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org, Date:2017-11-08 14:00:25 Subject:RE: YANG PUSH Based Generalized Network Control Automation Problem = Statement Hi, A few additional comments inline, Thanks --- Alex > -----Original Message----- > From: Igor Bryskin > Sent: Wednesday, November 08, 2017 9:00 AM > To: Qin Wu >; Alexander Cle= mm > >; Tianran = Zhou > >; Xufeng Liu >; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Hi Qin, > > Please, see in-line. > > Igor > > -----Original Message----- > From: Qin Wu > Sent: Wednesday, November 08, 2017 10:21 AM > To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu; > netconf@ietf.org > Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement > > Interesting discussion, does smart filter mean that netconf server should= be > stateful since it keep a few state while traditional yang push doesn't re= quire > netconf sever to be stateful, i.e., should be stateless? > > IB>> Yes. For example, an RPC (one of possible generalized actions) outpu= t > could be stored to be used in subsequent ECAs (event-condition-action). T= he > models we have in mind will allow for managing and accessing such state. Yes. Just how much state we want to allow is one of the items that = need to be discussed. I am of the opinion that this should be limited to a= few frequently used scenarios such as threshold crossing alerts and in-ran= ge/out-of-range monitors. By its nature, a threshold monitor _has_ to be s= tateful (it is not sufficient to simply compare the current value of a data= item against the threshold, you also need to know if you already reported = this earlier without clearing the counter threshold in the meantime). This= will be simply part of the feature of the smart filter that is configured = via Netconf/Restconf. However, I don't think the state in those cases shou= ld have to be externally exposed - it is simply part of how the filter cons= truct works. The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you keep track o= f the high water mark for some amount of time after which it is cleared. (= The analogy is that of a graphic equalizer.) With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one. The intent here is not to p= rovide a general programming framework to define any type of events - as me= ntioned earlier, this is not intended as an event+expression MIB or any suc= h thing, just frequently needed filters/categories of events that are fairl= y broadly applicable and useful. Obviously, where the "sweet spot" lies is= subject to discussion. We would love to hear feedback about what other fi= lters are deemed useful. > > > I think set threshold for packet loss or latency is pretty much common in > network trouble shooting, such threshold can be also moved down over > time. > What kind of threshold can be set more depends on empirical experience. I > am wondering how this can be modeled using XPATH statement or some > other mechanism. > > IB>> I let Alex answer this, but I would assume that the smart-filters > IB>> model will allow for comparing a data state pointed by XPath with > IB>> configured threshold value to evaluate trigger condition (and much > IB>> more) We need to figure out the details of the filter construct. In addit= ion to node selection and value/range comparison against a threshold/range = expression (so far, so straightforward), you need to be able to specify a c= omparison against a state, to update the state (e.g. threshold crossing sen= t vs cleared, current high water mark etc), to specify a counter / clear th= reshold, etc. I don't think this can be accomplished with XPATH alone. --- Alex (remainder of message thread deleted) --_000_0C72C38E7EBC34499E8A9E7DD00786391C19FA14sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alex,

 <= /p>

If I understand you corre= ctly, from the automation framework’s point of view a smart filter co= uld be a (part of) event of an event-condition-action that may or may not trigger an action depending on associated with the event condit= ions  (which could be, for example. one-time  check(s) of data st= ore node(s) or RPC output(s) against some constant or variable  value(= s)). I agree. What I meant to say is  that events may be explicitly defined, not be necessarily smart filters,  because= constant evaluation of smart filters may be too demanding for the server. = On the other hand, evaluating smart filters once in an event’s contex= t  is much simpler proposition.

 <= /p>

Igor

 <= /p>

From: Alexande= r Clemm
Sent: Wednesday, November 08, 2017 4:44 PM
To: Igor Bryskin; Qin Wu; Tianran Zhou; Xufeng_Liu@jabil.com; netcon= f@ietf.org
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Igor,

 <= /p>

But I don’t think w= e will assess conditions as part of smart filters.   IMHO this sh= ould be part of the automation framework.  Just to clarify terminology= , to me an event is some kind of “occurrence” that you are notif= ied of (such as “threshold has just been crossed”, “an up= date that meets a smart filter has just been observed”, “some Y= ANG notification has just been emitted”, etc), whereas the condition = is a “check” that is actively conducted (to see if the condition ho= lds when the event was observed).  Smart filters on YANG-push updates = will provide for many of the events that the automation framework would uti= lize, but they may not be the only source, that’s all. 

 <= /p>

Best

--- Alex

 <= /p>

From: Igor B= ryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin= <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@huawei.com>; Tianra= n Zhou <zhoutianran@huawei.com>; Xufeng_Liu@jabil.com; netconf@ietf.o= rg
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor

From:Alexander Clemm

To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org,

Date:2017-11-08 14:00:25

Subject:RE: YANG PUSH Based Generalized Network Control Automation Probl= em Statement

 

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.co= m>; Alexander Clemm
> <alexander.clemm@huaw= ei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@j= abil.com>;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

--_000_0C72C38E7EBC34499E8A9E7DD00786391C19FA14sjceml521mbxchi_-- From nobody Wed Nov 8 22:04:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC99012EB8B for ; Wed, 8 Nov 2017 22:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfoPWO43khC1 for ; Wed, 8 Nov 2017 22:04:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508EA12945F for ; Wed, 8 Nov 2017 22:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=83418; q=dns/txt; s=iport; t=1510207468; x=1511417068; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v+OqRaQUHEg6uIrcsHbbT80lMcGMRsK2Qk78i10nDBg=; b=liMM9lpINAjGKjJcGh2iv0iSl6F5BA9+ecC8dcKA9WF6o7ztWboX6X3y u9KkSNPQ91Yeoc3G1gJ1Ev9AsaZevHcCRprbUrMV1j2k5TuHu/FT6WwTL ofJo3WvxkwHsIN73Pm35nJs6CWDLi9lSNt0KkjBvlqelU9AQCM5sa/IqY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQAm7wNa/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEQi5kbicHg3abQIhVjXeCEQqFOwIahGJBFgEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAxoJCkoCEAIBCA4HDwETAQYDAgICHxEUEQIEDgUIE4kkTAMVqXuCJ?= =?us-ascii?q?4dGDYNIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMwggeBVIFpgyqCa4I4KAKCXYJ?= =?us-ascii?q?jBYoihz+BboU7iFM9AosChQGEcIIeigiHG40iiFICERkBgTgBJQExgXF6FYMth?= =?us-ascii?q?F93iUYCJQMEgQWBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,368,1505779200"; d="scan'208,217";a="316465310" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 06:04:19 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA964Iop000559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Nov 2017 06:04:19 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 9 Nov 2017 01:04:18 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 01:04:18 -0500 From: "Eric Voit (evoit)" To: Mahesh Jethanandani CC: netconf Thread-Topic: [Netconf] Review of subscribed notifications draft Thread-Index: AQHTWDKhsaKJGWsPKEOmOZ2QdnAke6MKjgQQ Date: Thu, 9 Nov 2017 06:04:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.20.127] Content-Type: multipart/alternative; boundary="_000_db172d667ba74b98a8cb9f7b1870b910XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Review of subscribed notifications draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 06:04:32 -0000 --_000_db172d667ba74b98a8cb9f7b1870b910XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpUaGFua3Mgc28gbXVjaCBmb3IgdGhlIHRob3JvdWdoIHJldmlldy4gICBU aG91Z2h0cyBpbi1saW5lLi4uDQoNCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmksIE5vdmVtYmVy IDcsIDIwMTcgODo0MSBQTQ0KDQpJIGhhdmUgcmV2aWV3ZWQgLTA1IHZlcnNpb24gb2YgdGhlIHN1 YnNjcmliZWQgbm90aWZpY2F0aW9ucyBkcmFmdC4gSSBrbm93IHRoZSBhdXRob3JzIGhhdmUgcHVi bGlzaGVkIGEgbW9yZSB1cGRhdGVkIHZlcnNpb24uIElmIHRoZSBjb21tZW50cyBpbiB0aGlzIHJl dmlldyBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBsYXRlciB2ZXJzaW9uIG9mIHRoZSBkcmFm dCwgYXV0aG9ycyBjYW4gaW5kaWNhdGUgaXQgc28uDQoNCjxFcmljPiBIYXZlIGluZGljYXRlZCB0 aGlzDQoNCkFzIHNvbWUgcmV2aWV3ZXJzIGhhdmUgYWxyZWFkeSBpbmRpY2F0ZWQsIHRoZSBkb2N1 bWVudCBpcyBoYXJkIHRvIHJlYWQuIEl0IHdvdWxkIGhlbHAgaWYgdGhlIGF1dGhvcnMgY291bGQg d29yayBvbiBzZW50ZW5jZSBjb25zdHJ1Y3Rpb24gYW5kIGNvbnNpc3RlbmN5IGluIHVzYWdlIG9m IHRlcm1zLiBUaGUgb3RoZXIsIGFuZCB0aGlzIGhhcyBiZWVuIGNvbnZleWVkIHRvIHRoZSBhdXRo b3JzIGJ5IHRoZSBjaGFpcnMgaXMgdGhlIGRlc2lyZSB0byBzZWUgZHJhZnQtaWV0Zi1uZXRjb25m LW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucyBhbmQgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rj b25mLW5vdGlmIGJlIHJldmlld2VkIGFuZCBwdWJsaXNoZWQgYWxvbmcgd2l0aCB0aGlzIGRyYWZ0 LiBXZSB0aGluayB0aGV5IG1ha2UgZm9yIGEgbmljZSBmaXQgdG9nZXRoZXIuDQoNCjxFcmljPiBJ dCBpcyBwb3NzaWJsZSB0byBjb21wbGV0ZSB0aGUgdHdvIGRyYWZ0cyB0b2dldGhlci4gIEFuZCBh cyBsZWFkIGF1dGhvciBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYsIEkgaG9w ZWQgdGhpcyB3b3VsZCBiZSB0aGUgY2FzZS4gIEhvd2V2ZXIgdGhlcmUgYXJlIHR3byBpc3N1ZXMg d2hpY2ggbWFrZSBpdCBub24tb3B0aW1hbDoNCg0KKGEpIFRoZXJlIGlzIGEgZGVwZW5kZW5jeSBv ZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYgb24gZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1tZXNzYWdlcy4gICBUaGlzIGRlcGVuZGVuY3kgaXMgdGhhdCBhbiDigJhv a+KAmSBtdXN0IGJlIHNlbnQgYWZ0ZXIgc3Vic2NyaXB0aW9uLXN0YXJ0ZWQgbm90aWZpY2F0aW9u IGZvciBhIENvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHRvIHNpZ25hbCByZWFkaW5lc3MgdG8gcmVj ZWl2ZSBvbi13YXkgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLiAgQnV0IHdoaWNoIG9uZS13YXkgbm90 aWZpY2F0aW9uIGVuY29kaW5nIHRvIHVzZSBmb3IgYSByZWNlaXZlcj8gICBJZiDigJhva+KAmSBp bmRpY2F0ZXMgc3VwcG9ydCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNz YWdlcywgZXZlcnl0aGluZyBpcyBjbGVhbi4gIE90aGVyd2lzZSBhbHRlcm5hdGUgSFRUUCByZXNw b25zZSBjb2RlcyBuZWVkZWQgdG8gc2lnbmFsIHRoZSByZWNlaXZlciBkZXNpcmVkIHVzZSBvZiB0 aGUgZXhpc3RpbmcgNTI3NyBvbmUgd2F5IG5vdGlmaWNhdGlvbiBlbmNvZGluZy4gIChOb3RlOiBJ ZiB3ZSB3YW50IHRvIHN0YXJ0IHBsYXlpbmcgd2l0aCBIVFRQIHJlc3BvbnNlIGNvZGVzLCB3ZSBs aWtlbHkgY2FuIGFkZHJlc3MgdGhpcywgYW5kIHJlbW92ZSB0aGUgZGVwZW5kZW5jeS4gIEJ1dCBz dWNoIGEgc29sdXRpb24gaXMgYSBoYWNrIGFzIEhUVFAgc3VjY2VzcyByZXNwb25zZSBjb2RlcyBh cmVu4oCZdCBkZXNpZ24gZm9yIHVzZSBhbiBlbmNvZGluZyBzZWxlY3Rpb24gbWVjaGFuaXNtLikN Cg0KKGIpIERlc3BpdGUgYSB5ZWFyIG9mIHJlcXVlc3RzIGF0IHZhcmlvdXMgSUVURnMsIHdlIGhh dmUgbmV2ZXIgYmVlbiBhYmxlIHRvIGdldCBhc3Npc3RhbmNlIG9uIEdSUEPigJlzIGludGVyc2Vj dGlvbiB3aXRoIFJFU1RDT05GLiAgQW5kIHNhZGx5IGl0IGRvZXNu4oCZdCBzZWVtIGxpa2UgUkVT VENPTkYgaXMgbm90IGEgY2xlYW4gbWF0Y2ggd2l0aCBHUlBDLiAgIFNwZWNpZmljYWxseSBHUlBD IGRlc2lyZXMgdGhlIHVzZSBvZiBQT1NUIHJhdGhlciB0aGFuIHRoZSBHRVQgdXNlZCBieSBSRVNU Q09ORi4gICAgSSBob3Bpbmcgc29tZSBtb3JlIHRpbWUgbWlnaHQgY2xlYXIgdGhpcyBsb2dqYW0s IGFuZCB3ZSB3aWxsIGdldCBzb21lIGhlbHAuICBPciBwZXJoYXBzIEdSUEMgd2lsbCBlYXNpbHkg c3VwcG9ydCBHRVQuICBCdXQgcmlnaHQgbm93LCBub2JvZHkgaXMgc2F5aW5nIHRoaXMgaXMgYSB2 YWxpZCBhcHByb2FjaC4NCg0KU28gYmFzZWQgb24gdGhlc2UgdHdvIGlzc3VlcywgaXQgc2VlbXMg dG8gbWUgY2xlYW5lciB0byB3YWl0LiAgQW5kIGFzIHRoZXJlIGFyZSBub3QgZGVwbG95bWVudHMg b2YgdGhlIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBkcmFmdCB5ZXQsIG5vIGlt cGxlbWVudGVycyBzZWVtIGFkdmVyc2VseSBpbXBhY3RlZC4NCg0KDQpDb21tZW50cy4NCg0KU2Vj dGlvbiAxLjMNCg0KICAqICAgV2h5IGlzIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIG9wdGlvbmFs IGJ1dCBkeW5hbWljIHN1YnNjcmlwdGlvbiBpcyBub3Q/IEF0IGxlYXN0IGl0IGRvZXMgbm90IHNh eSBzbyBmb3IgZHluYW1pYyBzdWJzY3JpcHRpb24uDQo8RXJpYz4gV2UgaGF2ZW7igJl0IGhlYXJk IGZyb20gYW55b25lIHdobyB3YW50cyB0byBkbyBqdXN0IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u cy4gIChUaGlzIGluY2x1ZGVzIHRoZSBSRkMtNzkyMyByZXF1aXJlbWVudHMuKSAgIEJhc2VkIG9u IHRoaXMsIGl0IHdvdWxkIG1ha2UgZm9yIG1vcmUgY29tcGxleGl0eSB0byBpbmRpY2F0ZSB0aGUg aW50ZXJwbGF5IG9mIG9wdGlvbmFsIGZlYXR1cmVzIGFjcm9zcyB0aGUgbW9kZWwgYW5kIGRyYWZ0 Lg0KDQogICogICAiRm9yIGNvbm5lY3Rpb24gbGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNwb3J0IGxp a2UgSFRUUCwgIOKApiB0aGF0IHdpbGwgdGVybWluYXRlIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyIg LSBEbyBub3QgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudC4gV2hlbiBpcyB0aGlzIHNlc3Npb24g dGVybWluYXRlZCBpZiBpdCBpcyBjb25uZWN0aW9uIGxlc3MgYW5kL29yIHN0YXRlbGVzcz8NCkEg Y29ubmVjdGlvbmxlc3MgZHluYW1pYyBzdWJzY3JpcHRpb24gaXMgdGVybWluYXRlZCB3aGVuIHRo ZXJlIGlzIGxvc3MgZGV0ZWN0ZWQgYnkgdGhlIHB1Ymxpc2hlciBvZiBpbmZvcm1hdGlvbiBiZWlu ZyBzZW50IHRvIHRoZSByZWNlaXZlci4gIFRoaXMgY2FuIGJlIHRoZSBsb3NzIG9mIGVpdGhlciBu b3RpZmljYXRpb24gbWVzc2FnZXMgb3IgdHJhbnNwb3J0IGtlZXAtYWxpdmVzLiAgU3BlY2lmaWNz IG9mIGhvdyB0aGlzIGlzIGRvbmUgaXMgd2l0aGluIGVhY2ggY29ubmVjdGlvbmxlc3MgdHJhbnNw b3J0IGRyYWZ0LiAgIFNlZSBwcm9wb3NlZCB0ZXh0IHdpdGggeWVsbG93IGhpZ2hsaWdodGluZyBi ZWxvdy4uLg0KDQogICogICBDb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgY2FuIGJlIG1vZGlmaWVk IGJ5IGFueSBjb25maWd1cmF0aW9uIGNsaWVudC4gSXMgaXQgbm90IHRoZSBjYXNlIHRoYXQgdGhh dCBzdWJzY3JpcHRpb24gaXMgY29udHJvbGxlZCBieSB1c2VyL05BQ00gbW9yZSB0aGFuIHdoZXRo ZXIgdGhlIGNsaWVudCBoYXMgdGhlIHdyaXRlIHBlcm1pc3Npb24/IFNhbWUgaXMgdHJ1ZSBmb3Ig ZHluYW1pYyBzdWJzY3JpcHRpb24uDQpOQUNNIGlzIGNlcnRhaW5seSBhIGdvb2Qgd2F5IHRvIGdv IHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50LiAgVGhlIHRleHQgaW50ZW5kIHRvIGFsbG93IGZvciBp bXBsZW1lbnRhdGlvbnMgd2l0aG91dCBOQUNNLiAgIEkgc2F3IHRoZSB3b3JkcyDigJx3cml0ZSBw ZXJtaXNzaW9uc+KAnSBhcyBhIG1vcmUgZ2VuZXJhbCB0ZXJtIHdoaWNoIGlzIHRyeWluZyB0byBj b3ZlciBhbnkgc3VjaCBjYXNlIHdoZXJlIGEgY29uZmlndXJhdGlvbiBzeXN0ZW0gaXMgdHJ5aW5n IHRvIG1ha2UgY2hhbmdlcyB0byB0aGUgY29uZmlndXJhdGlvbiB0cmVlLiBEbyB5b3UgaGF2ZSBh biBhbHRlcm5hdGl2ZSBmb3IgdGhpcyBnZW5lcmFsIGNhc2U/DQoNCiAgKiAgIElzIHRoZXJlIGEg Z3JhY2VmdWwgdGVybWluYXRpb24gb2YgYSBkeW5hbWljIHN1YnNjcmlwdGlvbj8gRG9lcyBub3Qg c2VlbSBhcHBhcmVudCByZWFkaW5nIHRoZSBwYXJhZ3JhcGguDQoNCiAgIG8gIFRoZSBsaWZldGlt ZSBvZiBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uIGlzIGJvdW5kZWQgYnkgdGhlIHRyYW5zcG9ydCBz ZXNzaW9uIHVzZWQgdG8gZXN0YWJsaXNoIGl0LiAgRm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQgc3Rh dGVmdWwgdHJhbnNwb3J0IGxpa2UgTkVUQ09ORiwgdGhlIGxvc3Mgb2YgdGhlIHRyYW5zcG9ydCBz ZXNzaW9uIHdpbGwgcmVzdWx0IGluIHRoZSBpbW1lZGlhdGUgdGVybWluYXRpb24gb2YgYXNzb2Np YXRlZCBkeW5hbWljIHN1YnNjcmlwdGlvbnMuICBGb3IgY29ubmVjdGlvbmxlc3Mgb3Igc3RhdGVs ZXNzIHRyYW5zcG9ydHMgbGlrZSBIVFRQLCBzb21lIGxvc3Mgb2YgdHJhZmZpYyBtdXN0IGJlIGRl dGVjdGVkIGJlZm9yZSB0aGUgZHluYW1pYyBzdWJzY3JpcHRpb24gc2hvdWxkIGJlIHRlcm1pbmF0 ZWQuICBTdWNoIGxvc3Mgb2YgdHJhZmZpYyBjYW4gYmUgZGV0ZWN0ZWQgaW4gd2F5cyBzdWNoIGFz IHRoZSBsYWNrIG9mIHJlY2VpcHQgVENQIGFja25vd2xlZGdlbWVudCBvZiBhIHNlcXVlbnRpYWwg c2V0IG9mIG5vdGlmaWNhdGlvbiBtZXNzYWdlcywgb3IgdGhlIGxvc3Mgb2YgdHJhbnNwb3J0IGtl ZXAtYWxpdmVzLg0KDQogICBvICAgVGhlIGxpZmV0aW1lIG9mIGEgY29uZmlndXJlZCBzdWJzY3Jp cHRpb24gaXMgZHJpdmVuIGJ5IHJlbGV2YW50IGNvbmZpZ3VyYXRpb24gYmVpbmcgcHJlc2VudCBv biB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uLiAgVGhpcyBpbXBsaWVzIGNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9ucyBwZXJzaXN0IGFjcm9zcyByZWJvb3RzLCBhbmQgcGVyc2lzdCBldmVuIHdoZW4g dHJhbnNwb3J0IGlzIHVuYXZhaWxhYmxlLg0KDQogICBvICBDb25maWd1cmVkIHN1YnNjcmlwdGlv bnMgY2FuIGJlIG1vZGlmaWVkIG9yIHRlcm1pbmF0ZWQgYnkgYW55IGNvbmZpZ3VyYXRpb24gY2xp ZW50IHdpdGggd3JpdGUgcGVybWlzc2lvbiBvbiB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgc3Vi c2NyaXB0aW9uLiAgRHluYW1pYyBzdWJzY3JpcHRpb25zIGNhbiBiZSBtb2RpZmllZCBvciB0ZXJt aW5hdGVkIHZpYSBhbiBSUEMgcmVxdWVzdCBtYWRlIHVwb24gdGhlIG9yaWdpbmFsIHN1YnNjcmli aW5nIHRyYW5zcG9ydCBzZXNzaW9uLg0KDQpTZWN0aW9uIDIuMQ0KDQogICogICBBcmUgdGhlcmUg bm8gbm90aWZpY2F0aW9ucyBvdmVyIFJFU1RDT05GPyBJZiBzbywgd2h5IGFyZSB0aGV5IG5vdCBt ZW50aW9uZWQgb3ZlciBoZXJlLiBBbmQgYXJlIG5vdGlmaWNhdGlvbnMgYWx3YXlzIGVuY29kZWQg dXNpbmcgWE1MPyBUaGVyZSBpcyBhIHJlZmVyZW5jZSB0byBvdGhlciBmb3JtcyBvZiBlbmNvZGlu ZyBpbiBTZWN0aW9uIDQuMSwgdW5kZXIgRHluYW1pYyBTdWJzY3JpcHRpb25zLiBJZiBpdCBpcyB0 cnVlIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgYWxzbywgY291bGQgaXQgYmUgc3RhdGVk IHVwIGZyb250Pw0KVGhlIE5FVENPTkYgZXZlbnQgc3RyZWFtIGlzIGEgbGVnYWN5IG5hbWUgZnJv bSBSRkMtNTI3NyB3aGljaCB0aGlzIGRyYWZ0IGFkb3B0ZWQgZm9yIGNvbnRpbnVpdHnigJlzIHNh a2UuICAgUkVTVENPTkYgbWF5IGFsc28gc3Vic2NyaWJlIHRvIHRoaXMgZXZlbnQgc3RyZWFtLiAg RG8geW91IHdhbnQgbWUgdG8gc2F5IOKAnFRoZSBORVRDT05GIGV2ZW50IHN0cmVhbSBpcyB3aG9s bHkgc2VwYXJhdGUgZnJvbSB0aGUgdXNlIG9mIE5FVENPTkYgYXMgYSB0cmFuc3BvcnTigJ0NCg0K ICAqICAgQXJlIHB1Ymxpc2hlciBhbmQgc3lzdGVtIHRoZSBzYW1lIGVudGl0eT8gSWYgbm90LCB3 aGF0IGlzIHRoZSBkaWZmZXJlbmNlPyBJZiB0aGV5IGFyZSB0aGUgc2FtZSwgY2FuIHdlIGJlIGNv bnNpc3RlbnQgaW4gdGhlIG5vbWVuY2xhdHVyZT8NCldpbGwgY2hhbmdlIOKAnFN5c3RlbeKAnSB0 byDigJxQdWJsaXNoZXLigJ0uDQoNCiAgKiAgIERvZXNuJ3QgTkFDTSBkZWZpbmUgbm90aWZpY2F0 aW9uIHBlcm1pc3Npb25zIG9uIHRoZSBwdWJsaXNoZXI/IFRoZSByZWNlaXZlciBtYXkgbm90IGhh dmUgcGVybWlzc2lvbiBmb3IgZXZlcnkgZXZlbnQgZ2VuZXJhdGVkIGJ5IHRoZSBwdWJsaXNoZXIu DQpCeSBkZWZpbml0aW9uLCBzdWJzY3JpcHRpb24gdG8gYSBzdHJlYW0gbWVhbnMgYWNjZXNzIHRv IGFsbCBldmVudHMgb24gYSBzdHJlYW0uICBUaGlzIGlzIGlkZW50aWNhbCB0byBjdXJyZW50IDUy NzcgYmVoYXZpb3IuDQpTZWN0aW9uIDIuMg0KDQogICogICBJc24ndCB0aGUgZGVmaW5pdGlvbiBv ZiBmaWx0ZXIganVzdCB0aGF0LiBEbyBub3QgdW5kZXJzdGFuZCB0aGUgaW1wbGljYXRpb24gb2Yg dGhlIGRlZmluaXRpb24gb2YgRXZlbnQgRmlsdGVyIGFuZCBob3cgaXQgaXMgZGlmZmVyZW50IGZy b20gb3RoZXIgZmlsdGVycy4NClNpZ25pZmljYW50IHVwZGF0ZXMgdG8gdGhlIGRlZmluaXRpb24g b2Yg4oCcU3RyZWFtIGZpbHRlcuKAnSBiYXNlZCBvbiBNYXJ0aW7igJlzIGNvbW1lbnRzLiAgTm8g bG9uZ2VyIGRvIHdlIHRyeSB0byBoYXZlIGEgZ2VuZXJpYyBmaWx0ZXIgZGVmaW5pdGlvbiB3aGlj aCBhbHNvIGNvdmVycyBlbGVtZW50cyBvZiB0aGUgU2VsZWN0aW9uIGZpbHRlciBmcm9tIHlhbmct cHVzaC4gICBFYWNoIHN0YW5kcyBvbiBpdHMgb3duIG5vdyAod2l0aCBpdHMgb3duIGVudHJ5IGlu IGVhY2ggcmVzcGVjdGl2ZSBkcmFmdHPigJkgdGVybWlub2xvZ3kgdGFibGUuKQ0KU2VjdGlvbiAy LjMNCg0KICAqICAgV2hhdCBjb25zdGl0dXRlcyBhbiAiYXNzZXJ0ZWQgc3Vic2NyaXB0aW9uIHRv IGJlIGV4dGVybmFsbHkgdmlzaWJsZSI/DQpBIOKAnGVzdGFibGlzaC1zdWJzY3JpcHRpb27igJ0g bmVlZHMgYSBzdWJzY3JpcHRpb24taWQgdG8gYmUgYXNzaWduZWQgYmVmb3JlIGl0IGFwcGVhcnMg aW4gdGhlIG9wZXJhdGlvbmFsIHlhbmctdHJlZS4gIEEgZmFpbGVkIOKAnGVzdGFibGlzaC1zdWJz Y3JpcHRpb27igJ0gaXMgbmV2ZXIgaW5zdGFudGlhdGVkIGluIHRoZSB5YW5nIG1vZGVsLiAgTGlr ZWx5IHRoaXMgaXMgb2J2aW91cywgYXMgYW55IGZhaWxlZCBSUEMgd2lsbCBub3QgcmVzdWx0IGlu IHRoZSBjcmVhdGlvbiBvZiBuZXcgb2JqZWN0cy4gICBBbmQgaWYgeW91IGZlZWwgdGhpcyBpcyBv YnZpb3VzLCB3ZSBjYW4ganVzdCBkZWxldGUgdGhlIHNlbnRlbmNlLiAgQnV0IGlmIHlvdSB3YW50 IHRvIGtlZXAgc29tZXRoaW5nIHdlIGNvdWxkIG1vcnBoIHRoZSBzdGF0ZW1lbnQgaW50byB0aGUg Zm9sbG93bmcgdGV4dCB0byBjbGFyaWZ5Og0KQW5kIHN1YnNjcmlwdGlvbiBzdGF0ZSBkb2VzIG5v dCBiZWNvbWUgZXhwb3NlZCB2aWEgdGhlIFlBTkcgbW9kZWwgdW50aWwgdGhlIHN0YXRlIG1hY2hp bmUgZmlyc3QgcmVhY2hlcyB0aGUg4oCcYWN0aXZl4oCdIHN0YXRlLg0KDQogICogICBJZiB0aGUg c3RhdGUgbWFjaGluZSBpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgcHVibGlzaGVyLCB0 aGVuIGNhbiB0aGUgcHVibGlzaGVyIHVuaWxhdGVyYWxseSAic3RhcnQiIGEgc3Vic2NyaXB0aW9u PyBPciBpcyB0aGF0IGl0IHNpdHMgaW4gaW5pdCBzdGF0ZSwgd2FpdGluZyBmb3IgYSBzdWJzY3Jp cHRpb24gcmVxdWVzdCB0byBiZSByZWNlaXZlZD8NCkJhc2VkIG9uIE1hcnRpbuKAmXMgY29tbWVu dHMsIHRoZSBzdGF0ZSBtYWNoaW5lIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBub3cgaXMg bW9yZSBmdWxseSBkb2N1bWVudGVkLiAgSXQgY292ZXJzIHRoaXMgY2FzZS4NCg0KICAqICAgQ2Fu IGEgcmVjZWl2ZXIgc3VzcGVuZCBzdWJzY3JpcHRpb24gdG8gYW4gZXZlbnQgc3RyZWFtPw0KTm8u ICAgQ3VycmVudCB0ZXh0IHNheXMg4oCcVGhlcmUgYXJlIG5vIGV4dGVybmFsIGNvbnRyb2xzIG92 ZXIgc3VzcGVuZCBhbmQgcmVzdW1lLuKAnQ0KU2VjdGlvbiAzDQoNCiAgKiAgIE5vdGUgdGhlIHJl Y2VudCBkaXNjdXNzaW9uIGFyb3VuZCBzaXplIG9mIHRoZSB0cmVlIHRyYXZlcnNpbmcgbXVsdGlw bGUgcGFnZXMuIEluIGdlbmVyYWwgaWYgYSB0cmVlIGRpYWdyYW0gc3BhbnMgbXVsdGlwbGUgcGFn ZXMsIGl0IGxvc2VzIGl0cyByZWFkYWJpbGl0eS4gQ29uc2lkZXIgYnJlYWtpbmcgdXAgdGhlIHRy ZWUgaW50byBtdWx0aXBsZSBwYXJ0cywgcGFydGljdWxhcmx5IHJwYyBhbmQgbm90aWZpY2F0aW9u cyBwYXJ0cyBvZiB0aGUgdHJlZS4gQW4gZXhwbGFuYXRpb24gYXQgdGhlIHRvcCBvZiBlYWNoIHBh cnQgb2YgdGhlIHRyZWUgd2lsbCBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgcmVhZGFiaWxpdHkuDQpJ IGNvdWxkIHB1bGwgdGhlIFJQQyBhbmQgbm90aWZpY2F0aW9uIHRyZWVzIHVuZGVyIGVhY2ggcmVz cGVjdGl2ZSBzZWN0aW9uIHdpdGhpbiB0aGlzIGRvY3VtZW50IHdpdGhvdXQgdGhpcyBkb2N1bWVu dOKAmXMgc2l6ZSBleHBsb2RpbmcuICBBbmQgSSAgd291bGQgYWNjZXB0IHdpdGggZG9pbmcgdGhh dC4gIEhvd2V2ZXIgdGhlcmUgd291bGQgYmUgaW1wbGljYXRpb25zIGZvciB0aGUgeWFuZy1wdXNo IGRvY3VtZW50IGFzIHRoZSB5YW5nLXB1c2ggZG9jdW1lbnQgZG9lcyBub3QgaGF2ZSBzaW1pbGFy IHNlY3Rpb25zIHJlLWV4cGxhaW5pbmcgZWFjaCBhdWdtZW50ZWQgUlBDIGFuZCBOb3RpZmljYXRp b24uICBBbmQgdGhlcmVmb3JlIHRoZXJlIGlzIG5vIGVhc3kgd2F5IHRvIHBhcnRpdGlvbiB0aGF0 IGV2ZW4gbGFyZ2VyIHlhbmctcHVzaCB0cmVlIGludG8gc21hbGwgcG9ydGlvbnMuICAgSWYgeW91 IHdhbnQgdG8gZ28gZG93biB0aGlzIHBhdGgsIHdlIHNob3VsZCB2YWxpZGF0ZSB0aGlzIGJyb2Fk bHkgYXMgSSBiZWxpZXZlIGl0IGRldHJhY3RzIGFzIGEgd2hvbGUgZnJvbSB5YW5nLXB1c2guICAg TXkgcHJlZmVyZW5jZSBpcyBzdGlsbCBmb3IgdGhlIGV4aXN0aW5nIGRvY3VtZW50IHN0cnVjdHVy ZSBiZWNhdXNlIGl0IGFsbG93cyBlYXN5IGNvbXBhcmlzb24gd2l0aCB0aGUgeWFuZy1wdXNoIGRy YWZ0Lg0KVGhlIGZpbmFsIGNob2ljZSBJIGRvbuKAmXQgcmVjb21tZW5kIGlzIHRvIGRvIGEgc2lt aWxhciB0cmVlIHBhcnRpdGlvbmluZyBmb3IgeWFuZy1wdXNoIGFzIHdlbGwuICBTdWNoIGEgcGFy dGl0aW9uaW5nIHdvdWxkIHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlIHlhbmctcHVzaCBkcmFm dCBzaXplIGFuZCB0ZXh0IHJlZHVuZGFuY3kuDQoNCiAgKiAgIFdoYXQgZG9lcyBpdCBtZWFuIHRv IGhhdmUgYSDigJxmaWx0ZXIgaW5saW5lIGZvciBlYWNoIHN1YnNjcmlwdGlvbuKAnT8gQ291bGQg aXQgYmUgdGhhdCDigJxGaWx0ZXJz4oCdIGFyZSBqdXN0IHByZS1kZWZpbmVkIHNldCBvZiBmaWx0 ZXJzLCB3aGlsZSBldmVyeXRoaW5nIGVsc2UgaXMgc3BlY2lmaWVkIGF0IHRoZSB0aW1lIG9mIHN1 YnNjcmlwdGlvbj8NCllvdSBhcmUgY29ycmVjdC4gICBIb3cgYWJvdXQgdGhlIHRleHQgc2F5aW5n ICDigJwgYWx0ZXJuYXRpdmUgdG8gZGVmaW5pbmcgdGhlIGZ1bGwgZmlsdGVyIHdpdGhpbiBlYWNo IHN1YnNjcmlwdGlvbi7igJ0NCg0KU2VjdGlvbiA0DQoNCiAgKiAgIFRoaXMgc2VjdGlvbiByZXBl YXRzIHRoZSBmYWN0IGhvdyBzdWJzY3JpcHRpb25zIGNhbiBiZSBtb2RpZmllZCwgZGVsZXRlZCwg a2lsbGVkIHVzaW5nIHRoZSBzZXNzaW9uIHRoYXQgd2FzIHVzZWQgdG8gZXN0YWJsaXNoIHRoZSBz dWJzY3JpcHRpb24uDQpZZXMuICAgVGhlIHJlYXNvbiBpcyB0aGF0IG9ubHkgdGhlIGtpbGwgUlBD IGNhbiByZWZlcmVuY2UgYSBzdWJzY3JpcHRpb24gY3JlYXRlZCBmcm9tIGEgZGlmZmVyZW50IHNl c3Npb24uICAgU28gd2UgY2Fu4oCZdCBnZW5lcmFsaXplIHRoaXMgb25jZSBhdCB0aGUgZnJvbnQg b2Ygc2VjdGlvbiA0Lg0KDQogICogICBXaGF0IGhhcHBlbnMgaWYgdGhlIHNlc3Npb24gaXRzZWxm IGdvZXMgYXdheT8NCkluIGFsbCBjYXNlcywgdGhlIGxvc3Mgb2YgYSBzZXNzaW9uIGRlbGV0ZXMg dGhlIHN1YnNjcmlwdGlvbi4gIEJ1dCBsb3NzIG9mIHNlc3Npb24gaXMgbWVhbnMgZGlmZmVyZW50 IHRoaW5ncyBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCAoTkVUQ09ORikgb3IgY29ubmVjdGlvbmxl c3MgKEhUVFApLiAgQXMgYSByZXN1bHQgdGhlIHNwZWNpZmljcyBhcmUgaW4gdGhlIHRyYW5zcG9y dCBkcmFmdHMsIGJ1dCB0aGUgZ2VuZXJhbCBiZWhhdmlvciBpcyBpbiB0aGlzIGRvY3VtZW50IGlu IHNlY3Rpb24gMS4zLg0KDQpTZWN0aW9uIDQuMQ0KDQogICogICBJc27igJl0IHJlcGxheSBzdWJz Y3JpcHRpb24gYW5kIG5vdGlmaWNhdGlvbiBhIGZ1bmN0aW9uIG9mIHRoZSBjYXBhYmlsaXR5IG9m IHRoZSBwdWJsaXNoZXIgaW4gaG93IG1hbnkgaGlzdG9yaWNhbCBldmVudHMgaXQgY2FuIGhvbGQ/ DQpZZXMNCg0KICAqICAgV291bGQgaXQgbm90IGJlIHNpbXBsZXIgZm9yIHRoZSBwdWJsaXNoZXIg YWxsIHRoZSBldmVudHMgaXQgaGFzIGluIGl0cyBoaXN0b3J5IGJ1ZmZlciBhbmQgbGV0IHRoZSBz dWJzY3JpYmVyIHRocm93IGF3YXkgd2hhdGV2ZXIgaXQgaXMgbm90IGludGVyZXN0ZWQgaW4/DQpU aGF0IHdvdWxkIGRyaXZlIGEgZGlmZmVyZW50IChhbmQgbGVzcyBjYXBhYmxlKSBiZWhhdmlvciB0 aGFuIGN1cnJlbnRseSBpbiA1Mjc3LiAgRm9yIGV4YW1wbGUsIGEgbGFyZ2VyIGJ1ZmZlciB3b3Vs ZCByZXN1bHQgaW4gbG90cyBvZiBvYmplY3RzIHdoaWNoIGEgc3Vic2NyaWJlciBkb2VzbuKAmXQg d2FudC4NCg0KICAqICAgV2hhdCBoYXBwZW5zIGlmIHRoZSBzdWJzY3JpcHRpb24gdGltZSBpcyBv bGRlciB0aGFuIHRoZSBvbGRlc3QgZXZlbnQgaW4gdGhlIGhpc3RvcnkgYnVmZmVyPw0KVGhpcyBz ZWN0aW9uIGlzIHNpZ25pZmljYW50bHkgdXBkYXRlZCBiYXNlZCBvbiBNYXJ0aW7igJlzIGNvbW1l bnRzLiAgVGhlIGVuaGFuY2VtZW50cyBpbmNsdWRlcyBlbmhhbmNlZCBkZWZpbml0aW9ucyBpbiB0 aGUgeWFuZyBtb2RlbCBzaG93aW5nIHdoeSBpdCBpcyBpbXBvcnRhbnQgZm9yIGR5bmFtaWMgc3Vi c2NyaXB0aW9ucyB0byByZWplY3QgYSBzdWJzY3JpcHRpb24gd2hpY2ggaXMgc2V0IGZvciBvbGRl ciB0aGFuIHdoYXQgaXMgaW4gdGhlIGV2ZW50IGJ1ZmZlci4gIEl0IGFsc28gZGlzY3Vzc2VzIGhv dyBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGNhbiBidWZmZXIgYW5kIHJlcGxheSBldmVudHMg cmVjb3JkZWQgZHVyaW5nIGEgYm9vdCBzZXF1ZW5jZS4NCg0KU2VjdGlvbiA0LjINCg0KICAqICAg Q2FuIHdlIHVzZSDigJxjb25maWd1cmVkIHN1YnNjcmlwdGlvbnPigJ0gY29uc2lzdGVudGx5LCBp bnN0ZWFkIG9mIHNvbWV0aW1lcyBzYXlpbmcg4oCcU3Vic2NyaXB0aW9ucyBjcmVhdGVkIGJ5IGNv bmZpZ3VyYXRpb27igJ0uIFRoZSB0ZXJtIOKAnGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uc+KAnSBz ZWVtcyB0byBiZSByZS1pbnRyb2R1Y2VkIGluIFNlY3Rpb24gNSwgd2hlbiBpdCBpcyBkZWZpbmVk IGluIFNlY3Rpb24gMS4yLiBTdWdnZXN0IHJlbW92aW5nIHRoZSBzZWN0aW9uIGRlZmluaXRpb24u DQpZZXMuICAgV2lsbCBtYWtlIHRoZSBjaGFuZ2UgaW4gc2VjdGlvbiA0LjIgYW5kIDUuDQoNCiAg KiAgIEFsc28gaWYgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGNhbm5vdCBiZSBtb2RpZmllZCwg d2hpY2ggQlRXIGlzIG5vdCBvYnZpb3VzIHdoeSwNCklmIHlvdSBhbGxvdyBjb25maWd1cmF0aW9u IG9wZXJhdGlvbnMgdG8gbW9kaWZ5IGJlaGF2aW9yIG9mIGEgZHluYW1pYyBzdWJzY3JpcHRpb24s IHlvdSBnZXQgc2V2ZXJhbCBjb25zZXF1ZW5jZXMgc3VjaCBhczoNCihhKSB0aGUgc3Vic2NyaWJl ciBpcyBubyBsb25nZXIgYWdyZWVpbmcgdG8gd2hhdCB0aGUgc3Vic2NyaXB0aW9uIGNvbnRyYWN0 IGluY2x1ZGVzDQooYikgY29tcGxleGl0eTogaG93IHdpbGwgdGhlIHJlY2VpdmVyIGtub3cgdGhl IHN1YnNjcmlwdGlvbiBoYXMgY2hhbmdlcyB3aXRob3V0IGFsc28gaW1wbGVtZW50aW5nIHRoZSBz dWJzY3JpcHRpb24tbW9kaWZpZWQgc3RhdGUgY2hhbmdlIG5vdGlmaWNhdGlvbi4gICBJZiBzZWVt cyBzaW1wbGVyIGp1c3QgdG8ga2lsbCB0aGUgc3Vic2NyaXB0aW9uLCBhbmQgbGV0IHRoZSBzdWJz Y3JpYmVyIHJlbmVnb3RpYXRlIHRoZSBwYXJhbWV0ZXJzIG5ldy4NCg0KICAqICAgdGhlbiBpdCB3 b3VsZCBoZWxwIHRvIHNheSB0aGF0IHRoZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBuZWVkcyB0 byBiZSB0ZXJtaW5hdGVkIGJ5IDxkZWxldGUtc3Vic2NyaXB0aW9uPiAoPz8pLCBhbmQgYSBuZXcg c3Vic2NyaXB0aW9uIGJlIGNyZWF0ZWQuDQpJIHdpbGwgYWRkIHRoYXQuDQoNClRoYW5rcyBhZ2Fp biENCkVyaWMNCg0KTW9yZSBsYXRlci4gVGhhbmtzLg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoN Cg== --_000_db172d667ba74b98a8cb9f7b1870b910XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYU5l dWU7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjIxNjY3MjU3ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyMzY4 NTc2ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjQ1MTEz MzkwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQwMzM1MDcwO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2MjI0MTc2MTY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE0NTAyMjEyMDg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1s aXN0LWlkOjkxODk3NjczMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTg0ODk2MTg4O30NCkBs aXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxMzExODU5NDY2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTQ0MTUxNDY4ODt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTU4NDUyOTkzMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE4Nzg5MDI3Mjg7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1 OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlk OjE3MTM3MjI0Mzg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjU1MTM1ODg0O30NCkBsaXN0 IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxODIwODgwNzQ0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxNDQ3NzUwNzI2O30NCkBsaXN0IGw3OmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNzpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsNzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIE1haGVzaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBzbyBtdWNoIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiZuYnNw OyZuYnNwOyBUaG91Z2h0cyBpbi1saW5lLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFoZXNoIEpldGhhbmFuZGFu aSwgTm92ZW1iZXIgNywgMjAxNyA4OjQxIFBNPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdl ZCAtMDUgdmVyc2lvbiBvZiB0aGUgc3Vic2NyaWJlZCBub3RpZmljYXRpb25zIGRyYWZ0LiBJIGtu b3cgdGhlIGF1dGhvcnMgaGF2ZSBwdWJsaXNoZWQgYSBtb3JlIHVwZGF0ZWQgdmVyc2lvbi4gSWYg dGhlIGNvbW1lbnRzIGluIHRoaXMgcmV2aWV3IGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIGxh dGVyIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCBhdXRob3JzIGNhbiBpbmRpY2F0ZSBpdCBzby48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IEhhdmUgaW5kaWNh dGVkIHRoaXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFzIHNvbWUgcmV2aWV3ZXJzIGhhdmUgYWxyZWFkeSBpbmRpY2F0ZWQsIHRoZSBkb2N1 bWVudCBpcyBoYXJkIHRvIHJlYWQuIEl0IHdvdWxkIGhlbHAgaWYgdGhlIGF1dGhvcnMgY291bGQg d29yayBvbiBzZW50ZW5jZSBjb25zdHJ1Y3Rpb24gYW5kIGNvbnNpc3RlbmN5IGluIHVzYWdlIG9m IHRlcm1zLiBUaGUgb3RoZXIsIGFuZCB0aGlzIGhhcyBiZWVuIGNvbnZleWVkIHRvIHRoZSBhdXRo b3JzIGJ5IHRoZSBjaGFpcnMNCiBpcyB0aGUgZGVzaXJlIHRvIHNlZSBkcmFmdC1pZXRmLW5ldGNv bmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zIGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVz dGNvbmYtbm90aWYgYmUgcmV2aWV3ZWQgYW5kIHB1Ymxpc2hlZCBhbG9uZyB3aXRoIHRoaXMgZHJh ZnQuIFdlIHRoaW5rIHRoZXkgbWFrZSBmb3IgYSBuaWNlIGZpdCB0b2dldGhlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IEl0 IGlzIHBvc3NpYmxlIHRvIGNvbXBsZXRlIHRoZSB0d28gZHJhZnRzIHRvZ2V0aGVyLiZuYnNwOyBB bmQgYXMgbGVhZCBhdXRob3Igb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmLCBJ IGhvcGVkIHRoaXMgd291bGQgYmUgdGhlIGNhc2UuICZuYnNwO0hvd2V2ZXINCiB0aGVyZSBhcmUg dHdvIGlzc3VlcyB3aGljaCBtYWtlIGl0IG5vbi1vcHRpbWFsOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KGEpIFRoZXJlIGlzIGEgZGVwZW5kZW5jeSBvZiBkcmFm dC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtbm90aWYgb24gZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlm aWNhdGlvbi1tZXNzYWdlcy4mbmJzcDsmbmJzcDsgVGhpcyBkZXBlbmRlbmN5IGlzIHRoYXQgYW4g 4oCYb2vigJkgbXVzdCBiZSBzZW50IGFmdGVyDQogc3Vic2NyaXB0aW9uLXN0YXJ0ZWQgbm90aWZp Y2F0aW9uIGZvciBhIENvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHRvIHNpZ25hbCByZWFkaW5lc3Mg dG8gcmVjZWl2ZSBvbi13YXkgbm90aWZpY2F0aW9uIG1lc3NhZ2VzLiZuYnNwOyBCdXQgd2hpY2gg b25lLXdheSBub3RpZmljYXRpb24gZW5jb2RpbmcgdG8gdXNlIGZvciBhIHJlY2VpdmVyPyZuYnNw OyZuYnNwOyBJZiDigJhva+KAmSBpbmRpY2F0ZXMgc3VwcG9ydCBmb3IgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcywNCiBldmVyeXRoaW5nIGlzIGNsZWFuLiZuYnNwOyBP dGhlcndpc2UgYWx0ZXJuYXRlIEhUVFAgcmVzcG9uc2UgY29kZXMgbmVlZGVkIHRvIHNpZ25hbCB0 aGUgcmVjZWl2ZXIgZGVzaXJlZCB1c2Ugb2YgdGhlIGV4aXN0aW5nIDUyNzcgb25lIHdheSBub3Rp ZmljYXRpb24gZW5jb2RpbmcuJm5ic3A7IChOb3RlOiBJZiB3ZSB3YW50IHRvIHN0YXJ0IHBsYXlp bmcgd2l0aCBIVFRQIHJlc3BvbnNlIGNvZGVzLCB3ZSBsaWtlbHkgY2FuIGFkZHJlc3MgdGhpcywg YW5kIHJlbW92ZQ0KIHRoZSBkZXBlbmRlbmN5LiZuYnNwOyBCdXQgc3VjaCBhIHNvbHV0aW9uIGlz IGEgaGFjayBhcyBIVFRQIHN1Y2Nlc3MgcmVzcG9uc2UgY29kZXMgYXJlbuKAmXQgZGVzaWduIGZv ciB1c2UgYW4gZW5jb2Rpbmcgc2VsZWN0aW9uIG1lY2hhbmlzbS4pJm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihiKSBEZXNwaXRlIGEgeWVhciBvZiBy ZXF1ZXN0cyBhdCB2YXJpb3VzIElFVEZzLCB3ZSBoYXZlIG5ldmVyIGJlZW4gYWJsZSB0byBnZXQg YXNzaXN0YW5jZSBvbiBHUlBD4oCZcyBpbnRlcnNlY3Rpb24gd2l0aCBSRVNUQ09ORi4mbmJzcDsg QW5kIHNhZGx5IGl0IGRvZXNu4oCZdCBzZWVtIGxpa2UNCiBSRVNUQ09ORiBpcyBub3QgYSBjbGVh biBtYXRjaCB3aXRoIEdSUEMuJm5ic3A7Jm5ic3A7IFNwZWNpZmljYWxseSBHUlBDIGRlc2lyZXMg dGhlIHVzZSBvZiBQT1NUIHJhdGhlciB0aGFuIHRoZSBHRVQgdXNlZCBieSBSRVNUQ09ORi4mbmJz cDsgJm5ic3A7Jm5ic3A7SSBob3Bpbmcgc29tZSBtb3JlIHRpbWUgbWlnaHQgY2xlYXIgdGhpcyBs b2dqYW0sIGFuZCB3ZSB3aWxsIGdldCBzb21lIGhlbHAuJm5ic3A7IE9yIHBlcmhhcHMgR1JQQyB3 aWxsIGVhc2lseSBzdXBwb3J0IEdFVC4mbmJzcDsgQnV0IHJpZ2h0IG5vdywNCiBub2JvZHkgaXMg c2F5aW5nIHRoaXMgaXMgYSB2YWxpZCBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlNvIGJhc2VkIG9uIHRoZXNlIHR3byBpc3N1ZXMsIGl0IHNlZW1z IHRvIG1lIGNsZWFuZXIgdG8gd2FpdC4mbmJzcDsgQW5kIGFzIHRoZXJlIGFyZSBub3QgZGVwbG95 bWVudHMgb2YgdGhlIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBkcmFmdCB5ZXQs IG5vIGltcGxlbWVudGVycw0KIHNlZW0gYWR2ZXJzZWx5IGltcGFjdGVkLjxiPjxvOnA+PC9vOnA+ PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAxLjM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5XaHkgaXMg Y29uZmlndXJlZCBzdWJzY3JpcHRpb24gb3B0aW9uYWwgYnV0IGR5bmFtaWMgc3Vic2NyaXB0aW9u IGlzIG5vdD8gQXQgbGVhc3QgaXQgZG9lcyBub3Qgc2F5IHNvIGZvciBkeW5hbWljIHN1YnNjcmlw dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsgV2UgaGF2ZW7igJl0 IGhlYXJkIGZyb20gYW55b25lIHdobyB3YW50cyB0byBkbyBqdXN0IGNvbmZpZ3VyZWQgc3Vic2Ny aXB0aW9ucy4mbmJzcDsgKFRoaXMgaW5jbHVkZXMNCiB0aGUgUkZDLTc5MjMgcmVxdWlyZW1lbnRz LikmbmJzcDsmbmJzcDsgQmFzZWQgb24gdGhpcywgaXQgd291bGQgbWFrZSBmb3IgbW9yZSBjb21w bGV4aXR5IHRvIGluZGljYXRlIHRoZSBpbnRlcnBsYXkgb2Ygb3B0aW9uYWwgZmVhdHVyZXMgYWNy b3NzIHRoZSBtb2RlbCBhbmQgZHJhZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm8x Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNl cmlmIj4mcXVvdDtGb3IgY29ubmVjdGlvbiBsZXNzIG9yIHN0YXRlbGVzcyB0cmFuc3BvcnQgbGlr ZSBIVFRQLCAmbmJzcDvigKYgdGhhdCB3aWxsIHRlcm1pbmF0ZSBkeW5hbWljIHN1YnNjcmlwdGlv bnMmcXVvdDsgLSBEbyBub3QgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudC4gV2hlbiBpcyB0aGlz IHNlc3Npb24gdGVybWluYXRlZCBpZiBpdCBpcyBjb25uZWN0aW9uIGxlc3MgYW5kL29yIHN0YXRl bGVzcz88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIGNvbm5lY3Rpb25sZXNzIGR5bmFtaWMg c3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQgd2hlbiB0aGVyZSBpcyBsb3NzIGRldGVjdGVkIGJ5 IHRoZSBwdWJsaXNoZXIgb2YNCiBpbmZvcm1hdGlvbiBiZWluZyBzZW50IHRvIHRoZSByZWNlaXZl ci4mbmJzcDsgVGhpcyBjYW4gYmUgdGhlIGxvc3Mgb2YgZWl0aGVyIG5vdGlmaWNhdGlvbiBtZXNz YWdlcyBvciB0cmFuc3BvcnQga2VlcC1hbGl2ZXMuJm5ic3A7IFNwZWNpZmljcyBvZiBob3cgdGhp cyBpcyBkb25lIGlzIHdpdGhpbiBlYWNoIGNvbm5lY3Rpb25sZXNzIHRyYW5zcG9ydCBkcmFmdC4m bmJzcDsmbmJzcDsgU2VlIHByb3Bvc2VkIHRleHQgd2l0aCB5ZWxsb3cgaGlnaGxpZ2h0aW5nIGJl bG93Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+Q29uZmlndXJlZCBzdWJz Y3JpcHRpb25zIGNhbiBiZSBtb2RpZmllZCBieSBhbnkgY29uZmlndXJhdGlvbiBjbGllbnQuIElz IGl0IG5vdCB0aGUgY2FzZSB0aGF0IHRoYXQgc3Vic2NyaXB0aW9uIGlzIGNvbnRyb2xsZWQgYnkg dXNlci9OQUNNIG1vcmUgdGhhbiB3aGV0aGVyIHRoZSBjbGllbnQgaGFzIHRoZSB3cml0ZSBwZXJt aXNzaW9uPyBTYW1lIGlzIHRydWUgZm9yDQogZHluYW1pYyBzdWJzY3JpcHRpb24uPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+TkFDTSBpcyBjZXJ0YWlubHkgYSBnb29kIHdheSB0byBnbyB0byBt ZWV0IHRoZSByZXF1aXJlbWVudC4mbmJzcDsgVGhlIHRleHQgaW50ZW5kIHRvIGFsbG93IGZvciBp bXBsZW1lbnRhdGlvbnMNCiB3aXRob3V0IE5BQ00uJm5ic3A7Jm5ic3A7IEkgc2F3IHRoZSB3b3Jk cyDigJx3cml0ZSBwZXJtaXNzaW9uc+KAnSBhcyBhIG1vcmUgZ2VuZXJhbCB0ZXJtIHdoaWNoIGlz IHRyeWluZyB0byBjb3ZlciBhbnkgc3VjaCBjYXNlIHdoZXJlIGEgY29uZmlndXJhdGlvbiBzeXN0 ZW0gaXMgdHJ5aW5nIHRvIG1ha2UgY2hhbmdlcyB0byB0aGUgY29uZmlndXJhdGlvbiB0cmVlLiBE byB5b3UgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBmb3IgdGhpcyBnZW5lcmFsIGNhc2U/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsNyBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+SXMgdGhlcmUgYSBncmFjZWZ1bCB0ZXJtaW5hdGlv biBvZiBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uPyBEb2VzIG5vdCBzZWVtIGFwcGFyZW50IHJlYWRp bmcgdGhlIHBhcmFncmFwaC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGxpZmV0aW1lIG9mIGEgZHluYW1pYyBzdWJzY3Jp cHRpb24gaXMgYm91bmRlZCBieSB0aGUgdHJhbnNwb3J0IHNlc3Npb24gdXNlZCB0byBlc3RhYmxp c2ggaXQuJm5ic3A7IEZvciBjb25uZWN0aW9uLW9yaWVudGVkIHN0YXRlZnVsIHRyYW5zcG9ydCBs aWtlIE5FVENPTkYsIHRoZSBsb3NzDQogb2YgdGhlIHRyYW5zcG9ydCBzZXNzaW9uIHdpbGwgcmVz dWx0IGluIHRoZSBpbW1lZGlhdGUgdGVybWluYXRpb24gb2YgYXNzb2NpYXRlZCBkeW5hbWljIHN1 YnNjcmlwdGlvbnMuJm5ic3A7IEZvciBjb25uZWN0aW9ubGVzcyBvciBzdGF0ZWxlc3MgdHJhbnNw b3J0cyBsaWtlIEhUVFAsDQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hs aWdodDp5ZWxsb3ciPnNvbWUgbG9zcyBvZiB0cmFmZmljIG11c3QgYmUgZGV0ZWN0ZWQgYmVmb3Jl IHRoZSBkeW5hbWljIHN1YnNjcmlwdGlvbiBzaG91bGQgYmUgdGVybWluYXRlZC4mbmJzcDsgU3Vj aCBsb3NzIG9mIHRyYWZmaWMgY2FuIGJlIGRldGVjdGVkIGluIHdheXMgc3VjaCBhczwvc3Bhbj4g dGhlIGxhY2sgb2YgcmVjZWlwdA0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1o aWdobGlnaHQ6eWVsbG93Ij5UQ1A8L3NwYW4+IGFja25vd2xlZGdlbWVudCBvZiBhIHNlcXVlbnRp YWwgc2V0IG9mIG5vdGlmaWNhdGlvbiBtZXNzYWdlcywNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+b3IgdGhlIGxvc3Mgb2YgdHJhbnNwb3J0PC9z cGFuPiBrZWVwLWFsaXZlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPm88 L3NwYW4+Jm5ic3A7Jm5ic3A7IFRoZSBsaWZldGltZSBvZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0 aW9uIGlzIGRyaXZlbiBieSByZWxldmFudCBjb25maWd1cmF0aW9uIGJlaW5nIHByZXNlbnQgb24g dGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbi4mbmJzcDsgVGhpcyBpbXBsaWVzIGNvbmZpZ3VyZWQg c3Vic2NyaXB0aW9ucyBwZXJzaXN0IGFjcm9zcyByZWJvb3RzLCBhbmQgcGVyc2lzdA0KIGV2ZW4g d2hlbiB0cmFuc3BvcnQgaXMgdW5hdmFpbGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgbyZuYnNwOyBDb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgY2FuIGJlIG1vZGlm aWVkDQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ci Pm9yIHRlcm1pbmF0ZWQ8L3NwYW4+IGJ5IGFueSBjb25maWd1cmF0aW9uIGNsaWVudCB3aXRoIHdy aXRlIHBlcm1pc3Npb24gb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHN1YnNjcmlwdGlvbi4m bmJzcDsgRHluYW1pYyBzdWJzY3JpcHRpb25zIGNhbiBiZSBtb2RpZmllZA0KPHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5vciB0ZXJtaW5hdGVkPC9z cGFuPiB2aWEgYW4gUlBDIHJlcXVlc3QgbWFkZSB1cG9uIHRoZSBvcmlnaW5hbCBzdWJzY3JpYmlu ZyB0cmFuc3BvcnQgc2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+U2VjdGlv biAyLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm8yIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5B cmUgdGhlcmUgbm8gbm90aWZpY2F0aW9ucyBvdmVyIFJFU1RDT05GPyBJZiBzbywgd2h5IGFyZSB0 aGV5IG5vdCBtZW50aW9uZWQgb3ZlciBoZXJlLiBBbmQgYXJlIG5vdGlmaWNhdGlvbnMgYWx3YXlz IGVuY29kZWQgdXNpbmcgWE1MPyBUaGVyZSBpcyBhIHJlZmVyZW5jZSB0byBvdGhlciBmb3JtcyBv ZiBlbmNvZGluZyBpbiBTZWN0aW9uIDQuMSwgdW5kZXIgRHluYW1pYw0KIFN1YnNjcmlwdGlvbnMu IElmIGl0IGlzIHRydWUgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyBhbHNvLCBjb3VsZCBp dCBiZSBzdGF0ZWQgdXAgZnJvbnQ/PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIE5FVENP TkYgZXZlbnQgc3RyZWFtIGlzIGEgbGVnYWN5IG5hbWUgZnJvbSBSRkMtNTI3NyB3aGljaCB0aGlz IGRyYWZ0IGFkb3B0ZWQgZm9yIGNvbnRpbnVpdHnigJlzIHNha2UuJm5ic3A7Jm5ic3A7DQogUkVT VENPTkYgbWF5IGFsc28gc3Vic2NyaWJlIHRvIHRoaXMgZXZlbnQgc3RyZWFtLiZuYnNwOyBEbyB5 b3Ugd2FudCBtZSB0byBzYXkg4oCcVGhlIE5FVENPTkYgZXZlbnQgc3RyZWFtIGlzIHdob2xseSBz ZXBhcmF0ZSBmcm9tIHRoZSB1c2Ugb2YgTkVUQ09ORiBhcyBhIHRyYW5zcG9ydOKAnTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsNSBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+QXJlIHB1Ymxpc2hlciBhbmQgc3lz dGVtIHRoZSBzYW1lIGVudGl0eT8gSWYgbm90LCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlPyBJZiB0 aGV5IGFyZSB0aGUgc2FtZSwgY2FuIHdlIGJlIGNvbnNpc3RlbnQgaW4gdGhlIG5vbWVuY2xhdHVy ZT88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIGNoYW5nZSDigJxTeXN0ZW3igJ0gdG8g 4oCcUHVibGlzaGVy4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPkRvZXNu J3QgTkFDTSBkZWZpbmUgbm90aWZpY2F0aW9uIHBlcm1pc3Npb25zIG9uIHRoZSBwdWJsaXNoZXI/ IFRoZSByZWNlaXZlciBtYXkgbm90IGhhdmUgcGVybWlzc2lvbiBmb3IgZXZlcnkgZXZlbnQgZ2Vu ZXJhdGVkIGJ5IHRoZSBwdWJsaXNoZXIuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnkgZGVm aW5pdGlvbiwgc3Vic2NyaXB0aW9uIHRvIGEgc3RyZWFtIG1lYW5zIGFjY2VzcyB0byBhbGwgZXZl bnRzIG9uIGEgc3RyZWFtLiZuYnNwOyBUaGlzIGlzIGlkZW50aWNhbA0KIHRvIGN1cnJlbnQgNTI3 NyBiZWhhdmlvci4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7 LHNlcmlmIj5TZWN0aW9uIDIuMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHVsIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZv MyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90Oyxz ZXJpZiI+SXNuJ3QgdGhlIGRlZmluaXRpb24gb2YgZmlsdGVyIGp1c3QgdGhhdC4gRG8gbm90IHVu ZGVyc3RhbmQgdGhlIGltcGxpY2F0aW9uIG9mIHRoZSBkZWZpbml0aW9uIG9mIEV2ZW50IEZpbHRl ciBhbmQgaG93IGl0IGlzIGRpZmZlcmVudCBmcm9tIG90aGVyIGZpbHRlcnMuPG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+U2lnbmlmaWNhbnQgdXBkYXRlcyB0byB0aGUgZGVmaW5pdGlvbiBvZiDi gJxTdHJlYW0gZmlsdGVy4oCdIGJhc2VkIG9uIE1hcnRpbuKAmXMgY29tbWVudHMuJm5ic3A7IE5v IGxvbmdlciBkbw0KIHdlIHRyeSB0byBoYXZlIGEgZ2VuZXJpYyBmaWx0ZXIgZGVmaW5pdGlvbiB3 aGljaCBhbHNvIGNvdmVycyBlbGVtZW50cyBvZiB0aGUgU2VsZWN0aW9uIGZpbHRlciBmcm9tIHlh bmctcHVzaC4mbmJzcDsmbmJzcDsgRWFjaCBzdGFuZHMgb24gaXRzIG93biBub3cgKHdpdGggaXRz IG93biBlbnRyeSBpbiBlYWNoIHJlc3BlY3RpdmUgZHJhZnRz4oCZIHRlcm1pbm9sb2d5IHRhYmxl Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPlNl Y3Rpb24gMi4zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5XaGF0 IGNvbnN0aXR1dGVzIGFuICZxdW90O2Fzc2VydGVkIHN1YnNjcmlwdGlvbiB0byBiZSBleHRlcm5h bGx5IHZpc2libGUmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSDigJxlc3RhYmxp c2gtc3Vic2NyaXB0aW9u4oCdIG5lZWRzIGEgc3Vic2NyaXB0aW9uLWlkIHRvIGJlIGFzc2lnbmVk IGJlZm9yZSBpdCBhcHBlYXJzIGluIHRoZSBvcGVyYXRpb25hbA0KIHlhbmctdHJlZS4mbmJzcDsg QSBmYWlsZWQg4oCcZXN0YWJsaXNoLXN1YnNjcmlwdGlvbuKAnSBpcyBuZXZlciBpbnN0YW50aWF0 ZWQgaW4gdGhlIHlhbmcgbW9kZWwuJm5ic3A7IExpa2VseSB0aGlzIGlzIG9idmlvdXMsIGFzIGFu eSBmYWlsZWQgUlBDIHdpbGwgbm90IHJlc3VsdCBpbiB0aGUgY3JlYXRpb24gb2YgbmV3IG9iamVj dHMuJm5ic3A7Jm5ic3A7IEFuZCBpZiB5b3UgZmVlbCB0aGlzIGlzIG9idmlvdXMsIHdlIGNhbiBq dXN0IGRlbGV0ZSB0aGUgc2VudGVuY2UuJm5ic3A7IEJ1dCBpZiB5b3UNCiB3YW50IHRvIGtlZXAg c29tZXRoaW5nIHdlIGNvdWxkIG1vcnBoIHRoZSBzdGF0ZW1lbnQgaW50byB0aGUgZm9sbG93bmcg dGV4dCB0byBjbGFyaWZ5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDoxMC4xNXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5BbmQgc3Vic2NyaXB0aW9uIHN0YXRlIGRv ZXMgbm90IGJlY29tZSBleHBvc2VkIHZpYSB0aGUgWUFORyBtb2RlbCB1bnRpbCB0aGUgc3RhdGUg bWFjaGluZSBmaXJzdCByZWFjaGVzIHRoZSDigJxhY3RpdmXigJ0gc3RhdGUuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5JZiB0 aGUgc3RhdGUgbWFjaGluZSBpcyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgcHVibGlzaGVy LCB0aGVuIGNhbiB0aGUgcHVibGlzaGVyIHVuaWxhdGVyYWxseSAmcXVvdDtzdGFydCZxdW90OyBh IHN1YnNjcmlwdGlvbj8gT3IgaXMgdGhhdCBpdCBzaXRzIGluIGluaXQgc3RhdGUsIHdhaXRpbmcg Zm9yIGEgc3Vic2NyaXB0aW9uIHJlcXVlc3QgdG8gYmUgcmVjZWl2ZWQ/PG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QmFzZWQgb24gTWFydGlu4oCZcyBjb21tZW50cywgdGhlIHN0YXRlIG1hY2hp bmUgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIG5vdyBpcyBtb3JlIGZ1bGx5IGRvY3VtZW50 ZWQuJm5ic3A7DQogSXQgY292ZXJzIHRoaXMgY2FzZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl bDEgbGZvNCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZx dW90OyxzZXJpZiI+Q2FuIGEgcmVjZWl2ZXIgc3VzcGVuZCBzdWJzY3JpcHRpb24gdG8gYW4gZXZl bnQgc3RyZWFtPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo1LjM1cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk5vLiZuYnNwOyZuYnNwOyBDdXJyZW50IHRleHQgc2F5cyDigJxUaGVyZSBhcmUgbm8gZXh0ZXJu YWwgY29udHJvbHMgb3ZlciBzdXNwZW5kIGFuZCByZXN1bWUu4oCdPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPlNlY3Rpb24gMzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPk5vdGUgdGhlIHJl Y2VudCBkaXNjdXNzaW9uIGFyb3VuZCBzaXplIG9mIHRoZSB0cmVlIHRyYXZlcnNpbmcgbXVsdGlw bGUgcGFnZXMuIEluIGdlbmVyYWwgaWYgYSB0cmVlIGRpYWdyYW0gc3BhbnMgbXVsdGlwbGUgcGFn ZXMsIGl0IGxvc2VzIGl0cyByZWFkYWJpbGl0eS4gQ29uc2lkZXIgYnJlYWtpbmcgdXAgdGhlIHRy ZWUgaW50byBtdWx0aXBsZSBwYXJ0cywgcGFydGljdWxhcmx5DQogcnBjIGFuZCBub3RpZmljYXRp b25zIHBhcnRzIG9mIHRoZSB0cmVlLiBBbiBleHBsYW5hdGlvbiBhdCB0aGUgdG9wIG9mIGVhY2gg cGFydCBvZiB0aGUgdHJlZSB3aWxsIGdvIGEgbG9uZyB3YXkgdG93YXJkcyByZWFkYWJpbGl0eS4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGNvdWxkIHB1bGwgdGhlIFJQQyBhbmQg bm90aWZpY2F0aW9uIHRyZWVzIHVuZGVyIGVhY2ggcmVzcGVjdGl2ZSBzZWN0aW9uIHdpdGhpbiB0 aGlzIGRvY3VtZW50IHdpdGhvdXQNCiB0aGlzIGRvY3VtZW504oCZcyBzaXplIGV4cGxvZGluZy4m bmJzcDsgQW5kIEkgJm5ic3A7d291bGQgYWNjZXB0IHdpdGggZG9pbmcgdGhhdC4mbmJzcDsgSG93 ZXZlciB0aGVyZSB3b3VsZCBiZSBpbXBsaWNhdGlvbnMgZm9yIHRoZSB5YW5nLXB1c2ggZG9jdW1l bnQgYXMgdGhlIHlhbmctcHVzaCBkb2N1bWVudCBkb2VzIG5vdCBoYXZlIHNpbWlsYXIgc2VjdGlv bnMgcmUtZXhwbGFpbmluZyBlYWNoIGF1Z21lbnRlZCBSUEMgYW5kIE5vdGlmaWNhdGlvbi4mbmJz cDsgQW5kIHRoZXJlZm9yZQ0KIHRoZXJlIGlzIG5vIGVhc3kgd2F5IHRvIHBhcnRpdGlvbiB0aGF0 IGV2ZW4gbGFyZ2VyIHlhbmctcHVzaCB0cmVlIGludG8gc21hbGwgcG9ydGlvbnMuJm5ic3A7Jm5i c3A7IElmIHlvdSB3YW50IHRvIGdvIGRvd24gdGhpcyBwYXRoLCB3ZSBzaG91bGQgdmFsaWRhdGUg dGhpcyBicm9hZGx5IGFzIEkgYmVsaWV2ZSBpdCBkZXRyYWN0cyBhcyBhIHdob2xlIGZyb20geWFu Zy1wdXNoLiZuYnNwOyZuYnNwOyBNeSBwcmVmZXJlbmNlIGlzIHN0aWxsIGZvciB0aGUgZXhpc3Rp bmcgZG9jdW1lbnQNCiBzdHJ1Y3R1cmUgYmVjYXVzZSBpdCBhbGxvd3MgZWFzeSBjb21wYXJpc29u IHdpdGggdGhlIHlhbmctcHVzaCBkcmFmdC4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl IGZpbmFsIGNob2ljZSBJIGRvbuKAmXQgcmVjb21tZW5kIGlzIHRvIGRvIGEgc2ltaWxhciB0cmVl IHBhcnRpdGlvbmluZyBmb3IgeWFuZy1wdXNoIGFzIHdlbGwuJm5ic3A7IFN1Y2gNCiBhIHBhcnRp dGlvbmluZyB3b3VsZCBzaWduaWZpY2FudGx5IGluY3JlYXNlIHRoZSB5YW5nLXB1c2ggZHJhZnQg c2l6ZSBhbmQgdGV4dCByZWR1bmRhbmN5LiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0Omw0IGxldmVsMSBsZm81Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5XaGF0IGRvZXMgaXQgbWVhbiB0byBoYXZlIGEg 4oCcZmlsdGVyIGlubGluZSBmb3IgZWFjaCBzdWJzY3JpcHRpb27igJ0/IENvdWxkIGl0IGJlIHRo YXQg4oCcRmlsdGVyc+KAnSBhcmUganVzdCBwcmUtZGVmaW5lZCBzZXQgb2YgZmlsdGVycywgd2hp bGUgZXZlcnl0aGluZyBlbHNlIGlzIHNwZWNpZmllZCBhdCB0aGUgdGltZSBvZiBzdWJzY3JpcHRp b24/PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjUuMzVwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91IGFy ZSBjb3JyZWN0LiZuYnNwOyZuYnNwOyBIb3cgYWJvdXQgdGhlIHRleHQgc2F5aW5nJm5ic3A7IOKA nA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5hbHRlcm5hdGl2ZSB0byBkZWZpbmluZw0K PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij50aGUg ZnVsbCBmaWx0ZXIgd2l0aGluPC9zcGFuPiBlYWNoIHN1YnNjcmlwdGlvbi7igJ08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPlNlY3Rpb24gNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzYiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPlRoaXMgc2VjdGlvbiByZXBlYXRz IHRoZSBmYWN0IGhvdyBzdWJzY3JpcHRpb25zIGNhbiBiZSZuYnNwO21vZGlmaWVkLCBkZWxldGVk LCBraWxsZWQgdXNpbmcgdGhlIHNlc3Npb24gdGhhdCB3YXMgdXNlZCB0byBlc3RhYmxpc2ggdGhl IHN1YnNjcmlwdGlvbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+WWVzLiZuYnNwOyZuYnNwOyBUaGUgcmVhc29uIGlzIHRoYXQgb25seSB0aGUga2lsbCBS UEMgY2FuIHJlZmVyZW5jZSBhIHN1YnNjcmlwdGlvbiBjcmVhdGVkIGZyb20gYSBkaWZmZXJlbnQg c2Vzc2lvbi4mbmJzcDsmbmJzcDsgU28gd2UgY2Fu4oCZdCBnZW5lcmFsaXplIHRoaXMgb25jZSBh dCB0aGUgZnJvbnQgb2Ygc2VjdGlvbiA0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzYi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2Vy aWYiPldoYXQgaGFwcGVucyBpZiB0aGUgc2Vzc2lvbiBpdHNlbGYgZ29lcyBhd2F5Pzwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkluIGFsbCBjYXNlcywgdGhlIGxvc3Mgb2YgYSBzZXNzaW9uIGRl bGV0ZXMgdGhlIHN1YnNjcmlwdGlvbi4mbmJzcDsgQnV0IGxvc3Mgb2Ygc2Vzc2lvbiBpcyBtZWFu cyBkaWZmZXJlbnQNCiB0aGluZ3MgZm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQgKE5FVENPTkYpIG9y IGNvbm5lY3Rpb25sZXNzIChIVFRQKS4mbmJzcDsgQXMgYSByZXN1bHQgdGhlIHNwZWNpZmljcyBh cmUgaW4gdGhlIHRyYW5zcG9ydCBkcmFmdHMsIGJ1dCB0aGUgZ2VuZXJhbCBiZWhhdmlvciBpcyBp biB0aGlzIGRvY3VtZW50IGluIHNlY3Rpb24gMS4zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPlNlY3Rpb24gNC4xJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvNyI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+SXNu4oCZdCBy ZXBsYXkgc3Vic2NyaXB0aW9uIGFuZCBub3RpZmljYXRpb24gYSBmdW5jdGlvbiBvZiB0aGUgY2Fw YWJpbGl0eSBvZiB0aGUgcHVibGlzaGVyIGluIGhvdyBtYW55IGhpc3RvcmljYWwgZXZlbnRzIGl0 IGNhbiBob2xkPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5ZZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm83Ij4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj5Xb3VsZCBpdCBub3QgYmUg c2ltcGxlciBmb3IgdGhlIHB1Ymxpc2hlciBhbGwgdGhlIGV2ZW50cyBpdCBoYXMgaW4gaXRzIGhp c3RvcnkgYnVmZmVyIGFuZCBsZXQgdGhlIHN1YnNjcmliZXIgdGhyb3cgYXdheSB3aGF0ZXZlciBp dCBpcyBub3QgaW50ZXJlc3RlZCBpbj8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGF0IHdvdWxkIGRyaXZlIGEgZGlmZmVyZW50IChhbmQgbGVzcyBjYXBh YmxlKSBiZWhhdmlvciB0aGFuIGN1cnJlbnRseSBpbiA1Mjc3LiZuYnNwOyBGb3IgZXhhbXBsZSwg YSBsYXJnZXIgYnVmZmVyIHdvdWxkIHJlc3VsdCBpbiBsb3RzIG9mIG9iamVjdHMgd2hpY2ggYSBz dWJzY3JpYmVyIGRvZXNu4oCZdCB3YW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzci Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2Vy aWYiPldoYXQgaGFwcGVucyBpZiB0aGUgc3Vic2NyaXB0aW9uIHRpbWUgaXMgb2xkZXIgdGhhbiB0 aGUgb2xkZXN0IGV2ZW50IGluIHRoZSBoaXN0b3J5IGJ1ZmZlcj88L3NwYW4+PG86cD48L286cD48 L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGlzIHNlY3Rpb24gaXMgc2lnbmlmaWNhbnRseSB1cGRhdGVkIGJhc2VkIG9uIE1h cnRpbuKAmXMgY29tbWVudHMuJm5ic3A7IFRoZSBlbmhhbmNlbWVudHMgaW5jbHVkZXMgZW5oYW5j ZWQNCiBkZWZpbml0aW9ucyBpbiB0aGUgeWFuZyBtb2RlbCBzaG93aW5nIHdoeSBpdCBpcyBpbXBv cnRhbnQgZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyB0byByZWplY3QgYSBzdWJzY3JpcHRpb24g d2hpY2ggaXMgc2V0IGZvciBvbGRlciB0aGFuIHdoYXQgaXMgaW4gdGhlIGV2ZW50IGJ1ZmZlci4m bmJzcDsgSXQgYWxzbyBkaXNjdXNzZXMgaG93IGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gY2Fu IGJ1ZmZlciBhbmQgcmVwbGF5IGV2ZW50cyByZWNvcmRlZCBkdXJpbmcNCiBhIGJvb3Qgc2VxdWVu Y2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FO ZXVlJnF1b3Q7LHNlcmlmIj5TZWN0aW9uIDQuMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYU5ldWUmcXVvdDssc2VyaWYiPkNhbiB3ZSB1c2UmbmJzcDvigJxjb25maWd1cmVkIHN1YnNj cmlwdGlvbnPigJ0gY29uc2lzdGVudGx5LCBpbnN0ZWFkIG9mIHNvbWV0aW1lcyBzYXlpbmcmbmJz cDvigJxTdWJzY3JpcHRpb25zIGNyZWF0ZWQgYnkgY29uZmlndXJhdGlvbuKAnS4gVGhlIHRlcm0m bmJzcDvigJxjb25maWd1cmVkIHN1YnNjcmlwdGlvbnPigJ0mbmJzcDtzZWVtcyB0byBiZSByZS1p bnRyb2R1Y2VkIGluIFNlY3Rpb24gNSwgd2hlbiBpdCBpcw0KIGRlZmluZWQgaW4gU2VjdGlvbiAx LjIuIFN1Z2dlc3QgcmVtb3ZpbmcgdGhlIHNlY3Rpb24gZGVmaW5pdGlvbi48L3NwYW4+PG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5ZZXMuJm5ic3A7Jm5ic3A7IFdpbGwgbWFrZSB0aGUgY2hhbmdlIGluIHNl Y3Rpb24gNC4yIGFuZCA1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPkFsc28g aWYgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGNhbm5vdCBiZSBtb2RpZmllZCwgd2hpY2ggQlRX IGlzIG5vdCBvYnZpb3VzIHdoeSwNCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SWYgeW91IGFsbG93IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyB0byBtb2Rp ZnkgYmVoYXZpb3Igb2YgYSBkeW5hbWljIHN1YnNjcmlwdGlvbiwgeW91IGdldCBzZXZlcmFsIGNv bnNlcXVlbmNlcyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+KGEpIHRoZSBzdWJzY3JpYmVyIGlzIG5vIGxvbmdlciBhZ3JlZWluZyB0byB3aGF0IHRoZSBz dWJzY3JpcHRpb24gY29udHJhY3QgaW5jbHVkZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjI1aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPihiKSBjb21wbGV4aXR5OiBob3cgd2lsbCB0aGUgcmVjZWl2ZXIga25vdyB0 aGUgc3Vic2NyaXB0aW9uIGhhcyBjaGFuZ2VzIHdpdGhvdXQgYWxzbyBpbXBsZW1lbnRpbmcgdGhl IHN1YnNjcmlwdGlvbi1tb2RpZmllZCBzdGF0ZSBjaGFuZ2Ugbm90aWZpY2F0aW9uLiZuYnNwOyZu YnNwOyBJZiBzZWVtcyBzaW1wbGVyIGp1c3QgdG8ga2lsbA0KIHRoZSBzdWJzY3JpcHRpb24sIGFu ZCBsZXQgdGhlIHN1YnNjcmliZXIgcmVuZWdvdGlhdGUgdGhlIHBhcmFtZXRlcnMgbmV3LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPnRoZW4gaXQgd291bGQgaGVscCB0byBzYXkg dGhhdCB0aGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gbmVlZHMgdG8gYmUgdGVybWluYXRlZCBi eSAmbHQ7ZGVsZXRlLXN1YnNjcmlwdGlvbiZndDsgKD8/KSwgYW5kIGEgbmV3IHN1YnNjcmlwdGlv biBiZSBjcmVhdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCBhZGQgdGhhdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgYWdh aW4hPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYU5ldWUmcXVvdDssc2VyaWYiPk1vcmUgbGF0ZXIuIFRoYW5rcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhTmV1ZSZxdW90OyxzZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_db172d667ba74b98a8cb9f7b1870b910XCHRTP013ciscocom_-- From nobody Thu Nov 9 02:45:14 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46F12F3D0; Thu, 9 Nov 2017 02:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxDv0RToLSvH; Thu, 9 Nov 2017 02:45:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39E112F4EA; Thu, 9 Nov 2017 02:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79817; q=dns/txt; s=iport; t=1510224300; x=1511433900; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=QfKXUubbP1tInZLRySU9E2fsvYIO7NEhR6tlW9Lg95Q=; b=YacHamqgeB/vGk9FlJGEvE8rD0DlSwO27DShZQNjLO/GDNOQNSijk1mb ccvjXK/OQ/2gCP2+iUymoFNQh3WZXGRzba7ZRPYUZTwM2wIEIKQ55YDXN lDeyUfXVCx+wbF6Gh7KP4c0fG9DZCSigT4X2wkNVOzyItm+ZYP1AGHCJF U=; X-Files: dfpcfioondggippe.png : 43605 X-IronPort-AV: E=Sophos;i="5.44,369,1505779200"; d="png'150?scan'150,208,217,150";a="157465" 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; 09 Nov 2017 10:44:58 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA9Aivw1018870; Thu, 9 Nov 2017 10:44:57 GMT To: Andy Bierman , Benoit Claise , NETCONF , Martin Bjorklund Cc: "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> From: Robert Wilton Message-ID: <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> Date: Thu, 9 Nov 2017 10:44:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3982B6BB606B00BA4B0B0454" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 10:45:12 -0000 This is a multi-part message in MIME format. --------------3982B6BB606B00BA4B0B0454 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, It isn't clear to me whether matching a path in NACM either:   (i) Only applies to the specific node, and not any children, or   (ii) Applies to the specific node and all descendant children nodes as well. As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as well? In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states: * The rule does not have a "rule-type" defined or the "rule- type" is "data-node" and the*"path" matches the requested data node*, action node, or notification node. My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system). However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless. E.g. taking this example from appendix B.4: permit-dummy-interface /acme:interfaces/acme:interface[acme:name='dummy'] read update permit Allow the limited and guest groups read and update access to the dummy interface. If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface, this doesn't seem useful. Further comments inline below ... On 08/11/2017 20:05, Andy Bierman wrote: > Hi, > > This change has no impact on the server if /nacm/read-default is "permit". > In that case, the extra read rules for /A and /A/B are not needed. I agree. > An operator worried about read access should set read-default to "deny". I agree.  This is the scenario that I'm considering. > In that case, explicit rules to read /A and /A/B would be needed > in the new NACM. Yes, if the interpretation of the rule is (i) above. Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order). >   The deny rules would not be needed. Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains all children nodes as well.  Perhaps 'A/B/J//*'? If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above. Thanks, Rob > > > Andy > > > On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton > wrote: > > Hi, > > I'm not sure about this change. > > I'm not that familiar with NACM, but if you want to give a > particular set of users read/write access to a subtree, but not > allow them to have any other access to the configuration in the > running datastore then with the existing RFC, that could be > expressed with a single rule (example in 6536bis, appendix B.4) > > With this new change, I think that you may need to configure many > more rules to achieve the same thing.  I think that you would need > to give read access to the top node in the desired path, and then > separate explicit "deny" rules for every sibling child node > walking from the top of the tree down to the data node that > read/write access is actually being given to.  The example below > may explain my understanding better: > > E.g. For a tree of data nodes, rooted at A, if we wanted to give > read/write access only to "J" subtree, and no access for the rest > of the tree then: > >                  A >                  | >         -------------------- >         |      |     |     | >         B      C     D     E >         | >    ----------- >    |   |  |  | >    F   G  H  J >              | >             ... > > > In the old model, I think that the ACL rules would be 1 rules long > (assuming default deny all): >    "read/write 'A/B/J' > > In the new model, I think that the equivalent ACL rules would need > to be 8 rules long (assuming default deny all): >    "read/write 'A/B/J' >    "read A" >    "deny C" >    "deny D" >    "deny E" >    "deny F" >    "deny G" >    "deny H" > > Note, I am assuming that a "path" rule matches for the given path > and all descendant nodes.  The draft doesn't seem to be > particularly clear on this point (it states that the rule applies > when the path matches, but this would seem to be counter > intuitive), and perhaps it could be clarified. > > If this change is allowed, then the example in appendix B.4 looks > like it would need to be fixed, since the "limited-acl" probably > wouldn't give any access at all, unless default read access had > been given. > > But, possibly I'm misunderstanding how this all works!  If so, > apologies for the noise :-) > > Thanks, > Rob > > > On 02/11/2017 14:18, Benoit Claise wrote: >> Dear all, >> >> Here is a major change in draft-ietf-netconf-rfc6536bis, >> suggested by the Security AD Eric Rescola part of the IESG >> review, which I would like to validate with the WG. See >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >> >> >> >> The NETCONF WG was cc'ed for the entire discussion. >> What do you think? I will draw the conclusions by Friday Nov 10th. >> >> Note: If the WG is fine, the next step is to approve this document. >> >> Regards, Benoit >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --------------3982B6BB606B00BA4B0B0454 Content-Type: multipart/related; boundary="------------99D4412EE7C8BE4DD9E6EDE6" --------------99D4412EE7C8BE4DD9E6EDE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

It isn't clear to me whether matching a path in NACM either:
  (i) Only applies to the specific node, and not any children, or
  (ii) Applies to the specific node and all descendant children nodes as well.

As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as well?

In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states: 

        *  The rule does not have a "rule-type" defined or the "rule-
           type" is "data-node" and the "path" matches the requested
           data node, action node, or notification node.

My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system).

However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.

E.g. taking this example from appendix B.4:
       <rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name='dummy']
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Allow the limited and guest groups read
           and update access to the dummy interface.
         </comment>
       </rule>

If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface, this doesn't seem useful.

Further comments inline below ...

On 08/11/2017 20:05, Andy Bierman wrote:
Hi,

This change has no impact on the server if /nacm/read-default is "permit".
In that case, the extra read rules for /A and /A/B are not needed.
I agree.

An operator worried about read access should set read-default to "deny".
I agree.  This is the scenario that I'm considering.

In that case, explicit rules to read /A and /A/B would be needed
in the new NACM.
Yes, if the interpretation of the rule is (i) above.
Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).


  The deny rules would not be needed.
Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains all children nodes as well.  Perhaps 'A/B/J//*'?

If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.

Thanks,
Rob




Andy


On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:

                 A
                 |
        --------------------
        |      |     |     |
        B      C     D     E
        |
   -----------
   |   |  |  |
   F   G  H  J
             |
            ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
   "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
   "read/write 'A/B/J'
   "read A"
   "deny C"
   "deny D"
   "deny E"
   "deny F"
   "deny G"
   "deny H"

Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:18, Benoit Claise wrote:
Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt


The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


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



--------------99D4412EE7C8BE4DD9E6EDE6 Content-Type: image/png; name="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dfpcfioondggippe.png" iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC +YHGlxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL 54BA95WpYrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIg iN2ClI8gCIIgCIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU 1budlnGWW9Ei1mf45fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluG nFMMK91+zhv/yNjzT4Gdo4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pd bo6buif+9eeWtPnXv6CR/FPYc+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJX x1+/P6TX1qbAn3/+DWvTKfuX9bC2S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi6 7wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4jlgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNX ud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllFnBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Y gfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvSS/v9L9HPMFFl8D5zbEGSizUDcgokCKIH 5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrfX8TtVh6W9yB1MxV/iBt3fOpwlw7v XD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbfwKXq6se7Lj//Sj6DlcJB+9FI FUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60IyDIBZ0CCIHpwvuN8FzTL +Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omknOhYrqi1hzNqj2od3 bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyrz1EzN0EQxL84 30WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt4qmnrDDA nL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB+Y7z XTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUj YtyTWcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35 KV73CFvrJiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX 7+JJ7+0z04ZX/O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz +95YmLPx+1/yMeRf4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV0 8idquf+lP/67/LhW/5k2PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE 7PAZOI49IrPfJ0V5TphipXuRygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWR MVfPIN/X+Z9//k1OMc9Qy8DwPJQgCGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/h E8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN 5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggbpHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIR BEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQpH0EQBLErrD2xEgRBEMS2QMpHEARB7Apr T6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjNa2EZnE+HzC6sB2G8LZmOIAhioxiZ 9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZkOoIgiJdH8fl5IxV3NnE+HcYZ UFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw81P7SxDEnpCa9NqqZxOX +jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw81P7SxDEeyJK7IQU Q1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEqyJ0AIcWQVSRJ CimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hCFmMqFlg1 urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1Eu5mm D0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL 3CW0ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YI Wu/yWetq1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/U NHcDNc3Zrp5a5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeI o4gGND27y1MLZvIPuQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t 8ln99duTIAhigLHKlxsiuxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl 1nzKp+Ujaq04WI5YRfkC1crmE9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rr P8E3YwZKFrZvMInH3uVDHQxlDPXk0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+Wb Zk+CIIgB8SYNeZRMve/lwsyUD6sDyNKbUD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPm UTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GDyXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7e C4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht0n0cLKoF63cIZ6B86kCoJV4MtQTbn29p SiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJsQL28FwT1Rv1Afhi4+9NJTcTLV2Ch S5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/SVkpCT7lSubom5cNqpuw8ws0z 7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PBd/P0Ke6NCIUUa39CuSOi 3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3PsSRDEmyA97eGP8seU LP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LPtyT0FMNYVceB kbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIlsPbESiyL J6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST9xEE sW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6C IAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhd Ye2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAI Ylsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGU jyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAI YldYe2IlCIIgiG3h+ZSvKYuiKJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G 0ZRFhxXNtdqM2lZFUVTtau0TPnC8HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5t c2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoOp7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8 XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZ xXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJWVXs7IOu11QsEyzPgUh9ze4nHa46R3CIe 6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62nqaX+mg3/dTr4hHMSfnKjo/d5vwh tJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+fpHwuZFGRuUDKNyb71Sjf+XTw rYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43PBYfEc+bhIX1bHY99vUt9 FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6hTkZi4gcoIxJ/r5K dxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebhdA4T6GBCXa/m 4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjPqJ5hsH0/ 4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+eccfX V9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eT q8ryNyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIg BcgOwM5jqseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCo yc3Yg+mb4O4sGQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqM nJpG051AgFBBv6gExusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3 q5PsRvuI/RbYTUoUbUXOpNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D951McnPo+4BKT5w0x1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82 v7StiIFUJKP+OPY80jwO+yt+UI+40fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olS QvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7 mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yL HfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFpBHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/ t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78FtkNU75gaTX4E61wKzuM2tmCZZ/U uHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTGk+dNAYvyWaGheKR9x8jsrpcP 9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fBAkNsw2smbXDqadsT6e/2 E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/RCreyw6idLVj2SY27 R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFwamQEojxnRP5N zPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9mpPy9d3P 6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRiRVxI /k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+u OW8IKOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnS rUTWXMqXWtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUU egQn2iG9uptBm9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6 FDqO+qs6IE5Gx1NwUD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M 6AmCbeO7RgDYb4Hd5Nu6hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk9 7vNQvuSNAC+Gzo5ZKZ9OTQrynvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBf GylLFahJ+UH0Zh23+2uaLXF8XE11AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQN qCb83Eja0uWpe70K2XlKv5BfWXomxrf/PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOI xz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUv w+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGb xBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq716uQnaf0C/mVpWdifPvfcykJaBfZ TVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7YITnuLn92jTu+voCjO+8/14Ve 4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbEDLLqLxPU6LdOReHOsd/8h 5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/kPK9M0TOFZf4dgaV T7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRBELvCWhMqQRAE QWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q 8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88dwDXu b41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW 38x2fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4Dk Uh+3EeYmNiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tb PMbXnzDyl7pawky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz 9XdGymcJIeWbqAkp33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+ eiIWmT3b6hYgXerjNmb1Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7 Nz4XHBL0eFjcbqvjsa93qY/ir01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP 6o2fLGoR1b5nb5bdL7JfsL/QPPl6Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl 2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3vgm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidw xhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0tedYYCyOZ860qfavR8efv1MPrY6deeeT4fhj6di kdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1 xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmrqm2tcbHGEfVXtdE55O0nLD/dqWw9 TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmWu1+zwvRD+z5g2WfCdQSvCyE+ 5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplThr0U6PiVrUrFWQKbOIiL/ bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0ZvdbmpcXMB2MPVH+vR5 tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbakQfl8/ZoZNgW1 /AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8tUjHVbIm FWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3mxoX F7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDy hWFPP+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+ SH88jjn1pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb 9vSBZ07p6y6CHkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMF rWEA64FfzwTlg3GTRfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3C OMoGosroOhq4wmTK5+rX3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNY l/KZsWIyprFDWBiZb4nyTdFzJsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxh T/N6eTApN9O9HqV83n7NDQfl03VGVvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUb Uz4zVkzGNHYICyPzLVG+KXrORPlAR72Ub54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xp Xi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/ZKN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1 sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq/Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQ ZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3taErw5ucqeS1I+Z7/6mvN8LTib8iXs 47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6FpAReGEmQaWSjkZCWPUFAf1b +NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2KpT/SB1EyOI6gv1ChKZTP pWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj1/9mue6ME2Rv+6+u wHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/tq5eN+r8fTj1z 9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpLWR76wBzK z+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJZI1f R/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq 2NHWxxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNo N4LORLQuu+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p 9mZm2J3hb33R9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa 2NpX2YmpMD7q8ap45F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOr AVK+veCRz3duC3He4lrgZn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4j iHUgUt5WD6FV0h+vDYJ4LtZc5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUW vu+o0H3scW/feUT9erf+EhOwwesUYXzcz3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3 /hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+dtuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W 2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPHzmx467Q1N1UD2x0+dce5JfqLtnFcY3vH Nfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xSvgfwUpTvyW2S8s3fxktTvlVAyrcc ZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVsondpEOogG513UpQgVwfNinPRA0 /KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZrSlFc+IXdFzaKDsB0m3n tPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0YVjPtgBP/oD3LMryO gvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8IR9LTJ5iF+kg GpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO20jalZdmt rURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y4z56 XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK 4E7H1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6Zcp B/sPGHdgh8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f 9egZnpEL+xGVfV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17Zt xU9RyCVU0C8GtZUM7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k 9Hf1F/t50j6efplysP+Acb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6O UD6Z+Zj9Lp/tz+77qkfP8Ixc2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkY ZOgwRodKKCRyUj7TbhHt6YSi40B/3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19Q DuhvYtyBsnhcPJQP91deO+o6msUP8XU6rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1Fnz Dv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPyMMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtD WP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/ gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1n/JlPsY2q2V+DWAy5ZMhyDyUD9kN KjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJlE/VnuqH6Dqd2i9DtfJ0Pp9O t5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2g4qMxNL5lO8RO4eyH6d8 0A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu57E/dHuXzXu+kfE7o lCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6Xz855fRi6oBsc XeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8uP4SUb1q/ YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzdfkLH jaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8 c93f4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+ rqY6Ifr+gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTL RqbdFHNH0p39BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9 cfk5KGw3lXd5GnudL+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0d H1dTnRB9f8BS/1hVfd7WUKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+ 2ci0m2LuSLqzv8DPzfrufqF2kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yh Py4/B4XtpvIu67HX+RL+7L3enXr67AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnz vfD8p849trQrwR7wbnZ7t/4SxASQ8vmQmTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/e zW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Budnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd 3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKV8Gug928tuHxGxoygW//7o1 nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Giw1v7yRLYCeVrShgUzbaTHrc5 Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqKta7TGGtPrM9FW8GgaLad 9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go1rpOH8H+Kd+MbWwn tHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hpMuSQ8j1R/lPk PBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/HhFJyQKfdW L2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9VLsvu l7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fg hEy5t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5 rXJVdb+MxaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI 7eMZFy9GKJ/lJzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18 OgxCz6eDmUB1Ph3GKZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfp GYx1TtButgvlO+V8NmVh6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJd gZ/0vyaO5FzXqD7qL7x/rnedxnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9TH QeilPpoJVJf6OE753HraAHKQnuh4G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw 1jlBu9kulO+Uc22rwtInZTeXfKd/ijpqSBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/ 6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZRUx8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fy oUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgo X9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8fa3rNMZTZ8079IPeHMqn6vTxQkIO SAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIcx4Q+oBPYnp7xhXqqMY3H15Yd V8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGPyxRYlM93X/Jd16g+6m/K 39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+MI4JgXZIDe35XpTP v65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+cmRrEAEk5G6J8 U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM877nn3Ge3P 81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR45DF r6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wq p/S2ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKH YByTuW8jIXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo 2yfRwdua2Bzs5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISN Ph8SfU9AJaSZcvrD8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuX jfp/7tjI8NS2g09OJ0O5WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+O cUzYJzEuc1A+swPQT6D/e69rXB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBB CBt9PiT6noBKSDPl9Ifl5yugnCl6Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZ V69a9f80jHahHXxyOhnKxWLPKvK+FGLp6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87 xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P 9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRqgFRhH+A47g/eV8AI4kWxGuVz7GxGbBgc xx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5ykcQBEEQs2PtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h 7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3/c3UF7JnGmL/8D10Z6dY dhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N33h7PW+U7n8pFI9B4 J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9JL3W1aAQa7yT2 9P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRDIOWbV84W rebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAmljKXk ntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xO hWf4/RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9 ofsfbgeP9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMq BdXN8cLH3fZ3jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nw DL/fIsR2TtoHyrf9E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatw KuKC91+bRtOsiPIVOpbuTnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7o uNv+3nH5dPtJp4J+4QzY+ROPi09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzU fSY8beSo+cuI/BgvdH1tHs+fOmVmk3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp 7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQrq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fA zlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9uOW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1 I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aCPhgysB3C6zDc7VW+/dDFvfClINTCeLu+ fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om6mnbE/ktPA76pY/l5Vlb/YL+7JQz wW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx4GCCCiV+TIXy97+rdoI+GDKw HcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gkGr/GfqJtrENky87xOVP1 tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRFKF/msgxYDUu2YjWI DvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy5ZPUzk35XHoi e0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd6ENAnz4Y Tsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBacduu ndzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgX p56JZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586 VVAcJFyZ8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6 lZNDB8QIZfB4oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQ n5Hd0JosvM+EzYwcNX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2Iosuf LA6nk/ndCbc+BrraZSPkWblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ 0MKhLA994AztbI2LW09oz6aUfqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyM XNfjuFu+vl4DS0yeKj+oFrRGZyypd2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5a Ic/KVVNMwXzfJsukoZZWu95+2fXHdSmOVXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6 Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328RsJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaC eEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKyXrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQx YAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5IOUjJoCUjyDk9marL/F1moTfIrGP Q6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1zIbd9COJ6vZLyEQRBEDvD2hMr QRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAE sS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH7bA+xI7aa5trY+g+ XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jpxgeQWAU7oXyJ zce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9sT4Xic3H trDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8Mc6n g281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b 5bLsflGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl 01jjgvRP43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusO uwlZ+T6y1/vY+2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5V rqruFxV7DfWrKidyNOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1 rTUuSP80bmflyAF2MP0qZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6w m5CV7yN7vY8RMeakfE2pgzsVLfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anW ORoVSJpVIFB9qaVIxMP2gcdt/T+B3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYH J9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4SpzBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97 Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+ 1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJhzgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTL iwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a9d12645kUr7d3scICzNSvjBc6ZdF wmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7YLsh/cM/cJ/v4i37hxLGY0ak vzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZcRUbiXG3OpfyW9s/7fp+ u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VRFF2RDec8NQf1MeWz 7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj2yIT/BNoY/+i 5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583Z6jk/YqC rA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7x/On zkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU 0u/s6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQW krfEh/TMXR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12 s5pP9muf97Fe7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUz KB+sP/ygcsQS9gHHgf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA 8OaXRfXH/RNqA35JXUh4MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xd d0p84CD4YfRrFEVRHMpSB+7Db8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7A Psj+QV7qKf063/3tuEHPqKp69WoMsZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5 /6EsdaKsgwwA/0z4oX1/wHaD9R12S48X6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIri WFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqLb5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fj Bj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jOEHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD +/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6QfXZit+wlPmIFPJD4txP/zMa79fel seKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/Kx63Gtgzvq6kS+/DPfLxbf18a K86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN5aO9aB/2Crmt3eQlvvca 23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQqH0EQBEEshrUnVoIg CILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8g CILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC 2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDl IwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8ST cD4dbk7ZlEVRHE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9 H9SfIJ6ES328OWVbFUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrS qmwfnRdIT5/+CIkenE8HhnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte 4s63Lywwd3YRixn4XOqjIxBqK6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTU dq0+b9X/L3WVo9Y894fr1WbDS9z53hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfD oktEE9udjx4tgEzKN9+yJSnfHFhuCrUf4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ 7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZsyrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0 y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3le85g0yskpaTG8XA6h3Y17eAdF6Bnl+VY Wv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717IczfSMrnu2/Y/iYS1O+/B5YL7p8J /yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH7YpTqupmj0S/zIQu2dGw087+ iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4AD27LMfK8k+AHPlZdutX yNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw/0z4JzEHXmyVT1IB QUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH1V10HKApdWSs WJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S3Kz6hJCM VL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T1iy1 unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQX o3xWqCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5 gL/NQ/mIFJabQpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBM vPKUjGzT6xFH11Wb1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1P pF4VDHf/xCPVrkn5gL/NQ/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGv cyQon8m5kvoYnUB2sNrW5y1O+ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK 51sGSdf3UD675pyU735QxYX+/hZmhOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTp XzWZi/LNm0r46Crfkz/2maB8vvsG9jdSvi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2v VMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOoDL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCA Pl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgEY899A/vb8Iu184xN+bB/EhaWm0LnoXzq /TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/pVzVKNITHUftKsXFyeh4jqIy9Jb5 vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgdb+T6Ndf9VKLvqHrqNiMTjD33 Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9+sN2ZRKY6m7cr9F3coxI 09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx9JQ+Gfrn2LBoSX67 JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmbmmUHwz+JFBaY O/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0BfpCY7b7eqM NxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhlk8Il 9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+ z3oSuwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJX WHtiJQiCIIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhY WFhcZXVuw2IW7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GW aIGU7+nl8uNLURRV/b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp 0mVBPduPpzrq6tyG5b//qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+ u3iltV/F3s9rm/Qlys3+S4z4qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTg p1/1l6eF5vXHLe6//PiyKF+C7f6qvzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3 q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodKW31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71 EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5O SfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198iy2TFgY3X5agQKR8fj29hZTvtQop3zLl iSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjcfFmCApHy+fX0FlK+vZYlWliF8tXD RqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJETp04iH6KQ/NYzy5b8qNTKSeG /vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4CfADm2PpP8QZji46P68uOi Egjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61zrxfndX3PKvxW/XGv rzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt+kP8hI6jgvQx +ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0oimN9uv1n OOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/EuKBi jlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b 11Zfi6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QG llJXIvZtP1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkr xiof1BONC7QDHC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jn NL8FLmGv8hWu68VzXXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef 1VBH6PbvfxwHfdDxBN+z2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7 VYXU/etq139fr9/b9nbwe3sZ2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGB doDjhTQ3/SQlB+jj8odL/dtgWz0WQ1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpX uK4Xz3UtfKLPmW6/tzePFFeCNOil/S7Irnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDI qT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvVFAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5d fnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZPKkp2fVYkpnxYTzQuCTuA8UKaW36SlAP0 8fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjEWGJnzvVi98sud34iKVBHVP7oD96Z UjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF/bXtM0L5/tDrnOP23Drl+17p 2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHleNtN2wcXFaDnjFoYOWE9 0bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6GeE/0WuMRYYmfO9WL3 yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb4bqSbxh3/x8f fcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdD lG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8ZGyTf IjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevow LkVOTMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4 g/6G568fx67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6d YAmZkknV2j8KldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KA YcZvK/VmSh/GpciJSfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/ TD9JyoGUz+EPOpo91cc+Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQ cdjuPJTPeHE28oP2q722aCVGRqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5 VX34VVdffohfgvB6wPCOkFrW7eWIb2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3G Ws9eY8GfbzHHEY5LhvxovKyC/ATISerj8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7v tL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87resjG/Naq/3c0podJwwIq1avyx7ejPGX4bImW A47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo/Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A 0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V/71GSMnxtmvaZ6z17DUW/PkWcxzh uGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVRVN/61+Sc/u+0v9dvsZ4Jv73U v/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVVj77O9706fhOBl/39oqFd U09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4rEP5cCi/3AYGb138 +/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz1rVyWbHtfe6X AsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ55avXWZZo YSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhYWFhe pazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVg YWFheZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv /ShytvOep/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+ LXK27Z6nnMQ+2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/H SVTw8vdv45Tv57fq5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnw uphdzrPL3Hpuxg/bD7tf6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyPar l1rYcjLtWo2H2g/In6tk6TlD6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdG y3qU78GyGOWbWkj55pU/V1mO8n3cIvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76 d1K+efWcofR+0Y3CsFO8f1xYsstm/JCUb137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+K ojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H//jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrj fljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yoHegpjs+fDThC+VLj8sh1MaOcX/WXm5Db f4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrPuCjDbz2UL243sNX9z7RWWJ/OkkVR fHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3WwswyXhpWUr22XY9lWRZc5eZfT x9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLar1XbtyBiLHHKUDkhB5ZB /aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJul8uxPkXXDbLb4OlV 2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+rarj/gePwukD+ 4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t80fGf3wRd /GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsYUb9D 5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+ 4/erJeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2 PCpykxVuGIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE 7ddOH6incoT2a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYL xAnOJjVytIv9EBfTD4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0f LZuifGKVIFi9iUu8UCYpX///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739U f//Pw4mdMtTWD9plqOSgfP0q1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZA jutiZjmh9RJ20/a//PhyfIjy5bab8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue 6HjiukD+4/arJeyfVxajfFFcI5ba7rjFIDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cRO GWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTdhFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu 2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5JtdSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9 Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUoX/0hwrJf9RcZKs1B+bzyU/Whb8xC +Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/qjx+XXz/q+lf98eMSVsvWx0/5 Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v/FR91PQ8lG+ZTzvOQPl0 3yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq2fr4KV/m8i8Yjhy/ WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2ehQxc0Nb2/EzgW Qqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TPdV3MLMeg XtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrUR38T 9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4G u611zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtB u5dvdf2tqk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH8 49uxkJTpH4Ms8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK7 27EVv1b1/9Q3G758VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtV itxdHzgu81wXz5MjBgXYLbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z 6RMOvewXOG7bGfmP06+ebX9feT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plw u2PhGP58i8odFe8lGvqMGHA4SbHdsOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/ gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI36VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2 c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0yccev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8Zco qxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4urLLUZBgvLUwop34uU1Q3OwuIppHwsL1BI +dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQcbfMB3JYWKaWLVO+IQ9pv5scr90+ C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30WFhaW9ymkfC9SVjc4CwsLy84K Kd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2hbUnVoIgCILYFkj5CIIg iF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnPp8MrqUu8JF7vung9 rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF62H79/k1V/ma EoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix6+L1sIqB 155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqTRvBi 18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlD s3r9AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvO WA5WsXefRtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjf m9VuF1F/8ZVNn1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/ Vd0nepHoeF8v6KLctjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV 1fZNi5g+IaeqjPojuuZ0SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68f Yj/XwroGkHwsx+//c6Ebi7sLDZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ 7Onyw6T/GP6J9fTYH9oN62/dGpPds+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+z YhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9Upk vOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA 7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7Qf21T46uVKP7/FP9donJUwRPl/ooI9Ih ernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9VolU/GouFZNvXC9Q1N21YEfbnrREa7 WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQndwPgqsZCD2nX6+QRcTMLUVpqg xY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/4503UH7Qb11z45ulKN7vPP 99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDIbsqRdeL6MfQC0QOU D8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+tu1Itf9xH9G/K 4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67yOwpVy5A UKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmWscQX S8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9e F3O/QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9 /VWp0d5GlVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX67 9EQq12wg5QtjrYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9 LftPtU9/Qt4q34Yo39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2 G7k/dJVci+iywa284jcn5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvji t0tsymfp+WzKp1/mmU75EnJsO9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5q N+nnzf01LfR7FuxR1A6l6zjGHesvkkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylf Uv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19Vt hS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x 5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+ pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W9x8+zbeHwu9dqDQm+dMgCR1P9CDm GfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/haR1mCxLPeEgk5GZqWp552p/pr vWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb15H6ZIgaX1G7e3WsZ2dN Ke8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9PzuwwNypM3WC7Kwbhs9+ 3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1VH0J+VaGqRkNQ qD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4fy/qkdBa CQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6S9lt RH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CL bCk5DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspH EARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASx K6w9sRIEQRDEtkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ 7UJswg2+KrilXQXFTtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb 2lVQ7LS9uE7vYYdxf7Dqv/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6 mPzBYjouP5nPbquSrnexw5g/gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptW vYqeTrTVLVy91EeTP1hMx+Un89ltVdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTl LbI/nw7WSsXjyYzz2W3NxMq3scOIPzxPo+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZ cT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsECyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQO E7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10EBvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ /s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv4bhlGMC/kR2S/oAQMx6c8GnYOXkf gE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+UFsQuvUOwIBI177+rPwbIU6q2 T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9z6suAoP9Rfqb45LSE9lh XMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1Nf0iMl3DcKgzg38gO SX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QUe2ZhXsrXNILo SSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn00GHv1H4 rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i9a03 ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9Mfj AvUEcqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa 5ErdT0I7u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/ KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T 6hh6DiqF5yfsBgfTpDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/Y jJTPvA/g++TGKJ96EPsI5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hc kJ5IDlYGyYf1ZTjbjy9o96akeB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4reww CfmUD9vZQ1GS16/D/vdqppEG3TMenISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXoby oRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9Ot5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8 OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKBLVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH 2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MU CxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXLQTkroFBBTeYHIMx+pfS3EEXpKgSO zwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmU D9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XPPVHGkBFC972E8JdwBwad zlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwuUE/X+khKvg0QwsJ2 L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l7Ya fx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y6/+QcsSx IP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaHJdmH lnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgW pH8lvm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1o Kcc+GfhJSk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJf URTHuja/N+W5n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB 7fDeePDzR7sDKR9BEMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAI glgJKt9z3g/dvDZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdae WAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu8 7c7XwDlrP3fiUeTZufuYIQeEIPaBZ0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFu mHOVrylXi5ntzaZm3YLqfDrM2r2sHZFfZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18Qm sMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URrw3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFi IOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5g XvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzOYaIfSvwT3dItoP4Ox8tmjIok+gX0 zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz3IdhTJjgcGp6aZFBwfDm+sOt UlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXdIWT83B/MS54TuwYP1UWi 5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLoF9A/T1hVddQG9hfp b45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ulqgqvr6T+Y5YI O2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a5Rv0EUo0 pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hPHJcQ 0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQi zf7KDLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXN YBiBYMlYhEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq +oH9I5TPqh/WVcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9 wgFJ1Z+jv6hdJP9TD8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvD cOoefwVrYcX4R1X0A/tHKJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenp G/ep4zLSo97OY/qEA5KqP0d/UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+ cnzz/ZPYGJ75Ll9P+XyJTipSVRHdFilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8 ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRF DHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOi yekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+P e16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgOYbMKp+w1MHHSEjuFflnyS/DogKXR iVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmdLBUxriYcR4892KGXNB8VNPtU 7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y87TNmxDcETeO+27cWfOF fDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHrekEdI7FTLZ+mv1q5e Px/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE94rwzKqUZ8/m ok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+Hk5Y+SC/Y 6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+GqGK7 kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86 vpb8GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6c u3wAgHoo+NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYA rkTphRUAcB7eLzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+s AAAAQF0g5AMAAHApSi+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/z Z9On77XHrvmru1fzBWPy/eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso8 8Pf82fTpe+2xa/5+Pqr5gjH5/vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJM yPfq7sy/6ZvR4Xl1d9EPljz2sA6TvsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a3 5hqXMzjpvsqra07tdiH7r2V8T11F388H82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2 eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51 f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5ENV7O5upuLhnwurjCOnDMX0cjtHdrRE30/ H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc 6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yIO7aUblbXUW6XnaDFLf0cH/NF Lq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1Ln79p/Q25YaBXr8yLmr9 ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU5cjQxpsQ8b6ImHA1 Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yRy2vu/kUY+h/a dhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5hCfmm0mNJ 9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKBM7w8 /vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6X bj/a/N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9i njz7Y7pSbZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU +lV55PrpzRr+LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it 8QlSRk2zEl12diN8denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz2 6V/CK49cvy6PWH9YQxC43RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6 UFd1w20it8YnSBk1zUp02dmN8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob 1t/1mrRx2ad/Ca88cv26PGL9YQ1B4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f 5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9Wvy KPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvbD4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwl B8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNu P9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITgCSO73fDDFUlK0sqN9/5zeE95Qj5B /0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1M03FiZF9Q57v2+iAogeSACDk AkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM7HbDD1ckKUkrN977z+E9 5Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80FSdGDi15vm+jA4oe SAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3bLAT9O0MTXOn l9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLelP7uGBef /jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1PYPRA lsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7 ZdqPNI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6 qw0/xDEh33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MU pRdWAAD4eVj+I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEF AAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0Epezit XfIFa9acdhx8O+xL6AnHJfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zB mjWnHQffDvsSesJxiaHN9wLPsd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNf R9tDbe3qH4jP8+F4owev7n69ewsV9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT /thUvk9QlfqY1QftJn1xOVe/avvY19H2UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5 vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd49ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGO dvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pvZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6 U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+TkTR5jHZV1nqanoR8opz+fvEGmsln MuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe4AQ7YXXQjoaddo9vbD9T7l6/ SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLowak3TR6pXVNKNsDkCufv lcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4DnMykiaP0a7KWk87 kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9oll8wDnGAnrA7a 0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RBTxQ9OPWm ySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto5hd/ lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiG tTEBbXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PF eoaWhT1CWBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2S vbnnhdANS06n/YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJ jdjt4iDki9IqeR3Us9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXT HX+tHisT2BfykfLkQn9/FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz 90GeF77fK5kMa2MC2wl1qxtKbhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDg iOsJjzEBRf34x0Ujjz3Q0CXt2Z8j7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNi PvcIJppm5077GSsiz6XxC44M+dz6dCHrwau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9N nhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uvXd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55 sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ffCvn8iTlySHOTqp//3gj50uTJEfJZcrr7 RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl+furhnxizGXWL99icM2L9dxBId/7 2T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdOkFQ/dRpIo3NzsYugXWDII/dL hjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiWdyV2yvXwIWVpnpYdyi2/ uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedlauzuPCwX5g6e3BH26 UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI/ZJhTiXJjbLk dPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/nY3ncM0X+ TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev3rLJ EzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO 4KF7+yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZD HmteeH+vBPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zc RkVOb7+CzKrwlvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQj eOje/or28ze0j+cz4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68essh jzUvvL9XH3H8p9grJ23XCPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/5 9ZDvdcUPWB9G1pQu8OUg5APVUnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOg EkovrFVBcoQQwgDgR/xyGgBfx2+GfAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAA AC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQ A7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI94ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC 4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5JpWz9ZWzqogRr19tt2tfIbevDOo/kFwAiG v5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yln5y8uuYjD1cZlyr19ut2ZTV+RT3s mkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p68t72SQt4xxv6Scn72f7kYer jEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F50lk+l6hIAtyGfrLyacin UKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYokwG3oJyufhnwKNert 5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdNfPM9vu8vJlxN WVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32NORzjqOS CKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/BHL5y ks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf0 4JlHRHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0 +S05l8d+/v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69 EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9 n92AVjO9ZFdMkOdPkd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJp cy9RVGH6OMq7Ip69EkWfxvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye 2Lm6EeQW9cQnPpfu2osuKXWPNtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDv OGYI+UR9WuPrB3alt6ud+Xo97CI95NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lc op74xOfSXXvRJaXu0YZbY8qppjeKLim70b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+o T2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9TMVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4 pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5 +nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6jahPqu pId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+TzXCqhUlMmoXjoEgnyW3K6XFKW Lsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6symRF+uh50kh3zG/JV/P9UG lQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ8ltyulxSli7J9laC J5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyVfz/VBpUCTv2P xbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+Vc6Ut0iw E/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2kHpxo 9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3 KyL6tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1 Aj38Ngd9jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/ hHwAAAA4LE/zlMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIK AAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+L fL/7G+sHAABQO6UX1pE3+X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+ 2ff9fMQx2gcfg7r6l4MBAABkonzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYn Idn8tV9Wln0CODjrrB8AAMDvccrqObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xse nU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM +cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06yBbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbG kG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNeuvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3 y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWPe4O7XwYDAADgsuR9fQt/9co9fE3L 7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1Lbfb7dY+58ftove00MBsPUkD OFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78 nUyiDns+ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnw dzKJOuy5DnKGfLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnD DrOMy7fMU4367Nb3O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf3 81G//H9/m3p+P9s6uiHJucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQ b6S+kfHzYyFfJlm+Y55q1CfpabMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6Wmz HSHfxBkhn7n7FxGWJvlHfdP0S9oTrYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywf XtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbqQU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOt pum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV 7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F5EJtOUxDe7vdHs9haWW9YGz58XzHCXRr A8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9EVHVZ9tK4ysw1T2Xmv5kveb1k4TD 4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG1vni1nNNdqvW4/2d1PqV1iyz 5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0fT+VYMEZa01oTCv/6u5r U6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+VuunUsYJdGGLNLMv +dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVVe/bqRyuv2bPz d3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7+Vibej8f 8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3Jzz7J 9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7X We8vDW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxq v8TCqj179aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0i q/7xfOotfKUepb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz 6F9tN888NbdVXXquy27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+ sb9mvbLLpUYiRUK+V9d0r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv2 6ietXf72mzwhn8d+ciyOaZwf8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/k S9werGGX79CQzzdP/SGfXH9tdpsr5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2E pKag8puadCT5mVx0VkKUUyvPvaA1bc2oPz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7r mnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNrkId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXn uyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn5GPPbwjOPPE1vDk+NO8sqFX0M7norIQo p1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2vN+R4P5/PZzvu8LEnfpT61xPSlwSE xE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1XZ7fmfPeEfHq/JDR79upHLa/a s/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IXARhispwiJn4sp1mentiq P3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8PhtmTOYINN3W43yG /cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wjltft2fU76R5f kfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUfvfdgW3Fy u0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJM9VE M0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUi fi0E+rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABA XSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClK L6wAAABAXVQS8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0e ll5Ybd5b37mur92hTfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/ V9cU8T2T2u0byZmRj34ppfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/ h8fN1NIL6ybvZ1vE90xqd2glZ0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTn qkev/sCBzfV7WMMvKEI+hHwjCPk+p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O 0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuSTmLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7 UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hye/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7 oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VUu6WoQeyXftxtP+l2NeWo9kvDtHT6fBln 42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23GTh85Zyyxdo5nYit5coHwdfD7UBD DpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjbPjb0M17+eL5nkdPalvSwOV5B 3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeeyfjT5VTnVbilqEPulH3fb T7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u7Pg9dNvtqWTd5aOb Bj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0sj2n9+/fvX99b LRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvtav3Sjrvt x2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ5002Bg jh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd 8afJ1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmf tpPC3bXFRyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02ra YSfiORtNn5qdkCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Q b5/8YT26/cvzxUYKTPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu /PJ/tV2L7UQm2l+v/FrIxzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQ CCf1dhPkT6rH3wOpXa1f2vEd9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGnd nt9Dr92eTZUhny/FR92wKRbyeVOU1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/k k9u15JdDvjzya+36Q75P7CfBrpQYyjtfdoR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJ DfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xorqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ 3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvocfP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43p jbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru4eNin+RCBlUHqZxUvHi8lHYt+UX9 ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb88od86b+HbrvNwhmLp+KacO9j cS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7XDdD/+J4qe1qcia1vG0n wSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7TjXvvx2hXNK/xjO7eu +eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7GM4G2XD36doCm mZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63dBmPi2wn 9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7RwfswtLC9b 7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNx ke2EXhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3ML y8tWuy2/Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAu CkI+AMAVQMgHFkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --------------99D4412EE7C8BE4DD9E6EDE6-- --------------3982B6BB606B00BA4B0B0454-- From nobody Thu Nov 9 05:33:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1A12025C for ; Thu, 9 Nov 2017 05:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAFbGnDXs-pB for ; Thu, 9 Nov 2017 05:32:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565501201FA for ; Thu, 9 Nov 2017 05:32:57 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSG82482; Thu, 09 Nov 2017 13:32:55 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 13:32:45 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 21:32:36 +0800 From: Qin Wu To: Alexander Clemm , Igor Bryskin , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNZXr9TPL6jGGkxQD+oZHaj9SKUGQ== Date: Thu, 9 Nov 2017 13:32:36 +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.28.135] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AC6C8F6nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5A045907.027C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.198, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac6f249a67cc060ff4292c9a64136255 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 13:33:00 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9AC6C8F6nkgeml513mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWxleDoNClRoYXQgaXMgYSBnb29kIGRlc2lnbiBjb25zaWRlcmF0aW9uLCBjb25kaXRpb24gY2hl Y2sgam9iIGlzIG5vdCB0cml2aWFsLiBXaGVuIHlvdSBkZWNvdXBsZSBjb25kaXRpb24gY2hlY2sg ZnJvbSBzbWFydCBmaWx0ZXIsIGRvZXMgdGhpcyBtZWFuIHlvdSBsZWF2ZSBjb25kaXRpb24gY2hl Y2sgdG8gTkVUQ09ORiBrZXJuZWwgdG8gZG8gdGhpcz8NCg0KLVFpbg0Kt6K8/sjLOiBBbGV4YW5k ZXIgQ2xlbW0NCreiy83KsbzkOiAyMDE3xOoxMdTCOcjVIDU6NDQNCsrVvP7IyzogSWdvciBCcnlz a2luIDxJZ29yLkJyeXNraW5AaHVhd2VpLmNvbT47IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29t PjsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgWHVmZW5nX0xpdUBqYWJp bC5jb207IG5ldGNvbmZAaWV0Zi5vcmcNCtb3zOI6IFJFOiBSRTogWUFORyBQVVNIIEJhc2VkIEdl bmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoN CkhpIElnb3IsDQoNCkJ1dCBJIGRvbqGvdCB0aGluayB3ZSB3aWxsIGFzc2VzcyBjb25kaXRpb25z IGFzIHBhcnQgb2Ygc21hcnQgZmlsdGVycy4gICBJTUhPIHRoaXMgc2hvdWxkIGJlIHBhcnQgb2Yg dGhlIGF1dG9tYXRpb24gZnJhbWV3b3JrLiAgSnVzdCB0byBjbGFyaWZ5IHRlcm1pbm9sb2d5LCB0 byBtZSBhbiBldmVudCBpcyBzb21lIGtpbmQgb2YgobBvY2N1cnJlbmNlobEgdGhhdCB5b3UgYXJl IG5vdGlmaWVkIG9mIChzdWNoIGFzIKGwdGhyZXNob2xkIGhhcyBqdXN0IGJlZW4gY3Jvc3NlZKGx LCChsGFuIHVwZGF0ZSB0aGF0IG1lZXRzIGEgc21hcnQgZmlsdGVyIGhhcyBqdXN0IGJlZW4gb2Jz ZXJ2ZWShsSwgobBzb21lIFlBTkcgbm90aWZpY2F0aW9uIGhhcyBqdXN0IGJlZW4gZW1pdHRlZKGx LCBldGMpLCB3aGVyZWFzIHRoZSBjb25kaXRpb24gaXMgYSChsGNoZWNrobEgdGhhdCBpcyBhY3Rp dmVseSBjb25kdWN0ZWQgKHRvIHNlZSBpZiB0aGUgY29uZGl0aW9uIGhvbGRzIHdoZW4gdGhlIGV2 ZW50IHdhcyBvYnNlcnZlZCkuICBTbWFydCBmaWx0ZXJzIG9uIFlBTkctcHVzaCB1cGRhdGVzIHdp bGwgcHJvdmlkZSBmb3IgbWFueSBvZiB0aGUgZXZlbnRzIHRoYXQgdGhlIGF1dG9tYXRpb24gZnJh bWV3b3JrIHdvdWxkIHV0aWxpemUsIGJ1dCB0aGV5IG1heSBub3QgYmUgdGhlIG9ubHkgc291cmNl LCB0aGF0oa9zIGFsbC4NCg0KQmVzdA0KLS0tIEFsZXgNCg0KRnJvbTogSWdvciBCcnlza2luDQpT ZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDExOjEyIEFNDQpUbzogQWxleGFuZGVy IENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20+PjsgSWdvciBCcnlza2luIDxJZ29yLkJyeXNraW5AaHVhd2VpLmNvbTxtYWls dG86SWdvci5Ccnlza2luQGh1YXdlaS5jb20+PjsgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208 bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+OyBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1 YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PjsgWHVmZW5nX0xpdUBqYWJp bC5jb208bWFpbHRvOlh1ZmVuZ19MaXVAamFiaWwuY29tPjsgbmV0Y29uZkBpZXRmLm9yZzxtYWls dG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSRTogWUFORyBQVVNIIEJhc2VkIEdl bmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoN CkhpIEFsZXgsDQoNCkkgZG8gYWdyZWUgd2l0aCB5b3UgdGhhdCBpbiB0aGUgY29udGV4dCBvZiB0 aGUgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24gc21hcnQgZmlsdGVycyB3aWxsIGNvbnRyaWJ1 dGUgY29uZGl0aW9ucyByYXRoZXIgdGhhbiBldmVudHMuIEV2ZW50cyB3aWxsIGJlIGV4cGxpY2l0 bHkgZGVmaW5lZCBieSB0aGUgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24gbW9kZWwocykgYW5k L29yIGFueSBvdGhlciBZQU5HIG1vZGVscyBzdXBwb3J0ZWQgYnkgdGhlIHNlcnZlci4NCg0KSWdv cg0KRnJvbTpBbGV4YW5kZXIgQ2xlbW0NClRvOklnb3IgQnJ5c2tpbixRaW4gV3UsVGlhbnJhbiBa aG91LFh1ZmVuZyBMaXUsbmV0Y29uZkBpZXRmLm9yZywNCkRhdGU6MjAxNy0xMS0wOCAxNDowMDoy NQ0KU3ViamVjdDpSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJv bCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpLA0KDQpBIGZldyBhZGRpdGlvbmFs IGNvbW1lbnRzIGlubGluZSwgPEFMRVg+DQoNClRoYW5rcw0KLS0tIEFsZXgNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZ29yIEJyeXNraW4NCj4gU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyA5OjAwIEFNDQo+IFRvOiBRaW4gV3UgPGJpbGwud3VAaHVh d2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj47IEFsZXhhbmRlciBDbGVtbQ0KPiA8 YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWku Y29tPj47IFRpYW5yYW4gWmhvdQ0KPiA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbTxtYWlsdG86emhv dXRpYW5yYW5AaHVhd2VpLmNvbT4+OyBYdWZlbmcgTGl1IDxYdWZlbmdfTGl1QGphYmlsLmNvbTxt YWlsdG86WHVmZW5nX0xpdUBqYWJpbC5jb20+PjsNCj4gbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFs aXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbg0KPiBQcm9ibGVtIFN0YXRlbWVudA0KPg0K PiBIaSBRaW4sDQo+DQo+IFBsZWFzZSwgc2VlIGluLWxpbmUuDQo+DQo+IElnb3INCj4NCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1DQo+IFNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMDgsIDIwMTcgMTA6MjEgQU0NCj4gVG86IElnb3IgQnJ5c2tpbjsgQWxleGFu ZGVyIENsZW1tOyBUaWFucmFuIFpob3U7IFh1ZmVuZyBMaXU7DQo+IG5ldGNvbmZAaWV0Zi5vcmc8 bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBZQU5HIFBVU0ggQmFzZWQg R2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24NCj4gUHJvYmxlbSBTdGF0ZW1l bnQNCj4NCj4gSW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgZG9lcyBzbWFydCBmaWx0ZXIgbWVhbiB0 aGF0IG5ldGNvbmYgc2VydmVyIHNob3VsZCBiZQ0KPiBzdGF0ZWZ1bCBzaW5jZSBpdCBrZWVwIGEg ZmV3IHN0YXRlIHdoaWxlIHRyYWRpdGlvbmFsIHlhbmcgcHVzaCBkb2Vzbid0IHJlcXVpcmUNCj4g bmV0Y29uZiBzZXZlciB0byBiZSBzdGF0ZWZ1bCwgaS5lLiwgc2hvdWxkIGJlIHN0YXRlbGVzcz8N Cj4NCj4gSUI+PiBZZXMuIEZvciBleGFtcGxlLCBhbiBSUEMgKG9uZSBvZiBwb3NzaWJsZSBnZW5l cmFsaXplZCBhY3Rpb25zKSBvdXRwdXQNCj4gY291bGQgYmUgc3RvcmVkIHRvIGJlIHVzZWQgaW4g c3Vic2VxdWVudCBFQ0FzIChldmVudC1jb25kaXRpb24tYWN0aW9uKS4gVGhlDQo+IG1vZGVscyB3 ZSBoYXZlIGluIG1pbmQgd2lsbCBhbGxvdyBmb3IgbWFuYWdpbmcgYW5kIGFjY2Vzc2luZyBzdWNo IHN0YXRlLg0KDQo8QUxFWD4gWWVzLiAgSnVzdCBob3cgbXVjaCBzdGF0ZSB3ZSB3YW50IHRvIGFs bG93IGlzIG9uZSBvZiB0aGUgaXRlbXMgdGhhdCBuZWVkIHRvIGJlIGRpc2N1c3NlZC4gIEkgYW0g b2YgdGhlIG9waW5pb24gdGhhdCB0aGlzIHNob3VsZCBiZSBsaW1pdGVkIHRvIGEgZmV3IGZyZXF1 ZW50bHkgdXNlZCBzY2VuYXJpb3Mgc3VjaCBhcyB0aHJlc2hvbGQgY3Jvc3NpbmcgYWxlcnRzIGFu ZCBpbi1yYW5nZS9vdXQtb2YtcmFuZ2UgbW9uaXRvcnMuICBCeSBpdHMgbmF0dXJlLCBhIHRocmVz aG9sZCBtb25pdG9yIF9oYXNfIHRvIGJlIHN0YXRlZnVsIChpdCBpcyBub3Qgc3VmZmljaWVudCB0 byBzaW1wbHkgY29tcGFyZSB0aGUgY3VycmVudCB2YWx1ZSBvZiBhIGRhdGEgaXRlbSBhZ2FpbnN0 IHRoZSB0aHJlc2hvbGQsIHlvdSBhbHNvIG5lZWQgdG8ga25vdyBpZiB5b3UgYWxyZWFkeSByZXBv cnRlZCB0aGlzIGVhcmxpZXIgd2l0aG91dCBjbGVhcmluZyB0aGUgY291bnRlciB0aHJlc2hvbGQg aW4gdGhlIG1lYW50aW1lKS4gIFRoaXMgd2lsbCBiZSBzaW1wbHkgcGFydCBvZiB0aGUgZmVhdHVy ZSBvZiB0aGUgc21hcnQgZmlsdGVyIHRoYXQgaXMgY29uZmlndXJlZCB2aWEgTmV0Y29uZi9SZXN0 Y29uZi4gIEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhlIHN0YXRlIGluIHRob3NlIGNhc2VzIHNo b3VsZCBoYXZlIHRvIGJlIGV4dGVybmFsbHkgZXhwb3NlZCAtIGl0IGlzIHNpbXBseSBwYXJ0IG9m IGhvdyB0aGUgZmlsdGVyIGNvbnN0cnVjdCB3b3Jrcy4NCg0KVGhlIG90aGVyIHN0YXRlZnVsIHNj ZW5hcmlvIGN1cnJlbnRseSBkZWZpbmVkIGFzIGluLXNjb3BlIGluIHRoZSBwcm9ibGVtIHN0YXRl bWVudCBpcyB0aGUgInJlY2VudCBoaWdoIHdhdGVyIG1hcmsiIHNjZW5hcmlvLCBpbiB3aGljaCB5 b3Uga2VlcCB0cmFjayBvZiB0aGUgaGlnaCB3YXRlciBtYXJrIGZvciBzb21lIGFtb3VudCBvZiB0 aW1lIGFmdGVyIHdoaWNoIGl0IGlzIGNsZWFyZWQuICAoVGhlIGFuYWxvZ3kgaXMgdGhhdCBvZiBh IGdyYXBoaWMgZXF1YWxpemVyLikNCg0KV2l0aCByZWdhcmRzIHRvIGF1dG9tYXRpb24gYW5kIEVD QSwgSSB3b3VsZCB2aWV3IHNtYXJ0IGZpbHRlcnMgYXMgYW4gaW1wb3J0YW50IHNvdXJjZSBvZiBl dmVudHMsIGJ1dCBub3QgYXMgdGhlIG9ubHkgb25lLiAgVGhlIGludGVudCBoZXJlIGlzIG5vdCB0 byBwcm92aWRlIGEgZ2VuZXJhbCBwcm9ncmFtbWluZyBmcmFtZXdvcmsgdG8gZGVmaW5lIGFueSB0 eXBlIG9mIGV2ZW50cyAtIGFzIG1lbnRpb25lZCBlYXJsaWVyLCB0aGlzIGlzIG5vdCBpbnRlbmRl ZCBhcyBhbiBldmVudCtleHByZXNzaW9uIE1JQiBvciBhbnkgc3VjaCB0aGluZywganVzdCBmcmVx dWVudGx5IG5lZWRlZCBmaWx0ZXJzL2NhdGVnb3JpZXMgb2YgZXZlbnRzIHRoYXQgYXJlIGZhaXJs eSBicm9hZGx5IGFwcGxpY2FibGUgYW5kIHVzZWZ1bC4gIE9idmlvdXNseSwgd2hlcmUgdGhlICJz d2VldCBzcG90IiBsaWVzIGlzIHN1YmplY3QgdG8gZGlzY3Vzc2lvbi4gIFdlIHdvdWxkIGxvdmUg dG8gaGVhciBmZWVkYmFjayBhYm91dCB3aGF0IG90aGVyIGZpbHRlcnMgYXJlIGRlZW1lZCB1c2Vm dWwuDQo8L0FMRVg+DQo+DQo+DQo+IEkgdGhpbmsgc2V0IHRocmVzaG9sZCBmb3IgcGFja2V0IGxv c3Mgb3IgbGF0ZW5jeSBpcyBwcmV0dHkgbXVjaCBjb21tb24gaW4NCj4gbmV0d29yayB0cm91Ymxl IHNob290aW5nLCBzdWNoIHRocmVzaG9sZCBjYW4gYmUgYWxzbyBtb3ZlZCBkb3duIG92ZXINCj4g dGltZS4NCj4gV2hhdCBraW5kIG9mIHRocmVzaG9sZCBjYW4gYmUgc2V0IG1vcmUgZGVwZW5kcyBv biBlbXBpcmljYWwgZXhwZXJpZW5jZS4gSQ0KPiBhbSB3b25kZXJpbmcgaG93IHRoaXMgY2FuIGJl IG1vZGVsZWQgdXNpbmcgWFBBVEggc3RhdGVtZW50IG9yIHNvbWUNCj4gb3RoZXIgbWVjaGFuaXNt Lg0KPg0KPiBJQj4+IEkgbGV0IEFsZXggYW5zd2VyIHRoaXMsIGJ1dCBJIHdvdWxkIGFzc3VtZSB0 aGF0IHRoZSBzbWFydC1maWx0ZXJzDQo+IElCPj4gbW9kZWwgd2lsbCBhbGxvdyBmb3IgY29tcGFy aW5nIGEgZGF0YSBzdGF0ZSBwb2ludGVkIGJ5IFhQYXRoIHdpdGgNCj4gSUI+PiBjb25maWd1cmVk IHRocmVzaG9sZCB2YWx1ZSB0byBldmFsdWF0ZSB0cmlnZ2VyIGNvbmRpdGlvbiAoYW5kIG11Y2gN Cj4gSUI+PiBtb3JlKQ0KDQo8QUxFWD4gV2UgbmVlZCB0byBmaWd1cmUgb3V0IHRoZSBkZXRhaWxz IG9mIHRoZSBmaWx0ZXIgY29uc3RydWN0LiAgSW4gYWRkaXRpb24gdG8gbm9kZSBzZWxlY3Rpb24g YW5kIHZhbHVlL3JhbmdlIGNvbXBhcmlzb24gYWdhaW5zdCBhIHRocmVzaG9sZC9yYW5nZSBleHBy ZXNzaW9uIChzbyBmYXIsIHNvIHN0cmFpZ2h0Zm9yd2FyZCksIHlvdSBuZWVkIHRvIGJlIGFibGUg dG8gc3BlY2lmeSBhIGNvbXBhcmlzb24gYWdhaW5zdCBhIHN0YXRlLCB0byB1cGRhdGUgdGhlIHN0 YXRlIChlLmcuIHRocmVzaG9sZCBjcm9zc2luZyBzZW50IHZzIGNsZWFyZWQsIGN1cnJlbnQgaGln aCB3YXRlciBtYXJrIGV0YyksIHRvIHNwZWNpZnkgYSBjb3VudGVyIC8gY2xlYXIgdGhyZXNob2xk LCBldGMuICAgSSBkb24ndCB0aGluayB0aGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgd2l0aCBYUEFU SCBhbG9uZS4NCi0tLSBBbGV4DQo8L0FMRVg+DQoNCiAocmVtYWluZGVyIG9mIG1lc3NhZ2UgdGhy ZWFkIGRlbGV0ZWQpDQo= --_000_B8F9A780D330094D99AF023C5877DABA9AC6C8F6nkgeml513mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Alex:

That is a good design = consideration, condition check job is not trivial. When you decouple condit= ion check from smart filter, does this mean you leave condition check to NETCONF kernel to do this?

 

-Qin=

=B7=A2=BC=FE=C8=CB: Alexander Clem= m
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2017=C4=EA11=D4=C29=C8=D5 5:44
=CA=D5=BC=FE=C8=CB: Igor Bryskin <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@hu= awei.com>; Tianran Zhou <zhoutianran@huawei.com>; Xufeng_Liu@jabil= .com; netconf@ietf.org
=D6=F7=CC=E2: RE: RE: YANG PUSH Based Generalized Network Control Automation Problem St= atement

 

Hi Igor,

 

But I don=A1=AFt think= we will assess conditions as part of smart filters.   IMHO this = should be part of the automation framework.  Just to clarify terminolo= gy, to me an event is some kind of =A1=B0occurrence=A1=B1 that you are notifie= d of (such as =A1=B0threshold has just been crossed=A1=B1, =A1=B0an update = that meets a smart filter has just been observed=A1=B1, =A1=B0some YANG not= ification has just been emitted=A1=B1, etc), whereas the condition is a =A1=B0check=A1=B1 that is actively conducted (to see if the condition hold= s when the event was observed).  Smart filters on YANG-push updates wi= ll provide for many of the events that the automation framework would utili= ze, but they may not be the only source, that=A1=AFs all. 

 

Best=

--- Alex

 

From: = Igor Bryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@huawei.com>; Tianran Zhou <zhoutianran@hua= wei.com>; Xufeng_Liu@jabil.com; netconf@ietf.org
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor

From:Alexander Clemm

To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufe= ng Liu,netconf@ietf.org,

Date:2017-11-08 14:00:25=

Subject:RE: YANG PUSH Based Generalized Ne= twork Control Automation Problem Statement

 

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.co= m>; Alexander Clemm
> <alexander.clemm@huaw= ei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@j= abil.com>;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

--_000_B8F9A780D330094D99AF023C5877DABA9AC6C8F6nkgeml513mbschi_-- From nobody Thu Nov 9 06:42:44 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB02126CF9 for ; Thu, 9 Nov 2017 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_MIME_MALF=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 OaLkAEaT8M1a for ; Thu, 9 Nov 2017 06:42:40 -0800 (PST) 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 7AFA4124319 for ; Thu, 9 Nov 2017 06:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23538; q=dns/txt; s=iport; t=1510238560; x=1511448160; h=from:to:subject:date:message-id:mime-version; bh=psROYbEK5FzsC2pRUs7bxuga3iMje4s4tbxYeXI3zpY=; b=cEDggQ2KKX7n2oMKdgfJcBGlBfK2NlwTxqOKmX4rhHcX1qPDdon1tGtA +TNGtv5JmH0m01SqO7n+V6eC0e042KVlLTbws1hRV1CD5dqozO0EjbE1+ hkISw6Dvf6b1z4LjUjzUUfp2wAYMhi0Vttg7YGPBsbEzsE0LDKc4huDhZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgB0aARa/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcGRuJweDdplGgVYmiFaNeBCCAQoYAQyER08CGoQbQBcBAQE?= =?us-ascii?q?BAQEBAQFrKIUeAQYBASErIAkUAQgRAwECDQEaAwIEHwYKARQJCgQBEh0EiR5MA?= =?us-ascii?q?xUQqTiCJyaHGQ2DSAEBAQEBAQEBAQEBAQEBAQEBAQEBGQWDMIIHgVSCEguCdoJ?= =?us-ascii?q?rgXUEARIBJhAJFoJfMYIyBYopjmGIVD0Ch2WIHoR5ghWGBYshjGg6iFMCERkBg?= =?us-ascii?q?TgBIAE2gQNuehVJLQGCNoMRgU53AYlFDxiBDAGBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,370,1505779200"; d="scan'208,217";a="316653375" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 14:42:38 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vA9Egcac014453 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Nov 2017 14:42:38 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 9 Nov 2017 09:42:38 -0500 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 09:42:38 -0500 From: "Tim Jenkins (timjenki)" To: "netconf@ietf.org" , "Eric Voit (evoit)" , "mjethanandani@gmail.com" Thread-Topic: Review of subscribed notifications draft (was Re: Netconf Digest, Vol 117, Issue 18) Thread-Index: AQHTWWj89CdYzjnI4EiYODlVaPzUqw== Date: Thu, 9 Nov 2017 14:42:38 +0000 Message-ID: <2DD9D626-6C64-4918-804C-D22A30FD7E00@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: [161.44.212.81] Content-Type: multipart/alternative; boundary="_000_2DD9D6266C644918804CD22A30FD7E00ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Review of subscribed notifications draft (was Re: Netconf Digest, Vol 117, Issue 18) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 14:42:42 -0000 --_000_2DD9D6266C644918804CD22A30FD7E00ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgZW1iZWRkZWQgd2l0aCA8VGltPi4NCg0KDQpGcm9tOiBOZXRjb25mIDxuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAibmV0Y29uZi1yZXF1ZXN0QGlldGYub3Jn IiA8bmV0Y29uZi1yZXF1ZXN0QGlldGYub3JnPg0KUmVwbHktVG86ICJuZXRjb25mQGlldGYub3Jn IiA8bmV0Y29uZkBpZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciA5LCAyMDE3IGF0 IDE6MDQgQU0NClRvOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBOZXRjb25mIERpZ2VzdCwgVm9sIDExNywgSXNzdWUgMTgNCg0KU2VuZCBOZXRjb25mIG1h aWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KICAgICAgICAgICAgICAgIG5ldGNvbmZAaWV0Zi5v cmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmli ZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0Kb3IsIHZpYSBlbWFpbCwgc2Vu ZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQogICAgICAgICAgICAg ICAgbmV0Y29uZi1yZXF1ZXN0QGlldGYub3JnPG1haWx0bzpuZXRjb25mLXJlcXVlc3RAaWV0Zi5v cmc+DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KICAg ICAgICAgICAgICAgIG5ldGNvbmYtb3duZXJAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtb3duZXJA aWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5l IHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBOZXRjb25mIGRp Z2VzdC4uLiINCg0KDQpUb2RheSdzIFRvcGljczoNCg0KICAgMS4gUmU6IFJldmlldyBvZiBzdWJz Y3JpYmVkIG5vdGlmaWNhdGlvbnMgZHJhZnQgKEVyaWMgVm9pdCAoZXZvaXQpKQ0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogVGh1LCA5IE5vdiAyMDE3IDA2OjA0OjE4ICsw MDAwDQpGcm9tOiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2 b2l0QGNpc2NvLmNvbT4+DQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBn bWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4NCkNjOiBuZXRjb25mIDxu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb TmV0Y29uZl0gUmV2aWV3IG9mIHN1YnNjcmliZWQgbm90aWZpY2F0aW9ucyBkcmFmdA0KTWVzc2Fn ZS1JRDogPGRiMTcyZDY2N2JhNzRiOThhOGNiOWY3YjE4NzBiOTEwQFhDSC1SVFAtMDEzLmNpc2Nv LmNvbTxtYWlsdG86ZGIxNzJkNjY3YmE3NGI5OGE4Y2I5ZjdiMTg3MGI5MTBAWENILVJUUC0wMTMu Y2lzY28uY29tPj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiDQoN Ci4uLg0KDQogICogICBBbHNvIGlmIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyBjYW5ub3QgYmUg bW9kaWZpZWQsIHdoaWNoIEJUVyBpcyBub3Qgb2J2aW91cyB3aHksDQpJZiB5b3UgYWxsb3cgY29u ZmlndXJhdGlvbiBvcGVyYXRpb25zIHRvIG1vZGlmeSBiZWhhdmlvciBvZiBhIGR5bmFtaWMgc3Vi c2NyaXB0aW9uLCB5b3UgZ2V0IHNldmVyYWwgY29uc2VxdWVuY2VzIHN1Y2ggYXM6DQooYSkgdGhl IHN1YnNjcmliZXIgaXMgbm8gbG9uZ2VyIGFncmVlaW5nIHRvIHdoYXQgdGhlIHN1YnNjcmlwdGlv biBjb250cmFjdCBpbmNsdWRlcw0KKGIpIGNvbXBsZXhpdHk6IGhvdyB3aWxsIHRoZSByZWNlaXZl ciBrbm93IHRoZSBzdWJzY3JpcHRpb24gaGFzIGNoYW5nZXMgd2l0aG91dCBhbHNvIGltcGxlbWVu dGluZyB0aGUgc3Vic2NyaXB0aW9uLW1vZGlmaWVkIHN0YXRlIGNoYW5nZSBub3RpZmljYXRpb24u ICAgSWYgc2VlbXMgc2ltcGxlciBqdXN0IHRvIGtpbGwgdGhlIHN1YnNjcmlwdGlvbiwgYW5kIGxl dCB0aGUgc3Vic2NyaWJlciByZW5lZ290aWF0ZSB0aGUgcGFyYW1ldGVycyBuZXcuDQoNCjxUaW0+ DQpJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u cyAqY2FuKiBiZSBtb2RpZmllZCwgYnV0IG9ubHkgYnkgbWFuYWdlbWVudCBvcGVyYXRpb25zLiBB bmQgd2hlbiB0aGF0IGhhcHBlbnMsIGlmIHRoZSBtb2RpZmljYXRpb25zIHJlc3VsdCBpbiBhIHN1 YnNjcmlwdGlvbiB0aGF0IGlzIHZhbGlkLCB0aGUgcmVjZWl2ZXJzIGFyZSBub3RpZmllZCBvZiB0 aGUgY2hhbmdlIGJ5IHRoZSB1c2Ugb2YgdGhlICJzdWJzY3JpcHRpb24tbW9kaWZpZWQiIG5vdGlm aWNhdGlvbi4NCjwvVGltPg0KDQogICogICB0aGVuIGl0IHdvdWxkIGhlbHAgdG8gc2F5IHRoYXQg dGhlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIG5lZWRzIHRvIGJlIHRlcm1pbmF0ZWQgYnkgPGRl bGV0ZS1zdWJzY3JpcHRpb24+ICg/PyksIGFuZCBhIG5ldyBzdWJzY3JpcHRpb24gYmUgY3JlYXRl ZC4NCkkgd2lsbCBhZGQgdGhhdC4NCg0KPFRpbT4NCklmIHRoZXkgY2Fubm90LCB0aGVuIHRoYXQg c2hvdWxkIHNheSB0aGF0IHRoZSBkZWxldGlvbiBtdXN0IGJlIGRvbmUgYnkgYSBtYW5hZ2VtZW50 IG9wZXJhdGlvbiwgbm90IGJ5IGRlbGV0ZS1zdWJzY3JpcHRpb24uIERlbGV0ZS1zdWJzY3JpcHRp b24gaXMgdXNhYmxlIG9ubHkgb24gZHluYW1pYyBzdWJzY3JpcHRpb25zLg0KDQpXaGF0IHBlcmhh cHMgY291bGQgYmUgbWFkZSBjbGVhcmVyIGlzIHRoYXQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGhh dmUgbm8gY29uZmlndXJhdGlvbiBkYXRhIGF0IGFsbCBhbmQgY2Fubm90IGJlIGFmZmVjdGVkIGJ5 IG5vcm1hbCBtYW5hZ2VtZW50IG9wZXJhdGlvbnMsIHdoaWNoIGlzIHdoeSB0aGUgUlBDICJraWxs LXN1YnNjcmlwdGlvbiIgd2FzIGNyZWF0ZWQuDQo8L1RpbT4NCg0KVGhhbmtzIGFnYWluIQ0KRXJp Yw0KDQpNb3JlIGxhdGVyLiBUaGFua3MuDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT48bWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0t LS0tLS0tLS0NCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4NClVSTDogPGh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvbmV0Y29uZi9hdHRhY2htZW50cy8y MDE3MTEwOS8zN2NkNGFhYi9hdHRhY2htZW50Lmh0bWw+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0 Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpFbmQgb2YgTmV0Y29uZiBEaWdlc3QsIFZvbCAxMTcsIElzc3VlIDE4DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg== --_000_2DD9D6266C644918804CD22A30FD7E00ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1l bnRzIGVtYmVkZGVkIHdpdGggJmx0O1RpbSZndDsuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+TmV0Y29uZiAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgJnF1b3Q7bmV0Y29uZi1yZXF1ZXN0QGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25m LXJlcXVlc3RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVwbHktVG86IDwvYj4mcXVvdDtuZXRjb25m QGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5UaHVyc2RheSwgTm92ZW1iZXIgOSwgMjAxNyBhdCAxOjA0IEFNPGJyPg0KPGI+VG86IDwvYj4m cXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5OZXRjb25mIERpZ2VzdCwgVm9sIDExNywgSXNzdWUgMTg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlNlbmQg TmV0Y29uZiBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZA aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPlRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2Vi LCB2aXNpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxw JyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bmV0Y29uZi1yZXF1ZXN0QGlldGYub3JnIj5uZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllvdSBjYW4g cmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0Y29uZi1vd25lckBpZXRmLm9yZyI+ bmV0Y29uZi1vd25lckBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+V2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJq ZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dGhh biAmcXVvdDtSZTogQ29udGVudHMgb2YgTmV0Y29uZiBkaWdlc3QuLi4mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5Ub2RheSdzIFRvcGljczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7IDEuIFJlOiBSZXZpZXcgb2Ygc3Vi c2NyaWJlZCBub3RpZmljYXRpb25zIGRyYWZ0IChFcmljIFZvaXQgKGV2b2l0KSk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPk1lc3NhZ2U6IDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRh dGU6IFRodSwgOSBOb3YgMjAxNyAwNjowNDoxOCAmIzQzOzAwMDA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkZyb206ICZxdW90O0VyaWMgVm9pdCAoZXZvaXQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86ZXZvaXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+VG86IE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Q2M6IG5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25m QGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gUmV2aWV3IG9mIHN1YnNjcmliZWQgbm90aWZpY2F0aW9u cyBkcmFmdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TWVzc2FnZS1JRDogJmx0OzxhIGhyZWY9Im1h aWx0bzpkYjE3MmQ2NjdiYTc0Yjk4YThjYjlmN2IxODcwYjkxMEBYQ0gtUlRQLTAxMy5jaXNjby5j b20iPmRiMTcyZDY2N2JhNzRiOThhOGNiOWY3YjE4NzBiOTEwQFhDSC1SVFAtMDEzLmNpc2NvLmNv bTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47 IGNoYXJzZXQ9JnF1b3Q7dXRmLTgmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyombmJzcDsmbmJzcDsgQWxzbyBpZiBjb25m aWd1cmVkIHN1YnNjcmlwdGlvbnMgY2Fubm90IGJlIG1vZGlmaWVkLCB3aGljaCBCVFcgaXMgbm90 IG9idmlvdXMgd2h5LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgeW91IGFsbG93IGNvbmZpZ3Vy YXRpb24gb3BlcmF0aW9ucyB0byBtb2RpZnkgYmVoYXZpb3Igb2YgYSBkeW5hbWljIHN1YnNjcmlw dGlvbiwgeW91IGdldCBzZXZlcmFsIGNvbnNlcXVlbmNlcyBzdWNoIGFzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+KGEpIHRoZSBzdWJzY3JpYmVyIGlzIG5vIGxvbmdlciBhZ3JlZWluZyB0byB3aGF0 IHRoZSBzdWJzY3JpcHRpb24gY29udHJhY3QgaW5jbHVkZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PihiKSBjb21wbGV4aXR5OiBob3cgd2lsbCB0aGUgcmVjZWl2ZXIga25vdyB0aGUgc3Vic2NyaXB0 aW9uIGhhcyBjaGFuZ2VzIHdpdGhvdXQgYWxzbyBpbXBsZW1lbnRpbmcgdGhlIHN1YnNjcmlwdGlv bi1tb2RpZmllZCBzdGF0ZSBjaGFuZ2Ugbm90aWZpY2F0aW9uLiZuYnNwOyZuYnNwOyBJZiBzZWVt cyBzaW1wbGVyIGp1c3QgdG8ga2lsbCB0aGUgc3Vic2NyaXB0aW9uLCBhbmQgbGV0DQogdGhlIHN1 YnNjcmliZXIgcmVuZWdvdGlhdGUgdGhlIHBhcmFtZXRlcnMgbmV3LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbHQ7VGltJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB3YXMgdW5kZXIgdGhlIGlt cHJlc3Npb24gdGhhdCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgKmNhbiogYmUgbW9kaWZpZWQs IGJ1dCBvbmx5IGJ5IG1hbmFnZW1lbnQgb3BlcmF0aW9ucy4gQW5kIHdoZW4gdGhhdCBoYXBwZW5z LCBpZiB0aGUgbW9kaWZpY2F0aW9ucyByZXN1bHQgaW4gYSBzdWJzY3JpcHRpb24gdGhhdCBpcyB2 YWxpZCwgdGhlIHJlY2VpdmVycw0KIGFyZSBub3RpZmllZCBvZiB0aGUgY2hhbmdlIGJ5IHRoZSB1 c2Ugb2YgdGhlICZxdW90O3N1YnNjcmlwdGlvbi1tb2RpZmllZCZxdW90OyBub3RpZmljYXRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbHQ7L1RpbSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7Jm5ic3A7KiZuYnNwOyZuYnNwOyB0aGVuIGl0IHdvdWxkIGhlbHAgdG8gc2F5IHRoYXQg dGhlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIG5lZWRzIHRvIGJlIHRlcm1pbmF0ZWQgYnkgJmx0 O2RlbGV0ZS1zdWJzY3JpcHRpb24mZ3Q7ICg/PyksIGFuZCBhIG5ldyBzdWJzY3JpcHRpb24gYmUg Y3JlYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgd2lsbCBhZGQgdGhhdC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmx0O1RpbSZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklmIHRoZXkgY2Fu bm90LCB0aGVuIHRoYXQgc2hvdWxkIHNheSB0aGF0IHRoZSBkZWxldGlvbiBtdXN0IGJlIGRvbmUg YnkgYSBtYW5hZ2VtZW50IG9wZXJhdGlvbiwgbm90IGJ5IGRlbGV0ZS1zdWJzY3JpcHRpb24uIERl bGV0ZS1zdWJzY3JpcHRpb24gaXMgdXNhYmxlIG9ubHkgb24gZHluYW1pYyBzdWJzY3JpcHRpb25z LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XaGF0IHBlcmhhcHMgY291bGQgYmUgbWFkZSBjbGVhcmVy IGlzIHRoYXQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGhhdmUgbm8gY29uZmlndXJhdGlvbiBkYXRh IGF0IGFsbCBhbmQgY2Fubm90IGJlIGFmZmVjdGVkIGJ5IG5vcm1hbCBtYW5hZ2VtZW50IG9wZXJh dGlvbnMsIHdoaWNoIGlzIHdoeSB0aGUgUlBDICZxdW90O2tpbGwtc3Vic2NyaXB0aW9uJnF1b3Q7 IHdhcyBjcmVhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmx0Oy9UaW0mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPlRoYW5rcyBhZ2FpbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkVyaWM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TW9yZSBsYXRl ci4gVGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9h PiZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJl ZC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VVJMOiAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRjb25mL2F0dGFjaG1lbnRzLzIwMTcxMTA5 LzM3Y2Q0YWFiL2F0dGFjaG1lbnQuaHRtbCI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL2Jyb3dzZS9uZXRjb25mL2F0dGFjaG1lbnRzLzIwMTcxMTA5LzM3Y2Q0YWFiL2F0dGFjaG1l bnQuaHRtbDwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5TdWJqZWN0OiBEaWdlc3QgRm9vdGVy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5OZXRjb25mIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJl Zj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u ZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RW5k IG9mIE5ldGNvbmYgRGlnZXN0LCBWb2wgMTE3LCBJc3N1ZSAxODxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_2DD9D6266C644918804CD22A30FD7E00ciscocom_-- From nobody Thu Nov 9 08:28:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C1D126557 for ; Thu, 9 Nov 2017 08:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_MIME_MALF=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 GFqrwww2hO73 for ; Thu, 9 Nov 2017 08:28:12 -0800 (PST) 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 AA9C91201F2 for ; Thu, 9 Nov 2017 08:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28014; q=dns/txt; s=iport; t=1510244892; x=1511454492; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=OY7Y5m/c/mTpsioOIaSAupXti06O/orhkTDPTpol25g=; b=hy4pqKwj1MpSZiJCJEjT+ISSnoJBAb8qxjuszSLHUnBxrZHqZT2tdJo4 88/FGP6SWpyNgwSSWgDkeBUTAfJxHZ7vwf1BG8b0pUT7XNcEsIcdyDdnZ HMbIyHFRaNHlWhc4kuyE3yin/i+V5Rm7IJ2LPggT6llQO3DlRNJSfKOCL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAACNgARa/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcGRuJweDdoofjyeBfIhWjXgQggEKGAEMhEdPAhqEHT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFHgEBAQQBASEKISAJEgIBCBEDAQEBDQETBwMCAgIfBgoBFAkIA?= =?us-ascii?q?gQBEggVBIkeTAMVEKk2gicmhxkNg0gBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM?= =?us-ascii?q?wggeBVIUTgmuBdQQBEgEmBwkJFoJfgmMFiimOYYhUPQKHZYgehHCCHoYFiyGMa?= =?us-ascii?q?DqIUwIRGQGBOAEfOIEDbnoVSYJkgxGBTncBiUUPGIEMgREBAQE?= X-IronPort-AV: E=Sophos; i="5.44,370,1505779200"; d="scan'208,217"; a="29216938" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Nov 2017 16:28:11 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vA9GSB9I010052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Nov 2017 16:28:11 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 9 Nov 2017 11:28:10 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 11:28:10 -0500 From: "Eric Voit (evoit)" To: "Tim Jenkins (timjenki)" , "netconf@ietf.org" , "mjethanandani@gmail.com" Thread-Topic: Review of subscribed notifications draft (was Re: Netconf Digest, Vol 117, Issue 18) Thread-Index: AQHTWWj89CdYzjnI4EiYODlVaPzUq6MMOtrw Date: Thu, 9 Nov 2017 16:28:10 +0000 Message-ID: References: <2DD9D626-6C64-4918-804C-D22A30FD7E00@cisco.com> In-Reply-To: <2DD9D626-6C64-4918-804C-D22A30FD7E00@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.52.10] Content-Type: multipart/alternative; boundary="_000_ae198a3166064bc3905736b9c4f76b62XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Review of subscribed notifications draft (was Re: Netconf Digest, Vol 117, Issue 18) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:28:16 -0000 --_000_ae198a3166064bc3905736b9c4f76b62XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRpbSBKZW5raW5zICh0aW1qZW5raSkNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciA5LCAyMDE3IDk6NDMgQU0NClRvOiBuZXRjb25mQGlldGYub3JnOyBFcmljIFZvaXQgKGV2b2l0 KSA8ZXZvaXRAY2lzY28uY29tPjsgbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NClN1YmplY3Q6IFJl OiBSZXZpZXcgb2Ygc3Vic2NyaWJlZCBub3RpZmljYXRpb25zIGRyYWZ0ICh3YXMgUmU6IE5ldGNv bmYgRGlnZXN0LCBWb2wgMTE3LCBJc3N1ZSAxOCkNCg0KQ29tbWVudHMgZW1iZWRkZWQgd2l0aCA8 VGltPi4NCg0KDQpGcm9tOiBOZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAibmV0Y29uZi1yZXF1ZXN0 QGlldGYub3JnPG1haWx0bzpuZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmc+IiA8bmV0Y29uZi1yZXF1 ZXN0QGlldGYub3JnPG1haWx0bzpuZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmc+Pg0KUmVwbHktVG86 ICJuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPiIgPG5ldGNvbmZAaWV0 Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KRGF0ZTogVGh1cnNkYXksIE5vdmVtYmVy IDksIDIwMTcgYXQgMTowNCBBTQ0KVG86ICJuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25m QGlldGYub3JnPiIgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0K U3ViamVjdDogTmV0Y29uZiBEaWdlc3QsIFZvbCAxMTcsIElzc3VlIDE4DQoNClNlbmQgTmV0Y29u ZiBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgICAgICAgICBuZXRjb25mQGll dGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJz Y3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQNCiAgICAgICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCm9yLCB2aWEgZW1haWws IHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KICAgICAgICAg ICAgICAgIG5ldGNvbmYtcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1yZXF1ZXN0QGll dGYub3JnPg0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQN CiAgICAgICAgICAgICAgICBuZXRjb25mLW93bmVyQGlldGYub3JnPG1haWx0bzpuZXRjb25mLW93 bmVyQGlldGYub3JnPg0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3Qg bGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgTmV0Y29u ZiBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIFJlOiBSZXZpZXcgb2Yg c3Vic2NyaWJlZCBub3RpZmljYXRpb25zIGRyYWZ0IChFcmljIFZvaXQgKGV2b2l0KSkNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6IFRodSwgOSBOb3YgMjAxNyAwNjowNDox OCArMDAwMA0KRnJvbTogIkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPG1haWx0 bzpldm9pdEBjaXNjby5jb20+Pg0KVG86IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRh bmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQpDYzogbmV0Y29u ZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW05ldGNvbmZdIFJldmlldyBvZiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMgZHJhZnQNCk1l c3NhZ2UtSUQ6IDxkYjE3MmQ2NjdiYTc0Yjk4YThjYjlmN2IxODcwYjkxMEBYQ0gtUlRQLTAxMy5j aXNjby5jb208bWFpbHRvOmRiMTcyZDY2N2JhNzRiOThhOGNiOWY3YjE4NzBiOTEwQFhDSC1SVFAt MDEzLmNpc2NvLmNvbT4+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04 Ig0KDQouLi4NCg0KICAqICAgQWxzbyBpZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgY2Fubm90 IGJlIG1vZGlmaWVkLCB3aGljaCBCVFcgaXMgbm90IG9idmlvdXMgd2h5LA0KSWYgeW91IGFsbG93 IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyB0byBtb2RpZnkgYmVoYXZpb3Igb2YgYSBkeW5hbWlj IHN1YnNjcmlwdGlvbiwgeW91IGdldCBzZXZlcmFsIGNvbnNlcXVlbmNlcyBzdWNoIGFzOg0KKGEp IHRoZSBzdWJzY3JpYmVyIGlzIG5vIGxvbmdlciBhZ3JlZWluZyB0byB3aGF0IHRoZSBzdWJzY3Jp cHRpb24gY29udHJhY3QgaW5jbHVkZXMNCihiKSBjb21wbGV4aXR5OiBob3cgd2lsbCB0aGUgcmVj ZWl2ZXIga25vdyB0aGUgc3Vic2NyaXB0aW9uIGhhcyBjaGFuZ2VzIHdpdGhvdXQgYWxzbyBpbXBs ZW1lbnRpbmcgdGhlIHN1YnNjcmlwdGlvbi1tb2RpZmllZCBzdGF0ZSBjaGFuZ2Ugbm90aWZpY2F0 aW9uLiAgIElmIHNlZW1zIHNpbXBsZXIganVzdCB0byBraWxsIHRoZSBzdWJzY3JpcHRpb24sIGFu ZCBsZXQgdGhlIHN1YnNjcmliZXIgcmVuZWdvdGlhdGUgdGhlIHBhcmFtZXRlcnMgbmV3Lg0KDQo8 VGltPg0KSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBjb25maWd1cmVkIHN1YnNjcmlw dGlvbnMgKmNhbiogYmUgbW9kaWZpZWQsIGJ1dCBvbmx5IGJ5IG1hbmFnZW1lbnQgb3BlcmF0aW9u cy4gQW5kIHdoZW4gdGhhdCBoYXBwZW5zLCBpZiB0aGUgbW9kaWZpY2F0aW9ucyByZXN1bHQgaW4g YSBzdWJzY3JpcHRpb24gdGhhdCBpcyB2YWxpZCwgdGhlIHJlY2VpdmVycyBhcmUgbm90aWZpZWQg b2YgdGhlIGNoYW5nZSBieSB0aGUgdXNlIG9mIHRoZSAic3Vic2NyaXB0aW9uLW1vZGlmaWVkIiBu b3RpZmljYXRpb24uDQoNCjxFcmljPiBZZXMgdGhpcyBpcyBhYnNvbHV0ZWx5IHRoZSBjYXNlLiAg IE5vdGUgbXkgY29tbWVudCB3YXMgYWJvdXQgdXNpbmcgY29uZmlndXJhdGlvbiBvcGVyYXRpb25z IHRvIG1vZGlmeSBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uLg0KDQo8L1RpbT4NCg0KICAqICAgdGhl biBpdCB3b3VsZCBoZWxwIHRvIHNheSB0aGF0IHRoZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBu ZWVkcyB0byBiZSB0ZXJtaW5hdGVkIGJ5IDxkZWxldGUtc3Vic2NyaXB0aW9uPiAoPz8pLCBhbmQg YSBuZXcgc3Vic2NyaXB0aW9uIGJlIGNyZWF0ZWQuDQpJIHdpbGwgYWRkIHRoYXQuDQoNCjxUaW0+ DQpJZiB0aGV5IGNhbm5vdCwgdGhlbiB0aGF0IHNob3VsZCBzYXkgdGhhdCB0aGUgZGVsZXRpb24g bXVzdCBiZSBkb25lIGJ5IGEgbWFuYWdlbWVudCBvcGVyYXRpb24sIG5vdCBieSBkZWxldGUtc3Vi c2NyaXB0aW9uLiBEZWxldGUtc3Vic2NyaXB0aW9uIGlzIHVzYWJsZSBvbmx5IG9uIGR5bmFtaWMg c3Vic2NyaXB0aW9ucy4NCg0KPEVyaWM+IEV4YWN0bHkuICAgV2hhdCBJIG1lYW50IGJ5IOKAnEkg d2lsbCBhZGQgdGhhdOKAnSBpczog4oCcSSB3aWxsIGFkZCBjbGFyaWZpY2F0aW9uIHRoYXQgZGVs ZXRpbmcgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBjYW4gb25seSBiZSBkb25lIGJ5IGRlbGV0 aW5nIHRoYXQgc3Vic2NyaXB0aW9u4oCZcyBjb25maWd1cmF0aW9uLg0KDQpXaGF0IHBlcmhhcHMg Y291bGQgYmUgbWFkZSBjbGVhcmVyIGlzIHRoYXQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGhhdmUg bm8gY29uZmlndXJhdGlvbiBkYXRhIGF0IGFsbCBhbmQgY2Fubm90IGJlIGFmZmVjdGVkIGJ5IG5v cm1hbCBtYW5hZ2VtZW50IG9wZXJhdGlvbnMsIHdoaWNoIGlzIHdoeSB0aGUgUlBDICJraWxsLXN1 YnNjcmlwdGlvbiIgd2FzIGNyZWF0ZWQuDQoNCjxFcmljPiAgVGhpcyBpcyBleGFjdGx5IHdoeSBr aWxsLVJQQyB3YXMgYWRkZWQuICBBbmQgc29tZSB0ZXh0IG9uIHRoaXMgaXMgaW4gU2VjdGlvbiA0 LjQuDQoNCkVyaWMNCjwvVGltPg0KDQpUaGFua3MgYWdhaW4hDQpFcmljDQoNCk1vcmUgbGF0ZXIu IFRoYW5rcy4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208 bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPjxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20+DQoNCi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KQW4gSFRN TCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLg0KVVJMOiA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRjb25mL2F0dGFjaG1lbnRzLzIwMTcxMTA5LzM3Y2Q0YWFi L2F0dGFjaG1lbnQuaHRtbD4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClN1 YmplY3Q6IERpZ2VzdCBGb290ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1h aWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkVuZCBv ZiBOZXRjb25mIERpZ2VzdCwgVm9sIDExNywgSXNzdWUgMTgNCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0K --_000_ae198a3166064bc3905736b9c4f76b62XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IFRpbSBKZW5raW5zICh0aW1qZW5raSkgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBO b3ZlbWJlciA5LCAyMDE3IDk6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc7 IEVyaWMgVm9pdCAoZXZvaXQpICZsdDtldm9pdEBjaXNjby5jb20mZ3Q7OyBtamV0aGFuYW5kYW5p QGdtYWlsLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUmV2aWV3IG9mIHN1YnNjcmliZWQg bm90aWZpY2F0aW9ucyBkcmFmdCAod2FzIFJlOiBOZXRjb25mIERpZ2VzdCwgVm9sIDExNywgSXNz dWUgMTgpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cyBl bWJlZGRlZCB3aXRoICZsdDtUaW0mZ3Q7LjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TmV0Y29uZiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLXJl cXVlc3RAaWV0Zi5vcmciPm5ldGNvbmYtcmVxdWVzdEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpuZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmciPm5ldGNvbmYtcmVxdWVzdEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+UmVwbHktVG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWls dG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDksIDIwMTcgYXQgMTowNCBBTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNv bmZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9y ZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPk5ldGNvbmYg RGlnZXN0LCBWb2wgMTE3LCBJc3N1ZSAxODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TZW5kIE5ldGNvbmYgbWFpbGluZyBsaXN0IHN1Ym1pc3Np b25zIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUg dmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3Vi amVjdCBvciBib2R5ICdoZWxwJyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtcmVxdWVzdEBpZXRmLm9yZyI+bmV0Y29uZi1yZXF1ZXN0 QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtb3duZXJA aWV0Zi5vcmciPm5ldGNvbmYtb3duZXJAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91 ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PnRoYW4gJnF1b3Q7UmU6IENvbnRlbnRzIG9mIE5ldGNvbmYgZGlnZXN0Li4uJnF1b3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+VG9kYXkncyBUb3BpY3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7IDEuIFJlOiBSZXZpZXcgb2Ygc3Vic2NyaWJl ZCBub3RpZmljYXRpb25zIGRyYWZ0IChFcmljIFZvaXQgKGV2b2l0KSk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+TWVzc2FnZTogMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRhdGU6IFRodSwgOSBOb3YgMjAx NyAwNjowNDoxOCAmIzQzOzAwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Gcm9tOiAmcXVvdDtFcmlj IFZvaXQgKGV2b2l0KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ ZXZvaXRAY2lzY28uY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UbzogTWFoZXNoIEpl dGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5t amV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q2M6IG5l dGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYu b3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5TdWJqZWN0OiBSZTogW05ldGNvbmZdIFJl dmlldyBvZiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMgZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5NZXNzYWdlLUlEOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMTcyZDY2N2JhNzRiOThhOGNiOWY3 YjE4NzBiOTEwQFhDSC1SVFAtMDEzLmNpc2NvLmNvbSI+ZGIxNzJkNjY3YmE3NGI5OGE4Y2I5Zjdi MTg3MGI5MTBAWENILVJUUC0wMTMuY2lzY28uY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXRmLTgmcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4uLi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsqJm5ic3A7 Jm5ic3A7IEFsc28gaWYgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGNhbm5vdCBiZSBtb2RpZmll ZCwgd2hpY2ggQlRXIGlzIG5vdCBvYnZpb3VzIHdoeSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JZiB5 b3UgYWxsb3cgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zIHRvIG1vZGlmeSBiZWhhdmlvciBvZiBh IGR5bmFtaWMgc3Vic2NyaXB0aW9uLCB5b3UgZ2V0IHNldmVyYWwgY29uc2VxdWVuY2VzIHN1Y2gg YXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KGEpIHRoZSBzdWJzY3JpYmVyIGlzIG5vIGxvbmdlciBh Z3JlZWluZyB0byB3aGF0IHRoZSBzdWJzY3JpcHRpb24gY29udHJhY3QgaW5jbHVkZXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4oYikgY29tcGxleGl0eTogaG93IHdpbGwgdGhlIHJlY2VpdmVyIGtub3cg dGhlIHN1YnNjcmlwdGlvbiBoYXMgY2hhbmdlcyB3aXRob3V0IGFsc28gaW1wbGVtZW50aW5nIHRo ZSBzdWJzY3JpcHRpb24tbW9kaWZpZWQgc3RhdGUgY2hhbmdlIG5vdGlmaWNhdGlvbi4mbmJzcDsm bmJzcDsgSWYgc2VlbXMgc2ltcGxlciBqdXN0IHRvIGtpbGwgdGhlIHN1YnNjcmlwdGlvbiwgYW5k IGxldCB0aGUNCiBzdWJzY3JpYmVyIHJlbmVnb3RpYXRlIHRoZSBwYXJhbWV0ZXJzIG5ldy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbHQ7VGltJmd0OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgd2FzIHVuZGVy IHRoZSBpbXByZXNzaW9uIHRoYXQgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zICpjYW4qIGJlIG1v ZGlmaWVkLCBidXQgb25seSBieSBtYW5hZ2VtZW50IG9wZXJhdGlvbnMuIEFuZCB3aGVuIHRoYXQg aGFwcGVucywgaWYgdGhlIG1vZGlmaWNhdGlvbnMgcmVzdWx0IGluIGEgc3Vic2NyaXB0aW9uIHRo YXQgaXMgdmFsaWQsIHRoZSByZWNlaXZlcnMgYXJlDQogbm90aWZpZWQgb2YgdGhlIGNoYW5nZSBi eSB0aGUgdXNlIG9mIHRoZSAmcXVvdDtzdWJzY3JpcHRpb24tbW9kaWZpZWQmcXVvdDsgbm90aWZp Y2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsgWWVzIHRo aXMgaXMgYWJzb2x1dGVseSB0aGUgY2FzZS4mbmJzcDsmbmJzcDsgTm90ZSBteSBjb21tZW50IHdh cyBhYm91dCB1c2luZyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMgdG8gbW9kaWZ5IGEgZHluYW1p YyBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbHQ7L1Rp bSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsqJm5ic3A7 Jm5ic3A7IHRoZW4gaXQgd291bGQgaGVscCB0byBzYXkgdGhhdCB0aGUgY29uZmlndXJlZCBzdWJz Y3JpcHRpb24gbmVlZHMgdG8gYmUgdGVybWluYXRlZCBieSAmbHQ7ZGVsZXRlLXN1YnNjcmlwdGlv biZndDsgKD8/KSwgYW5kIGEgbmV3IHN1YnNjcmlwdGlvbiBiZSBjcmVhdGVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPkkgd2lsbCBhZGQgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbHQ7VGltJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHRoZXkgY2Fubm90LCB0aGVuIHRoYXQgc2hvdWxkIHNheSB0 aGF0IHRoZSBkZWxldGlvbiBtdXN0IGJlIGRvbmUgYnkgYSBtYW5hZ2VtZW50IG9wZXJhdGlvbiwg bm90IGJ5IGRlbGV0ZS1zdWJzY3JpcHRpb24uIERlbGV0ZS1zdWJzY3JpcHRpb24gaXMgdXNhYmxl IG9ubHkgb24gZHluYW1pYyBzdWJzY3JpcHRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbHQ7RXJpYyZndDsgRXhhY3RseS4mbmJzcDsmbmJzcDsgV2hhdCBJIG1lYW50IGJ5IOKA nEkgd2lsbCBhZGQgdGhhdOKAnSBpczog4oCcSSB3aWxsIGFkZCBjbGFyaWZpY2F0aW9uIHRoYXQg ZGVsZXRpbmcgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBjYW4gb25seSBiZSBkb25lIGJ5IGRl bGV0aW5nIHRoYXQgc3Vic2NyaXB0aW9u4oCZcyBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5XaGF0IHBlcmhhcHMgY291bGQgYmUgbWFkZSBjbGVhcmVyIGlzIHRoYXQgZHlu YW1pYyBzdWJzY3JpcHRpb25zIGhhdmUgbm8gY29uZmlndXJhdGlvbiBkYXRhIGF0IGFsbCBhbmQg Y2Fubm90IGJlIGFmZmVjdGVkIGJ5IG5vcm1hbCBtYW5hZ2VtZW50IG9wZXJhdGlvbnMsIHdoaWNo IGlzIHdoeSB0aGUgUlBDICZxdW90O2tpbGwtc3Vic2NyaXB0aW9uJnF1b3Q7IHdhcyBjcmVhdGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsmbmJzcDsgVGhpcyBp cyBleGFjdGx5IHdoeSBraWxsLVJQQyB3YXMgYWRkZWQuJm5ic3A7IEFuZCBzb21lIHRleHQgb24g dGhpcyBpcyBpbiBTZWN0aW9uIDQuNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jmx0Oy9UaW0mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+VGhhbmtzIGFnYWluITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkVyaWM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Nb3JlIGxhdGVyLiBUaGFua3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TWFoZXNoIEpl dGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmx0OzxhIGhyZWY9Im1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4tLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5BbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+VVJMOiAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy b3dzZS9uZXRjb25mL2F0dGFjaG1lbnRzLzIwMTcxMTA5LzM3Y2Q0YWFiL2F0dGFjaG1lbnQuaHRt bCI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9uZXRjb25mL2F0dGFj aG1lbnRzLzIwMTcxMTA5LzM3Y2Q0YWFiL2F0dGFjaG1lbnQuaHRtbDwvYT4mZ3Q7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+U3ViamVjdDogRGlnZXN0IEZvb3RlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TmV0Y29uZiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5FbmQgb2YgTmV0Y29uZiBEaWdlc3QsIFZvbCAxMTcsIElzc3VlIDE4PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_ae198a3166064bc3905736b9c4f76b62XCHRTP013ciscocom_-- From nobody Thu Nov 9 08:51:37 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC5127876 for ; Thu, 9 Nov 2017 08:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 pn6vb-wqF8ro for ; Thu, 9 Nov 2017 08:51:30 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE911124C27 for ; Thu, 9 Nov 2017 08:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23731; q=dns/txt; s=iport; t=1510246278; x=1511455878; h=from:subject:to:message-id:date:mime-version; bh=q/m9WU/PiFBDP/ZEPYR9KySLto1unMFzrEG/h8ZEo5Q=; b=MxJl7uXyz+V/QO9pifU8QkgR7Xn177+yNcDL3gFNFqN6d9gnI7y9cR1w KqwGZ81APvLaWCte/8miNrsFotkg0OPi36gFoQgYqnSoNXzstuBhhJ9F/ AvZR+JBLYg5aXZkX753xiOx1APEoGBH1NCNRSedhUZKMBp+f1bkDhhs6v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAABChgRa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEgkKEJIofdKZ9EIIBCoozGAEBAQEBAQEBAWsohUgEa0QCXwE?= =?us-ascii?q?MCAEBih+LcZ1ogW06JoNwAYZ+AQEBBwEBAQEBI4Mwg1uBaSmHZQESAQmDK4JjB?= =?us-ascii?q?YophziQOpR+ghWGBYNgh0GOModwgTkfOEJBbjQhCB0VSYJlhCMBOkGKC4I1AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.44,370,1505779200"; d="scan'208,217";a="119903" 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; 09 Nov 2017 16:51:16 +0000 Received: from [10.63.23.122] (dhcp-ensft1-uk-vla370-10-63-23-122.cisco.com [10.63.23.122]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA9GpGsr013570; Thu, 9 Nov 2017 16:51:16 GMT From: Robert Wilton To: "netconf@ietf.org" , Ladislav Lhotka , Andy Bierman , Martin Bjorklund , Kent Watsen Message-ID: Date: Thu, 9 Nov 2017 16:51:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------263EF75C77336048B5E280C5" Content-Language: en-US Archived-At: Subject: [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:51:33 -0000 This is a multi-part message in MIME format. --------------263EF75C77336048B5E280C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Given some of the feedback related to the complexity of the YANG library bis structure, we have come up with two other possible structures for the YANG library data: (1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure, and arguably simpler. (2) An enhanced version of the structure (1) above, that is also extended to allow the structure to be reused for schema-mount via an augmentation. For reference, at the end of this email, I have also included the tree diagram of the existing YANG library, and the current YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) version. Considering the two new YANG library structures: ------------------------ *(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure.* The main changes are: (i) Split "implemented modules" and "import-only-modules" into two separate lists, making the most important list (i.e. implemented modules) keyed by module name only and hence easier to reference. (ii) Assume modules are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a module is not implemented in). (iii) Assume that features are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a feature is not implemented in). (iv) Deleted module-sets. (v) Datastores are now just a list of supported datastores (that could potentially be extended with further per datastore properties in future). Manually generated tree output for proposed YANG library: module: ietf-yang-library  +--ro yang-library     +--ro modules     |  +--ro module* [name]     |  |  +--ro name           yang:yang-identifier     |  |  +--ro revision?      revision-identifier     |  |  +--ro schema?        inet:uri     |  |  +--ro namespace      inet:uri     |  |  +--ro submodule* [name]     |  |  |  +--ro name        yang:yang-identifier     |  |  |  +--ro revision?   yang:yang-identifier     |  |  |  +--ro schema?     inet:uri     |  |  +--ro not-implemented-in*     |  |  |              -> /yang-library/datastore/name     |  |  +--ro feature* [name]     |  |  |  +--ro name        yang:yang-identifier     |  |  |  +--ro not-implemented-in*     |  |  |              -> /yang-library/datastore/name     |  |  +--ro deviation*     |  |                 -> ../name     |  |     |  +--ro import-only-module* [name revision]     |     +--ro name                yang:yang-identifier     |     +--ro revision            union     |     +--ro schema?             inet:uri     |     +--ro namespace           inet:uri     |     +--ro submodule* [name]     |        +--ro name        yang:yang-identifier     |        +--ro revision    yang:revision-identifier     |        +--ro schema?     inet:uri     +--ro datastore* [name] // Allows future per datastore properties.     |  +--ro name          identityref     +--ro checksum       string ------------------------------ *(2) An enhanced version of the structure (1) above, that is extended to allow the structure to be reused for schema-mount via an augmentation.* This is similar to the structure above, except that the "the set of modules" is contained in a list of named schema (e.g. similar to the schema mount draft), allowing this structure to be re-used for schema mount. Schema mount would be expected to augment yang-library to add in the additional schema mount information.  In the tree diagram, I have shown the schema-mount mount-point augmentation, but not including namespaces yet. Every server would be required to provide at least one schema in the schema list, and the primary schema for the device would always be given the name "primary". module: ietf-yang-library  +--ro yang-library     +--ro schema* [name]     |  +--ro name           string     |  +--ro checksum       string     |  +--ro module* [name]     |  |  +--ro name           yang:yang-identifier     |  |  +--ro revision?      yang:revision-identifier     |  |  +--ro schema?        inet:uri     |  |  +--ro namespace      inet:uri     |  |  +--ro submodule* [name]     |  |  |  +--ro name        yang:yang-identifier     |  |  |  +--ro revision?   yang:yang-identifier     |  |  |  +--ro schema?     inet:uri     |  |  +--ro not-implemented-in*     |  |  |              -> /yang-library/datastore/name     |  |  +--ro feature* [name]     |  |  |  +--ro name        yang:yang-identifier     |  |  |  +--ro not-implemented-in*     |  |  |              -> /yang-library/datastore/name     |  |  +--ro deviation*     |  |  |              -> ../name     |  |  +- schema-mount:mount-point* [label]     |  |     +--ro label         yang:yang-identifier     |  |     +--ro config?       boolean     |  |     +--ro (schema-ref)     |  |        +--:(inline)     |  |        |  +--ro inline?       empty     |  |        +--:(use-schema)     |  |           +--ro use-schema* [name]     |  |              +--ro name     |  |              |       -> /yang-library/schema/name     |  |              +--ro parent-reference* yang:xpath1.0     |  |     |  +--ro import-only-module* [name revision]     |     +--ro name                yang:yang-identifier     |     +--ro revision            union     |     +--ro schema?             inet:uri     |     +--ro namespace           inet:uri     |     +--ro submodule* [name]     |        +--ro name        yang:yang-identifier     |        +--ro revision    yang:revision-identifier     |        +--ro schema?     inet:uri     +--ro datastore* [name] // Allows future per datastore properties.     |  +--ro name          identityref     +--ro checksum       string Please can you provide comments on these structures, in particular: Is this version better (i.e. simpler) that the version currently in draft-ietf-netconf-rfc7895bis-02 (below)? Should we try and make the structure extensible for schema-mount via augmentation (i.e. version (2)), or is it better that schema-mount has its own separate subtree? For reference only I have included the existing YANG library and YANG library bis draft tree diagrams. Thanks, Rob ----------------------------- *** FOR REFERENCE ONLY *** (3)  The current YANG library structure in YANG library bis (draft-ietf-netconf-rfc7895bis-02) module: ietf-yang-library +--ro yang-library +--ro modules | +--ro module* [id] | +--ro id string | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro schema? inet:uri | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--ro deviation* [module] | | +--ro module -> ../../id | +--ro conformance-type enumeration | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro schema? inet:uri +--ro module-sets | +--ro module-set* [id] | +--ro id string | +--ro module* -> ../../../modules/module/id +--ro datastores | +--ro datastore* [name] | +--ro name identityref | +--ro module-set | -> ../../../module-sets/module-set/id +--ro checksum string ----------------------------- *** FOR REFERENCE ONLY *** (4)  The current YANG library structure (RFC 7895) +--ro modules-state +--ro module-set-id string +--ro module* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri +--ro namespace inet:uri +--ro feature* yang:yang-identifier +--ro deviation* [name revision] | +--ro name yang:yang-identifier | +--ro revision union +--ro conformance-type enumeration +--ro submodule* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri --------------263EF75C77336048B5E280C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

Given some of the feedback related to the complexity of the YANG library bis structure, we have come up with two other possible structures for the YANG library data:

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also extended to allow the structure to be reused for schema-mount via an augmentation.

For reference, at the end of this email, I have also included the tree diagram of the existing YANG library, and the current YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) version.

Considering the two new YANG library structures:

------------------------

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure.

The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two separate lists, making the most important list (i.e. implemented modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a module is not implemented in).
(iii) Assume that features are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a feature is not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could potentially be extended with further per datastore properties in future).

Manually generated tree output for proposed YANG library:

module: ietf-yang-library
 +--ro yang-library
    +--ro modules
    |  +--ro module* [name]
    |  |  +--ro name           yang:yang-identifier
    |  |  +--ro revision?      revision-identifier
    |  |  +--ro schema?        inet:uri
    |  |  +--ro namespace      inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema?     inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  |                 -> ../name             
    |  |
    |  +--ro import-only-module* [name revision]
    |     +--ro name                yang:yang-identifier
    |     +--ro revision            union
    |     +--ro schema?             inet:uri
    |     +--ro namespace           inet:uri
    |     +--ro submodule* [name]
    |        +--ro name        yang:yang-identifier
    |        +--ro revision    yang:revision-identifier
    |        +--ro schema?     inet:uri
    +--ro datastore* [name] // Allows future per datastore properties.
    |  +--ro name          identityref
    +--ro checksum       string

------------------------------

(2) An enhanced version of the structure (1) above, that is extended to allow the structure to be reused for schema-mount via an augmentation.

This is similar to the structure above, except that the "the set of modules" is contained in a list of named schema (e.g. similar to the schema mount draft), allowing this structure to be re-used for schema mount.

Schema mount would be expected to augment yang-library to add in the additional schema mount information.  In the tree diagram, I have shown the schema-mount mount-point augmentation, but not including namespaces yet.

Every server would be required to provide at least one schema in the schema list, and the primary schema for the device would always be given the name "primary".

module: ietf-yang-library
 +--ro yang-library
    +--ro schema* [name]
    |  +--ro name           string
    |  +--ro checksum       string
    |  +--ro module* [name]
    |  |  +--ro name           yang:yang-identifier
    |  |  +--ro revision?      yang:revision-identifier
    |  |  +--ro schema?        inet:uri
    |  |  +--ro namespace      inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema?     inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  |  |              -> ../name      
    |  |  +- schema-mount:mount-point* [label]
    |  |     +--ro label         yang:yang-identifier
    |  |     +--ro config?       boolean
    |  |     +--ro (schema-ref)
    |  |        +--:(inline)
    |  |        |  +--ro inline?       empty
    |  |        +--:(use-schema)
    |  |           +--ro use-schema* [name]
    |  |              +--ro name
    |  |              |       -> /yang-library/schema/name
    |  |              +--ro parent-reference*   yang:xpath1.0         
    |  |
    |  +--ro import-only-module* [name revision]
    |     +--ro name                yang:yang-identifier
    |     +--ro revision            union
    |     +--ro schema?             inet:uri
    |     +--ro namespace           inet:uri
    |     +--ro submodule* [name]
    |        +--ro name        yang:yang-identifier
    |        +--ro revision    yang:revision-identifier
    |        +--ro schema?     inet:uri
    +--ro datastore* [name] // Allows future per datastore properties.
    |  +--ro name          identityref
    +--ro checksum       string

Please can you provide comments on these structures, in particular:

Is this version better (i.e. simpler) that the version currently in draft-ietf-netconf-rfc7895bis-02 (below)?

Should we try and make the structure extensible for schema-mount via augmentation (i.e. version (2)), or is it better that schema-mount has its own separate subtree?

For reference only I have included the existing YANG library and YANG library bis draft tree diagrams.

Thanks,
Rob


-----------------------------

*** FOR REFERENCE ONLY ***

(3)  The current YANG library structure in YANG library bis (draft-ietf-netconf-rfc7895bis-02)

   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

-----------------------------

*** FOR REFERENCE ONLY ***

(4)  The current YANG library structure (RFC 7895)

      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri

--------------263EF75C77336048B5E280C5-- From nobody Thu Nov 9 10:51:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40981129504 for ; Thu, 9 Nov 2017 10:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH2WfxJAfn1Z for ; Thu, 9 Nov 2017 10:50:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117601294D8 for ; Thu, 9 Nov 2017 10:50:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSH16065; Thu, 09 Nov 2017 18:50:50 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 18:50:49 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 10:50:42 -0800 From: Alexander Clemm To: Qin Wu , Igor Bryskin , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNZXr9TtBUDrHqNQFassZLcA0NQKAAK+Naw Date: Thu, 9 Nov 2017 18:50:41 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66@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.213.48.60] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A04A38B.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac6f249a67cc060ff4292c9a64136255 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 18:50:57 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66sjceml521mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUWluLA0KDQpNeSB0aGlua2luZyBpcyAoYWx0aG91Z2ggSWdvciBvciBYdWZlbmcgbWF5IHdh bnQgdG8gY2hpbWUgaW4gaGVyZSkgdGhhdCB0aGlzIHdpbGwgYmUgcGFydCBvZiB0aGUgYXV0b21h dGlvbiBmcmFtZXdvcmsuICBXZSB3b3VsZCBub3QgYWZmZWN0IE5ldGNvbmYuICBOb3QgZXZlcnkg ZGV2aWNlIHdpbGwgaW1wbGVtZW50IHRoZSBhdXRvbWF0aW9uICBmcmFtZXdvcms7IHRob3NlIHRo YXQgZG8gd2lsbCBuZWVkIHRvIGFkZHJlc3MgdGhpcy4gIEluIG15IG9waW5pb24sIHdlIG5lZWQg dG8gbG9vayBmb3Igc2ltcGxlIHNvbHV0aW9ucywgd2hpY2ggbWVhbnMgdGhhdCB0aGUgY29tcGxl eGl0eSBvZiBjb25kaXRpb25zIGJlaW5nIGNoZWNrZWQgc2hvdWxkIGJlIGNvbnN0cmFpbmVkICh5 b3Ugd2lsbCBub3QgdXNlIHRoaXMgdG8gcHJvZ3JhbSBhcmJpdHJhcnkgY3VzdG9tIGRlY2lzaW9u IGxvZ2ljLCBqdXN0IHNpbXBsZSAocHJlc3VtYWJseSBzdGF0ZWxlc3MpIGNoZWNrcyBzdWNoIGFz IGV4aXN0ZW5jZSBvciB2YWx1ZSByYW5nZXMgb2YgY2VydGFpbiBvYmplY3RzICkuICBUaG9zZSBh cmUgc29tZSBvZiB0aGUgdGhpbmdzIHRoYXQgd2Ugd2lsbCBuZWVkIHRvIHdvcmsgb3V0IHRoZXJl Lg0KDQotLS0gQWxleA0KDQpGcm9tOiBRaW4gV3UNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAw OSwgMjAxNyA1OjMzIEFNDQpUbzogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVh d2VpLmNvbT47IElnb3IgQnJ5c2tpbiA8SWdvci5Ccnlza2luQGh1YXdlaS5jb20+OyBUaWFucmFu IFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+OyBYdWZlbmdfTGl1QGphYmlsLmNvbTsgbmV0 Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFJFOiBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6 ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24gUHJvYmxlbSBTdGF0ZW1lbnQNCg0KQWxleDoN ClRoYXQgaXMgYSBnb29kIGRlc2lnbiBjb25zaWRlcmF0aW9uLCBjb25kaXRpb24gY2hlY2sgam9i IGlzIG5vdCB0cml2aWFsLiBXaGVuIHlvdSBkZWNvdXBsZSBjb25kaXRpb24gY2hlY2sgZnJvbSBz bWFydCBmaWx0ZXIsIGRvZXMgdGhpcyBtZWFuIHlvdSBsZWF2ZSBjb25kaXRpb24gY2hlY2sgdG8g TkVUQ09ORiBrZXJuZWwgdG8gZG8gdGhpcz8NCg0KLVFpbg0Kt6K8/sjLOiBBbGV4YW5kZXIgQ2xl bW0NCreiy83KsbzkOiAyMDE3xOoxMdTCOcjVIDU6NDQNCsrVvP7IyzogSWdvciBCcnlza2luIDxJ Z29yLkJyeXNraW5AaHVhd2VpLmNvbTxtYWlsdG86SWdvci5Ccnlza2luQGh1YXdlaS5jb20+Pjsg UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+OyBU aWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1 YXdlaS5jb20+PjsgWHVmZW5nX0xpdUBqYWJpbC5jb208bWFpbHRvOlh1ZmVuZ19MaXVAamFiaWwu Y29tPjsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCtb3zOI6IFJF OiBSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0 aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIElnb3IsDQoNCkJ1dCBJIGRvbqGvdCB0aGluayB3 ZSB3aWxsIGFzc2VzcyBjb25kaXRpb25zIGFzIHBhcnQgb2Ygc21hcnQgZmlsdGVycy4gICBJTUhP IHRoaXMgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGF1dG9tYXRpb24gZnJhbWV3b3JrLiAgSnVzdCB0 byBjbGFyaWZ5IHRlcm1pbm9sb2d5LCB0byBtZSBhbiBldmVudCBpcyBzb21lIGtpbmQgb2YgobBv Y2N1cnJlbmNlobEgdGhhdCB5b3UgYXJlIG5vdGlmaWVkIG9mIChzdWNoIGFzIKGwdGhyZXNob2xk IGhhcyBqdXN0IGJlZW4gY3Jvc3NlZKGxLCChsGFuIHVwZGF0ZSB0aGF0IG1lZXRzIGEgc21hcnQg ZmlsdGVyIGhhcyBqdXN0IGJlZW4gb2JzZXJ2ZWShsSwgobBzb21lIFlBTkcgbm90aWZpY2F0aW9u IGhhcyBqdXN0IGJlZW4gZW1pdHRlZKGxLCBldGMpLCB3aGVyZWFzIHRoZSBjb25kaXRpb24gaXMg YSChsGNoZWNrobEgdGhhdCBpcyBhY3RpdmVseSBjb25kdWN0ZWQgKHRvIHNlZSBpZiB0aGUgY29u ZGl0aW9uIGhvbGRzIHdoZW4gdGhlIGV2ZW50IHdhcyBvYnNlcnZlZCkuICBTbWFydCBmaWx0ZXJz IG9uIFlBTkctcHVzaCB1cGRhdGVzIHdpbGwgcHJvdmlkZSBmb3IgbWFueSBvZiB0aGUgZXZlbnRz IHRoYXQgdGhlIGF1dG9tYXRpb24gZnJhbWV3b3JrIHdvdWxkIHV0aWxpemUsIGJ1dCB0aGV5IG1h eSBub3QgYmUgdGhlIG9ubHkgc291cmNlLCB0aGF0oa9zIGFsbC4NCg0KQmVzdA0KLS0tIEFsZXgN Cg0KRnJvbTogSWdvciBCcnlza2luDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3 IDExOjEyIEFNDQpUbzogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNv bTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PjsgSWdvciBCcnlza2luIDxJZ29y LkJyeXNraW5AaHVhd2VpLmNvbTxtYWlsdG86SWdvci5Ccnlza2luQGh1YXdlaS5jb20+PjsgUWlu IFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+OyBUaWFu cmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdl aS5jb20+PjsgWHVmZW5nX0xpdUBqYWJpbC5jb208bWFpbHRvOlh1ZmVuZ19MaXVAamFiaWwuY29t PjsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0 aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhpIEFsZXgsDQoNCkkgZG8gYWdyZWUgd2l0aCB5b3Ug dGhhdCBpbiB0aGUgY29udGV4dCBvZiB0aGUgbmV0d29yayBjb250cm9sIGF1dG9tYXRpb24gc21h cnQgZmlsdGVycyB3aWxsIGNvbnRyaWJ1dGUgY29uZGl0aW9ucyByYXRoZXIgdGhhbiBldmVudHMu IEV2ZW50cyB3aWxsIGJlIGV4cGxpY2l0bHkgZGVmaW5lZCBieSB0aGUgbmV0d29yayBjb250cm9s IGF1dG9tYXRpb24gbW9kZWwocykgYW5kL29yIGFueSBvdGhlciBZQU5HIG1vZGVscyBzdXBwb3J0 ZWQgYnkgdGhlIHNlcnZlci4NCg0KSWdvcg0KRnJvbTpBbGV4YW5kZXIgQ2xlbW0NClRvOklnb3Ig QnJ5c2tpbixRaW4gV3UsVGlhbnJhbiBaaG91LFh1ZmVuZyBMaXUsbmV0Y29uZkBpZXRmLm9yZywN CkRhdGU6MjAxNy0xMS0wOCAxNDowMDoyNQ0KU3ViamVjdDpSRTogWUFORyBQVVNIIEJhc2VkIEdl bmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoN CkhpLA0KDQpBIGZldyBhZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZSwgPEFMRVg+DQoNClRoYW5r cw0KLS0tIEFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJZ29y IEJyeXNraW4NCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyA5OjAwIEFNDQo+ IFRvOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29t Pj47IEFsZXhhbmRlciBDbGVtbQ0KPiA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRv OmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj47IFRpYW5yYW4gWmhvdQ0KPiA8emhvdXRpYW5y YW5AaHVhd2VpLmNvbTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4+OyBYdWZlbmcgTGl1 IDxYdWZlbmdfTGl1QGphYmlsLmNvbTxtYWlsdG86WHVmZW5nX0xpdUBqYWJpbC5jb20+PjsNCj4g bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6 IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbg0K PiBQcm9ibGVtIFN0YXRlbWVudA0KPg0KPiBIaSBRaW4sDQo+DQo+IFBsZWFzZSwgc2VlIGluLWxp bmUuDQo+DQo+IElnb3INCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog UWluIFd1DQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDgsIDIwMTcgMTA6MjEgQU0NCj4g VG86IElnb3IgQnJ5c2tpbjsgQWxleGFuZGVyIENsZW1tOyBUaWFucmFuIFpob3U7IFh1ZmVuZyBM aXU7DQo+IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1Ympl Y3Q6IFJFOiBZQU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9t YXRpb24NCj4gUHJvYmxlbSBTdGF0ZW1lbnQNCj4NCj4gSW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwg ZG9lcyBzbWFydCBmaWx0ZXIgbWVhbiB0aGF0IG5ldGNvbmYgc2VydmVyIHNob3VsZCBiZQ0KPiBz dGF0ZWZ1bCBzaW5jZSBpdCBrZWVwIGEgZmV3IHN0YXRlIHdoaWxlIHRyYWRpdGlvbmFsIHlhbmcg cHVzaCBkb2Vzbid0IHJlcXVpcmUNCj4gbmV0Y29uZiBzZXZlciB0byBiZSBzdGF0ZWZ1bCwgaS5l Liwgc2hvdWxkIGJlIHN0YXRlbGVzcz8NCj4NCj4gSUI+PiBZZXMuIEZvciBleGFtcGxlLCBhbiBS UEMgKG9uZSBvZiBwb3NzaWJsZSBnZW5lcmFsaXplZCBhY3Rpb25zKSBvdXRwdXQNCj4gY291bGQg YmUgc3RvcmVkIHRvIGJlIHVzZWQgaW4gc3Vic2VxdWVudCBFQ0FzIChldmVudC1jb25kaXRpb24t YWN0aW9uKS4gVGhlDQo+IG1vZGVscyB3ZSBoYXZlIGluIG1pbmQgd2lsbCBhbGxvdyBmb3IgbWFu YWdpbmcgYW5kIGFjY2Vzc2luZyBzdWNoIHN0YXRlLg0KDQo8QUxFWD4gWWVzLiAgSnVzdCBob3cg bXVjaCBzdGF0ZSB3ZSB3YW50IHRvIGFsbG93IGlzIG9uZSBvZiB0aGUgaXRlbXMgdGhhdCBuZWVk IHRvIGJlIGRpc2N1c3NlZC4gIEkgYW0gb2YgdGhlIG9waW5pb24gdGhhdCB0aGlzIHNob3VsZCBi ZSBsaW1pdGVkIHRvIGEgZmV3IGZyZXF1ZW50bHkgdXNlZCBzY2VuYXJpb3Mgc3VjaCBhcyB0aHJl c2hvbGQgY3Jvc3NpbmcgYWxlcnRzIGFuZCBpbi1yYW5nZS9vdXQtb2YtcmFuZ2UgbW9uaXRvcnMu ICBCeSBpdHMgbmF0dXJlLCBhIHRocmVzaG9sZCBtb25pdG9yIF9oYXNfIHRvIGJlIHN0YXRlZnVs IChpdCBpcyBub3Qgc3VmZmljaWVudCB0byBzaW1wbHkgY29tcGFyZSB0aGUgY3VycmVudCB2YWx1 ZSBvZiBhIGRhdGEgaXRlbSBhZ2FpbnN0IHRoZSB0aHJlc2hvbGQsIHlvdSBhbHNvIG5lZWQgdG8g a25vdyBpZiB5b3UgYWxyZWFkeSByZXBvcnRlZCB0aGlzIGVhcmxpZXIgd2l0aG91dCBjbGVhcmlu ZyB0aGUgY291bnRlciB0aHJlc2hvbGQgaW4gdGhlIG1lYW50aW1lKS4gIFRoaXMgd2lsbCBiZSBz aW1wbHkgcGFydCBvZiB0aGUgZmVhdHVyZSBvZiB0aGUgc21hcnQgZmlsdGVyIHRoYXQgaXMgY29u ZmlndXJlZCB2aWEgTmV0Y29uZi9SZXN0Y29uZi4gIEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhl IHN0YXRlIGluIHRob3NlIGNhc2VzIHNob3VsZCBoYXZlIHRvIGJlIGV4dGVybmFsbHkgZXhwb3Nl ZCAtIGl0IGlzIHNpbXBseSBwYXJ0IG9mIGhvdyB0aGUgZmlsdGVyIGNvbnN0cnVjdCB3b3Jrcy4N Cg0KVGhlIG90aGVyIHN0YXRlZnVsIHNjZW5hcmlvIGN1cnJlbnRseSBkZWZpbmVkIGFzIGluLXNj b3BlIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBpcyB0aGUgInJlY2VudCBoaWdoIHdhdGVyIG1h cmsiIHNjZW5hcmlvLCBpbiB3aGljaCB5b3Uga2VlcCB0cmFjayBvZiB0aGUgaGlnaCB3YXRlciBt YXJrIGZvciBzb21lIGFtb3VudCBvZiB0aW1lIGFmdGVyIHdoaWNoIGl0IGlzIGNsZWFyZWQuICAo VGhlIGFuYWxvZ3kgaXMgdGhhdCBvZiBhIGdyYXBoaWMgZXF1YWxpemVyLikNCg0KV2l0aCByZWdh cmRzIHRvIGF1dG9tYXRpb24gYW5kIEVDQSwgSSB3b3VsZCB2aWV3IHNtYXJ0IGZpbHRlcnMgYXMg YW4gaW1wb3J0YW50IHNvdXJjZSBvZiBldmVudHMsIGJ1dCBub3QgYXMgdGhlIG9ubHkgb25lLiAg VGhlIGludGVudCBoZXJlIGlzIG5vdCB0byBwcm92aWRlIGEgZ2VuZXJhbCBwcm9ncmFtbWluZyBm cmFtZXdvcmsgdG8gZGVmaW5lIGFueSB0eXBlIG9mIGV2ZW50cyAtIGFzIG1lbnRpb25lZCBlYXJs aWVyLCB0aGlzIGlzIG5vdCBpbnRlbmRlZCBhcyBhbiBldmVudCtleHByZXNzaW9uIE1JQiBvciBh bnkgc3VjaCB0aGluZywganVzdCBmcmVxdWVudGx5IG5lZWRlZCBmaWx0ZXJzL2NhdGVnb3JpZXMg b2YgZXZlbnRzIHRoYXQgYXJlIGZhaXJseSBicm9hZGx5IGFwcGxpY2FibGUgYW5kIHVzZWZ1bC4g IE9idmlvdXNseSwgd2hlcmUgdGhlICJzd2VldCBzcG90IiBsaWVzIGlzIHN1YmplY3QgdG8gZGlz Y3Vzc2lvbi4gIFdlIHdvdWxkIGxvdmUgdG8gaGVhciBmZWVkYmFjayBhYm91dCB3aGF0IG90aGVy IGZpbHRlcnMgYXJlIGRlZW1lZCB1c2VmdWwuDQo8L0FMRVg+DQo+DQo+DQo+IEkgdGhpbmsgc2V0 IHRocmVzaG9sZCBmb3IgcGFja2V0IGxvc3Mgb3IgbGF0ZW5jeSBpcyBwcmV0dHkgbXVjaCBjb21t b24gaW4NCj4gbmV0d29yayB0cm91YmxlIHNob290aW5nLCBzdWNoIHRocmVzaG9sZCBjYW4gYmUg YWxzbyBtb3ZlZCBkb3duIG92ZXINCj4gdGltZS4NCj4gV2hhdCBraW5kIG9mIHRocmVzaG9sZCBj YW4gYmUgc2V0IG1vcmUgZGVwZW5kcyBvbiBlbXBpcmljYWwgZXhwZXJpZW5jZS4gSQ0KPiBhbSB3 b25kZXJpbmcgaG93IHRoaXMgY2FuIGJlIG1vZGVsZWQgdXNpbmcgWFBBVEggc3RhdGVtZW50IG9y IHNvbWUNCj4gb3RoZXIgbWVjaGFuaXNtLg0KPg0KPiBJQj4+IEkgbGV0IEFsZXggYW5zd2VyIHRo aXMsIGJ1dCBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZSBzbWFydC1maWx0ZXJzDQo+IElCPj4gbW9k ZWwgd2lsbCBhbGxvdyBmb3IgY29tcGFyaW5nIGEgZGF0YSBzdGF0ZSBwb2ludGVkIGJ5IFhQYXRo IHdpdGgNCj4gSUI+PiBjb25maWd1cmVkIHRocmVzaG9sZCB2YWx1ZSB0byBldmFsdWF0ZSB0cmln Z2VyIGNvbmRpdGlvbiAoYW5kIG11Y2gNCj4gSUI+PiBtb3JlKQ0KDQo8QUxFWD4gV2UgbmVlZCB0 byBmaWd1cmUgb3V0IHRoZSBkZXRhaWxzIG9mIHRoZSBmaWx0ZXIgY29uc3RydWN0LiAgSW4gYWRk aXRpb24gdG8gbm9kZSBzZWxlY3Rpb24gYW5kIHZhbHVlL3JhbmdlIGNvbXBhcmlzb24gYWdhaW5z dCBhIHRocmVzaG9sZC9yYW5nZSBleHByZXNzaW9uIChzbyBmYXIsIHNvIHN0cmFpZ2h0Zm9yd2Fy ZCksIHlvdSBuZWVkIHRvIGJlIGFibGUgdG8gc3BlY2lmeSBhIGNvbXBhcmlzb24gYWdhaW5zdCBh IHN0YXRlLCB0byB1cGRhdGUgdGhlIHN0YXRlIChlLmcuIHRocmVzaG9sZCBjcm9zc2luZyBzZW50 IHZzIGNsZWFyZWQsIGN1cnJlbnQgaGlnaCB3YXRlciBtYXJrIGV0YyksIHRvIHNwZWNpZnkgYSBj b3VudGVyIC8gY2xlYXIgdGhyZXNob2xkLCBldGMuICAgSSBkb24ndCB0aGluayB0aGlzIGNhbiBi ZSBhY2NvbXBsaXNoZWQgd2l0aCBYUEFUSCBhbG9uZS4NCi0tLSBBbGV4DQo8L0FMRVg+DQoNCiAo cmVtYWluZGVyIG9mIG1lc3NhZ2UgdGhyZWFkIGRlbGV0ZWQpDQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66sjceml521mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Qin,

 = ;

My thinkin= g is (although Igor or Xufeng may want to chime in here) that this will be = part of the automation framework.  We would not affect Netconf.  Not every device will implement the automation = framework; those that do will need to address this.  In my opinion, w= e need to look for simple solutions, which means that the complexity of con= ditions being checked should be constrained (you will not use this to program arbitrary custom decision logic, just simple = (presumably stateless) checks such as existence or value ranges of certain = objects ).  Those are some of the things that we will need to work out= there.

 = ;

--- Alex

 = ;

From: Qin Wu
Sent: Thursday, November 09, 2017 5:33 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin= <Igor.Bryskin@huawei.com>; Tianran Zhou <zhoutianran@huawei.com&g= t;; Xufeng_Liu@jabil.com; netconf@ietf.org
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Alex:

That is a good design consideration, = condition check job is not trivial. When you decouple condition check from = smart filter, does this mean you leave condition check to NETCONF kernel to do this?

 

-Qin

=B7=A2=BC=FE=C8=CB= : Alexander Clemm
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA11=D4=C29=C8=D5 5:44
=CA=D5=BC=FE=C8=CB: Igor Bryskin <Igor.Bryskin@huawei.com>; Qi= n Wu <bill.wu@huawei.com>; = Tianran Zhou <zhoutianran@huaw= ei.com>; Xufeng_Liu@jabil.com; netconf@ietf.org
=D6=F7=CC=E2: RE: RE: YANG PUSH Based Ge= neralized Network Control Automation Problem Statement

 

Hi Igor,

 

But I don=A1=AFt think we will assess= conditions as part of smart filters.   IMHO this should be part = of the automation framework.  Just to clarify terminology, to me an event is some kind of =A1=B0occurrence=A1=B1 that you are notified o= f (such as =A1=B0threshold has just been crossed=A1=B1, =A1=B0an update tha= t meets a smart filter has just been observed=A1=B1, =A1=B0some YANG notifi= cation has just been emitted=A1=B1, etc), whereas the condition is a =A1=B0= check=A1=B1 that is actively conducted (to see if the condition holds when the event w= as observed).  Smart filters on YANG-push updates will provide for man= y of the events that the automation framework would utilize, but they may n= ot be the only source, that=A1=AFs all. 

 

Best

--- Alex

 

From: Igor Bryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@huawei.com>; Tianran Zhou <zhoutianran@hua= wei.com>; Xufeng_Liu@jabil.com; netconf@ietf.org
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor

From:Alexander Clemm

To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org,

Date:2017-11-08 14:00:25

Subject:RE: YANG PUSH Based Generalized Network Control Automation Probl= em Statement

 

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.co= m>; Alexander Clemm
> <alexander.clemm@huaw= ei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@j= abil.com>;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66sjceml521mbxchi_-- From nobody Thu Nov 9 11:16:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9B3127201 for ; Thu, 9 Nov 2017 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_yQ7i5Ql2VQ for ; Thu, 9 Nov 2017 11:16:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D6E12951C for ; Thu, 9 Nov 2017 11:16:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSH17652; Thu, 09 Nov 2017 19:16:13 +0000 (GMT) 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.361.1; Thu, 9 Nov 2017 19:16:12 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 11:15:59 -0800 From: Igor Bryskin To: Alexander Clemm , Qin Wu , Tianran Zhou , "Xufeng_Liu@jabil.com" , "netconf@ietf.org" Thread-Topic: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement Thread-Index: AdNZXr9TP1IQx6kSW02L2Q8DtmodTgAb/LGAABAaZUA= Date: Thu, 9 Nov 2017 19:15:58 +0000 Message-ID: <0C72C38E7EBC34499E8A9E7DD00786391C1A0EBA@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABDC66@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.104] Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD00786391C1A0EBAsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A04A97D.02E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac6f249a67cc060ff4292c9a64136255 Archived-At: Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:16:19 -0000 --_000_0C72C38E7EBC34499E8A9E7DD00786391C1A0EBAsjceml521mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KSSBhZ3JlZS4gVGhlIGF1dG9tYXRpb24gd2lsbCBiZSBnb3Zlcm5lZCAgYnkg YSBzZXQgb2YgcmVsYXRpdmVseSBzaW1wbGUgbW9kZWxzICAoc21hcnQgZmlsdGVycyBiZWluZyBv bmUgb2YgdGhlbSksIHdoaWNoIGEgc2VydmVyIG1heSBvciBtYXkgbm90IHN1cHBvcnQuDQpJbiBu byB3YXkgdGhpcyB3b3VsZCBhZmZlY3QgTmV0Y29uZi4NCg0KSWdvcg0KDQpGcm9tOiBBbGV4YW5k ZXIgQ2xlbW0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwOSwgMjAxNyAxOjUxIFBNDQpUbzog UWluIFd1OyBJZ29yIEJyeXNraW47IFRpYW5yYW4gWmhvdTsgWHVmZW5nX0xpdUBqYWJpbC5jb207 IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVy YWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkhp IFFpbiwNCg0KTXkgdGhpbmtpbmcgaXMgKGFsdGhvdWdoIElnb3Igb3IgWHVmZW5nIG1heSB3YW50 IHRvIGNoaW1lIGluIGhlcmUpIHRoYXQgdGhpcyB3aWxsIGJlIHBhcnQgb2YgdGhlIGF1dG9tYXRp b24gZnJhbWV3b3JrLiAgV2Ugd291bGQgbm90IGFmZmVjdCBOZXRjb25mLiAgTm90IGV2ZXJ5IGRl dmljZSB3aWxsIGltcGxlbWVudCB0aGUgYXV0b21hdGlvbiAgZnJhbWV3b3JrOyB0aG9zZSB0aGF0 IGRvIHdpbGwgbmVlZCB0byBhZGRyZXNzIHRoaXMuICBJbiBteSBvcGluaW9uLCB3ZSBuZWVkIHRv IGxvb2sgZm9yIHNpbXBsZSBzb2x1dGlvbnMsIHdoaWNoIG1lYW5zIHRoYXQgdGhlIGNvbXBsZXhp dHkgb2YgY29uZGl0aW9ucyBiZWluZyBjaGVja2VkIHNob3VsZCBiZSBjb25zdHJhaW5lZCAoeW91 IHdpbGwgbm90IHVzZSB0aGlzIHRvIHByb2dyYW0gYXJiaXRyYXJ5IGN1c3RvbSBkZWNpc2lvbiBs b2dpYywganVzdCBzaW1wbGUgKHByZXN1bWFibHkgc3RhdGVsZXNzKSBjaGVja3Mgc3VjaCBhcyBl eGlzdGVuY2Ugb3IgdmFsdWUgcmFuZ2VzIG9mIGNlcnRhaW4gb2JqZWN0cyApLiAgVGhvc2UgYXJl IHNvbWUgb2YgdGhlIHRoaW5ncyB0aGF0IHdlIHdpbGwgbmVlZCB0byB3b3JrIG91dCB0aGVyZS4N Cg0KLS0tIEFsZXgNCg0KRnJvbTogUWluIFd1DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDks IDIwMTcgNTozMyBBTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdl aS5jb20+OyBJZ29yIEJyeXNraW4gPElnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPjsgVGlhbnJhbiBa aG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgWHVmZW5nX0xpdUBqYWJpbC5jb207IG5ldGNv bmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVk IE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0aW9uIFByb2JsZW0gU3RhdGVtZW50DQoNCkFsZXg6DQpU aGF0IGlzIGEgZ29vZCBkZXNpZ24gY29uc2lkZXJhdGlvbiwgY29uZGl0aW9uIGNoZWNrIGpvYiBp cyBub3QgdHJpdmlhbC4gV2hlbiB5b3UgZGVjb3VwbGUgY29uZGl0aW9uIGNoZWNrIGZyb20gc21h cnQgZmlsdGVyLCBkb2VzIHRoaXMgbWVhbiB5b3UgbGVhdmUgY29uZGl0aW9uIGNoZWNrIHRvIE5F VENPTkYga2VybmVsIHRvIGRvIHRoaXM/DQoNCi1RaW4NCreivP7IyzogQWxleGFuZGVyIENsZW1t DQq3osvNyrG85DogMjAxN8TqMTHUwjnI1SA1OjQ0DQrK1bz+yMs6IElnb3IgQnJ5c2tpbiA8SWdv ci5Ccnlza2luQGh1YXdlaS5jb208bWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPj47IFFp biBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PjsgVGlh bnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3 ZWkuY29tPj47IFh1ZmVuZ19MaXVAamFiaWwuY29tPG1haWx0bzpYdWZlbmdfTGl1QGphYmlsLmNv bT47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQrW98ziOiBSRTog UkU6IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlv biBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSBJZ29yLA0KDQpCdXQgSSBkb26hr3QgdGhpbmsgd2Ug d2lsbCBhc3Nlc3MgY29uZGl0aW9ucyBhcyBwYXJ0IG9mIHNtYXJ0IGZpbHRlcnMuICAgSU1ITyB0 aGlzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBhdXRvbWF0aW9uIGZyYW1ld29yay4gIEp1c3QgdG8g Y2xhcmlmeSB0ZXJtaW5vbG9neSwgdG8gbWUgYW4gZXZlbnQgaXMgc29tZSBraW5kIG9mIKGwb2Nj dXJyZW5jZaGxIHRoYXQgeW91IGFyZSBub3RpZmllZCBvZiAoc3VjaCBhcyChsHRocmVzaG9sZCBo YXMganVzdCBiZWVuIGNyb3NzZWShsSwgobBhbiB1cGRhdGUgdGhhdCBtZWV0cyBhIHNtYXJ0IGZp bHRlciBoYXMganVzdCBiZWVuIG9ic2VydmVkobEsIKGwc29tZSBZQU5HIG5vdGlmaWNhdGlvbiBo YXMganVzdCBiZWVuIGVtaXR0ZWShsSwgZXRjKSwgd2hlcmVhcyB0aGUgY29uZGl0aW9uIGlzIGEg obBjaGVja6GxIHRoYXQgaXMgYWN0aXZlbHkgY29uZHVjdGVkICh0byBzZWUgaWYgdGhlIGNvbmRp dGlvbiBob2xkcyB3aGVuIHRoZSBldmVudCB3YXMgb2JzZXJ2ZWQpLiAgU21hcnQgZmlsdGVycyBv biBZQU5HLXB1c2ggdXBkYXRlcyB3aWxsIHByb3ZpZGUgZm9yIG1hbnkgb2YgdGhlIGV2ZW50cyB0 aGF0IHRoZSBhdXRvbWF0aW9uIGZyYW1ld29yayB3b3VsZCB1dGlsaXplLCBidXQgdGhleSBtYXkg bm90IGJlIHRoZSBvbmx5IHNvdXJjZSwgdGhhdKGvcyBhbGwuDQoNCkJlc3QNCi0tLSBBbGV4DQoN CkZyb206IElnb3IgQnJ5c2tpbg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyAx MToxMiBBTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208 bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj47IElnb3IgQnJ5c2tpbiA8SWdvci5C cnlza2luQGh1YXdlaS5jb208bWFpbHRvOklnb3IuQnJ5c2tpbkBodWF3ZWkuY29tPj47IFFpbiBX dSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PjsgVGlhbnJh biBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWku Y29tPj47IFh1ZmVuZ19MaXVAamFiaWwuY29tPG1haWx0bzpYdWZlbmdfTGl1QGphYmlsLmNvbT47 IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog UkU6IFlBTkcgUFVTSCBCYXNlZCBHZW5lcmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlv biBQcm9ibGVtIFN0YXRlbWVudA0KDQpIaSBBbGV4LA0KDQpJIGRvIGFncmVlIHdpdGggeW91IHRo YXQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIG5ldHdvcmsgY29udHJvbCBhdXRvbWF0aW9uIHNtYXJ0 IGZpbHRlcnMgd2lsbCBjb250cmlidXRlIGNvbmRpdGlvbnMgcmF0aGVyIHRoYW4gZXZlbnRzLiBF dmVudHMgd2lsbCBiZSBleHBsaWNpdGx5IGRlZmluZWQgYnkgdGhlIG5ldHdvcmsgY29udHJvbCBh dXRvbWF0aW9uIG1vZGVsKHMpIGFuZC9vciBhbnkgb3RoZXIgWUFORyBtb2RlbHMgc3VwcG9ydGVk IGJ5IHRoZSBzZXJ2ZXIuDQoNCklnb3INCkZyb206QWxleGFuZGVyIENsZW1tDQpUbzpJZ29yIEJy eXNraW4sUWluIFd1LFRpYW5yYW4gWmhvdSxYdWZlbmcgTGl1LG5ldGNvbmZAaWV0Zi5vcmcsDQpE YXRlOjIwMTctMTEtMDggMTQ6MDA6MjUNClN1YmplY3Q6UkU6IFlBTkcgUFVTSCBCYXNlZCBHZW5l cmFsaXplZCBOZXR3b3JrIENvbnRyb2wgQXV0b21hdGlvbiBQcm9ibGVtIFN0YXRlbWVudA0KDQpI aSwNCg0KQSBmZXcgYWRkaXRpb25hbCBjb21tZW50cyBpbmxpbmUsIDxBTEVYPg0KDQpUaGFua3MN Ci0tLSBBbGV4DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSWdvciBC cnlza2luDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDgsIDIwMTcgOTowMCBBTQ0KPiBU bzogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+ OyBBbGV4YW5kZXIgQ2xlbW0NCj4gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzph bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+OyBUaWFucmFuIFpob3UNCj4gPHpob3V0aWFucmFu QGh1YXdlaS5jb208bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+PjsgWHVmZW5nIExpdSA8 WHVmZW5nX0xpdUBqYWJpbC5jb208bWFpbHRvOlh1ZmVuZ19MaXVAamFiaWwuY29tPj47DQo+IG5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBZ QU5HIFBVU0ggQmFzZWQgR2VuZXJhbGl6ZWQgTmV0d29yayBDb250cm9sIEF1dG9tYXRpb24NCj4g UHJvYmxlbSBTdGF0ZW1lbnQNCj4NCj4gSGkgUWluLA0KPg0KPiBQbGVhc2UsIHNlZSBpbi1saW5l Lg0KPg0KPiBJZ29yDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFp biBXdQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDEwOjIxIEFNDQo+IFRv OiBJZ29yIEJyeXNraW47IEFsZXhhbmRlciBDbGVtbTsgVGlhbnJhbiBaaG91OyBYdWZlbmcgTGl1 Ow0KPiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiBTdWJqZWN0 OiBSRTogWUFORyBQVVNIIEJhc2VkIEdlbmVyYWxpemVkIE5ldHdvcmsgQ29udHJvbCBBdXRvbWF0 aW9uDQo+IFByb2JsZW0gU3RhdGVtZW50DQo+DQo+IEludGVyZXN0aW5nIGRpc2N1c3Npb24sIGRv ZXMgc21hcnQgZmlsdGVyIG1lYW4gdGhhdCBuZXRjb25mIHNlcnZlciBzaG91bGQgYmUNCj4gc3Rh dGVmdWwgc2luY2UgaXQga2VlcCBhIGZldyBzdGF0ZSB3aGlsZSB0cmFkaXRpb25hbCB5YW5nIHB1 c2ggZG9lc24ndCByZXF1aXJlDQo+IG5ldGNvbmYgc2V2ZXIgdG8gYmUgc3RhdGVmdWwsIGkuZS4s IHNob3VsZCBiZSBzdGF0ZWxlc3M/DQo+DQo+IElCPj4gWWVzLiBGb3IgZXhhbXBsZSwgYW4gUlBD IChvbmUgb2YgcG9zc2libGUgZ2VuZXJhbGl6ZWQgYWN0aW9ucykgb3V0cHV0DQo+IGNvdWxkIGJl IHN0b3JlZCB0byBiZSB1c2VkIGluIHN1YnNlcXVlbnQgRUNBcyAoZXZlbnQtY29uZGl0aW9uLWFj dGlvbikuIFRoZQ0KPiBtb2RlbHMgd2UgaGF2ZSBpbiBtaW5kIHdpbGwgYWxsb3cgZm9yIG1hbmFn aW5nIGFuZCBhY2Nlc3Npbmcgc3VjaCBzdGF0ZS4NCg0KPEFMRVg+IFllcy4gIEp1c3QgaG93IG11 Y2ggc3RhdGUgd2Ugd2FudCB0byBhbGxvdyBpcyBvbmUgb2YgdGhlIGl0ZW1zIHRoYXQgbmVlZCB0 byBiZSBkaXNjdXNzZWQuICBJIGFtIG9mIHRoZSBvcGluaW9uIHRoYXQgdGhpcyBzaG91bGQgYmUg bGltaXRlZCB0byBhIGZldyBmcmVxdWVudGx5IHVzZWQgc2NlbmFyaW9zIHN1Y2ggYXMgdGhyZXNo b2xkIGNyb3NzaW5nIGFsZXJ0cyBhbmQgaW4tcmFuZ2Uvb3V0LW9mLXJhbmdlIG1vbml0b3JzLiAg QnkgaXRzIG5hdHVyZSwgYSB0aHJlc2hvbGQgbW9uaXRvciBfaGFzXyB0byBiZSBzdGF0ZWZ1bCAo aXQgaXMgbm90IHN1ZmZpY2llbnQgdG8gc2ltcGx5IGNvbXBhcmUgdGhlIGN1cnJlbnQgdmFsdWUg b2YgYSBkYXRhIGl0ZW0gYWdhaW5zdCB0aGUgdGhyZXNob2xkLCB5b3UgYWxzbyBuZWVkIHRvIGtu b3cgaWYgeW91IGFscmVhZHkgcmVwb3J0ZWQgdGhpcyBlYXJsaWVyIHdpdGhvdXQgY2xlYXJpbmcg dGhlIGNvdW50ZXIgdGhyZXNob2xkIGluIHRoZSBtZWFudGltZSkuICBUaGlzIHdpbGwgYmUgc2lt cGx5IHBhcnQgb2YgdGhlIGZlYXR1cmUgb2YgdGhlIHNtYXJ0IGZpbHRlciB0aGF0IGlzIGNvbmZp Z3VyZWQgdmlhIE5ldGNvbmYvUmVzdGNvbmYuICBIb3dldmVyLCBJIGRvbid0IHRoaW5rIHRoZSBz dGF0ZSBpbiB0aG9zZSBjYXNlcyBzaG91bGQgaGF2ZSB0byBiZSBleHRlcm5hbGx5IGV4cG9zZWQg LSBpdCBpcyBzaW1wbHkgcGFydCBvZiBob3cgdGhlIGZpbHRlciBjb25zdHJ1Y3Qgd29ya3MuDQoN ClRoZSBvdGhlciBzdGF0ZWZ1bCBzY2VuYXJpbyBjdXJyZW50bHkgZGVmaW5lZCBhcyBpbi1zY29w ZSBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgdGhlICJyZWNlbnQgaGlnaCB3YXRlciBtYXJr IiBzY2VuYXJpbywgaW4gd2hpY2ggeW91IGtlZXAgdHJhY2sgb2YgdGhlIGhpZ2ggd2F0ZXIgbWFy ayBmb3Igc29tZSBhbW91bnQgb2YgdGltZSBhZnRlciB3aGljaCBpdCBpcyBjbGVhcmVkLiAgKFRo ZSBhbmFsb2d5IGlzIHRoYXQgb2YgYSBncmFwaGljIGVxdWFsaXplci4pDQoNCldpdGggcmVnYXJk cyB0byBhdXRvbWF0aW9uIGFuZCBFQ0EsIEkgd291bGQgdmlldyBzbWFydCBmaWx0ZXJzIGFzIGFu IGltcG9ydGFudCBzb3VyY2Ugb2YgZXZlbnRzLCBidXQgbm90IGFzIHRoZSBvbmx5IG9uZS4gIFRo ZSBpbnRlbnQgaGVyZSBpcyBub3QgdG8gcHJvdmlkZSBhIGdlbmVyYWwgcHJvZ3JhbW1pbmcgZnJh bWV3b3JrIHRvIGRlZmluZSBhbnkgdHlwZSBvZiBldmVudHMgLSBhcyBtZW50aW9uZWQgZWFybGll ciwgdGhpcyBpcyBub3QgaW50ZW5kZWQgYXMgYW4gZXZlbnQrZXhwcmVzc2lvbiBNSUIgb3IgYW55 IHN1Y2ggdGhpbmcsIGp1c3QgZnJlcXVlbnRseSBuZWVkZWQgZmlsdGVycy9jYXRlZ29yaWVzIG9m IGV2ZW50cyB0aGF0IGFyZSBmYWlybHkgYnJvYWRseSBhcHBsaWNhYmxlIGFuZCB1c2VmdWwuICBP YnZpb3VzbHksIHdoZXJlIHRoZSAic3dlZXQgc3BvdCIgbGllcyBpcyBzdWJqZWN0IHRvIGRpc2N1 c3Npb24uICBXZSB3b3VsZCBsb3ZlIHRvIGhlYXIgZmVlZGJhY2sgYWJvdXQgd2hhdCBvdGhlciBm aWx0ZXJzIGFyZSBkZWVtZWQgdXNlZnVsLg0KPC9BTEVYPg0KPg0KPg0KPiBJIHRoaW5rIHNldCB0 aHJlc2hvbGQgZm9yIHBhY2tldCBsb3NzIG9yIGxhdGVuY3kgaXMgcHJldHR5IG11Y2ggY29tbW9u IGluDQo+IG5ldHdvcmsgdHJvdWJsZSBzaG9vdGluZywgc3VjaCB0aHJlc2hvbGQgY2FuIGJlIGFs c28gbW92ZWQgZG93biBvdmVyDQo+IHRpbWUuDQo+IFdoYXQga2luZCBvZiB0aHJlc2hvbGQgY2Fu IGJlIHNldCBtb3JlIGRlcGVuZHMgb24gZW1waXJpY2FsIGV4cGVyaWVuY2UuIEkNCj4gYW0gd29u ZGVyaW5nIGhvdyB0aGlzIGNhbiBiZSBtb2RlbGVkIHVzaW5nIFhQQVRIIHN0YXRlbWVudCBvciBz b21lDQo+IG90aGVyIG1lY2hhbmlzbS4NCj4NCj4gSUI+PiBJIGxldCBBbGV4IGFuc3dlciB0aGlz LCBidXQgSSB3b3VsZCBhc3N1bWUgdGhhdCB0aGUgc21hcnQtZmlsdGVycw0KPiBJQj4+IG1vZGVs IHdpbGwgYWxsb3cgZm9yIGNvbXBhcmluZyBhIGRhdGEgc3RhdGUgcG9pbnRlZCBieSBYUGF0aCB3 aXRoDQo+IElCPj4gY29uZmlndXJlZCB0aHJlc2hvbGQgdmFsdWUgdG8gZXZhbHVhdGUgdHJpZ2dl ciBjb25kaXRpb24gKGFuZCBtdWNoDQo+IElCPj4gbW9yZSkNCg0KPEFMRVg+IFdlIG5lZWQgdG8g ZmlndXJlIG91dCB0aGUgZGV0YWlscyBvZiB0aGUgZmlsdGVyIGNvbnN0cnVjdC4gIEluIGFkZGl0 aW9uIHRvIG5vZGUgc2VsZWN0aW9uIGFuZCB2YWx1ZS9yYW5nZSBjb21wYXJpc29uIGFnYWluc3Qg YSB0aHJlc2hvbGQvcmFuZ2UgZXhwcmVzc2lvbiAoc28gZmFyLCBzbyBzdHJhaWdodGZvcndhcmQp LCB5b3UgbmVlZCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgYSBjb21wYXJpc29uIGFnYWluc3QgYSBz dGF0ZSwgdG8gdXBkYXRlIHRoZSBzdGF0ZSAoZS5nLiB0aHJlc2hvbGQgY3Jvc3Npbmcgc2VudCB2 cyBjbGVhcmVkLCBjdXJyZW50IGhpZ2ggd2F0ZXIgbWFyayBldGMpLCB0byBzcGVjaWZ5IGEgY291 bnRlciAvIGNsZWFyIHRocmVzaG9sZCwgZXRjLiAgIEkgZG9uJ3QgdGhpbmsgdGhpcyBjYW4gYmUg YWNjb21wbGlzaGVkIHdpdGggWFBBVEggYWxvbmUuDQotLS0gQWxleA0KPC9BTEVYPg0KDQogKHJl bWFpbmRlciBvZiBtZXNzYWdlIHRocmVhZCBkZWxldGVkKQ0K --_000_0C72C38E7EBC34499E8A9E7DD00786391C1A0EBAsjceml521mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Alex,

 <= /p>

I agree. The automation w= ill be governed  by a set of relatively simple models  (smart fil= ters being one of them), which a server may or may not support.<= /span>

In no way this would affe= ct Netconf.

 <= /p>

Igor  

 <= /p>

From: Alexande= r Clemm
Sent: Thursday, November 09, 2017 1:51 PM
To: Qin Wu; Igor Bryskin; Tianran Zhou; Xufeng_Liu@jabil.com; netcon= f@ietf.org
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Qin,=

 <= /p>

My thinking is (although = Igor or Xufeng may want to chime in here) that this will be part of the aut= omation framework.  We would not affect Netconf.  Not every device will implement the automation  framework; those that do will n= eed to address this.  In my opinion, we need to look for simple soluti= ons, which means that the complexity of conditions being checked should be = constrained (you will not use this to program arbitrary custom decision logic, just simple (presumably stateless) checks= such as existence or value ranges of certain objects ).  Those are so= me of the things that we will need to work out there.

 <= /p>

--- Alex

 <= /p>

From: Qin Wu
Sent: Thursday, November 09, 2017 5:33 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin= <Igor.Bryskin@huawei.com>; Tianran Zhou <zhoutianran@huawei.com&g= t;; Xufeng_Liu@jabil.com; netconf@ietf.org
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Alex:

That is a good design con= sideration, condition check job is not trivial. When you decouple condition= check from smart filter, does this mean you leave condition check to NETCONF kernel to do this?

 <= /p>

-Qin

=B7=A2=BC=FE= =C8=CB: Alexander Clemm
=B7=A2=CB=CD=CA=B1=BC=E4: 2017=C4=EA11=D4=C29=C8=D5 5:44
=CA=D5=BC=FE=C8=CB: Igor Bryskin <Igor.Bryskin@huawei.com>; Qi= n Wu <bill.wu@huawei.com>; = Tianran Zhou <zhoutianran@huaw= ei.com>; Xufeng_Liu@jabil.com; netconf@ietf.org
=D6=F7=CC=E2: RE: RE: YANG PUSH Based Ge= neralized Network Control Automation Problem Statement

 

Hi Igor,

 <= /p>

But I don=A1=AFt think we= will assess conditions as part of smart filters.   IMHO this sho= uld be part of the automation framework.  Just to clarify terminology, to me an event is some kind of =A1=B0occurrence=A1=B1 that you are notifie= d of (such as =A1=B0threshold has just been crossed=A1=B1, =A1=B0an update = that meets a smart filter has just been observed=A1=B1, =A1=B0some YANG not= ification has just been emitted=A1=B1, etc), whereas the condition is a =A1=B0check=A1=B1 that is actively conducted (to see if the condition hold= s when the event was observed).  Smart filters on YANG-push updates wi= ll provide for many of the events that the automation framework would utili= ze, but they may not be the only source, that=A1=AFs all. 

 <= /p>

Best

--- Alex

 <= /p>

From: Igor B= ryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <alexander.clemm@huawei.com>; Igor Bryskin <Igor.Bryskin@huawei.com>; Qin Wu <bill.wu@huawei.com>; Tianran Zhou <zhoutianran@hua= wei.com>; Xufeng_Liu@jabil.com; netconf@ietf.org
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automat= ion Problem Statement

 

Hi Alex,

I do agree with you that in the context of the network control automation s= mart filters will contribute conditions rather than events. Events will be = explicitly defined by the network control automation model(s) and/or any ot= her YANG models supported by the server.

Igor

From:Alexander Clemm

To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,netconf@ietf.org,

Date:2017-11-08 14:00:25

Subject:RE: YANG PUSH Based Generalized Network Control Automation Probl= em Statement

 

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <bill.wu@huawei.co= m>; Alexander Clemm
> <alexander.clemm@huaw= ei.com>; Tianran Zhou
> <zhoutianran@huawei.com>; Xufeng Liu <Xufeng_Liu@j= abil.com>;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Hi Qin,
>
> Please, see in-line.
>
> Igor
>
> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, November 08, 2017 10:21 AM
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> netconf@ietf.org
> Subject: RE: YANG PUSH Based Generalized Network Control Automation > Problem Statement
>
> Interesting discussion, does smart filter mean that netconf server sho= uld be
> stateful since it keep a few state while traditional yang push doesn't= require
> netconf sever to be stateful, i.e., should be stateless?
>
> IB>> Yes. For example, an RPC (one of possible generalized actio= ns) output
> could be stored to be used in subsequent ECAs (event-condition-action)= . The
> models we have in mind will allow for managing and accessing such stat= e.

<ALEX> Yes.  Just how much state we want to allow is one of the = items that need to be discussed.  I am of the opinion that this should= be limited to a few frequently used scenarios such as threshold crossing a= lerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to = simply compare the current value of a data item against the threshold, you = also need to know if you already reported this earlier without clearing the= counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is config= ured via Netconf/Restconf.  However, I don't think the state in those = cases should have to be externally exposed - it is simply part of how the f= ilter construct works. 

The other stateful scenario currently defined as in-scope in the problem st= atement is the "recent high water mark" scenario, in which you ke= ep track of the high water mark for some amount of time after which it is c= leared.  (The analogy is that of a graphic equalizer.) 

With regards to automation and ECA, I would view smart filters as an import= ant source of events, but not as the only one.  The intent here is not= to provide a general programming framework to define any type of events - = as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed f= ilters/categories of events that are fairly broadly applicable and useful.&= nbsp; Obviously, where the "sweet spot" lies is subject to discus= sion.  We would love to hear feedback about what other filters are deemed useful. 
</ALEX>
>
>
> I think set threshold for packet loss or latency is pretty much common= in
> network trouble shooting, such threshold can be also moved down over > time.
> What kind of threshold can be set more depends on empirical experience= . I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
>
> IB>> I let Alex answer this, but I would assume that the smart-f= ilters
> IB>> model will allow for comparing a data state pointed by XPat= h with
> IB>> configured threshold value to evaluate trigger condition (a= nd much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.&nbs= p; In addition to node selection and value/range comparison against a thres= hold/range expression (so far, so straightforward), you need to be able to = specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mar= k etc), to specify a counter / clear threshold, etc.   I don't th= ink this can be accomplished with XPATH alone. 
--- Alex
</ALEX>

 (remainder of message thread deleted)

--_000_0C72C38E7EBC34499E8A9E7DD00786391C1A0EBAsjceml521mbxchi_-- From nobody Thu Nov 9 11:34:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C4F1296B0 for ; Thu, 9 Nov 2017 11:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 Lz1PcU2NDeG7 for ; Thu, 9 Nov 2017 11:33:55 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 9DB631295A0 for ; Thu, 9 Nov 2017 11:33:54 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id w21so8448930lfc.6 for ; Thu, 09 Nov 2017 11:33:54 -0800 (PST) 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=h0DREyrBvK9expY53+XZbEABI1YgvFOtm7gxPRjwOcQ=; b=xdPmzFwbAJpF0XWpb/hdjTJrx5Ry9xZP7ukrdsqni9ZHxRI2wFCVPZ+/p0/9M32t8O +/gHroT+kbPun7SC6MeZHDsavO/WujSKM9HyZbk0g4S8RAaxpMQPxnz3p4DgSOf2IZy0 fFBKvyhDqKsl2rdLyt0jG8yrMP5z3rqaATpiLpVXBqSZthB6NKUa3zW6TAb6FJCr3/l+ 4xY9IO1VYBbkjHSVOXbgawsGNR1lKdM58ohZhH2QX3eY3Yu/J3+A0/fOsWt1d0j1FRzf zA272ODfCAO/3C7Ts+nvqN4sIWUuGgJDnqvaSRBhuCIjADwwbLJaP6FM5AKqCA/kYVI8 qDfA== 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=h0DREyrBvK9expY53+XZbEABI1YgvFOtm7gxPRjwOcQ=; b=NBQRPSNqnLHXNc94aAFY4RGDHTY19I1t1V3lecVsNoukIGzwNjGb7JDk7/MzQjO62n VccVqFzqUg4aq8X0G8Vv5vm+CLnlc3bW7L3LeS/0PpNJVj0/jmT5dHKrbnu+37VwteUI uA/Yj/Yal2OVwMDBkYWXHd7tWwyaQte5gaE2xavtOg6hTpLB4L/VIkgEEgGrRelQR3M3 tjXkjUD9/Ge0LFjotCSS3r52CGW7zu2Pi2d1hMX02+3ERclBVT/zpiLIDI5200bBATyH EjTm7k8YF2dyf1zWXLcG48KtoH2LD0Na0iU2lRWfdI/rAjAWctyTyI926gynZfkgHLNy 3zsw== X-Gm-Message-State: AJaThX6mbiDr22/q5mOumg/Iw9szNkdvyF1J0PcSTEqm8GMhtKeKBsyG +jxL/ufYPThbXL3A9TapcfJGdVjQ+oml87+Oo4A5jw== X-Google-Smtp-Source: AGs4zMZCgmKYSqXlti3VNHPOGumdYOr0UT6Z+l1lL8eVEyVuVOjNF6FhieTofTQDmh1IufRcrs+Mi6gn2EJWXmUQZVs= X-Received: by 10.25.156.66 with SMTP id f63mr630216lfe.194.1510256032760; Thu, 09 Nov 2017 11:33:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 11:33:51 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Thu, 9 Nov 2017 11:33:51 -0800 Message-ID: To: Robert Wilton Cc: "netconf@ietf.org" , Ladislav Lhotka , Martin Bjorklund , Kent Watsen Content-Type: multipart/alternative; boundary="001a11411bc65a6b90055d91e2ad" Archived-At: Subject: Re: [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:33:58 -0000 --001a11411bc65a6b90055d91e2ad Content-Type: text/plain; charset="UTF-8" Hi, The new structure still has the same problems for the client as before. It is a major change in the architecture to have different schema trees per datastore instead of per-server. The server is allowed to have different features and deviations for the same objects. The client is completely on its own trying to compare to anything if the schema trees are different container foo { leaf bar { if-feature X; type string; } leaf baz { if-feature "not X"; type string; } } How does the client compare to if the features do not match? If the server deviates the leaf (e.g. change type string to int32) how does the client compare the values? This new complexity would be mandatory for the client to support in some proprietary manner since the NMDA standard ignores these problems. NMDA was supposed to be simpler because the client could compare intended and applied values using the same object path. openconfig required a data model change and a trivial name-mapping. In reality, NMDA is far more disruptive to existing implementations. Andy On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton wrote: > Hi, > > Given some of the feedback related to the complexity of the YANG library > bis structure, we have come up with two other possible structures for the > YANG library data: > > (1) A simplified structure to make YANG library meet the NMDA > requirements, but that is closer to the existing YANG library structure, > and arguably simpler. > (2) An enhanced version of the structure (1) above, that is also extended > to allow the structure to be reused for schema-mount via an augmentation. > > For reference, at the end of this email, I have also included the tree > diagram of the existing YANG library, and the current YANG library bis > draft (draft-ietf-netconf-rfc7895bis-02) version. > > Considering the two new YANG library structures: > > ------------------------ > > *(1) A simplified structure to make YANG library meet the NMDA > requirements, but that is closer to the existing YANG library structure.* > > The main changes are: > (i) Split "implemented modules" and "import-only-modules" into two > separate lists, making the most important list (i.e. implemented modules) > keyed by module name only and hence easier to reference. > (ii) Assume modules are implemented in all datastores by default (with a > "not-implemented-in" leaflist of datastores that a module is not > implemented in). > (iii) Assume that features are implemented in all datastores by default > (with a "not-implemented-in" leaflist of datastores that a feature is not > implemented in). > (iv) Deleted module-sets. > (v) Datastores are now just a list of supported datastores (that could > potentially be extended with further per datastore properties in future). > > Manually generated tree output for proposed YANG library: > > module: ietf-yang-library > +--ro yang-library > +--ro modules > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro schema? inet:uri > | | +--ro namespace inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? yang:yang-identifier > | | | +--ro schema? inet:uri > | | +--ro not-implemented-in* > | | | -> /yang-library/datastore/name > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro not-implemented-in* > | | | -> /yang-library/datastore/name > | | +--ro deviation* > | | -> ../name > | | > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro schema? inet:uri > | +--ro namespace inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision yang:revision-identifier > | +--ro schema? inet:uri > +--ro datastore* [name] // Allows future per datastore properties. > | +--ro name identityref > +--ro checksum string > > ------------------------------ > > *(2) An enhanced version of the structure (1) above, that is extended to > allow the structure to be reused for schema-mount via an augmentation.* > > This is similar to the structure above, except that the "the set of > modules" is contained in a list of named schema (e.g. similar to the schema > mount draft), allowing this structure to be re-used for schema mount. > > Schema mount would be expected to augment yang-library to add in the > additional schema mount information. In the tree diagram, I have shown the > schema-mount mount-point augmentation, but not including namespaces yet. > > Every server would be required to provide at least one schema in the > schema list, and the primary schema for the device would always be given > the name "primary". > > module: ietf-yang-library > +--ro yang-library > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? yang:revision-identifier > | | +--ro schema? inet:uri > | | +--ro namespace inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? yang:yang-identifier > | | | +--ro schema? inet:uri > | | +--ro not-implemented-in* > | | | -> /yang-library/datastore/name > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro not-implemented-in* > | | | -> /yang-library/datastore/name > | | +--ro deviation* > | | | -> ../name > | | +- schema-mount:mount-point* [label] > | | +--ro label yang:yang-identifier > | | +--ro config? boolean > | | +--ro (schema-ref) > | | +--:(inline) > | | | +--ro inline? empty > | | +--:(use-schema) > | | +--ro use-schema* [name] > | | +--ro name > | | | -> /yang-library/schema/name > | | +--ro parent-reference* yang:xpath1.0 > | | > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro schema? inet:uri > | +--ro namespace inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision yang:revision-identifier > | +--ro schema? inet:uri > +--ro datastore* [name] // Allows future per datastore properties. > | +--ro name identityref > +--ro checksum string > > Please can you provide comments on these structures, in particular: > > Is this version better (i.e. simpler) that the version currently in > draft-ietf-netconf-rfc7895bis-02 (below)? > > Should we try and make the structure extensible for schema-mount via > augmentation (i.e. version (2)), or is it better that schema-mount has its > own separate subtree? > > For reference only I have included the existing YANG library and YANG > library bis draft tree diagrams. > > Thanks, > Rob > > > ----------------------------- > > *** FOR REFERENCE ONLY *** > > (3) The current YANG library structure in YANG library bis > (draft-ietf-netconf-rfc7895bis-02) > > module: ietf-yang-library > +--ro yang-library > +--ro modules > | +--ro module* [id] > | +--ro id string > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro schema? inet:uri > | +--ro namespace inet:uri > | +--ro feature* yang:yang-identifier > | +--ro deviation* [module] > | | +--ro module -> ../../id > | +--ro conformance-type enumeration > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro schema? inet:uri > +--ro module-sets > | +--ro module-set* [id] > | +--ro id string > | +--ro module* -> ../../../modules/module/id > +--ro datastores > | +--ro datastore* [name] > | +--ro name identityref > | +--ro module-set > | -> ../../../module-sets/module-set/id > +--ro checksum string > > ----------------------------- > > *** FOR REFERENCE ONLY *** > > (4) The current YANG library structure (RFC 7895) > > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > > > --001a11411bc65a6b90055d91e2ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The new structure still has the sam= e problems for the client as before.
It is a major change in the = architecture to have different schema trees per datastore instead of per-se= rver.
The server is allowed to have different features and deviat= ions for the same objects.
The client is completely on its own tr= ying to compare <operational> to anything
if the schema tre= es are different

=C2=A0 container foo {
= =C2=A0 =C2=A0 leaf bar {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 = }
=C2=A0 =C2=A0 leaf baz {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feat= ure "not X";
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 }
=C2=A0}

How does= the client compare <running> to <operational> if the features = do not match?
If the server deviates the leaf (e.g. change type s= tring to int32) how does the client
compare the values?

This new complexity would be mandatory for the client to su= pport in some proprietary
manner since the NMDA standard ignores = these problems.

NMDA was supposed to be simpler because the client could compare = intended
and applied values using the same = object path. openconfig required a data
mod= el change and a trivial name-mapping. In reality, NMDA
is far more disruptive to existing implementations.


Andy



On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton <rwilton@cisco.c= om> wrote:
=20 =20 =20

Hi,

Given some of the feedback related to the complexity of the YANG library bis structure, we have come up with two other possible structures for the YANG library data:

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also extended to allow the structure to be reused for schema-mount via an augmentation.

For reference, at the end of this email, I have also included the tree diagram of the existing YANG library, and the current YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) version.

Considering the two new YANG library structures:

------------------------

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure.

The main changes are:
(i) Split "implemented modules" and "import-only-modul= es" into two separate lists, making the most important list (i.e. implemented modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a = module is not implemented in).
(iii) Assume that features are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores= that a feature is not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could potentially be extended with further per datastore properties in future).

Manually generated tree output for proposed YANG library:

module: ietf-yang-library
=C2=A0+--ro yang-library
=C2=A0=C2=A0=C2=A0 +--ro modules
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 revision-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?= =C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-impleme= nted-in*
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ..= /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 |=C2=A0 |
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name r= evision]
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 in= et:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<= tt>
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule= * [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifi= er
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro revision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future = per datastore properties.
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref
=C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 string

------------------------------

(2) An enhanced version of the structure (1) above, that is extended to allow the structure to be reused for schema-mount via an augmentation.

This is similar to the structure above, except that the "the se= t of modules" is contained in a list of named schema (e.g. similar to the schema mount draft), allowing this structure to be re-used for schema mount.

Schema mount would be expected to augment yang-library to add in the additional schema mount information.=C2=A0 In the tree diagram, I have shown the schema-mount mount-point augmentation, but not including namespaces yet.

Every server would be required to provide at least one schema in the schema list, and the primary schema for the device would always be given the name "primary".

module: ietf-yang-library
=C2=A0+--ro yang-library
=C2=A0=C2=A0=C2=A0 +--ro schema* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 string
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 yang:revision-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?= =C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-impleme= nted-in*
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-poi= nt* [label]
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro l= abel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro c= onfig?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (= schema-ref)
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--:(inline)
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empt= y
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--:(use-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=C2=A0=C2=A0 +--ro use-schema* [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=C2=A0 +--ro 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=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -> /yang-library/schema/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=C2=A0 +--ro parent-reference*=C2= =A0=C2=A0 yang:xpath1.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name r= evision]
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 in= et:uri
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<= tt>
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule= * [name]
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifi= er
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro revision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future = per datastore properties.
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref
=C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 string

Please can you provide comments on these structures, in particular:

Is this version better (i.e. simpler) that the version currently in draft-ietf-netconf-rfc7895bis-02 (below)?

Should we try and make the structure extensible for schema-mount via augmentation (i.e. version (2)), or is it better that schema-mount has its own separate subtree?

For reference only I have included the existing YANG library and YANG library bis draft tree diagrams.

Thanks,
Rob


-----------------------------

*** FOR REFERENCE ONLY ***

(3)=C2=A0 The current YANG library structure in YANG library bis (draft-ietf-netconf-rfc7895bis-02)

   module:=
 ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

-----------------------------

*** FOR REFERENCE ONLY ***

(4)=C2=A0 The current YANG library structure (RFC 7895)

      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri


--001a11411bc65a6b90055d91e2ad-- From nobody Thu Nov 9 20:37:58 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E932B12953B for ; Thu, 9 Nov 2017 20:37:55 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 trsbj-x-3EoU for ; Thu, 9 Nov 2017 20:37:52 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 57787129524 for ; Thu, 9 Nov 2017 20:37:51 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id b190so9666977lfg.9 for ; Thu, 09 Nov 2017 20:37:51 -0800 (PST) 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=XWFi3+/AdYycF1U1ga0109Q1b0Lw3pHuR35ZlGeG8p4=; b=ZKrVa66Qft5TN1b7jVYf95FWeNdVjrwg5U3vmpbS/eCXinrcyKJNgLpcD/zqVej8mX nCyMCO9u+B20dm4z2p0f0u+LuKKhifLGP3xZqKfu4xmsbWfHDi3zr8sGenWXkZZsr0JE va84O7oCeoFInWhmDk2zgjOC7IwkXWPLS+idd36XPqaRssTxDPgt1SF7LsjfaTnAHUbO aa0tVAypf3k1AQ++PH27EY8xTprjQVlPGhK/HLDVLDtKsN0DkUJx0watKKLDSe4Cvp4l n3C67rC0ER2kc6ogiHXdgCnMq6C0BHdQasnTdfiX24NdyKTfQ9FqG9FuhQvGej7wy7Sp xb6g== 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=XWFi3+/AdYycF1U1ga0109Q1b0Lw3pHuR35ZlGeG8p4=; b=GAeWi1cAqq3kTLJGyd+Z/+c4SO6+MqTxL1cK2YlV2ddLGvAG8BicBosbnjOMSMJU9O 8ZwApcMxX4ZASzYIhL9dA/38KlW3w2AbPXMrz2gwV2Lk98uLQprS9S4WA17wSo1oj3+Z jKGK8gh8jH0W677i7s6GqdO6vE2/+ICC6Iy5qj79ohos2xqMT/yDltFzpPpwyOyha1Oa V8z4CMr5bdITR9ZzCd2ftgrHZiQy/mFqt3UVg/kZxAudwRFLe5uuekbIeDFNPH1IVAGZ zkPLno87fUlqXWQUvnw058p4fFcbCPNIB6S56A7eU/L4mlfJ36ZUabD0KFBRzW+a1O4F aAJA== X-Gm-Message-State: AJaThX6zNtgAucKWg4F7f/K612SPOYVrnB21wHn3xepzIz/PP5DwnFmx Cyr7QEht8PCXaKzng09Vvw7vSSMyk0I/XBcknFXu9g== X-Google-Smtp-Source: AGs4zMbnR40VFc5IRRb0i3hwvgiY2jk2GHuoB3Nwusyqd5pqAG9pwb4XTyQHIbcws18YqG5vjkdoP3oI1M1eUJf8gj0= X-Received: by 10.46.93.75 with SMTP id r72mr1064237ljb.182.1510288669463; Thu, 09 Nov 2017 20:37:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Thu, 9 Nov 2017 20:37:47 -0800 (PST) In-Reply-To: <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> From: Andy Bierman Date: Thu, 9 Nov 2017 20:37:48 -0800 Message-ID: To: Robert Wilton Cc: Benoit Claise , NETCONF , Martin Bjorklund , "sec-ads@ietf.org" Content-Type: multipart/related; boundary="001a114b72f4a741f7055d997bea" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 04:37:56 -0000 --001a114b72f4a741f7055d997bea Content-Type: multipart/alternative; boundary="001a114b72f4a741ea055d997be9" --001a114b72f4a741ea055d997be9 Content-Type: text/plain; charset="UTF-8" Hi, The term "data node" is used in the document to refer to the top-level node of the specified object, not the entire subtree (if any). The data-rule /foo does not match /foo/child1 in the text below. The child nodes are omitted because of step 11. The admin has to explicitly permit individual child nodes (or modules). This seems correct if the read-default is "deny". Should any text be added or changed to make this more clear? Andy On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton wrote: > Hi Andy, > > It isn't clear to me whether matching a path in NACM either: > (i) Only applies to the specific node, and not any children, or > (ii) Applies to the specific node and all descendant children nodes as > well. > > As an example, using the tree below. if I have a rule that matches path > "A/B" then does that apply to only the specific node "A/B", or does it also > apply to all descendant children of "A/B" as well? > > In rfc6536bis-08, section "3.4.5. Data Node Access Validation", step 6 > states: > > * The rule does not have a "rule-type" defined or the "rule- > type" is "data-node" and the *"path" matches the requested > data node*, action node, or notification node. > > > My reading of this is that it implies that the interpretation of the path > rule is (i), but this is not how I would normally expect an ACL rule to > apply in a tree like object (e.g a directory file system). > > However, the examples in Appendix B.4. imply that the path rule is to be > interpreted like (ii), or otherwise the example rules seem to be mostly > pointless. > > E.g. taking this example from appendix B.4: > > > permit-dummy-interface > > > /acme:interfaces/acme:interface[acme:name='dummy'] > > read update > permit > > Allow the limited and guest groups read > and update access to the dummy interface. > > > > > If the rule is (i) then the access rule allows the client to read the > specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but > not any child leafs/containers of that interface, this doesn't seem useful. > > Further comments inline below ... > > On 08/11/2017 20:05, Andy Bierman wrote: > > Hi, > > This change has no impact on the server if /nacm/read-default is "permit". > In that case, the extra read rules for /A and /A/B are not needed. > > I agree. > > An operator worried about read access should set read-default to "deny". > > I agree. This is the scenario that I'm considering. > > In that case, explicit rules to read /A and /A/B would be needed > in the new NACM. > > Yes, if the interpretation of the rule is (i) above. > Otherwise if the interpretation is (ii) then you only need "read /A" since > that implies "read A/B" as well (as long as the rules are listed in the > correct order). > > > The deny rules would not be needed. > > Only if the interpretation of the rule is (i) above. In which case the > "read/write 'A/B/J' rule would not be sufficient. It would be necessary to > define an Xpath expressions that contains all children nodes as well. > Perhaps 'A/B/J//*'? > > If the interpretation of the rule is (ii) then you would also need all the > explicit deny statements as well, otherwise they would be allowed by the > "read /A" rule above. > > Thanks, > Rob > > > > > Andy > > > On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton wrote: > >> Hi, >> >> I'm not sure about this change. >> >> I'm not that familiar with NACM, but if you want to give a particular set >> of users read/write access to a subtree, but not allow them to have any >> other access to the configuration in the running datastore then with the >> existing RFC, that could be expressed with a single rule (example in >> 6536bis, appendix B.4) >> >> With this new change, I think that you may need to configure many more >> rules to achieve the same thing. I think that you would need to give read >> access to the top node in the desired path, and then separate explicit >> "deny" rules for every sibling child node walking from the top of the tree >> down to the data node that read/write access is actually being given to. >> The example below may explain my understanding better: >> >> E.g. For a tree of data nodes, rooted at A, if we wanted to give >> read/write access only to "J" subtree, and no access for the rest of the >> tree then: >> >> A >> | >> -------------------- >> | | | | >> B C D E >> | >> ----------- >> | | | | >> F G H J >> | >> ... >> >> >> In the old model, I think that the ACL rules would be 1 rules long >> (assuming default deny all): >> "read/write 'A/B/J' >> >> In the new model, I think that the equivalent ACL rules would need to be >> 8 rules long (assuming default deny all): >> "read/write 'A/B/J' >> "read A" >> "deny C" >> "deny D" >> "deny E" >> "deny F" >> "deny G" >> "deny H" >> Note, I am assuming that a "path" rule matches for the given path and all >> descendant nodes. The draft doesn't seem to be particularly clear on this >> point (it states that the rule applies when the path matches, but this >> would seem to be counter intuitive), and perhaps it could be clarified. >> >> If this change is allowed, then the example in appendix B.4 looks like it >> would need to be fixed, since the "limited-acl" probably wouldn't give any >> access at all, unless default read access had been given. >> >> But, possibly I'm misunderstanding how this all works! If so, apologies >> for the noise :-) >> >> Thanks, >> Rob >> >> >> On 02/11/2017 14:18, Benoit Claise wrote: >> >> Dear all, >> >> Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the >> Security AD Eric Rescola part of the IESG review, which I would like to >> validate with the WG. See https://tools.ietf.org/rfcdiff >> ?url2=draft-ietf-netconf-rfc6536bis-08.txt >> >> >> The NETCONF WG was cc'ed for the entire discussion. >> What do you think? I will draw the conclusions by Friday Nov 10th. >> >> Note: If the WG is fine, the next step is to approve this document. >> >> Regards, Benoit >> >> >> _______________________________________________ >> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >> >> >> > > --001a114b72f4a741ea055d997be9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The term "data node" is u= sed in the document to refer to the top-level node
of the spe= cified object, not the entire subtree (if any).

Th= e data-rule /foo does not match /foo/child1 in the text below.
Th= e child nodes are omitted because of step 11.
The admin has to ex= plicitly permit individual child nodes (or modules).
This seems c= orrect if the read-default is "deny".

Sh= ould any text be added or changed to make this more clear?


Andy


<= div class=3D"gmail_quote">On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <r= wilton@cisco.com> wrote:
=20 =20 =20

Hi Andy,

It isn't clear to me whether matching a path in NACM either:
=C2=A0 (i) Only applies to the specific node, and not any children, o= r
=C2=A0 (ii) Applies to the specific node and all descendant children nodes as well.

As an example, using the tree below.=C2=A0 if I have a rule that matches path "A/B" then does that apply to only the specifi= c node "A/B", or does it also apply to all descendant children of = "A/B" as well?

In rfc6536bis-08, section "3.4.5.=C2=A0 Data Node Access Valida= tion", step 6 states: 

  =
      *  The rule does not have a "rule-type" defined or the &quo=
t;rule-
           type" is "data-node" and the "path" =
matches the requested
           data node, action node, or notification node.

My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system).

However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.

E.g. taking this example from appendix B.4:
  =
     <rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme=3D"htt=
p://example.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name=3D'dummy'=
]
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Allow the limited and guest groups read
           and update access to the dummy interface.
         </comment>
       </rule>

If the rule is (i)=C2=A0 then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name=3D'dummy']= " but not any child leafs/containers of that interface, this doesn't seem useful.=

Further comments inline below ...

On 08/11/2017 20:0= 5, Andy Bierman wrote:
=20
Hi,

This change has no impact on the server if /nacm/read-default is "permit".
In that case, the extra read rules for /A and /A/B are not needed.
I agree.

An operator worried about read access should set read-default to "deny".
I agree.=C2=A0 This is the scenario that I'm considering.

In that case, explicit rules to read /A and /A/B would be needed
in the new NACM.
Yes, if the interpretation of the rule is (i) above.
Otherwise if the interpretation is (ii) then you only need "read /= A" since that implies "read A/B" as well (as long as the rules a= re listed in the correct order).


=C2=A0 The deny rules would not be needed.
Only if the interpretation of the rule is (i) above.=C2=A0 In which cas= e the=C2=A0 "read/write 'A/B/J' rule would not be sufficient= .=C2=A0 It would be necessary to define an Xpath expressions that contains all children nodes as well.=C2=A0 Perhaps 'A/B/J//*'?

If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.

Thanks,
Rob




Andy


On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want t= o give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibl= ing child node walking from the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ----------= ----------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 B=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0 D=C2=A0=C2=A0=C2=A0=C2=A0 E=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 -----------
=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |
=C2=A0=C2=A0 F=C2=A0=C2=A0 G=C2=A0 H=C2=A0 J
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0 ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
=C2=A0=C2=A0 "read/write 'A/B/J'
=C2=A0=C2=A0 "read A"
=C2=A0=C2=A0 "deny C"
=C2=A0=C2=A0 "deny D"
=C2=A0=C2=A0 "deny E"
=C2=A0=C2=A0 "deny F"
=C2=A0=C2=A0 "deny G"
=C2=A0=C2=A0 "deny H"

Note, I am assuming that a "path" rule matches = for the given path and all descendant nodes.=C2=A0 The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't g= ive any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!=C2=A0 If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:18, Benoit Claise wrote:
Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-netconf-rfc6536bis-08.txt

=3D""
The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


_____________________________________________=
__
Netconf mailing list
Netconf@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/netconf




--001a114b72f4a741ea055d997be9-- --001a114b72f4a741f7055d997bea Content-Type: image/png; name="dfpcfioondggippe.png" Content-Disposition: inline; filename="dfpcfioondggippe.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 13a1986fc67d042_0.1.1 iVBORw0KGgoAAAANSUhEUgAABKYAAAGcCAIAAABspT/dAAAgAElEQVR4nOx9Ma7jOtK1FvGC+YHG lxgw0NELXnKjzh6gRJN140WzgAYcKp4JZwFCpwommy0M4BV4LXcL/gNbUhVZh2LJsiTL54BA95Wp YrFYEuuIJbH4F0EQBEEQBEEQBPHKuGIUa+tGEARBEARBEARBPARSPoIgCIIgCIIgiN2ClI8gCIIg CIIgCGK3IOUjCIIgCIIgCILYLUj5CIIYwc8//1YURfG3P3+aP//1e5H6ORTU1budlnGWW9Ei1mf4 5fe/5muPIAiC2BU43xF7BSkfMY77Lc66efz1++SbirodroPuvriuFluGnFMMK91+zhv/yNjzT4Gd o4bqCjX/+p3DTRAEBue7twXnO2LfIOUjcnC7t2xzCvz555/Tn2Pdbo6buif+9eeWtPnXv6CR/FPY c+efn3/+bspW6j/gsARBvAU43y0HzncTwfmO8IOUj8gBnAJXx1+/P6TX1qbAn3/+DWvTKfuX9bC2 S0b5/XfdI/Ek0LBTTv7HvY6uYB4cgZ5+ghBo+PGucSi67wiwD/hdJ+l4HtMSBPGW4Hy3EDjfcb4j lgQpH2FguDHKZ0XF73+JG83vf6nUhT4Z5neVFdNXud2Zw8T2QMyfUUaNSl0Ib15xFkak+FjPgllF nBVPHb3Kf0ZTkMqpD2+4tjLilNAmyQngVj+Ygfrx6aRqleXMok/6258/R2czI/4J+5s1p4gZUOvS S/v9L9HPMFFl8D5zbEGSizUDcgokCKIH5zvOd2HTnO+IPYKUj4jR36v++j2aAv/1r59//k0/ubrf X8TtVh6W9yB1MxV/iBt3fOpwlw7vXD9//qnuzsGDs/hG1x0eHriJSSrOhximdj2jhMeDACF8wNbf wKXq6se7Lj//Sj6DlcJB+9FIFUGXtK2kCTwzoHp/PfeJuPHMs//z/teff/4tsnn4YgKwz8+fP60I yDIBZ0CCIHpwvuN8FzTL+Y7YJ0j5iBjxnULe5OUdKJ4C5c1X3GGN23A0BUbVRQ1wn40nKDl5omkn OhYrqi1hzNqj2od3bvO+GzwWTabdKPWjhmLDm6ZX1UaeI0oTqAraPzJzhcZnQHtO7Uc174mlfuyr z1EzN0EQxL8430WW4HzH+Y7YJ0j5CAthUsT9rvT778Ed5LlTYPjUM753gTbt+tbdHk+B92eV6EFt 4qmnrDDAnL67DJuMKdA/A/7LeLqrZgagmNGsFRgoVUbnFfXI1p4B8dPZO7LmLiMI0DMgn3kSBCHB +Y7zXTzCltU53xEvDVI+AkHOGN3d48/ghvjcKfBf8mZt3v8mPPXUR5OKgkQX6zHscKfW93V017YS XZLnGDdzlOUSxyjhZJebm5KKJZTKM8yAVgZP9iPVUGOV56J8j488CYKIwfmO8x3nO2LnIOUjYtyT WcT9I5qujCQHcYuJH0Aa80bOFKjTaixNbzJuH64ecins1BJ1u/7r99//Gn/eamVKxF35KV73CFvr JiddoT9d3Zj7ZqMPV6NYI37kejPH3zrRicih/+mv39F0CKaN2wPbn2EFnIoyqPLX7+JJ7+0z04ZX /O3Pn3J85IxodEh29K/fowwtMbp84kkQhAbnO853ZkV5mPMdsQeQ8hEx/vqz+95YmLPx+1/yMeRf 4v/dnexvf5Nn/qu/eXeH9cOtoiiGD4IVw3fOZHqLAJxn1FMu1U7YNfV08idquf+lP/67/LhW/5k2 PfcUUoLSxk5zkaLUo7mo+t2I4WfgdJcGQ6rgw7SeUtmaGMI+BZWE7PAZOI49IrPfJ0V5TphipXuR ygECfdGNEQRBKHC+43zH+Y54C5DyEXMBZE/4UxUimWO3wNWRMVfPIN/X+Z9//k1OMc9Qy8DwPJQg CGK34HzH+Y7zHfFiIOUj5sL8U+Bfv4d5+pu8u/7882/hE8WZ5xqcspI8I3rM+ewpkBMgQRBvAc53 d3C+I4hXASkfMQ/AszUzISIb+mnidm+u+uHs3BNN5hvjxjnDKQvMgEHAQhAEsVNwvuN8t+ERIggb pHwEsWWMvoSQdybf5CYIgiA2Dc53BPFEkPIRBEEQBEEQBEHsFinK90kQBEEQO0JiziMIgiCINwQp H0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS10lO98Otzehy2bnAm1r14cTufx6k0p3rjN a2EZnE+HzC6sB2G8LZmOIAhioxiZ9y718XZLrdqcabKvXhzry3j1thLzXV4Ly+BSHzO7sB6E8bZk OoIgiJdH8fl5IxV3NnE+HcYZUFP2NOl8OmQQkabcLlk5n0rVYdMC63XgfDrYTWeN1FQMNHNZPpyw 81P7SxDEnpCa9NqqZxOX+jjOgNqqp0mX+phBRNpqu2TlUleqw6YF1uvApT7aTWeN1FQMNHNZPpyw 81P7SxDEeyJK7IQUQ1aRJCmkTBYWZEzn08G3Gpaj/4qUrykfJTrn08FH3MQTAEXvF8CWnw0QBPEq yJ0AIcWQVSRJCimThQUZ06U++lbDcvRfkfK11aNE51IffcRNPAFQ9H4BbPnZAEEQ+0NI+TIYX3hC FmMqFlg1urUi1UftDsfLRnSgS1dVdYccVkcPxEllKUibsXp2q1qW3S+D/mHL/S+mnuqMw6m5iW1E u5mmD0nmzSXuEhozo9e2802bw+kc6is6NlRP2Bn212dPgiDeBJnzXwbjC0/IYkz9XeyJ/OHWilQf tTscr1rRgS5dVdUdclgdPRAnVZUgbcbq2a1qVXW/DPqHLfe/mHqqM451exPbinYzTR+SzJtL3CW0 ZkavbeebNsf6EuorOjZUT9gZ9tdnT4IgiAAD5bvH1b4IuSm9IbX/jEypMSNQ3GVoV2YIWu/yWetq 1upTxFFEA5qe3eWpBTP5h1yHC1vHq3zRL8K0TWkMZUyJs8T2rF4LHVoDdu671p/UNHcDNc3Zrp5a 5bP667cnQRD7x+jMd4+rfRFyW3lDav8ZmVJjRqC4y9CuzBC03uWz1tWs1aeIo4gGND27y1MLZvIP uQ4Xto5X+aJfhGnbyhjKmBJnie1ZvRY6tAbs3HetP6ltb/9e2vZiV0+t8ln99duTIAhigLHKlxsi uxMGu9MylgU94g4G2/v8DL4ZM1CysH2DSTz2Lh/qYChjqCeXVsNl1nzKp+Ujaq04WI5YRfkC1crm E9o57GSkg1HbRfmm2ZMgiP0jc/5zvDHlThjsTstYFvSIO5rrP8E3YwZKFrZvMInH3uVDHQxlDPXk 0mq4zJpP+bR8RK0VB8sRqyhfoFrVXqGd9bmGDkZtF+WbZk+CIIgB8SYNeZRMve/lwsyUD6sDyNKb UD6T6mSNmp3YiRtMrqMZxlDMMVCTlI8giMeRPQPmUTL1vpcLM1O+Gyx1AFl6E8pnUp2sUbMTO3GD yXU0wxiKOQZqkvIRBLEkis84Jy6gHFE2oF7eC4J6o34gPwzc/emkJuLlK7DQpUiAsVRpU77+2Dht 0n0cLKoF63cIZ6B86kCoJV4MtQTbn29pSiWhp1ypXF2T8mE1U3Ye4eaZ9iQIYv9IzHlhTlxAOaJs QL28FwT1Rv1Afhi4+9NJTcTLV2ChS5EAY6nSpnz9sXHapPs4WFQL1u8QzkD51IFQS7wYagm2P9/S VkpCT7lSubom5cNqpuw8ws0z7UkQBDHgvsqHP8ofU7L090xsCie/l2L9MldUHjAbrap5uDx1r/PB d/P0Ke6NCIUUa39CuSOi3h0RfL4loacYxrI8DIzMbWGzu015OJ0SH2oJfhj9+sxdTaWc0XBWf3Ps SRDEmyA97eGP8seULP09E5vCye+lWL/MFZUHzEarah6u6u51Pvhunj7FvRGhkGLtTyh3RNS7I4LP tyT0FMNYVceBkbktbHa3rY51nfhQS/DD6Ndn7moq5YyGs/qbY0+CIIgAcWInsQs8YXWLX0IhCOIl sPbESiyLJ6xu8UsoBEHsDKR8+8QzNi4n5SMI4iWw9sRKLIpnbFxOykcQxM5AyrcnyO0AZ1/i6yST 9xEEsW2sPbESC0BuB9jOKxqn/hIEQbwqSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIht gZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhi V1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAI giC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkI giCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUn VoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJb IOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG3h+ZSvKYui KJunt0PMA46XA+fToSgOp/MGtCg2oMgIpuu5ATtv4rrYgB1G0ZRFhxXNtdqM2lZFUVTtau0TPnC8 HLjUx6I41pcNaFFsQJERTNdzA3bexHWxATuMoq36+W5tc2VhPsrXxXMCXWzSlI/P/bdA4i6xjyoO p7NsOAqGht8Op3NTls3tgKzXlC8QLM+A8+mQ20s8XnOM5BbxQL/Op1KZ1WFnP1J6NuVrePFEPUM7 A9nz+KctZxPen+Vv62l6Ph3spp96XcR4+szZxXMCXWzSVo/P/bdA4i6xjyqO9UU2HAVDw2/H+tJW VXs7IOu11QsEyzPgUh9ze4nHa46R3CIe6NelrpRZHXb2I6VnW72GF0/UM7QzkD2Pf9pyNuH9Wf62 nqaX+mg3/dTr4hHMSfnKjo/d5vwhtJspAGnKw2GIJ4LQ58bngkPiOfPwkL4pD4e+3vl0EH8Rn5+f pHwuZFGRuUDKNyb71Sjf+XTwrYYtagc/HvfC8+kwwyO4p8+cfSjShRtDaDdTANJWx+MQTwShz43P BYfEc+bhIX1bHY99vUt9FH8R1+uVlM+FLCoyF0j5xmS/GuW71EffatiidvDjcS+81MdFH8EtRvn6 hTkZi4gcoIxJ/r5KdxegQp/7YfWIGYU9TVmeunPPp8PwR6JraB1R/FKWItgBx2F/hx+UGHg8oebh dA4T6GBCXa/m4dScDv3gmOMVreJGS6W5eiJ7Qv1dfnI7uSwtfxOCDoL0434BiO7K5wzAzhP6ZfjP qJ5hsH0/4XZQ/TFmvHggDbuJRMf7WfcHKsKdzCYNUoDsAOw8pnosydB/gpyZ7mP6rBw5Hn+b4s+e ccfXV9iyeDrnu//MkXrx9JlzhPL1C3MyFhE5QBmT/H2V7i5AhT73w+oRMwp72qqqu3Mv9XH4I9E1 tI4ofqkqEeyA47C/ww9KDDyeUPNYX8IEOphQ16t5rNv62A+OOV7RKm60VJqrJ7In1N/lJ7eTq8ry NyHoKEg/7heA6K58zgDsPKFfhv+M6hkG2/cTbgfVH2PGiwfSsJtIdLyfdX+gItzJbNIgBcgOwM5j qseSDP0nyJnpPqbPypHj8bcp/uwZd3x9hS2Lp3O++8+yqRdPeJcvplpNKZM8RdCoyc3Yg+mb4O4s GQL2VE9wPhgiivXApjyczuOPzc9NI2IgFcmoPw49jzSPw/6KH9QjbnQ8paqMnJpG051AgFBBv6gE xusTr3749AT2RPp7/UQpofxNhe+Fkpq/KiIz1Kx3q8x1Dk+/kP+M6Bm3q5PsRvuI/RbYTUoUbUXO pNs1/NC0w5idLZh9TIy7S85c97FPQGkm2sHyN0v/OPN+aMA37uD6gtqAX+D951McnPo+4BKT5w0x 1WormeQpgkZNbsYeTN8Ed2fJELCneoLzwRBRrAe21bG+jD82v7StiIFUJKP+OPY80jwO+yt+UI+4 0fGUqjJyattW/BSF2kIF/aISGK8rXv3w6QnsifT3+olSQvmbCt8LJTV/VURmqFnvVpnrHJ5+If8Z 0TNuVyfZjfYR+y2wm5Qo2oqcSbdr+KFphzE7WzD7mBh3l5y57mNXQGkm2sHyN0v/OPN+aMA37uD6 gtqAX+D95yoOPv99wIUonxUaikfaOgQZE3yLHfTTbhFhWquAkZjzqTydI0EAOlga45ToeKK/sgFp BHQ8pSrsTBycBQsMsQ0/M2mDU0/bnkh/t58onaW/6fNkUw7KF2qYZjDorE/cr5Q/ehM7h2M5Xo78 FtkNU75gaTX4E61wKzuM2tmCZZ/UuHvkzHMfi18mHqRPs0Mu5cMaecfdvr6wNvYv+P6jWz2MWNTG k+dNAYvyWaGheKR9x8jsrpcP9dNuEWFaq4CRmEtd1ZdIEIAOlsY4JTqe6K9sQBoBHU+pCjsTB2fB AkNsw2smbXDqadsT6e/2E6Wz9Dd9nmzKQflCDdMMBp11xf1K+aM3sXM4luPlyG+R3TDlC5ZWgz/R Creyw6idLVj2SY27R84897H4ZeJB+jQ75FI+rJF33O3rC2tj/4LvP7rV44hFH8WqlM+ZuSPY3OFw amQEojxnRP5NzPAOzVgIqIKRjGVEHEJlLtOZ1TK/fjCZ8pm0+TMM6cZDyXE9kT2R/v63g16F8tn9 mpPy9d3P6OCMlC/laLnrQi9E+fwZiOo14/7YNDvsg/KZn32xzJSJ502ZIfIpnzNzR7C547FuZQRi RVxI/k3M8A7NWAiogpGMZUQcQmUu05nVMr9+MJnymbT5GoZ046HkuJ7Inve/DWrkzfB6Fcpn92tO ytd3P6ODM1K+lKPlrgu9EOXzZyCq14z7Y9PssA/KZ372xTLT7FiR8mXmQJli5FdXYAgZsI+uOW8I KOWrGETLH9Kj0HHUX9UBcTI6noKD8uGOpSifepdLrrpm6wmbRfp7/QSFpNoAqiWzXxnSrUTWXMqX Wtgw/WdETxBsG981AsB+C+wm39Yt9ItYiaTZVIJfoE7SzhbG/TOL8QE7z3Qf6wUUegQn2iG9uptB m9zjPg/lS94I8GJoJp48bwrkUr7MHChTjPzqCgwhA/bRNecNAaV8FYNo+UN6FDqO+qs6IE5Gx1Nw UD7csRTlU+9yyVXXbD1hs0h/r5+gkFQbQLVk9itDupXImkv5Ugsbpv+M6AmCbeO7RgDYb4Hd5Nu6 hX4RK5E0m0rwC9RJ2tnCuH9mMT5g55nuY72AYPlqoh3Sq7sZtMk97vNQvuSNAC+Gzo5ZKZ9OTQry nvqlNfGbXp9LTvBqX4bb34fhgxjBVyqKIdoLxAdfXwilmpBfGylLFahJ+UH0Zh23+2uaLXF8XE11 AnyHR7ZwKMuDNok1XlKYDtcceiJ7wq8/uPxE6RzqrzQNqCb83Eja0uWpe70K2XlKv5BfWXomxrf/ PZeSgHaR3cTlIz6/0ZSH0yn+EElCT2AH285J2OOIxz1fzkz3MasZMJQjdkiOu8ufXeOOry/g6M77 z+dDr/D1eP7UGaYmBXlP/dKa+E2vzyUneLUvw+3v4/BBjOArFcUQ7QXig68vhFJNyK+NVJUK1KT8 IHqzjtv9Nc2WOD6upjoBvsMjWzhW1VGbxBovKUyHaw49kT3h1x9cfqJ0DvVXmgZUE35uJNmBoqq7 16uQnaf0C/mVpWdifPvfcykJaBfZTVw+4vMbbXWs6/hDJAk9gR1sOydhjyMe93w5M93HrGbAUI7Y ITnuLn92jTu+voCjO+8/14Ve4evx/K3YiZeAmVhF7ACL7iLx+Tkt05F4c8x9/1lqAiVeE2ZiFbED LLqLxPU6LdOReHOsd/8h5SM+P7PzRomXw/JbtJHyEV7Mfv9ZZTYlXgWZeaPEy2H5LdpI+QgvVrz/ kPK9M0TOFZf4dgaVT7ccB3PsgEe8O554/1llNiW2DZFzxSW+nUHl0y0XTjt2wCPeHZu4/5DyEQRB ELvCWhMqQRAEQWwTpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wE QRAEsS2Q8hEEQRC7wtoTK0EQBEFsC7NSvnO3HXNTvsUX+16hvxtWLUL3Ab/83aOf+J3RueQ/W88d wDXub41z1n70xDKU79Jtx9xWb/HFvlfo74ZVi9B9wC9/9+gnfudvLvnP1nMHcI37W+OStR894cG8 q3xNeQtIzqfDNsLcxKZkc+wENVt/kZ4TNlWL+zVhn7TlN3OTbcfq2vo8W0u//HX0XBXe6wjW38x2 fmp7i8f4+hNG/nwqlzDTbbON+4j0O2/0NzuwD8fw2+F0bsqyuR2Q9RZ6BrXI7NlWt4DkUh+3EeYm NiWbYyeo2fqL9JywqVrcrwn7pC2/mZtsO1bX1ufZWvrlr6PnqvBeR7D+ZrbzU9tbPMbXnzDyl7pa wky3zTbuI9LvvNHf7MA+HMNvx/rSVlV7OyDrbe4Z1PyUr2xuM/8m4rcnB9uz9XdGymcJIeWbqAkp 33LYDOW7Yw59XpfyfX5+NuXhcOj1D9q98bngkKDHw+J2Ux4Ofb3z6SD+eiIWmT3b6hYgXerjNmb1 Jwfbs/V3RspnCSHlm6gJKd9y2Azlu2MOfV6X8l2v17Y6Ho+9/kG7Nz4XHBL0eFjcbqvjsa93qY/i r01gXsrXP8FvSv1sPN6g+f6wt5GPhY3q8nD/xDhMBDOfO4fP6o2fLGoR1b5nb5bdL7JfsL/QPPl6 Yv1H7WCt8qkH9X1Xb0rfz1N/WHYD4+JGap0gCrUT+jRl2TTWuFjjiPqr2ugc8vYTlp/uVLaepj3v gm4H1B9Oe0I/8Y/jcEJZloEjxh5yv1j6TnddTidwxhTL3a9ZYfqhfR+w7DPhOoLXhRAf8iwP0ted YYCyOZ860qfavR8efv1MPrY6deeeT4fhj6dikdmzf4LfVvrZeLxB8/1hbysfCxvV5eH+iXGYCGY+ dw6f1Rs/WdQiqn3P3qy6X2S/YH+hefL1xPqP2sFa5VMP6vuu3pS+n6f+sOwGxsWN1DpBFGon9Gmr qm2tcbHGEfVXtdE55O0nLD/dqWw9TXveBd0OqD+c9oR+4h/H4YSqqgJHjD3kfrH0ne66nE7gjCmW u1+zwvRD+z5g2WfCdQSvCyE+5FkepK87wwBVe6k70qfavR8efr0mH1vV3bmX+jj8sREs8fmWplTh r0U6PiVrUrFWQKbOIiL/bJp7NNI0Z7t66il7FGIiPdUi3iPP/v16Qv1NO3TnxP3S4X4nU0pX0Zvd bmpcXMB2MPVH+vR5tcFZcBxBf5VFApd0jrtTT2DPjLFQSNjT8hP3ODaleSnEv3YSD6fz8K/uDbak Qfl8/ZoZNgW1/AHbx3cd2f2VmbCPvcuXvu4MPctm0FZSvn5IxdhCKirWA5vycDovs0y54pzaVir8 tUjHVbImFWsFZOoiIvJr297+vbTtxa6eesoehZhIT7WI98izf7+eUH/TDt05cb90uN/JlNJV9Ga3 mxoXF7AdTP2RPn1ebXAWHEfQX2WRwCWd4+7UE9gzYywUEva0/MQ9jm1lXgrxr53EY30Z/tW9wZY0 KJ+vXzPDpqCWP2D7+K4ju78yE/axd/nS152hZ9UO2krK1w+pGFtIRcV6YFsd68tyy5R5WIDyhWFP P+XHS4H3RKAigKhlxgv6gfpUygf1VEFrGMB64NczQflg3GRRPsvOXsqXHBcXsB1M/YE+SH88jjn1 pbGwfRB8emJ7DjbICZAT9jROnzCOsoGoMrqOBq4wmfK5+jU3TH3s+wC0j+86Mvsb9vSBZ07p6y6C Hkihh+x738Mk5bv9Ggl6ItabUsOwp5/y46XAeyJQ6A+ilhkv6AfqUykf1FMFrWEA64FfzwTlg3GT RfksO3spX3JcXMB2MPUH+iD98Tjm1JfGwvZB8OmJ7TnYICdATtjTOH3COMoGosroOhq4wmTK5+rX 3DD1se8D0D6+68jsb9jTB545pa+7CHoghR6y730Pk5Tv9mskaBNYl/KZsWIyprFDWBiZb4nyTdFz JsoHOuqlfPMk0KXsgNpZjvKZ4aytqNk3j55JPz/cL4aMyDxhT/N6eTApN9O9HqV83n7NDQfl03VG Vvlw/83+zkb5xq4744RehcPh1MjboZrBR/z5Jmb4wtUbUz4zVkzGNHYICyPzLVG+KXrORPlAR72U b54EupQdUDvLUT4znLUVNeDTM+nnx/vFkBGZJ+xpXi8PJuVmutejlM/br7nhoHy6zsgqH+6/2d/Z KN/YdWec0KtwPNatvB1ajBX3q2rvJ1Wt0aG1sUxip35hZYjACzMJKpV0NBLCqi8I6N/Cn8aoEXiq /Qjl8+sJ9Xeu8ulMxyGN0c6xBe2mx+VQZC77pexg6o/0QZQMjiPoL1RoCuVz6ZkymPF9jNE2Y3ta Erw5ucqeS1I+Z7/6mvN8LTib8iXs47mOUH+j9cT49b9ZrjvjBNnb/qsrcJwC1+i6iR/BPBMrzqk6 FpAReGEmQaWSjkZCWPUFAf1b+NMYNQJPtR+hfH49of7OVT6d6diJGWqGOwmY7abH5ZizcBDqFw2K pT/SB1EyOI6gv1ChKZTPpWfKYMb3MUbbjO1pSfDm5Cp7Lkn5nP3qa87zteBsypewj+c6Qv2N1hPj 1/9mue6ME2Rv+6+uwHEKXKPrJn4Esw0ssxW7ymVSfOaU+FBL8AP8drr8KkFZ6hBIfTXcEh5oFB/t q5eN+r8fTj1z9bfTwrpf7i/yDXYOorLuYKNjR1sfc1z6H3KNAuyQGBdLn073fglBnGH7G+6v+NpL WR76wBzKz+lbjp7Qnt2PWSbNtKdpTaPdCDoT0brshp9Eb7tXSDtWgsYXjru/X5+zUD67AXwfAPYJ ZI1fR/D+oPJGT/J1vjmuOxvh555ub2aG3Rn+1hdNXyP4alH0EamnYdVZVeUyKT5TJz7UEvwAv50u v0pQVToEUl8Nt4QHGsVH++pVq/7vh1PPXKoM+VoAACAASURBVP3ttLDul/uLfIOdg6isO9jq2NHW xxyX/odcowA7JMbF0qfTvV9CEGfY/ob7K772UlXHPjCH8nP6lqMntGf3Y5ZJM+1pWtNoN4LORLQu u+En0dvuFdKOlaDxhePu79d1FspnN4DvA8A+gazx6wjeH1TeaC1f55vjurMRfu7p9mZm2J3hb33R 9DWCrxZFH5HaAJahfDa29lV2YiqMj3q8Kh55V3NeLPc1fuJFsaPrbm6sPbEa2NpX2YmpMD7q8ap4 5F3NebG11RBic9jRdbceSPmIx/HI5zu3hThvcS1wMz9iDPu57mbH2hOrAVK+veCRz3duC3He4lrg Zn7EGPZz3a2I1SifsXMaQawDkfK2egitkv54bRDEFKw9sYYwdk4jiHUgUt5WD6FV0h+vDYJ4LtZc 5SMIgiCI2bH2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7 wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKd9UNOUWvu+o0H3scW/feUT9erf+EhOwwesUYXzc z3If9tXwCv659sS6O7TVFr7vqNB97HFv33lE/Xq3/hITsMHrFGF83C9yH/bVsC//JOUL4diZDW+d tuamamC7w6fuOLdEf9E2jmts77hmf7eEhB1W2eHQ1sc/Whu8fjucT+U23MLSc4LdnuQna0+sLwPH zmx467Q1N1UD2x0+dce5JfqLtnFcY3vHNfu7JSTssMoOh7Y+/tHa4PXb4VJX23ALS88Jdlt9J0xS vgfwUpTvyW2S8s3fxktTvlVAyrccZqJ8T8KKc+pu8VKU78ltkvLN38ZLU75VQMq3HGaifKtjVson dpEOogG513UpQgVwfNinPRA0/KDEwOMJNQ+nc5igBBOWejUPp+Z06BPFmrJs+pa7WEdtpZ2X/mTZ rSlFc+IXdFzaKDsB0m3ntPKxpEFODn3B/mP3K308rAXtBv3B1H9Sf5H/p+zjoXyxnKSf2OM+el0Y VjPtgBP/oD3LMryOgvqP+KF5nU7oV6LZ4OpXo6CliETT4Nxe28R1WjbjlA/7s+d69+r5wH3PkAP8 IR9LTJ5iF+kgGpB7XVciVADHh33aA0HDD0oMPJ5Q81hfwgQlmLDUq3ms2/pYdIlibVW1fctdrKO2 0jalZdmtrURz4hd0XNooOwHSbee08rGkQU4OfcH+Y/crfTysBe0G/cHUf1J/kf+n7OOhfLGcpJ/Y 4z56XRhWM+2AE/+gPasqvI6C+o/4oXmdTuhXotng6lejoKWIRNPg3F7bxHVateOUD/uz53r36vnA fc+QA/zhGZiX8jWNiGX7ufp8Oug/7lM8Ot4EZK6vI34Q1fHxlKqCuX02jQ4zAwFCBf1iUFPK4E7H 1J5IBdgtaqxTFxxH+uN+Oe2MYfa3KTV5GpUD7ID0Hzlu6QPtZvlDQn9Xf7GfJ+3j6ZcpB/sPGHdg h8S4pPzcuo7s/konaxQhnsUP4XU6rV8hQg7W/w37K6WfT4cRyiczH7Pf5bP92X1f9egZnpEL+xGV fV/Nx5Pnzev1er1e2lbEsv1cfamP+o/7FI+OtwGZ6+uIH0R1fDylqmBu17ZtxU9RyCVU0C8GtZUM 7nRM7YlUgN2ixjp1wXGkP+6X084YZn/bSpOnUTnADkj/keOWPtBulj8k9Hf1F/t50j6efplysP+A cb+C6wKPS8rPrevI7q90slYR4ln8EF6n0/oVIuRg/d+wv1L6pT6OUD6Z+Zj9Lp/tz+77qkfP8Ixc 2I+o7PvqM/CsVb5CPvi2H0uj4+JRdCBJNRAHqvHxlKrwWXkYZOgwRodKKCRyUj7TbhHt6YSi40B/ 3C+3nSGs/obHcpcnUMNzUD5oN0O5lP6e/mI/T9snt19QDuhvYtyBsnhcPJQP91deO+o6msUP8XU6 rV9AfMcr+wZwf11UappbmP7svd5XpHy2Pzjw1FnzDv2gd3jwbT+WRsfFo+hAkmogDlTj4ylV4bPy MMjQYYwOlVBI5KR8pt0i2tMJRceB/uj4BDtDWP0Nj+UuT6CG56B80G6Gcin9Pf3Ffp62T26/oBzQ 38S4A2XxuHgoH+6vvHbUdTSLH+LrdFq/gPiOV/YN4P66qNQ0tzD92Xu9r0j5bH94CmakfCrCFDO1 n/JlPsY2q2V+DWAy5ZMhyDyUD9kNKjISS+dTvkfsHMp+nPJBO4zo66B82G77pHxmf5NybaoAx+XJ lE/VnuqH6Dqd2i9DtfJ0Pp9Ot5zL/tTtUT7v9U7Kl4KKMMVM7ad8mY+xzWqZXwOYTPlkCDIP5UN2 g4qMxNL5lO8RO4eyH6d80A797w9TPmy3fVI+s79JuTZVgOPyZMqnak/1Q3SdTu2XoVpVXy51fcu5 7E/dHuXzXu+kfE7olCz9DDl4Y+j2EzpuJPVFDciT0fEUHJQPdyxF+dT7M8mgJSG+MJMJ0XGkP+6X z855fRi6oBscXeSDdkD6jxw3KmK7Wdol9Hf1F/t50j4TqaxkFtB/oEOOUIVwXFJ+nk4kli2BEH8u P4SUb1q/YpxPp9OpvK3wFWa+ue7v8IO1g4SR2KnXPafe39zXu0/P4FiG3ZCcV6F8+h0lOWsHbwzd fkLHjaS+qAF5MjqegoPy4Y6lKJ96fyYZtCTEF2YyITqO9Mf98tk5rw9DF3SDo4t80A5I/5HjRkVs N0u7hP6u/mI/T9pnIpWVzAL6D3TIEaoQjkvKz9OJxLIlEOLP5YeQ8k3rV4xLXdd1dVvhK8x8c93f 4QdrBwkjsVOve069v7mvd5+ewbEMuyE5L0v5ZHrQoSwPRcBeOgRpktZxnXGl4g6jOjo+rqY6Ifr+ gKX+oSz7vK2hUn+qkSo1HqAhuzXl4XQyPrgAjiP9E/3y2TmvD7K/SpJnYKQdJvTLRqbdFHNH0p39 BX5u1nf3C7WL/AeMO7RD4rq27JB1HQ1H5bWjr6N5/BBfp85+pe3fv5+Z4w/9cfk5KGw3lXd5Gnud L+HP3uvdqafPbkAO9gcXnjpr3iC/hlBV4l0SnVSkQyvzuM64UnGHUR0dH1dTnRB9f8BS/1hVfd7W UKk/1UiVGg/QkN3a6ljXxgcXwHGkf6JfPjvn9UH2V0nyDIy0w4R+2ci0m2LuSLqzv8DPzfrufqF2 kf+AcYd2SFzXlh2yrqPhqLx29HU0jx/i69TZr7T9+/czc/yhPy4/B4XtpvIu67HX+RL+7L3enXr6 7AbkYH94ErhJgxNTnzpPwJZ2JdgD3s1u79ZfgujxvCnzvfD8p849trQrwR7wbnZ7t/4SxASQ8vmQ mTc6C0j55sW72e3d+ksQPdaeWHeCzLzRWUDKNy/ezW7v1l+CmABSvhyIHKTllvi6FtF3NhnPe/Bu dnu3/hKExNoT60tD5CAtt8QX5l+ljxNpvJvd3q2/BDENpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLEr rD2xEgRBEMS2QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARB ENsCKV8Gug928tuHxGxoygW//7o1nMf2Eyc6vLWfTMfaE+sro/tgJ799SMyGtlrw+69bw2VsP3Gi w1v7yRLYCeVrShgUzbaTHrc5Ww9LjK+z3RnkzCV9TkmLtXs+lePD9lz7bwpiI5hwe42k9kvuFDqK ta7TGGtPrM9FW8GgaLad9LjN2XpYYnyd7c4gZy7pc0parN1LXY0P23PtvymIjWDC7TWS2i+5U+go 1rpOH8H+Kd+MbWwntHo3vCClyZBDyvdE+U+R80T09uh0He43L6D9HdvRdO2J9blYIqQj5VsPL0hp MuSQ8j1R/lPkPBG9PTpdh/vNC2h/x+toOmBWyiceVI+yo6YsiuJwavpTxBlAzu3w4XRWiZbR0/Hh FJyQKfdWL2+hlUiguv8aRC8x5XPpOcluhp6p48P+23ADdyUGHkeIN/hOjSPQB9rHtMOk8TU2Ir9V Lsvul7HYNNGua6PzhJymLJvG0geOo0++2z/7E7oBvStl6ZO0D4Bwt0ZQvqnjHjdq+LN/HLF9POPi xQjls/wkx/+917WqD/tr3H/Wuk4Blpg8xYPqUXbUVkVRHOu2P0WcAeTcDh/ri0q0jJ6OD6fghEy5 t3p1C61EAtX91yB6iSmfS89JdjP0TB0f9t+GG7grMfA4QrzBd2ocgT7QPqYdJo2vsRH5rXJVdb+M xaaJdl0bnSfktFXVtpY+cBx98t3+2Z/QDehdKUufpH0AhLu1gvJNHfe4UcOf/eOI7eMZFy9GKJ/l Jzn+772uVX3YX+P+s9Z1+jDmpXxNI4KF0blav6UizkjIOatItBlOxq1FVO18OgxCz6eDmUB1Ph3G KZ9bTxtADtITHW8CMidMqwIqEcHaxwGaUtEVzfqMcYT6fAL7YHu6xhfpGYx1TtButgvlO+V8NmVh 6ZOym0u+0z9FHTWkCX08qzoys0+/y+cdd1Qf+7N7HG37uMdlCmJdgZ/0vyaO5FzXqD7qL7x/rned xnjyvHm9Xq/XS9uKYGF0rtZvqYgzEnIuKhJth5NxaxFVu9THQeilPpoJVJf6OE753HraAHKQnuh4 G5A5YVoVUIkI1j4O0FaKrmjWZ4wj1OcK7IPt6RpfpGcw1jlBu9kulO+Uc22rwtInZTeXfKd/ijpq SBP6eFZ1ZGaffpfPO+6oPvZn9zja9nGPyxTEugI/6X9NHMm5rlF91F94/1zvOn0Ez1rlKzIez4ZR Ux8vJOSAdDBPqIEzytyUz62nDVsOEoGOi0fyoUaygZh4ZQ+XriKWJcxxTOgDOoHt6RlfqKca03h8 bdlxJSzfJwf5W9JuLvk+/9QyJHPH+jgoX9hiwDM84w7rQ392j6NpH/+4TIFF+Xz3Jd91jeqj/qb8 fa3rNMZTZ8079IPeHMqn6vTxQkIOSAfzhBo4o8xN+dx62rDlIBHouHgkH2okG4iJV/Zw6SpiWcIc x4Q+oBPYnp7xhXqqMY3H15YdV8LyfXKQvyXt5pLv808tQzJ3rI+D8oUtBjzDM+6wPvRn9zia9vGP yxRYlM93X/Jd16g+6m/K39e6Th/BjJRPRf45MzWIAZJyNkT5puhpt2rL8VO+nOfh6CsK419XSFA+ MI4JgXZIDe35XpTPv65h6+nzTy0jT585KJ933PPuM9qf56F8y7zLOwPlE/B+NWWoj+SS8t2gIv+c mRrEAEk5G6J8U/S0W7Xl+ClfzvNw9BWF8a8rJCgfGMeEQDukhvZ8L8rnX9ew9fT5p5aRp88clM87 7nn3Ge3P81C+Zd7lnYHyCXi/mjLUR3JJ+SDklN6Ueat8VvJVUg6kfOp9m+AJf5zYGby5EwW31pfR 45DFr6cFKAfpiY6jXDOluDgZHc9RVPYQjGMy920kpA7t6RpfpOckyme0C+U75aBQfkLOoCXf7Z/o hIQ+qXEJoSwO8pFzxh3WT/izexxt+yQ6eFsTm2Pd72HK99B1re4Pdn/g/XO96zTGU2fN6/Wqp/S2 ylvls5KvknIg5VPv2wRP+OPEzuDNnSi4tb6MHocsfj0tQDlIT3Qc5ZopxcXJ6HiOorKHYByTuW8j IXVoT9f4Ij0nUT6jXSjfKQeF8hNyBi35bv9EJyT0SY1LCGVxkI+cM+6wfsKf3eNo2yfRwdua2Bzs 5GHK99B1re4Pdn/g/XO96/QRzJnYKb+qUJaH0QioKQ+nU/rDEFJO+H2AIISNPh8SfU9AJaSZcvrD 8vMVUM4UPZ12A3qi47ppxV9HjJAXraozVJxnjSPQB9on5T++8bX07KuXjfp/7tjI8NS2g09OJ0O5 WOxZRd6XQiw9/f4pvqZRlgfL+qE+tn1GlSyK8tS/zuccd1g/5c+OcUzYJzEuc1A+swPQT6D/e69r XB/2F92XVrtOIzx11rxBflWhqsS7MABtdazr9IchpJzw+wBBCBt9PiT6noBKSDPl9Ifl5yugnCl6 Ou0G9ETHddOKv44YIS9aVWeoOM8aR6APtE/Kf3zja+nZV69a9f80jHahHXxyOhnKxWLPKvK+FGLp 6fdP8TWNqjpa1g/1se0zqmRRVHX/Op9z3GH9lD87xjFhn8S4zEH5zA5AP4H+772ucX3YX3RfWu06 fQBrbtLAXQ/2AY7jDjF1dYUgtoDnTZmTwV0P9gGO4w7x/NUVgtgCSPmIR8Fx3B+8r4ARxKaw9sRq gFRhH+A47g/eV8AI4kWxGuVz7GxGbBgcxx1B5OBxiY94Zaw9sYZw7GxGbBgcxx1B5OBxiY94D6y5 ykcQBEEQs2PtiZUgCIIgtgVSPoIgCGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaFJ1G+c7/P8lpoyid/RLIp1/mu4VrtvhteyM7dhzY3 /c3UF7JnGmL/8D10Z6dYdhq99Pssr4W2evJHJNtqne8artXuu+GF7Nx9aHPT30x9IXumIfYP30N3 3h7PW+U7n8pFI9B4J7Gn7xfXlM+O+ewWnt/ujuHYcQ7beYsjMIe7z9WvHfgt8BO4RT13MtwUFp9J L3W1aAQa7yT29P3i2urZMZ/dwvPb3TEcO85hO29xBOZw97n6tQO/BX4Ct6jnToYviv1QvhikfMRD IOWbV84WrebF028qxCxYfCZdmvLFIOUjHgIp37xytmg1L55+UyEWxryUb8h5KhtJ+UQulA6YxAml jKXkntD9D7eDh9M5TGQDiW1NeTid+xbkj259UHfLpj9DRbPxBuV3Hbta9z8TTQgThJrCdr39gvVH VQqqm+OFj7vt7xoXr58INQ+n5nTojWraOTEuXv+x7HlPSG76n+6/oOPSdvqQcrGH/M3y55xOhWf4 /RYhtnPSPlC+7Z/AT8Ke9T3AibXouhg13Zavr5fAIrPnkPNUtZLyiVwoHTCJEyoZS8k9ofsfbgeP 9SVMZAOJbW11rC99C/JHtz6ou1Xbn6Gi2XiD8ruOXa37n4kmhAlCTWG73n7B+qMqBdXN8cLH3fZ3 jYvXT4Sax7qtj71RTTsnxsXrP5Y97wnJbf/T/Rd0XNpOH1Iu9pC/Wf6c06nwDL/fIsR2TtoHyrf9 E/hJ2LO+BzixFl0Xo6bb8vW1M8xI+WRmk3qXrwmCiz5UEj+cTwcVmatwKuKC91+bRtOsiPIVOpbu TnPqA9GUZiebUoW53R/hsmfOMihaLQHt+voF6yOcm0Z0Sw2RNV7ouNv+3nH5dPtJp4J+4QzY+ROP i09PYM9Iid5v7eOoX0ESYs4am1kH+LNbjttvsXTgz8hutvzUfSY8beSo+cuI/BgvdH1tHs+fOmVm k3qXrw2Ciz5UEj9c6qOKzFU4FXHB+69t29WKmrk3pWPp7jSnPhBtZXayrVSY2/0RLnvmLIOi1RLQ rq9fsD7CpW1Ft9QQWeOFjrvt7x2Xq9tPOhX0C2fAzlc8Lj49gT0jJXq/tY+jfgVJiDlrbGYd4M9u OW6/xdKBPyO72fJT95nwtJGj5i8j8mO80PW1I8xH+UIG08cR4pHzHdHj8eBgggolfkyF8ve/y2aC PhgysB3C6zDc7VW+/dDFvfClINTCeLu+fiXqA+hljiFytocEHZ9gf+e4JBr/jP1E21iHyJad43Om 6mnbE/ktPA76pY/l5Vlb/YL+7JQzwW8RbDs7r/exfjxK+fyZ7S90fW0eT585QwbTxxHikfMd0ePx 4GCCCiV+TIXy97+rdoI+GDKwHcLrMNztVb790MW98KUg1MJ4u75+JeoD6GWOIXK2hwQdn2B/57gk Gr/GfqJtrENky87xOVP1tO2J/BYeB/3Sx/LyrK1+QX92ypngtwi2nZ3X+1g/HqV8/sz2F7q+doRF KF/msgxYDUu2YjWIDvQhoE8fDCflO5/K0/l8Ot1yXrNebPKFzr5+ed9KUhG1YED+kPQR+2d+JWMy 5ZPUzk35XHoie0IF04rbdu3kZr5Gtw7le2RZSdjZeb1vjfK91PW1eTx95kxQvsxlGbAalmzFahAd 6ENAnz4YTsp3qav6cqnrW85r1otNvtDZ1y/vW0kqohYMyB+SPmL/zK9kTKZ8ktq5KZ9LT2RPqGBa cduundzM1+jWoXyPLCsJOzuv961Rvpe6vnaEeRM7VcgiE67MeFPFJiLU0FGHSl/yrvLpjLRhWcGl DwSgBFoRofH5dDqdytsKX95bSzpddOgAaNfXr5wcOiBGKIPHCx336+kcl8/pjwZUx1KUzxgXp56J ZpVz9Fqg46hfQ7Vs9jHerzwmM4vfZggP/RnZDa3JwvtM2MzIUfOXEfmp8zd/fW0ez586VVAcJFyZ 8aaKTUSooaMOlb7kXeXTGWnDsoJLHwhACbQiQuNLXdd1dVvhy3trSaeLDh0A7fr6lZNDB8QIZfB4 oeN+PZ3jcp3+aEB1LEX5jHFx6ploVjlHrwU6jvo1VMtmH+P9ymMys/hthvDQn5Hd0JosvM+EzYwc NX8ZkZ86f/PX144w6+dbVH7QSdAanbGk3r0ZTtDhVvwD+npC9L2IosufLA6nk/ndCbc+BrraZSPk WblqiimY79tkmTTU0mrX2y+7/rguxaEsD0XAUqwGwHGfnr5xcfpJ0MKhLA994AztbI2LW09oz6aU fqtfuTKOJ/rV/55Nqax+YX/2yPH7LQL2E9tuCfk59xmgJTyMXNfjuFu+vl4DS0yeKj+oFrRGZyyp d2+GE1ohSf4kX72xToi+F1F0+ZPFsa7N70649THQ1a5aIc/KVVNMwXzfJsukoZZWu95+2fXHdSmO VXUsApZiNQCO+/T0jYvTT4IWjlV17ANnaGdrXNx6Qnu2lfRb/cqVcTzRr/73bEpl9Qv7s0eO328R sJ/YdkvIz7nPAC3hYeS6Hsfd8vW1NzxvkwaCeEFkvWL5XKDHARMzINffLWUhcP8EosfaEytBvAKy XrF8LtDjgIkZkOvvlrIQuH8CMQGkfAQxYAt5bfNSvj1shpcHUj6ix9oTK0G8ALaQ1zYv5dvDZnh5 IOUjJoCUjyDk9marL/F1moTfIrGPQ6jkvv1zIbd9iF1j7YmVIDYLub1Zu64qaAc8x854N6jkvv1z Ibd9COJ6vZLyEQRBEDvD2hMrQRAEQWwLpHwEQRDErrD2xEoQBEEQ2wIpH0EQBLErrD2xEgRBEMS2 QMpHEARB7AprT6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8RALn02HkE4j3Le+f95HEptzAdzTH 7bA+xI7aa5trY+g+XrrxASRmxNoTK/GKuNTHkU8g3re8f95HEttqA9/RHLfD+hA7aq9tro2h+3jp xgeQWAU7oXyJzce2sNPa6nhgc7bxnbxn3A/N1nMTW8uFdjD9aj1N4RbyL+H/S9jtFbbt431sLqw9 sT4Xic3HtrDT2up4YHO28Z28Z9wPzdZzE1vLhXYw/Wo9TeEW8i/h/0vY7RW27eN9bHnsn/IRn6R8 Mc6ng281bNwOn2v64eODcD4dVlsHI+W7gfexubD2xPpcbIIUbBikfCEu9dG3GjZuh+uafvj4IFzq 42rrYKR8N/A+tjxmpnzxhsj3xL+m3xhaxl0iF00cvuVhHU7nMCFL7C49VFdbTts/WasxUe1b5bLs flGx11C/LHMiR6O+SFC861U2Cfsk7WZvPG3bLWEfYH+lfpNJ+fpTAoPe/1Z/mEjo2ZRl01jjgvRP 43ZWjhxgB9OvUnaGkHvAS8dy+WfYcv8L9P/+jM7BulPy03QT/gmv30S/gN3QBusOuwlZ+T6y1/vY +2CZ6TPeEPme+Nf2G0PLuEvkoonDtzysY30JE7LE7tJDdbXltP2TtRoT1b5VrqruFxV7DfWrKidy NOqLBMW7XlWbsE/SbvbG07bdEvYB9lfqt5mUrz8lMOj9b/WHiYSebVW1rTUuSP80bmflyAF2MP0q ZWcIuQe8dCyXf4Yt979A/+/P6BysOyU/TTfhn/D6TfQL2A1tsO6wm5CV7yN7vY8RMeakfE2pgzsV LfWRR1N2/1cx2HD48/OzD1zuFZvbv+emOdvVU0/Ho1AP6anWORoVSJpVIFB9qaVIxMP2gcdt/T+B 3YB9gP1lBlnWO2yaJ4iR0cmGOSsYaJWvsMYl5T9ZqvYHJ9nBohCW/lEsLxrQ9Gxg+z7/RNqAX4Sp zBclY0psA/nn0Gnthwm/Bf5p13fbrTuSSfl2ex97Jywwd7aVDu5UtNRHHm3V/V/FYMPh6/XaBy73 iu3t30vbXuzqqafjUaiH9FTrHK0KJM0qEKi+1FIk4mH7wOO2/ldgN2AfYH+ZQZb1DpvmCWJkdLJh zgoGWuUrrHFJ+U+Wqv3BSXawKISlfxTLiwY0PRvYvs8/kTbgF2Eq80XJmBLbQP45dFr7YcJvgX/a 9d12645kUr7d3scICzNSvjBc6ZdFwmj8XlE8GtehsDpZSzzYtV2hEtRTURRFV2TDOU/NQX1M+Sz7 YLsh/cM/cJ/v4i37hxLGY0akvzo5Ky8yI7FzsFvSfyL0Sy6W+pPskEv5sEa2RSb4J9DG/kXLR1RZ cRUbiXG3OpfyW9s/7fp+u3W/55GfHd/H3gjPnzrDcKVfFgmj8XtF8Whch8LqZC3xaNd2hUpQT0VR FF2RDec8NQf1MeWz7IPthvQP/4hF6mOm/UMJ4zEj0l+dnJUXmZHYOdgt6T8R+iUXS/1JdsilfFgj 2yIT/BNoY/+i5SOqrLiKjcS4W51L+a3tn3Z9v9263/PIz47vY4SBZSifGaskQzAzZCysyN9sW583 Z6jk/YqCrA8pn60gtNtclM/syBTKhw3cdTOTC/kon3/9oimtRa1pdtgH5TP93DKTT/A+Kd+O7mN7 x/OnzkSoZMYqyRDMDBkLK/I329bnzRkqeb+iIOtDymcrCO02F+UzOzKF8mEDd93M5EI+yudfv2gr a1Frmh32QflMP7fM5BO8T8q3o/sYtbg7EAAAIABJREFU0WHexE6dYthFIDIv71OEKqlcPDNU0u/s 6FBJJhaGD+OTsbp+R8sKlVT9DMoH6w8/qByxhH3AcaB/9Jel0mAfYP9ofTMnsVMNTbQWkrfEh/TM XR3NQ7x8NdEONuXDfmg1ELz5ZVH9cf+E2oBfUhcSXgy1BNv+GWgNFFE1gH/a9d12s5pP9muf97Fe 7Du84LfA3KljkiECkXl5VxGqpHLxzFBJv7OjQyWZWBg+jE/G6vodLStUUvUzKB+sP/ygcsQS9gHH gf7RX5ZKg32A/aP1zZzETjU00VpI3hIf0jN3dTQP8fLVRDvYlA/7odVA8OaXRfXH/RNqA35JXUh4 MdQSbPtnoDVQRNUA/mnXd9vNaj7Zr33ex3qxfMFPYt7Pt6gcJ5Xdd0p84CD4YfRrFEVRHMpSB+7D b8F3DExJlp599bJR/w8zt3JWP1B98Y0T8dkMZB9sN9PO0G7APsj+QV7qKf063/3tuEHPqKp69WoM sZ5dX8vmMxgXqH9uM8BVRuyQ8CtkZwg5kEKKzz/BwGf5/6EsdaKsgwwA/0z4oX1/wHaD9R12S48X 6plttde+j4lTSPlmgcpxUtl9deIDB8EPo1+jKIriWFU6cB9+C75jYEqy9OyrV636f5i5lbP6geqL b5yIz2Yg+2C7mXaGdgP2QfYP8lLr9Ot897fjBj2jqurVqzHEenZ9rdprMC5Q/9xmgKuM2CHhV8jO EHIghRSff4KBz/L/Y1XpRFkHGQD+mfBD+/6A7QbrO+yWHi/UM9tqr30fE6eQ8g1YYpOGd/2CQC6Q fXZit+wlPmIFPJD4txP/zMa79felseKcyi8IpIHssxO7ZS/xESvggcS/nfhnNt6tv28CUr71sW/K x63Gtgzvq6kS+/DPfLxbf18aK86pDJXS2Dfl41ZjW4b31VSJffhnPt6tv2+Cp1O+1E5ZBLbPy9tN 5aO9aB/2Crmt3eQlvvca23fr76tjrQk1tVMWge3z8nZT+Wgv2oe9Qm5r104T8fL+6cS79fd9sMQq H0EQBEEshrUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV 1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI+QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIg iG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtgVSPoIg CGJXWHtiJQiCIIhtgZSPIAiC2BXWnlgJgiAIYlsg5SMIgiB2hbUnVoIgCILYFkj5CIIgiF1h7YmV IAiCILYFUj6CIAhiV1h7YiUIgiCIbYGUjyAIgtgV1p5YCYIgCGJbIOUjCIIgdoW1J1aCIAiC2BZI +QiCIIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaF tSdWgiAIgtgWSPkIgiCIXWHtiZUgCIIgtoUFKV9TFh3KZuLpU06c1JCh54P6E8STcD4dbk7ZlEVR HE7n7bfblMup+QDOp0N2xx6/P9zsueQI7hdrT6zXa1v1/lC1E0+fcuKkhgw9H9SfIJ6ES328OWVb FUVxrC/bb7etllPzAVzqY3bHHr8/3Oy55AgS81K+LmIxA5/z6eAIhJrSqmwfnRdIT5/+CIkenE8H hnprYcVxmUN+U954wvl0WPR5xNR2rT5v1f/PpzJHrXnuD5+fNhte4s63Lywwd3YRixn4XOqjIxBq K6uyfXReID19+iMkenCpjwz11sKK4zKH/La68YRLfVz0ecTUdq0+b9X/L3WVo9Y894fr1WbDS9z5 3hVPWOWzH+D7HuuvR/mQnvMsSzB02yZefFya8sa4zqfDoktEE9udjx4tgEzKN9+yJSnfHFhuCrUf 4Pse669H+ZCe8yxLMHTbJl58XNrqxrgu9XHRJaKJ7c5HjxZAJuWbb9mSlG9ZLEH5kqt/EcLaIpZs yrLp06ekFJFTlRV42fWRnlh/2K44pSxv9kj0y0zokh0NO+3sr2gaD02nZ+o4bHf4QYmBxxGG+l3l e85g0yskpaTG8XA6h3Y17eAdF6Bnl+VYWv4JkCM/y279CllTBl4L9HHqj8bdancc0XqeO6HRe717 IczfSMrnu2/Y/iYS1O+/B5YL7p8J/yQwlptCo5AlufoXIawtYsm2qto+fUpKETlVWYGXXR/pifWH 7YpTqupmj0S/zIQu2dGw087+iqbx0HR6po7DdocflBh4HGGo31W+5wy2vUJSSmocj/UltKtpB++4 AD27LMfK8k+AHPlZdutXyNoq8Fqgj1N/NO5Wu+OI1vPcCY3e690LYf5WUj7ffcP2N5Ggfv89sFxw /0z4JzEHXmyVT1IBQUQ0yRgLPpP1Hat8SM75dNBhnyatWWp15/bVH+jv57lpRMCpVLP0RMdhu+IH 1V10HKApdWSsWJ9obCC+2A79a2afn5+fTdOk7PDpHBekp+pkvr/HNZ12gwD6ePV3+9u4VvbVnf3S 3Kz6hJCMVL3L575vIH+T3haveOau8kVckK8YCyw3hT5zlU9SAUFENMkYCz6T9R2rfEjOpT7qsE+T 1iy1unP76g/093ppWxFwKtUsPdFx2K74QXUXHQdoKx0ZK9YnGhuIL7ZD/5rZ9Xq9tm2bssPVOS5I T9XJfH+PazrtBgH08erv9rdxreyrO/uluVn1CSEZqXqXz33fQP4mvS1e8cxd5Yu4IF8xnoQXo3xW qCQevWeFPun6+ZQPyUllgvkon6gvTvT2NwwOB2Zq64mOJ9qVDcTEKzMeDW3T6xFH12WT1gd0wraD 1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4ZDHf/xCPVrkn5gL/NQ/mIFJab QpdJ7BxCJfHo/Y506JOun0/5kJxUJpiP8on64kRvf8PgcGCmtp7oeKJd2UBMvPKUjGzT6xFH11Wb 1gd0wraD1bbWK1zRBHqq8D0/edEYd5fdMGx9vPr7/W1UK/MSy71DzK1PpF4VDHf/xCPVrkn5gL/N Q/mIebALyudbBknX91A+u+aclO9+UMWF/v4WZoTpp3yZSaRmtfGvcyQon8m5kvoYnUB2sNrW5y1O +ZT06V81mYvyzZtK+Ogq35M/9pmgfL77BvY3Ur7nY7kpdHnK51sGSdf3UD675pyU735QxYX+/hZm hOmnfJlJpGa18a9zJCifybmS+hidQHaw2tbnLU75lPTpXzWZi/LNm0r46Crfkz/2maB8vvsG9jdS vi1hs5RPvT9mBKsiVPLmdiXruxI7bTk6SlcRrt2vVMvn0yF8ncvZXylXNYr0RMdRu0pxcTI6nqOo DL1lPu+nWvnEdjApH7DDp3NckJ5zUT6v3SCAPl79586dBF1C942iiF9ETF2/Uf17m9ZhoJ66zcgE Y899A/vb8Iu184xN+bB/EhaWm0LnoXzq/TEjWBWhkje3K1nfldhpy9FRuopw7X6lWr7Ux/B1Lmd/ pVzVKNITHUftKsXFyeh4jqIy9Jb5vFe18ontYFI+YIerc1yQnnNRPq/dIIA+Xv3nzp0EXUL3jWgd b+T6Ndf9VKLvqHrqNiMTjD33Dexvwy/WzjM25cP+STyGJTZp8H2+JTxHRUfF8IVAKUq3MB4i2/X9 +sN2ZRKY6m7cr9F3coxI09df+RWJslShL9ITHLfb1RlvMrLFnbKhzlA8+ZTx4QzxKqLZcMIOznGx 9JQ+Gfrn2LBoSX67JcUb+nj1915f46pBpwq7bFK4hD425Tu7dpFQebUn8Trf5PtG4G+9/bvvEqmb mmUHwz+JFBaYO/2fP8mRpaKjYvhCoBSlWxgPke36fv1huzIJTHU37tfoOzlGpOnrr/yKRFWp0Bfp CY7b7eqMNxnZ4k7ZUGconlxnfDhDvIpoNpywg3NcLD2lT4b+aQLK99stKd7Qx6u/9/oaVw06Vdhl k8Il9LEp38W1i4TKq63F63yT7xuBv/X2775LpG5qlh0M/yTmwYJbsRPEJLzItt1ENh5ZupzYHqnS e2HtiZUgJuJFtu0msvHI0uXE9kiVCBukfMTWQcq3Pyw7pvN/1pPYONaeWAliIkj59odlx3T+z3oS uwEpH7FpGDvIEQRBJLH2xEoQU2DsIEcQBDETSPkIgiCIXWHtiZUgCIIgtgVSPoIgCGJXWHtiJQiC IIhtofjf9X8sLCwsLP+7/u+/lyvLBot3HPGU928WFhYWluv13+tr8B5liRZI+VhYWFhcZXVuw2IW 7ziS8rGwsLCky/oavEdZogVSPhYWFhZXWZ3bsJjFO46kfCwsLCzpsr4G71GWaIGU7+nl8uNLURRV /b/2oyiKL/WvtdutP44/fnmltR/9Xpgf7domfYlys/8SI/7rx7EoJozp0mVBPduPpzrq6tyG5b// qf9fURRF8f/+cekPeseRlG/+cvl2LIqi+n5tvxZFcaxPa7f7vTp+u3iltV/F3s9rm/Qlys3+S4z4 qT4WxYQxXbosqGf79amO+hy5l2/HJW8QL1CWaOGtKF9dfdTgp1/1l6eF5vXHLe6//PiyKF+C7f6q vzjV+PXjCE33umUJf2g/FiH5v35U41Qq0d+lSpae3mL3q/34aJ/VkfUJzyuXn9+qn3NJ+2dFyodK W31twU+X+renxVrfq1sgd/l2XJQvwXYv9W9ONU71EZrudcsS/tB+XSSGP9XVOJVK9HepkqWnt9j9 ar++GuW7/vt6+VZtgvKd6uNv9WV1OaNVHr5OSfnmKmIRrEcX69cfN8Z1+fGl+PLjslh/cbuXH198 iy2TFgY3X5agQKR8fj29hZTvtQop3zLliSGvWATr0cUi36sb47p8OxazxFGZBbd7+Xb0LbZMWhjc fFmCApHy+fX0FlK+vZYlWliF8tXDRqL3+K+uiqL48qO958IViqLUA50SxONX/eVGq27/GU659EJE Tp04iH6KQ/NYzy5b8qNTKSeG/vXjeNOt/ujrJ+U427XtY7cb/jReOvP2aS51Ss/EuKBijlfKc4Cf ADm2PpP8QZji46P68uOiEgjvvwr7/O9qUT6XnilrDOP+0QoqNdX/c+zv9tuEntBvPSXRr/bjo61z rxfndX3PKvxW/XGvrzjMz2+d/P+r/z1KWroExULnKP73cv33P47dL9Uf345//0/6eNspE7Y76POt +kP8hI6jgvQx+ovsIzobdPkm/P/949K1kpT/UpRPbJx9j//aqiiK3+r2W2dQSVG+99VlVtil/q0o imN9uv1nOOXSCxFJUuIg+ikOzWM9u2zJr90vOTF0/6T7e9XXT8pxtmvbx243/Gm8dObtPf17Ss/E uKBijlfKc4CfADm2PpP8QZjia1X9Vl9UAuH9V2Gf69WifC49U9YYxr1qBZWa6v859nf7bUJP6Lee kuhX+7Vqv+deL87r+t/3LNXit/py+4+QJR7/xANsDO1Q/2s7Qvm+V0VRHL+1vShpOLtdS8+b11Zf i6Ioqu/3YescF/ufGMjqq8oUt47nyAkq31UalMkZ+tR9u/o69qxqDcpXVyos06yvj7QGllJXIvZt P1RI3b+udv3f/6513d4O1vVlaOujlU3jSC4KzZGeatHskTUcIMfbbso+yVGQlhkrxiof1BONC7QD HC+kueknKTlAH5c//Kq/DLbVYzG0dfnxZZzyufW0iiTt+h05r/877e/0W6jnNL8FLmGv8hWu68Vz XXfspaMlgnj8/CaY2z+rcdb3n/an4DZ//FPwq2+toIX3ttDxn4KD/fef1VBH6PbvfxwHfdDxBN+z 2wX9Bfb5b2KV704Ub620P/+ZYc/NU762UmGZZn19pDWwlLYSMUP7VYXU/etq139fr9/b9nbwe3sZ 2pJP+lOrHFFojvRUi2aPrOEAOd52U/ZJjoJnDcRY5YN6onGBdoDjhTQ3/SQlB+jj8odL/dtgWz0W Q1uXb8dxyufW0yqStOt35Lz+77S/02+hntP8FriEvcpXuK4Xz3UtfKLPmW6/tzePFFeCNOil/S7I rnj2o3nn2A3leyXomegAbNfWsxuhbtjC1G1lpvDIqT4WlkHVcSDneyVIoHSaS/1b5Bzjox+PVPvV FAnKCpSv/tCx3a/64xZmheHmPZKuo4xJEd5dfnzEkZl+8C9lekJ8qKcK6/v/pxI7cegcy/G2m7ZP Kkp2fVYkpnxYTzQuCTuA8UKaW36SlAP08fgDzkh0Uz63nqbRPgJ3PRqrfFn+77S/z2+hnhP9FrjE WGJnzvVi98sud34iKVBHVP7oD96ZUjUwsbFVvqLoKd/l799MDoaOiyW+O3padfn7/8UHE8fNgttF /bXtM0L5/tDrnOP23Drl+17p2O5Sf70FAGG4eY+kxSP5O0RkYj4T1w/+p1I+qKcK6/v/pxI7QTHl eNtN2wcXFaDnjFoYOWE90bgk7ADGC2lu+UlSDtDH4w84I9FN+dx6mkarAnc9Gqt8Wf7vtL/Pb6Ge E/0WuMRYYmfO9WL3yy66k7rVUH64eqZaDSWMP0MKl+zvncftIj1v1unI1TjlU44SP3iLj5tywnTb 4bqSbxh3/x8ffcNg3XJmllNti/LpTLae8iWSvowQWSUxBt8peSLlm1DmonyTkuIeXuWbi/Klxgto DvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/tUB/lQ+2uQ/naPwTd+vc/jtMpX2YSqVkNHSfle7QkKJ8Z GyTfIjNCZBURBd8peSLlm1DmonyTkuIeXuWbi/KlxgtoDvwkIWdDlG+KnkZJUSmX/7vtPxvlm+/t UB/lQ+3ORflszqbWMQd+NYXy6Q70lC9x4jyUTwm0v5oSH1+B8ukx3d4qXxCyD5F0XalXevowLkVO TMp3VC8LyXNF0+FPVmKnreeTKZ+7XSd568Rmv8sXWXXMPva45EiOBsX2H9NPknIg5XP4g/6G568f x67+ULP+KEbf5ZuiJxhBRdUKg0rl+L/b/k6/RXqOXNdfYkumXMIaR0DFYbvzUD6dYAmZkknV2j8K ldgpyMzl7/93/wkdl0mhsih9BLVDx1HB7YL+piifev9wUNugfGP23DrlC2KAYcZvK/VmSh/GpciJ SfkGId33S4ymw5+sxE5bzydTPne7TvLWifV9SM9M7AR62uOSIzkaFNt/TD9JyoGUz+EPOpo91cc+ Ua6vqXPubDlT9AQjqKhaYVCpHP9329/pt0jPkev6aK0YYZewxhFQcdjuPJTPeHE28oP2q722aCVG RqX7Dm//57B8mfj+7OOUT90CxMWAjmfJkR4/E+VTDW6T8gW5VX34VVdffohfgvB6wPCOkFrW7eWI b2x8+ai+yJ9EDpt+v0hLqhN69hKqWv3fa4SUHG+7pn3GWs9eY8GfbzHHEY5LhvxovKyC/ATISerj 8wfxeRIlp9em+65MVSfkTNEz7UJFUVQ/+tfknP7vtL/Xb7GeCb/9VX/x5XnG/eoSrT/a/2VdL87r esjG/Naq/3c0podJwwIq1avyx7ejPGX4bImWA47LRM3hSyeyskzgRMcTBbRr9TdlH5nL2tM5rfyo /Kj+rQu5DtOVBShfkFvVz/Jt9VtdJz5A0P/Qh5K6tyJa6I79VlW/yZ9ECpJ+v0hBvicWye8lVN/V /71GSMnxtmvaZ6z17DUW/PkWcxzhuGTIj8bLKshPgJykPj5/EJ+FUHJ6O3Tflam+J+RM0TPtQkVR VN/61+Sc/u+0v9dvsZ4Jv73Uv/nyPON+dXmO3RdrpZ5Wu87rOv5ujEo3V/LvDipaPX6tjoXlEEVV j77O9706fhOBl/39oqFdU09hnfsHke4fd/naRt/DMUcX3QX0m5GmnCAHNTRC1cr/YzPA66utjIO4 rEP5cCi/3AYGb138+/JtqNBP9l5+/TgusH/9Q2WUHbGsUrzjuAjls0s6k4hlxuLfl29DhX6y95Kz 1rVyWbHtfe6XAsoSLZDyvV957U326Cd7L/GeIpsrq3MbFrN4x5GU7w3KaweN9JO9l1SK4kbKqtZ5 5avXWZZoYSOUD+zoxcKiCv2EZQtldW7DYhbvOK5F+cCOXiwsqtBPWLZQ1mrY2NFu12WJFjZC+VhY WFhepazObVjM4h3HtSgfCwsLy6uU9TV4j7JEC6R8LCwsLK6yOrdhMYt3HEn5WFhYWNJlfQ3eoyzR wotSvtVji42HMiwsLCws6fJsyrd6DLHxsnb7LCwsLO9TSPlepKxucBYWFpadFVK+tQOQ1VVgYWFh eZNCyvciZXWDs7CwsOyskPKtHYCsrgILCwvLmxRSvsuwL/D/+8dlJpmXv//fsBXyOpSv/ShytvOe p/wS+2tvuWxAz0XH5d3KBsb3OuzqHm4tiI6zrFdI+axyGd0feShiJ+AJX5p3q9Z+LXK27Z6nnMQ+ 2lsuG9Bz0XF5t7KB8b0Om42HNwZ0nGWLZT3K96v+8kjoM/9K2j8rk/L9+x/HSVTw8vdv45Tv57fq 5xyUr66sfczaj4/WZ1VbTlb59aMaD7UfkD9XydJzhtLF9wLddoLJcXnwuphdzrPL3Hpuxg/bD7tf 6Pg7lQ3cB+5lN5TvVB9n3b7t8q3KieAu347V94cCkNTvbWWxyParl1rYcjLtWo2H2g/In6tk6TlD 6eJ7gc7vkuNyqX+bhRLMJefZZW49N+OH7Ve7X+j4O5UN3AdGy3qU78GyGOWbWkj55pU/V1mO8n3c IvtuFIYd5P3jwpJdNuOHpHzr2j+v7IbyzV0yKd+jgV76d1K+efWcofR+0Y3CsFO8f1xYsstm/JCU b137P1pWoXw4wWnYaLv6+EgmaP33MiRkypzMn9+Kojj+/Z/9T8e//yd1PEX5YMJn+0f/hEtlbw7H //jnGOUTyhdRKz+/hfJHjTmsJfVWbT8+2vrjfljEWOKUoXJCDiy98OKjFaG2V75ZP93f6sPoF9yo Hegpjs+fDThC+VLj8sh1MaOcX/WXm5Dbf4ZVSmi3Xz+6J8AfbZdjKRJZ73KqOq2nv100vs7rBfrP uCjDbz2UL243sNX9z7RWWJ/OkkVRfHz0fgiPw+sC+Y/Drxazf15ZgPKd6mNRFL/Vl9t/RIZW+3Ww swyXhpWUr22XY9lWRZc5eZfTx9eX+reiKIbVlnvxtzsc/9qOU75ObD/0bf+TuYGyqQ8UH60mDZLa r1XbtyBiLHHKUDkhB5ZB/aoVobZXvlk/3d/qq9EvuCE70FMcnz8bcITypcYlNsLQr+prNarqTHJu l8uxPkXXDbLb4OlV2+VYikTWu5x+tRvo6W8Xja/zeoH+My7K8FsP5YvbDWx1/zOtFdans2RRFF+r arj/gePwukD+4/Crxez/aFmF8qHQRxz5VX9Jz/r/vVz/+5/2538GjvTHPyVf6lfP2j+6/6PjI6t8 0fGf3wRd/GdVfGvvy3r/1x/PfZfPXOX7+U3Qv39WNzlpY6JVPplMKChWXV/6E9V7ZZ6n779+HPsY Ub9D5ZWP6+NQz+hXXSm62+kD9axF7Pu/9mOgInP7edgjNC5zXBczy7kT7Jtl6rpN2U2M3a8fxy9f euolLXD58SWws0mNHO1iP8TF9EPgPwnjJP02m/JBv9Xc9Vf9MXTfo8+v+oum2XdzoePwukD+4/er JeyfVxagfEMMcidF7ff2FoDo4KKjTN+rPl6+fDsef+upl3yGfKl/C5ZU2spI7HS0e/l2PCpykxVu GIHe90qQz7ZSciJ90uLRKp9MJhQU63srmpXm8Tx9lxmy+h0qr3xc3y6Xb0erX8qE7ddOH6incoT2 a/FQ4m1q5MMeoXFBniKOXOrfctnpLHLuBPtmme9tm7KbGLtTffztWA1PTgYLxAnOJjVytIv9EBfT D4H/JIyT9Ntsygf9VnPXS/11JCEd6HOpf9M0+24udBxeF8h//H61hP0fLZuifGKVIFi9iUu8UCYp X///G2u6/YmOOymfWOLrngD8vFz/+5/6j6DaRMrX/nHnkPfy739Uf//Pw4mdMtTWD9plqOSgfP0q 1r3Uw9N9r3xcHzWt+tIRgw/NJe4hMtRTLGXkudxkPw975KZAjutiZjmh9RJ20/a//PhyfIjy5bab 8ENcLD8E/pM0TspvcykfbPemZF3dSOyvH8exIbP1Qcue6HjiukD+4/arJeyfVxajfFFcI5ba7rjF IDqUlq8ETaJ8ue2GNTPztKwAXCumQrxIn7T48cROGWrrB+0TKV+4uikIslc+ro+aVn3piEGlucTd hFBPsZRxx3OSzSzK56RAcp04W8lZ5Bhr2Mhu2v7ywcgkypfbbsIPcbH8EPhP0jgpv82lfLDdm5Jt dSOxp/o4NmS2PmjZEx1PXBfIf9x+tYT9Hy3bonx6Oh9Z5VPLdP/+x1FQPp20OVA++7ib8plc7mUo X/0hwrJf9RcZKs1B+bzyU/Whb8xC+Zb5tOMMlM9xXcwsx6Re9omB/UW1uSif2e5qlG/Mbx+mfL/q jx+XXz/q+lf98eMSVsvWx0/5Mpd/wXDk+NUS9s8ra1I+FDqpSV4t98xD+cx2X57yicXRyDxzUD6v /FR91PQ8lG+ZTzvOQPl03yev8k2QY1Iv+8TA/qLaXJTPbHc1yjfmtw9Tvkv9tb6c6vr7pf5aX8Jq 2fr4KV/m8i8Yjhy/WsL+j5YtUT6VUJRD+QZO1f6hV/lkUmVPq9BxJ+WLVgvv5fL3/1MUNC+xs2eh Qxc0Nb2/EzgWQqn3cO7RD6J8g2FF5YQcu6hlB5HQ5ZWfqm8Xm/Jp/xkiWqRnOhnsttYxx7rfw5TP dV3MLMegXtBuMo4HiX/1R1GECbS5lA+1C8c3UUw/B/6DPSTtt47ETtDu5ceP+sdH/eu2nDX2uhrU R38T9deP4/BqpXkcj6/tPxP8agn755X1KJ+e20GMcKqPhaB8Q9pc/Pg3l/KhdlXQqtpNFTOxUwZH OnR1Uz71Hk6XEAoo39CsqJygNByjAAAgAElEQVSQYxe17CASurzyU/XtYlO+YGD7iBbpmU4Gu611 zLHu9zDlU/16gPJNkWO9qYrsFjxpsRL/vldFESbQ5lI+1C4c30Qx/Rz4D/aQtN86EjtBu5dvdf2t qk95+eNQH/1N1FN9HF6tNI/j8bX9Z4JfLWH/R8sKlE9mAd1wj9jqyjiIyp1W3XH849uxkJTpH4Ms 8WUX8/jl7/8X6HNjbuh49FNP7WSi6bc663W+/5ifk1G5o7dOjVh1yHEaXhK727EVv1b1/9Q3G758 VF8KGS3FcrIaLYrqR/8alVd+qn6i0aoO+hXkpFmNKj1DVzS+CPIY5WtVitxdHzgu81wXz5MjBgXY LbCz8ZmcLz/a/iU9pOfD7ea8zmf7OfAfUIDf5vZLDAFqt/4w36/z6RMOvewXOG7bGfmP06+ebX9f eT7lC9/rt783UojYR3x8oKhqEST2OZnHb23/Ulz81fxb7Plwu2PhGP58i8odFe8lGvqMGHA4SbHd sOv31NRe/d+qSrwzaMrJarQoqm/9a1Re+an6iUar70G/gpw0q1GlZzgyxhdBHqN8OjW45+FgXEI3 6VtvK+NgvrvNJUcMCrBbYGfjMzm/1W3/kh7S8+F2c17ns/0c+A8owG9z+yWGALU7vO1rPqfK0ycc ev0IxmFn5D9Ov3q2/ecqK1C+eUre0lnW8ZcoqxuchcVTltoMg4XlgfJ8yvegiMzNEl61rN0+C4ur LLUZBgvLUwop34uU1Q3OwuIppHwsL1BI+dYOQFZXgYUlv5Dysbx02R3li3e0Sx9/lbK6wVlYMsuQ cbfMB3JYWKaWLVO+IQ9pv5scr90+C0tuGTLulvlADgvL/GV3lG+vZXWDs7CwsOysbJnyvUNZu30W FhaW9ymkfC9SVjc4CwsLy84KKd/aAcjqKrCwsLC8ScmmfJ8EQRAEsSPkT4EEQRAE8Q4g5SMIgiB2 hbUnVoIgCILYFkj5CIIgiF1h7YmVIAiCILaF1ShfUxZFcTid12r/aWjKoijKZm01JM6nQ1G8lLnP p8MrqUu8JF7vung9rHWfX3tiDdFWRVEc68vaesyOtiqKomrXVkPicv8i6uuY+1IfX0ld4iXxetfF 62H79/k1V/maEoYCTbkt0vT5+Xk+HWJ1bT2T2ptylkDC3FvE+VSOq/tsP3l1+XOgI0YSL+VJI3ix 6+L1sIqB155YDbQVDAXaaluk6Xq9XupjrK6tZ1J7U84SSJh7i7jU1bi6z/aTV5c/By79FioDXsqT RvBi18XrYeMGJuV7CBMo32p4sdCWlG87CMbixTxpBPvqzQZBynfDa1E+ExMo32rYeOQVgpRvOwjG 4sU8aQT76s0GsXEDz0z5mrJ7LlKW94leJDre1wu6KLcpD6dzf0YXFkSLCn28cPvlcDpHCVlDs3r9 AR03EOh2//N2lpkAhvX8bMqy6ZsWMX1CTlka9Ud0dS63xJEXkIPt3J9wODU3tZu7aMvOWA5WsXef RtAMU8+E/f32MfzW64fYz7WwrgEkH8vx+/9c6Mbi7kKDJw0NzzTu6ioKjNtbwhjfm9VuF1F/8ZVN n1jY9KdEyhiMZCZ7uvww6T+Gf2I9PfaHdsP6W7fGZPfs+zzWfxYsM322Vad/Vd0nepHoeF8v6KLc tjrWl/6MLiyIFhX6eOH2y7G+RAlZQ7N6/QEdNxDodv/zdpaZAIb1vLZV1fZNi5g+IaeqjPojuuZ0 SyCOvIAcbOf+hGPd3tRu76ItO2M5WMXefVpBM0w9E/b328fwW68fYj/XwroGkHwsx+//c6Ebi7sL DZ40NDzTuKurKDBubwljfG9Wu11E/cVXtX1iYdufEiljMJKZ7Onyw6T/GP6J9fTYH9oN62/dGpPd s+/zWP+FMSvlE8HT+XSQEekQvZxPh4HyFTpsHWrB1Y+zYhpNEzSrxKDjAOGyUvi39bAarfLJWDQ8 y6ZeuL6hadOIoC93nchoF8ux7VyoocuxsyUH9UpkvOp3+bCetv299kF+6/RD5Ofn02FQQjcwvkos 5KB2nX4+AWeTMDWlJmjxY4OscU/o3wttSsmA7PHtKnf/9pbTb9dGBoqui9ns6fdDe9yBf8503UG7 Qf21T46uVKP7/FP9donJUwRPl/ooI9IhernUx4HyBWHrUAuuflwU02jboFklBh0HCJeVwr+th9Vo lU/GouFZNvXC9Q1N21YEfbnrREa7WI5t50INXY6dLTkAMuNVv8uH9bTt77UP8lunHyI/v9THQQnd wPgqsZCD2nX6+QRcTMLUVpqgxY8NssY9oX8vtK0kA7LHt6vc/dtbTr9dGxkoui5ms6ffD+1xB/45 03UH7Qb11z45ulKN7vPP99sszLvKJ1cuQFCgKZ+a5UW1RKgdpfuJR8WqaXQc4tZox9eCWNtH+WDI bsqRdeL6MfQC0QOUD8sx7azJlrHEF0vKSs80awZxrq0noHxe+wC/9fkhGveUCSZQvmz/nxHBKp+t u1Itf9xH9G/K4nAI3n61x7fTpxmWafsbQWpQw+tiPnt6/RCOu+mfM1132G7J625IyhhtCNj/uX67 yOwpVy5AUKApn5rlRbVEqB2l+4lHxappdBzi1mjH14JY20f5YMhuypF14vox9ALRA5QPyzHtrMmW scQXS8pKzzRrBnGurSegfF77AL/1+SEa95QJJlC+bP+fEcEqX6xlpFr+uI/o31bF8Ri8/WqPb6dP OyzT9jeC1KCG18V89vT6IRx30z9nuu6w3ZLX3ZCUMdoQsP8CfpuFp73LJ9dsIOULY62JlM9eF3O/ QnI+lafz+XS65RRGKmyF8iUeuI+cF4W2WM4o5RtOSNp5BsqX0tOy/1T79CfkrfJtiPI9/VWp0d5G lVyUYyzxUHM+NL4JygfvM/bP89jT74fp+0Z/vL8uZrnuoN1G7g9dJdciumzwuX679EQq12wg5Qtj rYmUz14Xc79Ccqmr+nKp61tOYaTCVihf4oH7yHlRaIvljFK+4YSknWegfCk9LftPtU9/Qt4q34Yo 39OT4kZ7G1VyUY6xxEPN+dD4JigfvM/YP89jT78fpu8b/fH+upjluoN2G7k/dJVci+iywa284jcn 5VNzuKZ8+pWbYZVPZ4bJjC71npIMPeJQBuUEuXOFzqfT6VTeVvjit0tsymfp+WzKp1/mmU75EnJs O9snpOzsCD2jdQ0jtA31tOzvtg/0W6cfIj/XIlWaJ/IfUw5qN+nnzf01LfR7FuxR1A6l6zjGHesv kkXVf5Eb4lW+VLKukdiZ8udDrjn91ym8T9r+OdN1hylfUv+mVO/bJhuw7/NPyUHusMDcqeZwTfn0 Kzfttf9DZYbJjC71npIMPeJQBuUEuXOFLnVd19VthS9+u8SmfJaez6Z8+mWe6ZQvIce2s31Cys6O 0DNa1zBC21BPy/5u+0C/dfoh8nMtUqV5Iv8x5aB2k37eVjOsn9ijqB1K13GMO9ZfJIuq/yI3xKt8 qWRdI7Ez5c/HXHP6r1N4n7T9c6brDlO+pP5tpd63TTZg3+fXy+VUmJfyyVXLIDvrhuGzH/cXPE7W 9x8+zbeHwu9dqDQm+dMgCR1P9CDmGfFH6s2WVbR2r9T/qv7QcmQdVR9CflWhLEdDUKg/kJOws/ha R1mCxLPeEgk5GZqWp552p/prvWXmtE/Cb71+aPh53ES4WhLpD+RM8P9e1COhtRIesiVDH/+4m/pb 15H6ZIgaX1G7e3WsZ2dNKe8z+DtR+oVL057n0yHfmF4/RP6D/fPx6y5ltxH91bOLdAPoPu+9Pzuw wNypM3WC7Kwbhs9+3F/wqK3vP1zNt4fC712oNCb50yAJHU/0IOYZ8UfqzZZVtHav1P+q/tByZB1V H0J+VaGqRkNQqD+Qk7Cz+FpHVYHEs94SCTkZmlZ1T7tT/bXeMnPaJ+G3Xj80/DxuIlwtifQHcib4 fy/qkdBaCQ/ZkqGPf9xN/a3rSH0yRI2vqN29Otazs7aS9xn8nSj9wqVpz0t9zDem1w+R/2D/fPy6 S9ltRH/17CLdALrPe+/PT8GamzQQLwx3xiRBrIP5MgiDj/u8NzwLuctjjcmU2C/cGZMEsQ7myyAM Pu7z3vAs5G4ZpHzEFJzX2lCeIJyYj/I9NRXxxbDxLSXXnliJXeGy1obyBOHEfJRvI6mIm8CLbCk5 DlI+Ih8iEWvT8R5B3GHuHEhMh0rG3K5N155YiR1AJGLtJN4jdg5z50BiOlQy5h5sSspHEARB7Apr T6wEQRAEsS2Q8hEEQRC7wtoTK0EQBEFsC6R8BEEQxK6w9sRKEARBENsCKR9BEASxK6w9sRIEQRDE tkDKR7wl5vuM42uDdiD2iLUnVoLYEub7jONrg3Yg3hvbo3xNueHvQZ77/cGJ7UJswg2+KrilXQXF TtuL6/Qedhj3B6v+e1/omabaLNaeWLPRVhv+HuSl3x+c2C7EJtzgq4Jb2lVQ7LS9uE7vYYdxf7Dq v/eFnmmqHWBlymdv7jTrlk9z7yCXtQPxxjet6vEqejrRlLdw9Xw6mPzBYjouP5nPbquSrnexw5g/ gJNMO6xknxXkT1gA3k5/155YbdibO8265dPcO8hl7UD8KptWvYqeTrTVLVy91EeTP1hMx+Un89lt VdL1LnYY8wdwkmmHleyzgvwJC8Cv2N/9U765Qcq3fTTlLbI/nw7WSsXjyYzz2W3NxMq3scOIPzxP o+1QoEnCSflmxgKUb26Q8m0fbXWL7C/10VqpeDyZcT67rZlY+TZ2GPGH52n0ihRICCfl80Ls0jsE CyJR8/67+sPa1rcpy6ZP81JzvLmx8k3S4XQOE7JQgpZIIdMtiB/UOcPxshmjfIl++TeGlnufl10E BvuL9DfHJaUnssO4lrlZc2Vpja/RrvKZ/s+RZvqVmKaMF3Xi9STTT5Cefruh8Qol9Vphe5r+kBgv 4bhlGMC/kR2S/oAQMx6c8GnYOXkfgE3Gtf32B3ZWl07OddSUh9O5V6mrOuF+biJ1H7Duk075c0+U FsQuvUOwIBI177+rPwbIU6q2T/NSc7y5sfJN0rG+hAlZKEFLpJDpFsQP6pzheNWOUb5Ev/wbQ8u9 z6suAoP9Rfqb45LSE9lhXMvcrLmqssbXaFf5TP/nSDP9SkxbxYs68XqS6SdIT7/d0HiFknqtsD1N f0iMl3DcKgzg38gOSX9AiBkPTvg07Jy8D8Am49p++wM7q0sn5zpqq2N96VXqqk64n5tI3Qes++QU e2ZhXsrXNILoSSY1/F8HmmiVT0YYMqBTTDJmNXdhTaPDh5jyifhFitRR612azOTKfZfP7FdKfwvn 00GHv1H4rPsL9MfjAvUEcqCiUD7umDm+wP6aY2ctsyYbtzW0Q3xDz88JdoP+aS2lAHsif4Dtih/i 9a03ssM0oEWu1P0ktLNr1Qtfvz77d6dEds659yp9Cv04qavvvZ8jwPsAvE9ua5Xv0raC6EkmNfxf B5polU9GGDKgU0wyZjV3YW0rhcah23AkEKmj1rs0mcmV+y6f2a+U/hYu9VGHv1H4rPsL9MfjAvUE cqCiUD6oL/qixhfYX3PsrGXWZOO2hnaIb+h5nWA36J/WUgqwJ/IH2K74IV7feiM7TANa5ErdT0I7 u1al8PXrs393SmTnnHuv0kcSK6GQ936OAO8D8D75Sqt8RfEQ5bPqh3VV6J/gATA/KWBdwdpf14NQ cla6k9WvpP4Gkr8bPwL9P/G4ID2RHKwMkg/ry3C2H1/Q7k1J8T7WI7E8Hj6T6hh6DiqF5yfsBgfT pDqmPZGIRLtSUKDwW9lhEvIpH7azhwIlr1+H/e/VTCMNumc8OAlZc9/YjJTPvA/g++TGKJ96EPsI 5bPqh3VV6J/gATA/KWBdwdpf14NQcla6k9WvpP4Gkr8bPwL9r3hckJ5IDlYGyYf1ZTjbjy9o96ak eB/rkbAPD59JdQw9B5XC8xN2g4NpUh3TnkhEol0pKFD4rewwCfmUD9vZQ1GS16/D/vdqppEG3TMe nISsuW9sRspn3gfwfXLjlE9FCCoS2CLli1fZ4OcaXobyoRAVjQvS0/cKT0q+DRTqgXbPp/J0Pp9O t5zah14XSqn3ONVJ2M1BdZA9MdXJTL7Vi8Rvaod8OCifgLazj/IhufNRvv70HMVChUj5FFSEoCKB LVK+eJUNfq7hZSgfClHRuCA9fSlTKfk2UKgH2r3UVX251PUtp/ahqC+l3uNUJ2E3B9VB9sRUJzP5 Vi8Sv6kd8uGgfALazj7Kh+TOR/n603MUCxUi5RuDjBC67yWEv4Q7MOh0niIdUugQRAc1PsqnczXL QTkroFBBTeYHIMx+pfS3EEXpKgSOzwb643GBerrWR1LybYAQFrZ7Pp1Op/J0zs6rzWk4go/qOO3m ojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/Xfa/VUN3l6Ycfx95kKiGIL4R593PEeB9AN4n8+XP PVHGkBFC972E8JdwBwadzlOkQwodguigxkf5dK5mNShnBRQqqMn8AITZr5T+FqIoXYXA8dlAfzwu UE/X+khKvg0QwsJ2L3Vd11V9yc6rzWk4go/qOO3mojrAnsgfULtKtDr5vewwEdmUD9sZ3N9gg9D/ Xfa/VUN3l7Yafx95kKiGIL4R593PEeB9AN4nffLzMGdip/zaQlmKd0mGnKXDqZEvmchzVBRRDF/Y 6/+QcsSxIP0r8X0D8XKeOqxCYeu4yts6ZdGOuF9Q/xTkCWP9hfrjcUF6AjuM9jWWn6hdNtH4onaH JdmHlnLsk4GfpPR02Q2OV4bjhva0/AHaTWcK2oH5O9jBCXTfgPcTaGdon7ymb2e47Z+4P/S/5yzx FUVxOJ3M70157uejfTX6he+T2fJnmBvHIL+2UFXiXZIhZ+lYt/IlE3mOiiKK4Qt7/R9SjjgWpH8l vm8gXs5Th1UobB1XeVt1Fu2I+wX1T0GeMNZfqD8eF6QnsMNoX2P5idpVG40vandYkn1oKcc+GfhJ Sk+X3eB4ZThuaE/LH6DddKagHZi/gx2cQPcNeD+Bdob2yWv6dobb/on7Q/97zhJfURTHuja/N+W5 n4/21egXvk/67JmF7W3FThBPwYMvAe4GtMN748HPH70I5pkeCeJV8eBLgLsB7fDeePDzR7sDKR9B EMS7YKdbcYZYe2IlCIIgVsZOt+KcDlI+giCIvUPle877oZstYu2JlSAIglgJKt9z3g/dvDZI+QiC IIhdYe2JlSAIgiC2BVI+giAIYldYe2IlCIIgiG2BlI8gCILYFdaeWAmCIAhiWyDlIwiCIHaFtSdW giAIgtgWSPkIgiCIXWHtiZUgCIIgtoXZKN99697tfAiuKYu87c7XwDlrP3fiUeTZufuYIQeEIPaB Z0+c9617t/MhuLYytiHeCi5Z+7kTjyLPzt3HDDkgBPFumHOVrylXi5ntzaZm3YLqfDrM2r2sHZFf ZROtDeuZvfO0x31n7K/pVxu2ZxbW0n9Cu3Nf18QmsMDc2Varxcz2ZlOzbkF1qY+zdi9rR+RX2URr w3pm7zztcd8Z+2v61YbtmYW19J/Q7tzXNfFiIOVbC6R8y2DrlG8V+c/GC1E+YpdYYO7cN+WbG6R8 y2DrlG8V+c/GC1E+4s0xO+VrSmO33/5gXvKc2DV4qC4SNe+/qz+sbYabsmz6plUsOCgk9LlJOpzO YaIfSvwT3dItoP4Ox8tmjIok+gX0zxNWlh21gf1F+pvjktLTOe7ecckQo+2c1MegfFb9Gftr9idz 3IdhTJjgcGp6aZFBwfDm+sOtUlmG11dS/zFLhB0z/GFCu6C/KfvH8pEdpvgn8XQsMHe21bG+tNXd IWT83B/MS54TuwYP1UWi5v139UdhtNBWVds3rWLBQSGhz03Ssb6EiX4o8U90S7eA+jscr9oxKpLo F9A/T1hVddQG9hfpb45LSk/nuHvHJUOMtnNSH4PyWfVn7K/Zn8xxH4YxYYJj3fbSIoOC4c31h1ul qgqvr6T+Y5YIO2b4w4R2QX9T9o/lIztM8U9iQ5iX8hU6TLxHSyqWHg5jnJtGxHySSQ3/P58OQg5a 5Rv0EUo0pWaScdjbKd5omhhTvkG6Emn2V2aQ5b7LZ/Yrpb+F8+kwGPF8OsThqu4vHC80LlBP37hP HJcQ0M4j+kTjm6g/S39Ru0i+rBkMIxBcCMYiFMLj6PQHoYTuhWu1Dfkn9Advu4n+RhIS8lPj6/BP YgksMHfq1/naqouWVCw9HMa4tK2I+SSTGv5/qY9CDlrlG/QRSrSVZpJx2Nsp3kqhMSUYjgQizf7K DLLcd/nMfqX0t3Cpj4MRL/UxDld1f+F4oXGBevrGfeK4hIB2HtEnGt9E/Vn6i9pF8mXNYBiBYMlY hEJ4HJ3+IJTQvXCttiH/hP7gbTfR30hCQn5qfB3+SWwLM1O+YCmtbD6jtbBi/KMq+oH9I5TPqh/W VcttibU3mPgXsBPQ31ByVh6h1a+k/gaSvxs/4vFC44L09I371HEZ6VFv5zF9wgFJ1Z+jv6hdJP9T D8C4cHA9psbR7Q+Sqo1ejzbQ0GJ/8Lab6O8noHyG/OT45vsnsQgWmDvDcOoefwVrYcX4R1X0A/tH KJ9VP6yrltsSa28w8S9gJ6C/oeSsPEKrX0n9DSR/N37E44XGBenpG/ep4zLSo97OY/qEA5KqP0d/ UbtI/lUPwLhwcD2mxtHtD5KqjV6PNtDQYn/wtpvo7xVQPkN+cnzz/ZPYGJ75Ll9P+XyJTipSVRHd FilfvMoG+vtClM9WDI8L0tM77s+mfGl9YvfF9efob+q8ccqU8dUReD3icfT4w6tQvmR/P/9/e+dy 7SgMg+H0knNSCxtKYZlO2NNJKkgt08KdBS/JloRFDHbI/21mLhhbluVYwgI8IZ+hcIR8lXHC2hn7 zFPI50t0Yp4q8+hqDPniXTalv18U8smC6eOiyekd96NDPlue2Hz18jn6a123HTIlvHVEnY/6OHrs 4VtCPrO/f56Qz1A4Qr6vJXdiJ8vEWm+Pe16qQF2rvuF7KySRkt1k52mbNyG4I24c9924s+YL+XgO YbMKp+w1MHHSEjuFflnyS/DogKXRiVcr8uvjosrp+0jGznEJUfW8IY+Q2KmWz9JfrV29fj6MKYmd LBUxriYcR4892KGXNB8VNPtU7cHXrtnfqBmjfmt8EfJVxglrJ82jpJ5Weo7bVJw/y0NDPpJIyW6y 87TNmxDcETeO+27cWfOFfDyHsF2FU/YamDhpiZ1Cvyz5JXh0wNLoxKsV+fVxUeX0fSRj57iEqHre kEdI7FTLZ+mv1q5ePx/GlMROlooYVxOOo8ce7NBLmo8Kmn2q9uBr1+xv1IxRvzW+CPm+ltzf5evE 94rwzKqUZ8/mok1DnpFZc6vm91KwR4B47XPZpidnpRwtOW3ReC8EeTiPHdZeaSK++aPpXJ+MU1+H k5Y+SC/Y6q8qvz4umpy+cXeOi46qZ1EedXwt+TP012hXrp9nFqYkdtL5KJohHUenPdA5Fc4vTT+G qGK7kj34203sb3hYqD/JfvaE/SA3Ry+c04N8T/G9IjyzKuXZs7lo25JnZNbcqvm9FOwRIF77XLYd yFkpR0tOWzTeC0EezmOHtVeaiG/+aJ+uT8apr8NJSx+kF2z1V5VfHxdNTt+4O8dFR9WzKI86vpb8 GfprtCvXzzMLUxI76XwUzZCOo9Me6JwK55emH0NUsV3JHvztJvY3PCzUn2Q/e8J+UI6cu3wAgHoo +NEUAMpSemEFAJxKwY+mAPAtIOQD4Jog5AM/S+mFFQBwKgj5ANgEIR8AF8T75UYArkTphRUAcB7e LzcC8Jsg5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHApSi+sAAAAQF0g5AMAAHAp Si+sAAAAQF1UE/Lh9YLgE2A/AICZ0gvrFni9IPgE2A8AwM9RIR/zwF/zZ9On77XHrvmru1fzBWPy /eeTZFL1UzSO+VAPfZNNgbAfm239AIn5I+rHa+zV3TEwp3LyOso88Pf82fTpe+2xa/5+Pqr5gjH5 /vNJMqn6KRrHfKiHoc2mQNiPzbZ+gMT8EfXjNfZ+PjAwlXJMyPfq7sy/6ZvR4Xl1d9EPljz2sA6T vsnlXRcJHlT9HCrN7PGKAYqvZVn/2UYF9mOzpZ8DG3a35hqXMzjpvsqra07tdiH7r2V8T11F388H 82+GdnR43s+H6AdLHntYh8nQ5vKuiwQPqn4OlWb2eMUAxdeyrP9sowL7sdnSz4ENu1tzjcsZnHRf 5f1sT+12Ifuvb3y3OCTki9zevhk90Vd3l+51f+505XNZimys6fo5wYGSe+zTwwkhH+zHatTUz5EN V7O5upuLhnwurjCOnDMX0cjtHdrRE30/H9K97s+drnwuS5GNNV0/JzhQco99ejgh5IP9WI2a+jmy 4Wo2V3dz0ZDPxRXGcS9HhHxxmLIc6Zt4EyLeFxETrqbstaYJ9qTCvSqeGCkdHa+4d6+gHXXXi5yI O7aUblbXUW6XnaDFLf0cH/NFLq+5+xdh6L9vmr4Px2s8oehHbwP2w0+k2o+qULEi4QPuO/Sm9dc1 Ln79p/Q25YaBXr8yLmr9ZLj6JeSbSo8l2R8qYrvTwXv3Wv4/6U7Xi2A/lv1r9qbgHt8DOXENjcOU 5cjQxpsQ8b6ImHA1Za+1c9rcfE24V8UTI6Wj4xWP5ztoR931Iifiji2l29V1lNtlJ2hxSz/Hx3yR y2vu/kUY+h/adhjC8RpPKPrR24D98BOp9qMqVKxI+ID7Dr1p/XWNi1//Kb1NuWGg16+Mi1o/Ga5h Cfmm0mNJ9oeK2O508PF8L/+fdKfrRbAfy/41e1Nwj28VHBDyvbq7Z11XM+Hiu+90E4OfFe9SsyKB M7w8/vTv379/fd/LF82F+574WcyTZ39MV6rtkhPp+zGpXvxujtzlu0njZY2LH9iPF71dHlCIjSXo Tetv3ItYhlQ7UfUvdv0nJCIAACAASURBVNgpj1K/Ko9cP71Zw5/l4ya7ucOm62EZpHmb1+6Xbj/a /N1jb555dxznLaHv58OzrquZcPHdd7qJwc+Kd6lZkcAZXh5/+vv7+xuGQb5oLjwMxM9injz7Y7pS bZecSN+PSfXid3PkLt9NGi9rXPzAfrzo7fKAQmwsQW9af+NexDKk2omqf7HDTnmU+lV55PrpzRr+ LB832c0dNl0PyyDN27x2v3T70ebvHnvzzLsaOCbkc6zqugsgug7UVd1wm8it8QlSRk2zEl12diN8 denkKox2aUWpgQ5zxI/gnMTOdbzMcXED+/Git8urXMv59Kb1d70mbVz26V/CK49cvy6PWH9YQxC4 3RfdbnXEni99c7vfxR9coV+q/Shh5y5788y74zhvCfXtS+kugOg6UFd1w20it8YnSBk1zUp02dmN 8NWlk6sw2qUVpQY6zBE/gnMSO9fxMsfFDezHi94ur3It59Ob1t/1mrRx2ad/Ca88cv26PGL9YQ1B 4PZYdLvVEXu+DO3t8RB/cIV+qfajhJ277M0z72qg8C6f5QB87rIbQYvDZWf31UmzuuucEiwlB8Zf vcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNvb D4Z8yf6B5QB87rIbQYvDZWf31UmzuuucEiwlB8Zfvcsnh3z5QljYj5+jQz6tv+v51JBvj/5j/PLI 9WvyKPWbId9SLuEhOlMP4ztaxZjPtiNuP9tipNsbQj6Pd2Cu/z6XnT1v00yJWHqw5HLZ+fMzVITg CSO73fDDFUlK0sqN9/5zeE95Qj5B/0rIlzGIhf3sQW+XByVLD316U/srdcOqf5f+Y/zyKPUr8mj1 M03FiZF9Q57v2+iAogeSACDkAkT9MuxHsf9d9vZrIZ/DOzDXf5/Lzp63Gc9YwZLLZefPz1ARgieM 7HbDD1ckKUkrN977z+E95Qn5BP0rIV/GIBb2swe9XR6ULD306U3tr9QNq/5d+o/xy6PUr8ij1c80 FSdGDi15vm+jA4oeSAKAkAsQ9cuwH8X+d9kbQr5/6cu6HFZE7xMYPZDlcNOz/4cXBffSSTXTmZS3 bLAT9O0MTXOnl9CkK5Z2JrQbZGilOT6qp5Uh5Evob7Kksf7n3jb9v2i8ZP24gf3sRWmXtRCOVbLe lP7uGBef/jV88lj1y+Oiji/Li+zCT/M5siGkdqX5de9eer9M+5HG0Wlvu+bdYZy5iKYu63JYEb1P YPRAlsPtwP4fXhTcSyfVTGdS3rLBTtC3M7Ttg15Ck65Y2pnQbpChleb4qJ5WhpAvob/Jksb6n3vb Dn/ReMn6cQP72YvSLmshHKtkvSn93TEuPv1r+OSx6pfHRR1flhf5DD/N58iGkNqV5tfj+db7ZdqP NI5Oe9s17yrgnO/yaYVOud/7zUBHOtAN+Gaq/mrD13PqKpp0S7i++731AR3pQDfgm6n6qw0/xDEh 33kvZrs20CIA1+R6n8KripPX0fpezPaNQIsAXJNf/hReVRwV8gEAAAhh+Y+4o3MUpRdWAAD4eVj+ I+7olAchHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtRemEFAAAA6gIhHwAAgEtR emEFAAAA6gIhHwAAgEtRemEFAAAA6uL4kK9vbmd8erdOXuH3l0EpezitXfIFa9acdhx8O+xL6AnH Jfom3ws8x3abPmulh7V7zLwotqIObWWf3j2Td/j9ZVDKHk5rl3zBmjWnHQffDvsSesJxiaHN9wLP sd12yFrpYe2WnheZQz75Y1P5PkFV6mNWH7Sb9MXlXP2q7WNfR9tDbe3qH4jP8+F4owev7n69ewsV 9ldtV/uIZvLHNfN9hbNvxojr1d1Pvb+wo9088yLmnOVT/thUvk9QlfqY1QftJn1xOVe/avvY19H2 UFu7+gfi83w43ujB+/m43r2FCvurtqt9RDP545r5vsI5tGPE9X4+To2jdrSbZ158AkK+o9tFyJd4 9ArtZnD8N2qva3yP5pv6W1nI1/TjttuZcfGOdvN1mnPO8omQLwIhX+LRK7SbwfHfqL2u8T2ab+pv ZSFfO4zbbmfGxTvazdfpveQL+dgnhnk6U980/ZK+Q304ktOzufAb9ZNTtJrx8L17RQlWywX3rp+T kTR5jHZV1nqanoR8opz+fvEGmslnMuVcy5Ojun4846KRyx6mbLFGKn9kuxZy+bDluQXtuNEuuWQe 4AQ7YXXQjoaddo9vbD9T7l6/SCWbW5K97Z0XseyCnTvtZ6o7GDs+xY7c5Vt6sK1PsxNjub4JeqLo wak3TR6pXVNKNsDkCufvlcDhKyf7xPDtRhN7hrYdlvQd6sORnJ7Nhd+on5yi1YyHH893lGC1XPB4 DnMykiaP0a7KWk87kJBPlNPfL95AO/lMppxreXJU149nXDRy2cOULdZK5Y9s10IuH7Y8t6AdN9ol l8wDnGAnrA7a0bDT7vGN7WfK3RsWqWRzS7K3vfMill2wc6f9THUHY8en2JG7fEsPtvVpdmIsN7RB TxQ9OPWmySO1a0rJBphc4fy9+oiTdvmoq0gCC7JmJzkJSv2vvl+9el7Ni0V0fR+UYQ94GfJ4dhto 5hd/lk+X09cvImhwP12sp29Y2COExaF+3OOikcceaCfTHOhD7dAs73D8tXpe3V3uu22HcQs0ae6j /sr2w5+OXCuy6pfszT0vlP6qdu6zn3BbPvzbG9o5Qr4bv+2SoE8Xih68esv4+6DMC9/vlUiGtTEB bXeFuooksCBrdpKToNT/HobVq+fVvFlENwxBGfaAlyGPZ7eBZn7xZ/l0OX39IoIG99PFeoaWhT1C WBzqxz0uGnnsgXYyzYE+1A7N8g7HX6vn/XzIfbftMG6BJs191F/ZfvjTkWtFVv2SvbnnhdANS06n /YTb8uHf3tDOEfLRMCZNny4UPXj1lvH3QZkXvt+rDzk9sXN1Q8mt4olt30EJjdjt4iDki9IqeR3U s9LlcYR8hoeoy+nsFz0RBBxxPeExJqCoH/+4aOSxBxq6pD37c6Qd2uXTHX+tHisT2BfykfLkQn9/ FfuJo92m36pf7Jx3Xsj91e3caT9jReS5NH7BkSGfW58uZD149Zbz90GeF77fK5kMa2MC2wl1qxtK bhVPbPsOSmjEbhcHIV+UVsnroJ6VLo8j5DM8RF1OZ7/oiSDgiOsJjzEBRf34x0Ujjz3Q0CXt2Z8j 7dAun+74a/VYmcC+kI+UJxf6+6vYTxzttsNW/WLnvPNiPvcIJppm5077GSsiz6XxC44M+dz6dCHr wau3nL8P8rzw/V59StGQz580KIc0N6n6+e+NkC9NnhwhnyWnu19U/o1dPn/Il+/pmjz2cHTI5+uv Xd4T8sklc4Z800GmNH9/1ZBPjLnM+uVbDK55sZ47KOR7dU33enXdmJMdiXBgyOfXp4tcIV++34ff Cvn8iTlySHOTqp//3gj50uTJEfJZcrr7RZp7sHvuOUK+fE/X5LGHo0M+X3/t8p6QTy6ZM+SbDjKl +furhnxizGXWL99icM2L9dxBId/72T7f7+dzzMmORDgw5PPr00WukC/f78MlQz72PJjgVBA3YkdO kFQ/dRpIo3NzsYugXWDII/dLhjmVJDfKktPVL+YlhSGfICf3qrhGZP3oHWSJVdvksYc9Id+BdmiW dyV2yvXwIWVpnpYdyi2/uvvyuGeK/JuirxZD82T/sR1Fy37MWwwp80IWy5DTbT+vruu6pnsFedla uzuPCwX5g6e3BH26UPTg1Vs2eeLGbXmivwzyLpMaPF3oJjgVxI3YkRMk1U+dBtLo3FzsImgXGPLI /ZJhTiXJjbLkdPWLeUlhyCfIyb0qrhFZP3oHWWLVNnnsYU/Id6AdmuVdiZ1yPXxIWZqnZYdyy+/n Y3ncM0X+TdFXi6F5sn9sR9GyH/MWQ8q8kMUy5HTbz/v5fD7b5zvIy9ba3XlcKMgfPL0l6NOFogev 3rLJEzduyxP9lYXc3+Vbc7TYEz+39U1uyx+sNL3CVz9/+0PTLCFJ2tsBmiYI0GR5pHYThLzdmm5x GxU5vf0KMqvCW+Ibr9NIeauIrgf3W98/twdaJix/ZLtptdPy/te3qO3SAQtuYUTjG73nJNCO4KF7 +yvaz7++uXddwotsphOqGpzzwuivJOce+1kfIFPTstdavMcNFVN9yr8+4Zl0LD149ZZDHmteeH+v BPIukyprjhZ74ue2vslt+YOVplf46udvf2jbJSRJeztA2wYBmiyP1G6CkLdb+1zcRkVOb7+CzKrw lvjG6zRS3iqi68H91vfP7YGWCcsf2W5a7bS8//Utart0wIJbGNH4Ru85CbQjeOje/or28ze0j+cz 4UU20wlVDc55YfRXknOP/awPkKlp2Wst3uOGiqk+5V+f8Ew6lh68esshjzUvvL9XH3H8p9grJ23X CPz794/tWYKf56j36wPwMXmWx+uRtmsE/v7+2J4l+HnKv18fgI/59ZDvdcUPWB9G1pQu8OUg5APV UnphrZT3FT9gfRhZU7rAl4OQD1yA3wz5SI4QQhgA/IhfTgOgEkovrFVBcoQQwgDgR/xyGgBfx2+G fAAAAC5L6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAAqAuEfAAAAC5F6YUVAAAA qIvLhXx4jSA4AtjVCPQAvoHSC+tZ4DWC4AhgVyPQA7gWx4d8fZPtvZjjizabfv5ucex61vSVPfI9 4ZNk2tZP1pYOaqBGvf22Xa38hh6882h+ATCC4XootqIObbb3Yo4v2myH+bvFsetZ01f2yPeET5Jp Wz9ZWzqogRr19tt2tfIbevDOo/kFwAiGv5HMIV/fSN6XfHRX9aNf9eruop8neaSuL+9lk7SMc7yl n5y8uuYjD1cZlyr19ut2ZTV+RT3smkfK/mch/ZSp/181Xzo9Z/kcWsn7ko/uqn70q97Ph+jnSR6p 68t72SQt4xxv6Scn72f7kYerjEuVevt1u7Iav6Ieds0jZf+zkH7K1P/3hV86/b6Qr+nH2+qCX/F5 0lk+l6hIAtyGfrLyacinUKPeft6usrX9JXrYNY9ySHSBkK8Szlk+Twj52mG8rS74FZ8nneVziYok wG3oJyufhnwKNert5+0qW9tfoodd8yiHRBcI+b6OfCEf+bx5+Inmvmn6JQ2L+hwkNyvJXVruIPdN fPM9vu8vJlxNWVtNKI8hvyLneMW9ewXthDUtUpETQXfpt+Gb1XVU9bOeoMVt/cTqEvUQ1M/aJc32 NORzjqOSCKfqbaseVpXZL70i2BU/wezq1/TgmUdEd6Ht6wmfgp4t/ehNxqX9+lf0PP0l/KHh6u/B HL5yks+bj6wO0NC2w5KGRX0OkpuV5C4td5CHNr75Ht/3FxOupqytNpTHkF+Rc7zi8XwH7YQ1LVKR E0F36bfh29V1VPWznqDFbf3E6hL1ENTP2iXNDjTkc46jkgin6m2rHlaV2S+9ItgVP8Hs6tf04JlH RHeh7esJn4KeLf3oTcal/fpX9Dz9Jfyh4epvNZy0y7e6AT11uLjX99kNaDXTS3bFBHk0+S05l8d+ /v3796/ve/miuXDfkyCJearsj+lKtV1y4qP9PEUPfcPCdeJpcy9RVGH6OMq7Ip69EkWfxvjuAHa1 HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5unvcZyzfGq7fKsbMFCHi3t9n92AVjO9ZFdMkOdP kd+Sc3ns5+/v728YBvmiufAwkCCJearsj+lKtV1y4qP9PEUPQ8vCdeJpcy9RVGH6OMq7Ip69EkWf xvjuAHa1HPkVPexDs7T4uK5n1y6cKr9T//MlkZ75kKfK5ulvDZye2Lm6EeQW9cQnPpfu2osuKXWP NtwaU041vVF0SdmN9vX2u1yF0S6t6AOlyXoIdTDJF4q5dHDvOGYI+UR9WuPrB3alt6ud+Xo97CI9 5NP17An5dPl9+p+KiUpaZU/P4/b09zjOWT63EztXN4Lcop74xOfSXXvRJaXu0YZbY8qppjeKLim7 0b7efperMNqlFX2gNFkPoQ4m+UIxlw7uHccMIZ+oT2t8/cCu9Ha1M1+vh12kh3y6nj0hny6/T/9T MVFJq+zpedye/tZA0ZAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+ckuX5aQb58An4Z8mj5zhnywq6ja hPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+nsc5yyfvpAv3+1ey7H/3CU15HS4pOFG1LZLmpgk+cku X5aQb58An4Z8mj5zhnywq6jahPqupId0HCEfgevZF/Jp9eYL+ZbLHYJ5+lsD2UM+9pyMEEQQF+Tz XCqhUlMmoXjoEgnyW3K6XFKWLsn2VoInmOx2WdX5Q75A9KWHYVRFcsd2jePnIZ+iz3whH+xK6sym RF+uh50kh3zG/JV/P9UGlQJO/Y/FtE28vuHP7W7i6e9xnLN88vTAmxBEEBfk81wqoVJTJqF46BIJ 8ltyulxSli7J9laCJ5jsdlnV+UO+QPSlh2FURXLHdo3j5yGfos98IR/sSurMpkRfroedJId8xvyV fz/VBpUCTv2PxbRNvKHlz+1u4ulvDeT+Lt+awkMCgtvttr4Bb/mDlaZXuJGdreh9BWOrVIZQHkl+ Vc6Ut0iwE/TtEk1zp5fQJC2W1ibph2d07fVaLT2wFnictxztyON8rnFUxsVQ6HZFRJ/2+LqAXf2k Hpxo9qzauTV/Zf2kNT1e4db/1rRjj0Lu0EOm3ysnJ62fawoPCQhut9v6BrzlD1aaXuFGdrai9xWM rVIZQnkk+VU5U94iwU7Qt0u07YNeQpO0WFqbpB+e0bXXa7X0wFrgcd5y9Eke53ONozIuhkK3KyL6 tMfXBezqJ/XgRLNn1c6t+SvrJ63p8Qq3/remHXsUcoceMv1eHcbxn2I/nE+f1gJAAnY1Aj38Ngd9 jeVgSi+sx/Hp01oASMCuRqCH3+agr7FUwwVCPgAAAIfwpZ/yK72wAgAA+DIu/yk/hHwAAAA4LE/z lMfvslJ6YQUAAPAlsDzNyh6/ywpCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei 9MIKAAAA1AVCPgAAAJei9MIKAAAA1AVCPgAAAJei9MIKAAAA1MXJId+LfL/7G+sHAABQO6UX1pE3 +X73N9YPAADgOpy/yxd+2ffV3eMY7YOPQX3nl4MBAABkovTCuhB+2ff9fMQx2gcfg7r6l4MBAABk onzIJ4KQDwAAwD5KL6wLSSEZQj4AAABHkzfk6xv5473r8aYnIdn8tV9Wln0CODjrrB8AAMDvccrq ObTyx3vX4+1AQrL5a7+sLPsEcHDWWT8AAACgkzPk6xsenU0bdTRzU3rWjl22HBN2+XbWDwAA4Jc4 Ye0cWh6dTRt1NHNTetaOXbYcE3b5dtYPAAAASGQM+cgW3LLl9i9OtIwivNSQb2/9AAAAfonjl06y Bbdsuf3FiZZRhJca8u2tHwAAAJDIGvKJsVbGkG9f/QAAAH6J45dOJdbKGPLtqx8AAACQyJvYeZNe uvLq7uvhV3dPS+xcjvXNtJ23r/5xb3D3y2AAAAB8GSesnWuuJeP9fKyH389HWmLncmxop+28ffWP e4O7XwYDAADgsuR9fQt/9co9fE3L7Xa7Nd38uF30nhYamK0naQDnqn8EIR8AAPwWp6ye/NUrj/A1 Lbfb7dY+58ftove00MBsPUkDOFf9Iwj5AAAAyJz/kQYAAADgQEovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABw KUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQD AABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBd IOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAA AEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUovrAAAAEBdIOQDAABwKUov rAAAAEBdnBjy9c1tpul3Xr7nwu/l1d1vt9vtdu9epUW5NNt6fnX3CobhK+zhB+dpXj78nUyiDns+ ktIL69/f0C7j2A47L99z4ffyfj5ut9vt9ni+S4tyabb1/H4+KhiGr7CHH5ynefnwdzKJOuy5DnKG fLNHKjosr+7ucGD6RiosHy3JGRL1Tf2+maGHV3evX/5//zb1/OqaOrohybnDDrOMy7fMU4367Nb3 O/lRQwn2nGskz7eIE9bO2SMVHZb38+FwYIZWKiwfLckZEg1t/b6ZoYf381G//H9/m3p+P9s6uiHJ ucMOs4zLt8xTjfrs1vc7+VFDCfacayRrtogDdvlk19kXuHyLK4mQb6S+kfHzYyFfJlm+Y55q1Cfp abMdIV8mZNfZF7h8iyuJkG+kvpHx82MhXyZZvmOeatQn6WmzHSHfxBkhn7n7FxGWJvlHfdP0S9oT rYXkQm05TH1zu93uXb+0sl4wtnzvXnEC3drAcsyQUywfXtQ0jVm/rs+t3rF6jP5qelP1QKQPtSbq QU9EVPXZNNL4Ckx1z6WmP1mvef0k4TC4dpEpknOtpum3XWTdflT7JA3M5uCV07RDU3c3oZ5k/R89 T6NG1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHsWct4RGTou5+xcRlib5R0PbDkvaE62F 5EJtOUxDe7vdHs9haWW9YGz58XzHCXRrA8sxQ06xfHhR27Zm/bo+t3rH6jH6q+lN1QORPtSaqAc9 EVHVZ9tK4ysw1T2Xmv5kveb1k4TD4NpFpkjOtZp22HaRdftR7ZM0MJuDV07TDi1Bg5JO/R89T6NG 1vni1nNNdqvW4/2d1PqV1iyz5736idsV7Nn/O7ljHn3Cl+3yUaeeOAKk6r7ZdJX400b8gsmBGw/0 fT+VYMEZa01oTCv/6u5rU6/uPp8w6o+6t9EvsR6tv5beJD38e/X9Sy5u3cWP5Ff7S3SS0OswBlv+ VuunUsYJdGGLNLMv+dkn2X4UPZMTtOtOOcMrUonr8elfbzfTPNXmy/xnsp7rslt7vnt+J/V+iaVV e/bqRyuv2bPzd3IRMHV8JTKtjwkcuctHnXriCJCqh3bTVeJPG/ELJgduPDAMw1SCBWesNaExrfz7 +Vibej8f8wmj/qh7G/0S69H6a+lN0sPfexjecnHrLn4kv9pfopOEXocx2PK3Wj+VMk6gC1ukmX3J zz7J9qPomZygXXfKGV6RSlyPT/96u5nmqTZf5j+T9VyX3drz3fM7qfdLLK3as1c/WnnNnp2/k4uA qeP7GV8W8kmuMLn1O7Hh/ITeAq822ssJZaFFJDm18to2kVX/eD71Fr5Sj9JfU2+isPyG/V7XWe8v DW8SnmkaK5rji+UCvX5XKLVvGET7UfVMFUqkKRjyefSvtptnnprbqi4912W39nx3hXxqv8TCqj17 9aOWV+zZ9zspSvvPaz9ZVsckzknsXF1hcut3YsMXCL0FXm20lxPKQotIcmrltW0iq/7xfOotfKUe pb+m3kRh+Q37va6z3l8a3iQ80zRWNMcXywV6/a5Qat8wiPaj6pkqlEhTMOTz6F9tN888NbdVXXqu y27t+e4K+dR+iYVVe/bqRy2v2LPvd1KU9m/H73wilwj5nE+/WL7cNUM+sb9mvbLLpUYiRUK+V9d0 r1fXjTlqS7X1hXyJ24M17PIdGvL55qk/5JPrr81uc4V8Vr8EVHv26ietXf72mzwhn8d+ciyOaZwf 8jmTfCxf7pohn9hfs17Z5VIjkSIh3/vZPt/v53PMUVuqrS/kS9werGGX79CQzzdP/SGfXH9tdpsr 5LP6JaDas1c/ae3yt9/kCfnyJXNSqg352PMbgjNPfI2EpKag8puadCT5mVx0VkKUUyvPvaA1bc2o Pz5t9kuuR+uvpbcNl4sMSnguPBXLr/bXG3K8uq7rmnGHjz3xo9S/npC+JCAkdjJzS0zslOxH1jNr kId8HjmDY5H+NfKEfAfOU22+jH8l67k6uzXnuyfk0/slodmzVz9qedWenb+T8V/Llen2c8BaqZAn 5GPPbwjOPPE1vDk+NO8sqFX0M7norIQop1aee0Fr2ppRf3za7Jdcj9ZfS28bLhcZlPBceCqWX+2v N+R4P5/PZzvu8LEnfpT61xPSlwSExE5mbomJnZL9yHpmDfKQzyNncCzSv0aekO/AearNl/GvZD1X Z7fmfPeEfHq/JDR79upHLa/as/N3Mv5ruTLPvh7njI80uF9LwK5h3u909XJ2qoq3sOUz9c296+IX ARhispwiJn4sp1mentiqP3rvwbbi5HaV/mp6U/VA39rQNHd6StKDIb8kJx3TcHyN/gp+q67/5fj8 PhtmTOYINN3W43yG/cj2yTPVRDNJk1PWf6qcUz179H/sPP0nzxe3nqu0W6F27++k1a+tC6g9O/Wj ltft2fU76R5fkfxLZYT2+gH3awnYNcz7na5ezk5V8Ra2fKahfTyf8YsADDFZThETP5bTLE9PbNUf vfdgW3Fyu0p/Nb2peqBvbWjbBz0l6cGQX5KTjmk4vkZ/Bb9V1/9yfH6fDTMmcwTa59bjfIb9yPbJ M9VEM0mTU9Z/qpxTPXv0f+w8/ZPni1vPVdqtULv3d9Lq19YF1J6d+lHL6/bs+p10j++HnPgp9mr4 hq8e5OTX+gsA8HYBAAAACeBJREFU+HFyLI4X4Ru+epCTX+svAAAkgpDv+vxafwEAP07phbUifi0E +rX+AgBAIj8X8llfwLsiv9ZfAAAovbDWgvUFvCvya/0FAIB0fi7kAwAAcG1KL6wAAABAXSDkAwAA cClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXSDkAwAAcClKL6wAAABAXVQS 8r22vnNdX7t9c0v7qvw3UEr/B1BwXF7zZ9P7puo3pH6LnOATyHfOz5gOlf0ell5Ybd5b37mur92h Tfha8rdQSv8HUHBc3vNn04e26jekfouc4BPId87PmA5f+3tYScj379+/V9cU8T2T2u0byZmRj34p pfSfhE/Txcalb8YI6tXdz3V/nT0uJucFeHX3LEFyrnr06g8c2Fy/h8fN1NIL6ybvZ1vE90xqd2gl Z0Y++qWU0n8SPk0XG5ehHSOo9/Nxrvvr7HExOS/A+/nIEiTnqkev/sCBzfV7WMMvKEI+hHwjCPk+ p2/GCOrV3c/dPNsR8hWRE5xF3xw5sAj5PgYhX1kQ8n3O0I4R1Pv5OHfzbEfIV0ROcBZDe+TAIuST mLLFmkZKJlI+CL4ebnoacpCcpBTHZWw6KG7Jo7W7UXnYRN80fW/Xvy0/SYiamiI1EUGb5r6hn/Hy e/eaRU5rW9LD5ngFdStySnjtxNC/3i15XEQ7oQXDi5x2uO7c9A3vF2l5VZA+Xkq7hp3L+tHkV+VU u6WoQeyXftxtP+l2NeWo9kvDtHT6fBln42icixHNKtLnlU/+lHqCwsp8EQktQvw92f27seP30G23 GTh85Zyyxdo5nYit5coHwdfD7UBDDpKTlOK4jE0HxS15tHY3Kg+bGNp2GOz6t+UnCVFTU6QmImjb Pjb0M17+eL5nkdPalvSwOV5B3YqcEl47MfSvd0seF9FOaMHwIqcdrjs3Q8v7RVpeFaSPl9KuYeey fjT5VTnVbilqEPulH3fbT7pdTTmqw9IwLZ0+X8bZOBrnYkSzivR55ZM/pZ6gsDJfREKLEH9Pdv9u 7Pg9dNvtqWTd5aObBj1z9JiHvXq83K8RLk1zSl99T6pfi8vyqO0aaHe1RaHd8tPaaUJWz73EFP0s j2n9+/fvX99bLRv6F8dLb1eR02rZYSfjX75dPtmYDDuR+uIeR4VXd1+vDRQkjZfaria/op9c8mvt av3Sjrvtx2lX/GmytQHnfJktb/43TJGM98/2yR/Vo9q/OvlNZUTljPnl+d0Yr3b8HnrtNgtnLJ50 02Bgjh7zsFePl/s1wqVpTul7GEj1a3FZHrVdA+2utii0W35aO03IGriXmKKf5TGtv7+/v2GwWjb0 L46X3q4ip9Wyw07Gv3y7fLIxGXYi9cU9jgrv52O9NlCQNF5qu5r8in5yya+1q/VLO+62H6dd8afJ 1gac82W2vPnfMEUy3j/bJ39Uj2r/6uQ3EMoZ88vzuzFe7fg99NrtyeQO+airt3hcfFmftpPC3bXF RyC35Ce23AJ+w1h25Zf/q+1abCcy0f565ddCPtYx6svq9aenZxr6F8fLaleU02raYSfiORtNn5qd kCvIpf5xlDGHRDipt5sgf1I9/h5I7Wr90o7vsB+fXYVR7aQU73yZdTlPiO2Qb5/8YT26/cvzxUYK TPX55U3r9vweeu02D2csntQ5Wv8fLuvTdlK4u7b4COSW/MSWW8BvGMuu/PJ/tV2L7UQm2l+v/FrI xzpGfVm9/vT0TEP/4nhZ7YpyWk077EQ8Z6PpU7MTcgW51D+OMuaQCCf1dhPkT6rH3wOpXa1f2vEd 9uOzqzCqnZTinS+zLucJsR3y7ZM/rEe3f3m+2EiBqT6/vGndnt9Dr92eTZUhny/FR92wKRbyeVOU 1JCPsO7JmfUfGvIlJtmm7PIVCPl0O/k3d44dzfU0lD/kk9u15JdDvjzya+36Q75P7CfBrpQYyjtf doR8u+T/lZDPa7d5OGPxzBXy+VJ81A2bYiGfN0VJDfkI656cWf+hIV9ikm3KLl+BkE+3k7+5c+xo rqeh/CGf3K4lvxzy5ZFfa9cf8n1iPwl2pcRQ3vmyI+TbJf+vhHxeuz2bE0K+wPtYnItoP4skFvoc fP5g1kbIp7eb1gZpQgnV3Dl0a+0sN43pjbiMVv0O183QvzhearuanEktb9tJcIoPsch2KB5X8uru 4eNin+RCBlUHqZxUvHi8lHYt+UX9ZJJfbVfrl3bcaz9eu6J5hf/Yzq1rvrhDvp3y2/VQyfKEfNb8 8od86b+HbrvNwhmLp+KacO9jcS6i/SySWOhz8PmDWRshn95uWhukCSVUc+fQrbWz3DSmN+IyWvU7 XDdD/+J4qe1qcia1vG0nwSk+xCLboXhcyfv5CB8X+yQXMqg6SOWk4sXjpbRryS/qJ5P8artav7Tj Xvvx2hXNK/xjO7eu+eIO+XbKb9dDJcsT8lnzyx/ypf8euu32ZHK/vmWMWOj///0LcquUvMWOPE7G M4G2XD36doCmmZ9JMeRR201pg0VnQlt++Yl+5vdPCBlpWsKYojTvex6YHpTxUvqly2k2mm4nov63 dBmPi2wn9MJQdu84bgpF+2WMl9yuJb+snzzyG+1K/TKO++zHZ1dj/NAZL2oJToj6J9Yzf7Rwfswt LC9b7bb8aj2y/VvzZXO8LIkS7DClje3fQ7/dZuDwlXPJ3mkH9v+/vyC3SslbfJLHyXgm0JarR98O 0LbzMymGPGq7KW2w6Exoyy8/0c/8/gkhI01LGFOU5n3PA9ODMl5Kv3Q5zUbT7eRP0v+WLuNxke2E XhjK7h3HTaFov4zxktu15Jf1k0d+o12pX8Zxn/347GqMH57Gi1qCE6L+ifXMHy2cH3MLy8tWuy2/ Wo9s/9Z82RwvS6IEO0xpY/v30G+3p1LPRxoAAGA/x36XAHwVZZZTAAA4hWO/SwAuCkI+AMAVQMgH FkovrAAAcCAI+cAOEPIBAL4e5UuS4EcpvbACAMBRKF+SBGADhHwAAAAuRemFFQAAAKgLhHwAAAAu RemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwA AAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgL hHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAA AKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemF FQAAAKgLhHwAAAAuRemFFQAAAKgLhHwAAAAuRemFFQAAAKiL/yHb36jUrG9uAAAAAElFTkSuQmCC --001a114b72f4a741f7055d997bea-- From nobody Fri Nov 10 02:03:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA30C12EC1D; Fri, 10 Nov 2017 02:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cnWLTVMPsCX; Fri, 10 Nov 2017 02:03:01 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 AC7BD12EC17; Fri, 10 Nov 2017 02:03:01 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id m191so933888itg.1; Fri, 10 Nov 2017 02:03:01 -0800 (PST) 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=u6JxOJl7Zj+B2yBnsJlXgPQypes1YI+Cem0e3trZP7w=; b=jcgu79Ikdk2y95yHuHeL6aC76owiTyRte3B1tWSRztyn3udp+WGUFRKVDSSG8XZliX DEw2bjvzCTPJZe547PPd5Dk2kNQTWyYZJ9xK8uLBEpluDF1amGZzXH636xiAph+7WI4q xonRs9iWAdUmxmzVl4jqFtwQz0womGy6TWLePhaZgQcgTkqZV/5CUbSmVlhX/7E/Zr5M Vf6D97GPkZegx9Gp0CDoTEk9ISkumu1bOOFkLK2U4cBqYCCP87x893yFBNVRFcyMfEdL WqigJFyfkKMkGOS6+JUeXASzov3J7PH/pX6aZ0N3XGHf+pqn8PU3Ks80Otwqkyqftx7K G4Pw== 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=u6JxOJl7Zj+B2yBnsJlXgPQypes1YI+Cem0e3trZP7w=; b=l9e76r7+yj1adXuF5aKhpYQvH1PD8zc9yLkh7R34gBTdxPZ/QKnIUT9xU/FuohmmD/ tgl8MLtlfcTqqmgYAY1Y4Rs2AN+SrcKh7RxTAC7h67uX5gnTI0OkDRH71D9aM47U1DHR 7Vrrc5elcym7m+Y/KgbUh6PRdazcmj8faCxWNkG7nwA3zksuNF/kgU2MiCFlLVxMbGtn 2c5PCTLpATfMzKnD5yuwBYfCcTLfsTG7e5oQS4kFb1MmcBXdzIfwx8FMy67Va0Q/hcUv QAJjO3LvitrQUOlQGqv5cb3hUXpuAwToN2jsorpR8n/+BIxP2C7sYBtjLLbkiMhGVyNE 67tQ== X-Gm-Message-State: AJaThX4SAdLyDNSf0tL7KmmXfeoZEIIzAt5GdRruMIso+RG1cVky00Z/ NsKqi0TvPXUoLvXMbMYLD4E= X-Google-Smtp-Source: AGs4zMahT5FmI9muLuZQenNjFXyOyMJMgFP0C/9gXHZaF2kYkVyLM54qtIizWw7JKI0I48nm6kXYCQ== X-Received: by 10.36.120.136 with SMTP id p130mr946986itc.54.1510308180961; Fri, 10 Nov 2017 02:03:00 -0800 (PST) Received: from [192.168.8.102] ([123.231.110.149]) by smtp.gmail.com with ESMTPSA id i201sm734117ita.32.2017.11.10.02.02.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 02:02:59 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-80AA0840-F978-43B5-9B41-0C7108B68797 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Fri, 10 Nov 2017 15:32:55 +0530 Cc: Robert Wilton , "sec-ads@ietf.org" , NETCONF Content-Transfer-Encoding: 7bit Message-Id: <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> To: Andy Bierman Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 10:03:09 -0000 --Apple-Mail-80AA0840-F978-43B5-9B41-0C7108B68797 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani=20 mjethanandani@gmail.com > On Nov 10, 2017, at 10:07 AM, Andy Bierman wrote: >=20 > Hi, >=20 > The term "data node" is used in the document to refer to the top-level nod= e > of the specified object, not the entire subtree (if any). >=20 > The data-rule /foo does not match /foo/child1 in the text below. > The child nodes are omitted because of step 11. > The admin has to explicitly permit individual child nodes (or modules). > This seems correct if the read-default is "deny". >=20 > Should any text be added or changed to make this more clear? I would agree with Robert that it was not entirely clear that rule applied o= n the parent data-node does not apply to the child nodes. So yes, it would h= elp to clarify it.=20 Thanks=20 >=20 >=20 > Andy >=20 >=20 >> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton wrote: >> Hi Andy, >>=20 >> It isn't clear to me whether matching a path in NACM either: >> (i) Only applies to the specific node, and not any children, or >> (ii) Applies to the specific node and all descendant children nodes as w= ell.=20 >> As an example, using the tree below. if I have a rule that matches path "= A/B" then does that apply to only the specific node "A/B", or does it also a= pply to all descendant children of "A/B" as well? >>=20 >> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", step 6 s= tates: >>=20 >> * The rule does not have a "rule-type" defined or the "rule- >> type" is "data-node" and the "path" matches the requested >> data node, action node, or notification node. >>=20 >> My reading of this is that it implies that the interpretation of the path= rule is (i), but this is not how I would normally expect an ACL rule to app= ly in a tree like object (e.g a directory file system). >>=20 >> However, the examples in Appendix B.4. imply that the path rule is to be i= nterpreted like (ii), or otherwise the example rules seem to be mostly point= less. >>=20 >> E.g. taking this example from appendix B.4: >> >> permit-dummy-interface >> >> /acme:interfaces/acme:interface[acme:name=3D'dummy'] >> >> read update >> permit >> >> Allow the limited and guest groups read >> and update access to the dummy interface. >> >> >>=20 >> If the rule is (i) then the access rule allows the client to read the sp= ecific node "/acme:interfaces/acme:interface[acme:name=3D'dummy']" but not a= ny child leafs/containers of that interface, this doesn't seem useful. >>=20 >> Further comments inline below ... >>=20 >>> On 08/11/2017 20:05, Andy Bierman wrote: >>> Hi, >>>=20 >>> This change has no impact on the server if /nacm/read-default i= s "permit". >>> In that case, the extra read rules for /A and /A/B are not needed. >> I agree. >>=20 >>> An operator worried about read access should set read-default to "deny".= >> I agree. This is the scenario that I'm considering. >>=20 >>> In that case, explicit rules to read /A and /A/B would be needed >>> in the new NACM. >> Yes, if the interpretation of the rule is (i) above. >> Otherwise if the interpretation is (ii) then you only need "read /A" sinc= e that implies "read A/B" as well (as long as the rules are listed in the co= rrect order). >>=20 >>=20 >>> The deny rules would not be needed. >> Only if the interpretation of the rule is (i) above. In which case the "= read/write 'A/B/J' rule would not be sufficient. It would be necessary to d= efine an Xpath expressions that contains all children nodes as well. Perhap= s 'A/B/J//*'? >>=20 >> If the interpretation of the rule is (ii) then you would also need all th= e explicit deny statements as well, otherwise they would be allowed by the "= read /A" rule above. >>=20 >> Thanks, >> Rob >>=20 >>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton wrote= : >>>> Hi, >>>> I'm not sure about this change. >>>> I'm not that familiar with NACM, but if you want to give a particular s= et of users read/write access to a subtree, but not allow them to have any o= ther access to the configuration in the running datastore = then with the existing RFC, that could be expressed with a single rule (ex= ample in 6536bis, appendix B.4) >>>> With this new change, I think that you may need to configure many more r= ules to achieve the same thing. I think that you would need to give read ac= cess to the top node in the desired path, and then separate explicit "deny" r= ules for every sibling child node walking from the top of the tree down to t= he data node that read/write access is actually being given to. The example= below may explain my understanding better: >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to give read/w= rite access only to "J" subtree, and no access for the rest of the tree then= : >>>> A >>>> | >>>> -------------------- >>>> | | | | >>>> B C D E >>>> | >>>> ----------- >>>> | | | | >>>> F G H J >>>> | >>>> ... >>>>=20 >>>>=20 >>>>=20 >>>> In the old model, I think that the ACL rules would be 1 rules long (ass= uming default deny all): >>>> "read/write 'A/B/J' >>>> In the new model, I think that the equivalent ACL rules would need to b= e 8 rules long (assuming default deny all): >>>> "read/write 'A/B/J' >>>> "read A" >>>> "deny C" >>>> "deny D" >>>> "deny E" >>>> "deny F" >>>> "deny G" >>>> "deny H" >>>> Note, I am assuming that a "path" rule matches for the given path and a= ll descendant nodes. The draft doesn't seem to be particularly clear on thi= s point (it states that the rule applies when the path mat= ches, but this would seem to be counter intuitive), and perhaps it could be c= larified. >>>>=20 >>>> If this change is allowed, then the example in appendix B.4 looks like i= t would need to be fixed, since the "limited-acl" probably wouldn't give any= access at all, unless default read access had been given. >>>>=20 >>>> But, possibly I'm misunderstanding how this all works! If so, apologie= s for the noise :-) >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>>> On 02/11/2017 14:18, Benoit Claise wrote: >>>>> Dear all, >>>>>=20 >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by t= he Security AD Eric Rescola part of the IESG review, which I would like to v= alidate with the WG. See https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ne= tconf-rfc6536bis-08.txt >>>>>=20 >>>>> >>>>> The NETCONF WG was cc'ed for the entire discussion.=20 >>>>> What do you think? I will draw the conclusions by Friday Nov 10th. >>>>>=20 >>>>> Note: If the WG is fine, the next step is to approve this document. >>>>>=20 >>>>> Regards, Benoit >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani=20 mjethanandani@gmail.com= --Apple-Mail-80AA0840-F978-43B5-9B41-0C7108B68797 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




Mahesh= Jethanandani 
On Nov 10, 2017, at 10:07 AM, Andy Bierman <= ;andy@yumaworks.com> wrote:
=
Hi,

=
The term "data node" is used in the document to refer to the top-level n= ode
of the specified object, not the entire subtree (if any).<= /div>

The data-rule /foo does not match /foo/child1 in th= e text below.
The child nodes are omitted because of step 11.
The admin has to explicitly permit individual child nodes (or modules)= .
This seems correct if the read-default is "deny".

Should any text be added or changed to make this more clea= r?

I would agree with Robert th= at it was not entirely clear that rule applied on the parent data-node does n= ot apply to the child nodes. So yes, it would help to clarify it. 

Thanks 



Andy


On Thu, Nov 9, 2017 a= t 2:44 AM, Robert Wilton <rwilton@cisco.com> wrote:
=20 =20 =20

Hi Andy,

It isn't clear to me whether matching a path in NACM either:
  (i) Only applies to the specific node, and not any children, or=
  (ii) Applies to the specific node and all descendant children nodes as well.

As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as well?

In rfc6536bis-08, section "3.4.5.  Data Node Access Validation",= step 6 states: 

       =
 *  The rule does not have a "rule-type" defined or the "rule-
           type" is "data-node" and the "path" matches the requested
           data node, action node, or notification node.

My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system).

However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.

E.g. taking this example from appendix B.4:
       &=
lt;rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme=3D"http://exa=
mple.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name=3D'dummy']
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Allow the limited and guest groups read
           and update access to the dummy interface.
         </comment>
       </rule>

If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name=3D'dummy']" but not any child leafs/containers of that interface, this doesn't seem useful.

Further comments inline below ...

On 08/11/2017 20:05= , Andy Bierman wrote:
=20
Hi,

This change has no impact on the server if /nacm/read-default is "permit".
In that case, the extra read rules for /A and /A/B are not needed.
I agree.

An operator worried about read access should set read-default to "deny".
I agree.  This is the scenario that I'm considering.

In that case, explicit rules to read /A and /A/B would be needed
in the new NACM.
Yes, if the interpretation of the rule is (i) above.
Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).


  The deny rules would not be needed.
Only if the interpretation of the rule is (i) above.  In which case= the  "read/write 'A/B/J' rule would not be sufficient.  It wou= ld be necessary to define an Xpath expressions that contains all children nodes as well.  Perhaps 'A/B/J//*'?

If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.

Thanks,
Rob




Andy


On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:

        &nb= sp;        A
        = ;         |
        -----------= ---------
        |      | &n= bsp;   |     |
        B &nbs= p;    C     D     E         |
   -----------
   |   |  |  |
   F   G  H  J
         =     |
         =   ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
   "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
   "read/write 'A/B/J'
   "read A"
   "deny C"
   "deny D"
   "deny E"
   "deny F"
   "deny G"
   "deny H"

Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:18, Benoit Claise wrote:
Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-net= conf-rfc6536bis-08.txt

<dfpcfioondggippe.png>
The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


______________________________________________=
_
Netconf mailing list
Netconf@ietf.org
=
https://www.ietf.org/mailman/listinfo/netconf




____________________= ___________________________
Netconf mailing list
<= span>Netconf@ietf.org
https://www.ietf= .org/mailman/listinfo/netconf

Mahesh Jethanandani&nb= sp;
= --Apple-Mail-80AA0840-F978-43B5-9B41-0C7108B68797-- From nobody Fri Nov 10 02:42:47 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81040129432; Fri, 10 Nov 2017 02:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Q5mo7vMgNIVW; Fri, 10 Nov 2017 02:42:42 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29EC1292AE; Fri, 10 Nov 2017 02:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36123; q=dns/txt; s=iport; t=1510310562; x=1511520162; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=NtOp83DjTI1PvRKuAhCjmAVeBTOTlUMS3cOKfi2Pmjg=; b=SJOrKVdFK2DhZUJrdMfB8BCue14LDPRxlMZnlCOpE/S/yTCC2F43BpLu KugOqkYzjIV9Oqdsl02tlk8D82G+J3xv7fUvETbr3bOuiXYp2SBhdQt2Q ssje6awGZ6hB/w2bEfYb2v+p1kzGJzEEqpBYtVQ9MBZzV02APbDhugTeQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAADLgQVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEgVVuJ4N+ih90kA0miFeFEohnEIF+AwoYAQyBN4MQTwKEehg?= =?us-ascii?q?BAQEBAQEBAQFrKIUeAQEBAQIBAQEhSwsQCQIOCiABBgMCAiEGHxEGAQwGAgEBi?= =?us-ascii?q?gYDDQgQi1mdaIInJocVDYNIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMwg1uBaSk?= =?us-ascii?q?LgnaCa1mBGwQNEUyCX4JjBYophzuHKYhWPYdpg2iENoR5ghVfiQgkhx6KMYI3O?= =?us-ascii?q?oEQh3CBOR84QoEwNCEIHRVJgmQJghpugU5BNgGJYAIlB4IWAQEB?= X-IronPort-AV: E=Sophos;i="5.44,373,1505779200"; d="scan'208,217";a="133826" 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; 10 Nov 2017 10:42:39 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAAAgdP8026929; Fri, 10 Nov 2017 10:42:39 GMT To: Mahesh Jethanandani , Andy Bierman , NETCONF Cc: "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> From: Robert Wilton Message-ID: <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> Date: Fri, 10 Nov 2017 10:42:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> Content-Type: multipart/alternative; boundary="------------7520C0A90875260FF381FE83" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 10:42:45 -0000 This is a multi-part message in MIME format. --------------7520C0A90875260FF381FE83 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/11/2017 10:02, Mahesh Jethanandani wrote: > > > > > Mahesh Jethanandani > mjethanandani@gmail.com > On Nov 10, 2017, at 10:07 AM, Andy Bierman > wrote: > >> Hi, >> >> The term "data node" is used in the document to refer to the >> top-level node >> of the specified object, not the entire subtree (if any). >> >> The data-rule /foo does not match /foo/child1 in the text below. >> The child nodes are omitted because of step 11. >> The admin has to explicitly permit individual child nodes (or modules). >> This seems correct if the read-default is "deny". >> >> Should any text be added or changed to make this more clear? > > I would agree with Robert that it was not entirely clear that rule > applied on the parent data-node does not apply to the child nodes. So > yes, it would help to clarify it. We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in the appendix B.4. If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write access to all acme entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable. To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies: (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes. (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root. (I.e. to mitigate the original change proposed on this thread.) Thanks, Rob > > Thanks > >> >> >> Andy >> >> >> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton > > wrote: >> >> Hi Andy, >> >> It isn't clear to me whether matching a path in NACM either: >>   (i) Only applies to the specific node, and not any children, or >>   (ii) Applies to the specific node and all descendant children >> nodes as well. >> >> As an example, using the tree below.  if I have a rule that >> matches path "A/B" then does that apply to only the specific node >> "A/B", or does it also apply to all descendant children of "A/B" >> as well? >> >> In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", >> step 6 states: >> >> * The rule does not have a "rule-type" defined or the "rule- >> type" is "data-node" and the*"path" matches the requested data node*, action node, or notification node. >> >> >> My reading of this is that it implies that the interpretation of >> the path rule is (i), but this is not how I would normally expect >> an ACL rule to apply in a tree like object (e.g a directory file >> system). >> >> However, the examples in Appendix B.4. imply that the path rule >> is to be interpreted like (ii), or otherwise the example rules >> seem to be mostly pointless. >> >> E.g. taking this example from appendix B.4: >> >> >> permit-dummy-interface >> > >> /acme:interfaces/acme:interface[acme:name='dummy'] >> >> read update >> permit >> >> Allow the limited and guest groups read >> and update access to the dummy interface. >> >> >> >> >> If the rule is (i)  then the access rule allows the client to >> read the specific node >> "/acme:interfaces/acme:interface[acme:name='dummy']" but not any >> child leafs/containers of that interface, this doesn't seem useful. >> >> Further comments inline below ... >> >> On 08/11/2017 20:05, Andy Bierman wrote: >>> Hi, >>> >>> This change has no impact on the server if /nacm/read-default is >>> "permit". >>> In that case, the extra read rules for /A and /A/B are not needed. >> I agree. >> >>> An operator worried about read access should set read-default to >>> "deny". >> I agree.  This is the scenario that I'm considering. >> >>> In that case, explicit rules to read /A and /A/B would be needed >>> in the new NACM. >> Yes, if the interpretation of the rule is (i) above. >> Otherwise if the interpretation is (ii) then you only need "read >> /A" since that implies "read A/B" as well (as long as the rules >> are listed in the correct order). >> >> >>>   The deny rules would not be needed. >> Only if the interpretation of the rule is (i) above.  In which >> case the  "read/write 'A/B/J' rule would not be sufficient.  It >> would be necessary to define an Xpath expressions that contains >> all children nodes as well.  Perhaps 'A/B/J//*'? >> >> If the interpretation of the rule is (ii) then you would also >> need all the explicit deny statements as well, otherwise they >> would be allowed by the "read /A" rule above. >> >> Thanks, >> Rob >> >> >>> >>> >>> Andy >>> >>> >>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton >> > wrote: >>> >>> Hi, >>> >>> I'm not sure about this change. >>> >>> I'm not that familiar with NACM, but if you want to give a >>> particular set of users read/write access to a subtree, but >>> not allow them to have any other access to the configuration >>> in the running datastore then with the existing RFC, that >>> could be expressed with a single rule (example in 6536bis, >>> appendix B.4) >>> >>> With this new change, I think that you may need to configure >>> many more rules to achieve the same thing.  I think that you >>> would need to give read access to the top node in the >>> desired path, and then separate explicit "deny" rules for >>> every sibling child node walking from the top of the tree >>> down to the data node that read/write access is actually >>> being given to.  The example below may explain my >>> understanding better: >>> >>> E.g. For a tree of data nodes, rooted at A, if we wanted to >>> give read/write access only to "J" subtree, and no access >>> for the rest of the tree then: >>> >>>                  A >>>                  | >>>         -------------------- >>>         |      |     |     | >>>         B      C     D     E >>>         | >>>    ----------- >>>    |   |  |  | >>>    F   G  H  J >>>              | >>>             ... >>> >>> >>> In the old model, I think that the ACL rules would be 1 >>> rules long (assuming default deny all): >>>    "read/write 'A/B/J' >>> >>> In the new model, I think that the equivalent ACL rules >>> would need to be 8 rules long (assuming default deny all): >>>    "read/write 'A/B/J' >>>    "read A" >>>    "deny C" >>>    "deny D" >>>    "deny E" >>>    "deny F" >>>    "deny G" >>>    "deny H" >>> >>> Note, I am assuming that a "path" rule matches for the given >>> path and all descendant nodes.  The draft doesn't seem to be >>> particularly clear on this point (it states that the rule >>> applies when the path matches, but this would seem to be >>> counter intuitive), and perhaps it could be clarified. >>> >>> If this change is allowed, then the example in appendix B.4 >>> looks like it would need to be fixed, since the >>> "limited-acl" probably wouldn't give any access at all, >>> unless default read access had been given. >>> >>> But, possibly I'm misunderstanding how this all works!  If >>> so, apologies for the noise :-) >>> >>> Thanks, >>> Rob >>> >>> >>> On 02/11/2017 14:18, Benoit Claise wrote: >>>> Dear all, >>>> >>>> Here is a major change in draft-ietf-netconf-rfc6536bis, >>>> suggested by the Security AD Eric Rescola part of the IESG >>>> review, which I would like to validate with the WG. See >>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>>> >>>> >>>> >>>> The NETCONF WG was cc'ed for the entire discussion. >>>> What do you think? I will draw the conclusions by Friday >>>> Nov 10th. >>>> >>>> Note: If the WG is fine, the next step is to approve this >>>> document. >>>> >>>> Regards, Benoit >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >>> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > Mahesh Jethanandani > mjethanandani@gmail.com --------------7520C0A90875260FF381FE83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/11/2017 10:02, Mahesh Jethanandani wrote:




Mahesh Jethanandani 
On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

The term "data node" is used in the document to refer to the top-level node
of the specified object, not the entire subtree (if any).

The data-rule /foo does not match /foo/child1 in the text below.
The child nodes are omitted because of step 11.
The admin has to explicitly permit individual child nodes (or modules).
This seems correct if the read-default is "deny".

Should any text be added or changed to make this more clear?

I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in the appendix B.4.

If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write access to all acme <interface> entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable.


To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies:

(i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.

(ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)


Thanks,
Rob



Thanks 



Andy


On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,

It isn't clear to me whether matching a path in NACM either:
  (i) Only applies to the specific node, and not any children, or
  (ii) Applies to the specific node and all descendant children nodes as well.

As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as well?

In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states: 

        *  The rule does not have a "rule-type" defined or the "rule-
           type" is "data-node" and the "path" matches the requested
           data node, action node, or notification node.

My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system).

However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.

E.g. taking this example from appendix B.4:
       <rule>
         <name>permit-dummy-interface</name>
         <path xmlns:acme="http://example.com/ns/itf">
           /acme:interfaces/acme:interface[acme:name='dummy']
         </path>
         <access-operations>read update</access-operations>
         <action>permit</action>
         <comment>
           Allow the limited and guest groups read
           and update access to the dummy interface.
         </comment>
       </rule>

If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface, this doesn't seem useful.

Further comments inline below ...

On 08/11/2017 20:05, Andy Bierman wrote:
Hi,

This change has no impact on the server if /nacm/read-default is "permit".
In that case, the extra read rules for /A and /A/B are not needed.
I agree.

An operator worried about read access should set read-default to "deny".
I agree.  This is the scenario that I'm considering.

In that case, explicit rules to read /A and /A/B would be needed
in the new NACM.
Yes, if the interpretation of the rule is (i) above.
Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).


  The deny rules would not be needed.
Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains all children nodes as well.  Perhaps 'A/B/J//*'?

If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.

Thanks,
Rob




Andy


On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)

With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:

                 A
                 |
        --------------------
        |      |     |     |
        B      C     D     E
        |
   -----------
   |   |  |  |
   F   G  H  J
             |
            ...


In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
   "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
   "read/write 'A/B/J'
   "read A"
   "deny C"
   "deny D"
   "deny E"
   "deny F"
   "deny G"
   "deny H"

Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.

If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)

Thanks,
Rob


On 02/11/2017 14:18, Benoit Claise wrote:
Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt

<dfpcfioondggippe.png>
The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit


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




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

Mahesh Jethanandani 

--------------7520C0A90875260FF381FE83-- From nobody Fri Nov 10 03:06:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0712E04D for ; Fri, 10 Nov 2017 03:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 wJ-xKCBP9XxU for ; Fri, 10 Nov 2017 03:06:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70FE128959 for ; Fri, 10 Nov 2017 03:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36266; q=dns/txt; s=iport; t=1510312001; x=1511521601; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=FiOu2NXmmz/S2pq/qPtY1rl028em00zVRFfcZtjMtTU=; b=jEbWRFSgGsjbqBcFF6KR8h5hQN5x0K+3aaApBOLN5m+TztI6Bcz0rNh2 GBqzngU9HCte6Bgl21bqH/UD8lUYMxWNUXuXY6qhTRqUzGVO/mBC+9KrO 2MPGkSckM27MNEtSlTYcaL8KkO3op9I+hph+r5wHWhtjretTzkRtz4JuI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAADfhgVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEgkMng36KH3SQDSaWUBCCAQqFOwKEehgBAQEBAQEBAQFrKIU?= =?us-ascii?q?fAQUaCQRSEAkCEgYgAQYDAgJGAw4GAQwGAgEBih6Lbp1ogW06JopqAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYMwg1uBaSkLgnaEZAESAQlMgl+CYwWKKYc7kDyVAII?= =?us-ascii?q?VhgeDYIdCjjKHcIE5HzhCQW80IQgdFUmCZIRfQTaJcII1AQEB?= X-IronPort-AV: E=Sophos;i="5.44,373,1505779200"; d="scan'208,217";a="126575" 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; 10 Nov 2017 11:06:39 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAAB6dsK006080; Fri, 10 Nov 2017 11:06:39 GMT To: Andy Bierman , "netconf@ietf.org" References: From: Robert Wilton Message-ID: <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com> Date: Fri, 10 Nov 2017 11:06:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6B5B3B73BEC443316A1956E8" Content-Language: en-US Archived-At: Subject: Re: [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 11:06:46 -0000 This is a multi-part message in MIME format. --------------6B5B3B73BEC443316A1956E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06) mandates two constraints that must apply: (1) All conventional datastores must have exactly the same schema.  Hence differences in deviations or features are allowed between these datastores. (sec 5.1, first paragraph) (2) The schema for operational must be a superset of all configuration datatstores, but that data nodes may be omitted (sec 5.3, third paragraph). This implies that only the following differences between datastores are allowed:  (i) a feature can be disabled in conventional (and/or dynamic configuration datastores), but enabled in operational (e.g. for configurable router-id).  (ii) deviations apply in all datastores, except that   a) a deviation can remove nodes in the conventional datastores (if they were not configurable, like the feature example)   b) a deviation can remove nodes in a dynamic datastore (e.g. like I2RS)   c) a deviation can remove nodes from operational only if a server is unable to accurately report them. (iii) modules exist in all datastores, except:   a) a module can be omitted from conventional datastores (e.g. if the module is not configurable)   b) a module can be omitted from a dynamic datastore (e.g. like I2RS)   c) a module can be omitted from operational only if a server is unable to accurately report the data nodes within the module. Changing the type of a node between datastores, or changing its properties is not allowed.  The only difference allowed between data nodes in different datastores is the nodes existence. These rules seem more restrictive that what a server using split config state trees (IETF style, or OpenConfig style) can achieve using deviations today. Thanks, Rob On 09/11/2017 19:33, Andy Bierman wrote: > Hi, > > The new structure still has the same problems for the client as before. > It is a major change in the architecture to have different schema > trees per datastore instead of per-server. > The server is allowed to have different features and deviations for > the same objects. > The client is completely on its own trying to compare to > anything > if the schema trees are different > >   container foo { >     leaf bar { >        if-feature X; >        type string; >     } >     leaf baz { >        if-feature "not X"; >        type string; >     } >  } > > How does the client compare to if the features > do not match? > If the server deviates the leaf (e.g. change type string to int32) how > does the client > compare the values? > > This new complexity would be mandatory for the client to support in > some proprietary > manner since the NMDA standard ignores these problems. > > NMDA was supposed to be simpler because the client could compare intended > and applied values using the same object path. openconfig required a data > model change and a trivial name-mapping. In reality, NMDA > is far more disruptive to existing implementations. > > > Andy > > > > On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton > wrote: > > Hi, > > Given some of the feedback related to the complexity of the YANG > library bis structure, we have come up with two other possible > structures for the YANG library data: > > (1) A simplified structure to make YANG library meet the NMDA > requirements, but that is closer to the existing YANG library > structure, and arguably simpler. > (2) An enhanced version of the structure (1) above, that is also > extended to allow the structure to be reused for schema-mount via > an augmentation. > > For reference, at the end of this email, I have also included the > tree diagram of the existing YANG library, and the current YANG > library bis draft (draft-ietf-netconf-rfc7895bis-02) version. > > Considering the two new YANG library structures: > > ------------------------ > > *(1) A simplified structure to make YANG library meet the NMDA > requirements, but that is closer to the existing YANG library > structure.* > > The main changes are: > (i) Split "implemented modules" and "import-only-modules" into two > separate lists, making the most important list (i.e. implemented > modules) keyed by module name only and hence easier to reference. > (ii) Assume modules are implemented in all datastores by default > (with a "not-implemented-in" leaflist of datastores that a module > is not implemented in). > (iii) Assume that features are implemented in all datastores by > default (with a "not-implemented-in" leaflist of datastores that a > feature is not implemented in). > (iv) Deleted module-sets. > (v) Datastores are now just a list of supported datastores (that > could potentially be extended with further per datastore > properties in future). > > Manually generated tree output for proposed YANG library: > > module: ietf-yang-library >  +--ro yang-library >     +--ro modules >     |  +--ro module* [name] >     |  |  +--ro name yang:yang-identifier >     |  |  +--ro revision? revision-identifier >     |  |  +--ro schema?        inet:uri >     |  |  +--ro namespace      inet:uri >     |  |  +--ro submodule* [name] >     |  |  |  +--ro name yang:yang-identifier >     |  |  |  +--ro revision? yang:yang-identifier >     |  |  |  +--ro schema?     inet:uri >     |  |  +--ro not-implemented-in* >     |  |  |              -> /yang-library/datastore/name >     |  |  +--ro feature* [name] >     |  |  |  +--ro name yang:yang-identifier >     |  |  |  +--ro not-implemented-in* >     |  |  |              -> /yang-library/datastore/name >     |  |  +--ro deviation* >     |  |                 -> ../name >     |  | >     |  +--ro import-only-module* [name revision] >     |     +--ro name yang:yang-identifier >     |     +--ro revision            union >     |     +--ro schema? inet:uri >     |     +--ro namespace inet:uri >     |     +--ro submodule* [name] >     |        +--ro name yang:yang-identifier >     |        +--ro revision yang:revision-identifier >     |        +--ro schema?     inet:uri >     +--ro datastore* [name] // Allows future per datastore properties. >     |  +--ro name          identityref >     +--ro checksum       string > > ------------------------------ > > *(2) An enhanced version of the structure (1) above, that is > extended to allow the structure to be reused for schema-mount via > an augmentation.* > > This is similar to the structure above, except that the "the set > of modules" is contained in a list of named schema (e.g. similar > to the schema mount draft), allowing this structure to be re-used > for schema mount. > > Schema mount would be expected to augment yang-library to add in > the additional schema mount information.  In the tree diagram, I > have shown the schema-mount mount-point augmentation, but not > including namespaces yet. > > Every server would be required to provide at least one schema in > the schema list, and the primary schema for the device would > always be given the name "primary". > > module: ietf-yang-library >  +--ro yang-library >     +--ro schema* [name] >     |  +--ro name           string >     |  +--ro checksum       string >     |  +--ro module* [name] >     |  |  +--ro name yang:yang-identifier >     |  |  +--ro revision? yang:revision-identifier >     |  |  +--ro schema?        inet:uri >     |  |  +--ro namespace      inet:uri >     |  |  +--ro submodule* [name] >     |  |  |  +--ro name yang:yang-identifier >     |  |  |  +--ro revision? yang:yang-identifier >     |  |  |  +--ro schema?     inet:uri >     |  |  +--ro not-implemented-in* >     |  |  |              -> /yang-library/datastore/name >     |  |  +--ro feature* [name] >     |  |  |  +--ro name yang:yang-identifier >     |  |  |  +--ro not-implemented-in* >     |  |  |              -> /yang-library/datastore/name >     |  |  +--ro deviation* >     |  |  |              -> ../name >     |  |  +- schema-mount:mount-point* [label] >     |  |     +--ro label yang:yang-identifier >     |  |     +--ro config?       boolean >     |  |     +--ro (schema-ref) >     |  |        +--:(inline) >     |  |        |  +--ro inline? empty >     |  |        +--:(use-schema) >     |  |           +--ro use-schema* [name] >     |  |              +--ro name >     |  |              |       -> /yang-library/schema/name >     |  |              +--ro parent-reference*   yang:xpath1.0 >     |  | >     |  +--ro import-only-module* [name revision] >     |     +--ro name yang:yang-identifier >     |     +--ro revision            union >     |     +--ro schema? inet:uri >     |     +--ro namespace inet:uri >     |     +--ro submodule* [name] >     |        +--ro name yang:yang-identifier >     |        +--ro revision yang:revision-identifier >     |        +--ro schema?     inet:uri >     +--ro datastore* [name] // Allows future per datastore properties. >     |  +--ro name          identityref >     +--ro checksum       string > > Please can you provide comments on these structures, in particular: > > Is this version better (i.e. simpler) that the version currently > in draft-ietf-netconf-rfc7895bis-02 (below)? > > Should we try and make the structure extensible for schema-mount > via augmentation (i.e. version (2)), or is it better that > schema-mount has its own separate subtree? > > For reference only I have included the existing YANG library and > YANG library bis draft tree diagrams. > > Thanks, > Rob > > > ----------------------------- > > *** FOR REFERENCE ONLY *** > > (3)  The current YANG library structure in YANG library bis > (draft-ietf-netconf-rfc7895bis-02) > > module: ietf-yang-library > +--ro yang-library > +--ro modules > | +--ro module* [id] > | +--ro id string > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro schema? inet:uri > | +--ro namespace inet:uri > | +--ro feature* yang:yang-identifier > | +--ro deviation* [module] > | | +--ro module -> ../../id > | +--ro conformance-type enumeration > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro schema? inet:uri > +--ro module-sets > | +--ro module-set* [id] > | +--ro id string > | +--ro module* -> ../../../modules/module/id > +--ro datastores > | +--ro datastore* [name] > | +--ro name identityref > | +--ro module-set > | -> ../../../module-sets/module-set/id > +--ro checksum string > > ----------------------------- > > *** FOR REFERENCE ONLY *** > > (4)  The current YANG library structure (RFC 7895) > > +--ro modules-state > +--ro module-set-id string > +--ro module* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > +--ro namespace inet:uri > +--ro feature* yang:yang-identifier > +--ro deviation* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > +--ro conformance-type enumeration > +--ro submodule* [name revision] > +--ro name yang:yang-identifier > +--ro revision union > +--ro schema? inet:uri > > --------------6B5B3B73BEC443316A1956E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,

The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06) mandates two constraints that must apply:

(1) All conventional datastores must have exactly the same schema.  Hence differences in deviations or features are allowed between these datastores. (sec 5.1, first paragraph)

(2) The schema for operational must be a superset of all configuration datatstores, but that data nodes may be omitted (sec 5.3, third paragraph).


This implies that only the following differences between datastores are allowed:
 (i) a feature can be disabled in conventional (and/or dynamic configuration datastores), but enabled in operational (e.g. for configurable router-id).

 (ii) deviations apply in all datastores, except that
  a) a deviation can remove nodes in the conventional datastores (if they were not configurable, like the feature example)
  b) a deviation can remove nodes in a dynamic datastore (e.g. like I2RS)
  c) a deviation can remove nodes from operational only if a server is unable to accurately report them.

(iii) modules exist in all datastores, except:
  a) a module can be omitted from conventional datastores (e.g. if the module is not configurable)
  b) a module can be omitted from a dynamic datastore (e.g. like I2RS)
  c) a module can be omitted from operational only if a server is unable to accurately report the data nodes within the module.


Changing the type of a node between datastores, or changing its properties is not allowed.  The only difference allowed between data nodes in different datastores is the nodes existence.
 
These rules seem more restrictive that what a server using split config state trees (IETF style, or OpenConfig style) can achieve using deviations today.

Thanks,
Rob



On 09/11/2017 19:33, Andy Bierman wrote:
Hi,

The new structure still has the same problems for the client as before.
It is a major change in the architecture to have different schema trees per datastore instead of per-server.
The server is allowed to have different features and deviations for the same objects.
The client is completely on its own trying to compare <operational> to anything
if the schema trees are different

  container foo {
    leaf bar {
       if-feature X;
       type string;
    }
    leaf baz {
       if-feature "not X";
       type string;
    }
 }

How does the client compare <running> to <operational> if the features do not match?
If the server deviates the leaf (e.g. change type string to int32) how does the client
compare the values?

This new complexity would be mandatory for the client to support in some proprietary
manner since the NMDA standard ignores these problems.

NMDA was supposed to be simpler because the client could compare intended
and applied values using the same object path. openconfig required a data
model change and a trivial name-mapping. In reality, NMDA
is far more disruptive to existing implementations.


Andy



On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,

Given some of the feedback related to the complexity of the YANG library bis structure, we have come up with two other possible structures for the YANG library data:

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also extended to allow the structure to be reused for schema-mount via an augmentation.

For reference, at the end of this email, I have also included the tree diagram of the existing YANG library, and the current YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) version.

Considering the two new YANG library structures:

------------------------

(1) A simplified structure to make YANG library meet the NMDA requirements, but that is closer to the existing YANG library structure.

The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two separate lists, making the most important list (i.e. implemented modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a module is not implemented in).
(iii) Assume that features are implemented in all datastores by default (with a "not-implemented-in" leaflist of datastores that a feature is not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could potentially be extended with further per datastore properties in future).

Manually generated tree output for proposed YANG library:

module: ietf-yang-library
 +--ro yang-library
    +--ro modules
    |  +--ro module* [name]
    |  |  +--ro name           yang:yang-identifier
    |  |  +--ro revision?      revision-identifier
    |  |  +--ro schema?        inet:uri
    |  |  +--ro namespace      inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema?     inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  |                 -> ../name             
    |  |
    |  +--ro import-only-module* [name revision]
    |     +--ro name                yang:yang-identifier
    |     +--ro revision            union
    |     +--ro schema?             inet:uri
    |     +--ro namespace           inet:uri
    |     +--ro submodule* [name]
    |        +--ro name        yang:yang-identifier
    |        +--ro revision    yang:revision-identifier
    |        +--ro schema?     inet:uri
    +--ro datastore* [name] // Allows future per datastore properties.
    |  +--ro name          identityref
    +--ro checksum       string

------------------------------

(2) An enhanced version of the structure (1) above, that is extended to allow the structure to be reused for schema-mount via an augmentation.

This is similar to the structure above, except that the "the set of modules" is contained in a list of named schema (e.g. similar to the schema mount draft), allowing this structure to be re-used for schema mount.

Schema mount would be expected to augment yang-library to add in the additional schema mount information.  In the tree diagram, I have shown the schema-mount mount-point augmentation, but not including namespaces yet.

Every server would be required to provide at least one schema in the schema list, and the primary schema for the device would always be given the name "primary".

module: ietf-yang-library
 +--ro yang-library
    +--ro schema* [name]
    |  +--ro name           string
    |  +--ro checksum       string
    |  +--ro module* [name]
    |  |  +--ro name           yang:yang-identifier
    |  |  +--ro revision?      yang:revision-identifier
    |  |  +--ro schema?        inet:uri
    |  |  +--ro namespace      inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema?     inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  |  |              -> ../name      
    |  |  +- schema-mount:mount-point* [label]
    |  |     +--ro label         yang:yang-identifier
    |  |     +--ro config?       boolean
    |  |     +--ro (schema-ref)
    |  |        +--:(inline)
    |  |        |  +--ro inline?       empty
    |  |        +--:(use-schema)
    |  |           +--ro use-schema* [name]
    |  |              +--ro name
    |  |              |       -> /yang-library/schema/name
    |  |              +--ro parent-reference*   yang:xpath1.0         
    |  |
    |  +--ro import-only-module* [name revision]
    |     +--ro name                yang:yang-identifier
    |     +--ro revision            union
    |     +--ro schema?             inet:uri
    |     +--ro namespace           inet:uri
    |     +--ro submodule* [name]
    |        +--ro name        yang:yang-identifier
    |        +--ro revision    yang:revision-identifier
    |        +--ro schema?     inet:uri
    +--ro datastore* [name] // Allows future per datastore properties.
    |  +--ro name          identityref
    +--ro checksum       string

Please can you provide comments on these structures, in particular:

Is this version better (i.e. simpler) that the version currently in draft-ietf-netconf-rfc7895bis-02 (below)?

Should we try and make the structure extensible for schema-mount via augmentation (i.e. version (2)), or is it better that schema-mount has its own separate subtree?

For reference only I have included the existing YANG library and YANG library bis draft tree diagrams.

Thanks,
Rob


-----------------------------

*** FOR REFERENCE ONLY ***

(3)  The current YANG library structure in YANG library bis (draft-ietf-netconf-rfc7895bis-02)

   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

-----------------------------

*** FOR REFERENCE ONLY ***

(4)  The current YANG library structure (RFC 7895)

      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



--------------6B5B3B73BEC443316A1956E8-- From nobody Fri Nov 10 05:07:55 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD912EB2B; Fri, 10 Nov 2017 05:07:53 -0800 (PST) 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 SawN1BAuw2mL; Fri, 10 Nov 2017 05:07:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98C001242F7; Fri, 10 Nov 2017 05:07:50 -0800 (PST) Received: from mars.tail-f.com (unknown [173.38.220.56]) by mail.tail-f.com (Postfix) with ESMTPSA id B470B1AE0471; Fri, 10 Nov 2017 14:07:48 +0100 (CET) From: Per Hedeland To: Robert Wilton References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> Cc: Mahesh Jethanandani , Andy Bierman , NETCONF , "sec-ads@ietf.org" Message-ID: <5A05A4A4.3000304@tail-f.com> Date: Fri, 10 Nov 2017 14:07:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 13:07:53 -0000 On 2017-11-10 11:42, Robert Wilton wrote: > > > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >> >> >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> On Nov 10, 2017, at 10:07 AM, Andy Bierman > wrote: >> >>> Hi, >>> >>> The term "data node" is used in the document to refer to the top-level node >>> of the specified object, not the entire subtree (if any). >>> >>> The data-rule /foo does not match /foo/child1 in the text below. >>> The child nodes are omitted because of step 11. >>> The admin has to explicitly permit individual child nodes (or modules). >>> This seems correct if the read-default is "deny". >>> >>> Should any text be added or changed to make this more clear? >> >> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it. > We should be doing more than clarifying it. We need to fix it so that it works in a sensible way. I.e. to make the normative text consistent with the behaviour currently described in the examples in > the appendix B.4. > > If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong. E.g. the 4th rule is described as "This rule gives the 'admin' group read-write > access to all acme entries." But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all. The admin is not even > allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry! Instead, a separate rule would be required for every > single possible schema node under "/acme:interfaces/acme:interface"! I think that this makes "permit" data-node rules completely unusable. I strongly agree with this, and I would say that it isn't only the case for "permit" rules - e.g. denying some access to a subtree of the data model that would otherwise be permitted due to defaults is at least as common, and the rules would be just as unusable for that. Besides the examples, I think that the very use of the term "match", though unfortunately not defined, strongly suggests that it is something other than use of e.g. the term "identify" would imply. Additionally, this text in the description of the 'path' leaf is consistent with the match being a prefix match: The special value '/' refers to all possible datastore contents."; FWIW, our NACM implementation, available to (and used by) customers since 2012, follows the prefix match logic, and I have yet to hear of any user expecting it to do otherwise. > To fix this properly, we need to make the data-node path rule a prefix match. In particular, we need text that specifies: > > (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes. Strongly agree. > (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root. (I.e. to mitigate the original change proposed on this thread.) This seems reasonable to me, although I haven't at this point evaluated the suggestion in detail. In any case I think the main point both regarding this and the prefix match is that this update to 6536 can't make radical changes to the semantics compared to a "reasonable interpretation" (hard to define, I know) of the under-specified original. --Per > Thanks, > Rob > > >> >> Thanks >> >>> >>> >>> Andy >>> >>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton > wrote: >>> >>> Hi Andy, >>> >>> It isn't clear to me whether matching a path in NACM either: >>> (i) Only applies to the specific node, and not any children, or >>> (ii) Applies to the specific node and all descendant children nodes as well. >>> >>> As an example, using the tree below. if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as >>> well? >>> >>> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", step 6 states: >>> >>> * The rule does not have a "rule-type" defined or the "rule- >>> type" is "data-node" and the *"path" matches the requested data node*, action node, or notification node. >>> >>> >>> My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory >>> file system). >>> >>> However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless. >>> >>> E.g. taking this example from appendix B.4: >>> >>> >>> permit-dummy-interface >>> > >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>> >>> read update >>> permit >>> >>> Allow the limited and guest groups read >>> and update access to the dummy interface. >>> >>> >>> >>> >>> If the rule is (i) then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface, >>> this doesn't seem useful. >>> >>> Further comments inline below ... >>> >>> On 08/11/2017 20:05, Andy Bierman wrote: >>>> Hi, >>>> >>>> This change has no impact on the server if /nacm/read-default is "permit". >>>> In that case, the extra read rules for /A and /A/B are not needed. >>> I agree. >>> >>>> An operator worried about read access should set read-default to "deny". >>> I agree. This is the scenario that I'm considering. >>> >>>> In that case, explicit rules to read /A and /A/B would be needed >>>> in the new NACM. >>> Yes, if the interpretation of the rule is (i) above. >>> Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order). >>> >>> >>>> The deny rules would not be needed. >>> Only if the interpretation of the rule is (i) above. In which case the "read/write 'A/B/J' rule would not be sufficient. It would be necessary to define an Xpath expressions that contains >>> all children nodes as well. Perhaps 'A/B/J//*'? >>> >>> If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above. >>> >>> Thanks, >>> Rob >>> >>> >>>> >>>> >>>> Andy >>>> >>>> >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton > wrote: >>>> >>>> Hi, >>>> >>>> I'm not sure about this change. >>>> >>>> I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the >>>> running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4) >>>> >>>> With this new change, I think that you may need to configure many more rules to achieve the same thing. I think that you would need to give read access to the top node in the desired >>>> path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to. The >>>> example below may explain my understanding better: >>>> >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then: >>>> >>>> A >>>> | >>>> -------------------- >>>> | | | | >>>> B C D E >>>> | >>>> ----------- >>>> | | | | >>>> F G H J >>>> | >>>> ... >>>> >>>> >>>> In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all): >>>> "read/write 'A/B/J' >>>> >>>> In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all): >>>> "read/write 'A/B/J' >>>> "read A" >>>> "deny C" >>>> "deny D" >>>> "deny E" >>>> "deny F" >>>> "deny G" >>>> "deny H" >>>> >>>> Note, I am assuming that a "path" rule matches for the given path and all descendant nodes. The draft doesn't seem to be particularly clear on this point (it states that the rule applies >>>> when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified. >>>> >>>> If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read >>>> access had been given. >>>> >>>> But, possibly I'm misunderstanding how this all works! If so, apologies for the noise :-) >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>> On 02/11/2017 14:18, Benoit Claise wrote: >>>>> Dear all, >>>>> >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See >>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>>>> >>>>> >>>>> The NETCONF WG was cc'ed for the entire discussion. >>>>> What do you think? I will draw the conclusions by Friday Nov 10th. >>>>> >>>>> Note: If the WG is fine, the next step is to approve this document. >>>>> >>>>> Regards, Benoit >>>>> >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> Mahesh Jethanandani >> mjethanandani@gmail.com > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Nov 10 07:49:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A386E126DFB for ; Fri, 10 Nov 2017 07:49:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 0YyONIIsCKZc for ; Fri, 10 Nov 2017 07:49:13 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49474126C3D for ; Fri, 10 Nov 2017 07:49:13 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id l23so11556148lfk.10 for ; Fri, 10 Nov 2017 07:49:13 -0800 (PST) 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=xqM8psankgKy4WIqgv+kYIr96IbL931sNKzOxXuDSYk=; b=tZnqD/A8GYzOE+GoiXivo4/XTisfil6nZO54sxpbLSssDSkDltfjsQaSDPdISkZ/93 tTEiCJt3MO3YQ8wwW1E9v4ZgXnSgfJK7em+L8e2N2u7PDBxObjC2DeCc5qcaC3I4/8wZ 7Vu4HS5QKYNd5UVsUZ0tIcJRpVwovjkVc6+l3v0UyJt7rnS2v2H0jrq/voAtWLUIkQor 1mXyje16CYPeYmrNlcowSkoEDECHWBiE0PU9Sg2Ivkefu53kIJGaIxNwmdsg/7mzys3P dAMxgWzDO9HZCvyE1qcDK+h2FJr5RXgqFcj6s1TVfDAVSGCiVkJJ8hEHmFPEd1FDAd0d 1PQQ== 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=xqM8psankgKy4WIqgv+kYIr96IbL931sNKzOxXuDSYk=; b=QbykJdB+s7Uz8VCcUq/GTCXXhHW03izXi5mdMClu6fAifn5dMZUNsAxn9LN/L3+7hg 7wPEMMMRK2jPAuvcleyUTbTdMDU1dKP012W1Tqd272EuXiT1l+sDOsTKpCFjIlY+98rZ 3gbHUUhKuwlXKsyPgOVD5145beOOTr7XX7+lXu28UHYIn/LLF+Yh3UmLafesNKWxoG/S VkcuwOSpfubChWEE033PhWv8dKFUjULCYJkMLHVbm9k+57kwAcj73hXnxONwfBqfe+8W zZs47kjeLzL3WoFYONdl6iuj3WJJwwgYSeX/rRIJMhP7mWaaNWL9xU/Vbmxf8Y0I61XC Os0Q== X-Gm-Message-State: AJaThX73TCVoP3soTOySuaZUvuRdtwgK8zMHjnDv8afCeTBWPOmYGEk8 83utI0plq+hSAMZv9mEwdYmMNR+xuKEBPi2c652gEw== X-Google-Smtp-Source: AGs4zMYkLHUqXSirYeDbUX1CDMHwawB84K+rAeH36h2jpTGz2Hz5yFxz4PKEvdezaVT0ZFuO3Yfq+4L4Lijin9TAY/8= X-Received: by 10.46.93.75 with SMTP id r72mr305965ljb.182.1510328951373; Fri, 10 Nov 2017 07:49:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Fri, 10 Nov 2017 07:49:10 -0800 (PST) In-Reply-To: <5A05A4A4.3000304@tail-f.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> From: Andy Bierman Date: Fri, 10 Nov 2017 07:49:10 -0800 Message-ID: To: Per Hedeland Cc: Robert Wilton , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a114b72f4a41ef3055da2dc6c" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 15:49:19 -0000 --001a114b72f4a41ef3055da2dc6c Content-Type: text/plain; charset="UTF-8" On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland wrote: > On 2017-11-10 11:42, Robert Wilton wrote: > > > > > > On 10/11/2017 10:02, Mahesh Jethanandani wrote: > >> > >> > >> > >> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > >> On Nov 10, 2017, at 10:07 AM, Andy Bierman andy@yumaworks.com>> wrote: > >> > >>> Hi, > >>> > >>> The term "data node" is used in the document to refer to the top-level > node > >>> of the specified object, not the entire subtree (if any). > >>> > >>> The data-rule /foo does not match /foo/child1 in the text below. > >>> The child nodes are omitted because of step 11. > >>> The admin has to explicitly permit individual child nodes (or modules). > >>> This seems correct if the read-default is "deny". > >>> > >>> Should any text be added or changed to make this more clear? > >> > >> I would agree with Robert that it was not entirely clear that rule > applied on the parent data-node does not apply to the child nodes. So yes, > it would help to clarify it. > > We should be doing more than clarifying it. We need to fix it so that > it works in a sensible way. I.e. to make the normative text consistent > with the behaviour currently described in the examples in > > the appendix B.4. > > > > If we follow Andy's interpretation that a data rule doesn't match child > nodes then those examples are completely wrong. E.g. the 4th rule is > described as "This rule gives the 'admin' group read-write > > access to all acme entries." But If the path only strictly > matches "/acme:interfaces/acme:interface" then the admin group rule > achieves nothing useful at all. The admin is not even > > allowed to create an interface because they would not even have > permission to write to the list key 'name' node required to create a list > entry! Instead, a separate rule would be required for every > > single possible schema node under "/acme:interfaces/acme:interface"! I > think that this makes "permit" data-node rules completely unusable. > > I strongly agree with this, and I would say that it isn't only the case > for "permit" rules - e.g. denying some access to a subtree of the data > model that would otherwise be permitted due to defaults is at least as > common, and the rules would be just as unusable for that. > > Besides the examples, I think that the very use of the term "match", > though unfortunately not defined, strongly suggests that it is something > other than use of e.g. the term "identify" would imply. Additionally, > this text in the description of the 'path' leaf is consistent with the > match being a prefix match: > > The special value '/' refers to all possible > datastore contents."; > > FWIW, our NACM implementation, available to (and used by) customers > since 2012, follows the prefix match logic, and I have yet to hear of > any user expecting it to do otherwise. > > > To fix this properly, we need to make the data-node path rule a prefix > match. In particular, we need text that specifies: > > > > (i) that a data-node path match succeeds if it matches the path prefix > from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and > all of foo's descendant children nodes. > > Strongly agree. > > I do not see how the text can be interpreted this way. There is nothing that says this is how it works. If it did, once could never have privileged sub-fiolders /var/log -> permit /var/log/apache2 -> deny > > (ii) if a data-node rule has action "permit" then it implicitly allows > read access for all ancestor parent nodes up to the root. (I.e. to > mitigate the original change proposed on this thread.) > > This seems reasonable to me, although I haven't at this point evaluated > the suggestion in detail. In any case I think the main point both > regarding this and the prefix match is that this update to 6536 can't > make radical changes to the semantics compared to a "reasonable > interpretation" (hard to define, I know) of the under-specified > original. > The text does not say this at all so I do not approve of this change > > --Per > > Andy > > Thanks, > > Rob > > > > > >> > >> Thanks > >> > >>> > >>> > >>> Andy > >>> > >>> > >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton > wrote: > >>> > >>> Hi Andy, > >>> > >>> It isn't clear to me whether matching a path in NACM either: > >>> (i) Only applies to the specific node, and not any children, or > >>> (ii) Applies to the specific node and all descendant children > nodes as well. > >>> > >>> As an example, using the tree below. if I have a rule that > matches path "A/B" then does that apply to only the specific node "A/B", or > does it also apply to all descendant children of "A/B" as > >>> well? > >>> > >>> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", > step 6 states: > >>> > >>> * The rule does not have a "rule-type" defined or the > "rule- > >>> type" is "data-node" and the *"path" matches the > requested data node*, action node, or notification node. > >>> > >>> > >>> My reading of this is that it implies that the interpretation of > the path rule is (i), but this is not how I would normally expect an ACL > rule to apply in a tree like object (e.g a directory > >>> file system). > >>> > >>> However, the examples in Appendix B.4. imply that the path rule is > to be interpreted like (ii), or otherwise the example rules seem to be > mostly pointless. > >>> > >>> E.g. taking this example from appendix B.4: > >>> > >>> > >>> permit-dummy-interface > >>> http://example.com/ns/itf>> > >>> /acme:interfaces/acme:interface[acme:name='dummy'] > >>> > >>> read update > >>> permit > >>> > >>> Allow the limited and guest groups read > >>> and update access to the dummy interface. > >>> > >>> > >>> > >>> > >>> If the rule is (i) then the access rule allows the client to read > the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" > but not any child leafs/containers of that interface, > >>> this doesn't seem useful. > >>> > >>> Further comments inline below ... > >>> > >>> On 08/11/2017 20:05, Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> This change has no impact on the server if /nacm/read-default is > "permit". > >>>> In that case, the extra read rules for /A and /A/B are not needed. > >>> I agree. > >>> > >>>> An operator worried about read access should set read-default to > "deny". > >>> I agree. This is the scenario that I'm considering. > >>> > >>>> In that case, explicit rules to read /A and /A/B would be needed > >>>> in the new NACM. > >>> Yes, if the interpretation of the rule is (i) above. > >>> Otherwise if the interpretation is (ii) then you only need "read > /A" since that implies "read A/B" as well (as long as the rules are listed > in the correct order). > >>> > >>> > >>>> The deny rules would not be needed. > >>> Only if the interpretation of the rule is (i) above. In which > case the "read/write 'A/B/J' rule would not be sufficient. It would be > necessary to define an Xpath expressions that contains > >>> all children nodes as well. Perhaps 'A/B/J//*'? > >>> > >>> If the interpretation of the rule is (ii) then you would also need > all the explicit deny statements as well, otherwise they would be allowed > by the "read /A" rule above. > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >>>> > >>>> > >>>> Andy > >>>> > >>>> > >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton > wrote: > >>>> > >>>> Hi, > >>>> > >>>> I'm not sure about this change. > >>>> > >>>> I'm not that familiar with NACM, but if you want to give a > particular set of users read/write access to a subtree, but not allow them > to have any other access to the configuration in the > >>>> running datastore then with the existing RFC, that could be > expressed with a single rule (example in 6536bis, appendix B.4) > >>>> > >>>> With this new change, I think that you may need to configure > many more rules to achieve the same thing. I think that you would need to > give read access to the top node in the desired > >>>> path, and then separate explicit "deny" rules for every > sibling child node walking from the top of the tree down to the data node > that read/write access is actually being given to. The > >>>> example below may explain my understanding better: > >>>> > >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to > give read/write access only to "J" subtree, and no access for the rest of > the tree then: > >>>> > >>>> A > >>>> | > >>>> -------------------- > >>>> | | | | > >>>> B C D E > >>>> | > >>>> ----------- > >>>> | | | | > >>>> F G H J > >>>> | > >>>> ... > >>>> > >>>> > >>>> In the old model, I think that the ACL rules would be 1 rules > long (assuming default deny all): > >>>> "read/write 'A/B/J' > >>>> > >>>> In the new model, I think that the equivalent ACL rules would > need to be 8 rules long (assuming default deny all): > >>>> "read/write 'A/B/J' > >>>> "read A" > >>>> "deny C" > >>>> "deny D" > >>>> "deny E" > >>>> "deny F" > >>>> "deny G" > >>>> "deny H" > >>>> > >>>> Note, I am assuming that a "path" rule matches for the given > path and all descendant nodes. The draft doesn't seem to be particularly > clear on this point (it states that the rule applies > >>>> when the path matches, but this would seem to be counter > intuitive), and perhaps it could be clarified. > >>>> > >>>> If this change is allowed, then the example in appendix B.4 > looks like it would need to be fixed, since the "limited-acl" probably > wouldn't give any access at all, unless default read > >>>> access had been given. > >>>> > >>>> But, possibly I'm misunderstanding how this all works! If > so, apologies for the noise :-) > >>>> > >>>> Thanks, > >>>> Rob > >>>> > >>>> > >>>> On 02/11/2017 14:18, Benoit Claise wrote: > >>>>> Dear all, > >>>>> > >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, > suggested by the Security AD Eric Rescola part of the IESG review, which I > would like to validate with the WG. See > >>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf- > netconf-rfc6536bis-08.txt netconf-rfc6536bis-08.txt> > >>>>> > >>>>> > >>>>> The NETCONF WG was cc'ed for the entire discussion. > >>>>> What do you think? I will draw the conclusions by Friday Nov > 10th. > >>>>> > >>>>> Note: If the WG is fine, the next step is to approve this > document. > >>>>> > >>>>> Regards, Benoit > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Netconf mailing list > >>>>> Netconf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netconf < > https://www.ietf.org/mailman/listinfo/netconf> > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > --001a114b72f4a41ef3055da2dc6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
On 2017-11-10 11:42, Robert Wi= lton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com= <mailto:mjethanandani@gm= ail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is used in the document to refe= r to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text belo= w.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or = modules).
>>> This seems correct if the read-default is "deny". >>>
>>> Should any text be added or changed to make this more clear? >>
>> I would agree with Robert that it was not entirely clear that rule= applied on the parent data-node does not apply to the child nodes. So yes,= it would help to clarify it.
> We should be doing more than clarifying it.=C2=A0 We need to fix it so= that it works in a sensible way.=C2=A0 I.e. to make the normative text con= sistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that a data rule doesn't ma= tch child nodes then those examples are completely wrong.=C2=A0 E.g. the 4t= h rule is described as "This rule gives the 'admin' group read= -write
> access to all acme <interface> entries."=C2=A0 But If the p= ath only strictly matches "/acme:interfaces/acme:interface" = then the admin group rule achieves nothing useful at all.=C2=A0 The admin i= s not even
> allowed to create an interface because they would not even have permis= sion to write to the list key 'name' node required to create a list= entry!=C2=A0 Instead, a separate rule would be required for every
> single possible schema node under "/acme:interfaces/acme:int= erface"!=C2=A0 I think that this makes "permit" data-node ru= les completely unusable.

I strongly agree with this, and I would say that it isn't only the case=
for "permit" rules - e.g. denying some access to a subtree of the= data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match&quo= t;,
though unfortunately not defined, strongly suggests that it is something other than use of e.g. the term "identify" would imply. Additiona= lly,
this text in the description of the 'path' leaf is consistent with = the
match being a prefix match:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The special value '/' refers to all poss= ible
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix= match.=C2=A0 In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix= from the root of the tree.=C2=A0 I.e. so the data-rule "/foo" ma= tches "/foo" and all of foo's descendant children nodes.

Strongly agree.



I do not see how the te= xt can be interpreted this way.
There is nothing that says this i= s how it works.
If it did, once could never have privileged sub-f= iolders

=C2=A0 =C2=A0 =C2=A0/var/log -> permit<= /div>
=C2=A0 =C2=A0 =C2=A0/var/log/apache2 =C2=A0-> deny
<= br>
=C2=A0
> (ii) if a data-node rule has action "permit" then it implici= tly allows read access for all ancestor parent nodes up to the root.=C2=A0 = (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated=
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at= all so I do not approve of this change

=C2=A0

--Per



Andy
=C2=A0
> Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0Hi Andy,
>>>
>>>=C2=A0 =C2=A0 =C2=A0It isn't clear to me whether matching a= path in NACM either:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(i) Only applies to the specific nod= e, and not any children, or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(ii) Applies to the specific node an= d all descendant children nodes as well.
>>>
>>>=C2=A0 =C2=A0 =C2=A0As an example, using the tree below.=C2=A0 = if I have a rule that matches path "A/B" then does that apply to = only the specific node "A/B", or does it also apply to all descen= dant children of "A/B" as
>>>=C2=A0 =C2=A0 =C2=A0well?
>>>
>>>=C2=A0 =C2=A0 =C2=A0In rfc6536bis-08, section "3.4.5.=C2= =A0 Data Node Access Validation", step 6 states:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 The rul= e does not have a "rule-type" defined or the "rule-
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type&qu= ot; is "data-node" and the *"path" matches the requeste= d data node*, action node, or notification node.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0My reading of this is that it implies that = the interpretation of the path rule is (i), but this is not how I would nor= mally expect an ACL rule to apply in a tree like object (e.g a directory >>>=C2=A0 =C2=A0 =C2=A0file system).
>>>
>>>=C2=A0 =C2=A0 =C2=A0However, the examples in Appendix B.4. impl= y that the path rule is to be interpreted like (ii), or otherwise the examp= le rules seem to be mostly pointless.
>>>
>>>=C2=A0 =C2=A0 =C2=A0E.g. taking this example from appendix B.4:=
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rule>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>pe= rmit-dummy-interface</name>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <path xmlns= :acme=3D"http://example.com/ns/itf" <http://example.c= om/ns/itf>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /acme:i= nterfaces/acme:interface[acme:name=3D'dummy']
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </path><= br> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <access-ope= rations>read update</access-operations>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <action>= permit</action>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <comment>= ;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow t= he limited and guest groups read
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and upd= ate access to the dummy interface.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </comment&g= t;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </rule>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the rule is (i)=C2=A0 then the access ru= le allows the client to read the specific node "/acme:interfaces/acme:= interface[acme:name=3D'dummy']" but not any child leafs/c= ontainers of that interface,
>>>=C2=A0 =C2=A0 =C2=A0this doesn't seem useful.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Further comments inline below ...
>>>
>>>=C2=A0 =C2=A0 =C2=A0On 08/11/2017 20:05, Andy Bierman wrote: >>>>=C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0This change has no impact on the server= if /nacm/read-default is "permit".
>>>>=C2=A0 =C2=A0 =C2=A0In that case, the extra read rules for = /A and /A/B are not needed.
>>>=C2=A0 =C2=A0 =C2=A0I agree.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0An operator worried about read access s= hould set read-default to "deny".
>>>=C2=A0 =C2=A0 =C2=A0I agree.=C2=A0 This is the scenario that I&= #39;m considering.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0In that case, explicit rules to read /A= and /A/B would be needed
>>>>=C2=A0 =C2=A0 =C2=A0in the new NACM.
>>>=C2=A0 =C2=A0 =C2=A0Yes, if the interpretation of the rule is (= i) above.
>>>=C2=A0 =C2=A0 =C2=A0Otherwise if the interpretation is (ii) the= n you only need "read /A" since that implies "read A/B"= as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The deny rules would not be need= ed.
>>>=C2=A0 =C2=A0 =C2=A0Only if the interpretation of the rule is (= i) above.=C2=A0 In which case the=C2=A0 "read/write 'A/B/J' ru= le would not be sufficient.=C2=A0 It would be necessary to define an Xpath = expressions that contains
>>>=C2=A0 =C2=A0 =C2=A0all children nodes as well.=C2=A0 Perhaps &= #39;A/B/J//*'?
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the interpretation of the rule is (ii) t= hen you would also need all the explicit deny statements as well, otherwise= they would be allowed by the "read /A" rule above.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Rob
>>>
>>>
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Andy
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On Wed, Nov 8, 2017 at 8:33 AM, Robert = Wilton <rwilton@cisco.com <m= ailto:rwilton@cisco.com>> wr= ote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not sure about th= is change.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not that familiar= with NACM, but if you want to give a particular set of users read/write ac= cess to a subtree, but not allow them to have any other access to the confi= guration in the
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0running datastore then wi= th the existing RFC, that could be expressed with a single rule (example in= 6536bis, appendix B.4)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0With this new change, I t= hink that you may need to configure many more rules to achieve the same thi= ng.=C2=A0 I think that you would need to give read access to the top node i= n the desired
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path, and then separate e= xplicit "deny" rules for every sibling child node walking from th= e top of the tree down to the data node that read/write access is actually = being given to.=C2=A0 The
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example below may explain= my understanding better:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E.g. For a tree of data n= odes, rooted at A, if we wanted to give read/write access only to "J&q= uot; subtree, and no access for the rest of the tree then:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0--------------------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0B=C2=A0 =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=A0 =C2=A0 =C2=A0E
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|= =C2=A0 |=C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F=C2=A0 =C2=A0G= =C2=A0 H=C2=A0 J
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0...
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the old model, I think= that the ACL rules would be 1 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read/write = 'A/B/J'
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the new model, I think= that the equivalent ACL rules would need to be 8 rules long (assuming defa= ult deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read/write = 'A/B/J'
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read A"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny C"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny D"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny E"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny F"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny G"= ;
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deny H"= ;
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note, I am assuming that = a "path" rule matches for the given path and all descendant nodes= .=C2=A0 The draft doesn't seem to be particularly clear on this point (= it states that the rule applies
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when the path matches, bu= t this would seem to be counter intuitive), and perhaps it could be clarifi= ed.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If this change is allowed= , then the example in appendix B.4 looks like it would need to be fixed, si= nce the "limited-acl" probably wouldn't give any access at al= l, unless default read
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access had been given. >>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But, possibly I'm mis= understanding how this all works!=C2=A0 If so, apologies for the noise :-)<= br> >>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rob
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 02/11/2017 14:18, Beno= it Claise wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear all,
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here is a major chang= e in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Resco= la part of the IESG review, which I would like to validate with the WG. See=
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-<= wbr>netconf-rfc6536bis-08.txt>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dfpcfioondggippe.= png>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The NETCONF WG was cc= 'ed for the entire discussion.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What do you think? I = will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note: If the WG is fi= ne, the next step is to approve this document.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards, Benoit
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________= __________________________
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netconf mailing list<= br> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org <m= ailto:Netconf@ietf.org>
>>> https://www.ietf.org/mailman/listinf= o/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com= <mailto:mjethanandani@gm= ail.com>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf=
>


--001a114b72f4a41ef3055da2dc6c-- From nobody Fri Nov 10 08:16:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE15126DFB; Fri, 10 Nov 2017 08:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 2HT1bQW62N5B; Fri, 10 Nov 2017 08:16:34 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EA2126BF6; Fri, 10 Nov 2017 08:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44634; q=dns/txt; s=iport; t=1510330593; x=1511540193; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=QKs2iMxPPmbVvfJe1qRbL0jXoRF9HoK0kPN9B1ARL9w=; b=XI7IJcYAFSY88IOWeCqjT/eHzRkVOvQfcJLz9SPACiOddx7XIZdoR53F kHTkaNaGPMPwJP3LYUNz+WCgloa6RNH5pSrR87XUsyt7cE3bpe+qUMjWq 7ubgYXd//8FrjICd1+0p+TM7GIUlvBSXKVRmYDbShGUkUJ8TpFydWIsve 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAADDzwVa/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDB4ESbieDfoofdJAziFeFEohnEIF+AwoYAQyBN4IBgQ9PAoU?= =?us-ascii?q?FGAEBAQEBAQEBAWsohR4BAQEBAgEBARgJBEcLBQsJAhggAQYDAgIhBh8RBgEMB?= =?us-ascii?q?gIBAReJbwMNCBCMA51ogW06JocVDYNIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYM?= =?us-ascii?q?0g1uBaSmDAYJrWYEMDwQJBBGDK4JjAQSKIAqHO4FuhTuIVj2HaYNohDaEeYIVX?= =?us-ascii?q?4kIJIcgijGCNzqBEIdwgTkfOIFyNCEIHRVJgmQJgho5HBmBTkE2AYl8AiUHghY?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.44,375,1505779200"; d="scan'208,217";a="133767" 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; 10 Nov 2017 16:16:30 +0000 Received: from [10.61.246.69] ([10.61.246.69]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAAGGUel026341; Fri, 10 Nov 2017 16:16:30 GMT To: Andy Bierman , Per Hedeland Cc: Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> From: Robert Wilton Message-ID: <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> Date: Fri, 10 Nov 2017 16:16:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------072FADE82EF4B3A4C694FFE0" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:16:37 -0000 This is a multi-part message in MIME format. --------------072FADE82EF4B3A4C694FFE0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/11/2017 15:49, Andy Bierman wrote: > > > On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland > wrote: > > On 2017-11-10 11:42, Robert Wilton wrote: > > > > > > On 10/11/2017 10:02, Mahesh Jethanandani wrote: > >> > >> > >> > >> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > > > >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >> wrote: > >> > >>> Hi, > >>> > >>> The term "data node" is used in the document to refer to the > top-level node > >>> of the specified object, not the entire subtree (if any). > >>> > >>> The data-rule /foo does not match /foo/child1 in the text below. > >>> The child nodes are omitted because of step 11. > >>> The admin has to explicitly permit individual child nodes (or > modules). > >>> This seems correct if the read-default is "deny". > >>> > >>> Should any text be added or changed to make this more clear? > >> > >> I would agree with Robert that it was not entirely clear that > rule applied on the parent data-node does not apply to the child > nodes. So yes, it would help to clarify it. > > We should be doing more than clarifying it.  We need to fix it > so that it works in a sensible way.  I.e. to make the normative > text consistent with the behaviour currently described in the > examples in > > the appendix B.4. > > > > If we follow Andy's interpretation that a data rule doesn't > match child nodes then those examples are completely wrong.  E.g. > the 4th rule is described as "This rule gives the 'admin' group > read-write > > access to all acme entries."  But If the path only > strictly matches "/acme:interfaces/acme:interface" then the admin > group rule achieves nothing useful at all. The admin is not even > > allowed to create an interface because they would not even have > permission to write to the list key 'name' node required to create > a list entry!  Instead, a separate rule would be required for every > > single possible schema node under > "/acme:interfaces/acme:interface"!  I think that this makes > "permit" data-node rules completely unusable. > > I strongly agree with this, and I would say that it isn't only the > case > for "permit" rules - e.g. denying some access to a subtree of the data > model that would otherwise be permitted due to defaults is at least as > common, and the rules would be just as unusable for that. > > Besides the examples, I think that the very use of the term "match", > though unfortunately not defined, strongly suggests that it is > something > other than use of e.g. the term "identify" would imply. Additionally, > this text in the description of the 'path' leaf is consistent with the > match being a prefix match: > >        The special value '/' refers to all possible >        datastore contents."; > > FWIW, our NACM implementation, available to (and used by) customers > since 2012, follows the prefix match logic, and I have yet to hear of > any user expecting it to do otherwise. > > > To fix this properly, we need to make the data-node path rule a > prefix match.  In particular, we need text that specifies: > > > > (i) that a data-node path match succeeds if it matches the path > prefix from the root of the tree.  I.e. so the data-rule "/foo" > matches "/foo" and all of foo's descendant children nodes. > > Strongly agree. > > > > I do not see how the text can be interpreted this way. Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.  The only way those examples make sense is the paths match descendant children nodes as well. > There is nothing that says this is how it works. > If it did, once could never have privileged sub-fiolders > >      /var/log -> permit >      /var/log/apache2  -> deny Yes, you can, you just list the longest path first in the list of rules:  (1)  /var/log/apache2  -> deny   (2) /var/log -> permit Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied. Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted. > > > > (ii) if a data-node rule has action "permit" then it implicitly > allows read access for all ancestor parent nodes up to the root.  > (I.e. to mitigate the original change proposed on this thread.) > > This seems reasonable to me, although I haven't at this point > evaluated > the suggestion in detail. In any case I think the main point both > regarding this and the prefix match is that this update to 6536 can't > make radical changes to the semantics compared to a "reasonable > interpretation" (hard to define, I know) of the under-specified > original. > > > The text does not say this at all so I do not approve of this change In the RFC version of the NACM this wasn't required because operation 'none' didn't require read access.  Now read access is required even for operation 'none', then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole. Thanks, Rob > > > --Per > > > > Andy > > > Thanks, > > Rob > > > > > >> > >> Thanks > >> > >>> > >>> > >>> Andy > >>> > >>> > >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton > > >> wrote: > >>> > >>>     Hi Andy, > >>> > >>>     It isn't clear to me whether matching a path in NACM either: > >>>       (i) Only applies to the specific node, and not any > children, or > >>>       (ii) Applies to the specific node and all descendant > children nodes as well. > >>> > >>>     As an example, using the tree below.  if I have a rule > that matches path "A/B" then does that apply to only the specific > node "A/B", or does it also apply to all descendant children of > "A/B" as > >>>     well? > >>> > >>>     In rfc6536bis-08, section "3.4.5.  Data Node Access > Validation", step 6 states: > >>> > >>>             *  The rule does not have a "rule-type" defined or > the "rule- > >>>                type" is "data-node" and the *"path" matches > the requested data node*, action node, or notification node. > >>> > >>> > >>>     My reading of this is that it implies that the > interpretation of the path rule is (i), but this is not how I > would normally expect an ACL rule to apply in a tree like object > (e.g a directory > >>>     file system). > >>> > >>>     However, the examples in Appendix B.4. imply that the path > rule is to be interpreted like (ii), or otherwise the example > rules seem to be mostly pointless. > >>> > >>>     E.g. taking this example from appendix B.4: > >>> > >>>            > >>> permit-dummy-interface > >>>              > > >>>                /acme:interfaces/acme:interface[acme:name='dummy'] > >>>              > >>>              read update > >>> permit > >>>              > >>>                Allow the limited and guest groups read > >>>                and update access to the dummy interface. > >>>              > >>>            > >>> > >>> > >>>     If the rule is (i)  then the access rule allows the client > to read the specific node > "/acme:interfaces/acme:interface[acme:name='dummy']" but not any > child leafs/containers of that interface, > >>>     this doesn't seem useful. > >>> > >>>     Further comments inline below ... > >>> > >>>     On 08/11/2017 20:05, Andy Bierman wrote: > >>>>     Hi, > >>>> > >>>>     This change has no impact on the server if > /nacm/read-default is "permit". > >>>>     In that case, the extra read rules for /A and /A/B are > not needed. > >>>     I agree. > >>> > >>>>     An operator worried about read access should set > read-default to "deny". > >>>     I agree.  This is the scenario that I'm considering. > >>> > >>>>     In that case, explicit rules to read /A and /A/B would be > needed > >>>>     in the new NACM. > >>>     Yes, if the interpretation of the rule is (i) above. > >>>     Otherwise if the interpretation is (ii) then you only need > "read /A" since that implies "read A/B" as well (as long as the > rules are listed in the correct order). > >>> > >>> > >>>>       The deny rules would not be needed. > >>>     Only if the interpretation of the rule is (i) above.  In > which case the  "read/write 'A/B/J' rule would not be sufficient.  > It would be necessary to define an Xpath expressions that contains > >>>     all children nodes as well.  Perhaps 'A/B/J//*'? > >>> > >>>     If the interpretation of the rule is (ii) then you would > also need all the explicit deny statements as well, otherwise they > would be allowed by the "read /A" rule above. > >>> > >>>     Thanks, > >>>     Rob > >>> > >>> > >>>> > >>>> > >>>>     Andy > >>>> > >>>> > >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton > > >> wrote: > >>>> > >>>>         Hi, > >>>> > >>>>         I'm not sure about this change. > >>>> > >>>>         I'm not that familiar with NACM, but if you want to > give a particular set of users read/write access to a subtree, but > not allow them to have any other access to the configuration in the > >>>>         running datastore then with the existing RFC, that > could be expressed with a single rule (example in 6536bis, > appendix B.4) > >>>> > >>>>         With this new change, I think that you may need to > configure many more rules to achieve the same thing.  I think that > you would need to give read access to the top node in the desired > >>>>         path, and then separate explicit "deny" rules for > every sibling child node walking from the top of the tree down to > the data node that read/write access is actually being given to.  The > >>>>         example below may explain my understanding better: > >>>> > >>>>         E.g. For a tree of data nodes, rooted at A, if we > wanted to give read/write access only to "J" subtree, and no > access for the rest of the tree then: > >>>> > >>>>                          A > >>>>                          | > >>>>                 -------------------- > >>>>                 |      |     |     | > >>>>                 B      C     D     E > >>>>                 | > >>>>            ----------- > >>>>            |   |  |  | > >>>>            F   G  H  J > >>>>                      | > >>>>                     ... > >>>> > >>>> > >>>>         In the old model, I think that the ACL rules would be > 1 rules long (assuming default deny all): > >>>>            "read/write 'A/B/J' > >>>> > >>>>         In the new model, I think that the equivalent ACL > rules would need to be 8 rules long (assuming default deny all): > >>>>            "read/write 'A/B/J' > >>>>            "read A" > >>>>            "deny C" > >>>>            "deny D" > >>>>            "deny E" > >>>>            "deny F" > >>>>            "deny G" > >>>>            "deny H" > >>>> > >>>>         Note, I am assuming that a "path" rule matches for > the given path and all descendant nodes. The draft doesn't seem to > be particularly clear on this point (it states that the rule applies > >>>>         when the path matches, but this would seem to be > counter intuitive), and perhaps it could be clarified. > >>>> > >>>>         If this change is allowed, then the example in > appendix B.4 looks like it would need to be fixed, since the > "limited-acl" probably wouldn't give any access at all, unless > default read > >>>>         access had been given. > >>>> > >>>>         But, possibly I'm misunderstanding how this all > works!  If so, apologies for the noise :-) > >>>> > >>>>         Thanks, > >>>>         Rob > >>>> > >>>> > >>>>         On 02/11/2017 14:18, Benoit Claise wrote: > >>>>>         Dear all, > >>>>> > >>>>>         Here is a major change in > draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric > Rescola part of the IESG review, which I would like to validate > with the WG. See > >>>>> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt > > > > >>>>> > >>>>>          > >>>>>         The NETCONF WG was cc'ed for the entire discussion. > >>>>>         What do you think? I will draw the conclusions by > Friday Nov 10th. > >>>>> > >>>>>         Note: If the WG is fine, the next step is to approve > this document. > >>>>> > >>>>>         Regards, Benoit > >>>>> > >>>>> > >>>>>  _______________________________________________ > >>>>>         Netconf mailing list > >>>>> Netconf@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/netconf > > > > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/netconf > > >> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > --------------072FADE82EF4B3A4C694FFE0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/11/2017 15:49, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
On 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is used in the document to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify" would imply. Additionally,
this text in the description of the 'path' leaf is consistent with the
match being a prefix match:

       The special value '/' refers to all possible
       datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.  The only way those examples make sense is the paths match descendant children nodes as well.

There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

     /var/log -> permit
     /var/log/apache2  -> deny

Yes, you can, you just list the longest path first in the list of rules:

 (1)  /var/log/apache2  -> deny
  (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



 
> (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read access.  Now read access is required even for operation 'none', then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


 

--Per



Andy
 
> Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>     Hi Andy,
>>>
>>>     It isn't clear to me whether matching a path in NACM either:
>>>       (i) Only applies to the specific node, and not any children, or
>>>       (ii) Applies to the specific node and all descendant children nodes as well.
>>>
>>>     As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as
>>>     well?
>>>
>>>     In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states:
>>>
>>>             *  The rule does not have a "rule-type" defined or the "rule-
>>>                type" is "data-node" and the *"path" matches the requested data node*, action node, or notification node.
>>>
>>>
>>>     My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>     file system).
>>>
>>>     However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>     E.g. taking this example from appendix B.4:
>>>
>>>            <rule>
>>>              <name>permit-dummy-interface</name>
>>>              <path xmlns:acme="http://example.com/ns/itf" <http://example.com/ns/itf>>
>>>                /acme:interfaces/acme:interface[acme:name='dummy']
>>>              </path>
>>>              <access-operations>read update</access-operations>
>>>              <action>permit</action>
>>>              <comment>
>>>                Allow the limited and guest groups read
>>>                and update access to the dummy interface.
>>>              </comment>
>>>            </rule>
>>>
>>>
>>>     If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface,
>>>     this doesn't seem useful.
>>>
>>>     Further comments inline below ...
>>>
>>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     This change has no impact on the server if /nacm/read-default is "permit".
>>>>     In that case, the extra read rules for /A and /A/B are not needed.
>>>     I agree.
>>>
>>>>     An operator worried about read access should set read-default to "deny".
>>>     I agree.  This is the scenario that I'm considering.
>>>
>>>>     In that case, explicit rules to read /A and /A/B would be needed
>>>>     in the new NACM.
>>>     Yes, if the interpretation of the rule is (i) above.
>>>     Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>       The deny rules would not be needed.
>>>     Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains
>>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>
>>>     If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>>
>>>>
>>>>     Andy
>>>>
>>>>
>>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         I'm not sure about this change.
>>>>
>>>>         I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>         running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>         With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired
>>>>         path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The
>>>>         example below may explain my understanding better:
>>>>
>>>>         E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:
>>>>
>>>>                          A
>>>>                          |
>>>>                 --------------------
>>>>                 |      |     |     |
>>>>                 B      C     D     E
>>>>                 |
>>>>            -----------
>>>>            |   |  |  |
>>>>            F   G  H  J
>>>>                      |
>>>>                     ...
>>>>
>>>>
>>>>         In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>
>>>>         In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>            "read A"
>>>>            "deny C"
>>>>            "deny D"
>>>>            "deny E"
>>>>            "deny F"
>>>>            "deny G"
>>>>            "deny H"
>>>>
>>>>         Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies
>>>>         when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>>
>>>>         If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read
>>>>         access had been given.
>>>>
>>>>         But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>         Dear all,
>>>>>
>>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>>>>>
>>>>>         <dfpcfioondggippe.png>
>>>>>         The NETCONF WG was cc'ed for the entire discussion.
>>>>>         What do you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>         Note: If the WG is fine, the next step is to approve this document.
>>>>>
>>>>>         Regards, Benoit
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Netconf mailing list
>>>>>         Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>>         https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>



--------------072FADE82EF4B3A4C694FFE0-- From nobody Fri Nov 10 08:33:42 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3210F126CD6 for ; Fri, 10 Nov 2017 08:33:40 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 rsenfFW3yRDi for ; Fri, 10 Nov 2017 08:33:37 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 6F1861243F3 for ; Fri, 10 Nov 2017 08:33:35 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id f134so3386027lfg.8 for ; Fri, 10 Nov 2017 08:33:35 -0800 (PST) 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=YjBqS9wGZV2y9/0UbRTympT4hnozNWp/GPYmyDDz4VM=; b=NEhOAtJACSETFQm1ZHnCfxv+O2cz6B/veIO1Dvv1OgQd75ImisPO4aPddG4ejtIa6s 2D+iyzd1NAr12pJ7ddexWBLCE4GakU1QWKANUdP/H9jib+phi0+l/hDCiaIqyTLQ2hnv SMygz6bBUNeMtq8CR7dF4j72EZJxW2e/flknhAHzTMjcuUk7aWlj1kipWNIJ1hk8kDlz yLFG7hCROCp5VW9+VUOl80grkPvr3H0OiKoCFHi5SAa+6TCaHjxaWPUgdEIIUnPbRoCP 5CP+hjKwq1V7+/P5yOQ+Kap39b7eSJG8LuPAcMAGzPS+Xk+2u846Zt+kMQcy+6iDa6P0 gSCA== 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=YjBqS9wGZV2y9/0UbRTympT4hnozNWp/GPYmyDDz4VM=; b=RlFV5o+Fi6G6mBL8UXRe3rYLHmkw6YdEry/DdxL9uSIgAtvDJoKmKj63TiOeyZlMWQ Uey7GZM9D/pKyjFz1Zn/PSnqR22ANzkYEsxUCs09cBVNjlk4Ql6l/lTtuX67a8rnhSwp l/hld3cEqG1vbe5QcRJ8bg9qRGHqImPBbrbpZDnwJjPuhrq+OZAAxU0sCs0JLpA28msv 0mfB+wdexWdIHxL42ac3UCxfxgXfuXA+jtT3ZJoqyHoC42GwCEcgAD+gkXDUCTId3kr7 elmWZghNGLOwTe4KeWa697SszrwTmljHrFTTL0AxvuV/pldE00+GWgnzwG6ho2MSmntb loEA== X-Gm-Message-State: AJaThX6ytAt723TGuMon1IvKThxo7dMXgM4AJEvSd9Kmrm1jW2sBqyId UeHYNtxFpYbUY2fGDd050WV+N1/4lIefDbLvhpeVXw== X-Google-Smtp-Source: AGs4zMZMwfAYWPqmk+gzjvGaxMt4+ogmBjE+ujEGlzr12Wg/tjqRYOUXgO+LAvXEoMz6SQYEuXVBQYyaTBDFqdYujkY= X-Received: by 10.25.160.211 with SMTP id j202mr298038lfe.218.1510331613605; Fri, 10 Nov 2017 08:33:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Fri, 10 Nov 2017 08:33:31 -0800 (PST) In-Reply-To: <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> From: Andy Bierman Date: Fri, 10 Nov 2017 08:33:31 -0800 Message-ID: To: Robert Wilton Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary="001a1141148052881c055da37b52" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:33:40 -0000 --001a1141148052881c055da37b52 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton wrote: > > > On 10/11/2017 15:49, Andy Bierman wrote: > > > > On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland wrote: > >> On 2017-11-10 11:42, Robert Wilton wrote: >> > >> > >> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >> >> >> >> >> >> >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman > > wrote: >> >> >> >>> Hi, >> >>> >> >>> The term "data node" is used in the document to refer to the >> top-level node >> >>> of the specified object, not the entire subtree (if any). >> >>> >> >>> The data-rule /foo does not match /foo/child1 in the text below. >> >>> The child nodes are omitted because of step 11. >> >>> The admin has to explicitly permit individual child nodes (or >> modules). >> >>> This seems correct if the read-default is "deny". >> >>> >> >>> Should any text be added or changed to make this more clear? >> >> >> >> I would agree with Robert that it was not entirely clear that rule >> applied on the parent data-node does not apply to the child nodes. So yes, >> it would help to clarify it. >> > We should be doing more than clarifying it. We need to fix it so that >> it works in a sensible way. I.e. to make the normative text consistent >> with the behaviour currently described in the examples in >> > the appendix B.4. >> > >> > If we follow Andy's interpretation that a data rule doesn't match child >> nodes then those examples are completely wrong. E.g. the 4th rule is >> described as "This rule gives the 'admin' group read-write >> > access to all acme entries." But If the path only strictly >> matches "/acme:interfaces/acme:interface" then the admin group rule >> achieves nothing useful at all. The admin is not even >> > allowed to create an interface because they would not even have >> permission to write to the list key 'name' node required to create a list >> entry! Instead, a separate rule would be required for every >> > single possible schema node under "/acme:interfaces/acme:interface"! >> I think that this makes "permit" data-node rules completely unusable. >> >> I strongly agree with this, and I would say that it isn't only the case >> for "permit" rules - e.g. denying some access to a subtree of the data >> model that would otherwise be permitted due to defaults is at least as >> common, and the rules would be just as unusable for that. >> >> Besides the examples, I think that the very use of the term "match", >> though unfortunately not defined, strongly suggests that it is something >> other than use of e.g. the term "identify" would imply. Additionally, >> this text in the description of the 'path' leaf is consistent with the >> match being a prefix match: >> >> The special value '/' refers to all possible >> datastore contents."; >> >> FWIW, our NACM implementation, available to (and used by) customers >> since 2012, follows the prefix match logic, and I have yet to hear of >> any user expecting it to do otherwise. >> >> > To fix this properly, we need to make the data-node path rule a prefix >> match. In particular, we need text that specifies: >> > >> > (i) that a data-node path match succeeds if it matches the path prefix >> from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and >> all of foo's descendant children nodes. >> >> Strongly agree. >> >> > > I do not see how the text can be interpreted this way. > > > Because otherwise the path match part of the NACM solution is really > broken, and the path based examples in the appendix are entirely misleading > and wrong. The only way those examples make sense is the paths match > descendant children nodes as well. > > IMO the text does not support this interpretation. There is nothing said about inheriting state from the parent data node. I think no matter how the permissions are derived, one can find examples that work better or worse because of it. IMO the number of rules required to implement a use-case is not very relevant or objective criteria. Using the previous example of /home and /home/user1, if the user1 is given read access to /home, then (according to you) it also has read access to every user subtree under /home. Instead of 1 rule per user, 2 rules are needed read-default=deny group=*, path=/home, action=permit group=user1, path=/home/user1, action=permit The above rules would allow access for every user to every other user. The 2nd rule has no effect, which is counter-intuitive. Every user dir would need 2 rules read-default=deny group=*, path=/home, action=permit group=user1, path=/home/user1, action=permit group=*, path=/home/user1, action=deny There is nothing that says this is how it works. > If it did, once could never have privileged sub-fiolders > > /var/log -> permit > /var/log/apache2 -> deny > > > Yes, you can, you just list the longest path first in the list of rules: > > (1) /var/log/apache2 -> deny > (2) /var/log -> permit > > Any requests that attempt to access anything under /var/log/apache2 would > match rule (1) and be denied. > Any requests that attempt to access anything under /var/log, but not under > /var/log/apache2, would fail to match rule (1), but would match rule (2) > instead and be permitted. > > > I do not see any text in the draft or RFC 7950 that suggests that /var/log and /var/log/apache2 represent the same data node. Andy > > > >> > (ii) if a data-node rule has action "permit" then it implicitly allows >> read access for all ancestor parent nodes up to the root. (I.e. to >> mitigate the original change proposed on this thread.) >> >> This seems reasonable to me, although I haven't at this point evaluated >> the suggestion in detail. In any case I think the main point both >> regarding this and the prefix match is that this update to 6536 can't >> make radical changes to the semantics compared to a "reasonable >> interpretation" (hard to define, I know) of the under-specified >> original. >> > > The text does not say this at all so I do not approve of this change > > > In the RFC version of the NACM this wasn't required because operation > 'none' didn't require read access. Now read access is required even for > operation 'none', then this change makes sense to make the NACM changes > backwards compatible, whilst still closing the security hole. > > Thanks, > Rob > > > > >> >> --Per >> >> > > Andy > > >> > Thanks, >> > Rob >> > >> > >> >> >> >> Thanks >> >> >> >>> >> >>> >> >>> Andy >> >>> >> >>> >> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton > > wrote: >> >>> >> >>> Hi Andy, >> >>> >> >>> It isn't clear to me whether matching a path in NACM either: >> >>> (i) Only applies to the specific node, and not any children, or >> >>> (ii) Applies to the specific node and all descendant children >> nodes as well. >> >>> >> >>> As an example, using the tree below. if I have a rule that >> matches path "A/B" then does that apply to only the specific node "A/B", or >> does it also apply to all descendant children of "A/B" as >> >>> well? >> >>> >> >>> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", >> step 6 states: >> >>> >> >>> * The rule does not have a "rule-type" defined or the >> "rule- >> >>> type" is "data-node" and the *"path" matches the >> requested data node*, action node, or notification node. >> >>> >> >>> >> >>> My reading of this is that it implies that the interpretation of >> the path rule is (i), but this is not how I would normally expect an ACL >> rule to apply in a tree like object (e.g a directory >> >>> file system). >> >>> >> >>> However, the examples in Appendix B.4. imply that the path rule >> is to be interpreted like (ii), or otherwise the example rules seem to be >> mostly pointless. >> >>> >> >>> E.g. taking this example from appendix B.4: >> >>> >> >>> >> >>> permit-dummy-interface >> >>> > http://example.com/ns/itf>> >> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >> >>> >> >>> read update >> >>> permit >> >>> >> >>> Allow the limited and guest groups read >> >>> and update access to the dummy interface. >> >>> >> >>> >> >>> >> >>> >> >>> If the rule is (i) then the access rule allows the client to >> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" >> but not any child leafs/containers of that interface, >> >>> this doesn't seem useful. >> >>> >> >>> Further comments inline below ... >> >>> >> >>> On 08/11/2017 20:05, Andy Bierman wrote: >> >>>> Hi, >> >>>> >> >>>> This change has no impact on the server if /nacm/read-default is >> "permit". >> >>>> In that case, the extra read rules for /A and /A/B are not >> needed. >> >>> I agree. >> >>> >> >>>> An operator worried about read access should set read-default to >> "deny". >> >>> I agree. This is the scenario that I'm considering. >> >>> >> >>>> In that case, explicit rules to read /A and /A/B would be needed >> >>>> in the new NACM. >> >>> Yes, if the interpretation of the rule is (i) above. >> >>> Otherwise if the interpretation is (ii) then you only need "read >> /A" since that implies "read A/B" as well (as long as the rules are listed >> in the correct order). >> >>> >> >>> >> >>>> The deny rules would not be needed. >> >>> Only if the interpretation of the rule is (i) above. In which >> case the "read/write 'A/B/J' rule would not be sufficient. It would be >> necessary to define an Xpath expressions that contains >> >>> all children nodes as well. Perhaps 'A/B/J//*'? >> >>> >> >>> If the interpretation of the rule is (ii) then you would also >> need all the explicit deny statements as well, otherwise they would be >> allowed by the "read /A" rule above. >> >>> >> >>> Thanks, >> >>> Rob >> >>> >> >>> >> >>>> >> >>>> >> >>>> Andy >> >>>> >> >>>> >> >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton > > wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> I'm not sure about this change. >> >>>> >> >>>> I'm not that familiar with NACM, but if you want to give a >> particular set of users read/write access to a subtree, but not allow them >> to have any other access to the configuration in the >> >>>> running datastore then with the existing RFC, that could be >> expressed with a single rule (example in 6536bis, appendix B.4) >> >>>> >> >>>> With this new change, I think that you may need to configure >> many more rules to achieve the same thing. I think that you would need to >> give read access to the top node in the desired >> >>>> path, and then separate explicit "deny" rules for every >> sibling child node walking from the top of the tree down to the data node >> that read/write access is actually being given to. The >> >>>> example below may explain my understanding better: >> >>>> >> >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to >> give read/write access only to "J" subtree, and no access for the rest of >> the tree then: >> >>>> >> >>>> A >> >>>> | >> >>>> -------------------- >> >>>> | | | | >> >>>> B C D E >> >>>> | >> >>>> ----------- >> >>>> | | | | >> >>>> F G H J >> >>>> | >> >>>> ... >> >>>> >> >>>> >> >>>> In the old model, I think that the ACL rules would be 1 >> rules long (assuming default deny all): >> >>>> "read/write 'A/B/J' >> >>>> >> >>>> In the new model, I think that the equivalent ACL rules >> would need to be 8 rules long (assuming default deny all): >> >>>> "read/write 'A/B/J' >> >>>> "read A" >> >>>> "deny C" >> >>>> "deny D" >> >>>> "deny E" >> >>>> "deny F" >> >>>> "deny G" >> >>>> "deny H" >> >>>> >> >>>> Note, I am assuming that a "path" rule matches for the given >> path and all descendant nodes. The draft doesn't seem to be particularly >> clear on this point (it states that the rule applies >> >>>> when the path matches, but this would seem to be counter >> intuitive), and perhaps it could be clarified. >> >>>> >> >>>> If this change is allowed, then the example in appendix B.4 >> looks like it would need to be fixed, since the "limited-acl" probably >> wouldn't give any access at all, unless default read >> >>>> access had been given. >> >>>> >> >>>> But, possibly I'm misunderstanding how this all works! If >> so, apologies for the noise :-) >> >>>> >> >>>> Thanks, >> >>>> Rob >> >>>> >> >>>> >> >>>> On 02/11/2017 14:18, Benoit Claise wrote: >> >>>>> Dear all, >> >>>>> >> >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, >> suggested by the Security AD Eric Rescola part of the IESG review, which I >> would like to validate with the WG. See >> >>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf- >> rfc6536bis-08.txt > f?url2=draft-ietf-netconf-rfc6536bis-08.txt> >> >>>>> >> >>>>> >> >>>>> The NETCONF WG was cc'ed for the entire discussion. >> >>>>> What do you think? I will draw the conclusions by Friday >> Nov 10th. >> >>>>> >> >>>>> Note: If the WG is fine, the next step is to approve this >> document. >> >>>>> >> >>>>> Regards, Benoit >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Netconf mailing list >> >>>>> Netconf@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >>>> >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Netconf mailing list >> >>> Netconf@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> > >> >> > > --001a1141148052881c055da37b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 10/11/201= 7 15:49, Andy Bierman wrote:
=20


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
On 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is used in the do= cument to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.=C2=A0 We nee= d to fix it so that it works in a sensible way.=C2=A0 I.e. to make the normative text consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.=C2=A0 E.g. the 4th rule is described as &qu= ot;This rule gives the 'admin' group read-write
> access to all acme <interface> entries."=C2= =A0 But If the path only strictly matches "/acme:interfaces/acme= :interface" then the admin group rule achieves nothing useful at all.=C2= =A0 The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' = node required to create a list entry!=C2=A0 Instead, a separate ru= le would be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!=C2=A0 I thi= nk that this makes "permit" data-node rules completely unusable.=

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some access to a = subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify" would im= ply. Additionally,
this text in the description of the 'path' leaf is consistent with the
match being a prefix match:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The special value '/' refe= rs to all possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.=C2=A0 In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.=C2=A0 I.e. so the data-rule "/foo" matches "/foo" an= d all of foo's descendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.=C2=A0 The only way those examples make sense is t= he paths match descendant children nodes as well.



IMO the text = does not support this interpretation.
There is nothing said about= inheriting state from the parent data node.
I think no matter ho= w the permissions are derived, one can
find examples that work be= tter or worse because of it.
IMO the number of rules required to = implement a use-case is not
very relevant or objective criteria.<= /div>

Using the previous example of /home and /home/user= 1,
if the user1 is given read access to /home, then (according to= you)
it also has read access to every user subtree under /home.<= /div>
Instead of 1 rule per user, 2 rules are needed

=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, p= ath=3D/home, action=3Dpermit
=C2=A0 =C2=A0group=3Duser1, path=3D/= home/user1, action=3Dpermit

The above rules would = allow access for every user to every other user.
The 2nd rule has= no effect, which is counter-intuitive.
Every user dir would need= 2 rules

=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dpermit
=C2= =A0 =C2=A0group=3Duser1, path=3D/home/user1, action=3Dpermit
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, action=3Ddeny
<= br>
There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

=C2=A0 =C2=A0 =C2=A0/var/log -> permit
=C2=A0 =C2=A0 =C2=A0/var/log/apache2 =C2=A0-> deny

Yes, you can, you just list the longest path first in the list of rules:

=C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> deny
=C2=A0 (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



I do not see any text in the= draft or RFC 7950 that
suggests that /var/log and /var/log/apach= e2 represent the same data node.


An= dy

=C2=A0

=C2=A0
> (ii) if a data-node rule has action "permit" t= hen it implicitly allows read access for all ancestor parent nodes up to the root.=C2=A0 (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read access.=C2=A0 Now read= access is required even for operation 'none', then this change makes sens= e to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


=C2=A0

--Per



Andy
=C2=A0
> Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rw= ilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0Hi Andy,
>>>
>>>=C2=A0 =C2=A0 =C2=A0It isn't clear to me whet= her matching a path in NACM either:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(i) Only applies to th= e specific node, and not any children, or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(ii) Applies to the sp= ecific node and all descendant children nodes as well.
>>>
>>>=C2=A0 =C2=A0 =C2=A0As an example, using the tree= below.=C2=A0 if I have a rule that matches path "A/B" then does tha= t apply to only the specific node "A/B", or does it also ap= ply to all descendant children of "A/B" as
>>>=C2=A0 =C2=A0 =C2=A0well?
>>>
>>>=C2=A0 =C2=A0 =C2=A0In rfc6536bis-08, section &qu= ot;3.4.5.=C2=A0 Data Node Access Validation", step 6 states:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*= =C2=A0 The rule does not have a "rule-type" defined or the "rule-
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 type" is "data-node" and the *"path" matches the requested data node*, action no= de, or notification node.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0My reading of this is that it= implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>=C2=A0 =C2=A0 =C2=A0file system).
>>>
>>>=C2=A0 =C2=A0 =C2=A0However, the examples in Appe= ndix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>=C2=A0 =C2=A0 =C2=A0E.g. taking this example from= appendix B.4:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rul= e>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>permit-dummy-interface</name>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <path xmlns:acme=3D"http://example.com/ns/itf" <http://example.com/ns/itf>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 /acme:interfaces/acme:interface[acme:name=3D'dummy'] >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = </path>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <access-operations>read update</access-operations>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <action>permit</action>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = <comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Allow the limited and guest groups read
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 and update access to the dummy interface.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = </comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </ru= le>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the rule is (i)=C2=A0 then= the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name=3D'd= ummy']" but not any child leafs/containers of that interface,
>>>=C2=A0 =C2=A0 =C2=A0this doesn't seem useful.=
>>>
>>>=C2=A0 =C2=A0 =C2=A0Further comments inline below= ...
>>>
>>>=C2=A0 =C2=A0 =C2=A0On 08/11/2017 20:05, Andy Bie= rman wrote:
>>>>=C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0This change has no impact= on the server if /nacm/read-default is "permit".
>>>>=C2=A0 =C2=A0 =C2=A0In that case, the extra r= ead rules for /A and /A/B are not needed.
>>>=C2=A0 =C2=A0 =C2=A0I agree.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0An operator worried about= read access should set read-default to "deny".
>>>=C2=A0 =C2=A0 =C2=A0I agree.=C2=A0 This is the sc= enario that I'm considering.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0In that case, explicit ru= les to read /A and /A/B would be needed
>>>>=C2=A0 =C2=A0 =C2=A0in the new NACM.
>>>=C2=A0 =C2=A0 =C2=A0Yes, if the interpretation of= the rule is (i) above.
>>>=C2=A0 =C2=A0 =C2=A0Otherwise if the interpretati= on is (ii) then you only need "read /A" since that implies &qu= ot;read A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The deny rules wou= ld not be needed.
>>>=C2=A0 =C2=A0 =C2=A0Only if the interpretation of= the rule is (i) above.=C2=A0 In which case the=C2=A0 "read/write = 9;A/B/J' rule would not be sufficient.=C2=A0 It would be necessary to defin= e an Xpath expressions that contains
>>>=C2=A0 =C2=A0 =C2=A0all children nodes as well.= =C2=A0 Perhaps 'A/B/J//*'?
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the interpretation of the = rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A= " rule above.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Rob
>>>
>>>
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Andy
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On Wed, Nov 8, 2017 at 8:= 33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not= sure about this change.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm not= that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0running dat= astore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0With this n= ew change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I think that you would need to give rea= d access to the top node in the desired
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path, and t= hen separate explicit "deny" rules for every sibling child node walking f= rom the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0example bel= ow may explain my understanding better:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0E.g. For a = tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the t= ree then:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0--------------------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0B=C2=A0 =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=A0 =C2=A0 = =C2=A0E
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---= --------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= =C2=A0 =C2=A0G=C2=A0 H=C2=A0 J
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the old = model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;read/write 'A/B/J'
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the new = model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;read/write 'A/B/J'
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;read A"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny C"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny D"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny E"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny F"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny G"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;deny H"
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note, I am = assuming that a "path" rule matches for the given path and all descendant nodes.=C2= =A0 The draft doesn't seem to be particularly clear on this point (it states that the rule applies
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when the pa= th matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If this cha= nge is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn'= t give any access at all, unless default read
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access had = been given.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But, possib= ly I'm misunderstanding how this all works!=C2=A0 If so, apologies f= or the noise :-)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rob
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 02/11/20= 17 14:18, Benoit Claise wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear al= l,
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here is= a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt <https://= tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.tx= t>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dfp= cfioondggippe.png>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The NET= CONF WG was cc'ed for the entire discussion.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What do= you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note: I= f the WG is fine, the next step is to approve this document.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards= , Benoit
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________________________________ >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netconf= mailing list
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/lis= tinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> ___________________________________________= ____
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf.org/mailman= /listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________________
> Netconf mailing list
> Ne= tconf@ietf.org
> https://www.ietf.org/mailman/li= stinfo/netconf
>




--001a1141148052881c055da37b52-- From nobody Fri Nov 10 09:24:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8754012EC76; Fri, 10 Nov 2017 09:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 khSRz9N3EypK; Fri, 10 Nov 2017 09:24:08 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DE812EC75; Fri, 10 Nov 2017 09:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65590; q=dns/txt; s=iport; t=1510334648; x=1511544248; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=nEk141QNg90haIIZnO5CjyYyQKltsJu8xL4tC/XLkUc=; b=FCgys9gWOu6G3ahRA64QIJFF0dEK/1KYhq6vJtCVIbEBOrZgYRQtwQ54 YB4vHePBtvy1ncBUQWF095S6SPpwe3BP3KW0uzTy2RMkXuyMBDUIkTTT1 JIusP658Pu3Fygj35ITL3NjitbG5jL382RI1izfSUp59DgbltUbS9cD3W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAAB83wVa/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDB4ESbieDfoofdJAziFeFEohnEIF+AwoYAQyBN4MQTwKFBRg?= =?us-ascii?q?BAQEBAQEBAQFrKIUeAQEBAQIBAQEYAQgERwsFCwkCGCABBgMCAiEGHxEGDQYCA?= =?us-ascii?q?QEXiW8DDQgQi2ydaIFtOiaHFg2DSAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DNIN?= =?us-ascii?q?bgWkpgwGCa1mBDA8ECQQRgyuCYwEEiiAKhzuBboU7iFY9h2mDaIQ2hHmCFV+JC?= =?us-ascii?q?CSHIIoxgjc6gRCHcIE5HziBcjQhCB0VSYJkCYIaORwZgU5BNgGJfAIlB4IWAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.44,375,1505779200"; d="scan'208,217";a="187362" 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; 10 Nov 2017 17:24:04 +0000 Received: from [10.61.246.69] ([10.61.246.69]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAAHO4wk010890; Fri, 10 Nov 2017 17:24:04 GMT To: Andy Bierman Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> From: Robert Wilton Message-ID: <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> Date: Fri, 10 Nov 2017 17:24:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6CEB2BFFB449EAEA141964A2" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:24:14 -0000 This is a multi-part message in MIME format. --------------6CEB2BFFB449EAEA141964A2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/11/2017 16:33, Andy Bierman wrote: > > > On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton > wrote: > > > > On 10/11/2017 15:49, Andy Bierman wrote: >> >> >> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland > > wrote: >> >> On 2017-11-10 11:42, Robert Wilton wrote: >> > >> > >> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >> >> >> >> >> >> >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> > >> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >> >> >> wrote: >> >> >> >>> Hi, >> >>> >> >>> The term "data node" is used in the document to refer to >> the top-level node >> >>> of the specified object, not the entire subtree (if any). >> >>> >> >>> The data-rule /foo does not match /foo/child1 in the text >> below. >> >>> The child nodes are omitted because of step 11. >> >>> The admin has to explicitly permit individual child nodes >> (or modules). >> >>> This seems correct if the read-default is "deny". >> >>> >> >>> Should any text be added or changed to make this more clear? >> >> >> >> I would agree with Robert that it was not entirely clear >> that rule applied on the parent data-node does not apply to >> the child nodes. So yes, it would help to clarify it. >> > We should be doing more than clarifying it.  We need to fix >> it so that it works in a sensible way.  I.e. to make the >> normative text consistent with the behaviour currently >> described in the examples in >> > the appendix B.4. >> > >> > If we follow Andy's interpretation that a data rule doesn't >> match child nodes then those examples are completely wrong.  >> E.g. the 4th rule is described as "This rule gives the >> 'admin' group read-write >> > access to all acme entries."  But If the path >> only strictly matches "/acme:interfaces/acme:interface" then >> the admin group rule achieves nothing useful at all.  The >> admin is not even >> > allowed to create an interface because they would not even >> have permission to write to the list key 'name' node required >> to create a list entry!  Instead, a separate rule would be >> required for every >> > single possible schema node under >> "/acme:interfaces/acme:interface"!  I think that this makes >> "permit" data-node rules completely unusable. >> >> I strongly agree with this, and I would say that it isn't >> only the case >> for "permit" rules - e.g. denying some access to a subtree of >> the data >> model that would otherwise be permitted due to defaults is at >> least as >> common, and the rules would be just as unusable for that. >> >> Besides the examples, I think that the very use of the term >> "match", >> though unfortunately not defined, strongly suggests that it >> is something >> other than use of e.g. the term "identify" would imply. >> Additionally, >> this text in the description of the 'path' leaf is consistent >> with the >> match being a prefix match: >> >>        The special value '/' refers to all possible >>        datastore contents."; >> >> FWIW, our NACM implementation, available to (and used by) >> customers >> since 2012, follows the prefix match logic, and I have yet to >> hear of >> any user expecting it to do otherwise. >> >> > To fix this properly, we need to make the data-node path >> rule a prefix match.  In particular, we need text that specifies: >> > >> > (i) that a data-node path match succeeds if it matches the >> path prefix from the root of the tree.  I.e. so the data-rule >> "/foo" matches "/foo" and all of foo's descendant children nodes. >> >> Strongly agree. >> >> >> >> I do not see how the text can be interpreted this way. > > Because otherwise the path match part of the NACM solution is > really broken, and the path based examples in the appendix are > entirely misleading and wrong.  The only way those examples make > sense is the paths match descendant children nodes as well. > > > > IMO the text does not support this interpretation. The examples in B.4, and the definition of "/" matching all nodes supports this interpretation. Hence, my opinion is that it is the text in 3.4.5 that is incorrectly specified; and that the examples, definition of "/" and standard practice are right. Otherwise, how did IETF manage to publish an RFC where the path based examples are so completely wrong?   Whoever wrote and reviewed those examples clearly had a different interpretation of how these path based ACLs worked. > There is nothing said about inheriting state from the parent data node. > I think no matter how the permissions are derived, one can > find examples that work better or worse because of it. No.  If the rules apply to descendant children, all normal examples work well (including the ones in the appendix). > IMO the number of rules required to implement a use-case is not > very relevant or objective criteria. Yes it is, particularly when the difference is between needing a 1 line rule, and a 100+ line rule. > > Using the previous example of /home and /home/user1, > if the user1 is given read access to /home, then (according to you) > it also has read access to every user subtree under /home. > Instead of 1 rule per user, 2 rules are needed No, just 1 rule per user:    read-default=deny    group=user1, path=/home/user1, action=permit This is because of my two proposed changes: (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes. <- This means that you only need 1 entry instead of 100 entries. (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root. (I.e. to mitigate the original change proposed on this thread.) <- This means that you don't need a separate read rule for "/home".  Read access to that node it is implicitly given via "group=user1, path=/home/user1, action=permit", hence meaning that the rule works the same way as it does on an rfc6536 compliant implementation. > >    read-default=deny >    group=*, path=/home, action=permit >    group=user1, path=/home/user1, action=permit > > The above rules would allow access for every user to every other user. > The 2nd rule has no effect, which is counter-intuitive. > Every user dir would need 2 rules > >    read-default=deny >    group=*, path=/home, action=permit >    group=user1, path=/home/user1, action=permit >    group=*, path=/home/user1, action=deny > >> There is nothing that says this is how it works. >> If it did, once could never have privileged sub-fiolders >> >>      /var/log -> permit >>      /var/log/apache2  -> deny > > Yes, you can, you just list the longest path first in the list of > rules: > >  (1)  /var/log/apache2  -> deny >   (2) /var/log -> permit > > Any requests that attempt to access anything under > /var/log/apache2 would match rule (1) and be denied. > Any requests that attempt to access anything under /var/log, but > not under /var/log/apache2, would fail to match rule (1), but > would match rule (2) instead and be permitted. > > > > I do not see any text in the draft or RFC 7950 that > suggests that /var/log and /var/log/apache2 represent the same data node. They are different data nodes, but I don't see how that is relevant. Thanks, Rob > > > Andy > >> >> >> > (ii) if a data-node rule has action "permit" then it >> implicitly allows read access for all ancestor parent nodes >> up to the root.  (I.e. to mitigate the original change >> proposed on this thread.) >> >> This seems reasonable to me, although I haven't at this point >> evaluated >> the suggestion in detail. In any case I think the main point both >> regarding this and the prefix match is that this update to >> 6536 can't >> make radical changes to the semantics compared to a "reasonable >> interpretation" (hard to define, I know) of the under-specified >> original. >> >> >> The text does not say this at all so I do not approve of this change > > In the RFC version of the NACM this wasn't required because > operation 'none' didn't require read access. Now read access is > required even for operation 'none', then this change makes sense > to make the NACM changes backwards compatible, whilst still > closing the security hole. > > Thanks, > Rob > >> >> >> --Per >> >> >> >> Andy >> >> > Thanks, >> > Rob >> > >> > >> >> >> >> Thanks >> >> >> >>> >> >>> >> >>> Andy >> >>> >> >>> >> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >> >> >> wrote: >> >>> >> >>>     Hi Andy, >> >>> >> >>>     It isn't clear to me whether matching a path in NACM >> either: >> >>>       (i) Only applies to the specific node, and not any >> children, or >> >>>       (ii) Applies to the specific node and all >> descendant children nodes as well. >> >>> >> >>>     As an example, using the tree below.  if I have a >> rule that matches path "A/B" then does that apply to only the >> specific node "A/B", or does it also apply to all descendant >> children of "A/B" as >> >>>     well? >> >>> >> >>>     In rfc6536bis-08, section "3.4.5.  Data Node Access >> Validation", step 6 states: >> >>> >> >>>             *  The rule does not have a "rule-type" >> defined or the "rule- >> >>>                type" is "data-node" and the *"path" >> matches the requested data node*, action node, or >> notification node. >> >>> >> >>> >> >>>     My reading of this is that it implies that the >> interpretation of the path rule is (i), but this is not how I >> would normally expect an ACL rule to apply in a tree like >> object (e.g a directory >> >>>     file system). >> >>> >> >>>     However, the examples in Appendix B.4. imply that the >> path rule is to be interpreted like (ii), or otherwise the >> example rules seem to be mostly pointless. >> >>> >> >>>     E.g. taking this example from appendix B.4: >> >>> >> >>>            >> >>> permit-dummy-interface >> >>>              > >> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >> >>>              >> >>> read update >> >>> permit >> >>>              >> >>>                Allow the limited and guest groups read >> >>>                and update access to the dummy interface. >> >>>              >> >>>            >> >>> >> >>> >> >>>     If the rule is (i)  then the access rule allows the >> client to read the specific node >> "/acme:interfaces/acme:interface[acme:name='dummy']" but not >> any child leafs/containers of that interface, >> >>>     this doesn't seem useful. >> >>> >> >>>     Further comments inline below ... >> >>> >> >>>     On 08/11/2017 20:05, Andy Bierman wrote: >> >>>>     Hi, >> >>>> >> >>>>     This change has no impact on the server if >> /nacm/read-default is "permit". >> >>>>     In that case, the extra read rules for /A and /A/B >> are not needed. >> >>>     I agree. >> >>> >> >>>>     An operator worried about read access should set >> read-default to "deny". >> >>>     I agree.  This is the scenario that I'm considering. >> >>> >> >>>>     In that case, explicit rules to read /A and /A/B >> would be needed >> >>>>     in the new NACM. >> >>>     Yes, if the interpretation of the rule is (i) above. >> >>>     Otherwise if the interpretation is (ii) then you only >> need "read /A" since that implies "read A/B" as well (as long >> as the rules are listed in the correct order). >> >>> >> >>> >> >>>>       The deny rules would not be needed. >> >>>     Only if the interpretation of the rule is (i) above.  >> In which case the "read/write 'A/B/J' rule would not be >> sufficient.  It would be necessary to define an Xpath >> expressions that contains >> >>>     all children nodes as well. Perhaps 'A/B/J//*'? >> >>> >> >>>     If the interpretation of the rule is (ii) then you >> would also need all the explicit deny statements as well, >> otherwise they would be allowed by the "read /A" rule above. >> >>> >> >>>     Thanks, >> >>>     Rob >> >>> >> >>> >> >>>> >> >>>> >> >>>>     Andy >> >>>> >> >>>> >> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton >> >> >> wrote: >> >>>> >> >>>>         Hi, >> >>>> >> >>>>         I'm not sure about this change. >> >>>> >> >>>>         I'm not that familiar with NACM, but if you want >> to give a particular set of users read/write access to a >> subtree, but not allow them to have any other access to the >> configuration in the >> >>>>         running datastore then with the existing RFC, >> that could be expressed with a single rule (example in >> 6536bis, appendix B.4) >> >>>> >> >>>>         With this new change, I think that you may need >> to configure many more rules to achieve the same thing.  I >> think that you would need to give read access to the top node >> in the desired >> >>>>         path, and then separate explicit "deny" rules >> for every sibling child node walking from the top of the tree >> down to the data node that read/write access is actually >> being given to.  The >> >>>>         example below may explain my understanding better: >> >>>> >> >>>>         E.g. For a tree of data nodes, rooted at A, if >> we wanted to give read/write access only to "J" subtree, and >> no access for the rest of the tree then: >> >>>> >> >>>>                          A >> >>>>                          | >> >>>>  -------------------- >> >>>>                 |      |  |     | >> >>>>                 B      C  D     E >> >>>>                 | >> >>>>            ----------- >> >>>>            |   |  |  | >> >>>>            F   G  H  J >> >>>>                      | >> >>>>                     ... >> >>>> >> >>>> >> >>>>         In the old model, I think that the ACL rules >> would be 1 rules long (assuming default deny all): >> >>>>            "read/write 'A/B/J' >> >>>> >> >>>>         In the new model, I think that the equivalent >> ACL rules would need to be 8 rules long (assuming default >> deny all): >> >>>>            "read/write 'A/B/J' >> >>>>            "read A" >> >>>>            "deny C" >> >>>>            "deny D" >> >>>>            "deny E" >> >>>>            "deny F" >> >>>>            "deny G" >> >>>>            "deny H" >> >>>> >> >>>>         Note, I am assuming that a "path" rule matches >> for the given path and all descendant nodes.  The draft >> doesn't seem to be particularly clear on this point (it >> states that the rule applies >> >>>>         when the path matches, but this would seem to be >> counter intuitive), and perhaps it could be clarified. >> >>>> >> >>>>         If this change is allowed, then the example in >> appendix B.4 looks like it would need to be fixed, since the >> "limited-acl" probably wouldn't give any access at all, >> unless default read >> >>>>         access had been given. >> >>>> >> >>>>         But, possibly I'm misunderstanding how this all >> works!  If so, apologies for the noise :-) >> >>>> >> >>>>         Thanks, >> >>>>         Rob >> >>>> >> >>>> >> >>>>         On 02/11/2017 14:18, Benoit Claise wrote: >> >>>>>         Dear all, >> >>>>> >> >>>>>         Here is a major change in >> draft-ietf-netconf-rfc6536bis, suggested by the Security AD >> Eric Rescola part of the IESG review, which I would like to >> validate with the WG. See >> >>>>> >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >> >> > > >> >>>>> >> >>>>>   >> >>>>>         The NETCONF WG was cc'ed for the entire discussion. >> >>>>>         What do you think? I will draw the conclusions >> by Friday Nov 10th. >> >>>>> >> >>>>>         Note: If the WG is fine, the next step is to >> approve this document. >> >>>>> >> >>>>>         Regards, Benoit >> >>>>> >> >>>>> >> >>>>>  _______________________________________________ >> >>>>>         Netconf mailing list >> >>>>> Netconf@ietf.org >> > >> >>>>> https://www.ietf.org/mailman/listinfo/netconf >> >> > > >> >>>> >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Netconf mailing list >> >>> Netconf@ietf.org >> > >> >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> > >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> > >> >> > > --------------6CEB2BFFB449EAEA141964A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/11/2017 16:33, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 10/11/2017 15:49, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
On 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is used in the document to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify" would imply. Additionally,
this text in the description of the 'path' leaf is consistent with the
match being a prefix match:

       The special value '/' refers to all possible
       datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.  The only way those examples make sense is the paths match descendant children nodes as well.



IMO the text does not support this interpretation.
The examples in B.4, and the definition of "/" matching all nodes supports this interpretation.

Hence, my opinion is that it is the text in 3.4.5 that is incorrectly specified; and that the examples, definition of "/" and standard practice are right.

Otherwise, how did IETF manage to publish an RFC where the path based examples are so completely wrong?   Whoever wrote and reviewed those examples clearly had a different interpretation of how these path based ACLs worked.


There is nothing said about inheriting state from the parent data node.
I think no matter how the permissions are derived, one can
find examples that work better or worse because of it.
No.  If the rules apply to descendant children, all normal examples work well (including the ones in the appendix).


IMO the number of rules required to implement a use-case is not
very relevant or objective criteria.
Yes it is, particularly when the difference is between needing a 1 line rule, and a 100+ line rule.


Using the previous example of /home and /home/user1,
if the user1 is given read access to /home, then (according to you)
it also has read access to every user subtree under /home.
Instead of 1 rule per user, 2 rules are needed
No, just 1 rule per user:
   read-default=deny
   group=user1, path=/home/user1, action=permit

This is because of my two proposed changes:

(i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.
<- This means that you only need 1 entry instead of 100 entries.

(ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)
<- This means that you don't need a separate read rule for "/home".  Read access to that node it is implicitly given via "group=user1, path=/home/user1, action=permit", hence meaning that the rule works the same way as it does on an rfc6536 compliant implementation.


   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit

The above rules would allow access for every user to every other user.
The 2nd rule has no effect, which is counter-intuitive.
Every user dir would need 2 rules

   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit
   group=*, path=/home/user1, action=deny

There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

     /var/log -> permit
     /var/log/apache2  -> deny

Yes, you can, you just list the longest path first in the list of rules:

 (1)  /var/log/apache2  -> deny
  (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



I do not see any text in the draft or RFC 7950 that
suggests that /var/log and /var/log/apache2 represent the same data node.
They are different data nodes, but I don't see how that is relevant.

Thanks,
Rob




Andy

 

 
> (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read access.  Now read access is required even for operation 'none', then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


 

--Per



Andy
 
> Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>     Hi Andy,
>>>
>>>     It isn't clear to me whether matching a path in NACM either:
>>>       (i) Only applies to the specific node, and not any children, or
>>>       (ii) Applies to the specific node and all descendant children nodes as well.
>>>
>>>     As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as
>>>     well?
>>>
>>>     In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states:
>>>
>>>             *  The rule does not have a "rule-type" defined or the "rule-
>>>                type" is "data-node" and the *"path" matches the requested data node*, action node, or notification node.
>>>
>>>
>>>     My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>     file system).
>>>
>>>     However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>     E.g. taking this example from appendix B.4:
>>>
>>>            <rule>
>>>              <name>permit-dummy-interface</name>
>>>              <path xmlns:acme="http://example.com/ns/itf" <http://example.com/ns/itf>>
>>>                /acme:interfaces/acme:interface[acme:name='dummy']
>>>              </path>
>>>              <access-operations>read update</access-operations>
>>>              <action>permit</action>
>>>              <comment>
>>>                Allow the limited and guest groups read
>>>                and update access to the dummy interface.
>>>              </comment>
>>>            </rule>
>>>
>>>
>>>     If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface,
>>>     this doesn't seem useful.
>>>
>>>     Further comments inline below ...
>>>
>>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     This change has no impact on the server if /nacm/read-default is "permit".
>>>>     In that case, the extra read rules for /A and /A/B are not needed.
>>>     I agree.
>>>
>>>>     An operator worried about read access should set read-default to "deny".
>>>     I agree.  This is the scenario that I'm considering.
>>>
>>>>     In that case, explicit rules to read /A and /A/B would be needed
>>>>     in the new NACM.
>>>     Yes, if the interpretation of the rule is (i) above.
>>>     Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>       The deny rules would not be needed.
>>>     Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains
>>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>
>>>     If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>>
>>>>
>>>>     Andy
>>>>
>>>>
>>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         I'm not sure about this change.
>>>>
>>>>         I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>         running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>         With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired
>>>>         path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The
>>>>         example below may explain my understanding better:
>>>>
>>>>         E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:
>>>>
>>>>                          A
>>>>                          |
>>>>                 --------------------
>>>>                 |      |     |     |
>>>>                 B      C     D     E
>>>>                 |
>>>>            -----------
>>>>            |   |  |  |
>>>>            F   G  H  J
>>>>                      |
>>>>                     ...
>>>>
>>>>
>>>>         In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>
>>>>         In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>            "read A"
>>>>            "deny C"
>>>>            "deny D"
>>>>            "deny E"
>>>>            "deny F"
>>>>            "deny G"
>>>>            "deny H"
>>>>
>>>>         Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies
>>>>         when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>>
>>>>         If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read
>>>>         access had been given.
>>>>
>>>>         But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>         Dear all,
>>>>>
>>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>>>>>
>>>>>         <dfpcfioondggippe.png>
>>>>>         The NETCONF WG was cc'ed for the entire discussion.
>>>>>         What do you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>         Note: If the WG is fine, the next step is to approve this document.
>>>>>
>>>>>         Regards, Benoit
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Netconf mailing list
>>>>>         Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>>         https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>





--------------6CEB2BFFB449EAEA141964A2-- From nobody Fri Nov 10 09:45:26 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3F412EC83 for ; Fri, 10 Nov 2017 09:45:25 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 XTlQGfV-aXCn for ; Fri, 10 Nov 2017 09:45:21 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 DAA8F12EC95 for ; Fri, 10 Nov 2017 09:45:20 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id f134so3610365lfg.8 for ; Fri, 10 Nov 2017 09:45:20 -0800 (PST) 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=3sE8+ftVIYq4Y2rLcWKH0pVgaI6H2fprFluc2NflGZs=; b=yWsfoXiC5pq3K2E6PDSMq9EDZz0dbjQhIfUi6lNQAYD4AxvXjcOevSpzQZZh2hhXsi 8YlkJGIF+rJvqhygiv0r5YwGBOlCDxH7DkK74IlBlvF/Jk38zd6y9ECghh/Dgxv9piVm E6EivDs+g+B3VnGD4MeejcsJ9S57eQTxFg5Qi49t4VWzqWA12tkR+mXnKCk6sWRVLTK/ K0BguTD1UjXORwS5eQMRK6EBvhUOZtqCUumg7/wGOEdJ4TlGdt7tYMVzNY6gfkI05cbA +ii6Ss32cHl6FjQdvUjlJTfVMazkLVY6ymWgkZuQ6TAuV3LW/IYeSchAnnXWFqgJ6RUC 4pdg== 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=3sE8+ftVIYq4Y2rLcWKH0pVgaI6H2fprFluc2NflGZs=; b=puk0E4Pd6tm3lo9yAijdBwKZJ/RVgxmPPZxi2On/WuA73BZJhVGeS5Hf31YBEAVhso 2KOtP1DovBotdBM9oGzveM2f9oSxJWbRLksu37zC0yOeWsT1WHh1b0arigoAid5nwANP jBp3bu+QvV0ZgRVXwG7EOiHyD69C6F+DlxB+5RorGpxefx8lfLmBplKvq83xsHZelTCy jLZ+HOFHngJNTGbfmdxK89BKW0qR5fNl2bV/2TB2LOb8NPxojmnx5ttJoWrkv5MDOLWw WP6S8fvodBhyH8p0ulqLwUKZvNvcVtgqmh7yD8fF+guVS/dmyTgFGG6eb7YjMv9Wpxjv Lisw== X-Gm-Message-State: AJaThX4v+F8Lkvjp3yx8mkUpjJw2/aKfCjc7m/zul13Xt8wSY603n/+j zJruP4D6pMY1Q9NAb8UcKcdw5N7jDBdgeJATXYlu9w== X-Google-Smtp-Source: AGs4zMar0AuTjuZQKfRnwxutdYDcNOXqGWRt+h8zYFE/r6mKJiAZWz5Fp4LovGW7goe4emwUWpXSBZrlIiVEf6GnEEs= X-Received: by 10.25.228.29 with SMTP id b29mr428781lfh.107.1510335919023; Fri, 10 Nov 2017 09:45:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Fri, 10 Nov 2017 09:45:17 -0800 (PST) In-Reply-To: <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> From: Andy Bierman Date: Fri, 10 Nov 2017 09:45:17 -0800 Message-ID: To: Robert Wilton Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e6114f1fb4c055da47b02" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:45:25 -0000 --94eb2c0e6114f1fb4c055da47b02 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton wrote: > > > On 10/11/2017 16:33, Andy Bierman wrote: > > > > On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton wrote: > >> >> >> On 10/11/2017 15:49, Andy Bierman wrote: >> >> >> >> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland wrote: >> >>> On 2017-11-10 11:42, Robert Wilton wrote: >>> > >>> > >>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >> > wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> The term "data node" is used in the document to refer to the >>> top-level node >>> >>> of the specified object, not the entire subtree (if any). >>> >>> >>> >>> The data-rule /foo does not match /foo/child1 in the text below. >>> >>> The child nodes are omitted because of step 11. >>> >>> The admin has to explicitly permit individual child nodes (or >>> modules). >>> >>> This seems correct if the read-default is "deny". >>> >>> >>> >>> Should any text be added or changed to make this more clear? >>> >> >>> >> I would agree with Robert that it was not entirely clear that rule >>> applied on the parent data-node does not apply to the child nodes. So yes, >>> it would help to clarify it. >>> > We should be doing more than clarifying it. We need to fix it so that >>> it works in a sensible way. I.e. to make the normative text consistent >>> with the behaviour currently described in the examples in >>> > the appendix B.4. >>> > >>> > If we follow Andy's interpretation that a data rule doesn't match >>> child nodes then those examples are completely wrong. E.g. the 4th rule is >>> described as "This rule gives the 'admin' group read-write >>> > access to all acme entries." But If the path only >>> strictly matches "/acme:interfaces/acme:interface" then the admin group >>> rule achieves nothing useful at all. The admin is not even >>> > allowed to create an interface because they would not even have >>> permission to write to the list key 'name' node required to create a list >>> entry! Instead, a separate rule would be required for every >>> > single possible schema node under "/acme:interfaces/acme:interface"! >>> I think that this makes "permit" data-node rules completely unusable. >>> >>> I strongly agree with this, and I would say that it isn't only the case >>> for "permit" rules - e.g. denying some access to a subtree of the data >>> model that would otherwise be permitted due to defaults is at least as >>> common, and the rules would be just as unusable for that. >>> >>> Besides the examples, I think that the very use of the term "match", >>> though unfortunately not defined, strongly suggests that it is something >>> other than use of e.g. the term "identify" would imply. Additionally, >>> this text in the description of the 'path' leaf is consistent with the >>> match being a prefix match: >>> >>> The special value '/' refers to all possible >>> datastore contents."; >>> >>> FWIW, our NACM implementation, available to (and used by) customers >>> since 2012, follows the prefix match logic, and I have yet to hear of >>> any user expecting it to do otherwise. >>> >>> > To fix this properly, we need to make the data-node path rule a prefix >>> match. In particular, we need text that specifies: >>> > >>> > (i) that a data-node path match succeeds if it matches the path prefix >>> from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and >>> all of foo's descendant children nodes. >>> >>> Strongly agree. >>> >>> >> >> I do not see how the text can be interpreted this way. >> >> >> Because otherwise the path match part of the NACM solution is really >> broken, and the path based examples in the appendix are entirely misleading >> and wrong. The only way those examples make sense is the paths match >> descendant children nodes as well. >> >> > > IMO the text does not support this interpretation. > > The examples in B.4, and the definition of "/" matching all nodes supports > this interpretation. > > Hence, my opinion is that it is the text in 3.4.5 that is incorrectly > specified; and that the examples, definition of "/" and standard practice > are right. > > Otherwise, how did IETF manage to publish an RFC where the path based > examples are so completely wrong? Whoever wrote and reviewed those > examples clearly had a different interpretation of how these path based > ACLs worked. > > Only the examples for "update" support this interpretation since the read-default=permit and write-default=deny in the example > There is nothing said about inheriting state from the parent data node. > I think no matter how the permissions are derived, one can > find examples that work better or worse because of it. > > No. If the rules apply to descendant children, all normal examples work > well (including the ones in the appendix). > > > > IMO the number of rules required to implement a use-case is not > very relevant or objective criteria. > > Yes it is, particularly when the difference is between needing a 1 line > rule, and a 100+ line rule. > Depending on how the defaults are set. If they are set to "permit" then only "deny" rules need to be added since access procedures do not proceed to a child node after a deny outcome is reached. > > > Using the previous example of /home and /home/user1, > if the user1 is given read access to /home, then (according to you) > it also has read access to every user subtree under /home. > > Instead of 1 rule per user, 2 rules are needed > > No, just 1 rule per user: > read-default=deny > group=user1, path=/home/user1, action=permit > > This is because of my two proposed changes: > > (i) that a data-node path match succeeds if it matches the path prefix > from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and > all of foo's descendant children nodes. > <- This means that you only need 1 entry instead of 100 entries. > > I will define a data-rule to apply to a data node if it is a descendant or the node itself if this is what the WG wants (ii) if a data-node rule has action "permit" then it implicitly allows read > access for all ancestor parent nodes up to the root. (I.e. to mitigate the > original change proposed on this thread.) > <- This means that you don't need a separate read rule for "/home". Read > access to that node it is implicitly given via "group=user1, > path=/home/user1, action=permit", hence meaning that the rule works the > same way as it does on an rfc6536 compliant implementation. > > > I do not agree at all that the definition of data node /home/foo includes its ancestors and this is brand new behavior that is not shown in the document at all. > read-default=deny > group=*, path=/home, action=permit > group=user1, path=/home/user1, action=permit > > The above rules would allow access for every user to every other user. > The 2nd rule has no effect, which is counter-intuitive. > Every user dir would need 2 rules > > read-default=deny > group=*, path=/home, action=permit > group=user1, path=/home/user1, action=permit > group=*, path=/home/user1, action=deny > > There is nothing that says this is how it works. >> If it did, once could never have privileged sub-fiolders >> >> /var/log -> permit >> /var/log/apache2 -> deny >> >> >> Yes, you can, you just list the longest path first in the list of rules: >> >> (1) /var/log/apache2 -> deny >> (2) /var/log -> permit >> >> Any requests that attempt to access anything under /var/log/apache2 would >> match rule (1) and be denied. >> Any requests that attempt to access anything under /var/log, but not >> under /var/log/apache2, would fail to match rule (1), but would match rule >> (2) instead and be permitted. >> >> >> > I do not see any text in the draft or RFC 7950 that > suggests that /var/log and /var/log/apache2 represent the same data node. > > They are different data nodes, but I don't see how that is relevant. > The NACM procedures refer to "the data node", not "the data node or its descendants", > > Thanks, > Rob > Andy > > > > > Andy > > > >> >> >> >>> > (ii) if a data-node rule has action "permit" then it implicitly allows >>> read access for all ancestor parent nodes up to the root. (I.e. to >>> mitigate the original change proposed on this thread.) >>> >>> This seems reasonable to me, although I haven't at this point evaluated >>> the suggestion in detail. In any case I think the main point both >>> regarding this and the prefix match is that this update to 6536 can't >>> make radical changes to the semantics compared to a "reasonable >>> interpretation" (hard to define, I know) of the under-specified >>> original. >>> >> >> The text does not say this at all so I do not approve of this change >> >> >> In the RFC version of the NACM this wasn't required because operation >> 'none' didn't require read access. Now read access is required even for >> operation 'none', then this change makes sense to make the NACM changes >> backwards compatible, whilst still closing the security hole. >> >> Thanks, >> Rob >> >> >> >> >>> >>> --Per >>> >>> >> >> Andy >> >> >>> > Thanks, >>> > Rob >>> > >>> > >>> >> >>> >> Thanks >>> >> >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >> > wrote: >>> >>> >>> >>> Hi Andy, >>> >>> >>> >>> It isn't clear to me whether matching a path in NACM either: >>> >>> (i) Only applies to the specific node, and not any children, or >>> >>> (ii) Applies to the specific node and all descendant children >>> nodes as well. >>> >>> >>> >>> As an example, using the tree below. if I have a rule that >>> matches path "A/B" then does that apply to only the specific node "A/B", or >>> does it also apply to all descendant children of "A/B" as >>> >>> well? >>> >>> >>> >>> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", >>> step 6 states: >>> >>> >>> >>> * The rule does not have a "rule-type" defined or the >>> "rule- >>> >>> type" is "data-node" and the *"path" matches the >>> requested data node*, action node, or notification node. >>> >>> >>> >>> >>> >>> My reading of this is that it implies that the interpretation of >>> the path rule is (i), but this is not how I would normally expect an ACL >>> rule to apply in a tree like object (e.g a directory >>> >>> file system). >>> >>> >>> >>> However, the examples in Appendix B.4. imply that the path rule >>> is to be interpreted like (ii), or otherwise the example rules seem to be >>> mostly pointless. >>> >>> >>> >>> E.g. taking this example from appendix B.4: >>> >>> >>> >>> >>> >>> permit-dummy-interface >>> >>> >> http://example.com/ns/itf>> >>> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>> >>> >>> >>> read update >>> >>> permit >>> >>> >>> >>> Allow the limited and guest groups read >>> >>> and update access to the dummy interface. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If the rule is (i) then the access rule allows the client to >>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" >>> but not any child leafs/containers of that interface, >>> >>> this doesn't seem useful. >>> >>> >>> >>> Further comments inline below ... >>> >>> >>> >>> On 08/11/2017 20:05, Andy Bierman wrote: >>> >>>> Hi, >>> >>>> >>> >>>> This change has no impact on the server if /nacm/read-default >>> is "permit". >>> >>>> In that case, the extra read rules for /A and /A/B are not >>> needed. >>> >>> I agree. >>> >>> >>> >>>> An operator worried about read access should set read-default >>> to "deny". >>> >>> I agree. This is the scenario that I'm considering. >>> >>> >>> >>>> In that case, explicit rules to read /A and /A/B would be needed >>> >>>> in the new NACM. >>> >>> Yes, if the interpretation of the rule is (i) above. >>> >>> Otherwise if the interpretation is (ii) then you only need "read >>> /A" since that implies "read A/B" as well (as long as the rules are listed >>> in the correct order). >>> >>> >>> >>> >>> >>>> The deny rules would not be needed. >>> >>> Only if the interpretation of the rule is (i) above. In which >>> case the "read/write 'A/B/J' rule would not be sufficient. It would be >>> necessary to define an Xpath expressions that contains >>> >>> all children nodes as well. Perhaps 'A/B/J//*'? >>> >>> >>> >>> If the interpretation of the rule is (ii) then you would also >>> need all the explicit deny statements as well, otherwise they would be >>> allowed by the "read /A" rule above. >>> >>> >>> >>> Thanks, >>> >>> Rob >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>> Andy >>> >>>> >>> >>>> >>> >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton < >>> rwilton@cisco.com > wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> I'm not sure about this change. >>> >>>> >>> >>>> I'm not that familiar with NACM, but if you want to give a >>> particular set of users read/write access to a subtree, but not allow them >>> to have any other access to the configuration in the >>> >>>> running datastore then with the existing RFC, that could be >>> expressed with a single rule (example in 6536bis, appendix B.4) >>> >>>> >>> >>>> With this new change, I think that you may need to >>> configure many more rules to achieve the same thing. I think that you >>> would need to give read access to the top node in the desired >>> >>>> path, and then separate explicit "deny" rules for every >>> sibling child node walking from the top of the tree down to the data node >>> that read/write access is actually being given to. The >>> >>>> example below may explain my understanding better: >>> >>>> >>> >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to >>> give read/write access only to "J" subtree, and no access for the rest of >>> the tree then: >>> >>>> >>> >>>> A >>> >>>> | >>> >>>> -------------------- >>> >>>> | | | | >>> >>>> B C D E >>> >>>> | >>> >>>> ----------- >>> >>>> | | | | >>> >>>> F G H J >>> >>>> | >>> >>>> ... >>> >>>> >>> >>>> >>> >>>> In the old model, I think that the ACL rules would be 1 >>> rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> >>> >>>> In the new model, I think that the equivalent ACL rules >>> would need to be 8 rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> "read A" >>> >>>> "deny C" >>> >>>> "deny D" >>> >>>> "deny E" >>> >>>> "deny F" >>> >>>> "deny G" >>> >>>> "deny H" >>> >>>> >>> >>>> Note, I am assuming that a "path" rule matches for the >>> given path and all descendant nodes. The draft doesn't seem to be >>> particularly clear on this point (it states that the rule applies >>> >>>> when the path matches, but this would seem to be counter >>> intuitive), and perhaps it could be clarified. >>> >>>> >>> >>>> If this change is allowed, then the example in appendix B.4 >>> looks like it would need to be fixed, since the "limited-acl" probably >>> wouldn't give any access at all, unless default read >>> >>>> access had been given. >>> >>>> >>> >>>> But, possibly I'm misunderstanding how this all works! If >>> so, apologies for the noise :-) >>> >>>> >>> >>>> Thanks, >>> >>>> Rob >>> >>>> >>> >>>> >>> >>>> On 02/11/2017 14:18, Benoit Claise wrote: >>> >>>>> Dear all, >>> >>>>> >>> >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, >>> suggested by the Security AD Eric Rescola part of the IESG review, which I >>> would like to validate with the WG. See >>> >>>>> https://tools.ietf.org/rfcdif >>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt < >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>> > >>> >>>>> >>> >>>>> >>> >>>>> The NETCONF WG was cc'ed for the entire discussion. >>> >>>>> What do you think? I will draw the conclusions by Friday >>> Nov 10th. >>> >>>>> >>> >>>>> Note: If the WG is fine, the next step is to approve this >>> document. >>> >>>>> >>> >>>>> Regards, Benoit >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Netconf mailing list >>> >>>>> Netconf@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/netconf < >>> https://www.ietf.org/mailman/listinfo/netconf> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Netconf mailing list >>> >>> Netconf@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> > >>> > >>> > >>> > _______________________________________________ >>> > Netconf mailing list >>> > Netconf@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netconf >>> > >>> >>> >> >> > > --94eb2c0e6114f1fb4c055da47b02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 10/11/2017 16:3= 3, Andy Bierman wrote:
=20


On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 10/11/2017 15:49, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
O= n 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is us= ed in the document to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.=C2=A0 We need to fix it so that it works in a sensible way.=C2=A0 I.e. to make the normative te= xt consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that = a data rule doesn't match child nodes then thos= e examples are completely wrong.=C2=A0 E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."=C2=A0 But If the path only strictl= y matches "/acme:interfaces/acme:interfac= e" then the admin group rule achieves nothing useful at all.=C2=A0 The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to c= reate a list entry!=C2=A0 Instead, a separate rule woul= d be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!= =C2=A0 I think that this makes "permit" data-nod= e rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some = access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify&qu= ot; would imply. Additionally,
this text in the description of the 'path'= ; leaf is consistent with the
match being a prefix match:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The special value '= ;/' refers to all possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore contents.&qu= ot;;

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.=C2=A0 In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.=C2=A0 I.e. so the data-rule "/foo&= quot; matches "/foo" and all of foo's des= cendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.=C2=A0 Th= e only way those examples make sense is the paths match descendant children nodes as well.



IMO the text does not support this interpretation.
The examples in B.4, and the definition of "/" matching all n= odes supports this interpretation.

Hence, my opinion is that it is the text in 3.4.5 that is incorrectly specified; and that the examples, definition of "/&quo= t; and standard practice are right.

Otherwise, how did IETF manage to publish an RFC where the path based examples are so completely wrong?=C2=A0=C2=A0 Whoever wrote and r= eviewed those examples clearly had a different interpretation of how these path based ACLs worked.



Only the exam= ples for "update" support this interpretation since
the= read-default=3Dpermit and write-default=3Ddeny in the example


There is nothing said about inheriting state from the parent data node.
I think no matter how the permissions are derived, one can
find examples that work better or worse because of it.
No.=C2=A0 If the rules apply to descendant children, all normal example= s work well (including the ones in the appendix).
<= div>

=C2=A0


IMO the number of rules required to implement a use-case is not
very relevant or objective criteria.
Yes it is, particularly when the difference is between needing a 1 line rule, and a 100+ line rule.

<= div>
Depending on how the defaults are set.
If they= are set to "permit" then only "deny" rules need to be = added since
access procedures do not proceed to a child node afte= r a deny outcome is reached.


=C2=A0=


Using the previous example of /home and /home/user1,
if the user1 is given read access to /home, then (according to you)
it also has read access to every user subtree under /home.
Instead of 1 rule per user, 2 rules are needed
No, just 1 rule per user:
=C2=A0=C2=A0 read-default=3Ddeny
=C2=A0=C2=A0 group=3Duser1, path=3D/home/user1, action=3Dpermit

This is because of my two proposed changes:

(i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.=C2=A0 I.e. so the data-rule "/fo= o" matches "/foo" and all of foo's descendant children nodes= .
<- This means that you only need 1 entry instead of 100 entries.




I will define a data-rule to apply to a data node if it is a descendant o= r the node itself
if this is what the WG wants



(ii) if a data-node rule has action "permit" then it implicit= ly allows read access for all ancestor parent nodes up to the root.=C2=A0 (I.e. to mitigate the original change proposed on this thread.)
<- This means that you don't need a separate read rule for "/home".=C2=A0 Read access to that node it is implicitly give= n via "group=3Duser1, path=3D/home/user1, action=3Dpermit", hence m= eaning that the rule works the same way as it does on an rfc6536 compliant implementation.




I do not agree at all that the definit= ion of data node /home/foo includes its ancestors
and this is bra= nd new behavior that is not shown in the document at all.

=C2=A0
=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dpermit
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1, action=3Dp= ermit

The above rules would allow access for every user to every other user.
The 2nd rule has no effect, which is counter-intuitive.
Every user dir would need 2 rules

=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dpermit
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1, action= =3Dpermit
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, action=3Ddeny<= br>

There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

=C2=A0 =C2=A0 =C2=A0/var/log -> permit
=C2=A0 =C2=A0 =C2=A0/var/log/apache2 =C2=A0-&g= t; deny

Yes, you can, you just list the longest path first in the list of rules:

=C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> deny
=C2=A0 (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



I do not see any text in the draft or RFC 7950 that
suggests that /var/log and /var/log/apache2 represent the same data node.
They are different data nodes, but I don't see how that is relevant= .

The NACM procedures refer to &q= uot;the data node", not "the data node or its descendants",<= /div>

=C2=A0

Thanks,
Rob


Andy
=

=C2=A0




Andy

=C2=A0

=C2=A0
= > (ii) if a data-node rule has action "permit"= then it implicitly allows read access for all ancestor parent nodes up to the root.=C2=A0 (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read ac= cess.=C2=A0 Now read access is required even for operation 'none= 9;, then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


=C2=A0
=
--Per



Andy
=C2=A0
= > Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0Hi Andy,
>>>
>>>=C2=A0 =C2=A0 =C2=A0It isn't clea= r to me whether matching a path in NACM either:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(i) Only a= pplies to the specific node, and not any children, or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(ii) Appli= es to the specific node and all descendant children nodes as well.
>>>
>>>=C2=A0 =C2=A0 =C2=A0As an example, us= ing the tree below.=C2=A0 if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also ap= ply to all descendant children of "A/B" as
>>>=C2=A0 =C2=A0 =C2=A0well?
>>>
>>>=C2=A0 =C2=A0 =C2=A0In rfc6536bis-08,= section "3.4.5.=C2=A0 Data Node Access Validation&qu= ot;, step 6 states:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=C2=A0 The rule does not have a "rule-type" defined or the "= ;rule-
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 type" is "data-node" and the *"path" m= atches the requested data node*, action node, or notification node.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0My reading of thi= s is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>=C2=A0 =C2=A0 =C2=A0file system).
>>>
>>>=C2=A0 =C2=A0 =C2=A0However, the exam= ples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>=C2=A0 =C2=A0 =C2=A0E.g. taking this = example from appendix B.4:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <rule>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <name>permit-dummy-interface</name&= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <path xmlns:acme=3D"http://example.com/ns/itf= " <http://example.com/ns/itf>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 /acme:interfaces/acme:interface[acme:name=3D= 'dummy']
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 </path>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <access-operations>read update</access-operations>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <action>permit</action>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Allow the limited and guest groups read
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 and update access to the dummy interface.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 </comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 </rule>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the rule is (i= )=C2=A0 then the access rule allows the client to read the specific node "/acme:interfaces/acme:interfa= ce[acme:name=3D'dummy']" but not any child leafs/containers of that interface,
>>>=C2=A0 =C2=A0 =C2=A0this doesn't = seem useful.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Further comments = inline below ...
>>>
>>>=C2=A0 =C2=A0 =C2=A0On 08/11/2017 20:= 05, Andy Bierman wrote:
>>>>=C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0This change h= as no impact on the server if /nacm/read-default is "permit".
>>>>=C2=A0 =C2=A0 =C2=A0In that case,= the extra read rules for /A and /A/B are not needed.
>>>=C2=A0 =C2=A0 =C2=A0I agree.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0An operator w= orried about read access should set read-default to "deny= ".
>>>=C2=A0 =C2=A0 =C2=A0I agree.=C2=A0 Th= is is the scenario that I'm considering.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0In that case,= explicit rules to read /A and /A/B would be needed
>>>>=C2=A0 =C2=A0 =C2=A0in the new NA= CM.
>>>=C2=A0 =C2=A0 =C2=A0Yes, if the inter= pretation of the rule is (i) above.
>>>=C2=A0 =C2=A0 =C2=A0Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read= A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The de= ny rules would not be needed.
>>>=C2=A0 =C2=A0 =C2=A0Only if the inter= pretation of the rule is (i) above.=C2=A0 In which case the=C2= =A0 "read/write 'A/B/J' rule would not b= e sufficient.=C2=A0 It would be necessary to define an Xpath expressions that contains
>>>=C2=A0 =C2=A0 =C2=A0all children node= s as well.=C2=A0 Perhaps 'A/B/J//*'?
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the interpreta= tion of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" = rule above.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Rob
>>>
>>>
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Andy
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On Wed, Nov 8= , 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I'm not sure about this change.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0With this new change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I thi= nk that you would need to give read access to the top node in the desired
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0path, and then separate explicit "deny" rules for ever= y sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0example below may explain my understanding better:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, = and no access for the rest of the tree then:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------------------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=C2=A0 =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=A0 =C2=A0 =C2=A0E
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -----------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0 |=C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 F=C2=A0 =C2=A0G=C2=A0 H=C2=A0 J
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read/write 'A/B/J'
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read/write 'A/B/J'
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read A"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny C"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny D"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny E"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny F"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny G"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny H"
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Note, I am assuming that a "path" rule matches for the give= n path and all descendant nodes.=C2=A0 The draft doesn&#= 39;t seem to be particularly clear on this point (it states that the rule applies
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified. >>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't= give any access at all, unless default read
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0access had been given.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0But, possibly I'm misunderstanding how this all works!=C2=A0 If so, apologies for the noise :-)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Thanks,
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Rob
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Dear all,
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6= 536bis-08.txt>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dfpcfioondggippe.png>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The NETCONF WG was cc'ed for the entire discussion.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0What do you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Note: If the WG is fine, the next step is to approve this document.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Regards, Benoit
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0______________________________________= _________
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Netconf mailing list
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Netconf@ietf.or= g <mailto:Netconf@ietf.org>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/netcon= f <https://www.ietf.org/mail= man/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________= ________________
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf= .org/mailman/listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________= ________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mai= lman/listinfo/netconf
>






--94eb2c0e6114f1fb4c055da47b02-- From nobody Fri Nov 10 10:23:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2E12ECA9 for ; Fri, 10 Nov 2017 10:23:14 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 rq-g7Q5u3qiJ for ; Fri, 10 Nov 2017 10:23:09 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F391293E3 for ; Fri, 10 Nov 2017 10:23:08 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id e102so7752401lfi.3 for ; Fri, 10 Nov 2017 10:23:08 -0800 (PST) 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=o1SaESTiF5D4/oGlMf5JuomwFZhVaSR/wliBlYUKPCo=; b=Tt4EE4AM3IeRn+tc6JH1DbqDxEuYUpn3LzuXdRXjoO2cHOiTr2qLMzqllSjjLh1qrq H3MqH/O2+rvQjdDIPsK3XzM9AvI0AoQKhy+FaqdfNIRCtM3gQuE12itO6euTC7d79PTl aS9sqnDL8du5atELhnbE0tfViQAndqc0fMNG/RchN8IAbSD+nMG7qUQqpt+BI4gAUmpR y/7nyw8YfRBJuD0neaDC0KyAWmIupk0/tItI8/vOPm/+weB10QRdOZGV+l7V1tH7cohk eF4noGVPUSSn/YHkUDxY1WMalTzvFJBTGbB2nJr+jv4RyueWWgjjcsnzen5VZ2KsDZGh Zv8w== 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=o1SaESTiF5D4/oGlMf5JuomwFZhVaSR/wliBlYUKPCo=; b=BCARFgmKBdWpBKfz2fL9Yf56QMNIraNp/y+XkgApl8ZNyWDv82VDp/s8izo1hhEF5v oO7wawtk2tj1Hr0UjXjojywgJpkjBtPcQD+OHr512aMhFRUXe/BwQxW8ANP/FSrDEm9Z IVwoLF0I8NpOaLoXn9oyA8KRUEfGs7y+OOtjShnnmWSUhkrK3vMvOla8OCcWGbtnNdPR fBYsmLbf3QwkHpiUvQoU+8uauuYx9t/ha1uy/OUbfs3fDxZAf2cwXZ0/9YSh6/V+WFBY IwARBq2GM6Ss0KdE2CW6TbTgAyp/c2CZ85bBPswDK5GcR4A4Z1fNSEhVGvpMEzTdYdkr YWig== X-Gm-Message-State: AJaThX770JyBbaNfZSlHrU14I+RJKGXbaTRlRpFwu3fbzHWF0GdhVK0z KjcZDaYeDLCgP8RC8Rxn7E8bafla04Cr008LRj7E9Q== X-Google-Smtp-Source: AGs4zMYY4U5WWW9d7qEhousPEREAUhi7croKa//ZgvECQ6kxb9pCIz49+X/XmUrGjia4tFgm7gx+HAdbyiDVFovtSgM= X-Received: by 10.25.221.216 with SMTP id w85mr453306lfi.19.1510338186672; Fri, 10 Nov 2017 10:23:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Fri, 10 Nov 2017 10:23:05 -0800 (PST) In-Reply-To: <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> From: Andy Bierman Date: Fri, 10 Nov 2017 10:23:05 -0800 Message-ID: To: Robert Wilton Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0ed18e1b962f055da5032c" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:23:14 -0000 --94eb2c0ed18e1b962f055da5032c Content-Type: text/plain; charset="UTF-8" Hi, Here are some proposed edits to make the data rule consistent with the examples. Note that this issue is not related to the edit in the original 1-week change. sec. 3.3.5: OLD: data node rule: controls access for a specific data node, identified by its path location within the conceptual XML document for the data node. NEW: data node rule: controls access for a specific data node and its descendants, identified by its path location within the conceptual XML document for the data node. sec 3.4.5, step 6, bullet 2: OLD: * The rule does not have a "rule-type" defined or the "rule- type" is "data-node" and the "path" matches the requested data node, action node, or notification node. NEW: * The rule does not have a "rule-type" defined or the "rule- type" is "data-node" and the "path" matches the requested data node, action node, or notification node. A path is considered to match if the current data node is the data node specified by the path, or is a descendant data node of this data node. appendix B.4: (2 bugs in explanation) OLD: deny-nacm: This rule denies the "guest" group any access to the subtree. Note that the default namespace is only applicable because this subtree is defined in the same namespace as the element. NEW: deny-nacm: This rule denies the "guest" group any access to the subtree. Andy On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton wrote: > > > On 10/11/2017 16:33, Andy Bierman wrote: > > > > On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton wrote: > >> >> >> On 10/11/2017 15:49, Andy Bierman wrote: >> >> >> >> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland wrote: >> >>> On 2017-11-10 11:42, Robert Wilton wrote: >>> > >>> > >>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >> > wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> The term "data node" is used in the document to refer to the >>> top-level node >>> >>> of the specified object, not the entire subtree (if any). >>> >>> >>> >>> The data-rule /foo does not match /foo/child1 in the text below. >>> >>> The child nodes are omitted because of step 11. >>> >>> The admin has to explicitly permit individual child nodes (or >>> modules). >>> >>> This seems correct if the read-default is "deny". >>> >>> >>> >>> Should any text be added or changed to make this more clear? >>> >> >>> >> I would agree with Robert that it was not entirely clear that rule >>> applied on the parent data-node does not apply to the child nodes. So yes, >>> it would help to clarify it. >>> > We should be doing more than clarifying it. We need to fix it so that >>> it works in a sensible way. I.e. to make the normative text consistent >>> with the behaviour currently described in the examples in >>> > the appendix B.4. >>> > >>> > If we follow Andy's interpretation that a data rule doesn't match >>> child nodes then those examples are completely wrong. E.g. the 4th rule is >>> described as "This rule gives the 'admin' group read-write >>> > access to all acme entries." But If the path only >>> strictly matches "/acme:interfaces/acme:interface" then the admin group >>> rule achieves nothing useful at all. The admin is not even >>> > allowed to create an interface because they would not even have >>> permission to write to the list key 'name' node required to create a list >>> entry! Instead, a separate rule would be required for every >>> > single possible schema node under "/acme:interfaces/acme:interface"! >>> I think that this makes "permit" data-node rules completely unusable. >>> >>> I strongly agree with this, and I would say that it isn't only the case >>> for "permit" rules - e.g. denying some access to a subtree of the data >>> model that would otherwise be permitted due to defaults is at least as >>> common, and the rules would be just as unusable for that. >>> >>> Besides the examples, I think that the very use of the term "match", >>> though unfortunately not defined, strongly suggests that it is something >>> other than use of e.g. the term "identify" would imply. Additionally, >>> this text in the description of the 'path' leaf is consistent with the >>> match being a prefix match: >>> >>> The special value '/' refers to all possible >>> datastore contents."; >>> >>> FWIW, our NACM implementation, available to (and used by) customers >>> since 2012, follows the prefix match logic, and I have yet to hear of >>> any user expecting it to do otherwise. >>> >>> > To fix this properly, we need to make the data-node path rule a prefix >>> match. In particular, we need text that specifies: >>> > >>> > (i) that a data-node path match succeeds if it matches the path prefix >>> from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and >>> all of foo's descendant children nodes. >>> >>> Strongly agree. >>> >>> >> >> I do not see how the text can be interpreted this way. >> >> >> Because otherwise the path match part of the NACM solution is really >> broken, and the path based examples in the appendix are entirely misleading >> and wrong. The only way those examples make sense is the paths match >> descendant children nodes as well. >> >> > > IMO the text does not support this interpretation. > > The examples in B.4, and the definition of "/" matching all nodes supports > this interpretation. > > Hence, my opinion is that it is the text in 3.4.5 that is incorrectly > specified; and that the examples, definition of "/" and standard practice > are right. > > Otherwise, how did IETF manage to publish an RFC where the path based > examples are so completely wrong? Whoever wrote and reviewed those > examples clearly had a different interpretation of how these path based > ACLs worked. > > > There is nothing said about inheriting state from the parent data node. > I think no matter how the permissions are derived, one can > find examples that work better or worse because of it. > > No. If the rules apply to descendant children, all normal examples work > well (including the ones in the appendix). > > > IMO the number of rules required to implement a use-case is not > very relevant or objective criteria. > > Yes it is, particularly when the difference is between needing a 1 line > rule, and a 100+ line rule. > > > Using the previous example of /home and /home/user1, > if the user1 is given read access to /home, then (according to you) > it also has read access to every user subtree under /home. > > Instead of 1 rule per user, 2 rules are needed > > No, just 1 rule per user: > read-default=deny > group=user1, path=/home/user1, action=permit > > This is because of my two proposed changes: > > (i) that a data-node path match succeeds if it matches the path prefix > from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and > all of foo's descendant children nodes. > <- This means that you only need 1 entry instead of 100 entries. > > (ii) if a data-node rule has action "permit" then it implicitly allows > read access for all ancestor parent nodes up to the root. (I.e. to > mitigate the original change proposed on this thread.) > <- This means that you don't need a separate read rule for "/home". Read > access to that node it is implicitly given via "group=user1, > path=/home/user1, action=permit", hence meaning that the rule works the > same way as it does on an rfc6536 compliant implementation. > > > read-default=deny > group=*, path=/home, action=permit > group=user1, path=/home/user1, action=permit > > The above rules would allow access for every user to every other user. > The 2nd rule has no effect, which is counter-intuitive. > Every user dir would need 2 rules > > read-default=deny > group=*, path=/home, action=permit > group=user1, path=/home/user1, action=permit > group=*, path=/home/user1, action=deny > > There is nothing that says this is how it works. >> If it did, once could never have privileged sub-fiolders >> >> /var/log -> permit >> /var/log/apache2 -> deny >> >> >> Yes, you can, you just list the longest path first in the list of rules: >> >> (1) /var/log/apache2 -> deny >> (2) /var/log -> permit >> >> Any requests that attempt to access anything under /var/log/apache2 would >> match rule (1) and be denied. >> Any requests that attempt to access anything under /var/log, but not >> under /var/log/apache2, would fail to match rule (1), but would match rule >> (2) instead and be permitted. >> >> >> > I do not see any text in the draft or RFC 7950 that > suggests that /var/log and /var/log/apache2 represent the same data node. > > They are different data nodes, but I don't see how that is relevant. > > Thanks, > Rob > > > > > Andy > > > >> >> >> >>> > (ii) if a data-node rule has action "permit" then it implicitly allows >>> read access for all ancestor parent nodes up to the root. (I.e. to >>> mitigate the original change proposed on this thread.) >>> >>> This seems reasonable to me, although I haven't at this point evaluated >>> the suggestion in detail. In any case I think the main point both >>> regarding this and the prefix match is that this update to 6536 can't >>> make radical changes to the semantics compared to a "reasonable >>> interpretation" (hard to define, I know) of the under-specified >>> original. >>> >> >> The text does not say this at all so I do not approve of this change >> >> >> In the RFC version of the NACM this wasn't required because operation >> 'none' didn't require read access. Now read access is required even for >> operation 'none', then this change makes sense to make the NACM changes >> backwards compatible, whilst still closing the security hole. >> >> Thanks, >> Rob >> >> >> >> >>> >>> --Per >>> >>> >> >> Andy >> >> >>> > Thanks, >>> > Rob >>> > >>> > >>> >> >>> >> Thanks >>> >> >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >> > wrote: >>> >>> >>> >>> Hi Andy, >>> >>> >>> >>> It isn't clear to me whether matching a path in NACM either: >>> >>> (i) Only applies to the specific node, and not any children, or >>> >>> (ii) Applies to the specific node and all descendant children >>> nodes as well. >>> >>> >>> >>> As an example, using the tree below. if I have a rule that >>> matches path "A/B" then does that apply to only the specific node "A/B", or >>> does it also apply to all descendant children of "A/B" as >>> >>> well? >>> >>> >>> >>> In rfc6536bis-08, section "3.4.5. Data Node Access Validation", >>> step 6 states: >>> >>> >>> >>> * The rule does not have a "rule-type" defined or the >>> "rule- >>> >>> type" is "data-node" and the *"path" matches the >>> requested data node*, action node, or notification node. >>> >>> >>> >>> >>> >>> My reading of this is that it implies that the interpretation of >>> the path rule is (i), but this is not how I would normally expect an ACL >>> rule to apply in a tree like object (e.g a directory >>> >>> file system). >>> >>> >>> >>> However, the examples in Appendix B.4. imply that the path rule >>> is to be interpreted like (ii), or otherwise the example rules seem to be >>> mostly pointless. >>> >>> >>> >>> E.g. taking this example from appendix B.4: >>> >>> >>> >>> >>> >>> permit-dummy-interface >>> >>> >> http://example.com/ns/itf>> >>> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>> >>> >>> >>> read update >>> >>> permit >>> >>> >>> >>> Allow the limited and guest groups read >>> >>> and update access to the dummy interface. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If the rule is (i) then the access rule allows the client to >>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" >>> but not any child leafs/containers of that interface, >>> >>> this doesn't seem useful. >>> >>> >>> >>> Further comments inline below ... >>> >>> >>> >>> On 08/11/2017 20:05, Andy Bierman wrote: >>> >>>> Hi, >>> >>>> >>> >>>> This change has no impact on the server if /nacm/read-default >>> is "permit". >>> >>>> In that case, the extra read rules for /A and /A/B are not >>> needed. >>> >>> I agree. >>> >>> >>> >>>> An operator worried about read access should set read-default >>> to "deny". >>> >>> I agree. This is the scenario that I'm considering. >>> >>> >>> >>>> In that case, explicit rules to read /A and /A/B would be needed >>> >>>> in the new NACM. >>> >>> Yes, if the interpretation of the rule is (i) above. >>> >>> Otherwise if the interpretation is (ii) then you only need "read >>> /A" since that implies "read A/B" as well (as long as the rules are listed >>> in the correct order). >>> >>> >>> >>> >>> >>>> The deny rules would not be needed. >>> >>> Only if the interpretation of the rule is (i) above. In which >>> case the "read/write 'A/B/J' rule would not be sufficient. It would be >>> necessary to define an Xpath expressions that contains >>> >>> all children nodes as well. Perhaps 'A/B/J//*'? >>> >>> >>> >>> If the interpretation of the rule is (ii) then you would also >>> need all the explicit deny statements as well, otherwise they would be >>> allowed by the "read /A" rule above. >>> >>> >>> >>> Thanks, >>> >>> Rob >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>> Andy >>> >>>> >>> >>>> >>> >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton < >>> rwilton@cisco.com > wrote: >>> >>>> >>> >>>> Hi, >>> >>>> >>> >>>> I'm not sure about this change. >>> >>>> >>> >>>> I'm not that familiar with NACM, but if you want to give a >>> particular set of users read/write access to a subtree, but not allow them >>> to have any other access to the configuration in the >>> >>>> running datastore then with the existing RFC, that could be >>> expressed with a single rule (example in 6536bis, appendix B.4) >>> >>>> >>> >>>> With this new change, I think that you may need to >>> configure many more rules to achieve the same thing. I think that you >>> would need to give read access to the top node in the desired >>> >>>> path, and then separate explicit "deny" rules for every >>> sibling child node walking from the top of the tree down to the data node >>> that read/write access is actually being given to. The >>> >>>> example below may explain my understanding better: >>> >>>> >>> >>>> E.g. For a tree of data nodes, rooted at A, if we wanted to >>> give read/write access only to "J" subtree, and no access for the rest of >>> the tree then: >>> >>>> >>> >>>> A >>> >>>> | >>> >>>> -------------------- >>> >>>> | | | | >>> >>>> B C D E >>> >>>> | >>> >>>> ----------- >>> >>>> | | | | >>> >>>> F G H J >>> >>>> | >>> >>>> ... >>> >>>> >>> >>>> >>> >>>> In the old model, I think that the ACL rules would be 1 >>> rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> >>> >>>> In the new model, I think that the equivalent ACL rules >>> would need to be 8 rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> "read A" >>> >>>> "deny C" >>> >>>> "deny D" >>> >>>> "deny E" >>> >>>> "deny F" >>> >>>> "deny G" >>> >>>> "deny H" >>> >>>> >>> >>>> Note, I am assuming that a "path" rule matches for the >>> given path and all descendant nodes. The draft doesn't seem to be >>> particularly clear on this point (it states that the rule applies >>> >>>> when the path matches, but this would seem to be counter >>> intuitive), and perhaps it could be clarified. >>> >>>> >>> >>>> If this change is allowed, then the example in appendix B.4 >>> looks like it would need to be fixed, since the "limited-acl" probably >>> wouldn't give any access at all, unless default read >>> >>>> access had been given. >>> >>>> >>> >>>> But, possibly I'm misunderstanding how this all works! If >>> so, apologies for the noise :-) >>> >>>> >>> >>>> Thanks, >>> >>>> Rob >>> >>>> >>> >>>> >>> >>>> On 02/11/2017 14:18, Benoit Claise wrote: >>> >>>>> Dear all, >>> >>>>> >>> >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, >>> suggested by the Security AD Eric Rescola part of the IESG review, which I >>> would like to validate with the WG. See >>> >>>>> https://tools.ietf.org/rfcdif >>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt < >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>> > >>> >>>>> >>> >>>>> >>> >>>>> The NETCONF WG was cc'ed for the entire discussion. >>> >>>>> What do you think? I will draw the conclusions by Friday >>> Nov 10th. >>> >>>>> >>> >>>>> Note: If the WG is fine, the next step is to approve this >>> document. >>> >>>>> >>> >>>>> Regards, Benoit >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Netconf mailing list >>> >>>>> Netconf@ietf.org >>> >>>>> https://www.ietf.org/mailman/listinfo/netconf < >>> https://www.ietf.org/mailman/listinfo/netconf> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Netconf mailing list >>> >>> Netconf@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> > >>> > >>> > >>> > _______________________________________________ >>> > Netconf mailing list >>> > Netconf@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netconf >>> > >>> >>> >> >> > > --94eb2c0ed18e1b962f055da5032c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here are some proposed edits to mak= e the data rule consistent with the examples.
Note that this issu= e is not related to the edit in the original 1-week change.

<= /div>

sec. 3.3.5:

OLD:


=C2=A0 =C2=A0 =C2=A0 data node rule: = =C2=A0controls access for a specific data node, identified
=C2=A0= =C2=A0 =C2=A0 by its path location within the conceptual XML document for = the
=C2=A0 =C2=A0 =C2=A0 data node.


NEW:

=C2=A0 =C2=A0 =C2=A0 da= ta node rule: =C2=A0controls access for a specific data node and its descen= dants,
=C2=A0 =C2=A0 =C2=A0 identified by its path location withi= n the conceptual XML document for the
=C2=A0 =C2=A0 =C2=A0 data n= ode.


sec 3.4.5, step 6, bulle= t 2:


OLD:

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a "rul= e-type" defined or the "rule-
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0type" is "data-node" and the "path&quo= t; matches the requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0data node, action node, or notification node.
      

<=
/pre>
NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a "rule-ty=
pe" defined or the "rule-
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "data-node" and the =
"path" matches the requested
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action node, or notification n=
ode. A path is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0considered to match if the current data node is the data node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specifie=
d by the path, or is a descendant data node of this data node.
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">

appendix B.4: (2 bugs in expl=
anation)

OLD:

deny-nacm: This= rule denies the "guest" group any access to the <nacm> subtree. Note that the default namespace is only applicable because this subtree is defined in the same namespace as the <data-rule> element.

 
NEW:


  =
    deny-nacm:  This rule denies the "guest" group any access to =
the
      <nacm> subtree.



Andy



On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <rwilton= @cisco.com> wrote:
=20 =20 =20



On 10/11/2017 16:33= , Andy Bierman wrote:
=20


On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 10/11/2017 15:49, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
O= n 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is us= ed in the document to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.=C2=A0 We need to fix it so that it works in a sensible way.=C2=A0 I.e. to make the normative te= xt consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that = a data rule doesn't match child nodes then thos= e examples are completely wrong.=C2=A0 E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."=C2=A0 But If the path only strictl= y matches "/acme:interfaces/acme:interfac= e" then the admin group rule achieves nothing useful at all.=C2=A0 The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to c= reate a list entry!=C2=A0 Instead, a separate rule woul= d be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!= =C2=A0 I think that this makes "permit" data-nod= e rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some = access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify&qu= ot; would imply. Additionally,
this text in the description of the 'path'= ; leaf is consistent with the
match being a prefix match:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The special value '= ;/' refers to all possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastore contents.&qu= ot;;

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.=C2=A0 In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.=C2=A0 I.e. so the data-rule "/foo&= quot; matches "/foo" and all of foo's des= cendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.=C2=A0 Th= e only way those examples make sense is the paths match descendant children nodes as well.



IMO the text does not support this interpretation.
The examples in B.4, and the definition of "/" matching all n= odes supports this interpretation.

Hence, my opinion is that it is the text in 3.4.5 that is incorrectly specified; and that the examples, definition of "/&quo= t; and standard practice are right.

Otherwise, how did IETF manage to publish an RFC where the path based examples are so completely wrong?=C2=A0=C2=A0 Whoever wrote and r= eviewed those examples clearly had a different interpretation of how these path based ACLs worked.


There is nothing said about inheriting state from the parent data node.
I think no matter how the permissions are derived, one can
find examples that work better or worse because of it.
No.=C2=A0 If the rules apply to descendant children, all normal example= s work well (including the ones in the appendix).


IMO the number of rules required to implement a use-case is not
very relevant or objective criteria.
Yes it is, particularly when the difference is between needing a 1 line rule, and a 100+ line rule.


Using the previous example of /home and /home/user1,
if the user1 is given read access to /home, then (according to you)
it also has read access to every user subtree under /home.
Instead of 1 rule per user, 2 rules are needed
No, just 1 rule per user:
=C2=A0=C2=A0 read-default=3Ddeny
=C2=A0=C2=A0 group=3Duser1, path=3D/home/user1, action=3Dpermit

This is because of my two proposed changes:

(i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.=C2=A0 I.e. so the data-rule "/fo= o" matches "/foo" and all of foo's descendant children nodes= .
<- This means that you only need 1 entry instead of 100 entries.

(ii) if a data-node rule has action "permit" then it implicit= ly allows read access for all ancestor parent nodes up to the root.=C2=A0 (I.e. to mitigate the original change proposed on this thread.)
<- This means that you don't need a separate read rule for "/home".=C2=A0 Read access to that node it is implicitly give= n via "group=3Duser1, path=3D/home/user1, action=3Dpermit", hence m= eaning that the rule works the same way as it does on an rfc6536 compliant implementation.


=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dpermit
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1, action=3Dp= ermit

The above rules would allow access for every user to every other user.
The 2nd rule has no effect, which is counter-intuitive.
Every user dir would need 2 rules

=C2=A0 =C2=A0read-default=3Ddeny
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dpermit
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1, action= =3Dpermit
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, action=3Ddeny<= br>

There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

=C2=A0 =C2=A0 =C2=A0/var/log -> permit
=C2=A0 =C2=A0 =C2=A0/var/log/apache2 =C2=A0-&g= t; deny

Yes, you can, you just list the longest path first in the list of rules:

=C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> deny
=C2=A0 (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



I do not see any text in the draft or RFC 7950 that
suggests that /var/log and /var/log/apache2 represent the same data node.
They are different data nodes, but I don't see how that is relevant= .

Thanks,
Rob




Andy

=C2=A0

=C2=A0
= > (ii) if a data-node rule has action "permit"= then it implicitly allows read access for all ancestor parent nodes up to the root.=C2=A0 (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read ac= cess.=C2=A0 Now read access is required even for operation 'none= 9;, then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


=C2=A0
=
--Per



Andy
=C2=A0
= > Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0Hi Andy,
>>>
>>>=C2=A0 =C2=A0 =C2=A0It isn't clea= r to me whether matching a path in NACM either:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(i) Only a= pplies to the specific node, and not any children, or
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(ii) Appli= es to the specific node and all descendant children nodes as well.
>>>
>>>=C2=A0 =C2=A0 =C2=A0As an example, us= ing the tree below.=C2=A0 if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also ap= ply to all descendant children of "A/B" as
>>>=C2=A0 =C2=A0 =C2=A0well?
>>>
>>>=C2=A0 =C2=A0 =C2=A0In rfc6536bis-08,= section "3.4.5.=C2=A0 Data Node Access Validation&qu= ot;, step 6 states:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*=C2=A0 The rule does not have a "rule-type" defined or the "= ;rule-
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 type" is "data-node" and the *"path" m= atches the requested data node*, action node, or notification node.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0My reading of thi= s is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>=C2=A0 =C2=A0 =C2=A0file system).
>>>
>>>=C2=A0 =C2=A0 =C2=A0However, the exam= ples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>=C2=A0 =C2=A0 =C2=A0E.g. taking this = example from appendix B.4:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <rule>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <name>permit-dummy-interface</name&= gt;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <path xmlns:acme=3D"http://example.com/ns/itf= " <http://example.com/ns/itf>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 /acme:interfaces/acme:interface[acme:name=3D= 'dummy']
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 </path>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <access-operations>read update</access-operations>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <action>permit</action>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Allow the limited and guest groups read
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 and update access to the dummy interface.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 </comment>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 </rule>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the rule is (i= )=C2=A0 then the access rule allows the client to read the specific node "/acme:interfaces/acme:interfa= ce[acme:name=3D'dummy']" but not any child leafs/containers of that interface,
>>>=C2=A0 =C2=A0 =C2=A0this doesn't = seem useful.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Further comments = inline below ...
>>>
>>>=C2=A0 =C2=A0 =C2=A0On 08/11/2017 20:= 05, Andy Bierman wrote:
>>>>=C2=A0 =C2=A0 =C2=A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0This change h= as no impact on the server if /nacm/read-default is "permit".
>>>>=C2=A0 =C2=A0 =C2=A0In that case,= the extra read rules for /A and /A/B are not needed.
>>>=C2=A0 =C2=A0 =C2=A0I agree.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0An operator w= orried about read access should set read-default to "deny= ".
>>>=C2=A0 =C2=A0 =C2=A0I agree.=C2=A0 Th= is is the scenario that I'm considering.
>>>
>>>>=C2=A0 =C2=A0 =C2=A0In that case,= explicit rules to read /A and /A/B would be needed
>>>>=C2=A0 =C2=A0 =C2=A0in the new NA= CM.
>>>=C2=A0 =C2=A0 =C2=A0Yes, if the inter= pretation of the rule is (i) above.
>>>=C2=A0 =C2=A0 =C2=A0Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read= A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The de= ny rules would not be needed.
>>>=C2=A0 =C2=A0 =C2=A0Only if the inter= pretation of the rule is (i) above.=C2=A0 In which case the=C2= =A0 "read/write 'A/B/J' rule would not b= e sufficient.=C2=A0 It would be necessary to define an Xpath expressions that contains
>>>=C2=A0 =C2=A0 =C2=A0all children node= s as well.=C2=A0 Perhaps 'A/B/J//*'?
>>>
>>>=C2=A0 =C2=A0 =C2=A0If the interpreta= tion of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" = rule above.
>>>
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Rob
>>>
>>>
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0Andy
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On Wed, Nov 8= , 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Hi,
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I'm not sure about this change.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0With this new change, I think that you may need to configure many more rules to achieve the same thing.=C2=A0 I thi= nk that you would need to give read access to the top node in the desired
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0path, and then separate explicit "deny" rules for ever= y sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.=C2=A0 The
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0example below may explain my understanding better:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, = and no access for the rest of the tree then:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------------------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=C2=A0 =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=A0 =C2=A0 =C2=A0E
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -----------
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0 |=C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 F=C2=A0 =C2=A0G=C2=A0 H=C2=A0 J
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read/write 'A/B/J'
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read/write 'A/B/J'
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "read A"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny C"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny D"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny E"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny F"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny G"
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deny H"
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Note, I am assuming that a "path" rule matches for the give= n path and all descendant nodes.=C2=A0 The draft doesn&#= 39;t seem to be particularly clear on this point (it states that the rule applies
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified. >>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't= give any access at all, unless default read
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0access had been given.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0But, possibly I'm misunderstanding how this all works!=C2=A0 If so, apologies for the noise :-)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Thanks,
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Rob
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Dear all,
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6= 536bis-08.txt>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dfpcfioondggippe.png>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The NETCONF WG was cc'ed for the entire discussion.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0What do you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Note: If the WG is fine, the next step is to approve this document.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Regards, Benoit
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0______________________________________= _________
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Netconf mailing list
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Netconf@ietf.or= g <mailto:Netconf@ietf.org>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/netcon= f <https://www.ietf.org/mail= man/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________= ________________
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf= .org/mailman/listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________= ________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mai= lman/listinfo/netconf
>






--94eb2c0ed18e1b962f055da5032c-- From nobody Fri Nov 10 10:42:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7A128954; Fri, 10 Nov 2017 10:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 APXCzZmgIJUf; Fri, 10 Nov 2017 10:42:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A29012878D; Fri, 10 Nov 2017 10:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92832; q=dns/txt; s=iport; t=1510339338; x=1511548938; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=32HZzrJZZFqI02Odwvg0R8eZfTGOJM0Bll7OnFvSQR4=; b=CgBYQKKlaFNp3CtAqyX1nvEt7fEKkiFYo2HzoVYAHQ85ZhTD5G1MoAyq 8SRNjbBbZGiDT6n9eRItl+/DYkuHpoLVoDuvGVrXqTbeI2X4vJ8CmSuNp XoJ8uOJnIP9h012jTmWYdgZsHcjkXnY0ydO9RN8Cl3HJunuQ/0YTIEmyg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAAAH8gVa/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDB4ESbieDfoofdJANJohXhRKIZxCBfgMKGAEMhEdPAoUFGAE?= =?us-ascii?q?BAQEBAQEBAWsohR4BAQEBAgEBARgBCARHCwULCQIYIAEGAwICIQYfEQYNBgIBA?= =?us-ascii?q?ReJbwMNCBCLbJxqfoFtOiaHFQ2DSAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DNIN?= =?us-ascii?q?bgWkpC4J2gmtZgQwPBAkEEYMrgmMBBIogCoc7gW6FO4hWPYdpg2iENoR5ghVfi?= =?us-ascii?q?QgkhyCKMYI3OoEQh3CBOR84gXI0IQgdFUmCZAmCGjkcGYFOQTYBiXwCJQeCFgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.44,375,1505779200"; d="scan'208,217";a="189534" 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; 10 Nov 2017 18:42:15 +0000 Received: from [10.61.246.69] ([10.61.246.69]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAAIgE3S021751; Fri, 10 Nov 2017 18:42:14 GMT To: Andy Bierman Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> From: Robert Wilton Message-ID: <44dd6617-367c-6284-ed03-1d37b506b8dc@cisco.com> Date: Fri, 10 Nov 2017 18:42:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DB56066255E5BFFA08BCD805" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:42:24 -0000 This is a multi-part message in MIME format. --------------DB56066255E5BFFA08BCD805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/11/2017 17:45, Andy Bierman wrote: > > > On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton > wrote: > > > > On 10/11/2017 16:33, Andy Bierman wrote: >> >> >> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton > > wrote: >> >> >> >> On 10/11/2017 15:49, Andy Bierman wrote: >>> >>> >>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland >>> > wrote: >>> >>> On 2017-11-10 11:42, Robert Wilton wrote: >>> > >>> > >>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >>> >> > >>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >>> >>> >> >>> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> The term "data node" is used in the document to >>> refer to the top-level node >>> >>> of the specified object, not the entire subtree (if >>> any). >>> >>> >>> >>> The data-rule /foo does not match /foo/child1 in the >>> text below. >>> >>> The child nodes are omitted because of step 11. >>> >>> The admin has to explicitly permit individual child >>> nodes (or modules). >>> >>> This seems correct if the read-default is "deny". >>> >>> >>> >>> Should any text be added or changed to make this >>> more clear? >>> >> >>> >> I would agree with Robert that it was not entirely >>> clear that rule applied on the parent data-node does not >>> apply to the child nodes. So yes, it would help to >>> clarify it. >>> > We should be doing more than clarifying it.  We need >>> to fix it so that it works in a sensible way.  I.e. to >>> make the normative text consistent with the behaviour >>> currently described in the examples in >>> > the appendix B.4. >>> > >>> > If we follow Andy's interpretation that a data rule >>> doesn't match child nodes then those examples are >>> completely wrong.  E.g. the 4th rule is described as >>> "This rule gives the 'admin' group read-write >>> > access to all acme entries."  But If the >>> path only strictly matches >>> "/acme:interfaces/acme:interface" then the admin group >>> rule achieves nothing useful at all.  The admin is not even >>> > allowed to create an interface because they would not >>> even have permission to write to the list key 'name' >>> node required to create a list entry!  Instead, a >>> separate rule would be required for every >>> > single possible schema node under >>> "/acme:interfaces/acme:interface"! I think that this >>> makes "permit" data-node rules completely unusable. >>> >>> I strongly agree with this, and I would say that it >>> isn't only the case >>> for "permit" rules - e.g. denying some access to a >>> subtree of the data >>> model that would otherwise be permitted due to defaults >>> is at least as >>> common, and the rules would be just as unusable for that. >>> >>> Besides the examples, I think that the very use of the >>> term "match", >>> though unfortunately not defined, strongly suggests that >>> it is something >>> other than use of e.g. the term "identify" would imply. >>> Additionally, >>> this text in the description of the 'path' leaf is >>> consistent with the >>> match being a prefix match: >>> >>>        The special value '/' refers to all possible >>>        datastore contents."; >>> >>> FWIW, our NACM implementation, available to (and used >>> by) customers >>> since 2012, follows the prefix match logic, and I have >>> yet to hear of >>> any user expecting it to do otherwise. >>> >>> > To fix this properly, we need to make the data-node >>> path rule a prefix match.  In particular, we need text >>> that specifies: >>> > >>> > (i) that a data-node path match succeeds if it matches >>> the path prefix from the root of the tree.  I.e. so the >>> data-rule "/foo" matches "/foo" and all of foo's >>> descendant children nodes. >>> >>> Strongly agree. >>> >>> >>> >>> I do not see how the text can be interpreted this way. >> >> Because otherwise the path match part of the NACM solution is >> really broken, and the path based examples in the appendix >> are entirely misleading and wrong.  The only way those >> examples make sense is the paths match descendant children >> nodes as well. >> >> >> >> IMO the text does not support this interpretation. > The examples in B.4, and the definition of "/" matching all nodes > supports this interpretation. > > Hence, my opinion is that it is the text in 3.4.5 that is > incorrectly specified; and that the examples, definition of "/" > and standard practice are right. > > Otherwise, how did IETF manage to publish an RFC where the path > based examples are so completely wrong? Whoever wrote and reviewed > those examples clearly had a different interpretation of how these > path based ACLs worked. > > > > Only the examples for "update" support this interpretation since > the read-default=permit and write-default=deny in the example. Well, no.  Not with your interpretation that a path rule only applies to the specific node and not it's descendant children. A client would be allowed to write to any children nodes below the node with a path deny rule (if the deny node already exists).  They can do this as long as they have read permissions (or with RFC 6536 they don't need any access rules at all). E.g.  read-default=permit.   path rule: "/interfaces/"  - write - deny Then a client can delete "/interfaces/interface[name=eth0]/mtu" by setting the default operation to "none", and "remove" on the mtu leaf. Similarly, the "nacm:default-deny-all;" rule will also be broken. It will only prevent users from modifying the "nacm" container, then would have full access to anything below that! > > > >> There is nothing said about inheriting state from the parent data >> node. >> I think no matter how the permissions are derived, one can >> find examples that work better or worse because of it. > No.  If the rules apply to descendant children, all normal > examples work well (including the ones in the appendix). > > > > > >> IMO the number of rules required to implement a use-case is not >> very relevant or objective criteria. > Yes it is, particularly when the difference is between needing a 1 > line rule, and a 100+ line rule. > > > > Depending on how the defaults are set. > If they are set to "permit" then only "deny" rules need to be added since > access procedures do not proceed to a child node after a deny outcome > is reached. I think that NACM is completely broken if the rules only apply to the specific datanode and not their descendants. > > > >> >> Using the previous example of /home and /home/user1, >> if the user1 is given read access to /home, then (according to you) >> it also has read access to every user subtree under /home. >> Instead of 1 rule per user, 2 rules are needed > No, just 1 rule per user: >    read-default=deny >    group=user1, path=/home/user1, action=permit > > This is because of my two proposed changes: > > (i) that a data-node path match succeeds if it matches the path > prefix from the root of the tree.  I.e. so the data-rule "/foo" > matches "/foo" and all of foo's descendant children nodes. > <- This means that you only need 1 entry instead of 100 entries. > > > > > I will define a data-rule to apply to a data node if it is a > descendant or the node itself > if this is what the WG wants I don't think that any extra data-rule is required.  I think that we just need to fix the one that we have. > > > > (ii) if a data-node rule has action "permit" then it implicitly > allows read access for all ancestor parent nodes up to the root. > (I.e. to mitigate the original change proposed on this thread.) > <- This means that you don't need a separate read rule for > "/home".  Read access to that node it is implicitly given via > "group=user1, path=/home/user1, action=permit", hence meaning that > the rule works the same way as it does on an rfc6536 compliant > implementation. > >> > > > I do not agree at all that the definition of data node /home/foo > includes its ancestors > and this is brand new behavior that is not shown in the document at all. This is proposed new behavior to mitigate the change from "none" requiring no access to "none" requiring read access. > >>    read-default=deny >>    group=*, path=/home, action=permit >>    group=user1, path=/home/user1, action=permit >> >> The above rules would allow access for every user to every other >> user. >> The 2nd rule has no effect, which is counter-intuitive. >> Every user dir would need 2 rules >> >>    read-default=deny >>    group=*, path=/home, action=permit >>    group=user1, path=/home/user1, action=permit >>    group=*, path=/home/user1, action=deny >> >>> There is nothing that says this is how it works. >>> If it did, once could never have privileged sub-fiolders >>> >>>      /var/log -> permit >>>      /var/log/apache2  -> deny >> >> Yes, you can, you just list the longest path first in the >> list of rules: >> >>  (1)  /var/log/apache2  -> deny >>   (2) /var/log -> permit >> >> Any requests that attempt to access anything under >> /var/log/apache2 would match rule (1) and be denied. >> Any requests that attempt to access anything under /var/log, >> but not under /var/log/apache2, would fail to match rule (1), >> but would match rule (2) instead and be permitted. >> >> >> >> I do not see any text in the draft or RFC 7950 that >> suggests that /var/log and /var/log/apache2 represent the same >> data node. > They are different data nodes, but I don't see how that is relevant. > > > The NACM procedures refer to "the data node", not "the data node or > its descendants", But logically each data node that is accessed is checked, so implicitly the descendants will already be checked. Thanks, Rob > > > Thanks, > Rob > > > > Andy > > > >> >> >> Andy >> >>> >>> >>> > (ii) if a data-node rule has action "permit" then it >>> implicitly allows read access for all ancestor parent >>> nodes up to the root.  (I.e. to mitigate the original >>> change proposed on this thread.) >>> >>> This seems reasonable to me, although I haven't at this >>> point evaluated >>> the suggestion in detail. In any case I think the main >>> point both >>> regarding this and the prefix match is that this update >>> to 6536 can't >>> make radical changes to the semantics compared to a >>> "reasonable >>> interpretation" (hard to define, I know) of the >>> under-specified >>> original. >>> >>> >>> The text does not say this at all so I do not approve of >>> this change >> >> In the RFC version of the NACM this wasn't required because >> operation 'none' didn't require read access.  Now read access >> is required even for operation 'none', then this change makes >> sense to make the NACM changes backwards compatible, whilst >> still closing the security hole. >> >> Thanks, >> Rob >> >>> >>> >>> --Per >>> >>> >>> >>> Andy >>> >>> > Thanks, >>> > Rob >>> > >>> > >>> >> >>> >> Thanks >>> >> >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >>> >>> >> >>> wrote: >>> >>> >>> >>>     Hi Andy, >>> >>> >>> >>>     It isn't clear to me whether matching a path in >>> NACM either: >>> >>>       (i) Only applies to the specific node, and not >>> any children, or >>> >>>       (ii) Applies to the specific node and all >>> descendant children nodes as well. >>> >>> >>> >>>     As an example, using the tree below.  if I have >>> a rule that matches path "A/B" then does that apply to >>> only the specific node "A/B", or does it also apply to >>> all descendant children of "A/B" as >>> >>>     well? >>> >>> >>> >>>     In rfc6536bis-08, section "3.4.5.  Data Node >>> Access Validation", step 6 states: >>> >>> >>> >>>             *  The rule does not have a "rule-type" >>> defined or the "rule- >>> >>>                type" is "data-node" and the *"path" >>> matches the requested data node*, action node, or >>> notification node. >>> >>> >>> >>> >>> >>>     My reading of this is that it implies that the >>> interpretation of the path rule is (i), but this is not >>> how I would normally expect an ACL rule to apply in a >>> tree like object (e.g a directory >>> >>>     file system). >>> >>> >>> >>>     However, the examples in Appendix B.4. imply >>> that the path rule is to be interpreted like (ii), or >>> otherwise the example rules seem to be mostly pointless. >>> >>> >>> >>>     E.g. taking this example from appendix B.4: >>> >>> >>> >>> >>> >>> permit-dummy-interface >>> >>>              >> xmlns:acme="http://example.com/ns/itf >>> " > >>> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>> >>> >>> >>> read update >>> >>> permit >>> >>> >>> >>>                Allow the limited and guest groups read >>> >>>                and update access to the dummy interface. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>     If the rule is (i)  then the access rule allows >>> the client to read the specific node >>> "/acme:interfaces/acme:interface[acme:name='dummy']" but >>> not any child leafs/containers of that interface, >>> >>>     this doesn't seem useful. >>> >>> >>> >>>     Further comments inline below ... >>> >>> >>> >>>     On 08/11/2017 20:05, Andy Bierman wrote: >>> >>>>     Hi, >>> >>>> >>> >>>>     This change has no impact on the server if >>> /nacm/read-default is "permit". >>> >>>>     In that case, the extra read rules for /A and >>> /A/B are not needed. >>> >>>     I agree. >>> >>> >>> >>>>     An operator worried about read access should >>> set read-default to "deny". >>> >>>     I agree.  This is the scenario that I'm considering. >>> >>> >>> >>>>     In that case, explicit rules to read /A and >>> /A/B would be needed >>> >>>>     in the new NACM. >>> >>>     Yes, if the interpretation of the rule is (i) above. >>> >>>     Otherwise if the interpretation is (ii) then you >>> only need "read /A" since that implies "read A/B" as >>> well (as long as the rules are listed in the correct order). >>> >>> >>> >>> >>> >>>>       The deny rules would not be needed. >>> >>>     Only if the interpretation of the rule is (i) >>> above.  In which case the "read/write 'A/B/J' rule would >>> not be sufficient.  It would be necessary to define an >>> Xpath expressions that contains >>> >>>     all children nodes as well.  Perhaps 'A/B/J//*'? >>> >>> >>> >>>     If the interpretation of the rule is (ii) then >>> you would also need all the explicit deny statements as >>> well, otherwise they would be allowed by the "read /A" >>> rule above. >>> >>> >>> >>>     Thanks, >>> >>>     Rob >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>>     Andy >>> >>>> >>> >>>> >>> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton >>> >>> >> >>> wrote: >>> >>>> >>> >>>>         Hi, >>> >>>> >>> >>>>         I'm not sure about this change. >>> >>>> >>> >>>>         I'm not that familiar with NACM, but if you >>> want to give a particular set of users read/write access >>> to a subtree, but not allow them to have any other >>> access to the configuration in the >>> >>>>         running datastore then with the existing >>> RFC, that could be expressed with a single rule (example >>> in 6536bis, appendix B.4) >>> >>>> >>> >>>>         With this new change, I think that you may >>> need to configure many more rules to achieve the same >>> thing.  I think that you would need to give read access >>> to the top node in the desired >>> >>>>         path, and then separate explicit "deny" >>> rules for every sibling child node walking from the top >>> of the tree down to the data node that read/write access >>> is actually being given to.  The >>> >>>>         example below may explain my understanding >>> better: >>> >>>> >>> >>>>         E.g. For a tree of data nodes, rooted at A, >>> if we wanted to give read/write access only to "J" >>> subtree, and no access for the rest of the tree then: >>> >>>> >>> >>>>         A >>> >>>>         | >>> >>>>  -------------------- >>> >>>>  |      |     |     | >>> >>>>  B      C     D     E >>> >>>>                 | >>> >>>> ----------- >>> >>>>            |   | |  | >>> >>>>            F   G H  J >>> >>>>     | >>> >>>>    ... >>> >>>> >>> >>>> >>> >>>>         In the old model, I think that the ACL >>> rules would be 1 rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> >>> >>>>         In the new model, I think that the >>> equivalent ACL rules would need to be 8 rules long >>> (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>>            "read A" >>> >>>>            "deny C" >>> >>>>            "deny D" >>> >>>>            "deny E" >>> >>>>            "deny F" >>> >>>>            "deny G" >>> >>>>            "deny H" >>> >>>> >>> >>>>         Note, I am assuming that a "path" rule >>> matches for the given path and all descendant nodes.  >>> The draft doesn't seem to be particularly clear on this >>> point (it states that the rule applies >>> >>>>         when the path matches, but this would seem >>> to be counter intuitive), and perhaps it could be clarified. >>> >>>> >>> >>>>         If this change is allowed, then the example >>> in appendix B.4 looks like it would need to be fixed, >>> since the "limited-acl" probably wouldn't give any >>> access at all, unless default read >>> >>>>         access had been given. >>> >>>> >>> >>>>         But, possibly I'm misunderstanding how this >>> all works!  If so, apologies for the noise :-) >>> >>>> >>> >>>>         Thanks, >>> >>>>         Rob >>> >>>> >>> >>>> >>> >>>>         On 02/11/2017 14:18, Benoit Claise wrote: >>> >>>>>         Dear all, >>> >>>>> >>> >>>>>         Here is a major change in >>> draft-ietf-netconf-rfc6536bis, suggested by the Security >>> AD Eric Rescola part of the IESG review, which I would >>> like to validate with the WG. See >>> >>>>> >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>> >>> >> > >>> >>>>> >>> >>>>>   >>> >>>>>         The NETCONF WG was cc'ed for the entire >>> discussion. >>> >>>>>         What do you think? I will draw the >>> conclusions by Friday Nov 10th. >>> >>>>> >>> >>>>>         Note: If the WG is fine, the next step is >>> to approve this document. >>> >>>>> >>> >>>>>  Regards, Benoit >>> >>>>> >>> >>>>> >>> >>>>>  _______________________________________________ >>> >>>>>  Netconf mailing list >>> >>>>> Netconf@ietf.org >>> > >>> >>>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Netconf mailing list >>> >>> Netconf@ietf.org >>> > >>> >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >>> >> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Netconf mailing list >>> > Netconf@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netconf >>> >>> > >>> >>> >> >> > > --------------DB56066255E5BFFA08BCD805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/11/2017 17:45, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 10/11/2017 16:33, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 10/11/2017 15:49, Andy Bierman wrote:


On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote:
On 2017-11-10 11:42, Robert Wilton wrote:
>
>
> On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>>
>>> Hi,
>>>
>>> The term "data node" is used in the document to refer to the top-level node
>>> of the specified object, not the entire subtree (if any).
>>>
>>> The data-rule /foo does not match /foo/child1 in the text below.
>>> The child nodes are omitted because of step 11.
>>> The admin has to explicitly permit individual child nodes (or modules).
>>> This seems correct if the read-default is "deny".
>>>
>>> Should any text be added or changed to make this more clear?
>>
>> I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it.
> We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in
> the appendix B.4.
>
> If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify" would imply. Additionally,
this text in the description of the 'path' leaf is consistent with the
match being a prefix match:

       The special value '/' refers to all possible
       datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies:
>
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.

Strongly agree.



I do not see how the text can be interpreted this way.

Because otherwise the path match part of the NACM solution is really broken, and the path based examples in the appendix are entirely misleading and wrong.  The only way those examples make sense is the paths match descendant children nodes as well.



IMO the text does not support this interpretation.
The examples in B.4, and the definition of "/" matching all nodes supports this interpretation.

Hence, my opinion is that it is the text in 3.4.5 that is incorrectly specified; and that the examples, definition of "/" and standard practice are right.

Otherwise, how did IETF manage to publish an RFC where the path based examples are so completely wrong?   Whoever wrote and reviewed those examples clearly had a different interpretation of how these path based ACLs worked.



Only the examples for "update" support this interpretation since
the read-default=permit and write-default=deny in the example.

Well, no.  Not with your interpretation that a path rule only applies to the specific node and not it's descendant children.

A client would be allowed to write to any children nodes below the node with a path deny rule (if the deny node already exists).  They can do this as long as they have read permissions (or with RFC 6536 they don't need any access rules at all).

E.g.  read-default=permit.
  path rule: "/interfaces/"  - write - deny

Then a client can delete "/interfaces/interface[name=eth0]/mtu" by setting the default operation to "none", and "remove" on the mtu leaf.

Similarly, the "nacm:default-deny-all;" rule will also be broken.  It will only prevent users from modifying the "nacm" container, then would have full access to anything below that!





There is nothing said about inheriting state from the parent data node.
I think no matter how the permissions are derived, one can
find examples that work better or worse because of it.
No.  If the rules apply to descendant children, all normal examples work well (including the ones in the appendix).


 


IMO the number of rules required to implement a use-case is not
very relevant or objective criteria.
Yes it is, particularly when the difference is between needing a 1 line rule, and a 100+ line rule.


Depending on how the defaults are set.
If they are set to "permit" then only "deny" rules need to be added since
access procedures do not proceed to a child node after a deny outcome is reached.

I think that NACM is completely broken if the rules only apply to the specific datanode and not their descendants.




 


Using the previous example of /home and /home/user1,
if the user1 is given read access to /home, then (according to you)
it also has read access to every user subtree under /home.
Instead of 1 rule per user, 2 rules are needed
No, just 1 rule per user:
   read-default=deny
   group=user1, path=/home/user1, action=permit

This is because of my two proposed changes:

(i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.
<- This means that you only need 1 entry instead of 100 entries.




I will define a data-rule to apply to a data node if it is a descendant or the node itself
if this is what the WG wants

I don't think that any extra data-rule is required.  I think that we just need to fix the one that we have.




(ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)
<- This means that you don't need a separate read rule for "/home".  Read access to that node it is implicitly given via "group=user1, path=/home/user1, action=permit", hence meaning that the rule works the same way as it does on an rfc6536 compliant implementation.




I do not agree at all that the definition of data node /home/foo includes its ancestors
and this is brand new behavior that is not shown in the document at all.

This is proposed new behavior to mitigate the change from "none" requiring no access to "none" requiring read access.



 
   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit

The above rules would allow access for every user to every other user.
The 2nd rule has no effect, which is counter-intuitive.
Every user dir would need 2 rules

   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit
   group=*, path=/home/user1, action=deny

There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

     /var/log -> permit
     /var/log/apache2  -> deny

Yes, you can, you just list the longest path first in the list of rules:

 (1)  /var/log/apache2  -> deny
  (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not under /var/log/apache2, would fail to match rule (1), but would match rule (2) instead and be permitted.



I do not see any text in the draft or RFC 7950 that
suggests that /var/log and /var/log/apache2 represent the same data node.
They are different data nodes, but I don't see how that is relevant.

The NACM procedures refer to "the data node", not "the data node or its descendants",
But logically each data node that is accessed is checked, so implicitly the descendants will already be checked.

Thanks,
Rob



 

Thanks,
Rob


Andy

 




Andy

 

 
> (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

The text does not say this at all so I do not approve of this change

In the RFC version of the NACM this wasn't required because operation 'none' didn't require read access.  Now read access is required even for operation 'none', then this change makes sense to make the NACM changes backwards compatible, whilst still closing the security hole.

Thanks,
Rob


 

--Per



Andy
 
> Thanks,
> Rob
>
>
>>
>> Thanks
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>
>>>     Hi Andy,
>>>
>>>     It isn't clear to me whether matching a path in NACM either:
>>>       (i) Only applies to the specific node, and not any children, or
>>>       (ii) Applies to the specific node and all descendant children nodes as well.
>>>
>>>     As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as
>>>     well?
>>>
>>>     In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states:
>>>
>>>             *  The rule does not have a "rule-type" defined or the "rule-
>>>                type" is "data-node" and the *"path" matches the requested data node*, action node, or notification node.
>>>
>>>
>>>     My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory
>>>     file system).
>>>
>>>     However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>>>
>>>     E.g. taking this example from appendix B.4:
>>>
>>>            <rule>
>>>              <name>permit-dummy-interface</name>
>>>              <path xmlns:acme="http://example.com/ns/itf" <http://example.com/ns/itf>>
>>>                /acme:interfaces/acme:interface[acme:name='dummy']
>>>              </path>
>>>              <access-operations>read update</access-operations>
>>>              <action>permit</action>
>>>              <comment>
>>>                Allow the limited and guest groups read
>>>                and update access to the dummy interface.
>>>              </comment>
>>>            </rule>
>>>
>>>
>>>     If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface,
>>>     this doesn't seem useful.
>>>
>>>     Further comments inline below ...
>>>
>>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     This change has no impact on the server if /nacm/read-default is "permit".
>>>>     In that case, the extra read rules for /A and /A/B are not needed.
>>>     I agree.
>>>
>>>>     An operator worried about read access should set read-default to "deny".
>>>     I agree.  This is the scenario that I'm considering.
>>>
>>>>     In that case, explicit rules to read /A and /A/B would be needed
>>>>     in the new NACM.
>>>     Yes, if the interpretation of the rule is (i) above.
>>>     Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).
>>>
>>>
>>>>       The deny rules would not be needed.
>>>     Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains
>>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>
>>>     If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>>
>>>>
>>>>     Andy
>>>>
>>>>
>>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         I'm not sure about this change.
>>>>
>>>>         I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>         running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>         With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired
>>>>         path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The
>>>>         example below may explain my understanding better:
>>>>
>>>>         E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:
>>>>
>>>>                          A
>>>>                          |
>>>>                 --------------------
>>>>                 |      |     |     |
>>>>                 B      C     D     E
>>>>                 |
>>>>            -----------
>>>>            |   |  |  |
>>>>            F   G  H  J
>>>>                      |
>>>>                     ...
>>>>
>>>>
>>>>         In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>
>>>>         In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>            "read/write 'A/B/J'
>>>>            "read A"
>>>>            "deny C"
>>>>            "deny D"
>>>>            "deny E"
>>>>            "deny F"
>>>>            "deny G"
>>>>            "deny H"
>>>>
>>>>         Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies
>>>>         when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>>
>>>>         If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read
>>>>         access had been given.
>>>>
>>>>         But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>         Dear all,
>>>>>
>>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>>>>>
>>>>>         <dfpcfioondggippe.png>
>>>>>         The NETCONF WG was cc'ed for the entire discussion.
>>>>>         What do you think? I will draw the conclusions by Friday Nov 10th.
>>>>>
>>>>>         Note: If the WG is fine, the next step is to approve this document.
>>>>>
>>>>>         Regards, Benoit
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Netconf mailing list
>>>>>         Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>>         https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>







--------------DB56066255E5BFFA08BCD805-- From nobody Fri Nov 10 12:36:14 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D45129492; Fri, 10 Nov 2017 12:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Hxr7zK8LlMup; Fri, 10 Nov 2017 12:36:08 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3E512948D; Fri, 10 Nov 2017 12:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=115974; q=dns/txt; s=iport; t=1510346168; x=1511555768; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=kC5lypbgo8CEI3XiSTKjH+kBm9DmMdB5GP3jQKQjb2c=; b=EpffrycpK+A61ZxrqGlFSofVijQnBJ9d8kAql+7sia7zqDto/ou27FbB dGNzCAbqSDj9SJP6i9jHTcI8fEXQMUklvC5NHP/7LoHKUm9J5NILth4RM D6PpMv5e6zGvABNhZqLxZ8H9c6lgP9Fm8nDHj7UWZiK9Y4mWrkP33GzEF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAABDQZa/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCREOBEm4ng36KH3SQBC+IV4USiGcQgX4DChgBDIRHTwIahGs?= =?us-ascii?q?YAQEBAQEBAQEBayiFHgEBAQECAQEBGAEIBEcLBQsJAhggAQYDAgICHwYfEQYNB?= =?us-ascii?q?gIBAReJbwMNCBCLQ51ogW06JocUDYNIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYM?= =?us-ascii?q?0g1uBaSmDAYJrWYEMDwQJBBEtgn6CYwWKIAoWhyWBboU7iFY9h2mDaIQ2hHmCF?= =?us-ascii?q?V+JCCSHIIoxgjc6gRCHcIE5HzhCgTA0IQgdFUmCZAmCGjkcGYFOQTYBiXoCJQe?= =?us-ascii?q?CFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,376,1505779200"; d="scan'208,217";a="136989" 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; 10 Nov 2017 20:36:04 +0000 Received: from [10.61.246.69] ([10.61.246.69]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAAKa3Dh025366; Fri, 10 Nov 2017 20:36:04 GMT To: Andy Bierman Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> From: Robert Wilton Message-ID: Date: Fri, 10 Nov 2017 20:36:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------74E919E94C6981F8487363DD" Content-Language: en-US Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 20:36:14 -0000 This is a multi-part message in MIME format. --------------74E919E94C6981F8487363DD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, Yes, I think those changes look OK. In addition, in 3.3.4, does it make sense to clarify that descendant data nodes are excluded on get requests: OLD: Data nodes to which the client does not have read access are silently omitted from the message. NEW: Data nodes to which the client does not have read access are silently omitted, along with any descendants, from the message. Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate that the operation is rejected if the data node, or any ancestor parent data node, has a default-deny-write/all statement. --- I think that these changes above fix the NACM draft to make it consistent with the examples. The remaining issue is the one first raised in this thread, i.e. the change of operation 'none' now requiring 'read' permissions.  If that change is retained to mitigate the security issue, then we also need to think about how to reduce the impact of the change (i.e. the issue in my original response to this thread still applies.) Thanks, Rob On 10/11/2017 18:23, Andy Bierman wrote: > Hi, > > Here are some proposed edits to make the data rule consistent with the > examples. > Note that this issue is not related to the edit in the original 1-week > change. > > > sec. 3.3.5: > > OLD: > > >       data node rule:  controls access for a specific data node, > identified >       by its path location within the conceptual XML document for the >       data node. > > > NEW: > >       data node rule:  controls access for a specific data node and > its descendants, >       identified by its path location within the conceptual XML > document for the >       data node. > > > sec 3.4.5, step 6, bullet 2: > > > OLD: > >         *  The rule does not have a "rule-type" defined or the "rule- >            type" is "data-node" and the "path" matches the requested >            data node, action node, or notification node. > > NEW: >         *  The rule does not have a "rule-type" defined or the "rule- >            type" is "data-node" and the "path" matches the requested >            data node, action node, or notification node. A path is >            considered to match if the current data node is the data node >            specified by the path, or is a descendant data node of this > data node. > appendix B.4: (2 bugs in explanation) > OLD: > deny-nacm: This rule denies the "guest" group any access to the > subtree. Note that the default namespace is only applicable because > this subtree is defined in the same namespace as the element. > NEW: > deny-nacm: This rule denies the "guest" group any access to the > subtree. > Andy > > On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton > wrote: > > > > On 10/11/2017 16:33, Andy Bierman wrote: >> >> >> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton > > wrote: >> >> >> >> On 10/11/2017 15:49, Andy Bierman wrote: >>> >>> >>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland >>> > wrote: >>> >>> On 2017-11-10 11:42, Robert Wilton wrote: >>> > >>> > >>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >>> >> > >>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >>> >>> >> >>> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> The term "data node" is used in the document to >>> refer to the top-level node >>> >>> of the specified object, not the entire subtree (if >>> any). >>> >>> >>> >>> The data-rule /foo does not match /foo/child1 in the >>> text below. >>> >>> The child nodes are omitted because of step 11. >>> >>> The admin has to explicitly permit individual child >>> nodes (or modules). >>> >>> This seems correct if the read-default is "deny". >>> >>> >>> >>> Should any text be added or changed to make this >>> more clear? >>> >> >>> >> I would agree with Robert that it was not entirely >>> clear that rule applied on the parent data-node does not >>> apply to the child nodes. So yes, it would help to >>> clarify it. >>> > We should be doing more than clarifying it.  We need >>> to fix it so that it works in a sensible way. I.e. to >>> make the normative text consistent with the behaviour >>> currently described in the examples in >>> > the appendix B.4. >>> > >>> > If we follow Andy's interpretation that a data rule >>> doesn't match child nodes then those examples are >>> completely wrong.  E.g. the 4th rule is described as >>> "This rule gives the 'admin' group read-write >>> > access to all acme entries."  But If the >>> path only strictly matches >>> "/acme:interfaces/acme:interface" then the admin group >>> rule achieves nothing useful at all.  The admin is not even >>> > allowed to create an interface because they would not >>> even have permission to write to the list key 'name' >>> node required to create a list entry!  Instead, a >>> separate rule would be required for every >>> > single possible schema node under >>> "/acme:interfaces/acme:interface"! I think that this >>> makes "permit" data-node rules completely unusable. >>> >>> I strongly agree with this, and I would say that it >>> isn't only the case >>> for "permit" rules - e.g. denying some access to a >>> subtree of the data >>> model that would otherwise be permitted due to defaults >>> is at least as >>> common, and the rules would be just as unusable for that. >>> >>> Besides the examples, I think that the very use of the >>> term "match", >>> though unfortunately not defined, strongly suggests that >>> it is something >>> other than use of e.g. the term "identify" would imply. >>> Additionally, >>> this text in the description of the 'path' leaf is >>> consistent with the >>> match being a prefix match: >>> >>>        The special value '/' refers to all possible >>>        datastore contents."; >>> >>> FWIW, our NACM implementation, available to (and used >>> by) customers >>> since 2012, follows the prefix match logic, and I have >>> yet to hear of >>> any user expecting it to do otherwise. >>> >>> > To fix this properly, we need to make the data-node >>> path rule a prefix match.  In particular, we need text >>> that specifies: >>> > >>> > (i) that a data-node path match succeeds if it matches >>> the path prefix from the root of the tree. I.e. so the >>> data-rule "/foo" matches "/foo" and all of foo's >>> descendant children nodes. >>> >>> Strongly agree. >>> >>> >>> >>> I do not see how the text can be interpreted this way. >> >> Because otherwise the path match part of the NACM solution is >> really broken, and the path based examples in the appendix >> are entirely misleading and wrong.  The only way those >> examples make sense is the paths match descendant children >> nodes as well. >> >> >> >> IMO the text does not support this interpretation. > The examples in B.4, and the definition of "/" matching all nodes > supports this interpretation. > > Hence, my opinion is that it is the text in 3.4.5 that is > incorrectly specified; and that the examples, definition of "/" > and standard practice are right. > > Otherwise, how did IETF manage to publish an RFC where the path > based examples are so completely wrong?   Whoever wrote and > reviewed those examples clearly had a different interpretation of > how these path based ACLs worked. > > >> There is nothing said about inheriting state from the parent data >> node. >> I think no matter how the permissions are derived, one can >> find examples that work better or worse because of it. > No.  If the rules apply to descendant children, all normal > examples work well (including the ones in the appendix). > > >> IMO the number of rules required to implement a use-case is not >> very relevant or objective criteria. > Yes it is, particularly when the difference is between needing a 1 > line rule, and a 100+ line rule. > >> >> Using the previous example of /home and /home/user1, >> if the user1 is given read access to /home, then (according to you) >> it also has read access to every user subtree under /home. >> Instead of 1 rule per user, 2 rules are needed > No, just 1 rule per user: >    read-default=deny >    group=user1, path=/home/user1, action=permit > > This is because of my two proposed changes: > > (i) that a data-node path match succeeds if it matches the path > prefix from the root of the tree.  I.e. so the data-rule "/foo" > matches "/foo" and all of foo's descendant children nodes. > <- This means that you only need 1 entry instead of 100 entries. > > (ii) if a data-node rule has action "permit" then it implicitly > allows read access for all ancestor parent nodes up to the root.  > (I.e. to mitigate the original change proposed on this thread.) > <- This means that you don't need a separate read rule for > "/home".  Read access to that node it is implicitly given via > "group=user1, path=/home/user1, action=permit", hence meaning that > the rule works the same way as it does on an rfc6536 compliant > implementation. > >> >>    read-default=deny >>    group=*, path=/home, action=permit >>    group=user1, path=/home/user1, action=permit >> >> The above rules would allow access for every user to every other >> user. >> The 2nd rule has no effect, which is counter-intuitive. >> Every user dir would need 2 rules >> >>    read-default=deny >>    group=*, path=/home, action=permit >>    group=user1, path=/home/user1, action=permit >>    group=*, path=/home/user1, action=deny >> >>> There is nothing that says this is how it works. >>> If it did, once could never have privileged sub-fiolders >>> >>>      /var/log -> permit >>>      /var/log/apache2  -> deny >> >> Yes, you can, you just list the longest path first in the >> list of rules: >> >>  (1)  /var/log/apache2  -> deny >>   (2) /var/log -> permit >> >> Any requests that attempt to access anything under >> /var/log/apache2 would match rule (1) and be denied. >> Any requests that attempt to access anything under /var/log, >> but not under /var/log/apache2, would fail to match rule (1), >> but would match rule (2) instead and be permitted. >> >> >> >> I do not see any text in the draft or RFC 7950 that >> suggests that /var/log and /var/log/apache2 represent the same >> data node. > They are different data nodes, but I don't see how that is relevant. > > Thanks, > Rob > > >> >> >> Andy >> >>> >>> >>> > (ii) if a data-node rule has action "permit" then it >>> implicitly allows read access for all ancestor parent >>> nodes up to the root.  (I.e. to mitigate the original >>> change proposed on this thread.) >>> >>> This seems reasonable to me, although I haven't at this >>> point evaluated >>> the suggestion in detail. In any case I think the main >>> point both >>> regarding this and the prefix match is that this update >>> to 6536 can't >>> make radical changes to the semantics compared to a >>> "reasonable >>> interpretation" (hard to define, I know) of the >>> under-specified >>> original. >>> >>> >>> The text does not say this at all so I do not approve of >>> this change >> >> In the RFC version of the NACM this wasn't required because >> operation 'none' didn't require read access.  Now read access >> is required even for operation 'none', then this change makes >> sense to make the NACM changes backwards compatible, whilst >> still closing the security hole. >> >> Thanks, >> Rob >> >>> >>> >>> --Per >>> >>> >>> >>> Andy >>> >>> > Thanks, >>> > Rob >>> > >>> > >>> >> >>> >> Thanks >>> >> >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>> >>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >>> >>> >> >>> wrote: >>> >>> >>> >>>     Hi Andy, >>> >>> >>> >>>     It isn't clear to me whether matching a path in >>> NACM either: >>> >>>       (i) Only applies to the specific node, and not >>> any children, or >>> >>>       (ii) Applies to the specific node and all >>> descendant children nodes as well. >>> >>> >>> >>>     As an example, using the tree below.  if I have >>> a rule that matches path "A/B" then does that apply to >>> only the specific node "A/B", or does it also apply to >>> all descendant children of "A/B" as >>> >>>     well? >>> >>> >>> >>>     In rfc6536bis-08, section "3.4.5.  Data Node >>> Access Validation", step 6 states: >>> >>> >>> >>>             *  The rule does not have a "rule-type" >>> defined or the "rule- >>> >>>                type" is "data-node" and the *"path" >>> matches the requested data node*, action node, or >>> notification node. >>> >>> >>> >>> >>> >>>     My reading of this is that it implies that the >>> interpretation of the path rule is (i), but this is not >>> how I would normally expect an ACL rule to apply in a >>> tree like object (e.g a directory >>> >>>     file system). >>> >>> >>> >>>     However, the examples in Appendix B.4. imply >>> that the path rule is to be interpreted like (ii), or >>> otherwise the example rules seem to be mostly pointless. >>> >>> >>> >>>     E.g. taking this example from appendix B.4: >>> >>> >>> >>>            >>> >>> permit-dummy-interface >>> >>>              >> xmlns:acme="http://example.com/ns/itf >>> " > >>> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>> >>> >>> >>> read update >>> >>> permit >>> >>> >>> >>>                Allow the limited and guest groups read >>> >>>                and update access to the dummy interface. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>     If the rule is (i) then the access rule allows >>> the client to read the specific node >>> "/acme:interfaces/acme:interface[acme:name='dummy']" but >>> not any child leafs/containers of that interface, >>> >>>     this doesn't seem useful. >>> >>> >>> >>>     Further comments inline below ... >>> >>> >>> >>>     On 08/11/2017 20:05, Andy Bierman wrote: >>> >>>>     Hi, >>> >>>> >>> >>>>     This change has no impact on the server if >>> /nacm/read-default is "permit". >>> >>>>     In that case, the extra read rules for /A and >>> /A/B are not needed. >>> >>>     I agree. >>> >>> >>> >>>>     An operator worried about read access should >>> set read-default to "deny". >>> >>>     I agree.  This is the scenario that I'm considering. >>> >>> >>> >>>>     In that case, explicit rules to read /A and >>> /A/B would be needed >>> >>>>     in the new NACM. >>> >>>     Yes, if the interpretation of the rule is (i) above. >>> >>>     Otherwise if the interpretation is (ii) then you >>> only need "read /A" since that implies "read A/B" as >>> well (as long as the rules are listed in the correct order). >>> >>> >>> >>> >>> >>>>       The deny rules would not be needed. >>> >>>     Only if the interpretation of the rule is (i) >>> above.  In which case the "read/write 'A/B/J' rule would >>> not be sufficient.  It would be necessary to define an >>> Xpath expressions that contains >>> >>>     all children nodes as well.  Perhaps 'A/B/J//*'? >>> >>> >>> >>>     If the interpretation of the rule is (ii) then >>> you would also need all the explicit deny statements as >>> well, otherwise they would be allowed by the "read /A" >>> rule above. >>> >>> >>> >>>     Thanks, >>> >>>     Rob >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>>     Andy >>> >>>> >>> >>>> >>> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton >>> >>> >> >>> wrote: >>> >>>> >>> >>>>         Hi, >>> >>>> >>> >>>>         I'm not sure about this change. >>> >>>> >>> >>>>         I'm not that familiar with NACM, but if you >>> want to give a particular set of users read/write access >>> to a subtree, but not allow them to have any other >>> access to the configuration in the >>> >>>>         running datastore then with the existing >>> RFC, that could be expressed with a single rule (example >>> in 6536bis, appendix B.4) >>> >>>> >>> >>>>         With this new change, I think that you may >>> need to configure many more rules to achieve the same >>> thing.  I think that you would need to give read access >>> to the top node in the desired >>> >>>>         path, and then separate explicit "deny" >>> rules for every sibling child node walking from the top >>> of the tree down to the data node that read/write access >>> is actually being given to.  The >>> >>>>         example below may explain my understanding >>> better: >>> >>>> >>> >>>>         E.g. For a tree of data nodes, rooted at A, >>> if we wanted to give read/write access only to "J" >>> subtree, and no access for the rest of the tree then: >>> >>>> >>> >>>>       A >>> >>>>       | >>> >>>>  -------------------- >>> >>>>                 |     |     |     | >>> >>>>                 B     C     D     E >>> >>>>                 | >>> >>>> ----------- >>> >>>>            |   | |  | >>> >>>>            F   G H  J >>> >>>>   | >>> >>>>  ... >>> >>>> >>> >>>> >>> >>>>         In the old model, I think that the ACL >>> rules would be 1 rules long (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>> >>> >>>>         In the new model, I think that the >>> equivalent ACL rules would need to be 8 rules long >>> (assuming default deny all): >>> >>>> "read/write 'A/B/J' >>> >>>>            "read A" >>> >>>>            "deny C" >>> >>>>            "deny D" >>> >>>>            "deny E" >>> >>>>            "deny F" >>> >>>>            "deny G" >>> >>>>            "deny H" >>> >>>> >>> >>>>         Note, I am assuming that a "path" rule >>> matches for the given path and all descendant nodes.  >>> The draft doesn't seem to be particularly clear on this >>> point (it states that the rule applies >>> >>>>         when the path matches, but this would seem >>> to be counter intuitive), and perhaps it could be clarified. >>> >>>> >>> >>>>         If this change is allowed, then the example >>> in appendix B.4 looks like it would need to be fixed, >>> since the "limited-acl" probably wouldn't give any >>> access at all, unless default read >>> >>>>         access had been given. >>> >>>> >>> >>>>         But, possibly I'm misunderstanding how this >>> all works!  If so, apologies for the noise :-) >>> >>>> >>> >>>>         Thanks, >>> >>>>         Rob >>> >>>> >>> >>>> >>> >>>>         On 02/11/2017 14:18, Benoit Claise wrote: >>> >>>>>         Dear all, >>> >>>>> >>> >>>>>         Here is a major change in >>> draft-ietf-netconf-rfc6536bis, suggested by the Security >>> AD Eric Rescola part of the IESG review, which I would >>> like to validate with the WG. See >>> >>>>> >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt >>> >>> >> > >>> >>>>> >>> >>>>>   >>> >>>>>         The NETCONF WG was cc'ed for the entire >>> discussion. >>> >>>>>         What do you think? I will draw the >>> conclusions by Friday Nov 10th. >>> >>>>> >>> >>>>>         Note: If the WG is fine, the next step is >>> to approve this document. >>> >>>>> >>> >>>>>  Regards, Benoit >>> >>>>> >>> >>>>> >>> >>>>>  _______________________________________________ >>> >>>>>         Netconf mailing list >>> >>>>> Netconf@ietf.org >>> > >>> >>>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Netconf mailing list >>> >>> Netconf@ietf.org >>> > >>> >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >>> >> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Netconf mailing list >>> > Netconf@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netconf >>> >>> > >>> >>> >> >> > > --------------74E919E94C6981F8487363DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5IaSBBbmR5LDwv cD4NCiAgICA8cD5ZZXMsIEkgdGhpbmsgdGhvc2UgY2hhbmdlcyBsb29rIE9LLjwvcD4NCiAg ICA8cD5JbiBhZGRpdGlvbiwgaW4gMy4zLjQsIGRvZXMgaXQgbWFrZSBzZW5zZSB0byBjbGFy aWZ5IHRoYXQNCiAgICAgIGRlc2NlbmRhbnQgZGF0YSBub2RlcyBhcmUgZXhjbHVkZWQgb24g Z2V0IHJlcXVlc3RzOjwvcD4NCiAgICA8cD5PTEQ6PC9wPg0KICAgIDxwcmUgY2xhc3M9Im5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlh bDsiPiAgRGF0YSBub2RlcyB0byB3aGljaCB0aGUgY2xpZW50IGRvZXMgbm90IGhhdmUgcmVh ZCBhY2Nlc3MgYXJlIHNpbGVudGx5DQogICBvbWl0dGVkIGZyb20gdGhlICZsdDtycGMtcmVw bHkmZ3Q7IG1lc3NhZ2UuDQo8L3ByZT4NCiAgICA8YnI+DQogICAgTkVXOjxicj4NCiAgICA8 YnI+DQogICAgPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMz M3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3Jl OiBwYWdlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog MjsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1k ZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+ICBEYXRhIG5vZGVzIHRvIHdoaWNoIHRoZSBj bGllbnQgZG9lcyBub3QgaGF2ZSByZWFkIGFjY2VzcyBhcmUgc2lsZW50bHkNCiAgIG9taXR0 ZWQsIGFsb25nIHdpdGggYW55IGRlc2NlbmRhbnRzLCBmcm9tIHRoZSAmbHQ7cnBjLXJlcGx5 Jmd0OyBtZXNzYWdlLjwvcHJlPg0KICAgIDxicj4NCiAgICBBbHNvLCBydWxlcyA5IGFuZCAx MCBvZiAzLjQuNSBtYXkgYWxzbyBuZWVkIHRvIGJlIHVwZGF0ZWQgdG8NCiAgICBpbmRpY2F0 ZSB0aGF0IHRoZSBvcGVyYXRpb24gaXMgcmVqZWN0ZWQgaWYgdGhlIGRhdGEgbm9kZSwgb3Ig YW55DQogICAgYW5jZXN0b3IgcGFyZW50IGRhdGEgbm9kZSwgaGFzIGEgZGVmYXVsdC1kZW55 LXdyaXRlL2FsbCBzdGF0ZW1lbnQuPGJyPg0KICAgIDxicj4NCiAgICAtLS08YnI+DQogICAg PGJyPg0KICAgIEkgdGhpbmsgdGhhdCB0aGVzZSBjaGFuZ2VzIGFib3ZlIGZpeCB0aGUgTkFD TSBkcmFmdCB0byBtYWtlIGl0DQogICAgY29uc2lzdGVudCB3aXRoIHRoZSBleGFtcGxlcy48 YnI+DQogICAgPGJyPg0KICAgIFRoZSByZW1haW5pbmcgaXNzdWUgaXMgdGhlIG9uZSBmaXJz dCByYWlzZWQgaW4gdGhpcyB0aHJlYWQsIGkuZS4gdGhlDQogICAgY2hhbmdlIG9mIG9wZXJh dGlvbiAnbm9uZScgbm93IHJlcXVpcmluZyAncmVhZCcgcGVybWlzc2lvbnMuwqAgSWYNCiAg ICB0aGF0IGNoYW5nZSBpcyByZXRhaW5lZCB0byBtaXRpZ2F0ZSB0aGUgc2VjdXJpdHkgaXNz dWUsIHRoZW4gd2UgYWxzbw0KICAgIG5lZWQgdG8gdGhpbmsgYWJvdXQgaG93IHRvIHJlZHVj ZSB0aGUgaW1wYWN0IG9mIHRoZSBjaGFuZ2UgKGkuZS4gdGhlDQogICAgaXNzdWUgaW4gbXkg b3JpZ2luYWwgcmVzcG9uc2UgdG8gdGhpcyB0aHJlYWQgc3RpbGwgYXBwbGllcy4pPGJyPg0K ICAgIDxicj4NCiAgICBUaGFua3MsPGJyPg0KICAgIFJvYjxicj4NCiAgICA8YnI+DQogICAg PGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMTAvMTEvMjAxNyAx ODoyMywgQW5keSBCaWVybWFuDQogICAgICB3cm90ZTo8YnI+DQogICAgPC9kaXY+DQogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpDQUJDT0NIVEVYd2hBcTZOem9B R0hjQy1FRTE5YlhKMGticVBTMGh3SkI1XytSdE9meWdAbWFpbC5nbWFpbC5jb20iPg0KICAg ICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KICAgICAgPGRpdiBkaXI9Imx0ciI+SGksDQogICAgICAgIDxk aXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj5IZXJlIGFyZSBzb21lIHBy b3Bvc2VkIGVkaXRzIHRvIG1ha2UgdGhlIGRhdGEgcnVsZQ0KICAgICAgICAgIGNvbnNpc3Rl bnQgd2l0aCB0aGUgZXhhbXBsZXMuPC9kaXY+DQogICAgICAgIDxkaXY+Tm90ZSB0aGF0IHRo aXMgaXNzdWUgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGVkaXQgaW4gdGhlDQogICAgICAgICAg b3JpZ2luYWwgMS13ZWVrIGNoYW5nZS48L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAg ICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAg IDxkaXY+c2VjLiAzLjMuNTo8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwv ZGl2Pg0KICAgICAgICA8ZGl2Pk9MRDo8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAg ICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlIHJ1bGU6IMKg Y29udHJvbHMgYWNjZXNzIGZvciBhIHNwZWNpZmljDQogICAgICAgICAgICBkYXRhIG5vZGUs IGlkZW50aWZpZWQ8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGJ5IGl0cyBwYXRo IGxvY2F0aW9uIHdpdGhpbiB0aGUgY29uY2VwdHVhbCBYTUwNCiAgICAgICAgICAgIGRvY3Vt ZW50IGZvciB0aGU8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGRhdGEgbm9kZS48 L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rp dj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pk5F Vzo8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8 ZGl2Pg0KICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlIHJ1bGU6IMKgY29udHJv bHMgYWNjZXNzIGZvciBhIHNwZWNpZmljDQogICAgICAgICAgICBkYXRhIG5vZGUgYW5kIGl0 cyBkZXNjZW5kYW50cyw8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGlkZW50aWZp ZWQgYnkgaXRzIHBhdGggbG9jYXRpb24gd2l0aGluIHRoZQ0KICAgICAgICAgICAgY29uY2Vw dHVhbCBYTUwgZG9jdW1lbnQgZm9yIHRoZTwvZGl2Pg0KICAgICAgICAgIDxkaXY+wqAgwqAg wqAgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+ DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQog ICAgICAgIDxkaXY+c2VjIDMuNC41LCBzdGVwIDYsIGJ1bGxldCAyOjwvZGl2Pg0KICAgICAg ICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAg ICA8L2Rpdj4NCiAgICAgICAgPGRpdj5PTEQ6PC9kaXY+DQogICAgICAgIDxkaXY+DQogICAg ICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj7CoCDC oCDCoCDCoCAqIMKgVGhlIHJ1bGUgZG9lcyBub3QgaGF2ZSBhICJydWxlLXR5cGUiIGRlZmlu ZWQNCiAgICAgICAgICAgIG9yIHRoZSAicnVsZS08L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKg IMKgIMKgIMKgIMKgIMKgdHlwZSIgaXMgImRhdGEtbm9kZSIgYW5kIHRoZSAicGF0aCIgbWF0 Y2hlcw0KICAgICAgICAgICAgdGhlIHJlcXVlc3RlZDwvZGl2Pg0KICAgICAgICAgIDxkaXY+ wqAgwqAgwqAgwqAgwqAgwqBkYXRhIG5vZGUsIGFjdGlvbiBub2RlLCBvciBub3RpZmljYXRp b24gbm9kZS48L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+DQogICAgICAg ICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMz cHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+ ICAgICAgPC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5 bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTow cHg7Y29sb3I6cmdiKDAsMCwwKSI+DQo8L3ByZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJn bWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBw eDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj5ORVc6PC9wcmU+DQogICAg ICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4z MzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCww KSI+DQo8L3ByZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHls ZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBw eDtjb2xvcjpyZ2IoMCwwLDApIj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2Zv bnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNl Om5vcm1hbCI+wqAgwqAgwqAgwqAgKiDCoFRoZSBydWxlIGRvZXMgbm90IGhhdmUgYSAicnVs ZS10eXBlIiBkZWZpbmVkIG9yIHRoZSAicnVsZS08L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjpy Z2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAgwqB0eXBlIiBpcyAiZGF0 YS1ub2RlIiBhbmQgdGhlICJwYXRoIiBtYXRjaGVzIHRoZSByZXF1ZXN0ZWQ8L2Rpdj48ZGl2 IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy aWY7Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAg wqBkYXRhIG5vZGUsIGFjdGlvbiBub2RlLCBvciBub3RpZmljYXRpb24gbm9kZS4gQSBwYXRo IGlzPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTph cmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKg IMKgIMKgIMKgIMKgIMKgY29uc2lkZXJlZCB0byBtYXRjaCBpZiB0aGUgY3VycmVudCBkYXRh IG5vZGUgaXMgdGhlIGRhdGEgbm9kZTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwz NCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7d2hp dGUtc3BhY2U6bm9ybWFsIj7CoCDCoCDCoCDCoCDCoCDCoHNwZWNpZmllZCBieSB0aGUgcGF0 aCwgb3IgaXMgYSBkZXNjZW5kYW50IGRhdGEgbm9kZSBvZiB0aGlzIGRhdGEgbm9kZS48L2Rp dj48L3ByZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0i Zm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtj b2xvcjpyZ2IoMCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWls LW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21h cmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAgICAgICAg PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7 bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+YXBw ZW5kaXggQi40OiAoMiBidWdzIGluIGV4cGxhbmF0aW9uKTwvcHJlPg0KICAgICAgICAgIDxw cmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21h cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9w cmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQt c2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6 cmdiKDAsMCwwKSI+T0xEOjwvcHJlPg0KICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAgICAgICAgPHBy ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1i b3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy4zMzMzcHgiPiAgICAgIGRlbnktbmFjbTogIFRoaXMgcnVsZSBkZW5pZXMgdGhlICJn dWVzdCIgZ3JvdXAgYW55IGFjY2VzcyB0byB0aGUNCiAgICAgICZsdDtuYWNtJmd0OyBzdWJ0 cmVlLiAgTm90ZSB0aGF0IHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBpcyBvbmx5DQogICAgICBh cHBsaWNhYmxlIGJlY2F1c2UgdGhpcyBzdWJ0cmVlIGlzIGRlZmluZWQgaW4gdGhlIHNhbWUg bmFtZXNwYWNlDQogICAgICBhcyB0aGUgJmx0O2RhdGEtcnVsZSZndDsgZWxlbWVudC4NCjwv c3Bhbj48L2ZvbnQ+PC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFn ZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJv dHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+DQo8L3ByZT4NCiAgICAgICAgICA8cHJlIGNs YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv bTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjMzMzNweCI+IDwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0i Z21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4 Ij48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtm b250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij5O RVc6PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImNvbG9yOnJnYigw LDAsMCk7Zm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t OjBweCI+DQo8L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6 cmdiKDAsMCwwKTtmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1i b3R0b206MHB4Ij4NCjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJt YXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4gICAgICBkZW55LW5hY206ICBU aGlzIHJ1bGUgZGVuaWVzIHRoZSAiZ3Vlc3QiIGdyb3VwIGFueSBhY2Nlc3MgdG8gdGhlDQog ICAgICAmbHQ7bmFjbSZndDsgc3VidHJlZS4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBj bGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0 b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdw YWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxmb250IGNv bG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+DQo8L3Nw YW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJn aW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+ PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdp bi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy4zMzMzcHgiPkFuZHk8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Imdt YWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+ PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4 Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5 bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAw MDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9u dD48L3ByZT48L3ByZT4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCiAgICAgIDxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBGcmksIE5vdiAxMCwgMjAxNyBhdCA5OjI0IEFNLCBSb2JlcnQNCiAgICAg ICAgICBXaWx0b24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRv bkBjaXNjby5jb20iDQogICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90 LXNlbmQ9InRydWUiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAg ICAgd3JvdGU6PGJyPg0KICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgIDxkaXYgdGV4 dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgIDxwPjxicj4N CiAgICAgICAgICAgICAgPC9wPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg IDxkaXYgY2xhc3M9Im1fOTA2NDgyODY5NDc3OTUzMjgzOG1vei1jaXRlLXByZWZpeCI+T24N CiAgICAgICAgICAgICAgICAxMC8xMS8yMDE3IDE2OjMzLCBBbmR5IEJpZXJtYW4gd3JvdGU6 PGJyPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+PGJyPg0KICAg ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCiAgICAgICAg ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92IDEwLCAy MDE3IGF0DQogICAgICAgICAgICAgICAgICAgICAgODoxNiBBTSwgUm9iZXJ0IFdpbHRvbiA8 c3BhbiBkaXI9Imx0ciI+Jmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAg dGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5j b208L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweA0KICAgICAgICAgICAgICAgICAgICAgICAgMHB4IDBweCAwLjhl eDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2IGJnY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8 cD48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgY2xhc3M9Im1fOTA2NDgyODY5NDc3OTUzMjgzOGdt YWlsLW1fLTczNjE2NDcyODM1MjA0NTY2MzVtb3otY2l0ZS1wcmVmaXgiPk9uDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgMTAvMTEvMjAxNyAxNTo0OSwgQW5keSBCaWVybWFuIHdy b3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPjxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmks IE5vdiAxMCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDE3IGF0IDU6 MDcgQU0sIFBlciBIZWRlbGFuZCA8c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZGlyPSJsdHIiPiZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86cGVyQHRhaWwtZi5jb20iDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnBlckB0 YWlsLWYuY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRk aW5nLWxlZnQ6MWV4Ij5Pbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MjAxNy0xMS0xMCAxMTo0MiwgUm9iZXJ0IFdpbHRvbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IE9u IDEwLzExLzIwMTcgMTA6MDIsIE1haGVzaA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSmV0aGFuYW5kYW5pIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsgTWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsi DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jbzx3YnI+bTwvYT4mZ3Q7PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgT24gTm92IDEwLCAy MDE3LCBhdCAxMDowNw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQU0s IEFuZHkgQmllcm1hbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5 dW1hd29ya3MuY29tPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmx0O21haWx0bzo8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5hbmR5QHl1bWF3b3Jr cy5jb208L2E+Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm Z3Q7IEhpLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7Jmd0OyBUaGUgdGVybSAiZGF0YSBub2RlIiBpcw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdXNlZCBpbiB0aGUgZG9jdW1lbnQgdG8gcmVmZXIgdG8gdGhlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0b3AtbGV2ZWwgbm9kZTxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBvZiB0 aGUgc3BlY2lmaWVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvYmpl Y3QsIG5vdCB0aGUgZW50aXJlIHN1YnRyZWUgKGlmDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhbnkpLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyBUaGUgZGF0YS1ydWxlIC9mb28gZG9lcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IG1hdGNoIC9mb28vY2hpbGQxIGluIHRo ZSB0ZXh0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxvdy48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhl IGNoaWxkIG5vZGVzIGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg b21pdHRlZCBiZWNhdXNlIG9mIHN0ZXAgMTEuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IFRoZSBhZG1pbiBoYXMgdG8NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0bHkgcGVybWl0IGluZGl2aWR1 YWwgY2hpbGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGVzIChv ciBtb2R1bGVzKS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm Z3Q7Jmd0OyZndDsgVGhpcyBzZWVtcyBjb3JyZWN0IGlmDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0aGUgcmVhZC1kZWZhdWx0IGlzICJkZW55Ii48YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgU2hvdWxkIGFu eSB0ZXh0IGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRlZCBv ciBjaGFuZ2VkIHRvIG1ha2UgdGhpcyBtb3JlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjbGVhcj88YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsmZ3Q7IEkgd291bGQgYWdyZWUgd2l0aCBSb2JlcnQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRoYXQgaXQgd2FzIG5vdCBlbnRpcmVseSBjbGVhciB0aGF0 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlIGFwcGxpZWQgb24g dGhlIHBhcmVudCBkYXRhLW5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRvZXMgbm90IGFwcGx5IHRvIHRoZSBjaGlsZCBub2Rlcy4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNvIHllcywgaXQgd291bGQgaGVscCB0byBjbGFyaWZ5 IGl0Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgV2Ug c2hvdWxkIGJlIGRvaW5nIG1vcmUgdGhhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY2xhcmlmeWluZyBpdC7CoCBXZSBuZWVkIHRvIGZpeCBpdCBzbw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBpdCB3b3JrcyBpbiBhIHNlbnNp YmxlIHdheS7CoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSS5lLiB0 byBtYWtlIHRoZSBub3JtYXRpdmUgdGV4dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29uc2lzdGVudCB3aXRoIHRoZSBiZWhhdmlvdXINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gdGhlIGV4YW1w bGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbjxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFwcGVuZGl4IEIuNC48 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBJZiB3ZSBmb2xsb3cgQW5k eSdzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlv biB0aGF0IGEgZGF0YSBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBkb2Vzbid0IG1hdGNoIGNoaWxkIG5vZGVzIHRoZW4gdGhvc2UNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGV4YW1wbGVzIGFyZSBjb21wbGV0ZWx5IHdyb25nLsKg IEUuZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSA0dGggcnVs ZSBpcyBkZXNjcmliZWQgYXMgIlRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJ1bGUgZ2l2ZXMgdGhlICdhZG1pbicgZ3JvdXANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHJlYWQtd3JpdGU8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7IGFjY2VzcyB0byBhbGwgYWNtZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmx0O2ludGVyZmFjZSZndDsgZW50cmllcy4iwqAg QnV0IElmDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcGF0aCBv bmx5IHN0cmljdGx5IG1hdGNoZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICIvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50ZXJmYTx3YnI+Y2UiDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVuIHRoZSBhZG1pbiBncm91cCBydWxlIGFj aGlldmVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3RoaW5nIHVz ZWZ1bCBhdCBhbGwuwqAgVGhlIGFkbWluIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBub3QgZXZlbjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsgYWxsb3dlZCB0byBjcmVhdGUgYW4gaW50ZXJmYWNlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBiZWNhdXNlIHRoZXkgd291bGQgbm90IGV2ZW4g aGF2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVybWlzc2lvbiB0 byB3cml0ZSB0byB0aGUgbGlzdCBrZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICduYW1lJyBub2RlIHJlcXVpcmVkIHRvIGNyZWF0ZSBhDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBsaXN0IGVudHJ5IcKgIEluc3RlYWQsIGEgc2VwYXJh dGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGUgd291bGQgYmUg cmVxdWlyZWQgZm9yIGV2ZXJ5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyBzaW5nbGUgcG9zc2libGUgc2NoZW1hIG5vZGUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHVuZGVyICIvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50 ZXJmYTx3YnI+Y2UiIcKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ IHRoaW5rIHRoYXQgdGhpcyBtYWtlcyAicGVybWl0Ig0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGF0YS1ub2RlIHJ1bGVzIGNvbXBsZXRlbHkgdW51c2FibGUuPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSSBzdHJvbmdseSBhZ3JlZSB3aXRoIHRoaXMs IGFuZCBJDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3VsZCBzYXkg dGhhdCBpdCBpc24ndCBvbmx5IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY2FzZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv ciAicGVybWl0IiBydWxlcyAtIGUuZy4gZGVueWluZw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc29tZSBhY2Nlc3MgdG8gYSBzdWJ0cmVlIG9mIHRoZSBkYXRhPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwgdGhhdCB3b3Vs ZCBvdGhlcndpc2UgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBl cm1pdHRlZCBkdWUgdG8gZGVmYXVsdHMgaXMgYXQNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGxlYXN0IGFzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29tbW9uLCBhbmQgdGhlIHJ1bGVzIHdvdWxkIGJlIGp1c3QNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFzIHVudXNhYmxlIGZvciB0aGF0Ljxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEJlc2lkZXMgdGhlIGV4YW1wbGVzLCBJIHRoaW5r IHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSB2ZXJ5IHVz ZSBvZiB0aGUgdGVybSAibWF0Y2giLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRob3VnaCB1bmZvcnR1bmF0ZWx5IG5vdCBkZWZpbmVkLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Ryb25nbHkgc3VnZ2VzdHMgdGhhdCBpdCBp cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIgdGhhbiB1c2Ugb2Yg ZS5nLiB0aGUgdGVybQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImlk ZW50aWZ5IiB3b3VsZCBpbXBseS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFkZGl0aW9uYWxseSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0aGlzIHRleHQgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJ3BhdGgnIGxlYWYgaXMgY29uc2lzdGVudCB3aXRo IHRoZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGJl aW5nIGEgcHJlZml4IG1hdGNoOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKg IMKgIMKgVGhlIHNwZWNpYWwgdmFsdWUgJy8nIHJlZmVycw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdG8gYWxsIHBvc3NpYmxlPGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqBkYXRhc3RvcmUgY29udGVudHMuIjs8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGV0lXLCBvdXIgTkFDTSBpbXBsZW1lbnRh dGlvbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF2YWlsYWJsZSB0 byAoYW5kIHVzZWQgYnkpIGN1c3RvbWVyczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNpbmNlIDIwMTIsIGZvbGxvd3MgdGhlIHByZWZpeCBtYXRjaA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9naWMsIGFuZCBJIGhhdmUgeWV0 IHRvIGhlYXIgb2Y8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh bnkgdXNlciBleHBlY3RpbmcgaXQgdG8gZG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG90aGVyd2lzZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 IFRvIGZpeCB0aGlzIHByb3Blcmx5LCB3ZSBuZWVkDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0byBtYWtlIHRoZSBkYXRhLW5vZGUgcGF0aCBydWxlIGENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWZpeCBtYXRjaC7CoCBJbiBwYXJ0 aWN1bGFyLCB3ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmVlZCB0 ZXh0IHRoYXQgc3BlY2lmaWVzOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm Z3Q7IChpKSB0aGF0IGEgZGF0YS1ub2RlIHBhdGggbWF0Y2gNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN1Y2NlZWRzIGlmIGl0IG1hdGNoZXMgdGhlIHBhdGgNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWZpeCBmcm9tIHRoZSByb290 IG9mIHRoZSB0cmVlLsKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ LmUuIHNvIHRoZSBkYXRhLXJ1bGUgIi9mb28iIG1hdGNoZXMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICIvZm9vIiBhbmQgYWxsIG9mIGZvbydzIGRlc2NlbmRhbnQN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoaWxkcmVuIG5vZGVzLjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0cm9uZ2x5IGFncmVlLjxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIGRvIG5vdCBzZWUgaG93IHRoZSB0ZXh0 IGNhbiBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0 ZWQgdGhpcyB3YXkuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwv YmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICBCZWNhdXNlIG90aGVyd2lzZSB0aGUgcGF0aCBtYXRjaCBwYXJ0 IG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBOQUNNIHNvbHV0aW9uIGlzIHJl YWxseSBicm9rZW4sIGFuZCB0aGUgcGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICBi YXNlZCBleGFtcGxlcyBpbiB0aGUgYXBwZW5kaXggYXJlIGVudGlyZWx5DQogICAgICAgICAg ICAgICAgICAgICAgICAgIG1pc2xlYWRpbmcgYW5kIHdyb25nLsKgIFRoZSBvbmx5IHdheSB0 aG9zZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBleGFtcGxlcyBtYWtlIHNlbnNlIGlz IHRoZSBwYXRocyBtYXRjaA0KICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNjZW5kYW50 IGNoaWxkcmVuIG5vZGVzIGFzIHdlbGwuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg ICAgICAgICAgPGRpdj5JTU8gdGhlIHRleHQgZG9lcyBub3Qgc3VwcG9ydCB0aGlzDQogICAg ICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbi48L2Rpdj4NCiAgICAgICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAg ICBUaGUgZXhhbXBsZXMgaW4gQi40LCBhbmQgdGhlIGRlZmluaXRpb24gb2YgIi8iIG1hdGNo aW5nDQogICAgICAgICAgICAgIGFsbCBub2RlcyBzdXBwb3J0cyB0aGlzIGludGVycHJldGF0 aW9uLjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICBIZW5jZSwgbXkg b3BpbmlvbiBpcyB0aGF0IGl0IGlzIHRoZSB0ZXh0IGluIDMuNC41IHRoYXQgaXMNCiAgICAg ICAgICAgICAgaW5jb3JyZWN0bHkgc3BlY2lmaWVkOyBhbmQgdGhhdCB0aGUgZXhhbXBsZXMs IGRlZmluaXRpb24NCiAgICAgICAgICAgICAgb2YgIi8iIGFuZCBzdGFuZGFyZCBwcmFjdGlj ZSBhcmUgcmlnaHQuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIE90 aGVyd2lzZSwgaG93IGRpZCBJRVRGIG1hbmFnZSB0byBwdWJsaXNoIGFuIFJGQyB3aGVyZSB0 aGUNCiAgICAgICAgICAgICAgcGF0aCBiYXNlZCBleGFtcGxlcyBhcmUgc28gY29tcGxldGVs eSB3cm9uZz/CoMKgIFdob2V2ZXINCiAgICAgICAgICAgICAgd3JvdGUgYW5kIHJldmlld2Vk IHRob3NlIGV4YW1wbGVzIGNsZWFybHkgaGFkIGEgZGlmZmVyZW50DQogICAgICAgICAgICAg IGludGVycHJldGF0aW9uIG9mIGhvdyB0aGVzZSBwYXRoIGJhc2VkIEFDTHMgd29ya2VkLiA8 YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGRp cj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4N CiAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAg ICAgICAgICAgICAgICAgIDxkaXY+VGhlcmUgaXMgbm90aGluZyBzYWlkIGFib3V0IGluaGVy aXRpbmcgc3RhdGUNCiAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gdGhlIHBhcmVudCBk YXRhIG5vZGUuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIHRoaW5rIG5v IG1hdHRlciBob3cgdGhlIHBlcm1pc3Npb25zIGFyZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgZGVyaXZlZCwgb25lIGNhbjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ ZmluZCBleGFtcGxlcyB0aGF0IHdvcmsgYmV0dGVyIG9yIHdvcnNlDQogICAgICAgICAgICAg ICAgICAgICAgICBiZWNhdXNlIG9mIGl0LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIE5vLsKgIElm IHRoZSBydWxlcyBhcHBseSB0byBkZXNjZW5kYW50IGNoaWxkcmVuLCBhbGwgbm9ybWFsDQog ICAgICAgICAgICAgIGV4YW1wbGVzIHdvcmsgd2VsbCAoaW5jbHVkaW5nIHRoZSBvbmVzIGlu IHRoZSBhcHBlbmRpeCkuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg IDxicj4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAg ICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PklNTyB0aGUgbnVtYmVyIG9m IHJ1bGVzIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgICAgICAgICAgICAgICAgICAgICAg YSB1c2UtY2FzZSBpcyBub3Q8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PnZl cnkgcmVsZXZhbnQgb3Igb2JqZWN0aXZlIGNyaXRlcmlhLjwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAg IFllcyBpdCBpcywgcGFydGljdWxhcmx5IHdoZW4gdGhlIGRpZmZlcmVuY2UgaXMgYmV0d2Vl bg0KICAgICAgICAgICAgICBuZWVkaW5nIGEgMSBsaW5lIHJ1bGUsIGFuZCBhIDEwMCsgbGlu ZSBydWxlLjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICA8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAg ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAg ICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+VXNpbmcgdGhlIHByZXZpb3VzIGV4YW1wbGUgb2YgL2hvbWUg YW5kDQogICAgICAgICAgICAgICAgICAgICAgICAvaG9tZS91c2VyMSw8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgICA8ZGl2PmlmIHRoZSB1c2VyMSBpcyBnaXZlbiByZWFkIGFjY2Vz cyB0byAvaG9tZSwNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gKGFjY29yZGluZyB0 byB5b3UpPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5pdCBhbHNvIGhhcyBy ZWFkIGFjY2VzcyB0byBldmVyeSB1c2VyIHN1YnRyZWUNCiAgICAgICAgICAgICAgICAgICAg ICAgIHVuZGVyIC9ob21lLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAg ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICA8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5J bnN0ZWFkIG9mIDEgcnVsZSBwZXIgdXNlciwgMiBydWxlcyBhcmUNCiAgICAgICAgICAgICAg ICAgICAgICAgIG5lZWRlZDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIE5vLCBqdXN0IDEgcnVsZSBw ZXIgdXNlcjo8YnI+DQogICAgICAgICAgICAgIMKgwqAgcmVhZC1kZWZhdWx0PWRlbnk8YnI+ DQogICAgICAgICAgICAgIMKgwqAgZ3JvdXA9dXNlcjEsIHBhdGg9L2hvbWUvdXNlcjEsIGFj dGlvbj1wZXJtaXQ8YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgVGhp cyBpcyBiZWNhdXNlIG9mIG15IHR3byBwcm9wb3NlZCBjaGFuZ2VzOjxicj4NCiAgICAgICAg ICAgICAgPGJyPg0KICAgICAgICAgICAgICAoaSkgdGhhdCBhIGRhdGEtbm9kZSBwYXRoIG1h dGNoIHN1Y2NlZWRzIGlmIGl0IG1hdGNoZXMgdGhlDQogICAgICAgICAgICAgIHBhdGggcHJl Zml4IGZyb20gdGhlIHJvb3Qgb2YgdGhlIHRyZWUuwqAgSS5lLiBzbyB0aGUNCiAgICAgICAg ICAgICAgZGF0YS1ydWxlICIvZm9vIiBtYXRjaGVzICIvZm9vIiBhbmQgYWxsIG9mIGZvbydz DQogICAgICAgICAgICAgIGRlc2NlbmRhbnQgY2hpbGRyZW4gbm9kZXMuPGJyPg0KICAgICAg ICAgICAgICAmbHQ7LSBUaGlzIG1lYW5zIHRoYXQgeW91IG9ubHkgbmVlZCAxIGVudHJ5IGlu c3RlYWQgb2YgMTAwDQogICAgICAgICAgICAgIGVudHJpZXMuPGJyPg0KICAgICAgICAgICAg ICA8YnI+DQogICAgICAgICAgICAgIChpaSkgaWYgYSBkYXRhLW5vZGUgcnVsZSBoYXMgYWN0 aW9uICJwZXJtaXQiIHRoZW4gaXQNCiAgICAgICAgICAgICAgaW1wbGljaXRseSBhbGxvd3Mg cmVhZCBhY2Nlc3MgZm9yIGFsbCBhbmNlc3RvciBwYXJlbnQNCiAgICAgICAgICAgICAgbm9k ZXMgdXAgdG8gdGhlIHJvb3QuwqAgKEkuZS4gdG8gbWl0aWdhdGUgdGhlIG9yaWdpbmFsDQog ICAgICAgICAgICAgIGNoYW5nZSBwcm9wb3NlZCBvbiB0aGlzIHRocmVhZC4pPGJyPg0KICAg ICAgICAgICAgICAmbHQ7LSBUaGlzIG1lYW5zIHRoYXQgeW91IGRvbid0IG5lZWQgYSBzZXBh cmF0ZSByZWFkIHJ1bGUNCiAgICAgICAgICAgICAgZm9yICIvaG9tZSIuwqAgUmVhZCBhY2Nl c3MgdG8gdGhhdCBub2RlIGl0IGlzIGltcGxpY2l0bHkNCiAgICAgICAgICAgICAgZ2l2ZW4g dmlhICJncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwgYWN0aW9uPXBlcm1pdCIsDQog ICAgICAgICAgICAgIGhlbmNlIG1lYW5pbmcgdGhhdCB0aGUgcnVsZSB3b3JrcyB0aGUgc2Ft ZSB3YXkgYXMgaXQgZG9lcw0KICAgICAgICAgICAgICBvbiBhbiByZmM2NTM2IGNvbXBsaWFu dCBpbXBsZW1lbnRhdGlvbi48YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgPGRpdiBkaXI9 Imx0ciI+DQogICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQog ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgcmVhZC1kZWZhdWx0PWRlbnk8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgZ3JvdXA9KiwgcGF0aD0vaG9t ZSwgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAg wqBncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAgICAgICAg ICAgIGFjdGlvbj1wZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg ICA8ZGl2PlRoZSBhYm92ZSBydWxlcyB3b3VsZCBhbGxvdyBhY2Nlc3MgZm9yIGV2ZXJ5DQog ICAgICAgICAgICAgICAgICAgICAgICB1c2VyIHRvIGV2ZXJ5IG90aGVyIHVzZXIuPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5UaGUgMm5kIHJ1bGUgaGFzIG5vIGVmZmVj dCwgd2hpY2ggaXMNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvdW50ZXItaW50dWl0aXZl LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+RXZlcnkgdXNlciBkaXIgd291 bGQgbmVlZCAyIHJ1bGVzPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg PGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqByZWFkLWRlZmF1bHQ9 ZGVueTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoGdyb3VwPSos IHBhdGg9L2hvbWUsIGFjdGlvbj1wZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+wqAgwqBncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0q LCBwYXRoPS9ob21lL3VzZXIxLCBhY3Rpb249ZGVueTxicj4NCiAgICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4DQogICAgICAgICAgICAg ICAgICAgICAgICAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAg ICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4N CiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5UaGVyZSBpcyBub3RoaW5nIHRoYXQg c2F5cyB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBob3cg aXQgd29ya3MuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp dj5JZiBpdCBkaWQsIG9uY2UgY291bGQgbmV2ZXIgaGF2ZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcHJpdmlsZWdlZCBzdWItZmlvbGRlcnM8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2PsKgIMKgIMKgL3Zhci9sb2cgLSZndDsgcGVybWl0PC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoC92YXIvbG9nL2Fw YWNoZTIgwqAtJmd0OyBkZW55PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBZZXMsIHlvdSBjYW4sIHlvdSBqdXN0IGxpc3QgdGhl IGxvbmdlc3QgcGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICBmaXJzdCBpbiB0aGUg bGlzdCBvZiBydWxlczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgwqAoMSnCoCAvdmFyL2xvZy9hcGFjaGUyIMKgLSZn dDsgZGVueTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgKDIpIC92YXIvbG9n IC0mZ3Q7IHBlcm1pdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBBbnkgcmVxdWVzdHMgdGhhdCBhdHRlbXB0IHRvIGFj Y2VzcyBhbnl0aGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlciAvdmFyL2xv Zy9hcGFjaGUyIHdvdWxkIG1hdGNoIHJ1bGUgKDEpDQogICAgICAgICAgICAgICAgICAgICAg ICAgIGFuZCBiZSBkZW5pZWQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbnkg cmVxdWVzdHMgdGhhdCBhdHRlbXB0IHRvIGFjY2VzcyBhbnl0aGluZw0KICAgICAgICAgICAg ICAgICAgICAgICAgICB1bmRlciAvdmFyL2xvZywgYnV0IG5vdCB1bmRlcg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAvdmFyL2xvZy9hcGFjaGUyLCB3b3VsZCBmYWlsIHRvIG1hdGNo IHJ1bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKDEpLCBidXQgd291bGQgbWF0Y2gg cnVsZSAoMikgaW5zdGVhZCBhbmQgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgcGVy bWl0dGVkLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAg ICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg ICAgICAgICAgICAgICAgPGRpdj5JIGRvIG5vdCBzZWUgYW55IHRleHQgaW4gdGhlIGRyYWZ0 IG9yIFJGQw0KICAgICAgICAgICAgICAgICAgICAgICAgNzk1MCB0aGF0PC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgPGRpdj5zdWdnZXN0cyB0aGF0IC92YXIvbG9nIGFuZCAvdmFy L2xvZy9hcGFjaGUyDQogICAgICAgICAgICAgICAgICAgICAgICByZXByZXNlbnQgdGhlIHNh bWUgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIFRoZXkgYXJlIGRpZmZlcmVudCBk YXRhIG5vZGVzLCBidXQgSSBkb24ndCBzZWUgaG93IHRoYXQgaXMNCiAgICAgICAgICAgICAg cmVsZXZhbnQuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIFRoYW5r cyw8YnI+DQogICAgICAgICAgICAgIFJvYjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAg PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRp dj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgPGRpdj5BbmR5PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+ DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg PGRpdj7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHgNCiAgICAgICAgICAgICAgICAgICAg ICAgIDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkDQogICAgICAgICAgICAg ICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2PsKgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgKGlpKSBpZiBhIGRhdGEt bm9kZSBydWxlIGhhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0 aW9uICJwZXJtaXQiIHRoZW4gaXQgaW1wbGljaXRseQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYWxsb3dzIHJlYWQgYWNjZXNzIGZvciBhbGwgYW5jZXN0b3INCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmVudCBub2RlcyB1cCB0byB0 aGUgcm9vdC7CoCAoSS5lLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dG8gbWl0aWdhdGUgdGhlIG9yaWdpbmFsIGNoYW5nZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJvcG9zZWQgb24gdGhpcyB0aHJlYWQuKTxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoaXMgc2VlbXMgcmVhc29uYWJsZSB0byBtZSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsdGhvdWdoIEkgaGF2ZW4ndCBhdCB0aGlz IHBvaW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBldmFsdWF0ZWQ8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc3VnZ2VzdGlv biBpbiBkZXRhaWwuIEluIGFueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgY2FzZSBJIHRoaW5rIHRoZSBtYWluIHBvaW50IGJvdGg8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZWdhcmRpbmcgdGhpcyBhbmQgdGhlIHByZWZpeCBt YXRjaA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgdGhhdCB0aGlz IHVwZGF0ZSB0byA2NTM2IGNhbid0PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbWFrZSByYWRpY2FsIGNoYW5nZXMgdG8gdGhlDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzZW1hbnRpY3MgY29tcGFyZWQgdG8gYSAicmVhc29uYWJs ZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGF0 aW9uIiAoaGFyZCB0byBkZWZpbmUsIEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGtub3cpIG9mIHRoZSB1bmRlci1zcGVjaWZpZWQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBvcmlnaW5hbC48YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhl IHRleHQgZG9lcyBub3Qgc2F5IHRoaXMgYXQgYWxsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzbyBJIGRvIG5vdCBhcHByb3ZlIG9mIHRoaXMgY2hhbmdlPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBJ biB0aGUgUkZDIHZlcnNpb24gb2YgdGhlIE5BQ00gdGhpcyB3YXNuJ3QNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgcmVxdWlyZWQgYmVjYXVzZSBvcGVyYXRpb24gJ25vbmUnIGRpZG4n dA0KICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlIHJlYWQgYWNjZXNzLsKgIE5v dyByZWFkIGFjY2VzcyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlZCBl dmVuIGZvciBvcGVyYXRpb24gJ25vbmUnLCB0aGVuIHRoaXMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgY2hhbmdlIG1ha2VzIHNlbnNlIHRvIG1ha2UgdGhlIE5BQ00gY2hhbmdlcw0K ICAgICAgICAgICAgICAgICAgICAgICAgICBiYWNrd2FyZHMgY29tcGF0aWJsZSwgd2hpbHN0 IHN0aWxsIGNsb3NpbmcgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHNlY3VyaXR5 IGhvbGUuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgIFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg IFJvYjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXY+wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s ZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLVBlcjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGRpdj5BbmR5PC9kaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGRpdj7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0 OjFweCBzb2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsgUm9iPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IFRo YW5rczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 IEFuZHk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDsgT24gVGh1LCBOb3YgOSwgMjAxNyBhdA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMjo0NCBBTSwgUm9iZXJ0IFdpbHRvbiAmbHQ7PGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28u Y29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9i bGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBIaSBBbmR5LDxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSXQgaXNu J3QgY2xlYXIgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lIHdo ZXRoZXIgbWF0Y2hpbmcgYSBwYXRoIGluIE5BQ00NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGVpdGhlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoChpKSBPbmx5IGFwcGxpZXMNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBzcGVjaWZpYyBub2RlLCBh bmQgbm90IGFueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hpbGRy ZW4sIG9yPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn dDsmZ3Q7wqAgwqAgwqAgwqAoaWkpIEFwcGxpZXMgdG8NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSBzcGVjaWZpYyBub2RlIGFuZCBhbGwgZGVzY2VuZGFudA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hpbGRyZW4gbm9kZXMgYXMg d2VsbC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDvCoCDCoCDCoEFzIGFuIGV4YW1wbGUsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1c2luZyB0aGUgdHJlZSBiZWxvdy7CoCBpZiBJIGhhdmUgYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZSB0aGF0IG1hdGNoZXMgcGF0aCAi QS9CIiB0aGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2VzIHRo YXQgYXBwbHkgdG8gb25seSB0aGUgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG5vZGUgIkEvQiIsIG9yIGRvZXMgaXQgYWxzbyBhcHBseSB0bw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsIGRlc2NlbmRhbnQgY2hpbGRy ZW4gb2YgIkEvQiIgYXM8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoHdlbGw/PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJbiByZmM2NTM2YmlzLTA4LA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VjdGlvbiAiMy40LjUuwqAg RGF0YSBOb2RlIEFjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VmFsaWRhdGlvbiIsIHN0ZXAgNiBzdGF0ZXM6PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAqwqAgVGhl IHJ1bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXMgbm90IGhh dmUgYSAicnVsZS10eXBlIiBkZWZpbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvciB0aGUgInJ1bGUtPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHlwZSIgaXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJkYXRhLW5vZGUiIGFuZCB0 aGUgKiJwYXRoIiBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB0aGUgcmVxdWVzdGVkIGRhdGEgbm9kZSosIGFjdGlvbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbm9kZSwgb3Igbm90aWZpY2F0aW9uIG5vZGUuPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBN eSByZWFkaW5nIG9mIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGlzIHRoYXQgaXQgaW1wbGllcyB0aGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhdGggcnVsZSBpcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGkpLCBidXQgdGhpcyBpcyBub3QgaG93 IEkgd291bGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbGx5 IGV4cGVjdCBhbiBBQ0wgcnVsZSB0byBhcHBseQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW4gYSB0cmVlIGxpa2Ugb2JqZWN0IChlLmcgYQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZGlyZWN0b3J5PGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBmaWxlIHN5c3RlbSku PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 wqAgwqAgwqBIb3dldmVyLCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGV4YW1wbGVzIGluIEFwcGVuZGl4IEIuNC4gaW1wbHkgdGhhdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHBhdGggcnVsZSBpcyB0byBiZSBpbnRlcnBy ZXRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlrZSAoaWkpLCBv ciBvdGhlcndpc2UgdGhlIGV4YW1wbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJ1bGVzIHNlZW0gdG8gYmUgbW9zdGx5IHBvaW50bGVzcy48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEUuZy4g dGFraW5nIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1w bGUgZnJvbSBhcHBlbmRpeCBCLjQ6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgJmx0O3J1bGUmZ3Q7PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAg wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZsdDtuYW1lJmd0O3Blcm1pdC1kdW1teS1pbnRlcmZhY2UmbHQ7Lzx3YnI+bmFtZSZndDs8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvC oCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7cGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgeG1sbnM6YWNtZT0iPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL25zL2l0ZiINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vZXhhbXBsZS5jb208d2JyPi9ucy9pdGY8L2E+Ig0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0OzxhDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9u cy9pdGYiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cDovL2V4YW1wbGUuY29tL25z L2l0ZjwvYT4mZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50ZXJmYWM8 d2JyPmVbYWNtZTpuYW1lPSdkdW1teSddPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsvcGF0aCZndDs8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDC oCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O2FjY2Vz cy1vcGVyYXRpb25zJmd0O3JlYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVwZGF0ZSZsdDsvYWNjZXNzLW9wZXJhdGlvbnMmZ3Q7PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDthY3Rpb24mZ3Q7 cGVybWl0Jmx0Oy9hY3Rpb24mZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtjb21tZW50Jmd0Ozxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIEFsbG93DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgbGltaXRlZCBhbmQgZ3Vlc3QgZ3JvdXBzIHJlYWQ8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVwZGF0ZSBhY2Nl c3MgdG8gdGhlIGR1bW15DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp bnRlcmZhY2UuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0 OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZsdDsvY29tbWVudCZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy9ydWxlJmd0Ozxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSWYg dGhlIHJ1bGUgaXMgKGkpwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRoZW4gdGhlIGFjY2VzcyBydWxlIGFsbG93cyB0aGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGNsaWVudCB0byByZWFkIHRoZSBzcGVjaWZpYyBub2RlDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiL2FjbWU6aW50ZXJmYWNlcy9hY21l OmludGVyZmE8d2JyPmNlW2FjbWU6bmFtZT0nZHVtbXknXSINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJ1dCBub3QgYW55IGNoaWxkIGxlYWZzL2NvbnRhaW5lcnMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIHRoYXQgaW50ZXJmYWNl LDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0 O8KgIMKgIMKgdGhpcyBkb2Vzbid0IHNlZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVzZWZ1bC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEZ1cnRoZXIgY29tbWVudHMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlubGluZSBiZWxvdyAuLi48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoE9uIDA4 LzExLzIwMTcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwOjA1LCBB bmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgSGksPGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoFRoaXMg Y2hhbmdlIGhhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm8gaW1w YWN0IG9uIHRoZSBzZXJ2ZXIgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC9uYWNtL3JlYWQtZGVmYXVsdCBpcyAicGVybWl0Ii48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqBJbiB0aGF0 IGNhc2UsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZXh0cmEg cmVhZCBydWxlcyBmb3IgL0EgYW5kIC9BL0INCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGFyZSBub3QgbmVlZGVkLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSSBhZ3JlZS48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqBB biBvcGVyYXRvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd29ycmll ZCBhYm91dCByZWFkIGFjY2VzcyBzaG91bGQgc2V0DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZWFkLWRlZmF1bHQgdG8gImRlbnkiLjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSSBhZ3JlZS7C oCBUaGlzIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2Nl bmFyaW8gdGhhdCBJJ20gY29uc2lkZXJpbmcuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgSW4gdGhhdCBjYXNlLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhwbGljaXQgcnVsZXMgdG8g cmVhZCAvQSBhbmQgL0EvQg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg d291bGQgYmUgbmVlZGVkPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgaW4gdGhlIG5ldw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTkFDTS48YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFllcywgaWYgdGhlDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVs ZSBpcyAoaSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFib3ZlLjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8Kg IMKgIMKgT3RoZXJ3aXNlIGlmIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW50ZXJwcmV0YXRpb24gaXMgKGlpKSB0aGVuIHlvdSBvbmx5DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBuZWVkICJyZWFkIC9BIiBzaW5jZSB0aGF0IGlt cGxpZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkIEEvQiIg YXMgd2VsbCAoYXMgbG9uZyBhcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJ1bGVzIGFyZSBsaXN0ZWQgaW4gdGhlIGNvcnJlY3QNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG9yZGVyKS48YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqBUaGUgZGVueQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZXMgd291bGQgbm90IGJl IG5lZWRlZC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDvCoCDCoCDCoE9ubHkgaWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcyAoaSkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFib3ZlLsKgIEluIHdoaWNoIGNhc2UgdGhl wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkL3dyaXRlICdB L0IvSicgcnVsZSB3b3VsZCBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJlIHN1ZmZpY2llbnQuwqAgSXQgd291bGQgYmUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG5lY2Vzc2FyeSB0byBkZWZpbmUgYW4gWHBhdGgNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cHJlc3Npb25zIHRoYXQgY29udGFpbnM8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvC oCDCoCDCoGFsbCBjaGlsZHJlbiBub2Rlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYXMgd2VsbC7CoCBQZXJoYXBzICdBL0IvSi8vKic/PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJZiB0aGUN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGF0aW9uIG9m IHRoZSBydWxlIGlzIChpaSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRoZW4geW91IHdvdWxkIGFsc28gbmVlZCBhbGwgdGhlDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBleHBsaWNpdCBkZW55IHN0YXRlbWVudHMgYXMgd2VsbCwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyd2lzZSB0aGV5IHdvdWxk IGJlIGFsbG93ZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZSAicmVhZCAvQSIgcnVsZSBhYm92ZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFRoYW5rcyw8YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFJvYjxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm Z3Q7Jmd0O8KgIMKgIMKgQW5keTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgT24gV2VkLCBOb3YgOCwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTcgYXQgODozMyBBTSwg Um9iZXJ0IFdpbHRvbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9u QGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZs dDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl Zj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNv bTwvYT4mZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3Jv dGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoEhpLDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20g bm90DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXJlIGFib3V0IHRo aXMgY2hhbmdlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0aGF0IGZhbWlsaWFyIHdpdGggTkFDTSwgYnV0IGlm IHlvdQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FudCB0byBnaXZl IGEgcGFydGljdWxhciBzZXQgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVzZXJzIHJlYWQvd3JpdGUgYWNjZXNzIHRvIGENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN1YnRyZWUsIGJ1dCBub3QgYWxsb3cgdGhlbSB0byBoYXZlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbnkgb3RoZXIgYWNjZXNzIHRv IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlv biBpbiB0aGU8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBydW5uaW5nDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBkYXRhc3RvcmUgdGhlbiB3aXRoIHRoZSBleGlzdGluZw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUkZDLCB0aGF0IGNvdWxkIGJlIGV4 cHJlc3NlZCB3aXRoIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNp bmdsZSBydWxlIChleGFtcGxlIGluIDY1MzZiaXMsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhcHBlbmRpeCBCLjQpPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFdpdGgg dGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3IGNoYW5nZSwg SSB0aGluayB0aGF0IHlvdSBtYXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG5lZWQgdG8gY29uZmlndXJlIG1hbnkgbW9yZSBydWxlcyB0bw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYWNoaWV2ZSB0aGUgc2FtZSB0aGluZy7CoCBJIHRo aW5rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHlvdSB3b3Vs ZCBuZWVkIHRvIGdpdmUgcmVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYWNjZXNzIHRvIHRoZSB0b3Agbm9kZSBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRlc2lyZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBwYXRoLCBhbmQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gc2VwYXJhdGUgZXhwbGlj aXQgImRlbnkiIHJ1bGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBm b3IgZXZlcnkgc2libGluZyBjaGlsZCBub2RlIHdhbGtpbmcNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGZyb20gdGhlIHRvcCBvZiB0aGUgdHJlZSBkb3duIHRvIHRo ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGF0YSBub2RlIHRoYXQg cmVhZC93cml0ZSBhY2Nlc3MgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGFjdHVhbGx5IGJlaW5nIGdpdmVuIHRvLsKgIFRoZTxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoGV4 YW1wbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlbG93IG1heSBl eHBsYWluIG15IHVuZGVyc3RhbmRpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGJldHRlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgRS5nLiBGb3IgYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJlZSBvZiBkYXRhIG5vZGVzLCByb290 ZWQgYXQgQSwgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlIHdh bnRlZCB0byBnaXZlIHJlYWQvd3JpdGUgYWNjZXNzDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBvbmx5IHRvICJKIiBzdWJ0cmVlLCBhbmQgbm8gYWNjZXNzDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIHJlc3Qgb2YgdGhlIHRy ZWUgdGhlbjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCBBPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICDCoCDCoCDCoCB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICDCoCDCoCB8wqAgwqAgwqB8wqAgwqAgwqB8PGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgQsKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDC oCBDwqAgwqAgwqBEwqAgwqAgwqBFPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn dDvCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tLS08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgfMKgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8wqAgfDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDC oCBGwqAgwqBHwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEjCoCBK PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICDCoCB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC4uLjxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0 O8KgIMKgIMKgIMKgIMKgSW4gdGhlIG9sZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbW9kZWwsIEkgdGhpbmsgdGhhdCB0aGUgQUNMIHJ1bGVzDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB3b3VsZCBiZSAxIHJ1bGVzIGxvbmcgKGFzc3Vt aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0IGRlbnkg YWxsKTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0 OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICJyZWFkL3dyaXRlICdBL0IvSic8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgSW4g dGhlIG5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwsIEkg dGhpbmsgdGhhdCB0aGUgZXF1aXZhbGVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQUNMIHJ1bGVzIHdvdWxkIG5lZWQgdG8gYmUgOCBydWxlcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9uZyAoYXNzdW1pbmcgZGVmYXVsdCBkZW55 IGFsbCk6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn dDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAicmVhZC93cml0ZSAnQS9CL0onPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJy ZWFkIEEiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn dDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEMiPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg IMKgICJkZW55IEQiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEUiPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKg IMKgIMKgIMKgICJkZW55IEYiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEciPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg IMKgIMKgIMKgIMKgIMKgICJkZW55IEgiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE5vdGUsIEkg YW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFzc3VtaW5nIHRoYXQg YSAicGF0aCIgcnVsZSBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmb3IgdGhlIGdpdmVuIHBhdGggYW5kIGFsbA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZGVzY2VuZGFudCBub2Rlcy7CoCBUaGUgZHJhZnQgZG9lc24ndA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VlbSB0byBiZSBwYXJ0aWN1 bGFybHkgY2xlYXIgb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo aXMgcG9pbnQgKGl0IHN0YXRlcyB0aGF0IHRoZSBydWxlDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhcHBsaWVzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgd2hlbiB0aGUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGggbWF0Y2hlcywgYnV0IHRo aXMgd291bGQgc2VlbSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YmUgY291bnRlciBpbnR1aXRpdmUpLCBhbmQgcGVyaGFwcw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaXQgY291bGQgYmUgY2xhcmlmaWVkLjxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAg wqAgwqAgwqBJZiB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj aGFuZ2UgaXMgYWxsb3dlZCwgdGhlbiB0aGUgZXhhbXBsZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaW4gYXBwZW5kaXggQi40IGxvb2tzIGxpa2UgaXQgd291bGQN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gYmUgZml4ZWQs IHNpbmNlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImxpbWl0 ZWQtYWNsIiBwcm9iYWJseSB3b3VsZG4ndCBnaXZlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBhbnkgYWNjZXNzIGF0IGFsbCwgdW5sZXNzIGRlZmF1bHQNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBh Y2Nlc3MgaGFkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWVuIGdp dmVuLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBCdXQsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBwb3NzaWJseSBJJ20gbWlzdW5kZXJzdGFuZGluZyBob3cNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgYWxsIHdvcmtzIcKgIElmIHNv LCBhcG9sb2dpZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciB0 aGUgbm9pc2UgOi0pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFRoYW5rcyw8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg wqAgwqBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE9uDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAwMi8xMS8yMDE3IDE0OjE4LCBCZW5vaXQgQ2xhaXNlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKg IMKgIMKgIMKgRGVhcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxs LDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0 OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoEhlcmUgaXMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGEgbWFqb3IgY2hhbmdlIGluDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcywN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Z2dlc3RlZCBieSB0aGUg U2VjdXJpdHkgQUQgRXJpYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UmVzY29sYSBwYXJ0IG9mIHRoZSBJRVNHIHJldmlldywNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdoaWNoIEkgd291bGQgbGlrZSB0byB2YWxpZGF0ZSB3aXRoDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgV0cuIFNlZTxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 wqAgwqAgwqAgwqAgwqA8YQ0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0Ig0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8t bm90LXNlbmQ9InRydWUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmPHdicj5mP3Vy bDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY8d2JyPjUzNmJpcy0wOC50eHQ8L2E+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCmhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2 YmlzLTA4LnR4dCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmll dGYub3JnL3JmY2RpZjx3YnI+Zj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2PHdicj41 MzZiaXMtMDgudHh0PC9hPiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgJmx0O2RmcGNmaW9vbmRnZ2lwcGUu cG5nJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBUaGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE5FVENPTkYgV0cgd2FzIGNjJ2VkIGZvciB0aGUgZW50aXJlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkaXNjdXNzaW9uLjxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 wqAgwqAgwqAgwqAgwqBXaGF0IGRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB5b3UgdGhpbms/IEkgd2lsbCBkcmF3IHRoZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29uY2x1c2lvbnMgYnkgRnJpZGF5IE5vdiAxMHRoLjxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE5vdGU6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJZiB0aGUgV0cgaXMgZmluZSwgdGhlIG5leHQgc3RlcCBpcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gYXBwcm92ZSB0aGlzIGRvY3VtZW50 Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0 OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgwqBSZWdhcmRzLCBCZW5vaXQ8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvC oCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBfX19f X19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX19fPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZn dDvCoCDCoCDCoCDCoCDCoE5ldGNvbmYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqA8YQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRm Lm9yZyINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJf YmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRy dWUiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqA8YQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL25l dGNvbmY8L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGEN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl bmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9u ZXRjb25mPC9hPiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZndDsmZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19f X19fXzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7 Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ TmV0Y29uZkBpZXRmLm9yZzwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5ldGNvbmZAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsmZ3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYi DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9sPHdicj5pc3RpbmZvL25ldGNvbmY8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7Jmd0OyBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgPGENCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9 Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJn ZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvPHdicj5tPC9hPiZn dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u ZiINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2w8d2JyPmlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAg ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVv dGU+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg IDwvYmxvY2txdW90ZT4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxicj4NCiAgICAgIDwv ZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogIDwvYm9keT4NCjwvaHRtbD4N Cg== --------------74E919E94C6981F8487363DD-- From nobody Fri Nov 10 14:38:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20AE126C25 for ; Fri, 10 Nov 2017 14:38:15 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 i6UjrT6tBRPJ for ; Fri, 10 Nov 2017 14:38:11 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 5B0691200E5 for ; Fri, 10 Nov 2017 14:38:10 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id f134so4321314lfg.8 for ; Fri, 10 Nov 2017 14:38:10 -0800 (PST) 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=GAxYT9HW8+2Rbc8lWNdM4k8sZnQn5gR1AGqJetDiHOw=; b=Y075YtB9EMzEjfwZiv2OldQY4ZS+k4PwmMRu9qbb6pbIhcbDP/VFeyiq9f++G90m1V ZdSIxyKWF/v57v6zOPnhGoeTM7anNrrZm+EfFmVLKHIH0QeiI2pIldK7ajc+SbBLXrKX ckvuFAhOZvkVx5gXqGj0OuogWgpVFRQa2BcVUkyjnrO1aAYKetrFV94IytLoUDh37kqN VaB+Cn/c6yNLTUnMydz+pGPylwcaeoy26kJ3i8l9uPcoK+iJDzZdH9eC4yY00xBuqeh2 HMT1Mb13WyDXXbnSzLOtXskDWXNeSKLJF87dUu07jOCgeMnMYrtncXDEhwOMchTYskdA lGEg== 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=GAxYT9HW8+2Rbc8lWNdM4k8sZnQn5gR1AGqJetDiHOw=; b=RIP2inW/sQ8YPDMLHqQnpAen10tRTTQHKdAhk+tfVaVrLisdKavd0jj6D4ysPNkFhu 80cQL3+bGKD8xsVQKTNu3MqtmSxzXqERVJpYg6gOq9EWAoEnts/0h3xfs7rzv/cbW1ih xn2IlJID3LW1osConVLtJCxvy4m03PdQQo99wOM8GF5MNC0MQEsQCwj2DAeT+gK6abNj z0LASBqQET3VtdC44ik5m0sewW/hRshU0C/9xC+Wer02kWTWfrqCfqEPfcohf2/IxE6G CK3q9eGOxGRpFO+NzW2FMUdwPFNl3eAslOIox2jN/l3ns1zlztmn00bEXpILKzC67mYt OeVA== X-Gm-Message-State: AJaThX5xey2TeHPUjdKHFDEmGUPz/9sPCgDe6fchvbrX0tM1wZpu4HbM eq5PHo7ezW3DtpCkjFV0Rd5xNPsy72fGYFRz5yabBA== X-Google-Smtp-Source: AGs4zMbaSZA56/Q5JEZo14fpOUt+7QBfutIEO9wNg267DDpvhKPQaueQclaBdkVk9DlMIUNePL2sceA5LEvzunz7VuM= X-Received: by 10.25.228.29 with SMTP id b29mr669998lfh.107.1510353488445; Fri, 10 Nov 2017 14:38:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.15 with HTTP; Fri, 10 Nov 2017 14:38:07 -0800 (PST) In-Reply-To: References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> From: Andy Bierman Date: Fri, 10 Nov 2017 14:38:07 -0800 Message-ID: To: Robert Wilton Cc: Per Hedeland , Mahesh Jethanandani , NETCONF , "sec-ads@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e61142a16ce055da8935b" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 22:38:16 -0000 --94eb2c0e61142a16ce055da8935b Content-Type: text/plain; charset="UTF-8" On Fri, Nov 10, 2017 at 12:36 PM, Robert Wilton wrote: > Hi Andy, > > Yes, I think those changes look OK. > > In addition, in 3.3.4, does it make sense to clarify that descendant data > nodes are excluded on get requests: > > OLD: > > Data nodes to which the client does not have read access are silently > omitted from the message. > > > NEW: > > Data nodes to which the client does not have read access are silently > omitted, along with any descendants, from the message. > > > Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate that > the operation is rejected if the data node, or any ancestor parent data > node, has a default-deny-write/all statement. > > OK -- I will look through the rules for related updates > --- > > I think that these changes above fix the NACM draft to make it consistent > with the examples. > > The remaining issue is the one first raised in this thread, i.e. the > change of operation 'none' now requiring 'read' permissions. If that > change is retained to mitigate the security issue, then we also need to > think about how to reduce the impact of the change (i.e. the issue in my > original response to this thread still applies.) > > I agree now that data-rule is changed that the original change makes NACM more difficult to use. There is much less ACL maintenance required if the "none" edit-op translates to "no-check" rather than if it is a "read" request. It is very implementation-specific what instance-info can be derived from the error-tag or other error information, allowing an attacker to guess the ancestor instances (i.e, nodes where the access check is "none" instead of "read") In our server, field validation is done before instance validation in most cases, so an 'invalid-value' can be returned regardless of the instances actually existing or not. I propose that the draft revert to the old text, and a note added in the security considerations that servers should try not to expose instance information via error reporting. I think your enhancement for ancestors is not the only way to solve the "/home read permit" problem. I agree that we don't want a permit rule for read, just the user-dir path=/home/user1, operation=*, group=user1, action=permit IMO the safe way to do that is to say that a read request on a normal NP-container is implicitly granted if no rule is found to prevent it. The same free-pass is not granted to P-containers or lists (they need explicit rules). They convey data model information but NP containers do not. > Thanks, > Rob > > Andy > > On 10/11/2017 18:23, Andy Bierman wrote: > > Hi, > > Here are some proposed edits to make the data rule consistent with the > examples. > Note that this issue is not related to the edit in the original 1-week > change. > > > sec. 3.3.5: > > OLD: > > > data node rule: controls access for a specific data node, identified > by its path location within the conceptual XML document for the > data node. > > > NEW: > > data node rule: controls access for a specific data node and its > descendants, > identified by its path location within the conceptual XML document > for the > data node. > > > sec 3.4.5, step 6, bullet 2: > > > OLD: > > * The rule does not have a "rule-type" defined or the "rule- > type" is "data-node" and the "path" matches the requested > data node, action node, or notification node. > > NEW: > > * The rule does not have a "rule-type" defined or the "rule- > type" is "data-node" and the "path" matches the requested > data node, action node, or notification node. A path is > considered to match if the current data node is the data node > specified by the path, or is a descendant data node of this data node. > > appendix B.4: (2 bugs in explanation) > > OLD: > > deny-nacm: This rule denies the "guest" group any access to the > subtree. Note that the default namespace is only > applicable because this subtree is defined in the same namespace > as the element. > > NEW: > > deny-nacm: This rule denies the "guest" group any access to the > subtree. > > Andy > > > On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton wrote: > >> >> >> On 10/11/2017 16:33, Andy Bierman wrote: >> >> >> >> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton wrote: >> >>> >>> >>> On 10/11/2017 15:49, Andy Bierman wrote: >>> >>> >>> >>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland wrote: >>> >>>> On 2017-11-10 11:42, Robert Wilton wrote: >>>> > >>>> > >>>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Mahesh Jethanandani >>>> >> mjethanandani@gmail.com >>>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >>> > wrote: >>>> >> >>>> >>> Hi, >>>> >>> >>>> >>> The term "data node" is used in the document to refer to the >>>> top-level node >>>> >>> of the specified object, not the entire subtree (if any). >>>> >>> >>>> >>> The data-rule /foo does not match /foo/child1 in the text below. >>>> >>> The child nodes are omitted because of step 11. >>>> >>> The admin has to explicitly permit individual child nodes (or >>>> modules). >>>> >>> This seems correct if the read-default is "deny". >>>> >>> >>>> >>> Should any text be added or changed to make this more clear? >>>> >> >>>> >> I would agree with Robert that it was not entirely clear that rule >>>> applied on the parent data-node does not apply to the child nodes. So yes, >>>> it would help to clarify it. >>>> > We should be doing more than clarifying it. We need to fix it so >>>> that it works in a sensible way. I.e. to make the normative text >>>> consistent with the behaviour currently described in the examples in >>>> > the appendix B.4. >>>> > >>>> > If we follow Andy's interpretation that a data rule doesn't match >>>> child nodes then those examples are completely wrong. E.g. the 4th rule is >>>> described as "This rule gives the 'admin' group read-write >>>> > access to all acme entries." But If the path only >>>> strictly matches "/acme:interfaces/acme:interface" then the admin >>>> group rule achieves nothing useful at all. The admin is not even >>>> > allowed to create an interface because they would not even have >>>> permission to write to the list key 'name' node required to create a list >>>> entry! Instead, a separate rule would be required for every >>>> > single possible schema node under "/acme:interfaces/acme:interface"! >>>> I think that this makes "permit" data-node rules completely unusable. >>>> >>>> I strongly agree with this, and I would say that it isn't only the case >>>> for "permit" rules - e.g. denying some access to a subtree of the data >>>> model that would otherwise be permitted due to defaults is at least as >>>> common, and the rules would be just as unusable for that. >>>> >>>> Besides the examples, I think that the very use of the term "match", >>>> though unfortunately not defined, strongly suggests that it is something >>>> other than use of e.g. the term "identify" would imply. Additionally, >>>> this text in the description of the 'path' leaf is consistent with the >>>> match being a prefix match: >>>> >>>> The special value '/' refers to all possible >>>> datastore contents."; >>>> >>>> FWIW, our NACM implementation, available to (and used by) customers >>>> since 2012, follows the prefix match logic, and I have yet to hear of >>>> any user expecting it to do otherwise. >>>> >>>> > To fix this properly, we need to make the data-node path rule a >>>> prefix match. In particular, we need text that specifies: >>>> > >>>> > (i) that a data-node path match succeeds if it matches the path >>>> prefix from the root of the tree. I.e. so the data-rule "/foo" matches >>>> "/foo" and all of foo's descendant children nodes. >>>> >>>> Strongly agree. >>>> >>>> >>> >>> I do not see how the text can be interpreted this way. >>> >>> >>> Because otherwise the path match part of the NACM solution is really >>> broken, and the path based examples in the appendix are entirely misleading >>> and wrong. The only way those examples make sense is the paths match >>> descendant children nodes as well. >>> >>> >> >> IMO the text does not support this interpretation. >> >> The examples in B.4, and the definition of "/" matching all nodes >> supports this interpretation. >> >> Hence, my opinion is that it is the text in 3.4.5 that is incorrectly >> specified; and that the examples, definition of "/" and standard practice >> are right. >> >> Otherwise, how did IETF manage to publish an RFC where the path based >> examples are so completely wrong? Whoever wrote and reviewed those >> examples clearly had a different interpretation of how these path based >> ACLs worked. >> >> >> There is nothing said about inheriting state from the parent data node. >> I think no matter how the permissions are derived, one can >> find examples that work better or worse because of it. >> >> No. If the rules apply to descendant children, all normal examples work >> well (including the ones in the appendix). >> >> >> IMO the number of rules required to implement a use-case is not >> very relevant or objective criteria. >> >> Yes it is, particularly when the difference is between needing a 1 line >> rule, and a 100+ line rule. >> >> >> Using the previous example of /home and /home/user1, >> if the user1 is given read access to /home, then (according to you) >> it also has read access to every user subtree under /home. >> >> Instead of 1 rule per user, 2 rules are needed >> >> No, just 1 rule per user: >> read-default=deny >> group=user1, path=/home/user1, action=permit >> >> This is because of my two proposed changes: >> >> (i) that a data-node path match succeeds if it matches the path prefix >> from the root of the tree. I.e. so the data-rule "/foo" matches "/foo" and >> all of foo's descendant children nodes. >> <- This means that you only need 1 entry instead of 100 entries. >> >> (ii) if a data-node rule has action "permit" then it implicitly allows >> read access for all ancestor parent nodes up to the root. (I.e. to >> mitigate the original change proposed on this thread.) >> <- This means that you don't need a separate read rule for "/home". Read >> access to that node it is implicitly given via "group=user1, >> path=/home/user1, action=permit", hence meaning that the rule works the >> same way as it does on an rfc6536 compliant implementation. >> >> >> read-default=deny >> group=*, path=/home, action=permit >> group=user1, path=/home/user1, action=permit >> >> The above rules would allow access for every user to every other user. >> The 2nd rule has no effect, which is counter-intuitive. >> Every user dir would need 2 rules >> >> read-default=deny >> group=*, path=/home, action=permit >> group=user1, path=/home/user1, action=permit >> group=*, path=/home/user1, action=deny >> >> There is nothing that says this is how it works. >>> If it did, once could never have privileged sub-fiolders >>> >>> /var/log -> permit >>> /var/log/apache2 -> deny >>> >>> >>> Yes, you can, you just list the longest path first in the list of rules: >>> >>> (1) /var/log/apache2 -> deny >>> (2) /var/log -> permit >>> >>> Any requests that attempt to access anything under /var/log/apache2 >>> would match rule (1) and be denied. >>> Any requests that attempt to access anything under /var/log, but not >>> under /var/log/apache2, would fail to match rule (1), but would match rule >>> (2) instead and be permitted. >>> >>> >>> >> I do not see any text in the draft or RFC 7950 that >> suggests that /var/log and /var/log/apache2 represent the same data node. >> >> They are different data nodes, but I don't see how that is relevant. >> >> Thanks, >> Rob >> >> >> >> >> Andy >> >> >> >>> >>> >>> >>>> > (ii) if a data-node rule has action "permit" then it implicitly >>>> allows read access for all ancestor parent nodes up to the root. (I.e. to >>>> mitigate the original change proposed on this thread.) >>>> >>>> This seems reasonable to me, although I haven't at this point evaluated >>>> the suggestion in detail. In any case I think the main point both >>>> regarding this and the prefix match is that this update to 6536 can't >>>> make radical changes to the semantics compared to a "reasonable >>>> interpretation" (hard to define, I know) of the under-specified >>>> original. >>>> >>> >>> The text does not say this at all so I do not approve of this change >>> >>> >>> In the RFC version of the NACM this wasn't required because operation >>> 'none' didn't require read access. Now read access is required even for >>> operation 'none', then this change makes sense to make the NACM changes >>> backwards compatible, whilst still closing the security hole. >>> >>> Thanks, >>> Rob >>> >>> >>> >>> >>>> >>>> --Per >>>> >>>> >>> >>> Andy >>> >>> >>>> > Thanks, >>>> > Rob >>>> > >>>> > >>>> >> >>>> >> Thanks >>>> >> >>>> >>> >>>> >>> >>>> >>> Andy >>>> >>> >>>> >>> >>>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >>> > wrote: >>>> >>> >>>> >>> Hi Andy, >>>> >>> >>>> >>> It isn't clear to me whether matching a path in NACM either: >>>> >>> (i) Only applies to the specific node, and not any children, >>>> or >>>> >>> (ii) Applies to the specific node and all descendant children >>>> nodes as well. >>>> >>> >>>> >>> As an example, using the tree below. if I have a rule that >>>> matches path "A/B" then does that apply to only the specific node "A/B", or >>>> does it also apply to all descendant children of "A/B" as >>>> >>> well? >>>> >>> >>>> >>> In rfc6536bis-08, section "3.4.5. Data Node Access >>>> Validation", step 6 states: >>>> >>> >>>> >>> * The rule does not have a "rule-type" defined or the >>>> "rule- >>>> >>> type" is "data-node" and the *"path" matches the >>>> requested data node*, action node, or notification node. >>>> >>> >>>> >>> >>>> >>> My reading of this is that it implies that the interpretation >>>> of the path rule is (i), but this is not how I would normally expect an ACL >>>> rule to apply in a tree like object (e.g a directory >>>> >>> file system). >>>> >>> >>>> >>> However, the examples in Appendix B.4. imply that the path rule >>>> is to be interpreted like (ii), or otherwise the example rules seem to be >>>> mostly pointless. >>>> >>> >>>> >>> E.g. taking this example from appendix B.4: >>>> >>> >>>> >>> >>>> >>> permit-dummy-interface >>>> >>> >>> http://example.com/ns/itf>> >>>> >>> /acme:interfaces/acme:interface[acme:name='dummy'] >>>> >>> >>>> >>> read update >>>> >>> permit >>>> >>> >>>> >>> Allow the limited and guest groups read >>>> >>> and update access to the dummy interface. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> If the rule is (i) then the access rule allows the client to >>>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" >>>> but not any child leafs/containers of that interface, >>>> >>> this doesn't seem useful. >>>> >>> >>>> >>> Further comments inline below ... >>>> >>> >>>> >>> On 08/11/2017 20:05, Andy Bierman wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> This change has no impact on the server if /nacm/read-default >>>> is "permit". >>>> >>>> In that case, the extra read rules for /A and /A/B are not >>>> needed. >>>> >>> I agree. >>>> >>> >>>> >>>> An operator worried about read access should set read-default >>>> to "deny". >>>> >>> I agree. This is the scenario that I'm considering. >>>> >>> >>>> >>>> In that case, explicit rules to read /A and /A/B would be >>>> needed >>>> >>>> in the new NACM. >>>> >>> Yes, if the interpretation of the rule is (i) above. >>>> >>> Otherwise if the interpretation is (ii) then you only need >>>> "read /A" since that implies "read A/B" as well (as long as the rules are >>>> listed in the correct order). >>>> >>> >>>> >>> >>>> >>>> The deny rules would not be needed. >>>> >>> Only if the interpretation of the rule is (i) above. In which >>>> case the "read/write 'A/B/J' rule would not be sufficient. It would be >>>> necessary to define an Xpath expressions that contains >>>> >>> all children nodes as well. Perhaps 'A/B/J//*'? >>>> >>> >>>> >>> If the interpretation of the rule is (ii) then you would also >>>> need all the explicit deny statements as well, otherwise they would be >>>> allowed by the "read /A" rule above. >>>> >>> >>>> >>> Thanks, >>>> >>> Rob >>>> >>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton < >>>> rwilton@cisco.com > wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I'm not sure about this change. >>>> >>>> >>>> >>>> I'm not that familiar with NACM, but if you want to give a >>>> particular set of users read/write access to a subtree, but not allow them >>>> to have any other access to the configuration in the >>>> >>>> running datastore then with the existing RFC, that could >>>> be expressed with a single rule (example in 6536bis, appendix B.4) >>>> >>>> >>>> >>>> With this new change, I think that you may need to >>>> configure many more rules to achieve the same thing. I think that you >>>> would need to give read access to the top node in the desired >>>> >>>> path, and then separate explicit "deny" rules for every >>>> sibling child node walking from the top of the tree down to the data node >>>> that read/write access is actually being given to. The >>>> >>>> example below may explain my understanding better: >>>> >>>> >>>> >>>> E.g. For a tree of data nodes, rooted at A, if we wanted >>>> to give read/write access only to "J" subtree, and no access for the rest >>>> of the tree then: >>>> >>>> >>>> >>>> A >>>> >>>> | >>>> >>>> -------------------- >>>> >>>> | | | | >>>> >>>> B C D E >>>> >>>> | >>>> >>>> ----------- >>>> >>>> | | | | >>>> >>>> F G H J >>>> >>>> | >>>> >>>> ... >>>> >>>> >>>> >>>> >>>> >>>> In the old model, I think that the ACL rules would be 1 >>>> rules long (assuming default deny all): >>>> >>>> "read/write 'A/B/J' >>>> >>>> >>>> >>>> In the new model, I think that the equivalent ACL rules >>>> would need to be 8 rules long (assuming default deny all): >>>> >>>> "read/write 'A/B/J' >>>> >>>> "read A" >>>> >>>> "deny C" >>>> >>>> "deny D" >>>> >>>> "deny E" >>>> >>>> "deny F" >>>> >>>> "deny G" >>>> >>>> "deny H" >>>> >>>> >>>> >>>> Note, I am assuming that a "path" rule matches for the >>>> given path and all descendant nodes. The draft doesn't seem to be >>>> particularly clear on this point (it states that the rule applies >>>> >>>> when the path matches, but this would seem to be counter >>>> intuitive), and perhaps it could be clarified. >>>> >>>> >>>> >>>> If this change is allowed, then the example in appendix >>>> B.4 looks like it would need to be fixed, since the "limited-acl" probably >>>> wouldn't give any access at all, unless default read >>>> >>>> access had been given. >>>> >>>> >>>> >>>> But, possibly I'm misunderstanding how this all works! If >>>> so, apologies for the noise :-) >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Rob >>>> >>>> >>>> >>>> >>>> >>>> On 02/11/2017 14:18, Benoit Claise wrote: >>>> >>>>> Dear all, >>>> >>>>> >>>> >>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, >>>> suggested by the Security AD Eric Rescola part of the IESG review, which I >>>> would like to validate with the WG. See >>>> >>>>> https://tools.ietf.org/rfcdif >>>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt < >>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6 >>>> 536bis-08.txt> >>>> >>>>> >>>> >>>>> >>>> >>>>> The NETCONF WG was cc'ed for the entire discussion. >>>> >>>>> What do you think? I will draw the conclusions by Friday >>>> Nov 10th. >>>> >>>>> >>>> >>>>> Note: If the WG is fine, the next step is to approve this >>>> document. >>>> >>>>> >>>> >>>>> Regards, Benoit >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> Netconf mailing list >>>> >>>>> Netconf@ietf.org >>>> >>>>> https://www.ietf.org/mailman/listinfo/netconf < >>>> https://www.ietf.org/mailman/listinfo/netconf> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Netconf mailing list >>>> >>> Netconf@ietf.org >>>> >>> https://www.ietf.org/mailman/listinfo/netconf >>>> >> >>>> >> Mahesh Jethanandani >>>> >> mjethanandani@gmail.com >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Netconf mailing list >>>> > Netconf@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/netconf >>>> > >>>> >>>> >>> >>> >> >> > > --94eb2c0e61142a16ce055da8935b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 10, 2017 at 12:36 PM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20

Hi Andy,

Yes, I think those changes look OK.

In addition, in 3.3.4, does it make sense to clarify that descendant data nodes are excluded on get requests:

OLD:

  D=
ata nodes to which the client does not have read access are silently
   omitted from the <rpc-reply> message.

NEW:

  D=
ata nodes to which the client does not have read access are silently
   omitted, along with any descendants, from the <rpc-reply> message.=

Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate that the operation is rejected if the data node, or any ancestor parent data node, has a default-deny-write/all statement.



OK -- I will = look through the rules for related updates


=C2=A0
---

I think that these changes above fix the NACM draft to make it consistent with the examples.

The remaining issue is the one first raised in this thread, i.e. the change of operation 'none' now requiring 'read' permiss= ions.=C2=A0 If that change is retained to mitigate the security issue, then we also need to think about how to reduce the impact of the change (i.e. the issue in my original response to this thread still applies.)



I agree now t= hat data-rule is changed that the original change makes NACM more difficult= to use.
There is much less ACL maintenance required if the "= ;none" edit-op translates to "no-check"
rather tha= n if it is a "read" request.

It is very = implementation-specific what instance-info can be derived from the error-ta= g
or other error information, allowing an attacker to guess the a= ncestor instances
(i.e, nodes where the access check is "non= e" instead of "read")

In our server= , field validation is done before instance validation in most cases,
<= div>so an 'invalid-value' can be returned regardless of the instanc= es actually existing or not.

I propose that the dr= aft revert to the old text, and a note added in the security considerations=
that servers should try not to expose instance information via e= rror reporting.


I think your enhanc= ement for ancestors is not the only way to solve the "/home read permi= t" problem.
I agree that we don't want a permit rule for= read, just the user-dir

=C2=A0 =C2=A0path=3D/home= /user1, operation=3D*, group=3Duser1, action=3Dpermit

<= div>
IMO the safe way to do that is to say that a read reques= t on a normal NP-container
is implicitly granted if no rule is fo= und to prevent it.=C2=A0 The same free-pass is not granted
to P-c= ontainers or lists (they need explicit rules). They convey data model infor= mation
but NP containers do not.


=C2=A0
Thanks,
Rob



Andy
=C2=A0

On 10/11/2017 18:23= , Andy Bierman wrote:
=20
Hi,

Here are some proposed edits to make the data rule consistent with the examples.
Note that this issue is not related to the edit in the original 1-week change.


sec. 3.3.5:

OLD:


=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls access f= or a specific data node, identified
=C2=A0 =C2=A0 =C2=A0 by its path location within the concept= ual XML document for the
=C2=A0 =C2=A0 =C2=A0 data node.


NEW:

=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls access f= or a specific data node and its descendants,
=C2=A0 =C2=A0 =C2=A0 identified by its path location within = the conceptual XML document for the
=C2=A0 =C2=A0 =C2=A0 data node.


sec 3.4.5, step 6, bullet 2:


OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a= "rule-type" defined or the "rule-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "= ;data-node" and the "path" matches the requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action n= ode, or notification node.
      
          

          
NEW:

          

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a =
"rule-type" defined or the "rule-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "data-node&q=
uot; and the "path" matches the requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action node, or n=
otification node. A path is
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0considered to match if the current data node is the=
 data node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0specified by the path, or is a descendant data node of this data node=
.

          

          

          
appendix B=
.4: (2 bugs in explanation)

          

          
OLD:

          

          
      deny-nacm:  This rule denies the "guest" group=
 any access to the
      <nacm> subtree.  Note that the default namespace is only
      applicable because this subtree is defined in the same namespace
      as the <data-rule> element.


          

          
 

          
NEW:
=

     =
 deny-nacm:  This rule denies the "guest" group any access to the
      <nacm> subtree.







Andy





        

      

      


        
On Fri, Nov 10, 2017 at 9:24 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            

              


              

              

              
On
                10/11/2017 16:33, Andy Bierman wrote:

              

              

                


                  


                    
On Fri, Nov 10, 2017 at
                      8:16 AM, Robert Wilton <rwilton@cisco.com>
                      wrote:

                      

                        

                          


                          

                          

                          
On
                            10/11/2017 15:49, Andy Bierman wrote:

                          

                          

                            


                              


                                
On Fri, Nov 10,
                                  2017 at 5:07 AM, Per Hedeland <per@tail-f=
.com>
                                  wrote:

                                  
On
                                    2017-11-10 11:42, Robert Wilton
                                    wrote:

                                    >

                                    >

                                    > On 10/11/2017 10:02, Mahesh
                                    Jethanandani wrote:

                                    >>

                                    >>

                                    >>

                                    >>

                                    >> Mahesh Jethanandani

                                    >> mjethanandani@gmail.com
                                    <mailto:mjethanandani@gmail.com>

                                    >> On Nov 10, 2017, at 10:07
                                    AM, Andy Bierman <andy@yumaworks.com
                                    <mailto:andy@yumaworks.com>>
                                    wrote:

                                    >>

                                    >>> Hi,

                                    >>>

                                    >>> The term "data node&q=
uot; is
                                    used in the document to refer to the
                                    top-level node

                                    >>> of the specified
                                    object, not the entire subtree (if
                                    any).

                                    >>>

                                    >>> The data-rule /foo does
                                    not match /foo/child1 in the text
                                    below.

                                    >>> The child nodes are
                                    omitted because of step 11.

                                    >>> The admin has to
                                    explicitly permit individual child
                                    nodes (or modules).

                                    >>> This seems correct if
                                    the read-default is "deny".
                                    >>>

                                    >>> Should any text be
                                    added or changed to make this more
                                    clear?

                                    >>

                                    >> I would agree with Robert
                                    that it was not entirely clear that
                                    rule applied on the parent data-node
                                    does not apply to the child nodes.
                                    So yes, it would help to clarify it.
                                    > We should be doing more than
                                    clarifying it.=C2=A0 We need to fix it =
so
                                    that it works in a sensible way.=C2=A0
                                    I.e. to make the normative text
                                    consistent with the behaviour
                                    currently described in the examples
                                    in

                                    > the appendix B.4.

                                    >

                                    > If we follow Andy's
                                    interpretation that a data rule
                                    doesn't match child nodes then thos=
e
                                    examples are completely wrong.=C2=A0 E.=
g.
                                    the 4th rule is described as "This
                                    rule gives the 'admin' group
                                    read-write

                                    > access to all acme
                                    <interface> entries."=C2=A0 =
But If
                                    the path only strictly matches
                                    "/acme:interfaces/acme:interface"
                                    then the admin group rule achieves
                                    nothing useful at all.=C2=A0 The admin =
is
                                    not even

                                    > allowed to create an interface
                                    because they would not even have
                                    permission to write to the list key
                                    'name' node required to create =
a
                                    list entry!=C2=A0 Instead, a separate
                                    rule would be required for every

                                    > single possible schema node
                                    under "/acme:interfaces/acme:inter=
face"!=C2=A0
                                    I think that this makes "permit&qu=
ot;
                                    data-node rules completely unusable.
                                    

                                    I strongly agree with this, and I
                                    would say that it isn't only the
                                    case

                                    for "permit" rules - e.g. den=
ying
                                    some access to a subtree of the data
                                    model that would otherwise be
                                    permitted due to defaults is at
                                    least as

                                    common, and the rules would be just
                                    as unusable for that.

                                    

                                    Besides the examples, I think that
                                    the very use of the term "match&qu=
ot;,

                                    though unfortunately not defined,
                                    strongly suggests that it is
                                    something

                                    other than use of e.g. the term
                                    "identify" would imply.
                                    Additionally,

                                    this text in the description of the
                                    'path' leaf is consistent with =
the

                                    match being a prefix match:

                                    

                                    =C2=A0 =C2=A0 =C2=A0 =C2=A0The special =
value '/' refers
                                    to all possible

                                    =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore co=
ntents.";

                                    

                                    FWIW, our NACM implementation,
                                    available to (and used by) customers
                                    since 2012, follows the prefix match
                                    logic, and I have yet to hear of

                                    any user expecting it to do
                                    otherwise.

                                    

                                    > To fix this properly, we need
                                    to make the data-node path rule a
                                    prefix match.=C2=A0 In particular, we
                                    need text that specifies:

                                    >

                                    > (i) that a data-node path match
                                    succeeds if it matches the path
                                    prefix from the root of the tree.=C2=A0
                                    I.e. so the data-rule "/foo" =
matches
                                    "/foo" and all of foo's d=
escendant
                                    children nodes.

                                    

                                    Strongly agree.

                                    

                                  

                                  


                                  

                                  


                                  

                                  
I do not see how the text can be
                                    interpreted this way.

                                

                              

                            

                          

                          

                          Because otherwise the path match part of the
                          NACM solution is really broken, and the path
                          based examples in the appendix are entirely
                          misleading and wrong.=C2=A0 The only way those
                          examples make sense is the paths match
                          descendant children nodes as well.

                          

                        

                      

                      


                      

                      


                      

                      
IMO the text does not support this
                        interpretation.

                    

                  

                

              

              The examples in B.4, and the definition of "/" matc=
hing
              all nodes supports this interpretation.

              

              Hence, my opinion is that it is the text in 3.4.5 that is
              incorrectly specified; and that the examples, definition
              of "/" and standard practice are right.

              

              Otherwise, how did IETF manage to publish an RFC where the
              path based examples are so completely wrong?=C2=A0=C2=A0 Whoe=
ver
              wrote and reviewed those examples clearly had a different
              interpretation of how these path based ACLs worked. 

              

              

              

                

                  

                    

                      
There is nothing said about inheriting state
                        from the parent data node.

                      
I think no matter how the permissions are
                        derived, one can

                      
find examples that work better or worse
                        because of it.

                    

                  

                

              

              No.=C2=A0 If the rules apply to descendant children, all norm=
al
              examples work well (including the ones in the appendix).

              

              

              

                

                  

                    

                      
IMO the number of rules required to implement
                        a use-case is not

                      
very relevant or objective criteria.

                    

                  

                

              

              Yes it is, particularly when the difference is between
              needing a 1 line rule, and a 100+ line rule.

              

              

                

                  

                    

                      


                      

                      
Using the previous example of /home and
                        /home/user1,

                      
if the user1 is given read access to /home,
                        then (according to you)

                      
it also has read access to every user subtree
                        under /home.

                    

                  

                

              

              

                

                  

                    

                      
Instead of 1 rule per user, 2 rules are
                        needed

                    

                  

                

              

              No, just 1 rule per user:

              =C2=A0=C2=A0 read-default=3Ddeny

              =C2=A0=C2=A0 group=3Duser1, path=3D/home/user1, action=3Dperm=
it

              

              This is because of my two proposed changes:

              

              (i) that a data-node path match succeeds if it matches the
              path prefix from the root of the tree.=C2=A0 I.e. so the
              data-rule "/foo" matches "/foo" and all o=
f foo's
              descendant children nodes.

              <- This means that you only need 1 entry instead of 100
              entries.

              

              (ii) if a data-node rule has action "permit" then i=
t
              implicitly allows read access for all ancestor parent
              nodes up to the root.=C2=A0 (I.e. to mitigate the original
              change proposed on this thread.)

              <- This means that you don't need a separate read rule
              for "/home".=C2=A0 Read access to that node it is i=
mplicitly
              given via "group=3Duser1, path=3D/home/user1, action=3Dp=
ermit",
              hence meaning that the rule works the same way as it does
              on an rfc6536 compliant implementation.

              

              

                

                  

                    

                      


                      

                      
=C2=A0 =C2=A0read-default=3Ddeny

                      
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dp=
ermit

                      
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1,
                        action=3Dpermit

                      


                      

                      
The above rules would allow access for every
                        user to every other user.

                      
The 2nd rule has no effect, which is
                        counter-intuitive.

                      
Every user dir would need 2 rules

                      


                      

                      

                        
=C2=A0 =C2=A0read-default=3Ddeny

                        
=C2=A0 =C2=A0group=3D*, path=3D/home, action=
=3Dpermit

                        
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1=
,
                          action=3Dpermit

                      

                      
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, acti=
on=3Ddeny

                      

                      


                      

                      

                        

                          

                            

                              

                                

                                  
There is nothing that says this
                                    is how it works.

                                  
If it did, once could never have
                                    privileged sub-fiolders

                                  


                                  

                                  
=C2=A0 =C2=A0 =C2=A0/var/log -> p=
ermit

                                  
=C2=A0 =C2=A0 =C2=A0/var/log/apache2=
 =C2=A0-> deny

                                

                              

                            

                          

                          

                          Yes, you can, you just list the longest path
                          first in the list of rules:

                          

                          =C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> deny=


                          =C2=A0 (2) /var/log -> permit

                          

                          Any requests that attempt to access anything
                          under /var/log/apache2 would match rule (1)
                          and be denied.

                          Any requests that attempt to access anything
                          under /var/log, but not under
                          /var/log/apache2, would fail to match rule
                          (1), but would match rule (2) instead and be
                          permitted.

                          

                          

                        

                      

                      


                      

                      
I do not see any text in the draft or RFC
                        7950 that

                      
suggests that /var/log and /var/log/apache2
                        represent the same data node.

                    

                  

                

              

              They are different data nodes, but I don't see how that i=
s
              relevant.

              

              Thanks,

              Rob

              

              

              

                

                  

                    

                      


                      

                      


                      

                      
Andy

                      


                      

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  


                                  

                                  
=C2=A0

                                  

                                  

                                    > (ii) if a data-node rule has
                                    action "permit" then it impli=
citly
                                    allows read access for all ancestor
                                    parent nodes up to the root.=C2=A0 (I.e=
.
                                    to mitigate the original change
                                    proposed on this thread.)

                                    

                                    This seems reasonable to me,
                                    although I haven't at this point
                                    evaluated

                                    the suggestion in detail. In any
                                    case I think the main point both

                                    regarding this and the prefix match
                                    is that this update to 6536 can't
                                    make radical changes to the
                                    semantics compared to a "reasonabl=
e

                                    interpretation" (hard to define, I
                                    know) of the under-specified

                                    original.

                                  

                                  


                                  

                                  
The text does not say this at all
                                    so I do not approve of this change
                                

                              

                            

                          

                          

                          In the RFC version of the NACM this wasn't
                          required because operation 'none' didn=
9;t
                          require read access.=C2=A0 Now read access is
                          required even for operation 'none', then =
this
                          change makes sense to make the NACM changes
                          backwards compatible, whilst still closing the
                          security hole.

                          

                          Thanks,

                          Rob

                          

                          

                            

                              

                                

                                  


                                  

                                  
=C2=A0

                                  

                                    

                                    --Per

                                    

                                  

                                  


                                  

                                  


                                  

                                  
Andy

                                  
=C2=A0

                                  

                                    > Thanks,

                                    > Rob

                                    >

                                    >

                                    >>

                                    >> Thanks

                                    >>

                                    >>>

                                    >>>

                                    >>> Andy

                                    >>>

                                    >>>

                                    >>> On Thu, Nov 9, 2017 at
                                    2:44 AM, Robert Wilton <rwilton@cisco.com
                                    <mailto:rwilton@cisco.com>>
                                    wrote:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Hi Andy=
,

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0It isn&=
#39;t clear to
                                    me whether matching a path in NACM
                                    either:

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
(i) Only applies
                                    to the specific node, and not any
                                    children, or

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
(ii) Applies to
                                    the specific node and all descendant
                                    children nodes as well.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0As an e=
xample,
                                    using the tree below.=C2=A0 if I have a
                                    rule that matches path "A/B" =
then
                                    does that apply to only the specific
                                    node "A/B", or does it also a=
pply to
                                    all descendant children of "A/B&qu=
ot; as

                                    >>>=C2=A0 =C2=A0 =C2=A0well?
                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0In rfc6=
536bis-08,
                                    section "3.4.5.=C2=A0 Data Node Ac=
cess
                                    Validation", step 6 states:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0*=C2=A0 The rule
                                    does not have a "rule-type" d=
efined
                                    or the "rule-

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type" is
                                    "data-node" and the *"pa=
th" matches
                                    the requested data node*, action
                                    node, or notification node.

                                    >>>

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0My read=
ing of this
                                    is that it implies that the
                                    interpretation of the path rule is
                                    (i), but this is not how I would
                                    normally expect an ACL rule to apply
                                    in a tree like object (e.g a
                                    directory

                                    >>>=C2=A0 =C2=A0 =C2=A0file sy=
stem).

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0However=
, the
                                    examples in Appendix B.4. imply that
                                    the path rule is to be interpreted
                                    like (ii), or otherwise the example
                                    rules seem to be mostly pointless.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0E.g. ta=
king this
                                    example from appendix B.4:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 <rule>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <name>permit-dummy-interface</=
name>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 <path
                                    xmlns:acme=3D"http://example.com/ns/itf"
                                    <http://example.com/ns/itf>&g=
t;

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    /acme:interfaces/acme:interface[ac=
me:name=3D'dummy']

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    </path>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <access-operations>read
                                    update</access-operations>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <action>permit</action>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <comment>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow
                                    the limited and guest groups read

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and
                                    update access to the dummy
                                    interface.

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    </comment>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0
                                    </rule>

                                    >>>

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0If the =
rule is (i)=C2=A0
                                    then the access rule allows the
                                    client to read the specific node
                                    "/acme:interfaces/acme:interface[acme:name=3D'dummy']"
                                    but not any child leafs/containers
                                    of that interface,

                                    >>>=C2=A0 =C2=A0 =C2=A0this do=
esn't seem
                                    useful.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Further=
 comments
                                    inline below ...

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0On 08/1=
1/2017
                                    20:05, Andy Bierman wrote:

                                    >>>>=C2=A0 =C2=A0 =C2=A0Hi,=


                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0Thi=
s change has
                                    no impact on the server if
                                    /nacm/read-default is "permit"=
;.

                                    >>>>=C2=A0 =C2=A0 =C2=A0In =
that case,
                                    the extra read rules for /A and /A/B
                                    are not needed.

                                    >>>=C2=A0 =C2=A0 =C2=A0I agree=
.

                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0An =
operator
                                    worried about read access should set
                                    read-default to "deny".

                                    >>>=C2=A0 =C2=A0 =C2=A0I agree=
.=C2=A0 This is
                                    the scenario that I'm considering.<=
br>
                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0In =
that case,
                                    explicit rules to read /A and /A/B
                                    would be needed

                                    >>>>=C2=A0 =C2=A0 =C2=A0in =
the new
                                    NACM.

                                    >>>=C2=A0 =C2=A0 =C2=A0Yes, if=
 the
                                    interpretation of the rule is (i)
                                    above.

                                    >>>=C2=A0 =C2=A0 =C2=A0Otherwi=
se if the
                                    interpretation is (ii) then you only
                                    need "read /A" since that imp=
lies
                                    "read A/B" as well (as long a=
s the
                                    rules are listed in the correct
                                    order).

                                    >>>

                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0The deny
                                    rules would not be needed.

                                    >>>=C2=A0 =C2=A0 =C2=A0Only if=
 the
                                    interpretation of the rule is (i)
                                    above.=C2=A0 In which case the=C2=A0
                                    "read/write 'A/B/J' rule w=
ould not
                                    be sufficient.=C2=A0 It would be
                                    necessary to define an Xpath
                                    expressions that contains

                                    >>>=C2=A0 =C2=A0 =C2=A0all chi=
ldren nodes
                                    as well.=C2=A0 Perhaps 'A/B/J//*=
9;?

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0If the
                                    interpretation of the rule is (ii)
                                    then you would also need all the
                                    explicit deny statements as well,
                                    otherwise they would be allowed by
                                    the "read /A" rule above.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Thanks,=


                                    >>>=C2=A0 =C2=A0 =C2=A0Rob

                                    >>>

                                    >>>

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0And=
y

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0On =
Wed, Nov 8,
                                    2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com
                                    <mailto:rwilton@cisco.com>>
                                    wrote:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Hi,

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0I'm not
                                    sure about this change.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0I'm not
                                    that familiar with NACM, but if you
                                    want to give a particular set of
                                    users read/write access to a
                                    subtree, but not allow them to have
                                    any other access to the
                                    configuration in the

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0running
                                    datastore then with the existing
                                    RFC, that could be expressed with a
                                    single rule (example in 6536bis,
                                    appendix B.4)

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0With this
                                    new change, I think that you may
                                    need to configure many more rules to
                                    achieve the same thing.=C2=A0 I think
                                    that you would need to give read
                                    access to the top node in the
                                    desired

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0path, and
                                    then separate explicit "deny"=
 rules
                                    for every sibling child node walking
                                    from the top of the tree down to the
                                    data node that read/write access is
                                    actually being given to.=C2=A0 The

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0example
                                    below may explain my understanding
                                    better:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0E.g. For a
                                    tree of data nodes, rooted at A, if
                                    we wanted to give read/write access
                                    only to "J" subtree, and no a=
ccess
                                    for the rest of the tree then:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 =C2=A0 =C2=A0 A

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 =C2=A0 =C2=A0 |

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0--------------------

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0
                                    =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=
=A0 =C2=A0 =C2=A0|

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=C2=A0
                                    =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=
=A0 =C2=A0 =C2=A0E

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    -----------

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0
                                    |=C2=A0 |

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 F=C2=A0 =C2=A0G=C2=A0
                                    H=C2=A0 J

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 |

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

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0In the old
                                    model, I think that the ACL rules
                                    would be 1 rules long (assuming
                                    default deny all):

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    "read/write 'A/B/J'

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0In the new
                                    model, I think that the equivalent
                                    ACL rules would need to be 8 rules
                                    long (assuming default deny all):

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    "read/write 'A/B/J'

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "read A"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny C"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny D"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny E"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny F"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny G"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny H"

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Note, I am
                                    assuming that a "path" rule m=
atches
                                    for the given path and all
                                    descendant nodes.=C2=A0 The draft doesn=
't
                                    seem to be particularly clear on
                                    this point (it states that the rule
                                    applies

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0when the
                                    path matches, but this would seem to
                                    be counter intuitive), and perhaps
                                    it could be clarified.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0If this
                                    change is allowed, then the example
                                    in appendix B.4 looks like it would
                                    need to be fixed, since the
                                    "limited-acl" probably wouldn=
't give
                                    any access at all, unless default
                                    read

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0access had
                                    been given.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0But,
                                    possibly I'm misunderstanding how
                                    this all works!=C2=A0 If so, apologies
                                    for the noise :-)

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Thanks,

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Rob

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0On
                                    02/11/2017 14:18, Benoit Claise
                                    wrote:

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Dear
                                    all,

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Here is
                                    a major change in
                                    draft-ietf-netconf-rfc6536bis,
                                    suggested by the Security AD Eric
                                    Rescola part of the IESG review,
                                    which I would like to validate with
                                    the WG. See

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0https://t=
ools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt=

                                    <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf=
-rfc6536bis-08.txt>

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0<dfpcfioondggippe.png>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0The
                                    NETCONF WG was cc'ed for the entire
                                    discussion.

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0What do
                                    you think? I will draw the
                                    conclusions by Friday Nov 10th.

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Note:
                                    If the WG is fine, the next step is
                                    to approve this document.

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0Regards, Benoit

                                    >>>>>

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0_______________________________________________

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Netconf
                                    mailing list

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Netc=
onf@ietf.org
                                    <mailto:Netconf@ietf.org>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list=
info/netconf
                                    <https://www.iet=
f.org/mailman/listinfo/netconf>

                                    >>>>

                                    >>>>

                                    >>>

                                    >>>

                                    >>>
                                    __________________________________=
_____________

                                    >>> Netconf mailing list

                                    >>> Netconf@ietf.org
                                    <mailto:Netconf@ietf.org>

                                    >>> https:=
//www.ietf.org/mailman/listinfo/netconf

                                    >>

                                    >> Mahesh Jethanandani

                                    >> mjethanandani@gmail.com
                                    <mailto:mjethanandani@gmail.com>

                                    >

                                    >

                                    >

                                    > _______________________________________________

                                    > Netconf mailing list

                                    > Netconf@ietf.org

                                    > https://www.ie=
tf.org/mailman/listinfo/netconf

                                    >

                                    

                                  

                                

                                

                              

                            

                          

                          

                        

                      

                    

                    

                  

                

              

              

            

          

        

        

      

    

    

  






--94eb2c0e61142a16ce055da8935b--


From nobody Sat Nov 11 06:49:47 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02587129649 for ; Sat, 11 Nov 2017 06:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 mhblI85EYdnM for ; Sat, 11 Nov 2017 06:49:43 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0110.outbound.protection.outlook.com [104.47.41.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576491295A0 for ; Sat, 11 Nov 2017 06:49:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=anRJaN7dd/sOTKwmTKL8B+XzREKbdH4nT2zkorzrRGY=; b=E1/8lb++ZFXw88N1TI9/8jEcRCXlH8PEDi+OFR3t+zwfx0WhJy+uFb9XRipeXFEYDVYXEWr/uOvnfptw1rbH+xI6tJhDCv/qyUvl+Eas0IVc0haBIqyRjqYG0rOYkwydJhPPQfMtQS3yuhX097n+SP1LQUBhZ5T/l9IbPM4UJsY=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Sat, 11 Nov 2017 14:49:41 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0239.004; Sat, 11 Nov 2017 14:49:41 +0000
From: Kent Watsen 
To: Martin Bjorklund , "mjethanandani@gmail.com" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] WGLC on zerotouch draft
Thread-Index: AQHTSo2X/9y7wRXxl0KFrYdSEL3me6MBL3QAgA3gOQA=
Date: Sat, 11 Nov 2017 14:49:41 +0000
Message-ID: <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@juniper.net>
References:  <20171102.145546.466862355235662064.mbj@tail-f.com>
In-Reply-To: <20171102.145546.466862355235662064.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [116.197.188.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:smcMfjuvHnVMpvONjFQieyYbIU18zuPiT2SktsDhAqr+1qXGMdJWjx2Dk4C7fXWK3cfx+SgWkONQ0lED2JO/XWm7JYHlrOrg3ayHkX3utfBhR4HMDugZpy+IWIYdI8qvLPJVy2FJHjTTQJg8JbP8CbFlBOEeX7Kp44a4MCXbMLWoTBS6rCEkWnNUSocITryW4mKM11hF90n2X8lfcbsTrbg9nS0N/LkZzD0ttvU7zdhkks5KrSeIB96U83jXe6GbiLMk3Pt11p4dQPs3VaDLbDzGIGTTs/iTRuG34LaqijIEVORZEPscf1ycE3ujQQqeE0JQ1/I49WBN3SSdOxVJofkJ79IMppvslNxZgLYqr8o=; 5:a7r6WXF+j/V60OtTI4Lj6JyxJ4V8RXxcO/ZxT7pBfZtcfhMp0sKFuYeQuaeiJ5fTMnf8TNlgzr4z3UV/CDhdztsGVy8Wtx178VsaZ2MqjZe3s23jv0eIb1RBdIXEY1IA+0inMavAUa0SfTOxtXpHFjgIILuORekBOfBEy7eI6fE=; 24:e6/yhnEu8bkC4OOmFswDhlG9ZBrYGln4X52KFG2ruxwkxMtAZc61p+9LIjJOWJ+Yv1ggBYlINdtlTmVKiBdg7LKbbP91vl/RHEUy73J8vMM=; 7:/RecNNyzowUgA8ibOWpPavzOd4sJL7ERGuxPC+cRTcL+pFfa0z3Qb9kPuKN+mj+eFwVm9RDYJQ23Q4B792PwLgsKSbgpdPqi1Thk7NrIiD79/6d24cyz2GlpmI22GKRY54IyhGUI+huhGABH/51weGZZa/kqa7rViS6mfVoO8TEHmg3+QwNfbetThFGPDS0ZKxsiJGEE53/ZGLhKmV/zDOkw8MRMzXBq0JR/cI+IZLQQDFoQA8/cLU7H2aO57oh9
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9bd42c2e-5d2c-4a6c-c4cf-08d52913709b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; 
x-forefront-prvs: 0488C54DB4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(189002)(24454002)(51914003)(199003)(7736002)(966005)(2950100002)(33656002)(68736007)(83506002)(229853002)(4326008)(66066001)(5660300001)(83716003)(478600001)(25786009)(39060400002)(6306002)(3280700002)(2906002)(3660700001)(77096006)(53936002)(6512007)(305945005)(99286004)(101416001)(102836003)(189998001)(2501003)(6116002)(316002)(97736004)(82746002)(6436002)(3846002)(6246003)(36756003)(8936002)(106356001)(6506006)(6486002)(58126008)(105586002)(110136005)(575784001)(14454004)(54356999)(76176999)(8676002)(81166006)(81156014)(50986999)(86362001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
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: 9bd42c2e-5d2c-4a6c-c4cf-08d52913709b
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2017 14:49:41.1917 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
Archived-At: 
Subject: Re: [Netconf] WGLC on zerotouch draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 14:49:46 -0000

DQpIaSBNYXJ0aW4sDQoNCj4gSGksDQo+DQo+IEkgaGF2ZSByZXZpZXdlZCB2ZXJzaW9uIC0xOSwg
YW5kIGNoZWNrZWQgdGhhdCBteSBwcmV2aW91cyBjb21tZW50cyBhcmUNCj4gYWRkcmVzc2VkLiAg
SGVyZSBhcmUgbXkgY29tbWVudHMgb24gdGhpcyB2ZXJzaW9uOg0KDQpUaGFua3MgZm9yIHRoZSBm
b2xsb3ctdXAuDQoNCg0KPiBvICBTZWN0aW9uIDIuMg0KPg0KPiAgVHJlZSBkaWFncmFtIGlzIG91
dCBvZiBkYXRlLg0KDQpGaXhlZC4NCg0KDQo+IG8gIFNlY3Rpb24gNS4xLCBpdGVtIDENCj4NCj4g
IEFkZCByZWZlcmVuY2UgdG8gdGhlIG5ldyBtb2R1bGUgaWV0Zi16ZXJvdG91Y2gtZGV2aWNlLCBt
YXliZSB0d2Vhaw0KPiAgdGhlIHRleHQ/DQoNCkkgcHV0IHRoZSByZWZlcmVuY2UgdG8gdGhlIG1v
ZHVsZSB1cCBhIGxldmVsIChTZWN0aW9uIDUpIGFzIHRoZSBtb2R1bGUNCmFwcGxpZXMgdG8gbW9y
ZSB0aGFuIGp1c3QgaXRlbSAxLiAgUmVnYXJkaW5nIHR3ZWFraW5nIHRoZSB0ZXh0LCBkbyB5b3UN
CmhhdmUgYSBzdWdnZXN0aW9uPw0KDQoNCj4gbyAgU2VjdGlvbiA2LjINCj4NCj4gIFRoZSBleGFt
cGxlIGhhczoNCj4NCj4gICAgICAgICJpZXRmLWRldmljZTp6ZXJvdG91Y2giIDogew0KPiAgICAg
ICAgICAgImVuYWJsZWQiIDogZmFsc2UNCj4gICAgICAgICB9DQo+DQo+ICBUaGlzIHNob3VsZCBi
ZToNCj4NCj4gICAgICAgICAiaWV0Zi16ZXJvdG91Y2gtZGV2aWNlOnplcm90b3VjaCIgOiB7DQo+
ICAgICAgICAgICAiZW5hYmxlZCIgOiBmYWxzZQ0KPiAgICAgICAgIH0NCg0KRml4ZWQuICBUb29s
LXN1cHBvcnQgZm9yIHZhbGlkYXRpbmcgeWFuZy1kYXRhIHdvdWxkIGJlIGhlbHBmdWwuDQoNCg0K
DQo+IG8gIGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXIueWFuZw0KPg0KPiAgSW4gdGhl
IGRlc2NyaXB0aW9uIGZvciAic2NyaXB0IiwgeW91IG1lbnRpb24gJ3NjcmlwdC13YXJuaW5nJyBh
bmQNCj4gICdzY3JpcHQtZXJyb3InLiAgQnV0IHRoZXkgYXJlIGNhbGxlZCAncHJlLXNjcmlwdC13
YXJuaW5nJywNCj4gICdwb3N0LXNjcmlwdC13YXJuaW5nJywgZXRjLg0KPg0KPiAgW0kgbWFkZSB0
aGlzIGNvbW1lbnQgZWFybGllciwgdG8gd2hpY2ggeW91IHJlcGxpZWQgIldpbGwgZml4Iiwgc28g
SQ0KPiAgYXNzdW1lIHlvdSBzaW1wbHkgZm9yZ290IHRoaXMgb25lLl0NCg0Kb2theSwgcmVhbGx5
IGZpeGVkIHRoaXMgdGltZS4NCg0KDQo+IG8gIGlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2
ZXIueWFuZw0KPg0KPiAgVGhlIGRlc2NyaXB0aW9uIG9mIHRoZSAic2NyaXB0IiB0eXBlZGVmIHNh
eXM6DQo+DQo+DQo+ICAgICAgIE5vIGF0dGVtcHQgaXMgbWFkZSB0byBzdGFuZGFyZGl6ZSB0aGUg
Y29udGVudHMsIHJ1bm5pbmcgY29udGV4dCwNCj4gICAgICAgb3IgcHJvZ3JhbW1pbmcgbGFuZ3Vh
Z2Ugb2YgdGhlIHNjcmlwdC4NCj4gICAgICAgWy4uLl0NCj4NCj4gICAgICAgVGhlIHNjcmlwdCBy
ZXR1cm5zIGV4aXQgc3RhdHVzIGNvZGUgJzAnIG9uIHN1Y2Nlc3MgYW5kIG5vbi16ZXJvDQo+ICAg
ICAgIG9uIGVycm9yLCB3aXRoIGFjY29tcGFueWluZyBzdGRlcnIvc3Rkb3V0IGZvciBsb2dnaW5n
IHB1cnBvc2VzLg0KPg0KPiAgICAgSSB0aGluayB0aGUgbGFzdCBxdW90ZWQgc2VudGVuY2UgY29u
dHJhZGljdHMgdGhlIGZpcnN0IC0gaXQgZG9lcyBpbg0KPiAgICAgZmFjdCBtYWtlIGFzc3VtcHRp
b25zIGFib3V0IHRoZSBydW5uaW5nIGNvbnRleHQgb2YgdGhlIHNjcmlwdC4NCj4NCj4gICAgIEkg
c3VnZ2VzdCB0aGUgbGF0dGVyIHNlbnRlbmNlIGlzIHJlbW92ZWQsIGFuZCB0aGUgcmVzdCBvZiB0
aGUgdGVzdA0KPiAgICAgYWRqdXN0ZWQuICBEb24ndCB0YWxrIGFib3V0IGV4aXQgY29kZXMsIGJ1
dCBpbnN0ZWFkIHRhbGsgYWJvdXQNCj4gICAgICJzdWNjZXNzIiBvciAiZXJyb3IiIGV0Yy4NCj4N
Cj4NCj4gIFtJIG1hZGUgdGhpcyBjb21tZW50IGVhcmxpZXIsIHRvIHdoaWNoIHlvdSByZXBsaWVk
ICJXaWxsIGRvIiwgc28gSQ0KPiAgYXNzdW1lIHlvdSBzaW1wbHkgZm9yZ290IHRoaXMgb25lLl0N
Cg0KSSBkaWQgZWRpdCBpdCBiZWZvcmUgKHNlZSB0aGUgMTcgLT4gMTggZGlmZiwgYnV0IG15IGVk
aXQgd2FzIG5vdCB3aGF0DQp5b3UgaGFkIHN1Z2dlc3RlZCBiZWZvcmUuICBSYXRoZXIgdGhhbiBu
b3QgdGFsayBhYm91dCBleGl0IGNvZGVzIGFuZA0Kd2hhdCBub3QgKHdoaWNoIEkgdGhpbmsgaXMg
aW1wb3J0YW50IHRvIGZpeCksIEkgbW9kaWZpZWQgdGhlIGZpcnN0DQpzZW50ZW5jZSB0byBjbGFy
aWZ5ICJvdGhlciB0aGFuIHRoYXQgaXQgY2FuIGVtaXQgYW4gZXhpdCBzdGF0dXMgY29kZQ0KYW5k
IHN0ZGVyci9zZHRvdXQiLg0KDQoNCg0KPiBvICBpZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2Vy
dmVyLnlhbmcNCj4NCj4NCj4gICAgICAgICAgICAgICAgZW51bSAic3NoLWRzcyIgew0KPiAgICAg
ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgICAgICAic3NoLWRzcyI7
DQo+DQo+ICBEaWQgeW91IGdldCBhIHdhcm5pbmcgZm9yIGEgbWlzc2luZyBkZXNjcmlwdGlvbiA7
LSkNCg0KWWVzLCBzZXZlcmFsIHJldmlzaW9ucyBiYWNrLCBidXQgSSB0YWtlIGl0IHRoYXQgeW91
J3JlIGFjdHVhbGx5IGRpbmdpbmcNCm1lIGZvciBub3QgaGF2ZSBhIG1vcmUgdXNlZnVsIGRlc2Ny
aXB0aW9uPyAgKEkganVzdCBtYWRlIHRoZSBkZXNjcmlwdGlvbnMNCmEgbGl0dGxlIG1vcmUgdXNl
ZnVsKS4NCg0KDQoNCj4gbyAgaWV0Zi16ZXJvdG91Y2gtaW5mb3JtYXRpb24ueWFuZw0KPg0KPiAg
SSBzdGlsbCB0aGluayB0aGF0IHdoZW4gcmM6eWFuZy1kYXRhIGlzIHVzZWQsIGl0IG5lZWRzIHRv
IGhhdmUgYQ0KPiAgc2luZ2xlIGNvbnRhaW5lci4NCj4NCj4gIFlvdSBjYW4gZWFzaWx5IGZpeCB0
aGlzIGJ5IGRlZmluaW5nIHR3byBzZXBhcmF0ZSBzdHJ1Y3R1cmVzLA0KPiAgInJlZGlyZWN0LWlu
Zm9ybWF0aW9uIiBhbmQgIm9uYm9hcmRpbmctaW5mb3JtYXRpb24iLCB0aGVuIGRlZmluZSBhDQo+
ICAiemVyb3RvdWNoLWluZm9ybWF0aW9uIiBhcnRpZmFjdCBhcyBiZWluZyBvbmUgb2YgdGhlc2Ug
dHdvDQo+ICBzdHJ1Y3R1cmVzLg0KDQpXYWl0LCBJIHRob3VnaHQgd2UgaGFkIGFuIGFncmVlbWVu
dCB0aGF0IHRoaXMgZHJhZnQgd291bGQgc3dpdGNoIHRvDQp1c2UgdGhlIG5ldyB5YW5nLWRhdGEg
ZXh0ZW5zaW9uIGJlaW5nIGRlZmluZWQgaW4gTkVUTU9EIHRoYXQgd291bGQNCmFsbG93IGZvciB0
aGlzIHVzZSBvZiBhICdjaG9pY2UnIHN0YXRlbWVudC4gIEkgd2lsbCBzd2l0Y2ggdG8gdGhpcw0K
eWFuZy1kYXRhIGRlZmluaXRpb24gbm93LCBva2F5Pw0KDQoNCj4gbyAgaWV0Zi16ZXJvdG91Y2gt
ZGV2aWNlLnlhbmcNCj4NCj4gICAgbGVhZiBkZXZpZC1jZXJ0aWZpY2F0ZQ0KPiAgU2hvdWxkIGl0
IGJlIGNhbGxlZCBpZGV2aWQtY2VydGlmaWNhdGU/DQoNClllcy4gIFRoYXQgc2FpZCwgYW4gSURl
dklEIGNlcnQgKmlzKiBhIERldklEIGNlcnQsIGJ1dCB0aGF0J3MNCm5vdCBpbXBvcnRhbnQgaGVy
ZS4NCg0KDQoNCj4gbyAgaWV0Zi16ZXJvdG91Y2gtZGV2aWNlLnlhbmcNCj4NCj4gICAgY29udGFp
bmVyIGJvb3RzdHJhcC1zZXJ2ZXJzIHsNCj4gICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gICAgICAg
IC4uLg0KPiAgICAgICAgIkRlZmF1bHQgbGlzdCBvZiBib290c3RyYXAgc2VydmVycyB0aGlzIGRl
dmljZSBpcw0KPiAgICAgICAgIGNvbmZpZ3VyZWQgdG8gcmVhY2ggb3V0IHRvIHdoZW4gYm9vdHN0
cmFwcGluZy4iOw0KPg0KPiAgSSBoYWQgdG8gdGhpbmsgaGFyZCBhYm91dCB0aGlzIG9uZS4gIEkg
KnRoaW5rKiB0aGF0IHRoZSBpZGVhIGlzIHRoYXQNCj4gIHRoaXMgbGlzdCBjb250YWlucyB0aGUg
ZmFjdG9yeS1pbnN0YWxsZWQgbGlzdCBvZiBib290c3RyYXAgc2VydmVycw0KPiAgZGVmaW5lZCBp
biBzZWN0aW9uIDUuMSwgYnVsbGV0IDM/DQo+DQo+IE1heWJlIHJlcGhyYXNlLCB3L28gdXNpbmcg
dGhlIHdvcmRzICJkZWZhdWx0IGxpc3QiIGFuZCAiY29uZmlndXJlZCIuDQoNCkRvbmUuDQoNCg0K
PiBvICBpZXRmLXplcm90b3VjaC1kZXZpY2UueWFuZw0KPg0KPiAgICBsZWFmIGJvb3RzdHJhcC1z
ZXJ2ZXItdGEtY2VydGlmaWNhdGVzIHsNCj4NCj4gIFdoYXQgZG9lcyAidGEiIHN0YW5kIGZvcj8N
Cg0KInRhIiBzdGFuZHMgZm9yICJ0cnVzdCBhbmNob3IiLCBidXQgSSB3ZW50IGFoZWFkIGFuZCBz
L3RhL3Bpbm5lZC8gdG8NCm1ha2UgaXQgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlIG5vZGUgdGhl
IGxlYWZyZWYgcG9pbnRzIHRvLg0KDQoNCg0KPiBFZGl0b3JpYWwgbml0DQo+IC0tLS0tLS0tLS0t
LS0NCj4NCj4gbyAgdXNlICIiIGluc3RlYWQgb2YgJycgY29uc2lzdGVudGx5ICAoZXhjZXB0IGlu
IFlBTkcgc3RyaW5ncykNCj4NCj4gICh5b3UgZml4ZWQgc29tZSwgYW5kIHRoZW4gYWRkZWQgc29t
ZSBuZXcgdXNhZ2VzIG9mICcnIDopDQoNCg0KT2theSwgYnV0IHdoYXQgIllBTkcgc3RyaW5ncyIg
Z2V0IHRoZSBzaW5nbGUgcXVvdGVzPw0KDQoNCg0KPiAvbWFydGluDQoNCktlbnQgLy8gY29udHJp
YnV0b3INCg0KDQoNCg0KDQoNCg0KTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBn
bWFpbC5jb20+IHdyb3RlOg0KDQo+IFRoZSB6ZXJvdG91Y2ggZHJhZnQgaGFzIGhhZCBhIGNvdXBs
ZSBvZiBjYWxscyBmb3IgY29uc2lkZXJhdGlvbiBvZiBMQywNCg0KPiBhbmQgaGFzIG92ZXIgdGhh
dCBwZXJpb2QgY3VtdWxhdGl2ZWx5IHBpY2tlZCB1cCB2b3RlcyBvZiBzdXBwb3J0LiBUaGUNCg0K
PiBsYXN0IGF0dGVtcHQgcmVzdWx0ZWQgaW4gYSBmZXcgbW9yZSBpc3N1ZXMgYmVpbmcgcmFpc2Vk
IGJ5IE1hcnRpbiwNCg0KPiB3aGljaCBLZW50IGhhcyBhZGRyZXNzZWQuIFRoYXQgbGVhdmVzIHRo
ZSBxdWVzdGlvbiBvZiB0aGUgZGVmaW5pdGlvbg0KDQo+IG9mIOKAnGhhc2gtYWxnb3JpdGht4oCd
IGFzIGEgYmFzZSBpZGVudGl0eSBpbiB0aGUgbW9kdWxlIGFuZCB0aGUNCg0KPiDigJh5YW5nLWRh
dGHigJkgZXh0ZW5zaW9uIHN0YXRlbWVudCBhcyBpdCBhcHBsaWVzIHRvIGEgZHJhZnQncyB1c2Ug
b2YNCg0KPiAnY2hvaWNlJyBzdGF0ZW1lbnQuIFNpbmNlIHRoZXJlIGlzIG5vIGNyeXB0byBtb2R1
bGUgd2l0aA0KDQo+IOKAnGhhc2gtYWxnb3JpdGhtIiBpZGVudGl0aWVzLCBLZW50IGlzIGxlYXZp
bmcgdGhlIGRlZmluaXRpb24gaW4gdGhpcw0KDQo+IGRyYWZ0LiBXaGVuIGFuZCBpZiwgc3VjaCBh
IG1vZGVsL2lkZW50aXR5IGlzIGRlZmluZWQsIHdlIHdpbGwNCg0KPiBkZXByZWNhdGUgdGhlIGRl
ZmluaXRpb24gaW4gdGhpcyBkcmFmdC4gRm9yIOKAmHlhbmctZGF0YeKAmSBleHRlbnNpb24NCg0K
PiBzdGF0ZW1lbnQsIHdlIHdpbGwgZ28gd2l0aCBNYXJ0aW7igJlzIHN1Z2dlc3Rpb24gdG8gYWRk
IHRoaXMgaW4gdGhlDQoNCj4geWFuZy1kYXRhLWF1Z21lbnRhdGlvbiBkcmFmdC4gUGxlYXNlIG5v
dGUgdGhhdCB0aGF0IGRyYWZ0IGlzIGFuDQoNCj4gaW5kaXZpZHVhbCBkcmFmdCwgYnV0IHNpbmNl
IGl0IGlzIGEgdGVjaG5pY2FsIGRldGFpbCwgd2hvc2Ugc29sdXRpb24NCg0KPiBoYXMgZ2VuZXJh
bGx5IGJlZW4gYWdyZWVkIHVwb24sIHdlIGZlZWwgaXQgc2hvdWxkIG5vdCBob2xkIHVwIHRoZSBM
Qy4NCg0KPiANCg0KPiBTaW5jZSB3ZSBhcmUgZGVhbGluZyB3aXRoIGFuIHVwZGF0ZWQgZHJhZnQs
IGEgbmV3IExDIGhhcyB0byBiZQ0KDQo+IGlzc3VlZC4gV2Ugd2lsbCBjb3VudCB0aGUgcHJldmlv
dXMgdm90ZXMgb2Ygc3VwcG9ydCBmb3IgdGhpcyBkcmFmdCBpbg0KDQo+IGFkZGl0aW9uIHRvIGFu
eSBuZXcgb25lcyB0byBtb3ZlIHRoZSBkcmFmdCBmb3J3YXJkLiBUaGlzIGUtbWFpbCBzdGFydHMN
Cg0KPiB0aGF0IExDIGFuZCB3aWxsIGxhc3QgMiB3ZWVrcy4gUGxlYXNlIGluZGljYXRlIHN1cHBv
cnQgZm9yIHRoZSBkcmFmdA0KDQo+IGJ5IHJlc3BvbmRpbmcgdG8gdGhlIGUtbWFpbHMsIGFuZCBp
ZiB5b3UgaGF2ZSBvYmplY3Rpb25zLCBpbmRpY2F0ZQ0KDQo+IHdoeS4gRm9yIHRob3NlIHRoYXQg
cHJvdmlkZWQgZmVlZGJhY2sgYmVmb3JlLCBwbGVhc2UgZW5zdXJlIHlvdXINCg0KPiBjb21tZW50
cyBoYXZlIGJlZW4gYWRkcmVzc2VkIGJ5IHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoNCj4g
DQoNCj4gVGhhbmtzLiANCg0KPiANCg0KPiBNYWhlc2ggSmV0aGFuYW5kYW5pIChhcyBjby1jaGFp
cikNCg0KPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KDQo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCg0K
PiBOZXRjb25mQGlldGYub3JnDQoNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t
L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25m
JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1GQ1FPMlRIcXB3
eFRHT0xjUzhDQTdOWS1QbVFpZFYyRnBlNXhfdGdPcURnJnM9RDM3am50bEl2TEZQMk1jVE0tblZF
WHRDQ2xiZVpzSXNhVEJ4TmNneTluUSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5v
cmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29uZiZkPUR3SUdhUSZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RkNRTzJUSHFwd3hUR09MY1M4Q0E3TlktUG1RaWRW
MkZwZTV4X3RnT3FEZyZzPUQzN2pudGxJdkxGUDJNY1RNLW5WRVh0Q0NsYmVac0lzYVRCeE5jZ3k5
blEmZT0NCg0KDQo=


From nobody Sat Nov 11 11:07:49 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD24124239 for ; Sat, 11 Nov 2017 11:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 O99TEQ869yRG for ; Sat, 11 Nov 2017 11:07:44 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 572521201F2 for ; Sat, 11 Nov 2017 11:07:43 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id f134so6051536lfg.8 for ; Sat, 11 Nov 2017 11:07:43 -0800 (PST)
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=uici/DEm6Q3/FIJ2hiS675WUEBqiA8Eg4Trcn979L8A=; b=xRtB/kPS8DUjz3NQMhNQBFKjaAizyznJCvMycFCUFQpa4iVIlgfWFG91E9ROtN+31d v79DSGP7R+2voSg3TRLTOEavSSkgYAfpjA94hMeE5ranlCMIbtvu4L69v75TK9JH+dkP GCgMVzNMGF+4hElxNXqyOh6doHdf73MBLFQi4sTk4zpTF6C7KQIo3kXlS93dvzvKMLpc 9SLAU/SYZw2Eq8MiOIw5NPu/PmLMaCbyINN6Cq9BO5LbYFMrHT5Q51zlwpgMEn1trZDR a18KSzZ53BeJJlORSQxZXW7oBqkwZGdYqGUwls+Of5PgwQrbnsNTIpgjmjSBChEWv2ow CdpQ==
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=uici/DEm6Q3/FIJ2hiS675WUEBqiA8Eg4Trcn979L8A=; b=Acu0N2HDSpl9iaa9/vk/h7puraaGdZ1sjmV+txwWav3460Qb4Qj+B51fFpBXF7sGVy 5qzkDtKPoXuRSm/NFq+HsRMOwbJ7rCwd8s+Kzni9t5iKM9VrFO2/TG++1RwwwYfXNguS QW2/1uUpjfQ5sQVhPoeAxALs3y9FsO15xr2CqP/YlojYeyTHvOWBleKsqDHFgCZG3HZO tvvciSIA0PVkXus/V9Tr+X1CnOjaeXIdDuTOewAm5q6jZMvH6I0SEPxjhInVLoFZI+l3 PcLTraRcadmnSILzJYYDpq94Wtg9F/yD6QyEudp++GCV8ehVIMSAj+rk3HxW3Fe96iOT ER1g==
X-Gm-Message-State: AJaThX7zwWlD11daIhf+/NESx6w/wW+TsqmsT7v6JFbtd3IIV/M+7QqI MjjbLsJzD2YT273/oeNe0Iw/gq/K8W89dkNH0fRBtA==
X-Google-Smtp-Source: AGs4zMYC35cTbuRBGn8X5cH+dSy8q3NVQUhbT4ktPApkx5p/ijjqHXFTvaOxVPRvwVtkS3wx4ckaqTfd8J4ICCcycMM=
X-Received: by 10.25.228.29 with SMTP id b29mr1500176lfh.107.1510427261322; Sat, 11 Nov 2017 11:07:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Sat, 11 Nov 2017 11:07:40 -0800 (PST)
In-Reply-To: <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>
From: Andy Bierman 
Date: Sat, 11 Nov 2017 11:07:40 -0800
Message-ID: 
To: Robert Wilton 
Cc: "netconf@ietf.org" , Ladislav Lhotka , Martin Bjorklund , Kent Watsen 
Content-Type: multipart/alternative; boundary="94eb2c0e61145eede3055db9c095"
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 19:07:47 -0000

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

On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton  wrote:

> Hi Andy,
>
> The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06)
> mandates two constraints that must apply:
>
> (1) All conventional datastores must have exactly the same schema.  Hence
> differences in deviations or features are allowed between these datastores.
> (sec 5.1, first paragraph)
>
> (2) The schema for operational must be a superset of all configuration
> datatstores, but that data nodes may be omitted (sec 5.3, third paragraph).
>
>
> This implies that only the following differences between datastores are
> allowed:
>  (i) a feature can be disabled in conventional (and/or dynamic
> configuration datastores), but enabled in operational (e.g. for
> configurable router-id).
>
 (ii) deviations apply in all datastores, except that
>   a) a deviation can remove nodes in the conventional datastores (if they
> were not configurable, like the feature example)
>   b) a deviation can remove nodes in a dynamic datastore (e.g. like I2RS)
>   c) a deviation can remove nodes from operational only if a server is
> unable to accurately report them.
>
> (iii) modules exist in all datastores, except:
>   a) a module can be omitted from conventional datastores (e.g. if the
> module is not configurable)
>   b) a module can be omitted from a dynamic datastore (e.g. like I2RS)
>   c) a module can be omitted from operational only if a server is unable
> to accurately report the data nodes within the module.
>
>
>
I am not convinced that moving to a datastore-centric conformance model
instead of server-centric
is a good idea.  I get it that it is supposed to allow the server to
accurately reflect its implementation,
but it actually says that servers MAY implement whatever partial subset of
a module they want,
and a client MUST deal with the mess.

IMO, YANG says that features and deviations are server-wide, not
per-datastore.
This new complexity is non-trivial to implement, so it may not be widely
supported.

The WG seems confused about the difference between a conformance model and
capabilities reporting.
(ii)(c) and (iii)(c) is about reporting, not conformance.  There is still
no way to express
trivial use-cases in the conformance model such as "this module is intended
for the I2RS ephemeral datastore only"


Changing the type of a node between datastores, or changing its properties
> is not allowed.  The only difference allowed between data nodes in
> different datastores is the nodes existence.
>
> These rules seem more restrictive that what a server using split config
> state trees (IETF style, or OpenConfig style) can achieve using deviations
> today.
>
>

Lots of rules to enforce actually makes the code harder, not easier.


> Thanks,
> Rob
>
>

Andy


>
>
> On 09/11/2017 19:33, Andy Bierman wrote:
>
> Hi,
>
> The new structure still has the same problems for the client as before.
> It is a major change in the architecture to have different schema trees
> per datastore instead of per-server.
> The server is allowed to have different features and deviations for the
> same objects.
> The client is completely on its own trying to compare  to
> anything
> if the schema trees are different
>
>   container foo {
>     leaf bar {
>        if-feature X;
>        type string;
>     }
>     leaf baz {
>        if-feature "not X";
>        type string;
>     }
>  }
>
> How does the client compare  to  if the features do
> not match?
> If the server deviates the leaf (e.g. change type string to int32) how
> does the client
> compare the values?
>
> This new complexity would be mandatory for the client to support in some
> proprietary
> manner since the NMDA standard ignores these problems.
>
> NMDA was supposed to be simpler because the client could compare intended
> and applied values using the same object path. openconfig required a data
> model change and a trivial name-mapping. In reality, NMDA
> is far more disruptive to existing implementations.
>
>
> Andy
>
>
>
> On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton  wrote:
>
>> Hi,
>>
>> Given some of the feedback related to the complexity of the YANG library
>> bis structure, we have come up with two other possible structures for the
>> YANG library data:
>>
>> (1) A simplified structure to make YANG library meet the NMDA
>> requirements, but that is closer to the existing YANG library structure,
>> and arguably simpler.
>> (2) An enhanced version of the structure (1) above, that is also extended
>> to allow the structure to be reused for schema-mount via an augmentation.
>>
>> For reference, at the end of this email, I have also included the tree
>> diagram of the existing YANG library, and the current YANG library bis
>> draft (draft-ietf-netconf-rfc7895bis-02) version.
>>
>> Considering the two new YANG library structures:
>>
>> ------------------------
>>
>> *(1) A simplified structure to make YANG library meet the NMDA
>> requirements, but that is closer to the existing YANG library structure.*
>>
>> The main changes are:
>> (i) Split "implemented modules" and "import-only-modules" into two
>> separate lists, making the most important list (i.e. implemented modules)
>> keyed by module name only and hence easier to reference.
>> (ii) Assume modules are implemented in all datastores by default (with a
>> "not-implemented-in" leaflist of datastores that a module is not
>> implemented in).
>> (iii) Assume that features are implemented in all datastores by default
>> (with a "not-implemented-in" leaflist of datastores that a feature is not
>> implemented in).
>> (iv) Deleted module-sets.
>> (v) Datastores are now just a list of supported datastores (that could
>> potentially be extended with further per datastore properties in future).
>>
>> Manually generated tree output for proposed YANG library:
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro modules
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision?      revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |                 -> ../name
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name                yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision    yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> ------------------------------
>>
>> *(2) An enhanced version of the structure (1) above, that is extended to
>> allow the structure to be reused for schema-mount via an augmentation.*
>>
>> This is similar to the structure above, except that the "the set of
>> modules" is contained in a list of named schema (e.g. similar to the schema
>> mount draft), allowing this structure to be re-used for schema mount.
>>
>> Schema mount would be expected to augment yang-library to add in the
>> additional schema mount information.  In the tree diagram, I have shown the
>> schema-mount mount-point augmentation, but not including namespaces yet.
>>
>> Every server would be required to provide at least one schema in the
>> schema list, and the primary schema for the device would always be given
>> the name "primary".
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro schema* [name]
>>     |  +--ro name           string
>>     |  +--ro checksum       string
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision?      yang:revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |  |              -> ../name
>>     |  |  +- schema-mount:mount-point* [label]
>>     |  |     +--ro label         yang:yang-identifier
>>     |  |     +--ro config?       boolean
>>     |  |     +--ro (schema-ref)
>>     |  |        +--:(inline)
>>     |  |        |  +--ro inline?       empty
>>     |  |        +--:(use-schema)
>>     |  |           +--ro use-schema* [name]
>>     |  |              +--ro name
>>     |  |              |       -> /yang-library/schema/name
>>     |  |              +--ro parent-reference*   yang:xpath1.0
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name                yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision    yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> Please can you provide comments on these structures, in particular:
>>
>> Is this version better (i.e. simpler) that the version currently in
>> draft-ietf-netconf-rfc7895bis-02 (below)?
>>
>> Should we try and make the structure extensible for schema-mount via
>> augmentation (i.e. version (2)), or is it better that schema-mount has its
>> own separate subtree?
>>
>> For reference only I have included the existing YANG library and YANG
>> library bis draft tree diagrams.
>>
>> Thanks,
>> Rob
>>
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (3)  The current YANG library structure in YANG library bis
>> (draft-ietf-netconf-rfc7895bis-02)
>>
>>    module: ietf-yang-library
>>        +--ro yang-library
>>           +--ro modules
>>           |  +--ro module* [id]
>>           |     +--ro id                  string
>>           |     +--ro name                yang:yang-identifier
>>           |     +--ro revision?           revision-identifier
>>           |     +--ro schema?             inet:uri
>>           |     +--ro namespace           inet:uri
>>           |     +--ro feature*            yang:yang-identifier
>>           |     +--ro deviation* [module]
>>           |     |  +--ro module    -> ../../id
>>           |     +--ro conformance-type    enumeration
>>           |     +--ro submodule* [name]
>>           |        +--ro name        yang:yang-identifier
>>           |        +--ro revision?   revision-identifier
>>           |        +--ro schema?     inet:uri
>>           +--ro module-sets
>>           |  +--ro module-set* [id]
>>           |     +--ro id        string
>>           |     +--ro module*   -> ../../../modules/module/id
>>           +--ro datastores
>>           |  +--ro datastore* [name]
>>           |     +--ro name          identityref
>>           |     +--ro module-set
>>           |             -> ../../../module-sets/module-set/id
>>           +--ro checksum       string
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (4)  The current YANG library structure (RFC 7895)
>>
>>       +--ro modules-state
>>          +--ro module-set-id    string
>>          +--ro module* [name revision]
>>             +--ro name                yang:yang-identifier
>>             +--ro revision            union
>>             +--ro schema?             inet:uri
>>             +--ro namespace           inet:uri
>>             +--ro feature*            yang:yang-identifier
>>             +--ro deviation* [name revision]
>>             |  +--ro name        yang:yang-identifier
>>             |  +--ro revision    union
>>             +--ro conformance-type    enumeration
>>             +--ro submodule* [name revision]
>>                +--ro name        yang:yang-identifier
>>                +--ro revision    union
>>                +--ro schema?     inet:uri
>>
>>
>>
>
>

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



Andy


<=
div>


On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    
The NMDA datastore draft
      (draft-ietf-netmod-revised-datastores-06) mandates two constrain=
ts
      that must apply:

    
(1) All conventional datastores must have exactly the same
      schema.=C2=A0 Hence differences in deviations or features are allowed
      between these datastores. (sec 5.1, first paragraph)

    

    
(2) The schema for operational must be a superset of all
      configuration datatstores, but that data nodes may be omitted (sec
      5.3, third paragraph).

    


    

    
This implies that only the following differences between
      datastores are allowed:

      =C2=A0(i) a feature can be disabled in conventional (and/or dynamic
      configuration datastores), but enabled in operational (e.g. for
      configurable router-id).=C2=A0

    
=C2=A0(ii) deviations apply in all datastores, except that

      =C2=A0 a) a deviation can remove nodes in the conventional datastores
      (if they were not configurable, like the feature example)

      =C2=A0 b) a deviation can remove nodes in a dynamic datastore (e.g.
      like I2RS)

      =C2=A0 c) a deviation can remove nodes from operational only if a
      server is unable to accurately report them.

    

    
(iii) modules exist in all datastores, except:

      =C2=A0 a) a module can be omitted from conventional datastores (e.g. =
if
      the module is not configurable)

      =C2=A0 b) a module can be omitted from a dynamic datastore (e.g. like
      I2RS)

      =C2=A0 c) a module can be omitted from operational only if a server i=
s
      unable to accurately report the data nodes within the module.

    


I am not convinced th=
at moving to a datastore-centric conformance model instead of server-centri=
c
is a good idea.=C2=A0 I get it that it is supposed to allow the=
 server to accurately reflect its implementation,
but it actually=
 says that servers MAY implement whatever partial subset of a module they w=
ant,
and a client MUST deal with the mess.=C2=A0

IMO, YANG says that features and deviations are server-wide, not p=
er-datastore.
This new complexity is non-trivial to implement, so=
 it may not be widely supported.

The WG seems conf=
used about the difference between a conformance model and capabilities repo=
rting.
(ii)(c) and (iii)(c) is about reporting, not conformance.=
=C2=A0 There is still no way to express
trivial use-cases in the =
conformance model such as "this module is intended for the I2RS epheme=
ral datastore only"



    

    Changing the type of a node between datastores, or changing its
    properties is not allowed.=C2=A0 The only difference allowed between da=
ta
    nodes in different datastores is the nodes existence.

    =C2=A0

    These rules seem more restrictive that what a server using split
    config state trees (IETF style, or OpenConfig style) can achieve
    using deviations today.

    


Lots of rules=
 to enforce actually makes the code harder, not easier.
=C2=A0

    Thanks,

    Rob

    


Andy
=C2=A0

    

    

    
On 09/11/2017 19:33=
, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
The new structure still has the same problems for the
          client as before.

        
It is a major change in the architecture to have different
          schema trees per datastore instead of per-server.

        
The server is allowed to have different features and
          deviations for the same objects.

        
The client is completely on its own trying to compare
          <operational> to anything

        
if the schema trees are different

        


        

        
=C2=A0 container foo {

        
=C2=A0 =C2=A0 leaf bar {

        
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;

        
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

        
=C2=A0 =C2=A0 }

        
=C2=A0 =C2=A0 leaf baz {
          
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X";
          
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

          
=C2=A0 =C2=A0 }

          
=C2=A0}

          


          

          
How does the client compare <running> to
            <operational> if the features do not match?

          
If the server deviates the leaf (e.g. change type string
            to int32) how does the client

          
compare the values?

          


          

          
This new complexity would be mandatory for the client to
            support in some proprietary

          
manner since the NMDA standard ignores these problems.

          


          

          
NMDA was supposed to be simpler
            because the client could compare intended

          
and applied values using the same
            object path. openconfig required a data

          
model change and a trivial
            name-mapping. In reality, NMDA

          
is far more disruptive to existing
            implementations.

          


          

          


          

          
Andy

          


          

          


          

          


            
On Thu, Nov 9, 2017 at 8:51 AM,
              Robert Wilton <rwilton@cisco.com>
              wrote:

              

                

                  
Hi,

                  
Given some of the feedback related to the
                    complexity of the YANG library bis structure, we
                    have come up with two other possible structures for
                    the YANG library data:

                  
(1) A simplified structure to make YANG library
                    meet the NMDA requirements, but that is closer to
                    the existing YANG library structure, and arguably
                    simpler.

                    (2) An enhanced version of the structure (1) above,
                    that is also extended to allow the structure to be
                    reused for schema-mount via an augmentation.

                  
For reference, at the end of this email, I have
                    also included the tree diagram of the existing YANG
                    library, and the current YANG library bis draft
                    (draft-ietf-netconf-rfc7895bis-02) version.

                  

                  
Considering the two new YANG library structures:

                  

                  
------------------------

                  

                  
(1) A simplified structure to make YANG library
                      meet the NMDA requirements, but that is closer to
                      the existing YANG library structure.

                  
The main changes are:

                    (i) Split "implemented modules" and
                    "import-only-modules" into two separate lists=
,
                    making the most important list (i.e. implemented
                    modules) keyed by module name only and hence easier
                    to reference.

                    (ii) Assume modules are implemented in all
                    datastores by default (with a "not-implemented-in&=
quot;
                    leaflist of datastores that a module is not
                    implemented in).

                    (iii) Assume that features are implemented in all
                    datastores by default (with a "not-implemented-in&=
quot;
                    leaflist of datastores that a feature is not
                    implemented in).

                    (iv) Deleted module-sets.

                    (v) Datastores are now just a list of supported
                    datastores (that could potentially be extended with
                    further per datastore properties in future).

                  

                  
Manually generated tree output for proposed YANG
                    library:

                  
module: ietf-yang-library

                    =C2=A0+--ro yang-library

                    =C2=A0=C2=A0=C2=A0 +--ro modules

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name=
]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revis=
ion?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submo=
dule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro revision?=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-i=
mplemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro featu=
re* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro not-implemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro devia=
tion*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ->
                      ../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 |=C2=A0 |

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-m=
odule* [name
                      revision]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 union

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro 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
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro submodule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<=
br>
                    =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // =
Allows
                      future per datastore properties.

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

                    =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 string

                  

                  
------------------------------

                  
(2) An enhanced version of the structure (1)
                      above, that is extended to allow the structure to
                      be reused for schema-mount via an augmentation.
                  
This is similar to the structure above, except that
                    the "the set of modules" is contained in a li=
st of
                    named schema (e.g. similar to the schema mount
                    draft), allowing this structure to be re-used for
                    schema mount.

                  
Schema mount would be expected to augment
                    yang-library to add in the additional schema mount
                    information.=C2=A0 In the tree diagram, I have shown th=
e
                    schema-mount mount-point augmentation, but not
                    including namespaces yet.

                  
Every server would be required to provide at least
                    one schema in the schema list, and the primary
                    schema for the device would always be given the name
                    "primary".

                  
module: ietf-yang-library

                    =C2=A0+--ro yang-library

                    =C2=A0=C2=A0=C2=A0 +--ro schema* [name]

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

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name=
]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revis=
ion?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submo=
dule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro revision?=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-i=
mplemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro featu=
re* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro not-implemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro devia=
tion*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      ../name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =


                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-m=
ount:mount-point*
                      [label]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro (schema-ref)

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--:(inline)

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=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=C2=A0 +--:(use-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=C2=A0=C2=A0 +--ro use-schema* [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=C2=A0 +--ro 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=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/schema/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=C2=A0 +--ro
                      parent-reference*=C2=A0=C2=A0 yang:xpath1.0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-m=
odule* [name
                      revision]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 union

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro 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
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro submodule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<=
br>
                    =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // =
Allows
                      future per datastore properties.

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

                    =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 string

                  
Please can you provide comments on these
                    structures, in particular:

                  
Is this version better (i.e. simpler) that the
                    version currently in draft-ietf-netconf-rfc7895bis-02
                    (below)?

                  

                  
Should we try and make the structure extensible for
                    schema-mount via augmentation (i.e. version (2)), or
                    is it better that schema-mount has its own separate
                    subtree?

                  
For reference only I have included the existing
                    YANG library and YANG library bis draft tree
                    diagrams.

                  

                  
Thanks,

                    Rob

                  

                  


                  

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(3)=C2=A0 The current YANG library structure in YANG
                    library bis (draft-ietf-netconf-rfc7895bis-02)

                  

                  
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(4)=C2=A0 The current YANG library structure (RFC 7895=
)

                  
      +--ro modules-st=
ate
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                  
 

                

              

            

            

          

        

      

    

    

  






--94eb2c0e61145eede3055db9c095--


From nobody Sat Nov 11 17:19:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06476128B91 for ; Sat, 11 Nov 2017 17:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 7g7iJBZRUHVW for ; Sat, 11 Nov 2017 17:18:59 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 648531252BA for ; Sat, 11 Nov 2017 17:18:58 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id a2so14785086lfh.11 for ; Sat, 11 Nov 2017 17:18:58 -0800 (PST)
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=7PGO3vA9HIAhwgujyzsETq+hd9ICyI969j6v1tVX3s4=; b=ODnicjQlLNPBv9U5Yj2vLb3XT9WZZTqoGLbQNkEI/1071uFRiAuc/7t12b1fWNokZG 5P2ouow0Zs823XuspeWvbl6CKOVKppZHE8igNfHXfCr9xEoDjmMsCmrxXcPeyly6hpBX bprvqCBDV2yKWRVsdvAdBhh2qtvKcazpnl9hDKoTTmveNv384A+sUMnVXTIbDVtRY4Vv vU4qvlBBxsbfOIJOHqu4rYlffZAmEVXkp7LwauAQaKJRnVFjf92Au6Tt3SvxwPzpf+sZ UgGNBnNx7z58WuLszQ1kcP1mY2icK0vTeXaCywOEIkG3r9iH31E3S7SEmHbGdZLMTa+O DXVA==
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=7PGO3vA9HIAhwgujyzsETq+hd9ICyI969j6v1tVX3s4=; b=Bzb2wDV0QI4CMMZfckOz3pYbc19Q/mULZ+dzkE8r0CtgoPVYVEuz5BDLLWPHwTKTOL dONpQB/tdCDudRuRsVulvu46T3PAj8UZPMwsRpxupitfdPT8UB8NrcASUOXkGqAhZ8zQ VG5ejf7koLHaV8IKr03+41yAVugQ2QPxHD7KpGsxeAVS3aD5rwIA1ULJUKjuQ9kgH5GD OnASjBQuvKK/73/75caTW0iDp/Zv7RRaKjMPl14FyeaygFg7PYpmoY4fZSDhlEaLkceV drdxQvSn59oxEnC9yiZDeciISLTd6sL7FEy0S7Ow2ueqaAoGqJMP6PpGSc7fU43Jv2pi 9mLQ==
X-Gm-Message-State: AJaThX4YNmhFc1EHL7NWN1EfDHvnvA0sLbX9DVOb8xt8rnXREeklt827 iS2HXqvUP0bDtTbO5gYSdjdVWPRNQNamnke23S6vsg==
X-Google-Smtp-Source: AGs4zMajALJzsQfbLdtcCoIH5PyTjC4Tz5C0mX9Jtz5s/Ge5GKu/CX47G6NfUIAqyGKSHgAExkK2yj0ezB1vVQ+udpI=
X-Received: by 10.46.57.3 with SMTP id g3mr1695856lja.77.1510449536476; Sat, 11 Nov 2017 17:18:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Sat, 11 Nov 2017 17:18:55 -0800 (PST)
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  
From: Andy Bierman 
Date: Sat, 11 Nov 2017 17:18:55 -0800
Message-ID: 
To: Robert Wilton 
Cc: Per Hedeland , Mahesh Jethanandani , NETCONF ,  "sec-ads@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082f6ee812bd78055dbef0bb"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:19:03 -0000

--089e082f6ee812bd78055dbef0bb
Content-Type: text/plain; charset="UTF-8"

Hi,

I have made the descendant node clarifications to the github draft-09
version.
No other changes have been made.

I think you have shown that a lot of "deny rule" maintenance would be needed
with the new edit-op=none change, possibly making real deployments more
vulnerable
than the current behavior for access operation "none".


Andy



Andy


On Fri, Nov 10, 2017 at 12:36 PM, Robert Wilton  wrote:

> Hi Andy,
>
> Yes, I think those changes look OK.
>
> In addition, in 3.3.4, does it make sense to clarify that descendant data
> nodes are excluded on get requests:
>
> OLD:
>
>   Data nodes to which the client does not have read access are silently
>    omitted from the  message.
>
>
> NEW:
>
>   Data nodes to which the client does not have read access are silently
>    omitted, along with any descendants, from the  message.
>
>
> Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate that
> the operation is rejected if the data node, or any ancestor parent data
> node, has a default-deny-write/all statement.
>
> ---
>
> I think that these changes above fix the NACM draft to make it consistent
> with the examples.
>
> The remaining issue is the one first raised in this thread, i.e. the
> change of operation 'none' now requiring 'read' permissions.  If that
> change is retained to mitigate the security issue, then we also need to
> think about how to reduce the impact of the change (i.e. the issue in my
> original response to this thread still applies.)
>
> Thanks,
> Rob
>
>
> On 10/11/2017 18:23, Andy Bierman wrote:
>
> Hi,
>
> Here are some proposed edits to make the data rule consistent with the
> examples.
> Note that this issue is not related to the edit in the original 1-week
> change.
>
>
> sec. 3.3.5:
>
> OLD:
>
>
>       data node rule:  controls access for a specific data node, identified
>       by its path location within the conceptual XML document for the
>       data node.
>
>
> NEW:
>
>       data node rule:  controls access for a specific data node and its
> descendants,
>       identified by its path location within the conceptual XML document
> for the
>       data node.
>
>
> sec 3.4.5, step 6, bullet 2:
>
>
> OLD:
>
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node.
>
>       NEW:
>
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node. A path is
>            considered to match if the current data node is the data node
>            specified by the path, or is a descendant data node of this data node.
>
> appendix B.4: (2 bugs in explanation)
>
> OLD:
>
>       deny-nacm:  This rule denies the "guest" group any access to the
>        subtree.  Note that the default namespace is only
>       applicable because this subtree is defined in the same namespace
>       as the  element.
>
>  NEW:
>
>       deny-nacm:  This rule denies the "guest" group any access to the
>        subtree.
>
> Andy
>
>
> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton  wrote:
>
>>
>>
>> On 10/11/2017 16:33, Andy Bierman wrote:
>>
>>
>>
>> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton  wrote:
>>
>>>
>>>
>>> On 10/11/2017 15:49, Andy Bierman wrote:
>>>
>>>
>>>
>>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland  wrote:
>>>
>>>> On 2017-11-10 11:42, Robert Wilton wrote:
>>>> >
>>>> >
>>>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Mahesh Jethanandani
>>>> >> mjethanandani@gmail.com 
>>>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >>> > wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> The term "data node" is used in the document to refer to the
>>>> top-level node
>>>> >>> of the specified object, not the entire subtree (if any).
>>>> >>>
>>>> >>> The data-rule /foo does not match /foo/child1 in the text below.
>>>> >>> The child nodes are omitted because of step 11.
>>>> >>> The admin has to explicitly permit individual child nodes (or
>>>> modules).
>>>> >>> This seems correct if the read-default is "deny".
>>>> >>>
>>>> >>> Should any text be added or changed to make this more clear?
>>>> >>
>>>> >> I would agree with Robert that it was not entirely clear that rule
>>>> applied on the parent data-node does not apply to the child nodes. So yes,
>>>> it would help to clarify it.
>>>> > We should be doing more than clarifying it.  We need to fix it so
>>>> that it works in a sensible way.  I.e. to make the normative text
>>>> consistent with the behaviour currently described in the examples in
>>>> > the appendix B.4.
>>>> >
>>>> > If we follow Andy's interpretation that a data rule doesn't match
>>>> child nodes then those examples are completely wrong.  E.g. the 4th rule is
>>>> described as "This rule gives the 'admin' group read-write
>>>> > access to all acme  entries."  But If the path only
>>>> strictly matches "/acme:interfaces/acme:interface" then the admin
>>>> group rule achieves nothing useful at all.  The admin is not even
>>>> > allowed to create an interface because they would not even have
>>>> permission to write to the list key 'name' node required to create a list
>>>> entry!  Instead, a separate rule would be required for every
>>>> > single possible schema node under "/acme:interfaces/acme:interface"!
>>>> I think that this makes "permit" data-node rules completely unusable.
>>>>
>>>> I strongly agree with this, and I would say that it isn't only the case
>>>> for "permit" rules - e.g. denying some access to a subtree of the data
>>>> model that would otherwise be permitted due to defaults is at least as
>>>> common, and the rules would be just as unusable for that.
>>>>
>>>> Besides the examples, I think that the very use of the term "match",
>>>> though unfortunately not defined, strongly suggests that it is something
>>>> other than use of e.g. the term "identify" would imply. Additionally,
>>>> this text in the description of the 'path' leaf is consistent with the
>>>> match being a prefix match:
>>>>
>>>>        The special value '/' refers to all possible
>>>>        datastore contents.";
>>>>
>>>> FWIW, our NACM implementation, available to (and used by) customers
>>>> since 2012, follows the prefix match logic, and I have yet to hear of
>>>> any user expecting it to do otherwise.
>>>>
>>>> > To fix this properly, we need to make the data-node path rule a
>>>> prefix match.  In particular, we need text that specifies:
>>>> >
>>>> > (i) that a data-node path match succeeds if it matches the path
>>>> prefix from the root of the tree.  I.e. so the data-rule "/foo" matches
>>>> "/foo" and all of foo's descendant children nodes.
>>>>
>>>> Strongly agree.
>>>>
>>>>
>>>
>>> I do not see how the text can be interpreted this way.
>>>
>>>
>>> Because otherwise the path match part of the NACM solution is really
>>> broken, and the path based examples in the appendix are entirely misleading
>>> and wrong.  The only way those examples make sense is the paths match
>>> descendant children nodes as well.
>>>
>>>
>>
>> IMO the text does not support this interpretation.
>>
>> The examples in B.4, and the definition of "/" matching all nodes
>> supports this interpretation.
>>
>> Hence, my opinion is that it is the text in 3.4.5 that is incorrectly
>> specified; and that the examples, definition of "/" and standard practice
>> are right.
>>
>> Otherwise, how did IETF manage to publish an RFC where the path based
>> examples are so completely wrong?   Whoever wrote and reviewed those
>> examples clearly had a different interpretation of how these path based
>> ACLs worked.
>>
>>
>> There is nothing said about inheriting state from the parent data node.
>> I think no matter how the permissions are derived, one can
>> find examples that work better or worse because of it.
>>
>> No.  If the rules apply to descendant children, all normal examples work
>> well (including the ones in the appendix).
>>
>>
>> IMO the number of rules required to implement a use-case is not
>> very relevant or objective criteria.
>>
>> Yes it is, particularly when the difference is between needing a 1 line
>> rule, and a 100+ line rule.
>>
>>
>> Using the previous example of /home and /home/user1,
>> if the user1 is given read access to /home, then (according to you)
>> it also has read access to every user subtree under /home.
>>
>> Instead of 1 rule per user, 2 rules are needed
>>
>> No, just 1 rule per user:
>>    read-default=deny
>>    group=user1, path=/home/user1, action=permit
>>
>> This is because of my two proposed changes:
>>
>> (i) that a data-node path match succeeds if it matches the path prefix
>> from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and
>> all of foo's descendant children nodes.
>> <- This means that you only need 1 entry instead of 100 entries.
>>
>> (ii) if a data-node rule has action "permit" then it implicitly allows
>> read access for all ancestor parent nodes up to the root.  (I.e. to
>> mitigate the original change proposed on this thread.)
>> <- This means that you don't need a separate read rule for "/home".  Read
>> access to that node it is implicitly given via "group=user1,
>> path=/home/user1, action=permit", hence meaning that the rule works the
>> same way as it does on an rfc6536 compliant implementation.
>>
>>
>>    read-default=deny
>>    group=*, path=/home, action=permit
>>    group=user1, path=/home/user1, action=permit
>>
>> The above rules would allow access for every user to every other user.
>> The 2nd rule has no effect, which is counter-intuitive.
>> Every user dir would need 2 rules
>>
>>    read-default=deny
>>    group=*, path=/home, action=permit
>>    group=user1, path=/home/user1, action=permit
>>    group=*, path=/home/user1, action=deny
>>
>> There is nothing that says this is how it works.
>>> If it did, once could never have privileged sub-fiolders
>>>
>>>      /var/log -> permit
>>>      /var/log/apache2  -> deny
>>>
>>>
>>> Yes, you can, you just list the longest path first in the list of rules:
>>>
>>>  (1)  /var/log/apache2  -> deny
>>>   (2) /var/log -> permit
>>>
>>> Any requests that attempt to access anything under /var/log/apache2
>>> would match rule (1) and be denied.
>>> Any requests that attempt to access anything under /var/log, but not
>>> under /var/log/apache2, would fail to match rule (1), but would match rule
>>> (2) instead and be permitted.
>>>
>>>
>>>
>> I do not see any text in the draft or RFC 7950 that
>> suggests that /var/log and /var/log/apache2 represent the same data node.
>>
>> They are different data nodes, but I don't see how that is relevant.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>>
>>>
>>>
>>>> > (ii) if a data-node rule has action "permit" then it implicitly
>>>> allows read access for all ancestor parent nodes up to the root.  (I.e. to
>>>> mitigate the original change proposed on this thread.)
>>>>
>>>> This seems reasonable to me, although I haven't at this point evaluated
>>>> the suggestion in detail. In any case I think the main point both
>>>> regarding this and the prefix match is that this update to 6536 can't
>>>> make radical changes to the semantics compared to a "reasonable
>>>> interpretation" (hard to define, I know) of the under-specified
>>>> original.
>>>>
>>>
>>> The text does not say this at all so I do not approve of this change
>>>
>>>
>>> In the RFC version of the NACM this wasn't required because operation
>>> 'none' didn't require read access.  Now read access is required even for
>>> operation 'none', then this change makes sense to make the NACM changes
>>> backwards compatible, whilst still closing the security hole.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>>>
>>>>
>>>> --Per
>>>>
>>>>
>>>
>>> Andy
>>>
>>>
>>>> > Thanks,
>>>> > Rob
>>>> >
>>>> >
>>>> >>
>>>> >> Thanks
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> Andy
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >>> > wrote:
>>>> >>>
>>>> >>>     Hi Andy,
>>>> >>>
>>>> >>>     It isn't clear to me whether matching a path in NACM either:
>>>> >>>       (i) Only applies to the specific node, and not any children,
>>>> or
>>>> >>>       (ii) Applies to the specific node and all descendant children
>>>> nodes as well.
>>>> >>>
>>>> >>>     As an example, using the tree below.  if I have a rule that
>>>> matches path "A/B" then does that apply to only the specific node "A/B", or
>>>> does it also apply to all descendant children of "A/B" as
>>>> >>>     well?
>>>> >>>
>>>> >>>     In rfc6536bis-08, section "3.4.5.  Data Node Access
>>>> Validation", step 6 states:
>>>> >>>
>>>> >>>             *  The rule does not have a "rule-type" defined or the
>>>> "rule-
>>>> >>>                type" is "data-node" and the *"path" matches the
>>>> requested data node*, action node, or notification node.
>>>> >>>
>>>> >>>
>>>> >>>     My reading of this is that it implies that the interpretation
>>>> of the path rule is (i), but this is not how I would normally expect an ACL
>>>> rule to apply in a tree like object (e.g a directory
>>>> >>>     file system).
>>>> >>>
>>>> >>>     However, the examples in Appendix B.4. imply that the path rule
>>>> is to be interpreted like (ii), or otherwise the example rules seem to be
>>>> mostly pointless.
>>>> >>>
>>>> >>>     E.g. taking this example from appendix B.4:
>>>> >>>
>>>> >>>            
>>>> >>>              permit-dummy-interface
>>>> >>>              >>> http://example.com/ns/itf>>
>>>> >>>                /acme:interfaces/acme:interface[acme:name='dummy']
>>>> >>>              
>>>> >>>              read update
>>>> >>>              permit
>>>> >>>              
>>>> >>>                Allow the limited and guest groups read
>>>> >>>                and update access to the dummy interface.
>>>> >>>              
>>>> >>>            
>>>> >>>
>>>> >>>
>>>> >>>     If the rule is (i)  then the access rule allows the client to
>>>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>> but not any child leafs/containers of that interface,
>>>> >>>     this doesn't seem useful.
>>>> >>>
>>>> >>>     Further comments inline below ...
>>>> >>>
>>>> >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>> >>>>     Hi,
>>>> >>>>
>>>> >>>>     This change has no impact on the server if /nacm/read-default
>>>> is "permit".
>>>> >>>>     In that case, the extra read rules for /A and /A/B are not
>>>> needed.
>>>> >>>     I agree.
>>>> >>>
>>>> >>>>     An operator worried about read access should set read-default
>>>> to "deny".
>>>> >>>     I agree.  This is the scenario that I'm considering.
>>>> >>>
>>>> >>>>     In that case, explicit rules to read /A and /A/B would be
>>>> needed
>>>> >>>>     in the new NACM.
>>>> >>>     Yes, if the interpretation of the rule is (i) above.
>>>> >>>     Otherwise if the interpretation is (ii) then you only need
>>>> "read /A" since that implies "read A/B" as well (as long as the rules are
>>>> listed in the correct order).
>>>> >>>
>>>> >>>
>>>> >>>>       The deny rules would not be needed.
>>>> >>>     Only if the interpretation of the rule is (i) above.  In which
>>>> case the  "read/write 'A/B/J' rule would not be sufficient.  It would be
>>>> necessary to define an Xpath expressions that contains
>>>> >>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>> >>>
>>>> >>>     If the interpretation of the rule is (ii) then you would also
>>>> need all the explicit deny statements as well, otherwise they would be
>>>> allowed by the "read /A" rule above.
>>>> >>>
>>>> >>>     Thanks,
>>>> >>>     Rob
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>>     Andy
>>>> >>>>
>>>> >>>>
>>>> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <
>>>> rwilton@cisco.com > wrote:
>>>> >>>>
>>>> >>>>         Hi,
>>>> >>>>
>>>> >>>>         I'm not sure about this change.
>>>> >>>>
>>>> >>>>         I'm not that familiar with NACM, but if you want to give a
>>>> particular set of users read/write access to a subtree, but not allow them
>>>> to have any other access to the configuration in the
>>>> >>>>         running datastore then with the existing RFC, that could
>>>> be expressed with a single rule (example in 6536bis, appendix B.4)
>>>> >>>>
>>>> >>>>         With this new change, I think that you may need to
>>>> configure many more rules to achieve the same thing.  I think that you
>>>> would need to give read access to the top node in the desired
>>>> >>>>         path, and then separate explicit "deny" rules for every
>>>> sibling child node walking from the top of the tree down to the data node
>>>> that read/write access is actually being given to.  The
>>>> >>>>         example below may explain my understanding better:
>>>> >>>>
>>>> >>>>         E.g. For a tree of data nodes, rooted at A, if we wanted
>>>> to give read/write access only to "J" subtree, and no access for the rest
>>>> of the tree then:
>>>> >>>>
>>>> >>>>                          A
>>>> >>>>                          |
>>>> >>>>                 --------------------
>>>> >>>>                 |      |     |     |
>>>> >>>>                 B      C     D     E
>>>> >>>>                 |
>>>> >>>>            -----------
>>>> >>>>            |   |  |  |
>>>> >>>>            F   G  H  J
>>>> >>>>                      |
>>>> >>>>                     ...
>>>> >>>>
>>>> >>>>
>>>> >>>>         In the old model, I think that the ACL rules would be 1
>>>> rules long (assuming default deny all):
>>>> >>>>            "read/write 'A/B/J'
>>>> >>>>
>>>> >>>>         In the new model, I think that the equivalent ACL rules
>>>> would need to be 8 rules long (assuming default deny all):
>>>> >>>>            "read/write 'A/B/J'
>>>> >>>>            "read A"
>>>> >>>>            "deny C"
>>>> >>>>            "deny D"
>>>> >>>>            "deny E"
>>>> >>>>            "deny F"
>>>> >>>>            "deny G"
>>>> >>>>            "deny H"
>>>> >>>>
>>>> >>>>         Note, I am assuming that a "path" rule matches for the
>>>> given path and all descendant nodes.  The draft doesn't seem to be
>>>> particularly clear on this point (it states that the rule applies
>>>> >>>>         when the path matches, but this would seem to be counter
>>>> intuitive), and perhaps it could be clarified.
>>>> >>>>
>>>> >>>>         If this change is allowed, then the example in appendix
>>>> B.4 looks like it would need to be fixed, since the "limited-acl" probably
>>>> wouldn't give any access at all, unless default read
>>>> >>>>         access had been given.
>>>> >>>>
>>>> >>>>         But, possibly I'm misunderstanding how this all works!  If
>>>> so, apologies for the noise :-)
>>>> >>>>
>>>> >>>>         Thanks,
>>>> >>>>         Rob
>>>> >>>>
>>>> >>>>
>>>> >>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>> >>>>>         Dear all,
>>>> >>>>>
>>>> >>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis,
>>>> suggested by the Security AD Eric Rescola part of the IESG review, which I
>>>> would like to validate with the WG. See
>>>> >>>>>         https://tools.ietf.org/rfcdif
>>>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt <
>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6
>>>> 536bis-08.txt>
>>>> >>>>>
>>>> >>>>>         
>>>> >>>>>         The NETCONF WG was cc'ed for the entire discussion.
>>>> >>>>>         What do you think? I will draw the conclusions by Friday
>>>> Nov 10th.
>>>> >>>>>
>>>> >>>>>         Note: If the WG is fine, the next step is to approve this
>>>> document.
>>>> >>>>>
>>>> >>>>>         Regards, Benoit
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>         _______________________________________________
>>>> >>>>>         Netconf mailing list
>>>> >>>>>         Netconf@ietf.org 
>>>> >>>>>         https://www.ietf.org/mailman/listinfo/netconf <
>>>> https://www.ietf.org/mailman/listinfo/netconf>
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Netconf mailing list
>>>> >>> Netconf@ietf.org 
>>>> >>> https://www.ietf.org/mailman/listinfo/netconf
>>>> >>
>>>> >> Mahesh Jethanandani
>>>> >> mjethanandani@gmail.com 
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Netconf mailing list
>>>> > Netconf@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/netconf
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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


Hi,

I have made the descendant node cla=
rifications to the github draft-09 version.
No other changes have=
 been made.

I think you have shown that a lot of &=
quot;deny rule" maintenance would be needed
with the new edi=
t-op=3Dnone change, possibly making real deployments more vulnerable
<=
div>than the current behavior for access operation "none".
<=
div>
Andy


On Fri, Nov 10, 2017 at 12:36 PM, Robert W=
ilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    
Yes, I think those changes look OK.

    
In addition, in 3.3.4, does it make sense to clarify that
      descendant data nodes are excluded on get requests:

    
OLD:

    
  =
Data nodes to which the client does not have read access are silently
   omitted from the <rpc-reply> message.


    

    NEW:

    

    
  =
Data nodes to which the client does not have read access are silently
   omitted, along with any descendants, from the <rpc-reply> message.=


    

    Also, rules 9 and 10 of 3.4.5 may also need to be updated to
    indicate that the operation is rejected if the data node, or any
    ancestor parent data node, has a default-deny-write/all statement.

    

    ---

    

    I think that these changes above fix the NACM draft to make it
    consistent with the examples.

    

    The remaining issue is the one first raised in this thread, i.e. the
    change of operation 'none' now requiring 'read' permiss=
ions.=C2=A0 If
    that change is retained to mitigate the security issue, then we also
    need to think about how to reduce the impact of the change (i.e. the
    issue in my original response to this thread still applies.)

    

    Thanks,

    Rob

    

    

    
On 10/11/2017 18:2=
3, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
Here are some proposed edits to make the data rule
          consistent with the examples.

        
Note that this issue is not related to the edit in the
          original 1-week change.

        


        

        


        

        
sec. 3.3.5:

        


        

        
OLD:

        


        

        

          


          

          
=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls access f=
or a specific
            data node, identified

          
=C2=A0 =C2=A0 =C2=A0 by its path location within the concept=
ual XML
            document for the

          
=C2=A0 =C2=A0 =C2=A0 data node.

        

        


        

        


        

        
NEW:

        


        

        

          
=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls access f=
or a specific
            data node and its descendants,

          
=C2=A0 =C2=A0 =C2=A0 identified by its path location within =
the
            conceptual XML document for the

          
=C2=A0 =C2=A0 =C2=A0 data node.

        

        


        

        


        

        
sec 3.4.5, step 6, bullet 2:

        


        

        


        

        
OLD:

        

          


          

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a=
 "rule-type" defined
            or the "rule-

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "=
;data-node" and the "path" matches
            the requested

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action n=
ode, or notification node.

        

        

          
      
          

          
NEW:
          

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not have a=
 "rule-type" defined or the "rule-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "data-node&=
quot; and the "path" matches the requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action node, or =
notification node. A path is
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0considered to match if the current data node is the=
 data node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0specified by the path, or is a descendant data node of this data node=
.

          

          

          
appendix =
B.4: (2 bugs in explanation)

          

          
OLD:
          

          
      deny-nacm:  This rule denies the "guest" grou=
p any access to the
      <nacm> subtree.  Note that the default namespace is only
      applicable because this subtree is defined in the same namespace
      as the <data-rule> element.


          

          
 

          
NEW:
  =
    deny-nacm:  This rule denies the "guest" group any access to =
the
      <nacm> subtree.







Andy





        

      

      


        
On Fri, Nov 10, 2017 at 9:24 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            

              


              

              

              
On
                10/11/2017 16:33, Andy Bierman wrote:

              

              

                


                  


                    
On Fri, Nov 10, 2017 at
                      8:16 AM, Robert Wilton <rwilton@cisco.com>
                      wrote:

                      

                        

                          


                          

                          

                          
On
                            10/11/2017 15:49, Andy Bierman wrote:

                          

                          

                            


                              


                                
On Fri, Nov 10,
                                  2017 at 5:07 AM, Per Hedeland <per@tail-f=
.com>
                                  wrote:

                                  
On
                                    2017-11-10 11:42, Robert Wilton
                                    wrote:

                                    >

                                    >

                                    > On 10/11/2017 10:02, Mahesh
                                    Jethanandani wrote:

                                    >>

                                    >>

                                    >>

                                    >>

                                    >> Mahesh Jethanandani

                                    >> mjethanandani@gmail.com
                                    <mailto:mjethanandani@gmail.com>

                                    >> On Nov 10, 2017, at 10:07
                                    AM, Andy Bierman <andy@yumaworks.com
                                    <mailto:andy@yumaworks.com>>
                                    wrote:

                                    >>

                                    >>> Hi,

                                    >>>

                                    >>> The term "data node&q=
uot; is
                                    used in the document to refer to the
                                    top-level node

                                    >>> of the specified
                                    object, not the entire subtree (if
                                    any).

                                    >>>

                                    >>> The data-rule /foo does
                                    not match /foo/child1 in the text
                                    below.

                                    >>> The child nodes are
                                    omitted because of step 11.

                                    >>> The admin has to
                                    explicitly permit individual child
                                    nodes (or modules).

                                    >>> This seems correct if
                                    the read-default is "deny".
                                    >>>

                                    >>> Should any text be
                                    added or changed to make this more
                                    clear?

                                    >>

                                    >> I would agree with Robert
                                    that it was not entirely clear that
                                    rule applied on the parent data-node
                                    does not apply to the child nodes.
                                    So yes, it would help to clarify it.
                                    > We should be doing more than
                                    clarifying it.=C2=A0 We need to fix it =
so
                                    that it works in a sensible way.=C2=A0
                                    I.e. to make the normative text
                                    consistent with the behaviour
                                    currently described in the examples
                                    in

                                    > the appendix B.4.

                                    >

                                    > If we follow Andy's
                                    interpretation that a data rule
                                    doesn't match child nodes then thos=
e
                                    examples are completely wrong.=C2=A0 E.=
g.
                                    the 4th rule is described as "This
                                    rule gives the 'admin' group
                                    read-write

                                    > access to all acme
                                    <interface> entries."=C2=A0 =
But If
                                    the path only strictly matches
                                    "/acme:interfaces/acme:interface"
                                    then the admin group rule achieves
                                    nothing useful at all.=C2=A0 The admin =
is
                                    not even

                                    > allowed to create an interface
                                    because they would not even have
                                    permission to write to the list key
                                    'name' node required to create =
a
                                    list entry!=C2=A0 Instead, a separate
                                    rule would be required for every

                                    > single possible schema node
                                    under "/acme:interfaces/acme:inter=
face"!=C2=A0
                                    I think that this makes "permit&qu=
ot;
                                    data-node rules completely unusable.
                                    

                                    I strongly agree with this, and I
                                    would say that it isn't only the
                                    case

                                    for "permit" rules - e.g. den=
ying
                                    some access to a subtree of the data
                                    model that would otherwise be
                                    permitted due to defaults is at
                                    least as

                                    common, and the rules would be just
                                    as unusable for that.

                                    

                                    Besides the examples, I think that
                                    the very use of the term "match&qu=
ot;,

                                    though unfortunately not defined,
                                    strongly suggests that it is
                                    something

                                    other than use of e.g. the term
                                    "identify" would imply.
                                    Additionally,

                                    this text in the description of the
                                    'path' leaf is consistent with =
the

                                    match being a prefix match:

                                    

                                    =C2=A0 =C2=A0 =C2=A0 =C2=A0The special =
value '/' refers
                                    to all possible

                                    =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore co=
ntents.";

                                    

                                    FWIW, our NACM implementation,
                                    available to (and used by) customers
                                    since 2012, follows the prefix match
                                    logic, and I have yet to hear of

                                    any user expecting it to do
                                    otherwise.

                                    

                                    > To fix this properly, we need
                                    to make the data-node path rule a
                                    prefix match.=C2=A0 In particular, we
                                    need text that specifies:

                                    >

                                    > (i) that a data-node path match
                                    succeeds if it matches the path
                                    prefix from the root of the tree.=C2=A0
                                    I.e. so the data-rule "/foo" =
matches
                                    "/foo" and all of foo's d=
escendant
                                    children nodes.

                                    

                                    Strongly agree.

                                    

                                  

                                  


                                  

                                  


                                  

                                  
I do not see how the text can be
                                    interpreted this way.

                                

                              

                            

                          

                          

                          Because otherwise the path match part of the
                          NACM solution is really broken, and the path
                          based examples in the appendix are entirely
                          misleading and wrong.=C2=A0 The only way those
                          examples make sense is the paths match
                          descendant children nodes as well.

                          

                        

                      

                      


                      

                      


                      

                      
IMO the text does not support this
                        interpretation.

                    

                  

                

              

              The examples in B.4, and the definition of "/" matc=
hing
              all nodes supports this interpretation.

              

              Hence, my opinion is that it is the text in 3.4.5 that is
              incorrectly specified; and that the examples, definition
              of "/" and standard practice are right.

              

              Otherwise, how did IETF manage to publish an RFC where the
              path based examples are so completely wrong?=C2=A0=C2=A0 Whoe=
ver
              wrote and reviewed those examples clearly had a different
              interpretation of how these path based ACLs worked. 

              

              

              

                

                  

                    

                      
There is nothing said about inheriting state
                        from the parent data node.

                      
I think no matter how the permissions are
                        derived, one can

                      
find examples that work better or worse
                        because of it.

                    

                  

                

              

              No.=C2=A0 If the rules apply to descendant children, all norm=
al
              examples work well (including the ones in the appendix).

              

              

              

                

                  

                    

                      
IMO the number of rules required to implement
                        a use-case is not

                      
very relevant or objective criteria.

                    

                  

                

              

              Yes it is, particularly when the difference is between
              needing a 1 line rule, and a 100+ line rule.

              

              

                

                  

                    

                      


                      

                      
Using the previous example of /home and
                        /home/user1,

                      
if the user1 is given read access to /home,
                        then (according to you)

                      
it also has read access to every user subtree
                        under /home.

                    

                  

                

              

              

                

                  

                    

                      
Instead of 1 rule per user, 2 rules are
                        needed

                    

                  

                

              

              No, just 1 rule per user:

              =C2=A0=C2=A0 read-default=3Ddeny

              =C2=A0=C2=A0 group=3Duser1, path=3D/home/user1, action=3Dperm=
it

              

              This is because of my two proposed changes:

              

              (i) that a data-node path match succeeds if it matches the
              path prefix from the root of the tree.=C2=A0 I.e. so the
              data-rule "/foo" matches "/foo" and all o=
f foo's
              descendant children nodes.

              <- This means that you only need 1 entry instead of 100
              entries.

              

              (ii) if a data-node rule has action "permit" then i=
t
              implicitly allows read access for all ancestor parent
              nodes up to the root.=C2=A0 (I.e. to mitigate the original
              change proposed on this thread.)

              <- This means that you don't need a separate read rule
              for "/home".=C2=A0 Read access to that node it is i=
mplicitly
              given via "group=3Duser1, path=3D/home/user1, action=3Dp=
ermit",
              hence meaning that the rule works the same way as it does
              on an rfc6536 compliant implementation.

              

              

                

                  

                    

                      


                      

                      
=C2=A0 =C2=A0read-default=3Ddeny

                      
=C2=A0 =C2=A0group=3D*, path=3D/home, action=3Dp=
ermit

                      
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1,
                        action=3Dpermit

                      


                      

                      
The above rules would allow access for every
                        user to every other user.

                      
The 2nd rule has no effect, which is
                        counter-intuitive.

                      
Every user dir would need 2 rules

                      


                      

                      

                        
=C2=A0 =C2=A0read-default=3Ddeny

                        
=C2=A0 =C2=A0group=3D*, path=3D/home, action=
=3Dpermit

                        
=C2=A0 =C2=A0group=3Duser1, path=3D/home/user1=
,
                          action=3Dpermit

                      

                      
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, acti=
on=3Ddeny

                      

                      


                      

                      

                        

                          

                            

                              

                                

                                  
There is nothing that says this
                                    is how it works.

                                  
If it did, once could never have
                                    privileged sub-fiolders

                                  


                                  

                                  
=C2=A0 =C2=A0 =C2=A0/var/log -> p=
ermit

                                  
=C2=A0 =C2=A0 =C2=A0/var/log/apache2=
 =C2=A0-> deny

                                

                              

                            

                          

                          

                          Yes, you can, you just list the longest path
                          first in the list of rules:

                          

                          =C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> deny=


                          =C2=A0 (2) /var/log -> permit

                          

                          Any requests that attempt to access anything
                          under /var/log/apache2 would match rule (1)
                          and be denied.

                          Any requests that attempt to access anything
                          under /var/log, but not under
                          /var/log/apache2, would fail to match rule
                          (1), but would match rule (2) instead and be
                          permitted.

                          

                          

                        

                      

                      


                      

                      
I do not see any text in the draft or RFC
                        7950 that

                      
suggests that /var/log and /var/log/apache2
                        represent the same data node.

                    

                  

                

              

              They are different data nodes, but I don't see how that i=
s
              relevant.

              

              Thanks,

              Rob

              

              

              

                

                  

                    

                      


                      

                      


                      

                      
Andy

                      


                      

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  


                                  

                                  
=C2=A0

                                  

                                  

                                    > (ii) if a data-node rule has
                                    action "permit" then it impli=
citly
                                    allows read access for all ancestor
                                    parent nodes up to the root.=C2=A0 (I.e=
.
                                    to mitigate the original change
                                    proposed on this thread.)

                                    

                                    This seems reasonable to me,
                                    although I haven't at this point
                                    evaluated

                                    the suggestion in detail. In any
                                    case I think the main point both

                                    regarding this and the prefix match
                                    is that this update to 6536 can't
                                    make radical changes to the
                                    semantics compared to a "reasonabl=
e

                                    interpretation" (hard to define, I
                                    know) of the under-specified

                                    original.

                                  

                                  


                                  

                                  
The text does not say this at all
                                    so I do not approve of this change
                                

                              

                            

                          

                          

                          In the RFC version of the NACM this wasn't
                          required because operation 'none' didn=
9;t
                          require read access.=C2=A0 Now read access is
                          required even for operation 'none', then =
this
                          change makes sense to make the NACM changes
                          backwards compatible, whilst still closing the
                          security hole.

                          

                          Thanks,

                          Rob

                          

                          

                            

                              

                                

                                  


                                  

                                  
=C2=A0

                                  

                                    

                                    --Per

                                    

                                  

                                  


                                  

                                  


                                  

                                  
Andy

                                  
=C2=A0

                                  

                                    > Thanks,

                                    > Rob

                                    >

                                    >

                                    >>

                                    >> Thanks

                                    >>

                                    >>>

                                    >>>

                                    >>> Andy

                                    >>>

                                    >>>

                                    >>> On Thu, Nov 9, 2017 at
                                    2:44 AM, Robert Wilton <rwilton@cisco.com
                                    <mailto:rwilton@cisco.com>>
                                    wrote:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Hi Andy=
,

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0It isn&=
#39;t clear to
                                    me whether matching a path in NACM
                                    either:

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
(i) Only applies
                                    to the specific node, and not any
                                    children, or

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
(ii) Applies to
                                    the specific node and all descendant
                                    children nodes as well.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0As an e=
xample,
                                    using the tree below.=C2=A0 if I have a
                                    rule that matches path "A/B" =
then
                                    does that apply to only the specific
                                    node "A/B", or does it also a=
pply to
                                    all descendant children of "A/B&qu=
ot; as

                                    >>>=C2=A0 =C2=A0 =C2=A0well?
                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0In rfc6=
536bis-08,
                                    section "3.4.5.=C2=A0 Data Node Ac=
cess
                                    Validation", step 6 states:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0*=C2=A0 The rule
                                    does not have a "rule-type" d=
efined
                                    or the "rule-

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type" is
                                    "data-node" and the *"pa=
th" matches
                                    the requested data node*, action
                                    node, or notification node.

                                    >>>

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0My read=
ing of this
                                    is that it implies that the
                                    interpretation of the path rule is
                                    (i), but this is not how I would
                                    normally expect an ACL rule to apply
                                    in a tree like object (e.g a
                                    directory

                                    >>>=C2=A0 =C2=A0 =C2=A0file sy=
stem).

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0However=
, the
                                    examples in Appendix B.4. imply that
                                    the path rule is to be interpreted
                                    like (ii), or otherwise the example
                                    rules seem to be mostly pointless.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0E.g. ta=
king this
                                    example from appendix B.4:

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 <rule>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <name>permit-dummy-interface</=
name>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 <path
                                    xmlns:acme=3D"http://example.com/ns/itf"
                                    <http://example.com/ns/itf>&g=
t;

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    /acme:interfaces/acme:interface[ac=
me:name=3D'dummy']

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    </path>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <access-operations>read
                                    update</access-operations>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <action>permit</action>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    <comment>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow
                                    the limited and guest groups read

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and
                                    update access to the dummy
                                    interface.

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0
                                    </comment>

                                    >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0
                                    </rule>

                                    >>>

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0If the =
rule is (i)=C2=A0
                                    then the access rule allows the
                                    client to read the specific node
                                    "/acme:interfaces/acme:interface[acme:name=3D'dummy']"
                                    but not any child leafs/containers
                                    of that interface,

                                    >>>=C2=A0 =C2=A0 =C2=A0this do=
esn't seem
                                    useful.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Further=
 comments
                                    inline below ...

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0On 08/1=
1/2017
                                    20:05, Andy Bierman wrote:

                                    >>>>=C2=A0 =C2=A0 =C2=A0Hi,=


                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0Thi=
s change has
                                    no impact on the server if
                                    /nacm/read-default is "permit"=
;.

                                    >>>>=C2=A0 =C2=A0 =C2=A0In =
that case,
                                    the extra read rules for /A and /A/B
                                    are not needed.

                                    >>>=C2=A0 =C2=A0 =C2=A0I agree=
.

                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0An =
operator
                                    worried about read access should set
                                    read-default to "deny".

                                    >>>=C2=A0 =C2=A0 =C2=A0I agree=
.=C2=A0 This is
                                    the scenario that I'm considering.<=
br>
                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0In =
that case,
                                    explicit rules to read /A and /A/B
                                    would be needed

                                    >>>>=C2=A0 =C2=A0 =C2=A0in =
the new
                                    NACM.

                                    >>>=C2=A0 =C2=A0 =C2=A0Yes, if=
 the
                                    interpretation of the rule is (i)
                                    above.

                                    >>>=C2=A0 =C2=A0 =C2=A0Otherwi=
se if the
                                    interpretation is (ii) then you only
                                    need "read /A" since that imp=
lies
                                    "read A/B" as well (as long a=
s the
                                    rules are listed in the correct
                                    order).

                                    >>>

                                    >>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0The deny
                                    rules would not be needed.

                                    >>>=C2=A0 =C2=A0 =C2=A0Only if=
 the
                                    interpretation of the rule is (i)
                                    above.=C2=A0 In which case the=C2=A0
                                    "read/write 'A/B/J' rule w=
ould not
                                    be sufficient.=C2=A0 It would be
                                    necessary to define an Xpath
                                    expressions that contains

                                    >>>=C2=A0 =C2=A0 =C2=A0all chi=
ldren nodes
                                    as well.=C2=A0 Perhaps 'A/B/J//*=
9;?

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0If the
                                    interpretation of the rule is (ii)
                                    then you would also need all the
                                    explicit deny statements as well,
                                    otherwise they would be allowed by
                                    the "read /A" rule above.

                                    >>>

                                    >>>=C2=A0 =C2=A0 =C2=A0Thanks,=


                                    >>>=C2=A0 =C2=A0 =C2=A0Rob

                                    >>>

                                    >>>

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0And=
y

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0On =
Wed, Nov 8,
                                    2017 at 8:33 AM, Robert Wilton <rwilton@cisco.com
                                    <mailto:rwilton@cisco.com>>
                                    wrote:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Hi,

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0I'm not
                                    sure about this change.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0I'm not
                                    that familiar with NACM, but if you
                                    want to give a particular set of
                                    users read/write access to a
                                    subtree, but not allow them to have
                                    any other access to the
                                    configuration in the

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0running
                                    datastore then with the existing
                                    RFC, that could be expressed with a
                                    single rule (example in 6536bis,
                                    appendix B.4)

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0With this
                                    new change, I think that you may
                                    need to configure many more rules to
                                    achieve the same thing.=C2=A0 I think
                                    that you would need to give read
                                    access to the top node in the
                                    desired

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0path, and
                                    then separate explicit "deny"=
 rules
                                    for every sibling child node walking
                                    from the top of the tree down to the
                                    data node that read/write access is
                                    actually being given to.=C2=A0 The

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0example
                                    below may explain my understanding
                                    better:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0E.g. For a
                                    tree of data nodes, rooted at A, if
                                    we wanted to give read/write access
                                    only to "J" subtree, and no a=
ccess
                                    for the rest of the tree then:

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 =C2=A0 =C2=A0 A

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 =C2=A0 =C2=A0 |

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0--------------------

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0
                                    =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=
=A0 =C2=A0 =C2=A0|

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=C2=A0
                                    =C2=A0 =C2=A0 C=C2=A0 =C2=A0 =C2=A0D=C2=
=A0 =C2=A0 =C2=A0E

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    -----------

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0
                                    |=C2=A0 |

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 F=C2=A0 =C2=A0G=C2=A0
                                    H=C2=A0 J

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                    =C2=A0 |

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

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0In the old
                                    model, I think that the ACL rules
                                    would be 1 rules long (assuming
                                    default deny all):

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    "read/write 'A/B/J'

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0In the new
                                    model, I think that the equivalent
                                    ACL rules would need to be 8 rules
                                    long (assuming default deny all):

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                    "read/write 'A/B/J'

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "read A"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny C"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny D"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny E"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny F"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny G"

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "deny H"

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Note, I am
                                    assuming that a "path" rule m=
atches
                                    for the given path and all
                                    descendant nodes.=C2=A0 The draft doesn=
't
                                    seem to be particularly clear on
                                    this point (it states that the rule
                                    applies

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0when the
                                    path matches, but this would seem to
                                    be counter intuitive), and perhaps
                                    it could be clarified.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0If this
                                    change is allowed, then the example
                                    in appendix B.4 looks like it would
                                    need to be fixed, since the
                                    "limited-acl" probably wouldn=
't give
                                    any access at all, unless default
                                    read

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0access had
                                    been given.

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0But,
                                    possibly I'm misunderstanding how
                                    this all works!=C2=A0 If so, apologies
                                    for the noise :-)

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Thanks,

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0Rob

                                    >>>>

                                    >>>>

                                    >>>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0On
                                    02/11/2017 14:18, Benoit Claise
                                    wrote:

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Dear
                                    all,

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Here is
                                    a major change in
                                    draft-ietf-netconf-rfc6536bis,
                                    suggested by the Security AD Eric
                                    Rescola part of the IESG review,
                                    which I would like to validate with
                                    the WG. See

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0https://t=
ools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.txt=

                                    <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf=
-rfc6536bis-08.txt>

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0<dfpcfioondggippe.png>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0The
                                    NETCONF WG was cc'ed for the entire
                                    discussion.

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0What do
                                    you think? I will draw the
                                    conclusions by Friday Nov 10th.

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Note:
                                    If the WG is fine, the next step is
                                    to approve this document.

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0Regards, Benoit

                                    >>>>>

                                    >>>>>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                    =C2=A0_______________________________________________

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Netconf
                                    mailing list

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Netc=
onf@ietf.org
                                    <mailto:Netconf@ietf.org>

                                    >>>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list=
info/netconf
                                    <https://www.iet=
f.org/mailman/listinfo/netconf>

                                    >>>>

                                    >>>>

                                    >>>

                                    >>>

                                    >>>
                                    __________________________________=
_____________

                                    >>> Netconf mailing list

                                    >>> Netconf@ietf.org
                                    <mailto:Netconf@ietf.org>

                                    >>> https:=
//www.ietf.org/mailman/listinfo/netconf

                                    >>

                                    >> Mahesh Jethanandani

                                    >> mjethanandani@gmail.com
                                    <mailto:mjethanandani@gmail.com>

                                    >

                                    >

                                    >

                                    > _______________________________________________

                                    > Netconf mailing list

                                    > Netconf@ietf.org

                                    > https://www.ie=
tf.org/mailman/listinfo/netconf

                                    >

                                    

                                  

                                

                                

                              

                            

                          

                          

                        

                      

                    

                    

                  

                

              

              

            

          

        

        

      

    

    

  






--089e082f6ee812bd78055dbef0bb--


From nobody Sat Nov 11 18:39:27 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382B0128B90 for ; Sat, 11 Nov 2017 18:39:25 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp2XZW6Ot3ZK for ; Sat, 11 Nov 2017 18:39:21 -0800 (PST)
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 1D375124BFA for ; Sat, 11 Nov 2017 18:39:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 965C41406622; Sun, 12 Nov 2017 03:39:18 +0100 (CET)
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 Xc-qDs6Zk6Js; Sun, 12 Nov 2017 03:39:18 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6D34F1406623; Sun, 12 Nov 2017 03:39:18 +0100 (CET)
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 fmfkPeDz57zq; Sun, 12 Nov 2017 03:39:18 +0100 (CET)
Received: from [172.16.143.223] (unknown [101.100.166.3]) by mail.transpacket.com (Postfix) with ESMTPSA id 3136B1403C8A; Sun, 12 Nov 2017 03:39:16 +0100 (CET)
To: Andy Bierman , Netconf 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com> 
From: Vladimir Vassilev 
Message-ID: 
Date: Sun, 12 Nov 2017 03:39:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E14CCADD1AE52F2F62878B11"
Content-Language: nb
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 02:39:25 -0000

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



On 11/11/2017 08:07 PM, Andy Bierman wrote:
>
>
> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>     The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06)
>     mandates two constraints that must apply:
>
>     (1) All conventional datastores must have exactly the same
>     schema.=C2=A0 Hence differences in deviations or features are allow=
ed
>     between these datastores. (sec 5.1, first paragraph)
>
>     (2) The schema for operational must be a superset of all
>     configuration datatstores, but that data nodes may be omitted (sec
>     5.3, third paragraph).
>
>
>     This implies that only the following differences between
>     datastores are allowed:
>     =C2=A0(i) a feature can be disabled in conventional (and/or dynamic
>     configuration datastores), but enabled in operational (e.g. for
>     configurable router-id).
>
>     =C2=A0(ii) deviations apply in all datastores, except that
>     =C2=A0 a) a deviation can remove nodes in the conventional datastor=
es
>     (if they were not configurable, like the feature example)
>     =C2=A0 b) a deviation can remove nodes in a dynamic datastore (e.g.
>     like I2RS)
>     =C2=A0 c) a deviation can remove nodes from operational only if a
>     server is unable to accurately report them.
>
>     (iii) modules exist in all datastores, except:
>     =C2=A0 a) a module can be omitted from conventional datastores (e.g=
. if
>     the module is not configurable)
>     =C2=A0 b) a module can be omitted from a dynamic datastore (e.g. li=
ke I2RS)
>     =C2=A0 c) a module can be omitted from operational only if a server=
 is
>     unable to accurately report the data nodes within the module.
>
>
>
> I am not convinced that moving to a datastore-centric conformance=20
> model instead of server-centric
> is a good idea.
+1
IMO yang-library:1.1 can and should be optional. As a first step NMDA=20
modules and the minimal protocol support  etc. can be=20
implemented without yang-library 1.0 to 1.1 transition (read=20
server-centric to datastore-centric conformance model transition).=20
draft-ietf-netconf-nmda-netconf-01.txt requires migration to=20
yang-library:1.1. I do not see good argument to support this limitation=20
and there are usecases that can benefit from NMDA with uniform datastore=20
model design.
> =C2=A0I get it that it is supposed to allow the server to accurately=20
> reflect its implementation,
> but it actually says that servers MAY implement whatever partial=20
> subset of a module they want,
> and a client MUST deal with the mess.
>
> IMO, YANG says that features and deviations are server-wide, not=20
> per-datastore.
> This new complexity is non-trivial to implement, so it may not be=20
> widely supported.
>
> The WG seems confused about the difference between a conformance model=20
> and capabilities reporting.
> (ii)(c) and (iii)(c) is about reporting, not conformance.=C2=A0 There i=
s=20
> still no way to express
> trivial use-cases in the conformance model such as "this module is=20
> intended for the I2RS ephemeral datastore only"
>
>
>     Changing the type of a node between datastores, or changing its
>     properties is not allowed.=C2=A0 The only difference allowed betwee=
n
>     data nodes in different datastores is the nodes existence.
>
>     These rules seem more restrictive that what a server using split
>     config state trees (IETF style, or OpenConfig style) can achieve
>     using deviations today.
>
>
>
> Lots of rules to enforce actually makes the code harder, not easier.
>
>     Thanks,
>     Rob
>
>
>
> Andy
>
>
>
>     On 09/11/2017 19:33, Andy Bierman wrote:
>>     Hi,
>>
>>     The new structure still has the same problems for the client as
>>     before.
>>     It is a major change in the architecture to have different schema
>>     trees per datastore instead of per-server.
>>     The server is allowed to have different features and deviations
>>     for the same objects.
>>     The client is completely on its own trying to compare
>>      to anything
>>     if the schema trees are different
>>
>>     =C2=A0 container foo {
>>     =C2=A0 =C2=A0 leaf bar {
>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;
>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>>     =C2=A0 =C2=A0 }
>>     =C2=A0 =C2=A0 leaf baz {
>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X";
>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>>     =C2=A0 =C2=A0 }
>>     =C2=A0}
>>
>>     How does the client compare  to  if the
>>     features do not match?
>>     If the server deviates the leaf (e.g. change type string to
>>     int32) how does the client
>>     compare the values?
>>
>>     This new complexity would be mandatory for the client to support
>>     in some proprietary
>>     manner since the NMDA standard ignores these problems.
>>
>>     NMDA was supposed to be simpler because the client could compare
>>     intended
>>     and applied values using the same object path. openconfig
>>     required a data
>>     model change and a trivial name-mapping. In reality, NMDA
>>     is far more disruptive to existing implementations.
>>
>>
>>     Andy
>>
>>
>>
>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton >     > wrote:
>>
>>         Hi,
>>
>>         Given some of the feedback related to the complexity of the
>>         YANG library bis structure, we have come up with two other
>>         possible structures for the YANG library data:
>>
>>         (1) A simplified structure to make YANG library meet the NMDA
>>         requirements, but that is closer to the existing YANG library
>>         structure, and arguably simpler.
>>         (2) An enhanced version of the structure (1) above, that is
>>         also extended to allow the structure to be reused for
>>         schema-mount via an augmentation.
>>
>>         For reference, at the end of this email, I have also included
>>         the tree diagram of the existing YANG library, and the
>>         current YANG library bis draft
>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>
>>         Considering the two new YANG library structures:
>>
>>         ------------------------
>>
>>         *(1) A simplified structure to make YANG library meet the
>>         NMDA requirements, but that is closer to the existing YANG
>>         library structure.*
>>
>>         The main changes are:
>>         (i) Split "implemented modules" and "import-only-modules"
>>         into two separate lists, making the most important list (i.e.
>>         implemented modules) keyed by module name only and hence
>>         easier to reference.
>>         (ii) Assume modules are implemented in all datastores by
>>         default (with a "not-implemented-in" leaflist of datastores
>>         that a module is not implemented in).
>>         (iii) Assume that features are implemented in all datastores
>>         by default (with a "not-implemented-in" leaflist of
>>         datastores that a feature is not implemented in).
>>         (iv) Deleted module-sets.
>>         (v) Datastores are now just a list of supported datastores
>>         (that could potentially be extended with further per
>>         datastore properties in future).
>>
>>         Manually generated tree output for proposed YANG library:
>>
>>         module: ietf-yang-library
>>         =C2=A0+--ro yang-library
>>         =C2=A0=C2=A0=C2=A0 +--ro modules
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identi=
fier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? revision-id=
entifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema? inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yan=
g-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? yan=
g:yang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema? inet:=
uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/data=
store/name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yan=
g-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implement=
ed-in*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/data=
store/name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name rev=
ision]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:y=
ang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 inet:u=
ri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* =
[name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro name yang:yang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro revision yang:revision-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro schema? inet:uri
>>         =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future pe=
r datastore
>>         properties.
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name identityref
>>         =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 string
>>
>>         ------------------------------
>>
>>         *(2) An enhanced version of the structure (1) above, that is
>>         extended to allow the structure to be reused for schema-mount
>>         via an augmentation.*
>>
>>         This is similar to the structure above, except that the "the
>>         set of modules" is contained in a list of named schema (e.g.
>>         similar to the schema mount draft), allowing this structure
>>         to be re-used for schema mount.
>>
>>         Schema mount would be expected to augment yang-library to add
>>         in the additional schema mount information.=C2=A0 In the tree
>>         diagram, I have shown the schema-mount mount-point
>>         augmentation, but not including namespaces yet.
>>
>>         Every server would be required to provide at least one schema
>>         in the schema list, and the primary schema for the device
>>         would always be given the name "primary".
>>
>>         module: ietf-yang-library
>>         =C2=A0+--ro yang-library
>>         =C2=A0=C2=A0=C2=A0 +--ro schema* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name string
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum string
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identi=
fier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:revisi=
on-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema? inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yan=
g-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? yan=
g:yang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema? inet:=
uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/data=
store/name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yan=
g-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implement=
ed-in*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/data=
store/name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-point=
* [label]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro lab=
el=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro con=
fig?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (sc=
hema-ref)
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--:(inline)
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 | +--:(use-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=C2=A0=C2=A0 +--ro use-schema* [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=C2=A0 +--ro 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=C2=A0 | -> /yang-library/schema/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=C2=A0 +--ro parent-reference* yang:x=
path1.0
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name rev=
ision]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:y=
ang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 inet:u=
ri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* =
[name]
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro name yang:yang-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro revision yang:revision-identifier
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro schema? inet:uri
>>         =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future pe=
r datastore
>>         properties.
>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name identityref
>>         =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 string
>>
>>         Please can you provide comments on these structures, in
>>         particular:
>>
>>         Is this version better (i.e. simpler) that the version
>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>
>>         Should we try and make the structure extensible for
>>         schema-mount via augmentation (i.e. version (2)), or is it
>>         better that schema-mount has its own separate subtree?
>>
>>         For reference only I have included the existing YANG library
>>         and YANG library bis draft tree diagrams.
>>
>>         Thanks,
>>         Rob
>>
>>
>>         -----------------------------
>>
>>         *** FOR REFERENCE ONLY ***
>>
>>         (3)=C2=A0 The current YANG library structure in YANG library b=
is
>>         (draft-ietf-netconf-rfc7895bis-02)
>>
>>             module: ietf-yang-library
>>                 +--ro yang-library
>>                    +--ro modules
>>                    |  +--ro module* [id]
>>                    |     +--ro id                  string
>>                    |     +--ro name                yang:yang-identifie=
r
>>                    |     +--ro revision?           revision-identifier
>>                    |     +--ro schema?             inet:uri
>>                    |     +--ro namespace           inet:uri
>>                    |     +--ro feature*            yang:yang-identifie=
r
>>                    |     +--ro deviation* [module]
>>                    |     |  +--ro module    -> ../../id
>>                    |     +--ro conformance-type    enumeration
>>                    |     +--ro submodule* [name]
>>                    |        +--ro name        yang:yang-identifier
>>                    |        +--ro revision?   revision-identifier
>>                    |        +--ro schema?     inet:uri
>>                    +--ro module-sets
>>                    |  +--ro module-set* [id]
>>                    |     +--ro id        string
>>                    |     +--ro module*   -> ../../../modules/module/id
>>                    +--ro datastores
>>                    |  +--ro datastore* [name]
>>                    |     +--ro name          identityref
>>                    |     +--ro module-set
>>                    |             -> ../../../module-sets/module-set/id
>>                    +--ro checksum       string
>>
>>         -----------------------------
>>
>>         *** FOR REFERENCE ONLY ***
>>
>>         (4)=C2=A0 The current YANG library structure (RFC 7895)
>>
>>                +--ro modules-state
>>                   +--ro module-set-id    string
>>                   +--ro module* [name revision]
>>                      +--ro name                yang:yang-identifier
>>                      +--ro revision            union
>>                      +--ro schema?             inet:uri
>>                      +--ro namespace           inet:uri
>>                      +--ro feature*            yang:yang-identifier
>>                      +--ro deviation* [name revision]
>>                      |  +--ro name        yang:yang-identifier
>>                      |  +--ro revision    union
>>                      +--ro conformance-type    enumeration
>>                      +--ro submodule* [name revision]
>>                         +--ro name        yang:yang-identifier
>>                         +--ro revision    union
>>                         +--ro schema?     inet:uri
>>
>>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


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


  
    
  
  
    


    

    

    
On 11/11/2017 08:07 PM, Andy Bierman
      wrote:

    

    

      


        


          
On Fri, Nov 10, 2017 at 3:06 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi Andy,

                
The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06)
                  mandates two constraints that must apply:

                
(1) All conventional datastores must have exactly the
                  same schema.=C2=A0 Hence differences in deviations or
                  features are allowed between these datastores. (sec
                  5.1, first paragraph)

                

                
(2) The schema for operational must be a superset of
                  all configuration datatstores, but that data nodes may
                  be omitted (sec 5.3, third paragraph).

                


                

                
This implies that only the following differences
                  between datastores are allowed:

                  =C2=A0(i) a feature can be disabled in conventional (an=
d/or
                  dynamic configuration datastores), but enabled in
                  operational (e.g. for configurable router-id).=C2=A0
              

            

            

              

                
=C2=A0(ii) deviations apply in all datastores, except =
that

                  =C2=A0 a) a deviation can remove nodes in the conventio=
nal
                  datastores (if they were not configurable, like the
                  feature example)

                  =C2=A0 b) a deviation can remove nodes in a dynamic
                  datastore (e.g. like I2RS)

                  =C2=A0 c) a deviation can remove nodes from operational
                  only if a server is unable to accurately report them.
                

                
(iii) modules exist in all datastores, except:

                  =C2=A0 a) a module can be omitted from conventional
                  datastores (e.g. if the module is not configurable)

                  =C2=A0 b) a module can be omitted from a dynamic datast=
ore
                  (e.g. like I2RS)

                  =C2=A0 c) a module can be omitted from operational only=
 if
                  a server is unable to accurately report the data nodes
                  within the module.

                


                

              

            

            


            

            
I am not convinced that moving to a datastore-centric
              conformance model instead of server-centric

            
is a good idea. 

          

        

      

    

    +1

    IMO yang-library:1.1 can and should be optional. As a first step
    NMDA modules and the minimal protocol support <get-data> etc.
    can be implemented without yang-library 1.0 to 1.1 transition (read
    server-centric to datastore-centric conformance model transition).
    draft-ietf-netconf-nmda-netconf-01.txt requires migration to
    yang-library:1.1. I do not see good argument to support this
    limitation and there are usecases that can benefit from NMDA with
    uniform datastore model design.

    

      

        

          

            
=C2=A0I get it that it is supposed to allow the server t=
o
              accurately reflect its implementation,

            
but it actually says that servers MAY implement
              whatever partial subset of a module they want,

            
and a client MUST deal with the mess.=C2=A0

            


            

            
IMO, YANG says that features and deviations are
              server-wide, not per-datastore.

            
This new complexity is non-trivial to implement, so it
              may not be widely supported.

            


            

            
The WG seems confused about the difference between a
              conformance model and capabilities reporting.

            
(ii)(c) and (iii)(c) is about reporting, not
              conformance.=C2=A0 There is still no way to express

            
trivial use-cases in the conformance model such as
              "this module is intended for the I2RS ephemeral datastore
              only"

            


            

            


            

            

              

                
 

                Changing the type of a node between datastores, or
                changing its properties is not allowed.=C2=A0 The only
                difference allowed between data nodes in different
                datastores is the nodes existence.

                =C2=A0

                These rules seem more restrictive that what a server
                using split config state trees (IETF style, or
                OpenConfig style) can achieve using deviations today.

                

              

            

            


            

            


            

            
Lots of rules to enforce actually makes the code
              harder, not easier.

            
=C2=A0

            

              
 Thanks,

                Rob

                

              

            

            


            

            


            

            
Andy

            
=C2=A0

            

              
 

                

                
On
                  09/11/2017 19:33, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
The new structure still has the same problems
                      for the client as before.

                    
It is a major change in the architecture to
                      have different schema trees per datastore instead
                      of per-server.

                    
The server is allowed to have different
                      features and deviations for the same objects.

                    
The client is completely on its own trying to
                      compare <operational> to anything

                    
if the schema trees are different

                    


                    

                    
=C2=A0 container foo {

                    
=C2=A0 =C2=A0 leaf bar {

                    
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;

                    
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

                    
=C2=A0 =C2=A0 }

                    
=C2=A0 =C2=A0 leaf baz {
                      
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X";=


                      
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

                      
=C2=A0 =C2=A0 }

                      
=C2=A0}

                      


                      

                      
How does the client compare <running>
                        to <operational> if the features do not
                        match?

                      
If the server deviates the leaf (e.g. change
                        type string to int32) how does the client

                      
compare the values?

                      


                      

                      
This new complexity would be mandatory for
                        the client to support in some proprietary

                      
manner since the NMDA standard ignores these
                        problems.

                      


                      

                      
NMDA was supposed to be
                        simpler because the client could compare
                        intended

                      
and applied values using
                        the same object path. openconfig required a data<=
/div>
                      
model change and a
                        trivial name-mapping. In reality, NMDA

                      
is far more disruptive t=
o
                        existing implementations.

                      


                      

                      


                      

                      
Andy

                      


                      

                      


                      

                      


                        
On Thu, Nov 9, 2017 at
                          8:51 AM, Robert Wilton <=
rwilton@cisco.com>
                          wrote:

                          

                            

                              
Hi,

                              
Given some of the feedback related to
                                the complexity of the YANG library bis
                                structure, we have come up with two
                                other possible structures for the YANG
                                library data:

                              
(1) A simplified structure to make YANG
                                library meet the NMDA requirements, but
                                that is closer to the existing YANG
                                library structure, and arguably simpler.<=
br>
                                (2) An enhanced version of the structure
                                (1) above, that is also extended to
                                allow the structure to be reused for
                                schema-mount via an augmentation.

                              
For reference, at the end of this
                                email, I have also included the tree
                                diagram of the existing YANG library,
                                and the current YANG library bis draft
                                (draft-ietf-netconf-rfc7895bis-02)
                                version.

                              

                              
Considering the two new YANG library
                                structures:

                              

                              
------------------------

                              

                              
(1) A simplified structure to make
                                  YANG library meet the NMDA
                                  requirements, but that is closer to
                                  the existing YANG library structure.

                              
The main changes are:

                                (i) Split "implemented modules" and
                                "import-only-modules" into two separate
                                lists, making the most important list
                                (i.e. implemented modules) keyed by
                                module name only and hence easier to
                                reference.

                                (ii) Assume modules are implemented in
                                all datastores by default (with a
                                "not-implemented-in" leaflist of
                                datastores that a module is not
                                implemented in).

                                (iii) Assume that features are
                                implemented in all datastores by default
                                (with a "not-implemented-in" leaflist of
                                datastores that a feature is not
                                implemented in).

                                (iv) Deleted module-sets.

                                (v) Datastores are now just a list of
                                supported datastores (that could
                                potentially be extended with further per
                                datastore properties in future).

                              

                              
Manually generated tree output for
                                proposed YANG library:

                              
module: ietf-yang-library
                                =C2=A0+--ro yang-library

                                =C2=A0=C2=A0=C2=A0 +--ro modules=


                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro=
 module* [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  revision-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro submodule*
                                  [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro revision?=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro
                                  not-implemented-in*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0=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-library/datastore/name
                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro feature* [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro
                                  not-implemented-in*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0=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-library/datastore/name
                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro deviation*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 ->
                                  ../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 |=C2=A0 |

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro
                                  import-only-module* [name revision]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  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 inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro submodule*
                                  [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                                  yang:revision-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 +--ro datasto=
re* [name] //
                                  Allows future per datastore
                                  properties.

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro=
 name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  identityref

                                =C2=A0=C2=A0=C2=A0 +--ro checksu=
m=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

                              

                              
------------------------------

                              
(2) An enhanced version of the
                                  structure (1) above, that is extended
                                  to allow the structure to be reused
                                  for schema-mount via an augmentation.

                              
This is similar to the structure above,
                                except that the "the set of modules" is
                                contained in a list of named schema
                                (e.g. similar to the schema mount
                                draft), allowing this structure to be
                                re-used for schema mount.

                              
Schema mount would be expected to
                                augment yang-library to add in the
                                additional schema mount information.=C2=A0=
 In
                                the tree diagram, I have shown the
                                schema-mount mount-point augmentation,
                                but not including namespaces yet.

                              
Every server would be required to
                                provide at least one schema in the
                                schema list, and the primary schema for
                                the device would always be given the
                                name "primary".

                              
module: ietf-yang-library
                                =C2=A0+--ro yang-library

                                =C2=A0=C2=A0=C2=A0 +--ro schema*=
 [name]

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

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro=
 checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  string

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro=
 module* [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:revision-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro submodule*
                                  [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro revision?=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro
                                  not-implemented-in*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0=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-library/datastore/name
                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro feature* [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0 +--ro
                                  not-implemented-in*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0=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-library/datastore/name
                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +--ro deviation*

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 ->
                                  ../name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
 +-
                                  schema-mount:mount-point* [label]<=
tt>

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro
                                  label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro
                                  config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 boolean

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(inline)

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro
                                  inline?=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=C2=A0
                                  +--:(use-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=C2=A0=C2=A0 +--ro
                                  use-schema* [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=C2=A0 =
+--ro
                                  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=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  -> /yang-library/schema/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=C2=A0 =
+--ro
                                  parent-reference*=C2=A0=C2=A0
                                  yang:xpath1.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 |

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro
                                  import-only-module* [name revision]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  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 inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro
                                  namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro submodule*
                                  [name]

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                  yang:yang-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                                  yang:revision-identifier

                                =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0
                                  inet:uri

                                =C2=A0=C2=A0=C2=A0 +--ro datasto=
re* [name] //
                                  Allows future per datastore
                                  properties.

                                =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro=
 name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                  identityref

                                =C2=A0=C2=A0=C2=A0 +--ro checksu=
m=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

                              
Please can you provide comments on
                                these structures, in particular:

                              
Is this version better (i.e. simpler)
                                that the version currently in
                                draft-ietf-netconf-rfc7895bis-02
                                (below)?

                              

                              
Should we try and make the structure
                                extensible for schema-mount via
                                augmentation (i.e. version (2)), or is
                                it better that schema-mount has its own
                                separate subtree?

                              
For reference only I have included the
                                existing YANG library and YANG library
                                bis draft tree diagrams.

                              

                              
Thanks,

                                Rob

                              

                              


                              

                              
-----------------------------

                              
*** FOR REFERENCE ONLY ***

                              

                              
(3)=C2=A0 The current YANG library struc=
ture
                                in YANG library bis
                                (draft-ietf-netconf-rfc7895bis-02)
                              

                              
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                              
-----------------------------

                              
*** FOR REFERENCE ONLY ***

                              

                              
(4)=C2=A0 The current YANG library struc=
ture
                                (RFC 7895)

                              
=
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                              
 

                            

                          

                        

                        

                      

                    

                  

                

                

              

            

          

          

        

      

      

      

      

      
_______________________________________________
Netconf mailing list
Ne=
tconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


    

    

  


--------------E14CCADD1AE52F2F62878B11--


From nobody Mon Nov 13 06:59:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F3129AD2 for ; Mon, 13 Nov 2017 06:59:07 -0800 (PST)
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 beDRRijGYP1h for ; Mon, 13 Nov 2017 06:59:05 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A67F128CD5 for ; Mon, 13 Nov 2017 06:59:05 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 1ED941AE0311; Mon, 13 Nov 2017 15:59:04 +0100 (CET)
Date: Mon, 13 Nov 2017 15:57:41 +0100 (CET)
Message-Id: <20171113.155741.613591566578760847.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: mjethanandani@gmail.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@juniper.net>
References:  <20171102.145546.466862355235662064.mbj@tail-f.com> <9430CAD9-E45D-4AC1-BC0C-C3353AFA5085@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: [Netconf] WGLC on zerotouch draft
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:59:08 -0000

Hi,

Kent Watsen  wrote:
> 
> Hi Martin,
> 
> > Hi,
> >
> > I have reviewed version -19, and checked that my previous comments are
> > addressed.  Here are my comments on this version:
> 
> Thanks for the follow-up.
> 
> 
> > o  Section 2.2
> >
> >  Tree diagram is out of date.
> 
> Fixed.
> 
> 
> > o  Section 5.1, item 1
> >
> >  Add reference to the new module ietf-zerotouch-device, maybe tweak
> >  the text?
> 
> I put the reference to the module up a level (Section 5) as the module
> applies to more than just item 1.  Regarding tweaking the text, do you
> have a suggestion?

The text has guidelines for how a vendor should define a
"enable zerotouch" variable.  Maybe replace the text with a reference
to the standard module instead.

> > o  Section 6.2
> >
> >  The example has:
> >
> >        "ietf-device:zerotouch" : {
> >           "enabled" : false
> >         }
> >
> >  This should be:
> >
> >         "ietf-zerotouch-device:zerotouch" : {
> >           "enabled" : false
> >         }
> 
> Fixed.  Tool-support for validating yang-data would be helpful.
> 
> 
> 
> > o  ietf-zerotouch-bootstrap-server.yang
> >
> >  In the description for "script", you mention 'script-warning' and
> >  'script-error'.  But they are called 'pre-script-warning',
> >  'post-script-warning', etc.
> >
> >  [I made this comment earlier, to which you replied "Will fix", so I
> >  assume you simply forgot this one.]
> 
> okay, really fixed this time.
> 
> 
> > o  ietf-zerotouch-bootstrap-server.yang
> >
> >  The description of the "script" typedef says:
> >
> >
> >       No attempt is made to standardize the contents, running context,
> >       or programming language of the script.
> >       [...]
> >
> >       The script returns exit status code '0' on success and non-zero
> >       on error, with accompanying stderr/stdout for logging purposes.
> >
> >     I think the last quoted sentence contradicts the first - it does in
> >     fact make assumptions about the running context of the script.
> >
> >     I suggest the latter sentence is removed, and the rest of the test
> >     adjusted.  Don't talk about exit codes, but instead talk about
> >     "success" or "error" etc.
> >
> >
> >  [I made this comment earlier, to which you replied "Will do", so I
> >  assume you simply forgot this one.]
> 
> I did edit it before (see the 17 -> 18 diff, but my edit was not what
> you had suggested before.  Rather than not talk about exit codes and
> what not (which I think is important to fix), I modified the first
> sentence to clarify "other than that it can emit an exit status code
> and stderr/sdtout".

But why even talk about exit codes?  The important thing to note is
ensure that the script can either succeed or fail.  For some
background, see https://en.wikipedia.org/wiki/Exit_status.

Also, there's no reason to talk about "stdout/stderr"; just use
"output", esp. since you never refer to just "stderr" or "stdout", but
always as "stderr/stdout".

> > o  ietf-zerotouch-bootstrap-server.yang
> >
> >
> >                enum "ssh-dss" {
> >                  description
> >                    "ssh-dss";
> >
> >  Did you get a warning for a missing description ;-)
> 
> Yes, several revisions back, but I take it that you're actually dinging
> me for not have a more useful description?

Yes ;-)

> (I just made the descriptions
> a little more useful).

Good!

> > o  ietf-zerotouch-information.yang
> >
> >  I still think that when rc:yang-data is used, it needs to have a
> >  single container.
> >
> >  You can easily fix this by defining two separate structures,
> >  "redirect-information" and "onboarding-information", then define a
> >  "zerotouch-information" artifact as being one of these two
> >  structures.
> 
> Wait, I thought we had an agreement that this draft would switch to
> use the new yang-data extension being defined in NETMOD that would
> allow for this use of a 'choice' statement.  I will switch to this
> yang-data definition now, okay?

Ok!

> > o  ietf-zerotouch-device.yang
> >
> >    leaf devid-certificate
> >  Should it be called idevid-certificate?
> 
> Yes.  That said, an IDevID cert *is* a DevID cert, but that's
> not important here.

Ok.

> > o  ietf-zerotouch-device.yang
> >
> >    container bootstrap-servers {
> >        config false;
> >        ...
> >        "Default list of bootstrap servers this device is
> >         configured to reach out to when bootstrapping.";
> >
> >  I had to think hard about this one.  I *think* that the idea is that
> >  this list contains the factory-installed list of bootstrap servers
> >  defined in section 5.1, bullet 3?
> >
> > Maybe rephrase, w/o using the words "default list" and "configured".
> 
> Done.
> 
> 
> > o  ietf-zerotouch-device.yang
> >
> >    leaf bootstrap-server-ta-certificates {
> >
> >  What does "ta" stand for?
> 
> "ta" stands for "trust anchor", but I went ahead and s/ta/pinned/ to
> make it more consistent with the node the leafref points to.
> 
> 
> 
> > Editorial nit
> > -------------
> >
> > o  use "" instead of '' consistently  (except in YANG strings)
> >
> >  (you fixed some, and then added some new usages of '' :)
> 
> 
> Okay, but what "YANG strings" get the single quotes?

Any term in a double quoted string, e.g. 'message' in:

    "Indicates that the device obtained warning messages
     when it committed the initial configuration.  The
     'message' field below SHOULD indicate any warning
     messages that were generated.";



/martin


From nobody Mon Nov 13 07:27:50 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A88129454 for ; Mon, 13 Nov 2017 07:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkLIqgejKVnb for ; Mon, 13 Nov 2017 07:27:46 -0800 (PST)
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 EF62E129449 for ; Mon, 13 Nov 2017 07:27:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54204; q=dns/txt; s=iport; t=1510586866; x=1511796466; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=O/pbiM/pc7yNv2bhboqLN/ALeD8QlQqYWYtrcLLkb/k=; b=k3l24+9qImQkoUXud4jvwEdO47K6Up5mPmbEEYfhOj/bPXJXe5yz1YXk 9I5zwvwI2NkzTdVFltwsbghlOlMHBMzeJkR7Qg0oXyYvlNoHEiiL/6BBL oze0PYqevIyHrBVHA6cVvG+wWh9Skp4OHkVfQjJBqMnPd/hmgI4IzZprT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAADIuAla/4QNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcWRuJ4N+ih+PKoF9llAQgX4DChgBCoRJTwKEWz8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHwEBAQMBARgJBEcbCQISBiABBgMCAicfAw4GAQwGAgEBih4QjV+da?= =?us-ascii?q?IFtOiaKXwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVgWkpgwGEZAESAQl?= =?us-ascii?q?Mgl+CYwWKLYc7gRKGGokWlQSCFYYIg2AkhyGOModygTkfOEJBbzQhCB0VSYJkh?= =?us-ascii?q?Gw0NoYvgjUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,389,1505779200";  d="scan'208,217";a="318190148"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 15:27:43 +0000
Received: from [10.24.11.108] ([10.24.11.108]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vADFRevX011160; Mon, 13 Nov 2017 15:27:41 GMT
To: Vladimir Vassilev , Andy Bierman , Netconf 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>  
From: Robert Wilton 
Message-ID: <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>
Date: Mon, 13 Nov 2017 23:27:39 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CC3001FB975F6D0C4B870D13"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:27:49 -0000

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

Hi Vladimir,


On 12/11/2017 10:39, Vladimir Vassilev wrote:
>
>
>
> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>
>>
>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton > > wrote:
>>
>>     Hi Andy,
>>
>>     The NMDA datastore draft
>>     (draft-ietf-netmod-revised-datastores-06) mandates two
>>     constraints that must apply:
>>
>>     (1) All conventional datastores must have exactly the same
>>     schema.  Hence differences in deviations or features are allowed
>>     between these datastores. (sec 5.1, first paragraph)
>>
>>     (2) The schema for operational must be a superset of all
>>     configuration datatstores, but that data nodes may be omitted
>>     (sec 5.3, third paragraph).
>>
>>
>>     This implies that only the following differences between
>>     datastores are allowed:
>>      (i) a feature can be disabled in conventional (and/or dynamic
>>     configuration datastores), but enabled in operational (e.g. for
>>     configurable router-id).
>>
>>      (ii) deviations apply in all datastores, except that
>>       a) a deviation can remove nodes in the conventional datastores
>>     (if they were not configurable, like the feature example)
>>       b) a deviation can remove nodes in a dynamic datastore (e.g.
>>     like I2RS)
>>       c) a deviation can remove nodes from operational only if a
>>     server is unable to accurately report them.
>>
>>     (iii) modules exist in all datastores, except:
>>       a) a module can be omitted from conventional datastores (e.g.
>>     if the module is not configurable)
>>       b) a module can be omitted from a dynamic datastore (e.g. like
>>     I2RS)
>>       c) a module can be omitted from operational only if a server is
>>     unable to accurately report the data nodes within the module.
>>
>>
>>
>> I am not convinced that moving to a datastore-centric conformance 
>> model instead of server-centric
>> is a good idea.
> +1
> IMO yang-library:1.1 can and should be optional. As a first step NMDA 
> modules and the minimal protocol support  etc. can be 
> implemented without yang-library 1.0 to 1.1 transition (read 
> server-centric to datastore-centric conformance model transition). 
> draft-ietf-netconf-nmda-netconf-01.txt requires migration to 
> yang-library:1.1. I do not see good argument to support this 
> limitation and there are usecases that can benefit from NMDA with 
> uniform datastore model design.

YANG library bis is the mechanism to indicate which datastores are 
available to the client.  E.g. a NMDA compatible client would attempt to 
read YANG library bis on the new path using the  RPC to 
determine whether NMDA is supported, and what datastores are supported.

The existing module-state path in YANG library is preserved, but marked 
as deprecated, so the intention is that it can be made backwards 
compatible to clients.

Thanks,
Rob

>>  I get it that it is supposed to allow the server to accurately 
>> reflect its implementation,
>> but it actually says that servers MAY implement whatever partial 
>> subset of a module they want,
>> and a client MUST deal with the mess.
>>
>> IMO, YANG says that features and deviations are server-wide, not 
>> per-datastore.
>> This new complexity is non-trivial to implement, so it may not be 
>> widely supported.
>>
>> The WG seems confused about the difference between a conformance 
>> model and capabilities reporting.
>> (ii)(c) and (iii)(c) is about reporting, not conformance.  There is 
>> still no way to express
>> trivial use-cases in the conformance model such as "this module is 
>> intended for the I2RS ephemeral datastore only"
>>
>>
>>     Changing the type of a node between datastores, or changing its
>>     properties is not allowed.  The only difference allowed between
>>     data nodes in different datastores is the nodes existence.
>>
>>     These rules seem more restrictive that what a server using split
>>     config state trees (IETF style, or OpenConfig style) can achieve
>>     using deviations today.
>>
>>
>>
>> Lots of rules to enforce actually makes the code harder, not easier.
>>
>>     Thanks,
>>     Rob
>>
>>
>>
>> Andy
>>
>>
>>
>>     On 09/11/2017 19:33, Andy Bierman wrote:
>>>     Hi,
>>>
>>>     The new structure still has the same problems for the client as
>>>     before.
>>>     It is a major change in the architecture to have different
>>>     schema trees per datastore instead of per-server.
>>>     The server is allowed to have different features and deviations
>>>     for the same objects.
>>>     The client is completely on its own trying to compare
>>>      to anything
>>>     if the schema trees are different
>>>
>>>       container foo {
>>>         leaf bar {
>>>            if-feature X;
>>>            type string;
>>>         }
>>>         leaf baz {
>>>            if-feature "not X";
>>>            type string;
>>>         }
>>>      }
>>>
>>>     How does the client compare  to  if the
>>>     features do not match?
>>>     If the server deviates the leaf (e.g. change type string to
>>>     int32) how does the client
>>>     compare the values?
>>>
>>>     This new complexity would be mandatory for the client to support
>>>     in some proprietary
>>>     manner since the NMDA standard ignores these problems.
>>>
>>>     NMDA was supposed to be simpler because the client could compare
>>>     intended
>>>     and applied values using the same object path. openconfig
>>>     required a data
>>>     model change and a trivial name-mapping. In reality, NMDA
>>>     is far more disruptive to existing implementations.
>>>
>>>
>>>     Andy
>>>
>>>
>>>
>>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton >>     > wrote:
>>>
>>>         Hi,
>>>
>>>         Given some of the feedback related to the complexity of the
>>>         YANG library bis structure, we have come up with two other
>>>         possible structures for the YANG library data:
>>>
>>>         (1) A simplified structure to make YANG library meet the
>>>         NMDA requirements, but that is closer to the existing YANG
>>>         library structure, and arguably simpler.
>>>         (2) An enhanced version of the structure (1) above, that is
>>>         also extended to allow the structure to be reused for
>>>         schema-mount via an augmentation.
>>>
>>>         For reference, at the end of this email, I have also
>>>         included the tree diagram of the existing YANG library, and
>>>         the current YANG library bis draft
>>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>>
>>>         Considering the two new YANG library structures:
>>>
>>>         ------------------------
>>>
>>>         *(1) A simplified structure to make YANG library meet the
>>>         NMDA requirements, but that is closer to the existing YANG
>>>         library structure.*
>>>
>>>         The main changes are:
>>>         (i) Split "implemented modules" and "import-only-modules"
>>>         into two separate lists, making the most important list
>>>         (i.e. implemented modules) keyed by module name only and
>>>         hence easier to reference.
>>>         (ii) Assume modules are implemented in all datastores by
>>>         default (with a "not-implemented-in" leaflist of datastores
>>>         that a module is not implemented in).
>>>         (iii) Assume that features are implemented in all datastores
>>>         by default (with a "not-implemented-in" leaflist of
>>>         datastores that a feature is not implemented in).
>>>         (iv) Deleted module-sets.
>>>         (v) Datastores are now just a list of supported datastores
>>>         (that could potentially be extended with further per
>>>         datastore properties in future).
>>>
>>>         Manually generated tree output for proposed YANG library:
>>>
>>>         module: ietf-yang-library
>>>          +--ro yang-library
>>>             +--ro modules
>>>             |  +--ro module* [name]
>>>             |  |  +--ro name           yang:yang-identifier
>>>             |  |  +--ro revision?      revision-identifier
>>>             |  |  +--ro schema?        inet:uri
>>>             |  |  +--ro namespace      inet:uri
>>>             |  |  +--ro submodule* [name]
>>>             |  |  |  +--ro name        yang:yang-identifier
>>>             |  |  |  +--ro revision?   yang:yang-identifier
>>>             |  |  |  +--ro schema?     inet:uri
>>>             |  |  +--ro not-implemented-in*
>>>             |  |  | -> /yang-library/datastore/name
>>>             |  |  +--ro feature* [name]
>>>             |  |  |  +--ro name        yang:yang-identifier
>>>             |  |  |  +--ro not-implemented-in*
>>>             |  |  | -> /yang-library/datastore/name
>>>             |  |  +--ro deviation*
>>>             |  | -> ../name
>>>             |  |
>>>             |  +--ro import-only-module* [name revision]
>>>             |     +--ro name yang:yang-identifier
>>>             |     +--ro revision            union
>>>             |     +--ro schema?             inet:uri
>>>             |     +--ro namespace           inet:uri
>>>             |     +--ro submodule* [name]
>>>             |        +--ro name        yang:yang-identifier
>>>             |        +--ro revision    yang:revision-identifier
>>>             |        +--ro schema?     inet:uri
>>>             +--ro datastore* [name] // Allows future per datastore
>>>         properties.
>>>             |  +--ro name identityref
>>>             +--ro checksum string
>>>
>>>         ------------------------------
>>>
>>>         *(2) An enhanced version of the structure (1) above, that is
>>>         extended to allow the structure to be reused for
>>>         schema-mount via an augmentation.*
>>>
>>>         This is similar to the structure above, except that the "the
>>>         set of modules" is contained in a list of named schema (e.g.
>>>         similar to the schema mount draft), allowing this structure
>>>         to be re-used for schema mount.
>>>
>>>         Schema mount would be expected to augment yang-library to
>>>         add in the additional schema mount information. In the tree
>>>         diagram, I have shown the schema-mount mount-point
>>>         augmentation, but not including namespaces yet.
>>>
>>>         Every server would be required to provide at least one
>>>         schema in the schema list, and the primary schema for the
>>>         device would always be given the name "primary".
>>>
>>>         module: ietf-yang-library
>>>          +--ro yang-library
>>>             +--ro schema* [name]
>>>             |  +--ro name string
>>>             |  +--ro checksum string
>>>             |  +--ro module* [name]
>>>             |  |  +--ro name           yang:yang-identifier
>>>             |  |  +--ro revision? yang:revision-identifier
>>>             |  |  +--ro schema?        inet:uri
>>>             |  |  +--ro namespace      inet:uri
>>>             |  |  +--ro submodule* [name]
>>>             |  |  |  +--ro name        yang:yang-identifier
>>>             |  |  |  +--ro revision?   yang:yang-identifier
>>>             |  |  |  +--ro schema?     inet:uri
>>>             |  |  +--ro not-implemented-in*
>>>             |  |  | -> /yang-library/datastore/name
>>>             |  |  +--ro feature* [name]
>>>             |  |  |  +--ro name        yang:yang-identifier
>>>             |  |  |  +--ro not-implemented-in*
>>>             |  |  | -> /yang-library/datastore/name
>>>             |  |  +--ro deviation*
>>>             |  |  | -> ../name
>>>             |  |  +- schema-mount:mount-point* [label]
>>>             |  |     +--ro label         yang:yang-identifier
>>>             |  |     +--ro config?       boolean
>>>             |  |     +--ro (schema-ref)
>>>             |  |        +--:(inline)
>>>             |  |        |  +--ro inline?       empty
>>>             |  | +--:(use-schema)
>>>             |  |           +--ro use-schema* [name]
>>>             |  |              +--ro name
>>>             |  |              | -> /yang-library/schema/name
>>>             |  |              +--ro parent-reference* yang:xpath1.0
>>>             |  |
>>>             |  +--ro import-only-module* [name revision]
>>>             |     +--ro name yang:yang-identifier
>>>             |     +--ro revision            union
>>>             |     +--ro schema?             inet:uri
>>>             |     +--ro namespace           inet:uri
>>>             |     +--ro submodule* [name]
>>>             |        +--ro name        yang:yang-identifier
>>>             |        +--ro revision    yang:revision-identifier
>>>             |        +--ro schema?     inet:uri
>>>             +--ro datastore* [name] // Allows future per datastore
>>>         properties.
>>>             |  +--ro name identityref
>>>             +--ro checksum string
>>>
>>>         Please can you provide comments on these structures, in
>>>         particular:
>>>
>>>         Is this version better (i.e. simpler) that the version
>>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>
>>>         Should we try and make the structure extensible for
>>>         schema-mount via augmentation (i.e. version (2)), or is it
>>>         better that schema-mount has its own separate subtree?
>>>
>>>         For reference only I have included the existing YANG library
>>>         and YANG library bis draft tree diagrams.
>>>
>>>         Thanks,
>>>         Rob
>>>
>>>
>>>         -----------------------------
>>>
>>>         *** FOR REFERENCE ONLY ***
>>>
>>>         (3)  The current YANG library structure in YANG library bis
>>>         (draft-ietf-netconf-rfc7895bis-02)
>>>
>>>             module: ietf-yang-library
>>>                 +--ro yang-library
>>>                    +--ro modules
>>>                    |  +--ro module* [id]
>>>                    |     +--ro id                  string
>>>                    |     +--ro name                yang:yang-identifier
>>>                    |     +--ro revision?           revision-identifier
>>>                    |     +--ro schema?             inet:uri
>>>                    |     +--ro namespace           inet:uri
>>>                    |     +--ro feature*            yang:yang-identifier
>>>                    |     +--ro deviation* [module]
>>>                    |     |  +--ro module    -> ../../id
>>>                    |     +--ro conformance-type    enumeration
>>>                    |     +--ro submodule* [name]
>>>                    |        +--ro name        yang:yang-identifier
>>>                    |        +--ro revision?   revision-identifier
>>>                    |        +--ro schema?     inet:uri
>>>                    +--ro module-sets
>>>                    |  +--ro module-set* [id]
>>>                    |     +--ro id        string
>>>                    |     +--ro module*   -> ../../../modules/module/id
>>>                    +--ro datastores
>>>                    |  +--ro datastore* [name]
>>>                    |     +--ro name          identityref
>>>                    |     +--ro module-set
>>>                    |             -> ../../../module-sets/module-set/id
>>>                    +--ro checksum       string
>>>
>>>         -----------------------------
>>>
>>>         *** FOR REFERENCE ONLY ***
>>>
>>>         (4)  The current YANG library structure (RFC 7895)
>>>
>>>                +--ro modules-state
>>>                   +--ro module-set-id    string
>>>                   +--ro module* [name revision]
>>>                      +--ro name                yang:yang-identifier
>>>                      +--ro revision            union
>>>                      +--ro schema?             inet:uri
>>>                      +--ro namespace           inet:uri
>>>                      +--ro feature*            yang:yang-identifier
>>>                      +--ro deviation* [name revision]
>>>                      |  +--ro name        yang:yang-identifier
>>>                      |  +--ro revision    union
>>>                      +--ro conformance-type    enumeration
>>>                      +--ro submodule* [name revision]
>>>                         +--ro name        yang:yang-identifier
>>>                         +--ro revision    union
>>>                         +--ro schema?     inet:uri
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


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


  
    
  
  
    
Hi Vladimir,

    

    

    
On 12/11/2017 10:39, Vladimir Vassilev
      wrote:

    

    

      
      


      

      

      
On 11/11/2017 08:07 PM, Andy Bierman
        wrote:

      

      

        


          


            
On Fri, Nov 10, 2017 at 3:06 AM,
              Robert Wilton <rwilton@cisco.com>
              wrote:

              

                

                  
Hi Andy,

                  
The NMDA datastore draft
                    (draft-ietf-netmod-revised-datastores-06)
                    mandates two constraints that must apply:

                  
(1) All conventional datastores must have exactly
                    the same schema.  Hence differences in deviations or
                    features are allowed between these datastores. (sec
                    5.1, first paragraph)

                  

                  
(2) The schema for operational must be a superset
                    of all configuration datatstores, but that data
                    nodes may be omitted (sec 5.3, third paragraph).

                  


                  

                  
This implies that only the following differences
                    between datastores are allowed:

                     (i) a feature can be disabled in conventional
                    (and/or dynamic configuration datastores), but
                    enabled in operational (e.g. for configurable
                    router-id). 

                

              

              

                

                  
 (ii) deviations apply in all datastores, except
                    that

                      a) a deviation can remove nodes in the
                    conventional datastores (if they were not
                    configurable, like the feature example)

                      b) a deviation can remove nodes in a dynamic
                    datastore (e.g. like I2RS)

                      c) a deviation can remove nodes from operational
                    only if a server is unable to accurately report
                    them.

                  

                  
(iii) modules exist in all datastores, except:

                      a) a module can be omitted from conventional
                    datastores (e.g. if the module is not configurable)

                      b) a module can be omitted from a dynamic
                    datastore (e.g. like I2RS)

                      c) a module can be omitted from operational only
                    if a server is unable to accurately report the data
                    nodes within the module.

                  


                  

                

              

              


              

              
I am not convinced that moving to a datastore-centric
                conformance model instead of server-centric

              
is a good idea. 

            

          

        

      

      +1

      IMO yang-library:1.1 can and should be optional. As a first step
      NMDA modules and the minimal protocol support <get-data>
      etc. can be implemented without yang-library 1.0 to 1.1 transition
      (read server-centric to datastore-centric conformance model
      transition). draft-ietf-netconf-nmda-netconf-01.txt requires
      migration to yang-library:1.1. I do not see good argument to
      support this limitation and there are usecases that can benefit
      from NMDA with uniform datastore model design.

    

    

    YANG library bis is the mechanism to indicate which datastores are
    available to the client.  E.g. a NMDA compatible client would
    attempt to read YANG library bis on the new path using the
    <get-data> RPC to determine whether NMDA is supported, and
    what datastores are supported.

    

    The existing module-state path in YANG library is preserved, but
    marked as deprecated, so the intention is that it can be made
    backwards compatible to clients.

    

    Thanks,

    Rob

    

    

      

        

          

            

              
 I get it that it is supposed to allow the server to
                accurately reflect its implementation,

              
but it actually says that servers MAY implement
                whatever partial subset of a module they want,

              
and a client MUST deal with the mess. 

              


              

              
IMO, YANG says that features and deviations are
                server-wide, not per-datastore.

              
This new complexity is non-trivial to implement, so
                it may not be widely supported.

              


              

              
The WG seems confused about the difference between a
                conformance model and capabilities reporting.

              
(ii)(c) and (iii)(c) is about reporting, not
                conformance.  There is still no way to express

              
trivial use-cases in the conformance model such as
                "this module is intended for the I2RS ephemeral
                datastore only"

              


              

              


              

              

                

                  
 

                  Changing the type of a node between datastores, or
                  changing its properties is not allowed.  The only
                  difference allowed between data nodes in different
                  datastores is the nodes existence.

                   

                  These rules seem more restrictive that what a server
                  using split config state trees (IETF style, or
                  OpenConfig style) can achieve using deviations today.

                  

                

              

              


              

              


              

              
Lots of rules to enforce actually makes the code
                harder, not easier.

              
 

              

                
 Thanks,

                  Rob

                  

                

              

              


              

              


              

              
Andy

              
 

              

                
 

                  

                  
On
                    09/11/2017 19:33, Andy Bierman wrote:

                  

                  

                    
Hi,
                      


                      

                      
The new structure still has the same problems
                        for the client as before.

                      
It is a major change in the architecture to
                        have different schema trees per datastore
                        instead of per-server.

                      
The server is allowed to have different
                        features and deviations for the same objects.

                      
The client is completely on its own trying to
                        compare <operational> to anything

                      
if the schema trees are different

                      


                      

                      
  container foo {

                      
    leaf bar {

                      
       if-feature X;

                      
       type string;

                      
    }

                      
    leaf baz {
                        
       if-feature "not X";

                        
       type string;

                        
    }

                        
 }

                        


                        

                        
How does the client compare <running>
                          to <operational> if the features do not
                          match?

                        
If the server deviates the leaf (e.g.
                          change type string to int32) how does the
                          client

                        
compare the values?

                        


                        

                        
This new complexity would be mandatory for
                          the client to support in some proprietary

                        
manner since the NMDA standard ignores
                          these problems.

                        


                        

                        
NMDA was supposed to be
                          simpler because the client could compare
                          intended

                        
and applied values
                          using the same object path. openconfig
                          required a data

                        
model change and a
                          trivial name-mapping. In reality, NMDA

                        
is far more disruptive
                          to existing implementations.

                        


                        

                        


                        

                        
Andy

                        


                        

                        


                        

                        


                          
On Thu, Nov 9, 2017
                            at 8:51 AM, Robert Wilton <rwilton@cisco.com>
                            wrote:

                            

                              

                                
Hi,

                                
Given some of the feedback related to
                                  the complexity of the YANG library bis
                                  structure, we have come up with two
                                  other possible structures for the YANG
                                  library data:

                                
(1) A simplified structure to make
                                  YANG library meet the NMDA
                                  requirements, but that is closer to
                                  the existing YANG library structure,
                                  and arguably simpler.

                                  (2) An enhanced version of the
                                  structure (1) above, that is also
                                  extended to allow the structure to be
                                  reused for schema-mount via an
                                  augmentation.

                                
For reference, at the end of this
                                  email, I have also included the tree
                                  diagram of the existing YANG library,
                                  and the current YANG library bis draft
                                  (draft-ietf-netconf-rfc7895bis-02)
                                  version.

                                

                                
Considering the two new YANG library
                                  structures:

                                

                                
------------------------

                                

                                
(1) A simplified structure to make
                                    YANG library meet the NMDA
                                    requirements, but that is closer to
                                    the existing YANG library structure.

                                
The main changes are:

                                  (i) Split "implemented modules" and
                                  "import-only-modules" into two
                                  separate lists, making the most
                                  important list (i.e. implemented
                                  modules) keyed by module name only and
                                  hence easier to reference.

                                  (ii) Assume modules are implemented in
                                  all datastores by default (with a
                                  "not-implemented-in" leaflist of
                                  datastores that a module is not
                                  implemented in).

                                  (iii) Assume that features are
                                  implemented in all datastores by
                                  default (with a "not-implemented-in"
                                  leaflist of datastores that a feature
                                  is not implemented in).

                                  (iv) Deleted module-sets.

                                  (v) Datastores are now just a list of
                                  supported datastores (that could
                                  potentially be extended with further
                                  per datastore properties in future).

                                

                                
Manually generated tree output for
                                  proposed YANG library:

                                
module: ietf-yang-library

                                   +--ro yang-library

                                      +--ro modules

                                      |  +--ro module* [name]

                                      |  |  +--ro
                                    name           yang:yang-identifier

                                      |  |  +--ro
                                    revision?      revision-identifier

                                      |  |  +--ro
                                    schema?        inet:uri

                                      |  |  +--ro
                                    namespace      inet:uri

                                      |  |  +--ro submodule*
                                    [name]

                                      |  |  |  +--ro
                                    name        yang:yang-identifier

                                      |  |  |  +--ro
                                    revision?   yang:yang-identifier

                                      |  |  |  +--ro
                                    schema?     inet:uri

                                      |  |  +--ro
                                    not-implemented-in*

                                      |  |  |             
                                    -> /yang-library/datastore/name

                                      |  |  +--ro feature*
                                    [name]

                                      |  |  |  +--ro
                                    name        yang:yang-identifier

                                      |  |  |  +--ro
                                    not-implemented-in*

                                      |  |  |             
                                    -> /yang-library/datastore/name

                                      |  |  +--ro deviation*

                                      |  |                
                                    -> ../name              

                                      |  |

                                      |  +--ro
                                    import-only-module* [name revision]

                                      |     +--ro
                                    name               
                                    yang:yang-identifier

                                      |     +--ro
                                    revision            union

                                      |     +--ro
                                    schema?             inet:uri

                                      |     +--ro
                                    namespace           inet:uri

                                      |     +--ro submodule*
                                    [name]

                                      |        +--ro
                                    name        yang:yang-identifier

                                      |        +--ro
                                    revision    yang:revision-identifier

                                      |        +--ro
                                    schema?     inet:uri

                                      +--ro datastore* [name]
                                    // Allows future per datastore
                                    properties.

                                      |  +--ro name         
                                    identityref

                                      +--ro checksum      
                                    string

                                

                                
------------------------------

                                
(2) An enhanced version of the
                                    structure (1) above, that is
                                    extended to allow the structure to
                                    be reused for schema-mount via an
                                    augmentation.

                                
This is similar to the structure
                                  above, except that the "the set of
                                  modules" is contained in a list of
                                  named schema (e.g. similar to the
                                  schema mount draft), allowing this
                                  structure to be re-used for schema
                                  mount.

                                
Schema mount would be expected to
                                  augment yang-library to add in the
                                  additional schema mount information. 
                                  In the tree diagram, I have shown the
                                  schema-mount mount-point augmentation,
                                  but not including namespaces yet.

                                
Every server would be required to
                                  provide at least one schema in the
                                  schema list, and the primary schema
                                  for the device would always be given
                                  the name "primary".

                                
module: ietf-yang-library

                                   +--ro yang-library

                                      +--ro schema* [name]

                                      |  +--ro name          
                                    string

                                      |  +--ro checksum      
                                    string

                                      |  +--ro module* [name]

                                      |  |  +--ro
                                    name           yang:yang-identifier

                                      |  |  +--ro
                                    revision?     
                                    yang:revision-identifier

                                      |  |  +--ro
                                    schema?        inet:uri

                                      |  |  +--ro
                                    namespace      inet:uri

                                      |  |  +--ro submodule*
                                    [name]

                                      |  |  |  +--ro
                                    name        yang:yang-identifier

                                      |  |  |  +--ro
                                    revision?   yang:yang-identifier

                                      |  |  |  +--ro
                                    schema?     inet:uri

                                      |  |  +--ro
                                    not-implemented-in*

                                      |  |  |             
                                    -> /yang-library/datastore/name

                                      |  |  +--ro feature*
                                    [name]

                                      |  |  |  +--ro
                                    name        yang:yang-identifier

                                      |  |  |  +--ro
                                    not-implemented-in*

                                      |  |  |             
                                    -> /yang-library/datastore/name

                                      |  |  +--ro deviation*

                                      |  |  |             
                                    -> ../name       

                                      |  |  +-
                                    schema-mount:mount-point* [label]

                                      |  |     +--ro
                                    label         yang:yang-identifier

                                      |  |     +--ro
                                    config?       boolean

                                      |  |     +--ro
                                    (schema-ref)

                                      |  |        +--:(inline)

                                      |  |        |  +--ro
                                    inline?       empty

                                      |  |       
                                    +--:(use-schema)

                                      |  |           +--ro
                                    use-schema* [name]

                                      |  |              +--ro
                                    name

                                      |  |              |      
                                    -> /yang-library/schema/name

                                      |  |              +--ro
                                    parent-reference*  
                                    yang:xpath1.0          

                                      |  |

                                      |  +--ro
                                    import-only-module* [name revision]

                                      |     +--ro
                                    name               
                                    yang:yang-identifier

                                      |     +--ro
                                    revision            union

                                      |     +--ro
                                    schema?             inet:uri

                                      |     +--ro
                                    namespace           inet:uri

                                      |     +--ro submodule*
                                    [name]

                                      |        +--ro
                                    name        yang:yang-identifier

                                      |        +--ro
                                    revision    yang:revision-identifier

                                      |        +--ro
                                    schema?     inet:uri

                                      +--ro datastore* [name]
                                    // Allows future per datastore
                                    properties.

                                      |  +--ro name         
                                    identityref

                                      +--ro checksum      
                                    string

                                
Please can you provide comments on
                                  these structures, in particular:

                                
Is this version better (i.e. simpler)
                                  that the version currently in
                                  draft-ietf-netconf-rfc7895bis-02
                                  (below)?

                                

                                
Should we try and make the structure
                                  extensible for schema-mount via
                                  augmentation (i.e. version (2)), or is
                                  it better that schema-mount has its
                                  own separate subtree?

                                
For reference only I have included
                                  the existing YANG library and YANG
                                  library bis draft tree diagrams.

                                

                                
Thanks,

                                  Rob

                                

                                


                                

                                
-----------------------------

                                
*** FOR REFERENCE ONLY ***

                                

                                
(3)  The current YANG library
                                  structure in YANG library bis
                                  (draft-ietf-netconf-rfc7895bis-02)

                                

                                
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                                
-----------------------------

                                
*** FOR REFERENCE ONLY ***

                                

                                
(4)  The current YANG library
                                  structure (RFC 7895)

                                
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                                
 

                              

                            

                          

                          

                        

                      

                    

                  

                  

                

              

            

            

          

        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------CC3001FB975F6D0C4B870D13--


From nobody Mon Nov 13 07:29:37 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A7E129AC1; Mon, 13 Nov 2017 07:29:36 -0800 (PST)
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 Z6K9d_0TJTuf; Mon, 13 Nov 2017 07:29:35 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9C8129454; Mon, 13 Nov 2017 07:29:35 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 99E441AE0311; Mon, 13 Nov 2017 16:29:33 +0100 (CET)
Date: Mon, 13 Nov 2017 16:28:10 +0100 (CET)
Message-Id: <20171113.162810.1853130535954821831.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, sec-ads@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:29:37 -0000

Hi,

I just read this thread, and I agree with the changes, but see below
for a comment.


Andy Bierman  wrote:
> Hi,
> 
> Here are some proposed edits to make the data rule consistent with the
> examples.
> Note that this issue is not related to the edit in the original 1-week
> change.
> 
> 
> sec. 3.3.5:
> 
> OLD:
> 
> 
>       data node rule:  controls access for a specific data node, identified
>       by its path location within the conceptual XML document for the
>       data node.
> 
> 
> NEW:
> 
>       data node rule:  controls access for a specific data node and its
> descendants,
>       identified by its path location within the conceptual XML document
> for the
>       data node.
> 
> 
> sec 3.4.5, step 6, bullet 2:
> 
> 
> OLD:
> 
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node.
> 
> 
> NEW:
> 
> 
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node. A path is
>            considered to match if the current data node is the data node
>            specified by the path, or is a descendant data node of this
>            data node.

I propose:

             The rule does not have a "rule-type" defined or the
             "rule-type" is "data-node" and the "path" matches the
             requested data node, action node, or notification node.
             A path is considered to match if the requested node
             is the node specified by the path, or is a
             descendant node of the path.

Note:  s/current node/requested node/ which is the term used in the
first sentence.  And then s/data node/node/ since the first sentence
refer to data-, action-, and notification node.

I have checked in this fix in the repo.


/martin


From nobody Mon Nov 13 07:42:51 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1995C1242F7 for ; Mon, 13 Nov 2017 07:42:50 -0800 (PST)
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 yQpaP34ech8Z for ; Mon, 13 Nov 2017 07:42:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B51200FC for ; Mon, 13 Nov 2017 07:42:45 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 08B0F1AE0311; Mon, 13 Nov 2017 16:42:43 +0100 (CET)
Date: Mon, 13 Nov 2017 16:41:21 +0100 (CET)
Message-Id: <20171113.164121.1325281346942898287.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netconf@ietf.org, lhotka@nic.cz, kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>
References:   <9096e95e-8621-f578-2c84-e502109e0a64@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: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:42:50 -0000

Robert Wilton  wrote:
> Hi Andy,
> =

> The NMDA datastore draft (draft-ietf-netmod-revised-datastores-06)
> mandates two constraints that must apply:
> =

> (1) All conventional datastores must have exactly the same schema.=A0=

> Hence differences in deviations or features are allowed between these=

> datastores. (sec 5.1, first paragraph)
> =

> (2) The schema for operational must be a superset of all configuratio=
n
> datatstores, but that data nodes may be omitted (sec 5.3, third
> paragraph).
> =

> =

> This implies that only the following differences between datastores
> are allowed:
> =A0(i) a feature can be disabled in conventional (and/or dynamic
> configuration datastores), but enabled in operational (e.g. for
> configurable router-id).
> =

> =A0(ii) deviations apply in all datastores, except that
> =A0 a) a deviation can remove nodes in the conventional datastores (i=
f
> they were not configurable, like the feature example)
> =A0 b) a deviation can remove nodes in a dynamic datastore (e.g. like=

> I2RS)
> =A0 c) a deviation can remove nodes from operational only if a server=
 is
> unable to accurately report them.
> =

> (iii) modules exist in all datastores, except:
> =A0 a) a module can be omitted from conventional datastores (e.g. if =
the
> module is not configurable)
> =A0 b) a module can be omitted from a dynamic datastore (e.g. like I2=
RS)
> =A0 c) a module can be omitted from operational only if a server is
> unable to accurately report the data nodes within the module.
> =

> =

> Changing the type of a node between datastores, or changing its
> properties is not allowed.=A0 The only difference allowed between dat=
a
> nodes in different datastores is the nodes existence.

Maybe this should be clarified in the text.

> These rules seem more restrictive that what a server using split
> config state trees (IETF style, or OpenConfig style) can achieve usin=
g
> deviations today.

Exactly, which in fact makes it easier to do comparisions between
intended and applied.



/martin


From nobody Mon Nov 13 19:07:16 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F651242F7; Mon, 13 Nov 2017 19:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 EElNBEruBtcw; Mon, 13 Nov 2017 19:07:09 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD8B126CC7; Mon, 13 Nov 2017 19:07:08 -0800 (PST)
Received: from [IPv6:2001:67c:370:1998:7cd0:43af:2e4f:3cb] ([31.130.238.124]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MDhGw-1eQ01M1bB8-00H3Bo; Tue, 14 Nov 2017 04:07:06 +0100
From: Ian Farrer 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Tue, 14 Nov 2017 11:07:04 +0800
To: draft-ietf-netconf-zerotouch@ietf.org, netconf@ietf.org
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:OFKdFy1At5eiDQcf8v2xKVTCqFVLdOHLYN2GNmPfCA0OMYSXM9Q F2LYJqleKMw1bGEsWYMwaz4JD8GsURPqWqnP12O7r/uZZ+E/p08joedwhPlxhVmAaiFGTul lnAR+oBfbZbgbyJEvbaRgGXWH9dvTFVVvXD2ID4voWTdtfcYqwLkGEBNEyGgchVyxB91D7w gOaVHlwXxsPE+m4GKlkYw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Y1I0Q8Tzvvo=:Q1cOTRj721bBedhIl3VFjb KK8JG3ggHJQRjBRVzqVVQLbXNA59XeBWrz0enjVRhhMIJSmawhQFTgFIBZKgUzUUgCLlc6HZc j1WDiEHxpcyncB7ODX3RCE8dtt0QTxuGs/Z5KkwNyJrQk+fIRiCcsfTbr2NHM6uSYt6wJE1A5 73SoToO+j2pW25rYYpdhrUOrDop2O0yYwvQM46J6JBcY93Ez20ZE9OtVsAAB+nd/7RXbddYIW iB5OSrr/y3FvZpqa7X/LCV8Um51dmXot/jp6gK9KmwO90xhzVw9exXfqRFz+awymZJRE8/vKl /ykw3oPTKqnolQmuDDfOGZFsJtdxIg2Lfj2lOqQGwzu58mcdwFu3TrnuEkNHxcv9XLoHCUwMY RjhiDHTMRBC7lg+LWwNRi9/KaJS/YsTjPR7+GYaTRhGgBR9bemrEl7SJzaweBtZNhnUTEE1Ss jr4HwY1dC57//BB88yV/xdmU4/YbW8zHIKcF+9YlyjlKvsxGLyNywjcyhxBpRAc5vuDc/oqDO EU3mZqkKaxBQZ3m1azm2Q7aTlx9UtDK/222ITh0JiBO2N+z46wo8/REYlfsrpKM6ZQmp1rkwh JMmfegF5z16RjM8xQQFCcPjoz1ERl8yiiRxmcJBXpd+9ZsZQw1Z8GKfLpkJxQfHA90EeBbOkz JNKlRlKUU//S9GzIfqNMTest6YJ7MU+TrarkThpEEeYHwu5BYP+IKZGg3dtpiOb5MvpnY3vfj k4bNjgp9eLokBkEdrH/sI0jqiZDeQ3aLbd5JF6N8wffmiked/NvTGONpElaI+P+/DlF45RLdR Twle93RSZdYJkyZM/lX20Atei7FDaBH+xR7oiromPhP1FvneaY=
Archived-At: 
Subject: [Netconf] DHCP Text Update Proposal for draft-ietf-netconf-zerotouch-19
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 03:07:10 -0000

Hi,

Apologies for the late stage comment here, but this was based on a =
discussion between the authors and one of the DHCWG chairs at the =
welcome reception. As a result we believe that the text specifying the =
allowable URI contents and error handling for the DHCP4&6 options can be =
improved. I would like to propose the following changes to the draft:

9.1.  DHCPv4 Zero Touch Option

Section 9.1

 1.  Check the contents of the DHCPv4 message for at least one valid
     URI. If there is more than one valid URI in the list, a candidate
     list of possible URIs is created.

Is changed to:

 1.  Check the contents of the DHCPv4 message for at least one valid
     URI (see section 9.4). If there is more than one valid URI in the =
list, a candidate
     list of possible URIs is created.

Likewise, section 9.2 point 1 is changed to:

 1.  Check the contents of the DHCPv6 message for at least one valid
     URI (see section 9.4). If there is more than one valid URI in the =
list, a candidate
     list of possible URIs is created.

And a new Section 9.4 is added:

9.4 DHCP URI Validation

The following is valid for both the DHCPv4 OPTION_V4_ZEROTOUCH_REDIRECT=20=

and the DHCPv6 OPTION_V6_ZEROTOUCH_REDIRECT, as both options
contain URI data in the same format.

A valid URI for a zerotouch bootstrap server, MUST be according to the =
HTTPS URI
scheme defined in Section 2.7.2 of RFC7230. On receipt of a URI, the =
client, only
the =E2=80=98scheme=E2=80=99 component, and the =E2=80=98host=E2=80=99 =
and =E2=80=98port=E2=80=99 subcomponents of the =E2=80=98authority=E2=80=99=

component of the URI (RFC3986 Sections 3.1, 3.2.2, and 3.2.3 =
respectively)
are evaluated. If the URI contains a =E2=80=98userinfo=E2=80=99 =
subcomponent, the URI is discarded
as being invalid. If the URI contains a =E2=80=98path=E2=80=99 =
component, then this is ignored.

Any invalid URI entries received in the uri-data field are ignored by
the client.  If the received DHCP options does not contain at
least one valid URI entry in the uri-data field, then the client MUST
discard the option.

=E2=80=94=E2=80=94

Finally, for section 9.3,  I suggest that:
   o URI: URI of zerotouch bootstrap server, using the HTTPS URI
     scheme defined in Section 2.7.2 of RFC7230.  URI MUST be in
     form "https://[:]=E2=80=9D.

Is re-worded to:
   o URI: URI of zerotouch bootstrap server, using the HTTPS URI
     scheme defined in Section 2.7.2 of RFC7230.  The URI is in
     the form "https://[:]=E2=80=9D.

This is to ensure that the text can=E2=80=99t be read to place any =
additional option content validation requirements on the server =
implementation.=


From nobody Mon Nov 13 20:03:36 2017
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91212704A; Mon, 13 Nov 2017 20:03:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151063220946.5815.16712573864957024762@ietfa.amsl.com>
Date: Mon, 13 Nov 2017 20:03:29 -0800
Archived-At: 
Subject: [Netconf] I-D Action: draft-ietf-netconf-udp-pub-channel-01.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 04:03:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : UDP based Publication Channel for Streaming Telemetry
        Authors         : Guangying Zheng
                          Tianran Zhou
                          Alexander Clemm
	Filename        : draft-ietf-netconf-udp-pub-channel-01.txt
	Pages           : 12
	Date            : 2017-11-13

Abstract:
   This document describes a UDP-based publication channel for streaming
   telemetry use to collect data from devices.  A new shim header is
   proposed to facilitate the distributed data collection mechanism
   which directly pushes data from line cards to the collector.  Because
   of the lightweight UDP encapsulation, higher frequency and better
   transit performance can be achieved.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-01
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-pub-channel-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-pub-channel-01


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

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


From nobody Mon Nov 13 23:16:40 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F1C1243FE for ; Mon, 13 Nov 2017 23:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn9lJXqmzP8Z for ; Mon, 13 Nov 2017 23:16:37 -0800 (PST)
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 C6C7D1200E5 for ; Mon, 13 Nov 2017 23:16:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11284; q=dns/txt; s=iport; t=1510643796; x=1511853396; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5kotHiaZH/n9lG2NQfR9wkLYsv3zvueD0hlvAFMhg7s=; b=NrjyRfUm1El/zhjz+YJtB47UnAxrYvxSXUyO88ukneGj7FsyPFLgHv/k KgOoshZTyLVbtTv8TzWEtyllMfjbOqgetHwdzTmCxej+1PT/vQ4PupYjj UHgO2Bf+UGc7sQzVsKkse3H0+8z6LF06bN/eq6CiIP8h+3W85Pmm7kcaT 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQAtmApa/5pdJa1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNmRuJwedRYF9llAQggEKGAuESU8ChGZAFwEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAgEBATg0BAUCBQsCAQgOBwMNERAnCxsBBgMCBAENBQiKEggQrTWLE?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVgWmCHYENglFzgSgThhAFii4?= =?us-ascii?q?WiRaOUwKHaoNpiSeCHooMhyGKMoI4iRECERkBgTgBIAE2gXJ6FUmCZIJcHBmBT?= =?us-ascii?q?neHSYERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,393,1505779200"; d="scan'208";a="31217773"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2017 07:16:28 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAE7GRoB032049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2017 07:16:28 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 02:16:27 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 02:16:27 -0500
From: "Eric Voit (evoit)" 
To: Kent Watsen , Martin Bjorklund 
CC: Alexander Clemm , "netconf@ietf.org" 
Thread-Topic: [Netconf] two-week review of drafts related to notifications and subscriptions
Thread-Index: AQHTSH5n2+KEwzxeaUmOUUOjdzqfBKLrmFPQgAClhQD//9LP4IAFmdcA///CDQCAA2UI0A==
Date: Tue, 14 Nov 2017 07:16:26 +0000
Message-ID: <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.cisco.com>
References: <9a7b1940bf5a461a9630840234063e6f@XCH-RTP-013.cisco.com>  <19ba083dda224158a7414af94e3d3640@XCH-RTP-013.cisco.com> <20171023.144114.150465814300377965.mbj@tail-f.com> <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com>
In-Reply-To: <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.217.192]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] FW: two-week review of drafts related to notifications and subscriptions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 07:16:39 -0000

Hi Martin,
Hi Kent,

Ensuring comments are covered.  I do ask a question on potential model part=
itioning across the document in the first set of comments..,

> From: Martin Bjorklund, October 23, 2017 8:41 AM
>=20
> Hi,
>=20
> Some comments inline.
>=20
> "Eric Voit (evoit)"  wrote:
> > Hi Kent,
> >
> > > From: Kent Watsen, October 19, 2017 9:51 PM
> > >
> > > >> draft-ietf-netconf-subscribed-notifications-05
> > > >> ------------------------------------------------------
> > >
> > > >> very complicated (many details).
> > > >
> > > > If there anything you see as unnecessary, or perhaps should be=20
> > > > optional?
> > >
> > > The tree diagram is huge.  I understand that much of it is from=20
> > > grouping expansion, but still, there is a lot to consider (many=20
> > > details).  I'm just thinking that this is going to take time for=20
> > > folks to digest fully.
> >
> > We really made an attempt to simplify the tree by using a=20
> > filter-type object instead of the explicit subtyping.  But=20
> > experienced and capable reviewers argued that explicit subtyping was=20
> > better.  The result is that we returned to the larger explicitly=20
> > subtyping a couple weeks ago.  Overall, this added 25% to the tree diag=
ram size :-(.
>=20
> I don't think a big tree in itself necessarily means that the data model =
is bad.
> However, for readability purposes, you may want to split the big tree=20
> into smaller pieces.  See for example RFC 7404.

I think you mean RFC 7407?

We can do this.   Before I make the change, I want to confirm that it shoul=
d be only done for individual RPCs and Notifications, and top level contain=
ers in the data trees (e.g. streams and filters top level container).   I w=
ould also like to confirm that you are ok with all the downsides (1)-(4) li=
sted below.

(1)  To what section of subscribed-notifications do you look to when you ar=
e doing an augmentation in yang-push?  Having one tree to go to in one full=
 tree is easier than finding info across split trees.  I.e., a single tree =
is pretty useful for outside referencing on augmentations.

(2) YANG Push does not have section partitions for existing subscribed-noti=
fication RPCs and Notifications.  Therefore we couldn't do the exact same s=
egmentation of the tree structures across the two documents.  (I.e. it won'=
t be a 1:1 comparison when looking between the drafts.)

(3)  Segmentation lower that any top level container is not recommended.  T=
his is because augmentations occur at different levels of the tree.   Any o=
ther approach would mean tree information replicated in different tree diag=
rams.

(4)  It will increase the size of an already big document.

Based on this, I still think a single model is better.  But I am happy to m=
ake the change if consensus is otherwise.
=20
> > > >>         flow difficult to read.
> > > >
> > > > Anything specific?  I am happy to re-order as suggested.
> > >
> > > Also, I'm suspecting that the update from Martin's comments will=20
> > > get much of this.  It just seemed that every time tried to chase=20
> > > some bit of information down, it wasn't stated quite right (e.g.,=20
> > > terminology, phasing, open-endedness, etc.).  All this got in the=20
> > > way of the readability.
> >
> > Hopefully I got the ones which don't resonate.  My natural ecosystem=20
> > is deeper in the router, and YANG means I need to use different terms.
> >
> > > >> * what is "promise theory based interaction model"? =20
> > > >> (reference?)
> > > > Yes, I will add the reference.  The best on-line one I know is:
> > > >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__markburgess.
> > > > or
> > > > g_Pr
> > > > omiseMethod.pdf&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > > ndb3voDTXcWzoCI
> > > >
> > >
> &r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DzDualRWvSwyZj8MF
> > > PL_Xo
> > > >
> > >
> pkywEp9xEJgZXjyhdIBPog&s=3DDcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2xpE
> > > Oc0o&e
> > > > =3D
> > >
> > > Oh my, that document is 38 pages, I was hoping for simple=20
> > > statement (e.g., the system takes defensive measures in order to=20
> > > ensure resources are available).  I think you have something like=20
> > > this in the yang-push draft.
> >
> > I can add a simple statement.  Something like "voluntary cooperation=20
> > between individual, autonomous agents who continuously refine their=20
> > changing intentions to one another in the form of promises".
>=20
> Does this really help people to understand this document?

I didn't such a statement helped either,  so all references in subscribed-n=
otifications have been removed.    As this is important in yang-push, I twe=
aked the reference section 3.4 with the kind of info I think Kent wanted in=
 his simple statement. =20

> > > >> * what is the relationship between streams here and in 5277?
> > > >
> > > > This document doesn't discuss the details of how streams are=20
> > > > generated within the publisher like 5277 does.  This detail is=20
> > > > not necessary for the external interface definition.
> > > >
> > > > That said, how to handle/encode names of the streams, the=20
> > > > managed objects, the ability to filter, etc. are identical.
> > >
> > > This document should explain the relationship though, right? (see
> > > above)
> >
> > Is this necessary in the normative part of the document?  When the=20
> > notification-messages draft is complete, it will be possible to=20
> > obsolete RFC-5277 at some later date.  How many linkages are=20
> > appropriate?
> >
> > What I did do in the new version (per Martin's request) is to place=20
> > in Appendix A: Relationship to RFC-5277.  What I believe we should=20
> > do is place statements identifying the re-used stream constructs. =20
> > Would that work?
>=20
> I think such a section is needed, and I think it shouldn't be an=20
> Appendix, but rather one of the first sections.  This is quite common=20
> in RFCs that updates/obsoletes older RFCs.

Done.  See Section 1.4.  Relationship to RFC-5277

> > > >> * streams here are identities, unlike "streamNameType"
> > > >> (aka xs:string) in 5077.  Is this an issue?
> > > >
> > > > Based on Martin's comments that he desires to retain the ability=20
> > > > for streams to be spun up possibly during run-time, we have=20
> > > > returned to using string for streams (as we did in earlier
> > > > versions of the draft).   Our switch to identities several
> > > > months ago was one attempt we made to simplify things, but
> > > > it didn't work out.    This is an issue and a resolution we
> > > > have long been anticipating.
> > >
> > > okay
> > >
> > >
> > > >> * use of " operations" for configured=20
> > > >> subscriptions is confusing.
> > > >
> > > > It is just a normal configuration.  I will happily delete the=20
> > > > example if you think it unnecessary or redundant.
> > >
> > > No, the examples are good.  It's literally the words=20
> > > " operations"
> > > are problematic.  Use some other phrasing that is not=20
> > > NETCONF-specific.
> >
> > I will just use 'configuration operations'
> >
> > > >> * the example in s5.1 seems to be more about how to create a=20
> > > >> configured subscription than establishing a subscription=20
> > > >> connection
> > > >
> > > > Exactly.  How to establish the subscription connection is=20
> > > > transport specific, and therefore in the netconf-notif draft.
> > > > Specifically in Section 3.4.3
> > >
> > > But the section is called "Establishing a Configured Subscription".
> > > I think this actually goes to your use of the word "establish",=20
> > > perhaps "create" is a better word - "Creating a Configured Subscripti=
on" ?
> >
> > Will do.  No reason to reuse the establish if it confuses people.
> >
> > > >> * Section 7 says "This notification message MAY be encoded as=20
> > > >> one-way notification element of [RFC5277], Section 4."  If this=20
> > > >> is a MAY, how does the client know what it received?  And how=20
> > > >> does the publisher know what format to send?
> > > >
> > > > I was trying to lay the groundwork for a future support of=20
> > > > notification-messages in a way that this document wouldn't have=20
> > > > to be updated.  I have given up on that.  Support is now a MUST. =20
> > > > And this will need to be revised in the future when we get=20
> > > > notification-messages to an RFC state.
> > >
> > > okay
> > >
> > >
> > > >> * xpath-filter is not a feature-based option?
> > > >
> > > > Not feature based.  Of course if the syntax is not supported on=20
> > > > a filter, the subscription will be rejected with the error=20
> > > > "filter-type-unsupported ".
> > > >
> > > > At this point, I don't recall anyone suggesting xpath should not=20
> > > > be a mandatory for event filtering though.
> > >
> > > well, it's not mandatory for NETCONF-based filtering.  So, a=20
> > > system that doesn't support XPath filtering in NETCONF would have=20
> > > to support XPath filtering here?
> >
> > Hmm.  I had been hoping to have at least one (xpath) as mandatory.
> > But maybe that is unrealistic.
> >
> > What I am thinking is that maybe both filters should be optional=20
> > features.  And then specific transport drafts (like NETCONF) can=20
> > identify them as mandatory. At least when that transport is used.
> >
> > > >> * I see top-level /subscription-config and /subscriptions - is=20
> > > >> this NMDA compliant?
> > > >
> > > > As this pre-dates NMDA, we are awaiting the "you MUST make the=20
> > > > conversion" directive.  And if this comes, we will gladly do that.
> > >
> > > https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSIoH
> > > 4g
> > > A-8M
> > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sectio
> > > n-
> > > 4.23.3
> >
> > Yep.  We do fall in the SHOULD category :-)
> >
> > But seriously, we can convert.
>=20
> Before doing anything, make sure the "subscription-id" issue is=20
> resolved first.  If Rob's proposal is adopted, we will still need two=20
> lists, one config and one operational, even in the NMDA-compliant=20
> version.  Some changes might be needed in the naming of top-level contain=
ers though.

Based on the comments received on the subscription-id datatype.  Rough cons=
ensus is integer.   We will covert to NMDA after all other issues are close=
d in set of drafts going to WGLC.

Eric

> > The question is how to do this without losing our place in the=20
> > review queue.  We had expected to be through WGLC *long* before NMDA=20
> > was formalized.  And we are very concerned this policy change could=20
> > result in further delay.  So the current plan we have is to get=20
> > agreement on the contents of the model.  And then agreement that we=20
> > have converted what is an acceptable model into an equivalent NMDA vers=
ion.
>=20
>=20
> /martin

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


From nobody Tue Nov 14 00:41:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C55124D6C for ; Tue, 14 Nov 2017 00:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYgd3HxEo_aE for ; Tue, 14 Nov 2017 00:41:18 -0800 (PST)
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 30FC912008A for ; Tue, 14 Nov 2017 00:41:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28708; q=dns/txt; s=iport; t=1510648878; x=1511858478; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2if7niPbzGf3Aeuf8kNrkFjVpLKtSbWk58LA4PSbYuE=; b=cTiZGDA8PQGVQmd8FHjmSLxnm5IAWy/W2iXVrKsg+9lbOTSD/LyuQts/ xEvBJcdp2FD6pUXCCFC9Ik0RUTkXIcA3QNeAvYpx3hW8RpJtoa47qtDHs kbNgmfLGgusH3bGSrfGJqg3Rb1qKY1F7MMYdSlEPR25CQyCstsYaV0+XO s=;
X-IronPort-AV: E=Sophos;i="5.44,393,1505779200";  d="scan'208,217";a="318507294"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 08:40:52 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAE8epU9018403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Nov 2017 08:40:51 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 03:40:50 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 03:40:50 -0500
From: "Eric Voit (evoit)" 
To: "netconf@ietf.org" 
Thread-Topic: SN #6 String or Integer for Subscription ID
Thread-Index: AQHTTC+bmnoVz/P44ke/JeKF0s6HTqMTrjKg
Date: Tue, 14 Nov 2017 08:40:50 +0000
Message-ID: 
References: <72EC9947-3A3B-425A-A5D7-93D1D1C6778E@cisco.com>
In-Reply-To: <72EC9947-3A3B-425A-A5D7-93D1D1C6778E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.217.192]
Content-Type: multipart/alternative; boundary="_000_df6e2364f58a47178cf2a4fd0d47512cXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 08:41:20 -0000

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

QWZ0ZXIgbG90cyBvZiBpbnRlcmFjdGlvbnMgYW5kIGdvb2QgZGlzY3Vzc2lvbiwgYSBtYWpvcml0
eSBvZiBwZW9wbGUgaGF2ZSBleHByZXNzZWQgYSBkZXNpcmUgZm9yIGludGVnZXIgb3ZlciBzdHJp
bmcgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuICBC
YXNlZCBvbiB0aGF0IEkgYW0gY2xvc2luZyB0aGUgaXNzdWUgU04jNiB3aXRoIG5vIGNoYW5nZXMg
dG8gdGhlIHlhbmcgbW9kZWwuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUy
NzdiaXMvaXNzdWVzLzYNCg0KRXJpYw0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW0gSmVua2lucyAodGltamVua2kpDQpT
ZW50OiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcgMjo0OSBQTQ0KVG86IG5ldGNvbmZAaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gU04gIzYgU3RyaW5nIG9yIEludGVnZXIgZm9yIFN1
YnNjcmlwdGlvbiBJRA0KDQpBbGwsDQoNClRoaXMgbm90ZSBhdHRlbXB0cyB0byB0YWtlIGEgZGV0
YWlsZWQgbG9vayBhdCB0aGUgdHdvIG1haW4gcHJvcG9zYWxzIGZvciB0aGUgdXNlIG9mIHN1YnNj
cmlwdGlvbiBJRHMgZm9yIHRoZSBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMgZHJhZnQuDQoNClRo
ZSB0d28gcHJvcG9zYWxzIHRoYXQgSSdsbCBleGFtaW5lIGhlcmUgYXJlICdzaW5nbGUgaW50ZWdl
ciBJRCB0eXBlJyBhbmQgJ21peGVkIElEIHR5cGUnIGFzIEknbSByZWZlcnJpbmcgdG8gdGhlbS4g
UHJvcG9zYWxzIHdoZXJlIHRoZSB1cGRhdGUgbm90aWZpY2F0aW9ucyBhcmUgZGlmZmVyZW50IGZy
b20gY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFuZCBkeW5hbWljIHN1YnNjcmlwdGlvbnMgYXJl
IG5vdCBjb25zaWRlcmVkLCBzaW5jZSB0aGF0IGlzIGhpZ2hseSB1bmRlc2lyYWJsZSBhbmQgbW9y
ZSBjb21wbGV4Lg0KDQpJbiB0aGUgJ3NpbmdsZSBpbnRlZ2VyIElEIHR5cGUnIHByb3Bvc2FsLCB0
aGUgc3Vic2NyaXB0aW9uIHJlY29yZHMgaW4gYm90aCB0aGUgY29uZmlndXJhdGlvbiBhbmQgb3Bl
cmF0aW9uYWwgdGFibGVzIG9mIHN1YnNjcmlwdGlvbnMgYXJlIGluZGV4ZWQgYnkgYSAzMi1iaXQg
aW50ZWdlciB2YWx1ZS4gU2luY2UgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFsc28gYXBwZWFy
IGluIHRoZSBvcGVyYXRpb25hbCB0YWJsZSwgdGhlIGluZGV4IHNwYWNlIGlzIGNvbW1vbiBiZXR3
ZWVuIGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGlvbmFsIHN1YnNjcmlwdGlvbnMuIFN1YnNjcmliZXJz
IGNyZWF0ZSB0aGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gSURzLCB3aGlsZSB0aGUgcHVibGlz
aGVyIGNyZWF0ZXMgdGhlIGR5bmFtaWMgc3Vic2NyaXB0aW9uIElEcy4gVGh1cywgdGhlcmUgaXMg
YW4gaXNzdWUgb2YgcG90ZW50aWFsIGNvbmZsaWN0OyBpdCBoYXMgYmVlbiBwcm9wb3NlZCB0byBz
cGxpdCB0aGUgc3BhY2UgYmV0d2VlbiBzdWJjcmliZXIgYW5kIHB1Ymxpc2hlciBnZW5lcmF0ZWQg
dG8gcmVtb3ZlIHRoaXMgcG90ZW50aWFsIGNvbmZsaWN0Lg0KDQpJbiB0aGUgJ21peGVkIElEIHR5
cGUnIHByb3Bvc2FsLCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgYXJlIGNyZWF0ZWQgd2l0aCBh
IHN0cmluZyBJRCBieSB0aGUgc3Vic2NyaWJlciwgYW5kIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBh
cmUgY3JlYXRlZCB3aXRoIGEgMzItYml0IGludGVnZXIgSUQgYnkgdGhlIHB1Ymxpc2hlci4gVGhl
IHB1Ymxpc2hlciBhbHNvIGNyZWF0ZXMgYSAzMi1iaXQgaW50ZWdlciBJRCBmb3IgY29uZmlndXJl
ZCBzdWJzY3JpcHRpb25zLCBzbyB0aGV5IGVmZmVjdGl2ZWx5IGhhdmUgdHdvIElEcy4gVGhlc2Ug
YXJlIHJlZmVycmVkIHRvIGFzIHRoZSBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoIElEcyBmb3IgdGhl
IHJlc3Qgb2YgdGhpcyBub3RlLiBUaGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIHRhYmxlIGlz
IGluZGV4ZWQgYnkgdGhlIHN1YnNjcmliZXIgSUQgYW5kIHRoZSBwdWJsaXNoZXIgSUQgZG9lcyBu
b3QgYXBwZWFyIGluIHRoaXMgdGFibGUgYmVjYXVzZSBpdCBpcyBub3QgY29uZmlndXJhdGlvbiBk
YXRhLiBUaGUgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9ucyB0YWJsZSBpcyBpbmRleGVkIGJ5IHRo
ZSBwdWJsaXNoZXIgSUQgYW5kIHRoZSBzdWJzY3JpYmVyIElEIGFwcGVhcnMgaW4gdGhpcyB0YWJs
ZSwgYnV0IG9ubHkgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGVudHJpZXMuDQoNCkkgd2ls
bCBhdHRlbXB0IHRvIGV2YWx1YXRlIHRoZSB0d28gcHJvcG9zYWxzIGFnYWluc3Qgc29tZSBpc3N1
ZXMuDQoNCjEvIEhvdyBhIHJlY2VpdmVyIGlkZW50aWZpZXMgd2hpY2ggc3Vic2NyaXB0aW9uIGFu
IHVwZGF0ZSBub3RpZmljYXRpb24ncyBjb250ZW50cyBhcmUgYXNzb2NpYXRlZCB3aXRoLg0KDQon
c2luZ2xlIGludGVnZXIgSUQnICAgICAgICAgICAgICAgLXVzZXMgb25seSBJRCBhdmFpbGFibGUs
IGJ1dCBjYW4gdXNlIHRoZSBJRCBpbiB0aGUgJ3N1YnNjcmlwdGlvbi1zdGFydGVkJyBub3RpZmlj
YXRpb24gYXMgd2VsbA0KJ21peGVkIElEcycgICAgICAgICAgICAgICAgICAgICAgICAgICAgLWxl
YXJucyBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoZXIgSURzIGZyb20gJ3N1YnNjcmlwdGlvbi1zdGFy
dGVkJyBub3RpZmljYXRpb24uIFRoaXMgbm90aWZpY2F0aW9uIGhhcyB0byBiZSBtb2RpZmllZCB0
byBjYXJyeSBpdCwgYW5kIHJlY2VpdmVycyBoYXZlIHRvIHBhcnNlIGl0Lg0KDQoyLyBIb3cgdGhl
IGlzc3VlIG9mIG11bHRpcGxlIHNvdXJjZXMgb2YgSUQgZ2VuZXJhdGlvbiBpcyBoYW5kbGVkLg0K
DQonc2luZ2xlIGludGVnZXIgSUQnICAgICAgICAgICAgICAgLXNwbGl0IHRoZSAzMi1iaXQgaW50
ZWdlciBzcGFjZSBmb3IgaXNzdWUgYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXJzOyB0
aGlzIGRvZXMgbm90IHNvbHZlIGlzc3VlIGFtb25nIG11bHRpcGxlIHN1YnNjcmliZXJzDQonbWl4
ZWQgSURzJyAgICAgICAgICAgICAgICAgICAgICAgICAgIC1ub3QgYW4gaXNzdWUgYmV0d2VlbiBw
dWJsaXNoZXIgYW5kIHN1YnNjcmliZXJzOyBidXQgZG9lcyBub3Qgc29sdmUgaXNzdWUgYW1vbmcg
bXVsdGlwbGUgc3Vic2NyaWJlcnMNCg0KMy8gSG93IHN1YnNjcmlwdGlvbnMgYXJlIGFzc29jaWF0
ZWQgYWNyb3NzIG11bHRpcGxlIHB1Ymxpc2hlcnMuIFRoYXQgaXMsIGhvdyBkbyBzZXBhcmF0ZSBy
ZWNlaXZlcnMga25vdyB3aGljaCBzdWJzY3JpcHRpb25zIGFyZSBjb25zaWRlcmVkIHRvIGJlIHRo
ZSBzYW1lIHdoZW4gdGhleSBhcnJpdmUgZnJvbSBkaWZmZXJlbnQgcHVibGlzaGVycz8NCg0KJ3Np
bmdsZSBpbnRlZ2VyIElEJyAgICAgICAgICAgICAgIC1zdWJzY3JpYmVyIHNlbmRzIHRvIHJlY2Vp
dmVycyB0aGUgSURzIGl0IHVzZWQgdG8gY3JlYXRlIHRoZSBzdWJzY3JpcHRpb25zOyBpdCBzaG91
bGQgaGF2ZSB1c2VkIHRoZSBzYW1lIElEIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb25zIG9uIHNl
cGFyYXRlIHB1Ymxpc2hlcnMNCidtaXhlZCBJRHMnICAgICAgICAgICAgICAgICAgICAgICAgICAg
LXN1YnNjcmliZXIgc2VuZHMgdG8gcmVjZWl2ZXJzIHRoZSBJRHMgaXQgdXNlZCB0byBjcmVhdGUg
dGhlIHN1YnNjcmlwdGlvbnM7IGl0IHNob3VsZCBoYXZlIHVzZWQgdGhlIHNhbWUgSUQgZm9yIHRo
ZSBzYW1lIHN1YnNjcmlwdGlvbnMgb24gc2VwYXJhdGUgcHVibGlzaGVycy4gVGhlIHJlY2VpdmVy
cyBtdXN0IHBhcnNlIHRoZSAnc3Vic2NyaXB0aW9uLXN0YXJ0ZWQnIG5vdGlmaWNhdGlvbnMgZnJv
bSBwdWJsaXNoZXJzIGFuZCBjcmVhdGUgYW5kIG1haW50YWluIGEgbWFwIG9mIGludGVnZXJzIElE
cyB0byB0ZXh0IElEcy4gVGhpcyBtYXAgbXVzdCBiZSB1c2VkIHdpdGggdXBkYXRlIG5vdGlmaWNh
dGlvbnMsIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIHN1YnNjcmlwdGlvbiBJRCBvZiBpbnRlcmVz
dC4NCg0KNC8gSG93IGh1bWFuIHJlYWRhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJzY3Jp
cHRpb25zIGlzIHByb3ZpZGVkLg0KDQonc2luZ2xlIGludGVnZXIgSUQnICAgICAgICAgICAgICAg
LWFuIHVucmVzdHJpY3RlZCB0ZXh0IGZpZWxkIGNhbiBiZSBhZGRlZCB0byBzdWJzY3JpcHRpb25z
IGFzIG5lZWRlZC4gVGhlIGFkZGl0aW9uIG9mIGFuIHVucmVzdHJpY3RlZCB0ZXh0IGZpZWxkIGNh
biBiZSBkb25lIGZvciBib3RoIGNvbmZpZ3VyZWQgYW5kIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBp
ZiBkZXNpcmVkIGFuZCBtYWtlcyB0aGUgbmVlZCBmb3IgYSB0ZXh0IElEIHN0cmluZyB1bm5lY2Vz
c2FyeS4NCidtaXhlZCBJRHMnICAgICAgICAgICAgICAgICAgICAgICAgICAgLXRoZSBzdHJpbmcg
SUQgdXNlZCBpcyBsaW1pdGVkOiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgb25seSwgYW5kIG11
c3QgYmUgYWJsZSB0byBiZSBhIGtleQ0KDQpBZGRpdGlvbmFsIE5vdGVzOg0KDQpJbnRlZ2VyIElE
IFNwYWNlIFNwbGl0OiBGb3IgdGhlIHNpbmdsZSBpbnRlZ2VyIElEIGNhc2UsIHRoaXMgaXMgYSB2
ZXJ5IHNpbXBsZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4gQXMgY3VycmVudGx5IHByb3Bvc2Vk
LCB0aGUgdXBwZXIgaGFsZiBvZiB0aGUgMzItYml0IHVuc2lnbmVkIGludGVnZXIgc3BhY2UgaXMg
c2V0IGFzaWRlIGZvciBkeW5hbWljIHN1YnNjcmlwdGlvbnMsIGJ1dCBvdGhlciBzcGxpdHMgYXJl
IHBvc3NpYmxlLiBPbmUgd291bGQgYmUgdG8gdXNlIHNpZ25lZCBpbnRlZ2VycywgYW5kIHVzZSB0
aGUgc2lnbiB0byBzcGl0IHRoZSBzcGFjZS4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgdXNlIG9mIHNt
YWxsIGludGVnZXJzIGZvciBib3RoIGNvbmZpZ3VyZWQgYW5kIGR5bmFtaWMgc3Vic2NyaXB0aW9u
cyB3aGVuIGVuY29kaW5nIHJ1bGVzIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBzdWNoIHRoaW5ncy4N
Cg0KQ29uY2x1c2lvbjoNCg0KVGhlIHVzZSBvZiBhIHN0cmluZyBhcyBhIHN1YnNjcmlwdGlvbiBJ
RCBpcyBvdmVyYWxsIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBmaW5kaW5nIGEgc2ltcGxlIHNvbHV0
aW9uIGZvciBzcGxpdHRpbmcgdGhlIGludGVnZXIgSUQgc3BhY2UgYmV0d2VlbiBwdWJsaXNoZXIg
YW5kIHN1YnNjcmliZXIgc3BhY2UuDQoNClRpbQ0KDQotLQ0KQ2lzY28gU3lzdGVtcyBDYW5hZGEg
Q28uDQoyMDAwIElubm92YXRpb24gRHJpdmUNCkthbmF0YSwgT04sIENhbmFkYSwgSzJLIDNFOA0K
UHJlZmVyZW5jZXMgPGh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmliZS8/c2lkPTAw
MDQ3ODMyNj4NClVuc3Vic2NyaWJlIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci91bnN1YnNj
cmliZS8/c2lkPTAwMDQ3ODMyNz4NClByaXZhY3kgPGh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9z
aXRlYXNzZXRzL2xlZ2FsL3ByaXZhY3kuaHRtbD4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw
YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi
IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5B
ZnRlciBsb3RzIG9mIGludGVyYWN0aW9ucyBhbmQgZ29vZCBkaXNjdXNzaW9uLCBhIG1ham9yaXR5
IG9mIHBlb3BsZSBoYXZlIGV4cHJlc3NlZCBhIGRlc2lyZSBmb3IgaW50ZWdlciBvdmVyIHN0cmlu
ZyBmb3IgdGhlIGlkZW50aWZpY2F0aW9uIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4mbmJz
cDsgQmFzZWQgb24gdGhhdCBJIGFtIGNsb3NpbmcNCiB0aGUgaXNzdWUgU04jNiB3aXRoIG5vIGNo
YW5nZXMgdG8gdGhlIHlhbmcgbW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9n
aXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNiI+aHR0cHM6Ly9naXRodWIu
Y29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5Fcmlj
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gTmV0Y29uZiBbbWFpbHRvOm5ldGNv
bmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGltIEplbmtpbnMgKHRp
bWplbmtpKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjMsIDIwMTcgMjo0OSBQ
TTxicj4NCjxiPlRvOjwvYj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogW05ldGNvbmZdIFNOICM2IFN0cmluZyBvciBJbnRlZ2VyIGZvciBTdWJzY3JpcHRpb24gSUQ8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+VGhpcyBub3RlIGF0dGVtcHRzIHRvIHRha2UgYSBkZXRhaWxlZCBsb29rIGF0
IHRoZSB0d28gbWFpbiBwcm9wb3NhbHMgZm9yIHRoZSB1c2Ugb2Ygc3Vic2NyaXB0aW9uIElEcyBm
b3IgdGhlIHN1YnNjcmliZWQgbm90aWZpY2F0aW9ucyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSB0d28gcHJvcG9zYWxzIHRoYXQgSSdsbCBleGFt
aW5lIGhlcmUgYXJlICdzaW5nbGUgaW50ZWdlciBJRCB0eXBlJyBhbmQgJ21peGVkIElEIHR5cGUn
IGFzIEknbSByZWZlcnJpbmcgdG8gdGhlbS4gUHJvcG9zYWxzIHdoZXJlIHRoZSB1cGRhdGUgbm90
aWZpY2F0aW9ucyBhcmUgZGlmZmVyZW50IGZyb20gY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFu
ZA0KIGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBhcmUgbm90IGNvbnNpZGVyZWQsIHNpbmNlIHRoYXQg
aXMgaGlnaGx5IHVuZGVzaXJhYmxlIGFuZCBtb3JlIGNvbXBsZXguPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiB0aGUgJ3NpbmdsZSBpbnRlZ2VyIElEIHR5cGUn
IHByb3Bvc2FsLCB0aGUgc3Vic2NyaXB0aW9uIHJlY29yZHMgaW4gYm90aCB0aGUgY29uZmlndXJh
dGlvbiBhbmQgb3BlcmF0aW9uYWwgdGFibGVzIG9mIHN1YnNjcmlwdGlvbnMgYXJlIGluZGV4ZWQg
YnkgYSAzMi1iaXQgaW50ZWdlciB2YWx1ZS4gU2luY2UgY29uZmlndXJlZCBzdWJzY3JpcHRpb25z
IGFsc28NCiBhcHBlYXIgaW4gdGhlIG9wZXJhdGlvbmFsIHRhYmxlLCB0aGUgaW5kZXggc3BhY2Ug
aXMgY29tbW9uIGJldHdlZW4gY29uZmlndXJlZCBhbmQgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9u
cy4gU3Vic2NyaWJlcnMgY3JlYXRlIHRoZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBJRHMsIHdo
aWxlIHRoZSBwdWJsaXNoZXIgY3JlYXRlcyB0aGUgZHluYW1pYyBzdWJzY3JpcHRpb24gSURzLiBU
aHVzLCB0aGVyZSBpcyBhbiBpc3N1ZSBvZiBwb3RlbnRpYWwNCiBjb25mbGljdDsgaXQgaGFzIGJl
ZW4gcHJvcG9zZWQgdG8gc3BsaXQgdGhlIHNwYWNlIGJldHdlZW4gc3ViY3JpYmVyIGFuZCBwdWJs
aXNoZXIgZ2VuZXJhdGVkIHRvIHJlbW92ZSB0aGlzIHBvdGVudGlhbCBjb25mbGljdC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHRoZSAnbWl4ZWQgSUQgdHlw
ZScgcHJvcG9zYWwsIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyBhcmUgY3JlYXRlZCB3aXRoIGEg
c3RyaW5nIElEIGJ5IHRoZSBzdWJzY3JpYmVyLCBhbmQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGFy
ZSBjcmVhdGVkIHdpdGggYSAzMi1iaXQgaW50ZWdlciBJRCBieSB0aGUgcHVibGlzaGVyLiBUaGUg
cHVibGlzaGVyIGFsc28NCiBjcmVhdGVzIGEgMzItYml0IGludGVnZXIgSUQgZm9yIGNvbmZpZ3Vy
ZWQgc3Vic2NyaXB0aW9ucywgc28gdGhleSBlZmZlY3RpdmVseSBoYXZlIHR3byBJRHMuIFRoZXNl
IGFyZSByZWZlcnJlZCB0byBhcyB0aGUgc3Vic2NyaWJlciBhbmQgcHVibGlzaCBJRHMgZm9yIHRo
ZSByZXN0IG9mIHRoaXMgbm90ZS4gVGhlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyB0YWJsZSBp
cyBpbmRleGVkIGJ5IHRoZSBzdWJzY3JpYmVyIElEIGFuZCB0aGUgcHVibGlzaGVyDQogSUQgZG9l
cyBub3QgYXBwZWFyIGluIHRoaXMgdGFibGUgYmVjYXVzZSBpdCBpcyBub3QgY29uZmlndXJhdGlv
biBkYXRhLiBUaGUgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9ucyB0YWJsZSBpcyBpbmRleGVkIGJ5
IHRoZSBwdWJsaXNoZXIgSUQgYW5kIHRoZSBzdWJzY3JpYmVyIElEIGFwcGVhcnMgaW4gdGhpcyB0
YWJsZSwgYnV0IG9ubHkgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGVudHJpZXMuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdpbGwgYXR0ZW1wdCB0byBl
dmFsdWF0ZSB0aGUgdHdvIHByb3Bvc2FscyBhZ2FpbnN0IHNvbWUgaXNzdWVzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MS8gSG93IGEgcmVjZWl2ZXIgaWRlbnRp
ZmllcyB3aGljaCBzdWJzY3JpcHRpb24gYW4gdXBkYXRlIG5vdGlmaWNhdGlvbidzIGNvbnRlbnRz
IGFyZSBhc3NvY2lhdGVkIHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4nc2luZ2xlIGludGVnZXIgSUQnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC11
c2VzIG9ubHkgSUQgYXZhaWxhYmxlLCBidXQgY2FuIHVzZSB0aGUgSUQgaW4gdGhlICdzdWJzY3Jp
cHRpb24tc3RhcnRlZCcgbm90aWZpY2F0aW9uIGFzIHdlbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+J21p
eGVkIElEcycmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
LWxlYXJucyBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoZXIgSURzIGZyb20gJ3N1YnNjcmlwdGlvbi1z
dGFydGVkJyBub3RpZmljYXRpb24uIFRoaXMgbm90aWZpY2F0aW9uIGhhcyB0byBiZSBtb2RpZmll
ZCB0byBjYXJyeSBpdCwgYW5kIHJlY2VpdmVycyBoYXZlIHRvIHBhcnNlIGl0LjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Mi8gSG93IHRoZSBpc3N1ZSBvZiBtdWx0
aXBsZSBzb3VyY2VzIG9mIElEIGdlbmVyYXRpb24gaXMgaGFuZGxlZC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidzaW5nbGUgaW50ZWdlciBJRCcmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgLXNwbGl0IHRoZSAzMi1iaXQgaW50ZWdlciBzcGFjZSBmb3IgaXNz
dWUgYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXJzOyB0aGlzIGRvZXMgbm90IHNvbHZl
IGlzc3VlIGFtb25nIG11bHRpcGxlIHN1YnNjcmliZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidtaXhl
ZCBJRHMnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LW5v
dCBhbiBpc3N1ZSBiZXR3ZWVuIHB1Ymxpc2hlciBhbmQgc3Vic2NyaWJlcnM7IGJ1dCBkb2VzIG5v
dCBzb2x2ZSBpc3N1ZSBhbW9uZyBtdWx0aXBsZSBzdWJzY3JpYmVyczxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+My8gSG93IHN1YnNjcmlwdGlvbnMgYXJlIGFzc29j
aWF0ZWQgYWNyb3NzIG11bHRpcGxlIHB1Ymxpc2hlcnMuIFRoYXQgaXMsIGhvdyBkbyBzZXBhcmF0
ZSByZWNlaXZlcnMga25vdyB3aGljaCBzdWJzY3JpcHRpb25zIGFyZSBjb25zaWRlcmVkIHRvIGJl
IHRoZSBzYW1lIHdoZW4gdGhleSBhcnJpdmUgZnJvbSBkaWZmZXJlbnQgcHVibGlzaGVycz88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidzaW5nbGUgaW50ZWdlciBJ
RCcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLXN1YnNjcmliZXIgc2VuZHMgdG8gcmVjZWl2
ZXJzIHRoZSBJRHMgaXQgdXNlZCB0byBjcmVhdGUgdGhlIHN1YnNjcmlwdGlvbnM7IGl0IHNob3Vs
ZCBoYXZlIHVzZWQgdGhlIHNhbWUgSUQgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbnMgb24gc2Vw
YXJhdGUgcHVibGlzaGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4nbWl4ZWQgSURzJyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy1zdWJzY3JpYmVyIHNlbmRzIHRv
IHJlY2VpdmVycyB0aGUgSURzIGl0IHVzZWQgdG8gY3JlYXRlIHRoZSBzdWJzY3JpcHRpb25zOyBp
dCBzaG91bGQgaGF2ZSB1c2VkIHRoZSBzYW1lIElEIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb25z
IG9uIHNlcGFyYXRlIHB1Ymxpc2hlcnMuIFRoZSByZWNlaXZlcnMNCiBtdXN0IHBhcnNlIHRoZSAn
c3Vic2NyaXB0aW9uLXN0YXJ0ZWQnIG5vdGlmaWNhdGlvbnMgZnJvbSBwdWJsaXNoZXJzIGFuZCBj
cmVhdGUgYW5kIG1haW50YWluIGEgbWFwIG9mIGludGVnZXJzIElEcyB0byB0ZXh0IElEcy4gVGhp
cyBtYXAgbXVzdCBiZSB1c2VkIHdpdGggdXBkYXRlIG5vdGlmaWNhdGlvbnMsIHRvIGRldGVybWlu
ZSB0aGUgYWN0dWFsIHN1YnNjcmlwdGlvbiBJRCBvZiBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+NC8gSG93IGh1bWFuIHJlYWRhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJzY3Jp
cHRpb25zIGlzIHByb3ZpZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+J3NpbmdsZSBpbnRlZ2VyIElEJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtYW4g
dW5yZXN0cmljdGVkIHRleHQgZmllbGQgY2FuIGJlIGFkZGVkIHRvIHN1YnNjcmlwdGlvbnMgYXMg
bmVlZGVkLiBUaGUgYWRkaXRpb24gb2YgYW4gdW5yZXN0cmljdGVkIHRleHQgZmllbGQgY2FuIGJl
IGRvbmUgZm9yIGJvdGggY29uZmlndXJlZCBhbmQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGlmDQog
ZGVzaXJlZCBhbmQgbWFrZXMgdGhlIG5lZWQgZm9yIGEgdGV4dCBJRCBzdHJpbmcgdW5uZWNlc3Nh
cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidtaXhlZCBJRHMnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LXRoZSBzdHJpbmcgSUQgdXNlZCBpcyBsaW1pdGVkOiBj
b25maWd1cmVkIHN1YnNjcmlwdGlvbnMgb25seSwgYW5kIG11c3QgYmUgYWJsZSB0byBiZSBhIGtl
eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWRkaXRpb25hbCBO
b3Rlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkludGVnZXIg
SUQgU3BhY2UgU3BsaXQ6IEZvciB0aGUgc2luZ2xlIGludGVnZXIgSUQgY2FzZSwgdGhpcyBpcyBh
IHZlcnkgc2ltcGxlIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLiBBcyBjdXJyZW50bHkgcHJvcG9z
ZWQsIHRoZSB1cHBlciBoYWxmIG9mIHRoZSAzMi1iaXQgdW5zaWduZWQgaW50ZWdlciBzcGFjZSBp
cyBzZXQgYXNpZGUgZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucywNCiBidXQgb3RoZXIgc3BsaXRz
IGFyZSBwb3NzaWJsZS4gT25lIHdvdWxkIGJlIHRvIHVzZSBzaWduZWQgaW50ZWdlcnMsIGFuZCB1
c2UgdGhlIHNpZ24gdG8gc3BpdCB0aGUgc3BhY2UuIFRoaXMgd291bGQgYWxsb3cgdGhlIHVzZSBv
ZiBzbWFsbCBpbnRlZ2VycyBmb3IgYm90aCBjb25maWd1cmVkIGFuZCBkeW5hbWljIHN1YnNjcmlw
dGlvbnMgd2hlbiBlbmNvZGluZyBydWxlcyBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2Ygc3VjaCB0aGlu
Z3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25jbHVzaW9u
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHVzZSBvZiBh
IHN0cmluZyBhcyBhIHN1YnNjcmlwdGlvbiBJRCBpcyBvdmVyYWxsIG1vcmUgY29tcGxpY2F0ZWQg
dGhhbiBmaW5kaW5nIGEgc2ltcGxlIHNvbHV0aW9uIGZvciBzcGxpdHRpbmcgdGhlIGludGVnZXIg
SUQgc3BhY2UgYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgc3BhY2UuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaW08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+LS0mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25z
b2xhcztjb2xvcjpibGFjayI+Q2lzY28gU3lzdGVtcyBDYW5hZGEgQ28uPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y
OmJsYWNrIj4yMDAwIElubm92YXRpb24gRHJpdmU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkthbmF0
YSwgT04sIENhbmFkYSwgSzJLIDNFODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UHJlZmVyZW5jZXMg
Jmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmliZS8/c2lkPTAw
MDQ3ODMyNiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmh0dHA6Ly93d3cuY2lzY28uY29tL29m
ZmVyL3N1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNjwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv
cjpibGFjayI+VW5zdWJzY3JpYmUgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL29m
ZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+
aHR0cDovL3d3dy5jaXNjby5jb20vb2ZmZXIvdW5zdWJzY3JpYmUvP3NpZD0wMDA0NzgzMjc8L3Nw
YW4+PC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlByaXZhY3kgJmx0OzxhIGhyZWY9Imh0
dHA6Ly93d3cuY2lzY28uY29tL3dlYi9zaXRlYXNzZXRzL2xlZ2FsL3ByaXZhY3kuaHRtbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsdWUiPmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9zaXRlYXNzZXRz
L2xlZ2FsL3ByaXZhY3kuaHRtbDwvc3Bhbj48L2E+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_df6e2364f58a47178cf2a4fd0d47512cXCHRTP013ciscocom_--


From nobody Tue Nov 14 07:41:31 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C21128B44 for ; Tue, 14 Nov 2017 07:41:29 -0800 (PST)
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 UpOnaHSRWXgN for ; Tue, 14 Nov 2017 07:41:25 -0800 (PST)
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 2EC6C124D37 for ; Tue, 14 Nov 2017 07:41:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B8EAF1406789; Tue, 14 Nov 2017 16:41:22 +0100 (CET)
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 ieSLlt6HUcVq; Tue, 14 Nov 2017 16:41:22 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 86E64140678A; Tue, 14 Nov 2017 16:41:22 +0100 (CET)
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 9bVh3jDNIev9; Tue, 14 Nov 2017 16:41:22 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 52E7A1406786; Tue, 14 Nov 2017 16:41:22 +0100 (CET)
To: Robert Wilton , Netconf 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>   <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>
From: Vladimir Vassilev 
Message-ID: 
Date: Tue, 14 Nov 2017 16:41:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 15:41:29 -0000

On 11/13/2017 04:27 PM, Robert Wilton wrote:
>
> Hi Vladimir,
>
>
> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>
>>
>>
>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>
>>>
>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton >> > wrote:
>>>
>>>     Hi Andy,
>>>
>>>     The NMDA datastore draft
>>>     (draft-ietf-netmod-revised-datastores-06) mandates two
>>>     constraints that must apply:
>>>
>>>     (1) All conventional datastores must have exactly the same
>>>     schema.=C2=A0 Hence differences in deviations or features are all=
owed
>>>     between these datastores. (sec 5.1, first paragraph)
>>>
>>>     (2) The schema for operational must be a superset of all
>>>     configuration datatstores, but that data nodes may be omitted
>>>     (sec 5.3, third paragraph).
>>>
>>>
>>>     This implies that only the following differences between
>>>     datastores are allowed:
>>>     =C2=A0(i) a feature can be disabled in conventional (and/or dynam=
ic
>>>     configuration datastores), but enabled in operational (e.g. for
>>>     configurable router-id).
>>>
>>>     =C2=A0(ii) deviations apply in all datastores, except that
>>>     =C2=A0 a) a deviation can remove nodes in the conventional datast=
ores
>>>     (if they were not configurable, like the feature example)
>>>     =C2=A0 b) a deviation can remove nodes in a dynamic datastore (e.=
g.
>>>     like I2RS)
>>>     =C2=A0 c) a deviation can remove nodes from operational only if a
>>>     server is unable to accurately report them.
>>>
>>>     (iii) modules exist in all datastores, except:
>>>     =C2=A0 a) a module can be omitted from conventional datastores (e=
.g.
>>>     if the module is not configurable)
>>>     =C2=A0 b) a module can be omitted from a dynamic datastore (e.g. =
like
>>>     I2RS)
>>>     =C2=A0 c) a module can be omitted from operational only if a serv=
er
>>>     is unable to accurately report the data nodes within the module.
>>>
>>>
>>>
>>> I am not convinced that moving to a datastore-centric conformance=20
>>> model instead of server-centric
>>> is a good idea.
>> +1
>> IMO yang-library:1.1 can and should be optional. As a first step NMDA=20
>> modules and the minimal protocol support  etc. can be=20
>> implemented without yang-library 1.0 to 1.1 transition (read=20
>> server-centric to datastore-centric conformance model transition).=20
>> draft-ietf-netconf-nmda-netconf-01.txt requires migration to=20
>> yang-library:1.1. I do not see good argument to support this=20
>> limitation and there are usecases that can benefit from NMDA with=20
>> uniform datastore model design.
>
> YANG library bis is the mechanism to indicate which datastores are=20
> available to the client.=C2=A0 E.g. a NMDA compatible client would atte=
mpt=20
> to read YANG library bis on the new path using the  RPC to=20
> determine whether NMDA is supported, and what datastores are supported.
>
> The existing module-state path in YANG library is preserved, but=20
> marked as deprecated, so the intention is that it can be made=20
> backwards compatible to clients.
I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library=20
Capability'=C2=A0 states exactly that. IMO this text can be changed and a=
llow=20
the case described above ( implementation with NMDA modules=20
implemented as indicated by yang-library:1.0 uniform model applying to=20
all datastores. For cases where the datastores do not have common model=20
yang-library:1.1 should still be mandatory). In other words if=20
yang-library:1.0 shows implemented ietf-netconf-datastores =20
and NMDA modules listed as implemented will not need yang-library:1.1=20
implementation which takes one obstacle out of the way to rolling NMDA=20
module implementations.

Is there an argument making the proposed change unreasonable?

Vladimir

>
> Thanks,
> Rob
>
>>> =C2=A0I get it that it is supposed to allow the server to accurately=20
>>> reflect its implementation,
>>> but it actually says that servers MAY implement whatever partial=20
>>> subset of a module they want,
>>> and a client MUST deal with the mess.
>>>
>>> IMO, YANG says that features and deviations are server-wide, not=20
>>> per-datastore.
>>> This new complexity is non-trivial to implement, so it may not be=20
>>> widely supported.
>>>
>>> The WG seems confused about the difference between a conformance=20
>>> model and capabilities reporting.
>>> (ii)(c) and (iii)(c) is about reporting, not conformance.=C2=A0 There=
 is=20
>>> still no way to express
>>> trivial use-cases in the conformance model such as "this module is=20
>>> intended for the I2RS ephemeral datastore only"
>>>
>>>
>>>     Changing the type of a node between datastores, or changing its
>>>     properties is not allowed.=C2=A0 The only difference allowed betw=
een
>>>     data nodes in different datastores is the nodes existence.
>>>
>>>     These rules seem more restrictive that what a server using split
>>>     config state trees (IETF style, or OpenConfig style) can achieve
>>>     using deviations today.
>>>
>>>
>>>
>>> Lots of rules to enforce actually makes the code harder, not easier.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>     On 09/11/2017 19:33, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     The new structure still has the same problems for the client as
>>>>     before.
>>>>     It is a major change in the architecture to have different
>>>>     schema trees per datastore instead of per-server.
>>>>     The server is allowed to have different features and deviations
>>>>     for the same objects.
>>>>     The client is completely on its own trying to compare
>>>>      to anything
>>>>     if the schema trees are different
>>>>
>>>>     =C2=A0 container foo {
>>>>     =C2=A0 =C2=A0 leaf bar {
>>>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;
>>>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>>>>     =C2=A0 =C2=A0 }
>>>>     =C2=A0 =C2=A0 leaf baz {
>>>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X";
>>>>     =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
>>>>     =C2=A0 =C2=A0 }
>>>>     =C2=A0}
>>>>
>>>>     How does the client compare  to  if the
>>>>     features do not match?
>>>>     If the server deviates the leaf (e.g. change type string to
>>>>     int32) how does the client
>>>>     compare the values?
>>>>
>>>>     This new complexity would be mandatory for the client to
>>>>     support in some proprietary
>>>>     manner since the NMDA standard ignores these problems.
>>>>
>>>>     NMDA was supposed to be simpler because the client could
>>>>     compare intended
>>>>     and applied values using the same object path. openconfig
>>>>     required a data
>>>>     model change and a trivial name-mapping. In reality, NMDA
>>>>     is far more disruptive to existing implementations.
>>>>
>>>>
>>>>     Andy
>>>>
>>>>
>>>>
>>>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>     > wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         Given some of the feedback related to the complexity of the
>>>>         YANG library bis structure, we have come up with two other
>>>>         possible structures for the YANG library data:
>>>>
>>>>         (1) A simplified structure to make YANG library meet the
>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>         library structure, and arguably simpler.
>>>>         (2) An enhanced version of the structure (1) above, that is
>>>>         also extended to allow the structure to be reused for
>>>>         schema-mount via an augmentation.
>>>>
>>>>         For reference, at the end of this email, I have also
>>>>         included the tree diagram of the existing YANG library, and
>>>>         the current YANG library bis draft
>>>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>>>
>>>>         Considering the two new YANG library structures:
>>>>
>>>>         ------------------------
>>>>
>>>>         *(1) A simplified structure to make YANG library meet the
>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>         library structure.*
>>>>
>>>>         The main changes are:
>>>>         (i) Split "implemented modules" and "import-only-modules"
>>>>         into two separate lists, making the most important list
>>>>         (i.e. implemented modules) keyed by module name only and
>>>>         hence easier to reference.
>>>>         (ii) Assume modules are implemented in all datastores by
>>>>         default (with a "not-implemented-in" leaflist of datastores
>>>>         that a module is not implemented in).
>>>>         (iii) Assume that features are implemented in all
>>>>         datastores by default (with a "not-implemented-in" leaflist
>>>>         of datastores that a feature is not implemented in).
>>>>         (iv) Deleted module-sets.
>>>>         (v) Datastores are now just a list of supported datastores
>>>>         (that could potentially be extended with further per
>>>>         datastore properties in future).
>>>>
>>>>         Manually generated tree output for proposed YANG library:
>>>>
>>>>         module: ietf-yang-library
>>>>         =C2=A0+--ro yang-library
>>>>         =C2=A0=C2=A0=C2=A0 +--ro modules
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-iden=
tifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 revision-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=
=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 | -> /yang-library/datast=
ore/name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-impleme=
nted-in*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 | -> /yang-library/datast=
ore/name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 | -> ../name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name r=
evision]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang=
:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 ine=
t:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule=
* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifie=
r
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro revision yang:revision-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future =
per datastore
>>>>         properties.
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name identityref
>>>>         =C2=A0=C2=A0=C2=A0 +--ro checksum string
>>>>
>>>>         ------------------------------
>>>>
>>>>         *(2) An enhanced version of the structure (1) above, that
>>>>         is extended to allow the structure to be reused for
>>>>         schema-mount via an augmentation.*
>>>>
>>>>         This is similar to the structure above, except that the
>>>>         "the set of modules" is contained in a list of named schema
>>>>         (e.g. similar to the schema mount draft), allowing this
>>>>         structure to be re-used for schema mount.
>>>>
>>>>         Schema mount would be expected to augment yang-library to
>>>>         add in the additional schema mount information.=C2=A0 In the
>>>>         tree diagram, I have shown the schema-mount mount-point
>>>>         augmentation, but not including namespaces yet.
>>>>
>>>>         Every server would be required to provide at least one
>>>>         schema in the schema list, and the primary schema for the
>>>>         device would always be given the name "primary".
>>>>
>>>>         module: ietf-yang-library
>>>>         =C2=A0+--ro yang-library
>>>>         =C2=A0=C2=A0=C2=A0 +--ro schema* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name string
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum string
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-iden=
tifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:revi=
sion-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=
=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 | -> /yang-library/datast=
ore/name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-impleme=
nted-in*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 | -> /yang-library/datast=
ore/name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 | -> ../name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-poi=
nt* [label]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro l=
abel=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro c=
onfig?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (=
schema-ref)
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 | +--:(inline)
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 | +--:(use-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=C2=A0=C2=A0 +--ro use-schema* [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=C2=A0 +--ro name
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 -> /yang-library/schema/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=C2=A0 +--ro parent-reference* yan=
g:xpath1.0
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name r=
evision]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang=
:yang-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 ine=
t:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule=
* [name]
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifie=
r
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro revision yang:revision-identifier
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>         =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future =
per datastore
>>>>         properties.
>>>>         =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name identityref
>>>>         =C2=A0=C2=A0=C2=A0 +--ro checksum string
>>>>
>>>>         Please can you provide comments on these structures, in
>>>>         particular:
>>>>
>>>>         Is this version better (i.e. simpler) that the version
>>>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>>
>>>>         Should we try and make the structure extensible for
>>>>         schema-mount via augmentation (i.e. version (2)), or is it
>>>>         better that schema-mount has its own separate subtree?
>>>>
>>>>         For reference only I have included the existing YANG
>>>>         library and YANG library bis draft tree diagrams.
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>         -----------------------------
>>>>
>>>>         *** FOR REFERENCE ONLY ***
>>>>
>>>>         (3)=C2=A0 The current YANG library structure in YANG library=
 bis
>>>>         (draft-ietf-netconf-rfc7895bis-02)
>>>>
>>>>             module: ietf-yang-library
>>>>                 +--ro yang-library
>>>>                    +--ro modules
>>>>                    |  +--ro module* [id]
>>>>                    |     +--ro id                  string
>>>>                    |     +--ro name                yang:yang-identif=
ier
>>>>                    |     +--ro revision?           revision-identifi=
er
>>>>                    |     +--ro schema?             inet:uri
>>>>                    |     +--ro namespace           inet:uri
>>>>                    |     +--ro feature*            yang:yang-identif=
ier
>>>>                    |     +--ro deviation* [module]
>>>>                    |     |  +--ro module    -> ../../id
>>>>                    |     +--ro conformance-type    enumeration
>>>>                    |     +--ro submodule* [name]
>>>>                    |        +--ro name        yang:yang-identifier
>>>>                    |        +--ro revision?   revision-identifier
>>>>                    |        +--ro schema?     inet:uri
>>>>                    +--ro module-sets
>>>>                    |  +--ro module-set* [id]
>>>>                    |     +--ro id        string
>>>>                    |     +--ro module*   -> ../../../modules/module/=
id
>>>>                    +--ro datastores
>>>>                    |  +--ro datastore* [name]
>>>>                    |     +--ro name          identityref
>>>>                    |     +--ro module-set
>>>>                    |             -> ../../../module-sets/module-set/=
id
>>>>                    +--ro checksum       string
>>>>
>>>>         -----------------------------
>>>>
>>>>         *** FOR REFERENCE ONLY ***
>>>>
>>>>         (4)=C2=A0 The current YANG library structure (RFC 7895)
>>>>
>>>>                +--ro modules-state
>>>>                   +--ro module-set-id    string
>>>>                   +--ro module* [name revision]
>>>>                      +--ro name                yang:yang-identifier
>>>>                      +--ro revision            union
>>>>                      +--ro schema?             inet:uri
>>>>                      +--ro namespace           inet:uri
>>>>                      +--ro feature*            yang:yang-identifier
>>>>                      +--ro deviation* [name revision]
>>>>                      |  +--ro name        yang:yang-identifier
>>>>                      |  +--ro revision    union
>>>>                      +--ro conformance-type    enumeration
>>>>                      +--ro submodule* [name revision]
>>>>                         +--ro name        yang:yang-identifier
>>>>                         +--ro revision    union
>>>>                         +--ro schema?     inet:uri
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>


From nobody Tue Nov 14 16:06:36 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F555126BFD for ; Tue, 14 Nov 2017 16:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0nrFwuY3fTx for ; Tue, 14 Nov 2017 16:06:33 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB2F124E15 for ; Tue, 14 Nov 2017 16:06:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22739; q=dns/txt; s=iport; t=1510704392; x=1511913992; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eQo1Jyy7loLtJH/9kMiAoUl/Bv3UPHLqD5CYc23SW9M=; b=W0j3XmvvsQrqDxUoelxmzcZYHULjNTz/dq/mXTCUvTpyqsGb5+HBMtgc 0lt9WWz7VCmR/F4gL5a5Xgtis6Ei+36wBebQjCHYPhSe/V8W48FhRtdUY YO8b5sNIon6Qbdmea1/HxgeTiLXvB9AoNRLFHTEBUFqD0y5qn3yf1Xpnp g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AACShAta/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4ng36KH48xgX2WVxCBfgMKGAuESU8ChQE/GAEBAQEBAQE?= =?us-ascii?q?BAWsohR4BAQEBAgEBARgJBAsBBTYbCQISBgICIwMCAicfAw4GAQwGAgEBihcIE?= =?us-ascii?q?I0dnWiBbTqLFQEBAQEBAQEBAQEBAQEBAQEBAQEaBYEPgiWCB4FVgWkpgwGEZQE?= =?us-ascii?q?SAQmDK4JjBYoyhz2BE48ylQaCFYYIg2AkhyGOOIdzgTkfOIEDcDQhCB0VSYJkh?= =?us-ascii?q?Gw0NoY1gjUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,397,1505779200"; d="scan'208";a="102755957"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 00:06:31 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAF06TLq015196; Wed, 15 Nov 2017 00:06:30 GMT
To: Vladimir Vassilev , Netconf 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>   <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Wed, 15 Nov 2017 08:06:28 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 00:06:35 -0000

On 14/11/2017 23:41, Vladimir Vassilev wrote:
>
>
> On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>
>> Hi Vladimir,
>>
>>
>> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>>
>>>
>>>
>>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>>
>>>>
>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton >>> > wrote:
>>>>
>>>>     Hi Andy,
>>>>
>>>>     The NMDA datastore draft
>>>>     (draft-ietf-netmod-revised-datastores-06) mandates two
>>>>     constraints that must apply:
>>>>
>>>>     (1) All conventional datastores must have exactly the same
>>>>     schema.  Hence differences in deviations or features are allowed
>>>>     between these datastores. (sec 5.1, first paragraph)
>>>>
>>>>     (2) The schema for operational must be a superset of all
>>>>     configuration datatstores, but that data nodes may be omitted
>>>>     (sec 5.3, third paragraph).
>>>>
>>>>
>>>>     This implies that only the following differences between
>>>>     datastores are allowed:
>>>>      (i) a feature can be disabled in conventional (and/or dynamic
>>>>     configuration datastores), but enabled in operational (e.g. for
>>>>     configurable router-id).
>>>>
>>>>      (ii) deviations apply in all datastores, except that
>>>>       a) a deviation can remove nodes in the conventional datastores
>>>>     (if they were not configurable, like the feature example)
>>>>       b) a deviation can remove nodes in a dynamic datastore (e.g.
>>>>     like I2RS)
>>>>       c) a deviation can remove nodes from operational only if a
>>>>     server is unable to accurately report them.
>>>>
>>>>     (iii) modules exist in all datastores, except:
>>>>       a) a module can be omitted from conventional datastores (e.g.
>>>>     if the module is not configurable)
>>>>       b) a module can be omitted from a dynamic datastore (e.g. like
>>>>     I2RS)
>>>>       c) a module can be omitted from operational only if a server
>>>>     is unable to accurately report the data nodes within the module.
>>>>
>>>>
>>>>
>>>> I am not convinced that moving to a datastore-centric conformance 
>>>> model instead of server-centric
>>>> is a good idea.
>>> +1
>>> IMO yang-library:1.1 can and should be optional. As a first step 
>>> NMDA modules and the minimal protocol support  etc. can be 
>>> implemented without yang-library 1.0 to 1.1 transition (read 
>>> server-centric to datastore-centric conformance model transition). 
>>> draft-ietf-netconf-nmda-netconf-01.txt requires migration to 
>>> yang-library:1.1. I do not see good argument to support this 
>>> limitation and there are usecases that can benefit from NMDA with 
>>> uniform datastore model design.
>>
>> YANG library bis is the mechanism to indicate which datastores are 
>> available to the client.  E.g. a NMDA compatible client would attempt 
>> to read YANG library bis on the new path using the  RPC to 
>> determine whether NMDA is supported, and what datastores are supported.
>>
>> The existing module-state path in YANG library is preserved, but 
>> marked as deprecated, so the intention is that it can be made 
>> backwards compatible to clients.
> I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library 
> Capability'  states exactly that. IMO this text can be changed and 
> allow the case described above ( implementation with NMDA 
> modules implemented as indicated by yang-library:1.0 uniform model 
> applying to all datastores. For cases where the datastores do not have 
> common model yang-library:1.1 should still be mandatory). In other 
> words if yang-library:1.0 shows implemented ietf-netconf-datastores 
>  and NMDA modules listed as implemented will not need 
> yang-library:1.1 implementation which takes one obstacle out of the 
> way to rolling NMDA module implementations.
>
> Is there an argument making the proposed change unreasonable?
Yes, I think so.

In an NMDA implementation, the YANG library information reported in the 
new structure can be entirely accurate.  I.e. it can report which 
modules are available in which datastores.

Of course, it is not possible to represent this in the old YANG library, 
so the information that a NMDA server provides via the old YANG library 
could be inaccurate.  I.e. I think that it has to report all modules and 
deviations as being reported in all datastores.

Hence the only way that a client would be able to know that it is 
talking to an NMDA server with modules not implemented in some 
datastores, or with deviations in some datastores would be for it to 
query the new YANG library path.  The new YANG library structures that 
we are proposing below are intended to be easier for a client to 
determine this, e.g. by checking whether any of the "not-implemented-in" 
leaf-lists are populated.

So the aim for keeping the old YANG library path is to inter-operate 
with old clients that don't know about NMDA, and hence would not be 
expected to use the  or  RPCs.

Thanks,
Rob


>
> Vladimir
>
>>
>> Thanks,
>> Rob
>>
>>>>  I get it that it is supposed to allow the server to accurately 
>>>> reflect its implementation,
>>>> but it actually says that servers MAY implement whatever partial 
>>>> subset of a module they want,
>>>> and a client MUST deal with the mess.
>>>>
>>>> IMO, YANG says that features and deviations are server-wide, not 
>>>> per-datastore.
>>>> This new complexity is non-trivial to implement, so it may not be 
>>>> widely supported.
>>>>
>>>> The WG seems confused about the difference between a conformance 
>>>> model and capabilities reporting.
>>>> (ii)(c) and (iii)(c) is about reporting, not conformance. There is 
>>>> still no way to express
>>>> trivial use-cases in the conformance model such as "this module is 
>>>> intended for the I2RS ephemeral datastore only"
>>>>
>>>>
>>>>     Changing the type of a node between datastores, or changing its
>>>>     properties is not allowed.  The only difference allowed between
>>>>     data nodes in different datastores is the nodes existence.
>>>>
>>>>     These rules seem more restrictive that what a server using split
>>>>     config state trees (IETF style, or OpenConfig style) can achieve
>>>>     using deviations today.
>>>>
>>>>
>>>>
>>>> Lots of rules to enforce actually makes the code harder, not easier.
>>>>
>>>>     Thanks,
>>>>     Rob
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>     On 09/11/2017 19:33, Andy Bierman wrote:
>>>>>     Hi,
>>>>>
>>>>>     The new structure still has the same problems for the client as
>>>>>     before.
>>>>>     It is a major change in the architecture to have different
>>>>>     schema trees per datastore instead of per-server.
>>>>>     The server is allowed to have different features and deviations
>>>>>     for the same objects.
>>>>>     The client is completely on its own trying to compare
>>>>>      to anything
>>>>>     if the schema trees are different
>>>>>
>>>>>       container foo {
>>>>>         leaf bar {
>>>>>            if-feature X;
>>>>>            type string;
>>>>>         }
>>>>>         leaf baz {
>>>>>            if-feature "not X";
>>>>>            type string;
>>>>>         }
>>>>>      }
>>>>>
>>>>>     How does the client compare  to  if the
>>>>>     features do not match?
>>>>>     If the server deviates the leaf (e.g. change type string to
>>>>>     int32) how does the client
>>>>>     compare the values?
>>>>>
>>>>>     This new complexity would be mandatory for the client to
>>>>>     support in some proprietary
>>>>>     manner since the NMDA standard ignores these problems.
>>>>>
>>>>>     NMDA was supposed to be simpler because the client could
>>>>>     compare intended
>>>>>     and applied values using the same object path. openconfig
>>>>>     required a data
>>>>>     model change and a trivial name-mapping. In reality, NMDA
>>>>>     is far more disruptive to existing implementations.
>>>>>
>>>>>
>>>>>     Andy
>>>>>
>>>>>
>>>>>
>>>>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>>     > wrote:
>>>>>
>>>>>         Hi,
>>>>>
>>>>>         Given some of the feedback related to the complexity of the
>>>>>         YANG library bis structure, we have come up with two other
>>>>>         possible structures for the YANG library data:
>>>>>
>>>>>         (1) A simplified structure to make YANG library meet the
>>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>>         library structure, and arguably simpler.
>>>>>         (2) An enhanced version of the structure (1) above, that is
>>>>>         also extended to allow the structure to be reused for
>>>>>         schema-mount via an augmentation.
>>>>>
>>>>>         For reference, at the end of this email, I have also
>>>>>         included the tree diagram of the existing YANG library, and
>>>>>         the current YANG library bis draft
>>>>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>>>>
>>>>>         Considering the two new YANG library structures:
>>>>>
>>>>>         ------------------------
>>>>>
>>>>>         *(1) A simplified structure to make YANG library meet the
>>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>>         library structure.*
>>>>>
>>>>>         The main changes are:
>>>>>         (i) Split "implemented modules" and "import-only-modules"
>>>>>         into two separate lists, making the most important list
>>>>>         (i.e. implemented modules) keyed by module name only and
>>>>>         hence easier to reference.
>>>>>         (ii) Assume modules are implemented in all datastores by
>>>>>         default (with a "not-implemented-in" leaflist of datastores
>>>>>         that a module is not implemented in).
>>>>>         (iii) Assume that features are implemented in all
>>>>>         datastores by default (with a "not-implemented-in" leaflist
>>>>>         of datastores that a feature is not implemented in).
>>>>>         (iv) Deleted module-sets.
>>>>>         (v) Datastores are now just a list of supported datastores
>>>>>         (that could potentially be extended with further per
>>>>>         datastore properties in future).
>>>>>
>>>>>         Manually generated tree output for proposed YANG library:
>>>>>
>>>>>         module: ietf-yang-library
>>>>>          +--ro yang-library
>>>>>             +--ro modules
>>>>>             |  +--ro module* [name]
>>>>>             |  |  +--ro name yang:yang-identifier
>>>>>             |  |  +--ro revision?      revision-identifier
>>>>>             |  |  +--ro schema?        inet:uri
>>>>>             |  |  +--ro namespace      inet:uri
>>>>>             |  |  +--ro submodule* [name]
>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>>             |  |  |  +--ro schema?     inet:uri
>>>>>             |  |  +--ro not-implemented-in*
>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>             |  |  +--ro feature* [name]
>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>             |  |  |  +--ro not-implemented-in*
>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>             |  |  +--ro deviation*
>>>>>             |  | -> ../name
>>>>>             |  |
>>>>>             |  +--ro import-only-module* [name revision]
>>>>>             |     +--ro name yang:yang-identifier
>>>>>             |     +--ro revision            union
>>>>>             |     +--ro schema?             inet:uri
>>>>>             |     +--ro namespace           inet:uri
>>>>>             |     +--ro submodule* [name]
>>>>>             |        +--ro name yang:yang-identifier
>>>>>             |        +--ro revision yang:revision-identifier
>>>>>             |        +--ro schema?     inet:uri
>>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>>         properties.
>>>>>             |  +--ro name identityref
>>>>>             +--ro checksum string
>>>>>
>>>>>         ------------------------------
>>>>>
>>>>>         *(2) An enhanced version of the structure (1) above, that
>>>>>         is extended to allow the structure to be reused for
>>>>>         schema-mount via an augmentation.*
>>>>>
>>>>>         This is similar to the structure above, except that the
>>>>>         "the set of modules" is contained in a list of named schema
>>>>>         (e.g. similar to the schema mount draft), allowing this
>>>>>         structure to be re-used for schema mount.
>>>>>
>>>>>         Schema mount would be expected to augment yang-library to
>>>>>         add in the additional schema mount information. In the
>>>>>         tree diagram, I have shown the schema-mount mount-point
>>>>>         augmentation, but not including namespaces yet.
>>>>>
>>>>>         Every server would be required to provide at least one
>>>>>         schema in the schema list, and the primary schema for the
>>>>>         device would always be given the name "primary".
>>>>>
>>>>>         module: ietf-yang-library
>>>>>          +--ro yang-library
>>>>>             +--ro schema* [name]
>>>>>             |  +--ro name string
>>>>>             |  +--ro checksum string
>>>>>             |  +--ro module* [name]
>>>>>             |  |  +--ro name yang:yang-identifier
>>>>>             |  |  +--ro revision? yang:revision-identifier
>>>>>             |  |  +--ro schema?        inet:uri
>>>>>             |  |  +--ro namespace      inet:uri
>>>>>             |  |  +--ro submodule* [name]
>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>>             |  |  |  +--ro schema?     inet:uri
>>>>>             |  |  +--ro not-implemented-in*
>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>             |  |  +--ro feature* [name]
>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>             |  |  |  +--ro not-implemented-in*
>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>             |  |  +--ro deviation*
>>>>>             |  |  | -> ../name
>>>>>             |  |  +- schema-mount:mount-point* [label]
>>>>>             |  |     +--ro label yang:yang-identifier
>>>>>             |  |     +--ro config?       boolean
>>>>>             |  |     +--ro (schema-ref)
>>>>>             |  | +--:(inline)
>>>>>             |  |        |  +--ro inline?       empty
>>>>>             |  | +--:(use-schema)
>>>>>             |  |           +--ro use-schema* [name]
>>>>>             |  |              +--ro name
>>>>>             |  | |       -> /yang-library/schema/name
>>>>>             |  |              +--ro parent-reference* yang:xpath1.0
>>>>>             |  |
>>>>>             |  +--ro import-only-module* [name revision]
>>>>>             |     +--ro name yang:yang-identifier
>>>>>             |     +--ro revision            union
>>>>>             |     +--ro schema?             inet:uri
>>>>>             |     +--ro namespace           inet:uri
>>>>>             |     +--ro submodule* [name]
>>>>>             |        +--ro name yang:yang-identifier
>>>>>             |        +--ro revision yang:revision-identifier
>>>>>             |        +--ro schema?     inet:uri
>>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>>         properties.
>>>>>             |  +--ro name identityref
>>>>>             +--ro checksum string
>>>>>
>>>>>         Please can you provide comments on these structures, in
>>>>>         particular:
>>>>>
>>>>>         Is this version better (i.e. simpler) that the version
>>>>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>>>
>>>>>         Should we try and make the structure extensible for
>>>>>         schema-mount via augmentation (i.e. version (2)), or is it
>>>>>         better that schema-mount has its own separate subtree?
>>>>>
>>>>>         For reference only I have included the existing YANG
>>>>>         library and YANG library bis draft tree diagrams.
>>>>>
>>>>>         Thanks,
>>>>>         Rob
>>>>>
>>>>>
>>>>>         -----------------------------
>>>>>
>>>>>         *** FOR REFERENCE ONLY ***
>>>>>
>>>>>         (3)  The current YANG library structure in YANG library bis
>>>>>         (draft-ietf-netconf-rfc7895bis-02)
>>>>>
>>>>>             module: ietf-yang-library
>>>>>                 +--ro yang-library
>>>>>                    +--ro modules
>>>>>                    |  +--ro module* [id]
>>>>>                    |     +--ro id                  string
>>>>>                    |     +--ro name yang:yang-identifier
>>>>>                    |     +--ro revision? revision-identifier
>>>>>                    |     +--ro schema? inet:uri
>>>>>                    |     +--ro namespace inet:uri
>>>>>                    |     +--ro feature* yang:yang-identifier
>>>>>                    |     +--ro deviation* [module]
>>>>>                    |     |  +--ro module    -> ../../id
>>>>>                    |     +--ro conformance-type enumeration
>>>>>                    |     +--ro submodule* [name]
>>>>>                    |        +--ro name yang:yang-identifier
>>>>>                    |        +--ro revision? revision-identifier
>>>>>                    |        +--ro schema?     inet:uri
>>>>>                    +--ro module-sets
>>>>>                    |  +--ro module-set* [id]
>>>>>                    |     +--ro id        string
>>>>>                    |     +--ro module*   -> 
>>>>> ../../../modules/module/id
>>>>>                    +--ro datastores
>>>>>                    |  +--ro datastore* [name]
>>>>>                    |     +--ro name          identityref
>>>>>                    |     +--ro module-set
>>>>>                    |             -> 
>>>>> ../../../module-sets/module-set/id
>>>>>                    +--ro checksum       string
>>>>>
>>>>>         -----------------------------
>>>>>
>>>>>         *** FOR REFERENCE ONLY ***
>>>>>
>>>>>         (4)  The current YANG library structure (RFC 7895)
>>>>>
>>>>>                +--ro modules-state
>>>>>                   +--ro module-set-id    string
>>>>>                   +--ro module* [name revision]
>>>>>                      +--ro name yang:yang-identifier
>>>>>                      +--ro revision            union
>>>>>                      +--ro schema?             inet:uri
>>>>>                      +--ro namespace           inet:uri
>>>>>                      +--ro feature* yang:yang-identifier
>>>>>                      +--ro deviation* [name revision]
>>>>>                      |  +--ro name yang:yang-identifier
>>>>>                      |  +--ro revision    union
>>>>>                      +--ro conformance-type    enumeration
>>>>>                      +--ro submodule* [name revision]
>>>>>                         +--ro name yang:yang-identifier
>>>>>                         +--ro revision    union
>>>>>                         +--ro schema?     inet:uri
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> .
>


From nobody Tue Nov 14 16:31:19 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEED81286C7 for ; Tue, 14 Nov 2017 16:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BHJLA7ThPxg for ; Tue, 14 Nov 2017 16:31:15 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0751250B8 for ; Tue, 14 Nov 2017 16:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24531; q=dns/txt; s=iport; t=1510705875; x=1511915475; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=14cR02rdBkdSMrlopDqDhZ1zgleCg+RDg1dm3IWmdVM=; b=IwEWt43Wm7qKmtzXQYojvthYqo1dMGuMQy3/9OkeNZ8rO6fK0Usp1dYZ hVUUIgUp8HUUzsP/aNOK4QeAIQ+jll5Dctl11ohBey0p0705a8eVbFKs8 2PgHgXEI2KaWFOsOssxdC4Ng2vH0Lco+IhggFYGnVwNMOHt6L+0WJSIzZ g=;
X-IronPort-AV: E=Sophos;i="5.44,397,1505779200";  d="scan'208,217";a="102762347"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 00:31:14 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAF0VDbr025609; Wed, 15 Nov 2017 00:31:13 GMT
To: "Eric Voit (evoit)" , "netconf@ietf.org" 
References: <72EC9947-3A3B-425A-A5D7-93D1D1C6778E@cisco.com> 
From: Robert Wilton 
Message-ID: <1515b54b-796d-a3c5-897f-8a2975018d25@cisco.com>
Date: Wed, 15 Nov 2017 08:31:12 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9536FC8CB05AF61840B4FAB6"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 00:31:18 -0000

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

Hi Eric,

Does this mean that the configured-subscriptions and subscriptions tree 
will be combined into a single tree (NMDA style)?

Thanks,
Rob


On 14/11/2017 16:40, Eric Voit (evoit) wrote:
>
> After lots of interactions and good discussion, a majority of people 
> have expressed a desire for integer over string for the identification 
> of configured subscriptions.  Based on that I am closing the issue 
> SN#6 with no changes to the yang model.
>
> https://github.com/netconf-wg/rfc5277bis/issues/6
>
> Eric
>
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Tim 
> Jenkins (timjenki)
> *Sent:* Monday, October 23, 2017 2:49 PM
> *To:* netconf@ietf.org
> *Subject:* Re: [Netconf] SN #6 String or Integer for Subscription ID
>
> All,
>
> This note attempts to take a detailed look at the two main proposals 
> for the use of subscription IDs for the subscribed notifications draft.
>
> The two proposals that I'll examine here are 'single integer ID type' 
> and 'mixed ID type' as I'm referring to them. Proposals where the 
> update notifications are different from configured subscriptions and 
> dynamic subscriptions are not considered, since that is highly 
> undesirable and more complex.
>
> In the 'single integer ID type' proposal, the subscription records in 
> both the configuration and operational tables of subscriptions are 
> indexed by a 32-bit integer value. Since configured subscriptions also 
> appear in the operational table, the index space is common between 
> configured and operational subscriptions. Subscribers create the 
> configured subscription IDs, while the publisher creates the dynamic 
> subscription IDs. Thus, there is an issue of potential conflict; it 
> has been proposed to split the space between subcriber and publisher 
> generated to remove this potential conflict.
>
> In the 'mixed ID type' proposal, configured subscriptions are created 
> with a string ID by the subscriber, and dynamic subscriptions are 
> created with a 32-bit integer ID by the publisher. The publisher also 
> creates a 32-bit integer ID for configured subscriptions, so they 
> effectively have two IDs. These are referred to as the subscriber and 
> publish IDs for the rest of this note. The configured subscriptions 
> table is indexed by the subscriber ID and the publisher ID does not 
> appear in this table because it is not configuration data. The 
> operational subscriptions table is indexed by the publisher ID and the 
> subscriber ID appears in this table, but only for configured 
> subscription entries.
>
> I will attempt to evaluate the two proposals against some issues.
>
> 1/ How a receiver identifies which subscription an update 
> notification's contents are associated with.
>
> 'single integer ID'               -uses only ID available, but can use 
> the ID in the 'subscription-started' notification as well
>
> 'mixed IDs'                            -learns subscriber and 
> publisher IDs from 'subscription-started' notification. This 
> notification has to be modified to carry it, and receivers have to 
> parse it.
>
> 2/ How the issue of multiple sources of ID generation is handled.
>
> 'single integer ID'               -split the 32-bit integer space for 
> issue between publisher and subscribers; this does not solve issue 
> among multiple subscribers
>
> 'mixed IDs'                           -not an issue between publisher 
> and subscribers; but does not solve issue among multiple subscribers
>
> 3/ How subscriptions are associated across multiple publishers. That 
> is, how do separate receivers know which subscriptions are considered 
> to be the same when they arrive from different publishers?
>
> 'single integer ID'               -subscriber sends to receivers the 
> IDs it used to create the subscriptions; it should have used the same 
> ID for the same subscriptions on separate publishers
>
> 'mixed IDs'                           -subscriber sends to receivers 
> the IDs it used to create the subscriptions; it should have used the 
> same ID for the same subscriptions on separate publishers. The 
> receivers must parse the 'subscription-started' notifications from 
> publishers and create and maintain a map of integers IDs to text IDs. 
> This map must be used with update notifications, to determine the 
> actual subscription ID of interest.
>
> 4/ How human readable information about the subscriptions is provided.
>
> 'single integer ID'               -an unrestricted text field can be 
> added to subscriptions as needed. The addition of an unrestricted text 
> field can be done for both configured and dynamic subscriptions if 
> desired and makes the need for a text ID string unnecessary.
>
> 'mixed IDs'                           -the string ID used is limited: 
> configured subscriptions only, and must be able to be a key
>
> Additional Notes:
>
> Integer ID Space Split: For the single integer ID case, this is a very 
> simple solution to the problem. As currently proposed, the upper half 
> of the 32-bit unsigned integer space is set aside for dynamic 
> subscriptions, but other splits are possible. One would be to use 
> signed integers, and use the sign to spit the space. This would allow 
> the use of small integers for both configured and dynamic 
> subscriptions when encoding rules can take advantage of such things.
>
> Conclusion:
>
> The use of a string as a subscription ID is overall more complicated 
> than finding a simple solution for splitting the integer ID space 
> between publisher and subscriber space.
>
> Tim
>
> -- 
>
> Cisco Systems Canada Co.
>
> 2000 Innovation Drive
>
> Kanata, ON, Canada, K2K 3E8
>
> Preferences 
>
> Unsubscribe 
>
> Privacy 
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------9536FC8CB05AF61840B4FAB6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Eric,

    
Does this mean that the configured-subscriptions and
      subscriptions tree will be combined into a single tree (NMDA
      style)?

    
Thanks,

      Rob

    

    

    
On 14/11/2017 16:40, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
After lots of
            interactions and good discussion, a majority of people have
            expressed a desire for integer over string for the
            identification of configured subscriptions.  Based on that I
            am closing the issue SN#6 with no changes to the yang model.

        
 

        
https://github.com/netconf-wg/rfc5277bis/issues/6

        
 

        
Eric

        
 

        
 

        

          

            

              
From: Netconf
                  [mailto:netconf-bounces@ietf.org]
                  On Behalf Of Tim Jenkins (timjenki)

                  Sent: Monday, October 23, 2017 2:49 PM

                  To: netconf@ietf.org

                  Subject: Re: [Netconf] SN #6 String or Integer
                  for Subscription ID

            

          

          
 

          
All,

          
 

          
This note
              attempts to take a detailed look at the two main proposals
              for the use of subscription IDs for the subscribed
              notifications draft.

          
 

          
The two
              proposals that I'll examine here are 'single integer ID
              type' and 'mixed ID type' as I'm referring to them.
              Proposals where the update notifications are different
              from configured subscriptions and dynamic subscriptions
              are not considered, since that is highly undesirable and
              more complex.

          
 

          
In the
              'single integer ID type' proposal, the subscription
              records in both the configuration and operational tables
              of subscriptions are indexed by a 32-bit integer value.
              Since configured subscriptions also appear in the
              operational table, the index space is common between
              configured and operational subscriptions. Subscribers
              create the configured subscription IDs, while the
              publisher creates the dynamic subscription IDs. Thus,
              there is an issue of potential conflict; it has been
              proposed to split the space between subcriber and
              publisher generated to remove this potential conflict.

          
 

          
In the
              'mixed ID type' proposal, configured subscriptions are
              created with a string ID by the subscriber, and dynamic
              subscriptions are created with a 32-bit integer ID by the
              publisher. The publisher also creates a 32-bit integer ID
              for configured subscriptions, so they effectively have two
              IDs. These are referred to as the subscriber and publish
              IDs for the rest of this note. The configured
              subscriptions table is indexed by the subscriber ID and
              the publisher ID does not appear in this table because it
              is not configuration data. The operational subscriptions
              table is indexed by the publisher ID and the subscriber ID
              appears in this table, but only for configured
              subscription entries.

          
 

          
I will
              attempt to evaluate the two proposals against some issues.

          
 

          
1/ How a
              receiver identifies which subscription an update
              notification's contents are associated with.

          
 

          
'single
              integer ID'               -uses only ID available, but can
              use the ID in the 'subscription-started' notification as
              well

          
'mixed
              IDs'                            -learns subscriber and
              publisher IDs from 'subscription-started' notification.
              This notification has to be modified to carry it, and
              receivers have to parse it.

          
 

          
2/ How the
              issue of multiple sources of ID generation is handled.

          
 

          
'single
              integer ID'               -split the 32-bit integer space
              for issue between publisher and subscribers; this does not
              solve issue among multiple subscribers

          
'mixed
              IDs'                           -not an issue between
              publisher and subscribers; but does not solve issue among
              multiple subscribers

          
 

          
3/ How
              subscriptions are associated across multiple publishers.
              That is, how do separate receivers know which
              subscriptions are considered to be the same when they
              arrive from different publishers?

          
 

          
'single
              integer ID'               -subscriber sends to receivers
              the IDs it used to create the subscriptions; it should
              have used the same ID for the same subscriptions on
              separate publishers

          
'mixed
              IDs'                           -subscriber sends to
              receivers the IDs it used to create the subscriptions; it
              should have used the same ID for the same subscriptions on
              separate publishers. The receivers must parse the
              'subscription-started' notifications from publishers and
              create and maintain a map of integers IDs to text IDs.
              This map must be used with update notifications, to
              determine the actual subscription ID of interest.

          
                                                                                                                                                                        
              

          
4/ How
              human readable information about the subscriptions is
              provided.

          
 

          
'single
              integer ID'               -an unrestricted text field can
              be added to subscriptions as needed. The addition of an
              unrestricted text field can be done for both configured
              and dynamic subscriptions if desired and makes the need
              for a text ID string unnecessary.

          
'mixed
              IDs'                           -the string ID used is
              limited: configured subscriptions only, and must be able
              to be a key

          
 

          
Additional
              Notes:

          
 

          
Integer ID
              Space Split: For the single integer ID case, this is a
              very simple solution to the problem. As currently
              proposed, the upper half of the 32-bit unsigned integer
              space is set aside for dynamic subscriptions, but other
              splits are possible. One would be to use signed integers,
              and use the sign to spit the space. This would allow the
              use of small integers for both configured and dynamic
              subscriptions when encoding rules can take advantage of
              such things.

          
 

          
Conclusion:

          
 

          
The use of
              a string as a subscription ID is overall more complicated
              than finding a simple solution for splitting the integer
              ID space between publisher and subscriber space.

          
 

          
Tim

          
 

          

            

              
-- 

            

            

              

                
Cisco
                    Systems Canada Co.

              

              

                
2000
                    Innovation Drive

              

              

                
Kanata,
                    ON, Canada, K2K 3E8

              

              
              
              
            

          

          
 

        

      

      

      

      

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


    

    

  


--------------9536FC8CB05AF61840B4FAB6--


From nobody Tue Nov 14 16:45:51 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F278B129432 for ; Tue, 14 Nov 2017 16:45:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiFFf7vojUd2 for ; Tue, 14 Nov 2017 16:45:49 -0800 (PST)
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 89A9C129421 for ; Tue, 14 Nov 2017 16:45:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13235; q=dns/txt; s=iport; t=1510706749; x=1511916349; h=from:to:subject:date:message-id:mime-version; bh=ZxUcuuIA+ujF7UIA+TaxEBb9TmzZamCLA4fP3mb6cSk=; b=R399xM/uKNgGTp/kUZaHa7eeR4B+Hu44pCBoJFYvAK8RGJcdKarHWLiT B6z1yQKAZ/12E8S7IIXN01VbdfUOuReFA+ts995kpHtL+gz76vyRlMIT0 +hFnTTGSGyLP3O2S2YLz039dtzAQ4ZU7JbAgtQXROwFbxcIQ9WBHR8oXJ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AAAAjQta/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuLo4WjzGTC4VJghEKI4QDhhg/GAEBAQEBAQEBAWsdC4V?= =?us-ascii?q?SXgEtUyYBBBuJN2QQrSyLFgEBAQEBAQQBAQEBAQEdBYM0ggeBVZAjBZFvkEUCh?= =?us-ascii?q?2uNEJNLjG2JEQIRGQGBOAEfOIFzehWDLoReiFCBEQEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,397,1505779200"; d="scan'208,217"; a="31535837"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 00:45:48 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAF0jmoi018630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Nov 2017 00:45:48 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 19:45:47 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 19:45:47 -0500
From: "Eric Voit (evoit)" 
To: "netconf@ietf.org" 
Thread-Topic: Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQw==
Date: Wed, 15 Nov 2017 00:45:47 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.215.19]
Content-Type: multipart/alternative; boundary="_000_f11c1a157bec4b0588a955a6385b96bfXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 00:45:51 -0000

--_000_f11c1a157bec4b0588a955a6385b96bfXCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/5



The two choices exposed during the two week review for how to represent Sou=
rce VRF of configured subscription were:



(1) Leafref to "ietf-network-instance"  /network-instances/network-instance=
/name

*        Creates dependency on schema mount for subscriptions.

*        Source VRF is an optional capability, but publishers that don't ca=
re about VRFs must still import.  (Note: could also augment the leafref in =
another model, but that adds another layer of complexity)

*        establishes model dependency to draft-ietf-rtgwg-ni-model



(2) Use a string which would be populated with exact same name as would be =
in the leafref of (1)

*        Possible to name VRF which doesn't exist



The current draft does (2).



Thanks,

Eric



--_000_f11c1a157bec4b0588a955a6385b96bfXCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











In the WG session tomorrow, I am hoping to get &#=
8220;hum feedback” on:


 


draft-ietf-netconf-subscribed-notifications =



https://github.com/netconf-wg/rfc5277bis/issues/5=
 


 


The two choices exposed during the two week revie=
w for how to represent Source VRF of configured subscription were:


 


(1) Leafref to “ietf-network-instance”=
;  /network-instances/network-instance/name



·       
Creates dependency on schema mount for subsc=
riptions.




·       
Source VRF is an optional capability, but pu=
blishers that don’t care about VRFs must still import.  (Note: c=
ould also augment the leafref in another model, but that adds another layer=
 of complexity)



·       
establishes model dependency to draft-ietf-r=
tgwg-ni-model


 


(2) Use a string which would be populated with ex=
act same name as would be in the leafref of (1)



·       
Possible to name VRF which doesn’t exi=
st


 


The current draft does (2).   


 


Thanks,


Eric 


 






--_000_f11c1a157bec4b0588a955a6385b96bfXCHRTP013ciscocom_--


From nobody Tue Nov 14 16:58:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFE6129443 for ; Tue, 14 Nov 2017 16:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOXaj0SGtqG9 for ; Tue, 14 Nov 2017 16:58:17 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246A312943F for ; Tue, 14 Nov 2017 16:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15721; q=dns/txt; s=iport; t=1510707496; x=1511917096; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=8u9Mu3UrpXJISMfkmx6r0XgarNiEnO1RWOGL/AezMrs=; b=Hz1kHjRzbsooWWuXI6dCERiZsD5wChS5k8Ul065z5a3xT8fjQiHhRHBi z6ZQ7Jz+jytzppmmO/yJOISWj0KD0ycZIecrCPytgXFMDAPxJzGODshjN xI0Jf8injIgSDtT0iBxlDKiJ+7egKthlZSggwSEmaS+Ln+P0fEhE4/nn3 0=;
X-IronPort-AV: E=Sophos;i="5.44,397,1505779200";  d="scan'208,217";a="314522999"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 00:58:16 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAF0wEwJ018370; Wed, 15 Nov 2017 00:58:15 GMT
To: "Eric Voit (evoit)" , "netconf@ietf.org" , Lou Berger 
References: 
From: Robert Wilton 
Message-ID: 
Date: Wed, 15 Nov 2017 08:58:14 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DE1ADEE7BE2089796A88EF10"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 00:58:19 -0000

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

Hi Eric, Lou,

This seems to be a generic problem.

Could the VRF leafref name dependency issue be solved with an if-feature 
statement?.

I.e.could the network instance draft define a separate YANG module (with 
no dependencies) that defines a "VRF" feature.

All the VRF references (ideally if all IETF YANG modules that may 
optionally depend on VRFs) could be leaf-refs to 
/network-instances/network-instance/name but predicated with an 
if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the 
"vrf" feature, so it doesn't have to implement the full network 
instances module, or schema mount.

Thanks,
Rob


On 15/11/2017 08:45, Eric Voit (evoit) wrote:
>
> In the WG session tomorrow, I am hoping to get hum feedback on:
>
> draft-ietf-netconf-subscribed-notifications
>
> https://github.com/netconf-wg/rfc5277bis/issues/5
>
> The two choices exposed during the two week review for how to 
> represent Source VRF of configured subscription were:
>
> (1) Leafref to ietf-network-instance 
> /network-instances/network-instance/name
>
> Creates dependency on schema mount for subscriptions.
>
> Source VRF is an optional capability, but publishers that dont care 
> about VRFs must still import. (Note: could also augment the leafref 
> in another model, but that adds another layer of complexity)
>
> establishes model dependency to draft-ietf-rtgwg-ni-model
>
> (2) Use a string which would be populated with exact same name as 
> would be in the leafref of (1)
>
> Possible to name VRF which doesnt exist
>
> The current draft does (2).
>
> Thanks,
>
> Eric
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------DE1ADEE7BE2089796A88EF10
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Eric, Lou,

    

    
This seems to be a generic problem.

    
Could the VRF leafref name dependency issue be solved with an
      if-feature statement?.

    
I.e.could the network instance draft define a separate YANG
      module (with no dependencies) that defines a "VRF" feature.

    
All the VRF references (ideally if all IETF YANG modules that may
      optionally depend on VRFs) could be leaf-refs to
      /network-instances/network-instance/name but predicated with an
      if-feature "ni:vrf".

    
Hence if a device doesn't support VRFs, then it doesn't implement
      the "vrf" feature, so it doesn't have to implement the full
      network instances module, or schema mount.

    
Thanks,

      Rob

    

    

    
On 15/11/2017 08:45, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
In the WG session tomorrow, I am hoping
          to get hum feedback on:

        

        
draft-ietf-netconf-subscribed-notifications
          

        
https://github.com/netconf-wg/rfc5277bis/issues/5
          

        

        
The two choices exposed during the two
          week review for how to represent Source VRF of configured
          subscription were:

        

        
(1) Leafref to ietf-network-instance
          /network-instances/network-instance/name

        

          
              Creates dependency on
          schema mount for subscriptions.
          

        

          
              Source VRF is an
          optional capability, but publishers that dont care about VRFs
          must still import. (Note: could also augment the leafref in
          another model, but that adds another layer of complexity)

        

          
              establishes model
          dependency to draft-ietf-rtgwg-ni-model

        

        
(2) Use a string which would be
          populated with exact same name as would be in the leafref of
          (1)

        

          
              Possible to name VRF
          which doesnt exist

        

        
The current draft does (2). 

        

        
Thanks,

        
Eric 

        

      

      

      

      

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


    

    

  


--------------DE1ADEE7BE2089796A88EF10--


From nobody Tue Nov 14 17:06:05 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1182212944C; Tue, 14 Nov 2017 17:06:03 -0800 (PST)
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 vnlQMxofqDgr; Tue, 14 Nov 2017 17:06:01 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 2A5DC12940E; Tue, 14 Nov 2017 17:06:01 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id 207so13934609pgc.12; Tue, 14 Nov 2017 17:06:01 -0800 (PST)
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=BZ5soZkbLbGFo9fe9Gk7LE8/UkAmdnExtyruabugQVQ=; b=kt6suCFZedrCfrezcPaOCY0lfgELKOrabkw3IpWfn4eg4z2qnxJnNEdLebCNIT2kre BOwrAnjAcjftItXlczfs8GJCIkcDjvAJcApePSy1tpv/HXtBuOQTJyS5BH9QxCFF9/LU LqIS2wUAfa+D3dJw7F8ZPKhQoGwZYakSRrxcteek1/dBnt8BVjGcgJijwGWxM0q0EmkH 35XO0OJZJDDW2MuvcPeZ5PYFUCISzmAwkQ2SPeHqHgs50EkG6MsLkkqrxTQmwFlBJO+s BYavmiUBRK3NBAUlLbTqDM6MhPpeoIqwTaW5NtnVQeCDCGiVST0dn/ClwGJldrR7WTkG 5QCA==
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=BZ5soZkbLbGFo9fe9Gk7LE8/UkAmdnExtyruabugQVQ=; b=HrK9GF9O4W0FosKAX1oI6fUzxI54VmcAhPk2NiynZo+kiQ0cqFLMJpnX/E4FiRPFoc 2fdUXWl5JdaTYWdC8MKpoM5ATKCmSfB3Yd7u0aUGgDDpzecz0t+2l52/cQPlg++vl5Ne /jMw7U3e2+5DAvBlmZZHBE3rn/fAQEUE2CzIqCPugUYkKS7sE2YANEFkS9485cOvwVSm Sa4QCLBmP6ahAvStUlQCLmngAQ90bjOFUBaiOXbATGKMIkK49/kQ8RgWtZADrEErtpQ0 HaA/QHs7v3tPFJWyGHaMtMIFduZO8i7yKoOgw8GWeuw1H9PbeivecEmQKedC8oztMTRj dmRQ==
X-Gm-Message-State: AJaThX7ifF4DPeaKiXerR1zGoYB5eHDjwWEvcY2UzvR4Ll8zIoCiLHR+ FyIY2vMCV+ix3h7S0ldaoewrAAiM
X-Google-Smtp-Source: AGs4zMYK/3OhlN7M9ReFnEHnWZSB4fUGBW/uImzBuHknGIyA+kIwF5fxXYwdzoP99nTq5bPoxbUhGw==
X-Received: by 10.159.254.4 with SMTP id r4mr14393246pls.229.1510707960577; Tue, 14 Nov 2017 17:06:00 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:6500:99eb:b351:1cc5? ([2001:67c:1232:144:6500:99eb:b351:1cc5]) by smtp.gmail.com with ESMTPSA id l22sm46060538pfk.45.2017.11.14.17.05.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 17:05:59 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6451D9E-F285-48BA-B7E2-5C28839E2BAE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20171113.162810.1853130535954821831.mbj@tail-f.com>
Date: Wed, 15 Nov 2017 09:05:56 +0800
Cc: Andy Bierman , sec-ads@ietf.org, netconf , Eric Rescorla 
Message-Id: <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 01:06:03 -0000

--Apple-Mail=_D6451D9E-F285-48BA-B7E2-5C28839E2BAE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Andy,

I assume you will incorporate these changes in the -09 version of the =
draft.

However, I am unable to review the changes in github. Can you post the =
diffs of the draft w.r.t. -08 version.

That still leaves us with one issue, and that has to do with the what =
permission to give edit-operation. I am assuming the WG agrees that =
making the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 =
for edit operations makes maintenance more difficult and makes the =
operation more vulnerable, unless all the deny rules are in place.

We will need to update the security considerations section to address =
Eric=E2=80=99s concerns. How about this update?

OLD:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

NEW:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

Cheers.

> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> I just read this thread, and I agree with the changes, but see below
> for a comment.
>=20
>=20
> Andy Bierman > wrote:
>> Hi,
>>=20
>> Here are some proposed edits to make the data rule consistent with =
the
>> examples.
>> Note that this issue is not related to the edit in the original =
1-week
>> change.
>>=20
>>=20
>> sec. 3.3.5:
>>=20
>> OLD:
>>=20
>>=20
>>      data node rule:  controls access for a specific data node, =
identified
>>      by its path location within the conceptual XML document for the
>>      data node.
>>=20
>>=20
>> NEW:
>>=20
>>      data node rule:  controls access for a specific data node and =
its
>> descendants,
>>      identified by its path location within the conceptual XML =
document
>> for the
>>      data node.
>>=20
>>=20
>> sec 3.4.5, step 6, bullet 2:
>>=20
>>=20
>> OLD:
>>=20
>>        *  The rule does not have a "rule-type" defined or the "rule-
>>           type" is "data-node" and the "path" matches the requested
>>           data node, action node, or notification node.
>>=20
>>=20
>> NEW:
>>=20
>>=20
>>        *  The rule does not have a "rule-type" defined or the "rule-
>>           type" is "data-node" and the "path" matches the requested
>>           data node, action node, or notification node. A path is
>>           considered to match if the current data node is the data =
node
>>           specified by the path, or is a descendant data node of this
>>           data node.
>=20
> I propose:
>=20
>             The rule does not have a "rule-type" defined or the
>             "rule-type" is "data-node" and the "path" matches the
>             requested data node, action node, or notification node.
>             A path is considered to match if the requested node
>             is the node specified by the path, or is a
>             descendant node of the path.
>=20
> Note:  s/current node/requested node/ which is the term used in the
> first sentence.  And then s/data node/node/ since the first sentence
> refer to data-, action-, and notification node.
>=20
> I have checked in this fix in the repo.
>=20
>=20
> /martin
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_D6451D9E-F285-48BA-B7E2-5C28839E2BAE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Andy,

I =
assume you will incorporate these changes in the -09 version of the =
draft.

However, =
I am unable to review the changes in github. Can you post the diffs of =
the draft w.r.t. -08 version.

That still leaves us with one issue, =
and that has to do with the what permission to give edit-operation. I am =
assuming the WG agrees that making the change from =E2=80=98none=E2=80=99 =
to =E2=80=98read=E2=80=99 for edit operations makes maintenance more =
difficult and makes the operation more vulnerable, unless all the deny =
rules are in place.

We will need to update the security =
considerations section to address Eric=E2=80=99s concerns. How about =
this update?

OLD:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

NEW:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In =
particular
servers should not expose instance information =
before validating field
information.

Cheers.

On Nov 13, 2017, at 11:28 PM, Martin =
Bjorklund <mbj@tail-f.com> wrote:

Hi,

I just read this thread, and I agree with the =
changes, but see below
for a comment.


Andy Bierman <andy@yumaworks.com> wrote:
Hi,

Here are some proposed edits to make the data rule consistent =
with the
examples.
Note that this issue is =
not related to the edit in the original 1-week
change.


sec. 3.3.5:

OLD:


     data node rule:  controls =
access for a specific data node, identified
     by its path location within the =
conceptual XML document for the
     data node.


NEW:

     data node rule:  controls =
access for a specific data node and its
descendants,
     identified by its path location =
within the conceptual XML document
for the
     data node.


sec 3.4.5, step 6, bullet 2:


OLD:

       *  The rule =
does not have a "rule-type" defined or the "rule-
          typ=
e" is "data-node" and the "path" matches the requested
          dat=
a node, action node, or notification node.


NEW:


       *  The rule =
does not have a "rule-type" defined or the "rule-
          typ=
e" is "data-node" and the "path" matches the requested
          dat=
a node, action node, or notification node. A path is
          con=
sidered to match if the current data node is the data node
          spe=
cified by the path, or is a descendant data node of this
          dat=
a node.

I propose:

          &nb=
sp; The rule does not have a "rule-type" defined or the
          &nb=
sp; "rule-type" is "data-node" and the "path" matches the
          &nb=
sp; requested data node, action node, or notification =
node.
          &nb=
sp; A path is considered to match if the requested node
          &nb=
sp; is the node specified by the path, or is a
          &nb=
sp; descendant node of the path.

Note:  s/current node/requested node/ which =
is the term used in the
first sentence.  And then s/data =
node/node/ since the first sentence
refer to data-, action-, and notification =
node.

I have checked in =
this fix in the repo.


/martin

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



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_D6451D9E-F285-48BA-B7E2-5C28839E2BAE--


From nobody Tue Nov 14 19:22:42 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFF412711E for ; Tue, 14 Nov 2017 19:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 TJpspEJCxXnx for ; Tue, 14 Nov 2017 19:22:39 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FED126B72 for ; Tue, 14 Nov 2017 19:22:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15179; q=dns/txt; s=iport; t=1510716159; x=1511925759; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XjS39P9MKEv813lmgioknD4wOScMYtNLdyKIYOvSFLc=; b=Dj8Qw/rmlqzq2PC/54eNWDbBWlJaV3yTZMlmCwzuDAmlb4bHdoSTFao+ 9Irvue7UjT5ICHao6rVpcQJtepcPg0dK0xeik544HxRQolZRrzdVx6ueY p+/cyYOSIxmlUVhRHsoxQsbYGvCobV3Arh+5FYPMco3NJY3/CLHakSL87 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClAAA8sgta/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJweOFo8xgX2RDoVJghEKGAEKhANGTwKFAT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQEDAQErQRsCAQgVEBoHJwsUEQEBBAESCIk3ZBCtBCaKcgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVhROFToVCBZFvhy2JGAKHa40Qk0u?= =?us-ascii?q?MbYkRAhEZAYE4AR84gXN6FUmCZIMRgU53h1aBEQEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,398,1505779200"; d="scan'208,217"; a="31560566"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 03:22:38 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAF3McPd015385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 03:22:38 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 22:22:37 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 22:22:37 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMA=
Date: Wed, 15 Nov 2017 03:22:37 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.215.19]
Content-Type: multipart/alternative; boundary="_000_c474b5778c704baab9070b298b5b2a3dXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:22:41 -0000

--_000_c474b5778c704baab9070b298b5b2a3dXCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree it is a generic problem.

I would defer to Lou and the other authors of draft-ietf-rtgwg-ni-model as =
this would be a fairly significant change.

Eric

From: Robert Wilton, November 14, 2017 7:58 PM


Hi Eric, Lou,

This seems to be a generic problem.

Could the VRF leafref name dependency issue be solved with an if-feature st=
atement?.

I.e.could the network instance draft define a separate YANG module (with no=
 dependencies) that defines a "VRF" feature.

All the VRF references (ideally if all IETF YANG modules that may optionall=
y depend on VRFs) could be leaf-refs to /network-instances/network-instance=
/name but predicated with an if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the "vrf"=
 feature, so it doesn't have to implement the full network instances module=
, or schema mount.

Thanks,
Rob

On 15/11/2017 08:45, Eric Voit (evoit) wrote:

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/5



The two choices exposed during the two week review for how to represent Sou=
rce VRF of configured subscription were:



(1) Leafref to "ietf-network-instance"  /network-instances/network-instance=
/name

*        Creates dependency on schema mount for subscriptions.

*        Source VRF is an optional capability, but publishers that don't ca=
re about VRFs must still import.  (Note: could also augment the leafref in =
another model, but that adds another layer of complexity)

*        establishes model dependency to draft-ietf-rtgwg-ni-model



(2) Use a string which would be populated with exact same name as would be =
in the leafref of (1)

*        Possible to name VRF which doesn't exist



The current draft does (2).



Thanks,

Eric






_______________________________________________

Netconf mailing list

Netconf@ietf.org

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


--_000_c474b5778c704baab9070b298b5b2a3dXCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Agree it is a generic =
problem. 



 


I would defer to Lou a=
nd the other authors of draft-ietf-rtgwg-ni-model as this would be a fairly=
 significant change.


 


Eric 


 








From:=
 Robert Wilton, November 14, 2017 7:58 PM<=
br>









Hi Eric, Lou,


This seems to be a generic problem.


Could the VRF leafref name dependency issue be solved with an if-feature=
 statement?.


I.e.could the network instance draft define a separate YANG module (with=
 no dependencies) that defines a "VRF" feature.


All the VRF references (ideally if all IETF YANG modules that may option=
ally depend on VRFs) could be leaf-refs to /network-instances/network-insta=
nce/name but predicated with an if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the &q=
uot;vrf" feature, so it doesn't have to implement the full network ins=
tances module, or schema mount.


Thanks,

Rob


 




On 15/11/2017 08:45, Eric Voit (evoit) wrote:






In the WG session tomorrow, I am hoping to get &#=
8220;hum feedback” on:


 


draft-ietf-netconf-subscribed-notifications =



https://github.com/netconf-wg/rfc5277bis/issues/5



 


The two choices exposed during the two week revie=
w for how to represent Source VRF of configured subscription were:


 


(1) Leafref to “ietf-network-instance”=
;  /network-instances/network-instance/name



·       
Creates dependency on schema mount for subsc=
riptions.




·       
Source VRF is an optional capability, but pu=
blishers that don’t care about VRFs must still import.  (Note: c=
ould also augment the leafref in another model, but that adds another layer=
 of complexity)



·       
establishes model dependency to draft-ietf-r=
tgwg-ni-model


 


(2) Use a string which would be populated with ex=
act same name as would be in the leafref of (1)



·       
Possible to name VRF which doesn’t exi=
st


 


The current draft does (2).   


 


Thanks,


Eric 


 











_______________________________________________


Netconf mailing list


Netconf@ietf.org

https://www.=
ietf.org/mailman/listinfo/netconf




 








--_000_c474b5778c704baab9070b298b5b2a3dXCHRTP013ciscocom_--


From nobody Tue Nov 14 19:43:32 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD830126C22 for ; Tue, 14 Nov 2017 19:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyNr4t8-ASiR for ; Tue, 14 Nov 2017 19:43:27 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1CE126B72 for ; Tue, 14 Nov 2017 19:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16767; q=dns/txt; s=iport; t=1510717407; x=1511927007; h=from:to:subject:date:message-id:mime-version; bh=eyX0iN/xAgb/pcWlgXAfN4aXyHb9Hgw0J1UR4QxgBRU=; b=mc1J4GTLW3eSQ+W+CkVYi4EQIwsDHd9pD8FZtt96/IbnUyjwO1eLmSCV WCKcD007xFt4SPTj2mBibOVFv0DwwPFR/Vh+CbyzKaY0vAxGd5QS37yNZ gCqk5MGi24eyUu+tuYn3jxx6VxKnHgNHxZyhcH9CFL1yU7uJYvWIc4eK8 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAAAotwta/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuLo4WjzGYVIIRCiOKGz8YAQEBAQEBAQEBax0LhVJeAS1?= =?us-ascii?q?TJgEEG4k3ZBCsf4sYAQEBAQEBBAEBAQEBAQEcBYM0ggeBVZAjBaI0AodrjRCTS?= =?us-ascii?q?4xtiRECERkBgTgBHziBc3oVgy6DEIFOhxorgQiBEQEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,398,1505779200"; d="scan'208,217"; a="31037291"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 03:43:26 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAF3hQki016016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Nov 2017 03:43:26 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 14 Nov 2017 22:43:25 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 22:43:25 -0500
From: "Eric Voit (evoit)" 
To: "netconf@ietf.org" 
Thread-Topic: Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQ==
Date: Wed, 15 Nov 2017 03:43:25 +0000
Message-ID: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.215.19]
Content-Type: multipart/alternative; boundary="_000_868e65f523c04a38b696649cfaec3666XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:43:31 -0000

--_000_868e65f523c04a38b696649cfaec3666XCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/4



The two choices and their issues exposed during the two week review on "Can=
 Transport vary across different receivers of a single configured subscript=
ion?" are:



(1) Yes, Transport can vary by receiver

*        Fewer subscriptions (scale benefit)

*        Can convert transport without requiring an application to learn a =
multiple subscription ids

*        No duplication of content during transport conversion.

*        (Potential confusion in allowing transport to vary, but encoding n=
ot to vary?)



(2) No, only one Transport across all subscriptions

*        Simpler model

*        But applications may need to create and track multiple subscriptio=
n-ids for the same content.

*        Temporary duplication of content streams during transport change.



The current draft does (1).



Thanks,

Eric



--_000_868e65f523c04a38b696649cfaec3666XCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











In the WG session tomorrow, I am hoping to get &#=
8220;hum feedback” on:


 


draft-ietf-netconf-subscribed-notifications =



https://github.com/netconf-wg/rf=
c5277bis/issues/4



 


The two choices and their issues exposed during t=
he two week review on “Can Transport vary across different receivers =
of a single configured subscription?” are:


 


(1) Yes, Transport can vary by receiver



·       
Fewer subscriptions (scale benefit)



·       
Can convert transport without requiring an a=
pplication to learn a multiple subscription ids



·       
No duplication of content during transport c=
onversion.



·       
(Potential confusion in allowing transport t=
o vary, but encoding not to vary?)


 


(2) No, only one Transport across all subscriptio=
ns



·       
Simpler model



·       
But applications may need to create and trac=
k multiple subscription-ids for the same content.



·       
Temporary duplication of content streams dur=
ing transport change.


 


The current draft does (1).  



 


Thanks,


Eric 


 






--_000_868e65f523c04a38b696649cfaec3666XCHRTP013ciscocom_--


From nobody Tue Nov 14 19:56:10 2017
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE2126CBF for ; Tue, 14 Nov 2017 19:56:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151071816147.25871.16968808871615603026.idtracker@ietfa.amsl.com>
Date: Tue, 14 Nov 2017 19:56:01 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] Milestones changed for netconf WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:56:01 -0000

Deleted milestone "WGLC for NETCONF and RESTCONF bis protocols".

Deleted milestone "Submit NETCONF and RESTCONF bis protocols to AD/IESG for
consideration as Proposed Standard".

URL: https://datatracker.ietf.org/wg/netconf/about/


From nobody Tue Nov 14 20:06:18 2017
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1C126CBF for ; Tue, 14 Nov 2017 20:06:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151071877704.25972.8330039014422073304.idtracker@ietfa.amsl.com>
Date: Tue, 14 Nov 2017 20:06:17 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] Milestones changed for netconf WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 04:06:17 -0000

Changed milestone "WGLC for Zero-touch Configuration Mechanism", set due date
to December 2017 from October 2017.

URL: https://datatracker.ietf.org/wg/netconf/about/


From nobody Tue Nov 14 21:01:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFB2127873 for ; Tue, 14 Nov 2017 21:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 RAGmQFtRQqlN for ; Tue, 14 Nov 2017 21:01:24 -0800 (PST)
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 58F131242EA for ; Tue, 14 Nov 2017 21:01:24 -0800 (PST)
X-AuditID: c1b4fb3a-c5bff70000004c48-a7-5a0bca228355
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.4B.19528.22ACB0A5; Wed, 15 Nov 2017 06:01:22 +0100 (CET)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 06:01:22 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/CZ5ul7GO3ya5iMhXGL0rkr3yJ2LR5utx7R8AZG4do=; b=dfOYrfBbmWJLpsldoSVo9AAkKul/VSo9AUsSlWi5DdoQ2jF131v14JMHQq+XxkYUQizWxth9ASpE+iNG1MV9/vmjTfrml/n36GSemsFu+NYeMN7XfmXbUJWTly8j96Z7Aq9YXU+6o6d6JJZ8jH+F31VUOzDDAbGAtEoiGx0k/UE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [IPv6:2001:67c:370:128:d151:2478:63f2:5fe7] (2001:67c:370:128:d151:2478:63f2:5fe7) by DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 15 Nov 2017 05:01:20 +0000
To: "Eric Voit (evoit)" , "netconf@ietf.org" 
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com>
From: Balazs Lengyel 
Message-ID: 
Date: Wed, 15 Nov 2017 13:00:59 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com>
Content-Type: text/html; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2001:67c:370:128:d151:2478:63f2:5fe7]
X-ClientProxiedBy: SG2PR0401CA0012.apcprd04.prod.outlook.com (2603:1096:3:1::22) To DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22)
X-MS-Office365-Filtering-Correlation-Id: 00621131-3f72-48c1-649b-08d52be5e99d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DB6PR07MB3431; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 3:ST5fpd1AWqEz762Y5CbIZpOzYR2trVpccOHE+dTbGyeLULVBckLE//R92zzoeCwHkBOZ5TUKNU9Aaj70cFzjEPpdhjMVzSpS09/21DCMiumzyF7srpDUQYE0E74QjK3fyKTEBISAxsL7VB9GR3S5OEPp9sBhFMk1wQh5uuyq7NYpz+skM8PPsOT7HCCimg7xZhTwvqcDX0neiD98LhyQG7pR3ETPdTFURxhYFFkqNBhQGoUfXWXkIpG4itZLnNDa; 25:1kU4OxS6YvHxLlsLqqhyMLOI+lv8LDAgLTEmQ7+HhK619ztlSqh6g4g+g+VjCLsSj9bf8ZZu87rLqbAA2QTQpbGXPTuJXcEsUuDoNakZseZqJx0OoJDzw1J6cbEy/2znLW77lvf3zJWuhCCt5rAQ2sw4n+jipb/H+2iTxNF+/82bL0lhDTrXhD0o6HxEU+W9MkkQRuS21fHBmi0ptF9OSX4tawzjPflC0TIi3TX3mEyxpWsAy4LK44OAx4rwU5pdQ7O9oe3co6XWnWTeXwc742cCCeFMaGdF9T02awoPlhlPrpJM6nz7TKDhowjxLiDvKu/5lfy1XiRFbmgGMOjHug==; 31:WxkHItUVj1FSE581F14jBnkKd3wAPeTPbBOvhisur8LTVVrNyXrMigowwx3sTckj+6LDjQOJ15GL21+ozpC0TRiXaWzxmEbo6QblW08uSALrcHBSYRCELi8sZGj8Mf9XH5uCGLu98OIysWjEGT9WKuRpLpKBq+US+Ba6zaAqjTWUCydZins+zjIsCzArVtXNb8yXccFD5x3JtkZSGbqqLsjtE9rkUEtcyee1MpNPjdg=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB6PR07MB3431:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 20:8dx96ex0KTvVzU5x+D4VOpSriz7ix/hO8c1tFyCr17689PHortoy1LwFs1ehFgmy1ksO+nlBbGD+5v3H1O1XdT9+Rzr3U4/2K3/7WPih459YpGBpJ7ASWpIx8wQXkGrnXGrqodJdkeIxmA+Sfvv0QJxJKv1y36jm8+E2nTK+j4eCR7yiaweohG3cxhSJuQEMAwhLK/lX1KBdx2DjgeoydEqFI/8ZQhXON/vcXfRjGCRSeVETkWwPFgn4ekbGE+luP1yBM9L64UxNxBx2mMWFv/YWWLY7+7O+tmV6qPpLGg9wtdqH2KR1GYsKt1Hk2LXxClJAVitWdFKWDGoQnj5S8wh1PlCJ1JemNM3B2pwFuOaN5hf4VWBfEVp5PakkF6Bd6pXm513KUuceEClzGuDmemXZzWdT0yW8VSJF5nxx85QOidKjLjfw/QSoNKhYkQFGVcaaV4setKCd6dCS8JHG5/n6XqwV1h+oPIIa4YgzI0/lxLyQXH8p+B/AJd/+v8VX; 4:pS4GLxHKB8lNOVwEfPIkOCngGE4kAvxR5pSLoOSGwH+w3oUxBuq2ScRTnnfPdtg8UWdlwuLrxHDR9r4K2cyh3Thdt/gPsXVV3tCnoKvhgajnw4raqmINawGmf1tmkBAIxa9UIuqXmo576t+6eNLnyFJnGQugdB9l2K9ZyQ/CFg1i3Wx+DMqKLgkReDlcWS7gjtfDcE9KpSqVZwKGNPc1nmbkdw0FNLPkFkWEnATL6h2DNL6x6yfQDsI+s15fEu3c16IPhIM1blRLJePAJjjWrIJADvFraPvPUgPti4jG5jgzfDVbcgm2AXw3HQzzIJI1NcGoICoSzBbQh1l227enEqMIFitYtxqnarr9qVe8aaGhX6q70h9XNIYg+IHmMBzJClJAwG5SRXaui3gNAHPKtr5Nx4ilkriGwbwzHIlVqHQ=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(278428928389397)(166708455590820)(95692535739014); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR07MB3431; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR07MB3431; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(252514010)(24454002)(199003)(189002)(377424004)(478600001)(33646002)(606006)(76176999)(54356999)(8936002)(7736002)(2906002)(189998001)(110136005)(106356001)(81166006)(65806001)(36756003)(229853002)(23746002)(966005)(1706002)(6486002)(25786009)(8676002)(81156014)(50986999)(6116002)(86362001)(31696002)(6666003)(58126008)(4001150100001)(53546010)(790700001)(68736007)(31686004)(65956001)(316002)(236005)(97736004)(6306002)(54896002)(83506002)(65826007)(23846002)(64126003)(53936002)(50466002)(2870700001)(5660300001)(105586002)(2950100002)(2501003)(6246003)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3431; H:[IPv6:2001:67c:370:128:d151:2478:63f2:5fe7]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR07MB3431; 23:Eb6C9+xbmsFjL2EvCIrzb4N16C4vJ5OHAGOfy?= =?Windows-1252?Q?BTFLrnAzXxOic9BxBCRSijJxrgAkdna/W0B5h7UULE7cDluALV97HNkE?= =?Windows-1252?Q?REfkG2kLk4SsomZxCAgSs5/hPPN7gPa4yyrbU+UgTQqKBXCNySnWJHgk?= =?Windows-1252?Q?yD5xcAfuYHJc8pp8jWWa3s6u4ZtrjoQMfw/vZ1sCyEFt5YkmZdoyGL/P?= =?Windows-1252?Q?cbtSdQ9Gr/u3fs3aqIgF3EU6cQ+QM9tfJ917j5zuGZcXA0pKoRNRucuh?= =?Windows-1252?Q?LyfZYWK71IUuz7esLph08BrtTQDacfrFnX4mR6M+rOopJG/sTUQ0Nlk7?= =?Windows-1252?Q?OWCgdC4dy8zuQrwaDAvEEFzvBUT9gIJrd36i7/5+y7qSV0/Eq0bJdPSH?= =?Windows-1252?Q?DItZ+/HKdKNKTNFmwrlpGgOeq25Ln6vWXBTzoLsUX8PE+da4WO2Q8CAQ?= =?Windows-1252?Q?pwAz1hsgfFDZfok9lxwjE+QckADkyoJ2QRsRBSFXzz2j8vI88UU2BsxX?= =?Windows-1252?Q?xgjyaE/L3bBBL+uclNewJfCh108tcS2R4GrePttdum3z8mCH+PoHlyvz?= =?Windows-1252?Q?tjQcyFteJH8QiZd+7DEtc9pzcr1X9MHWdJ7U+IPqQ4peTSBQ2OY1vhy+?= =?Windows-1252?Q?0grx+fenKdvTE8GobuEnErq1K15ZS84A1noAi82kne5L57dzBZtWL7W3?= =?Windows-1252?Q?8//CFzHGJluyuYXYbs6xdXEozbtGhpE5OjtaMNvYCeCYgW+NRuJH06I5?= =?Windows-1252?Q?I8F6YWznDlhHwesrvbu48WTiX5j1KC7RZxlQdK0OEofONDvcbeD3g86L?= =?Windows-1252?Q?VuriOsH7n8O+rn3aYhdaX7Zrs3qYH0z5Zg8Y+Y6A7IFoHkgeGlTCO35b?= =?Windows-1252?Q?50Totdfe7ILKaOb2sw8bnc7K4Lw89ysu0tNIZerYVva7mBlnPSOscTzR?= =?Windows-1252?Q?2HOyGo+12c6+uhsjaCQ+pP4vqhQtBq60dOXEP5E93fu50/HL2NhLq1OB?= =?Windows-1252?Q?N2GnjEbyuWkPssUx+JRxCRVl0TqZFvWy5UkYNaOfRxIwnFD+KKCTpK81?= =?Windows-1252?Q?swmhQ+w6JtI/Fnf0eCHfqnBOWoVV4LY+gQbXX5JbHWk/0boNm7tlhzS5?= =?Windows-1252?Q?rD5gNhWilVZ/2y8xOjECtngz9lrlPQPauqMKWv78c1m+RAGysMTbegB8?= =?Windows-1252?Q?LYVCwAAcxYyzQQyjSQ7fpZ4QoRgpMiRYBcSdryJS8DR1ZM2RlW4F3J3D?= =?Windows-1252?Q?M08yI7ML5ChnyZJVz/KSjjLICDSa0og1fBMtIDSpvyBFhhpnCAwA58u2?= =?Windows-1252?Q?0UPsU5jcpaU47M3RC/+aNpWaHhw7PpWRCwBPvZkBdC8Rn4gLJNqw+TGa?= =?Windows-1252?Q?DxUCo5LOqyRXuXILeaCt/RwUCBaxBDSmj6iNfjuC1+a8ssAXO5RW3mgO?= =?Windows-1252?Q?5QcB+ylbI526QA7zCd/NuDrOw0nsnP0HK5MQkwnIuJ+y6HlA1f8WVLtX?= =?Windows-1252?Q?i1xndHkTEIBuQCQzpaUOtW98p99?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 6:TFt+jTIrsc72Hb2+QL3JqtzLz+tNhm5jo+0OVB1z2oXSd060DdxF1f1Y9NSiP8DWh+pYC526+Crn9geIYELs3V2kdKg5UJV13IroJJL2SmLqmZRnxw0HNoqmkeCdiLJNPdB4UFw17lJI2KibObSn1MnDGp6sGswp6zscuNXIJW1rDyV8OrKbo03WSnrIMNaIglzdnr+qUl2DF0ROgaoHC7fDHplwa9bAGoz3OZNvvrQqmeYFPbhFOtz3a8ooYLigo13i82PNUJcWBKytKSd+ZiByv5CBIYFKsx1GyLhFnNennhfsOVQoLsBoGN6RSn+A5d2+p/pxrDA6fcZKs3vSOmEoRDvp2IE1jhcfd7eQO+Y=; 5:2yGFpP6rjYMKTT0DuT3mC9XKv6s4hmieu6Jm0qv1iCJBY/oAl1efWWqj2uYyZZEEWY3YN/2wPafxJyeKOVVSwJ99dwxtuFtZGPqWdg1ZRPivgTFvnYhJ1w0yM3ldLkm4Kk/KwHyU4aYQ2OB3Tmc6wXgq9EPPkMpQbTPttAKyz64=; 24:SEkddIZMOpdqwYlI+bD/8Kt2ckocZ5TPeH/fP4dhTlSX0wQNA0SZ3ERxytBKR3U04KUfXXpAAUuVw4pEs04FPzxrRPcXSPH5AXtOOlRmg80=; 7:5gaYrOqVQqS2BnW1jc0xhwg5J0l9NvU/VDkaU/aP9dd2EG8GFsWM1QPvAuqmVkcU2uZ9gvJqk2ZpkzHGV1bTHa5zTfvrSL0oXxkUBmsDASxeGdVK1ypLqUCnwoI1Mphz9IC7t4PoOGSrlAdKY7ipA1jb90IXI/6kyHWeXSSO8bC2m9dJMsxwCjVyW8m/K9NNO0RGtgFf4UPE+gX/cbzYCydvmQBF38pzm+5f3G2VXZ1gChcGN5kBvph0BaH9s18O
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 05:01:20.0954 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 00621131-3f72-48c1-649b-08d52be5e99d
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3431
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbFdUVfpFHeUwcUpqhYvVq9mspi66Tar A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx8bNowetWxorTOyezNzDuyu9i5OSQEDCR eHP4J2MXIxeHkMBhRonp35eyQTgnGCW+Xl3CAuKwCPQySxw5PpsJpIVRIE5i55qFrBBVu5gk vjWtZgRJCAtUSJztPQzUzsEhIhAksXiHGEhYSMBF4sbVtSwgNpuAkcTU/vNgNq+AvcTrll5m EJtFQFVi3u4Z7CC2qECMxMQHFxkhagQlTs58AlbPKeAqsXd9D9gNzAL6Etfv3GeFsMUlbj2Z DxWXl2jeOpsZ4jULiVd/Z4DdKSEwhVHi8I5GJoiDNCQeXvjLClHkK/FqejczRNFMRokTu79B OQ3sEtP2dkKNkpU4enYOC4StJbHxywd2CPsJu8TktxoQdrZE66njUDU5EtNnzWSDGHSFVeLL iimMEAkZiZM39jJCJCazSczr/sUygVF7FpJfZyH5bxaS/2Yh+W8BI8sqRtHi1OLi3HQjI73U oszk4uL8PL281JJNjMDkcXDLb6sdjAefOx5iFOBgVOLh/b+NO0qINbGsuDL3EKMEB7OSCG9y P1CINyWxsiq1KD++qDQntfgQozQHi5I4r4cIUEogPbEkNTs1tSC1CCbLxMEp1cDow6ejfOjM K4uGuh9T9WYyZgj7ma9yk0zgXdLgfWfzpWlyLUdWyFfJedo6GwhJv2YzfLpVUfxfm0xB6qQ/ 145PfOfW/C3wYQarj1S/XPs8w4C5nE6tB0XuH3ViOLQ72PDm92/5Bxl0Y6MM9iss5xD/3nlH vvnEg0mzFiiVHQ1aUrRxwbSY2JVKLMUZiYZazEXFiQAlr44GGgMAAA==
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:01:27 -0000


  
    
  
  
    
While I see no real need for different protocols for the same
      transport, I also any real reason to restrict this. I would vote
      for the draft to leave this to the implementations. Unless we have
      a good reason why make a stand pro or contra?

    
IMHO if we or an implementation allows transport conversion it is
      still not guaranteed that no notifications are lost or duplicated.

    
In case 2) will we would need to enforce the common transport in
      the model.

    

    
regards Balazs

    

    

    
On 2017-11-15 11:43, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
In the WG session tomorrow, I am hoping
          to get hum feedback on:

        

        
draft-ietf-netconf-subscribed-notifications
          

        
https://github.com/netconf-wg/rfc5277bis/issues/4
          

        

        
The two choices and their issues exposed
          during the two week review on Can Transport vary across
          different receivers of a single configured subscription? are:

        

        
(1) Yes, Transport can vary by receiver

        

          
              Fewer subscriptions
          (scale benefit)

        

          
              Can convert transport
          without requiring an application to learn a multiple
          subscription ids

        

          
              No duplication of
          content during transport conversion.

        

          
              (Potential confusion in
          allowing transport to vary, but encoding not to vary?)

        

        
(2) No, only one Transport across all
          subscriptions

        

          
              Simpler model

        

          
              But applications may
          need to create and track multiple subscription-ids for the
          same content.

        

          
              Temporary duplication
          of content streams during transport change.

        

        
The current draft does (1).
          

        

        
Thanks,

        
Eric 

        

      

      

      

      

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


    

    

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


  



From nobody Tue Nov 14 21:12:34 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D499127058 for ; Tue, 14 Nov 2017 21:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvsJO7FNr57K for ; Tue, 14 Nov 2017 21:12:31 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E69401242EA for ; Tue, 14 Nov 2017 21:12:30 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B3BB4D63117A6 for ; Wed, 15 Nov 2017 05:12:27 +0000 (GMT)
Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 05:12:29 +0000
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.146]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 13:12:20 +0800
From: Rohit R Ranade 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] draft-ietf-netconf-rfc6536bis Query
Thread-Index: AdNdz9MehD+d0xYjTJ+ndshlR/LYrA==
Date: Wed, 15 Nov 2017 05:12:20 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B14687C@DGGEMA502-MBS.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_991B70D8B4112A4699D5C00DDBBF878A6B14687CDGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [Netconf]  draft-ietf-netconf-rfc6536bis Query
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:12:32 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6B14687CDGGEMA502MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

For the state-data in NACM like the below :

leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the server last restarted that a
            protocol operation request was denied.";
       }

"Number of times since the server" =3D=3D> Here the server is being referen=
ced to NETCONF server or RESTCONF server ?
Please note that the both the NETCONF server and RESTCONF server maybe usin=
g the same NACM configurations but the state-data maintained by each protoc=
ol maybe different.

With Regards,
Rohit R

--_000_991B70D8B4112A4699D5C00DDBBF878A6B14687CDGGEMA502MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


For the state-data in NACM like=
 the below :


 


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the server last restarted that =
a


       &nb=
sp;    protocol operation request was denied.";


       }


 


“Number of times since the server”
è=
 Here the server is being referenced to NETCONF server=
 or RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.<=
/span>


 


With Regards,=



Rohit R






--_000_991B70D8B4112A4699D5C00DDBBF878A6B14687CDGGEMA502MBSchi_--


From nobody Tue Nov 14 21:48:07 2017
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC21294E2 for ; Tue, 14 Nov 2017 21:48:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151072488560.25902.4387821250661937379.idtracker@ietfa.amsl.com>
Date: Tue, 14 Nov 2017 21:48:05 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] Milestones changed for netconf WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:48:05 -0000

Changed milestone "WGLC for YANG Library bis (as Standards Track)", set state
to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/netconf/about/


From nobody Tue Nov 14 22:37:16 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677D129508 for ; Tue, 14 Nov 2017 22:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 k-9DHpSnFqks for ; Tue, 14 Nov 2017 22:37:13 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DC6129503 for ; Tue, 14 Nov 2017 22:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17506; q=dns/txt; s=iport; t=1510727833; x=1511937433; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=S8BgqteCL/oPI8b3dTyNoeDGmv9u1AKPcqI5w8p38eE=; b=i7K4fBihNu580oXFDeo2OOeRgqJr523gNyfgCXp7NNS8GK9lnFos2Ep4 zulRL26eENz75n6UI9lv94e14Z9RhDZFzGyxdPqigd69dmd2Cc/WWmTpj GjKWOt+lK8IM48TtFyjeO5QLRcaloG8TX/30kAejuHuA2VC4a849ydTso g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQAo3wta/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJwedR4F9lmeCAQoYAQqESU8ChQFCFQEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAwEBK0EbAgEIFRAWBAcnCxQRAQEEARIIiTdkEKxyJop0AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDNIIHgVWBaYMqhGUBEgFVhUIFojQCh2uNEJNLjG2?= =?us-ascii?q?JEQIRGQGBOAE1IoEDcHoVSYJkgxGBTneGIw8YBIEIgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200";  d="scan'208,217";a="320775298"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 06:37:11 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vAF6bAoO002621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 06:37:11 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 01:37:10 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 01:37:10 -0500
From: "Eric Voit (evoit)" 
To: Balazs Lengyel , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQANNxaAAAgwZhA=
Date: Wed, 15 Nov 2017 06:37:10 +0000
Message-ID: <1070f8102560439fb254e32770e96040@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.215.19]
Content-Type: multipart/alternative; boundary="_000_1070f8102560439fb254e32770e96040XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 06:37:15 -0000

--_000_1070f8102560439fb254e32770e96040XCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Balazs,

From: Balazs Lengyel, November 15, 2017 12:01 AM


While I see no real need for different protocols for the same transport, I =
also any real reason to restrict this. I would vote for the draft to leave =
this to the implementations. Unless we have a good reason why make a stand =
pro or contra?

Let me try to reframe to make sure I have your points right...

As the question is only for configured subscriptions, some transport must b=
e defined.  Otherwise the path to the receiver cannot be established.  If w=
e leave it to the implementation, it would make more sense to allow for the=
 configuration of transport on a per-receiver basis.  This way either metho=
d can be supported.  I.e., it looks like favors option (1).

IMHO if we or an implementation allows transport conversion it is still not=
 guaranteed that no notifications are lost or duplicated.

If there is a single subscription, there are mechanisms available to addres=
s potential sources of duplication.  An example would be the "previous-noti=
fication-id" from draft-ietf-netconf-notification-messages.  With two subsc=
riptions, there will be no such constructs, and duplication by definition w=
ill occur when both are configured.  So this also seems to favor option (1)=
.

In case 2) will we would need to enforce the common transport in the model.

Yes.  Enforcing (2) would move the transport under the subscription rather =
than under the receiver.  This would preclude (1).   As your point above is=
 that we shouldn't artificially constrain things here, this seems to be a v=
ote for (1) over (2).

Thanks,

Eric

regards Balazs

On 2017-11-15 11:43, Eric Voit (evoit) wrote:

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/4



The two choices and their issues exposed during the two week review on "Can=
 Transport vary across different receivers of a single configured subscript=
ion?" are:



(1) Yes, Transport can vary by receiver

*        Fewer subscriptions (scale benefit)

*        Can convert transport without requiring an application to learn a =
multiple subscription ids

*        No duplication of content during transport conversion.

*        (Potential confusion in allowing transport to vary, but encoding n=
ot to vary?)



(2) No, only one Transport across all subscriptions

*        Simpler model

*        But applications may need to create and track multiple subscriptio=
n-ids for the same content.

*        Temporary duplication of content streams during transport change.



The current draft does (1).



Thanks,

Eric






_______________________________________________

Netconf mailing list

Netconf@ietf.org

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



--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

--_000_1070f8102560439fb254e32770e96040XCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Balazs,<=
/span>


 








From:=
 Balazs Lengyel, November 15, 2017 12:01 A=
M










While I see no real need for different protocols for the same transport,=
 I also any real reason to restrict this. I would vote for the draft to lea=
ve this to the implementations. Unless we have a good reason why make a sta=
nd pro or contra?


Let me try to reframe to make sure I have your points rig=
ht...


As the question is only for
configured subscriptions, some transport must be defined.  Otherw=
ise the path to the receiver cannot be established.  If we leave it to=
 the implementation, it would make more sense to allow
 for the configuration of transport on a per-receiver basis.  This way either method can be supported.  I.e., it looks=
 like favors option (1).


IMHO if we or an implementation allows transport conversion it is still =
not guaranteed that no notifications are lost or duplicated.


If there is a single subscription, there are mechanisms a=
vailable to address potential sources of duplication.  An example woul=
d be the “previous-notification-id” from draft-ietf-netconf-not=
ification-messages. 
 With two subscriptions, there will be no such constructs, and duplication =
by definition will occur when both are configured.  So this also seems=
 to favor option (1).



In case 2) will we would need to enforce the common transport in the mod=
el.


Yes.  Enforcing (2) would move the transport under t=
he subscription rather than under the receiver.  This would preclude (=
1).   As your point above is that we shouldn’t artificially
 constrain things here, this seems to be a vote for (1) over (2).


Thanks,


Eric


regards Balazs


 




On 2017-11-15 11:43, Eric Voit (evoit) wrote:






In the WG session tomorrow, I am hoping to get &#=
8220;hum feedback” on:


 


draft-ietf-netconf-subscribed-notifications =



https://github.com/netconf-wg/rf=
c5277bis/issues/4



 


The two choices and their issues exposed during t=
he two week review on “Can Transport vary across different receivers =
of a single configured subscription?” are:


 


(1) Yes, Transport can vary by receiver



·       
Fewer subscriptions (scale benefit)



·       
Can convert transport without requiring an a=
pplication to learn a multiple subscription ids



·       
No duplication of content during transport c=
onversion.



·       
(Potential confusion in allowing transport t=
o vary, but encoding not to vary?)


 


(2) No, only one Transport across all subscriptio=
ns



·       
Simpler model



·       
But applications may need to create and trac=
k multiple subscription-ids for the same content.



·       
Temporary duplication of content streams dur=
ing transport change.


 


The current draft does (1).  



 


Thanks,


Eric 


 











_______________________________________________


Netconf mailing list


Netconf@ietf.org

https://www.=
ietf.org/mailman/listinfo/netconf











-- 


Balazs Lengyel         &n=
bsp;            =
; Ericsson Hungary Ltd.


Senior Specialist


Mobile: +36-70-330-7909       &=
nbsp;      email: Balazs.Lengyel@ericsson.com 








--_000_1070f8102560439fb254e32770e96040XCHRTP013ciscocom_--


From nobody Wed Nov 15 02:03:15 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE512706D for ; Wed, 15 Nov 2017 02:03:14 -0800 (PST)
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 Gq1SOaXO825l for ; Wed, 15 Nov 2017 02:03:12 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BF3E81243FE for ; Wed, 15 Nov 2017 02:03:12 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id B715D1AE043A; Wed, 15 Nov 2017 11:03:11 +0100 (CET)
Date: Wed, 15 Nov 2017 11:03:11 +0100 (CET)
Message-Id: <20171115.110311.268174371353663424.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.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: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:03:14 -0000

"Eric Voit (evoit)"  wrote:
> In the WG session tomorrow, I am hoping to get "hum feedback" on:
> 
> 
> 
> draft-ietf-netconf-subscribed-notifications
> 
> https://github.com/netconf-wg/rfc5277bis/issues/4
> 
> 
> 
> The two choices and their issues exposed during the two week review on "Can Transport vary across different receivers of a single configured subscription?" are:
> 
> 
> 
> (1) Yes, Transport can vary by receiver
> 
> *        Fewer subscriptions (scale benefit)
> 
> *        Can convert transport without requiring an application to learn a multiple subscription ids
> 
> *        No duplication of content during transport conversion.
> 
> *        (Potential confusion in allowing transport to vary, but encoding not to vary?)
> 
> 
> 
> (2) No, only one Transport across all subscriptions
> 
> *        Simpler model
> 
> *        But applications may need to create and track multiple subscription-ids for the same content.
> 
> *        Temporary duplication of content streams during transport change.
> 
> 
> 
> The current draft does (1).

Actually, the github issue lists 3 options, but here you just list 2.

I think the point is that in the term "Transport", we need to include
both protocol and encoding (in the case the protocol supports multiple
encodings).


/martin


From nobody Wed Nov 15 07:12:13 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D3B12949B for ; Wed, 15 Nov 2017 07:12:11 -0800 (PST)
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 XQu1h_lIGNgH for ; Wed, 15 Nov 2017 07:12:09 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 65D16126579 for ; Wed, 15 Nov 2017 07:12:09 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 19E0B18215DC; Wed, 15 Nov 2017 16:10:48 +0100 (CET)
Received: from localhost (dhcp-9083.meeting.ietf.org [31.133.144.131]) by trail.lhotka.name (Postfix) with ESMTPSA id 4659B1820F78; Wed, 15 Nov 2017 16:10:44 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netconf\@ietf.org" ,  Andy Bierman , Martin Bjorklund , Kent Watsen 
In-Reply-To: 
References: 
Date: Wed, 15 Nov 2017 23:13:10 +0800
Message-ID: <874lpvpoc9.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 15:12:12 -0000

Hi Rob,

I am sorry for a late reply but I needed to re-check my earlier
proposal first. Essentially, it is quite similar to your second
schema-mount-friendly version, except that I also proposed to explicitly
specify the schema for each datastore. If several datastores share the
same schema, then it is possible to define it as one of the named schema
entries, and just refer to its name in each datastore description.

But I like your proposal, too. I think it would be a huge improvement,
and I am prepared to help with the draft.

Thanks, Lada

Robert Wilton  writes:

> Hi,
>
> Given some of the feedback related to the complexity of the YANG library=
=20
> bis structure, we have come up with two other possible structures for=20
> the YANG library data:
>
> (1) A simplified structure to make YANG library meet the NMDA=20
> requirements, but that is closer to the existing YANG library structure,=
=20
> and arguably simpler.
> (2) An enhanced version of the structure (1) above, that is also=20
> extended to allow the structure to be reused for schema-mount via an=20
> augmentation.
>
> For reference, at the end of this email, I have also included the tree=20
> diagram of the existing YANG library, and the current YANG library bis=20
> draft (draft-ietf-netconf-rfc7895bis-02) version.
>
> Considering the two new YANG library structures:
>
> ------------------------
>
> *(1) A simplified structure to make YANG library meet the NMDA=20
> requirements, but that is closer to the existing YANG library structure.*
>
> The main changes are:
> (i) Split "implemented modules" and "import-only-modules" into two=20
> separate lists, making the most important list (i.e. implemented=20
> modules) keyed by module name only and hence easier to reference.
> (ii) Assume modules are implemented in all datastores by default (with a=
=20
> "not-implemented-in" leaflist of datastores that a module is not=20
> implemented in).
> (iii) Assume that features are implemented in all datastores by default=20
> (with a "not-implemented-in" leaflist of datastores that a feature is=20
> not implemented in).
> (iv) Deleted module-sets.
> (v) Datastores are now just a list of supported datastores (that could=20
> potentially be extended with further per datastore properties in future).
>
> Manually generated tree output for proposed YANG library:
>
> module: ietf-yang-library
>  =C2=A0+--ro yang-library
>  =C2=A0=C2=A0=C2=A0 +--ro modules
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 revision-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0 y=
ang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro nam=
e=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro rev=
ision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro sch=
ema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datastor=
e properties.
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 identityref
>  =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st=
ring
>
> ------------------------------
>
> *(2) An enhanced version of the structure (1) above, that is extended to=
=20
> allow the structure to be reused for schema-mount via an augmentation.*
>
> This is similar to the structure above, except that the "the set of=20
> modules" is contained in a list of named schema (e.g. similar to the=20
> schema mount draft), allowing this structure to be re-used for schema mou=
nt.
>
> Schema mount would be expected to augment yang-library to add in the=20
> additional schema mount information.=C2=A0 In the tree diagram, I have sh=
own=20
> the schema-mount mount-point augmentation, but not including namespaces y=
et.
>
> Every server would be required to provide at least one schema in the=20
> schema list, and the primary schema for the device would always be given=
=20
> the name "primary".
>
> module: ietf-yang-library
>  =C2=A0+--ro yang-library
>  =C2=A0=C2=A0=C2=A0 +--ro schema* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 string
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 string
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 yang:revision-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0 y=
ang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=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-library/datastore/name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-point* [label]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro label=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=
--:(inline)
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0 +--ro inline?=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=C2=A0 +=
--:(use-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=C2=A0=C2=A0 +--ro use-schema* [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=C2=A0 +--ro 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=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
-> /yang-library/schema/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=C2=A0 +--ro parent-reference* yang:xpath1.0
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 |
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro 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 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name]
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro nam=
e=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro rev=
ision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
>  =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro sch=
ema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>  =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datastor=
e properties.
>  =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 identityref
>  =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st=
ring
>
> Please can you provide comments on these structures, in particular:
>
> Is this version better (i.e. simpler) that the version currently in=20
> draft-ietf-netconf-rfc7895bis-02 (below)?
>
> Should we try and make the structure extensible for schema-mount via=20
> augmentation (i.e. version (2)), or is it better that schema-mount has=20
> its own separate subtree?
>
> For reference only I have included the existing YANG library and YANG=20
> library bis draft tree diagrams.
>
> Thanks,
> Rob
>
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (3)=C2=A0 The current YANG library structure in YANG library bis=20
> (draft-ietf-netconf-rfc7895bis-02)
>
>     module: ietf-yang-library
>         +--ro yang-library
>            +--ro modules
>            |  +--ro module* [id]
>            |     +--ro id                  string
>            |     +--ro name                yang:yang-identifier
>            |     +--ro revision?           revision-identifier
>            |     +--ro schema?             inet:uri
>            |     +--ro namespace           inet:uri
>            |     +--ro feature*            yang:yang-identifier
>            |     +--ro deviation* [module]
>            |     |  +--ro module    -> ../../id
>            |     +--ro conformance-type    enumeration
>            |     +--ro submodule* [name]
>            |        +--ro name        yang:yang-identifier
>            |        +--ro revision?   revision-identifier
>            |        +--ro schema?     inet:uri
>            +--ro module-sets
>            |  +--ro module-set* [id]
>            |     +--ro id        string
>            |     +--ro module*   -> ../../../modules/module/id
>            +--ro datastores
>            |  +--ro datastore* [name]
>            |     +--ro name          identityref
>            |     +--ro module-set
>            |             -> ../../../module-sets/module-set/id
>            +--ro checksum       string
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (4)=C2=A0 The current YANG library structure (RFC 7895)
>
>        +--ro modules-state
>           +--ro module-set-id    string
>           +--ro module* [name revision]
>              +--ro name                yang:yang-identifier
>              +--ro revision            union
>              +--ro schema?             inet:uri
>              +--ro namespace           inet:uri
>              +--ro feature*            yang:yang-identifier
>              +--ro deviation* [name revision]
>              |  +--ro name        yang:yang-identifier
>              |  +--ro revision    union
>              +--ro conformance-type    enumeration
>              +--ro submodule* [name revision]
>                 +--ro name        yang:yang-identifier
>                 +--ro revision    union
>                 +--ro schema?     inet:uri
>

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov 15 07:37:13 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8D1241FC for ; Wed, 15 Nov 2017 07:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z1mjol4GTv0 for ; Wed, 15 Nov 2017 07:37:11 -0800 (PST)
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 24E2A1200FC for ; Wed, 15 Nov 2017 07:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2186; q=dns/txt; s=iport; t=1510760231; x=1511969831; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cc0vLgidOLoy01tQHVIyCubUo59ZqOxxjaACNFWdzXc=; b=TqcKqEH/eGmXzI8tkTGsRSOcQ8HPqyvuUhPXN++2pq1ZrJ0riN4UrmOq 2esH5GxhdvHTtaBnb2PVpBKCfg9REr+oBc19MXCezUuOl1Tgb/txNKz7L SW8hmBNMaqandCuDvkCG/oDBJjp7D8cqigALjHKAsmQeH8kDcOj68rxXr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQCmXQxa/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB502gX2WXYIRCiOFGAKFDkAXAQEBAQEBAQEBayiFHgE?= =?us-ascii?q?BAQMBOj8FCwIBCA4HAw0RBQQHMhQRAQEEDgUIihQIEKpKixMBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYM0ggeBVYUTixAFojcCh2uNEJNNjG+JEgIRGQGBOAEhAjS?= =?us-ascii?q?BdHoVSYJkgxGBTneJTCuBCIERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,399,1505779200"; d="scan'208";a="310562788"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 15:37:10 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAFFbA7k008836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 15:37:10 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 10:37:09 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 10:37:09 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7A=
Date: Wed, 15 Nov 2017 15:37:09 +0000
Message-ID: <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com> <20171115.110311.268174371353663424.mbj@tail-f.com>
In-Reply-To: <20171115.110311.268174371353663424.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.215.19]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 15:37:12 -0000

Hi Martin,

> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>
> "Eric Voit (evoit)"  wrote:
> > In the WG session tomorrow, I am hoping to get "hum feedback" on:
> >
> >
> >
> > draft-ietf-netconf-subscribed-notifications
> >
> > https://github.com/netconf-wg/rfc5277bis/issues/4
> >
> >
> >
> > The two choices and their issues exposed during the two week review on
> "Can Transport vary across different receivers of a single configured
> subscription?" are:
> >
> >
> >
> > (1) Yes, Transport can vary by receiver
> >
> > *        Fewer subscriptions (scale benefit)
> >
> > *        Can convert transport without requiring an application to lear=
n a
> multiple subscription ids
> >
> > *        No duplication of content during transport conversion.
> >
> > *        (Potential confusion in allowing transport to vary, but encodi=
ng not
> to vary?)
> >
> >
> >
> > (2) No, only one Transport across all subscriptions
> >
> > *        Simpler model
> >
> > *        But applications may need to create and track multiple
> subscription-ids for the same content.
> >
> > *        Temporary duplication of content streams during transport chan=
ge.
> >
> >
> >
> > The current draft does (1).
>=20
> Actually, the github issue lists 3 options, but here you just list 2.

In reviewing tomorrow's slides with Mahesh, he preferred 2 options.   And a=
s varying the encoding by receiver seems unlikely in implementation, there =
is little reason to socialize this unlikely variant before the whole WG.   =
Since as your opinion was either both encoding and transport or neither enc=
oding and transport vary by receiver, the more likely of your primary ask i=
s supported. =20

=20
> I think the point is that in the term "Transport", we need to include bot=
h
> protocol and encoding (in the case the protocol supports multiple
> encodings).

While most likely the case for NETCONF and RESTCONF, Tianran's draft-ietf-n=
etconf-udp-pub-channel shows that there can be encoding variation by transp=
orts .   It Therefore it seems better to let them both vary independently. =
 .

Eric

> /martin


From nobody Wed Nov 15 07:43:02 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA812940A for ; Wed, 15 Nov 2017 07:43:00 -0800 (PST)
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 bQDZOHodmDMz for ; Wed, 15 Nov 2017 07:42:53 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0D124C27 for ; Wed, 15 Nov 2017 07:42:49 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 15AD11AE0311; Wed, 15 Nov 2017 16:42:48 +0100 (CET)
Date: Wed, 15 Nov 2017 16:42:47 +0100 (CET)
Message-Id: <20171115.164247.1419508866071356464.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com> <20171115.110311.268174371353663424.mbj@tail-f.com> <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.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: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 15:43:01 -0000

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> >
> > "Eric Voit (evoit)"  wrote:
> > > In the WG session tomorrow, I am hoping to get "hum feedback" on:
> > >
> > >
> > >
> > > draft-ietf-netconf-subscribed-notifications
> > >
> > > https://github.com/netconf-wg/rfc5277bis/issues/4
> > >
> > >
> > >
> > > The two choices and their issues exposed during the two week review on
> > "Can Transport vary across different receivers of a single configured
> > subscription?" are:
> > >
> > >
> > >
> > > (1) Yes, Transport can vary by receiver
> > >
> > > *        Fewer subscriptions (scale benefit)
> > >
> > > *        Can convert transport without requiring an application to learn a
> > multiple subscription ids
> > >
> > > *        No duplication of content during transport conversion.
> > >
> > > *        (Potential confusion in allowing transport to vary, but encoding not
> > to vary?)
> > >
> > >
> > >
> > > (2) No, only one Transport across all subscriptions
> > >
> > > *        Simpler model
> > >
> > > *        But applications may need to create and track multiple
> > subscription-ids for the same content.
> > >
> > > *        Temporary duplication of content streams during transport change.
> > >
> > >
> > >
> > > The current draft does (1).
> > 
> > Actually, the github issue lists 3 options, but here you just list 2.
> 
> In reviewing tomorrow's slides with Mahesh, he preferred 2 options.
> And as varying the encoding by receiver seems unlikely in
> implementation

Why is this unlikely?  Suppose I have two receivers for the same
subscription, one wants NETCONF/XML and the other RESTCONF/JSON.  Is
that unlikely?

> , there is little reason to socialize this unlikely variant before
> the whole WG.   Since as your opinion was either both encoding and
> transport or neither encoding and transport vary by receiver, the
> more likely of your primary ask is supported.
> 
>  
> > I think the point is that in the term "Transport", we need to include both
> > protocol and encoding (in the case the protocol supports multiple
> > encodings).
> 
> While most likely the case for NETCONF and RESTCONF, Tianran's
> draft-ietf-netconf-udp-pub-channel shows that there can be encoding
> variation by transports .   It Therefore it seems better to let them
> both vary independently.

Not sure I understand what you mean.  To be clear, do you think the
"encoding" leaf should stay where it is, or be moved down to the
receiver, as a sibling to "protocol"?


/martin


From nobody Wed Nov 15 11:12:31 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA551271DF for ; Wed, 15 Nov 2017 11:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yzePdUm46TDj for ; Wed, 15 Nov 2017 11:12:27 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99F2127005 for ; Wed, 15 Nov 2017 11:12:26 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id 73so13153828lfu.10 for ; Wed, 15 Nov 2017 11:12:26 -0800 (PST)
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=4M9N2ZfajRsYFH7pM29IfaOCMAARY04yiSLf27B9uVg=; b=PnZCg6StMDYnlxh9YSV8QXIzBoZOBYx4o3WkaFto8Cq4qKykIKJf1CTHmb7GukTFOT vXa6+VhXEfkh72pJv2rmneq0KRz+d3X9EoyY4H58KS58EGOtSKUYlqRlNKUFagL+/rdr WQK12HUusgGi04gLOsZ560wrwxvh/WRn4r1TmM5T91mBbbHznQ2o9ifNakCqkL14Ul1D UU+H+eFnY+RvVelsRMDcgwAFx8bq2VvCA4wbPBKy/uNkr/Rij8wNEtZx+RDZLlG8EoK5 nn9WOoKwIlbpuuRyoUDHvjUFsp3vxJUrtZtvR1b6CM9WsX3FVAFNmx5nXfr+yGOgVdIO 7LqA==
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=4M9N2ZfajRsYFH7pM29IfaOCMAARY04yiSLf27B9uVg=; b=HJYbVWqkeD5u9Y4rfBL9L4JLvctlFVMP9w5oOrNWsnefBNgMLIIHnv4dnikWyJ4nLl rQFtGpOpMNj0IZjc1NtziyXLH101CjeNH0/dSwag8Yrk+hBEWYMcjcpgcQBCX6QTSrJo FRpzX+NjZRG6wC9YtXgpq4R6/GHavuvfpv7JYNtgKEz2JuXOPU1z+nzvAQu3c5BRf2Ur jR7EaOHfNot92hS34AH4JKLU66bJgZ11l9reSRZ0ap9aTUPgSlxicjCCA1GT3Cd0gbk5 ZjQ7gIShetSmiSOx1KwRhqanSCNBDNpnSfjQ9W74hJYNCqegzdLBumr06/qUQCYeocnw LYAA==
X-Gm-Message-State: AJaThX4FFVme3QoHlTgS//v1lqQsjl+pKoQOb2U3fn6g5D1Cxiqrlq2i KO6EKQZqqz6GBYrjyY4RdC3eagR9ydFibOfRkovK2w==
X-Google-Smtp-Source: AGs4zMYK+UwEfGs8Wk0iscfUozMqgu0BRzVt+3O7lTdhfjHLjjRwAZz6IZ7AajF0wIK7PStqYHVqSgCn8Rct3pBlwRU=
X-Received: by 10.46.57.25 with SMTP id g25mr1787797lja.36.1510773144825; Wed, 15 Nov 2017 11:12:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 15 Nov 2017 11:12:23 -0800 (PST)
In-Reply-To: <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>
From: Andy Bierman 
Date: Wed, 15 Nov 2017 11:12:23 -0800
Message-ID: 
To: Mahesh Jethanandani 
Cc: Martin Bjorklund , sec-ads@ietf.org, netconf , Eric Rescorla 
Content-Type: multipart/alternative; boundary="089e082f29c4a255e4055e0a48bf"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:12:30 -0000

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

Hi,

I updated the draft with these changes on github.
There is a draft-pre-09.txt file now for you to review.


Andy


On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Andy,
>
> I assume you will incorporate these changes in the -09 version of the
> draft.
>
> However, I am unable to review the changes in github. Can you post the
> diffs of the draft w.r.t. -08 version.
>
> That still leaves us with one issue, and that has to do with the what
> permission to give edit-operation. I am assuming the WG agrees that makin=
g
> the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 for edit=
 operations makes maintenance more
> difficult and makes the operation more vulnerable, unless all the deny
> rules are in place.
>
> We will need to update the security considerations section to address
> Eric=E2=80=99s concerns. How about this update?
>
> OLD:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances.
>
>
> NEW:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances. In particular
>
> servers should not expose instance information before validating field
>
> information.
>
>
> Cheers.
>
> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund  wrote:
>
> Hi,
>
> I just read this thread, and I agree with the changes, but see below
> for a comment.
>
>
> Andy Bierman  wrote:
>
> Hi,
>
> Here are some proposed edits to make the data rule consistent with the
> examples.
> Note that this issue is not related to the edit in the original 1-week
> change.
>
>
> sec. 3.3.5:
>
> OLD:
>
>
>      data node rule:  controls access for a specific data node, identifie=
d
>      by its path location within the conceptual XML document for the
>      data node.
>
>
> NEW:
>
>      data node rule:  controls access for a specific data node and its
> descendants,
>      identified by its path location within the conceptual XML document
> for the
>      data node.
>
>
> sec 3.4.5, step 6, bullet 2:
>
>
> OLD:
>
>        *  The rule does not have a "rule-type" defined or the "rule-
>           type" is "data-node" and the "path" matches the requested
>           data node, action node, or notification node.
>
>
> NEW:
>
>
>        *  The rule does not have a "rule-type" defined or the "rule-
>           type" is "data-node" and the "path" matches the requested
>           data node, action node, or notification node. A path is
>           considered to match if the current data node is the data node
>           specified by the path, or is a descendant data node of this
>           data node.
>
>
> I propose:
>
>             The rule does not have a "rule-type" defined or the
>             "rule-type" is "data-node" and the "path" matches the
>             requested data node, action node, or notification node.
>             A path is considered to match if the requested node
>             is the node specified by the path, or is a
>             descendant node of the path.
>
> Note:  s/current node/requested node/ which is the term used in the
> first sentence.  And then s/data node/node/ since the first sentence
> refer to data-, action-, and notification node.
>
> I have checked in this fix in the repo.
>
>
> /martin
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>

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


Hi,

I updated the draft with these chan=
ges on github.
There is a draft-pre-09.txt file now for you to re=
view.


Andy


On Tue, Nov 14,=
 2017 at 5:05 PM, Mahesh Jethanandani <mjethanandani@gmail.com&g=
t; wrote:
Andy,

I assume you will incorporate these ch=
anges in the -09 version of the draft.

However, I =
am unable to review the changes in github. Can you post the diffs of the dr=
aft w.r.t. -08 version.

That still leaves us with =
one issue, and that has to do with the what permission to give edit-operati=
on. I am assuming the WG agrees that making the change from =E2=80=98none=
=E2=80=99 to =E2=80=98read=E2=80=99 for edit operations makes maintenance m=
ore difficult and makes the operation more vulnerable, unless all the deny =
rules are in place.

W=
e will need to update the security considerations section to address Eric=
=E2=80=99s concerns. How about this update?

OLD:
Ther=
efore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

NEW:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
=

servers shoul=
d not expose instance information before validating field
information.

Cheers.

On Nov 13,=
 2017, at 11:28 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

Hi,

I just read this thread,=
 and I agree with the changes, but see below
for a comment.


Andy Bie=
rman <andy@yum=
aworks.com> wrote:
Hi,

Here are some proposed edits to make the data rule=
 consistent with the
examples.
Note that this issue is not related to=
 the edit in the original 1-week
change.


sec. 3.3.5:

O=
LD:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data node rule: =C2=A0controls=
 access for a specific data node, identified
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0by its path location within the conceptual XML document for the
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0data node.


NEW:

=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0data node rule: =C2=A0controls access for a specific data=
 node and its
descendants,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0identified b=
y its path location within the conceptual XML document
for the
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0data node.


sec 3.4.5, step 6, bullet 2:<=
br>

OLD:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* =C2=A0Th=
e rule does not have a "rule-type" defined or the "rule-
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type" is &=
quot;data-node" and the "path" matches the requested
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data node, action =
node, or notification node.


NEW:


=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0* =C2=A0The rule does not have a "rule-type&qu=
ot; defined or the "rule-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0type" is "data-node" and the "path=
" matches the requested
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0data node, action node, or notification node. A path is=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0considered to=
 match if the current data node is the data node
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0specified by the path, or is a desce=
ndant data node of this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0data node.

=
I propose:

=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The rule does not have a=
 "rule-type" defined or the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0"rule-type" is "data-node" and the "path" =
matches the
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0requested data node, act=
ion node, or notification node.
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A p=
ath is considered to match if the requested node
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0is the node specified by the path, or is a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0descendant node of the path.

Note: =C2=A0s/current node/requested node/ which is the =
term used in the
first sentence.=
=C2=A0 And then s/data node/node/ since the first sentence
refer to data-, action-, and notification node.<=
/span>

I have checked in this fix in the =
repo.


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/netconf



Mahesh Jethanandani








--089e082f29c4a255e4055e0a48bf--


From nobody Wed Nov 15 11:33:15 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090F81271DF for ; Wed, 15 Nov 2017 11:33:14 -0800 (PST)
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 aLXpdZuvD8Kt for ; Wed, 15 Nov 2017 11:33:11 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 09E901200C1 for ; Wed, 15 Nov 2017 11:33:11 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F3F11AE0311; Wed, 15 Nov 2017 20:33:09 +0100 (CET)
Date: Wed, 15 Nov 2017 20:33:09 +0100 (CET)
Message-Id: <20171115.203309.1678677652045096446.mbj@tail-f.com>
To: evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <4541edddbd0741468298d7c83db84001@XCH-RTP-013.cisco.com> <20171018.105758.127713561892235408.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: [Netconf] Martin's thoughts on subscribed-notifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:33:14 -0000

Hi,

I have reviewed draft-ietf-netconf-subscribed-notifications-07,
specifically to ensure that my earlier comments are addressed.  Here
are my new comments:



o  General

  The document uses the term "RPC" to refer to the operations that
  affect dynamic subscriptions.  I think that this term is not quite
  correct.  For example the text says:

      a configured subscription cannot be modified or deleted using
      RPC.

  But this is not correct, I can delete a configured subscription with
  the  rpc.


o  Section 1.2

  What is "RPC subscription state signaling messages"?


o  Section 2.2

     The subsets of these filtering syntaxes supported are
     left to each implementation.

   Juergen has already pointed out that this is not good design - how
   will the client know which subset of subtree filtering a certain
   device supports?  I think that if the server doesn't support
   subtree filtering as defined, then it should not advertise the
   "subtree" feature.  It can always advertise another feature.


o  Section 2.3

  The state diagram shows an arrow "modify" from "suspended" to
  "active".  Is this really correct?  Will a suspended subscription be
  resumed if it is modified?  If so, this is not correct:

    o  Suspend and resume state changes are driven by internal process
       and prioritization.  There are no external controls over suspend
       and resume.


o  Section 3

  The data model is not yet converted to NMDA single tree (and there
  is no issue that tracks this).


o  Section 4.1.1

     Not all streams will support replay.  Those that do MUST include
     they do via the "replay-support" object.

  The second sentence still looks odd.  I propose:

    If a stream supports replay, the "replay-support" leaf is present
    in the "/streams/stream" list entry for the stream.


o  Section 4.4

     An operator may find subscription
     identifiers which may be used with "kill-subscription" by searching
     for the ip address of a receiver within the yang tree.

  s/within the yang tree/in the "subscription" list"/

  or something along those lines.


o  Section 5

     o  One or more receiver IP addresses (and corresponding ports)
        intended as the destination for notification messages for each
        subscription.  In addition, the transport for each destination MAY
        be defined.

   Since the transport is mandatory in the data model, the last
   sentence should be removed.


o  Section 5.1

  The text in -07 is an improvement over -05.  But there are still
  some things that needs to be specified.

  The text needs to discuss what's supposed to happen if a transport
  session goes down.  Will the server re-establish the session?  Will
  it buffer events during this time?  What happens if the call home
  setup due to authentication issues, will it still try to
  re-establish?

  The new text says:

     Note that is possible to configure replay on a configured
     subscription.  This is to allows a configured subscription to
     exist on a system so that event records generated during boot can
     be buffered and pushed as soon as the transport session is
     established.

  I assume this means that the reciever must be prepared to receive
  the same events multiple times?  (if the server reboots before the
  replay buffer has been overwritten)


o  Section 9.2

  s/yang/YANG/


  Also, the text says:

    In addition support for optional features: encode-xml,
    encode-json, configured, and replay MUST also be indicated if
    supported.

  I think you should remove this sentence; it is redundant.  If you
  decide to keep it, write:


    In addition support for optional features: "encode-xml",
    "encode-json", "configured", "replay", "xpath", and "subtree" MUST
    also be indicated if supported.


  BTW, why did you rename "configured-subscriptions" to "configured"?
  "configured" looks a bit short.


o  10 - extension

     extension subscription-state-notif {

  I think you should spell out "notification"; i.e., use
  subscription-state-notification.

  (You replied "will do" to this comment in my previous review, so I
  suspect you simply forgot this one)


o  10 - filter-spec

  I think both the subtree and XPath filters are not correctly
  defined.  I provided text about the XPath filter, but you didn't
  include it, so here it is again, updated with your text about
  events.

      anydata subtree-filter {
        description


  OLD:

          "Event stream evaluation criteria encoded in a syntax of a
           supported type of an RFC 6241, Section 6 filter.  The subtree
           filter is applied to the representation of individual,
           delineated event records as contained within the event
           stream.  For example, if the notification message contains an
           instance of a notification defined in YANG, then the top-
           level element is the name of the YANG notification.  If the
           stream filter matches an event record from the stream, the
           event record should be included in a notification message
           to the receiver(s).";
      }

  NEW:

          "Event stream evaluation criteria encoded in the syntax of
           a subtree filter as defined in RFC 6241, Section 6.

           The subtree filter is applied to the representation of
           individual, delineated event records as contained within
           the event stream.  For example, if the notification message
           contains an instance of a notification defined in YANG,
           then the top-level element is the name of the YANG
           notification.

           If the subtree filter returns a non-empty node set, the
           filter matches the event record, and the it is included in
           the notification message sent to the receivers.";

        reference "RFC 6241, Section 6.";
      }

  and:

      leaf xpath-filter {
        type yang:xpath1.0;
        description

  OLD:

          "Event stream evaluation criteria encoded in a syntax of xpath
           1.0 and applied against an event stream. The result of
           applying XPath expression is converted to a boolean value
           using the standard XPath 1.0 rules.  If the boolean value is
           'true', the stream filter matches an event record within the
           stream, and the notification message should be sent to the
           receiver(s).";

  NEW:

          "Event stream evaluation criteria encoded in the syntax of
           an XPath 1.0 expression.

           The XPath expression is evaluated on the representation of
           individual, delineated event records as contained within
           the event stream.  For example, if the notification message
           contains an instance of a notification defined in YANG,
           then the top-level element is the name of the YANG
           notification, and the root node has this top-level element
           as the only child.

           The result of the XPath expression is converted to a
           boolean value using the standard XPath 1.0 rules.  If the
           boolean value is 'true', the filter matches the the event
           record, and the it is included in the notification message
           sent to the receivers.

           The expression is evaluated in the following XPath context:

             o  The set of namespace declarations are those in scope on
                the 'xpath-filter' leaf element where th

             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 root node.

        reference
          "http://www.w3.org/TR/1999/REC-xpath-19991116
           RFC 7950, Section 10.";
      }



o  10 - grouping notification-origin-info

  In your reply tpo my previous review, you wrote that you would
  remove the term "push source".  It is still used.




/martin






From nobody Wed Nov 15 11:39:19 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA551271DF for ; Wed, 15 Nov 2017 11:39:18 -0800 (PST)
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 in9mcLwmCB58 for ; Wed, 15 Nov 2017 11:39:15 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCBB1200C1 for ; Wed, 15 Nov 2017 11:39:14 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id D9F8E1AE0311; Wed, 15 Nov 2017 20:39:13 +0100 (CET)
Date: Wed, 15 Nov 2017 20:39:13 +0100 (CET)
Message-Id: <20171115.203913.2068438246599432509.mbj@tail-f.com>
To: evoit@cisco.com
Cc: kwatsen@juniper.net, alexander.clemm@huawei.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.cisco.com>
References: <20171023.144114.150465814300377965.mbj@tail-f.com> <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com> <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.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: [Netconf] two-week review of drafts related to notifications and subscriptions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:39:18 -0000

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> Hi Kent,
> 
> Ensuring comments are covered.  I do ask a question on potential model
> partitioning across the document in the first set of comments..,
> 
> > From: Martin Bjorklund, October 23, 2017 8:41 AM
> > 
> > Hi,
> > 
> > Some comments inline.
> > 
> > "Eric Voit (evoit)"  wrote:
> > > Hi Kent,
> > >
> > > > From: Kent Watsen, October 19, 2017 9:51 PM
> > > >
> > > > >> draft-ietf-netconf-subscribed-notifications-05
> > > > >> ------------------------------------------------------
> > > >
> > > > >> very complicated (many details).
> > > > >
> > > > > If there anything you see as unnecessary, or perhaps should be 
> > > > > optional?
> > > >
> > > > The tree diagram is huge.  I understand that much of it is from 
> > > > grouping expansion, but still, there is a lot to consider (many 
> > > > details).  I'm just thinking that this is going to take time for 
> > > > folks to digest fully.
> > >
> > > We really made an attempt to simplify the tree by using a 
> > > filter-type object instead of the explicit subtyping.  But 
> > > experienced and capable reviewers argued that explicit subtyping was 
> > > better.  The result is that we returned to the larger explicitly 
> > > subtyping a couple weeks ago.  Overall, this added 25% to the tree
> > > diagram size :-(.
> > 
> > I don't think a big tree in itself necessarily means that the data
> > model is bad.
> > However, for readability purposes, you may want to split the big tree 
> > into smaller pieces.  See for example RFC 7404.
> 
> I think you mean RFC 7407?

Yes.

> We can do this.  Before I make the change, I want to confirm that it
> should be only done for individual RPCs and Notifications, and top
> level containers in the data trees (e.g. streams and filters top level
> container).

I think that would be sufficient.

> I would also like to confirm that you are ok with all the
> downsides (1)-(4) listed below.
> 
> (1) To what section of subscribed-notifications do you look to when
> you are doing an augmentation in yang-push?  Having one tree to go to
> in one full tree is easier than finding info across split trees.
> I.e., a single tree is pretty useful for outside referencing on
> augmentations.

The purpose of the tree is to get an overview of the basic structure
of the model.  It is not the normative reference that you need to
fully understand everything - that would be the module itself.

> (2) YANG Push does not have section partitions for existing
> subscribed-notification RPCs and Notifications.  Therefore we couldn't
> do the exact same segmentation of the tree structures across the two
> documents.  (I.e. it won't be a 1:1 comparison when looking between
> the drafts.)

I haven't yet reviewed YANG Push, but I don't think this will be an
issue.

> (3) Segmentation lower that any top level container is not
> recommended.

By whom?

> This is because augmentations occur at different levels
> of the tree.  Any other approach would mean tree information
> replicated in different tree diagrams.

I don't think that's a problem.

> (4)  It will increase the size of an already big document.

Probably not by much, and if it helps people to better understand this
model, I think it is worth it.


/martin


> Based on this, I still think a single model is better.  But I am happy
> to make the change if consensus is otherwise.
>  
> > > > >>         flow difficult to read.
> > > > >
> > > > > Anything specific?  I am happy to re-order as suggested.
> > > >
> > > > Also, I'm suspecting that the update from Martin's comments will 
> > > > get much of this.  It just seemed that every time tried to chase 
> > > > some bit of information down, it wasn't stated quite right (e.g., 
> > > > terminology, phasing, open-endedness, etc.).  All this got in the 
> > > > way of the readability.
> > >
> > > Hopefully I got the ones which don't resonate.  My natural ecosystem 
> > > is deeper in the router, and YANG means I need to use different terms.
> > >
> > > > >> * what is "promise theory based interaction model"?  
> > > > >> (reference?)
> > > > > Yes, I will add the reference.  The best on-line one I know is:
> > > > >
> > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__markburgess.
> > > > > or
> > > > > g_Pr
> > > > > omiseMethod.pdf&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > > > ndb3voDTXcWzoCI
> > > > >
> > > >
> > &r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=zDualRWvSwyZj8MF
> > > > PL_Xo
> > > > >
> > > >
> > pkywEp9xEJgZXjyhdIBPog&s=Dcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2xpE
> > > > Oc0o&e
> > > > > =
> > > >
> > > > Oh my, that document is 38 pages, I was hoping for simple 
> > > > statement (e.g., the system takes defensive measures in order to 
> > > > ensure resources are available).  I think you have something like 
> > > > this in the yang-push draft.
> > >
> > > I can add a simple statement.  Something like "voluntary cooperation 
> > > between individual, autonomous agents who continuously refine their 
> > > changing intentions to one another in the form of promises".
> > 
> > Does this really help people to understand this document?
> 
> I didn't such a statement helped either, so all references in
> subscribed-notifications have been removed.  As this is important in
> yang-push, I tweaked the reference section 3.4 with the kind of info I
> think Kent wanted in his simple statement.
> 
> > > > >> * what is the relationship between streams here and in 5277?
> > > > >
> > > > > This document doesn't discuss the details of how streams are 
> > > > > generated within the publisher like 5277 does.  This detail is 
> > > > > not necessary for the external interface definition.
> > > > >
> > > > > That said, how to handle/encode names of the streams, the 
> > > > > managed objects, the ability to filter, etc. are identical.
> > > >
> > > > This document should explain the relationship though, right? (see
> > > > above)
> > >
> > > Is this necessary in the normative part of the document?  When the 
> > > notification-messages draft is complete, it will be possible to 
> > > obsolete RFC-5277 at some later date.  How many linkages are 
> > > appropriate?
> > >
> > > What I did do in the new version (per Martin's request) is to place 
> > > in Appendix A: Relationship to RFC-5277.  What I believe we should 
> > > do is place statements identifying the re-used stream constructs.  
> > > Would that work?
> > 
> > I think such a section is needed, and I think it shouldn't be an 
> > Appendix, but rather one of the first sections.  This is quite common 
> > in RFCs that updates/obsoletes older RFCs.
> 
> Done.  See Section 1.4.  Relationship to RFC-5277
> 
> > > > >> * streams here are identities, unlike "streamNameType"
> > > > >> (aka xs:string) in 5077.  Is this an issue?
> > > > >
> > > > > Based on Martin's comments that he desires to retain the ability 
> > > > > for streams to be spun up possibly during run-time, we have 
> > > > > returned to using string for streams (as we did in earlier
> > > > > versions of the draft).   Our switch to identities several
> > > > > months ago was one attempt we made to simplify things, but
> > > > > it didn't work out.    This is an issue and a resolution we
> > > > > have long been anticipating.
> > > >
> > > > okay
> > > >
> > > >
> > > > >> * use of " operations" for configured 
> > > > >> subscriptions is confusing.
> > > > >
> > > > > It is just a normal configuration.  I will happily delete the 
> > > > > example if you think it unnecessary or redundant.
> > > >
> > > > No, the examples are good.  It's literally the words 
> > > > " operations"
> > > > are problematic.  Use some other phrasing that is not 
> > > > NETCONF-specific.
> > >
> > > I will just use 'configuration operations'
> > >
> > > > >> * the example in s5.1 seems to be more about how to create a 
> > > > >> configured subscription than establishing a subscription 
> > > > >> connection
> > > > >
> > > > > Exactly.  How to establish the subscription connection is 
> > > > > transport specific, and therefore in the netconf-notif draft.
> > > > > Specifically in Section 3.4.3
> > > >
> > > > But the section is called "Establishing a Configured Subscription".
> > > > I think this actually goes to your use of the word "establish", 
> > > > perhaps "create" is a better word - "Creating a Configured
> > > > Subscription" ?
> > >
> > > Will do.  No reason to reuse the establish if it confuses people.
> > >
> > > > >> * Section 7 says "This notification message MAY be encoded as 
> > > > >> one-way notification element of [RFC5277], Section 4."  If this 
> > > > >> is a MAY, how does the client know what it received?  And how 
> > > > >> does the publisher know what format to send?
> > > > >
> > > > > I was trying to lay the groundwork for a future support of 
> > > > > notification-messages in a way that this document wouldn't have 
> > > > > to be updated.  I have given up on that.  Support is now a MUST.  
> > > > > And this will need to be revised in the future when we get 
> > > > > notification-messages to an RFC state.
> > > >
> > > > okay
> > > >
> > > >
> > > > >> * xpath-filter is not a feature-based option?
> > > > >
> > > > > Not feature based.  Of course if the syntax is not supported on 
> > > > > a filter, the subscription will be rejected with the error 
> > > > > "filter-type-unsupported ".
> > > > >
> > > > > At this point, I don't recall anyone suggesting xpath should not 
> > > > > be a mandatory for event filtering though.
> > > >
> > > > well, it's not mandatory for NETCONF-based filtering.  So, a 
> > > > system that doesn't support XPath filtering in NETCONF would have 
> > > > to support XPath filtering here?
> > >
> > > Hmm.  I had been hoping to have at least one (xpath) as mandatory.
> > > But maybe that is unrealistic.
> > >
> > > What I am thinking is that maybe both filters should be optional 
> > > features.  And then specific transport drafts (like NETCONF) can 
> > > identify them as mandatory. At least when that transport is used.
> > >
> > > > >> * I see top-level /subscription-config and /subscriptions - is 
> > > > >> this NMDA compliant?
> > > > >
> > > > > As this pre-dates NMDA, we are awaiting the "you MUST make the 
> > > > > conversion" directive.  And if this comes, we will gladly do that.
> > > >
> > > > https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSIoH
> > > > 4g
> > > > A-8M
> > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sectio
> > > > n-
> > > > 4.23.3
> > >
> > > Yep.  We do fall in the SHOULD category :-)
> > >
> > > But seriously, we can convert.
> > 
> > Before doing anything, make sure the "subscription-id" issue is 
> > resolved first.  If Rob's proposal is adopted, we will still need two 
> > lists, one config and one operational, even in the NMDA-compliant 
> > version.  Some changes might be needed in the naming of top-level
> > containers though.
> 
> Based on the comments received on the subscription-id datatype.  Rough
> consensus is integer.  We will covert to NMDA after all other issues
> are closed in set of drafts going to WGLC.
> 
> Eric
> 
> > > The question is how to do this without losing our place in the 
> > > review queue.  We had expected to be through WGLC *long* before NMDA 
> > > was formalized.  And we are very concerned this policy change could 
> > > result in further delay.  So the current plan we have is to get 
> > > agreement on the contents of the model.  And then agreement that we 
> > > have converted what is an acceptable model into an equivalent NMDA
> > > version.
> > 
> > 
> > /martin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Wed Nov 15 13:53:51 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB711250B8 for ; Wed, 15 Nov 2017 13:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeCFKH9tU9SI for ; Wed, 15 Nov 2017 13:53:47 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD49127B60 for ; Wed, 15 Nov 2017 13:53:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3457; q=dns/txt; s=iport; t=1510782810; x=1511992410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4fAjfOpyNYrt/vMMPKQWLmwWjxk7e6bQfnxKTsXGvjw=; b=OgAqjBtMF0PvlUW6JWLrKK2gux72IQwvGLzwD2i/EDimJSdFMdivzMjX 3OtKFLamcMqdzXPfFe/wLs1CJzLCf9Oqe+WYLjbZeWwmXk2lcv5i4asyY tQSsSCNpWmKzu3tzuQnNVrMG2wdzO3E563s7ItJxNJvbqQtQKcS57vdD+ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQAftgxa/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB503gX2YbgojhRgChQ5CFQEBAQEBAQEBAWsohR4BAQE?= =?us-ascii?q?DATo/BQsCAQgOBwMNEQUEBzIUEQEBBAENBQiKFAgQrBWLDwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgzSCB4FVhROLEAWiNwKHa40Qk02Mb4kSAhEZAYE4ATUigXR?= =?us-ascii?q?6FUmCZIMRgU53iFYrgQiBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,401,1505779200"; d="scan'208";a="319265830"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 21:53:29 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAFLrTr4008675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 21:53:29 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 16:53:28 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 16:53:28 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund , "Einar Nilsen-Nygaard (einarnn)" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFw
Date: Wed, 15 Nov 2017 21:53:28 +0000
Message-ID: <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com> <20171115.110311.268174371353663424.mbj@tail-f.com> <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.cisco.com> <20171115.164247.1419508866071356464.mbj@tail-f.com>
In-Reply-To: <20171115.164247.1419508866071356464.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 21:53:49 -0000

Adding Einar as he had some strong opinions on this a few years ago when we=
 were setting the model...


> From: Martin Bjorklund, November 15, 2017 10:43 AM
>=20
> "Eric Voit (evoit)"  wrote:
> > Hi Martin,
> >
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > >
> > > "Eric Voit (evoit)"  wrote:
> > > > In the WG session tomorrow, I am hoping to get "hum feedback" on:
> > > >
> > > >
> > > >
> > > > draft-ietf-netconf-subscribed-notifications
> > > >
> > > > https://github.com/netconf-wg/rfc5277bis/issues/4
> > > >
> > > >
> > > >
> > > > The two choices and their issues exposed during the two week
> > > > review on
> > > "Can Transport vary across different receivers of a single
> > > configured subscription?" are:
> > > >
> > > >
> > > >
> > > > (1) Yes, Transport can vary by receiver
> > > >
> > > > *        Fewer subscriptions (scale benefit)
> > > >
> > > > *        Can convert transport without requiring an application to =
learn
> a
> > > multiple subscription ids
> > > >
> > > > *        No duplication of content during transport conversion.
> > > >
> > > > *        (Potential confusion in allowing transport to vary, but en=
coding
> not
> > > to vary?)
> > > >
> > > >
> > > >
> > > > (2) No, only one Transport across all subscriptions
> > > >
> > > > *        Simpler model
> > > >
> > > > *        But applications may need to create and track multiple
> > > subscription-ids for the same content.
> > > >
> > > > *        Temporary duplication of content streams during transport
> change.
> > > >
> > > >
> > > >
> > > > The current draft does (1).
> > >
> > > Actually, the github issue lists 3 options, but here you just list 2.
> >
> > In reviewing tomorrow's slides with Mahesh, he preferred 2 options.
> > And as varying the encoding by receiver seems unlikely in
> > implementation
>=20
> Why is this unlikely?  Suppose I have two receivers for the same
> subscription, one wants NETCONF/XML and the other RESTCONF/JSON.  Is
> that unlikely?

Einar's belief was that a publisher implementation would be unlikely to ser=
vice a single subscription into multiple encodings.   If such a condition e=
xisted, it would be far easier to create two subscriptions.  This also woul=
d have fewer error conditions.
=20
> > , there is little reason to socialize this unlikely variant before
> > the whole WG.   Since as your opinion was either both encoding and
> > transport or neither encoding and transport vary by receiver, the more
> > likely of your primary ask is supported.
> >
> >
> > > I think the point is that in the term "Transport", we need to
> > > include both protocol and encoding (in the case the protocol
> > > supports multiple encodings).
> >
> > While most likely the case for NETCONF and RESTCONF, Tianran's
> > draft-ietf-netconf-udp-pub-channel shows that there can be encoding
> > variation by transports .   It Therefore it seems better to let them
> > both vary independently.
>=20
> Not sure I understand what you mean.  To be clear, do you think the
> "encoding" leaf should stay where it is, or be moved down to the receiver=
,
> as a sibling to "protocol"?

Encoding leaf should stay where it is.   Your previous ask was to put encod=
ing and transport and the same level. There is an option proposed in the sl=
ides which does that.

Eric

> /martin


From nobody Wed Nov 15 13:53:56 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBCD1286B1 for ; Wed, 15 Nov 2017 13:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGKHXcqNd_qh for ; Wed, 15 Nov 2017 13:53:48 -0800 (PST)
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 42D91127BA3 for ; Wed, 15 Nov 2017 13:53:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13487; q=dns/txt; s=iport; t=1510782815; x=1511992415; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5H8MaC/c2HkT3n2LmC4fofOQ3dox0lzReGj9WH2C02g=; b=bomRDDI1O8lc2Z179z688AyzH9dX8yyoivrCH91wYn1vS+m7qSqabXhU InWIGX6R6LsmyukfUByKn8yjFXReCE57wi6J9kpo4zraNidtAK8g3iMl8 nmIjd1XbI04ncyh2cRmLBTDVs+pvkmhuBFMnfkSfmK47ugsjcGOW5tZsn I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAQANtwxa/4YNJK1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNmRuJwedBTKBfZZdEIIBChgLhElPAoUOQRYBAQEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBBAEBODQEBQIMBAIBCBEEAQEBDREJBycLFAkIAgQBDQUIihwQrBGLD?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVgWmCHYENglFzgSkThhAFijQ?= =?us-ascii?q?XiReOVQKHa4NpiSeCHooOhyGKM4I8iRICERkBgTgBJg0kgXR6FUmCZIJcHBmBT?= =?us-ascii?q?neKCYERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,401,1505779200"; d="scan'208";a="310701081"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 21:53:33 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAFLrXOA004304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 21:53:33 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 16:53:32 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 16:53:32 -0500
From: "Eric Voit (evoit)" 
To: "kwatsen@juniper.net" , "Mahesh Jethanandani (mahesh)" 
CC: "alexander.clemm@huawei.com" , "netconf@ietf.org" , Martin Bjorklund 
Thread-Topic: [Netconf] two-week review of drafts related to notifications and subscriptions
Thread-Index: AQHTSH5n2+KEwzxeaUmOUUOjdzqfBKLrmFPQgAClhQD//9LP4IAFmdcA///CDQCAA2UI0IAhhBaA///PwQA=
Date: Wed, 15 Nov 2017 21:53:32 +0000
Message-ID: <2aa5238c339447fba8a4bde3df66bf51@XCH-RTP-013.cisco.com>
References: <20171023.144114.150465814300377965.mbj@tail-f.com> <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com> <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.cisco.com> <20171115.203913.2068438246599432509.mbj@tail-f.com>
In-Reply-To: <20171115.203913.2068438246599432509.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] two-week review of drafts related to notifications and subscriptions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 21:53:52 -0000

Kent,
Mahesh,

You also thought it might be good to partition the trees.   Are you also ok=
 with the proposal below, and the identified downsides of such a partitioni=
ng of the tree within subscribed-notifications?    Specifically the implica=
tions of making it harder to find and compare augmentation points from yang=
-push?

Eric

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Wednesday, November 15, 2017 2:39 PM
> To: Eric Voit (evoit) 
> Cc: kwatsen@juniper.net; alexander.clemm@huawei.com; netconf@ietf.org
> Subject: Re: [Netconf] two-week review of drafts related to notifications=
 and
> subscriptions
>=20
> "Eric Voit (evoit)"  wrote:
> > Hi Martin,
> > Hi Kent,
> >
> > Ensuring comments are covered.  I do ask a question on potential model
> > partitioning across the document in the first set of comments..,
> >
> > > From: Martin Bjorklund, October 23, 2017 8:41 AM
> > >
> > > Hi,
> > >
> > > Some comments inline.
> > >
> > > "Eric Voit (evoit)"  wrote:
> > > > Hi Kent,
> > > >
> > > > > From: Kent Watsen, October 19, 2017 9:51 PM
> > > > >
> > > > > >> draft-ietf-netconf-subscribed-notifications-05
> > > > > >> ------------------------------------------------------
> > > > >
> > > > > >> very complicated (many details).
> > > > > >
> > > > > > If there anything you see as unnecessary, or perhaps should be
> > > > > > optional?
> > > > >
> > > > > The tree diagram is huge.  I understand that much of it is from
> > > > > grouping expansion, but still, there is a lot to consider (many
> > > > > details).  I'm just thinking that this is going to take time for
> > > > > folks to digest fully.
> > > >
> > > > We really made an attempt to simplify the tree by using a
> > > > filter-type object instead of the explicit subtyping.  But
> > > > experienced and capable reviewers argued that explicit subtyping
> > > > was better.  The result is that we returned to the larger
> > > > explicitly subtyping a couple weeks ago.  Overall, this added 25%
> > > > to the tree diagram size :-(.
> > >
> > > I don't think a big tree in itself necessarily means that the data
> > > model is bad.
> > > However, for readability purposes, you may want to split the big
> > > tree into smaller pieces.  See for example RFC 7404.
> >
> > I think you mean RFC 7407?
>=20
> Yes.
>=20
> > We can do this.  Before I make the change, I want to confirm that it
> > should be only done for individual RPCs and Notifications, and top
> > level containers in the data trees (e.g. streams and filters top level
> > container).
>=20
> I think that would be sufficient.
>=20
> > I would also like to confirm that you are ok with all the downsides
> > (1)-(4) listed below.
> >
> > (1) To what section of subscribed-notifications do you look to when
> > you are doing an augmentation in yang-push?  Having one tree to go to
> > in one full tree is easier than finding info across split trees.
> > I.e., a single tree is pretty useful for outside referencing on
> > augmentations.
>=20
> The purpose of the tree is to get an overview of the basic structure of t=
he
> model.  It is not the normative reference that you need to fully understa=
nd
> everything - that would be the module itself.
>=20
> > (2) YANG Push does not have section partitions for existing
> > subscribed-notification RPCs and Notifications.  Therefore we couldn't
> > do the exact same segmentation of the tree structures across the two
> > documents.  (I.e. it won't be a 1:1 comparison when looking between
> > the drafts.)
>=20
> I haven't yet reviewed YANG Push, but I don't think this will be an issue=
.
>=20
> > (3) Segmentation lower that any top level container is not
> > recommended.
>=20
> By whom?
>=20
> > This is because augmentations occur at different levels of the tree.
> > Any other approach would mean tree information replicated in different
> > tree diagrams.
>=20
> I don't think that's a problem.
>=20
> > (4)  It will increase the size of an already big document.
>=20
> Probably not by much, and if it helps people to better understand this
> model, I think it is worth it.
>=20
>=20
> /martin
>=20
>=20
> > Based on this, I still think a single model is better.  But I am happy
> > to make the change if consensus is otherwise.
> >
> > > > > >>         flow difficult to read.
> > > > > >
> > > > > > Anything specific?  I am happy to re-order as suggested.
> > > > >
> > > > > Also, I'm suspecting that the update from Martin's comments will
> > > > > get much of this.  It just seemed that every time tried to chase
> > > > > some bit of information down, it wasn't stated quite right
> > > > > (e.g., terminology, phasing, open-endedness, etc.).  All this
> > > > > got in the way of the readability.
> > > >
> > > > Hopefully I got the ones which don't resonate.  My natural
> > > > ecosystem is deeper in the router, and YANG means I need to use
> different terms.
> > > >
> > > > > >> * what is "promise theory based interaction model"?
> > > > > >> (reference?)
> > > > > > Yes, I will add the reference.  The best on-line one I know is:
> > > > > >
> > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
> 3A__markburgess.
> > > > > > or
> > > > > > g_Pr
> > > > > >
> omiseMethod.pdf&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > > > > ndb3voDTXcWzoCI
> > > > > >
> > > > >
> > >
> &r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DzDualRWvSwyZj
> 8MF
> > > > > PL_Xo
> > > > > >
> > > > >
> > >
> pkywEp9xEJgZXjyhdIBPog&s=3DDcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2
> xpE
> > > > > Oc0o&e
> > > > > > =3D
> > > > >
> > > > > Oh my, that document is 38 pages, I was hoping for simple
> > > > > statement (e.g., the system takes defensive measures in order to
> > > > > ensure resources are available).  I think you have something
> > > > > like this in the yang-push draft.
> > > >
> > > > I can add a simple statement.  Something like "voluntary
> > > > cooperation between individual, autonomous agents who
> continuously
> > > > refine their changing intentions to one another in the form of
> promises".
> > >
> > > Does this really help people to understand this document?
> >
> > I didn't such a statement helped either, so all references in
> > subscribed-notifications have been removed.  As this is important in
> > yang-push, I tweaked the reference section 3.4 with the kind of info I
> > think Kent wanted in his simple statement.
> >
> > > > > >> * what is the relationship between streams here and in 5277?
> > > > > >
> > > > > > This document doesn't discuss the details of how streams are
> > > > > > generated within the publisher like 5277 does.  This detail is
> > > > > > not necessary for the external interface definition.
> > > > > >
> > > > > > That said, how to handle/encode names of the streams, the
> > > > > > managed objects, the ability to filter, etc. are identical.
> > > > >
> > > > > This document should explain the relationship though, right?
> > > > > (see
> > > > > above)
> > > >
> > > > Is this necessary in the normative part of the document?  When the
> > > > notification-messages draft is complete, it will be possible to
> > > > obsolete RFC-5277 at some later date.  How many linkages are
> > > > appropriate?
> > > >
> > > > What I did do in the new version (per Martin's request) is to
> > > > place in Appendix A: Relationship to RFC-5277.  What I believe we
> > > > should do is place statements identifying the re-used stream
> constructs.
> > > > Would that work?
> > >
> > > I think such a section is needed, and I think it shouldn't be an
> > > Appendix, but rather one of the first sections.  This is quite
> > > common in RFCs that updates/obsoletes older RFCs.
> >
> > Done.  See Section 1.4.  Relationship to RFC-5277
> >
> > > > > >> * streams here are identities, unlike "streamNameType"
> > > > > >> (aka xs:string) in 5077.  Is this an issue?
> > > > > >
> > > > > > Based on Martin's comments that he desires to retain the
> > > > > > ability for streams to be spun up possibly during run-time, we
> > > > > > have returned to using string for streams (as we did in earlier
> > > > > > versions of the draft).   Our switch to identities several
> > > > > > months ago was one attempt we made to simplify things, but
> > > > > > it didn't work out.    This is an issue and a resolution we
> > > > > > have long been anticipating.
> > > > >
> > > > > okay
> > > > >
> > > > >
> > > > > >> * use of " operations" for configured
> > > > > >> subscriptions is confusing.
> > > > > >
> > > > > > It is just a normal configuration.  I will happily delete the
> > > > > > example if you think it unnecessary or redundant.
> > > > >
> > > > > No, the examples are good.  It's literally the words
> > > > > " operations"
> > > > > are problematic.  Use some other phrasing that is not
> > > > > NETCONF-specific.
> > > >
> > > > I will just use 'configuration operations'
> > > >
> > > > > >> * the example in s5.1 seems to be more about how to create a
> > > > > >> configured subscription than establishing a subscription
> > > > > >> connection
> > > > > >
> > > > > > Exactly.  How to establish the subscription connection is
> > > > > > transport specific, and therefore in the netconf-notif draft.
> > > > > > Specifically in Section 3.4.3
> > > > >
> > > > > But the section is called "Establishing a Configured Subscription=
".
> > > > > I think this actually goes to your use of the word "establish",
> > > > > perhaps "create" is a better word - "Creating a Configured
> > > > > Subscription" ?
> > > >
> > > > Will do.  No reason to reuse the establish if it confuses people.
> > > >
> > > > > >> * Section 7 says "This notification message MAY be encoded as
> > > > > >> one-way notification element of [RFC5277], Section 4."  If
> > > > > >> this is a MAY, how does the client know what it received?
> > > > > >> And how does the publisher know what format to send?
> > > > > >
> > > > > > I was trying to lay the groundwork for a future support of
> > > > > > notification-messages in a way that this document wouldn't
> > > > > > have to be updated.  I have given up on that.  Support is now a
> MUST.
> > > > > > And this will need to be revised in the future when we get
> > > > > > notification-messages to an RFC state.
> > > > >
> > > > > okay
> > > > >
> > > > >
> > > > > >> * xpath-filter is not a feature-based option?
> > > > > >
> > > > > > Not feature based.  Of course if the syntax is not supported
> > > > > > on a filter, the subscription will be rejected with the error
> > > > > > "filter-type-unsupported ".
> > > > > >
> > > > > > At this point, I don't recall anyone suggesting xpath should
> > > > > > not be a mandatory for event filtering though.
> > > > >
> > > > > well, it's not mandatory for NETCONF-based filtering.  So, a
> > > > > system that doesn't support XPath filtering in NETCONF would
> > > > > have to support XPath filtering here?
> > > >
> > > > Hmm.  I had been hoping to have at least one (xpath) as mandatory.
> > > > But maybe that is unrealistic.
> > > >
> > > > What I am thinking is that maybe both filters should be optional
> > > > features.  And then specific transport drafts (like NETCONF) can
> > > > identify them as mandatory. At least when that transport is used.
> > > >
> > > > > >> * I see top-level /subscription-config and /subscriptions -
> > > > > >> is this NMDA compliant?
> > > > > >
> > > > > > As this pre-dates NMDA, we are awaiting the "you MUST make the
> > > > > > conversion" directive.  And if this comes, we will gladly do th=
at.
> > > > >
> > > > >
> https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSI
> > > > > oH
> > > > > 4g
> > > > > A-8M
> > > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sect
> > > > > io
> > > > > n-
> > > > > 4.23.3
> > > >
> > > > Yep.  We do fall in the SHOULD category :-)
> > > >
> > > > But seriously, we can convert.
> > >
> > > Before doing anything, make sure the "subscription-id" issue is
> > > resolved first.  If Rob's proposal is adopted, we will still need
> > > two lists, one config and one operational, even in the
> > > NMDA-compliant version.  Some changes might be needed in the
> naming
> > > of top-level containers though.
> >
> > Based on the comments received on the subscription-id datatype.  Rough
> > consensus is integer.  We will covert to NMDA after all other issues
> > are closed in set of drafts going to WGLC.
> >
> > Eric
> >
> > > > The question is how to do this without losing our place in the
> > > > review queue.  We had expected to be through WGLC *long* before
> > > > NMDA was formalized.  And we are very concerned this policy change
> > > > could result in further delay.  So the current plan we have is to
> > > > get agreement on the contents of the model.  And then agreement
> > > > that we have converted what is an acceptable model into an
> > > > equivalent NMDA version.
> > >
> > >
> > > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >


From nobody Wed Nov 15 15:07:02 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3D128BB7 for ; Wed, 15 Nov 2017 15:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CH-B3i9aZ4W for ; Wed, 15 Nov 2017 15:06:58 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1E7126E01 for ; Wed, 15 Nov 2017 15:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6442; q=dns/txt; s=iport; t=1510787218; x=1511996818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ICWjiuysrmeQhs61HtT8K1AVgeKbs5RovXKlM2DWGlk=; b=FyMvd0SgiYuM5be5rLy3N+GU28CYwfkkQTS/5a4Ba3JoE6BTnitjRVYj 0pLreOUchrWKGCmstuhslBGqfALbiD63Dmdy2NJFJtSBCUzsiMh/VdFRs ZnU7ECNORt5zbIM1HPXJTOdms3HaEfTM4Qq3ZlMFLKA/TFMyQu1gCM/CB M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgCVxwxa/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4UEweDeJk/gVcmmG4KI4UYAhqEdEIVAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQMBIxFABQULAgEIFQMCAgkWBAMCAgIwFAEQAQEEDgWKHAgQqWmCJ4sQA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IlggeDZwuCdoUXAReCfjGCMgWiNwK?= =?us-ascii?q?Ha40Zk0SMb4V+gxQCERkBgTgBNSKBdHoVSS0BgjZJgkiBTneIViuBCIERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,401,1505779200"; d="scan'208";a="321131445"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 23:06:57 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAFN6uWJ002227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 23:06:57 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 18:06:56 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 18:06:56 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "Eric Voit (evoit)" 
CC: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFwAA3K+YA=
Date: Wed, 15 Nov 2017 23:06:56 +0000
Message-ID: <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com>
References: <868e65f523c04a38b696649cfaec3666@XCH-RTP-013.cisco.com> <20171115.110311.268174371353663424.mbj@tail-f.com> <4f48c351c272493eb4d3e5efc8730615@XCH-RTP-013.cisco.com> <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com>
In-Reply-To: <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.247.137]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:07:01 -0000

TWFydGluLA0KDQpBcyB5ZXQsIHdlIGhhdmUgbm8gcHJhY3RpY2FsIHVzZSBjYXNlcyB3aGVyZSB3
ZSB3b3VsZCBoYXZlIGEgc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdpdGggbXVsdGlw
bGUgcmVjZWl2ZXJzIHdobyB3aXNoIHRvIHJlY2VpdmUgdGhlIGRhdGEgaW4gZGlmZmVyZW50IGZv
cm1hdHMuIFRodXMgc3VwcG9ydGluZyB0aGlzIHNlZW1zIGxpa2UgYW4gdW5uZWNlc3NhcnkgY29t
cGxleGl0eSBmb3IgcGxhdGZvcm1zLCBhbmQgb25lIHdoaWNoIHBvdGVudGlhbGx5IGltcGFjdHMg
b3B0aW1pc2F0aW9ucyB0aGF0IHdlIGFscmVhZHkgdXNlIGluIHNvbWUgcGxhdGZvcm0gaW1wbGVt
ZW50YXRpb25zIChlLmcuIHNlbmRpbmcgdGhlIHNhbWUgZW5jb2RlZCBQRFUgdG8gbXVsdGlwbGUg
cmVjZWl2ZXJzLCByZWxpZXZpbmcgdGhlIHBsYXRmb3JtIG9mIGVuY29kaW5nIHRoZSBzYW1lIGRh
dGEgbXVsdGlwbGUgd2F5cykuDQoNCk9mIGNvdXJzZSwgaWYgYSBjbGllbnQgcmVhbGx5IHdhbnRz
IHRvIGhhdmUgdGhlIHNhbWUgZGF0YSBzZW50IHRvIG11bHRpcGxlIHJlY2VpdmVycyBidXQgaW4g
ZGlmZmVyZW50IGZvcm1hdHMsIHRoZXkgY2FuIGRvIHRoaXMg4oCUIGp1c3QgcHJvdmlzaW9uIHNl
cGFyYXRlIHN1YnNjcmlwdGlvbnMgd2l0aCB0aGUgc2FtZSBmaWx0ZXIuDQoNCkFsbC1pbi1hbGws
IEkgZG9u4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4gbWFraW5nIHRoZSBiYXNlIG1vZGVsIHN1cHBv
cnQgdGhpcywgb25seSBkb3duc2lkZXMsIHNvIGRvIHlvdSBoYXZlIGFueSBzcGVjaWZpYyB1c2Ug
Y2FzZXMgaW4gbWluZCB3aGVyZSB0aGlzIHdvdWxkIGJlIGEgYmVuZWZpdD8gU28gZmFyIGluIHRo
ZSB1c2UgY2FzZXMgd2UgaGF2ZSBsb29rZWQgYXQgaW4gU1AsIERDLCBlbnRlcnByaXNlIGFuZCBJ
b1Qgd2UgaGF2ZSBub3Qgc2VlbiBhbnkgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCB0aGlzLCBidXQg
d2UgaGF2ZSBzZWVuIHRoZSBuZWVkIGZvciBtdWx0aXBsZSByZWNlaXZlcnMgKGUuZy4gdG8gc3Vw
cG9ydCBIQS9yZWR1bmRhbmN5IGFwcHJvYWNoZXMpLiBBcyBzdWNoLCBJIHdvdWxkIGJlIHJlbHVj
dGFudCB0byBhZGQgdGhpcyB0byB0aGUgZHJhZnQgYXQgdGhpcyBzdGFnZSB3aGVuIHRoZSBmdW5j
dGlvbmFsaXR5IGNhbiBiZSBhY2hpZXZlZCBhbHJlYWR5IGlmIGFic29sdXRlbHkgbmVjZXNzYXJ5
Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KPiBPbiAxNSBOb3YgMjAxNywgYXQgMjE6NTMsIEVy
aWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gQWRkaW5nIEVp
bmFyIGFzIGhlIGhhZCBzb21lIHN0cm9uZyBvcGluaW9ucyBvbiB0aGlzIGEgZmV3IHllYXJzIGFn
byB3aGVuIHdlIHdlcmUgc2V0dGluZyB0aGUgbW9kZWwuLi4NCj4gDQo+IA0KPj4gRnJvbTogTWFy
dGluIEJqb3JrbHVuZCwgTm92ZW1iZXIgMTUsIDIwMTcgMTA6NDMgQU0NCj4+IA0KPj4gIkVyaWMg
Vm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4+PiBIaSBNYXJ0aW4sDQo+
Pj4gDQo+Pj4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0N
Cj4+Pj4gDQo+Pj4+ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6
DQo+Pj4+PiBJbiB0aGUgV0cgc2Vzc2lvbiB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8gZ2V0ICJo
dW0gZmVlZGJhY2siIG9uOg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gZHJhZnQtaWV0
Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucw0KPj4+Pj4gDQo+Pj4+PiBodHRwczov
L2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1Mjc3YmlzL2lzc3Vlcy80DQo+Pj4+PiANCj4+Pj4+
IA0KPj4+Pj4gDQo+Pj4+PiBUaGUgdHdvIGNob2ljZXMgYW5kIHRoZWlyIGlzc3VlcyBleHBvc2Vk
IGR1cmluZyB0aGUgdHdvIHdlZWsNCj4+Pj4+IHJldmlldyBvbg0KPj4+PiAiQ2FuIFRyYW5zcG9y
dCB2YXJ5IGFjcm9zcyBkaWZmZXJlbnQgcmVjZWl2ZXJzIG9mIGEgc2luZ2xlDQo+Pj4+IGNvbmZp
Z3VyZWQgc3Vic2NyaXB0aW9uPyIgYXJlOg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g
KDEpIFllcywgVHJhbnNwb3J0IGNhbiB2YXJ5IGJ5IHJlY2VpdmVyDQo+Pj4+PiANCj4+Pj4+ICog
ICAgICAgIEZld2VyIHN1YnNjcmlwdGlvbnMgKHNjYWxlIGJlbmVmaXQpDQo+Pj4+PiANCj4+Pj4+
ICogICAgICAgIENhbiBjb252ZXJ0IHRyYW5zcG9ydCB3aXRob3V0IHJlcXVpcmluZyBhbiBhcHBs
aWNhdGlvbiB0byBsZWFybg0KPj4gYQ0KPj4+PiBtdWx0aXBsZSBzdWJzY3JpcHRpb24gaWRzDQo+
Pj4+PiANCj4+Pj4+ICogICAgICAgIE5vIGR1cGxpY2F0aW9uIG9mIGNvbnRlbnQgZHVyaW5nIHRy
YW5zcG9ydCBjb252ZXJzaW9uLg0KPj4+Pj4gDQo+Pj4+PiAqICAgICAgICAoUG90ZW50aWFsIGNv
bmZ1c2lvbiBpbiBhbGxvd2luZyB0cmFuc3BvcnQgdG8gdmFyeSwgYnV0IGVuY29kaW5nDQo+PiBu
b3QNCj4+Pj4gdG8gdmFyeT8pDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAoMikgTm8s
IG9ubHkgb25lIFRyYW5zcG9ydCBhY3Jvc3MgYWxsIHN1YnNjcmlwdGlvbnMNCj4+Pj4+IA0KPj4+
Pj4gKiAgICAgICAgU2ltcGxlciBtb2RlbA0KPj4+Pj4gDQo+Pj4+PiAqICAgICAgICBCdXQgYXBw
bGljYXRpb25zIG1heSBuZWVkIHRvIGNyZWF0ZSBhbmQgdHJhY2sgbXVsdGlwbGUNCj4+Pj4gc3Vi
c2NyaXB0aW9uLWlkcyBmb3IgdGhlIHNhbWUgY29udGVudC4NCj4+Pj4+IA0KPj4+Pj4gKiAgICAg
ICAgVGVtcG9yYXJ5IGR1cGxpY2F0aW9uIG9mIGNvbnRlbnQgc3RyZWFtcyBkdXJpbmcgdHJhbnNw
b3J0DQo+PiBjaGFuZ2UuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGUgY3VycmVu
dCBkcmFmdCBkb2VzICgxKS4NCj4+Pj4gDQo+Pj4+IEFjdHVhbGx5LCB0aGUgZ2l0aHViIGlzc3Vl
IGxpc3RzIDMgb3B0aW9ucywgYnV0IGhlcmUgeW91IGp1c3QgbGlzdCAyLg0KPj4+IA0KPj4+IElu
IHJldmlld2luZyB0b21vcnJvdydzIHNsaWRlcyB3aXRoIE1haGVzaCwgaGUgcHJlZmVycmVkIDIg
b3B0aW9ucy4NCj4+PiBBbmQgYXMgdmFyeWluZyB0aGUgZW5jb2RpbmcgYnkgcmVjZWl2ZXIgc2Vl
bXMgdW5saWtlbHkgaW4NCj4+PiBpbXBsZW1lbnRhdGlvbg0KPj4gDQo+PiBXaHkgaXMgdGhpcyB1
bmxpa2VseT8gIFN1cHBvc2UgSSBoYXZlIHR3byByZWNlaXZlcnMgZm9yIHRoZSBzYW1lDQo+PiBz
dWJzY3JpcHRpb24sIG9uZSB3YW50cyBORVRDT05GL1hNTCBhbmQgdGhlIG90aGVyIFJFU1RDT05G
L0pTT04uICBJcw0KPj4gdGhhdCB1bmxpa2VseT8NCj4gDQo+IEVpbmFyJ3MgYmVsaWVmIHdhcyB0
aGF0IGEgcHVibGlzaGVyIGltcGxlbWVudGF0aW9uIHdvdWxkIGJlIHVubGlrZWx5IHRvIHNlcnZp
Y2UgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGludG8gbXVsdGlwbGUgZW5jb2RpbmdzLiAgIElmIHN1
Y2ggYSBjb25kaXRpb24gZXhpc3RlZCwgaXQgd291bGQgYmUgZmFyIGVhc2llciB0byBjcmVhdGUg
dHdvIHN1YnNjcmlwdGlvbnMuICBUaGlzIGFsc28gd291bGQgaGF2ZSBmZXdlciBlcnJvciBjb25k
aXRpb25zLg0KPiANCj4+PiAsIHRoZXJlIGlzIGxpdHRsZSByZWFzb24gdG8gc29jaWFsaXplIHRo
aXMgdW5saWtlbHkgdmFyaWFudCBiZWZvcmUNCj4+PiB0aGUgd2hvbGUgV0cuICAgU2luY2UgYXMg
eW91ciBvcGluaW9uIHdhcyBlaXRoZXIgYm90aCBlbmNvZGluZyBhbmQNCj4+PiB0cmFuc3BvcnQg
b3IgbmVpdGhlciBlbmNvZGluZyBhbmQgdHJhbnNwb3J0IHZhcnkgYnkgcmVjZWl2ZXIsIHRoZSBt
b3JlDQo+Pj4gbGlrZWx5IG9mIHlvdXIgcHJpbWFyeSBhc2sgaXMgc3VwcG9ydGVkLg0KPj4+IA0K
Pj4+IA0KPj4+PiBJIHRoaW5rIHRoZSBwb2ludCBpcyB0aGF0IGluIHRoZSB0ZXJtICJUcmFuc3Bv
cnQiLCB3ZSBuZWVkIHRvDQo+Pj4+IGluY2x1ZGUgYm90aCBwcm90b2NvbCBhbmQgZW5jb2Rpbmcg
KGluIHRoZSBjYXNlIHRoZSBwcm90b2NvbA0KPj4+PiBzdXBwb3J0cyBtdWx0aXBsZSBlbmNvZGlu
Z3MpLg0KPj4+IA0KPj4+IFdoaWxlIG1vc3QgbGlrZWx5IHRoZSBjYXNlIGZvciBORVRDT05GIGFu
ZCBSRVNUQ09ORiwgVGlhbnJhbidzDQo+Pj4gZHJhZnQtaWV0Zi1uZXRjb25mLXVkcC1wdWItY2hh
bm5lbCBzaG93cyB0aGF0IHRoZXJlIGNhbiBiZSBlbmNvZGluZw0KPj4+IHZhcmlhdGlvbiBieSB0
cmFuc3BvcnRzIC4gICBJdCBUaGVyZWZvcmUgaXQgc2VlbXMgYmV0dGVyIHRvIGxldCB0aGVtDQo+
Pj4gYm90aCB2YXJ5IGluZGVwZW5kZW50bHkuDQo+PiANCj4+IE5vdCBzdXJlIEkgdW5kZXJzdGFu
ZCB3aGF0IHlvdSBtZWFuLiAgVG8gYmUgY2xlYXIsIGRvIHlvdSB0aGluayB0aGUNCj4+ICJlbmNv
ZGluZyIgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBpcywgb3IgYmUgbW92ZWQgZG93biB0byB0
aGUgcmVjZWl2ZXIsDQo+PiBhcyBhIHNpYmxpbmcgdG8gInByb3RvY29sIj8NCj4gDQo+IEVuY29k
aW5nIGxlYWYgc2hvdWxkIHN0YXkgd2hlcmUgaXQgaXMuICAgWW91ciBwcmV2aW91cyBhc2sgd2Fz
IHRvIHB1dCBlbmNvZGluZyBhbmQgdHJhbnNwb3J0IGFuZCB0aGUgc2FtZSBsZXZlbC4gVGhlcmUg
aXMgYW4gb3B0aW9uIHByb3Bvc2VkIGluIHRoZSBzbGlkZXMgd2hpY2ggZG9lcyB0aGF0Lg0KPiAN
Cj4gRXJpYw0KPiANCj4+IC9tYXJ0aW4NCj4gDQoNCg==


From nobody Wed Nov 15 16:26:05 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAE412711A for ; Wed, 15 Nov 2017 16:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNzCCuZh0bBN for ; Wed, 15 Nov 2017 16:26:02 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1967128E00 for ; Wed, 15 Nov 2017 16:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12027; q=dns/txt; s=iport; t=1510791960; x=1512001560; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=n3UFELIisem4Hkv3kA3hBf1w0+JzASrMD0YjYmQVNa8=; b=ZluUijEmAc/55ejOplrc19egKJVssRm8vHb6AjmPDgWLbqrnT++opEUz mJux/7DB9mLqJrxkCsK4GmoAQSrgIN7iS6l/UNWI4tG0SmbvfTesYw+B2 oxA9F6j7tnv9mziEkUE4hfrnsyd7Tn7spDz30mDdoBdPb5POHspcv+/V8 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAAC52gxa/4cNJK1XBxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNmRuKAaOF48ggX1+lV8QggEKI4ooPxgBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQEEOz0HDQEWBxARQiYBBAEaihQIEKwPiw8BAQEBBgEBAQEBI4M0ggeBVYFpg?= =?us-ascii?q?nWFJw4CA4YLBZFxkEYClHuCHooOhyGKM4tOAhEZAYE4AR84gXR6FUmCZQiCUxy?= =?us-ascii?q?BZ4lNASYDgQmBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,401,1505779200"; d="scan'208";a="324169146"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 00:25:34 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAG0PYG7002878 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 00:25:34 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 19:25:33 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 19:25:33 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: Martin's thoughts on subscribed-notifications
Thread-Index: AdNeaGaRgL7jaaHdQPq4iKxC9iuYSQ==
Date: Thu, 16 Nov 2017 00:25:33 +0000
Message-ID: <821e452591614d80a7405a0318e3d66a@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] tRE: Martin's thoughts on subscribed-notifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:26:04 -0000

Hi Martin,

Thanks for the suggestions.   In-line...

> From: Martin Bjorklund, November 15, 2017 2:33 PM
>=20
> Hi,
>=20
> I have reviewed draft-ietf-netconf-subscribed-notifications-07,
> specifically to ensure that my earlier comments are addressed.  Here are =
my
> new comments:
>=20
>=20
>=20
> o  General
>=20
>   The document uses the term "RPC" to refer to the operations that
>   affect dynamic subscriptions.  I think that this term is not quite
>   correct.  For example the text says:
>=20
>       a configured subscription cannot be modified or deleted using
>       RPC.
>=20
>   But this is not correct, I can delete a configured subscription with
>   the  rpc.

Will append the clarification:
"using RPCs from the document."

> o  Section 1.2
>=20
>   What is "RPC subscription state signaling messages"?

Will change "signaling messages" to  "Notifications".   In this case the no=
tifications act as signaling messages.

> o  Section 2.2
>=20
>      The subsets of these filtering syntaxes supported are
>      left to each implementation.
>=20
>    Juergen has already pointed out that this is not good design - how
>    will the client know which subset of subtree filtering a certain
>    device supports?   I think that if the server doesn't support
>    subtree filtering as defined, then it should not advertise the
>    "subtree" feature.  It can always advertise another feature.

Agree,  that was always the intent.  The words just need to match to that. =
 How about:
" If [RFC6241] filtering is supported, the full set of Section 6 must be en=
abled.  If XPATH filtering is supported, the subset of XPATH functionality =
is left to the implementation "

> o  Section 2.3
>=20
>   The state diagram shows an arrow "modify" from "suspended" to
>   "active".  Is this really correct?  Will a suspended subscription be
>   resumed if it is modified? =20

Yes.=20
The subscription could immediately be suspended, but this reduces the avail=
able knobs.
=20
> If so, this is not correct:
>     o  Suspend and resume state changes are driven by internal process
>        and prioritization.  There are no external controls over suspend
>        and resume.

How about: "there are no direct controls over suspend and resume other than=
 modifying a subscription." =20

Right before Figure 2, I will also add the sentence to clarify:
Modification of a configured subscription will place any suspended receiver=
s into the connecting receiver state.

> o  Section 3
>=20
>   The data model is not yet converted to NMDA single tree (and there
>   is no issue that tracks this).

We have an umbrella issue for this:
YP#11: Shift to NMDA compliant structure

We authors are willing to shift to NMDA constructs (allowing side-by-side c=
omparison) once all other issues are closed and a firm WGLC start date is s=
et for yang push.=20

> o  Section 4.1.1
>=20
>      Not all streams will support replay.  Those that do MUST include
>      they do via the "replay-support" object.
>=20
>   The second sentence still looks odd.  I propose:
>=20
>     If a stream supports replay, the "replay-support" leaf is present
>     in the "/streams/stream" list entry for the stream.

Will make this change

> o  Section 4.4
>=20
>      An operator may find subscription
>      identifiers which may be used with "kill-subscription" by searching
>      for the ip address of a receiver within the yang tree.
>=20
>   s/within the yang tree/in the "subscription" list"/
>=20
>   or something along those lines.

Will make this change

> o  Section 5
>=20
>      o  One or more receiver IP addresses (and corresponding ports)
>         intended as the destination for notification messages for each
>         subscription.  In addition, the transport for each destination MA=
Y
>         be defined.
>=20
>    Since the transport is mandatory in the data model, the last
>    sentence should be removed.

Will make this change

> o  Section 5.1
>=20
>   The text in -07 is an improvement over -05.  But there are still
>   some things that needs to be specified.
>=20
>   The text needs to discuss what's supposed to happen if a transport
>   session goes down. Will the server re-establish the session? =20

As there are transport specific behaviors.  For NETCONF, see Section 5.2 of=
 draft-ietf-netconf-netconf-event-notifications.

>  Will it buffer events during this time? =20

Events are buffered, if available.  If events are lost (rather than just de=
layed) due to the loss of transport connectivity, a new subscription-starte=
d must be sent.  This indicates the discontinuity to the receiver.

Note I will add these two sentences directly above to section 5.1 to clear =
up any confusion.=20

On a side note: I will tweak the text of " 8.4. subscription-suspended" to=
=20
" This indicates that a publisher has suspended the sending of event record=
s to a receiver, and indicates the possible loss of events."
And delete the sentence from both 8.4 and 8.5 saying...
"Suspensions are notified to the subscriber..."
.
>  What happens if the call home
>   setup due to authentication issues, will it still try to
>   re-establish?

For NETCONF, see Section 5.2 of draft-ietf-netconf-netconf-event-notificati=
ons.
=20
>   The new text says:
>=20
>      Note that is possible to configure replay on a configured
>      subscription.  This is to allows a configured subscription to
>      exist on a system so that event records generated during boot can
>      be buffered and pushed as soon as the transport session is
>      established.
>=20
>   I assume this means that the reciever must be prepared to receive
>   the same events multiple times?  (if the server reboots before the
>   replay buffer has been overwritten)

No, boot time is considered.   The proper operation is documented in the YA=
NG model..

  notification subscription-started {
    uses subscription-policy {
      refine "target/stream/replay-start-time"
           "Indicates the time that a replay using for the streaming of
           buffered event records.  This will be populated with the most
           recent of the following: replay-log-creation-time,
           replay-log-aged-time, replay-start-time, or the most recent
           publisher boot time.";

> o  Section 9.2
>=20
>   s/yang/YANG/

Will fix

>   Also, the text says:
>=20
>     In addition support for optional features: encode-xml,
>     encode-json, configured, and replay MUST also be indicated if
>     supported.
>=20
>   I think you should remove this sentence; it is redundant.  If you
>   decide to keep it, write:
>=20
>=20
>     In addition support for optional features: "encode-xml",
>     "encode-json", "configured", "replay", "xpath", and "subtree" MUST
>     also be indicated if supported.

Will do this one. =20

>   BTW, why did you rename "configured-subscriptions" to "configured"?
>   "configured" looks a bit short.

Due to the YANG tree.   The longer feature name causes make a significant n=
umber of the lines exceed the character limit for a row.   And things becom=
e very difficult to read.

> o  10 - extension
>=20
>      extension subscription-state-notif {
>=20
>   I think you should spell out "notification"; i.e., use
>   subscription-state-notification.
>=20
>   (You replied "will do" to this comment in my previous review, so I
>   suspect you simply forgot this one)

Yes.  This time I really will do :-)

> o  10 - filter-spec
>=20
>   I think both the subtree and XPath filters are not correctly
>   defined.  I provided text about the XPath filter, but you didn't
>   include it, so here it is again, updated with your text about
>   events.


Thanks for keeping on about this.  The definitions you provide are an upgra=
de, and I will include.
=20
>       anydata subtree-filter {
>         description
>=20
>=20
>   OLD:
>=20
>           "Event stream evaluation criteria encoded in a syntax of a
>            supported type of an RFC 6241, Section 6 filter.  The subtree
>            filter is applied to the representation of individual,
>            delineated event records as contained within the event
>            stream.  For example, if the notification message contains an
>            instance of a notification defined in YANG, then the top-
>            level element is the name of the YANG notification.  If the
>            stream filter matches an event record from the stream, the
>            event record should be included in a notification message
>            to the receiver(s).";
>       }
>=20
>   NEW:
>=20
>           "Event stream evaluation criteria encoded in the syntax of
>            a subtree filter as defined in RFC 6241, Section 6.
>=20
>            The subtree filter is applied to the representation of
>            individual, delineated event records as contained within
>            the event stream.  For example, if the notification message
>            contains an instance of a notification defined in YANG,
>            then the top-level element is the name of the YANG
>            notification.
>=20
>            If the subtree filter returns a non-empty node set, the
>            filter matches the event record, and the it is included in
>            the notification message sent to the receivers.";
>=20
>         reference "RFC 6241, Section 6.";
>       }
>=20
>   and:
>=20
>       leaf xpath-filter {
>         type yang:xpath1.0;
>         description
>=20
>   OLD:
>=20
>           "Event stream evaluation criteria encoded in a syntax of xpath
>            1.0 and applied against an event stream. The result of
>            applying XPath expression is converted to a boolean value
>            using the standard XPath 1.0 rules.  If the boolean value is
>            'true', the stream filter matches an event record within the
>            stream, and the notification message should be sent to the
>            receiver(s).";
>=20
>   NEW:
>=20
>           "Event stream evaluation criteria encoded in the syntax of
>            an XPath 1.0 expression.
>=20
>            The XPath expression is evaluated on the representation of
>            individual, delineated event records as contained within
>            the event stream.  For example, if the notification message
>            contains an instance of a notification defined in YANG,
>            then the top-level element is the name of the YANG
>            notification, and the root node has this top-level element
>            as the only child.
>=20
>            The result of the XPath expression is converted to a
>            boolean value using the standard XPath 1.0 rules.  If the
>            boolean value is 'true', the filter matches the the event
>            record, and the it is included in the notification message
>            sent to the receivers.
>=20
>            The expression is evaluated in the following XPath context:
>=20
>              o  The set of namespace declarations are those in scope on
>                 the 'xpath-filter' leaf element where th
>=20
>              o  The set of variable bindings is empty.
>=20
>              o  The function library is the core function library, and
>                 the XPath functions defined in section 10 in RFC 7950.
>=20
>              o  The context node is the root node.
>=20
>         reference
>           "http://www.w3.org/TR/1999/REC-xpath-19991116
>            RFC 7950, Section 10.";
>       }
>=20
>=20
>=20
> o  10 - grouping notification-origin-info
>=20
>   In your reply tpo my previous review, you wrote that you would
>   remove the term "push source".  It is still used.

Yes, will update.

Eric

>=20
> /martin
>=20
>=20
>=20
>=20


From nobody Wed Nov 15 17:46:47 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2498F12894A for ; Wed, 15 Nov 2017 17:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SX8dCq26O0Rb for ; Wed, 15 Nov 2017 17:46:30 -0800 (PST)
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 E5F76124319 for ; Wed, 15 Nov 2017 17:46:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32484; q=dns/txt; s=iport; t=1510796789; x=1512006389; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lyS208qFa05XKY4uUNRfRi5RcLUFIDtTxhz0WvkDHyw=; b=R3lJzK6mVXpZRExelG4z8swy6qNUtL2aYD5t1ltt9Xfo/LS1NUQs5b32 LB0atY+3MC7fEjgU+8uZgSw/ZRglQ9Pto06BhS8ycfG7ecIGS28VMPRMu VWNLfZ8Pz3UsKnV9jDzH2ifg/3tBTYyK8eQvw5uN66y0zLSzK3Q0u1lZz Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAADu7Axa/4ENJK0WBUMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkRyZG4nB4N4ih+PIIF9ll2CEQoYAQqESU8CGoR0PxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUeAQEBBAEBIQohGAgbAgEIEQQBAQ0BEwcDAgICJQoBFAkIAgQBD?= =?us-ascii?q?gQBBxMCBIkfZBCFGqRKgicmimkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgzSCB4F?= =?us-ascii?q?VgWmDKoMkIIEtPh+CX4JjBZkeiRkCh2uNEIIekS+KM4I8iRICERkBgTgBHziBd?= =?us-ascii?q?HoVSYJkCQqCSRyBZ3cBB4hOgTOBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200";  d="scan'208,217";a="321198950"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 01:46:28 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAG1kS9R003934 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Nov 2017 01:46:28 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 20:46:27 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 20:46:27 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" 
Thread-Topic: [Netconf] SN #6 String or Integer for Subscription ID
Thread-Index: AQHTTC+bmnoVz/P44ke/JeKF0s6HTqMTrjKggAFfVACAAVHIYA==
Date: Thu, 16 Nov 2017 01:46:27 +0000
Message-ID: 
References: <72EC9947-3A3B-425A-A5D7-93D1D1C6778E@cisco.com>  <1515b54b-796d-a3c5-897f-8a2975018d25@cisco.com>
In-Reply-To: <1515b54b-796d-a3c5-897f-8a2975018d25@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: multipart/alternative; boundary="_000_fb9a8ec97d574d60933b44752d318e63XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 01:46:33 -0000

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

WWVzLiAgIFdlIGFyZSBjb21taXR0aW5nIHRvIHB1Ymxpc2ggTk1EQSBzdHlsZSB0cmVlcyB3aGVu
IFlBTkcgcHVzaCBpcyBkZWVtZWQgcmVhZHkgZm9yIFdHTEMuICBQZW9wbGUgY2FuIHRoZW4gZG8g
YW4gYXBwbGVzLXRvLWFwcGxlcyBjb21wYXJpc29uIGJldHdlZW4gdGhlIHR3byByZXByZXNlbnRh
dGlvbnMuDQoNCkVyaWMNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIgMTQsIDIwMTcg
NzozMSBQTQ0KDQoNCmkgRXJpYywNCg0KRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgY29uZmlndXJl
ZC1zdWJzY3JpcHRpb25zIGFuZCBzdWJzY3JpcHRpb25zIHRyZWUgd2lsbCBiZSBjb21iaW5lZCBp
bnRvIGEgc2luZ2xlIHRyZWUgKE5NREEgc3R5bGUpPw0KDQpUaGFua3MsDQpSb2INCg0KT24gMTQv
MTEvMjAxNyAxNjo0MCwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQpBZnRlciBsb3RzIG9mIGlu
dGVyYWN0aW9ucyBhbmQgZ29vZCBkaXNjdXNzaW9uLCBhIG1ham9yaXR5IG9mIHBlb3BsZSBoYXZl
IGV4cHJlc3NlZCBhIGRlc2lyZSBmb3IgaW50ZWdlciBvdmVyIHN0cmluZyBmb3IgdGhlIGlkZW50
aWZpY2F0aW9uIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4gIEJhc2VkIG9uIHRoYXQgSSBh
bSBjbG9zaW5nIHRoZSBpc3N1ZSBTTiM2IHdpdGggbm8gY2hhbmdlcyB0byB0aGUgeWFuZyBtb2Rl
bC4NCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNg0K
DQpFcmljDQoNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIFRpbSBKZW5raW5zICh0aW1qZW5raSkNClNlbnQ6IE1vbmRheSwgT2N0
b2JlciAyMywgMjAxNyAyOjQ5IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29u
ZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gU04gIzYgU3RyaW5nIG9yIEludGVn
ZXIgZm9yIFN1YnNjcmlwdGlvbiBJRA0KDQpBbGwsDQoNClRoaXMgbm90ZSBhdHRlbXB0cyB0byB0
YWtlIGEgZGV0YWlsZWQgbG9vayBhdCB0aGUgdHdvIG1haW4gcHJvcG9zYWxzIGZvciB0aGUgdXNl
IG9mIHN1YnNjcmlwdGlvbiBJRHMgZm9yIHRoZSBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMgZHJh
ZnQuDQoNClRoZSB0d28gcHJvcG9zYWxzIHRoYXQgSSdsbCBleGFtaW5lIGhlcmUgYXJlICdzaW5n
bGUgaW50ZWdlciBJRCB0eXBlJyBhbmQgJ21peGVkIElEIHR5cGUnIGFzIEknbSByZWZlcnJpbmcg
dG8gdGhlbS4gUHJvcG9zYWxzIHdoZXJlIHRoZSB1cGRhdGUgbm90aWZpY2F0aW9ucyBhcmUgZGlm
ZmVyZW50IGZyb20gY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFuZCBkeW5hbWljIHN1YnNjcmlw
dGlvbnMgYXJlIG5vdCBjb25zaWRlcmVkLCBzaW5jZSB0aGF0IGlzIGhpZ2hseSB1bmRlc2lyYWJs
ZSBhbmQgbW9yZSBjb21wbGV4Lg0KDQpJbiB0aGUgJ3NpbmdsZSBpbnRlZ2VyIElEIHR5cGUnIHBy
b3Bvc2FsLCB0aGUgc3Vic2NyaXB0aW9uIHJlY29yZHMgaW4gYm90aCB0aGUgY29uZmlndXJhdGlv
biBhbmQgb3BlcmF0aW9uYWwgdGFibGVzIG9mIHN1YnNjcmlwdGlvbnMgYXJlIGluZGV4ZWQgYnkg
YSAzMi1iaXQgaW50ZWdlciB2YWx1ZS4gU2luY2UgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFs
c28gYXBwZWFyIGluIHRoZSBvcGVyYXRpb25hbCB0YWJsZSwgdGhlIGluZGV4IHNwYWNlIGlzIGNv
bW1vbiBiZXR3ZWVuIGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGlvbmFsIHN1YnNjcmlwdGlvbnMuIFN1
YnNjcmliZXJzIGNyZWF0ZSB0aGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gSURzLCB3aGlsZSB0
aGUgcHVibGlzaGVyIGNyZWF0ZXMgdGhlIGR5bmFtaWMgc3Vic2NyaXB0aW9uIElEcy4gVGh1cywg
dGhlcmUgaXMgYW4gaXNzdWUgb2YgcG90ZW50aWFsIGNvbmZsaWN0OyBpdCBoYXMgYmVlbiBwcm9w
b3NlZCB0byBzcGxpdCB0aGUgc3BhY2UgYmV0d2VlbiBzdWJjcmliZXIgYW5kIHB1Ymxpc2hlciBn
ZW5lcmF0ZWQgdG8gcmVtb3ZlIHRoaXMgcG90ZW50aWFsIGNvbmZsaWN0Lg0KDQpJbiB0aGUgJ21p
eGVkIElEIHR5cGUnIHByb3Bvc2FsLCBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgYXJlIGNyZWF0
ZWQgd2l0aCBhIHN0cmluZyBJRCBieSB0aGUgc3Vic2NyaWJlciwgYW5kIGR5bmFtaWMgc3Vic2Ny
aXB0aW9ucyBhcmUgY3JlYXRlZCB3aXRoIGEgMzItYml0IGludGVnZXIgSUQgYnkgdGhlIHB1Ymxp
c2hlci4gVGhlIHB1Ymxpc2hlciBhbHNvIGNyZWF0ZXMgYSAzMi1iaXQgaW50ZWdlciBJRCBmb3Ig
Y29uZmlndXJlZCBzdWJzY3JpcHRpb25zLCBzbyB0aGV5IGVmZmVjdGl2ZWx5IGhhdmUgdHdvIElE
cy4gVGhlc2UgYXJlIHJlZmVycmVkIHRvIGFzIHRoZSBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoIElE
cyBmb3IgdGhlIHJlc3Qgb2YgdGhpcyBub3RlLiBUaGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb25z
IHRhYmxlIGlzIGluZGV4ZWQgYnkgdGhlIHN1YnNjcmliZXIgSUQgYW5kIHRoZSBwdWJsaXNoZXIg
SUQgZG9lcyBub3QgYXBwZWFyIGluIHRoaXMgdGFibGUgYmVjYXVzZSBpdCBpcyBub3QgY29uZmln
dXJhdGlvbiBkYXRhLiBUaGUgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9ucyB0YWJsZSBpcyBpbmRl
eGVkIGJ5IHRoZSBwdWJsaXNoZXIgSUQgYW5kIHRoZSBzdWJzY3JpYmVyIElEIGFwcGVhcnMgaW4g
dGhpcyB0YWJsZSwgYnV0IG9ubHkgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGVudHJpZXMu
DQoNCkkgd2lsbCBhdHRlbXB0IHRvIGV2YWx1YXRlIHRoZSB0d28gcHJvcG9zYWxzIGFnYWluc3Qg
c29tZSBpc3N1ZXMuDQoNCjEvIEhvdyBhIHJlY2VpdmVyIGlkZW50aWZpZXMgd2hpY2ggc3Vic2Ny
aXB0aW9uIGFuIHVwZGF0ZSBub3RpZmljYXRpb24ncyBjb250ZW50cyBhcmUgYXNzb2NpYXRlZCB3
aXRoLg0KDQonc2luZ2xlIGludGVnZXIgSUQnICAgICAgICAgICAgICAgLXVzZXMgb25seSBJRCBh
dmFpbGFibGUsIGJ1dCBjYW4gdXNlIHRoZSBJRCBpbiB0aGUgJ3N1YnNjcmlwdGlvbi1zdGFydGVk
JyBub3RpZmljYXRpb24gYXMgd2VsbA0KJ21peGVkIElEcycgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLWxlYXJucyBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoZXIgSURzIGZyb20gJ3N1YnNjcmlw
dGlvbi1zdGFydGVkJyBub3RpZmljYXRpb24uIFRoaXMgbm90aWZpY2F0aW9uIGhhcyB0byBiZSBt
b2RpZmllZCB0byBjYXJyeSBpdCwgYW5kIHJlY2VpdmVycyBoYXZlIHRvIHBhcnNlIGl0Lg0KDQoy
LyBIb3cgdGhlIGlzc3VlIG9mIG11bHRpcGxlIHNvdXJjZXMgb2YgSUQgZ2VuZXJhdGlvbiBpcyBo
YW5kbGVkLg0KDQonc2luZ2xlIGludGVnZXIgSUQnICAgICAgICAgICAgICAgLXNwbGl0IHRoZSAz
Mi1iaXQgaW50ZWdlciBzcGFjZSBmb3IgaXNzdWUgYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNj
cmliZXJzOyB0aGlzIGRvZXMgbm90IHNvbHZlIGlzc3VlIGFtb25nIG11bHRpcGxlIHN1YnNjcmli
ZXJzDQonbWl4ZWQgSURzJyAgICAgICAgICAgICAgICAgICAgICAgICAgIC1ub3QgYW4gaXNzdWUg
YmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXJzOyBidXQgZG9lcyBub3Qgc29sdmUgaXNz
dWUgYW1vbmcgbXVsdGlwbGUgc3Vic2NyaWJlcnMNCg0KMy8gSG93IHN1YnNjcmlwdGlvbnMgYXJl
IGFzc29jaWF0ZWQgYWNyb3NzIG11bHRpcGxlIHB1Ymxpc2hlcnMuIFRoYXQgaXMsIGhvdyBkbyBz
ZXBhcmF0ZSByZWNlaXZlcnMga25vdyB3aGljaCBzdWJzY3JpcHRpb25zIGFyZSBjb25zaWRlcmVk
IHRvIGJlIHRoZSBzYW1lIHdoZW4gdGhleSBhcnJpdmUgZnJvbSBkaWZmZXJlbnQgcHVibGlzaGVy
cz8NCg0KJ3NpbmdsZSBpbnRlZ2VyIElEJyAgICAgICAgICAgICAgIC1zdWJzY3JpYmVyIHNlbmRz
IHRvIHJlY2VpdmVycyB0aGUgSURzIGl0IHVzZWQgdG8gY3JlYXRlIHRoZSBzdWJzY3JpcHRpb25z
OyBpdCBzaG91bGQgaGF2ZSB1c2VkIHRoZSBzYW1lIElEIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRp
b25zIG9uIHNlcGFyYXRlIHB1Ymxpc2hlcnMNCidtaXhlZCBJRHMnICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLXN1YnNjcmliZXIgc2VuZHMgdG8gcmVjZWl2ZXJzIHRoZSBJRHMgaXQgdXNlZCB0
byBjcmVhdGUgdGhlIHN1YnNjcmlwdGlvbnM7IGl0IHNob3VsZCBoYXZlIHVzZWQgdGhlIHNhbWUg
SUQgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbnMgb24gc2VwYXJhdGUgcHVibGlzaGVycy4gVGhl
IHJlY2VpdmVycyBtdXN0IHBhcnNlIHRoZSAnc3Vic2NyaXB0aW9uLXN0YXJ0ZWQnIG5vdGlmaWNh
dGlvbnMgZnJvbSBwdWJsaXNoZXJzIGFuZCBjcmVhdGUgYW5kIG1haW50YWluIGEgbWFwIG9mIGlu
dGVnZXJzIElEcyB0byB0ZXh0IElEcy4gVGhpcyBtYXAgbXVzdCBiZSB1c2VkIHdpdGggdXBkYXRl
IG5vdGlmaWNhdGlvbnMsIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIHN1YnNjcmlwdGlvbiBJRCBv
ZiBpbnRlcmVzdC4NCg0KNC8gSG93IGh1bWFuIHJlYWRhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRo
ZSBzdWJzY3JpcHRpb25zIGlzIHByb3ZpZGVkLg0KDQonc2luZ2xlIGludGVnZXIgSUQnICAgICAg
ICAgICAgICAgLWFuIHVucmVzdHJpY3RlZCB0ZXh0IGZpZWxkIGNhbiBiZSBhZGRlZCB0byBzdWJz
Y3JpcHRpb25zIGFzIG5lZWRlZC4gVGhlIGFkZGl0aW9uIG9mIGFuIHVucmVzdHJpY3RlZCB0ZXh0
IGZpZWxkIGNhbiBiZSBkb25lIGZvciBib3RoIGNvbmZpZ3VyZWQgYW5kIGR5bmFtaWMgc3Vic2Ny
aXB0aW9ucyBpZiBkZXNpcmVkIGFuZCBtYWtlcyB0aGUgbmVlZCBmb3IgYSB0ZXh0IElEIHN0cmlu
ZyB1bm5lY2Vzc2FyeS4NCidtaXhlZCBJRHMnICAgICAgICAgICAgICAgICAgICAgICAgICAgLXRo
ZSBzdHJpbmcgSUQgdXNlZCBpcyBsaW1pdGVkOiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMgb25s
eSwgYW5kIG11c3QgYmUgYWJsZSB0byBiZSBhIGtleQ0KDQpBZGRpdGlvbmFsIE5vdGVzOg0KDQpJ
bnRlZ2VyIElEIFNwYWNlIFNwbGl0OiBGb3IgdGhlIHNpbmdsZSBpbnRlZ2VyIElEIGNhc2UsIHRo
aXMgaXMgYSB2ZXJ5IHNpbXBsZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4gQXMgY3VycmVudGx5
IHByb3Bvc2VkLCB0aGUgdXBwZXIgaGFsZiBvZiB0aGUgMzItYml0IHVuc2lnbmVkIGludGVnZXIg
c3BhY2UgaXMgc2V0IGFzaWRlIGZvciBkeW5hbWljIHN1YnNjcmlwdGlvbnMsIGJ1dCBvdGhlciBz
cGxpdHMgYXJlIHBvc3NpYmxlLiBPbmUgd291bGQgYmUgdG8gdXNlIHNpZ25lZCBpbnRlZ2Vycywg
YW5kIHVzZSB0aGUgc2lnbiB0byBzcGl0IHRoZSBzcGFjZS4gVGhpcyB3b3VsZCBhbGxvdyB0aGUg
dXNlIG9mIHNtYWxsIGludGVnZXJzIGZvciBib3RoIGNvbmZpZ3VyZWQgYW5kIGR5bmFtaWMgc3Vi
c2NyaXB0aW9ucyB3aGVuIGVuY29kaW5nIHJ1bGVzIGNhbiB0YWtlIGFkdmFudGFnZSBvZiBzdWNo
IHRoaW5ncy4NCg0KQ29uY2x1c2lvbjoNCg0KVGhlIHVzZSBvZiBhIHN0cmluZyBhcyBhIHN1YnNj
cmlwdGlvbiBJRCBpcyBvdmVyYWxsIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBmaW5kaW5nIGEgc2lt
cGxlIHNvbHV0aW9uIGZvciBzcGxpdHRpbmcgdGhlIGludGVnZXIgSUQgc3BhY2UgYmV0d2VlbiBw
dWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgc3BhY2UuDQoNClRpbQ0KDQotLQ0KQ2lzY28gU3lzdGVt
cyBDYW5hZGEgQ28uDQoyMDAwIElubm92YXRpb24gRHJpdmUNCkthbmF0YSwgT04sIENhbmFkYSwg
SzJLIDNFOA0KUHJlZmVyZW5jZXMgPGh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmli
ZS8/c2lkPTAwMDQ3ODMyNj4NClVuc3Vic2NyaWJlIDxodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZl
ci91bnN1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNz4NClByaXZhY3kgPGh0dHA6Ly93d3cuY2lzY28u
Y29tL3dlYi9zaXRlYXNzZXRzL2xlZ2FsL3ByaXZhY3kuaHRtbD4NCg0KDQoNCg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpOZXRjb25mIG1haWxp
bmcgbGlzdA0KDQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAs
IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h
bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu
MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr
O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0
ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN
Cglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUy
Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp
bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlllcy4m
bmJzcDsmbmJzcDsgV2UgYXJlIGNvbW1pdHRpbmcgdG8gcHVibGlzaCBOTURBIHN0eWxlIHRyZWVz
IHdoZW4gWUFORyBwdXNoIGlzIGRlZW1lZCByZWFkeSBmb3IgV0dMQy4mbmJzcDsgUGVvcGxlIGNh
biB0aGVuIGRvIGFuIGFwcGxlcy10by1hcHBsZXMgY29tcGFyaXNvbiBiZXR3ZWVuIHRoZSB0d28g
cmVwcmVzZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkVy
aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIg
MTQsIDIwMTcgNzozMSBQTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8cD5pIEVyaWMsPG86cD48L286cD48L3A+DQo8cD5Eb2VzIHRoaXMgbWVhbiB0
aGF0IHRoZSBjb25maWd1cmVkLXN1YnNjcmlwdGlvbnMgYW5kIHN1YnNjcmlwdGlvbnMgdHJlZSB3
aWxsIGJlIGNvbWJpbmVkIGludG8gYSBzaW5nbGUgdHJlZSAoTk1EQSBzdHlsZSk/PG86cD48L286
cD48L3A+DQo8cD5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiAxNC8xMS8yMDE3IDE2OjQwLCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5BZnRlciBsb3RzIG9mIGludGVyYWN0aW9ucyBhbmQg
Z29vZCBkaXNjdXNzaW9uLCBhIG1ham9yaXR5IG9mIHBlb3BsZSBoYXZlIGV4cHJlc3NlZCBhIGRl
c2lyZSBmb3IgaW50ZWdlciBvdmVyIHN0cmluZyBmb3IgdGhlIGlkZW50aWZpY2F0aW9uIG9mIGNv
bmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4mbmJzcDsgQmFzZWQgb24gdGhhdCBJIGFtIGNsb3NpbmcN
CiB0aGUgaXNzdWUgU04jNiB3aXRoIG5vIGNoYW5nZXMgdG8gdGhlIHlhbmcgbW9kZWwuPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6
IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jp
cy9pc3N1ZXMvNiI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1
ZXMvNjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtjb2xvcjojMUY0OTdEIj5FcmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PlRpbSBKZW5raW5zICh0aW1qZW5raSk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVy
IDIzLCAyMDE3IDI6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRjb25m
QGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W05ldGNvbmZdIFNOICM2IFN0cmluZyBvciBJbnRlZ2VyIGZvciBTdWJzY3JpcHRpb24gSUQ8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+QWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+VGhpcyBub3RlIGF0dGVtcHRzIHRvIHRha2UgYSBkZXRhaWxlZCBsb29rIGF0IHRo
ZSB0d28gbWFpbiBwcm9wb3NhbHMgZm9yIHRoZSB1c2Ugb2Ygc3Vic2NyaXB0aW9uIElEcyBmb3Ig
dGhlIHN1YnNjcmliZWQgbm90aWZpY2F0aW9ucyBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSB0d28gcHJvcG9zYWxzIHRoYXQgSSdsbCBleGFtaW5l
IGhlcmUgYXJlICdzaW5nbGUgaW50ZWdlciBJRCB0eXBlJyBhbmQgJ21peGVkIElEIHR5cGUnIGFz
IEknbSByZWZlcnJpbmcgdG8gdGhlbS4gUHJvcG9zYWxzIHdoZXJlIHRoZSB1cGRhdGUgbm90aWZp
Y2F0aW9ucyBhcmUgZGlmZmVyZW50IGZyb20gY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFuZA0K
IGR5bmFtaWMgc3Vic2NyaXB0aW9ucyBhcmUgbm90IGNvbnNpZGVyZWQsIHNpbmNlIHRoYXQgaXMg
aGlnaGx5IHVuZGVzaXJhYmxlIGFuZCBtb3JlIGNvbXBsZXguPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiB0aGUgJ3NpbmdsZSBpbnRlZ2VyIElEIHR5cGUnIHBy
b3Bvc2FsLCB0aGUgc3Vic2NyaXB0aW9uIHJlY29yZHMgaW4gYm90aCB0aGUgY29uZmlndXJhdGlv
biBhbmQgb3BlcmF0aW9uYWwgdGFibGVzIG9mIHN1YnNjcmlwdGlvbnMgYXJlIGluZGV4ZWQgYnkg
YSAzMi1iaXQgaW50ZWdlciB2YWx1ZS4gU2luY2UgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGFs
c28NCiBhcHBlYXIgaW4gdGhlIG9wZXJhdGlvbmFsIHRhYmxlLCB0aGUgaW5kZXggc3BhY2UgaXMg
Y29tbW9uIGJldHdlZW4gY29uZmlndXJlZCBhbmQgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9ucy4g
U3Vic2NyaWJlcnMgY3JlYXRlIHRoZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBJRHMsIHdoaWxl
IHRoZSBwdWJsaXNoZXIgY3JlYXRlcyB0aGUgZHluYW1pYyBzdWJzY3JpcHRpb24gSURzLiBUaHVz
LCB0aGVyZSBpcyBhbiBpc3N1ZSBvZiBwb3RlbnRpYWwNCiBjb25mbGljdDsgaXQgaGFzIGJlZW4g
cHJvcG9zZWQgdG8gc3BsaXQgdGhlIHNwYWNlIGJldHdlZW4gc3ViY3JpYmVyIGFuZCBwdWJsaXNo
ZXIgZ2VuZXJhdGVkIHRvIHJlbW92ZSB0aGlzIHBvdGVudGlhbCBjb25mbGljdC48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkluIHRoZSAnbWl4ZWQgSUQgdHlwZScg
cHJvcG9zYWwsIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyBhcmUgY3JlYXRlZCB3aXRoIGEgc3Ry
aW5nIElEIGJ5IHRoZSBzdWJzY3JpYmVyLCBhbmQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGFyZSBj
cmVhdGVkIHdpdGggYSAzMi1iaXQgaW50ZWdlciBJRCBieSB0aGUgcHVibGlzaGVyLiBUaGUgcHVi
bGlzaGVyIGFsc28NCiBjcmVhdGVzIGEgMzItYml0IGludGVnZXIgSUQgZm9yIGNvbmZpZ3VyZWQg
c3Vic2NyaXB0aW9ucywgc28gdGhleSBlZmZlY3RpdmVseSBoYXZlIHR3byBJRHMuIFRoZXNlIGFy
ZSByZWZlcnJlZCB0byBhcyB0aGUgc3Vic2NyaWJlciBhbmQgcHVibGlzaCBJRHMgZm9yIHRoZSBy
ZXN0IG9mIHRoaXMgbm90ZS4gVGhlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucyB0YWJsZSBpcyBp
bmRleGVkIGJ5IHRoZSBzdWJzY3JpYmVyIElEIGFuZCB0aGUgcHVibGlzaGVyDQogSUQgZG9lcyBu
b3QgYXBwZWFyIGluIHRoaXMgdGFibGUgYmVjYXVzZSBpdCBpcyBub3QgY29uZmlndXJhdGlvbiBk
YXRhLiBUaGUgb3BlcmF0aW9uYWwgc3Vic2NyaXB0aW9ucyB0YWJsZSBpcyBpbmRleGVkIGJ5IHRo
ZSBwdWJsaXNoZXIgSUQgYW5kIHRoZSBzdWJzY3JpYmVyIElEIGFwcGVhcnMgaW4gdGhpcyB0YWJs
ZSwgYnV0IG9ubHkgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGVudHJpZXMuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdpbGwgYXR0ZW1wdCB0byBldmFs
dWF0ZSB0aGUgdHdvIHByb3Bvc2FscyBhZ2FpbnN0IHNvbWUgaXNzdWVzLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+MS8gSG93IGEgcmVjZWl2ZXIgaWRlbnRpZmll
cyB3aGljaCBzdWJzY3JpcHRpb24gYW4gdXBkYXRlIG5vdGlmaWNhdGlvbidzIGNvbnRlbnRzIGFy
ZSBhc3NvY2lhdGVkIHdpdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4nc2luZ2xlIGludGVnZXIgSUQnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC11c2Vz
IG9ubHkgSUQgYXZhaWxhYmxlLCBidXQgY2FuIHVzZSB0aGUgSUQgaW4gdGhlICdzdWJzY3JpcHRp
b24tc3RhcnRlZCcgbm90aWZpY2F0aW9uIGFzIHdlbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+J21peGVk
IElEcycmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLWxl
YXJucyBzdWJzY3JpYmVyIGFuZCBwdWJsaXNoZXIgSURzIGZyb20gJ3N1YnNjcmlwdGlvbi1zdGFy
dGVkJyBub3RpZmljYXRpb24uIFRoaXMgbm90aWZpY2F0aW9uIGhhcyB0byBiZSBtb2RpZmllZCB0
byBjYXJyeSBpdCwgYW5kIHJlY2VpdmVycyBoYXZlIHRvIHBhcnNlIGl0Ljwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Mi8gSG93IHRoZSBpc3N1ZSBvZiBtdWx0aXBs
ZSBzb3VyY2VzIG9mIElEIGdlbmVyYXRpb24gaXMgaGFuZGxlZC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidzaW5nbGUgaW50ZWdlciBJRCcmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgLXNwbGl0IHRoZSAzMi1iaXQgaW50ZWdlciBzcGFjZSBmb3IgaXNzdWUg
YmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXJzOyB0aGlzIGRvZXMgbm90IHNvbHZlIGlz
c3VlIGFtb25nIG11bHRpcGxlIHN1YnNjcmliZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidtaXhlZCBJ
RHMnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LW5vdCBh
biBpc3N1ZSBiZXR3ZWVuIHB1Ymxpc2hlciBhbmQgc3Vic2NyaWJlcnM7IGJ1dCBkb2VzIG5vdCBz
b2x2ZSBpc3N1ZSBhbW9uZyBtdWx0aXBsZSBzdWJzY3JpYmVyczwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+My8gSG93IHN1YnNjcmlwdGlvbnMgYXJlIGFzc29jaWF0
ZWQgYWNyb3NzIG11bHRpcGxlIHB1Ymxpc2hlcnMuIFRoYXQgaXMsIGhvdyBkbyBzZXBhcmF0ZSBy
ZWNlaXZlcnMga25vdyB3aGljaCBzdWJzY3JpcHRpb25zIGFyZSBjb25zaWRlcmVkIHRvIGJlIHRo
ZSBzYW1lIHdoZW4gdGhleSBhcnJpdmUgZnJvbSBkaWZmZXJlbnQgcHVibGlzaGVycz88L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPidzaW5nbGUgaW50ZWdlciBJRCcm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLXN1YnNjcmliZXIgc2VuZHMgdG8gcmVjZWl2ZXJz
IHRoZSBJRHMgaXQgdXNlZCB0byBjcmVhdGUgdGhlIHN1YnNjcmlwdGlvbnM7IGl0IHNob3VsZCBo
YXZlIHVzZWQgdGhlIHNhbWUgSUQgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbnMgb24gc2VwYXJh
dGUgcHVibGlzaGVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4nbWl4ZWQgSURzJyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy1zdWJzY3JpYmVyIHNlbmRzIHRvIHJl
Y2VpdmVycyB0aGUgSURzIGl0IHVzZWQgdG8gY3JlYXRlIHRoZSBzdWJzY3JpcHRpb25zOyBpdCBz
aG91bGQgaGF2ZSB1c2VkIHRoZSBzYW1lIElEIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb25zIG9u
IHNlcGFyYXRlIHB1Ymxpc2hlcnMuIFRoZSByZWNlaXZlcnMNCiBtdXN0IHBhcnNlIHRoZSAnc3Vi
c2NyaXB0aW9uLXN0YXJ0ZWQnIG5vdGlmaWNhdGlvbnMgZnJvbSBwdWJsaXNoZXJzIGFuZCBjcmVh
dGUgYW5kIG1haW50YWluIGEgbWFwIG9mIGludGVnZXJzIElEcyB0byB0ZXh0IElEcy4gVGhpcyBt
YXAgbXVzdCBiZSB1c2VkIHdpdGggdXBkYXRlIG5vdGlmaWNhdGlvbnMsIHRvIGRldGVybWluZSB0
aGUgYWN0dWFsIHN1YnNjcmlwdGlvbiBJRCBvZiBpbnRlcmVzdC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+NC8gSG93IGh1bWFuIHJlYWRhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdWJzY3JpcHRp
b25zIGlzIHByb3ZpZGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+J3NpbmdsZSBpbnRlZ2VyIElEJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtYW4gdW5y
ZXN0cmljdGVkIHRleHQgZmllbGQgY2FuIGJlIGFkZGVkIHRvIHN1YnNjcmlwdGlvbnMgYXMgbmVl
ZGVkLiBUaGUgYWRkaXRpb24gb2YgYW4gdW5yZXN0cmljdGVkIHRleHQgZmllbGQgY2FuIGJlIGRv
bmUgZm9yIGJvdGggY29uZmlndXJlZCBhbmQgZHluYW1pYyBzdWJzY3JpcHRpb25zIGlmDQogZGVz
aXJlZCBhbmQgbWFrZXMgdGhlIG5lZWQgZm9yIGEgdGV4dCBJRCBzdHJpbmcgdW5uZWNlc3Nhcnku
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPidtaXhlZCBJRHMnJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LXRoZSBzdHJpbmcgSUQgdXNlZCBpcyBsaW1pdGVkOiBjb25m
aWd1cmVkIHN1YnNjcmlwdGlvbnMgb25seSwgYW5kIG11c3QgYmUgYWJsZSB0byBiZSBhIGtleTwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWRkaXRpb25hbCBOb3Rl
czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkludGVnZXIgSUQg
U3BhY2UgU3BsaXQ6IEZvciB0aGUgc2luZ2xlIGludGVnZXIgSUQgY2FzZSwgdGhpcyBpcyBhIHZl
cnkgc2ltcGxlIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLiBBcyBjdXJyZW50bHkgcHJvcG9zZWQs
IHRoZSB1cHBlciBoYWxmIG9mIHRoZSAzMi1iaXQgdW5zaWduZWQgaW50ZWdlciBzcGFjZSBpcyBz
ZXQgYXNpZGUgZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucywNCiBidXQgb3RoZXIgc3BsaXRzIGFy
ZSBwb3NzaWJsZS4gT25lIHdvdWxkIGJlIHRvIHVzZSBzaWduZWQgaW50ZWdlcnMsIGFuZCB1c2Ug
dGhlIHNpZ24gdG8gc3BpdCB0aGUgc3BhY2UuIFRoaXMgd291bGQgYWxsb3cgdGhlIHVzZSBvZiBz
bWFsbCBpbnRlZ2VycyBmb3IgYm90aCBjb25maWd1cmVkIGFuZCBkeW5hbWljIHN1YnNjcmlwdGlv
bnMgd2hlbiBlbmNvZGluZyBydWxlcyBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2Ygc3VjaCB0aGluZ3Mu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db25jbHVzaW9uOjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHVzZSBvZiBhIHN0
cmluZyBhcyBhIHN1YnNjcmlwdGlvbiBJRCBpcyBvdmVyYWxsIG1vcmUgY29tcGxpY2F0ZWQgdGhh
biBmaW5kaW5nIGEgc2ltcGxlIHNvbHV0aW9uIGZvciBzcGxpdHRpbmcgdGhlIGludGVnZXIgSUQg
c3BhY2UgYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgc3BhY2UuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaW08L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+LS0mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Q2lzY28gU3lz
dGVtcyBDYW5hZGEgQ28uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpDb25zb2xhcyI+MjAwMCBJbm5vdmF0aW9uIERyaXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+S2FuYXRhLCBPTiwgQ2FuYWRhLCBLMksgM0U4
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+UHJl
ZmVyZW5jZXMgJmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL29mZmVyL3N1YnNjcmli
ZS8/c2lkPTAwMDQ3ODMyNiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmh0dHA6Ly93d3cuY2lz
Y28uY29tL29mZmVyL3N1YnNjcmliZS8/c2lkPTAwMDQ3ODMyNjwvc3Bhbj48L2E+Jmd0Ozwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPlVuc3Vic2Ny
aWJlICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9vZmZlci91bnN1YnNjcmliZS8/
c2lkPTAwMDQ3ODMyNyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmh0dHA6Ly93d3cuY2lzY28u
Y29tL29mZmVyL3Vuc3Vic2NyaWJlLz9zaWQ9MDAwNDc4MzI3PC9zcGFuPjwvYT4mZ3Q7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+UHJpdmFjeSAm
bHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL3NpdGVhc3NldHMvbGVnYWwvcHJp
dmFjeS5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+aHR0cDovL3d3dy5jaXNjby5jb20v
d2ViL3NpdGVhc3NldHMvbGVnYWwvcHJpdmFjeS5odG1sPC9zcGFuPjwvYT4mZ3Q7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi
Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5OZXRjb25mIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9
Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_fb9a8ec97d574d60933b44752d318e63XCHRTP013ciscocom_--


From nobody Wed Nov 15 19:43:35 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1A129486 for ; Wed, 15 Nov 2017 19:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9bruu2R-6y6d for ; Wed, 15 Nov 2017 19:43:31 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9526E129470 for ; Wed, 15 Nov 2017 19:43:30 -0800 (PST)
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; bh=MdcXvxJ5yPKqlJVkX+j0DRptSwM0Se3S+JM9ecMx8qU=; b=VI6VKU8ACXQoRa0BTbPpMY3hbr56LNn7M+msZ+XsXlT2PrPuMBufygLph+Z21Z6H/Vk4dVDWQ5yzZ/7SODFH5V2YgGHHIKfFdWC6uHpVIxUzv9jPvDxlE8meSxSjn79GDKaFiiyKCk5HXylNMVnJrOAAf7aK09QlxXwjnATagZw=
Received: from AM3PR07MB354.eurprd07.prod.outlook.com (10.242.109.145) by AM3PR07MB355.eurprd07.prod.outlook.com (10.242.109.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Thu, 16 Nov 2017 03:43:26 +0000
Received: from AM3PR07MB354.eurprd07.prod.outlook.com ([fe80::cd8a:4575:3695:dd34]) by AM3PR07MB354.eurprd07.prod.outlook.com ([fe80::cd8a:4575:3695:dd34%16]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 03:43:26 +0000
From: "Elbokl, Walid (Nokia - CA/Ottawa)" 
To: "netconf@ietf.org" 
Thread-Topic: Feedback on subscribed-notifications and yang-push
Thread-Index: AdNejQcCtPM/wh9HQrCltghlmRo4DA==
Date: Thu, 16 Nov 2017 03:43:26 +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=walid.elbokl@nokia.com; 
x-originating-ip: [135.245.20.29]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB355; 6:UYU0OsTlTzL8Ufx1ZZe2m8Hw3oSHut1SjYs5COKPcWImcBEavnvGMRDt2Sm6754R3Ng+LUJcSfGLzLFjuJjk76ZPmTKXW+Z4zIWu1CPg6T38km9MSdLXhIvKmlCeCJZUS1l44gmfeeX3Ac6ukW9ZwXW+fkghw2QAWC9N9hvZKzLxF+R2REbENKgsFDxc/6SMA2U3MTv1SMroAbcunr0Jn5YXlxvCfBa/yDYA3CpiE8+4cQ75KAAlTiVcQSpTVZth7lDFck0fV0TcF69r3bIAnSkkSjO1n5Tw7mckIcV3kMYZjbrArxy4cVAY+llDy5CE2CVdHWJPoRzGJ+SuB7v2CcjlVXeusSqTvRB8rBUm1TQ=; 5:p3zfSphMtsda8FdNQjunudUpbM1dufx/ot+V1ak7sSjgGhJ6a2nLSGevBkJfsUUcM7o/nzHPHpTeq31HOjqYFKozdyqmlZQU5i0Id8FRhzjJcwFdxT7YOb0laSg4CKFm3bcZkWPpiFOH0GG5IAuvaHzOBYygtCzeITbwYxf50C4=; 24:NxrUy4KD/0YZn6uryVD9FSNpEQZP5po0ztJJsRG+yB5b4dw7sluxcmNUgX4Ad4H/RlQp+TNSc27mO2YvOQxzZ+WYKcmLHRXqviUYhddOsps=; 7:W3dPxQ3K/rjJulhwY0kQrnxVhTNoZgGYK4797S9fz22lxwxIlBWwy3XW+CM/iFW6NabbFhmmwXXa/vuzrAOVSdN+FC2Cda505WTTW1O3obAV/vIUGbddvy9mIJRUW5Yv6vHRjBEQ2cdkxenjyeC4HRpZ6mCJn6jJLSZxDFIfTqRBAOBSdw9fmzy0ZEeaJuMffzZxrMpZINHuzRypu87tPYpgzrn1NkNzX/vg6nv6vinlSru1PI4UrJJgSSL4vB+z
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: fafdaaec-4c1f-46c3-6f45-08d52ca431e3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM3PR07MB355; 
x-ms-traffictypediagnostic: AM3PR07MB355:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231022)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB355; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB355; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(8936002)(2420400007)(74316002)(3846002)(7696004)(7736002)(966005)(4326008)(15650500001)(10710500007)(54906003)(99286004)(6116002)(102836003)(66066001)(478600001)(5660300001)(7110500001)(2900100001)(97736004)(305945005)(6916009)(25786009)(316002)(86362001)(6436002)(54356999)(101416001)(3660700001)(3280700002)(5250100002)(50986999)(2906002)(8676002)(5640700003)(68736007)(9686003)(55016002)(6306002)(81166006)(53936002)(106356001)(6506006)(2501003)(189998001)(33656002)(14454004)(81156014)(1730700003)(105586002)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB355; H:AM3PR07MB354.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB35413A6F11DFEE94C5529FC8D2E0AM3PR07MB354eurprd_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fafdaaec-4c1f-46c3-6f45-08d52ca431e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 03:43:26.4321 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB355
Archived-At: 
Subject: [Netconf] Feedback on subscribed-notifications and yang-push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 03:43:33 -0000

--_000_AM3PR07MB35413A6F11DFEE94C5529FC8D2E0AM3PR07MB354eurprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

I have reviewed:
-       draft-ietf-netconf-subscribed-notifications-07
-       draft-ietf-netconf-yang-push-11
and have the following mix of comments/questions:

1.      subscribed-notifications draft: What is the background/reason for n=
ot having dscp with notifications (i.e. same as with yang push)?
2.      subscribed-notifications draft: In figure 1/page 8, it implies that=
 a modification to a suspended subscription would get the subscription to b=
e active first before the server decides to keep it active or suspend it ag=
ain. I would have thought a modification can be considered by the server wh=
ile the subscription is still suspended then it could either become active =
or stay suspended
3.      subscribed-notifications draft: Fully agree with having replay with=
 notifications only and not yang-push
4.      subscribed-notifications draft: In "modify-subscription", though a =
subscriber-id is writeable (i.e. to be able to specify which subscription t=
o modify) but the server should not allow changing it on a suspended/active=
 subscription
5.      subscribed-notifications draft: In "modify-subscription", why not m=
odify "replay-start-time"? i.e. purge whole/part of the replay buffer
      Use case: purging whole/part of the replay buffer in scenarios where =
it may have been a reason to suspend a subscription
      The argument that the operator can cancel the subscription and re-est=
ablish another one applies to modifying everything and would mean no need f=
or modify-subscription from the first place. Also, an operator may consider=
 purging part of the buffer and not all.
6.      Yang push draft: page 11/Figure 1,  should be =

7.      Yang push draft: section 7:
   If the access control permissions on subscribed YANG nodes change
   during the lifecycle of a subscription, a publisher MUST either
   transparently conform to the new access control permissions, or must
   terminate or restart the subscriptions so that new access control
   permissions are re-established.

      The draft allows authorization either at subscription time or at send=
 time. IMO, authorization @ send time should be the way to go.
Regards,
Walid


--_000_AM3PR07MB35413A6F11DFEE94C5529FC8D2E0AM3PR07MB354eurprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


I have reviewed:


    

  • draft-ietf-netconf-subscribed-notificatio=
ns-07
  • draft-ietf-netconf-yang-push-11=



and have the following mix of comments/questions:


 


    

  1. subscribed-notifications draft: What is t=
he background/reason for not having dscp with notifications (i.e. same as w=
ith yang push)?
  2. subscribed-notificati=
ons draft: In figure 1/page 8, it implies that a modification to a suspende=
d subscription would get the subscription to be active first before the ser=
ver decides to keep it active or suspend it again. I would
have thought a modification can be considered by the server while the subsc=
ription is still suspended then it could either become active or stay suspe=
nded
  3. subscribed-notifications draft: =
Fully agree with having replay with notifications only and not yang-push
  4. subscribed-notifications draft: In R=
20;modify-subscription”, though a subscriber-id is writeable (i.e. to be able to specify which =
subscription to modify) but the server should not allow
changing it on a suspended/active subscription
  5. subscribed-notifications draft: In “modify-s=
ubscription”, why not modify “replay-start-time”? i.e. pu=
rge whole/part of the replay buffer


Use case: purging whol=
e/part of the replay buffer in scenarios where it may have been a reason to=
 suspend a subscription


The argument that the =
operator can cancel the subscription and re-establish another one applies t=
o modifying everything and would mean no need for modify-subscription from =
the first place. Also, an operator
may consider purging part of the buffer and not all.


    

  1. Yang push draft: page 11/Figure 1, </p=
ush-change-update> should be </push-update>
  2. Yang push draft: section 7:


If the access control permissions on subscribed YA=
NG nodes change


during the lifecycle of a subscription, a publishe=
r MUST either


transparently conform to the new access control pe=
rmissions, or must


terminate or restart the subscriptions so that new=
 access control


permissions are re-established.

 


The draft allows autho=
rization either at subscription time or at send time. IMO, authorization @ =
send time should be the way to go.


Regards,


Walid


 





--_000_AM3PR07MB35413A6F11DFEE94C5529FC8D2E0AM3PR07MB354eurprd_--


From nobody Wed Nov 15 20:29:36 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DFA12941C; Wed, 15 Nov 2017 20:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suaoh6yFnmpa; Wed, 15 Nov 2017 20:29:32 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26848127419; Wed, 15 Nov 2017 20:29:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28955; q=dns/txt; s=iport; t=1510806572; x=1512016172; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TveRm2SPIuZym8/Kce8ksOKY1dlyl3dUTxhwnJrE8eY=; b=LUvqZ8Yc0kH7AL2PctCRzvPAFuOpTE46R7jaw2pJwmf4H/NaUXxMD3qQ 43sSoGzDs/OfZOCNuUwUIlGMemCWHwJs9zt4zH+j1U0YkhBxesu1/ZRaF dO29PkJiClmhA4jUB8z2pLKnDVRv+lYBXRms9OY1jXL9fl1rcrB60UQH0 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACKEw1a/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJ4N/ih+PIYF9iFyOAoIOAwoYAQqESU8ChQ4/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEDAQEhSwsQCQIYIAEGAwICIQYfEQYBDAYCAQGKCAMVEIt0n?= =?us-ascii?q?WiCJyaHGA2DSQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVghKDAYJrghe?= =?us-ascii?q?DK4JjBZMEhhqIXD2QDYR5ghWJaiSHIYozgnaBEYd0gTkfOEKBMjQhCB0VSYJkg?= =?us-ascii?q?iNugVs0NohqLIIWAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200";  d="scan'208,217";a="315040659"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 04:29:30 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vAG4TRUb024236; Thu, 16 Nov 2017 04:29:29 GMT
To: Andy Bierman , Mahesh Jethanandani 
Cc: sec-ads@ietf.org, netconf , Eric Rescorla 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 16 Nov 2017 12:29:27 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EF1A2046625468602E8D65BF"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:29:35 -0000

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

"validating field information" is slightly unclear to me, can this be 
reworded slightly?

Thanks,
Rob


On 16/11/2017 03:12, Andy Bierman wrote:
> Hi,
>
> I updated the draft with these changes on github.
> There is a draft-pre-09.txt file now for you to review.
>
>
> Andy
>
>
> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani 
> > wrote:
>
>     Andy,
>
>     I assume you will incorporate these changes in the -09 version of
>     the draft.
>
>     However, I am unable to review the changes in github. Can you post
>     the diffs of the draft w.r.t. -08 version.
>
>     That still leaves us with one issue, and that has to do with the
>     what permission to give edit-operation. I am assuming the WG
>     agrees that making the change from ‘none’ to ‘read’ for edit
>     operations makes maintenance more difficult and makes the
>     operation more vulnerable, unless all the deny rules are in place.
>
>     We will need to update the security considerations section to
>     address Eric’s concerns. How about this update?
>
>     OLD:
>
>     Therefore, a server MUST NOT vary their OPTIONS responses
>     based on the existence of the underlying resource, which would
>     indicate the presence or absence of resource instances.
>
>
>     NEW:
>
>     Therefore, a server MUST NOT vary their OPTIONS responses
>     based on the existence of the underlying resource, which would
>     indicate the presence or absence of resource instances. In particular
>
>     servers should not expose instance information before validating field
>
>     information.
>
>
>     Cheers.
>
>>     On Nov 13, 2017, at 11:28 PM, Martin Bjorklund >     > wrote:
>>
>>     Hi,
>>
>>     I just read this thread, and I agree with the changes, but see below
>>     for a comment.
>>
>>
>>     Andy Bierman > wrote:
>>>     Hi,
>>>
>>>     Here are some proposed edits to make the data rule consistent
>>>     with the
>>>     examples.
>>>     Note that this issue is not related to the edit in the original
>>>     1-week
>>>     change.
>>>
>>>
>>>     sec. 3.3.5:
>>>
>>>     OLD:
>>>
>>>
>>>          data node rule:  controls access for a specific data node,
>>>     identified
>>>          by its path location within the conceptual XML document for the
>>>          data node.
>>>
>>>
>>>     NEW:
>>>
>>>          data node rule:  controls access for a specific data node
>>>     and its
>>>     descendants,
>>>          identified by its path location within the conceptual XML
>>>     document
>>>     for the
>>>          data node.
>>>
>>>
>>>     sec 3.4.5, step 6, bullet 2:
>>>
>>>
>>>     OLD:
>>>
>>>            *  The rule does not have a "rule-type" defined or the "rule-
>>>               type" is "data-node" and the "path" matches the requested
>>>               data node, action node, or notification node.
>>>
>>>
>>>     NEW:
>>>
>>>
>>>            *  The rule does not have a "rule-type" defined or the "rule-
>>>               type" is "data-node" and the "path" matches the requested
>>>               data node, action node, or notification node. A path is
>>>               considered to match if the current data node is the
>>>     data node
>>>               specified by the path, or is a descendant data node of
>>>     this
>>>               data node.
>>
>>     I propose:
>>
>>                 The rule does not have a "rule-type" defined or the
>>                 "rule-type" is "data-node" and the "path" matches the
>>                 requested data node, action node, or notification node.
>>                 A path is considered to match if the requested node
>>                 is the node specified by the path, or is a
>>                 descendant node of the path.
>>
>>     Note:  s/current node/requested node/ which is the term used in the
>>     first sentence.  And then s/data node/node/ since the first sentence
>>     refer to data-, action-, and notification node.
>>
>>     I have checked in this fix in the repo.
>>
>>
>>     /martin
>>
>>     _______________________________________________
>>     Netconf mailing list
>>     Netconf@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netconf
>>     
>
>     Mahesh Jethanandani
>     mjethanandani@gmail.com 
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


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


  
    
  
  
    
"validating field information" is slightly unclear to me, can
      this be reworded slightly?

    
Thanks,

      Rob

    

    

    
On 16/11/2017 03:12, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I updated the draft with these changes on github.

        
There is a draft-pre-09.txt file now for you to review.

        


        

        


        

        
Andy

        


        

      

      


        
On Tue, Nov 14, 2017 at 5:05 PM, Mahesh
          Jethanandani <mjethanandani@gmail.com>
          wrote:

          

            
Andy,
              


              

              
I assume you will incorporate these changes in the
                -09 version of the draft.

              


              

              
However, I am unable to review the changes in github.
                Can you post the diffs of the draft w.r.t. -08 version.

              


              

              
That still leaves us with one issue, and that has to
                do with the what permission to give edit-operation. I am
                assuming the WG agrees that making the change from
                ‘none’ to ‘read’ for edit operations makes maintenance
                more difficult and makes the operation more vulnerable,
                unless all the deny rules are in place.

              

                

                  


                  

                  We will need to update the security considerations
                  section to address Eric’s concerns. How about this
                  update?

                


                

                
OLD:

                

                  
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                  


                  

                

                
NEW:

                

                  
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular

                  
servers should not expose instance information before validating field

                  
information.

                  


                    

                  
Cheers.

                  


                    

                

                

                  

                    
On Nov 13, 2017, at 11:28 PM, Martin Bjorklund
                      <mbj@tail-f.com>
                      wrote:

                    

                    
Hi,

                      

                      I
                        just read this thread, and I agree with the
                        changes, but see below

                      for
                        a comment.

                      

                      

                      Andy
                        Bierman <andy@yumaworks.com>
                        wrote:

                      
Hi,

                        

                        Here are some proposed edits to make the data
                        rule consistent with the

                        examples.

                        Note that this issue is not related to the edit
                        in the original 1-week

                        change.

                        

                        

                        sec. 3.3.5:

                        

                        OLD:

                        

                        

                             data node rule:  controls access for a
                        specific data node, identified

                             by its path location within the conceptual
                        XML document for the

                             data node.

                        

                        

                        NEW:

                        

                             data node rule:  controls access for a
                        specific data node and its

                        descendants,

                             identified by its path location within the
                        conceptual XML document

                        for the

                             data node.

                        

                        

                        sec 3.4.5, step 6, bullet 2:

                        

                        

                        OLD:

                        

                               *  The rule does not have a "rule-type"
                        defined or the "rule-

                                  type" is "data-node" and the "path"
                        matches the requested

                                  data node, action node, or
                        notification node.

                        

                        

                        NEW:

                        

                        

                               *  The rule does not have a "rule-type"
                        defined or the "rule-

                                  type" is "data-node" and the "path"
                        matches the requested

                                  data node, action node, or
                        notification node. A path is

                                  considered to match if the current
                        data node is the data node

                                  specified by the path, or is a
                        descendant data node of this

                                  data node.

                      

                      

                      I
                        propose:

                      

                                  The
                        rule does not have a "rule-type" defined or the

                                  "rule-type"
                        is "data-node" and the "path" matches the

                                  requested
                        data node, action node, or notification node.

                                  A
                        path is considered to match if the requested
                        node

                                  is
                        the node specified by the path, or is a

                                  descendant
                        node of the path.

                      

                      Note:
                         s/current node/requested node/ which is the
                        term used in the

                      first
                        sentence.  And then s/data node/node/ since the
                        first sentence

                      refer
                        to data-, action-, and notification node.

                      

                      I
                        have checked in this fix in the repo.

                      

                      

                      /martin

                      

                      _______________________________________________

                      Netconf
                        mailing list

                      Netconf@ietf.org

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

                  

                

                

                    

                      
Mahesh Jethanandani

                      
                    

                    

                  

            

          

        

        

      

      

      

      

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


    

    

  


--------------EF1A2046625468602E8D65BF--


From nobody Wed Nov 15 20:38:33 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70088127522 for ; Wed, 15 Nov 2017 20:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level: 
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 HGk7K18XzxdS for ; Wed, 15 Nov 2017 20:38:30 -0800 (PST)
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 A28A31201F2 for ; Wed, 15 Nov 2017 20:38:29 -0800 (PST)
X-AuditID: c1b4fb25-da9ff700000020f7-d2-5a0d1643e364
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.D0.08439.3461D0A5; Thu, 16 Nov 2017 05:38:27 +0100 (CET)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 16 Nov 2017 05:38:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T4ZD6jajagDeIZ0OCRq7MZiUwxfGbm0f9Bu9sQM7iy4=; b=j6XY74xxIPTsh4NmgFysJo/Z2OhkuDzRY/JyRnjZuDLgjCrgKU3iPlXEiepH6LiaymYMtau/nxYMaxWT7yNJDdN8DlHxw3C+nWh661zx8x+Cy+OO9R+nqcFEtXTb4zpYFGp0jWKvTNdQdwLo9+JMPoW8C2wUPNx7lngY7ULj/aA=
Received: from [IPv6:2001:67c:370:128:bc62:6d4e:1967:bfa1] (2001:67c:370:128:bc62:6d4e:1967:bfa1) by AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Thu, 16 Nov 2017 04:38:25 +0000
To: "netconf@ietf.org" 
References: 
From: Balazs Lengyel 
Message-ID: 
Date: Thu, 16 Nov 2017 12:38:07 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:bc62:6d4e:1967:bfa1]
X-ClientProxiedBy: SG2PR01CA0103.apcprd01.prod.exchangelabs.com (2603:1096:3:15::29) To AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5d05371e-a6dc-4bbb-a15a-08d52cabe0b5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM4PR07MB3426; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 3:e6Ryfw02kCpBQxfJBitJi7rh2ub1raIqmLGlEn/qHnXOoWCc8NoBkoOjy2T4VxJg4UpBp6TSVnLp+1MhBN2f2TxzMSOA31VpuQmzl/TROvcbejjldj5f1sA9mB+b9eGV6A+0CMEriyyHEBDoySl3eJ++6Pz6PHEr8WYzG0bmnpot5si6gQqRwk4U4d0QEpz4zQyaJOENo0n+vyLTB/wQTPZqTFm8v4ZbxSRoeE+oWL7TKkOERQCrNTkQFKFJzWNr; 25:LeEETsxJZgoMmARae2B44wYMSvYAYp2UuqLyKCYNhNOuKG+m5/Ne5OvOLMerv54J2RAhEXvhVxykJB93f/yb0GbuQVRxVlGu/BZooJwGeE3OKdu9IkLxcLI6H8wDeYLXwCOcBu0JJ0NF7emsHqSUGLbTtEWYfhz1aDwmxQfSltUiz9W6kiAO0c5ALSliejYUSIUyLPore3XqLMY4h0sP7xZdE/dKJDsw9BwRdyWriPD/lgsA8sCPwK+QDd+YeLbcedMf+QtcPCIIbGDNQ+xp/NARX5iqiWDsGfrKEbXnuGOxIC5tf8ZO6XesvKoFEUvLeaZyEbBjgHg1x8u82nQkbQ==; 31:/YP9AlML3IGpG8QxAwGpL3PSf81msI5iPFuc3/JXmhvM/7ZMWrDDa+CjJxhNSgmQjwt4sbHqcrTbSWxdbATAEuhUGvY3Hqd56smjTY72ntVpKuzF5re3BCt+rVQVrABsPGvMK4zoj3DaS/flS7Wo80uJ0KUa+tIqt479z42sKwupRyC92Z4cxXUbgrtXTpeSHnQwMq+XP15yHkEvEWEjHNl+iJmHqUY0X4m2PKpCSFs=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3426:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 20:+dZ9kf2Z5E78jxZWoXoEildws42/YdQQC27ddlrOzjtlR0QTwBObYv0AQVY5w4l//6ZN4lfaU9sGV8AosNQTWO0zwkelr2aJNVvyJbeHqobmPI+dLyxZjL283oIAFBhIDlpuIoYmpoKQtmcfonOJ15g0ff3Tvd1anR9Vp6XicXzMQNBtGb910bGePRUTEByACChBK9PuKgE/eWcVMzoPqNfXRCL2hqEPUp0v2Joc79CulDIRkmUuu9yAGMA92UPApWbNlpZlqS/Kj2pJ5rgGEwPo/iKkRyCJqq4ZwTvYnnzkilDSsXy2BhJ2rqJrLCVUkBeAlPhKQRjcwvWxjwxDDi36nP9X8UK65NMC1K3kTekP/xjWSs+CEmaDinxwYCXQcLokRQM8DBLTwc/DjZCyyGFVTO6rq5jDwQdapLOHKNoxrRvwZLhMmxM/nooBn3IwFVLqhz79ZrcVsYeNtsZbtELOhpSSzg91+Hi/YlVZqx/DzW+j3sMclVZQGrP1pL1W; 4:a48RAvtHjSE7tuhT9foOuam0vuSRwTQDnDIijs4mFMJgmr2IRdJliI32rZJAhVGftO1NrkQsIoGV1zLfkflbu2Cdc42DuN6/78fiapQx3Fmlq3nEA5CsU6hTbAGrluaj962jW2F/Ji9xhZfNEYD6czfTPMmTY8Th1F1CGtviZ+sQjh/ihSzaCyhXADDDa1I2s31z6MG4UON7dDS4Qn1zoCnIStQLqSB4/sMq9zkmS2PGXyas/sr12oJWVbURvZB8lBm4k2xvAUpKxd+PHuCVwwpNeR99LZ3YvWgTmM5YzLbTU8OMCJY4NYnV7jJz2JGK
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231022)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3426; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3426; 
X-Forefront-PRVS: 0493852DA9
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(189002)(252514010)(199003)(5660300001)(76176999)(33646002)(86362001)(31696002)(2351001)(6116002)(106356001)(8936002)(8676002)(81166006)(65826007)(36756003)(25786009)(67846002)(7736002)(6666003)(1706002)(81156014)(2950100002)(5640700003)(6916009)(1730700003)(2501003)(97736004)(305945005)(105586002)(64126003)(47776003)(230700001)(23746002)(31686004)(101416001)(558084003)(54356999)(50466002)(83506002)(6486002)(478600001)(229853002)(189998001)(58126008)(68736007)(53936002)(6246003)(2906002)(316002)(65956001)(65806001)(50986999)(554374003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3426; H:[IPv6:2001:67c:370:128:bc62:6d4e:1967:bfa1]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
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-Exchange-Diagnostics: =?Windows-1252?Q?1; AM4PR07MB3426; 23:sMn2tLt6lHqQ1yl7yk73tin0AN3KIa96LWiLc?= =?Windows-1252?Q?FZCc0iBMB77w64XKvMNPObvH2W6vAB5JmevqjZeDeztjAZ69M9eLkXQq?= =?Windows-1252?Q?LL3zGuBVItocqGq+Ym8p67LmCtVZKxVRz/V7d2Wrg//CtBgj7ftqE5Lt?= =?Windows-1252?Q?AZ6fFsv566l+2tvY7A1VbgAoWIxoDW/bLG7brtjuuxuOyDir8PpaNe7k?= =?Windows-1252?Q?Hfoi3YMqvTRgmtk4okVB3su6NKj9vEmYs5kPtUxVq7D9GRPn/p09GxUM?= =?Windows-1252?Q?WHN/udWGY5FlCqxV0UGElbAiVyrEgcIyeLuS7o1EKZmTYKGFFVYT4wdi?= =?Windows-1252?Q?a7we71F6zJE3QnDyXN0kHSnMEKQqs1MuJZxDnFOnysJSeEO9J+th7RgA?= =?Windows-1252?Q?/PvtJX0u5UWKbmEshUBByS7PN0akHIy0nqrP7hmVZltTtw9XITmcT/KB?= =?Windows-1252?Q?QwLPDRYkvISL9aEeHA97R0AEBD/mR1b403I4OKwejv3SqMYe4mSIxJ7W?= =?Windows-1252?Q?/psFXYmIt8bjmJJQ8jz0cJl3ocwaHjDiYnX3rT3/ehJaLxzTsDYjXJbn?= =?Windows-1252?Q?8S9pVPgf9TWf/g88Lx6i/7lbRZHnwDhlGzZsrBaj8uOCnbaHSzrWf3gh?= =?Windows-1252?Q?uED5SlQu5nMJ5SJ/XsraZEKysHWz+dL15yKshrId9E8GgpPmXLF73pxX?= =?Windows-1252?Q?gggiR/uxgy4b/FYTETWWyNrgooEIYs9KQY1davsD+nU90JjTXEsn4a19?= =?Windows-1252?Q?HczSAeJqemQXjH5h3r0AifQ5YhU5dA+JAmpoFb5BS1ZV9gyP930e/aA1?= =?Windows-1252?Q?w29VxzX7ProBdGzC20xHcOQgKOjZvks+I6xsTEaukAgfDv5dGDyUKI/+?= =?Windows-1252?Q?cFq7u4x4Wp2QzzxdRJiTzM1nuxTB8Li6W94HYsgkwJC5tbNEqCG4ZgUC?= =?Windows-1252?Q?mVoTMjSeRv3AVi+Hzk2ceF4mdRykE7LK1eNWrYHJX84uy2kCQJYuObKY?= =?Windows-1252?Q?0OUf1zPth0CfEsDsmpOFI7acZfUY0sliZIpbvRSx2qiVmFlHnlox3gka?= =?Windows-1252?Q?PI5YB61Apnp6juhbOZnQcoIE9w8yv8UwBk9wbIdqPNDbdO9ZAQNbb14s?= =?Windows-1252?Q?iWbuvlUmyHrUtm4NIvXGNiG1tZvtDBhLVkJHvo7kkb+43GT8LrKrrTq9?= =?Windows-1252?Q?f3fKcaKLXnvEscZnyveKFaYKRGfgbf4iwMVJvpF6eZo28ypgCqJqGv1D?= =?Windows-1252?Q?Ma+tS6kGxsPk5SNmFFcRGn89ahhlMYdrQuxcDmpfSTjZjexSXo/1B/Ee?= =?Windows-1252?Q?Xn+UHgan/ZydeLyda2N6Bbh6XoimyoeQDqqlRKAarpQU2Gq6OivJFR33?= =?Windows-1252?Q?Kyo/JfWOU3uZjQfv28yADE59BZKjaOcHLcK/vmKAHaSsBIGFGDe3LM2g?= =?Windows-1252?Q?bpTpATgFPFhXbqLXVfOzevft/EjqtybuIdS3v84Mw=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 6:18odTOHNCDJpe9u+CJ5NqEcD1Q8INj18GMyDwOvs649o2I5pxVnl+SmELJIFevbt8BmNTzqaEbtG/OAR3OiNhUdC5TYOLBDHklve4cVq8GBWPg53LhcLxyG3zl8CpFep1sShoVkb+sgizf08kFlrWtdHWWaMf9nMCNokU38FlqZip+zuLBi5E9NKHOOJ9wz3dOZJ6ZNqQDtCAOZ3sdI0cZ+FsaAA4OYTeGV2IGNulo3pxAejV6A9Zlz5o+mye0utPf17/dR9HJDAT5TkT8I7gPCRVvWrgoevdzZguVejeJVFtF34fv1jFhOB7spEiF2ZJtqIVfjAz7DniJ9gs11gc+KwUIqBq8tz7UlERGeYa9E=; 5:VleBLLJFjv2xeJ75v0L5Q1xp6YtFK1iRJq7c49zcOg0zXM8qAEqsGuamDaHwqu+8+S5auNTL1BaVni+I2cFgTDSAA5AQVTjfrmPKeutKf4hxU7XTmNnO6zGgO5q4gebK12+k0wwsu1qzwe9acNF8c/VHmmUvkKpMNByUx7G4mLE=; 24:lfmODHVqC5S5bss8Bm8ajJbpgQgQ3bKPXzDxvsOl6l7lvCAmSDoc89x65l1wgAx0OFiimmTyhf/osJxVq3PVJr7GaGqEGb3Wpr5pMBOxj80=; 7:BzCLf5zeKbA3IwtHzFX8HQXzWkyaDIbWhRefHUxd+Fz5zW2ycGXc0go0JN0TWujKVhNdIjSAg3hohozLHBllQ48F40aLhXOrmR1wjqHhHqHX3ZbRIpvAu7GLu3AZOuuHIrN6iObxezN4hSD43h7f7hzjcB5TkgX/Dus/sBYvHpgB7XIkcka9emodsKU8mZZezbg8aG/n+y1fA6XW9hf6RewnrnfPJIR87j350PZW1YjEzcmR7oc/ASlNDPukilV0
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2017 04:38:25.8197 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d05371e-a6dc-4bbb-a15a-08d52cabe0b5
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3426
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7hK6zGG+UwYENRhZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoFXT1kKTjJVvH5+iLmB8SVjFyMnh4SAicSWn1uZuhi5OIQE DjNK7Dr9mg3COcEocWXdXbAMi0Avs8TGP72sEJndTBKrPzWxgPQLC9hL3D23EcwWEdCUaJz1 AaiIA6goSmLW1EqQMJuAkcTU/vNgJbxA5Rcap4GtZhFQleh+s4sVxBYViJGY+OAiI0SNoMTJ mU/A6jkFoiVad18AG8kM1PtgaxlImFlAXmL72znMELa4xK0n85kgvrGQaO/qYwY5U0JgJqNE z7fHYHOEBDQkHl74ywpRJCtx9OwcFgjbV+L3mt2McA2tHTtZIJwGdollxyGekRDQkrj+XhEi /oNN4ty7KVDd2RIb1t5hhrCtJF7/+g416QqrxI/9O6ASMhIzlt9ih0g0skmsePWMCeKmVIkt N1rYJjBqz0Ly9iyEV2cheXUWklcXMLKsYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAhMEge3 /FbdwXj5jeMhRgEORiUe3sOMvFFCrIllxZW5hxglOJiVRHgjF/JECfGmJFZWpRblxxeV5qQW H2KU5mBREuf1EOGOEhJITyxJzU5NLUgtgskycXBKNTCKPy8zqbm8IEP9yWSJ8KTwvrsbdq5+ svR/TL/KOqPu/mc8X1csmNCW+DaT9eLEuoyVkcHc/K4lZ2O3N/5LWXf6qr+WNIOASNmujXsU U13lz06x7F5idchdwcgxndnb75v31eo/MpUc+g+1gxf9s6v1/XaP68hvKf3Y49kaXNO+fHRg rFpxfboSS3FGoqEWc1FxIgD1yvR/DgMAAA==
Archived-At: 
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:38:31 -0000

Hello,

I have been part of the design team and I am mostly happy with the 
results. I would like to see the drafts progress as soon as possible.

regards Balazs

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


From nobody Wed Nov 15 20:55:26 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B89127522; Wed, 15 Nov 2017 20:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 s365AgSDYiHK; Wed, 15 Nov 2017 20:55:22 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 E17FD1201F2; Wed, 15 Nov 2017 20:55:21 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id q4so10624702pfg.13; Wed, 15 Nov 2017 20:55:21 -0800 (PST)
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=EHpSh898ICaoWZ+AKvPlaKdEkLIfodrsLJKhcp7BQrc=; b=DaLnUBSe/Vlyeh7rfIB10OoafAcwPBGP67+U2t03Jk4VRSCorhELkVls4oPHN0nBQ8 TPRMkcDWst5tp8HYnNe2FZXdSkH/0rpTCwoK+Oz4hGVabnfV2GssSTA/Hz5dy8USCUjk GfZsg0ghOHCWhAqirAm/gHMCuQVLaCpqq4Mz5YL+HXN6mw5BiYzdABTdbQMuMBM6K06R 69o/ZhuTX9vEa7HfWRB7gxfEuzBaNUKVuOkKTc2QbP6aODsu/GgG5WVR1KdZxzmzvcbS 9mvwRD/c9gIi9Hyu6outK7PFba/47s4EYr1zy79RyOn2tFvOnoo9tb6d0hpFpdQULUwC +PkQ==
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=EHpSh898ICaoWZ+AKvPlaKdEkLIfodrsLJKhcp7BQrc=; b=l5mt5z4Rwphot4ds2EEn2Q4XniadPRs+Lsiod9SJiXOdu9t0y1BeGc7lYkJVDxCK7s I4/yqR4LDxXjgWDGYmbigCl2nm2PLFqJ3LLbLO4yLVpciEFD/6316c3UtsVtaoammWGH YNSUc0anuEbFg4uwJ1Q/GVsy+kztt1+JnQlDIlB0hDt3gZpAFPV78/KzAypZQZJYiQ2L gZ+WDDyHYsdfTLGpYlCiVU29dnpze3boHeSsEnWyClOAZjc7V42a2ODS7LU0IpJFtSHN qIQ9Wm2Fs6hyyNKK+xGIZl+CVmq6VEt3CSBfLLR0PovQKi3LjHAJF9M/c/C+cnYpS+2+ Qz2Q==
X-Gm-Message-State: AJaThX5NdlKbFoGdTreylp5H2xfMh17Tz5uMDMLK60lLcmJ4PjtY7nNe 50viCf3mO/mFhcB6/h7XWAk=
X-Google-Smtp-Source: AGs4zMYMqbwlHw/3wPdTqHN6WGmM5+0WzgKxfa/lxzpRwmkZ3a575A29KTOi79k4FWlSPVo/MZQgOA==
X-Received: by 10.159.214.139 with SMTP id n11mr422064plp.289.1510808121448; Wed, 15 Nov 2017 20:55:21 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:7583:41b7:854e:23e1? ([2001:67c:1232:144:7583:41b7:854e:23e1]) by smtp.gmail.com with ESMTPSA id k2sm453652pff.126.2017.11.15.20.55.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 20:55:20 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E77CCB7-4368-4CDF-9EA0-060997C208F6"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Thu, 16 Nov 2017 12:55:17 +0800
Cc: Andy Bierman , sec-ads@ietf.org, netconf , Eric Rescorla 
Message-Id: 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>  
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:55:25 -0000

--Apple-Mail=_8E77CCB7-4368-4CDF-9EA0-060997C208F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Can you provide text?

> On Nov 16, 2017, at 12:29 PM, Robert Wilton  wrote:
>=20
> "validating field information" is slightly unclear to me, can this be =
reworded slightly?
>=20
> Thanks,
> Rob
>=20
> On 16/11/2017 03:12, Andy Bierman wrote:
>> Hi,
>>=20
>> I updated the draft with these changes on github.
>> There is a draft-pre-09.txt file now for you to review.
>>=20
>>=20
>> Andy
>>=20
>>=20
>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani =
> wrote:
>> Andy,
>>=20
>> I assume you will incorporate these changes in the -09 version of the =
draft.
>>=20
>> However, I am unable to review the changes in github. Can you post =
the diffs of the draft w.r.t. -08 version.
>>=20
>> That still leaves us with one issue, and that has to do with the what =
permission to give edit-operation. I am assuming the WG agrees that =
making the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 =
for edit operations makes maintenance more difficult and makes the =
operation more vulnerable, unless all the deny rules are in place.
>>=20
>> We will need to update the security considerations section to address =
Eric=E2=80=99s concerns. How about this update?
>>=20
>> OLD:
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances.
>>=20
>> NEW:
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances. In particular
>> servers should not expose instance information before validating =
field
>> information.
>>=20
>> Cheers.
>>=20
>>> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund > wrote:
>>>=20
>>> Hi,
>>>=20
>>> I just read this thread, and I agree with the changes, but see below
>>> for a comment.
>>>=20
>>>=20
>>> Andy Bierman > wrote:
>>>> Hi,
>>>>=20
>>>> Here are some proposed edits to make the data rule consistent with =
the
>>>> examples.
>>>> Note that this issue is not related to the edit in the original =
1-week
>>>> change.
>>>>=20
>>>>=20
>>>> sec. 3.3.5:
>>>>=20
>>>> OLD:
>>>>=20
>>>>=20
>>>>      data node rule:  controls access for a specific data node, =
identified
>>>>      by its path location within the conceptual XML document for =
the
>>>>      data node.
>>>>=20
>>>>=20
>>>> NEW:
>>>>=20
>>>>      data node rule:  controls access for a specific data node and =
its
>>>> descendants,
>>>>      identified by its path location within the conceptual XML =
document
>>>> for the
>>>>      data node.
>>>>=20
>>>>=20
>>>> sec 3.4.5, step 6, bullet 2:
>>>>=20
>>>>=20
>>>> OLD:
>>>>=20
>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>           type" is "data-node" and the "path" matches the requested
>>>>           data node, action node, or notification node.
>>>>=20
>>>>=20
>>>> NEW:
>>>>=20
>>>>=20
>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>           type" is "data-node" and the "path" matches the requested
>>>>           data node, action node, or notification node. A path is
>>>>           considered to match if the current data node is the data =
node
>>>>           specified by the path, or is a descendant data node of =
this
>>>>           data node.
>>>=20
>>> I propose:
>>>=20
>>>             The rule does not have a "rule-type" defined or the
>>>             "rule-type" is "data-node" and the "path" matches the
>>>             requested data node, action node, or notification node.
>>>             A path is considered to match if the requested node
>>>             is the node specified by the path, or is a
>>>             descendant node of the path.
>>>=20
>>> Note:  s/current node/requested node/ which is the term used in the
>>> first sentence.  And then s/data node/node/ since the first sentence
>>> refer to data-, action-, and notification node.
>>>=20
>>> I have checked in this fix in the repo.
>>>=20
>>>=20
>>> /martin
>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netconf =

>> Mahesh Jethanandani
>> mjethanandani@gmail.com 
>>=20
>>=20
>>=20
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netconf =

>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_8E77CCB7-4368-4CDF-9EA0-060997C208F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Can you provide text?

On =
Nov 16, 2017, at 12:29 PM, Robert Wilton <rwilton@cisco.com> =
wrote:


 =20
    
 =20
  
"validating field information" is slightly unclear to me, can
      this be reworded slightly?
Thanks,

      Rob

    

    

    
On 16/11/2017 03:12, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I updated the draft with these changes on =
github.

        
There is a draft-pre-09.txt file now for you to =
review.

        


        

        


        

        
Andy

        


        

      

      


        
On Tue, Nov 14, 2017 at 5:05 PM, =
Mahesh
          Jethanandani <mjethanandani@gmail.com>=

          wrote:

          

            
Andy,
              


              

              
I assume you will incorporate these =
changes in the
                -09 version of the draft.

              


              

              
However, I am unable to review the changes =
in github.
                Can you post the diffs of the draft w.r.t. -08 =
version.

              


              

              
That still leaves us with one issue, and =
that has to
                do with the what permission to give edit-operation. I am
                assuming the WG agrees that making the change from
                =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 for =
edit operations makes maintenance
                more difficult and makes the operation more vulnerable,
                unless all the deny rules are in place.

              

                

                  


                  

                  We will need to update the security considerations
                  section to address Eric=E2=80=99s concerns. How about =
this
                  update?

                


                

                
OLD:

                

                  
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                  


                  

                

                
NEW:

                

                  
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In =
particular

                  
servers should not expose instance information before =
validating field

                  
information.

                  


                    

                  
Cheers.

                  


                    

                

                

                  

                    
On Nov 13, 2017, at 11:28 PM, Martin =
Bjorklund
                      <mbj@tail-f.com>
                      wrote:

                    

                    
Hi,

                      

                      I
                        just read this thread, and I agree with the
                        changes, but see below

                      for
                        a comment.

                      

                      

                      Andy
                        Bierman <andy@yumaworks.com>
                        wrote:

                      
Hi,

                        

                        Here are some proposed edits to make the data
                        rule consistent with the

                        examples.

                        Note that this issue is not related to the edit
                        in the original 1-week

                        change.

                        

                        

                        sec. 3.3.5:

                        

                        OLD:

                        

                        

                             data node rule: =
 controls access for a
                        specific data node, identified

                             by its path =
location within the conceptual
                        XML document for the

                             data node.

                        

                        

                        NEW:

                        

                             data node rule: =
 controls access for a
                        specific data node and its

                        descendants,

                             identified by its =
path location within the
                        conceptual XML document

                        for the

                             data node.

                        

                        

                        sec 3.4.5, step 6, bullet 2:

                        

                        

                        OLD:

                        

                               * =
 The rule does not have a "rule-type"
                        defined or the "rule-

                        =
          type" is =
"data-node" and the "path"
                        matches the requested

                        =
          data node, =
action node, or
                        notification node.

                        

                        

                        NEW:

                        

                        

                               * =
 The rule does not have a "rule-type"
                        defined or the "rule-

                        =
          type" is =
"data-node" and the "path"
                        matches the requested

                        =
          data node, =
action node, or
                        notification node. A path is

                        =
          considered =
to match if the current
                        data node is the data node

                        =
          specified by =
the path, or is a
                        descendant data node of this

                        =
          data =
node.

                      

                      

                      I
                        propose:

                      

                                &nb=
sp; The
                        rule does not have a "rule-type" defined or =
the

                                &nb=
sp; "rule-type"
                        is "data-node" and the "path" matches =
the

                                &nb=
sp; requested
                        data node, action node, or notification =
node.

                                &nb=
sp; A
                        path is considered to match if the requested
                        node

                                &nb=
sp; is
                        the node specified by the path, or is =
a

                                &nb=
sp; descendant
                        node of the path.

                      

                      Note:
                         s/current node/requested node/ which is =
the
                        term used in the

                      first
                        sentence.  And then s/data node/node/ since =
the
                        first sentence

                      refer
                        to data-, action-, and notification =
node.

                      

                      I
                        have checked in this fix in the repo.

                      

                      

                      /martin

                      

                      _______________________________________________

                      Netconf
                        mailing list

                      Netconf@ietf.org

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

                  

                

                

                    

                      
Mahesh Jethanandani

                      
mjethanandani@gmail.com

                    

                    

                  

            

          

        

        

      

      

      

      

      
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.or=
g/mailman/listinfo/netconf


    

    

  






Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_8E77CCB7-4368-4CDF-9EA0-060997C208F6--


From nobody Wed Nov 15 21:01:27 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7F1294DC for ; Wed, 15 Nov 2017 21:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6fUV-TgyYh9 for ; Wed, 15 Nov 2017 21:01:22 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 BF8521294C4 for ; Wed, 15 Nov 2017 21:01:22 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id q4so10635627pfg.13 for ; Wed, 15 Nov 2017 21:01:22 -0800 (PST)
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=7RAYs60LofjeEPVo9sm0ZmvlPP+ncSxEcuHVyh+8qYw=; b=K16Bnm8VXUGnF5/Rr3ftTcWGBmMVr/4u5rYQVLls5JKyxgbOerjg4jqOQcCb0z1J/f 20YgAdCIb72nPUX4d53cCtykxGam10HeaxVzJVTt6XArl8INP0Hro0a7yaaEBr9PlqBw hpUwLQkuJtUtZ2YYB986yIvSUVx1zvKqoBFIbPAKf+2ZSAVWryoUZLOYnR83OS9V8rB5 NbX79MH6YuLKShZpsY7zAWiMxYEG8+KY3aMFMw3PJAWZ+wHH5JxfboSq08HQUwLyVSvA X48dDN9Js9oB6/5di2Xha8hpfvcjjOxWlWLCi0Gvn1GA8RrKcdUpefF8Ho07QPm/HX6I 7XhA==
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=7RAYs60LofjeEPVo9sm0ZmvlPP+ncSxEcuHVyh+8qYw=; b=I2azUQRnDYhrPsOQAUanN1Ps29/ibZvQ61mEklqmQiMAVhk2T1FgqyX4BybzJaB+tI zutah7E9/pCYdmn3kDxg3eHFA5qXhYaVz2qrFBuO0kLmaO/RJMTRM0GfHuzBZjG6ttHo E9ZtyBpbhIsZSJEFR0fqn5w7jyIfHqtSRzU6/dKTeuv8zLNQAPvGv2GPcnFziE+K1eso hL8G/UfMP4IVtXP0jPz9mRDcrwMtxEqr8ghfTJVBa0ALfxgoPcdPp1rDUCE/cWE5UgWb WCmqXpbGTrDAUIFjeaW0Fnw6suyxuv69PiVTSWd9PbG4FqdmKAFDrN7J/gPNI3SRdIp7 Plzw==
X-Gm-Message-State: AJaThX5BbTd75A9sMdUOQLUUQ/jBh64LV4eUgi40dF9jRB9FMbnHamaQ TnwaNjPC97LSjx2unSuTN3Xvm7U5
X-Google-Smtp-Source: AGs4zMb6rO+mgg7Xy2730T5jdPlNAeVjmNgBjJyFrrZFDSw7IHUca9tbq4K+yZ2CQhQmhtw/1dd7GA==
X-Received: by 10.98.242.66 with SMTP id y2mr525497pfl.150.1510808482231; Wed, 15 Nov 2017 21:01:22 -0800 (PST)
Received: from dhcp-927c.meeting.ietf.org (dhcp-927c.meeting.ietf.org. [31.133.146.124]) by smtp.gmail.com with ESMTPSA id h70sm539444pfc.88.2017.11.15.21.01.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 21:01:21 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <2aa5238c339447fba8a4bde3df66bf51@XCH-RTP-013.cisco.com>
Date: Thu, 16 Nov 2017 13:01:18 +0800
Cc: "kwatsen@juniper.net" , "netconf@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FE7129C-9622-460A-9875-0736F476C16D@gmail.com>
References: <20171023.144114.150465814300377965.mbj@tail-f.com> <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com> <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.cisco.com> <20171115.203913.2068438246599432509.mbj@tail-f.com> <2aa5238c339447fba8a4bde3df66bf51@XCH-RTP-013.cisco.com>
To: "Eric Voit (evoit)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] two-week review of drafts related to notifications and subscriptions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 05:01:26 -0000

Eric,

I would agree with Martin. I find the tree a useful way to understand =
the model, but not when it is multiple pages long. The idea of breaking =
it up into smaller parts of the tree, and those individual parts =
explained, is helpful. If someone wants to do the comparison, they can =
generate the complete tree themselves.

Cheers.

> On Nov 16, 2017, at 5:53 AM, Eric Voit (evoit)  =
wrote:
>=20
> Kent,
> Mahesh,
>=20
> You also thought it might be good to partition the trees.   Are you =
also ok with the proposal below, and the identified downsides of such a =
partitioning of the tree within subscribed-notifications?    =
Specifically the implications of making it harder to find and compare =
augmentation points from yang-push?
>=20
> Eric
>=20
>> -----Original Message-----
>> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>> Sent: Wednesday, November 15, 2017 2:39 PM
>> To: Eric Voit (evoit) 
>> Cc: kwatsen@juniper.net; alexander.clemm@huawei.com; netconf@ietf.org
>> Subject: Re: [Netconf] two-week review of drafts related to =
notifications and
>> subscriptions
>>=20
>> "Eric Voit (evoit)"  wrote:
>>> Hi Martin,
>>> Hi Kent,
>>>=20
>>> Ensuring comments are covered.  I do ask a question on potential =
model
>>> partitioning across the document in the first set of comments..,
>>>=20
>>>> From: Martin Bjorklund, October 23, 2017 8:41 AM
>>>>=20
>>>> Hi,
>>>>=20
>>>> Some comments inline.
>>>>=20
>>>> "Eric Voit (evoit)"  wrote:
>>>>> Hi Kent,
>>>>>=20
>>>>>> From: Kent Watsen, October 19, 2017 9:51 PM
>>>>>>=20
>>>>>>>> draft-ietf-netconf-subscribed-notifications-05
>>>>>>>> ------------------------------------------------------
>>>>>>=20
>>>>>>>> very complicated (many details).
>>>>>>>=20
>>>>>>> If there anything you see as unnecessary, or perhaps should be
>>>>>>> optional?
>>>>>>=20
>>>>>> The tree diagram is huge.  I understand that much of it is from
>>>>>> grouping expansion, but still, there is a lot to consider (many
>>>>>> details).  I'm just thinking that this is going to take time for
>>>>>> folks to digest fully.
>>>>>=20
>>>>> We really made an attempt to simplify the tree by using a
>>>>> filter-type object instead of the explicit subtyping.  But
>>>>> experienced and capable reviewers argued that explicit subtyping
>>>>> was better.  The result is that we returned to the larger
>>>>> explicitly subtyping a couple weeks ago.  Overall, this added 25%
>>>>> to the tree diagram size :-(.
>>>>=20
>>>> I don't think a big tree in itself necessarily means that the data
>>>> model is bad.
>>>> However, for readability purposes, you may want to split the big
>>>> tree into smaller pieces.  See for example RFC 7404.
>>>=20
>>> I think you mean RFC 7407?
>>=20
>> Yes.
>>=20
>>> We can do this.  Before I make the change, I want to confirm that it
>>> should be only done for individual RPCs and Notifications, and top
>>> level containers in the data trees (e.g. streams and filters top =
level
>>> container).
>>=20
>> I think that would be sufficient.
>>=20
>>> I would also like to confirm that you are ok with all the downsides
>>> (1)-(4) listed below.
>>>=20
>>> (1) To what section of subscribed-notifications do you look to when
>>> you are doing an augmentation in yang-push?  Having one tree to go =
to
>>> in one full tree is easier than finding info across split trees.
>>> I.e., a single tree is pretty useful for outside referencing on
>>> augmentations.
>>=20
>> The purpose of the tree is to get an overview of the basic structure =
of the
>> model.  It is not the normative reference that you need to fully =
understand
>> everything - that would be the module itself.
>>=20
>>> (2) YANG Push does not have section partitions for existing
>>> subscribed-notification RPCs and Notifications.  Therefore we =
couldn't
>>> do the exact same segmentation of the tree structures across the two
>>> documents.  (I.e. it won't be a 1:1 comparison when looking between
>>> the drafts.)
>>=20
>> I haven't yet reviewed YANG Push, but I don't think this will be an =
issue.
>>=20
>>> (3) Segmentation lower that any top level container is not
>>> recommended.
>>=20
>> By whom?
>>=20
>>> This is because augmentations occur at different levels of the tree.
>>> Any other approach would mean tree information replicated in =
different
>>> tree diagrams.
>>=20
>> I don't think that's a problem.
>>=20
>>> (4)  It will increase the size of an already big document.
>>=20
>> Probably not by much, and if it helps people to better understand =
this
>> model, I think it is worth it.
>>=20
>>=20
>> /martin
>>=20
>>=20
>>> Based on this, I still think a single model is better.  But I am =
happy
>>> to make the change if consensus is otherwise.
>>>=20
>>>>>>>>        flow difficult to read.
>>>>>>>=20
>>>>>>> Anything specific?  I am happy to re-order as suggested.
>>>>>>=20
>>>>>> Also, I'm suspecting that the update from Martin's comments will
>>>>>> get much of this.  It just seemed that every time tried to chase
>>>>>> some bit of information down, it wasn't stated quite right
>>>>>> (e.g., terminology, phasing, open-endedness, etc.).  All this
>>>>>> got in the way of the readability.
>>>>>=20
>>>>> Hopefully I got the ones which don't resonate.  My natural
>>>>> ecosystem is deeper in the router, and YANG means I need to use
>> different terms.
>>>>>=20
>>>>>>>> * what is "promise theory based interaction model"?
>>>>>>>> (reference?)
>>>>>>> Yes, I will add the reference.  The best on-line one I know is:
>>>>>>>=20
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
>> 3A__markburgess.
>>>>>>> or
>>>>>>> g_Pr
>>>>>>>=20
>> omiseMethod.pdf&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
>>>>>> ndb3voDTXcWzoCI
>>>>>>>=20
>>>>>>=20
>>>>=20
>> &r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DzDualRWvSwyZj
>> 8MF
>>>>>> PL_Xo
>>>>>>>=20
>>>>>>=20
>>>>=20
>> pkywEp9xEJgZXjyhdIBPog&s=3DDcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2
>> xpE
>>>>>> Oc0o&e
>>>>>>> =3D
>>>>>>=20
>>>>>> Oh my, that document is 38 pages, I was hoping for simple
>>>>>> statement (e.g., the system takes defensive measures in order to
>>>>>> ensure resources are available).  I think you have something
>>>>>> like this in the yang-push draft.
>>>>>=20
>>>>> I can add a simple statement.  Something like "voluntary
>>>>> cooperation between individual, autonomous agents who
>> continuously
>>>>> refine their changing intentions to one another in the form of
>> promises".
>>>>=20
>>>> Does this really help people to understand this document?
>>>=20
>>> I didn't such a statement helped either, so all references in
>>> subscribed-notifications have been removed.  As this is important in
>>> yang-push, I tweaked the reference section 3.4 with the kind of info =
I
>>> think Kent wanted in his simple statement.
>>>=20
>>>>>>>> * what is the relationship between streams here and in 5277?
>>>>>>>=20
>>>>>>> This document doesn't discuss the details of how streams are
>>>>>>> generated within the publisher like 5277 does.  This detail is
>>>>>>> not necessary for the external interface definition.
>>>>>>>=20
>>>>>>> That said, how to handle/encode names of the streams, the
>>>>>>> managed objects, the ability to filter, etc. are identical.
>>>>>>=20
>>>>>> This document should explain the relationship though, right?
>>>>>> (see
>>>>>> above)
>>>>>=20
>>>>> Is this necessary in the normative part of the document?  When the
>>>>> notification-messages draft is complete, it will be possible to
>>>>> obsolete RFC-5277 at some later date.  How many linkages are
>>>>> appropriate?
>>>>>=20
>>>>> What I did do in the new version (per Martin's request) is to
>>>>> place in Appendix A: Relationship to RFC-5277.  What I believe we
>>>>> should do is place statements identifying the re-used stream
>> constructs.
>>>>> Would that work?
>>>>=20
>>>> I think such a section is needed, and I think it shouldn't be an
>>>> Appendix, but rather one of the first sections.  This is quite
>>>> common in RFCs that updates/obsoletes older RFCs.
>>>=20
>>> Done.  See Section 1.4.  Relationship to RFC-5277
>>>=20
>>>>>>>> * streams here are identities, unlike "streamNameType"
>>>>>>>> (aka xs:string) in 5077.  Is this an issue?
>>>>>>>=20
>>>>>>> Based on Martin's comments that he desires to retain the
>>>>>>> ability for streams to be spun up possibly during run-time, we
>>>>>>> have returned to using string for streams (as we did in earlier
>>>>>>> versions of the draft).   Our switch to identities several
>>>>>>> months ago was one attempt we made to simplify things, but
>>>>>>> it didn't work out.    This is an issue and a resolution we
>>>>>>> have long been anticipating.
>>>>>>=20
>>>>>> okay
>>>>>>=20
>>>>>>=20
>>>>>>>> * use of " operations" for configured
>>>>>>>> subscriptions is confusing.
>>>>>>>=20
>>>>>>> It is just a normal configuration.  I will happily delete the
>>>>>>> example if you think it unnecessary or redundant.
>>>>>>=20
>>>>>> No, the examples are good.  It's literally the words
>>>>>> " operations"
>>>>>> are problematic.  Use some other phrasing that is not
>>>>>> NETCONF-specific.
>>>>>=20
>>>>> I will just use 'configuration operations'
>>>>>=20
>>>>>>>> * the example in s5.1 seems to be more about how to create a
>>>>>>>> configured subscription than establishing a subscription
>>>>>>>> connection
>>>>>>>=20
>>>>>>> Exactly.  How to establish the subscription connection is
>>>>>>> transport specific, and therefore in the netconf-notif draft.
>>>>>>> Specifically in Section 3.4.3
>>>>>>=20
>>>>>> But the section is called "Establishing a Configured =
Subscription".
>>>>>> I think this actually goes to your use of the word "establish",
>>>>>> perhaps "create" is a better word - "Creating a Configured
>>>>>> Subscription" ?
>>>>>=20
>>>>> Will do.  No reason to reuse the establish if it confuses people.
>>>>>=20
>>>>>>>> * Section 7 says "This notification message MAY be encoded as
>>>>>>>> one-way notification element of [RFC5277], Section 4."  If
>>>>>>>> this is a MAY, how does the client know what it received?
>>>>>>>> And how does the publisher know what format to send?
>>>>>>>=20
>>>>>>> I was trying to lay the groundwork for a future support of
>>>>>>> notification-messages in a way that this document wouldn't
>>>>>>> have to be updated.  I have given up on that.  Support is now a
>> MUST.
>>>>>>> And this will need to be revised in the future when we get
>>>>>>> notification-messages to an RFC state.
>>>>>>=20
>>>>>> okay
>>>>>>=20
>>>>>>=20
>>>>>>>> * xpath-filter is not a feature-based option?
>>>>>>>=20
>>>>>>> Not feature based.  Of course if the syntax is not supported
>>>>>>> on a filter, the subscription will be rejected with the error
>>>>>>> "filter-type-unsupported ".
>>>>>>>=20
>>>>>>> At this point, I don't recall anyone suggesting xpath should
>>>>>>> not be a mandatory for event filtering though.
>>>>>>=20
>>>>>> well, it's not mandatory for NETCONF-based filtering.  So, a
>>>>>> system that doesn't support XPath filtering in NETCONF would
>>>>>> have to support XPath filtering here?
>>>>>=20
>>>>> Hmm.  I had been hoping to have at least one (xpath) as mandatory.
>>>>> But maybe that is unrealistic.
>>>>>=20
>>>>> What I am thinking is that maybe both filters should be optional
>>>>> features.  And then specific transport drafts (like NETCONF) can
>>>>> identify them as mandatory. At least when that transport is used.
>>>>>=20
>>>>>>>> * I see top-level /subscription-config and /subscriptions -
>>>>>>>> is this NMDA compliant?
>>>>>>>=20
>>>>>>> As this pre-dates NMDA, we are awaiting the "you MUST make the
>>>>>>> conversion" directive.  And if this comes, we will gladly do =
that.
>>>>>>=20
>>>>>>=20
>> https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSI
>>>>>> oH
>>>>>> 4g
>>>>>> A-8M
>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sect
>>>>>> io
>>>>>> n-
>>>>>> 4.23.3
>>>>>=20
>>>>> Yep.  We do fall in the SHOULD category :-)
>>>>>=20
>>>>> But seriously, we can convert.
>>>>=20
>>>> Before doing anything, make sure the "subscription-id" issue is
>>>> resolved first.  If Rob's proposal is adopted, we will still need
>>>> two lists, one config and one operational, even in the
>>>> NMDA-compliant version.  Some changes might be needed in the
>> naming
>>>> of top-level containers though.
>>>=20
>>> Based on the comments received on the subscription-id datatype.  =
Rough
>>> consensus is integer.  We will covert to NMDA after all other issues
>>> are closed in set of drafts going to WGLC.
>>>=20
>>> Eric
>>>=20
>>>>> The question is how to do this without losing our place in the
>>>>> review queue.  We had expected to be through WGLC *long* before
>>>>> NMDA was formalized.  And we are very concerned this policy change
>>>>> could result in further delay.  So the current plan we have is to
>>>>> get agreement on the contents of the model.  And then agreement
>>>>> that we have converted what is an acceptable model into an
>>>>> equivalent NMDA version.
>>>>=20
>>>>=20
>>>> /martin
>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf



Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Wed Nov 15 21:55:32 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F258F1294F4 for ; Wed, 15 Nov 2017 21:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA982yUYzFUg for ; Wed, 15 Nov 2017 21:55:28 -0800 (PST)
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 7CEDA12741D for ; Wed, 15 Nov 2017 21:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14718; q=dns/txt; s=iport; t=1510811728; x=1512021328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=47/UJrxUFCsqR3FeXYApJjdjnOx8KwurAkd9TNQGZVo=; b=CMtLOFJzF4WPLeg5PIscFh97hcZfL2p9Lf4yW7Ip8VOEhNfelb8nq4no 4JLZTUIeMJIM2dTw960sR99oerWpOftIF4XeUyDkn4ro59949CywXsBx7 2U8NqFYNg8WCuz0Psklaux+Hry3U6N1VQkkuYvI0X8fl0CfonG9zPv9wV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAQAWKA1a/49dJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNmRuJwedN4F9iFyOEoIBChgLhElPAoUOQhUBAQEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBAQIBAQE4NAQFAgUHBAIBCA4DBAEBAQ0RCQchBgsUCQgCBAENBQiKB?= =?us-ascii?q?AMNCBCrX4c9DYNJAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDNIIHgVWBaYIdgQ2?= =?us-ascii?q?CURpZgSkThhAFijQXiReOGD0Ch2uDaYQ3hHCCHooOhyGKM4I8OohYAhEZAYE4A?= =?us-ascii?q?TUigXR6FUmCZIJcHBmBTneKG4ERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208";a="32255465"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 05:55:13 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAG5tC5H003829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 05:55:13 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 00:55:12 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 00:55:12 -0500
From: "Eric Voit (evoit)" 
To: Mahesh Jethanandani , "kwatsen@juniper.net" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] two-week review of drafts related to notifications and subscriptions
Thread-Index: AQHTSH5n2+KEwzxeaUmOUUOjdzqfBKLrmFPQgAClhQD//9LP4IAFmdcA///CDQCAA2UI0IAhhBaA///PwQAAGalOAAAJMBEQ
Date: Thu, 16 Nov 2017 05:55:12 +0000
Message-ID: 
References: <20171023.144114.150465814300377965.mbj@tail-f.com> <48f0655352a6473fb816f54f23ac2931@XCH-RTP-013.cisco.com> <2acc74b116ec42cfa19762e5977877f2@XCH-RTP-013.cisco.com> <20171115.203913.2068438246599432509.mbj@tail-f.com> <2aa5238c339447fba8a4bde3df66bf51@XCH-RTP-013.cisco.com> <3FE7129C-9622-460A-9875-0736F476C16D@gmail.com>
In-Reply-To: <3FE7129C-9622-460A-9875-0736F476C16D@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] two-week review of drafts related to notifications and subscriptions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 05:55:32 -0000

Sounds good then.   I will split the tree into the sections per below in th=
e next release in the coming in a week or two.  It is a straightforward cha=
nge.

With luck we will be able to also have a cut at the NMDA model too, but I d=
on't want to splice that model into the mainline text until we get agreemen=
t that there is functional equivalence between the NMDA and non-NMDA versio=
ns.

Eric

> From: Mahesh Jethanandani, November 16, 2017 12:01 AM
>=20
> Eric,
>=20
> I would agree with Martin. I find the tree a useful way to understand the
> model, but not when it is multiple pages long. The idea of breaking it up
> into smaller parts of the tree, and those individual parts explained, is
> helpful. If someone wants to do the comparison, they can generate the
> complete tree themselves.
>=20
> Cheers.
> =20
> > On Nov 16, 2017, at 5:53 AM, Eric Voit (evoit)  wrote:
> >
> > Kent,
> > Mahesh,
> >
> > You also thought it might be good to partition the trees.   Are you als=
o ok
> with the proposal below, and the identified downsides of such a
> partitioning of the tree within subscribed-notifications?    Specifically=
 the
> implications of making it harder to find and compare augmentation points
> from yang-push?
> >
> > Eric
> >
> >> -----Original Message-----
> >> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> >> Sent: Wednesday, November 15, 2017 2:39 PM
> >> To: Eric Voit (evoit) 
> >> Cc: kwatsen@juniper.net; alexander.clemm@huawei.com;
> netconf@ietf.org
> >> Subject: Re: [Netconf] two-week review of drafts related to
> >> notifications and subscriptions
> >>
> >> "Eric Voit (evoit)"  wrote:
> >>> Hi Martin,
> >>> Hi Kent,
> >>>
> >>> Ensuring comments are covered.  I do ask a question on potential
> >>> model partitioning across the document in the first set of
> >>> comments..,
> >>>
> >>>> From: Martin Bjorklund, October 23, 2017 8:41 AM
> >>>>
> >>>> Hi,
> >>>>
> >>>> Some comments inline.
> >>>>
> >>>> "Eric Voit (evoit)"  wrote:
> >>>>> Hi Kent,
> >>>>>
> >>>>>> From: Kent Watsen, October 19, 2017 9:51 PM
> >>>>>>
> >>>>>>>> draft-ietf-netconf-subscribed-notifications-05
> >>>>>>>> ------------------------------------------------------
> >>>>>>
> >>>>>>>> very complicated (many details).
> >>>>>>>
> >>>>>>> If there anything you see as unnecessary, or perhaps should be
> >>>>>>> optional?
> >>>>>>
> >>>>>> The tree diagram is huge.  I understand that much of it is from
> >>>>>> grouping expansion, but still, there is a lot to consider (many
> >>>>>> details).  I'm just thinking that this is going to take time for
> >>>>>> folks to digest fully.
> >>>>>
> >>>>> We really made an attempt to simplify the tree by using a
> >>>>> filter-type object instead of the explicit subtyping.  But
> >>>>> experienced and capable reviewers argued that explicit subtyping
> >>>>> was better.  The result is that we returned to the larger
> >>>>> explicitly subtyping a couple weeks ago.  Overall, this added 25%
> >>>>> to the tree diagram size :-(.
> >>>>
> >>>> I don't think a big tree in itself necessarily means that the data
> >>>> model is bad.
> >>>> However, for readability purposes, you may want to split the big
> >>>> tree into smaller pieces.  See for example RFC 7404.
> >>>
> >>> I think you mean RFC 7407?
> >>
> >> Yes.
> >>
> >>> We can do this.  Before I make the change, I want to confirm that it
> >>> should be only done for individual RPCs and Notifications, and top
> >>> level containers in the data trees (e.g. streams and filters top
> >>> level container).
> >>
> >> I think that would be sufficient.
> >>
> >>> I would also like to confirm that you are ok with all the downsides
> >>> (1)-(4) listed below.
> >>>
> >>> (1) To what section of subscribed-notifications do you look to when
> >>> you are doing an augmentation in yang-push?  Having one tree to go
> >>> to in one full tree is easier than finding info across split trees.
> >>> I.e., a single tree is pretty useful for outside referencing on
> >>> augmentations.
> >>
> >> The purpose of the tree is to get an overview of the basic structure
> >> of the model.  It is not the normative reference that you need to
> >> fully understand everything - that would be the module itself.
> >>
> >>> (2) YANG Push does not have section partitions for existing
> >>> subscribed-notification RPCs and Notifications.  Therefore we
> >>> couldn't do the exact same segmentation of the tree structures
> >>> across the two documents.  (I.e. it won't be a 1:1 comparison when
> >>> looking between the drafts.)
> >>
> >> I haven't yet reviewed YANG Push, but I don't think this will be an is=
sue.
> >>
> >>> (3) Segmentation lower that any top level container is not
> >>> recommended.
> >>
> >> By whom?
> >>
> >>> This is because augmentations occur at different levels of the tree.
> >>> Any other approach would mean tree information replicated in
> >>> different tree diagrams.
> >>
> >> I don't think that's a problem.
> >>
> >>> (4)  It will increase the size of an already big document.
> >>
> >> Probably not by much, and if it helps people to better understand
> >> this model, I think it is worth it.
> >>
> >>
> >> /martin
> >>
> >>
> >>> Based on this, I still think a single model is better.  But I am
> >>> happy to make the change if consensus is otherwise.
> >>>
> >>>>>>>>        flow difficult to read.
> >>>>>>>
> >>>>>>> Anything specific?  I am happy to re-order as suggested.
> >>>>>>
> >>>>>> Also, I'm suspecting that the update from Martin's comments will
> >>>>>> get much of this.  It just seemed that every time tried to chase
> >>>>>> some bit of information down, it wasn't stated quite right (e.g.,
> >>>>>> terminology, phasing, open-endedness, etc.).  All this got in the
> >>>>>> way of the readability.
> >>>>>
> >>>>> Hopefully I got the ones which don't resonate.  My natural
> >>>>> ecosystem is deeper in the router, and YANG means I need to use
> >> different terms.
> >>>>>
> >>>>>>>> * what is "promise theory based interaction model"?
> >>>>>>>> (reference?)
> >>>>>>> Yes, I will add the reference.  The best on-line one I know is:
> >>>>>>>
> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-
> >> 3A__markburgess.
> >>>>>>> or
> >>>>>>> g_Pr
> >>>>>>>
> >> omiseMethod.pdf&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> >>>>>> ndb3voDTXcWzoCI
> >>>>>>>
> >>>>>>
> >>>>
> >>
> &r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DzDualRWvSwyZj
> >> 8MF
> >>>>>> PL_Xo
> >>>>>>>
> >>>>>>
> >>>>
> >>
> pkywEp9xEJgZXjyhdIBPog&s=3DDcx9OsC_ayHR7hbMowWHrtulPtXz20vSvnV2
> >> xpE
> >>>>>> Oc0o&e
> >>>>>>> =3D
> >>>>>>
> >>>>>> Oh my, that document is 38 pages, I was hoping for simple
> >>>>>> statement (e.g., the system takes defensive measures in order to
> >>>>>> ensure resources are available).  I think you have something like
> >>>>>> this in the yang-push draft.
> >>>>>
> >>>>> I can add a simple statement.  Something like "voluntary
> >>>>> cooperation between individual, autonomous agents who
> >> continuously
> >>>>> refine their changing intentions to one another in the form of
> >> promises".
> >>>>
> >>>> Does this really help people to understand this document?
> >>>
> >>> I didn't such a statement helped either, so all references in
> >>> subscribed-notifications have been removed.  As this is important in
> >>> yang-push, I tweaked the reference section 3.4 with the kind of info
> >>> I think Kent wanted in his simple statement.
> >>>
> >>>>>>>> * what is the relationship between streams here and in 5277?
> >>>>>>>
> >>>>>>> This document doesn't discuss the details of how streams are
> >>>>>>> generated within the publisher like 5277 does.  This detail is
> >>>>>>> not necessary for the external interface definition.
> >>>>>>>
> >>>>>>> That said, how to handle/encode names of the streams, the
> >>>>>>> managed objects, the ability to filter, etc. are identical.
> >>>>>>
> >>>>>> This document should explain the relationship though, right?
> >>>>>> (see
> >>>>>> above)
> >>>>>
> >>>>> Is this necessary in the normative part of the document?  When the
> >>>>> notification-messages draft is complete, it will be possible to
> >>>>> obsolete RFC-5277 at some later date.  How many linkages are
> >>>>> appropriate?
> >>>>>
> >>>>> What I did do in the new version (per Martin's request) is to
> >>>>> place in Appendix A: Relationship to RFC-5277.  What I believe we
> >>>>> should do is place statements identifying the re-used stream
> >> constructs.
> >>>>> Would that work?
> >>>>
> >>>> I think such a section is needed, and I think it shouldn't be an
> >>>> Appendix, but rather one of the first sections.  This is quite
> >>>> common in RFCs that updates/obsoletes older RFCs.
> >>>
> >>> Done.  See Section 1.4.  Relationship to RFC-5277
> >>>
> >>>>>>>> * streams here are identities, unlike "streamNameType"
> >>>>>>>> (aka xs:string) in 5077.  Is this an issue?
> >>>>>>>
> >>>>>>> Based on Martin's comments that he desires to retain the ability
> >>>>>>> for streams to be spun up possibly during run-time, we have
> >>>>>>> returned to using string for streams (as we did in earlier
> >>>>>>> versions of the draft).   Our switch to identities several
> >>>>>>> months ago was one attempt we made to simplify things, but
> >>>>>>> it didn't work out.    This is an issue and a resolution we
> >>>>>>> have long been anticipating.
> >>>>>>
> >>>>>> okay
> >>>>>>
> >>>>>>
> >>>>>>>> * use of " operations" for configured
> >>>>>>>> subscriptions is confusing.
> >>>>>>>
> >>>>>>> It is just a normal configuration.  I will happily delete the
> >>>>>>> example if you think it unnecessary or redundant.
> >>>>>>
> >>>>>> No, the examples are good.  It's literally the words
> >>>>>> " operations"
> >>>>>> are problematic.  Use some other phrasing that is not
> >>>>>> NETCONF-specific.
> >>>>>
> >>>>> I will just use 'configuration operations'
> >>>>>
> >>>>>>>> * the example in s5.1 seems to be more about how to create a
> >>>>>>>> configured subscription than establishing a subscription
> >>>>>>>> connection
> >>>>>>>
> >>>>>>> Exactly.  How to establish the subscription connection is
> >>>>>>> transport specific, and therefore in the netconf-notif draft.
> >>>>>>> Specifically in Section 3.4.3
> >>>>>>
> >>>>>> But the section is called "Establishing a Configured Subscription"=
.
> >>>>>> I think this actually goes to your use of the word "establish",
> >>>>>> perhaps "create" is a better word - "Creating a Configured
> >>>>>> Subscription" ?
> >>>>>
> >>>>> Will do.  No reason to reuse the establish if it confuses people.
> >>>>>
> >>>>>>>> * Section 7 says "This notification message MAY be encoded as
> >>>>>>>> one-way notification element of [RFC5277], Section 4."  If this
> >>>>>>>> is a MAY, how does the client know what it received?
> >>>>>>>> And how does the publisher know what format to send?
> >>>>>>>
> >>>>>>> I was trying to lay the groundwork for a future support of
> >>>>>>> notification-messages in a way that this document wouldn't have
> >>>>>>> to be updated.  I have given up on that.  Support is now a
> >> MUST.
> >>>>>>> And this will need to be revised in the future when we get
> >>>>>>> notification-messages to an RFC state.
> >>>>>>
> >>>>>> okay
> >>>>>>
> >>>>>>
> >>>>>>>> * xpath-filter is not a feature-based option?
> >>>>>>>
> >>>>>>> Not feature based.  Of course if the syntax is not supported on
> >>>>>>> a filter, the subscription will be rejected with the error
> >>>>>>> "filter-type-unsupported ".
> >>>>>>>
> >>>>>>> At this point, I don't recall anyone suggesting xpath should not
> >>>>>>> be a mandatory for event filtering though.
> >>>>>>
> >>>>>> well, it's not mandatory for NETCONF-based filtering.  So, a
> >>>>>> system that doesn't support XPath filtering in NETCONF would
> have
> >>>>>> to support XPath filtering here?
> >>>>>
> >>>>> Hmm.  I had been hoping to have at least one (xpath) as mandatory.
> >>>>> But maybe that is unrealistic.
> >>>>>
> >>>>> What I am thinking is that maybe both filters should be optional
> >>>>> features.  And then specific transport drafts (like NETCONF) can
> >>>>> identify them as mandatory. At least when that transport is used.
> >>>>>
> >>>>>>>> * I see top-level /subscription-config and /subscriptions - is
> >>>>>>>> this NMDA compliant?
> >>>>>>>
> >>>>>>> As this pre-dates NMDA, we are awaiting the "you MUST make
> the
> >>>>>>> conversion" directive.  And if this comes, we will gladly do that=
.
> >>>>>>
> >>>>>>
> >> https://mailarchive.ietf.org/arch/msg/netmod/rqrXUqs8YMIfcrKZnSI
> >>>>>> oH
> >>>>>> 4g
> >>>>>> A-8M
> >>>>>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#sect
> >>>>>> io
> >>>>>> n-
> >>>>>> 4.23.3
> >>>>>
> >>>>> Yep.  We do fall in the SHOULD category :-)
> >>>>>
> >>>>> But seriously, we can convert.
> >>>>
> >>>> Before doing anything, make sure the "subscription-id" issue is
> >>>> resolved first.  If Rob's proposal is adopted, we will still need
> >>>> two lists, one config and one operational, even in the
> >>>> NMDA-compliant version.  Some changes might be needed in the
> >> naming
> >>>> of top-level containers though.
> >>>
> >>> Based on the comments received on the subscription-id datatype.
> >>> Rough consensus is integer.  We will covert to NMDA after all other
> >>> issues are closed in set of drafts going to WGLC.
> >>>
> >>> Eric
> >>>
> >>>>> The question is how to do this without losing our place in the
> >>>>> review queue.  We had expected to be through WGLC *long* before
> >>>>> NMDA was formalized.  And we are very concerned this policy
> change
> >>>>> could result in further delay.  So the current plan we have is to
> >>>>> get agreement on the contents of the model.  And then agreement
> >>>>> that we have converted what is an acceptable model into an
> >>>>> equivalent NMDA version.
> >>>>
> >>>>
> >>>> /martin
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>=20
>=20
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com


From nobody Wed Nov 15 21:56:50 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6A127058; Wed, 15 Nov 2017 21:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8s1Rhue7U7v; Wed, 15 Nov 2017 21:56:45 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DF9129515; Wed, 15 Nov 2017 21:56:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40558; q=dns/txt; s=iport; t=1510811804; x=1512021404; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=xKsygnxv8mka8kG+xpK9Bh0aWyonOmvFFvi8wVrMucs=; b=EDJ/MacbJBw4cxjq+Je2tWrXseB/EL3OUD/NRAAe9S+YphM9sKF6qOt5 XYXU2iDDwW/3XoWLgx4Rf4Qj0TSJvSYZaVuQGjSBM4FBXLl859q6AOOzr nLjRP35AQhKepWi1Y9x3yiWY4krwCSu8xjS8rj4HlpDzffkCf4Gf6LS/w c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACGJw1a/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJ4N/ih+PIIF9iFyOAoIOAwoYAQqESU8ChQ4/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEDAQEhSwsQCQIOCiABBgMCAiEGHxEGAQwGAgEBiggDFRCLT?= =?us-ascii?q?51ogicmhxcNg0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYISgwGCa4I?= =?us-ascii?q?XgyuCYwWTBIYaiFw9kA2EeYIViWokhyGKM4J2gRGHdIE5HzhCgTI0IQgdFUmCZ?= =?us-ascii?q?IIjboFbNDaIaiyCFgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,402,1505779200"; d="scan'208,217"; a="32130430"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 05:56:43 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAG5ueLl029371; Thu, 16 Nov 2017 05:56:41 GMT
To: Mahesh Jethanandani , Andy Bierman 
Cc: sec-ads@ietf.org, netconf , Eric Rescorla 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>   
From: Robert Wilton 
Message-ID: <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com>
Date: Thu, 16 Nov 2017 13:56:40 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4F0E9AEC068D9D9024C0416D"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 05:56:48 -0000

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

I'm not sure I understand exactly what point the previous text was 
stating so I'm not sure whether my proposed text is stating the same 
thing (or whether this has already been stated elsewhere in the draft):

OLD:

Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.


NEW:

Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In particular

servers should not expose any instance information before ensuring
that the client has the necessary access permissions to obtain that
information.


Is that any more clear?  Or have I missed the point?

Thanks,
Rob


On 16/11/2017 12:55, Mahesh Jethanandani wrote:
> Can you provide text?
>
>> On Nov 16, 2017, at 12:29 PM, Robert Wilton > > wrote:
>>
>> "validating field information" is slightly unclear to me, can this be 
>> reworded slightly?
>>
>> Thanks,
>> Rob
>>
>>
>> On 16/11/2017 03:12, Andy Bierman wrote:
>>> Hi,
>>>
>>> I updated the draft with these changes on github.
>>> There is a draft-pre-09.txt file now for you to review.
>>>
>>>
>>> Andy
>>>
>>>
>>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani 
>>> > wrote:
>>>
>>>     Andy,
>>>
>>>     I assume you will incorporate these changes in the -09 version
>>>     of the draft.
>>>
>>>     However, I am unable to review the changes in github. Can you
>>>     post the diffs of the draft w.r.t. -08 version.
>>>
>>>     That still leaves us with one issue, and that has to do with the
>>>     what permission to give edit-operation. I am assuming the WG
>>>     agrees that making the change from ‘none’ to ‘read’ for edit
>>>     operations makes maintenance more difficult and makes the
>>>     operation more vulnerable, unless all the deny rules are in place.
>>>
>>>     We will need to update the security considerations section to
>>>     address Eric’s concerns. How about this update?
>>>
>>>     OLD:
>>>
>>>     Therefore, a server MUST NOT vary their OPTIONS responses
>>>     based on the existence of the underlying resource, which would
>>>     indicate the presence or absence of resource instances.
>>>
>>>
>>>     NEW:
>>>
>>>     Therefore, a server MUST NOT vary their OPTIONS responses
>>>     based on the existence of the underlying resource, which would
>>>     indicate the presence or absence of resource instances. In particular
>>>
>>>     servers should not expose instance information before validating field
>>>
>>>     information.
>>>
>>>
>>>     Cheers.
>>>
>>>>     On Nov 13, 2017, at 11:28 PM, Martin Bjorklund >>>     > wrote:
>>>>
>>>>     Hi,
>>>>
>>>>     I just read this thread, and I agree with the changes, but see
>>>>     below
>>>>     for a comment.
>>>>
>>>>
>>>>     Andy Bierman >
>>>>     wrote:
>>>>>     Hi,
>>>>>
>>>>>     Here are some proposed edits to make the data rule consistent
>>>>>     with the
>>>>>     examples.
>>>>>     Note that this issue is not related to the edit in the
>>>>>     original 1-week
>>>>>     change.
>>>>>
>>>>>
>>>>>     sec. 3.3.5:
>>>>>
>>>>>     OLD:
>>>>>
>>>>>
>>>>>          data node rule:  controls access for a specific data
>>>>>     node, identified
>>>>>          by its path location within the conceptual XML document
>>>>>     for the
>>>>>          data node.
>>>>>
>>>>>
>>>>>     NEW:
>>>>>
>>>>>          data node rule:  controls access for a specific data node
>>>>>     and its
>>>>>     descendants,
>>>>>          identified by its path location within the conceptual XML
>>>>>     document
>>>>>     for the
>>>>>          data node.
>>>>>
>>>>>
>>>>>     sec 3.4.5, step 6, bullet 2:
>>>>>
>>>>>
>>>>>     OLD:
>>>>>
>>>>>            *  The rule does not have a "rule-type" defined or the
>>>>>     "rule-
>>>>>               type" is "data-node" and the "path" matches the
>>>>>     requested
>>>>>               data node, action node, or notification node.
>>>>>
>>>>>
>>>>>     NEW:
>>>>>
>>>>>
>>>>>            *  The rule does not have a "rule-type" defined or the
>>>>>     "rule-
>>>>>               type" is "data-node" and the "path" matches the
>>>>>     requested
>>>>>               data node, action node, or notification node. A path is
>>>>>               considered to match if the current data node is the
>>>>>     data node
>>>>>               specified by the path, or is a descendant data node
>>>>>     of this
>>>>>               data node.
>>>>
>>>>     I propose:
>>>>
>>>>                 The rule does not have a "rule-type" defined or the
>>>>                 "rule-type" is "data-node" and the "path" matches the
>>>>                 requested data node, action node, or notification node.
>>>>                 A path is considered to match if the requested node
>>>>                 is the node specified by the path, or is a
>>>>                 descendant node of the path.
>>>>
>>>>     Note:  s/current node/requested node/ which is the term used in the
>>>>     first sentence.  And then s/data node/node/ since the first
>>>>     sentence
>>>>     refer to data-, action-, and notification node.
>>>>
>>>>     I have checked in this fix in the repo.
>>>>
>>>>
>>>>     /martin
>>>>
>>>>     _______________________________________________
>>>>     Netconf mailing list
>>>>     Netconf@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>     
>>>
>>>     Mahesh Jethanandani
>>>     mjethanandani@gmail.com 
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>


--------------4F0E9AEC068D9D9024C0416D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I'm not sure I understand exactly what point the
      previous text was stating so I'm not sure whether my proposed text
      is stating the same thing (or whether this has already been stated
      elsewhere in the draft):

      

      OLD:

    

      
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

      


      

    

    
NEW:

    
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In particular

    
servers should not expose any instance information before ensuring
that the client has the necessary access permissions to obtain that
information.




    Is that any more clear?  Or have I missed the point?

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 12:55, Mahesh
      Jethanandani wrote:

    

    

      
      Can you provide text?
      


        

          

            
On Nov 16, 2017, at 12:29 PM, Robert Wilton
              <rwilton@cisco.com> wrote:

            

            

              

                
"validating field information" is slightly
                  unclear to me, can this be reworded slightly?

                
Thanks,

                  Rob

                

                

                
On 16/11/2017 03:12, Andy
                  Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I updated the draft with these changes
                      on github.

                    
There is a draft-pre-09.txt file now
                      for you to review.

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Tue, Nov 14, 2017 at
                      5:05 PM, Mahesh Jethanandani <mjethanandani@gmail.com>
                      wrote:

                      

                        
Andy,
                          


                          

                          
I assume you will incorporate
                            these changes in the -09 version of the
                            draft.

                          


                          

                          
However, I am unable to review
                            the changes in github. Can you post the
                            diffs of the draft w.r.t. -08 version.

                          


                          

                          
That still leaves us with one
                            issue, and that has to do with the what
                            permission to give edit-operation. I am
                            assuming the WG agrees that making the
                            change from ‘none’ to ‘read’ for edit
                            operations makes maintenance more difficult
                            and makes the operation more vulnerable,
                            unless all the deny rules are in place.

                          

                            

                              


                              

                              We will need to update the security
                              considerations section to address Eric’s
                              concerns. How about this update?

                            


                            

                            
OLD:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                              


                              

                            

                            
NEW:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular

                              
servers should not expose instance information before validating field

                              
information.

                              


                                

                              
Cheers.

                              


                                

                            

                            

                              

                                
On Nov 13, 2017, at 11:28
                                  PM, Martin Bjorklund <mbj@tail-f.com>
                                  wrote:

                                

                                
Hi,

                                  

                                  I just read this thread,
                                    and I agree with the changes, but
                                    see below

                                  for a comment.

                                  

                                  

                                  Andy Bierman <andy@yumaworks.com> wrote:

                                  
Hi,

                                    

                                    Here are some proposed edits to make
                                    the data rule consistent with the

                                    examples.

                                    Note that this issue is not related
                                    to the edit in the original 1-week

                                    change.

                                    

                                    

                                    sec. 3.3.5:

                                    

                                    OLD:

                                    

                                    

                                         data node rule:  controls
                                    access for a specific data node,
                                    identified

                                         by its path location within the
                                    conceptual XML document for the

                                         data node.

                                    

                                    

                                    NEW:

                                    

                                         data node rule:  controls
                                    access for a specific data node and
                                    its

                                    descendants,

                                         identified by its path location
                                    within the conceptual XML document

                                    for the

                                         data node.

                                    

                                    

                                    sec 3.4.5, step 6, bullet 2:

                                    

                                    

                                    OLD:

                                    

                                           *  The rule does not have a
                                    "rule-type" defined or the "rule-

                                              type" is "data-node" and
                                    the "path" matches the requested

                                              data node, action node, or
                                    notification node.

                                    

                                    

                                    NEW:

                                    

                                    

                                           *  The rule does not have a
                                    "rule-type" defined or the "rule-

                                              type" is "data-node" and
                                    the "path" matches the requested

                                              data node, action node, or
                                    notification node. A path is

                                              considered to match if the
                                    current data node is the data node

                                              specified by the path, or
                                    is a descendant data node of this

                                              data node.

                                  

                                  

                                  I propose:

                                  

                                              The rule does
                                    not have a "rule-type" defined or
                                    the

                                              "rule-type" is
                                    "data-node" and the "path" matches
                                    the

                                              requested data
                                    node, action node, or notification
                                    node.

                                              A path is
                                    considered to match if the requested
                                    node

                                              is the node
                                    specified by the path, or is a

                                              descendant node
                                    of the path.

                                  

                                  Note:  s/current
                                    node/requested node/ which is the
                                    term used in the

                                  first sentence.  And then
                                    s/data node/node/ since the first
                                    sentence

                                  refer to data-, action-,
                                    and notification node.

                                  

                                  I have checked in this fix
                                    in the repo.

                                  

                                  

                                  /martin

                                  

                                  _______________________________________________

                                  Netconf mailing list

                                  Netconf@ietf.org

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

                              

                            

                            

                                

                                  
Mahesh Jethanandani

                                  
                                

                                

                              

                        

                      

                    

                    

                  

                  

                  

                  

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


                

                

              

            

          

        

        

        

          
Mahesh Jethanandani

          
        

        

      

    

    

  


--------------4F0E9AEC068D9D9024C0416D--


From nobody Wed Nov 15 22:02:56 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3E212741D for ; Wed, 15 Nov 2017 22:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ZW10Ne5yAT26 for ; Wed, 15 Nov 2017 22:02:52 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20112.outbound.protection.outlook.com [40.107.2.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCADB127201 for ; Wed, 15 Nov 2017 22:02:51 -0800 (PST)
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; bh=F/v7v8tlKFV4hakfMujeMzrYEE82PuGqGR4sNbwTiv8=; b=EON28tlTYfFda9D+6E0fLVroJa8CXLOypnXEP7Xv8jgsE9ZP9fPBaf7FNB25ZIa05xYopzGn090yEd5X93ci4kE5k4KlA8tDzeUVBz99daeGGPK2gC24US4nToYzPrMgqtUEGS7X02TmrMVIcvgnMXwdcOV0RIaBNM5vwqYvo7Q=
Received: from AM3PR07MB354.eurprd07.prod.outlook.com (10.242.109.145) by AM3PR07MB355.eurprd07.prod.outlook.com (10.242.109.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Thu, 16 Nov 2017 06:02:48 +0000
Received: from AM3PR07MB354.eurprd07.prod.outlook.com ([fe80::cd8a:4575:3695:dd34]) by AM3PR07MB354.eurprd07.prod.outlook.com ([fe80::cd8a:4575:3695:dd34%16]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 06:02:48 +0000
From: "Elbokl, Walid (Nokia - CA/Ottawa)" 
To: "netconf@ietf.org" 
Thread-Topic: Feedback on subscribed-notifications and yang-push
Thread-Index: AdNejQcCtPM/wh9HQrCltghlmRo4DAAEyPow
Date: Thu, 16 Nov 2017 06:02:48 +0000
Message-ID: 
References: 
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=walid.elbokl@nokia.com; 
x-originating-ip: [135.245.20.29]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB355; 6:yHjSOufrU3w/0JNMBshqwm1cdHrhhxhD1uqhFSAC04JV5gsTgXS1ZpSpXPDB8o1rwq3x5cf++N7hAwPauoOWYDynM/7WP9iEQkJdcM8gaHL2rONDK3A+RSKt8IT7LO7eNNlhVpZ0Gpe3apbdA9qSibOaV4QnKNSEwjNvA5jzJYkxxs6DZG7pYS4Pb7Zz4TOuNcFH6/L126PjAYaMbrFlV9Oog6gwNWfwu8mFAo38wJ/xQvBbJLqGZrOcfCTJUAAHoOTJvKdBXJ6gbQU4ulkRBvk4DKbvnOrzBJtiKlFgkj/p9sOsWggAwm7EF7qvdzA0JBRYDgvb6nQPVXAfHiXmbADJSwk3x8hjzQ/IyefMiA4=; 5:b44H0TPos+RAtul8zgCt7Xnx4dZNIVeN5Dstn3NnAcxSFth1klGHZkw/4FsvR+FXZZUxgTsXNamNIelJ1hlJLnCk0UlK6Nwh0QGYj/938J1C7zKLSDXl2LVLNY4I1tHwHJv0WVJch1jkXhahwr0GFxhJg2u8l/oZ2gl5eqX0dZk=; 24:JvPAH256S3pbCrxNARnyWQ8i5ilJfkU4Fsldi2Z4naQiEb+xNy0BkQGfp9M4R+qDCUuDZjFfARlgkxylgTX81wR25/I5i27xAwFlmWC8GvU=; 7:0b6PRhZ+wZDbX1kNZsELVleOO+809txBhxMjLETawVRBAcE5efzYzz8wHQao71GfLqc8a4YCX++blG4TF+F6I810Cg4S7THuHFIk4xz9675HdxRub4tjr8BT2pwwjup9te6ZURQJpXBHVX0Gk6A9qZrDkqixCh/ohUHzZEQ/hs0FzYBUmmQqnlujhhu4h4TNoy0IRfEoWtHsd0KnrbWuj6kFMru8bW77zp/YDGrACeclkVV4HIEpgtL5rLfL54aR
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2093dda1-fb19-4bfb-2a8f-08d52cb7a9d6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB355; 
x-ms-traffictypediagnostic: AM3PR07MB355:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB355; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB355; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(53754006)(199003)(189002)(2906002)(6246003)(50986999)(5640700003)(8676002)(229853002)(5250100002)(6436002)(101416001)(54356999)(76176999)(3660700001)(3280700002)(2501003)(6506006)(189998001)(33656002)(53936002)(106356001)(2351001)(14454004)(81156014)(1730700003)(105586002)(55016002)(9686003)(6306002)(68736007)(81166006)(10710500007)(15650500001)(8936002)(2420400007)(74316002)(99286004)(966005)(7736002)(4326008)(3846002)(7696004)(2950100002)(6916009)(86362001)(25786009)(316002)(5660300001)(478600001)(7110500001)(102836003)(2900100001)(66066001)(6116002)(97736004)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB355; H:AM3PR07MB354.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB3546D47D4C3C4F78514E4A38D2E0AM3PR07MB354eurprd_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2093dda1-fb19-4bfb-2a8f-08d52cb7a9d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 06:02:48.1565 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB355
Archived-At: 
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:02:54 -0000

--_000_AM3PR07MB3546D47D4C3C4F78514E4A38D2E0AM3PR07MB354eurprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Just to clarify, I do think that the drafts are ready to go to last call. A=
ny questions/concerns I listed below can be addressed then.

Regards,
Walid

_____________________________________________
From: Elbokl, Walid (Nokia - CA/Ottawa)
Sent: Thursday, November 16, 2017 11:43 AM
To: 'netconf@ietf.org' 
Cc: 'Eric Voit (evoit)' ; ludwig@clemm.org
Subject: Feedback on subscribed-notifications and yang-push


Hi All,

I have reviewed:
-       draft-ietf-netconf-subscribed-notifications-07
-       draft-ietf-netconf-yang-push-11
and have the following mix of comments/questions:

1.      subscribed-notifications draft: What is the background/reason for n=
ot having dscp with notifications (i.e. same as with yang push)?
2.      subscribed-notifications draft: In figure 1/page 8, it implies that=
 a modification to a suspended subscription would get the subscription to b=
e active first before the server decides to keep it active or suspend it ag=
ain. I would have thought a modification can be considered by the server wh=
ile the subscription is still suspended then it could either become active =
or stay suspended
3.      subscribed-notifications draft: Fully agree with having replay with=
 notifications only and not yang-push
4.      subscribed-notifications draft: In "modify-subscription", though a =
subscriber-id is writeable (i.e. to be able to specify which subscription t=
o modify) but the server should not allow changing it on a suspended/active=
 subscription
5.      subscribed-notifications draft: In "modify-subscription", why not m=
odify "replay-start-time"? i.e. purge whole/part of the replay buffer
      Use case: purging whole/part of the replay buffer in scenarios where =
it may have been a reason to suspend a subscription
      The argument that the operator can cancel the subscription and re-est=
ablish another one applies to modifying everything and would mean no need f=
or modify-subscription from the first place. Also, an operator may consider=
 purging part of the buffer and not all.
6.      Yang push draft: page 11/Figure 1,  should be =

7.      Yang push draft: section 7:
   If the access control permissions on subscribed YANG nodes change
   during the lifecycle of a subscription, a publisher MUST either
   transparently conform to the new access control permissions, or must
   terminate or restart the subscriptions so that new access control
   permissions are re-established.

      The draft allows authorization either at subscription time or at send=
 time. IMO, authorization @ send time should be the way to go.
Regards,
Walid


--_000_AM3PR07MB3546D47D4C3C4F78514E4A38D2E0AM3PR07MB354eurprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Just to clarify, I do think that the drafts are=
 ready to go to last call. Any questions/concerns I listed below can be add=
ressed then.


 


Regards,


Walid


 


_____________________________________________

From: Elbokl, Walid (Nokia - CA/Ottawa) 


Sent: Thursday, November 16, 2017 11:43 AM


To: 'netconf@ietf.org' <netconf@ietf.org>


Cc: 'Eric Voit (evoit)' <evoit@cisco.com>; ludwig@clemm.org

Subject: Feedback on subscribed-notifications and yang-push

 


 


Hi All,


 


I have reviewed:


    


  • draft-ietf-netconf-subscribed-notificatio=
ns-07
  • draft-ietf-netconf-yang-push-11=

    • 



and have the following mix of comments/question=
s:


 


    


  1. subscribed-notifications draft: What is t=
he background/reason for not having dscp with notifications (i.e. same as w=
ith yang push)?
  2. subscribed-notificati=
ons draft: In figure 1/page 8, it implies that a modification to a suspende=
d subscription would get the subscription to be active first before the ser=
ver decides to keep it active or suspend it again. I would
have thought a modification can be considered by the server while the subsc=
ription is still suspended then it could either become active or stay suspe=
nded
  3. subscribed-notifications draft: =
Fully agree with having replay with notifications only and not yang-push
  4. subscribed-notifications draft: In R=
20;modify-subscription”, though a subscriber-id is writeable (i.e. to be able to specify which =
subscription to modify) but the server should not allow
changing it on a suspended/active subscription
  5. subscribed-notifications draft: In “modify-s=
ubscription”, why not modify “replay-start-time”? i.e. pu=
rge whole/part of the replay buffer
    6. 



Use case: purging whole/part of the replay buffer in scenarios where it ma=
y have been a reason to suspend a subscription


The argument that the operator can cancel the subscription and re-establis=
h another one applies to modifying everything and would mean no need for mo=
dify-subscription from the first place.
Also, an operator may consider purging part of the buffer and not all.


    


  1. Yang push draft: page 11/Figure 1, </p=
ush-change-update> should be </push-update>
  2. Yang push draft: section 7:
    3. 



If the access control permissions on subscribed YA=
NG nodes change


during the lifecycle of a subscription, a publishe=
r MUST either


transparently conform to the new access control pe=
rmissions, or must


terminate or restart the subscriptions so that new=
 access control


permissions are re-established.

 


The draft allows authorization either at subscription time or at send time=
. IMO, authorization @ send time should be the way to go.


Regards,


Walid


 





--_000_AM3PR07MB3546D47D4C3C4F78514E4A38D2E0AM3PR07MB354eurprd_--


From nobody Wed Nov 15 22:16:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB861294D8; Wed, 15 Nov 2017 22:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9SiF0h8Tanwm; Wed, 15 Nov 2017 22:16:16 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6973F129510; Wed, 15 Nov 2017 22:16:16 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id b6so18647512pff.10; Wed, 15 Nov 2017 22:16:16 -0800 (PST)
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=/iaZFCZYOQrLwwGmiYrJSvA9To9aV8nISJzxKw5xoaQ=; b=mMbnGrO/uNDSiV3IyGiTKcOQfW9nrXHDEo+MrlkJsHvY2y0QqrFUTdYlYpTe1uFRvB Q4RtjTCRHJJqyCuTr+HrJgQYq+AeJXq4qYsW+8dP/YyceZxcJpk63cJF1Iut7eILYTig NPEzzlFVddFkrlbQBkCCyO75YvN495SPKd0oEUV2UuT4jn9M5fBM7aLfmxvnAhzqLroV ETPSpCj8GBycDAHb6J0s/7wTZWb1aKSukodEmmuPaZBPHqqpl66Eu28/LHbLBIOscGL1 kdOOaK5STlOJGmZJHiiSnzteYEJ7af9IQdQNckmwc9bXzIZatmUiYYyhTBdxqM4q1rC5 Yaiw==
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=/iaZFCZYOQrLwwGmiYrJSvA9To9aV8nISJzxKw5xoaQ=; b=tyr/bBKccBjfkdOq5jjFSB/mtr8pXSOswU7Ksfeo3IS+Hk0TZz6dNL/009jT+G5QsM 2Ec/v+xfFgqQC8bnOK74HGKBRUFpRZ16NHKkeR525CaLHwW8niy8rAB61k2U+dKOSQ0c eRFPO64OP2KRmGJvmopH5hYqxaPYEE/i7M/EygjCBezvkAgiKYq3JUKEh92KIdn0nB+s sHMJYgAcqYyyc5pdpdWylqqolovGABAITrt3N4eU6ta6RLzZR8PYEdYaIo2+Qh8e5Vyj PtnsCTF1uEDMEwtSkyPzWXGCDUAN+xqVJdqiowvGSs3fB6+TmfKP3dpf6tXdbLbPfBZL m2bg==
X-Gm-Message-State: AJaThX6RupQLalO/gtMX0sOA0gXDpM05Byp8Hc1OZkcJRigLLVpYnCxd Lr9GFqG9xPm0sj+2nsoUObM=
X-Google-Smtp-Source: AGs4zMbH6Ux8SkQlNwlxAivYQTrmgRKzPCAIQ8UXi/iDa9A14dLenpXPZt39cHdqy1frpQnKlKH6ww==
X-Received: by 10.159.198.9 with SMTP id f9mr656386plo.74.1510812975947; Wed, 15 Nov 2017 22:16:15 -0800 (PST)
Received: from dhcp-927c.meeting.ietf.org (dhcp-927c.meeting.ietf.org. [31.133.146.124]) by smtp.gmail.com with ESMTPSA id e18sm862575pfi.57.2017.11.15.22.16.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 22:16:15 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F58072AA-3F2D-47C9-8809-B9909343971F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com>
Date: Thu, 16 Nov 2017 14:16:11 +0800
Cc: Andy Bierman , sec-ads@ietf.org, netconf , Eric Rescorla 
Message-Id: 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>    <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:16:20 -0000

--Apple-Mail=_F58072AA-3F2D-47C9-8809-B9909343971F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Robert,

> On Nov 16, 2017, at 1:56 PM, Robert Wilton  wrote:
>=20
> I'm not sure I understand exactly what point the previous text was =
stating so I'm not sure whether my proposed text is stating the same =
thing (or whether this has already been stated elsewhere in the draft):
>=20
> OLD:
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances. In particular
> servers should not expose instance information before validating field
> information.
>=20
> NEW:
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances.  In particular
> servers should not expose any instance information before ensuring
> that the client has the necessary access permissions to obtain that
> information.
>=20
>=20
> Is that any more clear?  Or have I missed the point?

The point of the previous text was to make sure the client should have =
their access permission checked before any instance information was =
checked.=20

I am ok with this text.

>=20
> Thanks,
> Rob
>=20
>=20
> On 16/11/2017 12:55, Mahesh Jethanandani wrote:
>> Can you provide text?
>>=20
>>> On Nov 16, 2017, at 12:29 PM, Robert Wilton > wrote:
>>>=20
>>> "validating field information" is slightly unclear to me, can this =
be reworded slightly?
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>> On 16/11/2017 03:12, Andy Bierman wrote:
>>>> Hi,
>>>>=20
>>>> I updated the draft with these changes on github.
>>>> There is a draft-pre-09.txt file now for you to review.
>>>>=20
>>>>=20
>>>> Andy
>>>>=20
>>>>=20
>>>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani =
> wrote:
>>>> Andy,
>>>>=20
>>>> I assume you will incorporate these changes in the -09 version of =
the draft.
>>>>=20
>>>> However, I am unable to review the changes in github. Can you post =
the diffs of the draft w.r.t. -08 version.
>>>>=20
>>>> That still leaves us with one issue, and that has to do with the =
what permission to give edit-operation. I am assuming the WG agrees that =
making the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 =
for edit operations makes maintenance more difficult and makes the =
operation more vulnerable, unless all the deny rules are in place.
>>>>=20
>>>> We will need to update the security considerations section to =
address Eric=E2=80=99s concerns. How about this update?
>>>>=20
>>>> OLD:
>>>> Therefore, a server MUST NOT vary their OPTIONS responses
>>>> based on the existence of the underlying resource, which would
>>>> indicate the presence or absence of resource instances.
>>>>=20
>>>> NEW:
>>>> Therefore, a server MUST NOT vary their OPTIONS responses
>>>> based on the existence of the underlying resource, which would
>>>> indicate the presence or absence of resource instances. In =
particular
>>>> servers should not expose instance information before validating =
field
>>>> information.
>>>>=20
>>>> Cheers.
>>>>=20
>>>>> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund > wrote:
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I just read this thread, and I agree with the changes, but see =
below
>>>>> for a comment.
>>>>>=20
>>>>>=20
>>>>> Andy Bierman > =
wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> Here are some proposed edits to make the data rule consistent =
with the
>>>>>> examples.
>>>>>> Note that this issue is not related to the edit in the original =
1-week
>>>>>> change.
>>>>>>=20
>>>>>>=20
>>>>>> sec. 3.3.5:
>>>>>>=20
>>>>>> OLD:
>>>>>>=20
>>>>>>=20
>>>>>>      data node rule:  controls access for a specific data node, =
identified
>>>>>>      by its path location within the conceptual XML document for =
the
>>>>>>      data node.
>>>>>>=20
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>>      data node rule:  controls access for a specific data node =
and its
>>>>>> descendants,
>>>>>>      identified by its path location within the conceptual XML =
document
>>>>>> for the
>>>>>>      data node.
>>>>>>=20
>>>>>>=20
>>>>>> sec 3.4.5, step 6, bullet 2:
>>>>>>=20
>>>>>>=20
>>>>>> OLD:
>>>>>>=20
>>>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>>>           type" is "data-node" and the "path" matches the =
requested
>>>>>>           data node, action node, or notification node.
>>>>>>=20
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>>=20
>>>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>>>           type" is "data-node" and the "path" matches the =
requested
>>>>>>           data node, action node, or notification node. A path is
>>>>>>           considered to match if the current data node is the =
data node
>>>>>>           specified by the path, or is a descendant data node of =
this
>>>>>>           data node.
>>>>>=20
>>>>> I propose:
>>>>>=20
>>>>>             The rule does not have a "rule-type" defined or the
>>>>>             "rule-type" is "data-node" and the "path" matches the
>>>>>             requested data node, action node, or notification =
node.
>>>>>             A path is considered to match if the requested node
>>>>>             is the node specified by the path, or is a
>>>>>             descendant node of the path.
>>>>>=20
>>>>> Note:  s/current node/requested node/ which is the term used in =
the
>>>>> first sentence.  And then s/data node/node/ since the first =
sentence
>>>>> refer to data-, action-, and notification node.
>>>>>=20
>>>>> I have checked in this fix in the repo.
>>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/netconf =

>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com 
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/netconf =

>>>=20
>>=20
>> Mahesh Jethanandani
>> mjethanandani@gmail.com 
>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_F58072AA-3F2D-47C9-8809-B9909343971F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Robert,

On Nov 16, 2017, at 1:56 PM, =
Robert Wilton <rwilton@cisco.com> wrote:


 =20
    
 =20
  

    
I'm not sure I understand exactly what point the
      previous text was stating so I'm not sure whether my proposed text
      is stating the same thing (or whether this has already been stated
      elsewhere in the draft):

      

      OLD:

    

      
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

      


      

    

    
NEW:

    
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In =
particular

    
servers should not expose any instance information =
before ensuring
that the client has the necessary access permissions to obtain that
information.




    Is that any more clear?  Or have I missed the point?

The point =
of the previous text was to make sure the client should have their =
access permission checked before any instance information was =
checked. 

I am ok with this =
text.


    

    Thanks,

    Rob

    

    

    
On 16/11/2017 12:55, Mahesh
      Jethanandani wrote:

    

    

      
      Can you provide text?
      


        

          

            
On Nov 16, 2017, at 12:29 PM, Robert Wilton
              <rwilton@cisco.com> wrote:

            

            

              
"validating field information" is slightly
                  unclear to me, can this be reworded slightly?
Thanks,

                  Rob

                

                

                
On 16/11/2017 03:12, Andy
                  Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I updated the draft with these =
changes
                      on github.

                    
There is a draft-pre-09.txt file now
                      for you to review.

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Tue, Nov 14, 2017 at
                      5:05 PM, Mahesh Jethanandani <mjethanandani@gmail.com>
                      wrote:

                      

                        
Andy,
                          


                          

                          
I assume you will incorporate
                            these changes in the -09 version of the
                            draft.

                          


                          

                          
However, I am unable to review
                            the changes in github. Can you post the
                            diffs of the draft w.r.t. -08 version.

                          


                          

                          
That still leaves us with one
                            issue, and that has to do with the what
                            permission to give edit-operation. I am
                            assuming the WG agrees that making the
                            change from =E2=80=98none=E2=80=99 to =
=E2=80=98read=E2=80=99 for edit
                            operations makes maintenance more difficult
                            and makes the operation more vulnerable,
                            unless all the deny rules are in =
place.

                          

                            

                              


                              

                              We will need to update the security
                              considerations section to address Eric=E2=80=
=99s
                              concerns. How about this update?

                            


                            

                            
OLD:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                              


                              

                            

                            
NEW:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In =
particular

                              
servers should not expose instance information before =
validating field

                              
information.

                              


                                

                              
Cheers.

                              


                                

                            

                            

                              

                                
On Nov 13, 2017, at =
11:28
                                  PM, Martin Bjorklund <mbj@tail-f.com>
                                  wrote:

                                

                                
Hi,

                                  

                                  I just read this thread,
                                    and I agree with the changes, but
                                    see below

                                  for a comment.

                                  

                                  

                                  Andy Bierman <andy@yumaworks.com> wrote:

                                  
Hi,

                                    

                                    Here are some proposed edits to make
                                    the data rule consistent with the

                                    examples.

                                    Note that this issue is not related
                                    to the edit in the original =
1-week

                                    change.

                                    

                                    

                                    sec. 3.3.5:

                                    

                                    OLD:

                                    

                                    

                                         data =
node rule:  controls
                                    access for a specific data node,
                                    identified

                                         by its =
path location within the
                                    conceptual XML document for the

                                         data =
node.

                                    

                                    

                                    NEW:

                                    

                                         data =
node rule:  controls
                                    access for a specific data node and
                                    its

                                    descendants,

                                    =
     identified by its path location
                                    within the conceptual XML =
document

                                    for the

                                         data =
node.

                                    

                                    

                                    sec 3.4.5, step 6, bullet 2:

                                    

                                    

                                    OLD:

                                    

                                    =
       *  The rule does not have =
a
                                    "rule-type" defined or the "rule-

                                    =
          type" is =
"data-node" and
                                    the "path" matches the requested

                                    =
          data node, =
action node, or
                                    notification node.

                                    

                                    

                                    NEW:

                                    

                                    

                                    =
       *  The rule does not have =
a
                                    "rule-type" defined or the "rule-

                                    =
          type" is =
"data-node" and
                                    the "path" matches the requested

                                    =
          data node, =
action node, or
                                    notification node. A path is

                                    =
          considered =
to match if the
                                    current data node is the data =
node

                                    =
          specified by =
the path, or
                                    is a descendant data node of this

                                    =
          data =
node.

                                  

                                  

                                  I propose:

                                  

                                            &nb=
sp; The rule does
                                    not have a "rule-type" defined or
                                    the

                                            &nb=
sp; "rule-type" is
                                    "data-node" and the "path" matches
                                    the

                                            &nb=
sp; requested data
                                    node, action node, or notification
                                    node.

                                            &nb=
sp; A path is
                                    considered to match if the requested
                                    node

                                            &nb=
sp; is the node
                                    specified by the path, or is =
a

                                            &nb=
sp; descendant node
                                    of the path.

                                  

                                  Note:  s/current
                                    node/requested node/ which is the
                                    term used in the

                                  first sentence.  And =
then
                                    s/data node/node/ since the first
                                    sentence

                                  refer to data-, action-,
                                    and notification node.

                                  

                                  I have checked in this fix
                                    in the repo.

                                  

                                  

                                  /martin

                                  

                                  _______________________________________________

                                  Netconf mailing =
list

                                  Netconf@ietf.org

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

                              

                            

                            

                                

                                  
Mahesh =
Jethanandani

                                  
mjethanandani@gmail.com

                                

                                

                              

                        

                      

                    

                    

                  

                  

                  

                  

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



                

                

              

            

          

        

        

        

          
Mahesh Jethanandani

          
mjethanandani@gmail.com

        

        

      

    

    

  






Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_F58072AA-3F2D-47C9-8809-B9909343971F--


From nobody Wed Nov 15 22:47:32 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7961294E8 for ; Wed, 15 Nov 2017 22:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0axo6oMaTkhD for ; Wed, 15 Nov 2017 22:47:29 -0800 (PST)
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 4A08E12956D for ; Wed, 15 Nov 2017 22:47:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22065; q=dns/txt; s=iport; t=1510814838; x=1512024438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/qAb9oE952NzUdcnv98FEieo/hC7Fimrg/4lSjbKDKM=; b=QhMududCxa+HaPgTBP91TehOwmuQ72k/1VWbmCP0ZQnpMV0TlmCvUddS Z7XurdbsxHtZ8Hi59guMYF5fjIWSxoLHNGw8O6Kou0xbDUBUAUYOTCQ3o pY2fQMFmCYSCLfeXbsKoNfoMLY9gKO31DvCjcNHPTHOpPKV1W7LHRIm0d A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAQC4Mw1a/4QNJK0WBTwHGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYJERC5kbi6dN4F9ll6CEQqFOwKFEUEWAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQEDLUoCEAIBCBUQEw4yFBEBAQQBDQ2JOGSFGaZbixMBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgzSCB4FVgWmDKoUCAyGFagWiNwKUe4IekS+KM4tOAhEZAYE?= =?us-ascii?q?4ASYHKoF0ehWDLoReiV8HI4EJgREBAQE?=
X-IronPort-AV: E=Sophos; i="5.44,402,1505779200"; d="scan'208,217"; a="31620783"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 06:47:17 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAG6lGXT018892 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 06:47:17 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 01:47:16 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 01:47:16 -0500
From: "Eric Voit (evoit)" 
To: "Elbokl, Walid (Nokia - CA/Ottawa)" , "netconf@ietf.org" 
Thread-Topic: Feedback on subscribed-notifications and yang-push
Thread-Index: AdNejQcCtPM/wh9HQrCltghlmRo4DAAAaa5Q
Date: Thu, 16 Nov 2017 06:47:16 +0000
Message-ID: <5849f214483c427d802cc77fb9a90e94@XCH-RTP-013.cisco.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: multipart/alternative; boundary="_000_5849f214483c427d802cc77fb9a90e94XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:47:32 -0000

--_000_5849f214483c427d802cc77fb9a90e94XCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks for the comments on the two drafts Walid.  Thoughts in-line...

From: Elbokl, Walid, November 15, 2017 10:43 PM

Hi All,

I have reviewed:
*        draft-ietf-netconf-subscribed-notifications-07
*        draft-ietf-netconf-yang-push-11
and have the following mix of comments/questions:

1.      subscribed-notifications draft: What is the background/reason for n=
ot having dscp with notifications (i.e. same as with yang push)?
 Current 5277 event streams haven't shown need for QoS.   So for simp=
licities sake, we bundled all QoS elements together in YANG push where we k=
new there was demonstrable need.
2.      subscribed-notifications draft: In figure 1/page 8, it implies that=
 a modification to a suspended subscription would get the subscription to b=
e active first before the server decides to keep it active or suspend it ag=
ain. I would have thought a modification can be considered by the server wh=
ile the subscription is still suspended then it could either become active =
or stay suspended
 The result is pretty much the same.  When the configuration change =
is made, an immediate attempt should be made apply this to all receivers (a=
ctive and suspended).  This way allows for explicit kick-starting of receiv=
ers suspended, and another suspension despite the modification will be show=
n in the logs, or in an on-change subscription made on this subscription ta=
ble itself.
3.      subscribed-notifications draft: Fully agree with having replay with=
 notifications only and not yang-push
4.      subscribed-notifications draft: In "modify-subscription", though a =
subscriber-id is writeable (i.e. to be able to specify which subscription t=
o modify) but the server should not allow changing it on a suspended/active=
 subscription
 I think this is a diagrammatic convention that all RPC input fields =
are writeable.  Certainly we don't want the behavior you describe.
5.      subscribed-notifications draft: In "modify-subscription", why not m=
odify "replay-start-time"? i.e. purge whole/part of the replay buffer
Use case: purging whole/part of the replay buffer in scenarios where it may=
 have been a reason to suspend a subscription
The argument that the operator can cancel the subscription and re-establish=
 another one applies to modifying everything and would mean no need for mod=
ify-subscription from the first place. Also, an operator may consider purgi=
ng part of the buffer and not all.
 This is possible to cover, but to me it seems a corner case to modif=
y a replay in flight.  Deleting a subscription and restarting accomplishes =
the same.  Do other people have a desire to modify a replay in flight?
6.      Yang push draft: page 11/Figure 1,  should be =

 Good catch, thanks!
7.      Yang push draft: section 7:
If the access control permissions on subscribed YANG nodes change
during the lifecycle of a subscription, a publisher MUST either
transparently conform to the new access control permissions, or must
terminate or restart the subscriptions so that new access control
permissions are re-established.

The draft allows authorization either at subscription time or at send time.=
 IMO, authorization @ send time should be the way to go.

 I agree, but Andy B. asked for this option as he didn't want to buil=
d the more complex send-time capability.  Considering he wrote much of NACM=
, I listened :-)

Eric
Regards,
Walid


--_000_5849f214483c427d802cc77fb9a90e94XCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks for the comments on the two dr=
afts Walid.  Thoughts in-line...


 








From: Elbokl, Walid, November 15, 20=
17 10:43 PM












Hi All,






 






I have reviewed:





·       
draft-ietf-netconf-subscribed-notifications=
-07



·       
draft-ietf-netconf-yang-push-11<=
/span>




and have the following mix of comments/questions:






 





1.     
subscribed-notifications draft: What is the=
 background/reason for not having dscp with notifications (i.e. same as wit=
h yang push)?


<eric> Current 5277 event streams haven’t sho=
wn need for QoS.   So for simplicities sake, we bundled all
 QoS elements together in YANG push where we knew there was demonstrable ne=
ed.  




2.     
subscribed-notifications draft: In figure 1=
/page 8, it implies that a modification to a suspended subscription would g=
et the subscription to be active first before
 the server decides to keep it active or suspend it again. I would have tho=
ught a modification can be considered by the server while the subscription =
is still suspended then it could either become active or stay suspended


<evoit> The result is pretty much the same.  W=
hen the configuration change is made, an immediate attempt
 should be made apply this to all receivers (active and suspended).  T=
his way allows for explicit kick-starting of receivers suspended, and anoth=
er suspension despite the modification will be shown in the logs, or in an =
on-change subscription made on this subscription
 table itself.



3.     
subscribed-notifications draft: Fully agree=
 with having replay with notifications only and not yang-push



4.     
subscribed-notifications draft: In “m=
odify-subscription”,
though a =
subscriber-id is writeable (i.e. to be able to specify which subscription t=
o modify) but the server should not allow changing it on a suspended/active=
 subscription


<eric> I think this is a diagrammatic convention th=
at all RPC input fields are writeable.  Certainly we don’t
 want the behavior you describe.



5.     
subscribed-notifications draft: In “m=
odify-subscription”, why not modify “replay-start-time”? =
i.e. purge whole/part of the replay buffer




Use case: purging whole/part of the replay buffer i=
n scenarios where it may have been a reason to suspend a subscription<=
/o:p>






The argument that the operator can cancel the subsc=
ription and re-establish another one applies to modifying everything and wo=
uld mean no need for modify-subscription from
 the first place. Also, an operator may consider purging part of the buffer=
 and not all.


<Eric> This is possible to cover, but to me it seem=
s a corner case to modify a replay in flight.  Deleting
 a subscription and restarting accomplishes the same.  Do other people=
 have a desire to modify a replay in flight?





6.     
Yang push draft: page 11/Figure 1, </pus=
h-change-update> should be </push-update>


<Eric> Good catch, thanks!



7.     
Yang push draft: section 7:




If the access control permissions on subscribed YANG nodes change<=
o:p>






during the lifecycle of a subscription, a publisher MUST either






transparently conform to the new access control permissions, or must






terminate or restart the subscriptions so that new access control<=
o:p>






permissions are re-established.






 






The draft allows authorization either at subscripti=
on time or at send time. IMO, authorization @ send time should be the way t=
o go.


 


<Eric> I agree, but Andy B. ask=
ed for this option as he didn’t want to build the more complex send-t=
ime capability.  Considering he wrote much of NACM, I listened
 :-)


 


Eric






Regards,






Walid






 










--_000_5849f214483c427d802cc77fb9a90e94XCHRTP013ciscocom_--


From nobody Wed Nov 15 23:47:38 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C081287A0 for ; Wed, 15 Nov 2017 23:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcBSqpCu3duC for ; Wed, 15 Nov 2017 23:47:35 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A517D120724 for ; Wed, 15 Nov 2017 23:47:35 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A89BBF6B60183 for ; Thu, 16 Nov 2017 07:47:31 +0000 (GMT)
Received: from DGGEMA423-HUB.china.huawei.com (10.1.198.156) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 07:47:32 +0000
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.146]) by dggema423-hub.china.huawei.com ([10.1.198.156]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 15:47:20 +0800
From: Rohit R Ranade 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] draft-ietf-netconf-rfc6536bis Query
Thread-Index: AdNdz9MehD+d0xYjTJ+ndshlR/LYrAA3pAkg
Date: Thu, 16 Nov 2017 07:47:20 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B1482E3@DGGEMA502-MBS.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_991B70D8B4112A4699D5C00DDBBF878A6B1482E3DGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 07:47:38 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6B1482E3DGGEMA502MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

1 more point I wanted clarified was for the below point

leaf-list group {
           type union {
             type matchall-string-type;
             type group-name-type;
           }
           description
             "List of administrative groups that will be
              assigned the associated access rights
              defined by the 'rule' list.

              The string '*' indicates that all groups apply to the
              entry.";

Consider that existing configuration is like below:

   list1
   ug1


Consider that user will add to this group a record of '*"

   list1
   ug1
*


?  Whether this is valid configuration ? "*" can be considered as a super-s=
et as it will apply for all group. So can this leaf-list contain * along wi=
th other UGs ?

One scenario where this is possible is when initially the user had thought =
of applying a rule-list to only a particular Group , but later the user wan=
ts to apply to all groups.

With Regards,
Rohit R

From: Rohit R Ranade
Sent: 15 November 2017 10:42
To: netconf@ietf.org
Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi All,

For the state-data in NACM like the below :

leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the server last restarted that a
            protocol operation request was denied.";
       }

"Number of times since the server" =3D=3D> Here the server is being referen=
ced to NETCONF server or RESTCONF server ?
Please note that the both the NETCONF server and RESTCONF server maybe usin=
g the same NACM configurations but the state-data maintained by each protoc=
ol maybe different.

With Regards,
Rohit R

--_000_991B70D8B4112A4699D5C00DDBBF878A6B1482E3DGGEMA502MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,=



&n=
bsp;


1 more =
point I wanted clarified was for the below point


&n=
bsp;


leaf-list group {


       &nb=
sp;   type union {


       &nb=
sp;     type matchall-string-type;

       &nb=
sp;     type group-name-type;


       &nb=
sp;   }


       &nb=
sp;   description


       &nb=
sp;     "List of administrative groups that will b=
e


       &nb=
sp;      assigned the associated access rights


       &nb=
sp;      defined by the 'rule' list.


 


       &nb=
sp;      The string '*' indicates that all groups =
apply to the


       &nb=
sp;      entry.";


&n=
bsp;


Conside=
r that existing configuration is like below:


<rul=
e-list>


 &=
nbsp; <name>list1</name>


 &=
nbsp; <group>ug1</group>


</ru=
le-list>


&n=
bsp;


Conside=
r that user will add to this group a record of ‘*”


<rul=
e-list>


 &=
nbsp; <name>list1</name>


 &=
nbsp; <group>ug1</group>


<group>*</group>


</ru=
le-list>



ð 
Whether this is valid configuration ? “*” can be considered as=
 a super-set as it will apply for all group. So can this leaf-list contain =
* along with other UGs ?


&n=
bsp;


One sce=
nario where this is possible is when initially the user had thought of appl=
ying a rule-list to only a particular Group , but later the user wants to a=
pply to all groups.


&n=
bsp;


With Re=
gards,


Rohit R=



&n=
bsp;






From: Rohit R Ranade


Sent: 15 November 2017 10:42

To: netconf@ietf.org

Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query






 


Hi All,


 


For the state-data in NACM like=
 the below :


 


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the server last restarted that =
a


       &nb=
sp;    protocol operation request was denied.";


       }


 


“Number of times since the server”
è=
 Here the server is being referenced to NETCONF server=
 or RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.<=
/span>


 


With Regards,=



Rohit R






--_000_991B70D8B4112A4699D5C00DDBBF878A6B1482E3DGGEMA502MBSchi_--


From nobody Wed Nov 15 23:55:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF5126DEE for ; Wed, 15 Nov 2017 23:54:58 -0800 (PST)
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 0Zdy2QFGara2 for ; Wed, 15 Nov 2017 23:54:56 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37A7412969E for ; Wed, 15 Nov 2017 23:54:56 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 50F2D1AE030A; Thu, 16 Nov 2017 08:54:54 +0100 (CET)
Date: Thu, 16 Nov 2017 08:53:31 +0100 (CET)
Message-Id: <20171116.085331.436907075368637840.mbj@tail-f.com>
To: einarnn@cisco.com
Cc: evoit@cisco.com, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com>
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@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: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 07:54:59 -0000

SGksDQoNCk5vdGUgdGhhdCB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgY3VycmVudCBtb2RlbCBoYXM6
DQoNCiAgICAgICstLXJ3IHN1YnNjcmlwdGlvbiogW2lkZW50aWZpZXJdDQogICAgICAgICAuLi4N
CiAgICAgICAgICstLXJ3IGVuY29kaW5nDQogICAgICAgICAuLi4NCiAgICAgICAgICstLXJ3IHJl
Y2VpdmVycw0KICAgICAgICAgICAgKy0tcncgcmVjZWl2ZXIqIFthZGRyZXNzIHBvcnRdDQogICAg
ICAgICAgICAgICAuLi4NCiAgICAgICAgICAgICAgICstLXJ3IHByb3RvY29sDQoNCk15IHByb3Bv
c2FsIGlzIGhhdmUgZW5jb2RpbmcgYW5kIHByb3RvY29sIHRvZ2V0aGVyOg0KDQooQSkNCiAgICAg
ICstLXJ3IHN1YnNjcmlwdGlvbiogW2lkZW50aWZpZXJdDQogICAgICAgICAuLi4NCiAgICAgICAg
IC4uLg0KICAgICAgICAgKy0tcncgcmVjZWl2ZXJzDQogICAgICAgICAgICArLS1ydyByZWNlaXZl
ciogW2FkZHJlc3MgcG9ydF0NCiAgICAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgICAgKy0t
cncgcHJvdG9jb2wNCiAgICAgICAgICAgICAgICstLXJ3IGVuY29kaW5nDQoNCm9yOg0KDQooQikN
CiAgICAgICstLXJ3IHN1YnNjcmlwdGlvbiogW2lkZW50aWZpZXJdDQogICAgICAgICAuLi4NCiAg
ICAgICAgICstLXJ3IGVuY29kaW5nDQogICAgICAgICArLS1ydyBwcm90b2NvbA0KICAgICAgICAg
Li4uDQogICAgICAgICArLS1ydyByZWNlaXZlcnMNCiAgICAgICAgICAgICstLXJ3IHJlY2VpdmVy
KiBbYWRkcmVzcyBwb3J0XQ0KICAgICAgICAgICAgICAgLi4uDQoNCkkgdGhpbmsgdGhhdCB0aGlz
IGlzICpsZXNzKiBjb21wbGV4IGFuZCBwcm9iYWJseSBtb3JlIG9wdGltYWwgdGhhbiB0aGUNCmN1
cnJlbnQgc29sdXRpb24uDQoNCiJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikiIDxlaW5h
cm5uQGNpc2NvLmNvbT4gd3JvdGU6DQo+IE1hcnRpbiwNCj4gDQo+IEFzIHlldCwgd2UgaGF2ZSBu
byBwcmFjdGljYWwgdXNlIGNhc2VzIHdoZXJlIHdlIHdvdWxkIGhhdmUgYSBzaW5nbGUNCj4gY29u
ZmlndXJlZCBzdWJzY3JpcHRpb24gd2l0aCBtdWx0aXBsZSByZWNlaXZlcnMgd2hvIHdpc2ggdG8g
cmVjZWl2ZQ0KPiB0aGUgZGF0YSBpbiBkaWZmZXJlbnQgZm9ybWF0cy4gVGh1cyBzdXBwb3J0aW5n
IHRoaXMgc2VlbXMgbGlrZSBhbg0KPiB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IGZvciBwbGF0Zm9y
bXMsIGFuZCBvbmUgd2hpY2ggcG90ZW50aWFsbHkNCj4gaW1wYWN0cyBvcHRpbWlzYXRpb25zIHRo
YXQgd2UgYWxyZWFkeSB1c2UgaW4gc29tZSBwbGF0Zm9ybQ0KPiBpbXBsZW1lbnRhdGlvbnMgKGUu
Zy4gc2VuZGluZyB0aGUgc2FtZSBlbmNvZGVkIFBEVSB0byBtdWx0aXBsZQ0KPiByZWNlaXZlcnMs
IHJlbGlldmluZyB0aGUgcGxhdGZvcm0gb2YgZW5jb2RpbmcgdGhlIHNhbWUgZGF0YSBtdWx0aXBs
ZQ0KPiB3YXlzKS4NCg0KQnV0IHRoaXMgb3B0aW1pemF0aW9uIGRvZXNuJ3QgcmVhbGx5IHdvcmss
IGFzIHlvdSBub3RlIGJlbG93ICgqKS4NCg0KPiBPZiBjb3Vyc2UsIGlmIGEgY2xpZW50IHJlYWxs
eSB3YW50cyB0byBoYXZlIHRoZSBzYW1lIGRhdGEgc2VudCB0bw0KPiBtdWx0aXBsZSByZWNlaXZl
cnMgYnV0IGluIGRpZmZlcmVudCBmb3JtYXRzLCB0aGV5IGNhbiBkbyB0aGlzIOKAlCBqdXN0DQo+
IHByb3Zpc2lvbiBzZXBhcmF0ZSBzdWJzY3JpcHRpb25zIHdpdGggdGhlIHNhbWUgZmlsdGVyLg0K
DQpFeGFjdGx5OyB0aGlzIGlzIG1vcmUgY29tcGxleCBhbmQgbGVzcyBvcHRpbWFsIHNpbmNlIHRo
ZSBzYW1lIGZpbHRlcg0KbWlnaHQgYmUgZXZhbHVhdGVkIHR3aWNlLCB1bmxlc3MgeW91IGFkZCBj
b2RlIHRvIG9wdGltaXplIGZvciB0aGF0DQood2hpY2ggcHJvYmFibHkgZmFsbHMgaW4geW91ciBj
YXRlZ29yeSBvZiAidW5uZWNlc3NhcnkgY29tcGxleGl0eSIpLg0KDQooKikgU28gaWYgdGhlIG9w
ZXJhdG9yIHJlcXVpcmVzIHRoaXMgc2V0dXAsIGhlIHdpbGwgaGF2ZSB0byBjb25maWd1cmUNCnR3
byBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucyB0b2RheS4gIFRodXMsIHRoZSBwbGF0Zm9ybSB3aWxs
IGVuY29kZSB0aGUNCmRhdGEgdHdpY2UsIGFuZCB5b3VyIG9wdGltaXphdGlvbiBhYm92ZSB3b24n
dCBoZWxwLg0KDQo+IEFsbC1pbi1hbGwsIEkgZG9u4oCZdCBzZWUgYW55IGJlbmVmaXQgaW4gbWFr
aW5nIHRoZSBiYXNlIG1vZGVsIHN1cHBvcnQNCj4gdGhpcywgb25seSBkb3duc2lkZXMsIHNvIGRv
IHlvdSBoYXZlIGFueSBzcGVjaWZpYyB1c2UgY2FzZXMgaW4gbWluZA0KPiB3aGVyZSB0aGlzIHdv
dWxkIGJlIGEgYmVuZWZpdD8gU28gZmFyIGluIHRoZSB1c2UgY2FzZXMgd2UgaGF2ZSBsb29rZWQN
Cj4gYXQgaW4gU1AsIERDLCBlbnRlcnByaXNlIGFuZCBJb1Qgd2UgaGF2ZSBub3Qgc2VlbiBhbnkg
cmVxdWlyZW1lbnQgdG8NCj4gc3VwcG9ydCB0aGlzLCBidXQgd2UgaGF2ZSBzZWVuIHRoZSBuZWVk
IGZvciBtdWx0aXBsZSByZWNlaXZlcnMNCj4gKGUuZy4gdG8gc3VwcG9ydCBIQS9yZWR1bmRhbmN5
IGFwcHJvYWNoZXMpLg0KDQpUaGUgY3VycmVudCBtb2RlbCBzdXBwb3J0cyBkaWZmZXJlbnQgKnBy
b3RvY29scyogZm9yIHRoZSBkaWZmZXJlbnQNCnJlY2VpdmVycy4gIERvIHlvdSBoYXZlIGEgdXNl
IGNhc2Ugc3VwcG9ydGluZyB0aGF0LCBvciB3b3VsZCAoQikgYWJvdmUNCmZ1bGZpbCB5b3VyIHJl
cXVpcmVtZW50cy4NCg0KDQovbWFydGluDQoNCg0KDQo+IEFzIHN1Y2gsIEkgd291bGQgYmUNCj4g
cmVsdWN0YW50IHRvIGFkZCB0aGlzIHRvIHRoZSBkcmFmdCBhdCB0aGlzIHN0YWdlIHdoZW4gdGhl
DQo+IGZ1bmN0aW9uYWxpdHkgY2FuIGJlIGFjaGlldmVkIGFscmVhZHkgaWYgYWJzb2x1dGVseSBu
ZWNlc3NhcnkuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBFaW5hcg0KPiANCj4gDQo+ID4gT24gMTUg
Tm92IDIwMTcsIGF0IDIxOjUzLCBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPiB3
cm90ZToNCj4gPiANCj4gPiBBZGRpbmcgRWluYXIgYXMgaGUgaGFkIHNvbWUgc3Ryb25nIG9waW5p
b25zIG9uIHRoaXMgYSBmZXcgeWVhcnMgYWdvDQo+ID4gd2hlbiB3ZSB3ZXJlIHNldHRpbmcgdGhl
IG1vZGVsLi4uDQo+ID4gDQo+ID4gDQo+ID4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQsIE5vdmVt
YmVyIDE1LCAyMDE3IDEwOjQzIEFNDQo+ID4+IA0KPiA+PiAiRXJpYyBWb2l0IChldm9pdCkiIDxl
dm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4gSGkgTWFydGluLA0KPiA+Pj4gDQo+ID4+Pj4g
RnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXQ0KPiA+Pj4+IA0K
PiA+Pj4+ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+
Pj4+IEluIHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBnZXQgImh1bSBm
ZWVkYmFjayIgb246DQo+ID4+Pj4+IA0KPiA+Pj4+PiANCj4gPj4+Pj4gDQo+ID4+Pj4+IGRyYWZ0
LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCj4gPj4+Pj4gDQo+ID4+Pj4+
IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVzLzQNCj4gPj4+
Pj4gDQo+ID4+Pj4+IA0KPiA+Pj4+PiANCj4gPj4+Pj4gVGhlIHR3byBjaG9pY2VzIGFuZCB0aGVp
ciBpc3N1ZXMgZXhwb3NlZCBkdXJpbmcgdGhlIHR3byB3ZWVrDQo+ID4+Pj4+IHJldmlldyBvbg0K
PiA+Pj4+ICJDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVudCByZWNlaXZlcnMgb2Yg
YSBzaW5nbGUNCj4gPj4+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8iIGFyZToNCj4gPj4+Pj4g
DQo+ID4+Pj4+IA0KPiA+Pj4+PiANCj4gPj4+Pj4gKDEpIFllcywgVHJhbnNwb3J0IGNhbiB2YXJ5
IGJ5IHJlY2VpdmVyDQo+ID4+Pj4+IA0KPiA+Pj4+PiAqICAgICAgICBGZXdlciBzdWJzY3JpcHRp
b25zIChzY2FsZSBiZW5lZml0KQ0KPiA+Pj4+PiANCj4gPj4+Pj4gKiAgICAgICAgQ2FuIGNvbnZl
cnQgdHJhbnNwb3J0IHdpdGhvdXQgcmVxdWlyaW5nIGFuIGFwcGxpY2F0aW9uIHRvIGxlYXJuDQo+
ID4+IGENCj4gPj4+PiBtdWx0aXBsZSBzdWJzY3JpcHRpb24gaWRzDQo+ID4+Pj4+IA0KPiA+Pj4+
PiAqICAgICAgICBObyBkdXBsaWNhdGlvbiBvZiBjb250ZW50IGR1cmluZyB0cmFuc3BvcnQgY29u
dmVyc2lvbi4NCj4gPj4+Pj4gDQo+ID4+Pj4+ICogICAgICAgIChQb3RlbnRpYWwgY29uZnVzaW9u
IGluIGFsbG93aW5nIHRyYW5zcG9ydCB0byB2YXJ5LCBidXQNCj4gPj4+Pj4gKiAgICAgICAgZW5j
b2RpbmcNCj4gPj4gbm90DQo+ID4+Pj4gdG8gdmFyeT8pDQo+ID4+Pj4+IA0KPiA+Pj4+PiANCj4g
Pj4+Pj4gDQo+ID4+Pj4+ICgyKSBObywgb25seSBvbmUgVHJhbnNwb3J0IGFjcm9zcyBhbGwgc3Vi
c2NyaXB0aW9ucw0KPiA+Pj4+PiANCj4gPj4+Pj4gKiAgICAgICAgU2ltcGxlciBtb2RlbA0KPiA+
Pj4+PiANCj4gPj4+Pj4gKiAgICAgICAgQnV0IGFwcGxpY2F0aW9ucyBtYXkgbmVlZCB0byBjcmVh
dGUgYW5kIHRyYWNrIG11bHRpcGxlDQo+ID4+Pj4gc3Vic2NyaXB0aW9uLWlkcyBmb3IgdGhlIHNh
bWUgY29udGVudC4NCj4gPj4+Pj4gDQo+ID4+Pj4+ICogICAgICAgIFRlbXBvcmFyeSBkdXBsaWNh
dGlvbiBvZiBjb250ZW50IHN0cmVhbXMgZHVyaW5nIHRyYW5zcG9ydA0KPiA+PiBjaGFuZ2UuDQo+
ID4+Pj4+IA0KPiA+Pj4+PiANCj4gPj4+Pj4gDQo+ID4+Pj4+IFRoZSBjdXJyZW50IGRyYWZ0IGRv
ZXMgKDEpLg0KPiA+Pj4+IA0KPiA+Pj4+IEFjdHVhbGx5LCB0aGUgZ2l0aHViIGlzc3VlIGxpc3Rz
IDMgb3B0aW9ucywgYnV0IGhlcmUgeW91IGp1c3QgbGlzdCAyLg0KPiA+Pj4gDQo+ID4+PiBJbiBy
ZXZpZXdpbmcgdG9tb3Jyb3cncyBzbGlkZXMgd2l0aCBNYWhlc2gsIGhlIHByZWZlcnJlZCAyIG9w
dGlvbnMuDQo+ID4+PiBBbmQgYXMgdmFyeWluZyB0aGUgZW5jb2RpbmcgYnkgcmVjZWl2ZXIgc2Vl
bXMgdW5saWtlbHkgaW4NCj4gPj4+IGltcGxlbWVudGF0aW9uDQo+ID4+IA0KPiA+PiBXaHkgaXMg
dGhpcyB1bmxpa2VseT8gIFN1cHBvc2UgSSBoYXZlIHR3byByZWNlaXZlcnMgZm9yIHRoZSBzYW1l
DQo+ID4+IHN1YnNjcmlwdGlvbiwgb25lIHdhbnRzIE5FVENPTkYvWE1MIGFuZCB0aGUgb3RoZXIg
UkVTVENPTkYvSlNPTi4gIElzDQo+ID4+IHRoYXQgdW5saWtlbHk/DQo+ID4gDQo+ID4gRWluYXIn
cyBiZWxpZWYgd2FzIHRoYXQgYSBwdWJsaXNoZXIgaW1wbGVtZW50YXRpb24gd291bGQgYmUgdW5s
aWtlbHkNCj4gPiB0byBzZXJ2aWNlIGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBpbnRvIG11bHRpcGxl
IGVuY29kaW5ncy4gIElmIHN1Y2ggYQ0KPiA+IGNvbmRpdGlvbiBleGlzdGVkLCBpdCB3b3VsZCBi
ZSBmYXIgZWFzaWVyIHRvIGNyZWF0ZSB0d28gc3Vic2NyaXB0aW9ucy4NCj4gPiBUaGlzIGFsc28g
d291bGQgaGF2ZSBmZXdlciBlcnJvciBjb25kaXRpb25zLg0KPiA+IA0KPiA+Pj4gLCB0aGVyZSBp
cyBsaXR0bGUgcmVhc29uIHRvIHNvY2lhbGl6ZSB0aGlzIHVubGlrZWx5IHZhcmlhbnQgYmVmb3Jl
DQo+ID4+PiB0aGUgd2hvbGUgV0cuICAgU2luY2UgYXMgeW91ciBvcGluaW9uIHdhcyBlaXRoZXIg
Ym90aCBlbmNvZGluZyBhbmQNCj4gPj4+IHRyYW5zcG9ydCBvciBuZWl0aGVyIGVuY29kaW5nIGFu
ZCB0cmFuc3BvcnQgdmFyeSBieSByZWNlaXZlciwgdGhlIG1vcmUNCj4gPj4+IGxpa2VseSBvZiB5
b3VyIHByaW1hcnkgYXNrIGlzIHN1cHBvcnRlZC4NCj4gPj4+IA0KPiA+Pj4gDQo+ID4+Pj4gSSB0
aGluayB0aGUgcG9pbnQgaXMgdGhhdCBpbiB0aGUgdGVybSAiVHJhbnNwb3J0Iiwgd2UgbmVlZCB0
bw0KPiA+Pj4+IGluY2x1ZGUgYm90aCBwcm90b2NvbCBhbmQgZW5jb2RpbmcgKGluIHRoZSBjYXNl
IHRoZSBwcm90b2NvbA0KPiA+Pj4+IHN1cHBvcnRzIG11bHRpcGxlIGVuY29kaW5ncykuDQo+ID4+
PiANCj4gPj4+IFdoaWxlIG1vc3QgbGlrZWx5IHRoZSBjYXNlIGZvciBORVRDT05GIGFuZCBSRVNU
Q09ORiwgVGlhbnJhbidzDQo+ID4+PiBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVs
IHNob3dzIHRoYXQgdGhlcmUgY2FuIGJlIGVuY29kaW5nDQo+ID4+PiB2YXJpYXRpb24gYnkgdHJh
bnNwb3J0cyAuICAgSXQgVGhlcmVmb3JlIGl0IHNlZW1zIGJldHRlciB0byBsZXQgdGhlbQ0KPiA+
Pj4gYm90aCB2YXJ5IGluZGVwZW5kZW50bHkuDQo+ID4+IA0KPiA+PiBOb3Qgc3VyZSBJIHVuZGVy
c3RhbmQgd2hhdCB5b3UgbWVhbi4gIFRvIGJlIGNsZWFyLCBkbyB5b3UgdGhpbmsgdGhlDQo+ID4+
ICJlbmNvZGluZyIgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBpcywgb3IgYmUgbW92ZWQgZG93
biB0byB0aGUNCj4gPj4gcmVjZWl2ZXIsDQo+ID4+IGFzIGEgc2libGluZyB0byAicHJvdG9jb2wi
Pw0KPiA+IA0KPiA+IEVuY29kaW5nIGxlYWYgc2hvdWxkIHN0YXkgd2hlcmUgaXQgaXMuICBZb3Vy
IHByZXZpb3VzIGFzayB3YXMgdG8gcHV0DQo+ID4gZW5jb2RpbmcgYW5kIHRyYW5zcG9ydCBhbmQg
dGhlIHNhbWUgbGV2ZWwuIFRoZXJlIGlzIGFuIG9wdGlvbiBwcm9wb3NlZA0KPiA+IGluIHRoZSBz
bGlkZXMgd2hpY2ggZG9lcyB0aGF0Lg0KPiA+IA0KPiA+IEVyaWMNCj4gPiANCj4gPj4gL21hcnRp
bg0KPiA+IA0KPiANCg==


From nobody Thu Nov 16 00:20:37 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8875012955D for ; Thu, 16 Nov 2017 00:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level: 
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 OGDdX5naYjE8 for ; Thu, 16 Nov 2017 00:20:34 -0800 (PST)
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 36CC8129465 for ; Thu, 16 Nov 2017 00:20:33 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.139.117; 
From: "Susan Hares" 
To: "'Balazs Lengyel'" , 
References:  
In-Reply-To: 
Date: Thu, 16 Nov 2017 03:20:28 -0500
Message-ID: <000901d35eb3$c48258b0$4d870a10$@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: AQKl3CHTmaVTkUALcXZTreO85ODc3QMTsNAmoVkRCOA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 08:20:35 -0000

Balazs and netconf:

I hoped to be at netconf and say this in person.  The design team allowed me
to be an I2RS WG chair observer and commenter.  Like Balazs, I'm happy with
the results.   It's running in code.  We're seeing it starting to go to
different types of boxes - security and routing as well as management.

Sue Hares 

-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel
Sent: Wednesday, November 15, 2017 11:38 PM
To: netconf@ietf.org
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push

Hello,

I have been part of the design team and I am mostly happy with the results.
I would like to see the drafts progress as soon as possible.

regards Balazs

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

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


From nobody Thu Nov 16 00:30:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E77129566 for ; Thu, 16 Nov 2017 00:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4lDURZJ_cxN for ; Thu, 16 Nov 2017 00:30:23 -0800 (PST)
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 00716127444 for ; Thu, 16 Nov 2017 00:30:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10498; q=dns/txt; s=iport; t=1510821023; x=1512030623; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZP0VwoxCabDARUHDzlx4NR1KUwgwrqNYEruYacgeQYE=; b=Ka0l4as48tDou480fc4F6kZup7EUCize2K4GgwzqUTijVsNu+Q0EECro PbeLbmqeqbFtAtR+B+R3uSSce2wYH3qjQadxSZy5iNM4cfTFrDtOMcIpn ZSl2lOMsAzuJdxufXF/HAMFHuf8lBvemnMBjAwdIYim4igB1W0v/tUyx6 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAABCTA1a/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB4N4ih+PIIF9ll4QggEKI4UYAhqEej8YAQEBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQEDIxFABQwEAgEIDgMEAQEBAgIJFgQDAgICMBQBCAgCBAENBQgTi?= =?us-ascii?q?gkQqUWCJ4sUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IlggeBVYUThQAvgn6?= =?us-ascii?q?CYwWiNwKHa40Qk02Mb4kSAhEZAYE4AR84gXR6FUmCZIMRgU53iGgrgQiBEQEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208";a="31654552"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 08:30:22 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAG8ULQn000805 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 08:30:21 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 03:30:21 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 03:30:20 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund , "Einar Nilsen-Nygaard (einarnn)" 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFwAA3K+YAAEmKugAAKViNQ
Date: Thu, 16 Nov 2017 08:30:20 +0000
Message-ID: 
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com> <20171116.085331.436907075368637840.mbj@tail-f.com>
In-Reply-To: <20171116.085331.436907075368637840.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.68.216.199]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 08:30:27 -0000

SGkgTWFydGluLA0KDQpZZXMsIEkgb3JpZ2luYWxseSBoYWQgYm90aCB5b3VyIG9wdGlvbnMgaW4g
dGhlIFdHIHNsaWRlcy4gICAgSSByZW1vdmVkIChBKSBhZnRlciBkaXNjdXNzaW9uIHdpdGggTWFo
ZXNoIGZvciB0aGUgV0cgc2Vzc2lvbiBzbGlkZXMgdG8gc2ltcGxpZnkgdGhlIGluLXJvb20gZGlz
Y3Vzc2lvbnMsIGFzIHdlbGwgYXMgY29uc2lkZXJhdGlvbiBvZiB0aGUgcG9pbnRzIEVpbmFyIG1h
a2VzIGJlbG93LiAgV2UgY2FuIG9mIGNvdXJzZSBoYXZlIG1vcmUgYW5kIGRlZXBlciByZXNvbHV0
aW9uIGRpc2N1c3Npb25zIGhlcmUuDQoNClRoYW5rcywNCkVyaWMNCg0KPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwt
Zi5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNyAyOjU0IEFNDQo+IFRv
OiBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgPGVpbmFybm5AY2lzY28uY29tPg0KPiBD
YzogRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcN
Cj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNDogQ2FuIFRyYW5zcG9ydCB2YXJ5
IGFjcm9zcyBkaWZmZXJlbnQNCj4gcmVjZWl2ZXJzIG9mIGEgc2luZ2xlIGNvbmZpZ3VyZWQgc3Vi
c2NyaXB0aW9uPw0KPiANCj4gSGksDQo+IA0KPiBOb3RlIHRoYXQgdGhlIGlzc3VlIGlzIHRoYXQg
dGhlIGN1cnJlbnQgbW9kZWwgaGFzOg0KPiANCj4gICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBb
aWRlbnRpZmllcl0NCj4gICAgICAgICAgLi4uDQo+ICAgICAgICAgICstLXJ3IGVuY29kaW5nDQo+
ICAgICAgICAgIC4uLg0KPiAgICAgICAgICArLS1ydyByZWNlaXZlcnMNCj4gICAgICAgICAgICAg
Ky0tcncgcmVjZWl2ZXIqIFthZGRyZXNzIHBvcnRdDQo+ICAgICAgICAgICAgICAgIC4uLg0KPiAg
ICAgICAgICAgICAgICArLS1ydyBwcm90b2NvbA0KPiANCj4gTXkgcHJvcG9zYWwgaXMgaGF2ZSBl
bmNvZGluZyBhbmQgcHJvdG9jb2wgdG9nZXRoZXI6DQo+IA0KPiAoQSkNCj4gICAgICAgKy0tcncg
c3Vic2NyaXB0aW9uKiBbaWRlbnRpZmllcl0NCj4gICAgICAgICAgLi4uDQo+ICAgICAgICAgIC4u
Lg0KPiAgICAgICAgICArLS1ydyByZWNlaXZlcnMNCj4gICAgICAgICAgICAgKy0tcncgcmVjZWl2
ZXIqIFthZGRyZXNzIHBvcnRdDQo+ICAgICAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICAgICAg
ICArLS1ydyBwcm90b2NvbA0KPiAgICAgICAgICAgICAgICArLS1ydyBlbmNvZGluZw0KPiANCj4g
b3I6DQo+IA0KPiAoQikNCj4gICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBbaWRlbnRpZmllcl0N
Cj4gICAgICAgICAgLi4uDQo+ICAgICAgICAgICstLXJ3IGVuY29kaW5nDQo+ICAgICAgICAgICst
LXJ3IHByb3RvY29sDQo+ICAgICAgICAgIC4uLg0KPiAgICAgICAgICArLS1ydyByZWNlaXZlcnMN
Cj4gICAgICAgICAgICAgKy0tcncgcmVjZWl2ZXIqIFthZGRyZXNzIHBvcnRdDQo+ICAgICAgICAg
ICAgICAgIC4uLg0KPiANCj4gSSB0aGluayB0aGF0IHRoaXMgaXMgKmxlc3MqIGNvbXBsZXggYW5k
IHByb2JhYmx5IG1vcmUgb3B0aW1hbCB0aGFuIHRoZQ0KPiBjdXJyZW50IHNvbHV0aW9uLg0KPiAN
Cj4gIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSIgPGVpbmFybm5AY2lzY28uY29tPiB3
cm90ZToNCj4gPiBNYXJ0aW4sDQo+ID4NCj4gPiBBcyB5ZXQsIHdlIGhhdmUgbm8gcHJhY3RpY2Fs
IHVzZSBjYXNlcyB3aGVyZSB3ZSB3b3VsZCBoYXZlIGEgc2luZ2xlDQo+ID4gY29uZmlndXJlZCBz
dWJzY3JpcHRpb24gd2l0aCBtdWx0aXBsZSByZWNlaXZlcnMgd2hvIHdpc2ggdG8gcmVjZWl2ZQ0K
PiA+IHRoZSBkYXRhIGluIGRpZmZlcmVudCBmb3JtYXRzLiBUaHVzIHN1cHBvcnRpbmcgdGhpcyBz
ZWVtcyBsaWtlIGFuDQo+ID4gdW5uZWNlc3NhcnkgY29tcGxleGl0eSBmb3IgcGxhdGZvcm1zLCBh
bmQgb25lIHdoaWNoIHBvdGVudGlhbGx5DQo+ID4gaW1wYWN0cyBvcHRpbWlzYXRpb25zIHRoYXQg
d2UgYWxyZWFkeSB1c2UgaW4gc29tZSBwbGF0Zm9ybQ0KPiA+IGltcGxlbWVudGF0aW9ucyAoZS5n
LiBzZW5kaW5nIHRoZSBzYW1lIGVuY29kZWQgUERVIHRvIG11bHRpcGxlDQo+ID4gcmVjZWl2ZXJz
LCByZWxpZXZpbmcgdGhlIHBsYXRmb3JtIG9mIGVuY29kaW5nIHRoZSBzYW1lIGRhdGEgbXVsdGlw
bGUNCj4gPiB3YXlzKS4NCj4gDQo+IEJ1dCB0aGlzIG9wdGltaXphdGlvbiBkb2Vzbid0IHJlYWxs
eSB3b3JrLCBhcyB5b3Ugbm90ZSBiZWxvdyAoKikuDQo+IA0KPiA+IE9mIGNvdXJzZSwgaWYgYSBj
bGllbnQgcmVhbGx5IHdhbnRzIHRvIGhhdmUgdGhlIHNhbWUgZGF0YSBzZW50IHRvDQo+ID4gbXVs
dGlwbGUgcmVjZWl2ZXJzIGJ1dCBpbiBkaWZmZXJlbnQgZm9ybWF0cywgdGhleSBjYW4gZG8gdGhp
cyDigJQganVzdA0KPiA+IHByb3Zpc2lvbiBzZXBhcmF0ZSBzdWJzY3JpcHRpb25zIHdpdGggdGhl
IHNhbWUgZmlsdGVyLg0KPiANCj4gRXhhY3RseTsgdGhpcyBpcyBtb3JlIGNvbXBsZXggYW5kIGxl
c3Mgb3B0aW1hbCBzaW5jZSB0aGUgc2FtZSBmaWx0ZXIgbWlnaHQgYmUNCj4gZXZhbHVhdGVkIHR3
aWNlLCB1bmxlc3MgeW91IGFkZCBjb2RlIHRvIG9wdGltaXplIGZvciB0aGF0ICh3aGljaCBwcm9i
YWJseQ0KPiBmYWxscyBpbiB5b3VyIGNhdGVnb3J5IG9mICJ1bm5lY2Vzc2FyeSBjb21wbGV4aXR5
IikuDQo+IA0KPiAoKikgU28gaWYgdGhlIG9wZXJhdG9yIHJlcXVpcmVzIHRoaXMgc2V0dXAsIGhl
IHdpbGwgaGF2ZSB0byBjb25maWd1cmUgdHdvDQo+IGRpZmZlcmVudCBzdWJzY3JpcHRpb25zIHRv
ZGF5LiAgVGh1cywgdGhlIHBsYXRmb3JtIHdpbGwgZW5jb2RlIHRoZSBkYXRhDQo+IHR3aWNlLCBh
bmQgeW91ciBvcHRpbWl6YXRpb24gYWJvdmUgd29uJ3QgaGVscC4NCj4gDQo+ID4gQWxsLWluLWFs
bCwgSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiBtYWtpbmcgdGhlIGJhc2UgbW9kZWwgc3Vw
cG9ydA0KPiA+IHRoaXMsIG9ubHkgZG93bnNpZGVzLCBzbyBkbyB5b3UgaGF2ZSBhbnkgc3BlY2lm
aWMgdXNlIGNhc2VzIGluIG1pbmQNCj4gPiB3aGVyZSB0aGlzIHdvdWxkIGJlIGEgYmVuZWZpdD8g
U28gZmFyIGluIHRoZSB1c2UgY2FzZXMgd2UgaGF2ZSBsb29rZWQNCj4gPiBhdCBpbiBTUCwgREMs
IGVudGVycHJpc2UgYW5kIElvVCB3ZSBoYXZlIG5vdCBzZWVuIGFueSByZXF1aXJlbWVudCB0bw0K
PiA+IHN1cHBvcnQgdGhpcywgYnV0IHdlIGhhdmUgc2VlbiB0aGUgbmVlZCBmb3IgbXVsdGlwbGUg
cmVjZWl2ZXJzIChlLmcuDQo+ID4gdG8gc3VwcG9ydCBIQS9yZWR1bmRhbmN5IGFwcHJvYWNoZXMp
Lg0KPiANCj4gVGhlIGN1cnJlbnQgbW9kZWwgc3VwcG9ydHMgZGlmZmVyZW50ICpwcm90b2NvbHMq
IGZvciB0aGUgZGlmZmVyZW50DQo+IHJlY2VpdmVycy4gIERvIHlvdSBoYXZlIGEgdXNlIGNhc2Ug
c3VwcG9ydGluZyB0aGF0LCBvciB3b3VsZCAoQikgYWJvdmUgZnVsZmlsDQo+IHlvdXIgcmVxdWly
ZW1lbnRzLg0KPiANCj4gDQo+IC9tYXJ0aW4NCj4gDQo+IA0KPiANCj4gPiBBcyBzdWNoLCBJIHdv
dWxkIGJlDQo+ID4gcmVsdWN0YW50IHRvIGFkZCB0aGlzIHRvIHRoZSBkcmFmdCBhdCB0aGlzIHN0
YWdlIHdoZW4gdGhlDQo+ID4gZnVuY3Rpb25hbGl0eSBjYW4gYmUgYWNoaWV2ZWQgYWxyZWFkeSBp
ZiBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS4NCj4gPg0KPiA+IENoZWVycywNCj4gPg0KPiA+IEVpbmFy
DQo+ID4NCj4gPg0KPiA+ID4gT24gMTUgTm92IDIwMTcsIGF0IDIxOjUzLCBFcmljIFZvaXQgKGV2
b2l0KSA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBBZGRpbmcgRWluYXIg
YXMgaGUgaGFkIHNvbWUgc3Ryb25nIG9waW5pb25zIG9uIHRoaXMgYSBmZXcgeWVhcnMgYWdvDQo+
ID4gPiB3aGVuIHdlIHdlcmUgc2V0dGluZyB0aGUgbW9kZWwuLi4NCj4gPiA+DQo+ID4gPg0KPiA+
ID4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQsIE5vdmVtYmVyIDE1LCAyMDE3IDEwOjQzIEFNDQo+
ID4gPj4NCj4gPiA+PiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3Rl
Og0KPiA+ID4+PiBIaSBNYXJ0aW4sDQo+ID4gPj4+DQo+ID4gPj4+PiBGcm9tOiBNYXJ0aW4gQmpv
cmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21dDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gIkVyaWMg
Vm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+Pj4+PiBJbiB0aGUg
V0cgc2Vzc2lvbiB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8gZ2V0ICJodW0gZmVlZGJhY2siDQo+
IG9uOg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IGRyYWZ0LWll
dGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+
IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVzLzQNCj4gPiA+
Pj4+Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGUgdHdvIGNob2ljZXMgYW5k
IHRoZWlyIGlzc3VlcyBleHBvc2VkIGR1cmluZyB0aGUgdHdvIHdlZWsNCj4gPiA+Pj4+PiByZXZp
ZXcgb24NCj4gPiA+Pj4+ICJDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVudCByZWNl
aXZlcnMgb2YgYSBzaW5nbGUNCj4gPiA+Pj4+IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPyIgYXJl
Og0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICgxKSBZZXMsIFRy
YW5zcG9ydCBjYW4gdmFyeSBieSByZWNlaXZlcg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gKiAgICAg
ICAgRmV3ZXIgc3Vic2NyaXB0aW9ucyAoc2NhbGUgYmVuZWZpdCkNCj4gPiA+Pj4+Pg0KPiA+ID4+
Pj4+ICogICAgICAgIENhbiBjb252ZXJ0IHRyYW5zcG9ydCB3aXRob3V0IHJlcXVpcmluZyBhbiBh
cHBsaWNhdGlvbiB0bw0KPiBsZWFybg0KPiA+ID4+IGENCj4gPiA+Pj4+IG11bHRpcGxlIHN1YnNj
cmlwdGlvbiBpZHMNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICogICAgICAgIE5vIGR1cGxpY2F0aW9u
IG9mIGNvbnRlbnQgZHVyaW5nIHRyYW5zcG9ydCBjb252ZXJzaW9uLg0KPiA+ID4+Pj4+DQo+ID4g
Pj4+Pj4gKiAgICAgICAgKFBvdGVudGlhbCBjb25mdXNpb24gaW4gYWxsb3dpbmcgdHJhbnNwb3J0
IHRvIHZhcnksIGJ1dA0KPiA+ID4+Pj4+ICogICAgICAgIGVuY29kaW5nDQo+ID4gPj4gbm90DQo+
ID4gPj4+PiB0byB2YXJ5PykNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+
Pj4+PiAoMikgTm8sIG9ubHkgb25lIFRyYW5zcG9ydCBhY3Jvc3MgYWxsIHN1YnNjcmlwdGlvbnMN
Cj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICogICAgICAgIFNpbXBsZXIgbW9kZWwNCj4gPiA+Pj4+Pg0K
PiA+ID4+Pj4+ICogICAgICAgIEJ1dCBhcHBsaWNhdGlvbnMgbWF5IG5lZWQgdG8gY3JlYXRlIGFu
ZCB0cmFjayBtdWx0aXBsZQ0KPiA+ID4+Pj4gc3Vic2NyaXB0aW9uLWlkcyBmb3IgdGhlIHNhbWUg
Y29udGVudC4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICogICAgICAgIFRlbXBvcmFyeSBkdXBsaWNh
dGlvbiBvZiBjb250ZW50IHN0cmVhbXMgZHVyaW5nIHRyYW5zcG9ydA0KPiA+ID4+IGNoYW5nZS4N
Cj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGUgY3VycmVudCBk
cmFmdCBkb2VzICgxKS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBBY3R1YWxseSwgdGhlIGdpdGh1YiBp
c3N1ZSBsaXN0cyAzIG9wdGlvbnMsIGJ1dCBoZXJlIHlvdSBqdXN0IGxpc3QgMi4NCj4gPiA+Pj4N
Cj4gPiA+Pj4gSW4gcmV2aWV3aW5nIHRvbW9ycm93J3Mgc2xpZGVzIHdpdGggTWFoZXNoLCBoZSBw
cmVmZXJyZWQgMiBvcHRpb25zLg0KPiA+ID4+PiBBbmQgYXMgdmFyeWluZyB0aGUgZW5jb2Rpbmcg
YnkgcmVjZWl2ZXIgc2VlbXMgdW5saWtlbHkgaW4NCj4gPiA+Pj4gaW1wbGVtZW50YXRpb24NCj4g
PiA+Pg0KPiA+ID4+IFdoeSBpcyB0aGlzIHVubGlrZWx5PyAgU3VwcG9zZSBJIGhhdmUgdHdvIHJl
Y2VpdmVycyBmb3IgdGhlIHNhbWUNCj4gPiA+PiBzdWJzY3JpcHRpb24sIG9uZSB3YW50cyBORVRD
T05GL1hNTCBhbmQgdGhlIG90aGVyDQo+IFJFU1RDT05GL0pTT04uDQo+ID4gPj4gSXMgdGhhdCB1
bmxpa2VseT8NCj4gPiA+DQo+ID4gPiBFaW5hcidzIGJlbGllZiB3YXMgdGhhdCBhIHB1Ymxpc2hl
ciBpbXBsZW1lbnRhdGlvbiB3b3VsZCBiZSB1bmxpa2VseQ0KPiA+ID4gdG8gc2VydmljZSBhIHNp
bmdsZSBzdWJzY3JpcHRpb24gaW50byBtdWx0aXBsZSBlbmNvZGluZ3MuICBJZiBzdWNoIGENCj4g
PiA+IGNvbmRpdGlvbiBleGlzdGVkLCBpdCB3b3VsZCBiZSBmYXIgZWFzaWVyIHRvIGNyZWF0ZSB0
d28gc3Vic2NyaXB0aW9ucy4NCj4gPiA+IFRoaXMgYWxzbyB3b3VsZCBoYXZlIGZld2VyIGVycm9y
IGNvbmRpdGlvbnMuDQo+ID4gPg0KPiA+ID4+PiAsIHRoZXJlIGlzIGxpdHRsZSByZWFzb24gdG8g
c29jaWFsaXplIHRoaXMgdW5saWtlbHkgdmFyaWFudCBiZWZvcmUNCj4gPiA+Pj4gdGhlIHdob2xl
IFdHLiAgIFNpbmNlIGFzIHlvdXIgb3BpbmlvbiB3YXMgZWl0aGVyIGJvdGggZW5jb2RpbmcgYW5k
DQo+ID4gPj4+IHRyYW5zcG9ydCBvciBuZWl0aGVyIGVuY29kaW5nIGFuZCB0cmFuc3BvcnQgdmFy
eSBieSByZWNlaXZlciwgdGhlDQo+ID4gPj4+IG1vcmUgbGlrZWx5IG9mIHlvdXIgcHJpbWFyeSBh
c2sgaXMgc3VwcG9ydGVkLg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+Pj4gSSB0aGluayB0aGUg
cG9pbnQgaXMgdGhhdCBpbiB0aGUgdGVybSAiVHJhbnNwb3J0Iiwgd2UgbmVlZCB0bw0KPiA+ID4+
Pj4gaW5jbHVkZSBib3RoIHByb3RvY29sIGFuZCBlbmNvZGluZyAoaW4gdGhlIGNhc2UgdGhlIHBy
b3RvY29sDQo+ID4gPj4+PiBzdXBwb3J0cyBtdWx0aXBsZSBlbmNvZGluZ3MpLg0KPiA+ID4+Pg0K
PiA+ID4+PiBXaGlsZSBtb3N0IGxpa2VseSB0aGUgY2FzZSBmb3IgTkVUQ09ORiBhbmQgUkVTVENP
TkYsIFRpYW5yYW4ncw0KPiA+ID4+PiBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVs
IHNob3dzIHRoYXQgdGhlcmUgY2FuIGJlIGVuY29kaW5nDQo+ID4gPj4+IHZhcmlhdGlvbiBieSB0
cmFuc3BvcnRzIC4gICBJdCBUaGVyZWZvcmUgaXQgc2VlbXMgYmV0dGVyIHRvIGxldCB0aGVtDQo+
ID4gPj4+IGJvdGggdmFyeSBpbmRlcGVuZGVudGx5Lg0KPiA+ID4+DQo+ID4gPj4gTm90IHN1cmUg
SSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4uICBUbyBiZSBjbGVhciwgZG8geW91IHRoaW5rIHRo
ZQ0KPiA+ID4+ICJlbmNvZGluZyIgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBpcywgb3IgYmUg
bW92ZWQgZG93biB0byB0aGUNCj4gPiA+PiByZWNlaXZlciwgYXMgYSBzaWJsaW5nIHRvICJwcm90
b2NvbCI/DQo+ID4gPg0KPiA+ID4gRW5jb2RpbmcgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBp
cy4gIFlvdXIgcHJldmlvdXMgYXNrIHdhcyB0byBwdXQNCj4gPiA+IGVuY29kaW5nIGFuZCB0cmFu
c3BvcnQgYW5kIHRoZSBzYW1lIGxldmVsLiBUaGVyZSBpcyBhbiBvcHRpb24NCj4gPiA+IHByb3Bv
c2VkIGluIHRoZSBzbGlkZXMgd2hpY2ggZG9lcyB0aGF0Lg0KPiA+ID4NCj4gPiA+IEVyaWMNCj4g
PiA+DQo+ID4gPj4gL21hcnRpbg0KPiA+ID4NCj4gPg0K


From nobody Thu Nov 16 02:11:32 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2F81201F2 for ; Thu, 16 Nov 2017 02:11:31 -0800 (PST)
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 pPdn0ge6pEbk for ; Thu, 16 Nov 2017 02:11:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 42CDE1200CF for ; Thu, 16 Nov 2017 02:11:27 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9592E1AE039A; Thu, 16 Nov 2017 11:11:25 +0100 (CET)
Date: Thu, 16 Nov 2017 11:10:02 +0100 (CET)
Message-Id: <20171116.111002.1638797974351963946.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <821e452591614d80a7405a0318e3d66a@XCH-RTP-013.cisco.com>
References: <821e452591614d80a7405a0318e3d66a@XCH-RTP-013.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: [Netconf] tRE: Martin's thoughts on subscribed-notifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:11:31 -0000

Hi,

"Eric Voit (evoit)"  wrote:
> Hi Martin,
> 
> Thanks for the suggestions.   In-line...
> 
> > From: Martin Bjorklund, November 15, 2017 2:33 PM
> > 
> > Hi,
> > 
> > I have reviewed draft-ietf-netconf-subscribed-notifications-07,
> > specifically to ensure that my earlier comments are addressed.  Here are my
> > new comments:
> > 
> > 
> > 
> > o  General
> > 
> >   The document uses the term "RPC" to refer to the operations that
> >   affect dynamic subscriptions.  I think that this term is not quite
> >   correct.  For example the text says:
> > 
> >       a configured subscription cannot be modified or deleted using
> >       RPC.
> > 
> >   But this is not correct, I can delete a configured subscription with
> >   the  rpc.
> 
> Will append the clarification:
> "using RPCs from the document."
> 
> > o  Section 1.2
> > 
> >   What is "RPC subscription state signaling messages"?
> 
> Will change "signaling messages" to  "Notifications".   In this case the notifications act as signaling messages.
> 
> > o  Section 2.2
> > 
> >      The subsets of these filtering syntaxes supported are
> >      left to each implementation.
> > 
> >    Juergen has already pointed out that this is not good design - how
> >    will the client know which subset of subtree filtering a certain
> >    device supports?   I think that if the server doesn't support
> >    subtree filtering as defined, then it should not advertise the
> >    "subtree" feature.  It can always advertise another feature.
> 
> Agree,  that was always the intent.  The words just need to match to that.  How about:
> " If [RFC6241] filtering is supported, the full set of Section 6 must be enabled.  If XPATH filtering is supported, the subset of XPATH functionality is left to the implementation "

The same argument applies to XPath.  How would this be interoperable
otherwise?  I suggest you simply remove the sentence

      The subsets of these filtering syntaxes supported are
      left to each implementation.

> > o  Section 2.3
> > 
> >   The state diagram shows an arrow "modify" from "suspended" to
> >   "active".  Is this really correct?  Will a suspended subscription be
> >   resumed if it is modified?  
> 
> Yes. 
> The subscription could immediately be suspended, but this reduces the available knobs.

How does it reduce the available knobs?  I was thinking that if a
modify-subscription rpc was sent to a suspended subscription, it
wouldn't by itself change the suspension status; if the server thinks
it can be resumed it will resume.

With the current solution, the server must send three notifications if
a suspended subscription is modified, and it is still suspended:

  subscription-modified
  subscription-resumed
  subscription-suspended


> > If so, this is not correct:
> >     o  Suspend and resume state changes are driven by internal process
> >        and prioritization.  There are no external controls over suspend
> >        and resume.
> 
> How about: "there are no direct controls over suspend and resume other than modifying a subscription."  
> 
> Right before Figure 2, I will also add the sentence to clarify:
> Modification of a configured subscription will place any suspended receivers into the connecting receiver state.
> 
> > o  Section 3
> > 
> >   The data model is not yet converted to NMDA single tree (and there
> >   is no issue that tracks this).
> 
> We have an umbrella issue for this:
> YP#11: Shift to NMDA compliant structure
> 
> We authors are willing to shift to NMDA constructs (allowing side-by-side comparison) once all other issues are closed and a firm WGLC start date is set for yang push. 

The sooner you get it in the better, since it will speed up
everything.

> > o  Section 4.1.1
> > 
> >      Not all streams will support replay.  Those that do MUST include
> >      they do via the "replay-support" object.
> > 
> >   The second sentence still looks odd.  I propose:
> > 
> >     If a stream supports replay, the "replay-support" leaf is present
> >     in the "/streams/stream" list entry for the stream.
> 
> Will make this change
> 
> > o  Section 4.4
> > 
> >      An operator may find subscription
> >      identifiers which may be used with "kill-subscription" by searching
> >      for the ip address of a receiver within the yang tree.
> > 
> >   s/within the yang tree/in the "subscription" list"/
> > 
> >   or something along those lines.
> 
> Will make this change
> 
> > o  Section 5
> > 
> >      o  One or more receiver IP addresses (and corresponding ports)
> >         intended as the destination for notification messages for each
> >         subscription.  In addition, the transport for each destination MAY
> >         be defined.
> > 
> >    Since the transport is mandatory in the data model, the last
> >    sentence should be removed.
> 
> Will make this change
> 
> > o  Section 5.1
> > 
> >   The text in -07 is an improvement over -05.  But there are still
> >   some things that needs to be specified.
> > 
> >   The text needs to discuss what's supposed to happen if a transport
> >   session goes down. Will the server re-establish the session?  
> 
> As there are transport specific behaviors.  For NETCONF, see Section 5.2 of draft-ietf-netconf-netconf-event-notifications.

Ok, makes sense.  I suggest you add a sentence along the lines of:

  How transport failures are dealt with is out of scope for this
  document.  It is expected that transport-specific documents describe
  how failures are handled.

> >  Will it buffer events during this time?  
> 
> Events are buffered, if available.  If events are lost (rather than just delayed) due to the loss of transport connectivity, a new subscription-started must be sent.  This indicates the discontinuity to the receiver.

I assume this should also be covered by the transport specific
documents.

> Note I will add these two sentences directly above to section 5.1 to clear up any confusion. 
> 
> On a side note: I will tweak the text of " 8.4. subscription-suspended" to 
> " This indicates that a publisher has suspended the sending of event records to a receiver, and indicates the possible loss of events."
> And delete the sentence from both 8.4 and 8.5 saying...
> "Suspensions are notified to the subscriber..."
> .
> >  What happens if the call home
> >   setup due to authentication issues, will it still try to
> >   re-establish?
> 
> For NETCONF, see Section 5.2 of draft-ietf-netconf-netconf-event-notifications.
>  
> >   The new text says:
> > 
> >      Note that is possible to configure replay on a configured
> >      subscription.  This is to allows a configured subscription to
> >      exist on a system so that event records generated during boot can
> >      be buffered and pushed as soon as the transport session is
> >      established.
> > 
> >   I assume this means that the reciever must be prepared to receive
> >   the same events multiple times?  (if the server reboots before the
> >   replay buffer has been overwritten)
> 
> No, boot time is considered.   The proper operation is documented in the YANG model..
> 
>   notification subscription-started {
>     uses subscription-policy {
>       refine "target/stream/replay-start-time"
>            "Indicates the time that a replay using for the streaming of
>            buffered event records.  This will be populated with the most
>            recent of the following: replay-log-creation-time,
>            replay-log-aged-time, replay-start-time, or the most recent
>            publisher boot time.";

Ok.

> > o  Section 9.2
> > 
> >   s/yang/YANG/
> 
> Will fix
> 
> >   Also, the text says:
> > 
> >     In addition support for optional features: encode-xml,
> >     encode-json, configured, and replay MUST also be indicated if
> >     supported.
> > 
> >   I think you should remove this sentence; it is redundant.  If you
> >   decide to keep it, write:
> > 
> > 
> >     In addition support for optional features: "encode-xml",
> >     "encode-json", "configured", "replay", "xpath", and "subtree" MUST
> >     also be indicated if supported.
> 
> Will do this one.  
> 
> >   BTW, why did you rename "configured-subscriptions" to "configured"?
> >   "configured" looks a bit short.
> 
> Due to the YANG tree.   The longer feature name causes make a significant number of the lines exceed the character limit for a row.   And things become very difficult to read.

I think we should pick descriptive names that make sense, and not
names that make the tree diagram or whatever look nice.  I suggest you
keep the original name.

> > o  10 - extension
> > 
> >      extension subscription-state-notif {
> > 
> >   I think you should spell out "notification"; i.e., use
> >   subscription-state-notification.
> > 
> >   (You replied "will do" to this comment in my previous review, so I
> >   suspect you simply forgot this one)
> 
> Yes.  This time I really will do :-)
> 
> > o  10 - filter-spec
> > 
> >   I think both the subtree and XPath filters are not correctly
> >   defined.  I provided text about the XPath filter, but you didn't
> >   include it, so here it is again, updated with your text about
> >   events.
> 
> 
> Thanks for keeping on about this.  The definitions you provide are an upgrade, and I will include.
>  
> >       anydata subtree-filter {
> >         description
> > 
> > 
> >   OLD:
> > 
> >           "Event stream evaluation criteria encoded in a syntax of a
> >            supported type of an RFC 6241, Section 6 filter.  The subtree
> >            filter is applied to the representation of individual,
> >            delineated event records as contained within the event
> >            stream.  For example, if the notification message contains an
> >            instance of a notification defined in YANG, then the top-
> >            level element is the name of the YANG notification.  If the
> >            stream filter matches an event record from the stream, the
> >            event record should be included in a notification message
> >            to the receiver(s).";
> >       }
> > 
> >   NEW:
> > 
> >           "Event stream evaluation criteria encoded in the syntax of
> >            a subtree filter as defined in RFC 6241, Section 6.
> > 
> >            The subtree filter is applied to the representation of
> >            individual, delineated event records as contained within
> >            the event stream.  For example, if the notification message
> >            contains an instance of a notification defined in YANG,
> >            then the top-level element is the name of the YANG
> >            notification.
> > 
> >            If the subtree filter returns a non-empty node set, the
> >            filter matches the event record, and the it is included in
> >            the notification message sent to the receivers.";
> > 
> >         reference "RFC 6241, Section 6.";
> >       }
> > 
> >   and:
> > 
> >       leaf xpath-filter {
> >         type yang:xpath1.0;
> >         description
> > 
> >   OLD:
> > 
> >           "Event stream evaluation criteria encoded in a syntax of xpath
> >            1.0 and applied against an event stream. The result of
> >            applying XPath expression is converted to a boolean value
> >            using the standard XPath 1.0 rules.  If the boolean value is
> >            'true', the stream filter matches an event record within the
> >            stream, and the notification message should be sent to the
> >            receiver(s).";
> > 
> >   NEW:
> > 
> >           "Event stream evaluation criteria encoded in the syntax of
> >            an XPath 1.0 expression.
> > 
> >            The XPath expression is evaluated on the representation of
> >            individual, delineated event records as contained within
> >            the event stream.  For example, if the notification message
> >            contains an instance of a notification defined in YANG,
> >            then the top-level element is the name of the YANG
> >            notification, and the root node has this top-level element
> >            as the only child.
> > 
> >            The result of the XPath expression is converted to a
> >            boolean value using the standard XPath 1.0 rules.  If the
> >            boolean value is 'true', the filter matches the the event
> >            record, and the it is included in the notification message
> >            sent to the receivers.
> > 
> >            The expression is evaluated in the following XPath context:
> > 
> >              o  The set of namespace declarations are those in scope on
> >                 the 'xpath-filter' leaf element where th
> > 
> >              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 root node.
> > 
> >         reference
> >           "http://www.w3.org/TR/1999/REC-xpath-19991116
> >            RFC 7950, Section 10.";
> >       }
> > 
> > 
> > 
> > o  10 - grouping notification-origin-info
> > 
> >   In your reply tpo my previous review, you wrote that you would
> >   remove the term "push source".  It is still used.
> 
> Yes, will update.




/martin


From nobody Thu Nov 16 03:28:56 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270A7128B88 for ; Thu, 16 Nov 2017 03:28:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChfmxgLjIOdA for ; Thu, 16 Nov 2017 03:28:54 -0800 (PST)
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 00771126DFB for ; Thu, 16 Nov 2017 03:28:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9422; q=dns/txt; s=iport; t=1510831734; x=1512041334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZTRVrtjKN4z630+krG7yFtRpUOTPNOU3H3ODnUTUR/0=; b=CjAuxALnnaMjH1OLwfmcJYE0yYzYAoRTbE4o62dKvB4I077juEIWISY/ iGCqhzJ7ac2DMT4v1Y0Tbf2if5Nx0Ynq09MH5wYrgsK4CEym9OC4lybX3 SWaHhUqBjwTlw2yRFNfOad52rwr5OgWkTOuVYOOmnbjgZsXko1JvOm0TW U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAABGdQ1a/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB4N4ih+PIIFXJpZfghEKI4UYAhqEUj8YAQEBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQECASMRQAUFCwIBCA4HAwICCRYEAwICAjAUARACBA4FG4oBCBCpe?= =?us-ascii?q?oInixMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgiWCB4NnC4J3hRcBF4J+MYI?= =?us-ascii?q?yBaI7AodujRqTSIxxhX6DFAIRGQGBOAEfOIF0ehVJLQGCNkmCSIFOd4hpK4EIg?= =?us-ascii?q?REBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208";a="31718326"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 11:28:53 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAGBSqDG020513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 11:28:52 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 06:28:52 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 06:28:51 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Martin Bjorklund 
CC: "Eric Voit (evoit)" , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFwAA3K+YAAEmKugAAHhysA
Date: Thu, 16 Nov 2017 11:28:51 +0000
Message-ID: <97A0F5AB-C80D-4E2C-8728-5144BAC9076E@cisco.com>
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com> <20171116.085331.436907075368637840.mbj@tail-f.com>
In-Reply-To: <20171116.085331.436907075368637840.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.247.137]
Content-Type: text/plain; charset="utf-8"
Content-ID: <06B9BC9A5BD570429131F59752565743@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 11:28:56 -0000

KEIpIFdvdWxkIGJlIGZpbmUgZm9yIG1lLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KPiBPbiAx
NiBOb3YgMjAxNywgYXQgMDc6NTMsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3
cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gTm90ZSB0aGF0IHRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBj
dXJyZW50IG1vZGVsIGhhczoNCj4gDQo+ICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBbaWRlbnRp
Zmllcl0NCj4gICAgICAgICAuLi4NCj4gICAgICAgICArLS1ydyBlbmNvZGluZw0KPiAgICAgICAg
IC4uLg0KPiAgICAgICAgICstLXJ3IHJlY2VpdmVycw0KPiAgICAgICAgICAgICstLXJ3IHJlY2Vp
dmVyKiBbYWRkcmVzcyBwb3J0XQ0KPiAgICAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICAgICAg
ICstLXJ3IHByb3RvY29sDQo+IA0KPiBNeSBwcm9wb3NhbCBpcyBoYXZlIGVuY29kaW5nIGFuZCBw
cm90b2NvbCB0b2dldGhlcjoNCj4gDQo+IChBKQ0KPiAgICAgICstLXJ3IHN1YnNjcmlwdGlvbiog
W2lkZW50aWZpZXJdDQo+ICAgICAgICAgLi4uDQo+ICAgICAgICAgLi4uDQo+ICAgICAgICAgKy0t
cncgcmVjZWl2ZXJzDQo+ICAgICAgICAgICAgKy0tcncgcmVjZWl2ZXIqIFthZGRyZXNzIHBvcnRd
DQo+ICAgICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgICAgICAgKy0tcncgcHJvdG9jb2wNCj4g
ICAgICAgICAgICAgICArLS1ydyBlbmNvZGluZw0KPiANCj4gb3I6DQo+IA0KPiAoQikNCj4gICAg
ICArLS1ydyBzdWJzY3JpcHRpb24qIFtpZGVudGlmaWVyXQ0KPiAgICAgICAgIC4uLg0KPiAgICAg
ICAgICstLXJ3IGVuY29kaW5nDQo+ICAgICAgICAgKy0tcncgcHJvdG9jb2wNCj4gICAgICAgICAu
Li4NCj4gICAgICAgICArLS1ydyByZWNlaXZlcnMNCj4gICAgICAgICAgICArLS1ydyByZWNlaXZl
ciogW2FkZHJlc3MgcG9ydF0NCj4gICAgICAgICAgICAgICAuLi4NCj4gDQo+IEkgdGhpbmsgdGhh
dCB0aGlzIGlzICpsZXNzKiBjb21wbGV4IGFuZCBwcm9iYWJseSBtb3JlIG9wdGltYWwgdGhhbiB0
aGUNCj4gY3VycmVudCBzb2x1dGlvbi4NCj4gDQo+ICJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWlu
YXJubikiIDxlaW5hcm5uQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBNYXJ0aW4sDQo+PiANCj4+IEFz
IHlldCwgd2UgaGF2ZSBubyBwcmFjdGljYWwgdXNlIGNhc2VzIHdoZXJlIHdlIHdvdWxkIGhhdmUg
YSBzaW5nbGUNCj4+IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdpdGggbXVsdGlwbGUgcmVjZWl2
ZXJzIHdobyB3aXNoIHRvIHJlY2VpdmUNCj4+IHRoZSBkYXRhIGluIGRpZmZlcmVudCBmb3JtYXRz
LiBUaHVzIHN1cHBvcnRpbmcgdGhpcyBzZWVtcyBsaWtlIGFuDQo+PiB1bm5lY2Vzc2FyeSBjb21w
bGV4aXR5IGZvciBwbGF0Zm9ybXMsIGFuZCBvbmUgd2hpY2ggcG90ZW50aWFsbHkNCj4+IGltcGFj
dHMgb3B0aW1pc2F0aW9ucyB0aGF0IHdlIGFscmVhZHkgdXNlIGluIHNvbWUgcGxhdGZvcm0NCj4+
IGltcGxlbWVudGF0aW9ucyAoZS5nLiBzZW5kaW5nIHRoZSBzYW1lIGVuY29kZWQgUERVIHRvIG11
bHRpcGxlDQo+PiByZWNlaXZlcnMsIHJlbGlldmluZyB0aGUgcGxhdGZvcm0gb2YgZW5jb2Rpbmcg
dGhlIHNhbWUgZGF0YSBtdWx0aXBsZQ0KPj4gd2F5cykuDQo+IA0KPiBCdXQgdGhpcyBvcHRpbWl6
YXRpb24gZG9lc24ndCByZWFsbHkgd29yaywgYXMgeW91IG5vdGUgYmVsb3cgKCopLg0KPiANCj4+
IE9mIGNvdXJzZSwgaWYgYSBjbGllbnQgcmVhbGx5IHdhbnRzIHRvIGhhdmUgdGhlIHNhbWUgZGF0
YSBzZW50IHRvDQo+PiBtdWx0aXBsZSByZWNlaXZlcnMgYnV0IGluIGRpZmZlcmVudCBmb3JtYXRz
LCB0aGV5IGNhbiBkbyB0aGlzIOKAlCBqdXN0DQo+PiBwcm92aXNpb24gc2VwYXJhdGUgc3Vic2Ny
aXB0aW9ucyB3aXRoIHRoZSBzYW1lIGZpbHRlci4NCj4gDQo+IEV4YWN0bHk7IHRoaXMgaXMgbW9y
ZSBjb21wbGV4IGFuZCBsZXNzIG9wdGltYWwgc2luY2UgdGhlIHNhbWUgZmlsdGVyDQo+IG1pZ2h0
IGJlIGV2YWx1YXRlZCB0d2ljZSwgdW5sZXNzIHlvdSBhZGQgY29kZSB0byBvcHRpbWl6ZSBmb3Ig
dGhhdA0KPiAod2hpY2ggcHJvYmFibHkgZmFsbHMgaW4geW91ciBjYXRlZ29yeSBvZiAidW5uZWNl
c3NhcnkgY29tcGxleGl0eSIpLg0KPiANCj4gKCopIFNvIGlmIHRoZSBvcGVyYXRvciByZXF1aXJl
cyB0aGlzIHNldHVwLCBoZSB3aWxsIGhhdmUgdG8gY29uZmlndXJlDQo+IHR3byBkaWZmZXJlbnQg
c3Vic2NyaXB0aW9ucyB0b2RheS4gIFRodXMsIHRoZSBwbGF0Zm9ybSB3aWxsIGVuY29kZSB0aGUN
Cj4gZGF0YSB0d2ljZSwgYW5kIHlvdXIgb3B0aW1pemF0aW9uIGFib3ZlIHdvbid0IGhlbHAuDQo+
IA0KPj4gQWxsLWluLWFsbCwgSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiBtYWtpbmcgdGhl
IGJhc2UgbW9kZWwgc3VwcG9ydA0KPj4gdGhpcywgb25seSBkb3duc2lkZXMsIHNvIGRvIHlvdSBo
YXZlIGFueSBzcGVjaWZpYyB1c2UgY2FzZXMgaW4gbWluZA0KPj4gd2hlcmUgdGhpcyB3b3VsZCBi
ZSBhIGJlbmVmaXQ/IFNvIGZhciBpbiB0aGUgdXNlIGNhc2VzIHdlIGhhdmUgbG9va2VkDQo+PiBh
dCBpbiBTUCwgREMsIGVudGVycHJpc2UgYW5kIElvVCB3ZSBoYXZlIG5vdCBzZWVuIGFueSByZXF1
aXJlbWVudCB0bw0KPj4gc3VwcG9ydCB0aGlzLCBidXQgd2UgaGF2ZSBzZWVuIHRoZSBuZWVkIGZv
ciBtdWx0aXBsZSByZWNlaXZlcnMNCj4+IChlLmcuIHRvIHN1cHBvcnQgSEEvcmVkdW5kYW5jeSBh
cHByb2FjaGVzKS4NCj4gDQo+IFRoZSBjdXJyZW50IG1vZGVsIHN1cHBvcnRzIGRpZmZlcmVudCAq
cHJvdG9jb2xzKiBmb3IgdGhlIGRpZmZlcmVudA0KPiByZWNlaXZlcnMuICBEbyB5b3UgaGF2ZSBh
IHVzZSBjYXNlIHN1cHBvcnRpbmcgdGhhdCwgb3Igd291bGQgKEIpIGFib3ZlDQo+IGZ1bGZpbCB5
b3VyIHJlcXVpcmVtZW50cy4NCj4gDQo+IA0KPiAvbWFydGluDQo+IA0KPiANCj4gDQo+PiBBcyBz
dWNoLCBJIHdvdWxkIGJlDQo+PiByZWx1Y3RhbnQgdG8gYWRkIHRoaXMgdG8gdGhlIGRyYWZ0IGF0
IHRoaXMgc3RhZ2Ugd2hlbiB0aGUNCj4+IGZ1bmN0aW9uYWxpdHkgY2FuIGJlIGFjaGlldmVkIGFs
cmVhZHkgaWYgYWJzb2x1dGVseSBuZWNlc3NhcnkuDQo+PiANCj4+IENoZWVycywNCj4+IA0KPj4g
RWluYXINCj4+IA0KPj4gDQo+Pj4gT24gMTUgTm92IDIwMTcsIGF0IDIxOjUzLCBFcmljIFZvaXQg
KGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4+PiANCj4+PiBBZGRpbmcgRWluYXIg
YXMgaGUgaGFkIHNvbWUgc3Ryb25nIG9waW5pb25zIG9uIHRoaXMgYSBmZXcgeWVhcnMgYWdvDQo+
Pj4gd2hlbiB3ZSB3ZXJlIHNldHRpbmcgdGhlIG1vZGVsLi4uDQo+Pj4gDQo+Pj4gDQo+Pj4+IEZy
b206IE1hcnRpbiBCam9ya2x1bmQsIE5vdmVtYmVyIDE1LCAyMDE3IDEwOjQzIEFNDQo+Pj4+IA0K
Pj4+PiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4g
SGkgTWFydGluLA0KPj4+Pj4gDQo+Pj4+Pj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRv
Om1iakB0YWlsLWYuY29tXQ0KPj4+Pj4+IA0KPj4+Pj4+ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2
b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+IEluIHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93
LCBJIGFtIGhvcGluZyB0byBnZXQgImh1bSBmZWVkYmFjayIgb246DQo+Pj4+Pj4+IA0KPj4+Pj4+
PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlm
aWNhdGlvbnMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdn
L3JmYzUyNzdiaXMvaXNzdWVzLzQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+
Pj4gVGhlIHR3byBjaG9pY2VzIGFuZCB0aGVpciBpc3N1ZXMgZXhwb3NlZCBkdXJpbmcgdGhlIHR3
byB3ZWVrDQo+Pj4+Pj4+IHJldmlldyBvbg0KPj4+Pj4+ICJDYW4gVHJhbnNwb3J0IHZhcnkgYWNy
b3NzIGRpZmZlcmVudCByZWNlaXZlcnMgb2YgYSBzaW5nbGUNCj4+Pj4+PiBjb25maWd1cmVkIHN1
YnNjcmlwdGlvbj8iIGFyZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4g
KDEpIFllcywgVHJhbnNwb3J0IGNhbiB2YXJ5IGJ5IHJlY2VpdmVyDQo+Pj4+Pj4+IA0KPj4+Pj4+
PiAqICAgICAgICBGZXdlciBzdWJzY3JpcHRpb25zIChzY2FsZSBiZW5lZml0KQ0KPj4+Pj4+PiAN
Cj4+Pj4+Pj4gKiAgICAgICAgQ2FuIGNvbnZlcnQgdHJhbnNwb3J0IHdpdGhvdXQgcmVxdWlyaW5n
IGFuIGFwcGxpY2F0aW9uIHRvIGxlYXJuDQo+Pj4+IGENCj4+Pj4+PiBtdWx0aXBsZSBzdWJzY3Jp
cHRpb24gaWRzDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAqICAgICAgICBObyBkdXBsaWNhdGlvbiBvZiBj
b250ZW50IGR1cmluZyB0cmFuc3BvcnQgY29udmVyc2lvbi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICog
ICAgICAgIChQb3RlbnRpYWwgY29uZnVzaW9uIGluIGFsbG93aW5nIHRyYW5zcG9ydCB0byB2YXJ5
LCBidXQNCj4+Pj4+Pj4gKiAgICAgICAgZW5jb2RpbmcNCj4+Pj4gbm90DQo+Pj4+Pj4gdG8gdmFy
eT8pDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICgyKSBObywgb25seSBv
bmUgVHJhbnNwb3J0IGFjcm9zcyBhbGwgc3Vic2NyaXB0aW9ucw0KPj4+Pj4+PiANCj4+Pj4+Pj4g
KiAgICAgICAgU2ltcGxlciBtb2RlbA0KPj4+Pj4+PiANCj4+Pj4+Pj4gKiAgICAgICAgQnV0IGFw
cGxpY2F0aW9ucyBtYXkgbmVlZCB0byBjcmVhdGUgYW5kIHRyYWNrIG11bHRpcGxlDQo+Pj4+Pj4g
c3Vic2NyaXB0aW9uLWlkcyBmb3IgdGhlIHNhbWUgY29udGVudC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+
ICogICAgICAgIFRlbXBvcmFyeSBkdXBsaWNhdGlvbiBvZiBjb250ZW50IHN0cmVhbXMgZHVyaW5n
IHRyYW5zcG9ydA0KPj4+PiBjaGFuZ2UuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+
Pj4+Pj4+IFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDEpLg0KPj4+Pj4+IA0KPj4+Pj4+IEFjdHVh
bGx5LCB0aGUgZ2l0aHViIGlzc3VlIGxpc3RzIDMgb3B0aW9ucywgYnV0IGhlcmUgeW91IGp1c3Qg
bGlzdCAyLg0KPj4+Pj4gDQo+Pj4+PiBJbiByZXZpZXdpbmcgdG9tb3Jyb3cncyBzbGlkZXMgd2l0
aCBNYWhlc2gsIGhlIHByZWZlcnJlZCAyIG9wdGlvbnMuDQo+Pj4+PiBBbmQgYXMgdmFyeWluZyB0
aGUgZW5jb2RpbmcgYnkgcmVjZWl2ZXIgc2VlbXMgdW5saWtlbHkgaW4NCj4+Pj4+IGltcGxlbWVu
dGF0aW9uDQo+Pj4+IA0KPj4+PiBXaHkgaXMgdGhpcyB1bmxpa2VseT8gIFN1cHBvc2UgSSBoYXZl
IHR3byByZWNlaXZlcnMgZm9yIHRoZSBzYW1lDQo+Pj4+IHN1YnNjcmlwdGlvbiwgb25lIHdhbnRz
IE5FVENPTkYvWE1MIGFuZCB0aGUgb3RoZXIgUkVTVENPTkYvSlNPTi4gIElzDQo+Pj4+IHRoYXQg
dW5saWtlbHk/DQo+Pj4gDQo+Pj4gRWluYXIncyBiZWxpZWYgd2FzIHRoYXQgYSBwdWJsaXNoZXIg
aW1wbGVtZW50YXRpb24gd291bGQgYmUgdW5saWtlbHkNCj4+PiB0byBzZXJ2aWNlIGEgc2luZ2xl
IHN1YnNjcmlwdGlvbiBpbnRvIG11bHRpcGxlIGVuY29kaW5ncy4gIElmIHN1Y2ggYQ0KPj4+IGNv
bmRpdGlvbiBleGlzdGVkLCBpdCB3b3VsZCBiZSBmYXIgZWFzaWVyIHRvIGNyZWF0ZSB0d28gc3Vi
c2NyaXB0aW9ucy4NCj4+PiBUaGlzIGFsc28gd291bGQgaGF2ZSBmZXdlciBlcnJvciBjb25kaXRp
b25zLg0KPj4+IA0KPj4+Pj4gLCB0aGVyZSBpcyBsaXR0bGUgcmVhc29uIHRvIHNvY2lhbGl6ZSB0
aGlzIHVubGlrZWx5IHZhcmlhbnQgYmVmb3JlDQo+Pj4+PiB0aGUgd2hvbGUgV0cuICAgU2luY2Ug
YXMgeW91ciBvcGluaW9uIHdhcyBlaXRoZXIgYm90aCBlbmNvZGluZyBhbmQNCj4+Pj4+IHRyYW5z
cG9ydCBvciBuZWl0aGVyIGVuY29kaW5nIGFuZCB0cmFuc3BvcnQgdmFyeSBieSByZWNlaXZlciwg
dGhlIG1vcmUNCj4+Pj4+IGxpa2VseSBvZiB5b3VyIHByaW1hcnkgYXNrIGlzIHN1cHBvcnRlZC4N
Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gSSB0aGluayB0aGUgcG9pbnQgaXMgdGhhdCBpbiB0aGUg
dGVybSAiVHJhbnNwb3J0Iiwgd2UgbmVlZCB0bw0KPj4+Pj4+IGluY2x1ZGUgYm90aCBwcm90b2Nv
bCBhbmQgZW5jb2RpbmcgKGluIHRoZSBjYXNlIHRoZSBwcm90b2NvbA0KPj4+Pj4+IHN1cHBvcnRz
IG11bHRpcGxlIGVuY29kaW5ncykuDQo+Pj4+PiANCj4+Pj4+IFdoaWxlIG1vc3QgbGlrZWx5IHRo
ZSBjYXNlIGZvciBORVRDT05GIGFuZCBSRVNUQ09ORiwgVGlhbnJhbidzDQo+Pj4+PiBkcmFmdC1p
ZXRmLW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsIHNob3dzIHRoYXQgdGhlcmUgY2FuIGJlIGVuY29k
aW5nDQo+Pj4+PiB2YXJpYXRpb24gYnkgdHJhbnNwb3J0cyAuICAgSXQgVGhlcmVmb3JlIGl0IHNl
ZW1zIGJldHRlciB0byBsZXQgdGhlbQ0KPj4+Pj4gYm90aCB2YXJ5IGluZGVwZW5kZW50bHkuDQo+
Pj4+IA0KPj4+PiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4gIFRvIGJlIGNs
ZWFyLCBkbyB5b3UgdGhpbmsgdGhlDQo+Pj4+ICJlbmNvZGluZyIgbGVhZiBzaG91bGQgc3RheSB3
aGVyZSBpdCBpcywgb3IgYmUgbW92ZWQgZG93biB0byB0aGUNCj4+Pj4gcmVjZWl2ZXIsDQo+Pj4+
IGFzIGEgc2libGluZyB0byAicHJvdG9jb2wiPw0KPj4+IA0KPj4+IEVuY29kaW5nIGxlYWYgc2hv
dWxkIHN0YXkgd2hlcmUgaXQgaXMuICBZb3VyIHByZXZpb3VzIGFzayB3YXMgdG8gcHV0DQo+Pj4g
ZW5jb2RpbmcgYW5kIHRyYW5zcG9ydCBhbmQgdGhlIHNhbWUgbGV2ZWwuIFRoZXJlIGlzIGFuIG9w
dGlvbiBwcm9wb3NlZA0KPj4+IGluIHRoZSBzbGlkZXMgd2hpY2ggZG9lcyB0aGF0Lg0KPj4+IA0K
Pj4+IEVyaWMNCj4+PiANCj4+Pj4gL21hcnRpbg0KPj4+IA0KPj4gDQoNCg==


From nobody Thu Nov 16 03:40:16 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26A8129465; Thu, 16 Nov 2017 03:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aWnDr-SJSVMi; Thu, 16 Nov 2017 03:40:12 -0800 (PST)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 88F57126DFB; Thu, 16 Nov 2017 03:40:12 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id i15so9103601pfa.3; Thu, 16 Nov 2017 03:40:12 -0800 (PST)
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=iYaGZnAu9T+KXEHr2GfOaUubFMqSNUIJPeHwylCkOwY=; b=rRHhPQxg9yERrRkmPOFsgiK4f1+vFjfMvQ4F7iJjk5akbt/OCP14lINscOU5lQCafX j7zoioQ4gOqk/eyhDc9iyWC9BCMJIDbxL6F2syMTBebBIs+Va5VciwwLjxNXV+BPvTcQ pFNedaWphom6IspQizJ+wkfSjx/FcHfZAAd7HXPhXTbfuqyaMv3YGSq3SxJs6GBIIL56 uXmMwNS7XGenY5ewfqIbGcF7wRAW4BtH78qsJSIFe6LuZ6WjVCcnzkVr9w2VtmLRN2Hz a25lIfDVJdRu0zB6up0YodYW7i1B7sb8/sAlNXuG9BM3oU/J1UGIh24113jpiqLkiDtw kvpw==
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=iYaGZnAu9T+KXEHr2GfOaUubFMqSNUIJPeHwylCkOwY=; b=eGbv+uhSyjoUL4gWi95SgzVxhJngCR+WVX/7/sMBJA0+SClbjteV0L2umsego55+yD G3X+h/bYLTyQq3mQWZ9uWvhfEGjo71ctgGFKg2xjTbV4UpsqyNO3Xjm4+P/JpA417uN0 wC3f+sGvW3BeNxCDGNXfCUBvT+63xdqVMjAiEsOLOpVk0plxUh5wHW5dA8d2DlIHIVLb w740BNLP2STRDQPAskGMd9GzSQEK/cYPc1BlVqhBhNNUya1fNxRD2jsLbC4yQYvaTUb1 UvsRUpzlYjdyyLRT67f+DOG1vsQe2GhytnfTdFb1QZoUA5QeG0TGCFipZDb4SKEWAItP g/hw==
X-Gm-Message-State: AJaThX7necobscK2NNCobj6rb2nVbpzVaM+rzL2gNboiKnyPG7T4++KM qHXRHQbjlAIO0xk5fEdwXI4=
X-Google-Smtp-Source: AGs4zMbedwhhpITrO+ehf8aUyFvwwFiOq4mpfmbTieuvmrTKMk9rq1SFQs8zK7PexwjAxL/FvM9OfA==
X-Received: by 10.84.216.81 with SMTP id f17mr1419999plj.330.1510832412063; Thu, 16 Nov 2017 03:40:12 -0800 (PST)
Received: from [192.168.1.31] (bb219-75-122-125.singnet.com.sg. [219.75.122.125]) by smtp.gmail.com with ESMTPSA id t84sm2690403pfe.160.2017.11.16.03.40.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Nov 2017 03:40:11 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_903CED32-4885-41FC-8736-9F6655085F7C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com>
Date: Thu, 16 Nov 2017 19:40:06 +0800
Cc: Andy Bierman , sec-ads@ietf.org, netconf , Eric Rescorla 
Message-Id: <91F5996E-16B2-443D-B826-3A3116E8FA48@gmail.com>
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>    <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 11:40:16 -0000

--Apple-Mail=_903CED32-4885-41FC-8736-9F6655085F7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I have verified that the proposed changes have been incorporated in -09 =
version of the draft in GitHub.

Based on my discussion with Eric, there is a little more tweak that we =
need to provide to Security Considerations section in the third =
paragraph.

OLD:
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS method.  The risk here is that the response to
   OPTIONS may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances.

NEW:
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS and PATCH methods.  The risk here is that the =
response to
   OPTIONS and PATCH may vary based on the presence or absence of a =
resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary its responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances. In particular
   servers should not expose any instance information before ensuring
   that the client has the necessary access permissions to obtain that
   information. In such cases, servers are expected to always return the =
=E2=80=9Caccess-
   denied=E2=80=9D error response.


> On Nov 16, 2017, at 1:56 PM, Robert Wilton  wrote:
>=20
> I'm not sure I understand exactly what point the previous text was =
stating so I'm not sure whether my proposed text is stating the same =
thing (or whether this has already been stated elsewhere in the draft):
>=20
> OLD:
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances. In particular
> servers should not expose instance information before validating field
> information.
>=20
> NEW:
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances.  In particular
> servers should not expose any instance information before ensuring
> that the client has the necessary access permissions to obtain that
> information.
>=20
>=20
> Is that any more clear?  Or have I missed the point?
>=20
> Thanks,
> Rob
>=20
>=20
> On 16/11/2017 12:55, Mahesh Jethanandani wrote:
>> Can you provide text?
>>=20
>>> On Nov 16, 2017, at 12:29 PM, Robert Wilton > wrote:
>>>=20
>>> "validating field information" is slightly unclear to me, can this =
be reworded slightly?
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>> On 16/11/2017 03:12, Andy Bierman wrote:
>>>> Hi,
>>>>=20
>>>> I updated the draft with these changes on github.
>>>> There is a draft-pre-09.txt file now for you to review.
>>>>=20
>>>>=20
>>>> Andy
>>>>=20
>>>>=20
>>>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani =
> wrote:
>>>> Andy,
>>>>=20
>>>> I assume you will incorporate these changes in the -09 version of =
the draft.
>>>>=20
>>>> However, I am unable to review the changes in github. Can you post =
the diffs of the draft w.r.t. -08 version.
>>>>=20
>>>> That still leaves us with one issue, and that has to do with the =
what permission to give edit-operation. I am assuming the WG agrees that =
making the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 =
for edit operations makes maintenance more difficult and makes the =
operation more vulnerable, unless all the deny rules are in place.
>>>>=20
>>>> We will need to update the security considerations section to =
address Eric=E2=80=99s concerns. How about this update?
>>>>=20
>>>> OLD:
>>>> Therefore, a server MUST NOT vary their OPTIONS responses
>>>> based on the existence of the underlying resource, which would
>>>> indicate the presence or absence of resource instances.
>>>>=20
>>>> NEW:
>>>> Therefore, a server MUST NOT vary their OPTIONS responses
>>>> based on the existence of the underlying resource, which would
>>>> indicate the presence or absence of resource instances. In =
particular
>>>> servers should not expose instance information before validating =
field
>>>> information.
>>>>=20
>>>> Cheers.
>>>>=20
>>>>> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund > wrote:
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I just read this thread, and I agree with the changes, but see =
below
>>>>> for a comment.
>>>>>=20
>>>>>=20
>>>>> Andy Bierman > =
wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> Here are some proposed edits to make the data rule consistent =
with the
>>>>>> examples.
>>>>>> Note that this issue is not related to the edit in the original =
1-week
>>>>>> change.
>>>>>>=20
>>>>>>=20
>>>>>> sec. 3.3.5:
>>>>>>=20
>>>>>> OLD:
>>>>>>=20
>>>>>>=20
>>>>>>      data node rule:  controls access for a specific data node, =
identified
>>>>>>      by its path location within the conceptual XML document for =
the
>>>>>>      data node.
>>>>>>=20
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>>      data node rule:  controls access for a specific data node =
and its
>>>>>> descendants,
>>>>>>      identified by its path location within the conceptual XML =
document
>>>>>> for the
>>>>>>      data node.
>>>>>>=20
>>>>>>=20
>>>>>> sec 3.4.5, step 6, bullet 2:
>>>>>>=20
>>>>>>=20
>>>>>> OLD:
>>>>>>=20
>>>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>>>           type" is "data-node" and the "path" matches the =
requested
>>>>>>           data node, action node, or notification node.
>>>>>>=20
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>>=20
>>>>>>        *  The rule does not have a "rule-type" defined or the =
"rule-
>>>>>>           type" is "data-node" and the "path" matches the =
requested
>>>>>>           data node, action node, or notification node. A path is
>>>>>>           considered to match if the current data node is the =
data node
>>>>>>           specified by the path, or is a descendant data node of =
this
>>>>>>           data node.
>>>>>=20
>>>>> I propose:
>>>>>=20
>>>>>             The rule does not have a "rule-type" defined or the
>>>>>             "rule-type" is "data-node" and the "path" matches the
>>>>>             requested data node, action node, or notification =
node.
>>>>>             A path is considered to match if the requested node
>>>>>             is the node specified by the path, or is a
>>>>>             descendant node of the path.
>>>>>=20
>>>>> Note:  s/current node/requested node/ which is the term used in =
the
>>>>> first sentence.  And then s/data node/node/ since the first =
sentence
>>>>> refer to data-, action-, and notification node.
>>>>>=20
>>>>> I have checked in this fix in the repo.
>>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/netconf =

>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com 
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/netconf =

>>>=20
>>=20
>> Mahesh Jethanandani
>> mjethanandani@gmail.com 
>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_903CED32-4885-41FC-8736-9F6655085F7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I have verified that the proposed changes have been =
incorporated in -09 version of the draft in GitHub.

Based on my discussion =
with Eric, there is a little more tweak that we need to provide to =
Security Considerations section in the third paragraph.
OLD:
   There is a risk related to the lack of access control enforcement =
for
   the RESTCONF OPTIONS method.  The risk here is that the response to
   OPTIONS may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances.

NEW:
   =
There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS and PATCH methods.  The risk here is that the =
response to
   OPTIONS and PATCH may vary based on the presence or absence of a =
resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary its responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances. In particular
   =
servers should not expose any instance information before ensuring
   that the client has the necessary access permissions to obtain that
   information. In such cases, servers are expected to always return the =
=E2=80=9Caccess-
   denied=E2=80=9D error response.


On =
Nov 16, 2017, at 1:56 PM, Robert Wilton <rwilton@cisco.com> =
wrote:


 =20
    
 =20
  

    
I'm not sure I understand exactly what point the
      previous text was stating so I'm not sure whether my proposed text
      is stating the same thing (or whether this has already been stated
      elsewhere in the draft):

      

      OLD:

    

      
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

      


      

    

    
NEW:

    
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In =
particular

    
servers should not expose any instance information =
before ensuring
that the client has the necessary access permissions to obtain that
information.




    Is that any more clear?  Or have I missed the point?

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 12:55, Mahesh
      Jethanandani wrote:

    

    

      
      Can you provide text?
      


        

          

            
On Nov 16, 2017, at 12:29 PM, Robert Wilton
              <rwilton@cisco.com> wrote:

            

            

              
"validating field information" is slightly
                  unclear to me, can this be reworded slightly?
Thanks,

                  Rob

                

                

                
On 16/11/2017 03:12, Andy
                  Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I updated the draft with these =
changes
                      on github.

                    
There is a draft-pre-09.txt file now
                      for you to review.

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Tue, Nov 14, 2017 at
                      5:05 PM, Mahesh Jethanandani <mjethanandani@gmail.com>
                      wrote:

                      

                        
Andy,
                          


                          

                          
I assume you will incorporate
                            these changes in the -09 version of the
                            draft.

                          


                          

                          
However, I am unable to review
                            the changes in github. Can you post the
                            diffs of the draft w.r.t. -08 version.

                          


                          

                          
That still leaves us with one
                            issue, and that has to do with the what
                            permission to give edit-operation. I am
                            assuming the WG agrees that making the
                            change from =E2=80=98none=E2=80=99 to =
=E2=80=98read=E2=80=99 for edit
                            operations makes maintenance more difficult
                            and makes the operation more vulnerable,
                            unless all the deny rules are in =
place.

                          

                            

                              


                              

                              We will need to update the security
                              considerations section to address Eric=E2=80=
=99s
                              concerns. How about this update?

                            


                            

                            
OLD:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                              


                              

                            

                            
NEW:

                            

                              
Therefore, a server MUST NOT vary their OPTIONS =
responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In =
particular

                              
servers should not expose instance information before =
validating field

                              
information.

                              


                                

                              
Cheers.

                              


                                

                            

                            

                              

                                
On Nov 13, 2017, at =
11:28
                                  PM, Martin Bjorklund <mbj@tail-f.com>
                                  wrote:

                                

                                
Hi,

                                  

                                  I just read this thread,
                                    and I agree with the changes, but
                                    see below

                                  for a comment.

                                  

                                  

                                  Andy Bierman <andy@yumaworks.com> wrote:

                                  
Hi,

                                    

                                    Here are some proposed edits to make
                                    the data rule consistent with the

                                    examples.

                                    Note that this issue is not related
                                    to the edit in the original =
1-week

                                    change.

                                    

                                    

                                    sec. 3.3.5:

                                    

                                    OLD:

                                    

                                    

                                         data =
node rule:  controls
                                    access for a specific data node,
                                    identified

                                         by its =
path location within the
                                    conceptual XML document for the

                                         data =
node.

                                    

                                    

                                    NEW:

                                    

                                         data =
node rule:  controls
                                    access for a specific data node and
                                    its

                                    descendants,

                                    =
     identified by its path location
                                    within the conceptual XML =
document

                                    for the

                                         data =
node.

                                    

                                    

                                    sec 3.4.5, step 6, bullet 2:

                                    

                                    

                                    OLD:

                                    

                                    =
       *  The rule does not have =
a
                                    "rule-type" defined or the "rule-

                                    =
          type" is =
"data-node" and
                                    the "path" matches the requested

                                    =
          data node, =
action node, or
                                    notification node.

                                    

                                    

                                    NEW:

                                    

                                    

                                    =
       *  The rule does not have =
a
                                    "rule-type" defined or the "rule-

                                    =
          type" is =
"data-node" and
                                    the "path" matches the requested

                                    =
          data node, =
action node, or
                                    notification node. A path is

                                    =
          considered =
to match if the
                                    current data node is the data =
node

                                    =
          specified by =
the path, or
                                    is a descendant data node of this

                                    =
          data =
node.

                                  

                                  

                                  I propose:

                                  

                                            &nb=
sp; The rule does
                                    not have a "rule-type" defined or
                                    the

                                            &nb=
sp; "rule-type" is
                                    "data-node" and the "path" matches
                                    the

                                            &nb=
sp; requested data
                                    node, action node, or notification
                                    node.

                                            &nb=
sp; A path is
                                    considered to match if the requested
                                    node

                                            &nb=
sp; is the node
                                    specified by the path, or is =
a

                                            &nb=
sp; descendant node
                                    of the path.

                                  

                                  Note:  s/current
                                    node/requested node/ which is the
                                    term used in the

                                  first sentence.  And =
then
                                    s/data node/node/ since the first
                                    sentence

                                  refer to data-, action-,
                                    and notification node.

                                  

                                  I have checked in this fix
                                    in the repo.

                                  

                                  

                                  /martin

                                  

                                  _______________________________________________

                                  Netconf mailing =
list

                                  Netconf@ietf.org

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

                              

                            

                            

                                

                                  
Mahesh =
Jethanandani

                                  
mjethanandani@gmail.com

                                

                                

                              

                        

                      

                    

                    

                  

                  

                  

                  

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



                

                

              

            

          

        

        

        

          
Mahesh Jethanandani

          
mjethanandani@gmail.com

        

        

      

    

    

  






Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_903CED32-4885-41FC-8736-9F6655085F7C--


From nobody Thu Nov 16 17:12:27 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E361126D0C for ; Thu, 16 Nov 2017 17:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5GCdDngG5pY for ; Thu, 16 Nov 2017 17:12:23 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 BDA24126CD8 for ; Thu, 16 Nov 2017 17:12:23 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id 207so678926pgc.12 for ; Thu, 16 Nov 2017 17:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:message-id:date:to:mime-version; bh=mtc2xKEPm50QurKKzBtaBRCgnRoMB/ZGexGpgVWRc5o=; b=luX7kDOT2Kzi3hm9WDU+CfALqzy2Ksx6z0RCwHWfNCBKiRMnYRC6GUn+/HJgYG1KZh khByqsRdZpdfHbvNUTLg6l9aSBNV/7N6uVkUe1lTFstMkenVQOOa/6DqsCtYlSg5myhw yJt3fEAiCTxsbw0cOkrdsZWekg78rg9VjkOwZ/NPOV5gha3KiZlUROvPUx8+sxcL9uBv Uxe1hSik3w8lhmZaNyI0eTiFYGzLkWIgGYxE2qeog5MO18DhBzippmX4m0iEZellYdOF mSQ4epEOs2CYBayrjVM2u/P6y5XqVA97NfLsJrIpcdzriU5HSdZOnW1k/qOxPKszcMJq OZIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=mtc2xKEPm50QurKKzBtaBRCgnRoMB/ZGexGpgVWRc5o=; b=W5kI8Rqn9zyxUsu6Gj7qWzLWsMx6yf3hPczOsF5b7jAmQ4mtoU56xLTy0qYFHWc3SN G4zZfxT5zUNft4+wxMxF6rogUdx3GMLERcUdMRunc5KBL+xU2Cgl2nlfNlogh6SN0Trg 7jNoUimxwDkuMHI2Zt3V+RRjDpZqPL2U33lHweadCo1DEcFUSSTvzlMWksXjRjhgcAG7 BOetBrcPv/cugCs100HQvGQwS+vi/sEwaKDFXnSq5yMEzZtITaeAPi41Q4ie3M+v2TUN iF4/WHZoQzHgh/hAidyyscsR4SdFkj4NnUHglb0qjss8VQul8O3qWtcH0gmes7H3fDwe EKwQ==
X-Gm-Message-State: AJaThX6Rs8xgj0HCczD7m7oYpXAhvkDawSRCXY+5ySnj8qpm5Lm5RBsI U6ZB3SsUepNPg5srXKWfaWhsQi9B
X-Google-Smtp-Source: AGs4zMYakcaRrwOTXpLUCBT9kwMJ8eb/OtsU7BLPleHB2BJsjjCCpgkHriBQewDb9PH4Jk7JHZ85fA==
X-Received: by 10.101.80.6 with SMTP id f6mr3514209pgo.264.1510881142856; Thu, 16 Nov 2017 17:12:22 -0800 (PST)
Received: from [192.168.1.31] (bb219-75-122-125.singnet.com.sg. [219.75.122.125]) by smtp.gmail.com with ESMTPSA id q9sm5059092pfl.116.2017.11.16.17.12.21 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Nov 2017 17:12:22 -0800 (PST)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B7C31F9-1032-43E2-BFE7-5B6A8800E44C"
Message-Id: <10850A85-64A3-4DF5-9796-AA72F3A09764@gmail.com>
Date: Fri, 17 Nov 2017 09:12:19 +0800
To: netconf 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Netconf] Rough notes from the NETCONF meeting yesterday
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 01:12:26 -0000

--Apple-Mail=_3B7C31F9-1032-43E2-BFE7-5B6A8800E44C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The rough notes from the NETCONF meeting are here =
. Please review them, as there are still some gaps in the =
notes. Most importantly, if there was a decision or an agreement that =
was not recorded, please update it. You would have to be in the meeting, =
in person or remotely to make the changes.

To aid you in what was discussed, an audio recordings of what was =
discussed in the meeting can be found here =
. =
After about a week, these minutes will form the official version of the =
meeting minutes.

Thanks

Mahesh (and Kent)


--Apple-Mail=_3B7C31F9-1032-43E2-BFE7-5B6A8800E44C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

The rough notes from the NETCONF meeting are here. Please review them, as there =
are still some gaps in the notes. Most importantly, if there was a =
decision or an agreement that was not recorded, please update it. You =
would have to be in the meeting, in person or remotely to make the =
changes.

To aid you =
in what was discussed, an audio recordings of what was discussed in the =
meeting can be found here. After about a week, these minutes will form the =
official version of the meeting minutes.

Thanks



Mahesh (and Kent)





=

--Apple-Mail=_3B7C31F9-1032-43E2-BFE7-5B6A8800E44C--


From nobody Fri Nov 17 03:18:08 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F83127977 for ; Fri, 17 Nov 2017 03:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpdvNtkdr863 for ; Fri, 17 Nov 2017 03:18:05 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 214C1127275 for ; Fri, 17 Nov 2017 03:18:05 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2783BBFE0980 for ; Fri, 17 Nov 2017 11:18:02 +0000 (GMT)
Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Nov 2017 11:18:02 +0000
Received: from DGGEMA502-MBS.china.huawei.com ([169.254.3.146]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 19:17:54 +0800
From: Rohit R Ranade 
To: Andy Bierman 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] draft-ietf-netconf-rfc6536bis Edit proposal
Thread-Index: AdNflaUpQFPIekxGSVKLTR4Kg+SjkQ==
Date: Fri, 17 Nov 2017 11:17:54 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B14A1A7@DGGEMA502-MBS.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_991B70D8B4112A4699D5C00DDBBF878A6B14A1A7DGGEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [Netconf]  draft-ietf-netconf-rfc6536bis Edit proposal
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 11:18:07 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6B14A1A7DGGEMA502MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Andy,

If we want to use the NACM  module for RESTCONF also , then I propose the b=
elow changes.

OLD:
leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the server last restarted that a
            protocol operation request was denied.";
       }

NEW:
leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the NETCONF server last restarted that a
            protocol operation request was denied by the NETCONF server.";
       }

? To keep the meaning similar to RFC 6536

NEW:
ADD "leaf restconf-denied-operations" to provide the values for state-data =
corresponding to the RESTCONF server.

Another way was to mention that "denied-operations" is the total number of =
times the request was denied across all servers after they were started. Bu=
t since RESTCONF/NETCONF Servers MAY be started / stopped at different time=
 a combined total did not seem right.

With Regards,
Rohit R

From: Rohit R Ranade
Sent: 15 November 2017 10:42
To: netconf@ietf.org
Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi All,

For the state-data in NACM like the below :

leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the server last restarted that a
            protocol operation request was denied.";
       }

"Number of times since the server" =3D=3D> Here the server is being referen=
ced to NETCONF server or RESTCONF server ?
Please note that the both the NETCONF server and RESTCONF server maybe usin=
g the same NACM configurations but the state-data maintained by each protoc=
ol maybe different.

With Regards,
Rohit R

--_000_991B70D8B4112A4699D5C00DDBBF878A6B14A1A7DGGEMA502MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Andy=
,


&n=
bsp;


If we w=
ant to use the NACM  module for RESTCONF also , then I propose the bel=
ow changes.


&n=
bsp;


OLD:


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the server last restarted that =
a


       &nb=
sp;    protocol operation request was denied.";


       }


&n=
bsp;


NEW:


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the
NETCONF server last restarted that a


       &nb=
sp;    protocol operation request was denied by the
NETCONF server.";


       }



è
To keep the meaning similar to RFC 6536


&n=
bsp;


NEW:


ADD “leaf restconf-denied=
-operations” to provide the values for state-data corresponding to th=
e RESTCONF server.


 


Another way was to mention that=
 “denied-operations” is the total number of times the request w=
as denied across all servers after they were started. But since
 RESTCONF/NETCONF Servers MAY be started / stopped at different time a comb=
ined total did not seem right.



&n=
bsp;


With Re=
gards,


Rohit R=



&n=
bsp;






From: Rohit R Ranade


Sent: 15 November 2017 10:42

To: netconf@ietf.org

Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query






 


Hi All,


 


For the state-data in NACM like=
 the below :


 


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the server last restarted that =
a


       &nb=
sp;    protocol operation request was denied.";


       }


 


“Number of times since the server”
è=
 Here the server is being referenced to NETCONF server=
 or RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.<=
/span>


 


With Regards,=



Rohit R






--_000_991B70D8B4112A4699D5C00DDBBF878A6B14A1A7DGGEMA502MBSchi_--


From nobody Fri Nov 17 10:17:26 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E62126BF6 for ; Fri, 17 Nov 2017 10:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFARhfFHvMSa for ; Fri, 17 Nov 2017 10:17:23 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551861200FC for ; Fri, 17 Nov 2017 10:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12260; q=dns/txt; s=iport; t=1510942643; x=1512152243; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nfK+6TNK5JTz+TeUSXqSYGd15xRN8mnINI04E3FksH0=; b=HoE64Q2ro+LqOrFQ7VA8h89BC0ykAKzwkgx6/BsMxg1zUJxD+tivlO8b 4iJ0val+Ozq/TPD3GLQNeja/+Xll05twfOY4gc8DWfJV2X7B2HBgIgegZ KvnC4U9nWBLrzZNI+DLQcQfAnqte1lUGVdxc+63ZgaQZeEcdVnBvHdC+O 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgAqJw9a/4gNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8ZG4nB4N4mUWBfZZiEIIBChgLhElPAhqETUAXAQEBAQEBAQE?= =?us-ascii?q?Bax0LhR4BAQEBAgEBASEROgYKBwQCAQgRBAEBAQICCRYEAwICAiULFAEICAIEE?= =?us-ascii?q?wgTigIIEKorgieKegEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CJYIHgVWFFIU?= =?us-ascii?q?DL4J+gmMFoj4Ch3CNEZNVjHKJEwIRGQGBOQEhATaBdHoVSYJkgxGBTneIEiuBC?= =?us-ascii?q?IERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,410,1505779200"; d="scan'208";a="315772242"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2017 18:17:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAHIHLj4031816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Nov 2017 18:17:22 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 17 Nov 2017 13:17:21 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 17 Nov 2017 13:17:21 -0500
From: "Eric Voit (evoit)" 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAXxPeAAAB8W7AAC1/ogAABuWFwAA3K+YAAEmKugAAKViNQABak1OA=
Date: Fri, 17 Nov 2017 18:17:21 +0000
Message-ID: <1056296126874cfc9b52000290e84d67@XCH-RTP-013.cisco.com>
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com> <20171116.085331.436907075368637840.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.39.151]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 18:17:25 -0000

SW4gdGhlIG1lZXRpbmcgcm9vbSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgTkVUQ09ORiBXRywgc2Vu
dGltZW50IHdhcyB0byB1c2UgYSBjb21tb24gVHJhbnNwb3J0IGFjcm9zcyBhbGwgcmVjZWl2ZXJz
IG9mIGEgc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLiAgIFRoaXMgd2FzIHByb3Bvc2Fs
ICgyKSBiZWxvdy4NCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBpZiB0aGVyZSBpcyBhbnkgb2JqZWN0
aW9uIHRvIHRoaXMuICAgSWYgbm90LCB3ZSBjYW4gY2xvc2UgdGhpcyBpc3N1ZSBpbiBhIGZldyB3
ZWVrcy4NCg0KRXJpYw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5l
dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlj
IFZvaXQNCj4gKGV2b2l0KQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTYsIDIwMTcgMzoz
MCBBTQ0KPiBUbzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+OyBFaW5hciBOaWxz
ZW4tTnlnYWFyZCAoZWluYXJubikNCj4gPGVpbmFybm5AY2lzY28uY29tPg0KPiBDYzogbmV0Y29u
ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM0OiBDYW4gVHJh
bnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVudA0KPiByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29u
ZmlndXJlZCBzdWJzY3JpcHRpb24/DQo+IA0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBZZXMsIEkgb3Jp
Z2luYWxseSBoYWQgYm90aCB5b3VyIG9wdGlvbnMgaW4gdGhlIFdHIHNsaWRlcy4gICAgSSByZW1v
dmVkIChBKQ0KPiBhZnRlciBkaXNjdXNzaW9uIHdpdGggTWFoZXNoIGZvciB0aGUgV0cgc2Vzc2lv
biBzbGlkZXMgdG8gc2ltcGxpZnkgdGhlIGluLQ0KPiByb29tIGRpc2N1c3Npb25zLCBhcyB3ZWxs
IGFzIGNvbnNpZGVyYXRpb24gb2YgdGhlIHBvaW50cyBFaW5hciBtYWtlcyBiZWxvdy4NCj4gV2Ug
Y2FuIG9mIGNvdXJzZSBoYXZlIG1vcmUgYW5kIGRlZXBlciByZXNvbHV0aW9uIGRpc2N1c3Npb25z
IGhlcmUuDQo+IA0KPiBUaGFua3MsDQo+IEVyaWMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5j
b21dDQo+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3IDI6NTQgQU0NCj4gPiBU
bzogRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbT4NCj4g
PiBDYzogRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT47IG5ldGNvbmZAaWV0Zi5v
cmcNCj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM0OiBDYW4gVHJhbnNwb3J0
IHZhcnkgYWNyb3NzDQo+ID4gZGlmZmVyZW50IHJlY2VpdmVycyBvZiBhIHNpbmdsZSBjb25maWd1
cmVkIHN1YnNjcmlwdGlvbj8NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gTm90ZSB0aGF0IHRoZSBp
c3N1ZSBpcyB0aGF0IHRoZSBjdXJyZW50IG1vZGVsIGhhczoNCj4gPg0KPiA+ICAgICAgICstLXJ3
IHN1YnNjcmlwdGlvbiogW2lkZW50aWZpZXJdDQo+ID4gICAgICAgICAgLi4uDQo+ID4gICAgICAg
ICAgKy0tcncgZW5jb2RpbmcNCj4gPiAgICAgICAgICAuLi4NCj4gPiAgICAgICAgICArLS1ydyBy
ZWNlaXZlcnMNCj4gPiAgICAgICAgICAgICArLS1ydyByZWNlaXZlciogW2FkZHJlc3MgcG9ydF0N
Cj4gPiAgICAgICAgICAgICAgICAuLi4NCj4gPiAgICAgICAgICAgICAgICArLS1ydyBwcm90b2Nv
bA0KPiA+DQo+ID4gTXkgcHJvcG9zYWwgaXMgaGF2ZSBlbmNvZGluZyBhbmQgcHJvdG9jb2wgdG9n
ZXRoZXI6DQo+ID4NCj4gPiAoQSkNCj4gPiAgICAgICArLS1ydyBzdWJzY3JpcHRpb24qIFtpZGVu
dGlmaWVyXQ0KPiA+ICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAg
ICstLXJ3IHJlY2VpdmVycw0KPiA+ICAgICAgICAgICAgICstLXJ3IHJlY2VpdmVyKiBbYWRkcmVz
cyBwb3J0XQ0KPiA+ICAgICAgICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgICAgICAgICstLXJ3
IHByb3RvY29sDQo+ID4gICAgICAgICAgICAgICAgKy0tcncgZW5jb2RpbmcNCj4gPg0KPiA+IG9y
Og0KPiA+DQo+ID4gKEIpDQo+ID4gICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBbaWRlbnRpZmll
cl0NCj4gPiAgICAgICAgICAuLi4NCj4gPiAgICAgICAgICArLS1ydyBlbmNvZGluZw0KPiA+ICAg
ICAgICAgICstLXJ3IHByb3RvY29sDQo+ID4gICAgICAgICAgLi4uDQo+ID4gICAgICAgICAgKy0t
cncgcmVjZWl2ZXJzDQo+ID4gICAgICAgICAgICAgKy0tcncgcmVjZWl2ZXIqIFthZGRyZXNzIHBv
cnRdDQo+ID4gICAgICAgICAgICAgICAgLi4uDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgdGhpcyBp
cyAqbGVzcyogY29tcGxleCBhbmQgcHJvYmFibHkgbW9yZSBvcHRpbWFsIHRoYW4gdGhlDQo+ID4g
Y3VycmVudCBzb2x1dGlvbi4NCj4gPg0KPiA+ICJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJu
bikiIDxlaW5hcm5uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiBNYXJ0aW4sDQo+ID4gPg0KPiA+
ID4gQXMgeWV0LCB3ZSBoYXZlIG5vIHByYWN0aWNhbCB1c2UgY2FzZXMgd2hlcmUgd2Ugd291bGQg
aGF2ZSBhIHNpbmdsZQ0KPiA+ID4gY29uZmlndXJlZCBzdWJzY3JpcHRpb24gd2l0aCBtdWx0aXBs
ZSByZWNlaXZlcnMgd2hvIHdpc2ggdG8gcmVjZWl2ZQ0KPiA+ID4gdGhlIGRhdGEgaW4gZGlmZmVy
ZW50IGZvcm1hdHMuIFRodXMgc3VwcG9ydGluZyB0aGlzIHNlZW1zIGxpa2UgYW4NCj4gPiA+IHVu
bmVjZXNzYXJ5IGNvbXBsZXhpdHkgZm9yIHBsYXRmb3JtcywgYW5kIG9uZSB3aGljaCBwb3RlbnRp
YWxseQ0KPiA+ID4gaW1wYWN0cyBvcHRpbWlzYXRpb25zIHRoYXQgd2UgYWxyZWFkeSB1c2UgaW4g
c29tZSBwbGF0Zm9ybQ0KPiA+ID4gaW1wbGVtZW50YXRpb25zIChlLmcuIHNlbmRpbmcgdGhlIHNh
bWUgZW5jb2RlZCBQRFUgdG8gbXVsdGlwbGUNCj4gPiA+IHJlY2VpdmVycywgcmVsaWV2aW5nIHRo
ZSBwbGF0Zm9ybSBvZiBlbmNvZGluZyB0aGUgc2FtZSBkYXRhIG11bHRpcGxlDQo+ID4gPiB3YXlz
KS4NCj4gPg0KPiA+IEJ1dCB0aGlzIG9wdGltaXphdGlvbiBkb2Vzbid0IHJlYWxseSB3b3JrLCBh
cyB5b3Ugbm90ZSBiZWxvdyAoKikuDQo+ID4NCj4gPiA+IE9mIGNvdXJzZSwgaWYgYSBjbGllbnQg
cmVhbGx5IHdhbnRzIHRvIGhhdmUgdGhlIHNhbWUgZGF0YSBzZW50IHRvDQo+ID4gPiBtdWx0aXBs
ZSByZWNlaXZlcnMgYnV0IGluIGRpZmZlcmVudCBmb3JtYXRzLCB0aGV5IGNhbiBkbyB0aGlzIOKA
lCBqdXN0DQo+ID4gPiBwcm92aXNpb24gc2VwYXJhdGUgc3Vic2NyaXB0aW9ucyB3aXRoIHRoZSBz
YW1lIGZpbHRlci4NCj4gPg0KPiA+IEV4YWN0bHk7IHRoaXMgaXMgbW9yZSBjb21wbGV4IGFuZCBs
ZXNzIG9wdGltYWwgc2luY2UgdGhlIHNhbWUgZmlsdGVyDQo+ID4gbWlnaHQgYmUgZXZhbHVhdGVk
IHR3aWNlLCB1bmxlc3MgeW91IGFkZCBjb2RlIHRvIG9wdGltaXplIGZvciB0aGF0DQo+ID4gKHdo
aWNoIHByb2JhYmx5IGZhbGxzIGluIHlvdXIgY2F0ZWdvcnkgb2YgInVubmVjZXNzYXJ5IGNvbXBs
ZXhpdHkiKS4NCj4gPg0KPiA+ICgqKSBTbyBpZiB0aGUgb3BlcmF0b3IgcmVxdWlyZXMgdGhpcyBz
ZXR1cCwgaGUgd2lsbCBoYXZlIHRvIGNvbmZpZ3VyZQ0KPiA+IHR3byBkaWZmZXJlbnQgc3Vic2Ny
aXB0aW9ucyB0b2RheS4gIFRodXMsIHRoZSBwbGF0Zm9ybSB3aWxsIGVuY29kZSB0aGUNCj4gPiBk
YXRhIHR3aWNlLCBhbmQgeW91ciBvcHRpbWl6YXRpb24gYWJvdmUgd29uJ3QgaGVscC4NCj4gPg0K
PiA+ID4gQWxsLWluLWFsbCwgSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiBtYWtpbmcgdGhl
IGJhc2UgbW9kZWwgc3VwcG9ydA0KPiA+ID4gdGhpcywgb25seSBkb3duc2lkZXMsIHNvIGRvIHlv
dSBoYXZlIGFueSBzcGVjaWZpYyB1c2UgY2FzZXMgaW4gbWluZA0KPiA+ID4gd2hlcmUgdGhpcyB3
b3VsZCBiZSBhIGJlbmVmaXQ/IFNvIGZhciBpbiB0aGUgdXNlIGNhc2VzIHdlIGhhdmUNCj4gPiA+
IGxvb2tlZCBhdCBpbiBTUCwgREMsIGVudGVycHJpc2UgYW5kIElvVCB3ZSBoYXZlIG5vdCBzZWVu
IGFueQ0KPiA+ID4gcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCB0aGlzLCBidXQgd2UgaGF2ZSBzZWVu
IHRoZSBuZWVkIGZvciBtdWx0aXBsZQ0KPiByZWNlaXZlcnMgKGUuZy4NCj4gPiA+IHRvIHN1cHBv
cnQgSEEvcmVkdW5kYW5jeSBhcHByb2FjaGVzKS4NCj4gPg0KPiA+IFRoZSBjdXJyZW50IG1vZGVs
IHN1cHBvcnRzIGRpZmZlcmVudCAqcHJvdG9jb2xzKiBmb3IgdGhlIGRpZmZlcmVudA0KPiA+IHJl
Y2VpdmVycy4gIERvIHlvdSBoYXZlIGEgdXNlIGNhc2Ugc3VwcG9ydGluZyB0aGF0LCBvciB3b3Vs
ZCAoQikgYWJvdmUNCj4gPiBmdWxmaWwgeW91ciByZXF1aXJlbWVudHMuDQo+ID4NCj4gPg0KPiA+
IC9tYXJ0aW4NCj4gPg0KPiA+DQo+ID4NCj4gPiA+IEFzIHN1Y2gsIEkgd291bGQgYmUNCj4gPiA+
IHJlbHVjdGFudCB0byBhZGQgdGhpcyB0byB0aGUgZHJhZnQgYXQgdGhpcyBzdGFnZSB3aGVuIHRo
ZQ0KPiA+ID4gZnVuY3Rpb25hbGl0eSBjYW4gYmUgYWNoaWV2ZWQgYWxyZWFkeSBpZiBhYnNvbHV0
ZWx5IG5lY2Vzc2FyeS4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPg0KPiA+ID4gRWluYXIN
Cj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBPbiAxNSBOb3YgMjAxNywgYXQgMjE6NTMsIEVyaWMgVm9p
dCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiBBZGRp
bmcgRWluYXIgYXMgaGUgaGFkIHNvbWUgc3Ryb25nIG9waW5pb25zIG9uIHRoaXMgYSBmZXcgeWVh
cnMNCj4gPiA+ID4gYWdvIHdoZW4gd2Ugd2VyZSBzZXR0aW5nIHRoZSBtb2RlbC4uLg0KPiA+ID4g
Pg0KPiA+ID4gPg0KPiA+ID4gPj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCwgTm92ZW1iZXIgMTUs
IDIwMTcgMTA6NDMgQU0NCj4gPiA+ID4+DQo+ID4gPiA+PiAiRXJpYyBWb2l0IChldm9pdCkiIDxl
dm9pdEBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPj4+IEhpIE1hcnRpbiwNCj4gPiA+ID4+Pg0K
PiA+ID4gPj4+PiBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21d
DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+ICJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2Nv
LmNvbT4gd3JvdGU6DQo+ID4gPiA+Pj4+PiBJbiB0aGUgV0cgc2Vzc2lvbiB0b21vcnJvdywgSSBh
bSBob3BpbmcgdG8gZ2V0ICJodW0gZmVlZGJhY2siDQo+ID4gb246DQo+ID4gPiA+Pj4+Pg0KPiA+
ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gaHR0cHM6Ly9n
aXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNA0KPiA+ID4gPj4+Pj4NCj4g
PiA+ID4+Pj4+DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gVGhlIHR3byBjaG9pY2VzIGFuZCB0
aGVpciBpc3N1ZXMgZXhwb3NlZCBkdXJpbmcgdGhlIHR3byB3ZWVrDQo+ID4gPiA+Pj4+PiByZXZp
ZXcgb24NCj4gPiA+ID4+Pj4gIkNhbiBUcmFuc3BvcnQgdmFyeSBhY3Jvc3MgZGlmZmVyZW50IHJl
Y2VpdmVycyBvZiBhIHNpbmdsZQ0KPiA+ID4gPj4+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8i
IGFyZToNCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+
ICgxKSBZZXMsIFRyYW5zcG9ydCBjYW4gdmFyeSBieSByZWNlaXZlcg0KPiA+ID4gPj4+Pj4NCj4g
PiA+ID4+Pj4+ICogICAgICAgIEZld2VyIHN1YnNjcmlwdGlvbnMgKHNjYWxlIGJlbmVmaXQpDQo+
ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gKiAgICAgICAgQ2FuIGNvbnZlcnQgdHJhbnNwb3J0IHdp
dGhvdXQgcmVxdWlyaW5nIGFuIGFwcGxpY2F0aW9uIHRvDQo+ID4gbGVhcm4NCj4gPiA+ID4+IGEN
Cj4gPiA+ID4+Pj4gbXVsdGlwbGUgc3Vic2NyaXB0aW9uIGlkcw0KPiA+ID4gPj4+Pj4NCj4gPiA+
ID4+Pj4+ICogICAgICAgIE5vIGR1cGxpY2F0aW9uIG9mIGNvbnRlbnQgZHVyaW5nIHRyYW5zcG9y
dCBjb252ZXJzaW9uLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICogICAgICAgIChQb3RlbnRp
YWwgY29uZnVzaW9uIGluIGFsbG93aW5nIHRyYW5zcG9ydCB0byB2YXJ5LCBidXQNCj4gPiA+ID4+
Pj4+ICogICAgICAgIGVuY29kaW5nDQo+ID4gPiA+PiBub3QNCj4gPiA+ID4+Pj4gdG8gdmFyeT8p
DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAoMikg
Tm8sIG9ubHkgb25lIFRyYW5zcG9ydCBhY3Jvc3MgYWxsIHN1YnNjcmlwdGlvbnMNCj4gPiA+ID4+
Pj4+DQo+ID4gPiA+Pj4+PiAqICAgICAgICBTaW1wbGVyIG1vZGVsDQo+ID4gPiA+Pj4+Pg0KPiA+
ID4gPj4+Pj4gKiAgICAgICAgQnV0IGFwcGxpY2F0aW9ucyBtYXkgbmVlZCB0byBjcmVhdGUgYW5k
IHRyYWNrIG11bHRpcGxlDQo+ID4gPiA+Pj4+IHN1YnNjcmlwdGlvbi1pZHMgZm9yIHRoZSBzYW1l
IGNvbnRlbnQuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gKiAgICAgICAgVGVtcG9yYXJ5IGR1
cGxpY2F0aW9uIG9mIGNvbnRlbnQgc3RyZWFtcyBkdXJpbmcgdHJhbnNwb3J0DQo+ID4gPiA+PiBj
aGFuZ2UuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+
PiBUaGUgY3VycmVudCBkcmFmdCBkb2VzICgxKS4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gQWN0
dWFsbHksIHRoZSBnaXRodWIgaXNzdWUgbGlzdHMgMyBvcHRpb25zLCBidXQgaGVyZSB5b3UganVz
dCBsaXN0IDIuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJbiByZXZpZXdpbmcgdG9tb3Jyb3cncyBz
bGlkZXMgd2l0aCBNYWhlc2gsIGhlIHByZWZlcnJlZCAyDQo+IG9wdGlvbnMuDQo+ID4gPiA+Pj4g
QW5kIGFzIHZhcnlpbmcgdGhlIGVuY29kaW5nIGJ5IHJlY2VpdmVyIHNlZW1zIHVubGlrZWx5IGlu
DQo+ID4gPiA+Pj4gaW1wbGVtZW50YXRpb24NCj4gPiA+ID4+DQo+ID4gPiA+PiBXaHkgaXMgdGhp
cyB1bmxpa2VseT8gIFN1cHBvc2UgSSBoYXZlIHR3byByZWNlaXZlcnMgZm9yIHRoZSBzYW1lDQo+
ID4gPiA+PiBzdWJzY3JpcHRpb24sIG9uZSB3YW50cyBORVRDT05GL1hNTCBhbmQgdGhlIG90aGVy
DQo+ID4gUkVTVENPTkYvSlNPTi4NCj4gPiA+ID4+IElzIHRoYXQgdW5saWtlbHk/DQo+ID4gPiA+
DQo+ID4gPiA+IEVpbmFyJ3MgYmVsaWVmIHdhcyB0aGF0IGEgcHVibGlzaGVyIGltcGxlbWVudGF0
aW9uIHdvdWxkIGJlDQo+ID4gPiA+IHVubGlrZWx5IHRvIHNlcnZpY2UgYSBzaW5nbGUgc3Vic2Ny
aXB0aW9uIGludG8gbXVsdGlwbGUgZW5jb2RpbmdzLg0KPiA+ID4gPiBJZiBzdWNoIGEgY29uZGl0
aW9uIGV4aXN0ZWQsIGl0IHdvdWxkIGJlIGZhciBlYXNpZXIgdG8gY3JlYXRlIHR3bw0KPiBzdWJz
Y3JpcHRpb25zLg0KPiA+ID4gPiBUaGlzIGFsc28gd291bGQgaGF2ZSBmZXdlciBlcnJvciBjb25k
aXRpb25zLg0KPiA+ID4gPg0KPiA+ID4gPj4+ICwgdGhlcmUgaXMgbGl0dGxlIHJlYXNvbiB0byBz
b2NpYWxpemUgdGhpcyB1bmxpa2VseSB2YXJpYW50IGJlZm9yZQ0KPiA+ID4gPj4+IHRoZSB3aG9s
ZSBXRy4gICBTaW5jZSBhcyB5b3VyIG9waW5pb24gd2FzIGVpdGhlciBib3RoIGVuY29kaW5nDQo+
IGFuZA0KPiA+ID4gPj4+IHRyYW5zcG9ydCBvciBuZWl0aGVyIGVuY29kaW5nIGFuZCB0cmFuc3Bv
cnQgdmFyeSBieSByZWNlaXZlciwNCj4gPiA+ID4+PiB0aGUgbW9yZSBsaWtlbHkgb2YgeW91ciBw
cmltYXJ5IGFzayBpcyBzdXBwb3J0ZWQuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+
PiBJIHRoaW5rIHRoZSBwb2ludCBpcyB0aGF0IGluIHRoZSB0ZXJtICJUcmFuc3BvcnQiLCB3ZSBu
ZWVkIHRvDQo+ID4gPiA+Pj4+IGluY2x1ZGUgYm90aCBwcm90b2NvbCBhbmQgZW5jb2RpbmcgKGlu
IHRoZSBjYXNlIHRoZSBwcm90b2NvbA0KPiA+ID4gPj4+PiBzdXBwb3J0cyBtdWx0aXBsZSBlbmNv
ZGluZ3MpLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gV2hpbGUgbW9zdCBsaWtlbHkgdGhlIGNhc2Ug
Zm9yIE5FVENPTkYgYW5kIFJFU1RDT05GLCBUaWFucmFuJ3MNCj4gPiA+ID4+PiBkcmFmdC1pZXRm
LW5ldGNvbmYtdWRwLXB1Yi1jaGFubmVsIHNob3dzIHRoYXQgdGhlcmUgY2FuIGJlDQo+IGVuY29k
aW5nDQo+ID4gPiA+Pj4gdmFyaWF0aW9uIGJ5IHRyYW5zcG9ydHMgLiAgIEl0IFRoZXJlZm9yZSBp
dCBzZWVtcyBiZXR0ZXIgdG8gbGV0IHRoZW0NCj4gPiA+ID4+PiBib3RoIHZhcnkgaW5kZXBlbmRl
bnRseS4NCj4gPiA+ID4+DQo+ID4gPiA+PiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3Ug
bWVhbi4gIFRvIGJlIGNsZWFyLCBkbyB5b3UgdGhpbmsNCj4gPiA+ID4+IHRoZSAiZW5jb2Rpbmci
IGxlYWYgc2hvdWxkIHN0YXkgd2hlcmUgaXQgaXMsIG9yIGJlIG1vdmVkIGRvd24gdG8NCj4gPiA+
ID4+IHRoZSByZWNlaXZlciwgYXMgYSBzaWJsaW5nIHRvICJwcm90b2NvbCI/DQo+ID4gPiA+DQo+
ID4gPiA+IEVuY29kaW5nIGxlYWYgc2hvdWxkIHN0YXkgd2hlcmUgaXQgaXMuICBZb3VyIHByZXZp
b3VzIGFzayB3YXMgdG8NCj4gPiA+ID4gcHV0IGVuY29kaW5nIGFuZCB0cmFuc3BvcnQgYW5kIHRo
ZSBzYW1lIGxldmVsLiBUaGVyZSBpcyBhbiBvcHRpb24NCj4gPiA+ID4gcHJvcG9zZWQgaW4gdGhl
IHNsaWRlcyB3aGljaCBkb2VzIHRoYXQuDQo+ID4gPiA+DQo+ID4gPiA+IEVyaWMNCj4gPiA+ID4N
Cj4gPiA+ID4+IC9tYXJ0aW4NCj4gPiA+ID4NCj4gPiA+DQo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5l
dGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRjb25mDQo=


From nobody Fri Nov 17 10:17:32 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1611200FC for ; Fri, 17 Nov 2017 10:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 KxrsJrHHu-nd for ; Fri, 17 Nov 2017 10:17:25 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D306C1243FE for ; Fri, 17 Nov 2017 10:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32906; q=dns/txt; s=iport; t=1510942644; x=1512152244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hEw1A0W0Ny/+EI8R1tqwNahTluvbTlgVxxVBPgjko0k=; b=KJve4R2fEaQK7zg4ie10ji8joCazhV5nfum42s7l4O72HOuk6tfmgaCq EFlJk3ywjKGUJhqOE01UsB5mjJP/+o9Fh057ZK3Pos2rSGuAXd3yGmhr3 LcKNmik0YKZLDLklfgsTEg9iOL2gj7nJMQe7ne3oB08ZpC7jklCWS2fzH o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQBnJg9a/4ENJK1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkQuZG4nB44XjyaBfZZigg4DChgBCoQDRk8ChGc/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR4BAQEBAwEBK0ELEAIBCBEEAQEOEwEGBycLFAkIAQEEAQ0FCIk5Z?= =?us-ascii?q?BCsUCaKVAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVhRSEcARdhUIFkXS?= =?us-ascii?q?HLokcAodwjRGTVYxyiRMCERkBgTkBHzmBdHoVSYJkgxGBTneIEgIlB4EFgREBA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.44,410,1505779200";  d="scan'208,217";a="321944558"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2017 18:17:22 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAHIHMWK031130 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Nov 2017 18:17:22 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 17 Nov 2017 13:17:21 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Fri, 17 Nov 2017 13:17:21 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kA==
Date: Fri, 17 Nov 2017 18:17:21 +0000
Message-ID: <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.39.151]
Content-Type: multipart/alternative; boundary="_000_383a834a60eb489a9e4fbb9bdf5a5c43XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 18:17:27 -0000

--_000_383a834a60eb489a9e4fbb9bdf5a5c43XCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would like to continue the discussion on this topic from our session.   I=
 think we came to agreement among the attendees.   Hopefully this thread ca=
n confirm, or refine as need.

First let's look at Robert's proposal below:
There are lots of good elements in Robert's proposal below, but it isn't up=
 to our WG to determine the proper structure of the network-instance-model.=
   Authors of that model were in the room, and are aware that YANG model de=
velopers from outside would welcome a partitioning which decouples any link=
ages to schema-mount when all that is needed is to identify a VRF by name.

Looking at what we can control, discussed in the room was the following cha=
nge to subscribed-notifications:

1.      import "ietf-network-instance"

2.      create if-feature "VRF".

3.      apply feature "VRF" to object "source-VRF"

4.      Leafref to "source-VRF" to validate against the network-instance mo=
del's /network-instances/network-instance/name.

This is the current proposal.  Are there are concerns/objections/refinement=
s?

Eric



From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo=
it)
Sent: Tuesday, November 14, 2017 10:23 PM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) ; netconf@ietf.org; Lou Berger 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configur=
ed subscription?

Agree it is a generic problem.

I would defer to Lou and the other authors of draft-ietf-rtgwg-ni-model as =
this would be a fairly significant change.

Eric

From: Robert Wilton, November 14, 2017 7:58 PM

Hi Eric, Lou,

This seems to be a generic problem.

Could the VRF leafref name dependency issue be solved with an if-feature st=
atement?.

I.e.could the network instance draft define a separate YANG module (with no=
 dependencies) that defines a "VRF" feature.

All the VRF references (ideally if all IETF YANG modules that may optionall=
y depend on VRFs) could be leaf-refs to /network-instances/network-instance=
/name but predicated with an if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the "vrf"=
 feature, so it doesn't have to implement the full network instances module=
, or schema mount.

Thanks,
Rob

On 15/11/2017 08:45, Eric Voit (evoit) wrote:

In the WG session tomorrow, I am hoping to get "hum feedback" on:



draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/5



The two choices exposed during the two week review for how to represent Sou=
rce VRF of configured subscription were:



(1) Leafref to "ietf-network-instance"  /network-instances/network-instance=
/name

*        Creates dependency on schema mount for subscriptions.

*        Source VRF is an optional capability, but publishers that don't ca=
re about VRFs must still import.  (Note: could also augment the leafref in =
another model, but that adds another layer of complexity)

*        establishes model dependency to draft-ietf-rtgwg-ni-model



(2) Use a string which would be populated with exact same name as would be =
in the leafref of (1)

*        Possible to name VRF which doesn't exist



The current draft does (2).



Thanks,

Eric





_______________________________________________

Netconf mailing list

Netconf@ietf.org

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


--_000_383a834a60eb489a9e4fbb9bdf5a5c43XCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I would like to continue the discussion on this topic from our s=
ession.   I think we came to agreement
 among the attendees.   Hopefully this thread can confirm, or ref=
ine as need.


 


First let’s look at Robert’s proposal below:


There are lots of good elements in Robert’s proposal below=
, but it isn’t up to our WG to determine the
 proper structure of the network-instance-model.   Authors of tha=
t model were in the room, and are aware that YANG model developers from out=
side would welcome a partitioning which decouples any linkages to schema-mo=
unt when all that is needed is to identify
 a VRF by name.


 


Looking at what we can control, discussed in the room was the fo=
llowing change to subscribed-notifications:
  


1.&n=
bsp;    
import
“ietf-network-instance” 


2.&n=
bsp;    
create if-feature “VRF”.  


3.&n=
bsp;    
apply feature “VRF” to object “source-=
VRF”


4.&n=
bsp;    
Leafref to “source-VRF” to validate against =
the network-instance model’s /network-instances/network-instance/name=
. 



 


This is the current proposal.  Are there are concerns/objec=
tions/refinements?


 


Eric


 


 


 








From:=
 Netconf [mailto:netconf-bounces@ietf.org]
On Behalf Of Eric Voit (evoit)

Sent: Tuesday, November 14, 2017 10:23 PM

To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwilton=
@cisco.com>; netconf@ietf.org; Lou Berger <lberger@labn.net>

Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of c=
onfigured subscription?






 


Agree it is a generic =
problem. 



 


I would defer to Lou a=
nd the other authors of draft-ietf-rtgwg-ni-model as this would be a fairly=
 significant change.


 


Eric 


 








From: Robert Wil=
ton, November 14, 2017 7:58 PM






Hi Eric, Lou,


This seems to be a generic problem.


Could the VRF leafref name dependency issue be solved with an if-feature=
 statement?.


I.e.could the network instance draft define a separate YANG module (with=
 no dependencies) that defines a "VRF" feature.


All the VRF references (ideally if all IETF YANG modules that may option=
ally depend on VRFs) could be leaf-refs to /network-instances/network-insta=
nce/name but predicated with an if-feature "ni:vrf".

Hence if a device doesn't support VRFs, then it doesn't implement the &q=
uot;vrf" feature, so it doesn't have to implement the full network ins=
tances module, or schema mount.


Thanks,

Rob


 




On 15/11/2017 08:45, Eric Voit (evoit) wrote:






In the WG session tomorrow, I am hoping to get &#=
8220;hum feedback” on:


 


draft-ietf-netconf-subscribed-notifications =



https://github.com/netconf-wg/rfc5277bis/issues/5



 


The two choices exposed during the two week revie=
w for how to represent Source VRF of configured subscription were:


 


(1) Leafref to “ietf-network-instance”=
;  /network-instances/network-instance/name



·       
Creates dependency on schema mount for subsc=
riptions.




·       
Source VRF is an optional capability, but pu=
blishers that don’t care about VRFs must still import.  (Note: c=
ould also augment the leafref in another model, but that adds another layer=
 of complexity)



·       
establishes model dependency to draft-ietf-r=
tgwg-ni-model


 


(2) Use a string which would be populated with ex=
act same name as would be in the leafref of (1)



·       
Possible to name VRF which doesn’t exi=
st


 


The current draft does (2).   


 


Thanks,


Eric 


 









_______________________________________________


Netconf mailing list


Netconf@ietf.org

https://www.=
ietf.org/mailman/listinfo/netconf




 










--_000_383a834a60eb489a9e4fbb9bdf5a5c43XCHRTP013ciscocom_--


From nobody Fri Nov 17 10:45:55 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEC6126BF6 for ; Fri, 17 Nov 2017 10:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.489
X-Spam-Level: 
X-Spam-Status: No, score=-14.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 lVa6kH52MSgq for ; Fri, 17 Nov 2017 10:45:51 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73896124C27 for ; Fri, 17 Nov 2017 10:45:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37381; q=dns/txt; s=iport; t=1510944350; x=1512153950; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=RpfEmIjh48bB6t8irHDVE4flxp2lCCuijcB5FpTMcko=; b=ls2kB8B4hS/9Zmx6ZQ89y5ZVcwRhQlUHMQRk879og2DoXl3NQAx12z7G yLtxneG2nQrdIjHQtnu+6AWVaX9ZW8/RBDvAFlXZvpwPdIP2sfecjbCdx r1t8qs8N7pj+f03scB5UQNtX12JORr3EldL0pLY04L8Ubb4Rpz8AkK8Ah M=;
X-IronPort-AV: E=Sophos;i="5.44,410,1505779200"; d="scan'208,217";a="336657"
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; 17 Nov 2017 18:45:48 +0000
Received: from [10.61.226.53] ([10.61.226.53]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAHIjmEg028610; Fri, 17 Nov 2017 18:45:48 GMT
To: "Eric Voit (evoit)" , "netconf@ietf.org" , Lou Berger 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com>
From: Robert Wilton 
Message-ID: <31442888-3dba-7834-c408-bd7986b9e381@cisco.com>
Date: Fri, 17 Nov 2017 18:45:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com>
Content-Type: multipart/alternative; boundary="------------42A1B67DB94CDCE6B0B0EBFC"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 18:45:53 -0000

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


On 17/11/2017 18:17, Eric Voit (evoit) wrote:
>
> I would like to continue the discussion on this topic from our 
> session.   I think we came to agreement among the attendees.   
> Hopefully this thread can confirm, or refine as need.
>
> First let’s look at Robert’s proposal below:
>
> There are lots of good elements in Robert’s proposal below, but it 
> isn’t up to our WG to determine the proper structure of the 
> network-instance-model.   Authors of that model were in the room, and 
> are aware that YANG model developers from outside would welcome a 
> partitioning which decouples any linkages to schema-mount when all 
> that is needed is to identify a VRF by name.
>
> Looking at what we can control, discussed in the room was the 
> following change to subscribed-notifications:
>
> 1.import “ietf-network-instance”
>
> 2.create if-feature “VRF”.
>
> 3.apply feature “VRF” to object “source-VRF”
>
> 4.Leafref to “source-VRF” to validate against the network-instance 
> model’s /network-instances/network-instance/name.
>
> This is the current proposal. Are there are 
> concerns/objections/refinements?
>

No concerns, but perhaps one trivial refinement.

I had mistakenly thought that a device would either support VRFs for all 
protocols or none, hence my suggestion to have a single "VRF" feature, 
which would naturally be defined by the network-instances model.

In the discussions that I had with Lou, some of them at the mic, some 
afterwards, Lou clarified that it quite plausible that VRFs may only be 
supported by some protocols on a device and not all, and hence the 
solution of having a "VRF" feature per protocol seems like the right 
solution.

I think that I would call the feature "supports-vrf" rather than "vrf".

Thanks,
Rob


> Eric
>
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Eric 
> Voit (evoit)
> *Sent:* Tuesday, November 14, 2017 10:23 PM
> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
> ; netconf@ietf.org; Lou Berger 
> *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> Agree it is a generic problem.
>
> I would defer to Lou and the other authors of 
> draft-ietf-rtgwg-ni-model as this would be a fairly significant change.
>
> Eric
>
> *From:*Robert Wilton, November 14, 2017 7:58 PM
>
> Hi Eric, Lou,
>
> This seems to be a generic problem.
>
> Could the VRF leafref name dependency issue be solved with an 
> if-feature statement?.
>
> I.e.could the network instance draft define a separate YANG module 
> (with no dependencies) that defines a "VRF" feature.
>
> All the VRF references (ideally if all IETF YANG modules that may 
> optionally depend on VRFs) could be leaf-refs to 
> /network-instances/network-instance/name but predicated with an 
> if-feature "ni:vrf".
>
> Hence if a device doesn't support VRFs, then it doesn't implement the 
> "vrf" feature, so it doesn't have to implement the full network 
> instances module, or schema mount.
>
> Thanks,
> Rob
>
> On 15/11/2017 08:45, Eric Voit (evoit) wrote:
>
>     In the WG session tomorrow, I am hoping to get “hum feedback” on:
>
>     draft-ietf-netconf-subscribed-notifications
>
>     https://github.com/netconf-wg/rfc5277bis/issues/5
>
>     The two choices exposed during the two week review for how to
>     represent Source VRF of configured subscription were:
>
>     (1) Leafref to “ietf-network-instance”
>     /network-instances/network-instance/name
>
>     ·Creates dependency on schema mount for subscriptions.
>
>     ·Source VRF is an optional capability, but publishers that don’t
>     care about VRFs must still import.  (Note: could also augment the
>     leafref in another model, but that adds another layer of complexity)
>
>     ·establishes model dependency to draft-ietf-rtgwg-ni-model
>
>     (2) Use a string which would be populated with exact same name as
>     would be in the leafref of (1)
>
>     ·Possible to name VRF which doesn’t exist
>
>     The current draft does (2).
>
>     Thanks,
>
>     Eric
>
>
>
>     _______________________________________________
>
>     Netconf mailing list
>
>     Netconf@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netconf
>
> . 


--------------42A1B67DB94CDCE6B0B0EBFC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 17/11/2017 18:17, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
I would like to continue the
              discussion on this topic from our session.   I think we
              came to agreement among the attendees.   Hopefully this
              thread can confirm, or refine as need.

        
 

        
First let’s look at Robert’s
              proposal below:

        
There are lots of good elements
              in Robert’s proposal below, but it isn’t up to our WG to
              determine the proper structure of the
              network-instance-model.   Authors of that model were in
              the room, and are aware that YANG model developers from
              outside would welcome a partitioning which decouples any
              linkages to schema-mount when all that is needed is to
              identify a VRF by name.

        
 

        
Looking at what we can control,
              discussed in the room was the following change to
              subscribed-notifications:  

        
1.     
              import
            “ietf-network-instance” 

        
2.     
              create if-feature “VRF”.  

        
3.     
              apply feature “VRF” to object
              “source-VRF”

        
4.     
              Leafref to “source-VRF” to
              validate against the network-instance model’s
              /network-instances/network-instance/name. 
            

        
 

        
This is the current proposal. 
              Are there are concerns/objections/refinements?

      

    

    

    No concerns, but perhaps one trivial refinement.

    

    I had mistakenly thought that a device would either support VRFs for
    all protocols or none, hence my suggestion to have a single "VRF"
    feature, which would naturally be defined by the network-instances
    model.

    

    In the discussions that I had with Lou, some of them at the mic,
    some afterwards, Lou clarified that it quite plausible that VRFs may
    only be supported by some protocols on a device and not all, and
    hence the solution of having a "VRF" feature per protocol seems like
    the right solution.

    

    I think that I would call the feature "supports-vrf" rather than
    "vrf".

    

    Thanks,

    Rob

    

    

    

      

        

        
 

        
Eric

        
 

        
 

        
 

        

          

            

              
From: Netconf
                  [mailto:netconf-bounces@ietf.org]
                  On Behalf Of Eric Voit (evoit)

                  Sent: Tuesday, November 14, 2017 10:23 PM

                  To: Robert Wilton -X (rwilton - ENSOFT LIMITED
                  at Cisco) <rwilton@cisco.com>; netconf@ietf.org;
                  Lou Berger <lberger@labn.net>

                  Subject: Re: [Netconf] Issue SN #5: How to
                  represent Source VRF of configured subscription?

            

          

          
 

          
Agree it is a
              generic problem. 
              

          
 

          
I would defer
              to Lou and the other authors of draft-ietf-rtgwg-ni-model
              as this would be a fairly significant change.

          
 

          
Eric 

          
 

          

            

              

                
From: Robert Wilton, November
                    14, 2017 7:58 PM

              

            

            
Hi Eric, Lou,

            
This seems to be a generic problem.

            
Could the VRF leafref name dependency issue be solved
              with an if-feature statement?.

            
I.e.could the network instance draft define a separate
              YANG module (with no dependencies) that defines a "VRF"
              feature.

            
All the VRF references (ideally if all IETF YANG modules
              that may optionally depend on VRFs) could be leaf-refs to
              /network-instances/network-instance/name but predicated
              with an if-feature "ni:vrf".

            
Hence if a device doesn't support VRFs, then it doesn't
              implement the "vrf" feature, so it doesn't have to
              implement the full network instances module, or schema
              mount.

            
Thanks,

              Rob

            
 

            

              
On 15/11/2017 08:45, Eric Voit
                (evoit) wrote:

            

            

              
In the WG session tomorrow, I am
                hoping to get “hum feedback” on:

              
 

              
draft-ietf-netconf-subscribed-notifications
                

              
https://github.com/netconf-wg/rfc5277bis/issues/5
                

              
 

              
The two choices exposed during the
                two week review for how to represent Source VRF of
                configured subscription were:

              
 

              
(1) Leafref to
                “ietf-network-instance” 
                /network-instances/network-instance/name

              

                ·       
                    Creates
                dependency on schema mount for subscriptions.
                

              

                ·       
                    Source VRF is an
                optional capability, but publishers that don’t care
                about VRFs must still import.  (Note: could also augment
                the leafref in another model, but that adds another
                layer of complexity)

              

                ·       
                    establishes model
                dependency to draft-ietf-rtgwg-ni-model

              
 

              
(2) Use a string which would be
                populated with exact same name as would be in the
                leafref of (1)

              

                ·       
                    Possible to name
                VRF which doesn’t exist

              
 

              
The current draft does (2).   

              
 

              
Thanks,

              
Eric 

              
 

              


                  

                  

              
_______________________________________________

              
Netconf mailing list

              
Netconf@ietf.org

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

            

            
 

          

        

      

      .
    

    

  


--------------42A1B67DB94CDCE6B0B0EBFC--


From nobody Fri Nov 17 11:03:23 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF63D12717E for ; Fri, 17 Nov 2017 11:03:21 -0800 (PST)
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 Fpsut8J_jjGf for ; Fri, 17 Nov 2017 11:03:19 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 295B3124C27 for ; Fri, 17 Nov 2017 11:03:19 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id i14so3784286lfc.1 for ; Fri, 17 Nov 2017 11:03:19 -0800 (PST)
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=tG+kVAnqqYn6D8vbdiIPsY41FcuzjaMP4CM8M+7Wiaw=; b=I4NuoYWgA0biQxdgUvecddyQiZouzRt8/uP0KVpdlkNkSYDJOR72r9j9lbm3Eoy8Wz rUO8PeGuE3QX0R2dQImN/7e2CWBDaVMULaMGbAPj+vUbYG3q/wNvGkyDmX7C01+l68T8 wFxEqTM2+iFcqZx2rA6dRJGLJWBJUyzPCIQkDz/sfxMzC+o0E6jrpffkaFtZD9IwkefB nu8eaihmJCcmZ8X3qcCt1ojvdXPP4eBP62M8dfAOIOlwtjpQpM0VxQIZbZmlIMUlXcBc DR1hkXsYlniDK1mxZbaf4gkDiJoWtw6TsKR/2MsXmz+80uxfqckSG3dg7/Yr6/PA04LZ RAnA==
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=tG+kVAnqqYn6D8vbdiIPsY41FcuzjaMP4CM8M+7Wiaw=; b=saCzTpJr6Osj4Skv+2wjP1SUT2x4jl12cdZXVtn3VdL+BYE5FQKJ0j1h8V6dmGeJAK dDSwEPiHXlrz9uNLjqF7bZxY8vjRr436IQvAxQT0haIC5Pgw51N2ZSIiiS5A8AfEf8xR asca69kahxfo1S9/UvqgmqgWlVSoe6+MrR1YYbIJyc1UPNlEuwW8Yaqyd3irDDWPno1I dB+TATXCwFwMA0cfs6iQWR0DQbFZ3Zf+Gu+ezSNGWq8FIxJCoU9Y68PjT14/3grnWRHB lCYo/9SEGM/F7AZufODuuGAiokX8o168bMimZk7C/UIuJSTjV14rzyw1R51WdCTCbJOU BaWg==
X-Gm-Message-State: AJaThX5yyJnGn436Fu+xxg30JTLONPtaSHHoAWsx50g+CDyAdHcJ+QEG fg54KtvueJznDPxvTqnvkluZCmCtc+qVhXXMIIqIWQ==
X-Google-Smtp-Source: AGs4zMZE+tHCdIPyWD+CwVuCeFkc2wTmQEIaXwpsXbawNqln13lO0g54RUwpRFdSYCMZePcz0VdAR/0ps2/JRQfy5p0=
X-Received: by 10.25.162.140 with SMTP id l134mr1137564lfe.126.1510945397334;  Fri, 17 Nov 2017 11:03:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Fri, 17 Nov 2017 11:03:16 -0800 (PST)
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B14A1A7@DGGEMA502-MBS.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B14A1A7@DGGEMA502-MBS.china.huawei.com>
From: Andy Bierman 
Date: Fri, 17 Nov 2017 11:03:16 -0800
Message-ID: 
To: Rohit R Ranade 
Cc: "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411a4caefcd4055e32634b"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Edit proposal
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 19:03:22 -0000

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

Hi,


I don't think any changes are needed.
If the NETCONF and RESTCONF protocols are not supported
by the same server, then there should be separate server instances.


Andy


On Fri, Nov 17, 2017 at 3:17 AM, Rohit R Ranade 
wrote:

> Hi Andy,
>
>
>
> If we want to use the NACM  module for RESTCONF also , then I propose the
> below changes.
>
>
>
> OLD:
>
> leaf denied-operations {
>
>          type yang:zero-based-counter32;
>
>          config false;
>
>          mandatory true;
>
>          description
>
>            "Number of times since the server last restarted that a
>
>             protocol operation request was denied.";
>
>        }
>
>
>
> NEW:
>
> leaf denied-operations {
>
>          type yang:zero-based-counter32;
>
>          config false;
>
>          mandatory true;
>
>          description
>
>            "Number of times since the *NETCONF *server last restarted
> that a
>
>             protocol operation request was denied by the *NETCONF *
> server.";
>
>        }
>
> =C3=A8 To keep the meaning similar to RFC 6536
>
>
>
> NEW:
>
> ADD =E2=80=9Cleaf restconf-denied-operations=E2=80=9D to provide the valu=
es for state-data
> corresponding to the RESTCONF server.
>
>
>
> Another way was to mention that =E2=80=9Cdenied-operations=E2=80=9D is th=
e total number of
> times the request was denied across all servers after they were started.
> But since RESTCONF/NETCONF Servers MAY be started / stopped at different
> time a combined total did not seem right.
>
>
>
> With Regards,
>
> Rohit R
>
>
>
> *From:* Rohit R Ranade
> *Sent:* 15 November 2017 10:42
> *To:* netconf@ietf.org
> *Subject:* [Netconf] draft-ietf-netconf-rfc6536bis Query
>
>
>
> Hi All,
>
>
>
> For the state-data in NACM like the below :
>
>
>
> leaf denied-operations {
>
>          type yang:zero-based-counter32;
>
>          config false;
>
>          mandatory true;
>
>          description
>
>            "Number of times since the server last restarted that a
>
>             protocol operation request was denied.";
>
>        }
>
>
>
> =E2=80=9CNumber of times since the server=E2=80=9D =C3=A8 Here the server=
 is being referenced
> to NETCONF server or RESTCONF server ?
>
> Please note that the both the NETCONF server and RESTCONF server maybe
> using the same NACM configurations but the state-data maintained by each
> protocol maybe different.
>
>
>
> With Regards,
>
> Rohit R
>

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


Hi,


I don't think an=
y changes are needed.
If the NETCONF and RESTCONF protocols are n=
ot supported
by the same server, then there should be separate se=
rver instances.


Andy

=


On Fri, Nov 17, 2=
017 at 3:17 AM, Rohit R Ranade <rohitrranade@huawei.com> wrote:











Hi Andy=
,


=
=C2=A0


If we w=
ant to use the NACM =C2=A0module for RESTCONF also , then I propose the bel=
ow changes.


=
=C2=A0


OLD:=



leaf denied-operations {=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 type yang:zero-based-counter32;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 config false;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 mandatory true;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 description


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "Number of times since the server last restarted that =
a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 protocol operation request was denied.";<=
u>


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



=
=C2=A0


NEW:=



leaf denied-operations {=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 type yang:zero-based-counter32;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 config false;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 mandatory true;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 description


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "Number of times since the
NETCONF server last restarted that a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 protocol operation request was denied by the
NETCONF server.";


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




<=
span>=C3=A8
To=
 keep the meaning similar to RFC 6536


=
=C2=A0


NEW:=



ADD =E2=80=9Cleaf restconf-deni=
ed-operations=E2=80=9D to provide the values for state-data corresponding t=
o the RESTCONF server.


=C2=A0


Another way was to mention that=
 =E2=80=9Cdenied-operations=E2=80=9D is the total number of times the reque=
st was denied across all servers after they were started. But since
 RESTCONF/NETCONF Servers MAY be started / stopped at different time a comb=
ined total did not seem right.


=
=C2=A0


With Re=
gards,


Rohit R=



=
=C2=A0






From: Rohit R Ranade


Sent: 15 November 2017 10:42

To: netconf@ie=
tf.org

Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query=







=C2=A0


Hi All,

=C2=A0


For the state-data in NACM like=
 the below :


=C2=A0


leaf denied-operations {=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 type yang:zero-based-counter32;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 config false;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 mandatory true;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 description


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "Number of times since the server last restarted that =
a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 protocol operation request was denied.";<=
u>


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



=C2=A0


=E2=80=9CNumber of times since the server=E2=80=9D
=C3=A8 Here the server is being referenced to NETCONF server o=
r RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.


=C2=A0


With Regards,


Rohit R









--001a11411a4caefcd4055e32634b--


From nobody Fri Nov 17 12:16:18 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46258128891; Fri, 17 Nov 2017 12:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4Fg_44FTk3x; Fri, 17 Nov 2017 12:16:14 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741BB120454; Fri, 17 Nov 2017 12:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58147; q=dns/txt; s=iport; t=1510949773; x=1512159373; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=hG0DKa3j9FbCytG301GKHoihWicr+eDAr3I2LehTwls=; b=Ikzm2ss4aRJc3HL1eqpBWi6Q4eI06zU9fmbbFKRvXRcUDpgW6YmzBMu9 tJ489MEeDECfwTDxrGN+/qEvDYekPv3DJpxzuvsrys87LBUIOQphoNSIP j/Swv0LoZUcXfPZLOB7N31P42wKBgKGdrCN3VTqXsava5mNVCfwKzQa9x U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAAtQw9a/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgVZuJ4N/ih90kAkmiFyOBoIOAwoYAQqESU8ChSYYAQEBAQE?= =?us-ascii?q?BAQEBayiFHwEBAQMBASFLCxAJAg4KIAEGAwICIQYfEQYNBgIBAYoJAxUQjD2da?= =?us-ascii?q?IInJocRDYM1AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYM0g1yBaSkLgneCa4Iagyu?= =?us-ascii?q?CYwWKKYk9hTyIXz2HcoghhHmCFmKJDCSHJIo1gneBEod0gTofOUKBMjQhCB0VS?= =?us-ascii?q?YJkCYIaboFOQTaIFCyCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,411,1505779200"; d="scan'208,217";a="338837"
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; 17 Nov 2017 20:16:09 +0000
Received: from [10.61.226.53] ([10.61.226.53]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAHKG8jm026439; Fri, 17 Nov 2017 20:16:09 GMT
To: Mahesh Jethanandani 
Cc: Andy Bierman , sec-ads@ietf.org, netconf , Eric Rescorla 
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>    <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com> <91F5996E-16B2-443D-B826-3A3116E8FA48@gmail.com>
From: Robert Wilton 
Message-ID: <041e8574-4eb2-315d-1259-357185065b6b@cisco.com>
Date: Fri, 17 Nov 2017 20:16:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <91F5996E-16B2-443D-B826-3A3116E8FA48@gmail.com>
Content-Type: multipart/alternative; boundary="------------6CBECA711430F95E28A8B262"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 20:16:17 -0000

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

The updated text looks OK to me.

We also need to delete this paragraph from the end of section 1.2:

REMOVE:
    The server message processing behavior for the edit operation "none",
    used in the , has been changed.  Now read access is
    required for such data nodes, instead of no access required.

Thanks,
Rob


On 16/11/2017 11:40, Mahesh Jethanandani wrote:
> I have verified that the proposed changes have been incorporated in 
> -09 version of the draft in GitHub.
>
> Based on my discussion with Eric, there is a little more tweak that we 
> need to provide to Security Considerations section in the third 
> paragraph.
>
> OLD:
>     There is a risk related to the lack of access control enforcement for
>     the RESTCONF OPTIONS method.  The risk here is that the response to
>     OPTIONS may vary based on the presence or absence of a resource
>     corresponding to the URL's path.  If this is the case, then it can be
>     used to trivially probe for the presence or absence of values within
>     a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
>     based on the existence of the underlying resource, which would
>     indicate the presence or absence of resource instances.
> NEW:
>     There is a risk related to the lack of access control enforcement for
>     the RESTCONF OPTIONS and PATCH methods.  The risk here is that the response to
>     OPTIONS and PATCH may vary based on the presence or absence of a resource
>     corresponding to the URL's path.  If this is the case, then it can be
>     used to trivially probe for the presence or absence of values within
>     a tree.  Therefore, a server MUST NOT vary its responses
>     based on the existence of the underlying resource, which would
>     indicate the presence or absence of resource instances.In particular
>     servers should not expose any instance information before ensuring
>     that the client has the necessary access permissions to obtain that
>     information. In such cases, servers are expected to always return the “access-
> denied” error response.
>
>
>> On Nov 16, 2017, at 1:56 PM, Robert Wilton > > wrote:
>>
>> I'm not sure I understand exactly what point the previous text was 
>> stating so I'm not sure whether my proposed text is stating the same 
>> thing (or whether this has already been stated elsewhere in the draft):
>>
>> OLD:
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances. In particular
>> servers should not expose instance information before validating field
>> information.
>>
>> NEW:
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances.  In particular
>> servers should not expose any instance information before ensuring
>> that the client has the necessary access permissions to obtain that
>> information.
>>
>>
>> Is that any more clear?  Or have I missed the point?
>>
>> Thanks,
>> Rob
>>
>>
>> On 16/11/2017 12:55, Mahesh Jethanandani wrote:
>>> Can you provide text?
>>>
>>>> On Nov 16, 2017, at 12:29 PM, Robert Wilton >>> > wrote:
>>>>
>>>> "validating field information" is slightly unclear to me, can this 
>>>> be reworded slightly?
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 16/11/2017 03:12, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> I updated the draft with these changes on github.
>>>>> There is a draft-pre-09.txt file now for you to review.
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani 
>>>>> > wrote:
>>>>>
>>>>>     Andy,
>>>>>
>>>>>     I assume you will incorporate these changes in the -09 version
>>>>>     of the draft.
>>>>>
>>>>>     However, I am unable to review the changes in github. Can you
>>>>>     post the diffs of the draft w.r.t. -08 version.
>>>>>
>>>>>     That still leaves us with one issue, and that has to do with
>>>>>     the what permission to give edit-operation. I am assuming the
>>>>>     WG agrees that making the change from ‘none’ to ‘read’ for
>>>>>     edit operations makes maintenance more difficult and makes the
>>>>>     operation more vulnerable, unless all the deny rules are in place.
>>>>>
>>>>>     We will need to update the security considerations section to
>>>>>     address Eric’s concerns. How about this update?
>>>>>
>>>>>     OLD:
>>>>>
>>>>>     Therefore, a server MUST NOT vary their OPTIONS responses
>>>>>     based on the existence of the underlying resource, which would
>>>>>     indicate the presence or absence of resource instances.
>>>>>
>>>>>
>>>>>     NEW:
>>>>>
>>>>>     Therefore, a server MUST NOT vary their OPTIONS responses
>>>>>     based on the existence of the underlying resource, which would
>>>>>     indicate the presence or absence of resource instances. In particular
>>>>>
>>>>>     servers should not expose instance information before validating field
>>>>>
>>>>>     information.
>>>>>
>>>>>
>>>>>     Cheers.
>>>>>
>>>>>>     On Nov 13, 2017, at 11:28 PM, Martin Bjorklund
>>>>>>     > wrote:
>>>>>>
>>>>>>     Hi,
>>>>>>
>>>>>>     I just read this thread, and I agree with the changes, but
>>>>>>     see below
>>>>>>     for a comment.
>>>>>>
>>>>>>
>>>>>>     Andy Bierman >
>>>>>>     wrote:
>>>>>>>     Hi,
>>>>>>>
>>>>>>>     Here are some proposed edits to make the data rule
>>>>>>>     consistent with the
>>>>>>>     examples.
>>>>>>>     Note that this issue is not related to the edit in the
>>>>>>>     original 1-week
>>>>>>>     change.
>>>>>>>
>>>>>>>
>>>>>>>     sec. 3.3.5:
>>>>>>>
>>>>>>>     OLD:
>>>>>>>
>>>>>>>
>>>>>>>          data node rule:  controls access for a specific data
>>>>>>>     node, identified
>>>>>>>          by its path location within the conceptual XML document
>>>>>>>     for the
>>>>>>>          data node.
>>>>>>>
>>>>>>>
>>>>>>>     NEW:
>>>>>>>
>>>>>>>          data node rule:  controls access for a specific data
>>>>>>>     node and its
>>>>>>>     descendants,
>>>>>>>          identified by its path location within the conceptual
>>>>>>>     XML document
>>>>>>>     for the
>>>>>>>          data node.
>>>>>>>
>>>>>>>
>>>>>>>     sec 3.4.5, step 6, bullet 2:
>>>>>>>
>>>>>>>
>>>>>>>     OLD:
>>>>>>>
>>>>>>>            *  The rule does not have a "rule-type" defined or
>>>>>>>     the "rule-
>>>>>>>               type" is "data-node" and the "path" matches the
>>>>>>>     requested
>>>>>>>               data node, action node, or notification node.
>>>>>>>
>>>>>>>
>>>>>>>     NEW:
>>>>>>>
>>>>>>>
>>>>>>>            *  The rule does not have a "rule-type" defined or
>>>>>>>     the "rule-
>>>>>>>               type" is "data-node" and the "path" matches the
>>>>>>>     requested
>>>>>>>               data node, action node, or notification node. A
>>>>>>>     path is
>>>>>>>               considered to match if the current data node is
>>>>>>>     the data node
>>>>>>>               specified by the path, or is a descendant data
>>>>>>>     node of this
>>>>>>>               data node.
>>>>>>
>>>>>>     I propose:
>>>>>>
>>>>>>                 The rule does not have a "rule-type" defined or the
>>>>>>                 "rule-type" is "data-node" and the "path" matches the
>>>>>>                 requested data node, action node, or notification
>>>>>>     node.
>>>>>>                 A path is considered to match if the requested node
>>>>>>                 is the node specified by the path, or is a
>>>>>>                 descendant node of the path.
>>>>>>
>>>>>>     Note:  s/current node/requested node/ which is the term used
>>>>>>     in the
>>>>>>     first sentence.  And then s/data node/node/ since the first
>>>>>>     sentence
>>>>>>     refer to data-, action-, and notification node.
>>>>>>
>>>>>>     I have checked in this fix in the repo.
>>>>>>
>>>>>>
>>>>>>     /martin
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     Netconf mailing list
>>>>>>     Netconf@ietf.org 
>>>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>>>     
>>>>>
>>>>>     Mahesh Jethanandani
>>>>>     mjethanandani@gmail.com 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com 
>>>
>>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>


--------------6CBECA711430F95E28A8B262
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    The updated text looks OK to me.

    

    We also need to delete this paragraph from the end of section 1.2:

    

    REMOVE:

       The server message processing behavior for the edit operation
    "none",

       used in the <edit-config>, has been changed.  Now read
    access is

       required for such data nodes, instead of no access required.

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 11:40, Mahesh
      Jethanandani wrote:

    

    

      
      I have verified that the proposed changes have been incorporated
      in -09 version of the draft in GitHub.

      


      

      
Based on my discussion with Eric, there is a little
        more tweak that we need to provide to Security Considerations
        section in the third paragraph.
        


        

        

          
OLD:

          
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS method.  The risk here is that the response to
   OPTIONS may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances.

          

          
NEW:
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS and PATCH methods.  The risk here is that the response to
   OPTIONS and PATCH may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary its responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances. In particular
   servers should not expose any instance information before ensuring
   that the client has the necessary access permissions to obtain that
   information. In such cases, servers are expected to always return the “access-
   denied” error response.

          


          

          


            

              

                
On Nov 16, 2017, at 1:56 PM, Robert Wilton
                  <rwilton@cisco.com>
                  wrote:

                

                

                  

                    
I'm not sure I understand exactly what
                      point the previous text was stating so I'm not
                      sure whether my proposed text is stating the same
                      thing (or whether this has already been stated
                      elsewhere in the draft):

                      

                      OLD:

                    

                      
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

                      


                      

                    

                    
NEW:

                    
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In particular

                    
servers should not expose any instance information before ensuring
that the client has the necessary access permissions to obtain that
information.




                    Is that any more clear?  Or have I missed the point?

                    

                    Thanks,

                    Rob

                    

                    

                    
On 16/11/2017 12:55,
                      Mahesh Jethanandani wrote:

                    

                    
 Can you provide text?
                      


                        

                          

                            
On Nov 16, 2017, at 12:29 PM,
                              Robert Wilton <rwilton@cisco.com>
                              wrote:

                            

                            

                              

                                
"validating field
                                  information" is slightly unclear to
                                  me, can this be reworded slightly?

                                
Thanks,

                                  Rob

                                

                                

                                
On
                                  16/11/2017 03:12, Andy Bierman wrote:

                                

                                

                                  
Hi,
                                    


                                    

                                    
I updated the draft
                                      with these changes on github.

                                    
There is a
                                      draft-pre-09.txt file now for you
                                      to review.

                                    


                                    

                                    


                                    

                                    
Andy

                                    


                                    

                                  

                                  


                                    
On Tue, Nov
                                      14, 2017 at 5:05 PM, Mahesh
                                      Jethanandani <mjethanandani@gmail.com>
                                      wrote:

                                      

                                        
Andy,
                                          


                                          

                                          
I assume you
                                            will incorporate these
                                            changes in the -09 version
                                            of the draft.

                                          


                                          

                                          
However, I am
                                            unable to review the changes
                                            in github. Can you post the
                                            diffs of the draft w.r.t.
                                            -08 version.

                                          


                                          

                                          
That still
                                            leaves us with one issue,
                                            and that has to do with the
                                            what permission to give
                                            edit-operation. I am
                                            assuming the WG agrees that
                                            making the change from
                                            ‘none’ to ‘read’ for edit
                                            operations makes maintenance
                                            more difficult and makes the
                                            operation more vulnerable,
                                            unless all the deny rules
                                            are in place.

                                          

                                            

                                              


                                              

                                              We will need to update the
                                              security considerations
                                              section to address Eric’s
                                              concerns. How about this
                                              update?

                                            


                                            

                                            
OLD:

                                            

                                              
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                                              


                                              

                                            

                                            
NEW:

                                            

                                              
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular

                                              
servers should not expose instance information before validating field

                                              
information.

                                              


                                                

                                              
Cheers.

                                              


                                                

                                            

                                            

                                              

                                                
On Nov 13,
                                                  2017, at 11:28 PM,
                                                  Martin Bjorklund <mbj@tail-f.com>
                                                  wrote:

                                                

                                                
Hi,

                                                  

                                                  I just read
                                                    this thread, and I
                                                    agree with the
                                                    changes, but see
                                                    below

                                                  for a
                                                    comment.

                                                  

                                                  

                                                  Andy
                                                    Bierman <andy@yumaworks.com> wrote:

                                                  
Hi,

                                                    

                                                    Here are some
                                                    proposed edits to
                                                    make the data rule
                                                    consistent with the

                                                    examples.

                                                    Note that this issue
                                                    is not related to
                                                    the edit in the
                                                    original 1-week

                                                    change.

                                                    

                                                    

                                                    sec. 3.3.5:

                                                    

                                                    OLD:

                                                    

                                                    

                                                         data node rule:
                                                     controls access for
                                                    a specific data
                                                    node, identified

                                                         by its path
                                                    location within the
                                                    conceptual XML
                                                    document for the

                                                         data node.

                                                    

                                                    

                                                    NEW:

                                                    

                                                         data node rule:
                                                     controls access for
                                                    a specific data node
                                                    and its

                                                    descendants,

                                                         identified by
                                                    its path location
                                                    within the
                                                    conceptual XML
                                                    document

                                                    for the

                                                         data node.

                                                    

                                                    

                                                    sec 3.4.5, step 6,
                                                    bullet 2:

                                                    

                                                    

                                                    OLD:

                                                    

                                                           *  The rule
                                                    does not have a
                                                    "rule-type" defined
                                                    or the "rule-

                                                              type" is
                                                    "data-node" and the
                                                    "path" matches the
                                                    requested

                                                              data node,
                                                    action node, or
                                                    notification node.

                                                    

                                                    

                                                    NEW:

                                                    

                                                    

                                                           *  The rule
                                                    does not have a
                                                    "rule-type" defined
                                                    or the "rule-

                                                              type" is
                                                    "data-node" and the
                                                    "path" matches the
                                                    requested

                                                              data node,
                                                    action node, or
                                                    notification node. A
                                                    path is

                                                              considered
                                                    to match if the
                                                    current data node is
                                                    the data node

                                                              specified
                                                    by the path, or is a
                                                    descendant data node
                                                    of this

                                                              data node.

                                                  

                                                  

                                                  I propose:

                                                  

                                                              The
                                                    rule does not have a
                                                    "rule-type" defined
                                                    or the

                                                              "rule-type"
                                                    is "data-node" and
                                                    the "path" matches
                                                    the

                                                              requested
                                                    data node, action
                                                    node, or
                                                    notification node.

                                                              A
                                                    path is considered
                                                    to match if the
                                                    requested node

                                                              is
                                                    the node specified
                                                    by the path, or is a

                                                              descendant
                                                    node of the path.

                                                  

                                                  Note:
                                                     s/current
                                                    node/requested node/
                                                    which is the term
                                                    used in the

                                                  first
                                                    sentence.  And then
                                                    s/data node/node/
                                                    since the first
                                                    sentence

                                                  refer to
                                                    data-, action-, and
                                                    notification node.

                                                  

                                                  I have
                                                    checked in this fix
                                                    in the repo.

                                                  

                                                  

                                                  /martin

                                                  

                                                  _______________________________________________

                                                  Netconf
                                                    mailing list

                                                  Netconf@ietf.org

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

                                              

                                            

                                            

                                                

                                                  
Mahesh
                                                    Jethanandani

                                                  
                                                

                                                

                                              

                                        

                                      

                                    

                                    

                                  

                                  

                                  

                                  

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


                                

                                

                              

                            

                          

                        

                        

                        

                          
Mahesh Jethanandani

                          
                        

                        

                      

                    

                    

                  

                

              

            

            

            

              
Mahesh Jethanandani

              
            

            

          

        

      

    

    

  


--------------6CBECA711430F95E28A8B262--


From nobody Fri Nov 17 12:25:26 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D101201F2 for ; Fri, 17 Nov 2017 12:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IBhwrFLOgQdx for ; Fri, 17 Nov 2017 12:25:22 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 9011A120454 for ; Fri, 17 Nov 2017 12:25:19 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id y2so3070218lfj.4 for ; Fri, 17 Nov 2017 12:25:19 -0800 (PST)
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=xWJ2Bik/S9kK42yPNdv5WYn8NtN+VBWEwynXg9TtOBw=; b=TLOCniv9bcKX223ENjGJnmn4yCN6qn0ui09Q+1fiU/NTUHf1Sw5L7Zr0cr3dAZH8gS xi93tpHVNCmA+OzstYpjieys4l4Gw360Y1h1x6tYVHeWSeSTZtKv0ggkmLKJYNPmUu7W ai0wHP58f/EU0WsiiQ92d7wzpDUJGdL8+KpLLE/UAuLSmbGtd159El3w6wkwtT1jwz/t siE0UHJ58HPK13oXB+yC1jK5Usw5fI+gg2BRvpdCe1B/5MOhltnQVKMhgCjkYfMmZ7zT XLlugIiMwFP/S7z2fE7mXZUNmmedDLbC9pjzRzll27jLT422OYxUASMHnDABspueBrWi mUIg==
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=xWJ2Bik/S9kK42yPNdv5WYn8NtN+VBWEwynXg9TtOBw=; b=dzy2066z9i1NtFp1b8rKvTulrFvnwXnxXR0Rn8NOu04K6Y3y8PziD/+9BGiKiDdIZW VUQmahYw+Ifw24r2uHCmKXQbzy35ZNXHIQZ5eyvnbnoHR3QHijK2P6k9qUqxZGkG3gUM GNEfCWGQbulEOl93SjGMuFYUmcI/CyHRV/kngVbpFrbNfAkrG+iio+0j1wCqDqwWEPED lGhYAZwp1hciffsEqShxRu6yn+0ulKlPuB+iypzPa6p04znlkO7ui291Y2AMcXgKCdNe bPqOH8zoLxWs3YUxyWaIG/3SufwQidzF6rfCbOGm4s72wvzC+0TRNJynU/eK1GbV2V07 5wcA==
X-Gm-Message-State: AJaThX5bx3oHrWj6i7bB9r7RH1CJTBDeyy4dr3jJHMnvkVtVR1dQUrtB nbaDGZJ4Bf5TVdXgSZ9k7DyeLFMxvbQ/VTM+QngmGA==
X-Google-Smtp-Source: AGs4zMaGEGGppRkEMiSJHl2oj2ELVBStIgLQR4GeCJglIZEjPc083SKpTidqqfWyCX7pv94sTpc4Bzeqi1DuaN2X54k=
X-Received: by 10.25.21.77 with SMTP id l74mr1241237lfi.134.1510950317762; Fri, 17 Nov 2017 12:25:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Fri, 17 Nov 2017 12:25:16 -0800 (PST)
In-Reply-To: <041e8574-4eb2-315d-1259-357185065b6b@cisco.com>
References:  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  <20171113.162810.1853130535954821831.mbj@tail-f.com> <272FF52B-B843-46DA-A502-0080B66FA8E7@gmail.com>    <0cd2df0d-08cb-2f8b-2c66-906c699f4d83@cisco.com> <91F5996E-16B2-443D-B826-3A3116E8FA48@gmail.com> <041e8574-4eb2-315d-1259-357185065b6b@cisco.com>
From: Andy Bierman 
Date: Fri, 17 Nov 2017 12:25:16 -0800
Message-ID: 
To: Robert Wilton 
Cc: Mahesh Jethanandani , sec-ads@ietf.org, netconf , Eric Rescorla 
Content-Type: multipart/alternative; boundary="001a11402ddaf6b75f055e338842"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 20:25:25 -0000

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

Hi,

I updated the draft-pre-09.txt version with these changes.


Andy


On Fri, Nov 17, 2017 at 12:16 PM, Robert Wilton  wrote:

> The updated text looks OK to me.
>
> We also need to delete this paragraph from the end of section 1.2:
>
> REMOVE:
>    The server message processing behavior for the edit operation "none",
>    used in the , has been changed.  Now read access is
>    required for such data nodes, instead of no access required.
>
> Thanks,
> Rob
>
>
> On 16/11/2017 11:40, Mahesh Jethanandani wrote:
>
> I have verified that the proposed changes have been incorporated in -09
> version of the draft in GitHub.
>
> Based on my discussion with Eric, there is a little more tweak that we
> need to provide to Security Considerations section in the third paragraph=
.
>
> OLD:
>
>    There is a risk related to the lack of access control enforcement for
>    the RESTCONF OPTIONS method.  The risk here is that the response to
>    OPTIONS may vary based on the presence or absence of a resource
>    corresponding to the URL's path.  If this is the case, then it can be
>    used to trivially probe for the presence or absence of values within
>    a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
>    based on the existence of the underlying resource, which would
>    indicate the presence or absence of resource instances.
>
> NEW:
>
>    There is a risk related to the lack of access control enforcement for
>    the RESTCONF OPTIONS and PATCH methods.  The risk here is that the res=
ponse to
>    OPTIONS and PATCH may vary based on the presence or absence of a resou=
rce
>    corresponding to the URL's path.  If this is the case, then it can be
>    used to trivially probe for the presence or absence of values within
>    a tree.  Therefore, a server MUST NOT vary its responses
>    based on the existence of the underlying resource, which would
>    indicate the presence or absence of resource instances. In particular
>
>    servers should not expose any instance information before ensuring
>    that the client has the necessary access permissions to obtain that
>    information. In such cases, servers are expected to always return the =
=E2=80=9Caccess-
>
>    denied=E2=80=9D error response.
>
>
>
> On Nov 16, 2017, at 1:56 PM, Robert Wilton  wrote:
>
> I'm not sure I understand exactly what point the previous text was statin=
g
> so I'm not sure whether my proposed text is stating the same thing (or
> whether this has already been stated elsewhere in the draft):
>
> OLD:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances. In particular
> servers should not expose instance information before validating field
> information.
>
>
> NEW:
>
> Therefore, a server MUST NOT vary their OPTIONS responses
> based on the existence of the underlying resource, which would
> indicate the presence or absence of resource instances.  In particular
>
> servers should not expose any instance information before ensuring
> that the client has the necessary access permissions to obtain that
> information.
>
>
>
> Is that any more clear?  Or have I missed the point?
>
> Thanks,
> Rob
>
>
> On 16/11/2017 12:55, Mahesh Jethanandani wrote:
>
> Can you provide text?
>
> On Nov 16, 2017, at 12:29 PM, Robert Wilton  wrote:
>
> "validating field information" is slightly unclear to me, can this be
> reworded slightly?
>
> Thanks,
> Rob
>
> On 16/11/2017 03:12, Andy Bierman wrote:
>
> Hi,
>
> I updated the draft with these changes on github.
> There is a draft-pre-09.txt file now for you to review.
>
>
> Andy
>
>
> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
>
>> Andy,
>>
>> I assume you will incorporate these changes in the -09 version of the
>> draft.
>>
>> However, I am unable to review the changes in github. Can you post the
>> diffs of the draft w.r.t. -08 version.
>>
>> That still leaves us with one issue, and that has to do with the what
>> permission to give edit-operation. I am assuming the WG agrees that maki=
ng
>> the change from =E2=80=98none=E2=80=99 to =E2=80=98read=E2=80=99 for edi=
t operations makes maintenance more
>> difficult and makes the operation more vulnerable, unless all the deny
>> rules are in place.
>>
>> We will need to update the security considerations section to address
>> Eric=E2=80=99s concerns. How about this update?
>>
>> OLD:
>>
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances.
>>
>>
>> NEW:
>>
>> Therefore, a server MUST NOT vary their OPTIONS responses
>> based on the existence of the underlying resource, which would
>> indicate the presence or absence of resource instances. In particular
>>
>> servers should not expose instance information before validating field
>>
>> information.
>>
>>
>> Cheers.
>>
>> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund  wrote:
>>
>> Hi,
>>
>> I just read this thread, and I agree with the changes, but see below
>> for a comment.
>>
>>
>> Andy Bierman  wrote:
>>
>> Hi,
>>
>> Here are some proposed edits to make the data rule consistent with the
>> examples.
>> Note that this issue is not related to the edit in the original 1-week
>> change.
>>
>>
>> sec. 3.3.5:
>>
>> OLD:
>>
>>
>>      data node rule:  controls access for a specific data node, identifi=
ed
>>      by its path location within the conceptual XML document for the
>>      data node.
>>
>>
>> NEW:
>>
>>      data node rule:  controls access for a specific data node and its
>> descendants,
>>      identified by its path location within the conceptual XML document
>> for the
>>      data node.
>>
>>
>> sec 3.4.5, step 6, bullet 2:
>>
>>
>> OLD:
>>
>>        *  The rule does not have a "rule-type" defined or the "rule-
>>           type" is "data-node" and the "path" matches the requested
>>           data node, action node, or notification node.
>>
>>
>> NEW:
>>
>>
>>        *  The rule does not have a "rule-type" defined or the "rule-
>>           type" is "data-node" and the "path" matches the requested
>>           data node, action node, or notification node. A path is
>>           considered to match if the current data node is the data node
>>           specified by the path, or is a descendant data node of this
>>           data node.
>>
>>
>> I propose:
>>
>>             The rule does not have a "rule-type" defined or the
>>             "rule-type" is "data-node" and the "path" matches the
>>             requested data node, action node, or notification node.
>>             A path is considered to match if the requested node
>>             is the node specified by the path, or is a
>>             descendant node of the path.
>>
>> Note:  s/current node/requested node/ which is the term used in the
>> first sentence.  And then s/data node/node/ since the first sentence
>> refer to data-, action-, and notification node.
>>
>> I have checked in this fix in the repo.
>>
>>
>> /martin
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo=
/netconf
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>

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


Hi,

I updated the draft-pre-09.txt vers=
ion with these changes.


Andy
<=
div>

On Fri, Nov 17, 2017 at 12:16 PM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    The updated text looks OK to me.

    

    We also need to delete this paragraph from the end of section 1.2:

    

    REMOVE:

    =C2=A0=C2=A0 The server message processing behavior for the edit operat=
ion
    "none",

    =C2=A0=C2=A0 used in the <edit-config>, has been changed.=C2=A0 N=
ow read
    access is

    =C2=A0=C2=A0 required for such data nodes, instead of no access require=
d.

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 11:40=
, Mahesh
      Jethanandani wrote:

    

    

     =20
      I have verified that the proposed changes have been incorporated
      in -09 version of the draft in GitHub.

      


      

      
Based on my discussion with Eric, there is a little
        more tweak that we need to provide to Security Considerations
        section in the third paragraph.
        


        

        

          
OLD=
:

          
   =
There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS method.  The risk here is that the response to
   OPTIONS may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can b=
e
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances.

          

          
NEW:
   There is a risk =
related to the lack of access control enforcement for
   the RESTCONF OPTIONS and PATCH methods.  The risk here is that the respo=
nse to
   OPTIONS and PATCH may vary based on the presence or absence of a resourc=
e
   corresponding to the URL's path.  If this is the case, then it can b=
e
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary its responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances. In particular<=
/pre>
   servers should not expose=
 any instance information before ensuring
   that the client has the necessary access permissions to obtain that
   information. In such cases, servers are expected to always return the =
=E2=80=9Caccess-
   denied=E2=80=9D error response.

          


          

          


            

              

                
On Nov 16, 2017, at 1:56 PM, Robert Wilton
                  <rwilton@cisco.com>
                  wrote:

                

                

                  

                    
I'm not sure I understand exactly what
                      point the previous text was stating so I'm not
                      sure whether my proposed text is stating the same
                      thing (or whether this has already been stated
                      elsewhere in the draft):

                      

                      OLD:

                    

                      
Therefore, a server MUST NOT vary their OPTIO=
NS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

                      


                      

                    

                    
NEW:

                    
Therefore, a server MUST NOT vary their OPTIONS=
 responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.  In particular
                    
servers should not expose any instance informat=
ion before ensuring
that the client has the necessary access permissions to obtain that
information.




                    Is that any more clear?=C2=A0 Or have I missed the poin=
t?

                    

                    Thanks,

                    Rob

                    

                    

                    
On =
16/11/2017 12:55,
                      Mahesh Jethanandani wrote:

                    

                    
 Can you provide text?
                      


                        

                          

                            
On Nov 16, 2017, at 12:29 PM,
                              Robert Wilton <rwilton@cisco.com>
                              wrote:

                            

                            

                              

                                
"validating field
                                  information" is slightly unclear to
                                  me, can this be reworded slightly?

                                
Thanks,

                                  Rob

                                

                                

                                
On
                                  16/11/2017 03:12, Andy Bierman wrote:

                                

                                

                                  
Hi,
                                    


                                    

                                    
I updated the draft
                                      with these changes on github.

                                    
There is a
                                      draft-pre-09.txt file now for you
                                      to review.

                                    


                                    

                                    


                                    

                                    
Andy

                                    


                                    

                                  

                                  


                                    
On Tue, Nov
                                      14, 2017 at 5:05 PM, Mahesh
                                      Jethanandani <mjethanandani@gm=
ail.com>
                                      wrote:

                                      

                                        
Andy,
                                          


                                          

                                          
I assume you
                                            will incorporate these
                                            changes in the -09 version
                                            of the draft.

                                          


                                          

                                          
However, I am
                                            unable to review the changes
                                            in github. Can you post the
                                            diffs of the draft w.r.t.
                                            -08 version.

                                          


                                          

                                          
That still
                                            leaves us with one issue,
                                            and that has to do with the
                                            what permission to give
                                            edit-operation. I am
                                            assuming the WG agrees that
                                            making the change from
                                            =E2=80=98none=E2=80=99 to =E2=
=80=98read=E2=80=99 for edit
                                            operations makes maintenance
                                            more difficult and makes the
                                            operation more vulnerable,
                                            unless all the deny rules
                                            are in place.

                                          

                                            

                                              


                                              

                                              We will need to update the
                                              security considerations
                                              section to address Eric=E2=80=
=99s
                                              concerns. How about this
                                              update?

                                            


                                            

                                            
OLD:

                                            

                                              
Therefore, a server M=
UST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

                                              


                                              

                                            

                                            
NEW:

                                            

                                              
Therefore, a server M=
UST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular

                                              
servers should not ex=
pose instance information before validating field

                                              
information.

                                              


                                                

                                              
Cheers.

                                              


                                                

                                            

                                            

                                              

                                                
On Nov 13,
                                                  2017, at 11:28 PM,
                                                  Martin Bjorklund <mbj@tail-f.com>
                                                  wrote:

                                                

                                                
Hi,

                                                  

                                                  I just read
                                                    this thread, and I
                                                    agree with the
                                                    changes, but see
                                                    below

                                                  for a
                                                    comment.

                                                  

                                                  

                                                  Andy
                                                    Bierman <andy@yumaworks.com> wrote:

                                                  
Hi,<=
br>
                                                    

                                                    Here are some
                                                    proposed edits to
                                                    make the data rule
                                                    consistent with the

                                                    examples.

                                                    Note that this issue
                                                    is not related to
                                                    the edit in the
                                                    original 1-week

                                                    change.

                                                    

                                                    

                                                    sec. 3.3.5:

                                                    

                                                    OLD:

                                                    

                                                    

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0data node rule:
                                                    =C2=A0controls access f=
or
                                                    a specific data
                                                    node, identified

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0by its path
                                                    location within the
                                                    conceptual XML
                                                    document for the

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0data node.

                                                    

                                                    

                                                    NEW:

                                                    

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0data node rule:
                                                    =C2=A0controls access f=
or
                                                    a specific data node
                                                    and its

                                                    descendants,

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0identified by
                                                    its path location
                                                    within the
                                                    conceptual XML
                                                    document

                                                    for the

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0data node.

                                                    

                                                    

                                                    sec 3.4.5, step 6,
                                                    bullet 2:

                                                    

                                                    

                                                    OLD:

                                                    

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0* =C2=A0The rule
                                                    does not have a
                                                    "rule-type" d=
efined
                                                    or the "rule-

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type" is
                                                    "data-node" a=
nd the
                                                    "path" matche=
s the
                                                    requested

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data node,
                                                    action node, or
                                                    notification node.

                                                    

                                                    

                                                    NEW:

                                                    

                                                    

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0* =C2=A0The rule
                                                    does not have a
                                                    "rule-type" d=
efined
                                                    or the "rule-

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type" is
                                                    "data-node" a=
nd the
                                                    "path" matche=
s the
                                                    requested

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data node,
                                                    action node, or
                                                    notification node. A
                                                    path is

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0considered
                                                    to match if the
                                                    current data node is
                                                    the data node

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0specified
                                                    by the path, or is a
                                                    descendant data node
                                                    of this

                                                    =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0data node.

                                                  

                                                  

                                                  I propose:

                                                  

                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0The
                                                    rule does not have a
                                                    "rule-type" d=
efined
                                                    or the

                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0"rule-type"
                                                    is "data-node"=
; and
                                                    the "path" ma=
tches
                                                    the

                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0requested
                                                    data node, action
                                                    node, or
                                                    notification node.

                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0A
                                                    path is considered
                                                    to match if the
                                                    requested node
                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0is
                                                    the node specified
                                                    by the path, or is a

                                                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0descendant
                                                    node of the path.

                                                  

                                                  Note:
                                                    =C2=A0s/current
                                                    node/requested node/
                                                    which is the term
                                                    used in the

                                                  first
                                                    sentence.=C2=A0 And the=
n
                                                    s/data node/node/
                                                    since the first
                                                    sentence

                                                  refer to
                                                    data-, action-, and
                                                    notification node.

                                                  

                                                  I have
                                                    checked in this fix
                                                    in the repo.

                                                  

                                                  

                                                  /martin

                                                  

                                                  _______________________________________________

                                                  Netconf
                                                    mailing list

                                                  Netconf@ietf.org

                                                  https://www.ietf.org/mailman/=
listinfo/netconf

                                              

                                            

                                            

                                                

                                                  
Mahesh
                                                    Jethanandani

                                                  
                                                

                                                

                                              

                                        

                                      

                                    

                                    

                                  

                                  

                                  

                                  

                                  
_______________________________=
________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/=
mailman/listinfo/netconf


                                

                                

                              

                            

                          

                        

                        

                        

                          
Mahesh Jethanandani

                          
                        

                        

                      

                    

                    

                  

                

              

            

            

            

              
Mahesh Jethanandani

              
            

            

          

        

      

    

    

  






--001a11402ddaf6b75f055e338842--


From nobody Fri Nov 17 12:29:10 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589B120454 for ; Fri, 17 Nov 2017 12:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jEVEqCrgaOfk for ; Fri, 17 Nov 2017 12:29:05 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A31612008A for ; Fri, 17 Nov 2017 12:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9354; q=dns/txt; s=iport; t=1510950545; x=1512160145; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=UwcGu2BrL8QggCX0X/xZ7SD8n1Gu51HNdXSBpFKqyhE=; b=nAXXOn2JmNQOrc2zMTtrZBkIpRlZBhtUB94W/y+El1T8YF6lVz58B1ut 6sv+CEIauLTk9qcavAHAPZjEj1Pk0niw8HoAA5ROs8ElxGhL2Za6iPSk2 u5B2ymu9JWPAIjK8h9qcRtSOAXVYDl8r1JKQ4Pgyc3Utoc5jyDl6vC9nd M=;
X-IronPort-AV: E=Sophos;i="5.44,411,1505779200";  d="scan'208";a="339024"
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; 17 Nov 2017 20:29:03 +0000
Received: from [10.61.226.53] ([10.61.226.53]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAHKT3PA026509; Fri, 17 Nov 2017 20:29:03 GMT
To: "Eric Voit (evoit)" , "netconf@ietf.org" 
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com> <20171116.085331.436907075368637840.mbj@tail-f.com>  <1056296126874cfc9b52000290e84d67@XCH-RTP-013.cisco.com>
From: Robert Wilton 
Message-ID: <6af9442e-ea2c-e647-c180-d468ade8b33f@cisco.com>
Date: Fri, 17 Nov 2017 20:29:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1056296126874cfc9b52000290e84d67@XCH-RTP-013.cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 20:29:08 -0000

On 17/11/2017 18:17, Eric Voit (evoit) wrote:
> In the meeting room discussion during the NETCONF WG, sentiment was to use a common Transport across all receivers of a single configured subscription.   This was proposal (2) below.
>
> I would like to see if there is any objection to this.   If not, we can close this issue in a few weeks.
No objection to proposal 2 (B) below, which keeps it simple for now.

If there is a future requirement to support different transports and/or 
encodings for a subscription, then it looks like there is also a viable 
upgrade path to also support (A) under a feature statement or using an 
augmenting module, perhaps with some appropriate when/must constraints.

I.e. choosing the more simple solution now, doesn't seem to rule out 
extending it to the more complex solution in future, if the need arises.

Thanks,
Rob


>
> Eric
>
>> -----Original Message-----
>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit
>> (evoit)
>> Sent: Thursday, November 16, 2017 3:30 AM
>> To: Martin Bjorklund ; Einar Nilsen-Nygaard (einarnn)
>> 
>> Cc: netconf@ietf.org
>> Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different
>> receivers of a single configured subscription?
>>
>> Hi Martin,
>>
>> Yes, I originally had both your options in the WG slides.    I removed (A)
>> after discussion with Mahesh for the WG session slides to simplify the in-
>> room discussions, as well as consideration of the points Einar makes below.
>> We can of course have more and deeper resolution discussions here.
>>
>> Thanks,
>> Eric
>>
>>> -----Original Message-----
>>> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>>> Sent: Thursday, November 16, 2017 2:54 AM
>>> To: Einar Nilsen-Nygaard (einarnn) 
>>> Cc: Eric Voit (evoit) ; netconf@ietf.org
>>> Subject: Re: [Netconf] Issue SN #4: Can Transport vary across
>>> different receivers of a single configured subscription?
>>>
>>> Hi,
>>>
>>> Note that the issue is that the current model has:
>>>
>>>        +--rw subscription* [identifier]
>>>           ...
>>>           +--rw encoding
>>>           ...
>>>           +--rw receivers
>>>              +--rw receiver* [address port]
>>>                 ...
>>>                 +--rw protocol
>>>
>>> My proposal is have encoding and protocol together:
>>>
>>> (A)
>>>        +--rw subscription* [identifier]
>>>           ...
>>>           ...
>>>           +--rw receivers
>>>              +--rw receiver* [address port]
>>>                 ...
>>>                 +--rw protocol
>>>                 +--rw encoding
>>>
>>> or:
>>>
>>> (B)
>>>        +--rw subscription* [identifier]
>>>           ...
>>>           +--rw encoding
>>>           +--rw protocol
>>>           ...
>>>           +--rw receivers
>>>              +--rw receiver* [address port]
>>>                 ...
>>>
>>> I think that this is *less* complex and probably more optimal than the
>>> current solution.
>>>
>>> "Einar Nilsen-Nygaard (einarnn)"  wrote:
>>>> Martin,
>>>>
>>>> As yet, we have no practical use cases where we would have a single
>>>> configured subscription with multiple receivers who wish to receive
>>>> the data in different formats. Thus supporting this seems like an
>>>> unnecessary complexity for platforms, and one which potentially
>>>> impacts optimisations that we already use in some platform
>>>> implementations (e.g. sending the same encoded PDU to multiple
>>>> receivers, relieving the platform of encoding the same data multiple
>>>> ways).
>>> But this optimization doesn't really work, as you note below (*).
>>>
>>>> Of course, if a client really wants to have the same data sent to
>>>> multiple receivers but in different formats, they can do this — just
>>>> provision separate subscriptions with the same filter.
>>> Exactly; this is more complex and less optimal since the same filter
>>> might be evaluated twice, unless you add code to optimize for that
>>> (which probably falls in your category of "unnecessary complexity").
>>>
>>> (*) So if the operator requires this setup, he will have to configure
>>> two different subscriptions today.  Thus, the platform will encode the
>>> data twice, and your optimization above won't help.
>>>
>>>> All-in-all, I don’t see any benefit in making the base model support
>>>> this, only downsides, so do you have any specific use cases in mind
>>>> where this would be a benefit? So far in the use cases we have
>>>> looked at in SP, DC, enterprise and IoT we have not seen any
>>>> requirement to support this, but we have seen the need for multiple
>> receivers (e.g.
>>>> to support HA/redundancy approaches).
>>> The current model supports different *protocols* for the different
>>> receivers.  Do you have a use case supporting that, or would (B) above
>>> fulfil your requirements.
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>> As such, I would be
>>>> reluctant to add this to the draft at this stage when the
>>>> functionality can be achieved already if absolutely necessary.
>>>>
>>>> Cheers,
>>>>
>>>> Einar
>>>>
>>>>
>>>>> On 15 Nov 2017, at 21:53, Eric Voit (evoit)  wrote:
>>>>>
>>>>> Adding Einar as he had some strong opinions on this a few years
>>>>> ago when we were setting the model...
>>>>>
>>>>>
>>>>>> From: Martin Bjorklund, November 15, 2017 10:43 AM
>>>>>>
>>>>>> "Eric Voit (evoit)"  wrote:
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>>> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>>>>>>>>
>>>>>>>> "Eric Voit (evoit)"  wrote:
>>>>>>>>> In the WG session tomorrow, I am hoping to get "hum feedback"
>>> on:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> draft-ietf-netconf-subscribed-notifications
>>>>>>>>>
>>>>>>>>> https://github.com/netconf-wg/rfc5277bis/issues/4
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The two choices and their issues exposed during the two week
>>>>>>>>> review on
>>>>>>>> "Can Transport vary across different receivers of a single
>>>>>>>> configured subscription?" are:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (1) Yes, Transport can vary by receiver
>>>>>>>>>
>>>>>>>>> *        Fewer subscriptions (scale benefit)
>>>>>>>>>
>>>>>>>>> *        Can convert transport without requiring an application to
>>> learn
>>>>>> a
>>>>>>>> multiple subscription ids
>>>>>>>>> *        No duplication of content during transport conversion.
>>>>>>>>>
>>>>>>>>> *        (Potential confusion in allowing transport to vary, but
>>>>>>>>> *        encoding
>>>>>> not
>>>>>>>> to vary?)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (2) No, only one Transport across all subscriptions
>>>>>>>>>
>>>>>>>>> *        Simpler model
>>>>>>>>>
>>>>>>>>> *        But applications may need to create and track multiple
>>>>>>>> subscription-ids for the same content.
>>>>>>>>> *        Temporary duplication of content streams during transport
>>>>>> change.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The current draft does (1).
>>>>>>>> Actually, the github issue lists 3 options, but here you just list 2.
>>>>>>> In reviewing tomorrow's slides with Mahesh, he preferred 2
>> options.
>>>>>>> And as varying the encoding by receiver seems unlikely in
>>>>>>> implementation
>>>>>> Why is this unlikely?  Suppose I have two receivers for the same
>>>>>> subscription, one wants NETCONF/XML and the other
>>> RESTCONF/JSON.
>>>>>> Is that unlikely?
>>>>> Einar's belief was that a publisher implementation would be
>>>>> unlikely to service a single subscription into multiple encodings.
>>>>> If such a condition existed, it would be far easier to create two
>> subscriptions.
>>>>> This also would have fewer error conditions.
>>>>>
>>>>>>> , there is little reason to socialize this unlikely variant before
>>>>>>> the whole WG.   Since as your opinion was either both encoding
>> and
>>>>>>> transport or neither encoding and transport vary by receiver,
>>>>>>> the more likely of your primary ask is supported.
>>>>>>>
>>>>>>>
>>>>>>>> I think the point is that in the term "Transport", we need to
>>>>>>>> include both protocol and encoding (in the case the protocol
>>>>>>>> supports multiple encodings).
>>>>>>> While most likely the case for NETCONF and RESTCONF, Tianran's
>>>>>>> draft-ietf-netconf-udp-pub-channel shows that there can be
>> encoding
>>>>>>> variation by transports .   It Therefore it seems better to let them
>>>>>>> both vary independently.
>>>>>> Not sure I understand what you mean.  To be clear, do you think
>>>>>> the "encoding" leaf should stay where it is, or be moved down to
>>>>>> the receiver, as a sibling to "protocol"?
>>>>> Encoding leaf should stay where it is.  Your previous ask was to
>>>>> put encoding and transport and the same level. There is an option
>>>>> proposed in the slides which does that.
>>>>>
>>>>> Eric
>>>>>
>>>>>> /martin
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Mon Nov 20 02:28:34 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0A6129527 for ; Mon, 20 Nov 2017 02:28:32 -0800 (PST)
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 rh7QvaJKlOHK for ; Mon, 20 Nov 2017 02:28:31 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E55120046 for ; Mon, 20 Nov 2017 02:28:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1125; q=dns/txt; s=iport; t=1511173711; x=1512383311; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=IZhogxJzFzk7u9qgMReAKRuXrmWNkcJRfr9jZv2chro=; b=jOuJkUxPo7W3lGuZirlsAKwSxWmfs5m/124LUDX0Cpxn8RdWeYyIZCZJ Yab+CsCvnX+cPYfKuwJI9zCVgv/faY+Juxo1VDXej45rbjq/nqrVBAL8k nmTVWGlSmbZR1r87EDetA8BHFDyaVfjeQCZPgrqkgWR2gRnP83TJQgcNZ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgDIrRJa/xbLJq1bGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMOggKEJosTkAqXCIIRCoptFwEBAQEBAQEBAWsohUgPAQV2AiYCXwE?= =?us-ascii?q?MCAEBiiGoUYIninQBAQEHAgElgQ+CJYNcgWkpC4sngmMFikyJGo5YlQyMBIdIj?= =?us-ascii?q?j6HdIE6IQI1gXQ0IQgdFYMuhF5BjAYBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,426,1505779200";  d="scan'208";a="374923"
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; 20 Nov 2017 10:28:29 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAKASSiY029839; Mon, 20 Nov 2017 10:28:28 GMT
To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" 
From: Robert Wilton 
Message-ID: 
Date: Mon, 20 Nov 2017 10:28:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [Netconf] NACM and "when" statements
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 10:28:33 -0000

Hi Andy, Martin,

I've got a question about 'when' statement handling related to NACM.

Due to when statements, it is possible that a client could implicitly 
cause a change to a part of the data tree that they have no write access 
to because they cause a when condition to evaluate to a different 
answer.  Am I correct in presuming that this implicit change is allowed?

E.g. in the following example, a user may only have write access to 
"baz" but not "bar". If they create "baz" then that may implicitly cause 
"bar" to be deleted.  Further, even if this implicit delete to "bar" is 
allowed, I presume that the equivalent explicit change or creating "baz" 
and deleting "bar" would still be rejected because there is no explicit 
write access to bar.

container foo {
   leaf bar {
    when "not(../baz)";
   }
   leaf baz {
   }
}

Should this be mentioned in the NACM draft at all?  I'm not convinced 
that the draft makes the correct behaviour for handling 'when' 
statements obvious.

Similar considerations could also apply when writing to choice statements.

Thanks,
Rob





From nobody Mon Nov 20 05:34:12 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F921129789 for ; Mon, 20 Nov 2017 05:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 3FL8STWx8YAV for ; Mon, 20 Nov 2017 05:34:09 -0800 (PST)
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 73C4C1298A1 for ; Mon, 20 Nov 2017 05:34:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35428; q=dns/txt; s=iport; t=1511184849; x=1512394449; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=y5+7I7wj3tKoRa2SLCRxZxm7IZHtTwNS46mvlekyfLI=; b=iTS7vuiqNEtWlkt3mrUeNpW+uEsnaD557IfORHT9Kqazydk4qLPLqg0E 2lEqkNHNKg/8Oh34KOjH7tyl800ys81D/RVesFqwjzCwLeUW+kKCDtViB EAw4y/siXkzM679WE0Dja0H1dC2vZSbBnWxVhigx3H2aHNuT6xLd+MX5h 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AAAp2RJa/4wNJK1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkQuZm4nB4N4ih+PKIF9lmKCDgMKGAEKhANGTwIahGA/GAE?= =?us-ascii?q?BAQEBAQEBAWsohR4BAQEBAwEBIQpBGwIBCBEEAQEOEwEGAwICAiULFAkIAQEEA?= =?us-ascii?q?RIIE4kmZBCoT4InJopNAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDNIIHgVWFFIR?= =?us-ascii?q?wBDUJH4JfgmMFkXSHLokcAodwjRGTVYxyiRMCERkBgTkBHzmBdHoVSYJkgxGBT?= =?us-ascii?q?neJCQIlB4EFgRQBAQE?=
X-IronPort-AV: E=Sophos; i="5.44,427,1505779200"; d="scan'208,217"; a="33365102"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2017 13:34:08 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAKDY88f018675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 13:34:08 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 08:34:07 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 08:34:07 -0500
From: "Eric Voit (evoit)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAIFUkLA=
Date: Mon, 20 Nov 2017 13:34:07 +0000
Message-ID: <57573502664643a2bf6b9af22b52e69c@XCH-RTP-013.cisco.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com>
In-Reply-To: <31442888-3dba-7834-c408-bd7986b9e381@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_57573502664643a2bf6b9af22b52e69cXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 13:34:12 -0000

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

RnJvbTogUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIgMTcsIDIwMTcgMTo0NiBQTQ0KDQpPbiAxNy8x
MS8yMDE3IDE4OjE3LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCkkgd291bGQgbGlrZSB0byBj
b250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZyb20gb3VyIHNlc3Npb24uICAg
SSB0aGluayB3ZSBjYW1lIHRvIGFncmVlbWVudCBhbW9uZyB0aGUgYXR0ZW5kZWVzLiAgIEhvcGVm
dWxseSB0aGlzIHRocmVhZCBjYW4gY29uZmlybSwgb3IgcmVmaW5lIGFzIG5lZWQuDQoNCkZpcnN0
IGxldOKAmXMgbG9vayBhdCBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93Og0KVGhlcmUgYXJlIGxv
dHMgb2YgZ29vZCBlbGVtZW50cyBpbiBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93LCBidXQgaXQg
aXNu4oCZdCB1cCB0byBvdXIgV0cgdG8gZGV0ZXJtaW5lIHRoZSBwcm9wZXIgc3RydWN0dXJlIG9m
IHRoZSBuZXR3b3JrLWluc3RhbmNlLW1vZGVsLiAgIEF1dGhvcnMgb2YgdGhhdCBtb2RlbCB3ZXJl
IGluIHRoZSByb29tLCBhbmQgYXJlIGF3YXJlIHRoYXQgWUFORyBtb2RlbCBkZXZlbG9wZXJzIGZy
b20gb3V0c2lkZSB3b3VsZCB3ZWxjb21lIGEgcGFydGl0aW9uaW5nIHdoaWNoIGRlY291cGxlcyBh
bnkgbGlua2FnZXMgdG8gc2NoZW1hLW1vdW50IHdoZW4gYWxsIHRoYXQgaXMgbmVlZGVkIGlzIHRv
IGlkZW50aWZ5IGEgVlJGIGJ5IG5hbWUuDQoNCkxvb2tpbmcgYXQgd2hhdCB3ZSBjYW4gY29udHJv
bCwgZGlzY3Vzc2VkIGluIHRoZSByb29tIHdhcyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnM6DQoNCjEuICAgICAgaW1wb3J0IOKAnGlldGYtbmV0d29yay1p
bnN0YW5jZeKAnQ0KDQoyLiAgICAgIGNyZWF0ZSBpZi1mZWF0dXJlIOKAnFZSRuKAnS4NCg0KMy4g
ICAgICBhcHBseSBmZWF0dXJlIOKAnFZSRuKAnSB0byBvYmplY3Qg4oCcc291cmNlLVZSRuKAnQ0K
DQo0LiAgICAgIExlYWZyZWYgdG8g4oCcc291cmNlLVZSRuKAnSB0byB2YWxpZGF0ZSBhZ2FpbnN0
IHRoZSBuZXR3b3JrLWluc3RhbmNlIG1vZGVs4oCZcyAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29y
ay1pbnN0YW5jZS9uYW1lLg0KDQpUaGlzIGlzIHRoZSBjdXJyZW50IHByb3Bvc2FsLiAgQXJlIHRo
ZXJlIGFyZSBjb25jZXJucy9vYmplY3Rpb25zL3JlZmluZW1lbnRzPw0KDQpObyBjb25jZXJucywg
YnV0IHBlcmhhcHMgb25lIHRyaXZpYWwgcmVmaW5lbWVudC4NCg0KSSBoYWQgbWlzdGFrZW5seSB0
aG91Z2h0IHRoYXQgYSBkZXZpY2Ugd291bGQgZWl0aGVyIHN1cHBvcnQgVlJGcyBmb3IgYWxsIHBy
b3RvY29scyBvciBub25lLCBoZW5jZSBteSBzdWdnZXN0aW9uIHRvIGhhdmUgYSBzaW5nbGUgIlZS
RiIgZmVhdHVyZSwgd2hpY2ggd291bGQgbmF0dXJhbGx5IGJlIGRlZmluZWQgYnkgdGhlIG5ldHdv
cmstaW5zdGFuY2VzIG1vZGVsLg0KDQpJbiB0aGUgZGlzY3Vzc2lvbnMgdGhhdCBJIGhhZCB3aXRo
IExvdSwgc29tZSBvZiB0aGVtIGF0IHRoZSBtaWMsIHNvbWUgYWZ0ZXJ3YXJkcywgTG91IGNsYXJp
ZmllZCB0aGF0IGl0IHF1aXRlIHBsYXVzaWJsZSB0aGF0IFZSRnMgbWF5IG9ubHkgYmUgc3VwcG9y
dGVkIGJ5IHNvbWUgcHJvdG9jb2xzIG9uIGEgZGV2aWNlIGFuZCBub3QgYWxsLCBhbmQgaGVuY2Ug
dGhlIHNvbHV0aW9uIG9mIGhhdmluZyBhICJWUkYiIGZlYXR1cmUgcGVyIHByb3RvY29sIHNlZW1z
IGxpa2UgdGhlIHJpZ2h0IHNvbHV0aW9uLg0KDQpJIHRoaW5rIHRoYXQgSSB3b3VsZCBjYWxsIHRo
ZSBmZWF0dXJlICJzdXBwb3J0cy12cmYiIHJhdGhlciB0aGFuICJ2cmYiLg0KDQo8RXJpYz4g4oCc
c3VwcG9ydHMtdnJm4oCdIGlzIGZpbmUgd2l0aCBtZS4gIEFsc28gYXMgd2Ugb25seSBoYXZlIG9u
ZSB0cmFuc3BvcnQgcGVyIHN1YnNjcmlwdGlvbiwgYW55IGVycm9yIGNoZWNraW5nIG9uIGNvbmZp
Z3VyYXRpb24gc2hvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZC4NCg0KRXJpYw0KDQoNClRoYW5rcywN
ClJvYg0KDQoNCg0KDQpFcmljDQoNCg0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0IChldm9pdCkNClNlbnQ6IFR1
ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDEwOjIzIFBNDQpUbzogUm9iZXJ0IFdpbHRvbiAtWCAo
cndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSA8cndpbHRvbkBjaXNjby5jb20+PG1h
aWx0bzpyd2lsdG9uQGNpc2NvLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZA
aWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjxtYWlsdG86bGJlcmdlckBs
YWJuLm5ldD4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXBy
ZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8NCg0KQWdyZWUgaXQg
aXMgYSBnZW5lcmljIHByb2JsZW0uDQoNCkkgd291bGQgZGVmZXIgdG8gTG91IGFuZCB0aGUgb3Ro
ZXIgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsIGFzIHRoaXMgd291bGQgYmUg
YSBmYWlybHkgc2lnbmlmaWNhbnQgY2hhbmdlLg0KDQpFcmljDQoNCkZyb206IFJvYmVydCBXaWx0
b24sIE5vdmVtYmVyIDE0LCAyMDE3IDc6NTggUE0NCg0KSGkgRXJpYywgTG91LA0KDQpUaGlzIHNl
ZW1zIHRvIGJlIGEgZ2VuZXJpYyBwcm9ibGVtLg0KDQpDb3VsZCB0aGUgVlJGIGxlYWZyZWYgbmFt
ZSBkZXBlbmRlbmN5IGlzc3VlIGJlIHNvbHZlZCB3aXRoIGFuIGlmLWZlYXR1cmUgc3RhdGVtZW50
Py4NCg0KSS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3RhbmNlIGRyYWZ0IGRlZmluZSBhIHNlcGFy
YXRlIFlBTkcgbW9kdWxlICh3aXRoIG5vIGRlcGVuZGVuY2llcykgdGhhdCBkZWZpbmVzIGEgIlZS
RiIgZmVhdHVyZS4NCg0KQWxsIHRoZSBWUkYgcmVmZXJlbmNlcyAoaWRlYWxseSBpZiBhbGwgSUVU
RiBZQU5HIG1vZHVsZXMgdGhhdCBtYXkgb3B0aW9uYWxseSBkZXBlbmQgb24gVlJGcykgY291bGQg
YmUgbGVhZi1yZWZzIHRvIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUg
YnV0IHByZWRpY2F0ZWQgd2l0aCBhbiBpZi1mZWF0dXJlICJuaTp2cmYiLg0KDQpIZW5jZSBpZiBh
IGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBpdCBkb2Vzbid0IGltcGxlbWVudCB0
aGUgInZyZiIgZmVhdHVyZSwgc28gaXQgZG9lc24ndCBoYXZlIHRvIGltcGxlbWVudCB0aGUgZnVs
bCBuZXR3b3JrIGluc3RhbmNlcyBtb2R1bGUsIG9yIHNjaGVtYSBtb3VudC4NCg0KVGhhbmtzLA0K
Um9iDQoNCk9uIDE1LzExLzIwMTcgMDg6NDUsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KDQpJ
biB0aGUgV0cgc2Vzc2lvbiB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8gZ2V0IOKAnGh1bSBmZWVk
YmFja+KAnSBvbjoNCg0KDQoNCmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNh
dGlvbnMNCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMv
NQ0KDQoNCg0KVGhlIHR3byBjaG9pY2VzIGV4cG9zZWQgZHVyaW5nIHRoZSB0d28gd2VlayByZXZp
ZXcgZm9yIGhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlw
dGlvbiB3ZXJlOg0KDQoNCg0KKDEpIExlYWZyZWYgdG8g4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl
4oCdICAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lDQoNCsK3ICAgICAg
ICBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1vdW50IGZvciBzdWJzY3JpcHRpb25zLg0K
DQrCtyAgICAgICAgU291cmNlIFZSRiBpcyBhbiBvcHRpb25hbCBjYXBhYmlsaXR5LCBidXQgcHVi
bGlzaGVycyB0aGF0IGRvbuKAmXQgY2FyZSBhYm91dCBWUkZzIG11c3Qgc3RpbGwgaW1wb3J0LiAg
KE5vdGU6IGNvdWxkIGFsc28gYXVnbWVudCB0aGUgbGVhZnJlZiBpbiBhbm90aGVyIG1vZGVsLCBi
dXQgdGhhdCBhZGRzIGFub3RoZXIgbGF5ZXIgb2YgY29tcGxleGl0eSkNCg0KwrcgICAgICAgIGVz
dGFibGlzaGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8gZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbA0K
DQoNCg0KKDIpIFVzZSBhIHN0cmluZyB3aGljaCB3b3VsZCBiZSBwb3B1bGF0ZWQgd2l0aCBleGFj
dCBzYW1lIG5hbWUgYXMgd291bGQgYmUgaW4gdGhlIGxlYWZyZWYgb2YgKDEpDQoNCsK3ICAgICAg
ICBQb3NzaWJsZSB0byBuYW1lIFZSRiB3aGljaCBkb2VzbuKAmXQgZXhpc3QNCg0KDQoNClRoZSBj
dXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KDQoNCg0KVGhhbmtzLA0KDQpFcmljDQoNCg0KDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpOZXRj
b25mIG1haWxpbmcgbGlzdA0KDQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYu
b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K
Lg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg
MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7
bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ
cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjY2
Mzk4NTI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot
MTgyMDgwMDEyMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3MDMz
MzQwMzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02
MDM0MDgwODIgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMwMjU0MzgxMjsNCgltc28tbGlzdC10eXBl
Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4Mzc3NDY0MzYgNjc2OTg2ODkgNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIj
MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24s
IE5vdmVtYmVyIDE3LCAyMDE3IDE6NDYgUE08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMTEvMjAxNyAxODoxNywgRXJp
YyBWb2l0IChldm9pdCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkkgd291bGQgbGlrZSB0byBj
b250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZyb20gb3VyIHNlc3Npb24uJm5i
c3A7Jm5ic3A7IEkgdGhpbmsgd2UgY2FtZSB0byBhZ3JlZW1lbnQgYW1vbmcgdGhlIGF0dGVuZGVl
cy4mbmJzcDsmbmJzcDsgSG9wZWZ1bGx5IHRoaXMgdGhyZWFkIGNhbiBjb25maXJtLCBvciByZWZp
bmUgYXMgbmVlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkZpcnN0IGxl
dOKAmXMgbG9vayBhdCBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93Ojwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5U
aGVyZSBhcmUgbG90cyBvZiBnb29kIGVsZW1lbnRzIGluIFJvYmVydOKAmXMgcHJvcG9zYWwgYmVs
b3csIGJ1dCBpdCBpc27igJl0IHVwIHRvIG91ciBXRyB0byBkZXRlcm1pbmUgdGhlIHByb3BlciBz
dHJ1Y3R1cmUgb2YgdGhlIG5ldHdvcmstaW5zdGFuY2UtbW9kZWwuJm5ic3A7Jm5ic3A7IEF1dGhv
cnMgb2YgdGhhdCBtb2RlbCB3ZXJlIGluIHRoZSByb29tLCBhbmQgYXJlIGF3YXJlIHRoYXQNCiBZ
QU5HIG1vZGVsIGRldmVsb3BlcnMgZnJvbSBvdXRzaWRlIHdvdWxkIHdlbGNvbWUgYSBwYXJ0aXRp
b25pbmcgd2hpY2ggZGVjb3VwbGVzIGFueSBsaW5rYWdlcyB0byBzY2hlbWEtbW91bnQgd2hlbiBh
bGwgdGhhdCBpcyBuZWVkZWQgaXMgdG8gaWRlbnRpZnkgYSBWUkYgYnkgbmFtZS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJF
NzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkxvb2tpbmcgYXQgd2hhdCB3ZSBjYW4gY29udHJv
bCwgZGlzY3Vzc2VkIGluIHRoZSByb29tIHdhcyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnM6ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0
OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxp
c3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwh
W2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+aW1wb3J0IOKAnGlldGYtbmV0d29y
ay1pbnN0YW5jZeKAnSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs
MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl
Ij4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48
c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Y3JlYXRlIGlmLWZlYXR1cmUg4oCcVlJG4oCdLiAm
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg
c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYg
IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHls
ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv
bG9yOiMyRTc1QjYiPmFwcGx5IGZlYXR1cmUg4oCcVlJG4oCdIHRvIG9iamVjdCDigJxzb3VyY2Ut
VlJG4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi
IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lm
ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5
bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJj
b2xvcjojMkU3NUI2Ij5MZWFmcmVmIHRvIOKAnHNvdXJjZS1WUkbigJ0gdG8gdmFsaWRhdGUgYWdh
aW5zdCB0aGUgbmV0d29yay1pbnN0YW5jZSBtb2RlbOKAmXMgL25ldHdvcmstaW5zdGFuY2VzL25l
dHdvcmstaW5zdGFuY2UvbmFtZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5UaGlzIGlzIHRoZSBjdXJyZW50IHBy
b3Bvc2FsLiZuYnNwOyBBcmUgdGhlcmUgYXJlIGNvbmNlcm5zL29iamVjdGlvbnMvcmVmaW5lbWVu
dHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQpObyBjb25jZXJucywgYnV0IHBlcmhhcHMg
b25lIHRyaXZpYWwgcmVmaW5lbWVudC48YnI+DQo8YnI+DQpJIGhhZCBtaXN0YWtlbmx5IHRob3Vn
aHQgdGhhdCBhIGRldmljZSB3b3VsZCBlaXRoZXIgc3VwcG9ydCBWUkZzIGZvciBhbGwgcHJvdG9j
b2xzIG9yIG5vbmUsIGhlbmNlIG15IHN1Z2dlc3Rpb24gdG8gaGF2ZSBhIHNpbmdsZSAmcXVvdDtW
UkYmcXVvdDsgZmVhdHVyZSwgd2hpY2ggd291bGQgbmF0dXJhbGx5IGJlIGRlZmluZWQgYnkgdGhl
IG5ldHdvcmstaW5zdGFuY2VzIG1vZGVsLjxicj4NCjxicj4NCkluIHRoZSBkaXNjdXNzaW9ucyB0
aGF0IEkgaGFkIHdpdGggTG91LCBzb21lIG9mIHRoZW0gYXQgdGhlIG1pYywgc29tZSBhZnRlcndh
cmRzLCBMb3UgY2xhcmlmaWVkIHRoYXQgaXQgcXVpdGUgcGxhdXNpYmxlIHRoYXQgVlJGcyBtYXkg
b25seSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24gYSBkZXZpY2UgYW5kIG5vdCBh
bGwsIGFuZCBoZW5jZSB0aGUgc29sdXRpb24gb2YgaGF2aW5nIGEgJnF1b3Q7VlJGJnF1b3Q7IGZl
YXR1cmUgcGVyIHByb3RvY29sDQogc2VlbXMgbGlrZSB0aGUgcmlnaHQgc29sdXRpb24uPGJyPg0K
PGJyPg0KSSB0aGluayB0aGF0IEkgd291bGQgY2FsbCB0aGUgZmVhdHVyZSAmcXVvdDtzdXBwb3J0
cy12cmYmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7dnJmJnF1b3Q7Ljwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4mbHQ7RXJpYyZndDsg4oCcc3VwcG9ydHMtdnJm4oCdIGlzIGZpbmUgd2l0aCBtZS4mbmJz
cDsgQWxzbyBhcyB3ZSBvbmx5IGhhdmUgb25lIHRyYW5zcG9ydCBwZXIgc3Vic2NyaXB0aW9uLCBh
bnkgZXJyb3IgY2hlY2tpbmcgb24gY29uZmlndXJhdGlvbiBzaG91bGQgYmUgc3RyYWlnaHRmb3J3
YXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RXJpYyA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxi
cj4NCjxicj4NClRoYW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+RXJpYzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs
dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4
dCI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5F
cmljIFZvaXQgKGV2b2l0KTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxNCwg
MjAxNyAxMDoyMyBQTTxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAt
IEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSA8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5j
b20iPg0KJmx0O3J3aWx0b25AY2lzY28uY29tJmd0OzwvYT47IDxhIGhyZWY9Im1haWx0bzpuZXRj
b25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjsgTG91IEJlcmdlcg0KPGEgaHJlZj0i
bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiPiZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYT48YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJl
c2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5
QkQ1Ij5BZ3JlZSBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbS4gPC9zcGFuPg0KPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzVCOUJENSI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiM1QjlCRDUiPkkgd291bGQgZGVmZXIgdG8gTG91IGFuZCB0aGUgb3RoZXIgYXV0
aG9ycyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsIGFzIHRoaXMgd291bGQgYmUgYSBmYWly
bHkgc2lnbmlmaWNhbnQgY2hhbmdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzVCOUJE
NSI+RXJpYyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uLCBOb3ZlbWJlciAxNCwgMjAxNyA3OjU4IFBN
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPkhpIEVyaWMsIExvdSw8
bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgc2VlbXMgdG8gYmUgYSBnZW5lcmljIHByb2JsZW0uPG86
cD48L286cD48L3A+DQo8cD5Db3VsZCB0aGUgVlJGIGxlYWZyZWYgbmFtZSBkZXBlbmRlbmN5IGlz
c3VlIGJlIHNvbHZlZCB3aXRoIGFuIGlmLWZlYXR1cmUgc3RhdGVtZW50Py48bzpwPjwvbzpwPjwv
cD4NCjxwPkkuZS5jb3VsZCB0aGUgbmV0d29yayBpbnN0YW5jZSBkcmFmdCBkZWZpbmUgYSBzZXBh
cmF0ZSBZQU5HIG1vZHVsZSAod2l0aCBubyBkZXBlbmRlbmNpZXMpIHRoYXQgZGVmaW5lcyBhICZx
dW90O1ZSRiZxdW90OyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHA+QWxsIHRoZSBWUkYgcmVm
ZXJlbmNlcyAoaWRlYWxseSBpZiBhbGwgSUVURiBZQU5HIG1vZHVsZXMgdGhhdCBtYXkgb3B0aW9u
YWxseSBkZXBlbmQgb24gVlJGcykgY291bGQgYmUgbGVhZi1yZWZzIHRvIC9uZXR3b3JrLWluc3Rh
bmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUgYnV0IHByZWRpY2F0ZWQgd2l0aCBhbiBpZi1mZWF0
dXJlICZxdW90O25pOnZyZiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwPkhlbmNlIGlmIGEgZGV2
aWNlIGRvZXNuJ3Qgc3VwcG9ydCBWUkZzLCB0aGVuIGl0IGRvZXNuJ3QgaW1wbGVtZW50IHRoZSAm
cXVvdDt2cmYmcXVvdDsgZmVhdHVyZSwgc28gaXQgZG9lc24ndCBoYXZlIHRvIGltcGxlbWVudCB0
aGUgZnVsbCBuZXR3b3JrIGluc3RhbmNlcyBtb2R1bGUsIG9yIHNjaGVtYSBtb3VudC48bzpwPjwv
bzpwPjwvcD4NCjxwPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk9uIDE1LzExLzIwMTcgMDg6NDUsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIHRoZSBXRyBzZXNz
aW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBnZXQg4oCcaHVtIGZlZWRiYWNr4oCdIG9uOjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5kcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJl
ZC1ub3RpZmljYXRpb25zIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMv
NSI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNTwvYT4N
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgdHdvIGNob2ljZXMgZXhwb3NlZCBk
dXJpbmcgdGhlIHR3byB3ZWVrIHJldmlldyBmb3IgaG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJG
IG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPigxKSBMZWFmcmVmIHRvIOKAnGlldGYtbmV0d29yay1pbnN0YW5jZeKAnSZuYnNwOyAv
bmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu
dDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln
bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv
c3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNyZWF0ZXMgZGVwZW5kZW5jeSBvbiBzY2hlbWEgbW91bnQg
Zm9yIHN1YnNjcmlwdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps
MiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl
PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp
Zl0+U291cmNlIFZSRiBpcyBhbiBvcHRpb25hbCBjYXBhYmlsaXR5LCBidXQgcHVibGlzaGVycyB0
aGF0IGRvbuKAmXQgY2FyZSBhYm91dCBWUkZzIG11c3Qgc3RpbGwgaW1wb3J0LiZuYnNwOyAoTm90
ZTogY291bGQgYWxzbyBhdWdtZW50IHRoZSBsZWFmcmVmIGluIGFub3RoZXIgbW9kZWwsIGJ1dCB0
aGF0IGFkZHMgYW5vdGhlciBsYXllciBvZiBjb21wbGV4aXR5KTxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6
LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v
cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw
YW4+PC9zcGFuPjwhW2VuZGlmXT5lc3RhYmxpc2hlcyBtb2RlbCBkZXBlbmRlbmN5IHRvIGRyYWZ0
LWlldGYtcnRnd2ctbmktbW9kZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KDIpIFVz
ZSBhIHN0cmluZyB3aGljaCB3b3VsZCBiZSBwb3B1bGF0ZWQgd2l0aCBleGFjdCBzYW1lIG5hbWUg
YXMgd291bGQgYmUgaW4gdGhlIGxlYWZyZWYgb2YgKDEpPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1
aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+
wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPlBvc3NpYmxlIHRvIG5hbWUgVlJGIHdoaWNoIGRvZXNu4oCZdCBleGlz
dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgY3VycmVudCBkcmFmdCBkb2VzICgy
KS4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyw8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVyaWMgPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJpZiZx
dW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHBy
ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxw
cmU+PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzIE5ldyBSb21hbiAsc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssc2VyaWYiPi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_57573502664643a2bf6b9af22b52e69cXCHRTP013ciscocom_--


From nobody Mon Nov 20 05:44:45 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC161296C9 for ; Mon, 20 Nov 2017 05:44:43 -0800 (PST)
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 CGDfb4jRs83L for ; Mon, 20 Nov 2017 05:44:41 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DD01267BB for ; Mon, 20 Nov 2017 05:44:40 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B725CF36; Mon, 20 Nov 2017 14:44:38 +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 F8ly5BJWzbk6; Mon, 20 Nov 2017 14:44: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; Mon, 20 Nov 2017 14:44:38 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A112720121; Mon, 20 Nov 2017 14:44:33 +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 POGEJCFPqk6O; Mon, 20 Nov 2017 14:44:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FCF12011F; Mon, 20 Nov 2017 14:44:33 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AC3C3415FA77; Mon, 20 Nov 2017 14:43:05 +0100 (CET)
Date: Mon, 20 Nov 2017 14:43:05 +0100
From: Juergen Schoenwaelder 
To: "Eric Voit (evoit)" 
Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" , Lou Berger 
Message-ID: <20171120134305.h5q3ghfml2vtoy7n@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Eric Voit (evoit)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netconf@ietf.org" , Lou Berger 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <57573502664643a2bf6b9af22b52e69c@XCH-RTP-013.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: <57573502664643a2bf6b9af22b52e69c@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 13:44:43 -0000

On Mon, Nov 20, 2017 at 01:34:07PM +0000, Eric Voit (evoit) wrote:

[...]

> I think that I would call the feature "supports-vrf" rather than "vrf".
> 
>  “supports-vrf” is fine with me.  Also as we only have one transport per subscription, any error checking on configuration should be straightforward.
>

Since this same question (how to support VRFs) has come up in other
contexts, it would really be good if it would be documented, say in
the network instances draft, how other protocol models should refer to
VRFs - ideally with the rationale behind 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 Nov 20 06:41:17 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AE3129A8D for ; Mon, 20 Nov 2017 06:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqAO6qiiW0yq for ; Mon, 20 Nov 2017 06:41:15 -0800 (PST)
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 E9559129A9C for ; Mon, 20 Nov 2017 06:41:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1511188874; x=1512398474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XGjBWsCttN3Y9pD0guvKRKDCMXdH6mxUZJuOogdyhBc=; b=jfD7CcYAGnWMQPYuzjxVdxPTjnnCWPUS/3XZKEefvc6H+rV8rPUGBJBS YtPB+7a7t/ia8O8UhJ9ys0j55KmG308ipVPuNcqguacR0rMapB7CX35J2 hMDiuYocLF0NP4JLDDliyZC1XCUWbnt2GCsKPshozMKyozvvsEfmMOCHz Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAAAw6BJa/4QNJK1YAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuLoN4ih+PKIF9lmKCEQofhAeBFQIahGQ/GAEBAQEBAQE?= =?us-ascii?q?BAWsohR4BAQEBAgEjEUUFCQICAQgOAgUDAgIJHQICAhkXFRACBAENDYoVCKhpg?= =?us-ascii?q?ieKdAEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQqCJYIHgVWFFIUyChkNgk6CYwW?= =?us-ascii?q?RdJBKApUBk1WWBQIRGQGBOQEfOYF0ehWDLgiDCIFOiy+BFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,427,1505779200"; d="scan'208";a="312421137"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2017 14:41:13 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAKEfDul019727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 14:41:13 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 09:41:12 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 09:41:12 -0500
From: "Eric Voit (evoit)" 
To: Juergen Schoenwaelder , Lou Berger 
CC: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAIFUkLAACvjAgAAKFTbA
Date: Mon, 20 Nov 2017 14:41:12 +0000
Message-ID: 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <57573502664643a2bf6b9af22b52e69c@XCH-RTP-013.cisco.com> <20171120134305.h5q3ghfml2vtoy7n@elstar.local>
In-Reply-To: <20171120134305.h5q3ghfml2vtoy7n@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:41:16 -0000

PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIE5vdmVtYmVyIDIwLCAyMDE3IDg6NDMgQU0N
Cj4gDQo+IE9uIE1vbiwgTm92IDIwLCAyMDE3IGF0IDAxOjM0OjA3UE0gKzAwMDAsIEVyaWMgVm9p
dCAoZXZvaXQpIHdyb3RlOg0KPiANCj4gWy4uLl0NCj4gDQo+ID4gSSB0aGluayB0aGF0IEkgd291
bGQgY2FsbCB0aGUgZmVhdHVyZSAic3VwcG9ydHMtdnJmIiByYXRoZXIgdGhhbiAidnJmIi4NCj4g
Pg0KPiA+IDxFcmljPiDigJxzdXBwb3J0cy12cmbigJ0gaXMgZmluZSB3aXRoIG1lLiAgQWxzbyBh
cyB3ZSBvbmx5IGhhdmUgb25lIHRyYW5zcG9ydA0KPiBwZXIgc3Vic2NyaXB0aW9uLCBhbnkgZXJy
b3IgY2hlY2tpbmcgb24gY29uZmlndXJhdGlvbiBzaG91bGQgYmUNCj4gc3RyYWlnaHRmb3J3YXJk
Lg0KPiA+DQo+IA0KPiBTaW5jZSB0aGlzIHNhbWUgcXVlc3Rpb24gKGhvdyB0byBzdXBwb3J0IFZS
RnMpIGhhcyBjb21lIHVwIGluIG90aGVyDQo+IGNvbnRleHRzLCBpdCB3b3VsZCByZWFsbHkgYmUg
Z29vZCBpZiBpdCB3b3VsZCBiZSBkb2N1bWVudGVkLCBzYXkgaW4gdGhlDQo+IG5ldHdvcmsgaW5z
dGFuY2VzIGRyYWZ0LCBob3cgb3RoZXIgcHJvdG9jb2wgbW9kZWxzIHNob3VsZCByZWZlciB0byBW
UkZzIC0NCj4gaWRlYWxseSB3aXRoIHRoZSByYXRpb25hbGUgYmVoaW5kIGl0Lg0KDQpJIGFncmVl
IHRoYXQgaXQgd291bGQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIHN1cHBvcnRpbmcgY29udGV4dCB3
aXRoaW4gdGhlIG5ldHdvcmsgaW5zdGFuY2VzIGRyYWZ0LiAgU29tZSBlbGVtZW50cyB3b3J0aCBj
b3ZlcmluZzoNCg0KKGEpIGEgInN1cHBvcnRzLXZyZiIgaWYtZmVhdHVyZSBtYWludGFpbmVkIHdp
dGhpbiBuZXR3b3JrLWluc3RhbmNlcyB3aGljaCBpcyBhdmFpbGFibGUgdG8gYW55IG1vZGVsIHdh
bnRpbmcgdG8gcmVmZXIgdG8gYSBWUkYuDQoNCihiKSBFeGFtcGxlcyBvZiBjb25zdHJhaW50IGNo
ZWNraW5nIHRvIHNlZSBpZiBhIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25h
bWUgaXMgb25seSBvZiByb290IHR5cGU6ICB2cmYtcm9vdCBvciB2di1yb290LiAgKEkuZS4sIGRv
bid0IGxldCBzb21lb25lIGNvbmZpZ3VyZSBhbiBMMlZQTiB2aWEgYSBMZWFmcmVmKQ0KDQpFcmlj
DQoNCj4gL2pzDQo+IA0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph
Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg
ICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICAr
NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv
Pg0K


From nobody Mon Nov 20 11:15:40 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E0C12EA42 for ; Mon, 20 Nov 2017 11:15:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SsoIyhhUJmC for ; Mon, 20 Nov 2017 11:15:36 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9CC12E957 for ; Mon, 20 Nov 2017 11:15:36 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AB161B323B22E for ; Mon, 20 Nov 2017 19:15:31 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 20 Nov 2017 19:15:27 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 11:15:21 -0800
From: Alexander Clemm 
To: "Eric Voit (evoit)" , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
Thread-Index: AdNdw8aKy+YwdoNoSQ+TUlgDzy0olQAeDkqAAAup5YAAADJegAAM8isAAAKQ2AAAEmQFgAABSSsAAEbK8YAAiAjnkA==
Date: Mon, 20 Nov 2017 19:15:20 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8D8@sjceml521-mbx.china.huawei.com>
References: <20171115.164247.1419508866071356464.mbj@tail-f.com> <7da6319e524f4c6b85652c0fdaf6644c@XCH-RTP-013.cisco.com> <86ABB0EE-0201-4B57-AA3A-EDE516AFE82F@cisco.com> <20171116.085331.436907075368637840.mbj@tail-f.com>  <1056296126874cfc9b52000290e84d67@XCH-RTP-013.cisco.com>
In-Reply-To: <1056296126874cfc9b52000290e84d67@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.57]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:15:39 -0000

SGksDQoNClllcywgcGVyIHRoZSBkaXNjdXNzaW9uIGluIHRoZSByb29tIEkgdGhpbmsgdGhpcyBt
YWtlcyBzZW5zZSwgYXMgaXQga2VlcHMgdGhpbmdzIHNpbXBsZXIgKGZvciB0aGUgOTArJSBvZiBj
YXNlcyB0aGF0IGhhdmUgbm8gbmVlZCBmb3IgbXVsdGlwbGUgdHJhbnNwb3J0cyBldGMpLiAgDQoN
Ckp1c3QgdG8gY2xhcmlmeSwgdGhpcyBtZWFucyBib3RoIGNvbW1vbiB0cmFuc3BvcnQgYW5kIGNv
bW1vbiBlbmNvZGluZy4gIA0KLS0tIEFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgRXJpYyBWb2l0DQo+IChldm9pdCkNCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAx
NywgMjAxNyAxMDoxNyBBTQ0KPiBUbzogbmV0Y29uZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog
W05ldGNvbmZdIElzc3VlIFNOICM0OiBDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVu
dA0KPiByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/DQo+IA0K
PiBJbiB0aGUgbWVldGluZyByb29tIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBORVRDT05GIFdHLCBz
ZW50aW1lbnQgd2FzIHRvDQo+IHVzZSBhIGNvbW1vbiBUcmFuc3BvcnQgYWNyb3NzIGFsbCByZWNl
aXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJlZA0KPiBzdWJzY3JpcHRpb24uICAgVGhpcyB3YXMg
cHJvcG9zYWwgKDIpIGJlbG93Lg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHNlZSBpZiB0aGVyZSBp
cyBhbnkgb2JqZWN0aW9uIHRvIHRoaXMuICAgSWYgbm90LCB3ZSBjYW4gY2xvc2UgdGhpcw0KPiBp
c3N1ZSBpbiBhIGZldyB3ZWVrcy4NCj4gDQo+IEVyaWMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0DQo+ID4gKGV2b2l0KQ0KPiA+IFNlbnQ6IFRo
dXJzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNyAzOjMwIEFNDQo+ID4gVG86IE1hcnRpbiBCam9ya2x1
bmQgPG1iakB0YWlsLWYuY29tPjsgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pDQo+ID4g
PGVpbmFybm5AY2lzY28uY29tPg0KPiA+IENjOiBuZXRjb25mQGlldGYub3JnDQo+ID4gU3ViamVj
dDogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNDogQ2FuIFRyYW5zcG9ydCB2YXJ5IGFjcm9zcw0K
PiA+IGRpZmZlcmVudCByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJlZCBzdWJzY3JpcHRp
b24/DQo+ID4NCj4gPiBIaSBNYXJ0aW4sDQo+ID4NCj4gPiBZZXMsIEkgb3JpZ2luYWxseSBoYWQg
Ym90aCB5b3VyIG9wdGlvbnMgaW4gdGhlIFdHIHNsaWRlcy4gICAgSSByZW1vdmVkIChBKQ0KPiA+
IGFmdGVyIGRpc2N1c3Npb24gd2l0aCBNYWhlc2ggZm9yIHRoZSBXRyBzZXNzaW9uIHNsaWRlcyB0
byBzaW1wbGlmeSB0aGUNCj4gPiBpbi0gcm9vbSBkaXNjdXNzaW9ucywgYXMgd2VsbCBhcyBjb25z
aWRlcmF0aW9uIG9mIHRoZSBwb2ludHMgRWluYXIgbWFrZXMNCj4gYmVsb3cuDQo+ID4gV2UgY2Fu
IG9mIGNvdXJzZSBoYXZlIG1vcmUgYW5kIGRlZXBlciByZXNvbHV0aW9uIGRpc2N1c3Npb25zIGhl
cmUuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gRXJpYw0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0
YWlsLWYuY29tXQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3IDI6NTQg
QU0NCj4gPiA+IFRvOiBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgPGVpbmFybm5AY2lz
Y28uY29tPg0KPiA+ID4gQ2M6IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+OyBu
ZXRjb25mQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM0
OiBDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzDQo+ID4gPiBkaWZmZXJlbnQgcmVjZWl2ZXJzIG9m
IGEgc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KPiA+ID4NCj4gPiA+IEhpLA0KPiA+
ID4NCj4gPiA+IE5vdGUgdGhhdCB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgY3VycmVudCBtb2RlbCBo
YXM6DQo+ID4gPg0KPiA+ID4gICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBbaWRlbnRpZmllcl0N
Cj4gPiA+ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgZW5jb2RpbmcNCj4gPiA+
ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgcmVjZWl2ZXJzDQo+ID4gPiAgICAg
ICAgICAgICArLS1ydyByZWNlaXZlciogW2FkZHJlc3MgcG9ydF0NCj4gPiA+ICAgICAgICAgICAg
ICAgIC4uLg0KPiA+ID4gICAgICAgICAgICAgICAgKy0tcncgcHJvdG9jb2wNCj4gPiA+DQo+ID4g
PiBNeSBwcm9wb3NhbCBpcyBoYXZlIGVuY29kaW5nIGFuZCBwcm90b2NvbCB0b2dldGhlcjoNCj4g
PiA+DQo+ID4gPiAoQSkNCj4gPiA+ICAgICAgICstLXJ3IHN1YnNjcmlwdGlvbiogW2lkZW50aWZp
ZXJdDQo+ID4gPiAgICAgICAgICAuLi4NCj4gPiA+ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAg
ICAgKy0tcncgcmVjZWl2ZXJzDQo+ID4gPiAgICAgICAgICAgICArLS1ydyByZWNlaXZlciogW2Fk
ZHJlc3MgcG9ydF0NCj4gPiA+ICAgICAgICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgICAg
ICAgKy0tcncgcHJvdG9jb2wNCj4gPiA+ICAgICAgICAgICAgICAgICstLXJ3IGVuY29kaW5nDQo+
ID4gPg0KPiA+ID4gb3I6DQo+ID4gPg0KPiA+ID4gKEIpDQo+ID4gPiAgICAgICArLS1ydyBzdWJz
Y3JpcHRpb24qIFtpZGVudGlmaWVyXQ0KPiA+ID4gICAgICAgICAgLi4uDQo+ID4gPiAgICAgICAg
ICArLS1ydyBlbmNvZGluZw0KPiA+ID4gICAgICAgICAgKy0tcncgcHJvdG9jb2wNCj4gPiA+ICAg
ICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgcmVjZWl2ZXJzDQo+ID4gPiAgICAgICAg
ICAgICArLS1ydyByZWNlaXZlciogW2FkZHJlc3MgcG9ydF0NCj4gPiA+ICAgICAgICAgICAgICAg
IC4uLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgdGhhdCB0aGlzIGlzICpsZXNzKiBjb21wbGV4IGFu
ZCBwcm9iYWJseSBtb3JlIG9wdGltYWwgdGhhbg0KPiA+ID4gdGhlIGN1cnJlbnQgc29sdXRpb24u
DQo+ID4gPg0KPiA+ID4gIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSIgPGVpbmFybm5A
Y2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gTWFydGluLA0KPiA+ID4gPg0KPiA+ID4gPiBBcyB5
ZXQsIHdlIGhhdmUgbm8gcHJhY3RpY2FsIHVzZSBjYXNlcyB3aGVyZSB3ZSB3b3VsZCBoYXZlIGEN
Cj4gPiA+ID4gc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdpdGggbXVsdGlwbGUgcmVj
ZWl2ZXJzIHdobyB3aXNoIHRvDQo+ID4gPiA+IHJlY2VpdmUgdGhlIGRhdGEgaW4gZGlmZmVyZW50
IGZvcm1hdHMuIFRodXMgc3VwcG9ydGluZyB0aGlzIHNlZW1zDQo+ID4gPiA+IGxpa2UgYW4gdW5u
ZWNlc3NhcnkgY29tcGxleGl0eSBmb3IgcGxhdGZvcm1zLCBhbmQgb25lIHdoaWNoDQo+ID4gPiA+
IHBvdGVudGlhbGx5IGltcGFjdHMgb3B0aW1pc2F0aW9ucyB0aGF0IHdlIGFscmVhZHkgdXNlIGlu
IHNvbWUNCj4gPiA+ID4gcGxhdGZvcm0gaW1wbGVtZW50YXRpb25zIChlLmcuIHNlbmRpbmcgdGhl
IHNhbWUgZW5jb2RlZCBQRFUgdG8NCj4gPiA+ID4gbXVsdGlwbGUgcmVjZWl2ZXJzLCByZWxpZXZp
bmcgdGhlIHBsYXRmb3JtIG9mIGVuY29kaW5nIHRoZSBzYW1lDQo+ID4gPiA+IGRhdGEgbXVsdGlw
bGUgd2F5cykuDQo+ID4gPg0KPiA+ID4gQnV0IHRoaXMgb3B0aW1pemF0aW9uIGRvZXNuJ3QgcmVh
bGx5IHdvcmssIGFzIHlvdSBub3RlIGJlbG93ICgqKS4NCj4gPiA+DQo+ID4gPiA+IE9mIGNvdXJz
ZSwgaWYgYSBjbGllbnQgcmVhbGx5IHdhbnRzIHRvIGhhdmUgdGhlIHNhbWUgZGF0YSBzZW50IHRv
DQo+ID4gPiA+IG11bHRpcGxlIHJlY2VpdmVycyBidXQgaW4gZGlmZmVyZW50IGZvcm1hdHMsIHRo
ZXkgY2FuIGRvIHRoaXMg4oCUDQo+ID4gPiA+IGp1c3QgcHJvdmlzaW9uIHNlcGFyYXRlIHN1YnNj
cmlwdGlvbnMgd2l0aCB0aGUgc2FtZSBmaWx0ZXIuDQo+ID4gPg0KPiA+ID4gRXhhY3RseTsgdGhp
cyBpcyBtb3JlIGNvbXBsZXggYW5kIGxlc3Mgb3B0aW1hbCBzaW5jZSB0aGUgc2FtZSBmaWx0ZXIN
Cj4gPiA+IG1pZ2h0IGJlIGV2YWx1YXRlZCB0d2ljZSwgdW5sZXNzIHlvdSBhZGQgY29kZSB0byBv
cHRpbWl6ZSBmb3IgdGhhdA0KPiA+ID4gKHdoaWNoIHByb2JhYmx5IGZhbGxzIGluIHlvdXIgY2F0
ZWdvcnkgb2YgInVubmVjZXNzYXJ5IGNvbXBsZXhpdHkiKS4NCj4gPiA+DQo+ID4gPiAoKikgU28g
aWYgdGhlIG9wZXJhdG9yIHJlcXVpcmVzIHRoaXMgc2V0dXAsIGhlIHdpbGwgaGF2ZSB0bw0KPiA+
ID4gY29uZmlndXJlIHR3byBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucyB0b2RheS4gIFRodXMsIHRo
ZSBwbGF0Zm9ybQ0KPiA+ID4gd2lsbCBlbmNvZGUgdGhlIGRhdGEgdHdpY2UsIGFuZCB5b3VyIG9w
dGltaXphdGlvbiBhYm92ZSB3b24ndCBoZWxwLg0KPiA+ID4NCj4gPiA+ID4gQWxsLWluLWFsbCwg
SSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiBtYWtpbmcgdGhlIGJhc2UgbW9kZWwNCj4gPiA+
ID4gc3VwcG9ydCB0aGlzLCBvbmx5IGRvd25zaWRlcywgc28gZG8geW91IGhhdmUgYW55IHNwZWNp
ZmljIHVzZQ0KPiA+ID4gPiBjYXNlcyBpbiBtaW5kIHdoZXJlIHRoaXMgd291bGQgYmUgYSBiZW5l
Zml0PyBTbyBmYXIgaW4gdGhlIHVzZQ0KPiA+ID4gPiBjYXNlcyB3ZSBoYXZlIGxvb2tlZCBhdCBp
biBTUCwgREMsIGVudGVycHJpc2UgYW5kIElvVCB3ZSBoYXZlIG5vdA0KPiA+ID4gPiBzZWVuIGFu
eSByZXF1aXJlbWVudCB0byBzdXBwb3J0IHRoaXMsIGJ1dCB3ZSBoYXZlIHNlZW4gdGhlIG5lZWQN
Cj4gPiA+ID4gZm9yIG11bHRpcGxlDQo+ID4gcmVjZWl2ZXJzIChlLmcuDQo+ID4gPiA+IHRvIHN1
cHBvcnQgSEEvcmVkdW5kYW5jeSBhcHByb2FjaGVzKS4NCj4gPiA+DQo+ID4gPiBUaGUgY3VycmVu
dCBtb2RlbCBzdXBwb3J0cyBkaWZmZXJlbnQgKnByb3RvY29scyogZm9yIHRoZSBkaWZmZXJlbnQN
Cj4gPiA+IHJlY2VpdmVycy4gIERvIHlvdSBoYXZlIGEgdXNlIGNhc2Ugc3VwcG9ydGluZyB0aGF0
LCBvciB3b3VsZCAoQikNCj4gPiA+IGFib3ZlIGZ1bGZpbCB5b3VyIHJlcXVpcmVtZW50cy4NCj4g
PiA+DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBB
cyBzdWNoLCBJIHdvdWxkIGJlDQo+ID4gPiA+IHJlbHVjdGFudCB0byBhZGQgdGhpcyB0byB0aGUg
ZHJhZnQgYXQgdGhpcyBzdGFnZSB3aGVuIHRoZQ0KPiA+ID4gPiBmdW5jdGlvbmFsaXR5IGNhbiBi
ZSBhY2hpZXZlZCBhbHJlYWR5IGlmIGFic29sdXRlbHkgbmVjZXNzYXJ5Lg0KPiA+ID4gPg0KPiA+
ID4gPiBDaGVlcnMsDQo+ID4gPiA+DQo+ID4gPiA+IEVpbmFyDQo+ID4gPiA+DQo+ID4gPiA+DQo+
ID4gPiA+ID4gT24gMTUgTm92IDIwMTcsIGF0IDIxOjUzLCBFcmljIFZvaXQgKGV2b2l0KSA8ZXZv
aXRAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFkZGluZyBFaW5hciBh
cyBoZSBoYWQgc29tZSBzdHJvbmcgb3BpbmlvbnMgb24gdGhpcyBhIGZldyB5ZWFycw0KPiA+ID4g
PiA+IGFnbyB3aGVuIHdlIHdlcmUgc2V0dGluZyB0aGUgbW9kZWwuLi4NCj4gPiA+ID4gPg0KPiA+
ID4gPiA+DQo+ID4gPiA+ID4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQsIE5vdmVtYmVyIDE1LCAy
MDE3IDEwOjQzIEFNDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ICJFcmljIFZvaXQgKGV2b2l0KSIg
PGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4+PiBIaSBNYXJ0aW4sDQo+ID4gPiA+
ID4+Pg0KPiA+ID4gPiA+Pj4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0bzptYmpAdGFp
bC1mLmNvbV0NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+ICJFcmljIFZvaXQgKGV2b2l0KSIg
PGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4+Pj4+IEluIHRoZSBXRyBzZXNzaW9u
IHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBnZXQgImh1bQ0KPiBmZWVkYmFjayINCj4gPiA+IG9u
Og0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+
Pj4+PiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4gPiA+
ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUy
NzdiaXMvaXNzdWVzLzQNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+
Pj4NCj4gPiA+ID4gPj4+Pj4gVGhlIHR3byBjaG9pY2VzIGFuZCB0aGVpciBpc3N1ZXMgZXhwb3Nl
ZCBkdXJpbmcgdGhlIHR3byB3ZWVrDQo+ID4gPiA+ID4+Pj4+IHJldmlldyBvbg0KPiA+ID4gPiA+
Pj4+ICJDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVudCByZWNlaXZlcnMgb2YgYSBz
aW5nbGUNCj4gPiA+ID4gPj4+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8iIGFyZToNCj4gPiA+
ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gKDEp
IFllcywgVHJhbnNwb3J0IGNhbiB2YXJ5IGJ5IHJlY2VpdmVyDQo+ID4gPiA+ID4+Pj4+DQo+ID4g
PiA+ID4+Pj4+ICogICAgICAgIEZld2VyIHN1YnNjcmlwdGlvbnMgKHNjYWxlIGJlbmVmaXQpDQo+
ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIENhbiBjb252ZXJ0IHRyYW5zcG9y
dCB3aXRob3V0IHJlcXVpcmluZyBhbiBhcHBsaWNhdGlvbiB0bw0KPiA+ID4gbGVhcm4NCj4gPiA+
ID4gPj4gYQ0KPiA+ID4gPiA+Pj4+IG11bHRpcGxlIHN1YnNjcmlwdGlvbiBpZHMNCj4gPiA+ID4g
Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4gKiAgICAgICAgTm8gZHVwbGljYXRpb24gb2YgY29udGVudCBk
dXJpbmcgdHJhbnNwb3J0IGNvbnZlcnNpb24uDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+
ICogICAgICAgIChQb3RlbnRpYWwgY29uZnVzaW9uIGluIGFsbG93aW5nIHRyYW5zcG9ydCB0byB2
YXJ5LCBidXQNCj4gPiA+ID4gPj4+Pj4gKiAgICAgICAgZW5jb2RpbmcNCj4gPiA+ID4gPj4gbm90
DQo+ID4gPiA+ID4+Pj4gdG8gdmFyeT8pDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+
ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICgyKSBObywgb25seSBvbmUgVHJhbnNwb3J0IGFj
cm9zcyBhbGwgc3Vic2NyaXB0aW9ucw0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiAqICAg
ICAgICBTaW1wbGVyIG1vZGVsDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAg
IEJ1dCBhcHBsaWNhdGlvbnMgbWF5IG5lZWQgdG8gY3JlYXRlIGFuZCB0cmFjayBtdWx0aXBsZQ0K
PiA+ID4gPiA+Pj4+IHN1YnNjcmlwdGlvbi1pZHMgZm9yIHRoZSBzYW1lIGNvbnRlbnQuDQo+ID4g
PiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIFRlbXBvcmFyeSBkdXBsaWNhdGlvbiBv
ZiBjb250ZW50IHN0cmVhbXMgZHVyaW5nIHRyYW5zcG9ydA0KPiA+ID4gPiA+PiBjaGFuZ2UuDQo+
ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+
IFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDEpLg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4g
QWN0dWFsbHksIHRoZSBnaXRodWIgaXNzdWUgbGlzdHMgMyBvcHRpb25zLCBidXQgaGVyZSB5b3Ug
anVzdCBsaXN0IDIuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gSW4gcmV2aWV3aW5nIHRvbW9y
cm93J3Mgc2xpZGVzIHdpdGggTWFoZXNoLCBoZSBwcmVmZXJyZWQgMg0KPiA+IG9wdGlvbnMuDQo+
ID4gPiA+ID4+PiBBbmQgYXMgdmFyeWluZyB0aGUgZW5jb2RpbmcgYnkgcmVjZWl2ZXIgc2VlbXMg
dW5saWtlbHkgaW4NCj4gPiA+ID4gPj4+IGltcGxlbWVudGF0aW9uDQo+ID4gPiA+ID4+DQo+ID4g
PiA+ID4+IFdoeSBpcyB0aGlzIHVubGlrZWx5PyAgU3VwcG9zZSBJIGhhdmUgdHdvIHJlY2VpdmVy
cyBmb3IgdGhlDQo+ID4gPiA+ID4+IHNhbWUgc3Vic2NyaXB0aW9uLCBvbmUgd2FudHMgTkVUQ09O
Ri9YTUwgYW5kIHRoZSBvdGhlcg0KPiA+ID4gUkVTVENPTkYvSlNPTi4NCj4gPiA+ID4gPj4gSXMg
dGhhdCB1bmxpa2VseT8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEVpbmFyJ3MgYmVsaWVmIHdhcyB0
aGF0IGEgcHVibGlzaGVyIGltcGxlbWVudGF0aW9uIHdvdWxkIGJlDQo+ID4gPiA+ID4gdW5saWtl
bHkgdG8gc2VydmljZSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gaW50byBtdWx0aXBsZSBlbmNvZGlu
Z3MuDQo+ID4gPiA+ID4gSWYgc3VjaCBhIGNvbmRpdGlvbiBleGlzdGVkLCBpdCB3b3VsZCBiZSBm
YXIgZWFzaWVyIHRvIGNyZWF0ZQ0KPiA+ID4gPiA+IHR3bw0KPiA+IHN1YnNjcmlwdGlvbnMuDQo+
ID4gPiA+ID4gVGhpcyBhbHNvIHdvdWxkIGhhdmUgZmV3ZXIgZXJyb3IgY29uZGl0aW9ucy4NCj4g
PiA+ID4gPg0KPiA+ID4gPiA+Pj4gLCB0aGVyZSBpcyBsaXR0bGUgcmVhc29uIHRvIHNvY2lhbGl6
ZSB0aGlzIHVubGlrZWx5IHZhcmlhbnQgYmVmb3JlDQo+ID4gPiA+ID4+PiB0aGUgd2hvbGUgV0cu
ICAgU2luY2UgYXMgeW91ciBvcGluaW9uIHdhcyBlaXRoZXIgYm90aCBlbmNvZGluZw0KPiA+IGFu
ZA0KPiA+ID4gPiA+Pj4gdHJhbnNwb3J0IG9yIG5laXRoZXIgZW5jb2RpbmcgYW5kIHRyYW5zcG9y
dCB2YXJ5IGJ5IHJlY2VpdmVyLA0KPiA+ID4gPiA+Pj4gdGhlIG1vcmUgbGlrZWx5IG9mIHlvdXIg
cHJpbWFyeSBhc2sgaXMgc3VwcG9ydGVkLg0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+DQo+ID4g
PiA+ID4+Pj4gSSB0aGluayB0aGUgcG9pbnQgaXMgdGhhdCBpbiB0aGUgdGVybSAiVHJhbnNwb3J0
Iiwgd2UgbmVlZCB0bw0KPiA+ID4gPiA+Pj4+IGluY2x1ZGUgYm90aCBwcm90b2NvbCBhbmQgZW5j
b2RpbmcgKGluIHRoZSBjYXNlIHRoZSBwcm90b2NvbA0KPiA+ID4gPiA+Pj4+IHN1cHBvcnRzIG11
bHRpcGxlIGVuY29kaW5ncykuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gV2hpbGUgbW9zdCBs
aWtlbHkgdGhlIGNhc2UgZm9yIE5FVENPTkYgYW5kIFJFU1RDT05GLCBUaWFucmFuJ3MNCj4gPiA+
ID4gPj4+IGRyYWZ0LWlldGYtbmV0Y29uZi11ZHAtcHViLWNoYW5uZWwgc2hvd3MgdGhhdCB0aGVy
ZSBjYW4gYmUNCj4gPiBlbmNvZGluZw0KPiA+ID4gPiA+Pj4gdmFyaWF0aW9uIGJ5IHRyYW5zcG9y
dHMgLiAgIEl0IFRoZXJlZm9yZSBpdCBzZWVtcyBiZXR0ZXIgdG8gbGV0IHRoZW0NCj4gPiA+ID4g
Pj4+IGJvdGggdmFyeSBpbmRlcGVuZGVudGx5Lg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBOb3Qg
c3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4gIFRvIGJlIGNsZWFyLCBkbyB5b3UgdGhp
bmsNCj4gPiA+ID4gPj4gdGhlICJlbmNvZGluZyIgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBp
cywgb3IgYmUgbW92ZWQgZG93bg0KPiA+ID4gPiA+PiB0byB0aGUgcmVjZWl2ZXIsIGFzIGEgc2li
bGluZyB0byAicHJvdG9jb2wiPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRW5jb2RpbmcgbGVhZiBz
aG91bGQgc3RheSB3aGVyZSBpdCBpcy4gIFlvdXIgcHJldmlvdXMgYXNrIHdhcyB0bw0KPiA+ID4g
PiA+IHB1dCBlbmNvZGluZyBhbmQgdHJhbnNwb3J0IGFuZCB0aGUgc2FtZSBsZXZlbC4gVGhlcmUg
aXMgYW4NCj4gPiA+ID4gPiBvcHRpb24gcHJvcG9zZWQgaW4gdGhlIHNsaWRlcyB3aGljaCBkb2Vz
IHRoYXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4NCj4gPiA+ID4gPj4g
L21hcnRpbg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5l
dGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldGNvbmYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Mon Nov 20 11:27:04 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1512EA57 for ; Mon, 20 Nov 2017 11:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ATgDqWy2QmiT for ; Mon, 20 Nov 2017 11:27:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A1312EA58 for ; Mon, 20 Nov 2017 11:26:59 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8D72145A6F3EA for ; Mon, 20 Nov 2017 19:26:55 +0000 (GMT)
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.361.1; Mon, 20 Nov 2017 19:26:57 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 11:26:51 -0800
From: Alexander Clemm 
To: Robert Wilton , "Eric Voit (evoit)" ,  "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwARwawAAAUK44AAg9S/gAAA/l0AAIdhYyA=
Date: Mon, 20 Nov 2017 19:26:51 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com>
In-Reply-To: <31442888-3dba-7834-c408-bd7986b9e381@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.57]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:27:02 -0000

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

SSBhbSBmaW5lIHdpdGggdGhhdCBjaGFuZ2UsIGJ1dCB3YW50ZWQgdG8gYnJpbmcgdXAgb25lIGFk
ZGl0aW9uYWwgb3B0aW9uIHRoYXQgd2FzIGFsc28gYnJpZWZseSBtZW50aW9uZWQgaW4gdGhlIHJv
b20gd2hpY2ggc3RyaWtlcyBtZSBhcyBwZXJoYXBzIGEgYml0IG1vcmUgZWxlZ2FudC4gIFRoYXQg
aXMgdGhlIG9wdGlvbiB0byB1c2UgYXVnbWVudGF0aW9uLiAgSW4gdGhhdCBjYXNlLCBzb3VyY2Ut
dnJmIGFuZCB0aGUgaW1wb3J0IHN0YXRlbWVudCB3b3VsZCBzaW1wbHkgYmUgb21pdHRlZC4gSW5z
dGVhZCwgYSBuZXcgbW9kdWxlIHdvdWxkIGJlIGNyZWF0ZWQgKGUuZy4gaWV0Zi12cmYtZm9yLXN1
YnNjcmliZWQtbm90aWZpY2F0aW9ucyksIHdoaWNoIGNvbnRhaW5zIHRoZSBpbXBvcnQgc3RhdGVt
ZW50IGFuZCB0d28gYXVnbWVudHMgc3RhdGVtZW50cyB0byBhdWdtZW50IHRoZSBzb3VyY2UtdnJm
IGludG8gdGhlIGV4aXN0aW5nIG1vZHVsZS4NCg0KLS0tIEFsZXgNCg0KRnJvbTogTmV0Y29uZiBb
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBXaWx0
b24NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTcsIDIwMTcgMTA6NDYgQU0NClRvOiBFcmljIFZv
aXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPjsgbmV0Y29uZkBpZXRmLm9yZzsgTG91IEJlcmdl
ciA8bGJlcmdlckBsYWJuLm5ldD4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6
IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8N
Cg0KDQpPbiAxNy8xMS8yMDE3IDE4OjE3LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCkkgd291
bGQgbGlrZSB0byBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZyb20gb3Vy
IHNlc3Npb24uICAgSSB0aGluayB3ZSBjYW1lIHRvIGFncmVlbWVudCBhbW9uZyB0aGUgYXR0ZW5k
ZWVzLiAgIEhvcGVmdWxseSB0aGlzIHRocmVhZCBjYW4gY29uZmlybSwgb3IgcmVmaW5lIGFzIG5l
ZWQuDQoNCkZpcnN0IGxldOKAmXMgbG9vayBhdCBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93Og0K
VGhlcmUgYXJlIGxvdHMgb2YgZ29vZCBlbGVtZW50cyBpbiBSb2JlcnTigJlzIHByb3Bvc2FsIGJl
bG93LCBidXQgaXQgaXNu4oCZdCB1cCB0byBvdXIgV0cgdG8gZGV0ZXJtaW5lIHRoZSBwcm9wZXIg
c3RydWN0dXJlIG9mIHRoZSBuZXR3b3JrLWluc3RhbmNlLW1vZGVsLiAgIEF1dGhvcnMgb2YgdGhh
dCBtb2RlbCB3ZXJlIGluIHRoZSByb29tLCBhbmQgYXJlIGF3YXJlIHRoYXQgWUFORyBtb2RlbCBk
ZXZlbG9wZXJzIGZyb20gb3V0c2lkZSB3b3VsZCB3ZWxjb21lIGEgcGFydGl0aW9uaW5nIHdoaWNo
IGRlY291cGxlcyBhbnkgbGlua2FnZXMgdG8gc2NoZW1hLW1vdW50IHdoZW4gYWxsIHRoYXQgaXMg
bmVlZGVkIGlzIHRvIGlkZW50aWZ5IGEgVlJGIGJ5IG5hbWUuDQoNCkxvb2tpbmcgYXQgd2hhdCB3
ZSBjYW4gY29udHJvbCwgZGlzY3Vzc2VkIGluIHRoZSByb29tIHdhcyB0aGUgZm9sbG93aW5nIGNo
YW5nZSB0byBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6DQoNCjEuICAgICAgIGltcG9ydCDigJxp
ZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCg0KMi4gICAgICAgY3JlYXRlIGlmLWZlYXR1cmUg4oCc
VlJG4oCdLg0KDQozLiAgICAgICBhcHBseSBmZWF0dXJlIOKAnFZSRuKAnSB0byBvYmplY3Qg4oCc
c291cmNlLVZSRuKAnQ0KDQo0LiAgICAgICBMZWFmcmVmIHRvIOKAnHNvdXJjZS1WUkbigJ0gdG8g
dmFsaWRhdGUgYWdhaW5zdCB0aGUgbmV0d29yay1pbnN0YW5jZSBtb2RlbOKAmXMgL25ldHdvcmst
aW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZS4NCg0KVGhpcyBpcyB0aGUgY3VycmVudCBw
cm9wb3NhbC4gIEFyZSB0aGVyZSBhcmUgY29uY2VybnMvb2JqZWN0aW9ucy9yZWZpbmVtZW50cz8N
Cg0KTm8gY29uY2VybnMsIGJ1dCBwZXJoYXBzIG9uZSB0cml2aWFsIHJlZmluZW1lbnQuDQoNCkkg
aGFkIG1pc3Rha2VubHkgdGhvdWdodCB0aGF0IGEgZGV2aWNlIHdvdWxkIGVpdGhlciBzdXBwb3J0
IFZSRnMgZm9yIGFsbCBwcm90b2NvbHMgb3Igbm9uZSwgaGVuY2UgbXkgc3VnZ2VzdGlvbiB0byBo
YXZlIGEgc2luZ2xlICJWUkYiIGZlYXR1cmUsIHdoaWNoIHdvdWxkIG5hdHVyYWxseSBiZSBkZWZp
bmVkIGJ5IHRoZSBuZXR3b3JrLWluc3RhbmNlcyBtb2RlbC4NCg0KSW4gdGhlIGRpc2N1c3Npb25z
IHRoYXQgSSBoYWQgd2l0aCBMb3UsIHNvbWUgb2YgdGhlbSBhdCB0aGUgbWljLCBzb21lIGFmdGVy
d2FyZHMsIExvdSBjbGFyaWZpZWQgdGhhdCBpdCBxdWl0ZSBwbGF1c2libGUgdGhhdCBWUkZzIG1h
eSBvbmx5IGJlIHN1cHBvcnRlZCBieSBzb21lIHByb3RvY29scyBvbiBhIGRldmljZSBhbmQgbm90
IGFsbCwgYW5kIGhlbmNlIHRoZSBzb2x1dGlvbiBvZiBoYXZpbmcgYSAiVlJGIiBmZWF0dXJlIHBl
ciBwcm90b2NvbCBzZWVtcyBsaWtlIHRoZSByaWdodCBzb2x1dGlvbi4NCg0KSSB0aGluayB0aGF0
IEkgd291bGQgY2FsbCB0aGUgZmVhdHVyZSAic3VwcG9ydHMtdnJmIiByYXRoZXIgdGhhbiAidnJm
Ii4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KDQoNCkVyaWMNCg0KDQoNCkZyb206IE5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZvaXQgKGV2
b2l0KQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgMTA6MjMgUE0NClRvOiBSb2Jl
cnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9u
QGNpc2NvLmNvbT48bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPjsgbmV0Y29uZkBpZXRmLm9yZzxt
YWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+PG1h
aWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAj
NTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u
Pw0KDQpBZ3JlZSBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbS4NCg0KSSB3b3VsZCBkZWZlciB0byBM
b3UgYW5kIHRoZSBvdGhlciBhdXRob3JzIG9mIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXMg
dGhpcyB3b3VsZCBiZSBhIGZhaXJseSBzaWduaWZpY2FudCBjaGFuZ2UuDQoNCkVyaWMNCg0KRnJv
bTogUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIgMTQsIDIwMTcgNzo1OCBQTQ0KDQpIaSBFcmljLCBM
b3UsDQoNClRoaXMgc2VlbXMgdG8gYmUgYSBnZW5lcmljIHByb2JsZW0uDQoNCkNvdWxkIHRoZSBW
UkYgbGVhZnJlZiBuYW1lIGRlcGVuZGVuY3kgaXNzdWUgYmUgc29sdmVkIHdpdGggYW4gaWYtZmVh
dHVyZSBzdGF0ZW1lbnQ/Lg0KDQpJLmUuY291bGQgdGhlIG5ldHdvcmsgaW5zdGFuY2UgZHJhZnQg
ZGVmaW5lIGEgc2VwYXJhdGUgWUFORyBtb2R1bGUgKHdpdGggbm8gZGVwZW5kZW5jaWVzKSB0aGF0
IGRlZmluZXMgYSAiVlJGIiBmZWF0dXJlLg0KDQpBbGwgdGhlIFZSRiByZWZlcmVuY2VzIChpZGVh
bGx5IGlmIGFsbCBJRVRGIFlBTkcgbW9kdWxlcyB0aGF0IG1heSBvcHRpb25hbGx5IGRlcGVuZCBv
biBWUkZzKSBjb3VsZCBiZSBsZWFmLXJlZnMgdG8gL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmst
aW5zdGFuY2UvbmFtZSBidXQgcHJlZGljYXRlZCB3aXRoIGFuIGlmLWZlYXR1cmUgIm5pOnZyZiIu
DQoNCkhlbmNlIGlmIGEgZGV2aWNlIGRvZXNuJ3Qgc3VwcG9ydCBWUkZzLCB0aGVuIGl0IGRvZXNu
J3QgaW1wbGVtZW50IHRoZSAidnJmIiBmZWF0dXJlLCBzbyBpdCBkb2Vzbid0IGhhdmUgdG8gaW1w
bGVtZW50IHRoZSBmdWxsIG5ldHdvcmsgaW5zdGFuY2VzIG1vZHVsZSwgb3Igc2NoZW1hIG1vdW50
Lg0KDQpUaGFua3MsDQpSb2INCg0KT24gMTUvMTEvMjAxNyAwODo0NSwgRXJpYyBWb2l0IChldm9p
dCkgd3JvdGU6DQoNCkluIHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBn
ZXQg4oCcaHVtIGZlZWRiYWNr4oCdIG9uOg0KDQoNCg0KZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNj
cmliZWQtbm90aWZpY2F0aW9ucw0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1
Mjc3YmlzL2lzc3Vlcy81DQoNCg0KDQpUaGUgdHdvIGNob2ljZXMgZXhwb3NlZCBkdXJpbmcgdGhl
IHR3byB3ZWVrIHJldmlldyBmb3IgaG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZp
Z3VyZWQgc3Vic2NyaXB0aW9uIHdlcmU6DQoNCg0KDQooMSkgTGVhZnJlZiB0byDigJxpZXRmLW5l
dHdvcmstaW5zdGFuY2XigJ0gIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25h
bWUNCg0KwrcgICAgICAgICBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1vdW50IGZvciBz
dWJzY3JpcHRpb25zLg0KDQrCtyAgICAgICAgIFNvdXJjZSBWUkYgaXMgYW4gb3B0aW9uYWwgY2Fw
YWJpbGl0eSwgYnV0IHB1Ymxpc2hlcnMgdGhhdCBkb27igJl0IGNhcmUgYWJvdXQgVlJGcyBtdXN0
IHN0aWxsIGltcG9ydC4gIChOb3RlOiBjb3VsZCBhbHNvIGF1Z21lbnQgdGhlIGxlYWZyZWYgaW4g
YW5vdGhlciBtb2RlbCwgYnV0IHRoYXQgYWRkcyBhbm90aGVyIGxheWVyIG9mIGNvbXBsZXhpdHkp
DQoNCsK3ICAgICAgICAgZXN0YWJsaXNoZXMgbW9kZWwgZGVwZW5kZW5jeSB0byBkcmFmdC1pZXRm
LXJ0Z3dnLW5pLW1vZGVsDQoNCg0KDQooMikgVXNlIGEgc3RyaW5nIHdoaWNoIHdvdWxkIGJlIHBv
cHVsYXRlZCB3aXRoIGV4YWN0IHNhbWUgbmFtZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJlZiBv
ZiAoMSkNCg0KwrcgICAgICAgICBQb3NzaWJsZSB0byBuYW1lIFZSRiB3aGljaCBkb2VzbuKAmXQg
ZXhpc3QNCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KDQoNCg0KVGhhbmtzLA0K
DQpFcmljDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KDQpOZXRjb25mQGlldGYub3JnPG1h
aWx0bzpOZXRjb25mQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldGNvbmYNCg0KLg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg
MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNv
bG9yOmJsYWNrO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs
YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjY2
Mzk4NTI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot
MTgyMDgwMDEyMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3MDMz
MzQwMzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02
MDM0MDgwODIgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMwMjU0MzgxMjsNCgltc28tbGlzdC10eXBl
Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4Mzc3NDY0MzYgNjc2OTg2ODkgNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIj
MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYW0gZmluZSB3
aXRoIHRoYXQgY2hhbmdlLCBidXQgd2FudGVkIHRvIGJyaW5nIHVwIG9uZSBhZGRpdGlvbmFsIG9w
dGlvbiB0aGF0IHdhcyBhbHNvIGJyaWVmbHkgbWVudGlvbmVkIGluIHRoZSByb29tIHdoaWNoIHN0
cmlrZXMgbWUgYXMgcGVyaGFwcyBhIGJpdCBtb3JlIGVsZWdhbnQuJm5ic3A7IFRoYXQgaXMgdGhl
IG9wdGlvbiB0byB1c2UgYXVnbWVudGF0aW9uLiZuYnNwOyBJbg0KIHRoYXQgY2FzZSwgc291cmNl
LXZyZiBhbmQgdGhlIGltcG9ydCBzdGF0ZW1lbnQgd291bGQgc2ltcGx5IGJlIG9taXR0ZWQuIElu
c3RlYWQsIGEgbmV3IG1vZHVsZSB3b3VsZCBiZSBjcmVhdGVkIChlLmcuIGlldGYtdnJmLWZvci1z
dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMpLCB3aGljaCBjb250YWlucyB0aGUgaW1wb3J0IHN0YXRl
bWVudCBhbmQgdHdvIGF1Z21lbnRzIHN0YXRlbWVudHMgdG8gYXVnbWVudCB0aGUgc291cmNlLXZy
ZiBpbnRvIHRoZQ0KIGV4aXN0aW5nIG1vZHVsZS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi
bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5Sb2JlcnQgV2lsdG9uPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1i
ZXIgMTcsIDIwMTcgMTA6NDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgVm9pdCAoZXZvaXQpICZs
dDtldm9pdEBjaXNjby5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnOyBMb3UgQmVyZ2VyICZsdDts
YmVyZ2VyQGxhYm4ubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIElz
c3VlIFNOICM1OiBIb3cgdG8gcmVwcmVzZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJz
Y3JpcHRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNy8xMS8yMDE3IDE4OjE3LCBFcmlj
IFZvaXQgKGV2b2l0KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+SSB3b3VsZCBsaWtlIHRvIGNv
bnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMgZnJvbSBvdXIgc2Vzc2lvbi4mbmJz
cDsmbmJzcDsgSSB0aGluayB3ZSBjYW1lIHRvIGFncmVlbWVudCBhbW9uZyB0aGUgYXR0ZW5kZWVz
LiZuYnNwOyZuYnNwOyBIb3BlZnVsbHkgdGhpcyB0aHJlYWQgY2FuIGNvbmZpcm0sIG9yIHJlZmlu
ZSBhcyBuZWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Rmlyc3QgbGV0
4oCZcyBsb29rIGF0IFJvYmVydOKAmXMgcHJvcG9zYWwgYmVsb3c6PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPlRo
ZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxlbWVudHMgaW4gUm9iZXJ04oCZcyBwcm9wb3NhbCBiZWxv
dywgYnV0IGl0IGlzbuKAmXQgdXAgdG8gb3VyIFdHIHRvIGRldGVybWluZSB0aGUgcHJvcGVyIHN0
cnVjdHVyZSBvZiB0aGUgbmV0d29yay1pbnN0YW5jZS1tb2RlbC4mbmJzcDsmbmJzcDsgQXV0aG9y
cyBvZiB0aGF0IG1vZGVsIHdlcmUgaW4gdGhlIHJvb20sIGFuZCBhcmUgYXdhcmUgdGhhdA0KIFlB
TkcgbW9kZWwgZGV2ZWxvcGVycyBmcm9tIG91dHNpZGUgd291bGQgd2VsY29tZSBhIHBhcnRpdGlv
bmluZyB3aGljaCBkZWNvdXBsZXMgYW55IGxpbmthZ2VzIHRvIHNjaGVtYS1tb3VudCB3aGVuIGFs
bCB0aGF0IGlzIG5lZWRlZCBpcyB0byBpZGVudGlmeSBhIFZSRiBieSBuYW1lLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3
NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+TG9va2luZyBhdCB3aGF0IHdlIGNhbiBjb250cm9s
LCBkaXNjdXNzZWQgaW4gdGhlIHJvb20gd2FzIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHN1YnNj
cmliZWQtbm90aWZpY2F0aW9uczogJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6
bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlz
dDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5pbXBvcnQg4oCcaWV0Zi1u
ZXR3b3JrLWluc3RhbmNl4oCdJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg
bGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ
Z25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+
PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5jcmVhdGUgaWYtZmVhdHVyZSDi
gJxWUkbigJ0uICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0
UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs
Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4z
LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlm
XT48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+YXBwbHkgZmVhdHVyZSDigJxWUkbigJ0gdG8g
b2JqZWN0IOKAnHNvdXJjZS1WUkbigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs
ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln
bm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48
IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkxlYWZyZWYgdG8g4oCcc291cmNl
LVZSRuKAnSB0byB2YWxpZGF0ZSBhZ2FpbnN0IHRoZSBuZXR3b3JrLWluc3RhbmNlIG1vZGVs4oCZ
cyAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lLiZuYnNwOw0KPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi4yNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYi
PlRoaXMgaXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwuJm5ic3A7IEFyZSB0aGVyZSBhcmUgY29uY2Vy
bnMvb2JqZWN0aW9ucy9yZWZpbmVtZW50cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCk5v
IGNvbmNlcm5zLCBidXQgcGVyaGFwcyBvbmUgdHJpdmlhbCByZWZpbmVtZW50Ljxicj4NCjxicj4N
CkkgaGFkIG1pc3Rha2VubHkgdGhvdWdodCB0aGF0IGEgZGV2aWNlIHdvdWxkIGVpdGhlciBzdXBw
b3J0IFZSRnMgZm9yIGFsbCBwcm90b2NvbHMgb3Igbm9uZSwgaGVuY2UgbXkgc3VnZ2VzdGlvbiB0
byBoYXZlIGEgc2luZ2xlICZxdW90O1ZSRiZxdW90OyBmZWF0dXJlLCB3aGljaCB3b3VsZCBuYXR1
cmFsbHkgYmUgZGVmaW5lZCBieSB0aGUgbmV0d29yay1pbnN0YW5jZXMgbW9kZWwuPGJyPg0KPGJy
Pg0KSW4gdGhlIGRpc2N1c3Npb25zIHRoYXQgSSBoYWQgd2l0aCBMb3UsIHNvbWUgb2YgdGhlbSBh
dCB0aGUgbWljLCBzb21lIGFmdGVyd2FyZHMsIExvdSBjbGFyaWZpZWQgdGhhdCBpdCBxdWl0ZSBw
bGF1c2libGUgdGhhdCBWUkZzIG1heSBvbmx5IGJlIHN1cHBvcnRlZCBieSBzb21lIHByb3RvY29s
cyBvbiBhIGRldmljZSBhbmQgbm90IGFsbCwgYW5kIGhlbmNlIHRoZSBzb2x1dGlvbiBvZiBoYXZp
bmcgYSAmcXVvdDtWUkYmcXVvdDsgZmVhdHVyZSBwZXIgcHJvdG9jb2wNCiBzZWVtcyBsaWtlIHRo
ZSByaWdodCBzb2x1dGlvbi48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgSSB3b3VsZCBjYWxsIHRo
ZSBmZWF0dXJlICZxdW90O3N1cHBvcnRzLXZyZiZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDt2cmYm
cXVvdDsuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxicj4NCjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5FcmljPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1
QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0Ij4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm
Lm9yZyI+bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPkVyaWMgVm9pdCAoZXZvaXQpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVt
YmVyIDE0LCAyMDE3IDEwOjIzIFBNPGJyPg0KPGI+VG86PC9iPiBSb2JlcnQgV2lsdG9uIC1YIChy
d2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxhIGhyZWY9Im1haWx0bzpyd2lsdG9u
QGNpc2NvLmNvbSI+DQombHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFp
bHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+OyBMb3UgQmVyZ2VyDQo8
YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7
PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cg
dG8gcmVwcmVzZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiM1QjlCRDUiPkFncmVlIGl0IGlzIGEgZ2VuZXJpYyBwcm9ibGVtLiA8L3NwYW4+DQo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5
QkQ1Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzVCOUJENSI+SSB3b3VsZCBkZWZlciB0byBMb3UgYW5kIHRoZSBv
dGhlciBhdXRob3JzIG9mIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXMgdGhpcyB3b3VsZCBi
ZSBhIGZhaXJseSBzaWduaWZpY2FudCBjaGFuZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlCRDUiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojNUI5QkQ1Ij5FcmljIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0
O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24sIE5vdmVtYmVyIDE0LCAyMDE3
IDc6NTggUE08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+SGkgRXJp
YywgTG91LDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBzZWVtcyB0byBiZSBhIGdlbmVyaWMgcHJv
YmxlbS48bzpwPjwvbzpwPjwvcD4NCjxwPkNvdWxkIHRoZSBWUkYgbGVhZnJlZiBuYW1lIGRlcGVu
ZGVuY3kgaXNzdWUgYmUgc29sdmVkIHdpdGggYW4gaWYtZmVhdHVyZSBzdGF0ZW1lbnQ/LjxvOnA+
PC9vOnA+PC9wPg0KPHA+SS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3RhbmNlIGRyYWZ0IGRlZmlu
ZSBhIHNlcGFyYXRlIFlBTkcgbW9kdWxlICh3aXRoIG5vIGRlcGVuZGVuY2llcykgdGhhdCBkZWZp
bmVzIGEgJnF1b3Q7VlJGJnF1b3Q7IGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cD5BbGwgdGhl
IFZSRiByZWZlcmVuY2VzIChpZGVhbGx5IGlmIGFsbCBJRVRGIFlBTkcgbW9kdWxlcyB0aGF0IG1h
eSBvcHRpb25hbGx5IGRlcGVuZCBvbiBWUkZzKSBjb3VsZCBiZSBsZWFmLXJlZnMgdG8gL25ldHdv
cmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZSBidXQgcHJlZGljYXRlZCB3aXRoIGFu
IGlmLWZlYXR1cmUgJnF1b3Q7bmk6dnJmJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHA+SGVuY2Ug
aWYgYSBkZXZpY2UgZG9lc24ndCBzdXBwb3J0IFZSRnMsIHRoZW4gaXQgZG9lc24ndCBpbXBsZW1l
bnQgdGhlICZxdW90O3ZyZiZxdW90OyBmZWF0dXJlLCBzbyBpdCBkb2Vzbid0IGhhdmUgdG8gaW1w
bGVtZW50IHRoZSBmdWxsIG5ldHdvcmsgaW5zdGFuY2VzIG1vZHVsZSwgb3Igc2NoZW1hIG1vdW50
LjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gMTUvMTEvMjAxNyAwODo0NSwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gdGhl
IFdHIHNlc3Npb24gdG9tb3Jyb3csIEkgYW0gaG9waW5nIHRvIGdldCDigJxodW0gZmVlZGJhY2vi
gJ0gb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmRyYWZ0LWlldGYtbmV0Y29uZi1z
dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1Mjc3Ymlz
L2lzc3Vlcy81Ij5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1Mjc3YmlzL2lzc3Vl
cy81PC9hPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB0d28gY2hvaWNlcyBl
eHBvc2VkIGR1cmluZyB0aGUgdHdvIHdlZWsgcmV2aWV3IGZvciBob3cgdG8gcmVwcmVzZW50IFNv
dXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gd2VyZTo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+KDEpIExlYWZyZWYgdG8g4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCd
Jm5ic3A7IC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWU8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl
eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9y
dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv
LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Q3JlYXRlcyBkZXBlbmRlbmN5IG9u
IHNjaGVtYSBtb3VudCBmb3Igc3Vic2NyaXB0aW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4y
NWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi
PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48
L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Tb3VyY2UgVlJGIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxp
dHksIGJ1dCBwdWJsaXNoZXJzIHRoYXQgZG9u4oCZdCBjYXJlIGFib3V0IFZSRnMgbXVzdCBzdGls
bCBpbXBvcnQuJm5ic3A7IChOb3RlOiBjb3VsZCBhbHNvIGF1Z21lbnQgdGhlIGxlYWZyZWYgaW4g
YW5vdGhlciBtb2RlbCwgYnV0IHRoYXQgYWRkcyBhbm90aGVyIGxheWVyIG9mIGNvbXBsZXhpdHkp
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFb
aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4g
c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmVzdGFibGlzaGVz
IG1vZGVsIGRlcGVuZGVuY3kgdG8gZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4oMikgVXNlIGEgc3RyaW5nIHdoaWNoIHdvdWxkIGJlIHBvcHVs
YXRlZCB3aXRoIGV4YWN0IHNhbWUgbmFtZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJlZiBvZiAo
MSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+DQo8
IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3Bh
biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90
O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UG9zc2libGUg
dG8gbmFtZSBWUkYgd2hpY2ggZG9lc27igJl0IGV4aXN0PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPlRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+RXJpYyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls
eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4gLHNlcmlmJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8
YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+TmV0Y29uZiBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86TmV0Y29u
ZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJp
ZiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Lg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5sjceml521mbxchi_--


From nobody Mon Nov 20 11:39:08 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F9912EA93 for ; Mon, 20 Nov 2017 11:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 aDIJf2eSSmX4 for ; Mon, 20 Nov 2017 11:39:04 -0800 (PST)
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 934FA120713 for ; Mon, 20 Nov 2017 11:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40530; q=dns/txt; s=iport; t=1511206744; x=1512416344; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DBoDwqZmQGTDqCSo9fyVos2TD3tCxRZluQeoLsjnnl8=; b=b3iOxef9WS1EGPVhZfMDPwVHo/MzlpYG7V6VdrX0esw8/Y3EIlfxkq5x 7B3f3StB57FW6KQgACVWx/y/eHG8tj2fbpVchmenno4hksC85KztLqWK2 kFkpRYmdCVv5U+cTXNnk3Ze7egpmHgOrDA7y9fkOTp3/TFXA+8pgjwUCl E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAADILhNa/5hdJa1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkQuZm4nB4N4ih+PKIF9lmKCDgMKGAEKhANGTwIahGM/GAE?= =?us-ascii?q?BAQEBAQEBAWsohR4BAQEBAwEBIQpBGwIBCBEEAQEOEwEGAwICAiULFAkIAgQBE?= =?us-ascii?q?ggTiSZkEKhKgicmilABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYUUhHA?= =?us-ascii?q?EPh+CX4JjBZF0hy6JHAKHcI0Rk1WMcokTAhEZAYE5AR85gXR6FUmCZIMRgU53i?= =?us-ascii?q?QUCJQeBBYEUAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,429,1505779200";  d="scan'208,217";a="326570661"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 19:39:03 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAKJd3c6030977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 19:39:03 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 14:39:02 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 14:39:02 -0500
From: "Eric Voit (evoit)" 
To: Alexander Clemm , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAJhO04AACinC0A==
Date: Mon, 20 Nov 2017 19:39:02 +0000
Message-ID: <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_317134acb7bd4778b95b76554aeb93b0XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:39:07 -0000

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

SSBhZ3JlZSB0aGlzIGlzIG1vcmUgZWxlZ2FudCBpZiB3ZSBsb29rIGp1c3QgYXQgc3Vic2NyaWJl
ZC1ub3RpZmljYXRpb25zLiAgIEhvd2V2ZXIgZXh0cmFwb2xhdGluZyB0aGlzIG1lYW5zIHRoYXQg
d2UgaGF2ZSBhIGR1cGxpY2F0ZSBZQU5HIG1vZHVsZSBldmVyeSB0aW1lIHdlIGhhdmUgYSBWUkYu
ICAgQW5kIGluIG91ciBjYXNlIHdoZW4gd2UgYXVnbWVudCB5YW5nLXB1c2gsIHdoaWNoIG1vZGVs
IGRvIHdlIHN0YXJ0IGZyb20/DQoNCkVyaWMNCg0KRnJvbTogQWxleGFuZGVyIENsZW1tIFttYWls
dG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDIw
LCAyMDE3IDI6MjcgUE0NClRvOiBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJ
TUlURUQgYXQgQ2lzY28pIDxyd2lsdG9uQGNpc2NvLmNvbT47IEVyaWMgVm9pdCAoZXZvaXQpIDxl
dm9pdEBjaXNjby5jb20+OyBuZXRjb25mQGlldGYub3JnOyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh
Ym4ubmV0Pg0KU3ViamVjdDogUkU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJl
c2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KDQpJIGFtIGZpbmUg
d2l0aCB0aGF0IGNoYW5nZSwgYnV0IHdhbnRlZCB0byBicmluZyB1cCBvbmUgYWRkaXRpb25hbCBv
cHRpb24gdGhhdCB3YXMgYWxzbyBicmllZmx5IG1lbnRpb25lZCBpbiB0aGUgcm9vbSB3aGljaCBz
dHJpa2VzIG1lIGFzIHBlcmhhcHMgYSBiaXQgbW9yZSBlbGVnYW50LiAgVGhhdCBpcyB0aGUgb3B0
aW9uIHRvIHVzZSBhdWdtZW50YXRpb24uICBJbiB0aGF0IGNhc2UsIHNvdXJjZS12cmYgYW5kIHRo
ZSBpbXBvcnQgc3RhdGVtZW50IHdvdWxkIHNpbXBseSBiZSBvbWl0dGVkLiBJbnN0ZWFkLCBhIG5l
dyBtb2R1bGUgd291bGQgYmUgY3JlYXRlZCAoZS5nLiBpZXRmLXZyZi1mb3Itc3Vic2NyaWJlZC1u
b3RpZmljYXRpb25zKSwgd2hpY2ggY29udGFpbnMgdGhlIGltcG9ydCBzdGF0ZW1lbnQgYW5kIHR3
byBhdWdtZW50cyBzdGF0ZW1lbnRzIHRvIGF1Z21lbnQgdGhlIHNvdXJjZS12cmYgaW50byB0aGUg
ZXhpc3RpbmcgbW9kdWxlLg0KDQotLS0gQWxleA0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0
Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDog
RnJpZGF5LCBOb3ZlbWJlciAxNywgMjAxNyAxMDo0NiBBTQ0KVG86IEVyaWMgVm9pdCAoZXZvaXQp
IDxldm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+OyBuZXRjb25mQGlldGYu
b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l
dDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3Vl
IFNOICM1OiBIb3cgdG8gcmVwcmVzZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3Jp
cHRpb24/DQoNCg0KT24gMTcvMTEvMjAxNyAxODoxNywgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6
DQpJIHdvdWxkIGxpa2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBm
cm9tIG91ciBzZXNzaW9uLiAgIEkgdGhpbmsgd2UgY2FtZSB0byBhZ3JlZW1lbnQgYW1vbmcgdGhl
IGF0dGVuZGVlcy4gICBIb3BlZnVsbHkgdGhpcyB0aHJlYWQgY2FuIGNvbmZpcm0sIG9yIHJlZmlu
ZSBhcyBuZWVkLg0KDQpGaXJzdCBsZXTigJlzIGxvb2sgYXQgUm9iZXJ04oCZcyBwcm9wb3NhbCBi
ZWxvdzoNClRoZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxlbWVudHMgaW4gUm9iZXJ04oCZcyBwcm9w
b3NhbCBiZWxvdywgYnV0IGl0IGlzbuKAmXQgdXAgdG8gb3VyIFdHIHRvIGRldGVybWluZSB0aGUg
cHJvcGVyIHN0cnVjdHVyZSBvZiB0aGUgbmV0d29yay1pbnN0YW5jZS1tb2RlbC4gICBBdXRob3Jz
IG9mIHRoYXQgbW9kZWwgd2VyZSBpbiB0aGUgcm9vbSwgYW5kIGFyZSBhd2FyZSB0aGF0IFlBTkcg
bW9kZWwgZGV2ZWxvcGVycyBmcm9tIG91dHNpZGUgd291bGQgd2VsY29tZSBhIHBhcnRpdGlvbmlu
ZyB3aGljaCBkZWNvdXBsZXMgYW55IGxpbmthZ2VzIHRvIHNjaGVtYS1tb3VudCB3aGVuIGFsbCB0
aGF0IGlzIG5lZWRlZCBpcyB0byBpZGVudGlmeSBhIFZSRiBieSBuYW1lLg0KDQpMb29raW5nIGF0
IHdoYXQgd2UgY2FuIGNvbnRyb2wsIGRpc2N1c3NlZCBpbiB0aGUgcm9vbSB3YXMgdGhlIGZvbGxv
d2luZyBjaGFuZ2UgdG8gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOg0KDQoxLiAgICAgIGltcG9y
dCDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCg0KMi4gICAgICBjcmVhdGUgaWYtZmVhdHVy
ZSDigJxWUkbigJ0uDQoNCjMuICAgICAgYXBwbHkgZmVhdHVyZSDigJxWUkbigJ0gdG8gb2JqZWN0
IOKAnHNvdXJjZS1WUkbigJ0NCg0KNC4gICAgICBMZWFmcmVmIHRvIOKAnHNvdXJjZS1WUkbigJ0g
dG8gdmFsaWRhdGUgYWdhaW5zdCB0aGUgbmV0d29yay1pbnN0YW5jZSBtb2RlbOKAmXMgL25ldHdv
cmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZS4NCg0KVGhpcyBpcyB0aGUgY3VycmVu
dCBwcm9wb3NhbC4gIEFyZSB0aGVyZSBhcmUgY29uY2VybnMvb2JqZWN0aW9ucy9yZWZpbmVtZW50
cz8NCg0KTm8gY29uY2VybnMsIGJ1dCBwZXJoYXBzIG9uZSB0cml2aWFsIHJlZmluZW1lbnQuDQoN
CkkgaGFkIG1pc3Rha2VubHkgdGhvdWdodCB0aGF0IGEgZGV2aWNlIHdvdWxkIGVpdGhlciBzdXBw
b3J0IFZSRnMgZm9yIGFsbCBwcm90b2NvbHMgb3Igbm9uZSwgaGVuY2UgbXkgc3VnZ2VzdGlvbiB0
byBoYXZlIGEgc2luZ2xlICJWUkYiIGZlYXR1cmUsIHdoaWNoIHdvdWxkIG5hdHVyYWxseSBiZSBk
ZWZpbmVkIGJ5IHRoZSBuZXR3b3JrLWluc3RhbmNlcyBtb2RlbC4NCg0KSW4gdGhlIGRpc2N1c3Np
b25zIHRoYXQgSSBoYWQgd2l0aCBMb3UsIHNvbWUgb2YgdGhlbSBhdCB0aGUgbWljLCBzb21lIGFm
dGVyd2FyZHMsIExvdSBjbGFyaWZpZWQgdGhhdCBpdCBxdWl0ZSBwbGF1c2libGUgdGhhdCBWUkZz
IG1heSBvbmx5IGJlIHN1cHBvcnRlZCBieSBzb21lIHByb3RvY29scyBvbiBhIGRldmljZSBhbmQg
bm90IGFsbCwgYW5kIGhlbmNlIHRoZSBzb2x1dGlvbiBvZiBoYXZpbmcgYSAiVlJGIiBmZWF0dXJl
IHBlciBwcm90b2NvbCBzZWVtcyBsaWtlIHRoZSByaWdodCBzb2x1dGlvbi4NCg0KSSB0aGluayB0
aGF0IEkgd291bGQgY2FsbCB0aGUgZmVhdHVyZSAic3VwcG9ydHMtdnJmIiByYXRoZXIgdGhhbiAi
dnJmIi4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KDQpFcmljDQoNCg0KDQpGcm9tOiBOZXRjb25mIFtt
YWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0IChl
dm9pdCkNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDEwOjIzIFBNDQpUbzogUm9i
ZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSA8cndpbHRv
bkBjaXNjby5jb20+PG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmc8
bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pjxt
YWlsdG86bGJlcmdlckBsYWJuLm5ldD4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gSXNzdWUgU04g
IzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlv
bj8NCg0KQWdyZWUgaXQgaXMgYSBnZW5lcmljIHByb2JsZW0uDQoNCkkgd291bGQgZGVmZXIgdG8g
TG91IGFuZCB0aGUgb3RoZXIgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsIGFz
IHRoaXMgd291bGQgYmUgYSBmYWlybHkgc2lnbmlmaWNhbnQgY2hhbmdlLg0KDQpFcmljDQoNCkZy
b206IFJvYmVydCBXaWx0b24sIE5vdmVtYmVyIDE0LCAyMDE3IDc6NTggUE0NCg0KSGkgRXJpYywg
TG91LA0KDQpUaGlzIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBwcm9ibGVtLg0KDQpDb3VsZCB0aGUg
VlJGIGxlYWZyZWYgbmFtZSBkZXBlbmRlbmN5IGlzc3VlIGJlIHNvbHZlZCB3aXRoIGFuIGlmLWZl
YXR1cmUgc3RhdGVtZW50Py4NCg0KSS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3RhbmNlIGRyYWZ0
IGRlZmluZSBhIHNlcGFyYXRlIFlBTkcgbW9kdWxlICh3aXRoIG5vIGRlcGVuZGVuY2llcykgdGhh
dCBkZWZpbmVzIGEgIlZSRiIgZmVhdHVyZS4NCg0KQWxsIHRoZSBWUkYgcmVmZXJlbmNlcyAoaWRl
YWxseSBpZiBhbGwgSUVURiBZQU5HIG1vZHVsZXMgdGhhdCBtYXkgb3B0aW9uYWxseSBkZXBlbmQg
b24gVlJGcykgY291bGQgYmUgbGVhZi1yZWZzIHRvIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3Jr
LWluc3RhbmNlL25hbWUgYnV0IHByZWRpY2F0ZWQgd2l0aCBhbiBpZi1mZWF0dXJlICJuaTp2cmYi
Lg0KDQpIZW5jZSBpZiBhIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBpdCBkb2Vz
bid0IGltcGxlbWVudCB0aGUgInZyZiIgZmVhdHVyZSwgc28gaXQgZG9lc24ndCBoYXZlIHRvIGlt
cGxlbWVudCB0aGUgZnVsbCBuZXR3b3JrIGluc3RhbmNlcyBtb2R1bGUsIG9yIHNjaGVtYSBtb3Vu
dC4NCg0KVGhhbmtzLA0KUm9iDQoNCk9uIDE1LzExLzIwMTcgMDg6NDUsIEVyaWMgVm9pdCAoZXZv
aXQpIHdyb3RlOg0KDQpJbiB0aGUgV0cgc2Vzc2lvbiB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8g
Z2V0IOKAnGh1bSBmZWVkYmFja+KAnSBvbjoNCg0KDQoNCmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMNCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZj
NTI3N2Jpcy9pc3N1ZXMvNQ0KDQoNCg0KVGhlIHR3byBjaG9pY2VzIGV4cG9zZWQgZHVyaW5nIHRo
ZSB0d28gd2VlayByZXZpZXcgZm9yIGhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25m
aWd1cmVkIHN1YnNjcmlwdGlvbiB3ZXJlOg0KDQoNCg0KKDEpIExlYWZyZWYgdG8g4oCcaWV0Zi1u
ZXR3b3JrLWluc3RhbmNl4oCdICAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9u
YW1lDQoNCsK3ICAgICAgICBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1vdW50IGZvciBz
dWJzY3JpcHRpb25zLg0KDQrCtyAgICAgICAgU291cmNlIFZSRiBpcyBhbiBvcHRpb25hbCBjYXBh
YmlsaXR5LCBidXQgcHVibGlzaGVycyB0aGF0IGRvbuKAmXQgY2FyZSBhYm91dCBWUkZzIG11c3Qg
c3RpbGwgaW1wb3J0LiAgKE5vdGU6IGNvdWxkIGFsc28gYXVnbWVudCB0aGUgbGVhZnJlZiBpbiBh
bm90aGVyIG1vZGVsLCBidXQgdGhhdCBhZGRzIGFub3RoZXIgbGF5ZXIgb2YgY29tcGxleGl0eSkN
Cg0KwrcgICAgICAgIGVzdGFibGlzaGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8gZHJhZnQtaWV0Zi1y
dGd3Zy1uaS1tb2RlbA0KDQoNCg0KKDIpIFVzZSBhIHN0cmluZyB3aGljaCB3b3VsZCBiZSBwb3B1
bGF0ZWQgd2l0aCBleGFjdCBzYW1lIG5hbWUgYXMgd291bGQgYmUgaW4gdGhlIGxlYWZyZWYgb2Yg
KDEpDQoNCsK3ICAgICAgICBQb3NzaWJsZSB0byBuYW1lIFZSRiB3aGljaCBkb2VzbuKAmXQgZXhp
c3QNCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KDQoNCg0KVGhhbmtzLA0KDQpF
cmljDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCg0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86
TmV0Y29uZkBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRjb25mDQoNCi4NCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg
MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNv
bG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0
aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjY2Mzk4NTI4Ow0KCW1zby1saXN0LXR5
cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgyMDgwMDEyMCA2NzY5ODY4OSA2
NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5
ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz
dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk
aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3MDMzMzQwMzk7DQoJbXNvLWxpc3QtdHlw
ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02MDM0MDgwODIgNjc2OTg3MDMgNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNv
LWxpc3QtaWQ6MTMwMjU0MzgxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6LTE4Mzc3NDY0MzYgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2
ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg
bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv
dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
Ymdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3
MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhpcyBpcyBtb3JlIGVsZWdhbnQgaWYg
d2UgbG9vayBqdXN0IGF0IHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy4mbmJzcDsmbmJzcDsgSG93
ZXZlciBleHRyYXBvbGF0aW5nIHRoaXMgbWVhbnMgdGhhdCB3ZSBoYXZlIGEgZHVwbGljYXRlIFlB
TkcgbW9kdWxlIGV2ZXJ5IHRpbWUgd2UgaGF2ZSBhIFZSRi4mbmJzcDsmbmJzcDsgQW5kIGluIG91
ciBjYXNlIHdoZW4gd2UgYXVnbWVudCB5YW5nLXB1c2gsDQogd2hpY2ggbW9kZWwgZG8gd2Ugc3Rh
cnQgZnJvbT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu
MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF
MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gQWxleGFuZGVyIENsZW1tIFttYWlsdG86YWxl
eGFuZGVyLmNsZW1tQGh1YXdlaS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3Zl
bWJlciAyMCwgMjAxNyAyOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBSb2JlcnQgV2lsdG9uIC1YIChy
d2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn
dDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDtldm9pdEBjaXNjby5jb20mZ3Q7OyBuZXRjb25mQGll
dGYub3JnOyBMb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0Ozxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSRTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cgdG8gcmVwcmVzZW50IFNvdXJj
ZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYW0g
ZmluZSB3aXRoIHRoYXQgY2hhbmdlLCBidXQgd2FudGVkIHRvIGJyaW5nIHVwIG9uZSBhZGRpdGlv
bmFsIG9wdGlvbiB0aGF0IHdhcyBhbHNvIGJyaWVmbHkgbWVudGlvbmVkIGluIHRoZSByb29tIHdo
aWNoIHN0cmlrZXMgbWUgYXMgcGVyaGFwcyBhIGJpdCBtb3JlIGVsZWdhbnQuJm5ic3A7IFRoYXQg
aXMgdGhlIG9wdGlvbiB0byB1c2UgYXVnbWVudGF0aW9uLiZuYnNwOyBJbg0KIHRoYXQgY2FzZSwg
c291cmNlLXZyZiBhbmQgdGhlIGltcG9ydCBzdGF0ZW1lbnQgd291bGQgc2ltcGx5IGJlIG9taXR0
ZWQuIEluc3RlYWQsIGEgbmV3IG1vZHVsZSB3b3VsZCBiZSBjcmVhdGVkIChlLmcuIGlldGYtdnJm
LWZvci1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMpLCB3aGljaCBjb250YWlucyB0aGUgaW1wb3J0
IHN0YXRlbWVudCBhbmQgdHdvIGF1Z21lbnRzIHN0YXRlbWVudHMgdG8gYXVnbWVudCB0aGUgc291
cmNlLXZyZiBpbnRvIHRoZQ0KIGV4aXN0aW5nIG1vZHVsZS4mbmJzcDsgPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndp
bmRvd3RleHQiPiBOZXRjb25mIFs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+Um9iZXJ0IFdpbHRvbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDE3
LCAyMDE3IDEwOjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDs7DQo8
YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT47IExv
dSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5sYmVyZ2VyQGxh
Ym4ubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBJc3N1ZSBT
TiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0
aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcvMTEvMjAxNyAxODoxNywgRXJpYyBWb2l0
IChldm9pdCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkkgd291bGQgbGlrZSB0byBjb250aW51
ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZyb20gb3VyIHNlc3Npb24uJm5ic3A7Jm5i
c3A7IEkgdGhpbmsgd2UgY2FtZSB0byBhZ3JlZW1lbnQgYW1vbmcgdGhlIGF0dGVuZGVlcy4mbmJz
cDsmbmJzcDsgSG9wZWZ1bGx5IHRoaXMgdGhyZWFkIGNhbiBjb25maXJtLCBvciByZWZpbmUgYXMg
bmVlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkZpcnN0IGxldOKAmXMg
bG9vayBhdCBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5UaGVyZSBh
cmUgbG90cyBvZiBnb29kIGVsZW1lbnRzIGluIFJvYmVydOKAmXMgcHJvcG9zYWwgYmVsb3csIGJ1
dCBpdCBpc27igJl0IHVwIHRvIG91ciBXRyB0byBkZXRlcm1pbmUgdGhlIHByb3BlciBzdHJ1Y3R1
cmUgb2YgdGhlIG5ldHdvcmstaW5zdGFuY2UtbW9kZWwuJm5ic3A7Jm5ic3A7IEF1dGhvcnMgb2Yg
dGhhdCBtb2RlbCB3ZXJlIGluIHRoZSByb29tLCBhbmQgYXJlIGF3YXJlIHRoYXQNCiBZQU5HIG1v
ZGVsIGRldmVsb3BlcnMgZnJvbSBvdXRzaWRlIHdvdWxkIHdlbGNvbWUgYSBwYXJ0aXRpb25pbmcg
d2hpY2ggZGVjb3VwbGVzIGFueSBsaW5rYWdlcyB0byBzY2hlbWEtbW91bnQgd2hlbiBhbGwgdGhh
dCBpcyBuZWVkZWQgaXMgdG8gaWRlbnRpZnkgYSBWUkYgYnkgbmFtZS48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMyRTc1QjYiPkxvb2tpbmcgYXQgd2hhdCB3ZSBjYW4gY29udHJvbCwgZGlz
Y3Vzc2VkIGluIHRoZSByb29tIHdhcyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBzdWJzY3JpYmVk
LW5vdGlmaWNhdGlvbnM6ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl
dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu
b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlm
XT48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+aW1wb3J0IOKAnGlldGYtbmV0d29yay1pbnN0
YW5jZeKAnSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy
YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8y
Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxz
cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz
dHlsZT0iY29sb3I6IzJFNzVCNiI+Y3JlYXRlIGlmLWZlYXR1cmUg4oCcVlJG4oCdLiAmbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9
InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv
cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9u
dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMy
RTc1QjYiPmFwcGx5IGZlYXR1cmUg4oCcVlJG4oCdIHRvIG9iamVjdCDigJxzb3VyY2UtVlJG4oCd
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl
PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw
b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZv
bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MkU3NUI2Ij5MZWFmcmVmIHRvIOKAnHNvdXJjZS1WUkbigJ0gdG8gdmFsaWRhdGUgYWdhaW5zdCB0
aGUgbmV0d29yay1pbnN0YW5jZSBtb2RlbOKAmXMgL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmst
aW5zdGFuY2UvbmFtZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMy
RTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5UaGlzIGlzIHRoZSBjdXJyZW50IHByb3Bvc2Fs
LiZuYnNwOyBBcmUgdGhlcmUgYXJlIGNvbmNlcm5zL29iamVjdGlvbnMvcmVmaW5lbWVudHM/PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCk5v
IGNvbmNlcm5zLCBidXQgcGVyaGFwcyBvbmUgdHJpdmlhbCByZWZpbmVtZW50Ljxicj4NCjxicj4N
CkkgaGFkIG1pc3Rha2VubHkgdGhvdWdodCB0aGF0IGEgZGV2aWNlIHdvdWxkIGVpdGhlciBzdXBw
b3J0IFZSRnMgZm9yIGFsbCBwcm90b2NvbHMgb3Igbm9uZSwgaGVuY2UgbXkgc3VnZ2VzdGlvbiB0
byBoYXZlIGEgc2luZ2xlICZxdW90O1ZSRiZxdW90OyBmZWF0dXJlLCB3aGljaCB3b3VsZCBuYXR1
cmFsbHkgYmUgZGVmaW5lZCBieSB0aGUgbmV0d29yay1pbnN0YW5jZXMgbW9kZWwuPGJyPg0KPGJy
Pg0KSW4gdGhlIGRpc2N1c3Npb25zIHRoYXQgSSBoYWQgd2l0aCBMb3UsIHNvbWUgb2YgdGhlbSBh
dCB0aGUgbWljLCBzb21lIGFmdGVyd2FyZHMsIExvdSBjbGFyaWZpZWQgdGhhdCBpdCBxdWl0ZSBw
bGF1c2libGUgdGhhdCBWUkZzIG1heSBvbmx5IGJlIHN1cHBvcnRlZCBieSBzb21lIHByb3RvY29s
cyBvbiBhIGRldmljZSBhbmQgbm90IGFsbCwgYW5kIGhlbmNlIHRoZSBzb2x1dGlvbiBvZiBoYXZp
bmcgYSAmcXVvdDtWUkYmcXVvdDsgZmVhdHVyZSBwZXIgcHJvdG9jb2wNCiBzZWVtcyBsaWtlIHRo
ZSByaWdodCBzb2x1dGlvbi48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgSSB3b3VsZCBjYWxsIHRo
ZSBmZWF0dXJlICZxdW90O3N1cHBvcnRzLXZyZiZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDt2cmYm
cXVvdDsuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4NCjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5FcmljPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29s
b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0
ZXh0Ij4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i
PkVyaWMgVm9pdCAoZXZvaXQpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDE0
LCAyMDE3IDEwOjIzIFBNPGJyPg0KPGI+VG86PC9iPiBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9u
IC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2Nv
LmNvbSI+DQombHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm5l
dGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+OyBMb3UgQmVyZ2VyDQo8YSBocmVm
PSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PC9hPjxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cgdG8gcmVw
cmVzZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1
QjlCRDUiPkFncmVlIGl0IGlzIGEgZ2VuZXJpYyBwcm9ibGVtLiA8L3NwYW4+DQo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzVCOUJENSI+SSB3b3VsZCBkZWZlciB0byBMb3UgYW5kIHRoZSBvdGhlciBh
dXRob3JzIG9mIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXMgdGhpcyB3b3VsZCBiZSBhIGZh
aXJseSBzaWduaWZpY2FudCBjaGFuZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlCRDUiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5
QkQ1Ij5FcmljIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw
YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24sIE5vdmVtYmVyIDE0LCAyMDE3IDc6NTgg
UE08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+SGkgRXJpYywgTG91
LDxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBzZWVtcyB0byBiZSBhIGdlbmVyaWMgcHJvYmxlbS48
bzpwPjwvbzpwPjwvcD4NCjxwPkNvdWxkIHRoZSBWUkYgbGVhZnJlZiBuYW1lIGRlcGVuZGVuY3kg
aXNzdWUgYmUgc29sdmVkIHdpdGggYW4gaWYtZmVhdHVyZSBzdGF0ZW1lbnQ/LjxvOnA+PC9vOnA+
PC9wPg0KPHA+SS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3RhbmNlIGRyYWZ0IGRlZmluZSBhIHNl
cGFyYXRlIFlBTkcgbW9kdWxlICh3aXRoIG5vIGRlcGVuZGVuY2llcykgdGhhdCBkZWZpbmVzIGEg
JnF1b3Q7VlJGJnF1b3Q7IGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cD5BbGwgdGhlIFZSRiBy
ZWZlcmVuY2VzIChpZGVhbGx5IGlmIGFsbCBJRVRGIFlBTkcgbW9kdWxlcyB0aGF0IG1heSBvcHRp
b25hbGx5IGRlcGVuZCBvbiBWUkZzKSBjb3VsZCBiZSBsZWFmLXJlZnMgdG8gL25ldHdvcmstaW5z
dGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZSBidXQgcHJlZGljYXRlZCB3aXRoIGFuIGlmLWZl
YXR1cmUgJnF1b3Q7bmk6dnJmJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHA+SGVuY2UgaWYgYSBk
ZXZpY2UgZG9lc24ndCBzdXBwb3J0IFZSRnMsIHRoZW4gaXQgZG9lc24ndCBpbXBsZW1lbnQgdGhl
ICZxdW90O3ZyZiZxdW90OyBmZWF0dXJlLCBzbyBpdCBkb2Vzbid0IGhhdmUgdG8gaW1wbGVtZW50
IHRoZSBmdWxsIG5ldHdvcmsgaW5zdGFuY2VzIG1vZHVsZSwgb3Igc2NoZW1hIG1vdW50LjxvOnA+
PC9vOnA+PC9wPg0KPHA+VGhhbmtzLDxicj4NClJvYjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+T24gMTUvMTEvMjAxNyAwODo0NSwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gdGhlIFdHIHNl
c3Npb24gdG9tb3Jyb3csIEkgYW0gaG9waW5nIHRvIGdldCDigJxodW0gZmVlZGJhY2vigJ0gb246
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3Jp
YmVkLW5vdGlmaWNhdGlvbnMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1Mjc3YmlzL2lzc3Vl
cy81Ij5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1Mjc3YmlzL2lzc3Vlcy81PC9h
Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB0d28gY2hvaWNlcyBleHBvc2Vk
IGR1cmluZyB0aGUgdHdvIHdlZWsgcmV2aWV3IGZvciBob3cgdG8gcmVwcmVzZW50IFNvdXJjZSBW
UkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gd2VyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+KDEpIExlYWZyZWYgdG8g4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdJm5ic3A7
IC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWU8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k
ZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz
XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6
SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+
PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Q3JlYXRlcyBkZXBlbmRlbmN5IG9uIHNjaGVtYSBtb3Vu
dCBmb3Igc3Vic2NyaXB0aW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0
OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5
bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu
ZGlmXT5Tb3VyY2UgVlJGIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxpdHksIGJ1dCBwdWJsaXNoZXJz
IHRoYXQgZG9u4oCZdCBjYXJlIGFib3V0IFZSRnMgbXVzdCBzdGlsbCBpbXBvcnQuJm5ic3A7IChO
b3RlOiBjb3VsZCBhbHNvIGF1Z21lbnQgdGhlIGxlYWZyZWYgaW4gYW5vdGhlciBtb2RlbCwgYnV0
IHRoYXQgYWRkcyBhbm90aGVyIGxheWVyIG9mIGNvbXBsZXhpdHkpPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu
dDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln
bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv
c3Bhbj48L3NwYW4+PCFbZW5kaWZdPmVzdGFibGlzaGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8gZHJh
ZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oMikg
VXNlIGEgc3RyaW5nIHdoaWNoIHdvdWxkIGJlIHBvcHVsYXRlZCB3aXRoIGV4YWN0IHNhbWUgbmFt
ZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJlZiBvZiAoMSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0u
MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl
Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu
Pjwvc3Bhbj48IVtlbmRpZl0+UG9zc2libGUgdG8gbmFtZSBWUkYgd2hpY2ggZG9lc27igJl0IGV4
aXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBjdXJyZW50IGRyYWZ0IGRvZXMg
KDIpLiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLDxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RXJpYyA8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4gLHNlcmlm
JnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48
L3ByZT4NCjxwcmU+TmV0Y29uZiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuICxzZXJpZiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_317134acb7bd4778b95b76554aeb93b0XCHRTP013ciscocom_--


From nobody Mon Nov 20 11:41:44 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501F126CC7 for ; Mon, 20 Nov 2017 11:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ascwwy6eZFsc for ; Mon, 20 Nov 2017 11:41:39 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D22C120713 for ; Mon, 20 Nov 2017 11:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26456; q=dns/txt; s=iport; t=1511206899; x=1512416499; h=from:to:cc:subject:date:message-id:mime-version; bh=hzumh8tmye7BJT4MXfIM+4/bxJRugFwlGt7n1vSww68=; b=RAx7wophVFCtNvh62tSUjvF45cyWGSVwTUpsc/yQztgz+SAt2pHcsH3p AkfnlaVHx9qFc1lK+yV/YJ3Fe6tQh9AfehAqkeHRRNu9Hi7BtdnSWzPFM ZWPsLTu7Jl+2NeZSW2j2Jx4TAt6o0sHCmDCg3bbBj1oim2WB5kA4JoYkv I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AACiLhNa/51dJa1UBxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnJmbicHjhePKIF9lmIQggEKhTuEfz8YAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAgIBJwZFBQIFDQEIDgcQEwc5FBIBBA4FCBOJJlwIqkY6inYBAQEBAQEBA?= =?us-ascii?q?wEBAQEBAQEBAR+DNIIHgVWEBoEOhHUOAgOGCwWKNYc/kEoClQGCH4oShySWBQI?= =?us-ascii?q?RGQGBOQEfOYF0ehWDLYJcHIFnd4kFASYDgQmBFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,429,1505779200";  d="scan'208,217";a="316778338"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 19:41:38 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vAKJfcZV006176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 19:41:38 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 14:41:37 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 14:41:37 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund 
CC: "netconf@ietf.org" 
Thread-Topic: RE: Martin's thoughts on subscribed-notifications
Thread-Index: AdNiN42o9mKx4juCSwyTFXMwrJsOIw==
Date: Mon, 20 Nov 2017 19:41:37 +0000
Message-ID: <52d3ea46782e44ba89d02e5366b21c4f@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_52d3ea46782e44ba89d02e5366b21c4fXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Martin's thoughts on subscribed-notifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:41:42 -0000

--_000_52d3ea46782e44ba89d02e5366b21c4fXCHRTP013ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> From: Martin Bjorklund [mailto:mbj@tail-f.com]



> > Agree,  that was always the intent.  The words just need to match to th=
at.

> How about:

> > " If [RFC6241] filtering is supported, the full set of Section 6 must b=
e

> enabled.  If XPATH filtering is supported, the subset of XPATH functional=
ity

> is left to the implementation "

>

> The same argument applies to XPath.  How would this be interoperable

> otherwise?  I suggest you simply remove the sentence

>

>       The subsets of these filtering syntaxes supported are

>       left to each implementation.



Removed

> > > o  Section 2.3

> > >

> > >   The state diagram shows an arrow "modify" from "suspended" to

> > >   "active".  Is this really correct?  Will a suspended subscription b=
e

> > >   resumed if it is modified?

> >

> > Yes.

> > The subscription could immediately be suspended, but this reduces the

> available knobs.

>

> How does it reduce the available knobs?



For dynamic subscriptions, a successful execution of a modify-subscription =
RPC includes an implicit resume.   This is eliminates the need for an addit=
ional "resume" message.   And this should be the most common case.   I have=
 tweaked text to clarify this behavior as follows:



"If the publisher accepts the requested modifications on a currently suspen=
ded subscription, the subscription will immediately be resumed (i.e., the m=
odified subscription is returned to an active status.)  The publisher MAY i=
mmediately suspend this newly modified subscription through the "subscripti=
on-suspended" notification before any event records are sent."



I have also clarified the modify-subscription RPC and subscription-resumed =
notification accordingly.



> I was thinking that if a modify-

> subscription rpc was sent to a suspended subscription, it wouldn't by its=
elf

> change the suspension status; if the server thinks it can be resumed it w=
ill

> resume.



One of the goals for configured subscriptions is that the publisher does no=
t expose information about independent receivers, or activities which occur=
red when the subscription is not connected.   A result of this is that it i=
s best that a subscription-modified not go out to a currently suspended rec=
eiver.    Instead, when a modified subscription resumes for a particular re=
ceiver, the full current state of the subscription is provided if it has be=
en modified.



As an FYI: consider that for configured subscriptions, one of the receivers=
 might not be transport-connected when a configuration is being modified.  =
Even though there are multiple updates, only the last subscription-modified=
 notification need be sent when any suspension ends.



> With the current solution, the server must send three notifications if a

> suspended subscription is modified, and it is still suspended:

>

>   subscription-modified



This notification is only sent for configured subscriptions



>   subscription-resumed

>   subscription-suspended



Per the text above, these three in a row should never happen.  I have updat=
ed the text to clarify as follows...



"If the modification involved changing the policies for the subscription, t=
he publisher sends to currently active receivers a subscription-modified no=
tification.  For any suspended receivers, a subscription-modified notificat=
ion will be delayed until the subscription is resumed.  (Note: it is this s=
ame subscription-modified notification that informs the receiver that the s=
ubscription has been resumed, no additional subscription-resumed need be se=
nt.)"



And I have tweaked the state machine to better express the relationship as =
follows...



                    .-------.

                    | start |

                    '-------'

                        |

                     create

                        |

                        v

        .-------------------------------------------------------------.

  .---. |  Subscription              .------------.                   |

modify \|                            | connecting |-----------.       |

  '---->|      subscription-started--| receiver   |           |       |

        |              |    .------->|            |<-------.  |       |

        |              V    |        '------------'        |  V       |

        |             .--------.                          .---------. |

        |             |active  |--subscription-suspended->|suspended| |

        |subscription-|receiver|                          |receiver | |

        |  -modified  |        |<--subscription-resumed,--|         | |

        |       '---->'--------'   subscription-modified  '---------' |

        '-------------------------------------------------------------'

                        |

                      delete

                        |

                        v

                    .-------.

                    |  end  |

                    '-------'



> > As there are transport specific behaviors.  For NETCONF, see Section 5.=
2 of

> draft-ietf-netconf-netconf-event-notifications.

>

> Ok, makes sense.  I suggest you add a sentence along the lines of:

>

>   How transport failures are dealt with is out of scope for this

>   document.  It is expected that transport-specific documents describe

>   how failures are handled.

>

> > >  Will it buffer events during this time?

> >

> > Events are buffered, if available.  If events are lost (rather than jus=
t

> delayed) due to the loss of transport connectivity, a new subscription-

> started must be sent.  This indicates the discontinuity to the receiver.

>

> I assume this should also be covered by the transport specific documents.

>



There is text around the transport specific behaviors, I would love feedbac=
k if you feel anything is missing.   Certainly a NETCONF session can have a=
 subscription-started sent using a subscription-id which has been previousl=
y reported.



> > >   BTW, why did you rename "configured-subscriptions" to "configured"?

> > >   "configured" looks a bit short.

> >

> > Due to the YANG tree.   The longer feature name causes make a significa=
nt

> number of the lines exceed the character limit for a row.   And things

> become very difficult to read.

>

> I think we should pick descriptive names that make sense, and not names

> that make the tree diagram or whatever look nice.  I suggest you keep the

> original name.

>



The name for "configured" is understandable in this context, is defined in =
the yang model, and makes tree readability easier.



Eric

--_000_52d3ea46782e44ba89d02e5366b21c4fXCHRTP013ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











> From: Martin Bjorklund [mailto:mbj@tail-f.co=
m]


<snip>


> > Agree,  that was always the intent=
.  The words just need to match to that.


> How about:


> > " If [RFC6241] filtering is suppor=
ted, the full set of Section 6 must be


> enabled.  If XPATH filtering is support=
ed, the subset of XPATH functionality


> is left to the implementation "


> 


> The same argument applies to XPath.  Ho=
w would this be interoperable


> otherwise?  I suggest you simply remove=
 the sentence


> 


>       The subs=
ets of these filtering syntaxes supported are


>       left to =
each implementation.


 


Removed




> > > o  Section 2.3


> > >


> > >   The state diagram show=
s an arrow "modify" from "suspended" to


> > >   "active".&nb=
sp; Is this really correct?  Will a suspended subscription be


> > >   resumed if it is modif=
ied?


> >


> > Yes.


> > The subscription could immediately be s=
uspended, but this reduces the


> available knobs.


> 


> How does it reduce the available knobs? =
; 


 


For dynamic subscriptions, a successful execution=
 of a modify-subscription RPC includes an implicit resume.   This=
 is eliminates the need for an additional "resume" message. =
  And this should be the most common case.   I have tweaked
 text to clarify this behavior as follows:


 


"If the publisher accepts the requested modi=
fications on a currently suspended subscription, the subscription will imme=
diately be resumed (i.e., the modified subscription is returned to an activ=
e status.)  The publisher MAY immediately
 suspend this newly modified subscription through the "subscription-su=
spended" notification before any event records are sent."


 


I have also clarified the modify-subscription RPC=
 and subscription-resumed notification accordingly.


 


> I was thinking that if a modify-


> subscription rpc was sent to a suspended sub=
scription, it wouldn't by itself


> change the suspension status; if the server =
thinks it can be resumed it will


> resume.


 


One of the goals for configured subscriptions is =
that the publisher does not expose information about independent receivers,=
 or activities which occurred when the subscription is not connected. =
  A result of this is that it is best that
 a subscription-modified not go out to a currently suspended receiver. =
;   Instead, when a modified subscription resumes for a particula=
r receiver, the full current state of the subscription is provided if it ha=
s been modified.


 


As an FYI: consider that for configured subscript=
ions, one of the receivers might not be transport-connected when a configur=
ation is being modified.  Even though there are multiple updates, only=
 the last subscription-modified notification
 need be sent when any suspension ends.  


 


> With the current solution, the server must s=
end three notifications if a


> suspended subscription is modified, and it i=
s still suspended:


> 


>   subscription-modified


 


This notification is only sent for configured sub=
scriptions


 


>   subscription-resumed


>   subscription-suspended


 


Per the text above, these three in a row should n=
ever happen.  I have updated the text to clarify as follows...


 


"If the modification involved changing the p=
olicies for the subscription, the publisher sends to currently active recei=
vers a subscription-modified notification.  For any suspended receiver=
s, a subscription-modified notification will
 be delayed until the subscription is resumed.  (Note: it is this same=
 subscription-modified notification that informs the receiver that the subs=
cription has been resumed, no additional subscription-resumed need be sent.=
)"


 


And I have tweaked the state machine to better ex=
press the relationship as follows...


 


            =
        .-------.


            =
        | start |


            =
        '-------'


            =
            |


            =
         create

            =
            |


            =
            v &=
nbsp;           &nbs=
p;            &=
nbsp;   



        .-----------------------=
--------------------------------------.


  .---. |  Subscription      &nb=
sp;       .------------.   &nb=
sp;            =
   |


modify \|          &nb=
sp;            =
     | connecting |-----------.    =
   |


  '---->|      subscription-started--| =
receiver   |         =
;  |       |


        |    &nbs=
p;         |    .---=
---->|           =
 |<-------.  |       |


        |    &nbs=
p;         V    |&nb=
sp;       '------------'   &nb=
sp;    |  V       |<=
/o:p>


        |    &nbs=
p;        .--------.   &n=
bsp;            =
;          .---------. |<=
/o:p>


        |    &nbs=
p;        |active  |--subscription-=
suspended->|suspended| |


        |subscription-|receiver| =
;            &n=
bsp;            |rec=
eiver | |


        |  -modified  |&nbs=
p;       |<--subscription-resumed,--| =
;        | |


        |    &nbs=
p;  '---->'--------'   subscription-modified  '-----=
----' |


        '----------------------------=
---------------------------------'


            =
            | &=
nbsp;    



            =
          delete &nb=
sp; 



            =
            |&n=
bsp;    



            =
            v&n=
bsp;      



            =
        .-------.   =
    



            =
        |  end  |


            =
        '-------'


 


> > As there are transport specific behavio=
rs.  For NETCONF, see Section 5.2 of


> draft-ietf-netconf-netconf-event-notificatio=
ns.


> 


> Ok, makes sense.  I suggest you add a s=
entence along the lines of:


> 


>   How transport failures are dealt=
 with is out of scope for this


>   document.  It is expected t=
hat transport-specific documents describe


>   how failures are handled.


> 


> > >  Will it buffer events during=
 this time?


> >


> > Events are buffered, if available. =
; If events are lost (rather than just


> delayed) due to the loss of transport connec=
tivity, a new subscription-


> started must be sent.  This indicates t=
he discontinuity to the receiver.


> 


> I assume this should also be covered by the =
transport specific documents.


> 


 


There is text around the transport specific behav=
iors, I would love feedback if you feel anything is missing.   Ce=
rtainly a NETCONF session can have a subscription-started sent using a subs=
cription-id which has been previously reported.


 


> > >   BTW, why did you renam=
e "configured-subscriptions" to "configured"?


> > >   "configured"=
 looks a bit short.


> >


> > Due to the YANG tree.   The l=
onger feature name causes make a significant


> number of the lines exceed the character lim=
it for a row.   And things


> become very difficult to read.


> 


> I think we should pick descriptive names tha=
t make sense, and not names


> that make the tree diagram or whatever look =
nice.  I suggest you keep the


> original name.


> 


 


The name for "co=
nfigured" is understandable in this context, is defined in the yang mo=
del, and makes tree readability easier.


 


Eric






--_000_52d3ea46782e44ba89d02e5366b21c4fXCHRTP013ciscocom_--


From nobody Mon Nov 20 11:46:15 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8B12EA8C for ; Mon, 20 Nov 2017 11:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QEU7EUMCadlY for ; Mon, 20 Nov 2017 11:46:11 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F71120713 for ; Mon, 20 Nov 2017 11:46:10 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DB2996499A2A for ; Mon, 20 Nov 2017 19:46:06 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 20 Nov 2017 19:46:08 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 11:46:02 -0800
From: Alexander Clemm 
To: "Eric Voit (evoit)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwARwawAAAUK44AAg9S/gAAA/l0AAIdhYyAAEVpeAAAQqIug
Date: Mon, 20 Nov 2017 19:46:01 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com>
In-Reply-To: <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.57]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96Csjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:46:14 -0000

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

SGkgRXJpYywNCg0KSSBhZ3JlZSB0aGF0IHByb2xpZmVyYXRpb24gb2YgbW9kdWxlcyBpcyBhIGNv
bmNlcm4sIGFuZCBjZXJ0YWlubHkgd2Ugd291bGQgbm90IHdhbnQgdG8gcnVuIGludG8gY29tYmlu
YXRvcmlhbCBleHBsb3Npb25zLiAgSG93ZXZlciwgSSBkb27igJl0IHRoaW5rIHRoaXMgd291bGQg
YmUgdGhlIGNhc2UgaGVyZSAtIHdlIHdvdWxkIG5vdCBuZWVkIHRvIGF1Z21lbnQgVlJGIGludG8g
eWFuZy1wdXNoIGFsc28gKG9yIHlhbmctcHVzaCBpbnRvIFZSRikuICBJbnN0ZWFkLCBib3RoIHlh
bmctcHVzaCBhbmQgdnJmLWZvci1ub3RpZmljYXRpb25zIHdvdWxkIGJlIGF1Z21lbnRpbmcgc3Vi
c2NyaWJlZC1ub3RpZmljYXRpb25zIGluIHBhcmFsbGVsLg0KDQotLS0gQWxleA0KDQpGcm9tOiBF
cmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwg
Tm92ZW1iZXIgMjAsIDIwMTcgMTE6MzkgQU0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRl
ci5jbGVtbUBodWF3ZWkuY29tPjsgUm9iZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBM
SU1JVEVEIGF0IENpc2NvKSA8cndpbHRvbkBjaXNjby5jb20+OyBuZXRjb25mQGlldGYub3JnOyBM
b3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KU3ViamVjdDogUkU6IFtOZXRjb25mXSBJc3N1
ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2Ny
aXB0aW9uPw0KDQpJIGFncmVlIHRoaXMgaXMgbW9yZSBlbGVnYW50IGlmIHdlIGxvb2sganVzdCBh
dCBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuICAgSG93ZXZlciBleHRyYXBvbGF0aW5nIHRoaXMg
bWVhbnMgdGhhdCB3ZSBoYXZlIGEgZHVwbGljYXRlIFlBTkcgbW9kdWxlIGV2ZXJ5IHRpbWUgd2Ug
aGF2ZSBhIFZSRi4gICBBbmQgaW4gb3VyIGNhc2Ugd2hlbiB3ZSBhdWdtZW50IHlhbmctcHVzaCwg
d2hpY2ggbW9kZWwgZG8gd2Ugc3RhcnQgZnJvbT8NCg0KRXJpYw0KDQpGcm9tOiBBbGV4YW5kZXIg
Q2xlbW0gW21haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbV0NClNlbnQ6IE1vbmRheSwg
Tm92ZW1iZXIgMjAsIDIwMTcgMjoyNyBQTQ0KVG86IFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24g
LSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2ls
dG9uQGNpc2NvLmNvbT4+OyBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0
bzpldm9pdEBjaXNjby5jb20+PjsgbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRm
Lm9yZz47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5u
ZXQ+Pg0KU3ViamVjdDogUkU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2Vu
dCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KDQpJIGFtIGZpbmUgd2l0
aCB0aGF0IGNoYW5nZSwgYnV0IHdhbnRlZCB0byBicmluZyB1cCBvbmUgYWRkaXRpb25hbCBvcHRp
b24gdGhhdCB3YXMgYWxzbyBicmllZmx5IG1lbnRpb25lZCBpbiB0aGUgcm9vbSB3aGljaCBzdHJp
a2VzIG1lIGFzIHBlcmhhcHMgYSBiaXQgbW9yZSBlbGVnYW50LiAgVGhhdCBpcyB0aGUgb3B0aW9u
IHRvIHVzZSBhdWdtZW50YXRpb24uICBJbiB0aGF0IGNhc2UsIHNvdXJjZS12cmYgYW5kIHRoZSBp
bXBvcnQgc3RhdGVtZW50IHdvdWxkIHNpbXBseSBiZSBvbWl0dGVkLiBJbnN0ZWFkLCBhIG5ldyBt
b2R1bGUgd291bGQgYmUgY3JlYXRlZCAoZS5nLiBpZXRmLXZyZi1mb3Itc3Vic2NyaWJlZC1ub3Rp
ZmljYXRpb25zKSwgd2hpY2ggY29udGFpbnMgdGhlIGltcG9ydCBzdGF0ZW1lbnQgYW5kIHR3byBh
dWdtZW50cyBzdGF0ZW1lbnRzIHRvIGF1Z21lbnQgdGhlIHNvdXJjZS12cmYgaW50byB0aGUgZXhp
c3RpbmcgbW9kdWxlLg0KDQotLS0gQWxleA0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29u
Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogRnJp
ZGF5LCBOb3ZlbWJlciAxNywgMjAxNyAxMDo0NiBBTQ0KVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxl
dm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+OyBuZXRjb25mQGlldGYub3Jn
PG1haWx0bzpuZXRjb25mQGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxt
YWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3VlIFNO
ICM1OiBIb3cgdG8gcmVwcmVzZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRp
b24/DQoNCg0KT24gMTcvMTEvMjAxNyAxODoxNywgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQpJ
IHdvdWxkIGxpa2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBmcm9t
IG91ciBzZXNzaW9uLiAgIEkgdGhpbmsgd2UgY2FtZSB0byBhZ3JlZW1lbnQgYW1vbmcgdGhlIGF0
dGVuZGVlcy4gICBIb3BlZnVsbHkgdGhpcyB0aHJlYWQgY2FuIGNvbmZpcm0sIG9yIHJlZmluZSBh
cyBuZWVkLg0KDQpGaXJzdCBsZXTigJlzIGxvb2sgYXQgUm9iZXJ04oCZcyBwcm9wb3NhbCBiZWxv
dzoNClRoZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxlbWVudHMgaW4gUm9iZXJ04oCZcyBwcm9wb3Nh
bCBiZWxvdywgYnV0IGl0IGlzbuKAmXQgdXAgdG8gb3VyIFdHIHRvIGRldGVybWluZSB0aGUgcHJv
cGVyIHN0cnVjdHVyZSBvZiB0aGUgbmV0d29yay1pbnN0YW5jZS1tb2RlbC4gICBBdXRob3JzIG9m
IHRoYXQgbW9kZWwgd2VyZSBpbiB0aGUgcm9vbSwgYW5kIGFyZSBhd2FyZSB0aGF0IFlBTkcgbW9k
ZWwgZGV2ZWxvcGVycyBmcm9tIG91dHNpZGUgd291bGQgd2VsY29tZSBhIHBhcnRpdGlvbmluZyB3
aGljaCBkZWNvdXBsZXMgYW55IGxpbmthZ2VzIHRvIHNjaGVtYS1tb3VudCB3aGVuIGFsbCB0aGF0
IGlzIG5lZWRlZCBpcyB0byBpZGVudGlmeSBhIFZSRiBieSBuYW1lLg0KDQpMb29raW5nIGF0IHdo
YXQgd2UgY2FuIGNvbnRyb2wsIGRpc2N1c3NlZCBpbiB0aGUgcm9vbSB3YXMgdGhlIGZvbGxvd2lu
ZyBjaGFuZ2UgdG8gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOg0KDQoxLiAgICAgICBpbXBvcnQg
4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdDQoNCjIuICAgICAgIGNyZWF0ZSBpZi1mZWF0dXJl
IOKAnFZSRuKAnS4NCg0KMy4gICAgICAgYXBwbHkgZmVhdHVyZSDigJxWUkbigJ0gdG8gb2JqZWN0
IOKAnHNvdXJjZS1WUkbigJ0NCg0KNC4gICAgICAgTGVhZnJlZiB0byDigJxzb3VyY2UtVlJG4oCd
IHRvIHZhbGlkYXRlIGFnYWluc3QgdGhlIG5ldHdvcmstaW5zdGFuY2UgbW9kZWzigJlzIC9uZXR3
b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUuDQoNClRoaXMgaXMgdGhlIGN1cnJl
bnQgcHJvcG9zYWwuICBBcmUgdGhlcmUgYXJlIGNvbmNlcm5zL29iamVjdGlvbnMvcmVmaW5lbWVu
dHM/DQoNCk5vIGNvbmNlcm5zLCBidXQgcGVyaGFwcyBvbmUgdHJpdmlhbCByZWZpbmVtZW50Lg0K
DQpJIGhhZCBtaXN0YWtlbmx5IHRob3VnaHQgdGhhdCBhIGRldmljZSB3b3VsZCBlaXRoZXIgc3Vw
cG9ydCBWUkZzIGZvciBhbGwgcHJvdG9jb2xzIG9yIG5vbmUsIGhlbmNlIG15IHN1Z2dlc3Rpb24g
dG8gaGF2ZSBhIHNpbmdsZSAiVlJGIiBmZWF0dXJlLCB3aGljaCB3b3VsZCBuYXR1cmFsbHkgYmUg
ZGVmaW5lZCBieSB0aGUgbmV0d29yay1pbnN0YW5jZXMgbW9kZWwuDQoNCkluIHRoZSBkaXNjdXNz
aW9ucyB0aGF0IEkgaGFkIHdpdGggTG91LCBzb21lIG9mIHRoZW0gYXQgdGhlIG1pYywgc29tZSBh
ZnRlcndhcmRzLCBMb3UgY2xhcmlmaWVkIHRoYXQgaXQgcXVpdGUgcGxhdXNpYmxlIHRoYXQgVlJG
cyBtYXkgb25seSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24gYSBkZXZpY2UgYW5k
IG5vdCBhbGwsIGFuZCBoZW5jZSB0aGUgc29sdXRpb24gb2YgaGF2aW5nIGEgIlZSRiIgZmVhdHVy
ZSBwZXIgcHJvdG9jb2wgc2VlbXMgbGlrZSB0aGUgcmlnaHQgc29sdXRpb24uDQoNCkkgdGhpbmsg
dGhhdCBJIHdvdWxkIGNhbGwgdGhlIGZlYXR1cmUgInN1cHBvcnRzLXZyZiIgcmF0aGVyIHRoYW4g
InZyZiIuDQoNClRoYW5rcywNClJvYg0KDQoNCkVyaWMNCg0KDQoNCkZyb206IE5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZvaXQgKGV2
b2l0KQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgMTA6MjMgUE0NClRvOiBSb2Jl
cnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9u
QGNpc2NvLmNvbT48bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPjsgbmV0Y29uZkBpZXRmLm9yZzxt
YWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+PG1h
aWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAj
NTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u
Pw0KDQpBZ3JlZSBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbS4NCg0KSSB3b3VsZCBkZWZlciB0byBM
b3UgYW5kIHRoZSBvdGhlciBhdXRob3JzIG9mIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXMg
dGhpcyB3b3VsZCBiZSBhIGZhaXJseSBzaWduaWZpY2FudCBjaGFuZ2UuDQoNCkVyaWMNCg0KRnJv
bTogUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIgMTQsIDIwMTcgNzo1OCBQTQ0KDQpIaSBFcmljLCBM
b3UsDQoNClRoaXMgc2VlbXMgdG8gYmUgYSBnZW5lcmljIHByb2JsZW0uDQoNCkNvdWxkIHRoZSBW
UkYgbGVhZnJlZiBuYW1lIGRlcGVuZGVuY3kgaXNzdWUgYmUgc29sdmVkIHdpdGggYW4gaWYtZmVh
dHVyZSBzdGF0ZW1lbnQ/Lg0KDQpJLmUuY291bGQgdGhlIG5ldHdvcmsgaW5zdGFuY2UgZHJhZnQg
ZGVmaW5lIGEgc2VwYXJhdGUgWUFORyBtb2R1bGUgKHdpdGggbm8gZGVwZW5kZW5jaWVzKSB0aGF0
IGRlZmluZXMgYSAiVlJGIiBmZWF0dXJlLg0KDQpBbGwgdGhlIFZSRiByZWZlcmVuY2VzIChpZGVh
bGx5IGlmIGFsbCBJRVRGIFlBTkcgbW9kdWxlcyB0aGF0IG1heSBvcHRpb25hbGx5IGRlcGVuZCBv
biBWUkZzKSBjb3VsZCBiZSBsZWFmLXJlZnMgdG8gL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmst
aW5zdGFuY2UvbmFtZSBidXQgcHJlZGljYXRlZCB3aXRoIGFuIGlmLWZlYXR1cmUgIm5pOnZyZiIu
DQoNCkhlbmNlIGlmIGEgZGV2aWNlIGRvZXNuJ3Qgc3VwcG9ydCBWUkZzLCB0aGVuIGl0IGRvZXNu
J3QgaW1wbGVtZW50IHRoZSAidnJmIiBmZWF0dXJlLCBzbyBpdCBkb2Vzbid0IGhhdmUgdG8gaW1w
bGVtZW50IHRoZSBmdWxsIG5ldHdvcmsgaW5zdGFuY2VzIG1vZHVsZSwgb3Igc2NoZW1hIG1vdW50
Lg0KDQpUaGFua3MsDQpSb2INCg0KT24gMTUvMTEvMjAxNyAwODo0NSwgRXJpYyBWb2l0IChldm9p
dCkgd3JvdGU6DQoNCkluIHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBn
ZXQg4oCcaHVtIGZlZWRiYWNr4oCdIG9uOg0KDQoNCg0KZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNj
cmliZWQtbm90aWZpY2F0aW9ucw0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZmM1
Mjc3YmlzL2lzc3Vlcy81DQoNCg0KDQpUaGUgdHdvIGNob2ljZXMgZXhwb3NlZCBkdXJpbmcgdGhl
IHR3byB3ZWVrIHJldmlldyBmb3IgaG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZp
Z3VyZWQgc3Vic2NyaXB0aW9uIHdlcmU6DQoNCg0KDQooMSkgTGVhZnJlZiB0byDigJxpZXRmLW5l
dHdvcmstaW5zdGFuY2XigJ0gIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25h
bWUNCg0KwrcgICAgICAgICBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1vdW50IGZvciBz
dWJzY3JpcHRpb25zLg0KDQrCtyAgICAgICAgIFNvdXJjZSBWUkYgaXMgYW4gb3B0aW9uYWwgY2Fw
YWJpbGl0eSwgYnV0IHB1Ymxpc2hlcnMgdGhhdCBkb27igJl0IGNhcmUgYWJvdXQgVlJGcyBtdXN0
IHN0aWxsIGltcG9ydC4gIChOb3RlOiBjb3VsZCBhbHNvIGF1Z21lbnQgdGhlIGxlYWZyZWYgaW4g
YW5vdGhlciBtb2RlbCwgYnV0IHRoYXQgYWRkcyBhbm90aGVyIGxheWVyIG9mIGNvbXBsZXhpdHkp
DQoNCsK3ICAgICAgICAgZXN0YWJsaXNoZXMgbW9kZWwgZGVwZW5kZW5jeSB0byBkcmFmdC1pZXRm
LXJ0Z3dnLW5pLW1vZGVsDQoNCg0KDQooMikgVXNlIGEgc3RyaW5nIHdoaWNoIHdvdWxkIGJlIHBv
cHVsYXRlZCB3aXRoIGV4YWN0IHNhbWUgbmFtZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJlZiBv
ZiAoMSkNCg0KwrcgICAgICAgICBQb3NzaWJsZSB0byBuYW1lIFZSRiB3aGljaCBkb2VzbuKAmXQg
ZXhpc3QNCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KDQoNCg0KVGhhbmtzLA0K
DQpFcmljDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCk5ldGNvbmYgbWFpbGluZyBsaXN0DQoNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv
Ok5ldGNvbmZAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0Y29uZg0KDQouDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg
MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNv
bG9yOmJsYWNrO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs
YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9y
bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv
bm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg
bDANCgl7bXNvLWxpc3QtaWQ6NjY2Mzk4NTI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z
by1saXN0LXRlbXBsYXRlLWlkczotMTgyMDgwMDEyMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5
MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9
DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl
dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MQ0KCXttc28tbGlzdC1pZDo3MDMzMzQwMzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv
LWxpc3QtdGVtcGxhdGUtaWRzOi02MDM0MDgwODIgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMg
Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K
QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx
OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMwMjU0
MzgxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4
Mzc3NDY0MzYgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2
ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv
Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy
OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN
Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi
IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPkhpIEVyaWMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J
IGFncmVlIHRoYXQgcHJvbGlmZXJhdGlvbiBvZiBtb2R1bGVzIGlzIGEgY29uY2VybiwgYW5kIGNl
cnRhaW5seSB3ZSB3b3VsZCBub3Qgd2FudCB0byBydW4gaW50byBjb21iaW5hdG9yaWFsIGV4cGxv
c2lvbnMuJm5ic3A7IEhvd2V2ZXIsIEkgZG9u4oCZdCB0aGluayB0aGlzIHdvdWxkIGJlIHRoZSBj
YXNlIGhlcmUgLSB3ZSB3b3VsZCBub3QgbmVlZCB0byBhdWdtZW50IFZSRg0KIGludG8geWFuZy1w
dXNoIGFsc28gKG9yIHlhbmctcHVzaCBpbnRvIFZSRikuJm5ic3A7IEluc3RlYWQsIGJvdGggeWFu
Zy1wdXNoIGFuZCB2cmYtZm9yLW5vdGlmaWNhdGlvbnMgd291bGQgYmUgYXVnbWVudGluZyBzdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMgaW4gcGFyYWxsZWwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2lu
ZG93dGV4dCI+IEVyaWMgVm9pdCAoZXZvaXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0KPGJy
Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMjAsIDIwMTcgMTE6MzkgQU08YnI+DQo8
Yj5Ubzo8L2I+IEFsZXhhbmRlciBDbGVtbSAmbHQ7YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20m
Z3Q7OyBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28p
ICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs7IG5ldGNvbmZAaWV0Zi5vcmc7IExvdSBCZXJnZXIg
Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbTmV0Y29u
Zl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVk
IHN1YnNjcmlwdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGlzIGlzIG1vcmUgZWxl
Z2FudCBpZiB3ZSBsb29rIGp1c3QgYXQgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLiZuYnNwOyZu
YnNwOyBIb3dldmVyIGV4dHJhcG9sYXRpbmcgdGhpcyBtZWFucyB0aGF0IHdlIGhhdmUgYSBkdXBs
aWNhdGUgWUFORyBtb2R1bGUgZXZlcnkgdGltZSB3ZSBoYXZlIGEgVlJGLiZuYnNwOyZuYnNwOyBB
bmQgaW4gb3VyIGNhc2Ugd2hlbiB3ZSBhdWdtZW50IHlhbmctcHVzaCwNCiB3aGljaCBtb2RlbCBk
byB3ZSBzdGFydCBmcm9tPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RXJp
YzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBBbGV4YW5kZXIgQ2xlbW0gWzxh
IGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSI+bWFpbHRvOmFsZXhhbmRl
ci5jbGVtbUBodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVt
YmVyIDIwLCAyMDE3IDI6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydCBXaWx0b24gLVggKHJ3
aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2ls
dG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OzsgRXJpYyBWb2l0IChldm9p
dCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPmV2b2l0QGNpc2NvLmNvbTwv
YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5v
cmc8L2E+OyBMb3UgQmVyZ2VyICZsdDs8YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+
bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbTmV0Y29u
Zl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVk
IHN1YnNjcmlwdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbSBmaW5lIHdpdGggdGhhdCBjaGFu
Z2UsIGJ1dCB3YW50ZWQgdG8gYnJpbmcgdXAgb25lIGFkZGl0aW9uYWwgb3B0aW9uIHRoYXQgd2Fz
IGFsc28gYnJpZWZseSBtZW50aW9uZWQgaW4gdGhlIHJvb20gd2hpY2ggc3RyaWtlcyBtZSBhcyBw
ZXJoYXBzIGEgYml0IG1vcmUgZWxlZ2FudC4mbmJzcDsgVGhhdCBpcyB0aGUgb3B0aW9uIHRvIHVz
ZSBhdWdtZW50YXRpb24uJm5ic3A7IEluDQogdGhhdCBjYXNlLCBzb3VyY2UtdnJmIGFuZCB0aGUg
aW1wb3J0IHN0YXRlbWVudCB3b3VsZCBzaW1wbHkgYmUgb21pdHRlZC4gSW5zdGVhZCwgYSBuZXcg
bW9kdWxlIHdvdWxkIGJlIGNyZWF0ZWQgKGUuZy4gaWV0Zi12cmYtZm9yLXN1YnNjcmliZWQtbm90
aWZpY2F0aW9ucyksIHdoaWNoIGNvbnRhaW5zIHRoZSBpbXBvcnQgc3RhdGVtZW50IGFuZCB0d28g
YXVnbWVudHMgc3RhdGVtZW50cyB0byBhdWdtZW50IHRoZSBzb3VyY2UtdnJmIGludG8gdGhlDQog
ZXhpc3RpbmcgbW9kdWxlLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IE5ldGNvbmYg
WzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgV2lsdG9u
PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgMTcsIDIwMTcgMTA6NDYgQU08YnI+
DQo8Yj5Ubzo8L2I+IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRA
Y2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpuZXRj
b25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjsgTG91IEJlcmdlciAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiPmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0Ozxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cgdG8gcmVwcmVz
ZW50IFNvdXJjZSBWUkYgb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiAxNy8xMS8yMDE3IDE4OjE3LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzJFNzVCNiI+SSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9u
IHRoaXMgdG9waWMgZnJvbSBvdXIgc2Vzc2lvbi4mbmJzcDsmbmJzcDsgSSB0aGluayB3ZSBjYW1l
IHRvIGFncmVlbWVudCBhbW9uZyB0aGUgYXR0ZW5kZWVzLiZuYnNwOyZuYnNwOyBIb3BlZnVsbHkg
dGhpcyB0aHJlYWQgY2FuIGNvbmZpcm0sIG9yIHJlZmluZSBhcyBuZWVkLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Rmlyc3QgbGV04oCZcyBsb29rIGF0IFJvYmVydOKAmXMg
cHJvcG9zYWwgYmVsb3c6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPlRoZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxl
bWVudHMgaW4gUm9iZXJ04oCZcyBwcm9wb3NhbCBiZWxvdywgYnV0IGl0IGlzbuKAmXQgdXAgdG8g
b3VyIFdHIHRvIGRldGVybWluZSB0aGUgcHJvcGVyIHN0cnVjdHVyZSBvZiB0aGUgbmV0d29yay1p
bnN0YW5jZS1tb2RlbC4mbmJzcDsmbmJzcDsgQXV0aG9ycyBvZiB0aGF0IG1vZGVsIHdlcmUgaW4g
dGhlIHJvb20sIGFuZCBhcmUgYXdhcmUgdGhhdA0KIFlBTkcgbW9kZWwgZGV2ZWxvcGVycyBmcm9t
IG91dHNpZGUgd291bGQgd2VsY29tZSBhIHBhcnRpdGlvbmluZyB3aGljaCBkZWNvdXBsZXMgYW55
IGxpbmthZ2VzIHRvIHNjaGVtYS1tb3VudCB3aGVuIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyB0byBp
ZGVudGlmeSBhIFZSRiBieSBuYW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVC
NiI+TG9va2luZyBhdCB3aGF0IHdlIGNhbiBjb250cm9sLCBkaXNjdXNzZWQgaW4gdGhlIHJvb20g
d2FzIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHN1YnNjcmliZWQtbm90aWZpY2F0aW9uczogJm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0
eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFz
dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9
ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl
PSJjb2xvcjojMkU3NUI2Ij5pbXBvcnQg4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdJm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl
PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBw
b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZv
bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJj
b2xvcjojMkU3NUI2Ij5jcmVhdGUgaWYtZmVhdHVyZSDigJxWUkbigJ0uICZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p
bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3Rz
XT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0
ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzJF
NzVCNiI+YXBwbHkgZmVhdHVyZSDigJxWUkbigJ0gdG8gb2JqZWN0IOKAnHNvdXJjZS1WUkbigJ08
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9
InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv
cnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9u
dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv
bG9yOiMyRTc1QjYiPkxlYWZyZWYgdG8g4oCcc291cmNlLVZSRuKAnSB0byB2YWxpZGF0ZSBhZ2Fp
bnN0IHRoZSBuZXR3b3JrLWluc3RhbmNlIG1vZGVs4oCZcyAvbmV0d29yay1pbnN0YW5jZXMvbmV0
d29yay1pbnN0YW5jZS9uYW1lLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48c3BhbiBzdHlsZT0iY29s
b3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPlRoaXMgaXMgdGhlIGN1cnJlbnQgcHJv
cG9zYWwuJm5ic3A7IEFyZSB0aGVyZSBhcmUgY29uY2VybnMvb2JqZWN0aW9ucy9yZWZpbmVtZW50
cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJy
Pg0KTm8gY29uY2VybnMsIGJ1dCBwZXJoYXBzIG9uZSB0cml2aWFsIHJlZmluZW1lbnQuPGJyPg0K
PGJyPg0KSSBoYWQgbWlzdGFrZW5seSB0aG91Z2h0IHRoYXQgYSBkZXZpY2Ugd291bGQgZWl0aGVy
IHN1cHBvcnQgVlJGcyBmb3IgYWxsIHByb3RvY29scyBvciBub25lLCBoZW5jZSBteSBzdWdnZXN0
aW9uIHRvIGhhdmUgYSBzaW5nbGUgJnF1b3Q7VlJGJnF1b3Q7IGZlYXR1cmUsIHdoaWNoIHdvdWxk
IG5hdHVyYWxseSBiZSBkZWZpbmVkIGJ5IHRoZSBuZXR3b3JrLWluc3RhbmNlcyBtb2RlbC48YnI+
DQo8YnI+DQpJbiB0aGUgZGlzY3Vzc2lvbnMgdGhhdCBJIGhhZCB3aXRoIExvdSwgc29tZSBvZiB0
aGVtIGF0IHRoZSBtaWMsIHNvbWUgYWZ0ZXJ3YXJkcywgTG91IGNsYXJpZmllZCB0aGF0IGl0IHF1
aXRlIHBsYXVzaWJsZSB0aGF0IFZSRnMgbWF5IG9ubHkgYmUgc3VwcG9ydGVkIGJ5IHNvbWUgcHJv
dG9jb2xzIG9uIGEgZGV2aWNlIGFuZCBub3QgYWxsLCBhbmQgaGVuY2UgdGhlIHNvbHV0aW9uIG9m
IGhhdmluZyBhICZxdW90O1ZSRiZxdW90OyBmZWF0dXJlIHBlciBwcm90b2NvbA0KIHNlZW1zIGxp
a2UgdGhlIHJpZ2h0IHNvbHV0aW9uLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBJIHdvdWxkIGNh
bGwgdGhlIGZlYXR1cmUgJnF1b3Q7c3VwcG9ydHMtdnJmJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90
O3ZyZiZxdW90Oy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KUm9iPGJyPg0KPGJyPg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPkVyaWM8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi
bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl
eHQiPiBOZXRjb25mIFs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5t
YWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+
RXJpYyBWb2l0IChldm9pdCk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTQs
IDIwMTcgMTA6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24g
LSBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykgPGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28u
Y29tIj4NCiZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs8L2E+OyA8YSBocmVmPSJtYWlsdG86bmV0
Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT47IExvdSBCZXJnZXINCjxhIGhyZWY9
Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij4mbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2E+PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXBy
ZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj88L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzVC
OUJENSI+QWdyZWUgaXQgaXMgYSBnZW5lcmljIHByb2JsZW0uIDwvc3Bhbj4NCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlCRDUiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojNUI5QkQ1Ij5JIHdvdWxkIGRlZmVyIHRvIExvdSBhbmQgdGhlIG90aGVyIGF1
dGhvcnMgb2YgZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbCBhcyB0aGlzIHdvdWxkIGJlIGEgZmFp
cmx5IHNpZ25pZmljYW50IGNoYW5nZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzVCOUJENSI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlC
RDUiPkVyaWMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3Bh
biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdpbHRvbiwgTm92ZW1iZXIgMTQsIDIwMTcgNzo1OCBQ
TTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD5IaSBFcmljLCBMb3Us
PG86cD48L286cD48L3A+DQo8cD5UaGlzIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBwcm9ibGVtLjxv
OnA+PC9vOnA+PC9wPg0KPHA+Q291bGQgdGhlIFZSRiBsZWFmcmVmIG5hbWUgZGVwZW5kZW5jeSBp
c3N1ZSBiZSBzb2x2ZWQgd2l0aCBhbiBpZi1mZWF0dXJlIHN0YXRlbWVudD8uPG86cD48L286cD48
L3A+DQo8cD5JLmUuY291bGQgdGhlIG5ldHdvcmsgaW5zdGFuY2UgZHJhZnQgZGVmaW5lIGEgc2Vw
YXJhdGUgWUFORyBtb2R1bGUgKHdpdGggbm8gZGVwZW5kZW5jaWVzKSB0aGF0IGRlZmluZXMgYSAm
cXVvdDtWUkYmcXVvdDsgZmVhdHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwPkFsbCB0aGUgVlJGIHJl
ZmVyZW5jZXMgKGlkZWFsbHkgaWYgYWxsIElFVEYgWUFORyBtb2R1bGVzIHRoYXQgbWF5IG9wdGlv
bmFsbHkgZGVwZW5kIG9uIFZSRnMpIGNvdWxkIGJlIGxlYWYtcmVmcyB0byAvbmV0d29yay1pbnN0
YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lIGJ1dCBwcmVkaWNhdGVkIHdpdGggYW4gaWYtZmVh
dHVyZSAmcXVvdDtuaTp2cmYmcXVvdDsuPG86cD48L286cD48L3A+DQo8cD5IZW5jZSBpZiBhIGRl
dmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBpdCBkb2Vzbid0IGltcGxlbWVudCB0aGUg
JnF1b3Q7dnJmJnF1b3Q7IGZlYXR1cmUsIHNvIGl0IGRvZXNuJ3QgaGF2ZSB0byBpbXBsZW1lbnQg
dGhlIGZ1bGwgbmV0d29yayBpbnN0YW5jZXMgbW9kdWxlLCBvciBzY2hlbWEgbW91bnQuPG86cD48
L286cD48L3A+DQo8cD5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAxNS8xMS8yMDE3IDA4OjQ1LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiB0aGUgV0cgc2Vz
c2lvbiB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8gZ2V0IOKAnGh1bSBmZWVkYmFja+KAnSBvbjo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmli
ZWQtbm90aWZpY2F0aW9ucyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVz
LzUiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVzLzU8L2E+
DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIHR3byBjaG9pY2VzIGV4cG9zZWQg
ZHVyaW5nIHRoZSB0d28gd2VlayByZXZpZXcgZm9yIGhvdyB0byByZXByZXNlbnQgU291cmNlIFZS
RiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiB3ZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4oMSkgTGVhZnJlZiB0byDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0mbmJzcDsg
L25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZTxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRl
bnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNd
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ
Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv
c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5DcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1h
IG1vdW50IGZvciBzdWJzY3JpcHRpb25zLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv
LWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh
biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPlNvdXJjZSBWUkYgaXMgYW4gb3B0aW9uYWwgY2FwYWJpbGl0eSwgYnV0
IHB1Ymxpc2hlcnMgdGhhdCBkb27igJl0IGNhcmUgYWJvdXQgVlJGcyBtdXN0IHN0aWxsIGltcG9y
dC4mbmJzcDsgKE5vdGU6IGNvdWxkIGFsc28gYXVnbWVudCB0aGUgbGVhZnJlZiBpbiBhbm90aGVy
IG1vZGVsLCBidXQgdGhhdCBhZGRzIGFub3RoZXIgbGF5ZXIgb2YgY29tcGxleGl0eSk8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3Vw
cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i
bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ZXN0YWJsaXNoZXMgbW9kZWwg
ZGVwZW5kZW5jeSB0byBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPigyKSBVc2UgYSBzdHJpbmcgd2hpY2ggd291bGQgYmUgcG9wdWxhdGVkIHdp
dGggZXhhY3Qgc2FtZSBuYW1lIGFzIHdvdWxkIGJlIGluIHRoZSBsZWFmcmVmIG9mICgxKTxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm82Ij4NCjwhW2lmICFz
dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxl
PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Qb3NzaWJsZSB0byBuYW1l
IFZSRiB3aGljaCBkb2VzbuKAmXQgZXhpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
VGhlIGN1cnJlbnQgZHJhZnQgZG9lcyAoMikuJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij5FcmljIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv
bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5ldGNv
bmYgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOk5l
dGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxw
cmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48
L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiAs
c2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96Csjceml521mbxchi_--


From nobody Mon Nov 20 11:54:36 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48A12EA94 for ; Mon, 20 Nov 2017 11:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 a2hIq8gNfTDj for ; Mon, 20 Nov 2017 11:54:29 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEE012EAA4 for ; Mon, 20 Nov 2017 11:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46610; q=dns/txt; s=iport; t=1511207669; x=1512417269; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=G39mIG4MqY16pj3TpLwIPrm8XDk7PPBIr1l5SBTMM6o=; b=eDiDRup5qnNgJF/p96yTz1hXba9fZarUantMbnJ4DIIbYwrUpAhf6TAJ 6SKEo5/4FibUkWQL5lgpEaujNCa7pfpJFL6aHqoLfssORpX/hD+hTtZ06 foA7NUP84IbHzifg/dyhEFB8M1KAsBj7RSILmJ5W2V7SdG1HuHuKucbJU M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAADaMRNa/5JdJa1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkQuZm4nB4N4ih+PKIF9lmKCDgMKGAEKhANGTwIahGM/GAE?= =?us-ascii?q?BAQEBAQEBAWsohR4BAQEBAwEBIQpBGwIBCBEEAQEOEwEGAwICAiULFAkIAgQBE?= =?us-ascii?q?ggTiSZkEKhOgicmilABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYUUhHA?= =?us-ascii?q?ENQkfgl+CYwWRdIcuiRwCh3CNEZNVjHKJEwIRGQGBOQEfOYF0ehVJgmSDEYFOd?= =?us-ascii?q?4kFAiUHgQWBFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,429,1505779200";  d="scan'208,217";a="325971193"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 19:54:27 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAKJsR5f025553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 19:54:27 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 14:54:26 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 14:54:26 -0500
From: "Eric Voit (evoit)" 
To: Alexander Clemm , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netconf@ietf.org" , Lou Berger 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAJhO04AACinC0P//tAyAgABTJJA=
Date: Mon, 20 Nov 2017 19:54:26 +0000
Message-ID: 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_ce3ffea2d63345968e90a024815619b4XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:54:35 -0000

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

RnJvbTogQWxleGFuZGVyIENsZW1tLCBOb3ZlbWJlciAyMCwgMjAxNyAyOjQ2IFBNDQoNCg0KSGkg
RXJpYywNCg0KSSBhZ3JlZSB0aGF0IHByb2xpZmVyYXRpb24gb2YgbW9kdWxlcyBpcyBhIGNvbmNl
cm4sIGFuZCBjZXJ0YWlubHkgd2Ugd291bGQgbm90IHdhbnQgdG8gcnVuIGludG8gY29tYmluYXRv
cmlhbCBleHBsb3Npb25zLiAgSG93ZXZlciwgSSBkb27igJl0IHRoaW5rIHRoaXMgd291bGQgYmUg
dGhlIGNhc2UgaGVyZSAtIHdlIHdvdWxkIG5vdCBuZWVkIHRvIGF1Z21lbnQgVlJGIGludG8geWFu
Zy1wdXNoIGFsc28gKG9yIHlhbmctcHVzaCBpbnRvIFZSRikuICBJbnN0ZWFkLCBib3RoIHlhbmct
cHVzaCBhbmQgdnJmLWZvci1ub3RpZmljYXRpb25zIHdvdWxkIGJlIGF1Z21lbnRpbmcgc3Vic2Ny
aWJlZC1ub3RpZmljYXRpb25zIGluIHBhcmFsbGVsLg0KDQo8RXJpYz4gIFllcywgeW91IGFyZSBy
aWdodCwgd2l0aCB0aGlzIGFwcHJvYWNoIHdlIHdvdWxkIGVuZCB3aXRoIHRocmVlIG1vZGVscyBy
YXRoZXIgdGhhbiBmb3VyLiAgQnV0IHR3byBtb2RlbHMgaXMgYWxyZWFkeSBhIGxvdC4gICBBbmQg
d2Ugc3RpbGwgc2V0IHByZWNlZGVuY2UgdGhhdCB3ZSBlbmQgd2l0aCBhIG5ldyBWUkYgc3BlY2lm
aWMgbW9kZWwgZXZlcnkgdGltZSBhbnkgWUFORyBtb2RlbCBuZWVkcyBhIFZSRi4NCkVyaWMNCg0K
LS0tIEFsZXgNCg0KRnJvbTogRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5j
b21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDExOjM5IEFNDQpUbzogQWxleGFu
ZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNs
ZW1tQGh1YXdlaS5jb20+PjsgUm9iZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1J
VEVEIGF0IENpc2NvKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29t
Pj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3UgQmVyZ2Vy
IDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NClN1YmplY3Q6IFJF
OiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBj
b25maWd1cmVkIHN1YnNjcmlwdGlvbj8NCg0KSSBhZ3JlZSB0aGlzIGlzIG1vcmUgZWxlZ2FudCBp
ZiB3ZSBsb29rIGp1c3QgYXQgc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLiAgIEhvd2V2ZXIgZXh0
cmFwb2xhdGluZyB0aGlzIG1lYW5zIHRoYXQgd2UgaGF2ZSBhIGR1cGxpY2F0ZSBZQU5HIG1vZHVs
ZSBldmVyeSB0aW1lIHdlIGhhdmUgYSBWUkYuICAgQW5kIGluIG91ciBjYXNlIHdoZW4gd2UgYXVn
bWVudCB5YW5nLXB1c2gsIHdoaWNoIG1vZGVsIGRvIHdlIHN0YXJ0IGZyb20/DQoNCkVyaWMNCg0K
RnJvbTogQWxleGFuZGVyIENsZW1tIFttYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb21d
DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDI6MjcgUE0NClRvOiBSb2JlcnQgV2ls
dG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9uQGNpc2Nv
LmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0
QGNpc2NvLmNvbTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFp
bHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0
bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NClN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6
IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8N
Cg0KSSBhbSBmaW5lIHdpdGggdGhhdCBjaGFuZ2UsIGJ1dCB3YW50ZWQgdG8gYnJpbmcgdXAgb25l
IGFkZGl0aW9uYWwgb3B0aW9uIHRoYXQgd2FzIGFsc28gYnJpZWZseSBtZW50aW9uZWQgaW4gdGhl
IHJvb20gd2hpY2ggc3RyaWtlcyBtZSBhcyBwZXJoYXBzIGEgYml0IG1vcmUgZWxlZ2FudC4gIFRo
YXQgaXMgdGhlIG9wdGlvbiB0byB1c2UgYXVnbWVudGF0aW9uLiAgSW4gdGhhdCBjYXNlLCBzb3Vy
Y2UtdnJmIGFuZCB0aGUgaW1wb3J0IHN0YXRlbWVudCB3b3VsZCBzaW1wbHkgYmUgb21pdHRlZC4g
SW5zdGVhZCwgYSBuZXcgbW9kdWxlIHdvdWxkIGJlIGNyZWF0ZWQgKGUuZy4gaWV0Zi12cmYtZm9y
LXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyksIHdoaWNoIGNvbnRhaW5zIHRoZSBpbXBvcnQgc3Rh
dGVtZW50IGFuZCB0d28gYXVnbWVudHMgc3RhdGVtZW50cyB0byBhdWdtZW50IHRoZSBzb3VyY2Ut
dnJmIGludG8gdGhlIGV4aXN0aW5nIG1vZHVsZS4NCg0KLS0tIEFsZXgNCg0KRnJvbTogTmV0Y29u
ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBX
aWx0b24NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTcsIDIwMTcgMTA6NDYgQU0NClRvOiBFcmlj
IFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+Pjsg
bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJnZXIgPGxi
ZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KU3ViamVjdDogUmU6IFtO
ZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZp
Z3VyZWQgc3Vic2NyaXB0aW9uPw0KDQoNCk9uIDE3LzExLzIwMTcgMTg6MTcsIEVyaWMgVm9pdCAo
ZXZvaXQpIHdyb3RlOg0KSSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9u
IHRoaXMgdG9waWMgZnJvbSBvdXIgc2Vzc2lvbi4gICBJIHRoaW5rIHdlIGNhbWUgdG8gYWdyZWVt
ZW50IGFtb25nIHRoZSBhdHRlbmRlZXMuICAgSG9wZWZ1bGx5IHRoaXMgdGhyZWFkIGNhbiBjb25m
aXJtLCBvciByZWZpbmUgYXMgbmVlZC4NCg0KRmlyc3QgbGV04oCZcyBsb29rIGF0IFJvYmVydOKA
mXMgcHJvcG9zYWwgYmVsb3c6DQpUaGVyZSBhcmUgbG90cyBvZiBnb29kIGVsZW1lbnRzIGluIFJv
YmVydOKAmXMgcHJvcG9zYWwgYmVsb3csIGJ1dCBpdCBpc27igJl0IHVwIHRvIG91ciBXRyB0byBk
ZXRlcm1pbmUgdGhlIHByb3BlciBzdHJ1Y3R1cmUgb2YgdGhlIG5ldHdvcmstaW5zdGFuY2UtbW9k
ZWwuICAgQXV0aG9ycyBvZiB0aGF0IG1vZGVsIHdlcmUgaW4gdGhlIHJvb20sIGFuZCBhcmUgYXdh
cmUgdGhhdCBZQU5HIG1vZGVsIGRldmVsb3BlcnMgZnJvbSBvdXRzaWRlIHdvdWxkIHdlbGNvbWUg
YSBwYXJ0aXRpb25pbmcgd2hpY2ggZGVjb3VwbGVzIGFueSBsaW5rYWdlcyB0byBzY2hlbWEtbW91
bnQgd2hlbiBhbGwgdGhhdCBpcyBuZWVkZWQgaXMgdG8gaWRlbnRpZnkgYSBWUkYgYnkgbmFtZS4N
Cg0KTG9va2luZyBhdCB3aGF0IHdlIGNhbiBjb250cm9sLCBkaXNjdXNzZWQgaW4gdGhlIHJvb20g
d2FzIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHN1YnNjcmliZWQtbm90aWZpY2F0aW9uczoNCg0K
MS4gICAgICBpbXBvcnQg4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdDQoNCjIuICAgICAgY3Jl
YXRlIGlmLWZlYXR1cmUg4oCcVlJG4oCdLg0KDQozLiAgICAgIGFwcGx5IGZlYXR1cmUg4oCcVlJG
4oCdIHRvIG9iamVjdCDigJxzb3VyY2UtVlJG4oCdDQoNCjQuICAgICAgTGVhZnJlZiB0byDigJxz
b3VyY2UtVlJG4oCdIHRvIHZhbGlkYXRlIGFnYWluc3QgdGhlIG5ldHdvcmstaW5zdGFuY2UgbW9k
ZWzigJlzIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUuDQoNClRoaXMg
aXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwuICBBcmUgdGhlcmUgYXJlIGNvbmNlcm5zL29iamVjdGlv
bnMvcmVmaW5lbWVudHM/DQoNCk5vIGNvbmNlcm5zLCBidXQgcGVyaGFwcyBvbmUgdHJpdmlhbCBy
ZWZpbmVtZW50Lg0KDQpJIGhhZCBtaXN0YWtlbmx5IHRob3VnaHQgdGhhdCBhIGRldmljZSB3b3Vs
ZCBlaXRoZXIgc3VwcG9ydCBWUkZzIGZvciBhbGwgcHJvdG9jb2xzIG9yIG5vbmUsIGhlbmNlIG15
IHN1Z2dlc3Rpb24gdG8gaGF2ZSBhIHNpbmdsZSAiVlJGIiBmZWF0dXJlLCB3aGljaCB3b3VsZCBu
YXR1cmFsbHkgYmUgZGVmaW5lZCBieSB0aGUgbmV0d29yay1pbnN0YW5jZXMgbW9kZWwuDQoNCklu
IHRoZSBkaXNjdXNzaW9ucyB0aGF0IEkgaGFkIHdpdGggTG91LCBzb21lIG9mIHRoZW0gYXQgdGhl
IG1pYywgc29tZSBhZnRlcndhcmRzLCBMb3UgY2xhcmlmaWVkIHRoYXQgaXQgcXVpdGUgcGxhdXNp
YmxlIHRoYXQgVlJGcyBtYXkgb25seSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24g
YSBkZXZpY2UgYW5kIG5vdCBhbGwsIGFuZCBoZW5jZSB0aGUgc29sdXRpb24gb2YgaGF2aW5nIGEg
IlZSRiIgZmVhdHVyZSBwZXIgcHJvdG9jb2wgc2VlbXMgbGlrZSB0aGUgcmlnaHQgc29sdXRpb24u
DQoNCkkgdGhpbmsgdGhhdCBJIHdvdWxkIGNhbGwgdGhlIGZlYXR1cmUgInN1cHBvcnRzLXZyZiIg
cmF0aGVyIHRoYW4gInZyZiIuDQoNClRoYW5rcywNClJvYg0KDQpFcmljDQoNCg0KDQpGcm9tOiBO
ZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJp
YyBWb2l0IChldm9pdCkNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDEwOjIzIFBN
DQpUbzogUm9iZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2Nv
KSA8cndpbHRvbkBjaXNjby5jb20+PG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT47IG5ldGNvbmZA
aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh
Ym4ubmV0PjxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0g
SXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1
YnNjcmlwdGlvbj8NCg0KQWdyZWUgaXQgaXMgYSBnZW5lcmljIHByb2JsZW0uDQoNCkkgd291bGQg
ZGVmZXIgdG8gTG91IGFuZCB0aGUgb3RoZXIgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLW5p
LW1vZGVsIGFzIHRoaXMgd291bGQgYmUgYSBmYWlybHkgc2lnbmlmaWNhbnQgY2hhbmdlLg0KDQpF
cmljDQoNCkZyb206IFJvYmVydCBXaWx0b24sIE5vdmVtYmVyIDE0LCAyMDE3IDc6NTggUE0NCg0K
SGkgRXJpYywgTG91LA0KDQpUaGlzIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBwcm9ibGVtLg0KDQpD
b3VsZCB0aGUgVlJGIGxlYWZyZWYgbmFtZSBkZXBlbmRlbmN5IGlzc3VlIGJlIHNvbHZlZCB3aXRo
IGFuIGlmLWZlYXR1cmUgc3RhdGVtZW50Py4NCg0KSS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3Rh
bmNlIGRyYWZ0IGRlZmluZSBhIHNlcGFyYXRlIFlBTkcgbW9kdWxlICh3aXRoIG5vIGRlcGVuZGVu
Y2llcykgdGhhdCBkZWZpbmVzIGEgIlZSRiIgZmVhdHVyZS4NCg0KQWxsIHRoZSBWUkYgcmVmZXJl
bmNlcyAoaWRlYWxseSBpZiBhbGwgSUVURiBZQU5HIG1vZHVsZXMgdGhhdCBtYXkgb3B0aW9uYWxs
eSBkZXBlbmQgb24gVlJGcykgY291bGQgYmUgbGVhZi1yZWZzIHRvIC9uZXR3b3JrLWluc3RhbmNl
cy9uZXR3b3JrLWluc3RhbmNlL25hbWUgYnV0IHByZWRpY2F0ZWQgd2l0aCBhbiBpZi1mZWF0dXJl
ICJuaTp2cmYiLg0KDQpIZW5jZSBpZiBhIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhl
biBpdCBkb2Vzbid0IGltcGxlbWVudCB0aGUgInZyZiIgZmVhdHVyZSwgc28gaXQgZG9lc24ndCBo
YXZlIHRvIGltcGxlbWVudCB0aGUgZnVsbCBuZXR3b3JrIGluc3RhbmNlcyBtb2R1bGUsIG9yIHNj
aGVtYSBtb3VudC4NCg0KVGhhbmtzLA0KUm9iDQoNCk9uIDE1LzExLzIwMTcgMDg6NDUsIEVyaWMg
Vm9pdCAoZXZvaXQpIHdyb3RlOg0KDQpJbiB0aGUgV0cgc2Vzc2lvbiB0b21vcnJvdywgSSBhbSBo
b3BpbmcgdG8gZ2V0IOKAnGh1bSBmZWVkYmFja+KAnSBvbjoNCg0KDQoNCmRyYWZ0LWlldGYtbmV0
Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNv
bmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNQ0KDQoNCg0KVGhlIHR3byBjaG9pY2VzIGV4cG9zZWQg
ZHVyaW5nIHRoZSB0d28gd2VlayByZXZpZXcgZm9yIGhvdyB0byByZXByZXNlbnQgU291cmNlIFZS
RiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiB3ZXJlOg0KDQoNCg0KKDEpIExlYWZyZWYgdG8g
4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdICAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1p
bnN0YW5jZS9uYW1lDQoNCsK3ICAgICAgICBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1v
dW50IGZvciBzdWJzY3JpcHRpb25zLg0KDQrCtyAgICAgICAgU291cmNlIFZSRiBpcyBhbiBvcHRp
b25hbCBjYXBhYmlsaXR5LCBidXQgcHVibGlzaGVycyB0aGF0IGRvbuKAmXQgY2FyZSBhYm91dCBW
UkZzIG11c3Qgc3RpbGwgaW1wb3J0LiAgKE5vdGU6IGNvdWxkIGFsc28gYXVnbWVudCB0aGUgbGVh
ZnJlZiBpbiBhbm90aGVyIG1vZGVsLCBidXQgdGhhdCBhZGRzIGFub3RoZXIgbGF5ZXIgb2YgY29t
cGxleGl0eSkNCg0KwrcgICAgICAgIGVzdGFibGlzaGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8gZHJh
ZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbA0KDQoNCg0KKDIpIFVzZSBhIHN0cmluZyB3aGljaCB3b3Vs
ZCBiZSBwb3B1bGF0ZWQgd2l0aCBleGFjdCBzYW1lIG5hbWUgYXMgd291bGQgYmUgaW4gdGhlIGxl
YWZyZWYgb2YgKDEpDQoNCsK3ICAgICAgICBQb3NzaWJsZSB0byBuYW1lIFZSRiB3aGljaCBkb2Vz
buKAmXQgZXhpc3QNCg0KDQoNClRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KDQoNCg0KVGhh
bmtzLA0KDQpFcmljDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCk5ldGNvbmYgbWFpbGluZyBsaXN0DQoNCk5ldGNvbmZAaWV0Zi5vcmc8
bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0Y29uZg0KDQouDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg
MCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs
LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz
ZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t
OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNv
bG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNw
YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5
N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt
YWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu
IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjY2
Mzk4NTI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot
MTgyMDgwMDEyMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3MDMz
MzQwMzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02
MDM0MDgwODIgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2
OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMwMjU0MzgxMjsNCgltc28tbGlzdC10eXBl
Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4Mzc3NDY0MzYgNjc2OTg2ODkgNjc2
OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9
DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg
bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIj
MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEFsZXhhbmRlciBDbGVt
bSwgTm92ZW1iZXIgMjAsIDIwMTcgMjo0NiBQTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEVyaWMsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgcHJvbGlmZXJhdGlv
biBvZiBtb2R1bGVzIGlzIGEgY29uY2VybiwgYW5kIGNlcnRhaW5seSB3ZSB3b3VsZCBub3Qgd2Fu
dCB0byBydW4gaW50byBjb21iaW5hdG9yaWFsIGV4cGxvc2lvbnMuJm5ic3A7IEhvd2V2ZXIsIEkg
ZG9u4oCZdCB0aGluayB0aGlzIHdvdWxkIGJlIHRoZSBjYXNlIGhlcmUgLSB3ZSB3b3VsZCBub3Qg
bmVlZCB0byBhdWdtZW50IFZSRg0KIGludG8geWFuZy1wdXNoIGFsc28gKG9yIHlhbmctcHVzaCBp
bnRvIFZSRikuJm5ic3A7IEluc3RlYWQsIGJvdGggeWFuZy1wdXNoIGFuZCB2cmYtZm9yLW5vdGlm
aWNhdGlvbnMgd291bGQgYmUgYXVnbWVudGluZyBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgaW4g
cGFyYWxsZWwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjY7
bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJFNzVCNjttc28tc3R5bGUtdGV4dGZpbGwt
ZmlsbC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7RXJp
YyZndDsmbmJzcDsgWWVzLCB5b3UgYXJlIHJpZ2h0LCB3aXRoIHRoaXMgYXBwcm9hY2ggd2Ugd291
bGQgZW5kIHdpdGggdGhyZWUgbW9kZWxzIHJhdGhlciB0aGFuIGZvdXIuJm5ic3A7IEJ1dCB0d28N
CiBtb2RlbHMgaXMgYWxyZWFkeSBhIGxvdC4mbmJzcDsgJm5ic3A7QW5kIHdlIHN0aWxsIHNldCBw
cmVjZWRlbmNlIHRoYXQgd2UgZW5kIHdpdGggYSBuZXcgVlJGIHNwZWNpZmljIG1vZGVsIGV2ZXJ5
IHRpbWUgYW55IFlBTkcgbW9kZWwgbmVlZHMgYSBWUkYuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMy
RTc1QjY7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzJFNzVCNjttc28tc3R5bGUtdGV4
dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5F
cmljPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gRXJpYyBWb2l0IChldm9pdCkgWzxh
IGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPm1haWx0bzpldm9pdEBjaXNjby5jb208L2E+
XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMjAsIDIwMTcgMTE6MzkgQU08
YnI+DQo8Yj5Ubzo8L2I+IEFsZXhhbmRlciBDbGVtbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhh
bmRlci5jbGVtbUBodWF3ZWkuY29tIj5hbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTwvYT4mZ3Q7
OyBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pICZs
dDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9h
PiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y
ZzwvYT47IExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5s
YmVyZ2VyQGxhYm4ubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtOZXRjb25m
XSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQg
c3Vic2NyaXB0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoaXMgaXMgbW9yZSBlbGVn
YW50IGlmIHdlIGxvb2sganVzdCBhdCBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuJm5ic3A7Jm5i
c3A7IEhvd2V2ZXIgZXh0cmFwb2xhdGluZyB0aGlzIG1lYW5zIHRoYXQgd2UgaGF2ZSBhIGR1cGxp
Y2F0ZSBZQU5HIG1vZHVsZSBldmVyeSB0aW1lIHdlIGhhdmUgYSBWUkYuJm5ic3A7Jm5ic3A7IEFu
ZCBpbiBvdXIgY2FzZSB3aGVuIHdlIGF1Z21lbnQgeWFuZy1wdXNoLA0KIHdoaWNoIG1vZGVsIGRv
IHdlIHN0YXJ0IGZyb20/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Fcmlj
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEFsZXhhbmRlciBDbGVtbSBbPGEg
aHJlZj0ibWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tIj5tYWlsdG86YWxleGFuZGVy
LmNsZW1tQGh1YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1i
ZXIgMjAsIDIwMTcgMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFdpbHRvbiAtWCAocndp
bHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0
b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7OyBFcmljIFZvaXQgKGV2b2l0
KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9h
PiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y
ZzwvYT47IExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5s
YmVyZ2VyQGxhYm4ubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtOZXRjb25m
XSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQg
c3Vic2NyaXB0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFtIGZpbmUgd2l0aCB0aGF0IGNoYW5n
ZSwgYnV0IHdhbnRlZCB0byBicmluZyB1cCBvbmUgYWRkaXRpb25hbCBvcHRpb24gdGhhdCB3YXMg
YWxzbyBicmllZmx5IG1lbnRpb25lZCBpbiB0aGUgcm9vbSB3aGljaCBzdHJpa2VzIG1lIGFzIHBl
cmhhcHMgYSBiaXQgbW9yZSBlbGVnYW50LiZuYnNwOyBUaGF0IGlzIHRoZSBvcHRpb24gdG8gdXNl
IGF1Z21lbnRhdGlvbi4mbmJzcDsgSW4NCiB0aGF0IGNhc2UsIHNvdXJjZS12cmYgYW5kIHRoZSBp
bXBvcnQgc3RhdGVtZW50IHdvdWxkIHNpbXBseSBiZSBvbWl0dGVkLiBJbnN0ZWFkLCBhIG5ldyBt
b2R1bGUgd291bGQgYmUgY3JlYXRlZCAoZS5nLiBpZXRmLXZyZi1mb3Itc3Vic2NyaWJlZC1ub3Rp
ZmljYXRpb25zKSwgd2hpY2ggY29udGFpbnMgdGhlIGltcG9ydCBzdGF0ZW1lbnQgYW5kIHR3byBh
dWdtZW50cyBzdGF0ZW1lbnRzIHRvIGF1Z21lbnQgdGhlIHNvdXJjZS12cmYgaW50byB0aGUNCiBl
eGlzdGluZyBtb2R1bGUuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk
aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gTmV0Y29uZiBb
PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldGNvbmYt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBXaWx0b248
YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciAxNywgMjAxNyAxMDo0NiBBTTxicj4N
CjxiPlRvOjwvYj4gRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBj
aXNjby5jb20iPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNv
bmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+OyBMb3UgQmVyZ2VyICZsdDs8YSBocmVm
PSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNl
bnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj88bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIDE3LzExLzIwMTcgMTg6MTcsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMkU3NUI2Ij5JIHdvdWxkIGxpa2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gb24g
dGhpcyB0b3BpYyBmcm9tIG91ciBzZXNzaW9uLiZuYnNwOyZuYnNwOyBJIHRoaW5rIHdlIGNhbWUg
dG8gYWdyZWVtZW50IGFtb25nIHRoZSBhdHRlbmRlZXMuJm5ic3A7Jm5ic3A7IEhvcGVmdWxseSB0
aGlzIHRocmVhZCBjYW4gY29uZmlybSwgb3IgcmVmaW5lIGFzIG5lZWQuPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5GaXJzdCBsZXTigJlzIGxvb2sgYXQgUm9iZXJ04oCZcyBw
cm9wb3NhbCBiZWxvdzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+VGhlcmUgYXJlIGxvdHMgb2YgZ29vZCBlbGVt
ZW50cyBpbiBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93LCBidXQgaXQgaXNu4oCZdCB1cCB0byBv
dXIgV0cgdG8gZGV0ZXJtaW5lIHRoZSBwcm9wZXIgc3RydWN0dXJlIG9mIHRoZSBuZXR3b3JrLWlu
c3RhbmNlLW1vZGVsLiZuYnNwOyZuYnNwOyBBdXRob3JzIG9mIHRoYXQgbW9kZWwgd2VyZSBpbiB0
aGUgcm9vbSwgYW5kIGFyZSBhd2FyZSB0aGF0DQogWUFORyBtb2RlbCBkZXZlbG9wZXJzIGZyb20g
b3V0c2lkZSB3b3VsZCB3ZWxjb21lIGEgcGFydGl0aW9uaW5nIHdoaWNoIGRlY291cGxlcyBhbnkg
bGlua2FnZXMgdG8gc2NoZW1hLW1vdW50IHdoZW4gYWxsIHRoYXQgaXMgbmVlZGVkIGlzIHRvIGlk
ZW50aWZ5IGEgVlJGIGJ5IG5hbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2
Ij5Mb29raW5nIGF0IHdoYXQgd2UgY2FuIGNvbnRyb2wsIGRpc2N1c3NlZCBpbiB0aGUgcm9vbSB3
YXMgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOiAmbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5
bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1
cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0i
Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9y
OiMyRTc1QjYiPmltcG9ydCDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt
aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0
c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBw
dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRTc1QjYi
PmNyZWF0ZSBpZi1mZWF0dXJlIOKAnFZSRuKAnS4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47
bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl
PSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij5hcHBseSBmZWF0dXJl
IOKAnFZSRuKAnSB0byBvYmplY3Qg4oCcc291cmNlLVZSRuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu
O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls
ZT0ibXNvLWxpc3Q6SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+
PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+TGVhZnJlZiB0byDi
gJxzb3VyY2UtVlJG4oCdIHRvIHZhbGlkYXRlIGFnYWluc3QgdGhlIG5ldHdvcmstaW5zdGFuY2Ug
bW9kZWzigJlzIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUuJm5ic3A7
DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6LjI1aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzJFNzVCNiI+VGhpcyBpcyB0aGUgY3VycmVudCBwcm9wb3NhbC4mbmJzcDsgQXJlIHRoZXJlIGFy
ZSBjb25jZXJucy9vYmplY3Rpb25zL3JlZmluZW1lbnRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQpObyBjb25jZXJucywgYnV0IHBlcmhh
cHMgb25lIHRyaXZpYWwgcmVmaW5lbWVudC48YnI+DQo8YnI+DQpJIGhhZCBtaXN0YWtlbmx5IHRo
b3VnaHQgdGhhdCBhIGRldmljZSB3b3VsZCBlaXRoZXIgc3VwcG9ydCBWUkZzIGZvciBhbGwgcHJv
dG9jb2xzIG9yIG5vbmUsIGhlbmNlIG15IHN1Z2dlc3Rpb24gdG8gaGF2ZSBhIHNpbmdsZSAmcXVv
dDtWUkYmcXVvdDsgZmVhdHVyZSwgd2hpY2ggd291bGQgbmF0dXJhbGx5IGJlIGRlZmluZWQgYnkg
dGhlIG5ldHdvcmstaW5zdGFuY2VzIG1vZGVsLjxicj4NCjxicj4NCkluIHRoZSBkaXNjdXNzaW9u
cyB0aGF0IEkgaGFkIHdpdGggTG91LCBzb21lIG9mIHRoZW0gYXQgdGhlIG1pYywgc29tZSBhZnRl
cndhcmRzLCBMb3UgY2xhcmlmaWVkIHRoYXQgaXQgcXVpdGUgcGxhdXNpYmxlIHRoYXQgVlJGcyBt
YXkgb25seSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24gYSBkZXZpY2UgYW5kIG5v
dCBhbGwsIGFuZCBoZW5jZSB0aGUgc29sdXRpb24gb2YgaGF2aW5nIGEgJnF1b3Q7VlJGJnF1b3Q7
IGZlYXR1cmUgcGVyIHByb3RvY29sDQogc2VlbXMgbGlrZSB0aGUgcmlnaHQgc29sdXRpb24uPGJy
Pg0KPGJyPg0KSSB0aGluayB0aGF0IEkgd291bGQgY2FsbCB0aGUgZmVhdHVyZSAmcXVvdDtzdXBw
b3J0cy12cmYmcXVvdDsgcmF0aGVyIHRoYW4gJnF1b3Q7dnJmJnF1b3Q7Ljxicj4NCjxicj4NClRo
YW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+RXJp
Yzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMkU3NUI2Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJFNzVCNiI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFZvaXQgKGV2b2l0KTxicj4NCjxiPlNlbnQ6PC9iPiBU
dWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyAxMDoyMyBQTTxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0
IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSA8YSBocmVmPSJt
YWlsdG86cndpbHRvbkBjaXNjby5jb20iPg0KJmx0O3J3aWx0b25AY2lzY28uY29tJmd0OzwvYT47
IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPjsg
TG91IEJlcmdlcg0KPGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiPiZsdDtsYmVyZ2Vy
QGxhYm4ubmV0Jmd0OzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBJc3N1
ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2Ny
aXB0aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1Ij5BZ3JlZSBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbS4g
PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzVCOUJENSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1QjlCRDUiPkkgd291bGQgZGVmZXIgdG8g
TG91IGFuZCB0aGUgb3RoZXIgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsIGFz
IHRoaXMgd291bGQgYmUgYSBmYWlybHkgc2lnbmlmaWNhbnQgY2hhbmdlLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNUI5QkQ1
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzVCOUJENSI+RXJpYyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv
dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uLCBOb3Zl
bWJlciAxNCwgMjAxNyA3OjU4IFBNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwPkhpIEVyaWMsIExvdSw8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgc2VlbXMgdG8gYmUg
YSBnZW5lcmljIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cD5Db3VsZCB0aGUgVlJGIGxlYWZy
ZWYgbmFtZSBkZXBlbmRlbmN5IGlzc3VlIGJlIHNvbHZlZCB3aXRoIGFuIGlmLWZlYXR1cmUgc3Rh
dGVtZW50Py48bzpwPjwvbzpwPjwvcD4NCjxwPkkuZS5jb3VsZCB0aGUgbmV0d29yayBpbnN0YW5j
ZSBkcmFmdCBkZWZpbmUgYSBzZXBhcmF0ZSBZQU5HIG1vZHVsZSAod2l0aCBubyBkZXBlbmRlbmNp
ZXMpIHRoYXQgZGVmaW5lcyBhICZxdW90O1ZSRiZxdW90OyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9w
Pg0KPHA+QWxsIHRoZSBWUkYgcmVmZXJlbmNlcyAoaWRlYWxseSBpZiBhbGwgSUVURiBZQU5HIG1v
ZHVsZXMgdGhhdCBtYXkgb3B0aW9uYWxseSBkZXBlbmQgb24gVlJGcykgY291bGQgYmUgbGVhZi1y
ZWZzIHRvIC9uZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUgYnV0IHByZWRp
Y2F0ZWQgd2l0aCBhbiBpZi1mZWF0dXJlICZxdW90O25pOnZyZiZxdW90Oy48bzpwPjwvbzpwPjwv
cD4NCjxwPkhlbmNlIGlmIGEgZGV2aWNlIGRvZXNuJ3Qgc3VwcG9ydCBWUkZzLCB0aGVuIGl0IGRv
ZXNuJ3QgaW1wbGVtZW50IHRoZSAmcXVvdDt2cmYmcXVvdDsgZmVhdHVyZSwgc28gaXQgZG9lc24n
dCBoYXZlIHRvIGltcGxlbWVudCB0aGUgZnVsbCBuZXR3b3JrIGluc3RhbmNlcyBtb2R1bGUsIG9y
IHNjaGVtYSBtb3VudC48bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE1LzExLzIwMTcgMDg6NDUsIEVyaWMgVm9pdCAo
ZXZvaXQpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPkluIHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBnZXQg4oCc
aHVtIGZlZWRiYWNr4oCdIG9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5kcmFmdC1p
ZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYt
d2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNSI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmZj
NTI3N2Jpcy9pc3N1ZXMvNTwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUg
dHdvIGNob2ljZXMgZXhwb3NlZCBkdXJpbmcgdGhlIHR3byB3ZWVrIHJldmlldyBmb3IgaG93IHRv
IHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdlcmU6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPigxKSBMZWFmcmVmIHRvIOKAnGlldGYtbmV0d29y
ay1pbnN0YW5jZeKAnSZuYnNwOyAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9u
YW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0K
PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw
YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNyZWF0ZXMgZGVwZW5k
ZW5jeSBvbiBzY2hlbWEgbW91bnQgZm9yIHN1YnNjcmlwdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k
ZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz
XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6
SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+
PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U291cmNlIFZSRiBpcyBhbiBvcHRpb25hbCBjYXBhYmls
aXR5LCBidXQgcHVibGlzaGVycyB0aGF0IGRvbuKAmXQgY2FyZSBhYm91dCBWUkZzIG11c3Qgc3Rp
bGwgaW1wb3J0LiZuYnNwOyAoTm90ZTogY291bGQgYWxzbyBhdWdtZW50IHRoZSBsZWFmcmVmIGlu
IGFub3RoZXIgbW9kZWwsIGJ1dCB0aGF0IGFkZHMgYW5vdGhlciBsYXllciBvZiBjb21wbGV4aXR5
KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwh
W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFu
IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5lc3RhYmxpc2hlcyBtb2Rl
bCBkZXBlbmRlbmN5IHRvIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWw8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+KDIpIFVzZSBhIHN0cmluZyB3aGljaCB3b3VsZCBiZSBwb3B1bGF0ZWQg
d2l0aCBleGFjdCBzYW1lIG5hbWUgYXMgd291bGQgYmUgaW4gdGhlIGxlYWZyZWYgb2YgKDEpPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPg0KPCFbaWYg
IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5
bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlBvc3NpYmxlIHRvIG5hbWUgVlJG
IHdoaWNoIGRvZXNu4oCZdCBleGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUg
Y3VycmVudCBkcmFmdCBkb2VzICgyKS4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PkVyaWMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+TmV0Y29uZiBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86TmV0Y29u
ZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJp
ZiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Lg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_ce3ffea2d63345968e90a024815619b4XCHRTP013ciscocom_--


From nobody Mon Nov 20 17:14:31 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ADC1242F7 for ; Mon, 20 Nov 2017 17:14:30 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 WwCyWmHjfEmw for ; Mon, 20 Nov 2017 17:14:28 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 97AE11201FA for ; Mon, 20 Nov 2017 17:14:27 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id k66so12216541lfg.3 for ; Mon, 20 Nov 2017 17:14:27 -0800 (PST)
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=DEgf68CoIHuvmv8OK6N7d3/qUJYfMaVtb8qSjWsea5w=; b=TbtUK18nOz04pN0l+vcllyDhhcVr6nlhowOo/RSQJ82tgfrnfSoPXI8RtdTuFcoT13 /c/XsOMdOajrSH3sgKHboACrNbf06h8F7IYkzJ0MImnXpvPhxL9/Fjh2aCSkeEoBVPnT pBAdDhoFFFzrsa1ibiWDdSbAUKeObWauCEL7F5R/TfeqmSIn+n5763AibQ1dDJ/WjQsi NIvzf+IaW8mKPYLznpnE6WvquHXRN87x11xKUMs4+mkwDSlS+q5gC7gWB1pt+AtretBH hdP09q2lYbSgGz/HDHaQZYSfv728qdRL/vS+PWzNLECIr5nTpEitmrXv054/aWeyOwsI 0QwA==
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=DEgf68CoIHuvmv8OK6N7d3/qUJYfMaVtb8qSjWsea5w=; b=IquNuldDY6YblgYQh44Qm9zcGaaucQYiRDusHC4uV9/snlZ2w7zQogday+Ohoqo4PS lbmUr0d/iGo47VoBI4/1/sHqRS3Z2wpQpteHEBuT1RmhfSfLoOTNsFd0vcXyvTTjnbPT ggj7a6Dq/CrfQvGL2vq0ptOkLzzOJO4EQbB7lb4cLV5Sk+ZRd0xjlxOHOsoGpe566vrr rtofRD/OjQi/MpcD/cmx2rUIkBBvqje2Tg+NBF3boPI4vK21xGNTgn30FpKo0ENtIuKM oJNPLvRFSSSQCvEJH6rVgH4onlNW/+hBRkcb1SlKNyMYtnV/nM3sVwRYZNznA/BAXZDP 5uug==
X-Gm-Message-State: AJaThX4Xf8oYMhSvJbyRYeAw5w+zHvLI97PZyq+Ag9M03bS0Gri6omfS h0XQZr14ZVtZyhhcb26I4RYKtcAJ5ILvPzIC36NbUQ==
X-Google-Smtp-Source: AGs4zMbw8lDUqZ38s2JZu86eV4nBCOGAK4eRrBdLkFKcgxMKHOnUq7CmYWUewxGceM4zNU0qCXjv+rtelUpvRfSsF/w=
X-Received: by 10.25.160.13 with SMTP id j13mr3488706lfe.218.1511226865828; Mon, 20 Nov 2017 17:14:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 20 Nov 2017 17:14:24 -0800 (PST)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Mon, 20 Nov 2017 17:14:24 -0800
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund , "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11410468836062055e73ecf6"
Archived-At: 
Subject: Re: [Netconf] NACM and "when" statements
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 01:14:30 -0000

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

Hi,


On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton  wrote:

> Hi Andy, Martin,
>
> I've got a question about 'when' statement handling related to NACM.
>
> Due to when statements, it is possible that a client could implicitly
> cause a change to a part of the data tree that they have no write access to
> because they cause a when condition to evaluate to a different answer.  Am
> I correct in presuming that this implicit change is allowed?
>
> E.g. in the following example, a user may only have write access to "baz"
> but not "bar". If they create "baz" then that may implicitly cause "bar" to
> be deleted.  Further, even if this implicit delete to "bar" is allowed, I
> presume that the equivalent explicit change or creating "baz" and deleting
> "bar" would still be rejected because there is no explicit write access to
> bar.
>
> container foo {
>   leaf bar {
>    when "not(../baz)";
>   }
>   leaf baz {
>   }
> }
>
> Should this be mentioned in the NACM draft at all?  I'm not convinced that
> the draft makes the correct behaviour for handling 'when' statements
> obvious.
>
> Similar considerations could also apply when writing to choice statements.
>
>
I just confirmed that our server does not enforce nacm:default-deny-all for
the "when-stmt" node.
NACM rules say "user X is allowed to write /foo/baz" and nothing about
/foo/baz side-effects.
YANG says nodes exist only if the when-stmt is true and nothing about how
they change
from true to false. I don't think access control is mentioned in either RFC
for this corner-case.

Perhaps more security consideration text is needed, warning that any nodes
that are deleted
by the server because of false when-stmt evaluation are exempt from access
control.

It would be a significant change to implementations to enforce delete
permissions on
when-stmt and choice-stmt automatic node removal. This can also apply to
automatic
creation of default nodes (when-stmt evaluates true, was false).



> Thanks,
> Rob
>
>
>
Andy

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


Hi,


On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton <rwilton@cisco.=
com> wrote:
Hi Andy, Martin=
,



I've got a question about 'when' statement handling related to =
NACM.



Due to when statements, it is possible that a client could implicitly cause=
 a change to a part of the data tree that they have no write access to beca=
use they cause a when condition to evaluate to a different answer.=C2=A0 Am=
 I correct in presuming that this implicit change is allowed?



E.g. in the following example, a user may only have write access to "b=
az" but not "bar". If they create "baz" then that =
may implicitly cause "bar" to be deleted.=C2=A0 Further, even if =
this implicit delete to "bar" is allowed, I presume that the equi=
valent explicit change or creating "baz" and deleting "bar&q=
uot; would still be rejected because there is no explicit write access to b=
ar.



container foo {

=C2=A0 leaf bar {

=C2=A0=C2=A0 when "not(../baz)";

=C2=A0 }

=C2=A0 leaf baz {

=C2=A0 }

}



Should this be mentioned in the NACM draft at all?=C2=A0 I'm not convin=
ced that the draft makes the correct behaviour for handling 'when' =
statements obvious.



Similar considerations could also apply when writing to choice statements.<=
br>


I just confirmed that our server does =
not enforce nacm:default-deny-all for the "when-stmt" node.
=

NACM rules say "user X is allowed to write /foo/baz" and not=
hing about /foo/baz side-effects.
YANG says nodes exist only if t=
he when-stmt is true and nothing about how they change
from true =
to false. I don't think access control is mentioned in either RFC for t=
his corner-case.

Perhaps more security considerati=
on text is needed, warning that any nodes that are deleted
by the=
 server because of false when-stmt evaluation are exempt from access contro=
l.

It would be a significant change to implementat=
ions to enforce delete permissions on
when-stmt and choice-stmt a=
utomatic node removal. This can also apply to automatic
creation =
of default nodes (when-stmt evaluates true, was false).

=C2=A0

Thanks,

Rob





Andy

=C2=A0



--001a11410468836062055e73ecf6--


From nobody Tue Nov 21 01:56:22 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5427212945A for ; Tue, 21 Nov 2017 01:56:19 -0800 (PST)
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, 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 lXyhRuv49Szl for ; Tue, 21 Nov 2017 01:56:17 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B92129443 for ; Tue, 21 Nov 2017 01:56:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44196; q=dns/txt; s=iport; t=1511258176; x=1512467776; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=X29hUSUrqMT1AVk+cZpnu9474I3rVOjiUW38P6zkTHU=; b=lOWvoyMroZ9OT2Vk9kXUoV74PIMbIDIoV+gOM3rKl25J7D+iWKejHFlM ZlVn8t1ExgS4ZwpumqHlymFIe1DrfX8EqhfdaCtJhoLVBepfy6cyG4ziK xpL7cCd46dR2mK+D/6gPGJAN+S3jqd2jTrK5hBIQMZ31b03GFasC9d+pS Y=;
X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208,217";a="393883"
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; 21 Nov 2017 09:56:14 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAL9uEF2019969; Tue, 21 Nov 2017 09:56:14 GMT
To: "Eric Voit (evoit)" , Alexander Clemm , "netconf@ietf.org" , Lou Berger 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 21 Nov 2017 09:56:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1F7D4F829B6BA9B1BDC70C11"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 09:56:19 -0000

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

I think that using a feature is better here.  Defining a separate module 
for just one leaf seems somewhat like overkill.

I'm not sure that any compile time dependency on network instances, and 
hence schema mount, is really an issue; the more important one to avoid 
is the run time dependency on network instances and schema mount, and 
both solutions achieve this.

But I also agree with Juergen's comment that we should be consistent, 
and the same approach should be used for other protocols with 
conditional dependencies on network instances as well.

Thanks,
Rob


On 20/11/2017 19:54, Eric Voit (evoit) wrote:
>
> *From:*Alexander Clemm, November 20, 2017 2:46 PM
>
> Hi Eric,
>
> I agree that proliferation of modules is a concern, and certainly we 
> would not want to run into combinatorial explosions. However, I don’t 
> think this would be the case here - we would not need to augment VRF 
> into yang-push also (or yang-push into VRF).  Instead, both yang-push 
> and vrf-for-notifications would be augmenting subscribed-notifications 
> in parallel.
>
>   Yes, you are right, with this approach we would end with three 
> models rather than four.  But two models is already a lot.   And we 
> still set precedence that we end with a new VRF specific model every 
> time any YANG model needs a VRF.
>
> Eric
>
> --- Alex
>
> *From:*Eric Voit (evoit) [mailto:evoit@cisco.com]
> *Sent:* Monday, November 20, 2017 11:39 AM
> *To:* Alexander Clemm  >; Robert Wilton -X (rwilton - 
> ENSOFT LIMITED at Cisco)  >; netconf@ietf.org 
> ; Lou Berger  >
> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> I agree this is more elegant if we look just at 
> subscribed-notifications.   However extrapolating this means that we 
> have a duplicate YANG module every time we have a VRF.   And in our 
> case when we augment yang-push, which model do we start from?
>
> Eric
>
> *From:*Alexander Clemm [mailto:alexander.clemm@huawei.com]
> *Sent:* Monday, November 20, 2017 2:27 PM
> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
> >; Eric Voit (evoit) 
> >; netconf@ietf.org 
> ; Lou Berger  >
> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> I am fine with that change, but wanted to bring up one additional 
> option that was also briefly mentioned in the room which strikes me as 
> perhaps a bit more elegant.  That is the option to use augmentation.  
> In that case, source-vrf and the import statement would simply be 
> omitted. Instead, a new module would be created (e.g. 
> ietf-vrf-for-subscribed-notifications), which contains the import 
> statement and two augments statements to augment the source-vrf into 
> the existing module.
>
> --- Alex
>
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Robert 
> Wilton
> *Sent:* Friday, November 17, 2017 10:46 AM
> *To:* Eric Voit (evoit) >; 
> netconf@ietf.org ; Lou Berger 
> >
> *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF of 
> configured subscription?
>
> On 17/11/2017 18:17, Eric Voit (evoit) wrote:
>
>     I would like to continue the discussion on this topic from our
>     session.   I think we came to agreement among the attendees.  
>     Hopefully this thread can confirm, or refine as need.
>
>     First let’s look at Robert’s proposal below:
>
>     There are lots of good elements in Robert’s proposal below, but it
>     isn’t up to our WG to determine the proper structure of the
>     network-instance-model. Authors of that model were in the room,
>     and are aware that YANG model developers from outside would
>     welcome a partitioning which decouples any linkages to
>     schema-mount when all that is needed is to identify a VRF by name.
>
>     Looking at what we can control, discussed in the room was the
>     following change to subscribed-notifications:
>
>     1.import “ietf-network-instance”
>
>     2.create if-feature “VRF”.
>
>     3.apply feature “VRF” to object “source-VRF”
>
>     4.Leafref to “source-VRF” to validate against the network-instance
>     model’s /network-instances/network-instance/name.
>
>     This is the current proposal.  Are there are
>     concerns/objections/refinements?
>
>
> No concerns, but perhaps one trivial refinement.
>
> I had mistakenly thought that a device would either support VRFs for 
> all protocols or none, hence my suggestion to have a single "VRF" 
> feature, which would naturally be defined by the network-instances model.
>
> In the discussions that I had with Lou, some of them at the mic, some 
> afterwards, Lou clarified that it quite plausible that VRFs may only 
> be supported by some protocols on a device and not all, and hence the 
> solution of having a "VRF" feature per protocol seems like the right 
> solution.
>
> I think that I would call the feature "supports-vrf" rather than "vrf".
>
> Thanks,
> Rob
>
>     Eric
>
>     *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>     *Eric Voit (evoit)
>     *Sent:* Tuesday, November 14, 2017 10:23 PM
>     *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>      ; netconf@ietf.org
>     ; Lou Berger 
>     
>     *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF
>     of configured subscription?
>
>     Agree it is a generic problem.
>
>     I would defer to Lou and the other authors of
>     draft-ietf-rtgwg-ni-model as this would be a fairly significant
>     change.
>
>     Eric
>
>     *From:*Robert Wilton, November 14, 2017 7:58 PM
>
>     Hi Eric, Lou,
>
>     This seems to be a generic problem.
>
>     Could the VRF leafref name dependency issue be solved with an
>     if-feature statement?.
>
>     I.e.could the network instance draft define a separate YANG module
>     (with no dependencies) that defines a "VRF" feature.
>
>     All the VRF references (ideally if all IETF YANG modules that may
>     optionally depend on VRFs) could be leaf-refs to
>     /network-instances/network-instance/name but predicated with an
>     if-feature "ni:vrf".
>
>     Hence if a device doesn't support VRFs, then it doesn't implement
>     the "vrf" feature, so it doesn't have to implement the full
>     network instances module, or schema mount.
>
>     Thanks,
>     Rob
>
>     On 15/11/2017 08:45, Eric Voit (evoit) wrote:
>
>         In the WG session tomorrow, I am hoping to get “hum feedback” on:
>
>         draft-ietf-netconf-subscribed-notifications
>
>         https://github.com/netconf-wg/rfc5277bis/issues/5
>
>         The two choices exposed during the two week review for how to
>         represent Source VRF of configured subscription were:
>
>         (1) Leafref to “ietf-network-instance”
>         /network-instances/network-instance/name
>
>         ·Creates dependency on schema mount for subscriptions.
>
>         ·Source VRF is an optional capability, but publishers that
>         don’t care about VRFs must still import. (Note: could also
>         augment the leafref in another model, but that adds another
>         layer of complexity)
>
>         ·establishes model dependency to draft-ietf-rtgwg-ni-model
>
>         (2) Use a string which would be populated with exact same name
>         as would be in the leafref of (1)
>
>         ·Possible to name VRF which doesn’t exist
>
>         The current draft does (2).
>
>         Thanks,
>
>         Eric
>
>         _______________________________________________
>
>         Netconf mailing list
>
>         Netconf@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/netconf
>
>     .
>


--------------1F7D4F829B6BA9B1BDC70C11
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I think that using a feature is better here.  Defining a separate
      module for just one leaf seems somewhat like overkill.

    
I'm not sure that any compile time dependency on network
      instances, and hence schema mount, is really an issue; the more
      important one to avoid is the run time dependency on network
      instances and schema mount, and both solutions achieve this.

    
But I also agree with Juergen's comment that we should be
      consistent, and the same approach should be used for other
      protocols with conditional dependencies on network instances as
      well.

    

    
Thanks,

      Rob

    

    
On 20/11/2017 19:54, Eric Voit (evoit)
      wrote:

    

    

      
      
      
      

        
From: Alexander Clemm, November 20, 2017
            2:46 PM

            

            

        
 

        
Hi Eric,

        
 

        
I agree that
            proliferation of modules is a concern, and certainly we
            would not want to run into combinatorial explosions. 
            However, I don’t think this would be the case here - we
            would not need to augment VRF into yang-push also (or
            yang-push into VRF).  Instead, both yang-push and
            vrf-for-notifications would be augmenting
            subscribed-notifications in parallel. 
            

        
 

        
<Eric>  Yes, you are right,
              with this approach we would end with three models rather
              than four.  But two models is already a lot.   And we
              still set precedence that we end with a new VRF specific
              model every time any YANG model needs a VRF. 
              

        
Eric

        
 

        
--- Alex

        
 

        

          

            

              
From: Eric Voit (evoit) [mailto:evoit@cisco.com]
                  

                  Sent: Monday, November 20, 2017 11:39 AM

                  To: Alexander Clemm <alexander.clemm@huawei.com>;
                  Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
                  <rwilton@cisco.com>;
                  netconf@ietf.org; Lou
                  Berger <lberger@labn.net>

                  Subject: RE: [Netconf] Issue SN #5: How to
                  represent Source VRF of configured subscription?

            

          

          
 

          
I agree this
              is more elegant if we look just at
              subscribed-notifications.   However extrapolating this
              means that we have a duplicate YANG module every time we
              have a VRF.   And in our case when we augment yang-push,
              which model do we start from?

          
 

          
Eric

          
 

          

            

              

                
From: Alexander Clemm [mailto:alexander.clemm@huawei.com]
                    

                    Sent: Monday, November 20, 2017 2:27 PM

                    To: Robert Wilton -X (rwilton - ENSOFT
                    LIMITED at Cisco) <rwilton@cisco.com>;
                    Eric Voit (evoit) <evoit@cisco.com>;
                    netconf@ietf.org; Lou
                    Berger <lberger@labn.net>

                    Subject: RE: [Netconf] Issue SN #5: How to
                    represent Source VRF of configured subscription?

              

            

            
 

            
I am fine
                with that change, but wanted to bring up one additional
                option that was also briefly mentioned in the room which
                strikes me as perhaps a bit more elegant.  That is the
                option to use augmentation.  In that case, source-vrf
                and the import statement would simply be omitted.
                Instead, a new module would be created (e.g.
                ietf-vrf-for-subscribed-notifications), which contains
                the import statement and two augments statements to
                augment the source-vrf into the existing module.  

            
 

            
--- Alex

            
 

            

              

                

                  
From: Netconf [mailto:netconf-bounces@ietf.org]
                      On Behalf Of Robert Wilton

                      Sent: Friday, November 17, 2017 10:46 AM

                      To: Eric Voit (evoit) <evoit@cisco.com>;
                      netconf@ietf.org; Lou
                      Berger <lberger@labn.net>

                      Subject: Re: [Netconf] Issue SN #5: How to
                      represent Source VRF of configured subscription?

                

              

              
 

              
 

              

                
On 17/11/2017 18:17, Eric Voit
                  (evoit) wrote:

              

              

                
I would
                    like to continue the discussion on this topic from
                    our session.   I think we came to agreement among
                    the attendees.   Hopefully this thread can confirm,
                    or refine as need.

                
 

                
First
                    let’s look at Robert’s proposal below:

                
There
                    are lots of good elements in Robert’s proposal
                    below, but it isn’t up to our WG to determine the
                    proper structure of the network-instance-model.  
                    Authors of that model were in the room, and are
                    aware that YANG model developers from outside would
                    welcome a partitioning which decouples any linkages
                    to schema-mount when all that is needed is to
                    identify a VRF by name.

                
 

                
Looking
                    at what we can control, discussed in the room was
                    the following change to subscribed-notifications:  

                
1.     
                    import
                    “ietf-network-instance” 

                
2.     
                    create if-feature “VRF”.  

                
3.     
                    apply feature “VRF” to object
                    “source-VRF”

                
4.     
                    Leafref to “source-VRF” to
                    validate against the network-instance model’s
                    /network-instances/network-instance/name. 
                  

                
 

                
This is
                    the current proposal.  Are there are
                    concerns/objections/refinements?

              

              


                  No concerns, but perhaps one trivial refinement.

                  

                  I had mistakenly thought that a device would either
                  support VRFs for all protocols or none, hence my
                  suggestion to have a single "VRF" feature, which would
                  naturally be defined by the network-instances model.

                  

                  In the discussions that I had with Lou, some of them
                  at the mic, some afterwards, Lou clarified that it
                  quite plausible that VRFs may only be supported by
                  some protocols on a device and not all, and hence the
                  solution of having a "VRF" feature per protocol seems
                  like the right solution.

                  

                  I think that I would call the feature "supports-vrf"
                  rather than "vrf".

                  

                  Thanks,

                  Rob

              

                
 

                
Eric

                
 

                
 

                
 

                

                  

                    

                      
From: Netconf [mailto:netconf-bounces@ietf.org]
                          On Behalf Of Eric Voit (evoit)

                          Sent: Tuesday, November 14, 2017 10:23
                          PM

                          To: Robert Wilton -X (rwilton - ENSOFT
                          LIMITED at Cisco) 
                            <rwilton@cisco.com>; netconf@ietf.org;
                          Lou Berger
                          <lberger@labn.net>

                          Subject: Re: [Netconf] Issue SN #5: How
                          to represent Source VRF of configured
                          subscription?

                    

                  

                  
 

                  
Agree
                      it is a generic problem. 
                    

                  
 

                  
I
                      would defer to Lou and the other authors of
                      draft-ietf-rtgwg-ni-model as this would be a
                      fairly significant change.

                  
 

                  
Eric
                    

                  
 

                  

                    

                      

                        
From: Robert Wilton,
                            November 14, 2017 7:58 PM

                      

                    

                    
Hi Eric, Lou,

                    
This seems to be a generic problem.

                    
Could the VRF leafref name dependency issue be
                      solved with an if-feature statement?.

                    
I.e.could the network instance draft define a
                      separate YANG module (with no dependencies) that
                      defines a "VRF" feature.

                    
All the VRF references (ideally if all IETF YANG
                      modules that may optionally depend on VRFs) could
                      be leaf-refs to
                      /network-instances/network-instance/name but
                      predicated with an if-feature "ni:vrf".

                    
Hence if a device doesn't support VRFs, then it
                      doesn't implement the "vrf" feature, so it doesn't
                      have to implement the full network instances
                      module, or schema mount.

                    
Thanks,

                      Rob

                    
 

                    

                      
On 15/11/2017 08:45, Eric
                        Voit (evoit) wrote:

                    

                    

                      
In the WG session
                        tomorrow, I am hoping to get “hum feedback” on:

                      
 

                      
draft-ietf-netconf-subscribed-notifications
                        

                      
https://github.com/netconf-wg/rfc5277bis/issues/5
                        

                      
 

                      
The two choices exposed
                        during the two week review for how to represent
                        Source VRF of configured subscription were:

                      
 

                      
(1) Leafref to
                        “ietf-network-instance” 
                        /network-instances/network-instance/name

                      

                        ·       
                            Creates
                        dependency on schema mount for subscriptions.
                        

                      

                        ·       
                            Source
                        VRF is an optional capability, but publishers
                        that don’t care about VRFs must still import. 
                        (Note: could also augment the leafref in another
                        model, but that adds another layer of
                        complexity)

                      

                        ·       
                            establishes
                        model dependency to draft-ietf-rtgwg-ni-model

                      
 

                      
(2) Use a string which
                        would be populated with exact same name as would
                        be in the leafref of (1)

                      

                        ·       
                            Possible
                        to name VRF which doesn’t exist

                      
 

                      
The current draft does
                        (2).   

                      
 

                      
Thanks,

                      
Eric 

                      
 

                      
 

                      
_______________________________________________

                      
Netconf mailing list

                      
Netconf@ietf.org

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

                    

                    
 

                  

                

                
.
                    

              

              
 

            

          

        

      

    

    

  


--------------1F7D4F829B6BA9B1BDC70C11--


From nobody Tue Nov 21 02:00:26 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558A812945E for ; Tue, 21 Nov 2017 02:00:25 -0800 (PST)
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 e8fLOrQTgY-X for ; Tue, 21 Nov 2017 02:00:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE36F129443 for ; Tue, 21 Nov 2017 02:00:18 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 990CD1AE0144; Tue, 21 Nov 2017 11:00:17 +0100 (CET)
Date: Tue, 21 Nov 2017 10:58:55 +0100 (CET)
Message-Id: <20171121.105855.1884534168363830366.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, netconf@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: [Netconf] NACM and "when" statements
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 10:00:25 -0000

Andy Bierman  wrote:
> Hi,
> 
> 
> On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton  wrote:
> 
> > Hi Andy, Martin,
> >
> > I've got a question about 'when' statement handling related to NACM.
> >
> > Due to when statements, it is possible that a client could implicitly
> > cause a change to a part of the data tree that they have no write access to
> > because they cause a when condition to evaluate to a different answer.  Am
> > I correct in presuming that this implicit change is allowed?
> >
> > E.g. in the following example, a user may only have write access to "baz"
> > but not "bar". If they create "baz" then that may implicitly cause "bar" to
> > be deleted.  Further, even if this implicit delete to "bar" is allowed, I
> > presume that the equivalent explicit change or creating "baz" and deleting
> > "bar" would still be rejected because there is no explicit write access to
> > bar.
> >
> > container foo {
> >   leaf bar {
> >    when "not(../baz)";
> >   }
> >   leaf baz {
> >   }
> > }
> >
> > Should this be mentioned in the NACM draft at all?  I'm not convinced that
> > the draft makes the correct behaviour for handling 'when' statements
> > obvious.
> >
> > Similar considerations could also apply when writing to choice statements.
> >
> >
> I just confirmed that our server does not enforce nacm:default-deny-all for
> the "when-stmt" node.
> NACM rules say "user X is allowed to write /foo/baz" and nothing about
> /foo/baz side-effects.

Our implementation works the same way, and I agree this is reasonable
behavior.  NACM controls access to the operations, not the side
effects.


/martin


> YANG says nodes exist only if the when-stmt is true and nothing about how
> they change
> from true to false. I don't think access control is mentioned in either RFC
> for this corner-case.
> 
> Perhaps more security consideration text is needed, warning that any nodes
> that are deleted
> by the server because of false when-stmt evaluation are exempt from access
> control.
> 
> It would be a significant change to implementations to enforce delete
> permissions on
> when-stmt and choice-stmt automatic node removal. This can also apply to
> automatic
> creation of default nodes (when-stmt evaluates true, was false).
> 
> 
> 
> > Thanks,
> > Rob
> >
> >
> >
> Andy


From nobody Tue Nov 21 04:16:31 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9B12946E for ; Tue, 21 Nov 2017 04:16:29 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 30pXKGTojD6H for ; Tue, 21 Nov 2017 04:16:26 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 496DC129401 for ; Tue, 21 Nov 2017 04:16:26 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 06F4C1AB1AE for ; Tue, 21 Nov 2017 05:16:25 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id ccGL1w0142SSUrH01cGPBu; Tue, 21 Nov 2017 05:16:25 -0700
X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=sC3jslCIGhcA:10 a=AUd_NHdVAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=NEAV23lmAAAA:8 a=bZ9CBtdj5EYBusYyw4kA:9 a=1QmuLIfQkCrDTzBS:21 a=EttQLzpN9i3nLNzB:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22
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=DiMtDj12mdx6IiHomRjb7eaa9+TPHobw/AblrFGWMpA=; b=0q2C/wAnOid0pajEK+cvI4AmkB O+XDIUQoTCqE6qYXWwR7mXtvzEktQTGRA/TGZXEIKPt15hn8sReOgDk5y9cbmv4j4elXQ/06K96GT qyxObTZl0sVVasrF/968bHq7w;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44956 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eH7TQ-002QR9-Hg; Tue, 21 Nov 2017 05:16:20 -0700
To: Robert Wilton , "Eric Voit (evoit)" ,  Alexander Clemm , "netconf@ietf.org" 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>  
From: Lou Berger 
Message-ID: <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net>
Date: Tue, 21 Nov 2017 07:16:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
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.86.101
X-Exim-ID: 1eH7TQ-002QR9-Hg
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:44956
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 12:16:30 -0000

Taking a step back: what is the purpose of having source-vrf in
draft-ietf-netconf-subscribed-notifications?

>From the configuration side, the model seems to allow the configuration
of an IP address for  notification-message-origin that doesn't match any
configured interface.  Does this really make sense?  Why not just limit
configuration to if:interface-ref?  Doing this eliminates the whole VRF
discussion for this model (of course, I'm not saying the discussion
won't happen in other contexts). 

What am I missing?

Also if you do keep 'source-vrf' I think 'source-ni-name' is more
consistent with draft-ietf-rtgwg-ni-model augmentations of if:interface.

Lou

On 11/21/2017 4:56 AM, Robert Wilton wrote:
>
> I think that using a feature is better here.  Defining a separate
> module for just one leaf seems somewhat like overkill.
>
> I'm not sure that any compile time dependency on network instances,
> and hence schema mount, is really an issue; the more important one to
> avoid is the run time dependency on network instances and schema
> mount, and both solutions achieve this.
>
> But I also agree with Juergen's comment that we should be consistent,
> and the same approach should be used for other protocols with
> conditional dependencies on network instances as well.
>
> Thanks,
> Rob
>
>
> On 20/11/2017 19:54, Eric Voit (evoit) wrote:
>>
>> *From:*Alexander Clemm, November 20, 2017 2:46 PM
>>
>>  
>>
>> Hi Eric,
>>
>>  
>>
>> I agree that proliferation of modules is a concern, and certainly we
>> would not want to run into combinatorial explosions.  However, I
>> don’t think this would be the case here - we would not need to
>> augment VRF into yang-push also (or yang-push into VRF).  Instead,
>> both yang-push and vrf-for-notifications would be augmenting
>> subscribed-notifications in parallel. 
>>
>>  
>>
>>   Yes, you are right, with this approach we would end with
>> three models rather than four.  But two models is already a lot. 
>>  And we still set precedence that we end with a new VRF specific
>> model every time any YANG model needs a VRF. 
>>
>> Eric
>>
>>  
>>
>> --- Alex
>>
>>  
>>
>> *From:*Eric Voit (evoit) [mailto:evoit@cisco.com]
>> *Sent:* Monday, November 20, 2017 11:39 AM
>> *To:* Alexander Clemm > >; Robert Wilton -X (rwilton -
>> ENSOFT LIMITED at Cisco) > >; netconf@ietf.org
>> ; Lou Berger > >
>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of
>> configured subscription?
>>
>>  
>>
>> I agree this is more elegant if we look just at
>> subscribed-notifications.   However extrapolating this means that we
>> have a duplicate YANG module every time we have a VRF.   And in our
>> case when we augment yang-push, which model do we start from?
>>
>>  
>>
>> Eric
>>
>>  
>>
>> *From:*Alexander Clemm [mailto:alexander.clemm@huawei.com]
>> *Sent:* Monday, November 20, 2017 2:27 PM
>> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>> >; Eric Voit (evoit)
>> >; netconf@ietf.org
>> ; Lou Berger > >
>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of
>> configured subscription?
>>
>>  
>>
>> I am fine with that change, but wanted to bring up one additional
>> option that was also briefly mentioned in the room which strikes me
>> as perhaps a bit more elegant.  That is the option to use
>> augmentation.  In that case, source-vrf and the import statement
>> would simply be omitted. Instead, a new module would be created (e.g.
>> ietf-vrf-for-subscribed-notifications), which contains the import
>> statement and two augments statements to augment the source-vrf into
>> the existing module. 
>>
>>  
>>
>> --- Alex
>>
>>  
>>
>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>> *Robert Wilton
>> *Sent:* Friday, November 17, 2017 10:46 AM
>> *To:* Eric Voit (evoit) >;
>> netconf@ietf.org ; Lou Berger
>> >
>> *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF of
>> configured subscription?
>>
>>  
>>
>>  
>>
>> On 17/11/2017 18:17, Eric Voit (evoit) wrote:
>>
>>     I would like to continue the discussion on this topic from our
>>     session.   I think we came to agreement among the attendees.  
>>     Hopefully this thread can confirm, or refine as need.
>>
>>      
>>
>>     First let’s look at Robert’s proposal below:
>>
>>     There are lots of good elements in Robert’s proposal below, but
>>     it isn’t up to our WG to determine the proper structure of the
>>     network-instance-model.   Authors of that model were in the room,
>>     and are aware that YANG model developers from outside would
>>     welcome a partitioning which decouples any linkages to
>>     schema-mount when all that is needed is to identify a VRF by name.
>>
>>      
>>
>>     Looking at what we can control, discussed in the room was the
>>     following change to subscribed-notifications:  
>>
>>     1.      import “ietf-network-instance” 
>>
>>     2.      create if-feature “VRF”.  
>>
>>     3.      apply feature “VRF” to object “source-VRF”
>>
>>     4.      Leafref to “source-VRF” to validate against the
>>     network-instance model’s /network-instances/network-instance/name. 
>>
>>      
>>
>>     This is the current proposal.  Are there are
>>     concerns/objections/refinements?
>>
>>
>> No concerns, but perhaps one trivial refinement.
>>
>> I had mistakenly thought that a device would either support VRFs for
>> all protocols or none, hence my suggestion to have a single "VRF"
>> feature, which would naturally be defined by the network-instances model.
>>
>> In the discussions that I had with Lou, some of them at the mic, some
>> afterwards, Lou clarified that it quite plausible that VRFs may only
>> be supported by some protocols on a device and not all, and hence the
>> solution of having a "VRF" feature per protocol seems like the right
>> solution.
>>
>> I think that I would call the feature "supports-vrf" rather than "vrf".
>>
>> Thanks,
>> Rob
>>
>>      
>>
>>     Eric
>>
>>      
>>
>>      
>>
>>      
>>
>>     *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>>     *Eric Voit (evoit)
>>     *Sent:* Tuesday, November 14, 2017 10:23 PM
>>     *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>>      ; netconf@ietf.org
>>     ; Lou Berger 
>>     
>>     *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF
>>     of configured subscription?
>>
>>      
>>
>>     Agree it is a generic problem.
>>
>>      
>>
>>     I would defer to Lou and the other authors of
>>     draft-ietf-rtgwg-ni-model as this would be a fairly significant
>>     change.
>>
>>      
>>
>>     Eric
>>
>>      
>>
>>     *From:*Robert Wilton, November 14, 2017 7:58 PM
>>
>>     Hi Eric, Lou,
>>
>>     This seems to be a generic problem.
>>
>>     Could the VRF leafref name dependency issue be solved with an
>>     if-feature statement?.
>>
>>     I.e.could the network instance draft define a separate YANG
>>     module (with no dependencies) that defines a "VRF" feature.
>>
>>     All the VRF references (ideally if all IETF YANG modules that may
>>     optionally depend on VRFs) could be leaf-refs to
>>     /network-instances/network-instance/name but predicated with an
>>     if-feature "ni:vrf".
>>
>>     Hence if a device doesn't support VRFs, then it doesn't implement
>>     the "vrf" feature, so it doesn't have to implement the full
>>     network instances module, or schema mount.
>>
>>     Thanks,
>>     Rob
>>
>>      
>>
>>     On 15/11/2017 08:45, Eric Voit (evoit) wrote:
>>
>>         In the WG session tomorrow, I am hoping to get “hum feedback” on:
>>
>>          
>>
>>         draft-ietf-netconf-subscribed-notifications
>>
>>         https://github.com/netconf-wg/rfc5277bis/issues/5
>>
>>          
>>
>>         The two choices exposed during the two week review for how to
>>         represent Source VRF of configured subscription were:
>>
>>          
>>
>>         (1) Leafref to “ietf-network-instance” 
>>         /network-instances/network-instance/name
>>
>>         ·        Creates dependency on schema mount for subscriptions.
>>
>>         ·        Source VRF is an optional capability, but publishers
>>         that don’t care about VRFs must still import.  (Note: could
>>         also augment the leafref in another model, but that adds
>>         another layer of complexity)
>>
>>         ·        establishes model dependency to
>>         draft-ietf-rtgwg-ni-model
>>
>>          
>>
>>         (2) Use a string which would be populated with exact same
>>         name as would be in the leafref of (1)
>>
>>         ·        Possible to name VRF which doesn’t exist
>>
>>          
>>
>>         The current draft does (2).  
>>
>>          
>>
>>         Thanks,
>>
>>         Eric
>>
>>          
>>
>>          
>>
>>         _______________________________________________
>>
>>         Netconf mailing list
>>
>>         Netconf@ietf.org 
>>
>>         https://www.ietf.org/mailman/listinfo/netconf
>>
>>      
>>
>>     .
>>
>>  
>>
>


From nobody Tue Nov 21 05:06:25 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D9129482 for ; Tue, 21 Nov 2017 05:06:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZlzW1OofxyJ for ; Tue, 21 Nov 2017 05:06:16 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB469129480 for ; Tue, 21 Nov 2017 05:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16212; q=dns/txt; s=iport; t=1511269576; x=1512479176; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pFgyDHctQ+840FpHK3r8gArL1rP8QqFXhTy/WxPzk2o=; b=SeVm1ZMpOffEQvf2NIG2ov6vFYdwP5E3IfEha2laPt9fdis7aC91lhfK /3W6DYXPnxovLRBPNJtHQQncCGCuXXbx1uxoKy1klq2Hhl2dhtK3T4IFm C4UN2ofDfGjhXTpKoEYyLofHSnjAIxhBVpdV/3L76YCE0eAkafzqjFyoq k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAACyIxRa/51dJa1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuJweDeIofjyqBfZZighEKGAuEA0ZPAhqEbT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQMBAQEhEToQCwIBBgIOAwQBAQECAgkaAwICAiULFAEICAIEA?= =?us-ascii?q?RIIE4l/CBCLFJ1rgieLAgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CJYIHgVW?= =?us-ascii?q?FFIRwBAEtECOCW4JjBZF0kEoCh3CNEZNWjHSJFAIRGQGBOQEfOYF0ehVJgmSDE?= =?us-ascii?q?YFOd4knAQElB4EFgRQBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208";a="33899505"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2017 13:06:15 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vALD6EBT009628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Nov 2017 13:06:14 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 21 Nov 2017 08:06:13 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 08:06:13 -0500
From: "Eric Voit (evoit)" 
To: Lou Berger , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Alexander Clemm , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAJhO04AACinC0P//tAyAgABTJJCAAJppAIAAJx6AgABLagA=
Date: Tue, 21 Nov 2017 13:06:13 +0000
Message-ID: <72ace49056484d49a0f6eadc42ea49a5@XCH-RTP-013.cisco.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>   <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net>
In-Reply-To: <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 13:06:24 -0000

SGkgTG91LA0KDQo+IEZyb206IExvdSBCZXJnZXIsIE5vdmVtYmVyIDIxLCAyMDE3IDc6MTYgQU0N
Cj4gDQo+IFRha2luZyBhIHN0ZXAgYmFjazogd2hhdCBpcyB0aGUgcHVycG9zZSBvZiBoYXZpbmcg
c291cmNlLXZyZiBpbiBkcmFmdC1pZXRmLQ0KPiBuZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0
aW9ucz8NCg0KVGhlcmUgYXJlIG1hbnkgdXNlcyBmb3IgdGhpcywgYW5kIG5vdCBoYXZpbmcgaXQg
aXMgYWxyZWFkeSBiZWluZyBzZWVuIGFzIGEgcHJvZHVjdGlvbiBwcm9ibGVtIGluIHR3byBzZXBh
cmF0ZSB0ZWxlbWV0cnkgZW52aXJvbm1lbnRzOg0KKDEpIEJlaW5nIGFibGUgdG8gcHVzaCB0ZWxl
bWV0cnkgdHJhZmZpYyB0byBvbmUgb3IgbW9yZSBjb2xsZWN0aW9uIFZSRnMgd2hpY2ggYXJlIG5v
dCBleHBvc2VkIGluIHRoZSBnbG9iYWwgcm91dGluZyB0YWJsZS4NCigyKSBCZWluZyBhYmxlIHRv
IHNlbmQgcm91dGluZyBhbmQgc3dpdGNoaW5nIGluZm8gcmVsZXZhbnQgdG8gYSBzcGVjaWZpYyBj
dXN0b21lciBWUkZzIG9uIHRoYXQgY3VzdG9tZXIncyBWUkYuICAoSS5lLiwgcHJvdmlkZSB0cmFm
ZmljIGNvdW50ZXJzIHRvIGEgY29sbGVjdGlvbiBJUCBhZGRyZXNzL2RvbWFpbiBmb3IgdGhhdCBW
UkYpDQogDQo+IEZyb20gdGhlIGNvbmZpZ3VyYXRpb24gc2lkZSwgdGhlIG1vZGVsIHNlZW1zIHRv
IGFsbG93IHRoZSBjb25maWd1cmF0aW9uIG9mDQo+IGFuIElQIGFkZHJlc3MgZm9ywqAgbm90aWZp
Y2F0aW9uLW1lc3NhZ2Utb3JpZ2luIHRoYXQgZG9lc24ndCBtYXRjaCBhbnkNCj4gY29uZmlndXJl
ZCBpbnRlcmZhY2UuwqAgRG9lcyB0aGlzIHJlYWxseSBtYWtlIHNlbnNlP8KgIFdoeSBub3QganVz
dCBsaW1pdA0KPiBjb25maWd1cmF0aW9uIHRvIGlmOmludGVyZmFjZS1yZWY/wqANCg0KVGhlIHBl
cnNvbiBkb2luZyB0aGUgY29uZmlndXJhdGlvbiBuZWVkIGhhdmUgbm8gdW5kZXJzdGFuZGluZyBv
ZiB0aGUgaW50ZXJmYWNlcyBvbiB0aGUgcm91dGVyLiAgSW4gYWRkaXRpb24sIGlmIHRoZSBuaS1u
YW1lIGlzIHRoZSBzYW1lIGFjcm9zcyByb3V0ZXJzLCB0aGUgc2FtZSBuaS1uYW1lIGNhbiBiZSB1
c2VkIGFjcm9zcyB0aGUgZG9tYWluIHdpdGhvdXQga25vd2xlZGdlIG9mIHN1Y2ggZGV2aWNlIHNw
ZWNpZmljcy4NCg0KPiBEb2luZyB0aGlzIGVsaW1pbmF0ZXMgdGhlIHdob2xlIFZSRg0KPiBkaXNj
dXNzaW9uIGZvciB0aGlzIG1vZGVsIChvZiBjb3Vyc2UsIEknbSBub3Qgc2F5aW5nIHRoZSBkaXNj
dXNzaW9uIHdvbid0DQo+IGhhcHBlbiBpbiBvdGhlciBjb250ZXh0cykuDQo+IA0KPiBXaGF0IGFt
IEkgbWlzc2luZz8NCg0KVGhpcyB0eXBlIG9mIGNvbmZpZ3VyYXRpb24gaXMgcmVhbGx5IGFpbWVk
IGF0IGEgbGV2ZWwgaGlnaGVyIHRoYW4gc29tZW9uZSB3aG8gbmVlZHMgY2FyZSBhYm91dCB0b3Bv
bG9neSBpc3N1ZXMuICBUaGV5IGp1c3Qgd2FudCBzb21ldGhpbmcgb3V0IG9mIHRoZSBuZXR3b3Jr
IGNsb3VkLiAgIEl0IGlzIHF1aXRlIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSB0aGUgc2FtZSBzdWJz
Y3JpcHRpb24gaW5mbyB0byBhbGwgZGV2aWNlcyBpbiBhIGRvbWFpbiB3aXRob3V0IGFueSBwZXIt
ZGV2aWNlIGRldmlhdGlvbnMgYXQgYWxsLiAgKEkuZS4sIHNhbWUgY29uZmlndXJlZCBzdWJzY3Jp
cHRpb24taWQsIHNhbWUgZmlsdGVyLCBzYW1lIFZSRiwgc2FtZSBwZXJpb2QsIC4uLikNCg0KPiBB
bHNvIGlmIHlvdSBkbyBrZWVwICdzb3VyY2UtdnJmJyBJIHRoaW5rICdzb3VyY2UtbmktbmFtZScg
aXMgbW9yZSBjb25zaXN0ZW50DQo+IHdpdGggZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbCBhdWdt
ZW50YXRpb25zIG9mIGlmOmludGVyZmFjZS4NCg0KIk5pLW5hbWUiIGlzIG1vcmUgZ2VuZXJpYyBi
ZWNhdXNlIGl0IHN1cHBvcnRzIG1vcmUgdHlwZXMgb2YgdGVjaG5vbG9naWVzIHRoYW4gcmVxdWly
ZWQgYXQgdGhpcyB0aW1lLiAgIEFzIG5vIGN1c3RvbWVyIGlzIHRhbGtpbmcgYWJvdXQgdGhpbmdz
IGJleW9uZCBWUkYsIGluc3RhbGxpbmcgdGhlIG1vcmUgZ2VuZXJpYyBuYW1lIHdvdWxkIGJlIGFu
IGFkZGVkIGxheWVyIG9mIGNvbXBsZXhpdHkuDQoNCkVyaWMNCiANCj4gTG91DQo+IA0KPiBPbiAx
MS8yMS8yMDE3IDQ6NTYgQU0sIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4NCj4gPiBJIHRoaW5r
IHRoYXQgdXNpbmcgYSBmZWF0dXJlIGlzIGJldHRlciBoZXJlLsKgIERlZmluaW5nIGEgc2VwYXJh
dGUNCj4gPiBtb2R1bGUgZm9yIGp1c3Qgb25lIGxlYWYgc2VlbXMgc29tZXdoYXQgbGlrZSBvdmVy
a2lsbC4NCj4gPg0KPiA+IEknbSBub3Qgc3VyZSB0aGF0IGFueSBjb21waWxlIHRpbWUgZGVwZW5k
ZW5jeSBvbiBuZXR3b3JrIGluc3RhbmNlcywNCj4gPiBhbmQgaGVuY2Ugc2NoZW1hIG1vdW50LCBp
cyByZWFsbHkgYW4gaXNzdWU7IHRoZSBtb3JlIGltcG9ydGFudCBvbmUgdG8NCj4gPiBhdm9pZCBp
cyB0aGUgcnVuIHRpbWUgZGVwZW5kZW5jeSBvbiBuZXR3b3JrIGluc3RhbmNlcyBhbmQgc2NoZW1h
DQo+ID4gbW91bnQsIGFuZCBib3RoIHNvbHV0aW9ucyBhY2hpZXZlIHRoaXMuDQo+ID4NCj4gPiBC
dXQgSSBhbHNvIGFncmVlIHdpdGggSnVlcmdlbidzIGNvbW1lbnQgdGhhdCB3ZSBzaG91bGQgYmUg
Y29uc2lzdGVudCwNCj4gPiBhbmQgdGhlIHNhbWUgYXBwcm9hY2ggc2hvdWxkIGJlIHVzZWQgZm9y
IG90aGVyIHByb3RvY29scyB3aXRoDQo+ID4gY29uZGl0aW9uYWwgZGVwZW5kZW5jaWVzIG9uIG5l
dHdvcmsgaW5zdGFuY2VzIGFzIHdlbGwuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gUm9iDQo+ID4N
Cj4gPg0KPiA+IE9uIDIwLzExLzIwMTcgMTk6NTQsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0K
PiA+Pg0KPiA+PiAqRnJvbToqQWxleGFuZGVyIENsZW1tLCBOb3ZlbWJlciAyMCwgMjAxNyAyOjQ2
IFBNDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEhpIEVyaWMsDQo+ID4+DQo+ID4+DQo+ID4+DQo+
ID4+IEkgYWdyZWUgdGhhdCBwcm9saWZlcmF0aW9uIG9mIG1vZHVsZXMgaXMgYSBjb25jZXJuLCBh
bmQgY2VydGFpbmx5IHdlDQo+ID4+IHdvdWxkIG5vdCB3YW50IHRvIHJ1biBpbnRvIGNvbWJpbmF0
b3JpYWwgZXhwbG9zaW9ucy7CoCBIb3dldmVyLCBJDQo+ID4+IGRvbuKAmXQgdGhpbmsgdGhpcyB3
b3VsZCBiZSB0aGUgY2FzZSBoZXJlIC0gd2Ugd291bGQgbm90IG5lZWQgdG8NCj4gPj4gYXVnbWVu
dCBWUkYgaW50byB5YW5nLXB1c2ggYWxzbyAob3IgeWFuZy1wdXNoIGludG8gVlJGKS7CoCBJbnN0
ZWFkLA0KPiA+PiBib3RoIHlhbmctcHVzaCBhbmQgdnJmLWZvci1ub3RpZmljYXRpb25zIHdvdWxk
IGJlIGF1Z21lbnRpbmcNCj4gPj4gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGluIHBhcmFsbGVs
Lg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiA8RXJpYz7CoCBZZXMsIHlvdSBhcmUgcmlnaHQsIHdp
dGggdGhpcyBhcHByb2FjaCB3ZSB3b3VsZCBlbmQgd2l0aA0KPiA+PiB0aHJlZSBtb2RlbHMgcmF0
aGVyIHRoYW4gZm91ci7CoCBCdXQgdHdvIG1vZGVscyBpcyBhbHJlYWR5IGEgbG90Lg0KPiA+PiDC
oEFuZCB3ZSBzdGlsbCBzZXQgcHJlY2VkZW5jZSB0aGF0IHdlIGVuZCB3aXRoIGEgbmV3IFZSRiBz
cGVjaWZpYw0KPiA+PiBtb2RlbCBldmVyeSB0aW1lIGFueSBZQU5HIG1vZGVsIG5lZWRzIGEgVlJG
Lg0KPiA+Pg0KPiA+PiBFcmljDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLSBBbGV4DQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+ICpGcm9tOipFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0
QGNpc2NvLmNvbV0NCj4gPj4gKlNlbnQ6KiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDExOjM5
IEFNDQo+ID4+ICpUbzoqIEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5j
b20NCj4gPj4gPG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+OyBSb2JlcnQgV2ls
dG9uIC1YIChyd2lsdG9uIC0NCj4gPj4gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9u
QGNpc2NvLmNvbQ0KPiA+PiA8bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj47IG5ldGNvbmZAaWV0
Zi5vcmcNCj4gPj4gPG1haWx0bzpuZXRjb25mQGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJlcmdl
ckBsYWJuLm5ldA0KPiA+PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPiA+PiAqU3ViamVj
dDoqIFJFOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZS
RiBvZg0KPiA+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8NCj4gPj4NCj4gPj4NCj4gPj4NCj4g
Pj4gSSBhZ3JlZSB0aGlzIGlzIG1vcmUgZWxlZ2FudCBpZiB3ZSBsb29rIGp1c3QgYXQNCj4gPj4g
c3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLsKgwqAgSG93ZXZlciBleHRyYXBvbGF0aW5nIHRoaXMg
bWVhbnMgdGhhdCB3ZQ0KPiA+PiBoYXZlIGEgZHVwbGljYXRlIFlBTkcgbW9kdWxlIGV2ZXJ5IHRp
bWUgd2UgaGF2ZSBhIFZSRi7CoMKgIEFuZCBpbiBvdXINCj4gPj4gY2FzZSB3aGVuIHdlIGF1Z21l
bnQgeWFuZy1wdXNoLCB3aGljaCBtb2RlbCBkbyB3ZSBzdGFydCBmcm9tPw0KPiA+Pg0KPiA+Pg0K
PiA+Pg0KPiA+PiBFcmljDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICpGcm9tOipBbGV4YW5kZXIg
Q2xlbW0gW21haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbV0NCj4gPj4gKlNlbnQ6KiBN
b25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDI6MjcgUE0NCj4gPj4gKlRvOiogUm9iZXJ0IFdpbHRv
biAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKQ0KPiA+PiA8cndpbHRvbkBj
aXNjby5jb20gPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+OyBFcmljIFZvaXQgKGV2b2l0KQ0K
PiA+PiA8ZXZvaXRAY2lzY28uY29tIDxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj47IG5ldGNvbmZA
aWV0Zi5vcmcNCj4gPj4gPG1haWx0bzpuZXRjb25mQGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJl
cmdlckBsYWJuLm5ldA0KPiA+PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPiA+PiAqU3Vi
amVjdDoqIFJFOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNl
IFZSRiBvZg0KPiA+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8NCj4gPj4NCj4gPj4NCj4gPj4N
Cj4gPj4gSSBhbSBmaW5lIHdpdGggdGhhdCBjaGFuZ2UsIGJ1dCB3YW50ZWQgdG8gYnJpbmcgdXAg
b25lIGFkZGl0aW9uYWwNCj4gPj4gb3B0aW9uIHRoYXQgd2FzIGFsc28gYnJpZWZseSBtZW50aW9u
ZWQgaW4gdGhlIHJvb20gd2hpY2ggc3RyaWtlcyBtZQ0KPiA+PiBhcyBwZXJoYXBzIGEgYml0IG1v
cmUgZWxlZ2FudC7CoCBUaGF0IGlzIHRoZSBvcHRpb24gdG8gdXNlDQo+ID4+IGF1Z21lbnRhdGlv
bi7CoCBJbiB0aGF0IGNhc2UsIHNvdXJjZS12cmYgYW5kIHRoZSBpbXBvcnQgc3RhdGVtZW50DQo+
ID4+IHdvdWxkIHNpbXBseSBiZSBvbWl0dGVkLiBJbnN0ZWFkLCBhIG5ldyBtb2R1bGUgd291bGQg
YmUgY3JlYXRlZCAoZS5nLg0KPiA+PiBpZXRmLXZyZi1mb3Itc3Vic2NyaWJlZC1ub3RpZmljYXRp
b25zKSwgd2hpY2ggY29udGFpbnMgdGhlIGltcG9ydA0KPiA+PiBzdGF0ZW1lbnQgYW5kIHR3byBh
dWdtZW50cyBzdGF0ZW1lbnRzIHRvIGF1Z21lbnQgdGhlIHNvdXJjZS12cmYgaW50bw0KPiA+PiB0
aGUgZXhpc3RpbmcgbW9kdWxlLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0gQWxleA0KPiA+
Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAqRnJvbToqTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNl
c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZg0KPiA+PiAqUm9iZXJ0IFdpbHRvbg0KPiA+PiAqU2Vu
dDoqIEZyaWRheSwgTm92ZW1iZXIgMTcsIDIwMTcgMTA6NDYgQU0NCj4gPj4gKlRvOiogRXJpYyBW
b2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbSA8bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+Ow0K
PiA+PiBuZXRjb25mQGlldGYub3JnIDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJn
ZXINCj4gPj4gPGxiZXJnZXJAbGFibi5uZXQgPG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NCj4g
Pj4gKlN1YmplY3Q6KiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cgdG8gcmVwcmVzZW50
IFNvdXJjZSBWUkYgb2YNCj4gPj4gY29uZmlndXJlZCBzdWJzY3JpcHRpb24/DQo+ID4+DQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDE3LzExLzIwMTcgMTg6MTcsIEVyaWMgVm9pdCAo
ZXZvaXQpIHdyb3RlOg0KPiA+Pg0KPiA+PiAgICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVlIHRo
ZSBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMgZnJvbSBvdXINCj4gPj4gICAgIHNlc3Npb24uwqDC
oCBJIHRoaW5rIHdlIGNhbWUgdG8gYWdyZWVtZW50IGFtb25nIHRoZSBhdHRlbmRlZXMuDQo+ID4+
ICAgICBIb3BlZnVsbHkgdGhpcyB0aHJlYWQgY2FuIGNvbmZpcm0sIG9yIHJlZmluZSBhcyBuZWVk
Lg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgRmlyc3QgbGV04oCZcyBsb29rIGF0IFJvYmVy
dOKAmXMgcHJvcG9zYWwgYmVsb3c6DQo+ID4+DQo+ID4+ICAgICBUaGVyZSBhcmUgbG90cyBvZiBn
b29kIGVsZW1lbnRzIGluIFJvYmVydOKAmXMgcHJvcG9zYWwgYmVsb3csIGJ1dA0KPiA+PiAgICAg
aXQgaXNu4oCZdCB1cCB0byBvdXIgV0cgdG8gZGV0ZXJtaW5lIHRoZSBwcm9wZXIgc3RydWN0dXJl
IG9mIHRoZQ0KPiA+PiAgICAgbmV0d29yay1pbnN0YW5jZS1tb2RlbC7CoMKgIEF1dGhvcnMgb2Yg
dGhhdCBtb2RlbCB3ZXJlIGluIHRoZSByb29tLA0KPiA+PiAgICAgYW5kIGFyZSBhd2FyZSB0aGF0
IFlBTkcgbW9kZWwgZGV2ZWxvcGVycyBmcm9tIG91dHNpZGUgd291bGQNCj4gPj4gICAgIHdlbGNv
bWUgYSBwYXJ0aXRpb25pbmcgd2hpY2ggZGVjb3VwbGVzIGFueSBsaW5rYWdlcyB0bw0KPiA+PiAg
ICAgc2NoZW1hLW1vdW50IHdoZW4gYWxsIHRoYXQgaXMgbmVlZGVkIGlzIHRvIGlkZW50aWZ5IGEg
VlJGIGJ5IG5hbWUuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAgICBMb29raW5nIGF0IHdoYXQg
d2UgY2FuIGNvbnRyb2wsIGRpc2N1c3NlZCBpbiB0aGUgcm9vbSB3YXMgdGhlDQo+ID4+ICAgICBm
b2xsb3dpbmcgY2hhbmdlIHRvIHN1YnNjcmliZWQtbm90aWZpY2F0aW9uczoNCj4gPj4NCj4gPj4g
ICAgIDEuwqDCoMKgwqDCoCBpbXBvcnQg4oCcaWV0Zi1uZXR3b3JrLWluc3RhbmNl4oCdDQo+ID4+
DQo+ID4+ICAgICAyLsKgwqDCoMKgwqAgY3JlYXRlIGlmLWZlYXR1cmUg4oCcVlJG4oCdLg0KPiA+
Pg0KPiA+PiAgICAgMy7CoMKgwqDCoMKgIGFwcGx5IGZlYXR1cmUg4oCcVlJG4oCdIHRvIG9iamVj
dCDigJxzb3VyY2UtVlJG4oCdDQo+ID4+DQo+ID4+ICAgICA0LsKgwqDCoMKgwqAgTGVhZnJlZiB0
byDigJxzb3VyY2UtVlJG4oCdIHRvIHZhbGlkYXRlIGFnYWluc3QgdGhlDQo+ID4+ICAgICBuZXR3
b3JrLWluc3RhbmNlIG1vZGVs4oCZcw0KPiA+PiAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1p
bnN0YW5jZS9uYW1lLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgVGhpcyBpcyB0aGUgY3Vy
cmVudCBwcm9wb3NhbC7CoCBBcmUgdGhlcmUgYXJlDQo+ID4+ICAgICBjb25jZXJucy9vYmplY3Rp
b25zL3JlZmluZW1lbnRzPw0KPiA+Pg0KPiA+Pg0KPiA+PiBObyBjb25jZXJucywgYnV0IHBlcmhh
cHMgb25lIHRyaXZpYWwgcmVmaW5lbWVudC4NCj4gPj4NCj4gPj4gSSBoYWQgbWlzdGFrZW5seSB0
aG91Z2h0IHRoYXQgYSBkZXZpY2Ugd291bGQgZWl0aGVyIHN1cHBvcnQgVlJGcyBmb3INCj4gPj4g
YWxsIHByb3RvY29scyBvciBub25lLCBoZW5jZSBteSBzdWdnZXN0aW9uIHRvIGhhdmUgYSBzaW5n
bGUgIlZSRiINCj4gPj4gZmVhdHVyZSwgd2hpY2ggd291bGQgbmF0dXJhbGx5IGJlIGRlZmluZWQg
YnkgdGhlIG5ldHdvcmstaW5zdGFuY2VzDQo+IG1vZGVsLg0KPiA+Pg0KPiA+PiBJbiB0aGUgZGlz
Y3Vzc2lvbnMgdGhhdCBJIGhhZCB3aXRoIExvdSwgc29tZSBvZiB0aGVtIGF0IHRoZSBtaWMsIHNv
bWUNCj4gPj4gYWZ0ZXJ3YXJkcywgTG91IGNsYXJpZmllZCB0aGF0IGl0IHF1aXRlIHBsYXVzaWJs
ZSB0aGF0IFZSRnMgbWF5IG9ubHkNCj4gPj4gYmUgc3VwcG9ydGVkIGJ5IHNvbWUgcHJvdG9jb2xz
IG9uIGEgZGV2aWNlIGFuZCBub3QgYWxsLCBhbmQgaGVuY2UgdGhlDQo+ID4+IHNvbHV0aW9uIG9m
IGhhdmluZyBhICJWUkYiIGZlYXR1cmUgcGVyIHByb3RvY29sIHNlZW1zIGxpa2UgdGhlIHJpZ2h0
DQo+ID4+IHNvbHV0aW9uLg0KPiA+Pg0KPiA+PiBJIHRoaW5rIHRoYXQgSSB3b3VsZCBjYWxsIHRo
ZSBmZWF0dXJlICJzdXBwb3J0cy12cmYiIHJhdGhlciB0aGFuICJ2cmYiLg0KPiA+Pg0KPiA+PiBU
aGFua3MsDQo+ID4+IFJvYg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgRXJpYw0KPiA+Pg0K
PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgKkZyb206Kk5ldGNv
bmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4gPj4g
ICAgICpFcmljIFZvaXQgKGV2b2l0KQ0KPiA+PiAgICAgKlNlbnQ6KiBUdWVzZGF5LCBOb3ZlbWJl
ciAxNCwgMjAxNyAxMDoyMyBQTQ0KPiA+PiAgICAgKlRvOiogUm9iZXJ0IFdpbHRvbiAtWCAocndp
bHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKQ0KPiA+PiAgICAgPHJ3aWx0b25AY2lzY28u
Y29tPiA8bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KPiA+PiAg
ICAgPG1haWx0bzpuZXRjb25mQGlldGYub3JnPjsgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l
dD4NCj4gPj4gICAgIDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4NCj4gPj4gICAgICpTdWJqZWN0
OiogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJG
DQo+ID4+ICAgICBvZiBjb25maWd1cmVkIHN1YnNjcmlwdGlvbj8NCj4gPj4NCj4gPj4NCj4gPj4N
Cj4gPj4gICAgIEFncmVlIGl0IGlzIGEgZ2VuZXJpYyBwcm9ibGVtLg0KPiA+Pg0KPiA+Pg0KPiA+
Pg0KPiA+PiAgICAgSSB3b3VsZCBkZWZlciB0byBMb3UgYW5kIHRoZSBvdGhlciBhdXRob3JzIG9m
DQo+ID4+ICAgICBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsIGFzIHRoaXMgd291bGQgYmUgYSBm
YWlybHkgc2lnbmlmaWNhbnQNCj4gPj4gICAgIGNoYW5nZS4NCj4gPj4NCj4gPj4NCj4gPj4NCj4g
Pj4gICAgIEVyaWMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgICpGcm9tOipSb2JlcnQgV2ls
dG9uLCBOb3ZlbWJlciAxNCwgMjAxNyA3OjU4IFBNDQo+ID4+DQo+ID4+ICAgICBIaSBFcmljLCBM
b3UsDQo+ID4+DQo+ID4+ICAgICBUaGlzIHNlZW1zIHRvIGJlIGEgZ2VuZXJpYyBwcm9ibGVtLg0K
PiA+Pg0KPiA+PiAgICAgQ291bGQgdGhlIFZSRiBsZWFmcmVmIG5hbWUgZGVwZW5kZW5jeSBpc3N1
ZSBiZSBzb2x2ZWQgd2l0aCBhbg0KPiA+PiAgICAgaWYtZmVhdHVyZSBzdGF0ZW1lbnQ/Lg0KPiA+
Pg0KPiA+PiAgICAgSS5lLmNvdWxkIHRoZSBuZXR3b3JrIGluc3RhbmNlIGRyYWZ0IGRlZmluZSBh
IHNlcGFyYXRlIFlBTkcNCj4gPj4gICAgIG1vZHVsZSAod2l0aCBubyBkZXBlbmRlbmNpZXMpIHRo
YXQgZGVmaW5lcyBhICJWUkYiIGZlYXR1cmUuDQo+ID4+DQo+ID4+ICAgICBBbGwgdGhlIFZSRiBy
ZWZlcmVuY2VzIChpZGVhbGx5IGlmIGFsbCBJRVRGIFlBTkcgbW9kdWxlcyB0aGF0IG1heQ0KPiA+
PiAgICAgb3B0aW9uYWxseSBkZXBlbmQgb24gVlJGcykgY291bGQgYmUgbGVhZi1yZWZzIHRvDQo+
ID4+ICAgICAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lIGJ1dCBwcmVk
aWNhdGVkIHdpdGggYW4NCj4gPj4gICAgIGlmLWZlYXR1cmUgIm5pOnZyZiIuDQo+ID4+DQo+ID4+
ICAgICBIZW5jZSBpZiBhIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBpdCBkb2Vz
bid0IGltcGxlbWVudA0KPiA+PiAgICAgdGhlICJ2cmYiIGZlYXR1cmUsIHNvIGl0IGRvZXNuJ3Qg
aGF2ZSB0byBpbXBsZW1lbnQgdGhlIGZ1bGwNCj4gPj4gICAgIG5ldHdvcmsgaW5zdGFuY2VzIG1v
ZHVsZSwgb3Igc2NoZW1hIG1vdW50Lg0KPiA+Pg0KPiA+PiAgICAgVGhhbmtzLA0KPiA+PiAgICAg
Um9iDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAgICBPbiAxNS8xMS8yMDE3IDA4OjQ1LCBFcmlj
IFZvaXQgKGV2b2l0KSB3cm90ZToNCj4gPj4NCj4gPj4gICAgICAgICBJbiB0aGUgV0cgc2Vzc2lv
biB0b21vcnJvdywgSSBhbSBob3BpbmcgdG8gZ2V0IOKAnGh1bSBmZWVkYmFja+KAnQ0KPiBvbjoN
Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2Ny
aWJlZC1ub3RpZmljYXRpb25zDQo+ID4+DQo+ID4+ICAgICAgICAgaHR0cHM6Ly9naXRodWIuY29t
L25ldGNvbmYtd2cvcmZjNTI3N2Jpcy9pc3N1ZXMvNQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAg
ICAgICAgIFRoZSB0d28gY2hvaWNlcyBleHBvc2VkIGR1cmluZyB0aGUgdHdvIHdlZWsgcmV2aWV3
IGZvciBob3cgdG8NCj4gPj4gICAgICAgICByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1
cmVkIHN1YnNjcmlwdGlvbiB3ZXJlOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICgx
KSBMZWFmcmVmIHRvIOKAnGlldGYtbmV0d29yay1pbnN0YW5jZeKAnQ0KPiA+PiAgICAgICAgIC9u
ZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUNCj4gPj4NCj4gPj4gICAgICAg
ICDCt8KgwqDCoMKgwqDCoMKgIENyZWF0ZXMgZGVwZW5kZW5jeSBvbiBzY2hlbWEgbW91bnQgZm9y
IHN1YnNjcmlwdGlvbnMuDQo+ID4+DQo+ID4+ICAgICAgICAgwrfCoMKgwqDCoMKgwqDCoCBTb3Vy
Y2UgVlJGIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxpdHksIGJ1dCBwdWJsaXNoZXJzDQo+ID4+ICAg
ICAgICAgdGhhdCBkb27igJl0IGNhcmUgYWJvdXQgVlJGcyBtdXN0IHN0aWxsIGltcG9ydC7CoCAo
Tm90ZTogY291bGQNCj4gPj4gICAgICAgICBhbHNvIGF1Z21lbnQgdGhlIGxlYWZyZWYgaW4gYW5v
dGhlciBtb2RlbCwgYnV0IHRoYXQgYWRkcw0KPiA+PiAgICAgICAgIGFub3RoZXIgbGF5ZXIgb2Yg
Y29tcGxleGl0eSkNCj4gPj4NCj4gPj4gICAgICAgICDCt8KgwqDCoMKgwqDCoMKgIGVzdGFibGlz
aGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8NCj4gPj4gICAgICAgICBkcmFmdC1pZXRmLXJ0Z3dnLW5p
LW1vZGVsDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAgICAgICAgKDIpIFVzZSBhIHN0cmluZyB3
aGljaCB3b3VsZCBiZSBwb3B1bGF0ZWQgd2l0aCBleGFjdCBzYW1lDQo+ID4+ICAgICAgICAgbmFt
ZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJlZiBvZiAoMSkNCj4gPj4NCj4gPj4gICAgICAgICDC
t8KgwqDCoMKgwqDCoMKgIFBvc3NpYmxlIHRvIG5hbWUgVlJGIHdoaWNoIGRvZXNu4oCZdCBleGlz
dA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgIFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMg
KDIpLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgIFRoYW5rcywNCj4gPj4NCj4gPj4g
ICAgICAgICBFcmljDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAgICAgICAg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4NCj4g
Pj4gICAgICAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pg0KPiA+PiAgICAgICAgIE5ldGNv
bmZAaWV0Zi5vcmcgPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+Pg0KPiA+PiAgICAgICAg
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+Pg0KPiA+
Pg0KPiA+Pg0KPiA+PiAgICAgLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+DQoNCg==


From nobody Tue Nov 21 05:58:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEC112702E for ; Tue, 21 Nov 2017 05:58:05 -0800 (PST)
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 zGQNKPrl2xGi for ; Tue, 21 Nov 2017 05:58:04 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80EA1201F8 for ; Tue, 21 Nov 2017 05:58:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8244; q=dns/txt; s=iport; t=1511272683; x=1512482283; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Rc8/7cHLopAg/chSgJncczNIrm7X77l9Bw9+QCfCfeA=; b=kBsFdyTIcMwtSiF2Uqn6SsLrBTpvR/Fh3yfHk++6Gq9LSqTFlEpYOGLG lqe8mCnl+vTRx3ejcVXKFEGbyRL/0LG/tdd+1WT1MWryPubyjMcgU+3OR x0hqlVR7T7f64ofABllxyNdrvJcJ9DOdZuYIi8kn1HMyRaGHLKieg7AOG A=;
X-Files: nacm.diff : 2542
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgDhLxRa/xbLJq1bGgEBAwIBAQoBA?= =?us-ascii?q?YQkbieDf4sTkDOWcoIBCh+FHAKFShQBAQEBAQEBAQFrKIUfAQUjZgsOCioCAgJ?= =?us-ascii?q?VBgEMBgIBAYoeEKh7gieLAwEBAQEBAQEBAQEBAQEBAQEBAQEQD4M0g1yBaSmDA?= =?us-ascii?q?oUDAi2CfoJjBYpMiRqFPIkchEmCKIEBjRqMBIdJjkGHdIE6NiKBdDQhCB0VH4M?= =?us-ascii?q?OCYRWQTaLbgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,432,1505779200"; d="diff'?scan'208"; a="345273"
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; 21 Nov 2017 13:58:01 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vALDw1f8008315; Tue, 21 Nov 2017 13:58:01 GMT
To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org
References:   <20171121.105855.1884534168363830366.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <372d5b0f-5da5-3a2e-aa41-bfcd87e0f96f@cisco.com>
Date: Tue, 21 Nov 2017 13:58:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171121.105855.1884534168363830366.mbj@tail-f.com>
Content-Type: multipart/mixed; boundary="------------220DFA6B7225BC9351FCD2AB"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] NACM and "when" statements
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 13:58:06 -0000

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

Proposed text below.


On 21/11/2017 09:58, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> Hi,
>>
>>
>> On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton  wrote:
>>
>>> Hi Andy, Martin,
>>>
>>> I've got a question about 'when' statement handling related to NACM.
>>>
>>> Due to when statements, it is possible that a client could implicitly
>>> cause a change to a part of the data tree that they have no write access to
>>> because they cause a when condition to evaluate to a different answer.  Am
>>> I correct in presuming that this implicit change is allowed?
>>>
>>> E.g. in the following example, a user may only have write access to "baz"
>>> but not "bar". If they create "baz" then that may implicitly cause "bar" to
>>> be deleted.  Further, even if this implicit delete to "bar" is allowed, I
>>> presume that the equivalent explicit change or creating "baz" and deleting
>>> "bar" would still be rejected because there is no explicit write access to
>>> bar.
>>>
>>> container foo {
>>>    leaf bar {
>>>     when "not(../baz)";
>>>    }
>>>    leaf baz {
>>>    }
>>> }
>>>
>>> Should this be mentioned in the NACM draft at all?  I'm not convinced that
>>> the draft makes the correct behaviour for handling 'when' statements
>>> obvious.
>>>
>>> Similar considerations could also apply when writing to choice statements.
>>>
>>>
>> I just confirmed that our server does not enforce nacm:default-deny-all for
>> the "when-stmt" node.
>> NACM rules say "user X is allowed to write /foo/baz" and nothing about
>> /foo/baz side-effects.
> Our implementation works the same way, and I agree this is reasonable
> behavior.  NACM controls access to the operations, not the side
> effects.
OK, so I propose the following NEW additions to rfc6536bis:


Added to the end of section "1.2.  Changes Since RFC 6536":

    The data node access behavior for path matches has been clarified to
    also include matching descendant nodes of the specified path.

    The  operation access rights behavior has been clarified
    to indicate that write access is not required for data nodes that are
    implicitly modified through side-effects (such as the evaluation of
    YANG when-stmts, or data nodes implicitly deleted when creating a
    data node under a different branch under a YANG choice-stmt).

Added to the end of section "3.2.5.   Operation":

    An  operation may cause data nodes to be implicitly
    created or deleted as an implicit side-effect of a requested
    operation.  For example, a YANG when-stmt expression may evaluate to
    a different result, causing data nodes to be deleted, or created with
    default values; or if a data node is created under one branch of a
    YANG choice-stmt, then all data nodes under the other branches are
    implicitly removed.  No NACM access rights are required on any data
    nodes that are implicitly changed as a side effect of another allowed
    operation.

Added after paragraph 4 of "3.7.2.  General Configuration Issues":

    It is possible that the data model definition itself (e.g., YANG
    when-stmt or choice-stmt) will allow a session to implicitly create
    or delete nodes that the session does not have write access to as an
    implicit side effect from the processing of an allowed 
    operation.

In case it is useful, git diff for the above change is also attached.

Thanks,
Rob


>
>
> /martin
>
>
>> YANG says nodes exist only if the when-stmt is true and nothing about how
>> they change
>> from true to false. I don't think access control is mentioned in either RFC
>> for this corner-case.
>>
>> Perhaps more security consideration text is needed, warning that any nodes
>> that are deleted
>> by the server because of false when-stmt evaluation are exempt from access
>> control.
>>
>> It would be a significant change to implementations to enforce delete
>> permissions on
>> when-stmt and choice-stmt automatic node removal. This can also apply to
>> automatic
>> creation of default nodes (when-stmt evaluates true, was false).
>>
>>
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>> Andy
> .
>


--------------220DFA6B7225BC9351FCD2AB
Content-Type: text/plain; charset=UTF-8;
 name="nacm.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="nacm.diff"

ZGlmZiAtLWdpdCBhL25ldGNvbmYtYWNjZXNzLWNvbnRyb2wueG1sLmluIGIvbmV0Y29uZi1h
Y2Nlc3MtY29udHJvbC54bWwuaW4KaW5kZXggNDAyYmY3Yy4uNmM1YWJkZiAxMDA2NDQKLS0t
IGEvbmV0Y29uZi1hY2Nlc3MtY29udHJvbC54bWwuaW4KKysrIGIvbmV0Y29uZi1hY2Nlc3Mt
Y29udHJvbC54bWwuaW4KQEAgLTI4Niw2ICsyODYsMjAgQEAKICAgICAgICAgc28gYSBzaW1w
bGUgbWFwcGluZyB0byB0aGUgZXhpc3RpbmcgTkFDTSBwcm9jZWR1cmVzCiAgICAgICAgIGFu
ZCBkYXRhIG1vZGVsIGlzIHBvc3NpYmxlLgogICAgICAgPC90PgorICAgICAgPHQ+CisgICAg
ICAgIFRoZSBkYXRhIG5vZGUgYWNjZXNzIGJlaGF2aW9yIGZvciBwYXRoIG1hdGNoZXMgaGFz
IGJlZW4KKyAgICAgICAgY2xhcmlmaWVkIHRvIGFsc28gaW5jbHVkZSBtYXRjaGluZyBkZXNj
ZW5kYW50IG5vZGVzIG9mIHRoZQorICAgICAgICBzcGVjaWZpZWQgcGF0aC4KKyAgICAgIDwv
dD4KKyAgICAgIDx0PgorICAgICAgICBUaGUgJmx0O2VkaXQtY29uZmlnJmd0OyBvcGVyYXRp
b24gYWNjZXNzIHJpZ2h0cyBiZWhhdmlvciBoYXMKKyAgICAgICAgYmVlbiBjbGFyaWZpZWQg
dG8gaW5kaWNhdGUgdGhhdCB3cml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkCisgICAgICAg
IGZvciBkYXRhIG5vZGVzIHRoYXQgYXJlIGltcGxpY2l0bHkgbW9kaWZpZWQgdGhyb3VnaAor
ICAgICAgICBzaWRlLWVmZmVjdHMgKHN1Y2ggYXMgdGhlIGV2YWx1YXRpb24gb2YgWUFORyB3
aGVuLXN0bXRzLCBvcgorICAgICAgICBkYXRhIG5vZGVzIGltcGxpY2l0bHkgZGVsZXRlZCB3
aGVuIGNyZWF0aW5nIGEgZGF0YSBub2RlIHVuZGVyCisgICAgICAgIGEgZGlmZmVyZW50IGJy
YW5jaCB1bmRlciBhIFlBTkcgY2hvaWNlLXN0bXQpLgorCisgICAgICA8L3Q+CiAgICAgPC9z
ZWN0aW9uPgogICA8L3NlY3Rpb24+CiAKQEAgLTk5MCw2ICsxMDA0LDE4IEBACiAgICAgICAg
ICAgYmUgZXhwb3NlZCBpbiBhbnkgJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudHMKICAgICAg
ICAgICB3aXRoaW4gdGhlIHJlcGx5LgogICAgICAgICA8L3Q+CisgICAgICAgIDx0PgorICAg
ICAgICAgIEFuICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uIG1heSBjYXVzZSBkYXRh
IG5vZGVzIHRvIGJlCisgICAgICAgICAgaW1wbGljaXRseSBjcmVhdGVkIG9yIGRlbGV0ZWQg
YXMgYW4gaW1wbGljaXQgc2lkZS1lZmZlY3Qgb2YKKyAgICAgICAgICBhIHJlcXVlc3RlZCBv
cGVyYXRpb24uICBGb3IgZXhhbXBsZSwgYSBZQU5HIHdoZW4tc3RtdAorICAgICAgICAgIGV4
cHJlc3Npb24gbWF5IGV2YWx1YXRlIHRvIGEgZGlmZmVyZW50IHJlc3VsdCwgY2F1c2luZyBk
YXRhCisgICAgICAgICAgbm9kZXMgdG8gYmUgZGVsZXRlZCwgb3IgY3JlYXRlZCB3aXRoIGRl
ZmF1bHQgdmFsdWVzOyBvciBpZiBhCisgICAgICAgICAgZGF0YSBub2RlIGlzIGNyZWF0ZWQg
dW5kZXIgb25lIGJyYW5jaCBvZiBhIFlBTkcgY2hvaWNlLXN0bXQsCisgICAgICAgICAgdGhl
biBhbGwgZGF0YSBub2RlcyB1bmRlciB0aGUgb3RoZXIgYnJhbmNoZXMgYXJlIGltcGxpY2l0
bHkKKyAgICAgICAgICByZW1vdmVkLiAgTm8gTkFDTSBhY2Nlc3MgcmlnaHRzIGFyZSByZXF1
aXJlZCBvbiBhbnkgZGF0YQorICAgICAgICAgIG5vZGVzIHRoYXQgYXJlIGltcGxpY2l0bHkg
Y2hhbmdlZCBhcyBhIHNpZGUgZWZmZWN0IG9mCisgICAgICAgICAgYW5vdGhlciBhbGxvd2Vk
IG9wZXJhdGlvbi4KKyAgICAgICAgPC90PgogICAgICAgPC9zZWN0aW9uPgogCiAgICAgICA8
c2VjdGlvbiB0aXRsZT0iJmx0O2NvcHktY29uZmlnJmd0OyBPcGVyYXRpb24iPgpAQCAtMjA0
Nyw2ICsyMDczLDEzIEBAIG00X2luY2x1ZGUoaWV0Zi1uZXRjb25mLWFjbS55YW5nKQogICAg
ICAgICAgYnkgZXhhbWluaW5nIHRoZSBwcmVzZW5jZSBhbmQgdmFsdWVzIG9mIGRpZmZlcmVu
dCBkYXRhIG5vZGVzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KKyAgICAgICAgIEl0IGlz
IHBvc3NpYmxlIHRoYXQgdGhlIGRhdGEgbW9kZWwgZGVmaW5pdGlvbiBpdHNlbGYgKGUuZy4s
CisgICAgICAgICBZQU5HIHdoZW4tc3RtdCBvciBjaG9pY2Utc3RtdCkgd2lsbCBhbGxvdyBh
IHNlc3Npb24gdG8KKyAgICAgICAgIGltcGxpY2l0bHkgY3JlYXRlIG9yIGRlbGV0ZSBub2Rl
cyB0aGF0IHRoZSBzZXNzaW9uIGRvZXMgbm90CisgICAgICAgICBoYXZlIHdyaXRlIGFjY2Vz
cyB0byBhcyBhbiBpbXBsaWNpdCBzaWRlIGVmZmVjdCBmcm9tIHRoZQorICAgICAgICAgcHJv
Y2Vzc2luZyBvZiBhbiBhbGxvd2VkICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uLgor
ICAgICAgIDwvdD4KKyAgICAgICA8dD4KICAgICAgICAgIFRoZXJlIGlzIGEgcmlzayB0aGF0
IG5vbi1zdGFuZGFyZCBwcm90b2NvbCBvcGVyYXRpb25zLCBvcgogICAgICAgICAgZXZlbiB0
aGUgc3RhbmRhcmQgJmx0O2dldCZndDsgcHJvdG9jb2wgb3BlcmF0aW9uLCBtYXkKICAgICAg
ICAgIHJldHVybiBkYXRhIHRoYXQgImFsaWFzZXMiIG9yICJjb3BpZXMiIHNlbnNpdGl2ZSBk
YXRhCg==
--------------220DFA6B7225BC9351FCD2AB--


From nobody Tue Nov 21 06:37:16 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59936129498 for ; Tue, 21 Nov 2017 06:37:15 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 snb-N8d19hCb for ; Tue, 21 Nov 2017 06:37:12 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 90AB7129493 for ; Tue, 21 Nov 2017 06:37:12 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id E3C471AB263 for ; Tue, 21 Nov 2017 07:37:09 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id ced61w0042SSUrH01ed9Pl; Tue, 21 Nov 2017 07:37:09 -0700
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=AUd_NHdVAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=NEAV23lmAAAA:8 a=XJSIq5p9Wsf27P0wEusA:9 a=wEQTy_7k_ESjaEyy:21 a=pB4oCgtH0J2xwIpo:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22
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=kgD/C8r1cyHwR5dQy/HK6nocZOZv66kmDMNqy5ryIMc=; b=Pfjsz5Ko4LUChbT2wXuS+iSMwt yIr8qEUIfRrU0yPiwMv1aJj5iuWSa35bRMtUciv2NT1ruKhiTWInEfJFcsBG10OndDVMvcGsfsHAY RJQt9yrM8yWCAcBWCP+zlwAVo;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49786 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eH9fd-002snB-Pt; Tue, 21 Nov 2017 07:37:05 -0700
To: "Eric Voit (evoit)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Alexander Clemm , "netconf@ietf.org" 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>   <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net> <72ace49056484d49a0f6eadc42ea49a5@XCH-RTP-013.cisco.com>
From: Lou Berger 
Message-ID: <7845f9fd-9d46-2ec0-b8e8-8593d00b5706@labn.net>
Date: Tue, 21 Nov 2017 09:37:04 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <72ace49056484d49a0f6eadc42ea49a5@XCH-RTP-013.cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
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: 100.15.86.101
X-Exim-ID: 1eH9fd-002snB-Pt
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:49786
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 14:37:15 -0000

Eric,

See below

On 11/21/2017 08:06 AM, Eric Voit (evoit) wrote:
> Hi Lou,
> 
>> From: Lou Berger, November 21, 2017 7:16 AM
>>
>> Taking a step back: what is the purpose of having source-vrf in draft-ietf-
>> netconf-subscribed-notifications?
> 
> There are many uses for this, and not having it is already being seen as a production problem in two separate telemetry environments:
> (1) Being able to push telemetry traffic to one or more collection VRFs which are not exposed in the global routing table.

By "collection VRFs" you mean that the configured receivers are only
reachable within the context of a VRF/NI, right?  If not, I don't think
I follow. I this case, the SN configuration is still server-wide and not
scoped per NI/VRF, right?

> (2) Being able to send routing and switching info relevant to a specific customer VRFs on that customer's VRF.  (I.e., provide traffic counters to a collection IP address/domain for that VRF)

Now we're getting somewhere.  So you also have a use case where SNs are
VRF-specific, right? Does config happen inside the context of the VRF or
the core instance?  Is there a separate logical management instance for
the VRF?

>  
>> From the configuration side, the model seems to allow the configuration of
>> an IP address for  notification-message-origin that doesn't match any
>> configured interface.  Does this really make sense?  Why not just limit
>> configuration to if:interface-ref? 
> 
> The person doing the configuration need have no understanding of the interfaces on the router.  In addition, if the ni-name is the same across routers, the same ni-name can be used across the domain without knowledge of such device specifics.
> 

So this sounds like the provider config policy, right?

>> Doing this eliminates the whole VRF
>> discussion for this model (of course, I'm not saying the discussion won't
>> happen in other contexts).
>>
>> What am I missing?
> 
> This type of configuration is really aimed at a level higher than someone who needs care about topology issues. 

What topology issues?

> They just want something out of the network cloud.   It is quite possible to configure the same subscription info to all devices in a domain without any per-device deviations at all.  (I.e., same configured subscription-id, same filter, same VRF, same period, ...)

So this case would configure vrf but not source IP, right?  Is there a
use case for source ip?

> 
>> Also if you do keep 'source-vrf' I think 'source-ni-name' is more consistent
>> with draft-ietf-rtgwg-ni-model augmentations of if:interface.
> 
> "Ni-name" is more generic because it supports more types of technologies than required at this time.   As no customer is talking about things beyond VRF, installing the more generic name would be an added layer of complexity.

the augmentation to interfaces is called bind-ni-name, as long as you
reference it or ni-name all is good.

Lou
> 
> Eric
>  
>> Lou
>>
>> On 11/21/2017 4:56 AM, Robert Wilton wrote:
>>>
>>> I think that using a feature is better here.  Defining a separate
>>> module for just one leaf seems somewhat like overkill.
>>>
>>> I'm not sure that any compile time dependency on network instances,
>>> and hence schema mount, is really an issue; the more important one to
>>> avoid is the run time dependency on network instances and schema
>>> mount, and both solutions achieve this.
>>>
>>> But I also agree with Juergen's comment that we should be consistent,
>>> and the same approach should be used for other protocols with
>>> conditional dependencies on network instances as well.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 20/11/2017 19:54, Eric Voit (evoit) wrote:
>>>>
>>>> *From:*Alexander Clemm, November 20, 2017 2:46 PM
>>>>
>>>>
>>>>
>>>> Hi Eric,
>>>>
>>>>
>>>>
>>>> I agree that proliferation of modules is a concern, and certainly we
>>>> would not want to run into combinatorial explosions.  However, I
>>>> don’t think this would be the case here - we would not need to
>>>> augment VRF into yang-push also (or yang-push into VRF).  Instead,
>>>> both yang-push and vrf-for-notifications would be augmenting
>>>> subscribed-notifications in parallel.
>>>>
>>>>
>>>>
>>>>   Yes, you are right, with this approach we would end with
>>>> three models rather than four.  But two models is already a lot.
>>>>  And we still set precedence that we end with a new VRF specific
>>>> model every time any YANG model needs a VRF.
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> --- Alex
>>>>
>>>>
>>>>
>>>> *From:*Eric Voit (evoit) [mailto:evoit@cisco.com]
>>>> *Sent:* Monday, November 20, 2017 11:39 AM
>>>> *To:* Alexander Clemm >>> >; Robert Wilton -X (rwilton -
>>>> ENSOFT LIMITED at Cisco) >>> >; netconf@ietf.org
>>>> ; Lou Berger >>> >
>>>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of
>>>> configured subscription?
>>>>
>>>>
>>>>
>>>> I agree this is more elegant if we look just at
>>>> subscribed-notifications.   However extrapolating this means that we
>>>> have a duplicate YANG module every time we have a VRF.   And in our
>>>> case when we augment yang-push, which model do we start from?
>>>>
>>>>
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> *From:*Alexander Clemm [mailto:alexander.clemm@huawei.com]
>>>> *Sent:* Monday, November 20, 2017 2:27 PM
>>>> *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>>>> >; Eric Voit (evoit)
>>>> >; netconf@ietf.org
>>>> ; Lou Berger >>> >
>>>> *Subject:* RE: [Netconf] Issue SN #5: How to represent Source VRF of
>>>> configured subscription?
>>>>
>>>>
>>>>
>>>> I am fine with that change, but wanted to bring up one additional
>>>> option that was also briefly mentioned in the room which strikes me
>>>> as perhaps a bit more elegant.  That is the option to use
>>>> augmentation.  In that case, source-vrf and the import statement
>>>> would simply be omitted. Instead, a new module would be created (e.g.
>>>> ietf-vrf-for-subscribed-notifications), which contains the import
>>>> statement and two augments statements to augment the source-vrf into
>>>> the existing module.
>>>>
>>>>
>>>>
>>>> --- Alex
>>>>
>>>>
>>>>
>>>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>>>> *Robert Wilton
>>>> *Sent:* Friday, November 17, 2017 10:46 AM
>>>> *To:* Eric Voit (evoit) >;
>>>> netconf@ietf.org ; Lou Berger
>>>> >
>>>> *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF of
>>>> configured subscription?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 17/11/2017 18:17, Eric Voit (evoit) wrote:
>>>>
>>>>     I would like to continue the discussion on this topic from our
>>>>     session.   I think we came to agreement among the attendees.
>>>>     Hopefully this thread can confirm, or refine as need.
>>>>
>>>>
>>>>
>>>>     First let’s look at Robert’s proposal below:
>>>>
>>>>     There are lots of good elements in Robert’s proposal below, but
>>>>     it isn’t up to our WG to determine the proper structure of the
>>>>     network-instance-model.   Authors of that model were in the room,
>>>>     and are aware that YANG model developers from outside would
>>>>     welcome a partitioning which decouples any linkages to
>>>>     schema-mount when all that is needed is to identify a VRF by name.
>>>>
>>>>
>>>>
>>>>     Looking at what we can control, discussed in the room was the
>>>>     following change to subscribed-notifications:
>>>>
>>>>     1.      import “ietf-network-instance”
>>>>
>>>>     2.      create if-feature “VRF”.
>>>>
>>>>     3.      apply feature “VRF” to object “source-VRF”
>>>>
>>>>     4.      Leafref to “source-VRF” to validate against the
>>>>     network-instance model’s
>>>> /network-instances/network-instance/name.
>>>>
>>>>
>>>>
>>>>     This is the current proposal.  Are there are
>>>>     concerns/objections/refinements?
>>>>
>>>>
>>>> No concerns, but perhaps one trivial refinement.
>>>>
>>>> I had mistakenly thought that a device would either support VRFs for
>>>> all protocols or none, hence my suggestion to have a single "VRF"
>>>> feature, which would naturally be defined by the network-instances
>> model.
>>>>
>>>> In the discussions that I had with Lou, some of them at the mic, some
>>>> afterwards, Lou clarified that it quite plausible that VRFs may only
>>>> be supported by some protocols on a device and not all, and hence the
>>>> solution of having a "VRF" feature per protocol seems like the right
>>>> solution.
>>>>
>>>> I think that I would call the feature "supports-vrf" rather than "vrf".
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>     Eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
>>>>     *Eric Voit (evoit)
>>>>     *Sent:* Tuesday, November 14, 2017 10:23 PM
>>>>     *To:* Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>>>>      ; netconf@ietf.org
>>>>     ; Lou Berger 
>>>>     
>>>>     *Subject:* Re: [Netconf] Issue SN #5: How to represent Source VRF
>>>>     of configured subscription?
>>>>
>>>>
>>>>
>>>>     Agree it is a generic problem.
>>>>
>>>>
>>>>
>>>>     I would defer to Lou and the other authors of
>>>>     draft-ietf-rtgwg-ni-model as this would be a fairly significant
>>>>     change.
>>>>
>>>>
>>>>
>>>>     Eric
>>>>
>>>>
>>>>
>>>>     *From:*Robert Wilton, November 14, 2017 7:58 PM
>>>>
>>>>     Hi Eric, Lou,
>>>>
>>>>     This seems to be a generic problem.
>>>>
>>>>     Could the VRF leafref name dependency issue be solved with an
>>>>     if-feature statement?.
>>>>
>>>>     I.e.could the network instance draft define a separate YANG
>>>>     module (with no dependencies) that defines a "VRF" feature.
>>>>
>>>>     All the VRF references (ideally if all IETF YANG modules that may
>>>>     optionally depend on VRFs) could be leaf-refs to
>>>>     /network-instances/network-instance/name but predicated with an
>>>>     if-feature "ni:vrf".
>>>>
>>>>     Hence if a device doesn't support VRFs, then it doesn't implement
>>>>     the "vrf" feature, so it doesn't have to implement the full
>>>>     network instances module, or schema mount.
>>>>
>>>>     Thanks,
>>>>     Rob
>>>>
>>>>
>>>>
>>>>     On 15/11/2017 08:45, Eric Voit (evoit) wrote:
>>>>
>>>>         In the WG session tomorrow, I am hoping to get “hum feedback”
>> on:
>>>>
>>>>
>>>>
>>>>         draft-ietf-netconf-subscribed-notifications
>>>>
>>>>         https://github.com/netconf-wg/rfc5277bis/issues/5
>>>>
>>>>
>>>>
>>>>         The two choices exposed during the two week review for how to
>>>>         represent Source VRF of configured subscription were:
>>>>
>>>>
>>>>
>>>>         (1) Leafref to “ietf-network-instance”
>>>>         /network-instances/network-instance/name
>>>>
>>>>         ·        Creates dependency on schema mount for subscriptions.
>>>>
>>>>         ·        Source VRF is an optional capability, but publishers
>>>>         that don’t care about VRFs must still import.  (Note: could
>>>>         also augment the leafref in another model, but that adds
>>>>         another layer of complexity)
>>>>
>>>>         ·        establishes model dependency to
>>>>         draft-ietf-rtgwg-ni-model
>>>>
>>>>
>>>>
>>>>         (2) Use a string which would be populated with exact same
>>>>         name as would be in the leafref of (1)
>>>>
>>>>         ·        Possible to name VRF which doesn’t exist
>>>>
>>>>
>>>>
>>>>         The current draft does (2).
>>>>
>>>>
>>>>
>>>>         Thanks,
>>>>
>>>>         Eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>
>>>>         Netconf mailing list
>>>>
>>>>         Netconf@ietf.org 
>>>>
>>>>         https://www.ietf.org/mailman/listinfo/netconf
>>>>
>>>>
>>>>
>>>>     .
>>>>
>>>>
>>>>
>>>
> 


From nobody Tue Nov 21 08:30:34 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB77129ACC for ; Tue, 21 Nov 2017 08:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tT6onAVozkO for ; Tue, 21 Nov 2017 08:30:30 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FD2129AD2 for ; Tue, 21 Nov 2017 08:30:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20560; q=dns/txt; s=iport; t=1511281829; x=1512491429; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Yrsu798PsmpysDucWK30qixEHQwpRmJTsvQmTfctaXw=; b=kJLkL9f/Rwv6h8FsRCATwiWYhodtAt//NZ8zJEShz9tjX7hfqpJjLCMS clkG/CWhwvGx/Eez9t4L5EON9t+9Tu2qpxMiuC8SlSoNmt0Aik1V9TsMl HxwH2cExRZRtl/uTtUCRdOxfvyP3rTzYrwT3DBndiAtRqEtUCawc5B/vn E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAAC6UxRa/4YNJK1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuJweDeIofjyqBfZZighEKGAuEA0ZPAhqEbz8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQMBAQEhEToQCwIBBgIOAwQBAQECAgkaAwICAiULFAEICAIEA?= =?us-ascii?q?RIIE4l/CBCKdJ1rgieKdwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CJYIHgVW?= =?us-ascii?q?FFIRwBAEQHRAjgluCYwWRdJBKAodwjRGTVox0iRQCERkBgTkBHzmBdHoVSYJkg?= =?us-ascii?q?xGBTneJJwEBJQeBBYEUAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208";a="326374066"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Nov 2017 16:30:26 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vALGUQiP002325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Nov 2017 16:30:26 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 21 Nov 2017 11:30:26 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 11:30:26 -0500
From: "Eric Voit (evoit)" 
To: Lou Berger , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Alexander Clemm , "netconf@ietf.org" 
Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAJhO04AACinC0P//tAyAgABTJJCAAJppAIAAJx6AgABLagD//9vuAIAAPCsw
Date: Tue, 21 Nov 2017 16:30:25 +0000
Message-ID: <6e6cf4edb48441fbadb5e19b36d7a2ca@XCH-RTP-013.cisco.com>
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>   <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net> <72ace49056484d49a0f6eadc42ea49a5@XCH-RTP-013.cisco.com> <7845f9fd-9d46-2ec0-b8e8-8593d00b5706@labn.net>
In-Reply-To: <7845f9fd-9d46-2ec0-b8e8-8593d00b5706@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 16:30:33 -0000

SGkgTG91LA0KDQo+IEZyb206IExvdSBCZXJnZXIsIE5vdmVtYmVyIDIxLCAyMDE3IDk6MzcgQU0N
Cj4gDQo+IEVyaWMsDQo+IA0KPiBTZWUgYmVsb3cNCj4gDQo+IE9uIDExLzIxLzIwMTcgMDg6MDYg
QU0sIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+IEhpIExvdSwNCj4gPg0KPiA+PiBGcm9t
OiBMb3UgQmVyZ2VyLCBOb3ZlbWJlciAyMSwgMjAxNyA3OjE2IEFNDQo+ID4+DQo+ID4+IFRha2lu
ZyBhIHN0ZXAgYmFjazogd2hhdCBpcyB0aGUgcHVycG9zZSBvZiBoYXZpbmcgc291cmNlLXZyZiBp
bg0KPiA+PiBkcmFmdC1pZXRmLSBuZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucz8NCj4g
Pg0KPiA+IFRoZXJlIGFyZSBtYW55IHVzZXMgZm9yIHRoaXMsIGFuZCBub3QgaGF2aW5nIGl0IGlz
IGFscmVhZHkgYmVpbmcgc2VlbiBhcyBhDQo+IHByb2R1Y3Rpb24gcHJvYmxlbSBpbiB0d28gc2Vw
YXJhdGUgdGVsZW1ldHJ5IGVudmlyb25tZW50czoNCj4gPiAoMSkgQmVpbmcgYWJsZSB0byBwdXNo
IHRlbGVtZXRyeSB0cmFmZmljIHRvIG9uZSBvciBtb3JlIGNvbGxlY3Rpb24gVlJGcw0KPiB3aGlj
aCBhcmUgbm90IGV4cG9zZWQgaW4gdGhlIGdsb2JhbCByb3V0aW5nIHRhYmxlLg0KPiANCj4gQnkg
ImNvbGxlY3Rpb24gVlJGcyIgeW91IG1lYW4gdGhhdCB0aGUgY29uZmlndXJlZCByZWNlaXZlcnMg
YXJlIG9ubHkNCj4gcmVhY2hhYmxlIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIFZSRi9OSSwgcmln
aHQ/ICBJZiBub3QsIEkgZG9uJ3QgdGhpbmsgSSBmb2xsb3cuDQo+IEkgdGhpcyBjYXNlLCB0aGUg
U04gY29uZmlndXJhdGlvbiBpcyBzdGlsbCBzZXJ2ZXItd2lkZSBhbmQgbm90IHNjb3BlZCBwZXIN
Cj4gTkkvVlJGLCByaWdodD8NCg0KWWVzIHRvIGJvdGguICAgSGVyZSB3ZSBoYXZlIGEgVGVsZW1l
dHJ5IFNlcnZlciBnYXRoZXJpbmcgcHJldHR5IG11Y2ggYW55dGhpbmcgYWJvdXQgYSBzZXQgb2Yg
bmV0d29yayBkZXZpY2VzLCBidXQgc2VuZGluZyB0aGUgdGVsZW1ldHJ5IHRyYWZmaWMgb3V0IG9u
IGEgZGVkaWNhdGVkIG1hbmFnZW1lbnQgVlJGLg0KIA0KPiA+ICgyKSBCZWluZyBhYmxlIHRvIHNl
bmQgcm91dGluZyBhbmQgc3dpdGNoaW5nIGluZm8gcmVsZXZhbnQgdG8gYQ0KPiA+IHNwZWNpZmlj
IGN1c3RvbWVyIFZSRnMgb24gdGhhdCBjdXN0b21lcidzIFZSRi4gIChJLmUuLCBwcm92aWRlIHRy
YWZmaWMNCj4gPiBjb3VudGVycyB0byBhIGNvbGxlY3Rpb24gSVAgYWRkcmVzcy9kb21haW4gZm9y
IHRoYXQgVlJGKQ0KPiANCj4gTm93IHdlJ3JlIGdldHRpbmcgc29tZXdoZXJlLiAgU28geW91IGFs
c28gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIFNOcyBhcmUNCj4gVlJGLXNwZWNpZmljLCByaWdodD8g
RG9lcyBjb25maWcgaGFwcGVuIGluc2lkZSB0aGUgY29udGV4dCBvZiB0aGUgVlJGIG9yIHRoZQ0K
PiBjb3JlIGluc3RhbmNlPyAgSXMgdGhlcmUgYSBzZXBhcmF0ZSBsb2dpY2FsIG1hbmFnZW1lbnQg
aW5zdGFuY2UgZm9yIHRoZQ0KPiBWUkY/DQoNClRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBzdWJz
Y3JpcHRpb24gaXMgaW4gdGhlIGNvcmUgaW5zdGFuY2UuICAgSSBoYXZlIG5vdCB5ZXQgaGVhcmQg
YW55IHJlcXVpcmVtZW50cyBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIHVuZGVyIGEgVlJG
IGluc3RhbmNlLg0KDQo+ID4NCj4gPj4gRnJvbSB0aGUgY29uZmlndXJhdGlvbiBzaWRlLCB0aGUg
bW9kZWwgc2VlbXMgdG8gYWxsb3cgdGhlDQo+ID4+IGNvbmZpZ3VyYXRpb24gb2YgYW4gSVAgYWRk
cmVzcyBmb3LCoCBub3RpZmljYXRpb24tbWVzc2FnZS1vcmlnaW4gdGhhdA0KPiA+PiBkb2Vzbid0
IG1hdGNoIGFueSBjb25maWd1cmVkIGludGVyZmFjZS7CoCBEb2VzIHRoaXMgcmVhbGx5IG1ha2Ug
c2Vuc2U/DQo+ID4+IFdoeSBub3QganVzdCBsaW1pdCBjb25maWd1cmF0aW9uIHRvIGlmOmludGVy
ZmFjZS1yZWY/DQo+ID4NCj4gPiBUaGUgcGVyc29uIGRvaW5nIHRoZSBjb25maWd1cmF0aW9uIG5l
ZWQgaGF2ZSBubyB1bmRlcnN0YW5kaW5nIG9mIHRoZQ0KPiBpbnRlcmZhY2VzIG9uIHRoZSByb3V0
ZXIuICBJbiBhZGRpdGlvbiwgaWYgdGhlIG5pLW5hbWUgaXMgdGhlIHNhbWUgYWNyb3NzDQo+IHJv
dXRlcnMsIHRoZSBzYW1lIG5pLW5hbWUgY2FuIGJlIHVzZWQgYWNyb3NzIHRoZSBkb21haW4gd2l0
aG91dA0KPiBrbm93bGVkZ2Ugb2Ygc3VjaCBkZXZpY2Ugc3BlY2lmaWNzLg0KPiA+DQo+IA0KPiBT
byB0aGlzIHNvdW5kcyBsaWtlIHRoZSBwcm92aWRlciBjb25maWcgcG9saWN5LCByaWdodD8NCg0K
RGVwZW5kaW5nIG9uIHdoYXQgeW91IG1lYW4gYnkgdGhhdCwgSSBiZWxpZXZlIHRoZSBhbnN3ZXIg
aXMgWWVzLiAgVGhlIGNvbmZpZ3VyYXRpb24gcG9saWN5IGlzIHRvIHNlbmQgdG8gYW4gSVAgYWRk
cmVzcyBvbiB0aGlzIFZSRi4gICBBbmQgZm9yIG1hbmFnZW1lbnQgc2ltcGxpZmljYXRpb24vc2Vj
dXJpdHksIHdlIGFyZSBub3QgYWxsb3dpbmcgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIHRvIGhhdmUg
aW5kZXBlbmRlbnQgcmVjZWl2ZXJzIGxvY2F0ZWQgaW4gZGlmZmVyZW50IFZSRnMuDQogDQo+ID4+
IERvaW5nIHRoaXMgZWxpbWluYXRlcyB0aGUgd2hvbGUgVlJGDQo+ID4+IGRpc2N1c3Npb24gZm9y
IHRoaXMgbW9kZWwgKG9mIGNvdXJzZSwgSSdtIG5vdCBzYXlpbmcgdGhlIGRpc2N1c3Npb24NCj4g
Pj4gd29uJ3QgaGFwcGVuIGluIG90aGVyIGNvbnRleHRzKS4NCj4gPj4NCj4gPj4gV2hhdCBhbSBJ
IG1pc3Npbmc/DQo+ID4NCj4gPiBUaGlzIHR5cGUgb2YgY29uZmlndXJhdGlvbiBpcyByZWFsbHkg
YWltZWQgYXQgYSBsZXZlbCBoaWdoZXIgdGhhbiBzb21lb25lDQo+IHdobyBuZWVkcyBjYXJlIGFi
b3V0IHRvcG9sb2d5IGlzc3Vlcy4NCj4gDQo+IFdoYXQgdG9wb2xvZ3kgaXNzdWVzPw0KDQpUb3Bv
bG9neSBpc3N1ZXMgd2FzIHNob3J0LWhhbmQgZm9yIG5ldHdvcmtpbmcgc3BlY2lmaWNzLiAgTGV0
J3Mgc2F5IHRoZSBzdWJzY3JpcHRpb24gaXMganVzdCBmb3IgQ1BVIFRlbXBlcmF0dXJlLCBvciBm
b3IgY29uZmlndXJlZCBrZXlzLCBvciBmb3IgcnVubmluZyBwcm9jZXNzZXMsIGV0Yy4uLiAgIElu
IHRoaXMgY2FzZSwgdGhlcmUgaXMgbm8gbmVlZCB0byBjYXJlIGFib3V0IGludGVyZmFjZXMsIGxp
bmsgc3RhdHVzLCBhZGphY2VuY2llcywgZXRjLg0KDQo+ID4gVGhleSBqdXN0IHdhbnQgc29tZXRo
aW5nIG91dCBvZiB0aGUgbmV0d29yayBjbG91ZC4gICBJdCBpcyBxdWl0ZSBwb3NzaWJsZQ0KPiB0
byBjb25maWd1cmUgdGhlIHNhbWUgc3Vic2NyaXB0aW9uIGluZm8gdG8gYWxsIGRldmljZXMgaW4g
YSBkb21haW4gd2l0aG91dA0KPiBhbnkgcGVyLWRldmljZSBkZXZpYXRpb25zIGF0IGFsbC4gIChJ
LmUuLCBzYW1lIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLWlkLCBzYW1lDQo+IGZpbHRlciwgc2Ft
ZSBWUkYsIHNhbWUgcGVyaW9kLCAuLi4pDQo+IA0KPiBTbyB0aGlzIGNhc2Ugd291bGQgY29uZmln
dXJlIHZyZiBidXQgbm90IHNvdXJjZSBJUCwgcmlnaHQ/ICBJcyB0aGVyZSBhIHVzZSBjYXNlDQo+
IGZvciBzb3VyY2UgaXA/DQoNClllcy4gIEF0IGxlYXN0IG9uZSBsYXJnZSBkYXRhIGNlbnRlciBj
dXN0b21lciBoYXMgd2FudGVkIHRvIHVzZSBzb3VyY2UtSVAgdG8gYWxsb3cgZGlmZmVyZW50aWF0
aW9uIG9mIGNvbnRlbnQgb24gdGhlIFdBTi4gICBUaGlzIGlzIHByZXN1bWFibHkgZm9yIFFvUyBw
dXJwb3Nlcy4gICBQZXJzb25hbGx5IEkgd291bGQgcmF0aGVyIHVzZSBvdGhlciBRb1MgY29uc3Ry
dWN0cyBhcyB0aGVyZSBpcyBsZXNzIGNoYW5nZSBmb3IgbWlzcy1jb25maWd1cmF0aW9uLiAgQnV0
IHNpZ25hbGluZyB2aWEgc291cmNlIGFkZHJlc3MgaXMgYSB2YWxpZCB3YXkgdG8gZG8gbmV0d29y
ayBkZXNpZ24gd2hpY2ggcmVsaWVzIGxlc3Mgb24gdGhlIGNhcGFiaWxpdGllcyBvZiBzcGVjaWZp
YyB2ZW5kb3JzLg0KDQo+ID4NCj4gPj4gQWxzbyBpZiB5b3UgZG8ga2VlcCAnc291cmNlLXZyZicg
SSB0aGluayAnc291cmNlLW5pLW5hbWUnIGlzIG1vcmUNCj4gPj4gY29uc2lzdGVudCB3aXRoIGRy
YWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXVnbWVudGF0aW9ucyBvZiBpZjppbnRlcmZhY2UuDQo+
ID4NCj4gPiAiTmktbmFtZSIgaXMgbW9yZSBnZW5lcmljIGJlY2F1c2UgaXQgc3VwcG9ydHMgbW9y
ZSB0eXBlcyBvZiB0ZWNobm9sb2dpZXMNCj4gdGhhbiByZXF1aXJlZCBhdCB0aGlzIHRpbWUuICAg
QXMgbm8gY3VzdG9tZXIgaXMgdGFsa2luZyBhYm91dCB0aGluZ3MgYmV5b25kDQo+IFZSRiwgaW5z
dGFsbGluZyB0aGUgbW9yZSBnZW5lcmljIG5hbWUgd291bGQgYmUgYW4gYWRkZWQgbGF5ZXIgb2YN
Cj4gY29tcGxleGl0eS4NCj4gDQo+IHRoZSBhdWdtZW50YXRpb24gdG8gaW50ZXJmYWNlcyBpcyBj
YWxsZWQgYmluZC1uaS1uYW1lLCBhcyBsb25nIGFzIHlvdQ0KPiByZWZlcmVuY2UgaXQgb3Igbmkt
bmFtZSBhbGwgaXMgZ29vZC4NCg0KRXhjZWxsZW50LiAgIE1vZGVsIG5vdyB1c2VzOg0KDQogICAg
ICAgICAgdHlwZSBsZWFmcmVmIHsNCiAgICAgICAgICAgIHBhdGggIi9uaTpuZXR3b3JrLWluc3Rh
bmNlcy9uaTpuZXR3b3JrLWluc3RhbmNlL25pOm5hbWUiOw0KICAgICAgICAgIH0NCg0KRXJpYw0K
DQogDQo+IExvdQ0KPiA+DQo+ID4gRXJpYw0KPiA+DQo+ID4+IExvdQ0KPiA+Pg0KPiA+PiBPbiAx
MS8yMS8yMDE3IDQ6NTYgQU0sIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSSB0
aGluayB0aGF0IHVzaW5nIGEgZmVhdHVyZSBpcyBiZXR0ZXIgaGVyZS7CoCBEZWZpbmluZyBhIHNl
cGFyYXRlDQo+ID4+PiBtb2R1bGUgZm9yIGp1c3Qgb25lIGxlYWYgc2VlbXMgc29tZXdoYXQgbGlr
ZSBvdmVya2lsbC4NCj4gPj4+DQo+ID4+PiBJJ20gbm90IHN1cmUgdGhhdCBhbnkgY29tcGlsZSB0
aW1lIGRlcGVuZGVuY3kgb24gbmV0d29yayBpbnN0YW5jZXMsDQo+ID4+PiBhbmQgaGVuY2Ugc2No
ZW1hIG1vdW50LCBpcyByZWFsbHkgYW4gaXNzdWU7IHRoZSBtb3JlIGltcG9ydGFudCBvbmUNCj4g
Pj4+IHRvIGF2b2lkIGlzIHRoZSBydW4gdGltZSBkZXBlbmRlbmN5IG9uIG5ldHdvcmsgaW5zdGFu
Y2VzIGFuZCBzY2hlbWENCj4gPj4+IG1vdW50LCBhbmQgYm90aCBzb2x1dGlvbnMgYWNoaWV2ZSB0
aGlzLg0KPiA+Pj4NCj4gPj4+IEJ1dCBJIGFsc28gYWdyZWUgd2l0aCBKdWVyZ2VuJ3MgY29tbWVu
dCB0aGF0IHdlIHNob3VsZCBiZQ0KPiA+Pj4gY29uc2lzdGVudCwgYW5kIHRoZSBzYW1lIGFwcHJv
YWNoIHNob3VsZCBiZSB1c2VkIGZvciBvdGhlciBwcm90b2NvbHMNCj4gPj4+IHdpdGggY29uZGl0
aW9uYWwgZGVwZW5kZW5jaWVzIG9uIG5ldHdvcmsgaW5zdGFuY2VzIGFzIHdlbGwuDQo+ID4+Pg0K
PiA+Pj4gVGhhbmtzLA0KPiA+Pj4gUm9iDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IE9uIDIwLzExLzIw
MTcgMTk6NTQsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gKkZyb206
KkFsZXhhbmRlciBDbGVtbSwgTm92ZW1iZXIgMjAsIDIwMTcgMjo0NiBQTQ0KPiA+Pj4+DQo+ID4+
Pj4NCj4gPj4+Pg0KPiA+Pj4+IEhpIEVyaWMsDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+
Pj4gSSBhZ3JlZSB0aGF0IHByb2xpZmVyYXRpb24gb2YgbW9kdWxlcyBpcyBhIGNvbmNlcm4sIGFu
ZCBjZXJ0YWlubHkNCj4gPj4+PiB3ZSB3b3VsZCBub3Qgd2FudCB0byBydW4gaW50byBjb21iaW5h
dG9yaWFsIGV4cGxvc2lvbnMuwqAgSG93ZXZlciwgSQ0KPiA+Pj4+IGRvbuKAmXQgdGhpbmsgdGhp
cyB3b3VsZCBiZSB0aGUgY2FzZSBoZXJlIC0gd2Ugd291bGQgbm90IG5lZWQgdG8NCj4gPj4+PiBh
dWdtZW50IFZSRiBpbnRvIHlhbmctcHVzaCBhbHNvIChvciB5YW5nLXB1c2ggaW50byBWUkYpLsKg
IEluc3RlYWQsDQo+ID4+Pj4gYm90aCB5YW5nLXB1c2ggYW5kIHZyZi1mb3Itbm90aWZpY2F0aW9u
cyB3b3VsZCBiZSBhdWdtZW50aW5nDQo+ID4+Pj4gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIGlu
IHBhcmFsbGVsLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IDxFcmljPsKgIFllcywg
eW91IGFyZSByaWdodCwgd2l0aCB0aGlzIGFwcHJvYWNoIHdlIHdvdWxkIGVuZCB3aXRoDQo+ID4+
Pj4gdGhyZWUgbW9kZWxzIHJhdGhlciB0aGFuIGZvdXIuwqAgQnV0IHR3byBtb2RlbHMgaXMgYWxy
ZWFkeSBhIGxvdC4NCj4gPj4+PiDCoEFuZCB3ZSBzdGlsbCBzZXQgcHJlY2VkZW5jZSB0aGF0IHdl
IGVuZCB3aXRoIGEgbmV3IFZSRiBzcGVjaWZpYw0KPiA+Pj4+IG1vZGVsIGV2ZXJ5IHRpbWUgYW55
IFlBTkcgbW9kZWwgbmVlZHMgYSBWUkYuDQo+ID4+Pj4NCj4gPj4+PiBFcmljDQo+ID4+Pj4NCj4g
Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gLS0tIEFsZXgNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4g
Pj4+PiAqRnJvbToqRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQo+
ID4+Pj4gKlNlbnQ6KiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDExOjM5IEFNDQo+ID4+Pj4g
KlRvOiogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbQ0KPiA+Pj4+
IDxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PjsgUm9iZXJ0IFdpbHRvbiAtWCAo
cndpbHRvbiAtDQo+ID4+Pj4gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIDxyd2lsdG9uQGNpc2Nv
LmNvbQ0KPiA+Pj4+IDxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgbmV0Y29uZkBpZXRmLm9y
Zw0KPiA+Pj4+IDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJnZXIgPGxiZXJnZXJA
bGFibi5uZXQNCj4gPj4+PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPiA+Pj4+ICpTdWJq
ZWN0OiogUkU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2Ug
VlJGDQo+ID4+Pj4gb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/DQo+ID4+Pj4NCj4gPj4+Pg0K
PiA+Pj4+DQo+ID4+Pj4gSSBhZ3JlZSB0aGlzIGlzIG1vcmUgZWxlZ2FudCBpZiB3ZSBsb29rIGp1
c3QgYXQNCj4gPj4+PiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMuwqDCoCBIb3dldmVyIGV4dHJh
cG9sYXRpbmcgdGhpcyBtZWFucyB0aGF0DQo+ID4+Pj4gd2UgaGF2ZSBhIGR1cGxpY2F0ZSBZQU5H
IG1vZHVsZSBldmVyeSB0aW1lIHdlIGhhdmUgYSBWUkYuwqDCoCBBbmQgaW4NCj4gPj4+PiBvdXIg
Y2FzZSB3aGVuIHdlIGF1Z21lbnQgeWFuZy1wdXNoLCB3aGljaCBtb2RlbCBkbyB3ZSBzdGFydA0K
PiBmcm9tPw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEVyaWMNCj4gPj4+Pg0KPiA+
Pj4+DQo+ID4+Pj4NCj4gPj4+PiAqRnJvbToqQWxleGFuZGVyIENsZW1tIFttYWlsdG86YWxleGFu
ZGVyLmNsZW1tQGh1YXdlaS5jb21dDQo+ID4+Pj4gKlNlbnQ6KiBNb25kYXksIE5vdmVtYmVyIDIw
LCAyMDE3IDI6MjcgUE0NCj4gPj4+PiAqVG86KiBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0g
RU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pDQo+ID4+Pj4gPHJ3aWx0b25AY2lzY28uY29tIDxtYWls
dG86cndpbHRvbkBjaXNjby5jb20+PjsgRXJpYyBWb2l0IChldm9pdCkNCj4gPj4+PiA8ZXZvaXRA
Y2lzY28uY29tIDxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj47IG5ldGNvbmZAaWV0Zi5vcmcNCj4g
Pj4+PiA8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4u
bmV0DQo+ID4+Pj4gPG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NCj4gPj4+PiAqU3ViamVjdDoq
IFJFOiBbTmV0Y29uZl0gSXNzdWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRg0K
PiA+Pj4+IG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+
Pg0KPiA+Pj4+IEkgYW0gZmluZSB3aXRoIHRoYXQgY2hhbmdlLCBidXQgd2FudGVkIHRvIGJyaW5n
IHVwIG9uZSBhZGRpdGlvbmFsDQo+ID4+Pj4gb3B0aW9uIHRoYXQgd2FzIGFsc28gYnJpZWZseSBt
ZW50aW9uZWQgaW4gdGhlIHJvb20gd2hpY2ggc3RyaWtlcyBtZQ0KPiA+Pj4+IGFzIHBlcmhhcHMg
YSBiaXQgbW9yZSBlbGVnYW50LsKgIFRoYXQgaXMgdGhlIG9wdGlvbiB0byB1c2UNCj4gPj4+PiBh
dWdtZW50YXRpb24uwqAgSW4gdGhhdCBjYXNlLCBzb3VyY2UtdnJmIGFuZCB0aGUgaW1wb3J0IHN0
YXRlbWVudA0KPiA+Pj4+IHdvdWxkIHNpbXBseSBiZSBvbWl0dGVkLiBJbnN0ZWFkLCBhIG5ldyBt
b2R1bGUgd291bGQgYmUgY3JlYXRlZA0KPiAoZS5nLg0KPiA+Pj4+IGlldGYtdnJmLWZvci1zdWJz
Y3JpYmVkLW5vdGlmaWNhdGlvbnMpLCB3aGljaCBjb250YWlucyB0aGUgaW1wb3J0DQo+ID4+Pj4g
c3RhdGVtZW50IGFuZCB0d28gYXVnbWVudHMgc3RhdGVtZW50cyB0byBhdWdtZW50IHRoZSBzb3Vy
Y2UtdnJmDQo+ID4+Pj4gaW50byB0aGUgZXhpc3RpbmcgbW9kdWxlLg0KPiA+Pj4+DQo+ID4+Pj4N
Cj4gPj4+Pg0KPiA+Pj4+IC0tLSBBbGV4DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4g
KkZyb206Kk5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhh
bGYgT2YNCj4gPj4+PiAqUm9iZXJ0IFdpbHRvbg0KPiA+Pj4+ICpTZW50OiogRnJpZGF5LCBOb3Zl
bWJlciAxNywgMjAxNyAxMDo0NiBBTQ0KPiA+Pj4+ICpUbzoqIEVyaWMgVm9pdCAoZXZvaXQpIDxl
dm9pdEBjaXNjby5jb20gPG1haWx0bzpldm9pdEBjaXNjby5jb20+PjsNCj4gPj4+PiBuZXRjb25m
QGlldGYub3JnIDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJnZXINCj4gPj4+PiA8
bGJlcmdlckBsYWJuLm5ldCA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPiA+Pj4+ICpTdWJq
ZWN0OiogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2Ug
VlJGDQo+ID4+Pj4gb2YgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/DQo+ID4+Pj4NCj4gPj4+Pg0K
PiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDE3LzExLzIwMTcgMTg6MTcsIEVyaWMg
Vm9pdCAoZXZvaXQpIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gICAgIEkgd291bGQgbGlrZSB0byBj
b250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZyb20gb3VyDQo+ID4+Pj4gICAg
IHNlc3Npb24uwqDCoCBJIHRoaW5rIHdlIGNhbWUgdG8gYWdyZWVtZW50IGFtb25nIHRoZSBhdHRl
bmRlZXMuDQo+ID4+Pj4gICAgIEhvcGVmdWxseSB0aGlzIHRocmVhZCBjYW4gY29uZmlybSwgb3Ig
cmVmaW5lIGFzIG5lZWQuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgIEZpcnN0
IGxldOKAmXMgbG9vayBhdCBSb2JlcnTigJlzIHByb3Bvc2FsIGJlbG93Og0KPiA+Pj4+DQo+ID4+
Pj4gICAgIFRoZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxlbWVudHMgaW4gUm9iZXJ04oCZcyBwcm9w
b3NhbCBiZWxvdywgYnV0DQo+ID4+Pj4gICAgIGl0IGlzbuKAmXQgdXAgdG8gb3VyIFdHIHRvIGRl
dGVybWluZSB0aGUgcHJvcGVyIHN0cnVjdHVyZSBvZiB0aGUNCj4gPj4+PiAgICAgbmV0d29yay1p
bnN0YW5jZS1tb2RlbC7CoMKgIEF1dGhvcnMgb2YgdGhhdCBtb2RlbCB3ZXJlIGluIHRoZSByb29t
LA0KPiA+Pj4+ICAgICBhbmQgYXJlIGF3YXJlIHRoYXQgWUFORyBtb2RlbCBkZXZlbG9wZXJzIGZy
b20gb3V0c2lkZSB3b3VsZA0KPiA+Pj4+ICAgICB3ZWxjb21lIGEgcGFydGl0aW9uaW5nIHdoaWNo
IGRlY291cGxlcyBhbnkgbGlua2FnZXMgdG8NCj4gPj4+PiAgICAgc2NoZW1hLW1vdW50IHdoZW4g
YWxsIHRoYXQgaXMgbmVlZGVkIGlzIHRvIGlkZW50aWZ5IGEgVlJGIGJ5IG5hbWUuDQo+ID4+Pj4N
Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgIExvb2tpbmcgYXQgd2hhdCB3ZSBjYW4gY29udHJv
bCwgZGlzY3Vzc2VkIGluIHRoZSByb29tIHdhcyB0aGUNCj4gPj4+PiAgICAgZm9sbG93aW5nIGNo
YW5nZSB0byBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6DQo+ID4+Pj4NCj4gPj4+PiAgICAgMS7C
oMKgwqDCoMKgIGltcG9ydCDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCj4gPj4+Pg0KPiA+
Pj4+ICAgICAyLsKgwqDCoMKgwqAgY3JlYXRlIGlmLWZlYXR1cmUg4oCcVlJG4oCdLg0KPiA+Pj4+
DQo+ID4+Pj4gICAgIDMuwqDCoMKgwqDCoCBhcHBseSBmZWF0dXJlIOKAnFZSRuKAnSB0byBvYmpl
Y3Qg4oCcc291cmNlLVZSRuKAnQ0KPiA+Pj4+DQo+ID4+Pj4gICAgIDQuwqDCoMKgwqDCoCBMZWFm
cmVmIHRvIOKAnHNvdXJjZS1WUkbigJ0gdG8gdmFsaWRhdGUgYWdhaW5zdCB0aGUNCj4gPj4+PiAg
ICAgbmV0d29yay1pbnN0YW5jZSBtb2RlbOKAmXMNCj4gPj4+PiAvbmV0d29yay1pbnN0YW5jZXMv
bmV0d29yay1pbnN0YW5jZS9uYW1lLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAg
ICBUaGlzIGlzIHRoZSBjdXJyZW50IHByb3Bvc2FsLsKgIEFyZSB0aGVyZSBhcmUNCj4gPj4+PiAg
ICAgY29uY2VybnMvb2JqZWN0aW9ucy9yZWZpbmVtZW50cz8NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+
Pj4gTm8gY29uY2VybnMsIGJ1dCBwZXJoYXBzIG9uZSB0cml2aWFsIHJlZmluZW1lbnQuDQo+ID4+
Pj4NCj4gPj4+PiBJIGhhZCBtaXN0YWtlbmx5IHRob3VnaHQgdGhhdCBhIGRldmljZSB3b3VsZCBl
aXRoZXIgc3VwcG9ydCBWUkZzDQo+ID4+Pj4gZm9yIGFsbCBwcm90b2NvbHMgb3Igbm9uZSwgaGVu
Y2UgbXkgc3VnZ2VzdGlvbiB0byBoYXZlIGEgc2luZ2xlICJWUkYiDQo+ID4+Pj4gZmVhdHVyZSwg
d2hpY2ggd291bGQgbmF0dXJhbGx5IGJlIGRlZmluZWQgYnkgdGhlIG5ldHdvcmstaW5zdGFuY2Vz
DQo+ID4+IG1vZGVsLg0KPiA+Pj4+DQo+ID4+Pj4gSW4gdGhlIGRpc2N1c3Npb25zIHRoYXQgSSBo
YWQgd2l0aCBMb3UsIHNvbWUgb2YgdGhlbSBhdCB0aGUgbWljLA0KPiA+Pj4+IHNvbWUgYWZ0ZXJ3
YXJkcywgTG91IGNsYXJpZmllZCB0aGF0IGl0IHF1aXRlIHBsYXVzaWJsZSB0aGF0IFZSRnMNCj4g
Pj4+PiBtYXkgb25seSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24gYSBkZXZpY2Ug
YW5kIG5vdCBhbGwsDQo+ID4+Pj4gYW5kIGhlbmNlIHRoZSBzb2x1dGlvbiBvZiBoYXZpbmcgYSAi
VlJGIiBmZWF0dXJlIHBlciBwcm90b2NvbCBzZWVtcw0KPiA+Pj4+IGxpa2UgdGhlIHJpZ2h0IHNv
bHV0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gSSB0aGluayB0aGF0IEkgd291bGQgY2FsbCB0aGUgZmVh
dHVyZSAic3VwcG9ydHMtdnJmIiByYXRoZXIgdGhhbiAidnJmIi4NCj4gPj4+Pg0KPiA+Pj4+IFRo
YW5rcywNCj4gPj4+PiBSb2INCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAgICAgRXJp
Yw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+
DQo+ID4+Pj4gICAgICpGcm9tOipOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnXSAqT24gQmVoYWxmIE9mDQo+ID4+Pj4gICAgICpFcmljIFZvaXQgKGV2b2l0KQ0KPiA+Pj4+
ICAgICAqU2VudDoqIFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDEwOjIzIFBNDQo+ID4+Pj4g
ICAgICpUbzoqIFJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBhdCBD
aXNjbykNCj4gPj4+PiAgICAgPHJ3aWx0b25AY2lzY28uY29tPiA8bWFpbHRvOnJ3aWx0b25AY2lz
Y28uY29tPjsNCj4gbmV0Y29uZkBpZXRmLm9yZw0KPiA+Pj4+ICAgICA8bWFpbHRvOm5ldGNvbmZA
aWV0Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KPiA+Pj4+ICAgICA8bWFp
bHRvOmxiZXJnZXJAbGFibi5uZXQ+DQo+ID4+Pj4gICAgICpTdWJqZWN0OiogUmU6IFtOZXRjb25m
XSBJc3N1ZSBTTiAjNTogSG93IHRvIHJlcHJlc2VudCBTb3VyY2UgVlJGDQo+ID4+Pj4gICAgIG9m
IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+
ICAgICBBZ3JlZSBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbS4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+
Pj4NCj4gPj4+PiAgICAgSSB3b3VsZCBkZWZlciB0byBMb3UgYW5kIHRoZSBvdGhlciBhdXRob3Jz
IG9mDQo+ID4+Pj4gICAgIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXMgdGhpcyB3b3VsZCBi
ZSBhIGZhaXJseSBzaWduaWZpY2FudA0KPiA+Pj4+ICAgICBjaGFuZ2UuDQo+ID4+Pj4NCj4gPj4+
Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgIEVyaWMNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+
PiAgICAgKkZyb206KlJvYmVydCBXaWx0b24sIE5vdmVtYmVyIDE0LCAyMDE3IDc6NTggUE0NCj4g
Pj4+Pg0KPiA+Pj4+ICAgICBIaSBFcmljLCBMb3UsDQo+ID4+Pj4NCj4gPj4+PiAgICAgVGhpcyBz
ZWVtcyB0byBiZSBhIGdlbmVyaWMgcHJvYmxlbS4NCj4gPj4+Pg0KPiA+Pj4+ICAgICBDb3VsZCB0
aGUgVlJGIGxlYWZyZWYgbmFtZSBkZXBlbmRlbmN5IGlzc3VlIGJlIHNvbHZlZCB3aXRoIGFuDQo+
ID4+Pj4gICAgIGlmLWZlYXR1cmUgc3RhdGVtZW50Py4NCj4gPj4+Pg0KPiA+Pj4+ICAgICBJLmUu
Y291bGQgdGhlIG5ldHdvcmsgaW5zdGFuY2UgZHJhZnQgZGVmaW5lIGEgc2VwYXJhdGUgWUFORw0K
PiA+Pj4+ICAgICBtb2R1bGUgKHdpdGggbm8gZGVwZW5kZW5jaWVzKSB0aGF0IGRlZmluZXMgYSAi
VlJGIiBmZWF0dXJlLg0KPiA+Pj4+DQo+ID4+Pj4gICAgIEFsbCB0aGUgVlJGIHJlZmVyZW5jZXMg
KGlkZWFsbHkgaWYgYWxsIElFVEYgWUFORyBtb2R1bGVzIHRoYXQgbWF5DQo+ID4+Pj4gICAgIG9w
dGlvbmFsbHkgZGVwZW5kIG9uIFZSRnMpIGNvdWxkIGJlIGxlYWYtcmVmcyB0bw0KPiA+Pj4+ICAg
ICAvbmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lIGJ1dCBwcmVkaWNhdGVk
IHdpdGggYW4NCj4gPj4+PiAgICAgaWYtZmVhdHVyZSAibmk6dnJmIi4NCj4gPj4+Pg0KPiA+Pj4+
ICAgICBIZW5jZSBpZiBhIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBpdCBkb2Vz
bid0IGltcGxlbWVudA0KPiA+Pj4+ICAgICB0aGUgInZyZiIgZmVhdHVyZSwgc28gaXQgZG9lc24n
dCBoYXZlIHRvIGltcGxlbWVudCB0aGUgZnVsbA0KPiA+Pj4+ICAgICBuZXR3b3JrIGluc3RhbmNl
cyBtb2R1bGUsIG9yIHNjaGVtYSBtb3VudC4NCj4gPj4+Pg0KPiA+Pj4+ICAgICBUaGFua3MsDQo+
ID4+Pj4gICAgIFJvYg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAgICBPbiAxNS8x
MS8yMDE3IDA4OjQ1LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+ICAg
ICAgICAgSW4gdGhlIFdHIHNlc3Npb24gdG9tb3Jyb3csIEkgYW0gaG9waW5nIHRvIGdldCDigJxo
dW0gZmVlZGJhY2vigJ0NCj4gPj4gb246DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4g
ICAgICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zDQo+ID4+
Pj4NCj4gPj4+PiAgICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdi
aXMvaXNzdWVzLzUNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgIFRoZSB0
d28gY2hvaWNlcyBleHBvc2VkIGR1cmluZyB0aGUgdHdvIHdlZWsgcmV2aWV3IGZvciBob3cgdG8N
Cj4gPj4+PiAgICAgICAgIHJlcHJlc2VudCBTb3VyY2UgVlJGIG9mIGNvbmZpZ3VyZWQgc3Vic2Ny
aXB0aW9uIHdlcmU6DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICAoMSkg
TGVhZnJlZiB0byDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCj4gPj4+PiAgICAgICAgIC9u
ZXR3b3JrLWluc3RhbmNlcy9uZXR3b3JrLWluc3RhbmNlL25hbWUNCj4gPj4+Pg0KPiA+Pj4+ICAg
ICAgICAgwrfCoMKgwqDCoMKgwqDCoCBDcmVhdGVzIGRlcGVuZGVuY3kgb24gc2NoZW1hIG1vdW50
IGZvciBzdWJzY3JpcHRpb25zLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICDCt8KgwqDCoMKgwqDC
oMKgIFNvdXJjZSBWUkYgaXMgYW4gb3B0aW9uYWwgY2FwYWJpbGl0eSwgYnV0IHB1Ymxpc2hlcnMN
Cj4gPj4+PiAgICAgICAgIHRoYXQgZG9u4oCZdCBjYXJlIGFib3V0IFZSRnMgbXVzdCBzdGlsbCBp
bXBvcnQuwqAgKE5vdGU6IGNvdWxkDQo+ID4+Pj4gICAgICAgICBhbHNvIGF1Z21lbnQgdGhlIGxl
YWZyZWYgaW4gYW5vdGhlciBtb2RlbCwgYnV0IHRoYXQgYWRkcw0KPiA+Pj4+ICAgICAgICAgYW5v
dGhlciBsYXllciBvZiBjb21wbGV4aXR5KQ0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICDCt8KgwqDC
oMKgwqDCoMKgIGVzdGFibGlzaGVzIG1vZGVsIGRlcGVuZGVuY3kgdG8NCj4gPj4+PiAgICAgICAg
IGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+
PiAgICAgICAgICgyKSBVc2UgYSBzdHJpbmcgd2hpY2ggd291bGQgYmUgcG9wdWxhdGVkIHdpdGgg
ZXhhY3Qgc2FtZQ0KPiA+Pj4+ICAgICAgICAgbmFtZSBhcyB3b3VsZCBiZSBpbiB0aGUgbGVhZnJl
ZiBvZiAoMSkNCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgwrfCoMKgwqDCoMKgwqDCoCBQb3NzaWJs
ZSB0byBuYW1lIFZSRiB3aGljaCBkb2VzbuKAmXQgZXhpc3QNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+
Pj4NCj4gPj4+PiAgICAgICAgIFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDIpLg0KPiA+Pj4+DQo+
ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgVGhhbmtzLA0KPiA+Pj4+DQo+ID4+Pj4gICAg
ICAgICBFcmljDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+
ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4+Pg0KPiA+
Pj4+ICAgICAgICAgTmV0Y29uZkBpZXRmLm9yZyA8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+
ID4+Pj4NCj4gPj4+PiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0Y29uZg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAuDQo+ID4+Pj4N
Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pg0KPiA+DQoNCg==


From nobody Tue Nov 21 11:08:17 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD661296D2 for ; Tue, 21 Nov 2017 11:08:16 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 GYoaM62ggkX0 for ; Tue, 21 Nov 2017 11:08:15 -0800 (PST)
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 255191296CD for ; Tue, 21 Nov 2017 11:08:15 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id E76BF1E0D39 for ; Tue, 21 Nov 2017 12:08:10 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id cj861w00v2SSUrH01j8911; Tue, 21 Nov 2017 12:08:10 -0700
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=_E_AE8ZCsEvHKCqp5D4A:9 a=QEXdDO2ut3YA:10
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=L401ZET7e0WwhohdohBl/Gk0ZYNw0Rm1j3NOeQcn3Gs=; b=cO8l/7W/DJEZ0ycrP9xx8M3tdx XEnGZsBHWlnx99heUCN2TyMuekDRYeTaqlMiMZ7e8vbVe6LSrBmlWzbXPnbh2tsoNLi9v9WPzunlA E8mPiys+/EsJr9rBwdGg9KRfU;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:33084 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eHDtu-003seO-Ma; Tue, 21 Nov 2017 12:08:06 -0700
To: "Eric Voit (evoit)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Alexander Clemm , "netconf@ietf.org" 
References:    <383a834a60eb489a9e4fbb9bdf5a5c43@XCH-RTP-013.cisco.com> <31442888-3dba-7834-c408-bd7986b9e381@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD8F5@sjceml521-mbx.china.huawei.com> <317134acb7bd4778b95b76554aeb93b0@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACD96C@sjceml521-mbx.china.huawei.com>   <0628ad1c-55df-536b-bbf6-1c8d65e751ea@labn.net> <72ace49056484d49a0f6eadc42ea49a5@XCH-RTP-013.cisco.com> <7845f9fd-9d46-2ec0-b8e8-8593d00b5706@labn.net> <6e6cf4edb48441fbadb5e19b36d7a2ca@XCH-RTP-013.cisco.com>
From: Lou Berger 
Message-ID: 
Date: Tue, 21 Nov 2017 14:08:05 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <6e6cf4edb48441fbadb5e19b36d7a2ca@XCH-RTP-013.cisco.com>
Content-Type: text/plain; charset=utf-8
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.86.101
X-Exim-ID: 1eHDtu-003seO-Ma
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:33084
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 19:08:16 -0000

On 11/21/2017 11:30 AM, Eric Voit (evoit) wrote:
>> the augmentation to interfaces is called bind-ni-name, as long as you
>> reference it or ni-name all is good.
> Excellent.   Model now uses:
> 
>           type leafref {
>             path "/ni:network-instances/ni:network-instance/ni:name";
>           }

Okay then.  You probably want to mention that wen ni-name is set the ip
address must be assigned to an interfaces with the matching bind-ni-name.

Lou


From nobody Wed Nov 22 05:25:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D5612943A; Wed, 22 Nov 2017 05:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t2nSNi58sLP; Wed, 22 Nov 2017 05:25:22 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8043129439; Wed, 22 Nov 2017 05:25:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113101; q=dns/txt; s=iport; t=1511357121; x=1512566721; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=apXZDQ5AnE1uqP1iY4fYmYZv8RWoaRKYNX7F1TnvLOA=; b=LjFL+DMWNhZQ+7BcLjCYU4ApxLQBzs4SSBManaBQ5XuH1iwPbMwqLjc8 0sfuKzyOa26MquTXzrfqROU3xyAiW+ep6J3VNoAr9bhSqKdYfGhIUHgKJ NyMqyO+57I1Ez4aTlQ76DBDbqJhshDmVIHJPdGdjnEkanBKv9a6cU0Q6g 0=;
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="scan'208,217";a="364429"
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; 22 Nov 2017 13:25:19 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAMDPIva030783; Wed, 22 Nov 2017 13:25:18 GMT
To: Andy Bierman , Robert Wilton 
Cc: "sec-ads@ietf.org" , NETCONF 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> 
From: Benoit Claise 
Message-ID: 
Date: Wed, 22 Nov 2017 14:25:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------91506FC7964D2B80B377A1F0"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:25:26 -0000

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

On 11/10/2017 7:23 PM, Andy Bierman wrote:
> Hi,
>
> Here are some proposed edits to make the data rule consistent with the 
> examples.
> Note that this issue is not related to the edit in the original 1-week 
> change.
That's right, but we found a source of misinterpretation in the draft 
and you have rightly corrected it in the github v9.

Regards, Benoit
>
>
> sec. 3.3.5:
>
> OLD:
>
>
>       data node rule:  controls access for a specific data node, 
> identified
>       by its path location within the conceptual XML document for the
>       data node.
>
>
> NEW:
>
>       data node rule:  controls access for a specific data node and 
> its descendants,
>       identified by its path location within the conceptual XML 
> document for the
>       data node.
>
>
> sec 3.4.5, step 6, bullet 2:
>
>
> OLD:
>
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node.
>        
> NEW:
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node. A path is
>            considered to match if the current data node is the data node
>            specified by the path, or is a descendant data node of this 
> data node.
> appendix B.4: (2 bugs in explanation)
> OLD:
> deny-nacm: This rule denies the "guest" group any access to the  
> subtree. Note that the default namespace is only applicable because 
> this subtree is defined in the same namespace as the  element.
> NEW:
> deny-nacm: This rule denies the "guest" group any access to the  
> subtree.
> Andy
>
> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton  > wrote:
>
>
>
>     On 10/11/2017 16:33, Andy Bierman wrote:
>>
>>
>>     On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton >     > wrote:
>>
>>
>>
>>         On 10/11/2017 15:49, Andy Bierman wrote:
>>>
>>>
>>>         On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
>>>         > wrote:
>>>
>>>             On 2017-11-10 11:42, Robert Wilton wrote:
>>>             >
>>>             >
>>>             > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>             >>
>>>             >>
>>>             >>
>>>             >>
>>>             >> Mahesh Jethanandani
>>>             >> mjethanandani@gmail.com
>>>             
>>>             >>             >
>>>             >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
>>>             
>>>             >>
>>>             wrote:
>>>             >>
>>>             >>> Hi,
>>>             >>>
>>>             >>> The term "data node" is used in the document to
>>>             refer to the top-level node
>>>             >>> of the specified object, not the entire subtree (if
>>>             any).
>>>             >>>
>>>             >>> The data-rule /foo does not match /foo/child1 in the
>>>             text below.
>>>             >>> The child nodes are omitted because of step 11.
>>>             >>> The admin has to explicitly permit individual child
>>>             nodes (or modules).
>>>             >>> This seems correct if the read-default is "deny".
>>>             >>>
>>>             >>> Should any text be added or changed to make this
>>>             more clear?
>>>             >>
>>>             >> I would agree with Robert that it was not entirely
>>>             clear that rule applied on the parent data-node does not
>>>             apply to the child nodes. So yes, it would help to
>>>             clarify it.
>>>             > We should be doing more than clarifying it.  We need
>>>             to fix it so that it works in a sensible way. I.e. to
>>>             make the normative text consistent with the behaviour
>>>             currently described in the examples in
>>>             > the appendix B.4.
>>>             >
>>>             > If we follow Andy's interpretation that a data rule
>>>             doesn't match child nodes then those examples are
>>>             completely wrong.  E.g. the 4th rule is described as
>>>             "This rule gives the 'admin' group read-write
>>>             > access to all acme  entries."  But If the
>>>             path only strictly matches
>>>             "/acme:interfaces/acme:interface" then the admin group
>>>             rule achieves nothing useful at all.  The admin is not even
>>>             > allowed to create an interface because they would not
>>>             even have permission to write to the list key 'name'
>>>             node required to create a list entry!  Instead, a
>>>             separate rule would be required for every
>>>             > single possible schema node under
>>>             "/acme:interfaces/acme:interface"! I think that this
>>>             makes "permit" data-node rules completely unusable.
>>>
>>>             I strongly agree with this, and I would say that it
>>>             isn't only the case
>>>             for "permit" rules - e.g. denying some access to a
>>>             subtree of the data
>>>             model that would otherwise be permitted due to defaults
>>>             is at least as
>>>             common, and the rules would be just as unusable for that.
>>>
>>>             Besides the examples, I think that the very use of the
>>>             term "match",
>>>             though unfortunately not defined, strongly suggests that
>>>             it is something
>>>             other than use of e.g. the term "identify" would imply.
>>>             Additionally,
>>>             this text in the description of the 'path' leaf is
>>>             consistent with the
>>>             match being a prefix match:
>>>
>>>                    The special value '/' refers to all possible
>>>                    datastore contents.";
>>>
>>>             FWIW, our NACM implementation, available to (and used
>>>             by) customers
>>>             since 2012, follows the prefix match logic, and I have
>>>             yet to hear of
>>>             any user expecting it to do otherwise.
>>>
>>>             > To fix this properly, we need to make the data-node
>>>             path rule a prefix match.  In particular, we need text
>>>             that specifies:
>>>             >
>>>             > (i) that a data-node path match succeeds if it matches
>>>             the path prefix from the root of the tree. I.e. so the
>>>             data-rule "/foo" matches "/foo" and all of foo's
>>>             descendant children nodes.
>>>
>>>             Strongly agree.
>>>
>>>
>>>
>>>         I do not see how the text can be interpreted this way.
>>
>>         Because otherwise the path match part of the NACM solution is
>>         really broken, and the path based examples in the appendix
>>         are entirely misleading and wrong.  The only way those
>>         examples make sense is the paths match descendant children
>>         nodes as well.
>>
>>
>>
>>     IMO the text does not support this interpretation.
>     The examples in B.4, and the definition of "/" matching all nodes
>     supports this interpretation.
>
>     Hence, my opinion is that it is the text in 3.4.5 that is
>     incorrectly specified; and that the examples, definition of "/"
>     and standard practice are right.
>
>     Otherwise, how did IETF manage to publish an RFC where the path
>     based examples are so completely wrong?   Whoever wrote and
>     reviewed those examples clearly had a different interpretation of
>     how these path based ACLs worked.
>
>
>>     There is nothing said about inheriting state from the parent data
>>     node.
>>     I think no matter how the permissions are derived, one can
>>     find examples that work better or worse because of it.
>     No.  If the rules apply to descendant children, all normal
>     examples work well (including the ones in the appendix).
>
>
>>     IMO the number of rules required to implement a use-case is not
>>     very relevant or objective criteria.
>     Yes it is, particularly when the difference is between needing a 1
>     line rule, and a 100+ line rule.
>
>>
>>     Using the previous example of /home and /home/user1,
>>     if the user1 is given read access to /home, then (according to you)
>>     it also has read access to every user subtree under /home.
>>     Instead of 1 rule per user, 2 rules are needed
>     No, just 1 rule per user:
>        read-default=deny
>        group=user1, path=/home/user1, action=permit
>
>     This is because of my two proposed changes:
>
>     (i) that a data-node path match succeeds if it matches the path
>     prefix from the root of the tree.  I.e. so the data-rule "/foo"
>     matches "/foo" and all of foo's descendant children nodes.
>     <- This means that you only need 1 entry instead of 100 entries.
>
>     (ii) if a data-node rule has action "permit" then it implicitly
>     allows read access for all ancestor parent nodes up to the root. 
>     (I.e. to mitigate the original change proposed on this thread.)
>     <- This means that you don't need a separate read rule for
>     "/home".  Read access to that node it is implicitly given via
>     "group=user1, path=/home/user1, action=permit", hence meaning that
>     the rule works the same way as it does on an rfc6536 compliant
>     implementation.
>
>>
>>        read-default=deny
>>        group=*, path=/home, action=permit
>>        group=user1, path=/home/user1, action=permit
>>
>>     The above rules would allow access for every user to every other
>>     user.
>>     The 2nd rule has no effect, which is counter-intuitive.
>>     Every user dir would need 2 rules
>>
>>        read-default=deny
>>        group=*, path=/home, action=permit
>>        group=user1, path=/home/user1, action=permit
>>        group=*, path=/home/user1, action=deny
>>
>>>         There is nothing that says this is how it works.
>>>         If it did, once could never have privileged sub-fiolders
>>>
>>>              /var/log -> permit
>>>              /var/log/apache2  -> deny
>>
>>         Yes, you can, you just list the longest path first in the
>>         list of rules:
>>
>>          (1)  /var/log/apache2  -> deny
>>           (2) /var/log -> permit
>>
>>         Any requests that attempt to access anything under
>>         /var/log/apache2 would match rule (1) and be denied.
>>         Any requests that attempt to access anything under /var/log,
>>         but not under /var/log/apache2, would fail to match rule (1),
>>         but would match rule (2) instead and be permitted.
>>
>>
>>
>>     I do not see any text in the draft or RFC 7950 that
>>     suggests that /var/log and /var/log/apache2 represent the same
>>     data node.
>     They are different data nodes, but I don't see how that is relevant.
>
>     Thanks,
>     Rob
>
>
>>
>>
>>     Andy
>>
>>>
>>>
>>>             > (ii) if a data-node rule has action "permit" then it
>>>             implicitly allows read access for all ancestor parent
>>>             nodes up to the root.  (I.e. to mitigate the original
>>>             change proposed on this thread.)
>>>
>>>             This seems reasonable to me, although I haven't at this
>>>             point evaluated
>>>             the suggestion in detail. In any case I think the main
>>>             point both
>>>             regarding this and the prefix match is that this update
>>>             to 6536 can't
>>>             make radical changes to the semantics compared to a
>>>             "reasonable
>>>             interpretation" (hard to define, I know) of the
>>>             under-specified
>>>             original.
>>>
>>>
>>>         The text does not say this at all so I do not approve of
>>>         this change
>>
>>         In the RFC version of the NACM this wasn't required because
>>         operation 'none' didn't require read access.  Now read access
>>         is required even for operation 'none', then this change makes
>>         sense to make the NACM changes backwards compatible, whilst
>>         still closing the security hole.
>>
>>         Thanks,
>>         Rob
>>
>>>
>>>
>>>             --Per
>>>
>>>
>>>
>>>         Andy
>>>
>>>             > Thanks,
>>>             > Rob
>>>             >
>>>             >
>>>             >>
>>>             >> Thanks
>>>             >>
>>>             >>>
>>>             >>>
>>>             >>> Andy
>>>             >>>
>>>             >>>
>>>             >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton
>>>             
>>>             >>
>>>             wrote:
>>>             >>>
>>>             >>>     Hi Andy,
>>>             >>>
>>>             >>>     It isn't clear to me whether matching a path in
>>>             NACM either:
>>>             >>>       (i) Only applies to the specific node, and not
>>>             any children, or
>>>             >>>       (ii) Applies to the specific node and all
>>>             descendant children nodes as well.
>>>             >>>
>>>             >>>     As an example, using the tree below.  if I have
>>>             a rule that matches path "A/B" then does that apply to
>>>             only the specific node "A/B", or does it also apply to
>>>             all descendant children of "A/B" as
>>>             >>>     well?
>>>             >>>
>>>             >>>     In rfc6536bis-08, section "3.4.5.  Data Node
>>>             Access Validation", step 6 states:
>>>             >>>
>>>             >>>             *  The rule does not have a "rule-type"
>>>             defined or the "rule-
>>>             >>>                type" is "data-node" and the *"path"
>>>             matches the requested data node*, action node, or
>>>             notification node.
>>>             >>>
>>>             >>>
>>>             >>>     My reading of this is that it implies that the
>>>             interpretation of the path rule is (i), but this is not
>>>             how I would normally expect an ACL rule to apply in a
>>>             tree like object (e.g a directory
>>>             >>>     file system).
>>>             >>>
>>>             >>>     However, the examples in Appendix B.4. imply
>>>             that the path rule is to be interpreted like (ii), or
>>>             otherwise the example rules seem to be mostly pointless.
>>>             >>>
>>>             >>>     E.g. taking this example from appendix B.4:
>>>             >>>
>>>             >>>            
>>>             >>> permit-dummy-interface
>>>             >>>              >>             xmlns:acme="http://example.com/ns/itf
>>>             " >
>>>             >>> /acme:interfaces/acme:interface[acme:name='dummy']
>>>             >>> 
>>>             >>> read update
>>>             >>> permit
>>>             >>> 
>>>             >>>                Allow the limited and guest groups read
>>>             >>>                and update access to the dummy interface.
>>>             >>> 
>>>             >>> 
>>>             >>>
>>>             >>>
>>>             >>>     If the rule is (i) then the access rule allows
>>>             the client to read the specific node
>>>             "/acme:interfaces/acme:interface[acme:name='dummy']" but
>>>             not any child leafs/containers of that interface,
>>>             >>>     this doesn't seem useful.
>>>             >>>
>>>             >>>     Further comments inline below ...
>>>             >>>
>>>             >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>             >>>>     Hi,
>>>             >>>>
>>>             >>>>     This change has no impact on the server if
>>>             /nacm/read-default is "permit".
>>>             >>>>     In that case, the extra read rules for /A and
>>>             /A/B are not needed.
>>>             >>>     I agree.
>>>             >>>
>>>             >>>>     An operator worried about read access should
>>>             set read-default to "deny".
>>>             >>>     I agree.  This is the scenario that I'm considering.
>>>             >>>
>>>             >>>>     In that case, explicit rules to read /A and
>>>             /A/B would be needed
>>>             >>>>     in the new NACM.
>>>             >>>     Yes, if the interpretation of the rule is (i) above.
>>>             >>>     Otherwise if the interpretation is (ii) then you
>>>             only need "read /A" since that implies "read A/B" as
>>>             well (as long as the rules are listed in the correct order).
>>>             >>>
>>>             >>>
>>>             >>>>       The deny rules would not be needed.
>>>             >>>     Only if the interpretation of the rule is (i)
>>>             above.  In which case the "read/write 'A/B/J' rule would
>>>             not be sufficient.  It would be necessary to define an
>>>             Xpath expressions that contains
>>>             >>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>             >>>
>>>             >>>     If the interpretation of the rule is (ii) then
>>>             you would also need all the explicit deny statements as
>>>             well, otherwise they would be allowed by the "read /A"
>>>             rule above.
>>>             >>>
>>>             >>>     Thanks,
>>>             >>>     Rob
>>>             >>>
>>>             >>>
>>>             >>>>
>>>             >>>>
>>>             >>>>     Andy
>>>             >>>>
>>>             >>>>
>>>             >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton
>>>             
>>>             >>
>>>             wrote:
>>>             >>>>
>>>             >>>>         Hi,
>>>             >>>>
>>>             >>>>         I'm not sure about this change.
>>>             >>>>
>>>             >>>>         I'm not that familiar with NACM, but if you
>>>             want to give a particular set of users read/write access
>>>             to a subtree, but not allow them to have any other
>>>             access to the configuration in the
>>>             >>>>         running datastore then with the existing
>>>             RFC, that could be expressed with a single rule (example
>>>             in 6536bis, appendix B.4)
>>>             >>>>
>>>             >>>>         With this new change, I think that you may
>>>             need to configure many more rules to achieve the same
>>>             thing.  I think that you would need to give read access
>>>             to the top node in the desired
>>>             >>>>         path, and then separate explicit "deny"
>>>             rules for every sibling child node walking from the top
>>>             of the tree down to the data node that read/write access
>>>             is actually being given to.  The
>>>             >>>>         example below may explain my understanding
>>>             better:
>>>             >>>>
>>>             >>>>         E.g. For a tree of data nodes, rooted at A,
>>>             if we wanted to give read/write access only to "J"
>>>             subtree, and no access for the rest of the tree then:
>>>             >>>>
>>>             >>>>       A
>>>             >>>>       |
>>>             >>>>  --------------------
>>>             >>>>                 |     |     |     |
>>>             >>>>                 B     C     D     E
>>>             >>>>                 |
>>>             >>>> -----------
>>>             >>>>            |   | |  |
>>>             >>>>            F   G H  J
>>>             >>>>   |
>>>             >>>>  ...
>>>             >>>>
>>>             >>>>
>>>             >>>>         In the old model, I think that the ACL
>>>             rules would be 1 rules long (assuming default deny all):
>>>             >>>> "read/write 'A/B/J'
>>>             >>>>
>>>             >>>>         In the new model, I think that the
>>>             equivalent ACL rules would need to be 8 rules long
>>>             (assuming default deny all):
>>>             >>>> "read/write 'A/B/J'
>>>             >>>>            "read A"
>>>             >>>>            "deny C"
>>>             >>>>            "deny D"
>>>             >>>>            "deny E"
>>>             >>>>            "deny F"
>>>             >>>>            "deny G"
>>>             >>>>            "deny H"
>>>             >>>>
>>>             >>>>         Note, I am assuming that a "path" rule
>>>             matches for the given path and all descendant nodes. 
>>>             The draft doesn't seem to be particularly clear on this
>>>             point (it states that the rule applies
>>>             >>>>         when the path matches, but this would seem
>>>             to be counter intuitive), and perhaps it could be clarified.
>>>             >>>>
>>>             >>>>         If this change is allowed, then the example
>>>             in appendix B.4 looks like it would need to be fixed,
>>>             since the "limited-acl" probably wouldn't give any
>>>             access at all, unless default read
>>>             >>>>         access had been given.
>>>             >>>>
>>>             >>>>         But, possibly I'm misunderstanding how this
>>>             all works!  If so, apologies for the noise :-)
>>>             >>>>
>>>             >>>>         Thanks,
>>>             >>>>         Rob
>>>             >>>>
>>>             >>>>
>>>             >>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>             >>>>>         Dear all,
>>>             >>>>>
>>>             >>>>>         Here is a major change in
>>>             draft-ietf-netconf-rfc6536bis, suggested by the Security
>>>             AD Eric Rescola part of the IESG review, which I would
>>>             like to validate with the WG. See
>>>             >>>>>
>>>             https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>>             
>>>             >>             >
>>>             >>>>>
>>>             >>>>>  
>>>             >>>>>         The NETCONF WG was cc'ed for the entire
>>>             discussion.
>>>             >>>>>         What do you think? I will draw the
>>>             conclusions by Friday Nov 10th.
>>>             >>>>>
>>>             >>>>>         Note: If the WG is fine, the next step is
>>>             to approve this document.
>>>             >>>>>
>>>             >>>>>  Regards, Benoit
>>>             >>>>>
>>>             >>>>>
>>>             >>>>>  _______________________________________________
>>>             >>>>>         Netconf mailing list
>>>             >>>>> Netconf@ietf.org 
>>>             >
>>>             >>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>             
>>>             >>             >
>>>             >>>>
>>>             >>>>
>>>             >>>
>>>             >>>
>>>             >>> _______________________________________________
>>>             >>> Netconf mailing list
>>>             >>> Netconf@ietf.org 
>>>             >
>>>             >>> https://www.ietf.org/mailman/listinfo/netconf
>>>             
>>>             >>
>>>             >> Mahesh Jethanandani
>>>             >> mjethanandani@gmail.com
>>>             
>>>             >>             >
>>>             >
>>>             >
>>>             >
>>>             > _______________________________________________
>>>             > Netconf mailing list
>>>             > Netconf@ietf.org 
>>>             > https://www.ietf.org/mailman/listinfo/netconf
>>>             
>>>             >
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------91506FC7964D2B80B377A1F0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k
eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8ZGl2IGNsYXNzPSJt
b3otY2l0ZS1wcmVmaXgiPk9uIDExLzEwLzIwMTcgNzoyMyBQTSwgQW5keSBCaWVybWFuDQog
ICAgICB3cm90ZTo8YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSINCmNpdGU9Im1pZDpDQUJDT0NIVEVYd2hBcTZOem9BR0hjQy1FRTE5YlhKMGticVBTMGh3
SkI1XytSdE9meWdAbWFpbC5nbWFpbC5jb20iPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0i
Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICAg
ICAgPGRpdiBkaXI9Imx0ciI+SGksDQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rp
dj4NCiAgICAgICAgPGRpdj5IZXJlIGFyZSBzb21lIHByb3Bvc2VkIGVkaXRzIHRvIG1ha2Ug
dGhlIGRhdGEgcnVsZQ0KICAgICAgICAgIGNvbnNpc3RlbnQgd2l0aCB0aGUgZXhhbXBsZXMu
PC9kaXY+DQogICAgICAgIDxkaXY+Tm90ZSB0aGF0IHRoaXMgaXNzdWUgaXMgbm90IHJlbGF0
ZWQgdG8gdGhlIGVkaXQgaW4gdGhlDQogICAgICAgICAgb3JpZ2luYWwgMS13ZWVrIGNoYW5n
ZS48L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICBUaGF0J3Mg
cmlnaHQsIGJ1dCB3ZSBmb3VuZCBhIHNvdXJjZSBvZiBtaXNpbnRlcnByZXRhdGlvbiBpbiB0
aGUNCiAgICBkcmFmdCBhbmQgeW91IGhhdmUgcmlnaHRseSBjb3JyZWN0ZWQgaXQgaW4gdGhl
IGdpdGh1YiB2OS48YnI+DQogICAgPGJyPg0KICAgIFJlZ2FyZHMsIEJlbm9pdDxicj4NCiAg
ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KY2l0ZT0ibWlkOkNBQkNPQ0hURVh3aEFxNk56
b0FHSGNDLUVFMTliWEowa2JxUFMwaHdKQjVfK1J0T2Z5Z0BtYWlsLmdtYWlsLmNvbSI+DQog
ICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2
Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+c2Vj
LiAzLjMuNTo8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAg
ICAgICA8ZGl2Pk9MRDo8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2
Pg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlIHJ1bGU6IMKgY29udHJvbHMg
YWNjZXNzIGZvciBhIHNwZWNpZmljDQogICAgICAgICAgICBkYXRhIG5vZGUsIGlkZW50aWZp
ZWQ8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGJ5IGl0cyBwYXRoIGxvY2F0aW9u
IHdpdGhpbiB0aGUgY29uY2VwdHVhbCBYTUwNCiAgICAgICAgICAgIGRvY3VtZW50IGZvciB0
aGU8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGRhdGEgbm9kZS48L2Rpdj4NCiAg
ICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pk5FVzo8L2Rpdj4N
CiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pg0KICAg
ICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlIHJ1bGU6IMKgY29udHJvbHMgYWNjZXNz
IGZvciBhIHNwZWNpZmljDQogICAgICAgICAgICBkYXRhIG5vZGUgYW5kIGl0cyBkZXNjZW5k
YW50cyw8L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGlkZW50aWZpZWQgYnkgaXRz
IHBhdGggbG9jYXRpb24gd2l0aGluIHRoZQ0KICAgICAgICAgICAgY29uY2VwdHVhbCBYTUwg
ZG9jdW1lbnQgZm9yIHRoZTwvZGl2Pg0KICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBu
b2RlLjwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAg
IDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxk
aXY+c2VjIDMuNC41LCBzdGVwIDYsIGJ1bGxldCAyOjwvZGl2Pg0KICAgICAgICA8ZGl2Pjxi
cj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4N
CiAgICAgICAgPGRpdj5PTEQ6PC9kaXY+DQogICAgICAgIDxkaXY+DQogICAgICAgICAgPGRp
dj48YnI+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj7CoCDCoCDCoCDCoCAq
IMKgVGhlIHJ1bGUgZG9lcyBub3QgaGF2ZSBhICJydWxlLXR5cGUiIGRlZmluZWQNCiAgICAg
ICAgICAgIG9yIHRoZSAicnVsZS08L2Rpdj4NCiAgICAgICAgICA8ZGl2PsKgIMKgIMKgIMKg
IMKgIMKgdHlwZSIgaXMgImRhdGEtbm9kZSIgYW5kIHRoZSAicGF0aCIgbWF0Y2hlcw0KICAg
ICAgICAgICAgdGhlIHJlcXVlc3RlZDwvZGl2Pg0KICAgICAgICAgIDxkaXY+wqAgwqAgwqAg
wqAgwqAgwqBkYXRhIG5vZGUsIGFjdGlvbiBub2RlLCBvciBub3RpZmljYXRpb24gbm9kZS48
L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXY+DQogICAgICAgICAgPHByZSBj
bGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2lu
LXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+ICAgICAgPC9w
cmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQt
c2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6
cmdiKDAsMCwwKSI+DQo8L3ByZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdw
YWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4t
Ym90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj5ORVc6PC9wcmU+DQogICAgICAgICAgPHBy
ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFy
Z2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+DQo8L3By
ZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpy
Z2IoMCwwLDApIj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5
OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+
wqAgwqAgwqAgwqAgKiDCoFRoZSBydWxlIGRvZXMgbm90IGhhdmUgYSAicnVsZS10eXBlIiBk
ZWZpbmVkIG9yIHRoZSAicnVsZS08L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQs
MzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsO3doaXRl
LXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAgwqB0eXBlIiBpcyAiZGF0YS1ub2RlIiBh
bmQgdGhlICJwYXRoIiBtYXRjaGVzIHRoZSByZXF1ZXN0ZWQ8L2Rpdj48ZGl2IHN0eWxlPSJj
b2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1z
aXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAgwqBkYXRhIG5v
ZGUsIGFjdGlvbiBub2RlLCBvciBub3RpZmljYXRpb24gbm9kZS4gQSBwYXRoIGlzPC9kaXY+
PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5z
LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKg
IMKgIMKgY29uc2lkZXJlZCB0byBtYXRjaCBpZiB0aGUgY3VycmVudCBkYXRhIG5vZGUgaXMg
dGhlIGRhdGEgbm9kZTwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9u
dC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7d2hpdGUtc3BhY2U6
bm9ybWFsIj7CoCDCoCDCoCDCoCDCoCDCoHNwZWNpZmllZCBieSB0aGUgcGF0aCwgb3IgaXMg
YSBkZXNjZW5kYW50IGRhdGEgbm9kZSBvZiB0aGlzIGRhdGEgbm9kZS48L2Rpdj48L3ByZT4N
CiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl
OjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2Io
MCwwLDApIj4NCjwvcHJlPg0KICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2Ui
IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0
b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAgICAgICAgPHByZSBjbGFz
cz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRv
cDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+YXBwZW5kaXggQi40
OiAoMiBidWdzIGluIGV4cGxhbmF0aW9uKTwvcHJlPg0KICAgICAgICAgIDxwcmUgY2xhc3M9
ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6
MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAg
ICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4z
MzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCww
KSI+T0xEOjwvcHJlPg0KICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0
eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206
MHB4O2NvbG9yOnJnYigwLDAsMCkiPg0KPC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0i
Z21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4
Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMz
cHgiPiAgICAgIGRlbnktbmFjbTogIFRoaXMgcnVsZSBkZW5pZXMgdGhlICJndWVzdCIgZ3Jv
dXAgYW55IGFjY2VzcyB0byB0aGUNCiAgICAgICZsdDtuYWNtJmd0OyBzdWJ0cmVlLiAgTm90
ZSB0aGF0IHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBpcyBvbmx5DQogICAgICBhcHBsaWNhYmxl
IGJlY2F1c2UgdGhpcyBzdWJ0cmVlIGlzIGRlZmluZWQgaW4gdGhlIHNhbWUgbmFtZXNwYWNl
DQogICAgICBhcyB0aGUgJmx0O2RhdGEtcnVsZSZndDsgZWxlbWVudC4NCjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9
ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7
Y29sb3I6cmdiKDAsMCwwKSI+DQo8L3ByZT4NCiAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFp
bC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxm
b250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+
IDwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQogICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3
cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48cHJlIGNs
YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6
MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij5ORVc6PC9wcmU+
PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9u
dC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+DQo8
L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0iY29sb3I6cmdiKDAsMCww
KTtmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4
Ij4NCjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9w
OjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4gICAgICBkZW55LW5hY206ICBUaGlzIHJ1bGUg
ZGVuaWVzIHRoZSAiZ3Vlc3QiIGdyb3VwIGFueSBhY2Nlc3MgdG8gdGhlDQogICAgICAmbHQ7
bmFjbSZndDsgc3VidHJlZS4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21h
aWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48
Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgi
Pg0KPC9zcGFuPjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHls
ZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAw
MDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+DQo8L3NwYW4+PC9mb250
PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBw
eDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFz
cz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206
MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4z
MzMzcHgiPkFuZHk8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3Bh
Z2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29s
b3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdp
bi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48L3ByZT48
L3ByZT4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYgY2xhc3M9
ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P
biBGcmksIE5vdiAxMCwgMjAxNyBhdCA5OjI0IEFNLCBSb2JlcnQNCiAgICAgICAgICBXaWx0
b24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5j
b20iDQogICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy
dWUiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgd3JvdGU6
PGJyPg0KICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz
b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgIDxkaXYgdGV4dD0iIzAwMDAw
MCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgIDxwPjxicj4NCiAgICAgICAg
ICAgICAgPC9wPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDxkaXYgY2xh
c3M9Im1fOTA2NDgyODY5NDc3OTUzMjgzOG1vei1jaXRlLXByZWZpeCI+T24NCiAgICAgICAg
ICAgICAgICAxMC8xMS8yMDE3IDE2OjMzLCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KICAg
ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+DQogICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+PGJyPg0KICAgICAgICAgICAg
ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92IDEwLCAyMDE3IGF0DQog
ICAgICAgICAgICAgICAgICAgICAgODoxNiBBTSwgUm9iZXJ0IFdpbHRvbiA8c3BhbiBkaXI9
Imx0ciI+Jmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpy
d2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJf
YmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0
Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy
Z2luOjBweA0KICAgICAgICAgICAgICAgICAgICAgICAgMHB4IDBweCAwLjhleDtib3JkZXIt
bGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIw
NCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGJn
Y29sb3I9IiNGRkZGRkYiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY2xhc3M9Im1fOTA2NDgyODY5NDc3OTUzMjgzOGdtYWlsLW1fLTcz
NjE2NDcyODM1MjA0NTY2MzVtb3otY2l0ZS1wcmVmaXgiPk9uDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMTAvMTEvMjAxNyAxNTo0OSwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxkaXYgZGlyPSJsdHIiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIE5vdiAxMCwN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDE3IGF0IDU6MDcgQU0sIFBl
ciBIZWRlbGFuZCA8c3Bhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZGlyPSJsdHIiPiZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBocmVmPSJtYWlsdG86cGVyQHRhaWwtZi5jb20iDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnBlckB0YWlsLWYuY29t
PC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3Jv
dGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3Rl
IGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6
MWV4Ij5Pbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAxNy0xMS0x
MCAxMTo0MiwgUm9iZXJ0IFdpbHRvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IE9uIDEwLzExLzIw
MTcgMTA6MDIsIE1haGVzaA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
SmV0aGFuYW5kYW5pIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsg
TWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bWpl
dGhhbmFuZGFuaUBnbWFpbC5jb208L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
bWpldGhhbmFuZGFuaUBnbWFpbC5jbzx3YnI+bTwvYT4mZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsgT24gTm92IDEwLCAyMDE3LCBhdCAx
MDowNw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQU0sIEFuZHkgQmll
cm1hbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl
Zj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5dW1hd29ya3Mu
Y29tPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0
bzo8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWls
dG86YW5keUB5dW1hd29ya3MuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+
Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IEhpLDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBU
aGUgdGVybSAiZGF0YSBub2RlIiBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdXNlZCBpbiB0aGUgZG9jdW1lbnQgdG8gcmVmZXIgdG8gdGhlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3AtbGV2ZWwgbm9kZTxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBvZiB0aGUgc3BlY2lm
aWVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvYmplY3QsIG5vdCB0
aGUgZW50aXJlIHN1YnRyZWUgKGlmDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBhbnkpLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyBUaGUgZGF0YS1ydWxlIC9mb28gZG9lcw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbm90IG1hdGNoIC9mb28vY2hpbGQxIGluIHRoZSB0ZXh0DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxvdy48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhlIGNoaWxkIG5v
ZGVzIGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb21pdHRlZCBi
ZWNhdXNlIG9mIHN0ZXAgMTEuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7IFRoZSBhZG1pbiBoYXMgdG8NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0bHkgcGVybWl0IGluZGl2aWR1YWwgY2hpbGQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGVzIChvciBtb2R1bGVz
KS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsgVGhpcyBzZWVtcyBjb3JyZWN0IGlmDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0aGUgcmVhZC1kZWZhdWx0IGlzICJkZW55Ii48YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgU2hvdWxkIGFueSB0ZXh0IGJl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRlZCBvciBjaGFuZ2Vk
IHRvIG1ha2UgdGhpcyBtb3JlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjbGVhcj88YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
IEkgd291bGQgYWdyZWUgd2l0aCBSb2JlcnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRoYXQgaXQgd2FzIG5vdCBlbnRpcmVseSBjbGVhciB0aGF0DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlIGFwcGxpZWQgb24gdGhlIHBhcmVu
dCBkYXRhLW5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXMg
bm90IGFwcGx5IHRvIHRoZSBjaGlsZCBub2Rlcy4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFNvIHllcywgaXQgd291bGQgaGVscCB0byBjbGFyaWZ5IGl0Ljxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgV2Ugc2hvdWxkIGJl
IGRvaW5nIG1vcmUgdGhhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y2xhcmlmeWluZyBpdC7CoCBXZSBuZWVkIHRvIGZpeCBpdCBzbw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhhdCBpdCB3b3JrcyBpbiBhIHNlbnNpYmxlIHdheS7C
oA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSS5lLiB0byBtYWtlIHRo
ZSBub3JtYXRpdmUgdGV4dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uc2lzdGVudCB3aXRoIHRoZSBiZWhhdmlvdXINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGN1cnJlbnRseSBkZXNjcmliZWQgaW4gdGhlIGV4YW1wbGVzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbjxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFwcGVuZGl4IEIuNC48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBJZiB3ZSBmb2xsb3cgQW5keSdzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiB0aGF0IGEg
ZGF0YSBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2Vzbid0
IG1hdGNoIGNoaWxkIG5vZGVzIHRoZW4gdGhvc2UNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGV4YW1wbGVzIGFyZSBjb21wbGV0ZWx5IHdyb25nLsKgIEUuZy4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSA0dGggcnVsZSBpcyBkZXNj
cmliZWQgYXMgIlRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1
bGUgZ2l2ZXMgdGhlICdhZG1pbicgZ3JvdXANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHJlYWQtd3JpdGU8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7IGFjY2VzcyB0byBhbGwgYWNtZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmx0O2ludGVyZmFjZSZndDsgZW50cmllcy4iwqAgQnV0IElmDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcGF0aCBvbmx5IHN0cmlj
dGx5IG1hdGNoZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvYWNt
ZTppbnRlcmZhY2VzL2FjbWU6aW50ZXJmYTx3YnI+Y2UiDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0aGVuIHRoZSBhZG1pbiBncm91cCBydWxlIGFjaGlldmVzDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3RoaW5nIHVzZWZ1bCBhdCBh
bGwuwqAgVGhlIGFkbWluIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBub3QgZXZlbjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsgYWxsb3dlZCB0byBjcmVhdGUgYW4gaW50ZXJmYWNlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBiZWNhdXNlIHRoZXkgd291bGQgbm90IGV2ZW4gaGF2ZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVybWlzc2lvbiB0byB3cml0ZSB0
byB0aGUgbGlzdCBrZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdu
YW1lJyBub2RlIHJlcXVpcmVkIHRvIGNyZWF0ZSBhDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsaXN0IGVudHJ5IcKgIEluc3RlYWQsIGEgc2VwYXJhdGUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGUgd291bGQgYmUgcmVxdWlyZWQg
Zm9yIGV2ZXJ5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyBzaW5nbGUgcG9zc2libGUgc2NoZW1hIG5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHVuZGVyICIvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50ZXJmYTx3YnI+
Y2UiIcKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIHRo
YXQgdGhpcyBtYWtlcyAicGVybWl0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZGF0YS1ub2RlIHJ1bGVzIGNvbXBsZXRlbHkgdW51c2FibGUuPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgSSBzdHJvbmdseSBhZ3JlZSB3aXRoIHRoaXMsIGFuZCBJDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3VsZCBzYXkgdGhhdCBpdCBp
c24ndCBvbmx5IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2Fz
ZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciAicGVybWl0
IiBydWxlcyAtIGUuZy4gZGVueWluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc29tZSBhY2Nlc3MgdG8gYSBzdWJ0cmVlIG9mIHRoZSBkYXRhPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwgdGhhdCB3b3VsZCBvdGhlcndp
c2UgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBlcm1pdHRlZCBk
dWUgdG8gZGVmYXVsdHMgaXMgYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGxlYXN0IGFzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29tbW9uLCBhbmQgdGhlIHJ1bGVzIHdvdWxkIGJlIGp1c3QNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGFzIHVudXNhYmxlIGZvciB0aGF0Ljxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEJlc2lkZXMgdGhlIGV4YW1wbGVzLCBJIHRoaW5rIHRoYXQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSB2ZXJ5IHVzZSBvZiB0aGUg
dGVybSAibWF0Y2giLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRob3VnaCB1bmZvcnR1bmF0ZWx5IG5vdCBkZWZpbmVkLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3Ryb25nbHkgc3VnZ2VzdHMgdGhhdCBpdCBpcw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIgdGhhbiB1c2Ugb2YgZS5nLiB0aGUg
dGVybQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImlkZW50aWZ5IiB3
b3VsZCBpbXBseS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFkZGl0
aW9uYWxseSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlz
IHRleHQgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJ3BhdGgnIGxlYWYgaXMgY29uc2lzdGVudCB3aXRoIHRoZTxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGJlaW5nIGEgcHJl
Zml4IG1hdGNoOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIMKgIMKgVGhl
IHNwZWNpYWwgdmFsdWUgJy8nIHJlZmVycw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdG8gYWxsIHBvc3NpYmxlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqAgwqAgwqAgwqBkYXRhc3RvcmUgY29udGVudHMuIjs8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBGV0lXLCBvdXIgTkFDTSBpbXBsZW1lbnRhdGlvbiwNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF2YWlsYWJsZSB0byAoYW5kIHVz
ZWQgYnkpIGN1c3RvbWVyczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHNpbmNlIDIwMTIsIGZvbGxvd3MgdGhlIHByZWZpeCBtYXRjaA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbG9naWMsIGFuZCBJIGhhdmUgeWV0IHRvIGhlYXIg
b2Y8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbnkgdXNlciBl
eHBlY3RpbmcgaXQgdG8gZG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG90aGVyd2lzZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IFRvIGZpeCB0
aGlzIHByb3Blcmx5LCB3ZSBuZWVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0byBtYWtlIHRoZSBkYXRhLW5vZGUgcGF0aCBydWxlIGENCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHByZWZpeCBtYXRjaC7CoCBJbiBwYXJ0aWN1bGFyLCB3
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmVlZCB0ZXh0IHRoYXQg
c3BlY2lmaWVzOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IChpKSB0
aGF0IGEgZGF0YS1ub2RlIHBhdGggbWF0Y2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN1Y2NlZWRzIGlmIGl0IG1hdGNoZXMgdGhlIHBhdGgNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHByZWZpeCBmcm9tIHRoZSByb290IG9mIHRoZSB0
cmVlLsKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJLmUuIHNvIHRo
ZSBkYXRhLXJ1bGUgIi9mb28iIG1hdGNoZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICIvZm9vIiBhbmQgYWxsIG9mIGZvbydzIGRlc2NlbmRhbnQNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoaWxkcmVuIG5vZGVzLjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIFN0cm9uZ2x5IGFncmVlLjxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj5JIGRvIG5vdCBzZWUgaG93IHRoZSB0ZXh0IGNhbiBiZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0ZWQgdGhpcyB3
YXkuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90
ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICBCZWNhdXNlIG90aGVyd2lzZSB0aGUgcGF0aCBtYXRjaCBwYXJ0IG9mIHRoZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICBOQUNNIHNvbHV0aW9uIGlzIHJlYWxseSBicm9r
ZW4sIGFuZCB0aGUgcGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICBiYXNlZCBleGFt
cGxlcyBpbiB0aGUgYXBwZW5kaXggYXJlIGVudGlyZWx5DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIG1pc2xlYWRpbmcgYW5kIHdyb25nLsKgIFRoZSBvbmx5IHdheSB0aG9zZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICBleGFtcGxlcyBtYWtlIHNlbnNlIGlzIHRoZSBwYXRo
cyBtYXRjaA0KICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNjZW5kYW50IGNoaWxkcmVu
IG5vZGVzIGFzIHdlbGwuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8
L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg
PGRpdj5JTU8gdGhlIHRleHQgZG9lcyBub3Qgc3VwcG9ydCB0aGlzDQogICAgICAgICAgICAg
ICAgICAgICAgICBpbnRlcnByZXRhdGlvbi48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICBUaGUgZXhh
bXBsZXMgaW4gQi40LCBhbmQgdGhlIGRlZmluaXRpb24gb2YgIi8iIG1hdGNoaW5nDQogICAg
ICAgICAgICAgIGFsbCBub2RlcyBzdXBwb3J0cyB0aGlzIGludGVycHJldGF0aW9uLjxicj4N
CiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICBIZW5jZSwgbXkgb3BpbmlvbiBp
cyB0aGF0IGl0IGlzIHRoZSB0ZXh0IGluIDMuNC41IHRoYXQgaXMNCiAgICAgICAgICAgICAg
aW5jb3JyZWN0bHkgc3BlY2lmaWVkOyBhbmQgdGhhdCB0aGUgZXhhbXBsZXMsIGRlZmluaXRp
b24NCiAgICAgICAgICAgICAgb2YgIi8iIGFuZCBzdGFuZGFyZCBwcmFjdGljZSBhcmUgcmln
aHQuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIE90aGVyd2lzZSwg
aG93IGRpZCBJRVRGIG1hbmFnZSB0byBwdWJsaXNoIGFuIFJGQyB3aGVyZSB0aGUNCiAgICAg
ICAgICAgICAgcGF0aCBiYXNlZCBleGFtcGxlcyBhcmUgc28gY29tcGxldGVseSB3cm9uZz/C
oMKgIFdob2V2ZXINCiAgICAgICAgICAgICAgd3JvdGUgYW5kIHJldmlld2VkIHRob3NlIGV4
YW1wbGVzIGNsZWFybHkgaGFkIGEgZGlmZmVyZW50DQogICAgICAgICAgICAgIGludGVycHJl
dGF0aW9uIG9mIGhvdyB0aGVzZSBwYXRoIGJhc2VkIEFDTHMgd29ya2VkLiA8YnI+DQogICAg
ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICA8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4N
CiAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAg
ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAg
ICAgICAgIDxkaXY+VGhlcmUgaXMgbm90aGluZyBzYWlkIGFib3V0IGluaGVyaXRpbmcgc3Rh
dGUNCiAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gdGhlIHBhcmVudCBkYXRhIG5vZGUu
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIHRoaW5rIG5vIG1hdHRlciBo
b3cgdGhlIHBlcm1pc3Npb25zIGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgZGVyaXZl
ZCwgb25lIGNhbjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ZmluZCBleGFt
cGxlcyB0aGF0IHdvcmsgYmV0dGVyIG9yIHdvcnNlDQogICAgICAgICAgICAgICAgICAgICAg
ICBiZWNhdXNlIG9mIGl0LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIE5vLsKgIElmIHRoZSBydWxl
cyBhcHBseSB0byBkZXNjZW5kYW50IGNoaWxkcmVuLCBhbGwgbm9ybWFsDQogICAgICAgICAg
ICAgIGV4YW1wbGVzIHdvcmsgd2VsbCAoaW5jbHVkaW5nIHRoZSBvbmVzIGluIHRoZSBhcHBl
bmRpeCkuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAg
PGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9l
eHRyYSI+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4N
CiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PklNTyB0aGUgbnVtYmVyIG9mIHJ1bGVzIHJl
cXVpcmVkIHRvIGltcGxlbWVudA0KICAgICAgICAgICAgICAgICAgICAgICAgYSB1c2UtY2Fz
ZSBpcyBub3Q8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PnZlcnkgcmVsZXZh
bnQgb3Igb2JqZWN0aXZlIGNyaXRlcmlhLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIFllcyBpdCBp
cywgcGFydGljdWxhcmx5IHdoZW4gdGhlIGRpZmZlcmVuY2UgaXMgYmV0d2Vlbg0KICAgICAg
ICAgICAgICBuZWVkaW5nIGEgMSBsaW5lIHJ1bGUsIGFuZCBhIDEwMCsgbGluZSBydWxlLjxi
cj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAg
ICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAgICAg
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgIDxkaXY+VXNpbmcgdGhlIHByZXZpb3VzIGV4YW1wbGUgb2YgL2hvbWUgYW5kDQogICAg
ICAgICAgICAgICAgICAgICAgICAvaG9tZS91c2VyMSw8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2PmlmIHRoZSB1c2VyMSBpcyBnaXZlbiByZWFkIGFjY2VzcyB0byAvaG9t
ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gKGFjY29yZGluZyB0byB5b3UpPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5pdCBhbHNvIGhhcyByZWFkIGFjY2Vz
cyB0byBldmVyeSB1c2VyIHN1YnRyZWUNCiAgICAgICAgICAgICAgICAgICAgICAgIHVuZGVy
IC9ob21lLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8
L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
ICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgPGRp
diBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj5JbnN0ZWFkIG9m
IDEgcnVsZSBwZXIgdXNlciwgMiBydWxlcyBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAg
IG5lZWRlZDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8
L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgIE5vLCBqdXN0IDEgcnVsZSBwZXIgdXNlcjo8
YnI+DQogICAgICAgICAgICAgIMKgwqAgcmVhZC1kZWZhdWx0PWRlbnk8YnI+DQogICAgICAg
ICAgICAgIMKgwqAgZ3JvdXA9dXNlcjEsIHBhdGg9L2hvbWUvdXNlcjEsIGFjdGlvbj1wZXJt
aXQ8YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgVGhpcyBpcyBiZWNh
dXNlIG9mIG15IHR3byBwcm9wb3NlZCBjaGFuZ2VzOjxicj4NCiAgICAgICAgICAgICAgPGJy
Pg0KICAgICAgICAgICAgICAoaSkgdGhhdCBhIGRhdGEtbm9kZSBwYXRoIG1hdGNoIHN1Y2Nl
ZWRzIGlmIGl0IG1hdGNoZXMgdGhlDQogICAgICAgICAgICAgIHBhdGggcHJlZml4IGZyb20g
dGhlIHJvb3Qgb2YgdGhlIHRyZWUuwqAgSS5lLiBzbyB0aGUNCiAgICAgICAgICAgICAgZGF0
YS1ydWxlICIvZm9vIiBtYXRjaGVzICIvZm9vIiBhbmQgYWxsIG9mIGZvbydzDQogICAgICAg
ICAgICAgIGRlc2NlbmRhbnQgY2hpbGRyZW4gbm9kZXMuPGJyPg0KICAgICAgICAgICAgICAm
bHQ7LSBUaGlzIG1lYW5zIHRoYXQgeW91IG9ubHkgbmVlZCAxIGVudHJ5IGluc3RlYWQgb2Yg
MTAwDQogICAgICAgICAgICAgIGVudHJpZXMuPGJyPg0KICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgIChpaSkgaWYgYSBkYXRhLW5vZGUgcnVsZSBoYXMgYWN0aW9uICJwZXJt
aXQiIHRoZW4gaXQNCiAgICAgICAgICAgICAgaW1wbGljaXRseSBhbGxvd3MgcmVhZCBhY2Nl
c3MgZm9yIGFsbCBhbmNlc3RvciBwYXJlbnQNCiAgICAgICAgICAgICAgbm9kZXMgdXAgdG8g
dGhlIHJvb3QuwqAgKEkuZS4gdG8gbWl0aWdhdGUgdGhlIG9yaWdpbmFsDQogICAgICAgICAg
ICAgIGNoYW5nZSBwcm9wb3NlZCBvbiB0aGlzIHRocmVhZC4pPGJyPg0KICAgICAgICAgICAg
ICAmbHQ7LSBUaGlzIG1lYW5zIHRoYXQgeW91IGRvbid0IG5lZWQgYSBzZXBhcmF0ZSByZWFk
IHJ1bGUNCiAgICAgICAgICAgICAgZm9yICIvaG9tZSIuwqAgUmVhZCBhY2Nlc3MgdG8gdGhh
dCBub2RlIGl0IGlzIGltcGxpY2l0bHkNCiAgICAgICAgICAgICAgZ2l2ZW4gdmlhICJncm91
cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwgYWN0aW9uPXBlcm1pdCIsDQogICAgICAgICAg
ICAgIGhlbmNlIG1lYW5pbmcgdGhhdCB0aGUgcnVsZSB3b3JrcyB0aGUgc2FtZSB3YXkgYXMg
aXQgZG9lcw0KICAgICAgICAgICAgICBvbiBhbiByZmM2NTM2IGNvbXBsaWFudCBpbXBsZW1l
bnRhdGlvbi48YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQog
ICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAg
ICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICA8ZGl2PsKgIMKgcmVhZC1kZWZhdWx0PWRlbnk8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgZ3JvdXA9KiwgcGF0aD0vaG9tZSwgYWN0aW9u
PXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD11
c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlv
bj1wZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRo
ZSBhYm92ZSBydWxlcyB3b3VsZCBhbGxvdyBhY2Nlc3MgZm9yIGV2ZXJ5DQogICAgICAgICAg
ICAgICAgICAgICAgICB1c2VyIHRvIGV2ZXJ5IG90aGVyIHVzZXIuPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgPGRpdj5UaGUgMm5kIHJ1bGUgaGFzIG5vIGVmZmVjdCwgd2hpY2gg
aXMNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvdW50ZXItaW50dWl0aXZlLjwvZGl2Pg0K
ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+RXZlcnkgdXNlciBkaXIgd291bGQgbmVlZCAy
IHJ1bGVzPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqByZWFkLWRlZmF1bHQ9ZGVueTwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoGdyb3VwPSosIHBhdGg9L2hv
bWUsIGFjdGlvbj1wZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
wqAgwqBncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDwv
ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0qLCBwYXRoPS9o
b21lL3VzZXIxLCBhY3Rpb249ZGVueTxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0i
Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4DQogICAgICAgICAgICAgICAgICAgICAg
ICAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAgICAg
ICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdj5UaGVyZSBpcyBub3RoaW5nIHRoYXQgc2F5cyB0aGlz
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBob3cgaXQgd29ya3Mu
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JZiBpdCBk
aWQsIG9uY2UgY291bGQgbmV2ZXIgaGF2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcHJpdmlsZWdlZCBzdWItZmlvbGRlcnM8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2PsKgIMKgIMKgL3Zhci9sb2cgLSZndDsgcGVybWl0PC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoC92YXIvbG9nL2FwYWNoZTIgwqAt
Jmd0OyBkZW55PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxv
Y2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICBZZXMsIHlvdSBjYW4sIHlvdSBqdXN0IGxpc3QgdGhlIGxvbmdlc3Qg
cGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICBmaXJzdCBpbiB0aGUgbGlzdCBvZiBy
dWxlczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgwqAoMSnCoCAvdmFyL2xvZy9hcGFjaGUyIMKgLSZndDsgZGVueTxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgKDIpIC92YXIvbG9nIC0mZ3Q7IHBl
cm1pdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICBBbnkgcmVxdWVzdHMgdGhhdCBhdHRlbXB0IHRvIGFjY2VzcyBhbnl0
aGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlciAvdmFyL2xvZy9hcGFjaGUy
IHdvdWxkIG1hdGNoIHJ1bGUgKDEpDQogICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBi
ZSBkZW5pZWQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBBbnkgcmVxdWVzdHMg
dGhhdCBhdHRlbXB0IHRvIGFjY2VzcyBhbnl0aGluZw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICB1bmRlciAvdmFyL2xvZywgYnV0IG5vdCB1bmRlcg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAvdmFyL2xvZy9hcGFjaGUyLCB3b3VsZCBmYWlsIHRvIG1hdGNoIHJ1bGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgKDEpLCBidXQgd291bGQgbWF0Y2ggcnVsZSAoMikg
aW5zdGVhZCBhbmQgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgcGVybWl0dGVkLjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgPGRp
dj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg
ICAgICAgPGRpdj5JIGRvIG5vdCBzZWUgYW55IHRleHQgaW4gdGhlIGRyYWZ0IG9yIFJGQw0K
ICAgICAgICAgICAgICAgICAgICAgICAgNzk1MCB0aGF0PC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgPGRpdj5zdWdnZXN0cyB0aGF0IC92YXIvbG9nIGFuZCAvdmFyL2xvZy9hcGFj
aGUyDQogICAgICAgICAgICAgICAgICAgICAgICByZXByZXNlbnQgdGhlIHNhbWUgZGF0YSBu
b2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Js
b2NrcXVvdGU+DQogICAgICAgICAgICAgIFRoZXkgYXJlIGRpZmZlcmVudCBkYXRhIG5vZGVz
LCBidXQgSSBkb24ndCBzZWUgaG93IHRoYXQgaXMNCiAgICAgICAgICAgICAgcmVsZXZhbnQu
PGJyPg0KICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIFRoYW5rcyw8YnI+DQog
ICAgICAgICAgICAgIFJvYjxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICA8YnI+DQogICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAg
ICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgPGRpdiBjbGFz
cz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFp
bF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRp
dj5BbmR5PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoDwv
ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x
dW90ZSIgc3R5bGU9Im1hcmdpbjowcHgNCiAgICAgICAgICAgICAgICAgICAgICAgIDBweCAw
cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkDQogICAgICAgICAgICAgICAgICAgICAg
ICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90
ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46
MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuOGV4
O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgKGlpKSBpZiBhIGRhdGEtbm9kZSBydWxl
IGhhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uICJwZXJt
aXQiIHRoZW4gaXQgaW1wbGljaXRseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYWxsb3dzIHJlYWQgYWNjZXNzIGZvciBhbGwgYW5jZXN0b3INCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmVudCBub2RlcyB1cCB0byB0aGUgcm9vdC7C
oCAoSS5lLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gbWl0aWdh
dGUgdGhlIG9yaWdpbmFsIGNoYW5nZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcHJvcG9zZWQgb24gdGhpcyB0aHJlYWQuKTxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFRoaXMgc2VlbXMgcmVhc29uYWJsZSB0byBtZSwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGFsdGhvdWdoIEkgaGF2ZW4ndCBhdCB0aGlzIHBvaW50DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBldmFsdWF0ZWQ8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc3VnZ2VzdGlvbiBpbiBkZXRh
aWwuIEluIGFueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBJ
IHRoaW5rIHRoZSBtYWluIHBvaW50IGJvdGg8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICByZWdhcmRpbmcgdGhpcyBhbmQgdGhlIHByZWZpeCBtYXRjaA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgdGhhdCB0aGlzIHVwZGF0ZSB0
byA2NTM2IGNhbid0PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bWFrZSByYWRpY2FsIGNoYW5nZXMgdG8gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBzZW1hbnRpY3MgY29tcGFyZWQgdG8gYSAicmVhc29uYWJsZTxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGF0aW9uIiAoaGFy
ZCB0byBkZWZpbmUsIEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtu
b3cpIG9mIHRoZSB1bmRlci1zcGVjaWZpZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBvcmlnaW5hbC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlIHRleHQgZG9l
cyBub3Qgc2F5IHRoaXMgYXQgYWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBzbyBJIGRvIG5vdCBhcHByb3ZlIG9mIHRoaXMgY2hhbmdlPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBJbiB0aGUgUkZD
IHZlcnNpb24gb2YgdGhlIE5BQ00gdGhpcyB3YXNuJ3QNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgcmVxdWlyZWQgYmVjYXVzZSBvcGVyYXRpb24gJ25vbmUnIGRpZG4ndA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICByZXF1aXJlIHJlYWQgYWNjZXNzLsKgIE5vdyByZWFkIGFj
Y2VzcyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlZCBldmVuIGZvciBv
cGVyYXRpb24gJ25vbmUnLCB0aGVuIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
Y2hhbmdlIG1ha2VzIHNlbnNlIHRvIG1ha2UgdGhlIE5BQ00gY2hhbmdlcw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICBiYWNrd2FyZHMgY29tcGF0aWJsZSwgd2hpbHN0IHN0aWxsIGNs
b3NpbmcgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHNlY3VyaXR5IGhvbGUuPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIFJvYjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFz
cz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAtLVBlcjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj5BbmR5PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdj7CoDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xp
ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0
KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsgUm9iPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IFRoYW5rczxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IEFuZHk8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgT24g
VGh1LCBOb3YgOSwgMjAxNyBhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMjo0NCBBTSwgUm9iZXJ0IFdpbHRvbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2ls
dG9uQGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBIaSBBbmR5LDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSXQgaXNuJ3QgY2xlYXIg
dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lIHdoZXRoZXIgbWF0
Y2hpbmcgYSBwYXRoIGluIE5BQ00NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGVpdGhlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoChpKSBPbmx5IGFwcGxpZXMNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBzcGVjaWZpYyBub2RlLCBhbmQgbm90IGFu
eQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hpbGRyZW4sIG9yPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqAoaWkpIEFwcGxpZXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRoZSBzcGVjaWZpYyBub2RlIGFuZCBhbGwgZGVzY2VuZGFudA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hpbGRyZW4gbm9kZXMgYXMgd2VsbC48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDC
oCDCoEFzIGFuIGV4YW1wbGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB1c2luZyB0aGUgdHJlZSBiZWxvdy7CoCBpZiBJIGhhdmUgYQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcnVsZSB0aGF0IG1hdGNoZXMgcGF0aCAiQS9CIiB0aGVu
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2VzIHRoYXQgYXBwbHkg
dG8gb25seSB0aGUgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG5vZGUgIkEvQiIsIG9yIGRvZXMgaXQgYWxzbyBhcHBseSB0bw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYWxsIGRlc2NlbmRhbnQgY2hpbGRyZW4gb2YgIkEv
QiIgYXM8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDvCoCDCoCDCoHdlbGw/PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJbiByZmM2NTM2YmlzLTA4LA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VjdGlvbiAiMy40LjUuwqAgRGF0YSBOb2Rl
IEFjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFsaWRhdGlv
biIsIHN0ZXAgNiBzdGF0ZXM6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAqwqAgVGhlIHJ1bGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXMgbm90IGhhdmUgYSAicnVs
ZS10eXBlIiBkZWZpbmVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBv
ciB0aGUgInJ1bGUtPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHlwZSIgaXMNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJkYXRhLW5vZGUiIGFuZCB0aGUgKiJwYXRo
IiBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcmVx
dWVzdGVkIGRhdGEgbm9kZSosIGFjdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbm9kZSwgb3Igbm90aWZpY2F0aW9uIG5vZGUuPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBNeSByZWFkaW5n
IG9mIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIHRoYXQg
aXQgaW1wbGllcyB0aGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHBhdGggcnVsZSBpcw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKGkpLCBidXQgdGhpcyBpcyBub3QgaG93IEkgd291bGQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbGx5IGV4cGVjdCBh
biBBQ0wgcnVsZSB0byBhcHBseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaW4gYSB0cmVlIGxpa2Ugb2JqZWN0IChlLmcgYQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZGlyZWN0b3J5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBmaWxlIHN5c3RlbSkuPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBI
b3dldmVyLCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1w
bGVzIGluIEFwcGVuZGl4IEIuNC4gaW1wbHkgdGhhdA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGhlIHBhdGggcnVsZSBpcyB0byBiZSBpbnRlcnByZXRlZA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlrZSAoaWkpLCBvciBvdGhlcndp
c2UgdGhlIGV4YW1wbGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1
bGVzIHNlZW0gdG8gYmUgbW9zdGx5IHBvaW50bGVzcy48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEUuZy4gdGFraW5nIHRo
aXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1wbGUgZnJvbSBh
cHBlbmRpeCBCLjQ6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgJmx0O3J1bGUmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAg
wqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtuYW1l
Jmd0O3Blcm1pdC1kdW1teS1pbnRlcmZhY2UmbHQ7Lzx3YnI+bmFtZSZndDs8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoCAmbHQ7cGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgeG1sbnM6YWNtZT0iPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL25zL2l0ZiINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIj5odHRwOi8vZXhhbXBsZS5jb208d2JyPi9ucy9pdGY8L2E+Ig0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0OzxhDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pdGYiDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIg
dGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cDovL2V4YW1wbGUuY29tL25zL2l0ZjwvYT4m
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50ZXJmYWM8d2JyPmVbYWNt
ZTpuYW1lPSdkdW1teSddPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZsdDsvcGF0aCZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O2FjY2Vzcy1vcGVyYXRp
b25zJmd0O3JlYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVwZGF0
ZSZsdDsvYWNjZXNzLW9wZXJhdGlvbnMmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDthY3Rpb24mZ3Q7cGVybWl0Jmx0
Oy9hY3Rpb24mZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZsdDtjb21tZW50Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IEFsbG93DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgbGltaXRl
ZCBhbmQgZ3Vlc3QgZ3JvdXBzIHJlYWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVwZGF0ZSBhY2Nlc3MgdG8gdGhl
IGR1bW15DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcmZhY2Uu
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZsdDsvY29tbWVudCZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmx0Oy9ydWxlJmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSWYgdGhlIHJ1bGUg
aXMgKGkpwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gdGhl
IGFjY2VzcyBydWxlIGFsbG93cyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGNsaWVudCB0byByZWFkIHRoZSBzcGVjaWZpYyBub2RlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAiL2FjbWU6aW50ZXJmYWNlcy9hY21lOmludGVyZmE8
d2JyPmNlW2FjbWU6bmFtZT0nZHVtbXknXSINCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGJ1dCBub3QgYW55IGNoaWxkIGxlYWZzL2NvbnRhaW5lcnMNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIHRoYXQgaW50ZXJmYWNlLDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
dGhpcyBkb2Vzbid0IHNlZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVzZWZ1bC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDvCoCDCoCDCoEZ1cnRoZXIgY29tbWVudHMNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGlubGluZSBiZWxvdyAuLi48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoE9uIDA4LzExLzIwMTcN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwOjA1LCBBbmR5IEJpZXJt
YW4gd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgSGksPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoFRoaXMgY2hhbmdlIGhh
cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm8gaW1wYWN0IG9uIHRo
ZSBzZXJ2ZXIgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC9uYWNt
L3JlYWQtZGVmYXVsdCBpcyAicGVybWl0Ii48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqBJbiB0aGF0IGNhc2UsDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZXh0cmEgcmVhZCBydWxl
cyBmb3IgL0EgYW5kIC9BL0INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGFyZSBub3QgbmVlZGVkLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSSBhZ3JlZS48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqBBbiBvcGVyYXRv
cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd29ycmllZCBhYm91dCBy
ZWFkIGFjY2VzcyBzaG91bGQgc2V0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICByZWFkLWRlZmF1bHQgdG8gImRlbnkiLjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSSBhZ3JlZS7CoCBUaGlzIGlz
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2NlbmFyaW8gdGhh
dCBJJ20gY29uc2lkZXJpbmcuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgSW4gdGhhdCBjYXNlLA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhwbGljaXQgcnVsZXMgdG8gcmVhZCAvQSBh
bmQgL0EvQg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd291bGQgYmUg
bmVlZGVkPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0O8KgIMKgIMKgaW4gdGhlIG5ldw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgTkFDTS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFllcywgaWYgdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcyAoaSkN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFib3ZlLjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgT3Ro
ZXJ3aXNlIGlmIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50
ZXJwcmV0YXRpb24gaXMgKGlpKSB0aGVuIHlvdSBvbmx5DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBuZWVkICJyZWFkIC9BIiBzaW5jZSB0aGF0IGltcGxpZXMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkIEEvQiIgYXMgd2VsbCAo
YXMgbG9uZyBhcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1
bGVzIGFyZSBsaXN0ZWQgaW4gdGhlIGNvcnJlY3QNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG9yZGVyKS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqBUaGUgZGVueQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZXMgd291bGQgbm90IGJlIG5lZWRlZC48
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvC
oCDCoCDCoE9ubHkgaWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcyAoaSkNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGFib3ZlLsKgIEluIHdoaWNoIGNhc2UgdGhlwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkL3dyaXRlICdBL0IvSicgcnVs
ZSB3b3VsZCBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlIHN1
ZmZpY2llbnQuwqAgSXQgd291bGQgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG5lY2Vzc2FyeSB0byBkZWZpbmUgYW4gWHBhdGgNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4cHJlc3Npb25zIHRoYXQgY29udGFpbnM8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoGFs
bCBjaGlsZHJlbiBub2Rlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YXMgd2VsbC7CoCBQZXJoYXBzICdBL0IvSi8vKic/PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJZiB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGF0aW9uIG9mIHRoZSBydWxl
IGlzIChpaSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4geW91
IHdvdWxkIGFsc28gbmVlZCBhbGwgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBleHBsaWNpdCBkZW55IHN0YXRlbWVudHMgYXMgd2VsbCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyd2lzZSB0aGV5IHdvdWxkIGJlIGFsbG93
ZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSAicmVhZCAv
QSIgcnVsZSBhYm92ZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFJvYjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgIMKgQW5keTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgT24gV2VkLCBOb3YgOCwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTcgYXQgODozMyBBTSwgUm9iZXJ0IFdp
bHRvbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl
Zj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNv
bTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86
PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRv
OnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7
Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDvCoCDCoCDCoCDCoCDCoEhpLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXJlIGFib3V0IHRoaXMgY2hhbmdl
Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGF0IGZhbWlsaWFyIHdpdGggTkFDTSwgYnV0IGlmIHlvdQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2FudCB0byBnaXZlIGEgcGFydGlj
dWxhciBzZXQgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzZXJz
IHJlYWQvd3JpdGUgYWNjZXNzIHRvIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN1YnRyZWUsIGJ1dCBub3QgYWxsb3cgdGhlbSB0byBoYXZlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBhbnkgb3RoZXIgYWNjZXNzIHRvIHRoZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiBpbiB0aGU8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7wqAgwqAgwqAgwqAgwqBydW5uaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBkYXRhc3RvcmUgdGhlbiB3aXRoIHRoZSBleGlzdGluZw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgUkZDLCB0aGF0IGNvdWxkIGJlIGV4cHJlc3NlZCB3
aXRoIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpbmdsZSBydWxl
IChleGFtcGxlIGluIDY1MzZiaXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBhcHBlbmRpeCBCLjQpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFdpdGggdGhpcw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3IGNoYW5nZSwgSSB0aGluayB0
aGF0IHlvdSBtYXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWQg
dG8gY29uZmlndXJlIG1hbnkgbW9yZSBydWxlcyB0bw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYWNoaWV2ZSB0aGUgc2FtZSB0aGluZy7CoCBJIHRoaW5rDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHlvdSB3b3VsZCBuZWVkIHRv
IGdpdmUgcmVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXNz
IHRvIHRoZSB0b3Agbm9kZSBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGRlc2lyZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBwYXRoLCBhbmQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gc2VwYXJhdGUgZXhwbGljaXQgImRlbnki
IHJ1bGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3IgZXZlcnkg
c2libGluZyBjaGlsZCBub2RlIHdhbGtpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGZyb20gdGhlIHRvcCBvZiB0aGUgdHJlZSBkb3duIHRvIHRoZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGF0YSBub2RlIHRoYXQgcmVhZC93cml0
ZSBhY2Nlc3MgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdHVh
bGx5IGJlaW5nIGdpdmVuIHRvLsKgIFRoZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoGV4YW1wbGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlbG93IG1heSBleHBsYWluIG15
IHVuZGVyc3RhbmRpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJl
dHRlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgRS5nLiBGb3IgYQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdHJlZSBvZiBkYXRhIG5vZGVzLCByb290ZWQgYXQgQSwg
aWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlIHdhbnRlZCB0byBn
aXZlIHJlYWQvd3JpdGUgYWNjZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBvbmx5IHRvICJKIiBzdWJ0cmVlLCBhbmQgbm8gYWNjZXNzDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIHJlc3Qgb2YgdGhlIHRyZWUgdGhlbjo8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCBBPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDC
oCB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgfMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDC
oCDCoCB8wqAgwqAgwqB8wqAgwqAgwqB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
QsKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCBDwqAgwqAg
wqBEwqAgwqAgwqBFPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDC
oCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0t
LS0tLS08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgfMKgDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8wqAgfDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCBGwqAgwqBH
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEjCoCBKPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICDCoCB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC4uLjxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKg
IMKgIMKgSW4gdGhlIG9sZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bW9kZWwsIEkgdGhpbmsgdGhhdCB0aGUgQUNMIHJ1bGVzDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB3b3VsZCBiZSAxIHJ1bGVzIGxvbmcgKGFzc3VtaW5nDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0IGRlbnkgYWxsKTo8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICJyZWFkL3dyaXRlICdBL0IvSic8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgSW4gdGhlIG5ldw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwsIEkgdGhpbmsgdGhh
dCB0aGUgZXF1aXZhbGVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
QUNMIHJ1bGVzIHdvdWxkIG5lZWQgdG8gYmUgOCBydWxlcw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbG9uZyAoYXNzdW1pbmcgZGVmYXVsdCBkZW55IGFsbCk6PGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAicmVhZC93cml0ZSAnQS9CL0onPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJyZWFkIEEiPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEMiPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55
IEQiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEUiPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKg
ICJkZW55IEYiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55IEciPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKg
IMKgIMKgICJkZW55IEgiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE5vdGUsIEkgYW0NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFzc3VtaW5nIHRoYXQgYSAicGF0aCIg
cnVsZSBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3Ig
dGhlIGdpdmVuIHBhdGggYW5kIGFsbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZGVzY2VuZGFudCBub2Rlcy7CoCBUaGUgZHJhZnQgZG9lc24ndA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VlbSB0byBiZSBwYXJ0aWN1bGFybHkgY2xl
YXIgb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgcG9pbnQg
KGl0IHN0YXRlcyB0aGF0IHRoZSBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBhcHBsaWVzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgd2hlbiB0aGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGggbWF0Y2hlcywgYnV0IHRoaXMgd291bGQg
c2VlbSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgY291bnRl
ciBpbnR1aXRpdmUpLCBhbmQgcGVyaGFwcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaXQgY291bGQgYmUgY2xhcmlmaWVkLjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJ
ZiB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGFuZ2UgaXMg
YWxsb3dlZCwgdGhlbiB0aGUgZXhhbXBsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaW4gYXBwZW5kaXggQi40IGxvb2tzIGxpa2UgaXQgd291bGQNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWQgdG8gYmUgZml4ZWQsIHNpbmNlIHRo
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImxpbWl0ZWQtYWNsIiBw
cm9iYWJseSB3b3VsZG4ndCBnaXZlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBhbnkgYWNjZXNzIGF0IGFsbCwgdW5sZXNzIGRlZmF1bHQNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlYWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBhY2Nlc3MgaGFk
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWVuIGdpdmVuLjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7wqAgwqAgwqAgwqAgwqBCdXQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBwb3NzaWJseSBJJ20gbWlzdW5kZXJzdGFuZGluZyBob3cNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRoaXMgYWxsIHdvcmtzIcKgIElmIHNvLCBhcG9sb2dp
ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciB0aGUgbm9pc2Ug
Oi0pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBSb2I8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE9uDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwMi8xMS8yMDE3IDE0OjE4LCBCZW5vaXQgQ2xhaXNlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg
RGVhcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsLDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoCDCoEhlcmUgaXMNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGEgbWFqb3IgY2hhbmdlIGluDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcywNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Z2dlc3RlZCBieSB0aGUgU2VjdXJpdHkg
QUQgRXJpYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVzY29sYSBw
YXJ0IG9mIHRoZSBJRVNHIHJldmlldywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHdoaWNoIEkgd291bGQgbGlrZSB0byB2YWxpZGF0ZSB3aXRoDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgV0cuIFNlZTxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqA8YQ0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh
ZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0Ig0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9
InRydWUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmPHdicj5mP3VybDI9ZHJhZnQt
aWV0Zi1uZXRjb25mLXJmYzY8d2JyPjUzNmJpcy0wOC50eHQ8L2E+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCmhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2YmlzLTA4LnR4
dCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVy
cmVyIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL3Jm
Y2RpZjx3YnI+Zj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2PHdicj41MzZiaXMtMDgu
dHh0PC9hPiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIMKgJmx0O2RmcGNmaW9vbmRnZ2lwcGUucG5nJmd0Ozxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqAgwqAgwqAgwqBUaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIE5FVENPTkYgV0cgd2FzIGNjJ2VkIGZvciB0aGUgZW50aXJlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkaXNjdXNzaW9uLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqBXaGF0IGRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3Ug
dGhpbms/IEkgd2lsbCBkcmF3IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29uY2x1c2lvbnMgYnkgRnJpZGF5IE5vdiAxMHRoLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvC
oCDCoCDCoCDCoCDCoE5vdGU6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBJZiB0aGUgV0cgaXMgZmluZSwgdGhlIG5leHQgc3RlcCBpcw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdG8gYXBwcm92ZSB0aGlzIGRvY3VtZW50Ljxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqBSZWdhcmRzLCBCZW5vaXQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDC
oA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX19fPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDC
oCDCoCDCoE5ldGNvbmYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1h
aWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqA8YQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0i
dHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5ldGNv
bmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqA8YQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL25ldGNvbmY8L2E+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9uZXRjb25mPC9h
PiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBOZXRj
b25mIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29uZkBp
ZXRmLm9yZzwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtt
YWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0i
bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0
PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9sPHdicj5p
c3RpbmZvL25ldGNvbmY8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29t
Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFu
ayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvPHdicj5tPC9hPiZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19f
X19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29u
ZkBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiINCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIiB0YXJn
ZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2w8d2Jy
PmlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAg
ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvYmxvY2tx
dW90ZT4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxicj4NCiAgICAgIDwvZGl2Pg0KICAg
ICAgPGJyPg0KICAgICAgPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+
PC9maWVsZHNldD4NCiAgICAgIDxicj4NCiAgICAgIDxwcmUgd3JhcD0iIj5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5n
IGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0
bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1v
ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmY8L2E+DQo8L3ByZT4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0K
ICA8L2JvZHk+DQo8L2h0bWw+DQo=
--------------91506FC7964D2B80B377A1F0--


From nobody Wed Nov 22 05:34:52 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97A12943E; Wed, 22 Nov 2017 05:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql0sNjuaLdf9; Wed, 22 Nov 2017 05:34:47 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9001200FC; Wed, 22 Nov 2017 05:34:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128759; q=dns/txt; s=iport; t=1511357686; x=1512567286; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=oaXdOqwC6MlwquYeCLqg2XxmhJ0yYtlMrNWSUJiWc0Y=; b=YsmTy0Vbllxv3eNw9lN5nAKd0ia9AUp8PkwmFQUN2RKj0k6tGJyC3I+k CKw7E+Cpx8LGvMwiBlF41v52vmOGXZ5IgrCX9MwtWNjsE9tr8tqNvdnxi S6CD9AZavCqu73uZi0FIIw2SSh9vSDwMBVI2f8bpszCTZ2ynDYE1JbGIK A=;
X-Files: nacm.diff : 2542
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200";  d="diff'?scan'208,217";a="372956"
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; 22 Nov 2017 13:34:44 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAMDYiDP019601; Wed, 22 Nov 2017 13:34:44 GMT
To: Benoit Claise , Andy Bierman 
Cc: "sec-ads@ietf.org" , NETCONF 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>  
From: Robert Wilton 
Message-ID: 
Date: Wed, 22 Nov 2017 13:34:44 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/mixed; boundary="------------08A93BB611366AE7B91C5D61"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:34:51 -0000

This is a multi-part message in MIME format.
--------------08A93BB611366AE7B91C5D61
Content-Type: multipart/alternative;
 boundary="------------0D4EF8FA01DABC6EFA7357DE"


--------------0D4EF8FA01DABC6EFA7357DE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Benoit,

There is also one further, unrelated change that I am proposing is made 
the draft before it is published, to help better clarify the expected 
behavior.  It isn't the end of the world if this doesn't go in, but I 
think that it prevents sometime taking a different, but IMO reasonable, 
interpretation of how "when" statements are considered, and then having 
a future argument about what behavior it specified in the standard.

If we clarify it now, then it closes that door :-)

I've proposed text to Andy and Martin on Monday, but I've not heard back 
yet.

Netconf email with proposed text attached.  The text doesn't necessarily 
have to match this, but personally I think that it is useful if the 
draft says something on this.

Thanks,
Rob


On 22/11/2017 13:25, Benoit Claise wrote:
> On 11/10/2017 7:23 PM, Andy Bierman wrote:
>> Hi,
>>
>> Here are some proposed edits to make the data rule consistent with 
>> the examples.
>> Note that this issue is not related to the edit in the original 
>> 1-week change.
> That's right, but we found a source of misinterpretation in the draft 
> and you have rightly corrected it in the github v9.
>
> Regards, Benoit
>>
>>
>> sec. 3.3.5:
>>
>> OLD:
>>
>>
>>       data node rule:  controls access for a specific data node, 
>> identified
>>       by its path location within the conceptual XML document for the
>>       data node.
>>
>>
>> NEW:
>>
>>       data node rule:  controls access for a specific data node and 
>> its descendants,
>>       identified by its path location within the conceptual XML 
>> document for the
>>       data node.
>>
>>
>> sec 3.4.5, step 6, bullet 2:
>>
>>
>> OLD:
>>
>>         *  The rule does not have a "rule-type" defined or the "rule-
>>            type" is "data-node" and the "path" matches the requested
>>            data node, action node, or notification node.
>>        
>> NEW:
>>         *  The rule does not have a "rule-type" defined or the "rule-
>>            type" is "data-node" and the "path" matches the requested
>>            data node, action node, or notification node. A path is
>>            considered to match if the current data node is the data node
>>            specified by the path, or is a descendant data node of 
>> this data node.
>> appendix B.4: (2 bugs in explanation)
>> OLD:
>> deny-nacm: This rule denies the "guest" group any access to the 
>>  subtree. Note that the default namespace is only applicable 
>> because this subtree is defined in the same namespace as the 
>>  element.
>> NEW:
>> deny-nacm: This rule denies the "guest" group any access to the 
>>  subtree.
>> Andy
>>
>> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton > > wrote:
>>
>>
>>
>>     On 10/11/2017 16:33, Andy Bierman wrote:
>>>
>>>
>>>     On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>>>     > wrote:
>>>
>>>
>>>
>>>         On 10/11/2017 15:49, Andy Bierman wrote:
>>>>
>>>>
>>>>         On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
>>>>         > wrote:
>>>>
>>>>             On 2017-11-10 11:42, Robert Wilton wrote:
>>>>             >
>>>>             >
>>>>             > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>>             >>
>>>>             >>
>>>>             >>
>>>>             >>
>>>>             >> Mahesh Jethanandani
>>>>             >> mjethanandani@gmail.com
>>>>             
>>>>             >>>             >
>>>>             >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
>>>>             
>>>>             >>>             >> wrote:
>>>>             >>
>>>>             >>> Hi,
>>>>             >>>
>>>>             >>> The term "data node" is used in the document to
>>>>             refer to the top-level node
>>>>             >>> of the specified object, not the entire subtree (if
>>>>             any).
>>>>             >>>
>>>>             >>> The data-rule /foo does not match /foo/child1 in
>>>>             the text below.
>>>>             >>> The child nodes are omitted because of step 11.
>>>>             >>> The admin has to explicitly permit individual child
>>>>             nodes (or modules).
>>>>             >>> This seems correct if the read-default is "deny".
>>>>             >>>
>>>>             >>> Should any text be added or changed to make this
>>>>             more clear?
>>>>             >>
>>>>             >> I would agree with Robert that it was not entirely
>>>>             clear that rule applied on the parent data-node does
>>>>             not apply to the child nodes. So yes, it would help to
>>>>             clarify it.
>>>>             > We should be doing more than clarifying it.  We need
>>>>             to fix it so that it works in a sensible way.  I.e. to
>>>>             make the normative text consistent with the behaviour
>>>>             currently described in the examples in
>>>>             > the appendix B.4.
>>>>             >
>>>>             > If we follow Andy's interpretation that a data rule
>>>>             doesn't match child nodes then those examples are
>>>>             completely wrong.  E.g. the 4th rule is described as
>>>>             "This rule gives the 'admin' group read-write
>>>>             > access to all acme  entries."  But If the
>>>>             path only strictly matches
>>>>             "/acme:interfaces/acme:interface" then the admin group
>>>>             rule achieves nothing useful at all.  The admin is not even
>>>>             > allowed to create an interface because they would not
>>>>             even have permission to write to the list key 'name'
>>>>             node required to create a list entry!  Instead, a
>>>>             separate rule would be required for every
>>>>             > single possible schema node under
>>>>             "/acme:interfaces/acme:interface"! I think that this
>>>>             makes "permit" data-node rules completely unusable.
>>>>
>>>>             I strongly agree with this, and I would say that it
>>>>             isn't only the case
>>>>             for "permit" rules - e.g. denying some access to a
>>>>             subtree of the data
>>>>             model that would otherwise be permitted due to defaults
>>>>             is at least as
>>>>             common, and the rules would be just as unusable for that.
>>>>
>>>>             Besides the examples, I think that the very use of the
>>>>             term "match",
>>>>             though unfortunately not defined, strongly suggests
>>>>             that it is something
>>>>             other than use of e.g. the term "identify" would imply.
>>>>             Additionally,
>>>>             this text in the description of the 'path' leaf is
>>>>             consistent with the
>>>>             match being a prefix match:
>>>>
>>>>                    The special value '/' refers to all possible
>>>>                    datastore contents.";
>>>>
>>>>             FWIW, our NACM implementation, available to (and used
>>>>             by) customers
>>>>             since 2012, follows the prefix match logic, and I have
>>>>             yet to hear of
>>>>             any user expecting it to do otherwise.
>>>>
>>>>             > To fix this properly, we need to make the data-node
>>>>             path rule a prefix match.  In particular, we need text
>>>>             that specifies:
>>>>             >
>>>>             > (i) that a data-node path match succeeds if it
>>>>             matches the path prefix from the root of the tree. 
>>>>             I.e. so the data-rule "/foo" matches "/foo" and all of
>>>>             foo's descendant children nodes.
>>>>
>>>>             Strongly agree.
>>>>
>>>>
>>>>
>>>>         I do not see how the text can be interpreted this way.
>>>
>>>         Because otherwise the path match part of the NACM solution
>>>         is really broken, and the path based examples in the
>>>         appendix are entirely misleading and wrong.  The only way
>>>         those examples make sense is the paths match descendant
>>>         children nodes as well.
>>>
>>>
>>>
>>>     IMO the text does not support this interpretation.
>>     The examples in B.4, and the definition of "/" matching all nodes
>>     supports this interpretation.
>>
>>     Hence, my opinion is that it is the text in 3.4.5 that is
>>     incorrectly specified; and that the examples, definition of "/"
>>     and standard practice are right.
>>
>>     Otherwise, how did IETF manage to publish an RFC where the path
>>     based examples are so completely wrong? Whoever wrote and
>>     reviewed those examples clearly had a different interpretation of
>>     how these path based ACLs worked.
>>
>>
>>>     There is nothing said about inheriting state from the parent
>>>     data node.
>>>     I think no matter how the permissions are derived, one can
>>>     find examples that work better or worse because of it.
>>     No.  If the rules apply to descendant children, all normal
>>     examples work well (including the ones in the appendix).
>>
>>
>>>     IMO the number of rules required to implement a use-case is not
>>>     very relevant or objective criteria.
>>     Yes it is, particularly when the difference is between needing a
>>     1 line rule, and a 100+ line rule.
>>
>>>
>>>     Using the previous example of /home and /home/user1,
>>>     if the user1 is given read access to /home, then (according to you)
>>>     it also has read access to every user subtree under /home.
>>>     Instead of 1 rule per user, 2 rules are needed
>>     No, just 1 rule per user:
>>        read-default=deny
>>        group=user1, path=/home/user1, action=permit
>>
>>     This is because of my two proposed changes:
>>
>>     (i) that a data-node path match succeeds if it matches the path
>>     prefix from the root of the tree.  I.e. so the data-rule "/foo"
>>     matches "/foo" and all of foo's descendant children nodes.
>>     <- This means that you only need 1 entry instead of 100 entries.
>>
>>     (ii) if a data-node rule has action "permit" then it implicitly
>>     allows read access for all ancestor parent nodes up to the root. 
>>     (I.e. to mitigate the original change proposed on this thread.)
>>     <- This means that you don't need a separate read rule for
>>     "/home".  Read access to that node it is implicitly given via
>>     "group=user1, path=/home/user1, action=permit", hence meaning
>>     that the rule works the same way as it does on an rfc6536
>>     compliant implementation.
>>
>>>
>>>        read-default=deny
>>>        group=*, path=/home, action=permit
>>>        group=user1, path=/home/user1, action=permit
>>>
>>>     The above rules would allow access for every user to every other
>>>     user.
>>>     The 2nd rule has no effect, which is counter-intuitive.
>>>     Every user dir would need 2 rules
>>>
>>>        read-default=deny
>>>        group=*, path=/home, action=permit
>>>        group=user1, path=/home/user1, action=permit
>>>        group=*, path=/home/user1, action=deny
>>>
>>>>         There is nothing that says this is how it works.
>>>>         If it did, once could never have privileged sub-fiolders
>>>>
>>>>              /var/log -> permit
>>>>              /var/log/apache2  -> deny
>>>
>>>         Yes, you can, you just list the longest path first in the
>>>         list of rules:
>>>
>>>          (1)  /var/log/apache2  -> deny
>>>           (2) /var/log -> permit
>>>
>>>         Any requests that attempt to access anything under
>>>         /var/log/apache2 would match rule (1) and be denied.
>>>         Any requests that attempt to access anything under /var/log,
>>>         but not under /var/log/apache2, would fail to match rule
>>>         (1), but would match rule (2) instead and be permitted.
>>>
>>>
>>>
>>>     I do not see any text in the draft or RFC 7950 that
>>>     suggests that /var/log and /var/log/apache2 represent the same
>>>     data node.
>>     They are different data nodes, but I don't see how that is relevant.
>>
>>     Thanks,
>>     Rob
>>
>>
>>>
>>>
>>>     Andy
>>>
>>>>
>>>>
>>>>             > (ii) if a data-node rule has action "permit" then it
>>>>             implicitly allows read access for all ancestor parent
>>>>             nodes up to the root.  (I.e. to mitigate the original
>>>>             change proposed on this thread.)
>>>>
>>>>             This seems reasonable to me, although I haven't at this
>>>>             point evaluated
>>>>             the suggestion in detail. In any case I think the main
>>>>             point both
>>>>             regarding this and the prefix match is that this update
>>>>             to 6536 can't
>>>>             make radical changes to the semantics compared to a
>>>>             "reasonable
>>>>             interpretation" (hard to define, I know) of the
>>>>             under-specified
>>>>             original.
>>>>
>>>>
>>>>         The text does not say this at all so I do not approve of
>>>>         this change
>>>
>>>         In the RFC version of the NACM this wasn't required because
>>>         operation 'none' didn't require read access.  Now read
>>>         access is required even for operation 'none', then this
>>>         change makes sense to make the NACM changes backwards
>>>         compatible, whilst still closing the security hole.
>>>
>>>         Thanks,
>>>         Rob
>>>
>>>>
>>>>
>>>>             --Per
>>>>
>>>>
>>>>
>>>>         Andy
>>>>
>>>>             > Thanks,
>>>>             > Rob
>>>>             >
>>>>             >
>>>>             >>
>>>>             >> Thanks
>>>>             >>
>>>>             >>>
>>>>             >>>
>>>>             >>> Andy
>>>>             >>>
>>>>             >>>
>>>>             >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton
>>>>             
>>>>             >>
>>>>             wrote:
>>>>             >>>
>>>>             >>>     Hi Andy,
>>>>             >>>
>>>>             >>>     It isn't clear to me whether matching a path in
>>>>             NACM either:
>>>>             >>>       (i) Only applies to the specific node, and
>>>>             not any children, or
>>>>             >>>       (ii) Applies to the specific node and all
>>>>             descendant children nodes as well.
>>>>             >>>
>>>>             >>>     As an example, using the tree below.  if I have
>>>>             a rule that matches path "A/B" then does that apply to
>>>>             only the specific node "A/B", or does it also apply to
>>>>             all descendant children of "A/B" as
>>>>             >>>     well?
>>>>             >>>
>>>>             >>>     In rfc6536bis-08, section "3.4.5.  Data Node
>>>>             Access Validation", step 6 states:
>>>>             >>>
>>>>             >>>             *  The rule does not have a "rule-type"
>>>>             defined or the "rule-
>>>>             >>>                type" is "data-node" and the *"path"
>>>>             matches the requested data node*, action node, or
>>>>             notification node.
>>>>             >>>
>>>>             >>>
>>>>             >>>     My reading of this is that it implies that the
>>>>             interpretation of the path rule is (i), but this is not
>>>>             how I would normally expect an ACL rule to apply in a
>>>>             tree like object (e.g a directory
>>>>             >>>     file system).
>>>>             >>>
>>>>             >>>     However, the examples in Appendix B.4. imply
>>>>             that the path rule is to be interpreted like (ii), or
>>>>             otherwise the example rules seem to be mostly pointless.
>>>>             >>>
>>>>             >>>     E.g. taking this example from appendix B.4:
>>>>             >>>
>>>>             >>> 
>>>>             >>> permit-dummy-interface
>>>>             >>>              >>>             xmlns:acme="http://example.com/ns/itf
>>>>             " >
>>>>             >>> /acme:interfaces/acme:interface[acme:name='dummy']
>>>>             >>> 
>>>>             >>> read update
>>>>             >>> permit
>>>>             >>> 
>>>>             >>>                Allow the limited and guest groups read
>>>>             >>>                and update access to the dummy
>>>>             interface.
>>>>             >>> 
>>>>             >>> 
>>>>             >>>
>>>>             >>>
>>>>             >>>     If the rule is (i)  then the access rule allows
>>>>             the client to read the specific node
>>>>             "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>>             but not any child leafs/containers of that interface,
>>>>             >>>     this doesn't seem useful.
>>>>             >>>
>>>>             >>>     Further comments inline below ...
>>>>             >>>
>>>>             >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>             >>>>     Hi,
>>>>             >>>>
>>>>             >>>>     This change has no impact on the server if
>>>>             /nacm/read-default is "permit".
>>>>             >>>>     In that case, the extra read rules for /A and
>>>>             /A/B are not needed.
>>>>             >>>     I agree.
>>>>             >>>
>>>>             >>>>     An operator worried about read access should
>>>>             set read-default to "deny".
>>>>             >>>     I agree.  This is the scenario that I'm
>>>>             considering.
>>>>             >>>
>>>>             >>>>     In that case, explicit rules to read /A and
>>>>             /A/B would be needed
>>>>             >>>>     in the new NACM.
>>>>             >>>     Yes, if the interpretation of the rule is (i)
>>>>             above.
>>>>             >>>     Otherwise if the interpretation is (ii) then
>>>>             you only need "read /A" since that implies "read A/B"
>>>>             as well (as long as the rules are listed in the correct
>>>>             order).
>>>>             >>>
>>>>             >>>
>>>>             >>>>       The deny rules would not be needed.
>>>>             >>>     Only if the interpretation of the rule is (i)
>>>>             above.  In which case the "read/write 'A/B/J' rule
>>>>             would not be sufficient.  It would be necessary to
>>>>             define an Xpath expressions that contains
>>>>             >>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>>             >>>
>>>>             >>>     If the interpretation of the rule is (ii) then
>>>>             you would also need all the explicit deny statements as
>>>>             well, otherwise they would be allowed by the "read /A"
>>>>             rule above.
>>>>             >>>
>>>>             >>>     Thanks,
>>>>             >>>     Rob
>>>>             >>>
>>>>             >>>
>>>>             >>>>
>>>>             >>>>
>>>>             >>>>     Andy
>>>>             >>>>
>>>>             >>>>
>>>>             >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton
>>>>             
>>>>             >>
>>>>             wrote:
>>>>             >>>>
>>>>             >>>>         Hi,
>>>>             >>>>
>>>>             >>>>         I'm not sure about this change.
>>>>             >>>>
>>>>             >>>>         I'm not that familiar with NACM, but if
>>>>             you want to give a particular set of users read/write
>>>>             access to a subtree, but not allow them to have any
>>>>             other access to the configuration in the
>>>>             >>>>         running datastore then with the existing
>>>>             RFC, that could be expressed with a single rule
>>>>             (example in 6536bis, appendix B.4)
>>>>             >>>>
>>>>             >>>>         With this new change, I think that you may
>>>>             need to configure many more rules to achieve the same
>>>>             thing.  I think that you would need to give read access
>>>>             to the top node in the desired
>>>>             >>>>         path, and then separate explicit "deny"
>>>>             rules for every sibling child node walking from the top
>>>>             of the tree down to the data node that read/write
>>>>             access is actually being given to.  The
>>>>             >>>>         example below may explain my understanding
>>>>             better:
>>>>             >>>>
>>>>             >>>>         E.g. For a tree of data nodes, rooted at
>>>>             A, if we wanted to give read/write access only to "J"
>>>>             subtree, and no access for the rest of the tree then:
>>>>             >>>>
>>>>             >>>>         A
>>>>             >>>>         |
>>>>             >>>>  --------------------
>>>>             >>>>  |      |     |     |
>>>>             >>>>  B      C     D     E
>>>>             >>>>                 |
>>>>             >>>> -----------
>>>>             >>>>            |   | |  |
>>>>             >>>>            F   G H  J
>>>>             >>>>     |
>>>>             >>>>    ...
>>>>             >>>>
>>>>             >>>>
>>>>             >>>>         In the old model, I think that the ACL
>>>>             rules would be 1 rules long (assuming default deny all):
>>>>             >>>> "read/write 'A/B/J'
>>>>             >>>>
>>>>             >>>>         In the new model, I think that the
>>>>             equivalent ACL rules would need to be 8 rules long
>>>>             (assuming default deny all):
>>>>             >>>> "read/write 'A/B/J'
>>>>             >>>>            "read A"
>>>>             >>>>            "deny C"
>>>>             >>>>            "deny D"
>>>>             >>>>            "deny E"
>>>>             >>>>            "deny F"
>>>>             >>>>            "deny G"
>>>>             >>>>            "deny H"
>>>>             >>>>
>>>>             >>>>         Note, I am assuming that a "path" rule
>>>>             matches for the given path and all descendant nodes. 
>>>>             The draft doesn't seem to be particularly clear on this
>>>>             point (it states that the rule applies
>>>>             >>>>         when the path matches, but this would seem
>>>>             to be counter intuitive), and perhaps it could be
>>>>             clarified.
>>>>             >>>>
>>>>             >>>>         If this change is allowed, then the
>>>>             example in appendix B.4 looks like it would need to be
>>>>             fixed, since the "limited-acl" probably wouldn't give
>>>>             any access at all, unless default read
>>>>             >>>>         access had been given.
>>>>             >>>>
>>>>             >>>>         But, possibly I'm misunderstanding how
>>>>             this all works!  If so, apologies for the noise :-)
>>>>             >>>>
>>>>             >>>>         Thanks,
>>>>             >>>>         Rob
>>>>             >>>>
>>>>             >>>>
>>>>             >>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>>             >>>>>         Dear all,
>>>>             >>>>>
>>>>             >>>>>         Here is a major change in
>>>>             draft-ietf-netconf-rfc6536bis, suggested by the
>>>>             Security AD Eric Rescola part of the IESG review, which
>>>>             I would like to validate with the WG. See
>>>>             >>>>>
>>>>             https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>>>             
>>>>             >>>             >
>>>>             >>>>>
>>>>             >>>>>  
>>>>             >>>>>         The NETCONF WG was cc'ed for the entire
>>>>             discussion.
>>>>             >>>>>         What do you think? I will draw the
>>>>             conclusions by Friday Nov 10th.
>>>>             >>>>>
>>>>             >>>>>         Note: If the WG is fine, the next step is
>>>>             to approve this document.
>>>>             >>>>>
>>>>             >>>>>  Regards, Benoit
>>>>             >>>>>
>>>>             >>>>>
>>>>             >>>>>  _______________________________________________
>>>>             >>>>>  Netconf mailing list
>>>>             >>>>> Netconf@ietf.org 
>>>>             >
>>>>             >>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>             
>>>>             >>>             >
>>>>             >>>>
>>>>             >>>>
>>>>             >>>
>>>>             >>>
>>>>             >>> _______________________________________________
>>>>             >>> Netconf mailing list
>>>>             >>> Netconf@ietf.org 
>>>>             >
>>>>             >>> https://www.ietf.org/mailman/listinfo/netconf
>>>>             
>>>>             >>
>>>>             >> Mahesh Jethanandani
>>>>             >> mjethanandani@gmail.com
>>>>             
>>>>             >>>             >
>>>>             >
>>>>             >
>>>>             >
>>>>             > _______________________________________________
>>>>             > Netconf mailing list
>>>>             > Netconf@ietf.org 
>>>>             > https://www.ietf.org/mailman/listinfo/netconf
>>>>             
>>>>             >
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>


--------------0D4EF8FA01DABC6EFA7357DE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k
eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5IaSBCZW5vaXQs
PC9wPg0KICAgIDxwPlRoZXJlIGlzIGFsc28gb25lIGZ1cnRoZXIsIHVucmVsYXRlZCBjaGFu
Z2UgdGhhdCBJIGFtIHByb3Bvc2luZw0KICAgICAgaXMgbWFkZSB0aGUgZHJhZnQgYmVmb3Jl
IGl0IGlzIHB1Ymxpc2hlZCwgdG8gaGVscCBiZXR0ZXIgY2xhcmlmeQ0KICAgICAgdGhlIGV4
cGVjdGVkIGJlaGF2aW9yLsKgIEl0IGlzbid0IHRoZSBlbmQgb2YgdGhlIHdvcmxkIGlmIHRo
aXMNCiAgICAgIGRvZXNuJ3QgZ28gaW4sIGJ1dCBJIHRoaW5rIHRoYXQgaXQgcHJldmVudHMg
c29tZXRpbWUgdGFraW5nIGENCiAgICAgIGRpZmZlcmVudCwgYnV0IElNTyByZWFzb25hYmxl
LCBpbnRlcnByZXRhdGlvbiBvZiBob3cgIndoZW4iDQogICAgICBzdGF0ZW1lbnRzIGFyZSBj
b25zaWRlcmVkLCBhbmQgdGhlbiBoYXZpbmcgYSBmdXR1cmUgYXJndW1lbnQgYWJvdXQNCiAg
ICAgIHdoYXQgYmVoYXZpb3IgaXQgc3BlY2lmaWVkIGluIHRoZSBzdGFuZGFyZC48YnI+DQog
ICAgPC9wPg0KICAgIDxwPklmIHdlIGNsYXJpZnkgaXQgbm93LCB0aGVuIGl0IGNsb3NlcyB0
aGF0IGRvb3IgOi0pPC9wPg0KICAgIDxwPkkndmUgcHJvcG9zZWQgdGV4dCB0byBBbmR5IGFu
ZCBNYXJ0aW4gb24gTW9uZGF5LCBidXQgSSd2ZSBub3QNCiAgICAgIGhlYXJkIGJhY2sgeWV0
LjwvcD4NCiAgICA8cD5OZXRjb25mIGVtYWlsIHdpdGggcHJvcG9zZWQgdGV4dCBhdHRhY2hl
ZC7CoCBUaGUgdGV4dCBkb2Vzbid0DQogICAgICBuZWNlc3NhcmlseSBoYXZlIHRvIG1hdGNo
IHRoaXMsIGJ1dCBwZXJzb25hbGx5IEkgdGhpbmsgdGhhdCBpdCBpcw0KICAgICAgdXNlZnVs
IGlmIHRoZSBkcmFmdCBzYXlzIHNvbWV0aGluZyBvbiB0aGlzLjxicj4NCiAgICA8L3A+DQog
ICAgVGhhbmtzLDxicj4NCiAgICBSb2I8YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAgICA8
ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDIyLzExLzIwMTcgMTM6MjUsIEJlbm9p
dCBDbGFpc2UNCiAgICAgIHdyb3RlOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOmU0MThlMDA3LWZiYWMtMDI5ZC05Yzc3
LWVkMzNkZjNkMjMzYkBjaXNjby5jb20iPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29u
dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICAgICAg
PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMS8xMC8yMDE3IDc6MjMgUE0sIEFu
ZHkgQmllcm1hbg0KICAgICAgICB3cm90ZTo8YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6Q0FCQ09DSFRFWHdoQXE2TnpvQUdI
Y0MtRUUxOWJYSjBrYnFQUzBod0pCNV8rUnRPZnlnQG1haWwuZ21haWwuY29tIj4NCiAgICAg
ICAgPGRpdiBkaXI9Imx0ciI+SGksDQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgPGRpdj5IZXJlIGFyZSBzb21lIHByb3Bvc2VkIGVkaXRzIHRv
IG1ha2UgdGhlIGRhdGEgcnVsZQ0KICAgICAgICAgICAgY29uc2lzdGVudCB3aXRoIHRoZSBl
eGFtcGxlcy48L2Rpdj4NCiAgICAgICAgICA8ZGl2Pk5vdGUgdGhhdCB0aGlzIGlzc3VlIGlz
IG5vdCByZWxhdGVkIHRvIHRoZSBlZGl0IGluIHRoZQ0KICAgICAgICAgICAgb3JpZ2luYWwg
MS13ZWVrIGNoYW5nZS48L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Jsb2NrcXVv
dGU+DQogICAgICBUaGF0J3MgcmlnaHQsIGJ1dCB3ZSBmb3VuZCBhIHNvdXJjZSBvZiBtaXNp
bnRlcnByZXRhdGlvbiBpbiB0aGUNCiAgICAgIGRyYWZ0IGFuZCB5b3UgaGF2ZSByaWdodGx5
IGNvcnJlY3RlZCBpdCBpbiB0aGUgZ2l0aHViIHY5Ljxicj4NCiAgICAgIDxicj4NCiAgICAg
IFJlZ2FyZHMsIEJlbm9pdDxicj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpj
aXRlPSJtaWQ6Q0FCQ09DSFRFWHdoQXE2TnpvQUdIY0MtRUUxOWJYSjBrYnFQUzBod0pCNV8r
UnRPZnlnQG1haWwuZ21haWwuY29tIj4NCiAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAg
ICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+
DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj5zZWMuIDMuMy41OjwvZGl2Pg0K
ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxkaXY+
T0xEOjwvZGl2Pg0KICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgIDxkaXY+DQogICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCBkYXRhIG5vZGUgcnVsZTogwqBjb250cm9s
cyBhY2Nlc3MgZm9yIGEgc3BlY2lmaWMNCiAgICAgICAgICAgICAgZGF0YSBub2RlLCBpZGVu
dGlmaWVkPC9kaXY+DQogICAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGJ5IGl0cyBwYXRoIGxv
Y2F0aW9uIHdpdGhpbiB0aGUgY29uY2VwdHVhbCBYTUwNCiAgICAgICAgICAgICAgZG9jdW1l
bnQgZm9yIHRoZTwvZGl2Pg0KICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCBkYXRhIG5vZGUu
PC9kaXY+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgPC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgPGRpdj5ORVc6PC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0
YSBub2RlIHJ1bGU6IMKgY29udHJvbHMgYWNjZXNzIGZvciBhIHNwZWNpZmljDQogICAgICAg
ICAgICAgIGRhdGEgbm9kZSBhbmQgaXRzIGRlc2NlbmRhbnRzLDwvZGl2Pg0KICAgICAgICAg
ICAgPGRpdj7CoCDCoCDCoCBpZGVudGlmaWVkIGJ5IGl0cyBwYXRoIGxvY2F0aW9uIHdpdGhp
biB0aGUNCiAgICAgICAgICAgICAgY29uY2VwdHVhbCBYTUwgZG9jdW1lbnQgZm9yIHRoZTwv
ZGl2Pg0KICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCBkYXRhIG5vZGUuPC9kaXY+DQogICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj5z
ZWMgMy40LjUsIHN0ZXAgNiwgYnVsbGV0IDI6PC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+
DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgPGRpdj5PTEQ6PC9kaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAg
ICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2
PsKgIMKgIMKgIMKgICogwqBUaGUgcnVsZSBkb2VzIG5vdCBoYXZlIGEgInJ1bGUtdHlwZSIg
ZGVmaW5lZA0KICAgICAgICAgICAgICBvciB0aGUgInJ1bGUtPC9kaXY+DQogICAgICAgICAg
ICA8ZGl2PsKgIMKgIMKgIMKgIMKgIMKgdHlwZSIgaXMgImRhdGEtbm9kZSIgYW5kIHRoZSAi
cGF0aCIgbWF0Y2hlcw0KICAgICAgICAgICAgICB0aGUgcmVxdWVzdGVkPC9kaXY+DQogICAg
ICAgICAgICA8ZGl2PsKgIMKgIMKgIMKgIMKgIMKgZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwg
b3Igbm90aWZpY2F0aW9uDQogICAgICAgICAgICAgIG5vZGUuPC9kaXY+DQogICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWls
LW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21h
cmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPiAgICAgIDwvcHJlPg0KICAgICAg
ICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4z
MzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCww
KSI+TkVXOjwvcHJlPg0KICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIg
c3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0
KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1z
cGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgICogwqBUaGUgcnVsZSBkb2VzIG5vdCBoYXZlIGEg
InJ1bGUtdHlwZSIgZGVmaW5lZCBvciB0aGUgInJ1bGUtPC9kaXY+PGRpdiBzdHlsZT0iY29s
b3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6
ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgIMKgIMKgdHlwZSIgaXMg
ImRhdGEtbm9kZSIgYW5kIHRoZSAicGF0aCIgbWF0Y2hlcyB0aGUgcmVxdWVzdGVkPC9kaXY+
PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5z
LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKg
IMKgIMKgZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwgb3Igbm90aWZpY2F0aW9uIG5vZGUuIEEg
cGF0aCBpczwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1mYW1p
bHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7d2hpdGUtc3BhY2U6bm9ybWFs
Ij7CoCDCoCDCoCDCoCDCoCDCoGNvbnNpZGVyZWQgdG8gbWF0Y2ggaWYgdGhlIGN1cnJlbnQg
ZGF0YSBub2RlIGlzIHRoZSBkYXRhIG5vZGU8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2Io
MzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs
O3doaXRlLXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAgwqBzcGVjaWZpZWQgYnkgdGhl
IHBhdGgsIG9yIGlzIGEgZGVzY2VuZGFudCBkYXRhIG5vZGUgb2YgdGhpcyBkYXRhIG5vZGUu
PC9kaXY+PC9wcmU+DQogICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBz
dHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t
OjBweDtjb2xvcjpyZ2IoMCwwLDApIj5hcHBlbmRpeCBCLjQ6ICgyIGJ1Z3MgaW4gZXhwbGFu
YXRpb24pPC9wcmU+DQogICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBz
dHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t
OjBweDtjb2xvcjpyZ2IoMCwwLDApIj5PTEQ6PC9wcmU+DQogICAgICAgICAgICA8cHJlIGNs
YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz
LjMzMzNweCI+ICAgICAgZGVueS1uYWNtOiAgVGhpcyBydWxlIGRlbmllcyB0aGUgImd1ZXN0
IiBncm91cCBhbnkgYWNjZXNzIHRvIHRoZQ0KICAgICAgJmx0O25hY20mZ3Q7IHN1YnRyZWUu
ICBOb3RlIHRoYXQgdGhlIGRlZmF1bHQgbmFtZXNwYWNlIGlzIG9ubHkNCiAgICAgIGFwcGxp
Y2FibGUgYmVjYXVzZSB0aGlzIHN1YnRyZWUgaXMgZGVmaW5lZCBpbiB0aGUgc2FtZSBuYW1l
c3BhY2UNCiAgICAgIGFzIHRoZSAmbHQ7ZGF0YS1ydWxlJmd0OyBlbGVtZW50Lg0KPC9zcGFu
PjwvZm9udD48L3ByZT4NCiAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2Ui
IHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9
IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4gPC9zcGFuPjwv
Zm9udD48L3ByZT4NCiAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0
eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PHByZSBjbGFzcz0iZ21h
aWwtbmV3cGFnZSIgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjEzLjMzMzNw
eDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+TkVXOjwvcHJlPjxwcmUgY2xh
c3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9t
OjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu
MzMzM3B4Ij4gICAgICBkZW55LW5hY206ICBUaGlzIHJ1bGUgZGVuaWVzIHRoZSAiZ3Vlc3Qi
IGdyb3VwIGFueSBhY2Nlc3MgdG8gdGhlDQogICAgICAmbHQ7bmFjbSZndDsgc3VidHJlZS4N
Cjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9
Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAw
MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48
L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7
bWFyZ2luLWJvdHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEzLjMzMzNweCI+DQo8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9
ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBw
eCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIg
c3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0i
IzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPkFuZHk8L3NwYW4+
PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4t
dG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1i
b3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48L3ByZT48L3ByZT4NCiAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh
Ij48YnI+DQogICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92
IDEwLCAyMDE3IGF0IDk6MjQgQU0sDQogICAgICAgICAgICBSb2JlcnQgV2lsdG9uIDxzcGFu
IGRpcj0ibHRyIj4mbHQ7PGENCiAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cndpbHRv
bkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4NCiAgICAg
ICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFp
bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgICAuOGV4O2JvcmRl
ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAg
ICA8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICAgICAg
ICAgIDxwPjxicj4NCiAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAgICAgICAgPGJy
Pg0KICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9Im1fOTA2NDgyODY5NDc3OTUzMjgzOG1v
ei1jaXRlLXByZWZpeCI+T24NCiAgICAgICAgICAgICAgICAgIDEwLzExLzIwMTcgMTY6MzMs
IEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAg
ICA8ZGl2IGRpcj0ibHRyIj48YnI+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9
ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPk9uIEZyaSwgTm92IDEwLCAyMDE3IGF0DQogICAgICAgICAgICAgICAg
ICAgICAgICA4OjE2IEFNLCBSb2JlcnQgV2lsdG9uIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj
by5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiIG1v
ei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4N
CiAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8cD48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBj
bGFzcz0ibV85MDY0ODI4Njk0Nzc5NTMyODM4Z21haWwtbV8tNzM2MTY0NzI4MzUyMDQ1NjYz
NW1vei1jaXRlLXByZWZpeCI+T24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEw
LzExLzIwMTcgMTU6NDksIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2IGRpcj0ibHRyIj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTm92DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMCwgMjAxNyBhdCA1OjA3IEFNLCBQZXIg
SGVkZWxhbmQgPHNwYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZGlyPSJsdHIiPiZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGhyZWY9Im1haWx0bzpwZXJAdGFpbC1mLmNvbSINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnBlckB0YWls
LWYuY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIw
NCk7cGFkZGluZy1sZWZ0OjFleCI+T24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMjAxNy0xMS0xMCAxMTo0MiwgUm9iZXJ0IFdpbHRvbg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsgT24gMTAvMTEvMjAxNyAxMDowMiwgTWFoZXNoDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpldGhhbmFuZGFuaSB3cm90ZTo8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyBNYWhlc2ggSmV0aGFuYW5k
YW5pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1h
aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRh
bmlAZ21haWwuY29tPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
bWpldGhhbmFuZGFuaUBnbWFpbC5jbzx3YnI+bTwvYT4mZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyBPbiBOb3YgMTAsIDIwMTcsIGF0
IDEwOjA3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFNLCBBbmR5
IEJpZXJtYW4gJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmFuZHlA
eXVtYXdvcmtzLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmx0O21haWx0bzo8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5hbmR5
QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7IEhpLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhlIHRlcm0gImRhdGEgbm9kZSINCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgdXNlZCBpbiB0aGUgZG9jdW1l
bnQgdG8gcmVmZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8g
dGhlIHRvcC1sZXZlbCBub2RlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsgb2YgdGhlIHNwZWNpZmllZA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBvYmplY3QsIG5vdCB0aGUgZW50aXJlIHN1YnRyZWUg
KGlmDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFueSkuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBU
aGUgZGF0YS1ydWxlIC9mb28NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZG9lcyBub3QgbWF0Y2ggL2Zvby9jaGlsZDEgaW4gdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRleHQgYmVsb3cuPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhlIGNoaWxkIG5vZGVzIGFy
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbWl0dGVkIGJlY2F1
c2Ugb2Ygc3RlcCAxMS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0OyBUaGUgYWRtaW4gaGFzIHRvDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0bHkgcGVybWl0IGluZGl2aWR1YWwgY2hpbGQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9kZXMgKG9yIG1vZHVs
ZXMpLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7IFRoaXMgc2VlbXMgY29ycmVjdCBpZg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGUgcmVhZC1kZWZhdWx0IGlzICJkZW55Ii48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IFNob3VsZCBh
bnkgdGV4dCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZGRl
ZCBvciBjaGFuZ2VkIHRvIG1ha2UgdGhpcyBtb3JlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNsZWFyPzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7IEkgd291bGQgYWdyZWUgd2l0aCBSb2JlcnQNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBpdCB3YXMgbm90IGVudGlyZWx5
IGNsZWFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgcnVs
ZSBhcHBsaWVkIG9uIHRoZSBwYXJlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZGF0YS1ub2RlIGRvZXMgbm90IGFwcGx5IHRvIHRoZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBjaGlsZCBub2Rlcy4gU28geWVzLCBpdCB3b3Vs
ZCBoZWxwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGNsYXJp
ZnkgaXQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
IFdlIHNob3VsZCBiZSBkb2luZyBtb3JlIHRoYW4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY2xhcmlmeWluZyBpdC7CoCBXZSBuZWVkIHRvIGZpeCBpdA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzbyB0aGF0IGl0IHdvcmtzIGlu
IGEgc2Vuc2libGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2F5
LsKgIEkuZS4gdG8gbWFrZSB0aGUgbm9ybWF0aXZlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRleHQgY29uc2lzdGVudCB3aXRoIHRoZSBiZWhhdmlvdXINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VycmVudGx5IGRlc2NyaWJl
ZCBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhhbXBs
ZXMgaW48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsg
dGhlIGFwcGVuZGl4IEIuNC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsgSWYgd2UgZm9sbG93IEFuZHkncw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpbnRlcnByZXRhdGlvbiB0aGF0IGEgZGF0YSBydWxlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXNuJ3QgbWF0Y2ggY2hpbGQgbm9kZXMg
dGhlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aG9zZSBleGFt
cGxlcyBhcmUgY29tcGxldGVseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB3cm9uZy7CoCBFLmcuIHRoZSA0dGggcnVsZSBpcw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBkZXNjcmliZWQgYXMgIlRoaXMgcnVsZSBnaXZlcyB0aGUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2FkbWluJyBncm91cCBy
ZWFkLXdyaXRlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7IGFjY2VzcyB0byBhbGwgYWNtZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmbHQ7aW50ZXJmYWNlJmd0OyBlbnRyaWVzLiLCoCBCdXQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgdGhlIHBhdGggb25seSBzdHJpY3RseSBt
YXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvYWNtZTpp
bnRlcmZhY2VzL2FjbWU6aW50ZXJmYTx3YnI+Y2UiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZW4gdGhlIGFkbWluIGdyb3VwIHJ1bGUgYWNoaWV2ZXMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90aGluZyB1c2VmdWwgYXQg
YWxsLsKgIFRoZSBhZG1pbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpcyBub3QgZXZlbjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyBhbGxvd2VkIHRvIGNyZWF0ZSBhbg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBpbnRlcmZhY2UgYmVjYXVzZSB0aGV5IHdvdWxkIG5vdA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBldmVuIGhhdmUgcGVybWlzc2lvbiB0
byB3cml0ZSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUg
bGlzdCBrZXkgJ25hbWUnIG5vZGUgcmVxdWlyZWQNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdG8gY3JlYXRlIGEgbGlzdCBlbnRyeSHCoCBJbnN0ZWFkLA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIHNlcGFyYXRlIHJ1bGUgd291
bGQgYmUgcmVxdWlyZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Zm9yIGV2ZXJ5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7IHNpbmdsZSBwb3NzaWJsZSBzY2hlbWEgbm9kZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1bmRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiL2FjbWU6aW50ZXJmYWNlcy9hY21lOmludGVyZmE8d2JyPmNlIiHCoA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIHRoYXQgdGhpcyBt
YWtlcyAicGVybWl0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk
YXRhLW5vZGUgcnVsZXMgY29tcGxldGVseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB1bnVzYWJsZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
SSBzdHJvbmdseSBhZ3JlZSB3aXRoIHRoaXMsIGFuZCBJDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHdvdWxkIHNheSB0aGF0IGl0IGlzbid0IG9ubHkgdGhlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhc2U8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciAicGVybWl0IiBydWxlcyAtIGUu
Zy4gZGVueWluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb21l
IGFjY2VzcyB0byBhIHN1YnRyZWUgb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRhdGE8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1vZGVsIHRoYXQgd291bGQgb3RoZXJ3aXNlIGJlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHBlcm1pdHRlZCBkdWUgdG8gZGVmYXVsdHMgaXMgYXQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVhc3QgYXM8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbW1vbiwgYW5kIHRoZSBy
dWxlcyB3b3VsZCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBq
dXN0IGFzIHVudXNhYmxlIGZvciB0aGF0Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBCZXNpZGVzIHRoZSBleGFtcGxlcywgSSB0aGluayB0aGF0DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSB2ZXJ5IHVzZSBvZiB0aGUgdGVybSAibWF0
Y2giLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhvdWdo
IHVuZm9ydHVuYXRlbHkgbm90IGRlZmluZWQsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cm9uZ2x5IHN1Z2dlc3RzIHRoYXQgaXQgaXMNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlciB0aGFuIHVzZSBvZiBlLmcuIHRoZSB0
ZXJtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJpZGVudGlmeSIg
d291bGQgaW1wbHkuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFk
ZGl0aW9uYWxseSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRoaXMgdGV4dCBpbiB0aGUgZGVzY3JpcHRpb24gb2YNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdGhlICdwYXRoJyBsZWFmIGlzIGNvbnNpc3RlbnQgd2l0aA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGU8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGJlaW5nIGEgcHJlZml4IG1h
dGNoOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoFRoZSBz
cGVjaWFsIHZhbHVlICcvJw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICByZWZlcnMgdG8gYWxsIHBvc3NpYmxlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICDCoCDCoCDCoCDCoGRhdGFzdG9yZSBjb250ZW50cy4iOzxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBGV0lXLCBvdXIgTkFDTSBpbXBsZW1lbnRhdGlv
biwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXZhaWxhYmxlIHRv
IChhbmQgdXNlZCBieSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y3VzdG9tZXJzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
aW5jZSAyMDEyLCBmb2xsb3dzIHRoZSBwcmVmaXgNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbWF0Y2ggbG9naWMsIGFuZCBJIGhhdmUgeWV0IHRvDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlYXIgb2Y8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFueSB1c2VyIGV4cGVjdGluZyBpdCB0byBk
bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlcndpc2UuPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgVG8gZml4IHRoaXMgcHJvcGVy
bHksIHdlIG5lZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8g
bWFrZSB0aGUgZGF0YS1ub2RlIHBhdGggcnVsZSBhDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHByZWZpeCBtYXRjaC7CoCBJbiBwYXJ0aWN1bGFyLCB3ZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZWVkIHRleHQgdGhhdCBzcGVj
aWZpZXM6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IChpKSB0
aGF0IGEgZGF0YS1ub2RlIHBhdGgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbWF0Y2ggc3VjY2VlZHMgaWYgaXQgbWF0Y2hlcyB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBwcmVmaXggZnJvbSB0aGUgcm9vdCBvZiB0
aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJlZS7CoCBJLmUu
IHNvIHRoZSBkYXRhLXJ1bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIi9mb28iIG1hdGNoZXMgIi9mb28iIGFuZCBhbGwgb2YNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZm9vJ3MgZGVzY2VuZGFudCBjaGlsZHJlbiBub2Rlcy48
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Ryb25nbHkgYWdyZWUuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SSBkbyBu
b3Qgc2VlIGhvdyB0aGUgdGV4dCBjYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgYmUgaW50ZXJwcmV0ZWQgdGhpcyB3YXkuPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZWNh
dXNlIG90aGVyd2lzZSB0aGUgcGF0aCBtYXRjaCBwYXJ0IG9mIHRoZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIE5BQ00gc29sdXRpb24gaXMgcmVhbGx5IGJyb2tlbiwgYW5kIHRo
ZSBwYXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFzZWQgZXhhbXBsZXMgaW4g
dGhlIGFwcGVuZGl4IGFyZSBlbnRpcmVseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1pc2xlYWRpbmcgYW5kIHdyb25nLsKgIFRoZSBvbmx5IHdheSB0aG9zZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4YW1wbGVzIG1ha2Ugc2Vuc2UgaXMgdGhlIHBhdGhzIG1h
dGNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzY2VuZGFudCBjaGlsZHJlbiBu
b2RlcyBhcyB3ZWxsLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
IDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg
ICAgICAgICAgICAgICA8ZGl2PklNTyB0aGUgdGV4dCBkb2VzIG5vdCBzdXBwb3J0IHRoaXMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24uPC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K
ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgPC9ibG9ja3F1b3Rl
Pg0KICAgICAgICAgICAgICAgIFRoZSBleGFtcGxlcyBpbiBCLjQsIGFuZCB0aGUgZGVmaW5p
dGlvbiBvZiAiLyIgbWF0Y2hpbmcNCiAgICAgICAgICAgICAgICBhbGwgbm9kZXMgc3VwcG9y
dHMgdGhpcyBpbnRlcnByZXRhdGlvbi48YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAg
ICAgICAgICAgICAgIEhlbmNlLCBteSBvcGluaW9uIGlzIHRoYXQgaXQgaXMgdGhlIHRleHQg
aW4gMy40LjUgdGhhdA0KICAgICAgICAgICAgICAgIGlzIGluY29ycmVjdGx5IHNwZWNpZmll
ZDsgYW5kIHRoYXQgdGhlIGV4YW1wbGVzLA0KICAgICAgICAgICAgICAgIGRlZmluaXRpb24g
b2YgIi8iIGFuZCBzdGFuZGFyZCBwcmFjdGljZSBhcmUgcmlnaHQuPGJyPg0KICAgICAgICAg
ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICBPdGhlcndpc2UsIGhvdyBkaWQgSUVURiBt
YW5hZ2UgdG8gcHVibGlzaCBhbiBSRkMgd2hlcmUNCiAgICAgICAgICAgICAgICB0aGUgcGF0
aCBiYXNlZCBleGFtcGxlcyBhcmUgc28gY29tcGxldGVseSB3cm9uZz/CoMKgDQogICAgICAg
ICAgICAgICAgV2hvZXZlciB3cm90ZSBhbmQgcmV2aWV3ZWQgdGhvc2UgZXhhbXBsZXMgY2xl
YXJseSBoYWQgYQ0KICAgICAgICAgICAgICAgIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbiBv
ZiBob3cgdGhlc2UgcGF0aCBiYXNlZCBBQ0xzDQogICAgICAgICAgICAgICAgd29ya2VkLiA8
YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgIDxicj4NCiAgICAg
ICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAg
IDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFp
bF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVv
dGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5UaGVyZSBpcyBub3RoaW5nIHNh
aWQgYWJvdXQgaW5oZXJpdGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdGF0ZSBm
cm9tIHRoZSBwYXJlbnQgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgPGRpdj5JIHRoaW5rIG5vIG1hdHRlciBob3cgdGhlIHBlcm1pc3Npb25zIGFyZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICBkZXJpdmVkLCBvbmUgY2FuPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2PmZpbmQgZXhhbXBsZXMgdGhhdCB3b3JrIGJldHRlciBv
ciB3b3JzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBiZWNhdXNlIG9mIGl0LjwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvYmxv
Y2txdW90ZT4NCiAgICAgICAgICAgICAgICBOby7CoCBJZiB0aGUgcnVsZXMgYXBwbHkgdG8g
ZGVzY2VuZGFudCBjaGlsZHJlbiwgYWxsDQogICAgICAgICAgICAgICAgbm9ybWFsIGV4YW1w
bGVzIHdvcmsgd2VsbCAoaW5jbHVkaW5nIHRoZSBvbmVzIGluIHRoZQ0KICAgICAgICAgICAg
ICAgIGFwcGVuZGl4KS48YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg
ICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBj
bGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JTU8g
dGhlIG51bWJlciBvZiBydWxlcyByZXF1aXJlZCB0bw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbXBsZW1lbnQgYSB1c2UtY2FzZSBpcyBub3Q8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+dmVyeSByZWxldmFudCBvciBvYmplY3RpdmUgY3JpdGVyaWEuPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgPC9i
bG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgIFllcyBpdCBpcywgcGFydGljdWxhcmx5IHdo
ZW4gdGhlIGRpZmZlcmVuY2UgaXMgYmV0d2Vlbg0KICAgICAgICAgICAgICAgIG5lZWRpbmcg
YSAxIGxpbmUgcnVsZSwgYW5kIGEgMTAwKyBsaW5lIHJ1bGUuPGJyPg0KICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg
ICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBj
bGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgIDxkaXY+VXNpbmcgdGhlIHByZXZpb3VzIGV4YW1wbGUgb2YgL2hvbWUgYW5kDQogICAg
ICAgICAgICAgICAgICAgICAgICAgIC9ob21lL3VzZXIxLDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj5pZiB0aGUgdXNlcjEgaXMgZ2l2ZW4gcmVhZCBhY2Nlc3MgdG8g
L2hvbWUsDQogICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gKGFjY29yZGluZyB0byB5
b3UpPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pml0IGFsc28gaGFzIHJl
YWQgYWNjZXNzIHRvIGV2ZXJ5IHVzZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgc3Vi
dHJlZSB1bmRlciAvaG9tZS48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4N
CiAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAg
ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXY+SW5zdGVhZCBvZiAxIHJ1bGUgcGVyIHVzZXIsIDIgcnVsZXMg
YXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWRlZDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg
ICAgICAgICAgICAgICBObywganVzdCAxIHJ1bGUgcGVyIHVzZXI6PGJyPg0KICAgICAgICAg
ICAgICAgIMKgwqAgcmVhZC1kZWZhdWx0PWRlbnk8YnI+DQogICAgICAgICAgICAgICAgwqDC
oCBncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwgYWN0aW9uPXBlcm1pdDxicj4NCiAg
ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgVGhpcyBpcyBiZWNhdXNlIG9m
IG15IHR3byBwcm9wb3NlZCBjaGFuZ2VzOjxicj4NCiAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgKGkpIHRoYXQgYSBkYXRhLW5vZGUgcGF0aCBtYXRjaCBzdWNjZWVk
cyBpZiBpdCBtYXRjaGVzDQogICAgICAgICAgICAgICAgdGhlIHBhdGggcHJlZml4IGZyb20g
dGhlIHJvb3Qgb2YgdGhlIHRyZWUuwqAgSS5lLiBzbyB0aGUNCiAgICAgICAgICAgICAgICBk
YXRhLXJ1bGUgIi9mb28iIG1hdGNoZXMgIi9mb28iIGFuZCBhbGwgb2YgZm9vJ3MNCiAgICAg
ICAgICAgICAgICBkZXNjZW5kYW50IGNoaWxkcmVuIG5vZGVzLjxicj4NCiAgICAgICAgICAg
ICAgICAmbHQ7LSBUaGlzIG1lYW5zIHRoYXQgeW91IG9ubHkgbmVlZCAxIGVudHJ5IGluc3Rl
YWQgb2YNCiAgICAgICAgICAgICAgICAxMDAgZW50cmllcy48YnI+DQogICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgIChpaSkgaWYgYSBkYXRhLW5vZGUgcnVsZSBoYXMg
YWN0aW9uICJwZXJtaXQiIHRoZW4gaXQNCiAgICAgICAgICAgICAgICBpbXBsaWNpdGx5IGFs
bG93cyByZWFkIGFjY2VzcyBmb3IgYWxsIGFuY2VzdG9yIHBhcmVudA0KICAgICAgICAgICAg
ICAgIG5vZGVzIHVwIHRvIHRoZSByb290LsKgIChJLmUuIHRvIG1pdGlnYXRlIHRoZSBvcmln
aW5hbA0KICAgICAgICAgICAgICAgIGNoYW5nZSBwcm9wb3NlZCBvbiB0aGlzIHRocmVhZC4p
PGJyPg0KICAgICAgICAgICAgICAgICZsdDstIFRoaXMgbWVhbnMgdGhhdCB5b3UgZG9uJ3Qg
bmVlZCBhIHNlcGFyYXRlIHJlYWQNCiAgICAgICAgICAgICAgICBydWxlIGZvciAiL2hvbWUi
LsKgIFJlYWQgYWNjZXNzIHRvIHRoYXQgbm9kZSBpdCBpcw0KICAgICAgICAgICAgICAgIGlt
cGxpY2l0bHkgZ2l2ZW4gdmlhICJncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAg
ICAgICAgICAgICAgICBhY3Rpb249cGVybWl0IiwgaGVuY2UgbWVhbmluZyB0aGF0IHRoZSBy
dWxlIHdvcmtzIHRoZQ0KICAgICAgICAgICAgICAgIHNhbWUgd2F5IGFzIGl0IGRvZXMgb24g
YW4gcmZjNjUzNiBjb21wbGlhbnQNCiAgICAgICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi48
YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgIDxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAg
ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoHJlYWQtZGVmYXVsdD1kZW55PC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgZ3JvdXA9KiwgcGF0aD0vaG9t
ZSwgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7C
oCDCoGdyb3VwPXVzZXIxLCBwYXRoPS9ob21lL3VzZXIxLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICBhY3Rpb249cGVybWl0PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj5UaGUgYWJvdmUgcnVsZXMgd291bGQgYWxsb3cgYWNjZXNzIGZv
cg0KICAgICAgICAgICAgICAgICAgICAgICAgICBldmVyeSB1c2VyIHRvIGV2ZXJ5IG90aGVy
IHVzZXIuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZSAybmQgcnVs
ZSBoYXMgbm8gZWZmZWN0LCB3aGljaCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICBj
b3VudGVyLWludHVpdGl2ZS48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
RXZlcnkgdXNlciBkaXIgd291bGQgbmVlZCAyIHJ1bGVzPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K
ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGRpdj7CoCDCoHJlYWQtZGVmYXVsdD1kZW55PC9kaXY+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0qLCBwYXRoPS9ob21lLCBhY3Rpb249cGVybWl0
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD11c2Vy
MSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY3Rp
b249cGVybWl0PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0qLCBwYXRoPS9ob21lL3VzZXIx
LCBhY3Rpb249ZGVueTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJn
bWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjow
cHggMHB4IDBweA0KICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVm
dDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0
KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBi
Z2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYg
ZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNz
PSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
diBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj5UaGVyZSBpcyBub3RoaW5nIHRoYXQgc2F5cyB0aGlzDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGhvdyBpdCB3b3Jrcy48L2Rpdj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SWYgaXQgZGlkLCBvbmNl
IGNvdWxkIG5ldmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhh
dmUgcHJpdmlsZWdlZCBzdWItZmlvbGRlcnM8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2PsKgIMKgIMKgL3Zhci9sb2cgLSZndDsgcGVybWl0PC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgIMKgL3Zhci9sb2cvYXBhY2hlMiDC
oC0mZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlbnk8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVv
dGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFllcywgeW91IGNhbiwgeW91IGp1c3QgbGlzdCB0aGUgbG9uZ2VzdCBw
YXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlyc3QgaW4gdGhlIGxpc3Qgb2Yg
cnVsZXM6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICDCoCgxKcKgIC92YXIvbG9nL2FwYWNoZTIgwqAtJmd0OyBk
ZW55PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgICgyKSAvdmFyL2xvZyAt
Jmd0OyBwZXJtaXQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEFueSByZXF1ZXN0cyB0aGF0IGF0dGVtcHQgdG8g
YWNjZXNzIGFueXRoaW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5kZXIgL3Zh
ci9sb2cvYXBhY2hlMiB3b3VsZCBtYXRjaCBydWxlICgxKQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGFuZCBiZSBkZW5pZWQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIEFueSByZXF1ZXN0cyB0aGF0IGF0dGVtcHQgdG8gYWNjZXNzIGFueXRoaW5nDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5kZXIgL3Zhci9sb2csIGJ1dCBub3QgdW5kZXIN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAvdmFyL2xvZy9hcGFjaGUyLCB3b3VsZCBm
YWlsIHRvIG1hdGNoIHJ1bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoMSksIGJ1
dCB3b3VsZCBtYXRjaCBydWxlICgyKSBpbnN0ZWFkIGFuZCBiZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHBlcm1pdHRlZC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2Nr
cXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIGRv
IG5vdCBzZWUgYW55IHRleHQgaW4gdGhlIGRyYWZ0IG9yIFJGQw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICA3OTUwIHRoYXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXY+c3VnZ2VzdHMgdGhhdCAvdmFyL2xvZyBhbmQgL3Zhci9sb2cvYXBhY2hlMg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICByZXByZXNlbnQgdGhlIHNhbWUgZGF0YSBub2RlLjwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvYmxv
Y2txdW90ZT4NCiAgICAgICAgICAgICAgICBUaGV5IGFyZSBkaWZmZXJlbnQgZGF0YSBub2Rl
cywgYnV0IEkgZG9uJ3Qgc2VlIGhvdyB0aGF0DQogICAgICAgICAgICAgICAgaXMgcmVsZXZh
bnQuPGJyPg0KICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICBUaGFua3Ms
PGJyPg0KICAgICAgICAgICAgICAgIFJvYjxicj4NCiAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAg
ICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+QW5keTwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDox
cHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIw
NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyAoaWkpIGlmIGEgZGF0YS1ub2RlIHJ1bGUgaGFzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlvbiAicGVybWl0IiB0aGVu
IGl0IGltcGxpY2l0bHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YWxsb3dzIHJlYWQgYWNjZXNzIGZvciBhbGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYW5jZXN0b3IgcGFyZW50IG5vZGVzIHVwIHRvIHRoZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByb290LsKgIChJLmUuIHRvIG1pdGlnYXRl
IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcmlnaW5hbCBj
aGFuZ2UgcHJvcG9zZWQgb24gdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0aHJlYWQuKTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlz
IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGFsdGhvdWdoIEkgaGF2ZW4ndCBhdCB0aGlzIHBvaW50DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV2YWx1YXRlZDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHN1Z2dlc3Rpb24gaW4gZGV0YWlsLiBJ
biBhbnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FzZSBJIHRo
aW5rIHRoZSBtYWluIHBvaW50IGJvdGg8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJlZ2FyZGluZyB0aGlzIGFuZCB0aGUgcHJlZml4DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGlzIHRoYXQgdGhpcyB1cGRhdGUg
dG8gNjUzNg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYW4ndDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFrZSByYWRpY2Fs
IGNoYW5nZXMgdG8gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNlbWFudGljcyBjb21wYXJlZCB0byBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICJyZWFzb25hYmxlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBpbnRlcnByZXRhdGlvbiIgKGhhcmQgdG8gZGVmaW5lLCBJDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtub3cpIG9mIHRoZSB1bmRlci1zcGVj
aWZpZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9yaWdp
bmFsLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2tx
dW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZSB0ZXh0IGRvZXMgbm90IHNheSB0
aGlzIGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCBzbyBJ
IGRvIG5vdCBhcHByb3ZlIG9mIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgY2hhbmdlPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbiB0aGUgUkZDIHZlcnNpb24gb2Yg
dGhlIE5BQ00gdGhpcyB3YXNuJ3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1
aXJlZCBiZWNhdXNlIG9wZXJhdGlvbiAnbm9uZScgZGlkbid0DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmVxdWlyZSByZWFkIGFjY2Vzcy7CoCBOb3cgcmVhZCBhY2Nlc3MgaXMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlZCBldmVuIGZvciBvcGVyYXRp
b24gJ25vbmUnLCB0aGVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBjaGFu
Z2UgbWFrZXMgc2Vuc2UgdG8gbWFrZSB0aGUgTkFDTQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGNoYW5nZXMgYmFja3dhcmRzIGNvbXBhdGlibGUsIHdoaWxzdCBzdGlsbA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGNsb3NpbmcgdGhlIHNlY3VyaXR5IGhvbGUuPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBUaGFua3MsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv
Yjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2PsKgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6
MXB4IHNvbGlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigy
MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLS1QZXI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90
ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj5BbmR5PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2PsKgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNv
bGlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0
LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyBUaGFua3M8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7IEFuZHk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgT24gVGh1LCBOb3YgOSwgMjAxNw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdCAyOjQ0IEFNLCBSb2JlcnQgV2ls
dG9uICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhy
ZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnJ3aWx0b25AY2lz
Y28uY29tPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7
bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJl
Zj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNj
by5jb208L2E+Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSGkgQW5keSw8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJdCBpc24ndCBjbGVh
ciB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtZSB3aGV0aGVy
IG1hdGNoaW5nIGEgcGF0aCBpbiBOQUNNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGVpdGhlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgKGkpIE9ubHkNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYXBwbGllcyB0byB0aGUgc3BlY2lmaWMgbm9kZSwg
YW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBhbnkgY2hp
bGRyZW4sIG9yPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoChpaSkgQXBwbGllcyB0bw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB0aGUgc3BlY2lmaWMgbm9kZSBhbmQgYWxsDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlc2NlbmRhbnQgY2hpbGRyZW4g
bm9kZXMgYXMgd2VsbC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBBcyBhbiBleGFtcGxlLA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1c2luZyB0aGUgdHJlZSBiZWxvdy7CoCBpZiBJ
IGhhdmUgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlIHRo
YXQgbWF0Y2hlcyBwYXRoICJBL0IiIHRoZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZG9lcyB0aGF0IGFwcGx5IHRvIG9ubHkgdGhlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljIG5vZGUgIkEvQiIsIG9yIGRvZXMg
aXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxzbyBhcHBseSB0
byBhbGwgZGVzY2VuZGFudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjaGlsZHJlbiBvZiAiQS9CIiBhczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqB3ZWxsPzxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEluIHJm
YzY1MzZiaXMtMDgsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNl
Y3Rpb24gIjMuNC41LsKgIERhdGEgTm9kZSBBY2Nlc3MNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgVmFsaWRhdGlvbiIsIHN0ZXAgNiBzdGF0ZXM6PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgKsKgIFRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBydWxlIGRvZXMgbm90IGhhdmUgYSAicnVsZS10eXBlIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmVkIG9yIHRoZSAicnVsZS08YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIHR5cGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGlzICJkYXRhLW5vZGUiIGFuZCB0aGUgKiJwYXRoIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaGVzIHRoZSByZXF1ZXN0ZWQgZGF0YSBu
b2RlKiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uIG5v
ZGUsIG9yIG5vdGlmaWNhdGlvbiBub2RlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgTXkgcmVhZGluZyBvZg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIGlzIHRoYXQgaXQg
aW1wbGllcyB0aGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcGF0aCBydWxlIGlzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChpKSwgYnV0IHRoaXMgaXMgbm90IGhvdyBJIHdvdWxk
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vcm1hbGx5IGV4cGVj
dCBhbiBBQ0wgcnVsZSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhcHBseSBpbiBhIHRyZWUgbGlrZSBvYmplY3QgKGUuZyBhDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGRpcmVjdG9yeTxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBmaWxlIHN5c3RlbSku
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0O8KgIMKgIMKgSG93ZXZlciwgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGV4YW1wbGVzIGluIEFwcGVuZGl4IEIuNC4gaW1wbHkNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCB0aGUgcGF0aCBydWxlIGlzIHRvIGJl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGVkIGxp
a2UgKGlpKSwgb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3Ro
ZXJ3aXNlIHRoZSBleGFtcGxlIHJ1bGVzIHNlZW0NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdG8gYmUgbW9zdGx5IHBvaW50bGVzcy48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBFLmcu
IHRha2luZyB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4
YW1wbGUgZnJvbSBhcHBlbmRpeCBCLjQ6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtydWxlJmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0
O25hbWUmZ3Q7cGVybWl0LWR1bW15LWludGVyZmFjZSZsdDsvPHdicj5uYW1lJmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgJmx0O3BhdGgNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgeG1sbnM6YWNtZT0iPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvaXRmIg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFy
Z2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vZXhhbXBsZS5jb208d2JyPi9ucy9pdGY8
L2E+Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwOi8vZXhh
bXBsZS5jb20vbnMvaXRmIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8v
ZXhhbXBsZS5jb20vbnMvaXRmPC9hPiZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvYWNtZTppbnRlcmZh
Y2VzL2FjbWU6aW50ZXJmYWM8d2JyPmVbYWNtZTpuYW1lPSdkdW1teSddPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDC
oCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7
L3BhdGgmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmbHQ7YWNjZXNzLW9wZXJhdGlvbnMmZ3Q7cmVhZA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1cGRhdGUmbHQ7L2FjY2Vzcy1vcGVy
YXRpb25zJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmx0O2FjdGlvbiZndDtwZXJtaXQmbHQ7L2FjdGlvbiZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZsdDtjb21tZW50Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQWxsb3cN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGxpbWl0ZWQgYW5k
IGd1ZXN0IGdyb3VwcyByZWFkPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXBkYXRlIGFjY2VzcyB0byB0aGUg
ZHVtbXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJmYWNl
Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmx0Oy9jb21tZW50Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy9ydWxlJmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKg
IMKgSWYgdGhlIHJ1bGUgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGkpwqAgdGhlbiB0aGUgYWNjZXNzIHJ1bGUgYWxsb3dzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRoZSBjbGllbnQgdG8gcmVhZCB0aGUgc3BlY2lmaWMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9kZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiL2FjbWU6aW50ZXJmYWNlcy9hY21lOmlu
dGVyZmE8d2JyPmNlW2FjbWU6bmFtZT0nZHVtbXknXSINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgYnV0IG5vdCBhbnkgY2hpbGQgbGVhZnMvY29udGFpbmVycw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiB0aGF0IGludGVyZmFj
ZSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0O8KgIMKgIMKgdGhpcyBkb2Vzbid0IHNlZW0NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdXNlZnVsLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEZ1cnRoZXIgY29tbWVudHMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5saW5lIGJlbG93IC4uLjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDvCoCDCoCDCoE9uIDA4LzExLzIwMTcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMjA6MDUsIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoEhpLDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0O8KgIMKgIMKgVGhpcyBjaGFuZ2UNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgaGFzIG5vIGltcGFjdCBvbiB0aGUgc2VydmVyIGlmDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC9uYWNtL3JlYWQtZGVmYXVsdCBpcyAi
cGVybWl0Ii48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoEluIHRoYXQgY2FzZSwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhlIGV4dHJhIHJlYWQgcnVsZXMgZm9yIC9BIGFuZA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvQS9CIGFyZSBub3QgbmVl
ZGVkLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7wqAgwqAgwqBJIGFncmVlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqBBbiBvcGVyYXRvcg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3b3JyaWVkIGFib3V0IHJlYWQg
YWNjZXNzIHNob3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
ZXQgcmVhZC1kZWZhdWx0IHRvICJkZW55Ii48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSSBhZ3JlZS7CoCBUaGlzIGlz
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBzY2VuYXJpbyB0
aGF0IEknbSBjb25zaWRlcmluZy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgSW4gdGhhdCBjYXNlLA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHBsaWNpdCBydWxlcyB0byBy
ZWFkIC9BIGFuZCAvQS9CDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHdvdWxkIGJlIG5lZWRlZDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgaW4gdGhlIG5ldw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBOQUNNLjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBZZXMsIGlmIHRoZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBv
ZiB0aGUgcnVsZSBpcyAoaSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYWJvdmUuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDvCoCDCoCDCoE90aGVyd2lzZSBpZiB0aGUNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24gaXMgKGlpKSB0aGVuIHlvdQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbmx5IG5lZWQgInJlYWQg
L0EiIHNpbmNlIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
aW1wbGllcyAicmVhZCBBL0IiIGFzIHdlbGwgKGFzDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGxvbmcgYXMgdGhlIHJ1bGVzIGFyZSBsaXN0ZWQgaW4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNvcnJlY3Qgb3JkZXIpLjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoFRoZSBkZW55DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJ1bGVzIHdvdWxkIG5vdCBiZSBuZWVkZWQuPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoE9ubHkg
aWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJl
dGF0aW9uIG9mIHRoZSBydWxlIGlzIChpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBhYm92ZS7CoCBJbiB3aGljaCBjYXNlIHRoZcKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkL3dyaXRlICdBL0IvSicgcnVsZSB3b3Vs
ZCBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgc3VmZmlj
aWVudC7CoCBJdCB3b3VsZCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBuZWNlc3NhcnkgdG8gZGVmaW5lIGFuIFhwYXRoDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4cHJlc3Npb25zIHRoYXQgY29udGFpbnM8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
YWxsIGNoaWxkcmVuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5v
ZGVzIGFzIHdlbGwuwqAgUGVyaGFwcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAnQS9CL0ovLyonPzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoElmIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcyAo
aWkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4geW91IHdv
dWxkIGFsc28gbmVlZCBhbGwgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGV4cGxpY2l0IGRlbnkgc3RhdGVtZW50cyBhcyB3ZWxsLA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlcndpc2UgdGhleSB3b3VsZCBiZSBhbGxv
d2VkIGJ5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSAicmVh
ZCAvQSIgcnVsZSBhYm92ZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBUaGFua3MsPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFJvYjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoEFuZHk8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDC
oE9uIFdlZCwgTm92DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDgs
IDIwMTcgYXQgODozMyBBTSwgUm9iZXJ0IFdpbHRvbg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
Ij5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmx0O21haWx0bzo8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi
PnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsmZ3Q7DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgSGksPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN1cmUgYWJvdXQgdGhpcyBjaGFuZ2UuPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqAgwqBJJ20gbm90DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHRoYXQgZmFtaWxpYXIgd2l0aCBOQUNNLCBidXQgaWYNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgeW91IHdhbnQgdG8gZ2l2ZSBhIHBhcnRpY3VsYXIgc2V0
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIHVzZXJzIHJlYWQv
d3JpdGUgYWNjZXNzIHRvIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3VidHJlZSwgYnV0IG5vdCBhbGxvdyB0aGVtIHRvDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGhhdmUgYW55IG90aGVyIGFjY2VzcyB0byB0aGUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiBpbiB0aGU8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDvCoCDCoCDCoCDCoCDCoHJ1bm5pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZGF0YXN0b3JlIHRoZW4gd2l0aCB0aGUgZXhpc3RpbmcNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUkZDLCB0aGF0IGNvdWxkIGJlIGV4cHJl
c3NlZCB3aXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgc2lu
Z2xlIHJ1bGUgKGV4YW1wbGUgaW4gNjUzNmJpcywNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYXBwZW5kaXggQi40KTxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg
V2l0aCB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5ldyBj
aGFuZ2UsIEkgdGhpbmsgdGhhdCB5b3UgbWF5DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG5lZWQgdG8gY29uZmlndXJlIG1hbnkgbW9yZSBydWxlcw0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhY2hpZXZlIHRoZSBzYW1lIHRo
aW5nLsKgIEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpbmsg
dGhhdCB5b3Ugd291bGQgbmVlZCB0byBnaXZlDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJlYWQgYWNjZXNzIHRvIHRoZSB0b3Agbm9kZSBpbiB0aGUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzaXJlZDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKg
IMKgIMKgcGF0aCwgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRoZW4gc2VwYXJhdGUgZXhwbGljaXQgImRlbnkiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHJ1bGVzIGZvciBldmVyeSBzaWJsaW5nIGNoaWxkIG5vZGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2Fsa2luZyBmcm9tIHRoZSB0
b3Agb2YgdGhlIHRyZWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ZG93biB0byB0aGUgZGF0YSBub2RlIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmVhZC93cml0ZSBhY2Nlc3MgaXMgYWN0dWFsbHkNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVpbmcgZ2l2ZW4gdG8uwqAgVGhlPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqAgwqBleGFtcGxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGJlbG93IG1heSBleHBsYWluIG15IHVuZGVyc3RhbmRpbmcNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgYmV0dGVyOjxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKg
IMKgIMKgRS5nLiBGb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YSB0cmVlIG9mIGRhdGEgbm9kZXMsIHJvb3RlZCBhdCBBLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBpZiB3ZSB3YW50ZWQgdG8gZ2l2ZSByZWFkL3dyaXRlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjY2VzcyBvbmx5IHRvICJK
IiBzdWJ0cmVlLCBhbmQgbm8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYWNjZXNzIGZvciB0aGUgcmVzdCBvZiB0aGUgdHJlZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB0aGVuOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKg
IMKgIMKgIEE8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCB8PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
wqAtLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgfMKgIMKgIMKgIHzCoCDC
oCDCoHzCoCDCoCDCoHw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoELCoCDCoCDCoCBDwqAgwqAgwqBEwqAg
wqAgwqBFPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0t
LS0tLS08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqB8wqANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfMKgIHw8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCBG
wqAgwqBHwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSMKgIEo8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoCDCoCB8PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAuLi48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoEluIHRoZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBvbGQgbW9kZWwsIEkgdGhpbmsgdGhhdCB0aGUgQUNMDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGVzIHdvdWxkIGJlIDEg
cnVsZXMgbG9uZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoYXNz
dW1pbmcgZGVmYXVsdCBkZW55IGFsbCk6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInJlYWQvd3JpdGUgJ0EvQi9KJzxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgSW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG5ldyBtb2RlbCwgSSB0aGluayB0aGF0IHRoZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcXVpdmFsZW50IEFDTCBydWxlcyB3b3Vs
ZCBuZWVkIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlIDgg
cnVsZXMgbG9uZyAoYXNzdW1pbmcgZGVmYXVsdA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBkZW55IGFsbCk6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInJlYWQvd3JpdGUgJ0EvQi9KJzxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0O8KgIMKgIMKgIMKgIMKgIMKgICJyZWFkDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEEiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgImRlbnkNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQyI8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDC
oCAiZGVueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEIjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgIMKgICJkZW55DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEUiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgImRlbnkNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgRiI8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCAi
ZGVueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHIjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgIMKgIMKgIMKgIMKgICJkZW55DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEgiPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBOb3RlLCBJDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFtIGFzc3VtaW5nIHRoYXQgYSAicGF0aCIg
cnVsZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaGVzIGZv
ciB0aGUgZ2l2ZW4gcGF0aCBhbmQgYWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGRlc2NlbmRhbnQgbm9kZXMuwqAgVGhlIGRyYWZ0DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXNuJ3Qgc2VlbSB0byBiZSBwYXJ0aWN1bGFy
bHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xlYXIgb24gdGhp
cyBwb2ludCAoaXQgc3RhdGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHRoYXQgdGhlIHJ1bGUgYXBwbGllczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgd2hlbiB0aGUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBtYXRjaGVzLCBi
dXQgdGhpcyB3b3VsZCBzZWVtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHRvIGJlIGNvdW50ZXIgaW50dWl0aXZlKSwgYW5kDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHBlcmhhcHMgaXQgY291bGQgYmUgY2xhcmlmaWVkLjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgIMKgIMKgIMKgSWYgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjaGFuZ2UgaXMgYWxsb3dlZCwgdGhlbiB0aGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhhbXBsZSBpbiBhcHBlbmRpeCBCLjQgbG9v
a3MgbGlrZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpdCB3b3Vs
ZCBuZWVkIHRvIGJlIGZpeGVkLCBzaW5jZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0aGUgImxpbWl0ZWQtYWNsIiBwcm9iYWJseQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB3b3VsZG4ndCBnaXZlIGFueSBhY2Nlc3MgYXQgYWxs
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxlc3MgZGVmYXVs
dCByZWFkPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBhY2Nlc3MNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaGFkIGJlZW4gZ2l2ZW4uPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqBCdXQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvc3Np
Ymx5IEknbSBtaXN1bmRlcnN0YW5kaW5nIGhvdw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGlzIGFsbCB3b3JrcyHCoCBJZiBzbywgYXBvbG9naWVzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciB0aGUgbm9pc2UgOi0pPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBUaGFua3MsPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBSb2I8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoE9uDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDAyLzExLzIwMTcgMTQ6MTgsIEJlbm9pdCBDbGFpc2UNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgIMKgIMKgIMKgRGVhcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhbGwsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoEhlcmUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgYSBtYWpvciBjaGFuZ2UgaW4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25m
LXJmYzY1MzZiaXMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1
Z2dlc3RlZCBieSB0aGUgU2VjdXJpdHkgQUQgRXJpYw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBSZXNjb2xhIHBhcnQgb2YgdGhlIElFU0cgcmV2aWV3LA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGljaCBJIHdvdWxkIGxpa2Ug
dG8gdmFsaWRhdGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0
aCB0aGUgV0cuIFNlZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoDxhDQpocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUz
NmJpcy0wOC50eHQiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvcmZjZGlmPHdicj5mP3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY8
d2JyPjUzNmJpcy0wOC50eHQ8L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZsdDs8YQ0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy
bDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0Ig0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf
YmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZjx3YnI+Zj91
cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2PHdicj41MzZiaXMtMDgudHh0PC9hPiZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIMKgJmx0O2RmcGNmaW9vbmRnZ2lwcGUucG5nJmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZn
dDvCoCDCoCDCoCDCoCDCoFRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBORVRDT05GIFdHIHdhcyBjYydlZCBmb3IgdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGVudGlyZSBkaXNjdXNzaW9uLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDC
oCDCoCDCoFdoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG8g
eW91IHRoaW5rPyBJIHdpbGwgZHJhdyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY29uY2x1c2lvbnMgYnkgRnJpZGF5IE5vdiAxMHRoLjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBOb3RlOg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBJZiB0aGUgV0cgaXMgZmluZSwgdGhlIG5leHQgc3RlcA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyB0byBhcHByb3ZlIHRoaXMgZG9j
dW1lbnQuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDCoFJlZ2FyZHMsIEJlbm9pdDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19f
X19fX19fX19fX19fXzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICDCoE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgIMKgIMKgIMKgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5ldGNvbmZA
aWV0Zi5vcmc8L2E+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZs
dDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo
cmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5ldGNvbmZAaWV0
Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoDxhDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vbmV0Y29uZjwv
YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0OzxhDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8v
bmV0Y29uZjwvYT4mZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+
X19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IDxhDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZA
aWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFy
Z2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5OZXRjb25mQGlldGYub3JnPC9hPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0
Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0
PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIj5OZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyA8YQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r
Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9sPHdicj5pc3RpbmZv
L25ldGNvbmY8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsgTWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20i
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxh
bmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzo8YQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5p
QGdtYWlsLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY288d2JyPm08
L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ow0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsi
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0Y29uZiINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9sPHdicj5pc3RpbmZvL25ldGNvbmY8L2E+PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQog
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
IDwvYmxvY2txdW90ZT4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8YnI+DQogICAg
ICAgIDwvZGl2Pg0KICAgICAgICA8YnI+DQogICAgICAgIDxmaWVsZHNldCBjbGFzcz0ibWlt
ZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+DQogICAgICAgIDxicj4NCiAgICAgICAg
PHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1h
YmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxp
bmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0Y29uZiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+DQo8L3ByZT4NCiAgICAgIDwvYmxvY2tx
dW90ZT4NCiAgICAgIDxicj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICA8L2Jv
ZHk+DQo8L2h0bWw+DQo=
--------------0D4EF8FA01DABC6EFA7357DE--

--------------08A93BB611366AE7B91C5D61
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="Attached Message"

X-Mozilla-Keys: 
Subject: Re: NACM and "when" statements
To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org
References: 
 
 <20171121.105855.1884534168363830366.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <372d5b0f-5da5-3a2e-aa41-bfcd87e0f96f@cisco.com>
Date: Tue, 21 Nov 2017 13:58:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171121.105855.1884534168363830366.mbj@tail-f.com>
Content-Type: multipart/mixed;
 boundary="------------220DFA6B7225BC9351FCD2AB"
Content-Language: en-US

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

Proposed text below.


On 21/11/2017 09:58, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> Hi,
>>
>>
>> On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton  wrote:
>>
>>> Hi Andy, Martin,
>>>
>>> I've got a question about 'when' statement handling related to NACM.
>>>
>>> Due to when statements, it is possible that a client could implicitly
>>> cause a change to a part of the data tree that they have no write access to
>>> because they cause a when condition to evaluate to a different answer.  Am
>>> I correct in presuming that this implicit change is allowed?
>>>
>>> E.g. in the following example, a user may only have write access to "baz"
>>> but not "bar". If they create "baz" then that may implicitly cause "bar" to
>>> be deleted.  Further, even if this implicit delete to "bar" is allowed, I
>>> presume that the equivalent explicit change or creating "baz" and deleting
>>> "bar" would still be rejected because there is no explicit write access to
>>> bar.
>>>
>>> container foo {
>>>    leaf bar {
>>>     when "not(../baz)";
>>>    }
>>>    leaf baz {
>>>    }
>>> }
>>>
>>> Should this be mentioned in the NACM draft at all?  I'm not convinced that
>>> the draft makes the correct behaviour for handling 'when' statements
>>> obvious.
>>>
>>> Similar considerations could also apply when writing to choice statements.
>>>
>>>
>> I just confirmed that our server does not enforce nacm:default-deny-all for
>> the "when-stmt" node.
>> NACM rules say "user X is allowed to write /foo/baz" and nothing about
>> /foo/baz side-effects.
> Our implementation works the same way, and I agree this is reasonable
> behavior.  NACM controls access to the operations, not the side
> effects.
OK, so I propose the following NEW additions to rfc6536bis:


Added to the end of section "1.2.  Changes Since RFC 6536":

    The data node access behavior for path matches has been clarified to
    also include matching descendant nodes of the specified path.

    The  operation access rights behavior has been clarified
    to indicate that write access is not required for data nodes that are
    implicitly modified through side-effects (such as the evaluation of
    YANG when-stmts, or data nodes implicitly deleted when creating a
    data node under a different branch under a YANG choice-stmt).

Added to the end of section "3.2.5.   Operation":

    An  operation may cause data nodes to be implicitly
    created or deleted as an implicit side-effect of a requested
    operation.  For example, a YANG when-stmt expression may evaluate to
    a different result, causing data nodes to be deleted, or created with
    default values; or if a data node is created under one branch of a
    YANG choice-stmt, then all data nodes under the other branches are
    implicitly removed.  No NACM access rights are required on any data
    nodes that are implicitly changed as a side effect of another allowed
    operation.

Added after paragraph 4 of "3.7.2.  General Configuration Issues":

    It is possible that the data model definition itself (e.g., YANG
    when-stmt or choice-stmt) will allow a session to implicitly create
    or delete nodes that the session does not have write access to as an
    implicit side effect from the processing of an allowed 
    operation.

In case it is useful, git diff for the above change is also attached.

Thanks,
Rob


>
>
> /martin
>
>
>> YANG says nodes exist only if the when-stmt is true and nothing about how
>> they change
>> from true to false. I don't think access control is mentioned in either RFC
>> for this corner-case.
>>
>> Perhaps more security consideration text is needed, warning that any nodes
>> that are deleted
>> by the server because of false when-stmt evaluation are exempt from access
>> control.
>>
>> It would be a significant change to implementations to enforce delete
>> permissions on
>> when-stmt and choice-stmt automatic node removal. This can also apply to
>> automatic
>> creation of default nodes (when-stmt evaluates true, was false).
>>
>>
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>> Andy
> .
>


--------------220DFA6B7225BC9351FCD2AB
Content-Type: text/plain; charset=UTF-8;
 name="nacm.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="nacm.diff"

ZGlmZiAtLWdpdCBhL25ldGNvbmYtYWNjZXNzLWNvbnRyb2wueG1sLmluIGIvbmV0Y29uZi1h
Y2Nlc3MtY29udHJvbC54bWwuaW4KaW5kZXggNDAyYmY3Yy4uNmM1YWJkZiAxMDA2NDQKLS0t
IGEvbmV0Y29uZi1hY2Nlc3MtY29udHJvbC54bWwuaW4KKysrIGIvbmV0Y29uZi1hY2Nlc3Mt
Y29udHJvbC54bWwuaW4KQEAgLTI4Niw2ICsyODYsMjAgQEAKICAgICAgICAgc28gYSBzaW1w
bGUgbWFwcGluZyB0byB0aGUgZXhpc3RpbmcgTkFDTSBwcm9jZWR1cmVzCiAgICAgICAgIGFu
ZCBkYXRhIG1vZGVsIGlzIHBvc3NpYmxlLgogICAgICAgPC90PgorICAgICAgPHQ+CisgICAg
ICAgIFRoZSBkYXRhIG5vZGUgYWNjZXNzIGJlaGF2aW9yIGZvciBwYXRoIG1hdGNoZXMgaGFz
IGJlZW4KKyAgICAgICAgY2xhcmlmaWVkIHRvIGFsc28gaW5jbHVkZSBtYXRjaGluZyBkZXNj
ZW5kYW50IG5vZGVzIG9mIHRoZQorICAgICAgICBzcGVjaWZpZWQgcGF0aC4KKyAgICAgIDwv
dD4KKyAgICAgIDx0PgorICAgICAgICBUaGUgJmx0O2VkaXQtY29uZmlnJmd0OyBvcGVyYXRp
b24gYWNjZXNzIHJpZ2h0cyBiZWhhdmlvciBoYXMKKyAgICAgICAgYmVlbiBjbGFyaWZpZWQg
dG8gaW5kaWNhdGUgdGhhdCB3cml0ZSBhY2Nlc3MgaXMgbm90IHJlcXVpcmVkCisgICAgICAg
IGZvciBkYXRhIG5vZGVzIHRoYXQgYXJlIGltcGxpY2l0bHkgbW9kaWZpZWQgdGhyb3VnaAor
ICAgICAgICBzaWRlLWVmZmVjdHMgKHN1Y2ggYXMgdGhlIGV2YWx1YXRpb24gb2YgWUFORyB3
aGVuLXN0bXRzLCBvcgorICAgICAgICBkYXRhIG5vZGVzIGltcGxpY2l0bHkgZGVsZXRlZCB3
aGVuIGNyZWF0aW5nIGEgZGF0YSBub2RlIHVuZGVyCisgICAgICAgIGEgZGlmZmVyZW50IGJy
YW5jaCB1bmRlciBhIFlBTkcgY2hvaWNlLXN0bXQpLgorCisgICAgICA8L3Q+CiAgICAgPC9z
ZWN0aW9uPgogICA8L3NlY3Rpb24+CiAKQEAgLTk5MCw2ICsxMDA0LDE4IEBACiAgICAgICAg
ICAgYmUgZXhwb3NlZCBpbiBhbnkgJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudHMKICAgICAg
ICAgICB3aXRoaW4gdGhlIHJlcGx5LgogICAgICAgICA8L3Q+CisgICAgICAgIDx0PgorICAg
ICAgICAgIEFuICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uIG1heSBjYXVzZSBkYXRh
IG5vZGVzIHRvIGJlCisgICAgICAgICAgaW1wbGljaXRseSBjcmVhdGVkIG9yIGRlbGV0ZWQg
YXMgYW4gaW1wbGljaXQgc2lkZS1lZmZlY3Qgb2YKKyAgICAgICAgICBhIHJlcXVlc3RlZCBv
cGVyYXRpb24uICBGb3IgZXhhbXBsZSwgYSBZQU5HIHdoZW4tc3RtdAorICAgICAgICAgIGV4
cHJlc3Npb24gbWF5IGV2YWx1YXRlIHRvIGEgZGlmZmVyZW50IHJlc3VsdCwgY2F1c2luZyBk
YXRhCisgICAgICAgICAgbm9kZXMgdG8gYmUgZGVsZXRlZCwgb3IgY3JlYXRlZCB3aXRoIGRl
ZmF1bHQgdmFsdWVzOyBvciBpZiBhCisgICAgICAgICAgZGF0YSBub2RlIGlzIGNyZWF0ZWQg
dW5kZXIgb25lIGJyYW5jaCBvZiBhIFlBTkcgY2hvaWNlLXN0bXQsCisgICAgICAgICAgdGhl
biBhbGwgZGF0YSBub2RlcyB1bmRlciB0aGUgb3RoZXIgYnJhbmNoZXMgYXJlIGltcGxpY2l0
bHkKKyAgICAgICAgICByZW1vdmVkLiAgTm8gTkFDTSBhY2Nlc3MgcmlnaHRzIGFyZSByZXF1
aXJlZCBvbiBhbnkgZGF0YQorICAgICAgICAgIG5vZGVzIHRoYXQgYXJlIGltcGxpY2l0bHkg
Y2hhbmdlZCBhcyBhIHNpZGUgZWZmZWN0IG9mCisgICAgICAgICAgYW5vdGhlciBhbGxvd2Vk
IG9wZXJhdGlvbi4KKyAgICAgICAgPC90PgogICAgICAgPC9zZWN0aW9uPgogCiAgICAgICA8
c2VjdGlvbiB0aXRsZT0iJmx0O2NvcHktY29uZmlnJmd0OyBPcGVyYXRpb24iPgpAQCAtMjA0
Nyw2ICsyMDczLDEzIEBAIG00X2luY2x1ZGUoaWV0Zi1uZXRjb25mLWFjbS55YW5nKQogICAg
ICAgICAgYnkgZXhhbWluaW5nIHRoZSBwcmVzZW5jZSBhbmQgdmFsdWVzIG9mIGRpZmZlcmVu
dCBkYXRhIG5vZGVzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KKyAgICAgICAgIEl0IGlz
IHBvc3NpYmxlIHRoYXQgdGhlIGRhdGEgbW9kZWwgZGVmaW5pdGlvbiBpdHNlbGYgKGUuZy4s
CisgICAgICAgICBZQU5HIHdoZW4tc3RtdCBvciBjaG9pY2Utc3RtdCkgd2lsbCBhbGxvdyBh
IHNlc3Npb24gdG8KKyAgICAgICAgIGltcGxpY2l0bHkgY3JlYXRlIG9yIGRlbGV0ZSBub2Rl
cyB0aGF0IHRoZSBzZXNzaW9uIGRvZXMgbm90CisgICAgICAgICBoYXZlIHdyaXRlIGFjY2Vz
cyB0byBhcyBhbiBpbXBsaWNpdCBzaWRlIGVmZmVjdCBmcm9tIHRoZQorICAgICAgICAgcHJv
Y2Vzc2luZyBvZiBhbiBhbGxvd2VkICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uLgor
ICAgICAgIDwvdD4KKyAgICAgICA8dD4KICAgICAgICAgIFRoZXJlIGlzIGEgcmlzayB0aGF0
IG5vbi1zdGFuZGFyZCBwcm90b2NvbCBvcGVyYXRpb25zLCBvcgogICAgICAgICAgZXZlbiB0
aGUgc3RhbmRhcmQgJmx0O2dldCZndDsgcHJvdG9jb2wgb3BlcmF0aW9uLCBtYXkKICAgICAg
ICAgIHJldHVybiBkYXRhIHRoYXQgImFsaWFzZXMiIG9yICJjb3BpZXMiIHNlbnNpdGl2ZSBk
YXRhCg==
--------------220DFA6B7225BC9351FCD2AB--

--------------08A93BB611366AE7B91C5D61--


From nobody Wed Nov 22 05:41:19 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9AD129443; Wed, 22 Nov 2017 05:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGd3sBrKM35o; Wed, 22 Nov 2017 05:41:12 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EA71200FC; Wed, 22 Nov 2017 05:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=124384; q=dns/txt; s=iport; t=1511358072; x=1512567672; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=P8/6cbA4BwhS2WvVUlZ0Dx18HjKf+LaEzEr9JJ8Zg10=; b=V0IPavH8ELRvrNSbjhvtruXj8ZJLLIUC8KTL9IjEKq5t3DkeN0p5wmTk /IuxCSAzIfckvpiiu9Tb4XPE9TK6YXkHHdDXwz1kNbsKSDyCzt51HdKKq hDel25TwBU9csLleQ0f1RRto1oWfmOByzdT9cWkKIMqxPMbJSRaysNJ+u E=;
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="scan'208,217";a="364705"
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; 22 Nov 2017 13:41:10 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAMDf996002152; Wed, 22 Nov 2017 13:41:09 GMT
To: Robert Wilton , Andy Bierman 
Cc: "sec-ads@ietf.org" , NETCONF 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>   
From: Benoit Claise 
Message-ID: 
Date: Wed, 22 Nov 2017 14:41:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------5DE615BA2360F6FD6C40074B"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:41:17 -0000

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

Hi Rob,

At that points in time, if it clarifies the spec. and the authors agree 
with this, let's do the right thing.

Regards, Benoit.
>
> Hi Benoit,
>
> There is also one further, unrelated change that I am proposing is 
> made the draft before it is published, to help better clarify the 
> expected behavior.  It isn't the end of the world if this doesn't go 
> in, but I think that it prevents sometime taking a different, but IMO 
> reasonable, interpretation of how "when" statements are considered, 
> and then having a future argument about what behavior it specified in 
> the standard.
>
> If we clarify it now, then it closes that door :-)
>
> I've proposed text to Andy and Martin on Monday, but I've not heard 
> back yet.
>
> Netconf email with proposed text attached.  The text doesn't 
> necessarily have to match this, but personally I think that it is 
> useful if the draft says something on this.
>
> Thanks,
> Rob
>
>
> On 22/11/2017 13:25, Benoit Claise wrote:
>> On 11/10/2017 7:23 PM, Andy Bierman wrote:
>>> Hi,
>>>
>>> Here are some proposed edits to make the data rule consistent with 
>>> the examples.
>>> Note that this issue is not related to the edit in the original 
>>> 1-week change.
>> That's right, but we found a source of misinterpretation in the draft 
>> and you have rightly corrected it in the github v9.
>>
>> Regards, Benoit
>>>
>>>
>>> sec. 3.3.5:
>>>
>>> OLD:
>>>
>>>
>>>       data node rule:  controls access for a specific data node, 
>>> identified
>>>       by its path location within the conceptual XML document for the
>>>       data node.
>>>
>>>
>>> NEW:
>>>
>>>       data node rule:  controls access for a specific data node and 
>>> its descendants,
>>>       identified by its path location within the conceptual XML 
>>> document for the
>>>       data node.
>>>
>>>
>>> sec 3.4.5, step 6, bullet 2:
>>>
>>>
>>> OLD:
>>>
>>>         *  The rule does not have a "rule-type" defined or the "rule-
>>>            type" is "data-node" and the "path" matches the requested
>>>            data node, action node, or notification node.
>>>        
>>> NEW:
>>>         *  The rule does not have a "rule-type" defined or the "rule-
>>>            type" is "data-node" and the "path" matches the requested
>>>            data node, action node, or notification node. A path is
>>>            considered to match if the current data node is the data node
>>>            specified by the path, or is a descendant data node of 
>>> this data node.
>>> appendix B.4: (2 bugs in explanation)
>>> OLD:
>>> deny-nacm: This rule denies the "guest" group any access to the 
>>>  subtree. Note that the default namespace is only applicable 
>>> because this subtree is defined in the same namespace as the 
>>>  element.
>>> NEW:
>>> deny-nacm: This rule denies the "guest" group any access to the 
>>>  subtree.
>>> Andy
>>>
>>> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton >> > wrote:
>>>
>>>
>>>
>>>     On 10/11/2017 16:33, Andy Bierman wrote:
>>>>
>>>>
>>>>     On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>>>>     > wrote:
>>>>
>>>>
>>>>
>>>>         On 10/11/2017 15:49, Andy Bierman wrote:
>>>>>
>>>>>
>>>>>         On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
>>>>>         > wrote:
>>>>>
>>>>>             On 2017-11-10 11:42, Robert Wilton wrote:
>>>>>             >
>>>>>             >
>>>>>             > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>>>             >>
>>>>>             >>
>>>>>             >>
>>>>>             >>
>>>>>             >> Mahesh Jethanandani
>>>>>             >> mjethanandani@gmail.com
>>>>>             
>>>>>             >>>>             >
>>>>>             >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
>>>>>             
>>>>>             >>>>             >> wrote:
>>>>>             >>
>>>>>             >>> Hi,
>>>>>             >>>
>>>>>             >>> The term "data node" is used in the document to
>>>>>             refer to the top-level node
>>>>>             >>> of the specified object, not the entire subtree
>>>>>             (if any).
>>>>>             >>>
>>>>>             >>> The data-rule /foo does not match /foo/child1 in
>>>>>             the text below.
>>>>>             >>> The child nodes are omitted because of step 11.
>>>>>             >>> The admin has to explicitly permit individual
>>>>>             child nodes (or modules).
>>>>>             >>> This seems correct if the read-default is "deny".
>>>>>             >>>
>>>>>             >>> Should any text be added or changed to make this
>>>>>             more clear?
>>>>>             >>
>>>>>             >> I would agree with Robert that it was not entirely
>>>>>             clear that rule applied on the parent data-node does
>>>>>             not apply to the child nodes. So yes, it would help to
>>>>>             clarify it.
>>>>>             > We should be doing more than clarifying it.  We need
>>>>>             to fix it so that it works in a sensible way.  I.e. to
>>>>>             make the normative text consistent with the behaviour
>>>>>             currently described in the examples in
>>>>>             > the appendix B.4.
>>>>>             >
>>>>>             > If we follow Andy's interpretation that a data rule
>>>>>             doesn't match child nodes then those examples are
>>>>>             completely wrong.  E.g. the 4th rule is described as
>>>>>             "This rule gives the 'admin' group read-write
>>>>>             > access to all acme  entries."  But If the
>>>>>             path only strictly matches
>>>>>             "/acme:interfaces/acme:interface" then the admin group
>>>>>             rule achieves nothing useful at all. The admin is not even
>>>>>             > allowed to create an interface because they would
>>>>>             not even have permission to write to the list key
>>>>>             'name' node required to create a list entry!  Instead,
>>>>>             a separate rule would be required for every
>>>>>             > single possible schema node under
>>>>>             "/acme:interfaces/acme:interface"! I think that this
>>>>>             makes "permit" data-node rules completely unusable.
>>>>>
>>>>>             I strongly agree with this, and I would say that it
>>>>>             isn't only the case
>>>>>             for "permit" rules - e.g. denying some access to a
>>>>>             subtree of the data
>>>>>             model that would otherwise be permitted due to
>>>>>             defaults is at least as
>>>>>             common, and the rules would be just as unusable for that.
>>>>>
>>>>>             Besides the examples, I think that the very use of the
>>>>>             term "match",
>>>>>             though unfortunately not defined, strongly suggests
>>>>>             that it is something
>>>>>             other than use of e.g. the term "identify" would
>>>>>             imply. Additionally,
>>>>>             this text in the description of the 'path' leaf is
>>>>>             consistent with the
>>>>>             match being a prefix match:
>>>>>
>>>>>                    The special value '/' refers to all possible
>>>>>                    datastore contents.";
>>>>>
>>>>>             FWIW, our NACM implementation, available to (and used
>>>>>             by) customers
>>>>>             since 2012, follows the prefix match logic, and I have
>>>>>             yet to hear of
>>>>>             any user expecting it to do otherwise.
>>>>>
>>>>>             > To fix this properly, we need to make the data-node
>>>>>             path rule a prefix match.  In particular, we need text
>>>>>             that specifies:
>>>>>             >
>>>>>             > (i) that a data-node path match succeeds if it
>>>>>             matches the path prefix from the root of the tree. 
>>>>>             I.e. so the data-rule "/foo" matches "/foo" and all of
>>>>>             foo's descendant children nodes.
>>>>>
>>>>>             Strongly agree.
>>>>>
>>>>>
>>>>>
>>>>>         I do not see how the text can be interpreted this way.
>>>>
>>>>         Because otherwise the path match part of the NACM solution
>>>>         is really broken, and the path based examples in the
>>>>         appendix are entirely misleading and wrong.  The only way
>>>>         those examples make sense is the paths match descendant
>>>>         children nodes as well.
>>>>
>>>>
>>>>
>>>>     IMO the text does not support this interpretation.
>>>     The examples in B.4, and the definition of "/" matching all
>>>     nodes supports this interpretation.
>>>
>>>     Hence, my opinion is that it is the text in 3.4.5 that is
>>>     incorrectly specified; and that the examples, definition of "/"
>>>     and standard practice are right.
>>>
>>>     Otherwise, how did IETF manage to publish an RFC where the path
>>>     based examples are so completely wrong? Whoever wrote and
>>>     reviewed those examples clearly had a different interpretation
>>>     of how these path based ACLs worked.
>>>
>>>
>>>>     There is nothing said about inheriting state from the parent
>>>>     data node.
>>>>     I think no matter how the permissions are derived, one can
>>>>     find examples that work better or worse because of it.
>>>     No.  If the rules apply to descendant children, all normal
>>>     examples work well (including the ones in the appendix).
>>>
>>>
>>>>     IMO the number of rules required to implement a use-case is not
>>>>     very relevant or objective criteria.
>>>     Yes it is, particularly when the difference is between needing a
>>>     1 line rule, and a 100+ line rule.
>>>
>>>>
>>>>     Using the previous example of /home and /home/user1,
>>>>     if the user1 is given read access to /home, then (according to you)
>>>>     it also has read access to every user subtree under /home.
>>>>     Instead of 1 rule per user, 2 rules are needed
>>>     No, just 1 rule per user:
>>>        read-default=deny
>>>        group=user1, path=/home/user1, action=permit
>>>
>>>     This is because of my two proposed changes:
>>>
>>>     (i) that a data-node path match succeeds if it matches the path
>>>     prefix from the root of the tree.  I.e. so the data-rule "/foo"
>>>     matches "/foo" and all of foo's descendant children nodes.
>>>     <- This means that you only need 1 entry instead of 100 entries.
>>>
>>>     (ii) if a data-node rule has action "permit" then it implicitly
>>>     allows read access for all ancestor parent nodes up to the
>>>     root.  (I.e. to mitigate the original change proposed on this
>>>     thread.)
>>>     <- This means that you don't need a separate read rule for
>>>     "/home".  Read access to that node it is implicitly given via
>>>     "group=user1, path=/home/user1, action=permit", hence meaning
>>>     that the rule works the same way as it does on an rfc6536
>>>     compliant implementation.
>>>
>>>>
>>>>        read-default=deny
>>>>        group=*, path=/home, action=permit
>>>>        group=user1, path=/home/user1, action=permit
>>>>
>>>>     The above rules would allow access for every user to every
>>>>     other user.
>>>>     The 2nd rule has no effect, which is counter-intuitive.
>>>>     Every user dir would need 2 rules
>>>>
>>>>        read-default=deny
>>>>        group=*, path=/home, action=permit
>>>>        group=user1, path=/home/user1, action=permit
>>>>        group=*, path=/home/user1, action=deny
>>>>
>>>>>         There is nothing that says this is how it works.
>>>>>         If it did, once could never have privileged sub-fiolders
>>>>>
>>>>>              /var/log -> permit
>>>>>              /var/log/apache2  -> deny
>>>>
>>>>         Yes, you can, you just list the longest path first in the
>>>>         list of rules:
>>>>
>>>>          (1)  /var/log/apache2  -> deny
>>>>           (2) /var/log -> permit
>>>>
>>>>         Any requests that attempt to access anything under
>>>>         /var/log/apache2 would match rule (1) and be denied.
>>>>         Any requests that attempt to access anything under
>>>>         /var/log, but not under /var/log/apache2, would fail to
>>>>         match rule (1), but would match rule (2) instead and be
>>>>         permitted.
>>>>
>>>>
>>>>
>>>>     I do not see any text in the draft or RFC 7950 that
>>>>     suggests that /var/log and /var/log/apache2 represent the same
>>>>     data node.
>>>     They are different data nodes, but I don't see how that is relevant.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>>
>>>>
>>>>     Andy
>>>>
>>>>>
>>>>>
>>>>>             > (ii) if a data-node rule has action "permit" then it
>>>>>             implicitly allows read access for all ancestor parent
>>>>>             nodes up to the root.  (I.e. to mitigate the original
>>>>>             change proposed on this thread.)
>>>>>
>>>>>             This seems reasonable to me, although I haven't at
>>>>>             this point evaluated
>>>>>             the suggestion in detail. In any case I think the main
>>>>>             point both
>>>>>             regarding this and the prefix match is that this
>>>>>             update to 6536 can't
>>>>>             make radical changes to the semantics compared to a
>>>>>             "reasonable
>>>>>             interpretation" (hard to define, I know) of the
>>>>>             under-specified
>>>>>             original.
>>>>>
>>>>>
>>>>>         The text does not say this at all so I do not approve of
>>>>>         this change
>>>>
>>>>         In the RFC version of the NACM this wasn't required because
>>>>         operation 'none' didn't require read access.  Now read
>>>>         access is required even for operation 'none', then this
>>>>         change makes sense to make the NACM changes backwards
>>>>         compatible, whilst still closing the security hole.
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>>
>>>>>
>>>>>             --Per
>>>>>
>>>>>
>>>>>
>>>>>         Andy
>>>>>
>>>>>             > Thanks,
>>>>>             > Rob
>>>>>             >
>>>>>             >
>>>>>             >>
>>>>>             >> Thanks
>>>>>             >>
>>>>>             >>>
>>>>>             >>>
>>>>>             >>> Andy
>>>>>             >>>
>>>>>             >>>
>>>>>             >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton
>>>>>             
>>>>>             >>
>>>>>             wrote:
>>>>>             >>>
>>>>>             >>>     Hi Andy,
>>>>>             >>>
>>>>>             >>>     It isn't clear to me whether matching a path
>>>>>             in NACM either:
>>>>>             >>>       (i) Only applies to the specific node, and
>>>>>             not any children, or
>>>>>             >>>       (ii) Applies to the specific node and all
>>>>>             descendant children nodes as well.
>>>>>             >>>
>>>>>             >>>     As an example, using the tree below.  if I
>>>>>             have a rule that matches path "A/B" then does that
>>>>>             apply to only the specific node "A/B", or does it also
>>>>>             apply to all descendant children of "A/B" as
>>>>>             >>>     well?
>>>>>             >>>
>>>>>             >>>     In rfc6536bis-08, section "3.4.5. Data Node
>>>>>             Access Validation", step 6 states:
>>>>>             >>>
>>>>>             >>>             *  The rule does not have a
>>>>>             "rule-type" defined or the "rule-
>>>>>             >>> type" is "data-node" and the *"path" matches the
>>>>>             requested data node*, action node, or notification node.
>>>>>             >>>
>>>>>             >>>
>>>>>             >>>     My reading of this is that it implies that the
>>>>>             interpretation of the path rule is (i), but this is
>>>>>             not how I would normally expect an ACL rule to apply
>>>>>             in a tree like object (e.g a directory
>>>>>             >>>     file system).
>>>>>             >>>
>>>>>             >>>     However, the examples in Appendix B.4. imply
>>>>>             that the path rule is to be interpreted like (ii), or
>>>>>             otherwise the example rules seem to be mostly pointless.
>>>>>             >>>
>>>>>             >>>     E.g. taking this example from appendix B.4:
>>>>>             >>>
>>>>>             >>> 
>>>>>             >>> permit-dummy-interface
>>>>>             >>> >
>>>>>             >>> /acme:interfaces/acme:interface[acme:name='dummy']
>>>>>             >>> 
>>>>>             >>> read update
>>>>>             >>> permit
>>>>>             >>> 
>>>>>             >>> Allow the limited and guest groups read
>>>>>             >>>                and update access to the dummy
>>>>>             interface.
>>>>>             >>> 
>>>>>             >>> 
>>>>>             >>>
>>>>>             >>>
>>>>>             >>>     If the rule is (i)  then the access rule
>>>>>             allows the client to read the specific node
>>>>>             "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>>>             but not any child leafs/containers of that interface,
>>>>>             >>>     this doesn't seem useful.
>>>>>             >>>
>>>>>             >>>     Further comments inline below ...
>>>>>             >>>
>>>>>             >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>>             >>>>     Hi,
>>>>>             >>>>
>>>>>             >>>>     This change has no impact on the server if
>>>>>             /nacm/read-default is "permit".
>>>>>             >>>>     In that case, the extra read rules for /A and
>>>>>             /A/B are not needed.
>>>>>             >>>     I agree.
>>>>>             >>>
>>>>>             >>>>     An operator worried about read access should
>>>>>             set read-default to "deny".
>>>>>             >>>     I agree.  This is the scenario that I'm
>>>>>             considering.
>>>>>             >>>
>>>>>             >>>>     In that case, explicit rules to read /A and
>>>>>             /A/B would be needed
>>>>>             >>>>     in the new NACM.
>>>>>             >>>     Yes, if the interpretation of the rule is (i)
>>>>>             above.
>>>>>             >>>     Otherwise if the interpretation is (ii) then
>>>>>             you only need "read /A" since that implies "read A/B"
>>>>>             as well (as long as the rules are listed in the
>>>>>             correct order).
>>>>>             >>>
>>>>>             >>>
>>>>>             >>>>       The deny rules would not be needed.
>>>>>             >>>     Only if the interpretation of the rule is (i)
>>>>>             above.  In which case the "read/write 'A/B/J' rule
>>>>>             would not be sufficient.  It would be necessary to
>>>>>             define an Xpath expressions that contains
>>>>>             >>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>>>             >>>
>>>>>             >>>     If the interpretation of the rule is (ii) then
>>>>>             you would also need all the explicit deny statements
>>>>>             as well, otherwise they would be allowed by the "read
>>>>>             /A" rule above.
>>>>>             >>>
>>>>>             >>>     Thanks,
>>>>>             >>>     Rob
>>>>>             >>>
>>>>>             >>>
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>     Andy
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton
>>>>>             
>>>>>             >>
>>>>>             wrote:
>>>>>             >>>>
>>>>>             >>>>         Hi,
>>>>>             >>>>
>>>>>             >>>>         I'm not sure about this change.
>>>>>             >>>>
>>>>>             >>>>         I'm not that familiar with NACM, but if
>>>>>             you want to give a particular set of users read/write
>>>>>             access to a subtree, but not allow them to have any
>>>>>             other access to the configuration in the
>>>>>             >>>>         running datastore then with the existing
>>>>>             RFC, that could be expressed with a single rule
>>>>>             (example in 6536bis, appendix B.4)
>>>>>             >>>>
>>>>>             >>>>         With this new change, I think that you
>>>>>             may need to configure many more rules to achieve the
>>>>>             same thing.  I think that you would need to give read
>>>>>             access to the top node in the desired
>>>>>             >>>>         path, and then separate explicit "deny"
>>>>>             rules for every sibling child node walking from the
>>>>>             top of the tree down to the data node that read/write
>>>>>             access is actually being given to.  The
>>>>>             >>>>         example below may explain my
>>>>>             understanding better:
>>>>>             >>>>
>>>>>             >>>>         E.g. For a tree of data nodes, rooted at
>>>>>             A, if we wanted to give read/write access only to "J"
>>>>>             subtree, and no access for the rest of the tree then:
>>>>>             >>>>
>>>>>             >>>>           A
>>>>>             >>>>           |
>>>>>             >>>>  --------------------
>>>>>             >>>>  |      |     |     |
>>>>>             >>>>  B      C     D     E
>>>>>             >>>>  |
>>>>>             >>>> -----------
>>>>>             >>>>            |  |  |  |
>>>>>             >>>>            F  G  H  J
>>>>>             >>>>       |
>>>>>             >>>>      ...
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>         In the old model, I think that the ACL
>>>>>             rules would be 1 rules long (assuming default deny all):
>>>>>             >>>> "read/write 'A/B/J'
>>>>>             >>>>
>>>>>             >>>>         In the new model, I think that the
>>>>>             equivalent ACL rules would need to be 8 rules long
>>>>>             (assuming default deny all):
>>>>>             >>>> "read/write 'A/B/J'
>>>>>             >>>> "read A"
>>>>>             >>>> "deny C"
>>>>>             >>>> "deny D"
>>>>>             >>>> "deny E"
>>>>>             >>>> "deny F"
>>>>>             >>>> "deny G"
>>>>>             >>>> "deny H"
>>>>>             >>>>
>>>>>             >>>>         Note, I am assuming that a "path" rule
>>>>>             matches for the given path and all descendant nodes. 
>>>>>             The draft doesn't seem to be particularly clear on
>>>>>             this point (it states that the rule applies
>>>>>             >>>>         when the path matches, but this would
>>>>>             seem to be counter intuitive), and perhaps it could be
>>>>>             clarified.
>>>>>             >>>>
>>>>>             >>>>         If this change is allowed, then the
>>>>>             example in appendix B.4 looks like it would need to be
>>>>>             fixed, since the "limited-acl" probably wouldn't give
>>>>>             any access at all, unless default read
>>>>>             >>>>         access had been given.
>>>>>             >>>>
>>>>>             >>>>         But, possibly I'm misunderstanding how
>>>>>             this all works!  If so, apologies for the noise :-)
>>>>>             >>>>
>>>>>             >>>>         Thanks,
>>>>>             >>>>         Rob
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>             >>>>>  Dear all,
>>>>>             >>>>>
>>>>>             >>>>>  Here is a major change in
>>>>>             draft-ietf-netconf-rfc6536bis, suggested by the
>>>>>             Security AD Eric Rescola part of the IESG review,
>>>>>             which I would like to validate with the WG. See
>>>>>             >>>>>
>>>>>             https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>>>>             
>>>>>             >>>>             >
>>>>>             >>>>>
>>>>>             >>>>>  
>>>>>             >>>>>         The NETCONF WG was cc'ed for the entire
>>>>>             discussion.
>>>>>             >>>>>  What do you think? I will draw the conclusions
>>>>>             by Friday Nov 10th.
>>>>>             >>>>>
>>>>>             >>>>>  Note: If the WG is fine, the next step is to
>>>>>             approve this document.
>>>>>             >>>>>
>>>>>             >>>>>  Regards, Benoit
>>>>>             >>>>>
>>>>>             >>>>>
>>>>>             >>>>>  _______________________________________________
>>>>>             >>>>>  Netconf mailing list
>>>>>             >>>>> Netconf@ietf.org 
>>>>>             >
>>>>>             >>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>             
>>>>>             >>>>             >
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>
>>>>>             >>>
>>>>>             >>> _______________________________________________
>>>>>             >>> Netconf mailing list
>>>>>             >>> Netconf@ietf.org 
>>>>>             >
>>>>>             >>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>             
>>>>>             >>
>>>>>             >> Mahesh Jethanandani
>>>>>             >> mjethanandani@gmail.com
>>>>>             
>>>>>             >>>>             >
>>>>>             >
>>>>>             >
>>>>>             >
>>>>>             > _______________________________________________
>>>>>             > Netconf mailing list
>>>>>             > Netconf@ietf.org 
>>>>>             > https://www.ietf.org/mailman/listinfo/netconf
>>>>>             
>>>>>             >
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>
>


--------------5DE615BA2360F6FD6C40074B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k
eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8ZGl2IGNsYXNzPSJt
b3otY2l0ZS1wcmVmaXgiPkhpIFJvYiw8YnI+DQogICAgICA8YnI+DQogICAgICBBdCB0aGF0
IHBvaW50cyBpbiB0aW1lLCBpZiBpdCBjbGFyaWZpZXMgdGhlIHNwZWMuIGFuZCB0aGUgYXV0
aG9ycw0KICAgICAgYWdyZWUgd2l0aCB0aGlzLCBsZXQncyBkbyB0aGUgcmlnaHQgdGhpbmcu
PGJyPg0KICAgICAgPGJyPg0KICAgICAgUmVnYXJkcywgQmVub2l0Ljxicj4NCiAgICA8L2Rp
dj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KICAgICAgY2l0ZT0ibWlkOmMyNjYz
MTAzLTcwYzItMGY1Mi1mMjRmLTg1MjQ2MjUwOWUyN0BjaXNjby5jb20iPg0KICAgICAgPG1l
dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz
ZXQ9dXRmLTgiPg0KICAgICAgPHA+SGkgQmVub2l0LDwvcD4NCiAgICAgIDxwPlRoZXJlIGlz
IGFsc28gb25lIGZ1cnRoZXIsIHVucmVsYXRlZCBjaGFuZ2UgdGhhdCBJIGFtIHByb3Bvc2lu
Zw0KICAgICAgICBpcyBtYWRlIHRoZSBkcmFmdCBiZWZvcmUgaXQgaXMgcHVibGlzaGVkLCB0
byBoZWxwIGJldHRlciBjbGFyaWZ5DQogICAgICAgIHRoZSBleHBlY3RlZCBiZWhhdmlvci7C
oCBJdCBpc24ndCB0aGUgZW5kIG9mIHRoZSB3b3JsZCBpZiB0aGlzDQogICAgICAgIGRvZXNu
J3QgZ28gaW4sIGJ1dCBJIHRoaW5rIHRoYXQgaXQgcHJldmVudHMgc29tZXRpbWUgdGFraW5n
IGENCiAgICAgICAgZGlmZmVyZW50LCBidXQgSU1PIHJlYXNvbmFibGUsIGludGVycHJldGF0
aW9uIG9mIGhvdyAid2hlbiINCiAgICAgICAgc3RhdGVtZW50cyBhcmUgY29uc2lkZXJlZCwg
YW5kIHRoZW4gaGF2aW5nIGEgZnV0dXJlIGFyZ3VtZW50DQogICAgICAgIGFib3V0IHdoYXQg
YmVoYXZpb3IgaXQgc3BlY2lmaWVkIGluIHRoZSBzdGFuZGFyZC48YnI+DQogICAgICA8L3A+
DQogICAgICA8cD5JZiB3ZSBjbGFyaWZ5IGl0IG5vdywgdGhlbiBpdCBjbG9zZXMgdGhhdCBk
b29yIDotKTwvcD4NCiAgICAgIDxwPkkndmUgcHJvcG9zZWQgdGV4dCB0byBBbmR5IGFuZCBN
YXJ0aW4gb24gTW9uZGF5LCBidXQgSSd2ZSBub3QNCiAgICAgICAgaGVhcmQgYmFjayB5ZXQu
PC9wPg0KICAgICAgPHA+TmV0Y29uZiBlbWFpbCB3aXRoIHByb3Bvc2VkIHRleHQgYXR0YWNo
ZWQuwqAgVGhlIHRleHQgZG9lc24ndA0KICAgICAgICBuZWNlc3NhcmlseSBoYXZlIHRvIG1h
dGNoIHRoaXMsIGJ1dCBwZXJzb25hbGx5IEkgdGhpbmsgdGhhdCBpdA0KICAgICAgICBpcyB1
c2VmdWwgaWYgdGhlIGRyYWZ0IHNheXMgc29tZXRoaW5nIG9uIHRoaXMuPGJyPg0KICAgICAg
PC9wPg0KICAgICAgVGhhbmtzLDxicj4NCiAgICAgIFJvYjxicj4NCiAgICAgIDxicj4NCiAg
ICAgIDxicj4NCiAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMjIvMTEv
MjAxNyAxMzoyNSwgQmVub2l0IENsYWlzZQ0KICAgICAgICB3cm90ZTo8YnI+DQogICAgICA8
L2Rpdj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQogICAgICAgIGNpdGU9Im1p
ZDplNDE4ZTAwNy1mYmFjLTAyOWQtOWM3Ny1lZDMzZGYzZDIzM2JAY2lzY28uY29tIj4NCiAg
ICAgICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMS8xMC8yMDE3IDc6MjMg
UE0sIEFuZHkgQmllcm1hbg0KICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgPC9kaXY+
DQogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6Q0FCQ09DSFRF
WHdoQXE2TnpvQUdIY0MtRUUxOWJYSjBrYnFQUzBod0pCNV8rUnRPZnlnQG1haWwuZ21haWwu
Y29tIj4NCiAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj5IaSwNCiAgICAgICAgICAgIDxkaXY+
PGJyPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2PkhlcmUgYXJlIHNv
bWUgcHJvcG9zZWQgZWRpdHMgdG8gbWFrZSB0aGUgZGF0YSBydWxlDQogICAgICAgICAgICAg
IGNvbnNpc3RlbnQgd2l0aCB0aGUgZXhhbXBsZXMuPC9kaXY+DQogICAgICAgICAgICA8ZGl2
Pk5vdGUgdGhhdCB0aGlzIGlzc3VlIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBlZGl0IGluIHRo
ZQ0KICAgICAgICAgICAgICBvcmlnaW5hbCAxLXdlZWsgY2hhbmdlLjwvZGl2Pg0KICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgIFRoYXQncyByaWdo
dCwgYnV0IHdlIGZvdW5kIGEgc291cmNlIG9mIG1pc2ludGVycHJldGF0aW9uIGluIHRoZQ0K
ICAgICAgICBkcmFmdCBhbmQgeW91IGhhdmUgcmlnaHRseSBjb3JyZWN0ZWQgaXQgaW4gdGhl
IGdpdGh1YiB2OS48YnI+DQogICAgICAgIDxicj4NCiAgICAgICAgUmVnYXJkcywgQmVub2l0
PGJyPg0KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KY2l0ZT0ibWlkOkNBQkNP
Q0hURVh3aEFxNk56b0FHSGNDLUVFMTliWEowa2JxUFMwaHdKQjVfK1J0T2Z5Z0BtYWlsLmdt
YWlsLmNvbSI+DQogICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICA8ZGl2
Pjxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPGRpdj48YnI+DQogICAg
ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+c2VjLiAzLjMuNTo8L2Rpdj4NCiAg
ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8
ZGl2Pk9MRDo8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2Rl
IHJ1bGU6IMKgY29udHJvbHMgYWNjZXNzIGZvciBhIHNwZWNpZmljDQogICAgICAgICAgICAg
ICAgZGF0YSBub2RlLCBpZGVudGlmaWVkPC9kaXY+DQogICAgICAgICAgICAgIDxkaXY+wqAg
wqAgwqAgYnkgaXRzIHBhdGggbG9jYXRpb24gd2l0aGluIHRoZSBjb25jZXB0dWFsIFhNTA0K
ICAgICAgICAgICAgICAgIGRvY3VtZW50IGZvciB0aGU8L2Rpdj4NCiAgICAgICAgICAgICAg
PGRpdj7CoCDCoCDCoCBkYXRhIG5vZGUuPC9kaXY+DQogICAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8
ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPGRpdj5ORVc6PC9k
aXY+DQogICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCBkYXRhIG5vZGUgcnVs
ZTogwqBjb250cm9scyBhY2Nlc3MgZm9yIGEgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICBk
YXRhIG5vZGUgYW5kIGl0cyBkZXNjZW5kYW50cyw8L2Rpdj4NCiAgICAgICAgICAgICAgPGRp
dj7CoCDCoCDCoCBpZGVudGlmaWVkIGJ5IGl0cyBwYXRoIGxvY2F0aW9uIHdpdGhpbiB0aGUN
CiAgICAgICAgICAgICAgICBjb25jZXB0dWFsIFhNTCBkb2N1bWVudCBmb3IgdGhlPC9kaXY+
DQogICAgICAgICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgIDxkaXY+c2VjIDMuNC41LCBzdGVwIDYsIGJ1bGxldCAyOjwvZGl2Pg0KICAgICAgICAg
ICAgPGRpdj48YnI+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+PGJy
Pg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2Pk9MRDo8L2Rpdj4NCiAg
ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCDCoCAqIMKgVGhlIHJ1bGUg
ZG9lcyBub3QgaGF2ZSBhICJydWxlLXR5cGUiDQogICAgICAgICAgICAgICAgZGVmaW5lZCBv
ciB0aGUgInJ1bGUtPC9kaXY+DQogICAgICAgICAgICAgIDxkaXY+wqAgwqAgwqAgwqAgwqAg
wqB0eXBlIiBpcyAiZGF0YS1ub2RlIiBhbmQgdGhlICJwYXRoIg0KICAgICAgICAgICAgICAg
IG1hdGNoZXMgdGhlIHJlcXVlc3RlZDwvZGl2Pg0KICAgICAgICAgICAgICA8ZGl2PsKgIMKg
IMKgIMKgIMKgIMKgZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwgb3Igbm90aWZpY2F0aW9uDQog
ICAgICAgICAgICAgICAgbm9kZS48L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIg
c3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+ICAgICAgPC9wcmU+DQogICAgICAgICAgICAgIDxw
cmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21h
cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPk5FVzo8
L3ByZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9
ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7
Y29sb3I6cmdiKDAsMCwwKSI+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250
LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpu
b3JtYWwiPsKgIMKgIMKgIMKgICogwqBUaGUgcnVsZSBkb2VzIG5vdCBoYXZlIGEgInJ1bGUt
dHlwZSIgZGVmaW5lZCBvciB0aGUgInJ1bGUtPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdi
KDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs
bDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgIMKgIMKgdHlwZSIgaXMgImRhdGEt
bm9kZSIgYW5kIHRoZSAicGF0aCIgbWF0Y2hlcyB0aGUgcmVxdWVzdGVkPC9kaXY+PGRpdiBz
dHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlm
O2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgIMKgIMKg
ZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwgb3Igbm90aWZpY2F0aW9uIG5vZGUuIEEgcGF0aCBp
czwvZGl2PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJp
YWwsc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7d2hpdGUtc3BhY2U6bm9ybWFsIj7CoCDC
oCDCoCDCoCDCoCDCoGNvbnNpZGVyZWQgdG8gbWF0Y2ggaWYgdGhlIGN1cnJlbnQgZGF0YSBu
b2RlIGlzIHRoZSBkYXRhIG5vZGU8L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQs
MzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsO3doaXRl
LXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAgwqAgwqAgwqBzcGVjaWZpZWQgYnkgdGhlIHBhdGgs
IG9yIGlzIGEgZGVzY2VuZGFudCBkYXRhIG5vZGUgb2YgdGhpcyBkYXRhIG5vZGUuPC9kaXY+
PC9wcmU+DQogICAgICAgICAgICAgIDxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxl
PSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4
O2NvbG9yOnJnYigwLDAsMCkiPmFwcGVuZGl4IEIuNDogKDIgYnVncyBpbiBleHBsYW5hdGlv
bik8L3ByZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5
bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTow
cHg7Y29sb3I6cmdiKDAsMCwwKSI+T0xEOjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNs
YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz
LjMzMzNweCI+ICAgICAgZGVueS1uYWNtOiAgVGhpcyBydWxlIGRlbmllcyB0aGUgImd1ZXN0
IiBncm91cCBhbnkgYWNjZXNzIHRvIHRoZQ0KICAgICAgJmx0O25hY20mZ3Q7IHN1YnRyZWUu
ICBOb3RlIHRoYXQgdGhlIGRlZmF1bHQgbmFtZXNwYWNlIGlzIG9ubHkNCiAgICAgIGFwcGxp
Y2FibGUgYmVjYXVzZSB0aGlzIHN1YnRyZWUgaXMgZGVmaW5lZCBpbiB0aGUgc2FtZSBuYW1l
c3BhY2UNCiAgICAgIGFzIHRoZSAmbHQ7ZGF0YS1ydWxlJmd0OyBlbGVtZW50Lg0KPC9zcGFu
PjwvZm9udD48L3ByZT4NCiAgICAgICAgICAgICAgPHByZSBjbGFzcz0iZ21haWwtbmV3cGFn
ZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xv
cj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPiA8L3NwYW4+
PC9mb250PjwvcHJlPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdl
IiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxwcmUgY2xhc3M9
ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4z
MzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPk5FVzo8L3ByZT48cHJl
IGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJv
dHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEzLjMzMzNweCI+ICAgICAgZGVueS1uYWNtOiAgVGhpcyBydWxlIGRlbmllcyB0aGUgImd1
ZXN0IiBncm91cCBhbnkgYWNjZXNzIHRvIHRoZQ0KICAgICAgJmx0O25hY20mZ3Q7IHN1YnRy
ZWUuDQo8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0
eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMw
MDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZSBjbGFzcz0iZ21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6
MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48L3ByZT48cHJlIGNs
YXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz
LjMzMzNweCI+DQo8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9ImdtYWlsLW5ld3Bh
Z2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQgY29s
b3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij5BbmR5PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFy
Z2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+DQo8L3NwYW4+PC9mb250PjwvcHJl
PjxwcmUgY2xhc3M9ImdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJn
aW4tYm90dG9tOjBweCI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTMuMzMzM3B4Ij4NCjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9wcmU+DQogICAgICAg
ICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJn
bWFpbF9leHRyYSI+PGJyPg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi
Pk9uIEZyaSwgTm92IDEwLCAyMDE3IGF0IDk6MjQgQU0sDQogICAgICAgICAgICAgIFJvYmVy
dCBXaWx0b24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YQ0KICAgICAgICAgICAgICAgICAgaHJl
Zj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAg
ICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+
Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICA8
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAg
ICAgICAgICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct
bGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgIDxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xv
cj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgICAgICA8cD48YnI+DQogICAgICAgICAgICAg
ICAgICA8L3A+DQogICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJtXzkwNjQ4Mjg2OTQ3Nzk1MzI4Mzhtb3otY2l0ZS1wcmVmaXgiPk9uDQog
ICAgICAgICAgICAgICAgICAgIDEwLzExLzIwMTcgMTY6MzMsIEFuZHkgQmllcm1hbiB3cm90
ZTo8YnI+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0i
bHRyIj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0
cmEiPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1
b3RlIj5PbiBGcmksIE5vdiAxMCwgMjAxNyBhdA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICA4OjE2IEFNLCBSb2JlcnQgV2lsdG9uIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGENCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNv
bSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8L3NwYW4+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNsYXNzPSJtXzkwNjQ4Mjg2OTQ3Nzk1MzI4MzhnbWFpbC1t
Xy03MzYxNjQ3MjgzNTIwNDU2NjM1bW96LWNpdGUtcHJlZml4Ij5Pbg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAxMC8xMS8yMDE3IDE1OjQ5LCBBbmR5IEJpZXJtYW4gd3Jv
dGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJn
bWFpbF9xdW90ZSI+T24gRnJpLCBOb3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMTAsIDIwMTcgYXQgNTowNyBBTSwgUGVyIEhlZGVsYW5kDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGENCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpw
ZXJAdGFpbC1mLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5wZXJAdGFpbC1mLmNvbTwvYT4mZ3Q7
PC9zcGFuPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3Rl
IGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtw
YWRkaW5nLWxlZnQ6MWV4Ij5Pbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDIwMTctMTEtMTAgMTE6NDIsIFJvYmVydCBXaWx0b24NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsgT24gMTAvMTEvMjAxNyAxMDowMiwgTWFoZXNoDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSmV0aGFuYW5kYW5pIHdyb3Rl
Ojxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFu
ayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzo8YQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5h
bmRhbmlAZ21haWwuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21haWwu
Y288d2JyPm08L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyBPbiBOb3YgMTAsIDIwMTcsIGF0DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgMTA6MDcgQU0sIEFuZHkgQmllcm1hbiAmbHQ7PGEN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0
bzphbmR5QHl1bWF3b3Jrcy5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5dW1hd29ya3Mu
Y29tPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtt
YWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhy
ZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5
dW1hd29ya3MuY29tPC9hPiZndDsmZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0OyBIaSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBUaGUgdGVybSAiZGF0YQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUiIGlzIHVzZWQgaW4g
dGhlIGRvY3VtZW50IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcmVmZXIgdG8gdGhlIHRvcC1sZXZlbCBub2RlPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBvZiB0aGUgc3BlY2lmaWVkDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0LCBub3QgdGhl
IGVudGlyZSBzdWJ0cmVlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgKGlmIGFueSkuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhlIGRhdGEtcnVsZSAvZm9vDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9lcyBub3QgbWF0Y2ggL2Zvby9jaGlsZDEg
aW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdGV4dCBi
ZWxvdy48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7IFRoZSBjaGlsZCBub2RlcyBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBvbWl0dGVkIGJlY2F1c2Ugb2Ygc3RlcCAxMS48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IFRoZSBh
ZG1pbiBoYXMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBl
eHBsaWNpdGx5IHBlcm1pdCBpbmRpdmlkdWFsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgY2hpbGQgbm9kZXMgKG9yIG1vZHVsZXMpLjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhpcyBzZWVt
cyBjb3JyZWN0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYg
dGhlIHJlYWQtZGVmYXVsdCBpcyAiZGVueSIuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgU2hvdWxkIGFueSB0ZXh0IGJl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWRkZWQgb3IgY2hh
bmdlZCB0byBtYWtlIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBtb3JlIGNsZWFyPzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyBJIHdvdWxkIGFncmVlIHdpdGgNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBSb2JlcnQgdGhhdCBpdCB3YXMgbm90IGVudGlyZWx5
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xlYXIgdGhhdCBy
dWxlIGFwcGxpZWQgb24gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcGFyZW50IGRhdGEtbm9kZSBkb2VzIG5vdCBhcHBseQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSBjaGlsZCBub2Rlcy4gU28geWVzLCBp
dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIGhlbHAg
dG8gY2xhcmlmeSBpdC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyBXZSBzaG91bGQgYmUgZG9pbmcgbW9yZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRoYW4gY2xhcmlmeWluZyBpdC7CoCBXZSBuZWVkIHRv
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZml4IGl0IHNvIHRo
YXQgaXQgd29ya3MgaW4gYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHNlbnNpYmxlIHdheS7CoCBJLmUuIHRvIG1ha2UgdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbm9ybWF0aXZlIHRleHQgY29uc2lzdGVudCB3aXRo
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGJlaGF2aW91
ciBjdXJyZW50bHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk
ZXNjcmliZWQgaW4gdGhlIGV4YW1wbGVzIGluPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFwcGVuZGl4IEIuNC48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IElmIHdlIGZvbGxvdyBBbmR5J3MN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlv
biB0aGF0IGEgZGF0YSBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgZG9lc24ndCBtYXRjaCBjaGlsZCBub2RlcyB0aGVuDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGhvc2UgZXhhbXBsZXMgYXJlIGNvbXBsZXRlbHkN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm9uZy7CoCBFLmcu
IHRoZSA0dGggcnVsZSBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGRlc2NyaWJlZCBhcyAiVGhpcyBydWxlIGdpdmVzDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhlICdhZG1pbicgZ3JvdXAgcmVhZC13cml0ZTxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IGFjY2VzcyB0
byBhbGwgYWNtZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZs
dDtpbnRlcmZhY2UmZ3Q7IGVudHJpZXMuIsKgIEJ1dA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIElmIHRoZSBwYXRoIG9ubHkgc3RyaWN0bHkNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaGVzDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIi9hY21lOmludGVyZmFjZXMvYWNtZTppbnRl
cmZhPHdicj5jZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
aGVuIHRoZSBhZG1pbiBncm91cCBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYWNoaWV2ZXMgbm90aGluZyB1c2VmdWwgYXQgYWxsLsKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGFkbWluIGlzIG5vdCBldmVu
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgYWxs
b3dlZCB0byBjcmVhdGUgYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbnRlcmZhY2UgYmVjYXVzZSB0aGV5IHdvdWxkIG5vdA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGV2ZW4gaGF2ZSBwZXJtaXNzaW9uIHRvIHdyaXRl
IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGxpc3Qg
a2V5ICduYW1lJyBub2RlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcmVxdWlyZWQgdG8gY3JlYXRlIGEgbGlzdA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGVudHJ5IcKgIEluc3RlYWQsIGEgc2VwYXJhdGUgcnVsZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIGJlIHJlcXVpcmVk
IGZvciBldmVyeTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7IHNpbmdsZSBwb3NzaWJsZSBzY2hlbWEgbm9kZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVuZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIi9hY21lOmludGVyZmFjZXMvYWNtZTppbnRlcmZhPHdicj5jZSIh
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIHRo
YXQgdGhpcyBtYWtlcyAicGVybWl0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGRhdGEtbm9kZSBydWxlcyBjb21wbGV0ZWx5DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW51c2FibGUuPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBJIHN0cm9uZ2x5IGFncmVlIHdpdGggdGhpcywgYW5kDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSB3b3VsZCBzYXkgdGhhdCBp
dCBpc24ndCBvbmx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dGhlIGNhc2U8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Zm9yICJwZXJtaXQiIHJ1bGVzIC0gZS5nLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRlbnlpbmcgc29tZSBhY2Nlc3MgdG8gYSBzdWJ0cmVlDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGRhdGE8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwgdGhhdCB3b3VsZCBv
dGhlcndpc2UgYmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw
ZXJtaXR0ZWQgZHVlIHRvIGRlZmF1bHRzIGlzIGF0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbGVhc3QgYXM8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29tbW9uLCBhbmQgdGhlIHJ1bGVzIHdvdWxkIGJlDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAganVzdCBhcyB1bnVzYWJsZSBm
b3IgdGhhdC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc2lkZXMg
dGhlIGV4YW1wbGVzLCBJIHRoaW5rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdGhhdCB0aGUgdmVyeSB1c2Ugb2YgdGhlIHRlcm0NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAibWF0Y2giLDxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0aG91Z2ggdW5mb3J0dW5hdGVseSBub3QNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmVkLCBzdHJvbmds
eSBzdWdnZXN0cyB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaXQgaXMgc29tZXRoaW5nPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG90aGVyIHRoYW4gdXNlIG9mIGUuZy4gdGhlIHRlcm0NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaWRlbnRpZnkiIHdvdWxkIGltcGx5Lg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFkZGl0aW9uYWxseSw8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyB0ZXh0
IGluIHRoZSBkZXNjcmlwdGlvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRoZSAncGF0aCcgbGVhZiBpcyBjb25zaXN0ZW50DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCB0aGU8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0Y2ggYmVpbmcgYSBwcmVmaXggbWF0Y2g6
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoFRoZSBz
cGVjaWFsIHZhbHVlICcvJw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHJlZmVycyB0byBhbGwgcG9zc2libGU8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqBkYXRhc3RvcmUgY29udGVudHMuIjs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZXSVcsIG91ciBOQUNNIGltcGxl
bWVudGF0aW9uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF2
YWlsYWJsZSB0byAoYW5kIHVzZWQgYnkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY3VzdG9tZXJzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHNpbmNlIDIwMTIsIGZvbGxvd3MgdGhlIHByZWZpeA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGxvZ2ljLCBhbmQgSSBoYXZl
IHlldCB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlYXIg
b2Y8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW55IHVz
ZXIgZXhwZWN0aW5nIGl0IHRvIGRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgb3RoZXJ3aXNlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyBUbyBmaXggdGhpcyBwcm9wZXJseSwgd2UNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBuZWVkIHRvIG1ha2UgdGhlIGRhdGEtbm9kZSBwYXRoDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZSBhIHByZWZpeCBt
YXRjaC7CoCBJbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBh
cnRpY3VsYXIsIHdlIG5lZWQgdGV4dCB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3BlY2lmaWVzOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsgKGkpIHRoYXQgYSBkYXRhLW5vZGUgcGF0aA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIHN1Y2NlZWRzIGlmIGl0IG1h
dGNoZXMgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0
aCBwcmVmaXggZnJvbSB0aGUgcm9vdCBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0cmVlLsKgIEkuZS4gc28gdGhlIGRhdGEtcnVsZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvZm9vIiBtYXRjaGVzICIvZm9v
IiBhbmQgYWxsIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Zm9vJ3MgZGVzY2VuZGFudCBjaGlsZHJlbiBub2Rlcy48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFN0cm9uZ2x5IGFncmVlLjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SSBkbyBub3Qg
c2VlIGhvdyB0aGUgdGV4dCBjYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBiZSBpbnRlcnByZXRlZCB0aGlzIHdheS48L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEJlY2F1c2Ugb3RoZXJ3aXNlIHRoZSBwYXRoIG1hdGNoIHBhcnQgb2YNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBOQUNNIHNvbHV0aW9uIGlzIHJlYWxseSBi
cm9rZW4sIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHBhdGggYmFz
ZWQgZXhhbXBsZXMgaW4gdGhlIGFwcGVuZGl4DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBhcmUgZW50aXJlbHkgbWlzbGVhZGluZyBhbmQgd3JvbmcuwqAgVGhlDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBvbmx5IHdheSB0aG9zZSBleGFtcGxlcyBtYWtlIHNl
bnNlIGlzIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aHMgbWF0Y2gg
ZGVzY2VuZGFudCBjaGlsZHJlbiBub2RlcyBhcw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgd2VsbC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SU1PIHRoZSB0ZXh0IGRvZXMgbm90
IHN1cHBvcnQgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVycHJldGF0
aW9uLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgVGhlIGV4YW1w
bGVzIGluIEIuNCwgYW5kIHRoZSBkZWZpbml0aW9uIG9mICIvIg0KICAgICAgICAgICAgICAg
ICAgbWF0Y2hpbmcgYWxsIG5vZGVzIHN1cHBvcnRzIHRoaXMgaW50ZXJwcmV0YXRpb24uPGJy
Pg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgSGVuY2UsIG15
IG9waW5pb24gaXMgdGhhdCBpdCBpcyB0aGUgdGV4dCBpbiAzLjQuNSB0aGF0DQogICAgICAg
ICAgICAgICAgICBpcyBpbmNvcnJlY3RseSBzcGVjaWZpZWQ7IGFuZCB0aGF0IHRoZSBleGFt
cGxlcywNCiAgICAgICAgICAgICAgICAgIGRlZmluaXRpb24gb2YgIi8iIGFuZCBzdGFuZGFy
ZCBwcmFjdGljZSBhcmUgcmlnaHQuPGJyPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAg
ICAgICAgICAgICAgICAgT3RoZXJ3aXNlLCBob3cgZGlkIElFVEYgbWFuYWdlIHRvIHB1Ymxp
c2ggYW4gUkZDIHdoZXJlDQogICAgICAgICAgICAgICAgICB0aGUgcGF0aCBiYXNlZCBleGFt
cGxlcyBhcmUgc28gY29tcGxldGVseSB3cm9uZz/CoMKgDQogICAgICAgICAgICAgICAgICBX
aG9ldmVyIHdyb3RlIGFuZCByZXZpZXdlZCB0aG9zZSBleGFtcGxlcyBjbGVhcmx5IGhhZA0K
ICAgICAgICAgICAgICAgICAgYSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb24gb2YgaG93IHRo
ZXNlIHBhdGggYmFzZWQNCiAgICAgICAgICAgICAgICAgIEFDTHMgd29ya2VkLiA8YnI+DQog
ICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg
ICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAg
ICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i
Z21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21h
aWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZXJlIGlzIG5v
dGhpbmcgc2FpZCBhYm91dCBpbmhlcml0aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RhdGUgZnJvbSB0aGUgcGFyZW50IGRhdGEgbm9kZS48L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj5JIHRoaW5rIG5vIG1hdHRlciBob3cgdGhlIHBlcm1pc3Np
b25zIGFyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlcml2ZWQsIG9uZSBjYW48
L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5maW5kIGV4YW1wbGVzIHRo
YXQgd29yayBiZXR0ZXIgb3Igd29yc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBi
ZWNhdXNlIG9mIGl0LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAg
Tm8uwqAgSWYgdGhlIHJ1bGVzIGFwcGx5IHRvIGRlc2NlbmRhbnQgY2hpbGRyZW4sIGFsbA0K
ICAgICAgICAgICAgICAgICAgbm9ybWFsIGV4YW1wbGVzIHdvcmsgd2VsbCAoaW5jbHVkaW5n
IHRoZSBvbmVzIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgYXBwZW5kaXgpLjxicj4NCiAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAg
ICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAg
ICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJn
bWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFp
bF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SU1PIHRoZSBudW1i
ZXIgb2YgcnVsZXMgcmVxdWlyZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bXBsZW1lbnQgYSB1c2UtY2FzZSBpcyBub3Q8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj52ZXJ5IHJlbGV2YW50IG9yIG9iamVjdGl2ZSBjcml0ZXJpYS48L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg
IDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgIFllcyBpdCBpcywgcGFydGljdWxh
cmx5IHdoZW4gdGhlIGRpZmZlcmVuY2UgaXMgYmV0d2Vlbg0KICAgICAgICAgICAgICAgICAg
bmVlZGluZyBhIDEgbGluZSBydWxlLCBhbmQgYSAxMDArIGxpbmUgcnVsZS48YnI+DQogICAg
ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAg
ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VXNpbmcgdGhlIHByZXZpb3VzIGV4
YW1wbGUgb2YgL2hvbWUgYW5kDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgL2hvbWUv
dXNlcjEsPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+aWYgdGhlIHVz
ZXIxIGlzIGdpdmVuIHJlYWQgYWNjZXNzIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgL2hvbWUsIHRoZW4gKGFjY29yZGluZyB0byB5b3UpPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXY+aXQgYWxzbyBoYXMgcmVhZCBhY2Nlc3MgdG8gZXZlcnkgdXNl
cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1YnRyZWUgdW5kZXIgL2hvbWUuPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg
ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAg
ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pkluc3RlYWQgb2YgMSBydWxlIHBlciB1c2VyLCAyIHJ1bGVzIGFy
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWRlZDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1
b3RlPg0KICAgICAgICAgICAgICAgICAgTm8sIGp1c3QgMSBydWxlIHBlciB1c2VyOjxicj4N
CiAgICAgICAgICAgICAgICAgIMKgwqAgcmVhZC1kZWZhdWx0PWRlbnk8YnI+DQogICAgICAg
ICAgICAgICAgICDCoMKgIGdyb3VwPXVzZXIxLCBwYXRoPS9ob21lL3VzZXIxLCBhY3Rpb249
cGVybWl0PGJyPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg
VGhpcyBpcyBiZWNhdXNlIG9mIG15IHR3byBwcm9wb3NlZCBjaGFuZ2VzOjxicj4NCiAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIChpKSB0aGF0IGEgZGF0YS1u
b2RlIHBhdGggbWF0Y2ggc3VjY2VlZHMgaWYgaXQgbWF0Y2hlcw0KICAgICAgICAgICAgICAg
ICAgdGhlIHBhdGggcHJlZml4IGZyb20gdGhlIHJvb3Qgb2YgdGhlIHRyZWUuwqAgSS5lLiBz
bw0KICAgICAgICAgICAgICAgICAgdGhlIGRhdGEtcnVsZSAiL2ZvbyIgbWF0Y2hlcyAiL2Zv
byIgYW5kIGFsbCBvZiBmb28ncw0KICAgICAgICAgICAgICAgICAgZGVzY2VuZGFudCBjaGls
ZHJlbiBub2Rlcy48YnI+DQogICAgICAgICAgICAgICAgICAmbHQ7LSBUaGlzIG1lYW5zIHRo
YXQgeW91IG9ubHkgbmVlZCAxIGVudHJ5IGluc3RlYWQgb2YNCiAgICAgICAgICAgICAgICAg
IDEwMCBlbnRyaWVzLjxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgIChpaSkgaWYgYSBkYXRhLW5vZGUgcnVsZSBoYXMgYWN0aW9uICJwZXJtaXQiIHRo
ZW4gaXQNCiAgICAgICAgICAgICAgICAgIGltcGxpY2l0bHkgYWxsb3dzIHJlYWQgYWNjZXNz
IGZvciBhbGwgYW5jZXN0b3IgcGFyZW50DQogICAgICAgICAgICAgICAgICBub2RlcyB1cCB0
byB0aGUgcm9vdC7CoCAoSS5lLiB0byBtaXRpZ2F0ZSB0aGUgb3JpZ2luYWwNCiAgICAgICAg
ICAgICAgICAgIGNoYW5nZSBwcm9wb3NlZCBvbiB0aGlzIHRocmVhZC4pPGJyPg0KICAgICAg
ICAgICAgICAgICAgJmx0Oy0gVGhpcyBtZWFucyB0aGF0IHlvdSBkb24ndCBuZWVkIGEgc2Vw
YXJhdGUgcmVhZA0KICAgICAgICAgICAgICAgICAgcnVsZSBmb3IgIi9ob21lIi7CoCBSZWFk
IGFjY2VzcyB0byB0aGF0IG5vZGUgaXQgaXMNCiAgICAgICAgICAgICAgICAgIGltcGxpY2l0
bHkgZ2l2ZW4gdmlhICJncm91cD11c2VyMSwgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAg
ICAgICAgICAgIGFjdGlvbj1wZXJtaXQiLCBoZW5jZSBtZWFuaW5nIHRoYXQgdGhlIHJ1bGUg
d29ya3MgdGhlDQogICAgICAgICAgICAgICAgICBzYW1lIHdheSBhcyBpdCBkb2VzIG9uIGFu
IHJmYzY1MzYgY29tcGxpYW50DQogICAgICAgICAgICAgICAgICBpbXBsZW1lbnRhdGlvbi48
YnI+DQogICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICA8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+
DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqByZWFkLWRl
ZmF1bHQ9ZGVueTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKg
Z3JvdXA9KiwgcGF0aD0vaG9tZSwgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICA8ZGl2PsKgIMKgZ3JvdXA9dXNlcjEsIHBhdGg9L2hvbWUvdXNlcjEs
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlIGFib3Zl
IHJ1bGVzIHdvdWxkIGFsbG93IGFjY2VzcyBmb3INCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBldmVyeSB1c2VyIHRvIGV2ZXJ5IG90aGVyIHVzZXIuPC9kaXY+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgIDxkaXY+VGhlIDJuZCBydWxlIGhhcyBubyBlZmZlY3QsIHdoaWNo
IGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgY291bnRlci1pbnR1aXRpdmUuPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+RXZlcnkgdXNlciBkaXIgd291
bGQgbmVlZCAyIHJ1bGVzPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKg
IMKgcmVhZC1kZWZhdWx0PWRlbnk8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2PsKgIMKgZ3JvdXA9KiwgcGF0aD0vaG9tZSwgYWN0aW9uPXBlcm1pdDwvZGl2Pg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD11c2VyMSwgcGF0
aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlvbj1w
ZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0qLCBwYXRoPS9ob21lL3VzZXIx
LCBhY3Rpb249ZGVueTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl
PSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhl
eDtib3JkZXItbGVmdDoxcHggc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBy
Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PlRoZXJlIGlzIG5vdGhpbmcg
dGhhdCBzYXlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhp
cyBpcyBob3cgaXQgd29ya3MuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+SWYgaXQgZGlkLCBvbmNlIGNvdWxkIG5ldmVyDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBwcml2aWxlZ2VkIHN1Yi1maW9s
ZGVyczwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2
Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqAgwqAvdmFy
L2xvZyAtJmd0OyBwZXJtaXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdj7CoCDCoCDCoC92YXIvbG9nL2FwYWNoZTIgwqAtJmd0Ow0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlbnk8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFllcywgeW91IGNhbiwgeW91IGp1c3QgbGlzdCB0aGUgbG9uZ2VzdA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBmaXJzdCBpbiB0aGUgbGlzdCBv
ZiBydWxlczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICDCoCgxKcKgIC92YXIvbG9nL2FwYWNoZTIgwqAt
Jmd0OyBkZW55PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgKDIpIC92
YXIvbG9nIC0mZ3Q7IHBlcm1pdDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFueSByZXF1ZXN0cyB0aGF0
IGF0dGVtcHQgdG8gYWNjZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbnl0
aGluZyB1bmRlciAvdmFyL2xvZy9hcGFjaGUyIHdvdWxkDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBtYXRjaCBydWxlICgxKSBhbmQgYmUgZGVuaWVkLjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIEFueSByZXF1ZXN0cyB0aGF0IGF0dGVtcHQgdG8gYWNj
ZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbnl0aGluZyB1bmRlciAvdmFy
L2xvZywgYnV0IG5vdCB1bmRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL3Zh
ci9sb2cvYXBhY2hlMiwgd291bGQgZmFpbCB0byBtYXRjaCBydWxlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoMSksIGJ1dCB3b3VsZCBtYXRjaCBydWxlICgyKSBpbnN0ZWFk
IGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmUgcGVybWl0dGVkLjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SSBkbyBub3Qgc2VlIGFueSB0
ZXh0IGluIHRoZSBkcmFmdCBvciBSRkMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA3
OTUwIHRoYXQ8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5zdWdnZXN0
cyB0aGF0IC92YXIvbG9nIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIC92YXIv
bG9nL2FwYWNoZTIgcmVwcmVzZW50IHRoZSBzYW1lIGRhdGENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBub2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwv
ZGl2Pg0KICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAg
ICAgVGhleSBhcmUgZGlmZmVyZW50IGRhdGEgbm9kZXMsIGJ1dCBJIGRvbid0IHNlZSBob3cN
CiAgICAgICAgICAgICAgICAgIHRoYXQgaXMgcmVsZXZhbnQuPGJyPg0KICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgVGhhbmtzLDxicj4NCiAgICAgICAgICAg
ICAgICAgIFJvYjxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
ICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
IDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PkFuZHk8L2Rpdj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x
dW90ZSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0ibWFyZ2luOjBweCAw
cHggMHB4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6
MXB4IHNvbGlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0
KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2
IGJnY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2PsKgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2Nr
cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwy
MDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsgKGlpKSBpZiBhIGRhdGEtbm9kZSBydWxlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgaGFzIGFjdGlvbiAicGVybWl0IiB0aGVuIGl0
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGljaXRseSBh
bGxvd3MgcmVhZCBhY2Nlc3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmb3IgYWxsIGFuY2VzdG9yIHBhcmVudCBub2RlcyB1cA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRvIHRoZSByb290LsKgIChJLmUuIHRvIG1pdGln
YXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIG9yaWdp
bmFsIGNoYW5nZSBwcm9wb3NlZCBvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRoaXMgdGhyZWFkLik8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFRoaXMgc2VlbXMgcmVhc29uYWJsZSB0byBtZSwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBhbHRob3VnaCBJIGhhdmVuJ3QgYXQgdGhpcyBwb2lu
dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV2YWx1YXRlZDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc3VnZ2Vz
dGlvbiBpbiBkZXRhaWwuIEluIGFueQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGNhc2UgSSB0aGluayB0aGUgbWFpbiBwb2ludCBib3RoPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZ2FyZGluZyB0aGlzIGFuZCB0
aGUgcHJlZml4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0
Y2ggaXMgdGhhdCB0aGlzIHVwZGF0ZSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDY1MzYgY2FuJ3Q8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbWFrZSByYWRpY2FsIGNoYW5nZXMgdG8gdGhlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VtYW50aWNzIGNvbXBhcmVkIHRvIGEN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAicmVhc29uYWJsZTxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRh
dGlvbiIgKGhhcmQgdG8gZGVmaW5lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEkga25vdykgb2YgdGhlIHVuZGVyLXNwZWNpZmllZDxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcmlnaW5hbC48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2PlRoZSB0ZXh0IGRvZXMgbm90IHNheSB0aGlzIGF0DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsIHNvIEkgZG8gbm90
IGFwcHJvdmUgb2YgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNoYW5nZTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW4gdGhlIFJGQyB2ZXJz
aW9uIG9mIHRoZSBOQUNNIHRoaXMgd2Fzbid0DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICByZXF1aXJlZCBiZWNhdXNlIG9wZXJhdGlvbiAnbm9uZScgZGlkbid0DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlIHJlYWQgYWNjZXNzLsKgIE5vdyByZWFk
IGFjY2VzcyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWlyZWQgZXZl
biBmb3Igb3BlcmF0aW9uICdub25lJywgdGhlbg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGhpcyBjaGFuZ2UgbWFrZXMgc2Vuc2UgdG8gbWFrZSB0aGUgTkFDTQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgY2hhbmdlcyBiYWNrd2FyZHMgY29tcGF0aWJsZSwg
d2hpbHN0IHN0aWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbG9zaW5nIHRo
ZSBzZWN1cml0eSBob2xlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyw8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBk
aXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFz
cz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXY+wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJs
b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29s
aWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIw
NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAtLVBlcjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2tx
dW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+QW5keTwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0ibWFyZ2luOjBw
eCAwcHggMHB4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IFRoYW5rcyw8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBSb2I8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IFRoYW5rczxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyBBbmR5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7IE9uIFRodSwgTm92IDksIDIwMTcNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdCAyOjQ0IEFNLCBSb2JlcnQgV2lsdG9u
ICZsdDs8YQ0KaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu
ayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cndp
bHRvbkBjaXNjby5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+
Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90
ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0O8KgIMKgIMKgSGkgQW5keSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSXQgaXNuJ3QgY2xl
YXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBtZSB3aGV0
aGVyIG1hdGNoaW5nIGEgcGF0aCBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIE5BQ00gZWl0aGVyOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoChpKSBPbmx5DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXBwbGllcyB0byB0aGUgc3BlY2lm
aWMgbm9kZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQg
bm90IGFueSBjaGlsZHJlbiwgb3I8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAoaWkpIEFwcGxpZXMNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byB0aGUgc3BlY2lmaWMgbm9k
ZSBhbmQgYWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVz
Y2VuZGFudCBjaGlsZHJlbiBub2RlcyBhcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHdlbGwuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEFzIGFuIGV4YW1wbGUsDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNpbmcgdGhlIHRyZWUgYmVs
b3cuwqAgaWYgSSBoYXZlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYSBydWxlIHRoYXQgbWF0Y2hlcyBwYXRoICJBL0IiDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhlbiBkb2VzIHRoYXQgYXBwbHkgdG8gb25seSB0aGUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpYyBub2Rl
ICJBL0IiLCBvciBkb2VzIGl0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYWxzbyBhcHBseSB0byBhbGwgZGVzY2VuZGFudA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNoaWxkcmVuIG9mICJBL0IiIGFzPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
d2VsbD88YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICByZmM2NTM2YmlzLTA4LCBzZWN0aW9uICIzLjQuNS7CoA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdGEgTm9kZSBBY2Nlc3MgVmFsaWRh
dGlvbiIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RlcCA2
IHN0YXRlczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgKsKgIFRoZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGUgZG9lcyBub3QgaGF2ZSBhICJy
dWxlLXR5cGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVm
aW5lZCBvciB0aGUgInJ1bGUtPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSIgaXMgImRhdGEtbm9kZSIg
YW5kIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICoicGF0
aCIgbWF0Y2hlcyB0aGUgcmVxdWVzdGVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZGF0YSBub2RlKiwgYWN0aW9uIG5vZGUsIG9yDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIG5vZGUuPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7wqAgwqAgwqBNeSByZWFkaW5nIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhpcyBpcyB0aGF0IGl0IGltcGxpZXMgdGhhdCB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUg
cGF0aCBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMg
KGkpLCBidXQgdGhpcyBpcyBub3QgaG93IEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB3b3VsZCBub3JtYWxseSBleHBlY3QgYW4gQUNMDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZSB0byBhcHBseSBpbiBhIHRyZWUg
bGlrZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCAo
ZS5nIGEgZGlyZWN0b3J5PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgZmlsZSBzeXN0ZW0pLjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAg
wqBIb3dldmVyLCB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBleGFtcGxlcyBpbiBBcHBlbmRpeCBCLjQuIGltcGx5DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhhdCB0aGUgcGF0aCBydWxlIGlzIHRvIGJlDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0ZWQgbGlrZSAo
aWkpLCBvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVy
d2lzZSB0aGUgZXhhbXBsZSBydWxlcyBzZWVtDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdG8gYmUgbW9zdGx5IHBvaW50bGVzcy48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
RS5nLiB0YWtpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
aGlzIGV4YW1wbGUgZnJvbSBhcHBlbmRpeCBCLjQ6PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDC
oA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtydWxlJmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZsdDtuYW1lJmd0O3Blcm1pdC1kdW1teS1pbnRlcmZhY2UmbHQ7Lzx3
YnI+bmFtZSZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7cGF0aCB4bWxuczphY21lPSI8YQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cDovL2V4YW1w
bGUuY29tL25zL2l0ZiINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vZXhhbXBsZS5j
b208d2JyPi9ucy9pdGY8L2E+Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL25zL2l0ZiINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIj5odHRwOi8vZXhhbXBsZS5jb20vbnMvaXRmPC9hPiZndDsmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgL2FjbWU6aW50ZXJmYWNlcy9hY21lOmludGVyZmFjPHdicj5lW2FjbWU6bmFtZT0nZHVt
bXknXTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZsdDsvcGF0aCZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7YWNjZXNzLW9w
ZXJhdGlvbnMmZ3Q7cmVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHVwZGF0ZSZsdDsvYWNjZXNzLW9wZXJhdGlvbnMmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg
IMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O2Fj
dGlvbiZndDtwZXJtaXQmbHQ7L2FjdGlvbiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7Y29tbWVudCZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBBbGxvdyB0aGUgbGltaXRlZCBhbmQgZ3Vlc3QNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBncm91cHMgcmVhZDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB1cGRhdGUgYWNjZXNzIHRvIHRoZSBkdW1teQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGludGVyZmFjZS48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAg
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L2NvbW1l
bnQmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmx0Oy9ydWxlJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSWYgdGhl
IHJ1bGUgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaSnC
oCB0aGVuIHRoZSBhY2Nlc3MgcnVsZSBhbGxvd3MNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0aGUgY2xpZW50IHRvIHJlYWQgdGhlIHNwZWNpZmljDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9kZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50
ZXJmYTx3YnI+Y2VbYWNtZTpuYW1lPSdkdW1teSddIg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGJ1dCBub3QgYW55IGNoaWxkDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbGVhZnMvY29udGFpbmVycyBvZiB0aGF0DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJmYWNlLDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDC
oCDCoHRoaXMgZG9lc24ndA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHNlZW0gdXNlZnVsLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBGdXJ0aGVyDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tbWVudHMgaW5saW5lIGJlbG93IC4uLjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7wqAgwqAgwqBPbiAwOC8xMS8yMDE3DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMjA6MDUsIEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKg
IMKgSGksPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgVGhpcyBjaGFuZ2UNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBoYXMgbm8gaW1wYWN0IG9uIHRoZSBzZXJ2
ZXIgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvbmFjbS9y
ZWFkLWRlZmF1bHQgaXMgInBlcm1pdCIuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoEluIHRoYXQNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXNlLCB0aGUgZXh0cmEgcmVh
ZCBydWxlcyBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAv
QSBhbmQgL0EvQiBhcmUgbm90IG5lZWRlZC48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBJIGFncmVlLjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0O8KgIMKgIMKgQW4gb3BlcmF0b3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB3b3JyaWVkIGFib3V0IHJlYWQgYWNjZXNzIHNob3VsZA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNldCByZWFkLWRlZmF1bHQgdG8gImRl
bnkiLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDvCoCDCoCDCoEkgYWdyZWUuwqAgVGhpcw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGlzIHRoZSBzY2VuYXJpbyB0aGF0IEknbQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnNpZGVyaW5nLjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgSW4gdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNhc2UsIGV4cGxpY2l0IHJ1bGVzIHRvIHJlYWQgL0ENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBhbmQgL0EvQiB3b3VsZCBiZSBuZWVkZWQ8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgaW4gdGhlIG5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIE5BQ00uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgWWVzLCBpZiB0aGUNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChpKSBhYm92ZS48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqBPdGhlcndpc2UgaWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0aGUgaW50ZXJwcmV0YXRpb24gaXMgKGlpKSB0aGVuDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgeW91IG9ubHkgbmVlZCAicmVhZCAvQSIgc2lu
Y2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IGltcGxp
ZXMgInJlYWQgQS9CIiBhcyB3ZWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKGFzIGxvbmcgYXMgdGhlIHJ1bGVzIGFyZSBsaXN0ZWQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbiB0aGUgY29ycmVjdCBvcmRlcikuPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgVGhlIGRlbnkNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBydWxlcyB3b3VsZCBub3QgYmUgbmVlZGVkLjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDC
oCDCoE9ubHkgaWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHJ1bGUgaXMNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAoaSkgYWJvdmUuwqAgSW4gd2hpY2ggY2FzZSB0aGXCoA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJyZWFkL3dyaXRlICdB
L0IvSicgcnVsZSB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG5vdCBiZSBzdWZmaWNpZW50LsKgIEl0IHdvdWxkIGJlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbmVjZXNzYXJ5IHRvIGRlZmluZSBhbiBYcGF0aA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cHJlc3Npb25zIHRo
YXQgY29udGFpbnM8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBhbGwgY2hpbGRyZW4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBub2RlcyBhcyB3ZWxsLsKgIFBlcmhhcHMNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnQS9CL0ovLyonPzxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqBJZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcnVsZSBpcw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChpaSkgdGhlbiB5b3Ugd291bGQgYWxzbyBuZWVkDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsIHRoZSBleHBsaWNpdCBk
ZW55IHN0YXRlbWVudHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhcyB3ZWxsLCBvdGhlcndpc2UgdGhleSB3b3VsZCBiZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGFsbG93ZWQgYnkgdGhlICJyZWFkIC9BIiBydWxlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJvdmUuPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvC
oCDCoCDCoFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgIMKgQW5keTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgT24g
V2VkLCBOb3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4LCAy
MDE3IGF0IDg6MzMgQU0sIFJvYmVydA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFdpbHRvbiAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFu
ayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyZndDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqAgwqBIaSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VyZSBhYm91dCB0
aGlzIGNoYW5nZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBJJ20gbm90DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBmYW1pbGlhciB3aXRo
IE5BQ00sIGJ1dCBpZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHlvdSB3YW50IHRvIGdpdmUgYSBwYXJ0aWN1bGFyDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2V0IG9mIHVzZXJzIHJlYWQvd3JpdGUgYWNjZXNzDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gYSBzdWJ0cmVlLCBidXQg
bm90IGFsbG93IHRoZW0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0byBoYXZlIGFueSBvdGhlciBhY2Nlc3MgdG8gdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiBpbiB0aGU8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKg
IMKgIMKgIMKgcnVubmluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGRhdGFzdG9yZSB0aGVuIHdpdGggdGhlIGV4aXN0aW5nDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgUkZDLCB0aGF0IGNvdWxkIGJlIGV4cHJlc3NlZA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggYSBzaW5nbGUg
cnVsZSAoZXhhbXBsZSBpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDY1MzZiaXMsIGFwcGVuZGl4IEIuNCk8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAg
wqBXaXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBu
ZXcgY2hhbmdlLCBJIHRoaW5rIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB5b3UgbWF5IG5lZWQgdG8gY29uZmlndXJlIG1hbnkNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3JlIHJ1bGVzIHRvIGFjaGlldmUgdGhl
IHNhbWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGluZy7C
oCBJIHRoaW5rIHRoYXQgeW91IHdvdWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbmVlZCB0byBnaXZlIHJlYWQgYWNjZXNzIHRvIHRoZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvcCBub2RlIGluIHRoZSBkZXNpcmVk
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoCDCoHBhdGgsDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYW5kIHRoZW4gc2VwYXJhdGUgZXhwbGljaXQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiZGVueSIgcnVsZXMgZm9yIGV2ZXJ5IHNp
YmxpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGlsZCBu
b2RlIHdhbGtpbmcgZnJvbSB0aGUgdG9wDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgb2YgdGhlIHRyZWUgZG93biB0byB0aGUgZGF0YQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUgdGhhdCByZWFkL3dyaXRlIGFjY2Vz
cyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdHVhbGx5
IGJlaW5nIGdpdmVuIHRvLsKgIFRoZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBleGFtcGxlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmVsb3cgbWF5IGV4cGxh
aW4gbXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlcnN0
YW5kaW5nIGJldHRlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBFLmcuDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRm9yIGEgdHJlZSBvZiBkYXRh
IG5vZGVzLCByb290ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhdCBBLCBpZiB3ZSB3YW50ZWQgdG8gZ2l2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHJlYWQvd3JpdGUgYWNjZXNzIG9ubHkgdG8gIkoiDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VidHJlZSwgYW5kIG5vIGFjY2Vz
cyBmb3IgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVz
dCBvZiB0aGUgdHJlZSB0aGVuOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIMKg
IMKgIMKgIEE8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICDCoC0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgfMKg
IMKgIMKgIHzCoCDCoCDCoHzCoCDCoCDCoHw8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBCwqAgwqAg
wqAgQ8KgIMKgIMKgRMKgIMKgIMKgRTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoHw8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgIMKgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgLS0tLS0tLS0tLS08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgIHzCoA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgfMKgIHzCoCB8PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDC
oCDCoCDCoCDCoCDCoCBGwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICDCoEfCoCBIwqAgSjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCB8PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgIMKgIMKgLi4uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAg
wqAgwqBJbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBv
bGQgbW9kZWwsIEkgdGhpbmsgdGhhdCB0aGUgQUNMDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcnVsZXMgd291bGQgYmUgMSBydWxlcyBsb25nDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGFzc3VtaW5nIGRlZmF1bHQgZGVu
eSBhbGwpOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAicmVhZC93cml0ZSAnQS9CL0onPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgSW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbmV3IG1vZGVsLCBJIHRoaW5rIHRoYXQgdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgZXF1aXZhbGVudCBBQ0wgcnVsZXMgd291bGQgbmVl
ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGJlIDggcnVs
ZXMgbG9uZyAoYXNzdW1pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBkZWZhdWx0IGRlbnkgYWxsKTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgIMKgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInJlYWQvd3JpdGUgJ0EvQi9K
Jzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAicmVhZCBBIjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiZGVueSBDIjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAiZGVueSBEIjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAiZGVueSBFIjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAg
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiZGVueSBGIjxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAiZGVueSBHIjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAgwqANCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiZGVueSBIIjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDvCoCDCoCDCoCDCoCDCoE5vdGUsIEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBhbSBhc3N1bWluZyB0aGF0IGEgInBhdGgiIHJ1bGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaGVzIGZvciB0aGUgZ2l2ZW4gcGF0
aCBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgZGVz
Y2VuZGFudCBub2Rlcy7CoCBUaGUgZHJhZnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBkb2Vzbid0IHNlZW0gdG8gYmUgcGFydGljdWxhcmx5DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xlYXIgb24gdGhpcyBwb2ludCAo
aXQgc3RhdGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhh
dCB0aGUgcnVsZSBhcHBsaWVzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoHdoZW4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcGF0aCBtYXRjaGVzLCBidXQg
dGhpcyB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNl
ZW0gdG8gYmUgY291bnRlciBpbnR1aXRpdmUpLA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGFuZCBwZXJoYXBzIGl0IGNvdWxkIGJlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY2xhcmlmaWVkLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvC
oCDCoCDCoCDCoCDCoElmIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjaGFuZ2UgaXMgYWxsb3dlZCwgdGhlbiB0aGUNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBleGFtcGxlIGluIGFwcGVuZGl4IEIuNCBsb29rcw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpa2UgaXQgd291bGQg
bmVlZCB0byBiZSBmaXhlZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBzaW5jZSB0aGUgImxpbWl0ZWQtYWNsIiBwcm9iYWJseQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkbid0IGdpdmUgYW55IGFjY2VzcyBhdCBh
bGwsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5sZXNzIGRl
ZmF1bHQgcmVhZDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqBhY2Nlc3MNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBoYWQgYmVlbiBnaXZlbi48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsm
Z3Q7wqAgwqAgwqAgwqAgwqBCdXQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgcG9zc2libHkgSSdtIG1pc3VuZGVyc3RhbmRpbmcNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBob3cgdGhpcyBhbGwgd29ya3MhwqAgSWYgc28s
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXBvbG9naWVzIGZv
ciB0aGUgbm9pc2UgOi0pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgVGhhbmtzLDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqAgwqAgwqAgwqBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDC
oCDCoCDCoE9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDIv
MTEvMjAxNyAxNDoxOCwgQmVub2l0IENsYWlzZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBEZWFyIGFsbCw8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgSGVyZSBpcyBhIG1ham9yIGNoYW5nZSBpbg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2
YmlzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Z2dlc3Rl
ZCBieSB0aGUgU2VjdXJpdHkgQUQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBFcmljIFJlc2NvbGEgcGFydCBvZiB0aGUgSUVTRw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHJldmlldywgd2hpY2ggSSB3b3VsZCBsaWtlIHRv
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsaWRhdGUgd2l0
aCB0aGUgV0cuIFNlZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgPGENCmhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2
NTM2YmlzLTA4LnR4dCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL3JmY2RpZjx3YnI+Zj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2PHdicj41
MzZiaXMtMDgudHh0PC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZsdDs8YQ0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9
ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0Ig0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9
InRydWUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmPHdicj5mP3VybDI9ZHJhZnQt
aWV0Zi1uZXRjb25mLXJmYzY8d2JyPjUzNmJpcy0wOC50eHQ8L2E+Jmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqAmbHQ7ZGZwY2Zpb29uZGdnaXBwZS5wbmcmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqAgwqBUaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBORVRDT05GIFdHIHdhcyBjYydlZCBmb3IgdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZW50aXJlIGRpc2N1c3Npb24uPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAg
wqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoFdo
YXQgZG8geW91IHRoaW5rPyBJIHdpbGwgZHJhdw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBjb25jbHVzaW9ucyBieSBGcmlkYXkgTm92DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTB0aC48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgTm90ZTogSWYgdGhlIFdHIGlzIGZpbmUsIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG5leHQgc3RlcCBpcyB0byBhcHByb3ZlIHRoaXMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N1bWVudC48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgUmVnYXJkcywgQmVub2l0PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5f
X19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDvCoCDCoCDCoCDCoCDCoDxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIj5OZXRjb25mQGlldGYub3JnPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsi
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90
LXNlbmQ9InRydWUiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKg
IMKgIMKgIMKgPGENCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0Y29uZiIgcmVsPSJub3JlZmVycmVyIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9uZXRjb25mPC9hPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDs8YQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5mby9uZXRjb25mPC9hPiZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5f
X19fX19fX19fX19fX19fXzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsgTmV0Y29uZiBtYWlsaW5nDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbGlzdDxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgPGENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3Jn
Ig0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJf
YmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzo8YQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0
Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJn
ZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyA8
YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsi
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90
LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbDx3YnI+aXN0aW5m
by9uZXRjb25mPC9hPjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBn
bWFpbC5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzo8
YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFp
bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5h
bmRhbmlAZ21haWwuY288d2JyPm08L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IE5ldGNv
bmYgbWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5l
dGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsgPGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
Y29uZiINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0i
bm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2w8d2JyPmlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
IDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgIDxicj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8YnI+
DQogICAgICAgICAgPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9m
aWVsZHNldD4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPHByZSB3cmFwPSIiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1h
aWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0i
bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29u
ZkBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldGNvbmY8L2E+DQo8L3ByZT4NCiAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICA8
YnI+DQogICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICA8YnI+DQogICAgPC9ibG9ja3F1b3Rl
Pg0KICAgIDxicj4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K
--------------5DE615BA2360F6FD6C40074B--


From nobody Wed Nov 22 10:09:53 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B18129ACC for ; Wed, 22 Nov 2017 10:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 STJaEnzFEVLa for ; Wed, 22 Nov 2017 10:09:46 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 4C384129A9C for ; Wed, 22 Nov 2017 10:09:45 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id o41so19240947lfi.2 for ; Wed, 22 Nov 2017 10:09:45 -0800 (PST)
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=HYZUFEZHr31aHuynMGoUPSdn7JdMEzcQP4p6klbW7Yo=; b=M125MilOySW/V7IqYJfHykpKfU96AnHppnK2nj1rEJIPA+7LHdisRIEGZIXbs/8+cN kEZYVx8quU3RAxbgc6Vn8zxSO9oD5mKWWJcqMJDz63oynDwgDZaI8/Wa537bgHSMpFlo 52g36wp/CCyHMCHJMz0AtU43JNINilTEqcCVbUDBlLBetmmvfKvURts6LwOvegengkVe E13TjDXQC8FZ0QMJnPgiScKtdZQNobTONnnTKMO2oOYl5i6K08KRow0xYJYyd1H8gfgq ykQQ93QuFDkgsrjSmvvjz/WO4uUvuzMne/kMo2Ac+9huddVipBfsrLIv6d+EZefgmO34 lDBw==
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=HYZUFEZHr31aHuynMGoUPSdn7JdMEzcQP4p6klbW7Yo=; b=sQMj5BIcqyZU4j9HgM5l16JT2b9hiuuodj8cOpJ+wFlIxYwWs5xo+/r3fTl7ihMAzg ZeHQcYtkgMbIwNFCH6G76bEltZbrkNDmTU9+BPxCOMOEWFXC8E2J0gUpPaIPW61RdSVV zirAGK7Ywpe95rOBGjBSYsmAfYf/KWkS07uIfkadn/HSTgSSbSdfhMfV1V4xyMoNetZN 9/mpyD4wx+wrYaqpuDJzxNxzHq8uPINqn7WM7PjrOybBdXZ4Ydg1q9CX8IKdaHavcOJr exlby5Udqr9If+Ap3puD0O6nM5a2VPelEnmx7JjihDTlTLGWaohgkUktFm9e/SflQnqX 4O6Q==
X-Gm-Message-State: AJaThX653ZwqQCy/x5MACXLxGh2wdHk84U7tV5y6Ota0N/tIEy1Q2hJp Wchu40AQkqLXJWxPSFt0YfN+8Wxa5FqXcgsvqyqlvA==
X-Google-Smtp-Source: AGs4zMaE5lTMTJbMq3DlmeMAvscPvwVvI2nOsQgPBstPhqsKbUSQfCbtAkOMySDdybp3Gucptv/mGE0VC4hX0Q1qvt0=
X-Received: by 10.46.93.2 with SMTP id r2mr7525233ljb.182.1511374183284; Wed, 22 Nov 2017 10:09:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 22 Nov 2017 10:09:41 -0800 (PST)
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>    
From: Andy Bierman 
Date: Wed, 22 Nov 2017 10:09:41 -0800
Message-ID: 
To: Benoit Claise 
Cc: Robert Wilton , "sec-ads@ietf.org" ,  NETCONF 
Content-Type: multipart/alternative; boundary="001a114b8c245167b2055e9639f8"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 18:09:51 -0000

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

On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise  wrote:

> Hi Rob,
>
> At that points in time, if it clarifies the spec. and the authors agree
> with this, let's do the right thing.
>
>
I will add the new text if that is what the WG wants.
There have not been any comments on this issue.


Andy


> Regards, Benoit.
>
> Hi Benoit,
>
> There is also one further, unrelated change that I am proposing is made
> the draft before it is published, to help better clarify the expected
> behavior.  It isn't the end of the world if this doesn't go in, but I think
> that it prevents sometime taking a different, but IMO reasonable,
> interpretation of how "when" statements are considered, and then having a
> future argument about what behavior it specified in the standard.
>
> If we clarify it now, then it closes that door :-)
>
> I've proposed text to Andy and Martin on Monday, but I've not heard back
> yet.
>
> Netconf email with proposed text attached.  The text doesn't necessarily
> have to match this, but personally I think that it is useful if the draft
> says something on this.
> Thanks,
> Rob
>
>
> On 22/11/2017 13:25, Benoit Claise wrote:
>
> On 11/10/2017 7:23 PM, Andy Bierman wrote:
>
> Hi,
>
> Here are some proposed edits to make the data rule consistent with the
> examples.
> Note that this issue is not related to the edit in the original 1-week
> change.
>
> That's right, but we found a source of misinterpretation in the draft and
> you have rightly corrected it in the github v9.
>
> Regards, Benoit
>
>
>
> sec. 3.3.5:
>
> OLD:
>
>
>       data node rule:  controls access for a specific data node, identified
>       by its path location within the conceptual XML document for the
>       data node.
>
>
> NEW:
>
>       data node rule:  controls access for a specific data node and its
> descendants,
>       identified by its path location within the conceptual XML document
> for the
>       data node.
>
>
> sec 3.4.5, step 6, bullet 2:
>
>
> OLD:
>
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node.
>
>       NEW:
>
>         *  The rule does not have a "rule-type" defined or the "rule-
>            type" is "data-node" and the "path" matches the requested
>            data node, action node, or notification node. A path is
>            considered to match if the current data node is the data node
>            specified by the path, or is a descendant data node of this data node.
>
> appendix B.4: (2 bugs in explanation)
>
> OLD:
>
>       deny-nacm:  This rule denies the "guest" group any access to the
>        subtree.  Note that the default namespace is only
>       applicable because this subtree is defined in the same namespace
>       as the  element.
>
>  NEW:
>
>       deny-nacm:  This rule denies the "guest" group any access to the
>        subtree.
>
> Andy
>
>
> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton  wrote:
>
>>
>>
>> On 10/11/2017 16:33, Andy Bierman wrote:
>>
>>
>>
>> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton  wrote:
>>
>>>
>>>
>>> On 10/11/2017 15:49, Andy Bierman wrote:
>>>
>>>
>>>
>>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland  wrote:
>>>
>>>> On 2017-11-10 11:42, Robert Wilton wrote:
>>>> >
>>>> >
>>>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Mahesh Jethanandani
>>>> >> mjethanandani@gmail.com 
>>>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman >>> > wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> The term "data node" is used in the document to refer to the
>>>> top-level node
>>>> >>> of the specified object, not the entire subtree (if any).
>>>> >>>
>>>> >>> The data-rule /foo does not match /foo/child1 in the text below.
>>>> >>> The child nodes are omitted because of step 11.
>>>> >>> The admin has to explicitly permit individual child nodes (or
>>>> modules).
>>>> >>> This seems correct if the read-default is "deny".
>>>> >>>
>>>> >>> Should any text be added or changed to make this more clear?
>>>> >>
>>>> >> I would agree with Robert that it was not entirely clear that rule
>>>> applied on the parent data-node does not apply to the child nodes. So yes,
>>>> it would help to clarify it.
>>>> > We should be doing more than clarifying it.  We need to fix it so
>>>> that it works in a sensible way.  I.e. to make the normative text
>>>> consistent with the behaviour currently described in the examples in
>>>> > the appendix B.4.
>>>> >
>>>> > If we follow Andy's interpretation that a data rule doesn't match
>>>> child nodes then those examples are completely wrong.  E.g. the 4th rule is
>>>> described as "This rule gives the 'admin' group read-write
>>>> > access to all acme  entries."  But If the path only
>>>> strictly matches "/acme:interfaces/acme:interface" then the admin
>>>> group rule achieves nothing useful at all.  The admin is not even
>>>> > allowed to create an interface because they would not even have
>>>> permission to write to the list key 'name' node required to create a list
>>>> entry!  Instead, a separate rule would be required for every
>>>> > single possible schema node under "/acme:interfaces/acme:interface"!
>>>> I think that this makes "permit" data-node rules completely unusable.
>>>>
>>>> I strongly agree with this, and I would say that it isn't only the case
>>>> for "permit" rules - e.g. denying some access to a subtree of the data
>>>> model that would otherwise be permitted due to defaults is at least as
>>>> common, and the rules would be just as unusable for that.
>>>>
>>>> Besides the examples, I think that the very use of the term "match",
>>>> though unfortunately not defined, strongly suggests that it is something
>>>> other than use of e.g. the term "identify" would imply. Additionally,
>>>> this text in the description of the 'path' leaf is consistent with the
>>>> match being a prefix match:
>>>>
>>>>        The special value '/' refers to all possible
>>>>        datastore contents.";
>>>>
>>>> FWIW, our NACM implementation, available to (and used by) customers
>>>> since 2012, follows the prefix match logic, and I have yet to hear of
>>>> any user expecting it to do otherwise.
>>>>
>>>> > To fix this properly, we need to make the data-node path rule a
>>>> prefix match.  In particular, we need text that specifies:
>>>> >
>>>> > (i) that a data-node path match succeeds if it matches the path
>>>> prefix from the root of the tree.  I.e. so the data-rule "/foo" matches
>>>> "/foo" and all of foo's descendant children nodes.
>>>>
>>>> Strongly agree.
>>>>
>>>>
>>>
>>> I do not see how the text can be interpreted this way.
>>>
>>>
>>> Because otherwise the path match part of the NACM solution is really
>>> broken, and the path based examples in the appendix are entirely misleading
>>> and wrong.  The only way those examples make sense is the paths match
>>> descendant children nodes as well.
>>>
>>>
>>
>> IMO the text does not support this interpretation.
>>
>> The examples in B.4, and the definition of "/" matching all nodes
>> supports this interpretation.
>>
>> Hence, my opinion is that it is the text in 3.4.5 that is incorrectly
>> specified; and that the examples, definition of "/" and standard practice
>> are right.
>>
>> Otherwise, how did IETF manage to publish an RFC where the path based
>> examples are so completely wrong?   Whoever wrote and reviewed those
>> examples clearly had a different interpretation of how these path based
>> ACLs worked.
>>
>>
>> There is nothing said about inheriting state from the parent data node.
>> I think no matter how the permissions are derived, one can
>> find examples that work better or worse because of it.
>>
>> No.  If the rules apply to descendant children, all normal examples work
>> well (including the ones in the appendix).
>>
>>
>> IMO the number of rules required to implement a use-case is not
>> very relevant or objective criteria.
>>
>> Yes it is, particularly when the difference is between needing a 1 line
>> rule, and a 100+ line rule.
>>
>>
>> Using the previous example of /home and /home/user1,
>> if the user1 is given read access to /home, then (according to you)
>> it also has read access to every user subtree under /home.
>>
>> Instead of 1 rule per user, 2 rules are needed
>>
>> No, just 1 rule per user:
>>    read-default=deny
>>    group=user1, path=/home/user1, action=permit
>>
>> This is because of my two proposed changes:
>>
>> (i) that a data-node path match succeeds if it matches the path prefix
>> from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and
>> all of foo's descendant children nodes.
>> <- This means that you only need 1 entry instead of 100 entries.
>>
>> (ii) if a data-node rule has action "permit" then it implicitly allows
>> read access for all ancestor parent nodes up to the root.  (I.e. to
>> mitigate the original change proposed on this thread.)
>> <- This means that you don't need a separate read rule for "/home".  Read
>> access to that node it is implicitly given via "group=user1,
>> path=/home/user1, action=permit", hence meaning that the rule works the
>> same way as it does on an rfc6536 compliant implementation.
>>
>>
>>    read-default=deny
>>    group=*, path=/home, action=permit
>>    group=user1, path=/home/user1, action=permit
>>
>> The above rules would allow access for every user to every other user.
>> The 2nd rule has no effect, which is counter-intuitive.
>> Every user dir would need 2 rules
>>
>>    read-default=deny
>>    group=*, path=/home, action=permit
>>    group=user1, path=/home/user1, action=permit
>>    group=*, path=/home/user1, action=deny
>>
>> There is nothing that says this is how it works.
>>> If it did, once could never have privileged sub-fiolders
>>>
>>>      /var/log -> permit
>>>      /var/log/apache2  -> deny
>>>
>>>
>>> Yes, you can, you just list the longest path first in the list of rules:
>>>
>>>  (1)  /var/log/apache2  -> deny
>>>   (2) /var/log -> permit
>>>
>>> Any requests that attempt to access anything under /var/log/apache2
>>> would match rule (1) and be denied.
>>> Any requests that attempt to access anything under /var/log, but not
>>> under /var/log/apache2, would fail to match rule (1), but would match rule
>>> (2) instead and be permitted.
>>>
>>>
>>>
>> I do not see any text in the draft or RFC 7950 that
>> suggests that /var/log and /var/log/apache2 represent the same data node.
>>
>> They are different data nodes, but I don't see how that is relevant.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>>
>>>
>>>
>>>> > (ii) if a data-node rule has action "permit" then it implicitly
>>>> allows read access for all ancestor parent nodes up to the root.  (I.e. to
>>>> mitigate the original change proposed on this thread.)
>>>>
>>>> This seems reasonable to me, although I haven't at this point evaluated
>>>> the suggestion in detail. In any case I think the main point both
>>>> regarding this and the prefix match is that this update to 6536 can't
>>>> make radical changes to the semantics compared to a "reasonable
>>>> interpretation" (hard to define, I know) of the under-specified
>>>> original.
>>>>
>>>
>>> The text does not say this at all so I do not approve of this change
>>>
>>>
>>> In the RFC version of the NACM this wasn't required because operation
>>> 'none' didn't require read access.  Now read access is required even for
>>> operation 'none', then this change makes sense to make the NACM changes
>>> backwards compatible, whilst still closing the security hole.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>>>
>>>>
>>>> --Per
>>>>
>>>>
>>>
>>> Andy
>>>
>>>
>>>> > Thanks,
>>>> > Rob
>>>> >
>>>> >
>>>> >>
>>>> >> Thanks
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> Andy
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton >>> > wrote:
>>>> >>>
>>>> >>>     Hi Andy,
>>>> >>>
>>>> >>>     It isn't clear to me whether matching a path in NACM either:
>>>> >>>       (i) Only applies to the specific node, and not any children,
>>>> or
>>>> >>>       (ii) Applies to the specific node and all descendant children
>>>> nodes as well.
>>>> >>>
>>>> >>>     As an example, using the tree below.  if I have a rule that
>>>> matches path "A/B" then does that apply to only the specific node "A/B", or
>>>> does it also apply to all descendant children of "A/B" as
>>>> >>>     well?
>>>> >>>
>>>> >>>     In rfc6536bis-08, section "3.4.5.  Data Node Access
>>>> Validation", step 6 states:
>>>> >>>
>>>> >>>             *  The rule does not have a "rule-type" defined or the
>>>> "rule-
>>>> >>>                type" is "data-node" and the *"path" matches the
>>>> requested data node*, action node, or notification node.
>>>> >>>
>>>> >>>
>>>> >>>     My reading of this is that it implies that the interpretation
>>>> of the path rule is (i), but this is not how I would normally expect an ACL
>>>> rule to apply in a tree like object (e.g a directory
>>>> >>>     file system).
>>>> >>>
>>>> >>>     However, the examples in Appendix B.4. imply that the path rule
>>>> is to be interpreted like (ii), or otherwise the example rules seem to be
>>>> mostly pointless.
>>>> >>>
>>>> >>>     E.g. taking this example from appendix B.4:
>>>> >>>
>>>> >>>            
>>>> >>>              permit-dummy-interface
>>>> >>>              >>> http://example.com/ns/itf>>
>>>> >>>                /acme:interfaces/acme:interface[acme:name='dummy']
>>>> >>>              
>>>> >>>              read update
>>>> >>>              permit
>>>> >>>              
>>>> >>>                Allow the limited and guest groups read
>>>> >>>                and update access to the dummy interface.
>>>> >>>              
>>>> >>>            
>>>> >>>
>>>> >>>
>>>> >>>     If the rule is (i)  then the access rule allows the client to
>>>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>> but not any child leafs/containers of that interface,
>>>> >>>     this doesn't seem useful.
>>>> >>>
>>>> >>>     Further comments inline below ...
>>>> >>>
>>>> >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>> >>>>     Hi,
>>>> >>>>
>>>> >>>>     This change has no impact on the server if /nacm/read-default
>>>> is "permit".
>>>> >>>>     In that case, the extra read rules for /A and /A/B are not
>>>> needed.
>>>> >>>     I agree.
>>>> >>>
>>>> >>>>     An operator worried about read access should set read-default
>>>> to "deny".
>>>> >>>     I agree.  This is the scenario that I'm considering.
>>>> >>>
>>>> >>>>     In that case, explicit rules to read /A and /A/B would be
>>>> needed
>>>> >>>>     in the new NACM.
>>>> >>>     Yes, if the interpretation of the rule is (i) above.
>>>> >>>     Otherwise if the interpretation is (ii) then you only need
>>>> "read /A" since that implies "read A/B" as well (as long as the rules are
>>>> listed in the correct order).
>>>> >>>
>>>> >>>
>>>> >>>>       The deny rules would not be needed.
>>>> >>>     Only if the interpretation of the rule is (i) above.  In which
>>>> case the  "read/write 'A/B/J' rule would not be sufficient.  It would be
>>>> necessary to define an Xpath expressions that contains
>>>> >>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>>> >>>
>>>> >>>     If the interpretation of the rule is (ii) then you would also
>>>> need all the explicit deny statements as well, otherwise they would be
>>>> allowed by the "read /A" rule above.
>>>> >>>
>>>> >>>     Thanks,
>>>> >>>     Rob
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>>     Andy
>>>> >>>>
>>>> >>>>
>>>> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <
>>>> rwilton@cisco.com > wrote:
>>>> >>>>
>>>> >>>>         Hi,
>>>> >>>>
>>>> >>>>         I'm not sure about this change.
>>>> >>>>
>>>> >>>>         I'm not that familiar with NACM, but if you want to give a
>>>> particular set of users read/write access to a subtree, but not allow them
>>>> to have any other access to the configuration in the
>>>> >>>>         running datastore then with the existing RFC, that could
>>>> be expressed with a single rule (example in 6536bis, appendix B.4)
>>>> >>>>
>>>> >>>>         With this new change, I think that you may need to
>>>> configure many more rules to achieve the same thing.  I think that you
>>>> would need to give read access to the top node in the desired
>>>> >>>>         path, and then separate explicit "deny" rules for every
>>>> sibling child node walking from the top of the tree down to the data node
>>>> that read/write access is actually being given to.  The
>>>> >>>>         example below may explain my understanding better:
>>>> >>>>
>>>> >>>>         E.g. For a tree of data nodes, rooted at A, if we wanted
>>>> to give read/write access only to "J" subtree, and no access for the rest
>>>> of the tree then:
>>>> >>>>
>>>> >>>>                          A
>>>> >>>>                          |
>>>> >>>>                 --------------------
>>>> >>>>                 |      |     |     |
>>>> >>>>                 B      C     D     E
>>>> >>>>                 |
>>>> >>>>            -----------
>>>> >>>>            |   |  |  |
>>>> >>>>            F   G  H  J
>>>> >>>>                      |
>>>> >>>>                     ...
>>>> >>>>
>>>> >>>>
>>>> >>>>         In the old model, I think that the ACL rules would be 1
>>>> rules long (assuming default deny all):
>>>> >>>>            "read/write 'A/B/J'
>>>> >>>>
>>>> >>>>         In the new model, I think that the equivalent ACL rules
>>>> would need to be 8 rules long (assuming default deny all):
>>>> >>>>            "read/write 'A/B/J'
>>>> >>>>            "read A"
>>>> >>>>            "deny C"
>>>> >>>>            "deny D"
>>>> >>>>            "deny E"
>>>> >>>>            "deny F"
>>>> >>>>            "deny G"
>>>> >>>>            "deny H"
>>>> >>>>
>>>> >>>>         Note, I am assuming that a "path" rule matches for the
>>>> given path and all descendant nodes.  The draft doesn't seem to be
>>>> particularly clear on this point (it states that the rule applies
>>>> >>>>         when the path matches, but this would seem to be counter
>>>> intuitive), and perhaps it could be clarified.
>>>> >>>>
>>>> >>>>         If this change is allowed, then the example in appendix
>>>> B.4 looks like it would need to be fixed, since the "limited-acl" probably
>>>> wouldn't give any access at all, unless default read
>>>> >>>>         access had been given.
>>>> >>>>
>>>> >>>>         But, possibly I'm misunderstanding how this all works!  If
>>>> so, apologies for the noise :-)
>>>> >>>>
>>>> >>>>         Thanks,
>>>> >>>>         Rob
>>>> >>>>
>>>> >>>>
>>>> >>>>         On 02/11/2017 14:18, Benoit Claise wrote:
>>>> >>>>>         Dear all,
>>>> >>>>>
>>>> >>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis,
>>>> suggested by the Security AD Eric Rescola part of the IESG review, which I
>>>> would like to validate with the WG. See
>>>> >>>>>         https://tools.ietf.org/rfcdif
>>>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt <
>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6
>>>> 536bis-08.txt>
>>>> >>>>>
>>>> >>>>>         
>>>> >>>>>         The NETCONF WG was cc'ed for the entire discussion.
>>>> >>>>>         What do you think? I will draw the conclusions by Friday
>>>> Nov 10th.
>>>> >>>>>
>>>> >>>>>         Note: If the WG is fine, the next step is to approve this
>>>> document.
>>>> >>>>>
>>>> >>>>>         Regards, Benoit
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>         _______________________________________________
>>>> >>>>>         Netconf mailing list
>>>> >>>>>         Netconf@ietf.org 
>>>> >>>>>         https://www.ietf.org/mailman/listinfo/netconf <
>>>> https://www.ietf.org/mailman/listinfo/netconf>
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Netconf mailing list
>>>> >>> Netconf@ietf.org 
>>>> >>> https://www.ietf.org/mailman/listinfo/netconf
>>>> >>
>>>> >> Mahesh Jethanandani
>>>> >> mjethanandani@gmail.com 
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Netconf mailing list
>>>> > Netconf@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/netconf
>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
>

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




On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise <bclaise@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Rob,

      

      At that points in time, if it clarifies the spec. and the authors
      agree with this, let's do the right thing.

      

I will add the new t=
ext if that is what the WG wants.
There have not been any comment=
s on this issue.


Andy
=C2=
=A0

      Regards, Benoit.

    

    

     =20
      
Hi Benoit,

      
There is also one further, unrelated change that I am proposing
        is made the draft before it is published, to help better clarify
        the expected behavior.=C2=A0 It isn't the end of the world if t=
his
        doesn't go in, but I think that it prevents sometime taking a
        different, but IMO reasonable, interpretation of how "when&quo=
t;
        statements are considered, and then having a future argument
        about what behavior it specified in the standard.

      

      
If we clarify it now, then it closes that door :-)

      
I've proposed text to Andy and Martin on Monday, but I've =
not
        heard back yet.

      
Netconf email with proposed text attached.=C2=A0 The text doesn=
9;t
        necessarily have to match this, but personally I think that it
        is useful if the draft says something on this.

      

      Thanks,

      Rob

      

      

      
On 22/11/2017 13=
:25, Benoit Claise
        wrote:

      

      

        
On 11/10/2017 =
7:23 PM, Andy Bierman
          wrote:

        

        

          
Hi,
            


            

            
Here are some proposed edits to make the data rule
              consistent with the examples.

            
Note that this issue is not related to the edit in the
              original 1-week change.

          

        

        That's right, but we found a source of misinterpretation in the
        draft and you have rightly corrected it in the github v9.

        

        Regards, Benoit

        

          

            


            

            


            

            
sec. 3.3.5:

            


            

            
OLD:

            


            

            

              


              

              
=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls acce=
ss for a specific
                data node, identified

              
=C2=A0 =C2=A0 =C2=A0 by its path location within the con=
ceptual XML
                document for the

              
=C2=A0 =C2=A0 =C2=A0 data node.

            

            


            

            


            

            
NEW:

            


            

            

              
=C2=A0 =C2=A0 =C2=A0 data node rule: =C2=A0controls acce=
ss for a specific
                data node and its descendants,

              
=C2=A0 =C2=A0 =C2=A0 identified by its path location wit=
hin the
                conceptual XML document for the

              
=C2=A0 =C2=A0 =C2=A0 data node.

            

            


            

            


            

            
sec 3.4.5, step 6, bullet 2:

            


            

            


            

            
OLD:

            

              


              

              
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not ha=
ve a "rule-type"
                defined or the "rule-

              
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is &=
quot;data-node" and the "path"
                matches the requested

              
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, acti=
on node, or notification
                node.

            

            

              
     =
 

              
NEW:<=
/pre>
              
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0The rule does not ha=
ve a "rule-type" defined or the "rule-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type" is "data-n=
ode" and the "path" matches the requested
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data node, action node,=
 or notification node. A path is
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0considered to match if the current data node is=
 the data node
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0specified by the path, or is a descendant data node of this data =
node.

              
appen=
dix B.4: (2 bugs in explanation)

              
OLD:<=
/pre>
              
      deny-nacm:  This rule denies the "guest" =
group any access to the
      <nacm> subtree.  Note that the default namespace is only
      applicable because this subtree is defined in the same namespace
      as the <data-rule> element.


              
 

              
NEW:
      deny-nacm:  This rule denies the "gu=
est" group any access to the
      <nacm> subtree.







Andy





            

          

          


            
On Fri, Nov 10, 2017 at 9:24 AM,
              Robert Wilton <rwilton@cisco.com>
              wrote:

              

                

                  


                  

                  

                  
On
                    10/11/2017 16:33, Andy Bierman wrote:

                  

                  

                    


                      


                        
On Fri, Nov 10, 2017 at
                          8:16 AM, Robert Wilton <rwilton@cisco.com>=
;
                          wrote:

                          

                            

                              


                              

                              

                              
On
                                10/11/2017 15:49, Andy Bierman wrote:

                              

                              

                                


                                  


                                    
On Fri, Nov
                                      10, 2017 at 5:07 AM, Per Hedeland
                                      <per@tail-f.com>
                                      wrote:

                                      
On
                                        2017-11-10 11:42, Robert Wilton
                                        wrote:

                                        >

                                        >

                                        > On 10/11/2017 10:02, Mahesh
                                        Jethanandani wrote:

                                        >>

                                        >>

                                        >>

                                        >>

                                        >> Mahesh Jethanandani

                                        >> mjethanandani@gmail.com
                                        <mailto:mjethanandani@gmail.com>
                                        >> On Nov 10, 2017, at
                                        10:07 AM, Andy Bierman <andy@yumaworks.com
                                        <mailto:andy@yumaworks.com>>
                                        wrote:

                                        >>

                                        >>> Hi,

                                        >>>

                                        >>> The term "data
                                        node" is used in the document =
to
                                        refer to the top-level node

                                        >>> of the specified
                                        object, not the entire subtree
                                        (if any).

                                        >>>

                                        >>> The data-rule /foo
                                        does not match /foo/child1 in
                                        the text below.

                                        >>> The child nodes are
                                        omitted because of step 11.

                                        >>> The admin has to
                                        explicitly permit individual
                                        child nodes (or modules).

                                        >>> This seems correct
                                        if the read-default is "deny&q=
uot;.

                                        >>>

                                        >>> Should any text be
                                        added or changed to make this
                                        more clear?

                                        >>

                                        >> I would agree with
                                        Robert that it was not entirely
                                        clear that rule applied on the
                                        parent data-node does not apply
                                        to the child nodes. So yes, it
                                        would help to clarify it.

                                        > We should be doing more
                                        than clarifying it.=C2=A0 We need t=
o
                                        fix it so that it works in a
                                        sensible way.=C2=A0 I.e. to make th=
e
                                        normative text consistent with
                                        the behaviour currently
                                        described in the examples in

                                        > the appendix B.4.

                                        >

                                        > If we follow Andy's
                                        interpretation that a data rule
                                        doesn't match child nodes then
                                        those examples are completely
                                        wrong.=C2=A0 E.g. the 4th rule is
                                        described as "This rule gives
                                        the 'admin' group read-writ=
e

                                        > access to all acme
                                        <interface> entries."=C2=
=A0 But
                                        If the path only strictly
                                        matches
                                        "/acme:interfaces/acme:interfa=
ce"
                                        then the admin group rule
                                        achieves nothing useful at all.=C2=
=A0
                                        The admin is not even

                                        > allowed to create an
                                        interface because they would not
                                        even have permission to write to
                                        the list key 'name' node
                                        required to create a list
                                        entry!=C2=A0 Instead, a separate ru=
le
                                        would be required for every

                                        > single possible schema node
                                        under
                                        "/acme:interfaces/acme:interfa=
ce"!=C2=A0
                                        I think that this makes "permi=
t"
                                        data-node rules completely
                                        unusable.

                                        

                                        I strongly agree with this, and
                                        I would say that it isn't only
                                        the case

                                        for "permit" rules - e.g.
                                        denying some access to a subtree
                                        of the data

                                        model that would otherwise be
                                        permitted due to defaults is at
                                        least as

                                        common, and the rules would be
                                        just as unusable for that.

                                        

                                        Besides the examples, I think
                                        that the very use of the term
                                        "match",

                                        though unfortunately not
                                        defined, strongly suggests that
                                        it is something

                                        other than use of e.g. the term
                                        "identify" would imply.
                                        Additionally,

                                        this text in the description of
                                        the 'path' leaf is consiste=
nt
                                        with the

                                        match being a prefix match:

                                        

                                        =C2=A0 =C2=A0 =C2=A0 =C2=A0The spec=
ial value '/'
                                        refers to all possible

                                        =C2=A0 =C2=A0 =C2=A0 =C2=A0datastor=
e contents.";

                                        

                                        FWIW, our NACM implementation,
                                        available to (and used by)
                                        customers

                                        since 2012, follows the prefix
                                        match logic, and I have yet to
                                        hear of

                                        any user expecting it to do
                                        otherwise.

                                        

                                        > To fix this properly, we
                                        need to make the data-node path
                                        rule a prefix match.=C2=A0 In
                                        particular, we need text that
                                        specifies:

                                        >

                                        > (i) that a data-node path
                                        match succeeds if it matches the
                                        path prefix from the root of the
                                        tree.=C2=A0 I.e. so the data-rule
                                        "/foo" matches "/foo=
" and all of
                                        foo's descendant children nodes=
.

                                        

                                        Strongly agree.

                                        

                                      

                                      


                                      

                                      


                                      

                                      
I do not see how the text can
                                        be interpreted this way.

                                    

                                  

                                

                              

                              

                              Because otherwise the path match part of
                              the NACM solution is really broken, and
                              the path based examples in the appendix
                              are entirely misleading and wrong.=C2=A0 The
                              only way those examples make sense is the
                              paths match descendant children nodes as
                              well.

                              

                            

                          

                          


                          

                          


                          

                          
IMO the text does not support this
                            interpretation.

                        

                      

                    

                  

                  The examples in B.4, and the definition of "/"
                  matching all nodes supports this interpretation.

                  

                  Hence, my opinion is that it is the text in 3.4.5 that
                  is incorrectly specified; and that the examples,
                  definition of "/" and standard practice are rig=
ht.

                  

                  Otherwise, how did IETF manage to publish an RFC where
                  the path based examples are so completely wrong?=C2=A0=C2=
=A0
                  Whoever wrote and reviewed those examples clearly had
                  a different interpretation of how these path based
                  ACLs worked. 

                  

                  

                  

                    

                      

                        

                          
There is nothing said about inheriting
                            state from the parent data node.

                          
I think no matter how the permissions are
                            derived, one can

                          
find examples that work better or worse
                            because of it.

                        

                      

                    

                  

                  No.=C2=A0 If the rules apply to descendant children, all
                  normal examples work well (including the ones in the
                  appendix).

                  

                  

                  

                    

                      

                        

                          
IMO the number of rules required to
                            implement a use-case is not

                          
very relevant or objective criteria.

                        

                      

                    

                  

                  Yes it is, particularly when the difference is between
                  needing a 1 line rule, and a 100+ line rule.

                  

                  

                    

                      

                        

                          


                          

                          
Using the previous example of /home and
                            /home/user1,

                          
if the user1 is given read access to
                            /home, then (according to you)

                          
it also has read access to every user
                            subtree under /home.

                        

                      

                    

                  

                  

                    

                      

                        

                          
Instead of 1 rule per user, 2 rules are
                            needed

                        

                      

                    

                  

                  No, just 1 rule per user:

                  =C2=A0=C2=A0 read-default=3Ddeny

                  =C2=A0=C2=A0 group=3Duser1, path=3D/home/user1, action=3D=
permit

                  

                  This is because of my two proposed changes:

                  

                  (i) that a data-node path match succeeds if it matches
                  the path prefix from the root of the tree.=C2=A0 I.e. so
                  the data-rule "/foo" matches "/foo" a=
nd all of foo's
                  descendant children nodes.

                  <- This means that you only need 1 entry instead of
                  100 entries.

                  

                  (ii) if a data-node rule has action "permit" th=
en it
                  implicitly allows read access for all ancestor parent
                  nodes up to the root.=C2=A0 (I.e. to mitigate the origina=
l
                  change proposed on this thread.)

                  <- This means that you don't need a separate read
                  rule for "/home".=C2=A0 Read access to that nod=
e it is
                  implicitly given via "group=3Duser1, path=3D/home/us=
er1,
                  action=3Dpermit", hence meaning that the rule works =
the
                  same way as it does on an rfc6536 compliant
                  implementation.

                  

                  

                    

                      

                        

                          


                          

                          
=C2=A0 =C2=A0read-default=3Ddeny

                          
=C2=A0 =C2=A0group=3D*, path=3D/home, action=
=3Dpermit

                          
=C2=A0 =C2=A0group=3Duser1, path=3D/home/use=
r1,
                            action=3Dpermit

                          


                          

                          
The above rules would allow access for
                            every user to every other user.

                          
The 2nd rule has no effect, which is
                            counter-intuitive.

                          
Every user dir would need 2 rules

                          


                          

                          

                            
=C2=A0 =C2=A0read-default=3Ddeny

                            
=C2=A0 =C2=A0group=3D*, path=3D/home, acti=
on=3Dpermit

                            
=C2=A0 =C2=A0group=3Duser1, path=3D/home/u=
ser1,
                              action=3Dpermit

                          

                          
=C2=A0 =C2=A0group=3D*, path=3D/home/user1, =
action=3Ddeny

                          

                          


                          

                          

                            

                              

                                

                                  

                                    

                                      
There is nothing that says
                                        this is how it works.

                                      
If it did, once could never
                                        have privileged sub-fiolders

                                      


                                      

                                      
=C2=A0 =C2=A0 =C2=A0/var/log -&g=
t; permit

                                      
=C2=A0 =C2=A0 =C2=A0/var/log/apa=
che2 =C2=A0->
                                        deny

                                    

                                  

                                

                              

                              

                              Yes, you can, you just list the longest
                              path first in the list of rules:

                              

                              =C2=A0(1)=C2=A0 /var/log/apache2 =C2=A0-> =
deny

                              =C2=A0 (2) /var/log -> permit

                              

                              Any requests that attempt to access
                              anything under /var/log/apache2 would
                              match rule (1) and be denied.

                              Any requests that attempt to access
                              anything under /var/log, but not under
                              /var/log/apache2, would fail to match rule
                              (1), but would match rule (2) instead and
                              be permitted.

                              

                              

                            

                          

                          


                          

                          
I do not see any text in the draft or RFC
                            7950 that

                          
suggests that /var/log and
                            /var/log/apache2 represent the same data
                            node.

                        

                      

                    

                  

                  They are different data nodes, but I don't see how
                  that is relevant.

                  

                  Thanks,

                  Rob

                  

                  

                  

                    

                      

                        

                          


                          

                          


                          

                          
Andy

                          


                          

                          
=C2=A0

                          

                            

                              

                                

                                  

                                    

                                      


                                      

                                      
=C2=A0

                                      

                                      

                                        > (ii) if a data-node rule
                                        has action "permit" then =
it
                                        implicitly allows read access
                                        for all ancestor parent nodes up
                                        to the root.=C2=A0 (I.e. to mitigat=
e
                                        the original change proposed on
                                        this thread.)

                                        

                                        This seems reasonable to me,
                                        although I haven't at this poin=
t
                                        evaluated

                                        the suggestion in detail. In any
                                        case I think the main point both
                                        regarding this and the prefix
                                        match is that this update to
                                        6536 can't

                                        make radical changes to the
                                        semantics compared to a
                                        "reasonable

                                        interpretation" (hard to defin=
e,
                                        I know) of the under-specified

                                        original.

                                      

                                      


                                      

                                      
The text does not say this at
                                        all so I do not approve of this
                                        change

                                    

                                  

                                

                              

                              

                              In the RFC version of the NACM this wasn'=
t
                              required because operation 'none' did=
n't
                              require read access.=C2=A0 Now read access is
                              required even for operation 'none', t=
hen
                              this change makes sense to make the NACM
                              changes backwards compatible, whilst still
                              closing the security hole.

                              

                              Thanks,

                              Rob

                              

                              

                                

                                  

                                    

                                      


                                      

                                      
=C2=A0

                                      

                                        

                                        --Per

                                        

                                      

                                      


                                      

                                      


                                      

                                      
Andy

                                      
=C2=A0

                                      

                                        > Thanks,

                                        > Rob

                                        >

                                        >

                                        >>

                                        >> Thanks

                                        >>

                                        >>>

                                        >>>

                                        >>> Andy

                                        >>>

                                        >>>

                                        >>> On Thu, Nov 9, 2017
                                        at 2:44 AM, Robert Wilton <rwilton@cisco.com
                                        <mailto:rwilton@cisco.com>>
                                        wrote:

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0Hi =
Andy,

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0It =
isn't clear
                                        to me whether matching a path in
                                        NACM either:

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0(i) Only
                                        applies to the specific node,
                                        and not any children, or

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0(ii) Applies
                                        to the specific node and all
                                        descendant children nodes as
                                        well.

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0As =
an example,
                                        using the tree below.=C2=A0 if I ha=
ve
                                        a rule that matches path "A/B&=
quot;
                                        then does that apply to only the
                                        specific node "A/B", or d=
oes it
                                        also apply to all descendant
                                        children of "A/B" as

                                        >>>=C2=A0 =C2=A0 =C2=A0wel=
l?

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0In
                                        rfc6536bis-08, section "3.4.5.=
=C2=A0
                                        Data Node Access Validation",
                                        step 6 states:

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 The
                                        rule does not have a "rule-typ=
e"
                                        defined or the "rule-

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        type" is "data-node"=
 and the
                                        *"path" matches the reque=
sted
                                        data node*, action node, or
                                        notification node.

                                        >>>

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0My =
reading of
                                        this is that it implies that the
                                        interpretation of the path rule
                                        is (i), but this is not how I
                                        would normally expect an ACL
                                        rule to apply in a tree like
                                        object (e.g a directory

                                        >>>=C2=A0 =C2=A0 =C2=A0fil=
e system).

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0How=
ever, the
                                        examples in Appendix B.4. imply
                                        that the path rule is to be
                                        interpreted like (ii), or
                                        otherwise the example rules seem
                                        to be mostly pointless.

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0E.g=
. taking
                                        this example from appendix B.4:

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                        <rule>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        <name>permit-dummy-interface&=
lt;/name>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        <path xmlns:acme=3D"http://=
example.com/ns/itf"
                                        <http://example.com/ns/itf&g=
t;>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        /acme:interfaces/acme:interfac=
e[acme:name=3D'dummy']

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        </path>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        <access-operations>read
                                        update</access-operations>
                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        <action>permit</action>=


                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        <comment>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        Allow the limited and guest
                                        groups read

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and
                                        update access to the dummy
                                        interface.

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        </comment>

                                        >>>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                        </rule>

                                        >>>

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0If =
the rule is
                                        (i)=C2=A0 then the access rule allo=
ws
                                        the client to read the specific
                                        node
                                        "/acme:interfaces/acme:interfa=
ce[acme:name=3D'dummy']"
                                        but not any child
                                        leafs/containers of that
                                        interface,

                                        >>>=C2=A0 =C2=A0 =C2=A0thi=
s doesn't
                                        seem useful.

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0Fur=
ther
                                        comments inline below ...

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0On =
08/11/2017
                                        20:05, Andy Bierman wrote:

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0Hi,

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0This change
                                        has no impact on the server if
                                        /nacm/read-default is "permit&=
quot;.

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0In that
                                        case, the extra read rules for
                                        /A and /A/B are not needed.

                                        >>>=C2=A0 =C2=A0 =C2=A0I a=
gree.

                                        >>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0An operator
                                        worried about read access should
                                        set read-default to "deny"=
;.

                                        >>>=C2=A0 =C2=A0 =C2=A0I a=
gree.=C2=A0 This
                                        is the scenario that I'm
                                        considering.

                                        >>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0In that
                                        case, explicit rules to read /A
                                        and /A/B would be needed

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0in the new
                                        NACM.

                                        >>>=C2=A0 =C2=A0 =C2=A0Yes=
, if the
                                        interpretation of the rule is
                                        (i) above.

                                        >>>=C2=A0 =C2=A0 =C2=A0Oth=
erwise if
                                        the interpretation is (ii) then
                                        you only need "read /A" s=
ince
                                        that implies "read A/B" a=
s well
                                        (as long as the rules are listed
                                        in the correct order).

                                        >>>

                                        >>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0The deny
                                        rules would not be needed.

                                        >>>=C2=A0 =C2=A0 =C2=A0Onl=
y if the
                                        interpretation of the rule is
                                        (i) above.=C2=A0 In which case the=
=C2=A0
                                        "read/write 'A/B/J' ru=
le would
                                        not be sufficient.=C2=A0 It would b=
e
                                        necessary to define an Xpath
                                        expressions that contains

                                        >>>=C2=A0 =C2=A0 =C2=A0all=
 children
                                        nodes as well.=C2=A0 Perhaps
                                        'A/B/J//*'?

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0If =
the
                                        interpretation of the rule is
                                        (ii) then you would also need
                                        all the explicit deny statements
                                        as well, otherwise they would be
                                        allowed by the "read /A" =
rule
                                        above.

                                        >>>

                                        >>>=C2=A0 =C2=A0 =C2=A0Tha=
nks,

                                        >>>=C2=A0 =C2=A0 =C2=A0Rob=


                                        >>>

                                        >>>

                                        >>>>

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0Andy

                                        >>>>

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0On Wed, Nov
                                        8, 2017 at 8:33 AM, Robert
                                        Wilton <rwilton@cisco.com
                                        <mailto:rwilton@cisco.com>>
                                        wrote:

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Hi,

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0I'm not
                                        sure about this change.

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0I'm not
                                        that familiar with NACM, but if
                                        you want to give a particular
                                        set of users read/write access
                                        to a subtree, but not allow them
                                        to have any other access to the
                                        configuration in the

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0running
                                        datastore then with the existing
                                        RFC, that could be expressed
                                        with a single rule (example in
                                        6536bis, appendix B.4)

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0With
                                        this new change, I think that
                                        you may need to configure many
                                        more rules to achieve the same
                                        thing.=C2=A0 I think that you would
                                        need to give read access to the
                                        top node in the desired

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0path,
                                        and then separate explicit
                                        "deny" rules for every si=
bling
                                        child node walking from the top
                                        of the tree down to the data
                                        node that read/write access is
                                        actually being given to.=C2=A0 The<=
br>
                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0example
                                        below may explain my
                                        understanding better:

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0E.g.
                                        For a tree of data nodes, rooted
                                        at A, if we wanted to give
                                        read/write access only to "J&q=
uot;
                                        subtree, and no access for the
                                        rest of the tree then:

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
A

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
|

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0--------------------

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0|=C2=A0 =C2=A0 =C2=A0 |=C2=A0=
 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0B=C2=A0 =C2=A0 =C2=A0 C=C2=A0=
 =C2=A0 =C2=A0D=C2=A0 =C2=A0 =C2=A0E

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0|

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        -----------

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
                                        =C2=A0|=C2=A0 |=C2=A0 |

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 F=C2=A0
                                        =C2=A0G=C2=A0 H=C2=A0 J

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
                                        =C2=A0 =C2=A0 =C2=A0 |

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

                                        >>>>

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0In the
                                        old model, I think that the ACL
                                        rules would be 1 rules long
                                        (assuming default deny all):

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "read/write 'A/B/J'
                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0In the
                                        new model, I think that the
                                        equivalent ACL rules would need
                                        to be 8 rules long (assuming
                                        default deny all):

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "read/write 'A/B/J'
                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "read A"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny C"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny D"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny E"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny F"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny G"

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0
                                        "deny H"

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Note, I
                                        am assuming that a "path"=
 rule
                                        matches for the given path and
                                        all descendant nodes.=C2=A0 The dra=
ft
                                        doesn't seem to be particularly
                                        clear on this point (it states
                                        that the rule applies

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0when
                                        the path matches, but this would
                                        seem to be counter intuitive),
                                        and perhaps it could be
                                        clarified.

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0If this
                                        change is allowed, then the
                                        example in appendix B.4 looks
                                        like it would need to be fixed,
                                        since the "limited-acl" p=
robably
                                        wouldn't give any access at all=
,
                                        unless default read

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0access
                                        had been given.

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0But,
                                        possibly I'm misunderstanding
                                        how this all works!=C2=A0 If so,
                                        apologies for the noise :-)

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Thanks,

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Rob

                                        >>>>

                                        >>>>

                                        >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0On
                                        02/11/2017 14:18, Benoit Claise
                                        wrote:

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0Dear all,

                                        >>>>>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0Here is a major change in
                                        draft-ietf-netconf-rfc6536bis,
                                        suggested by the Security AD
                                        Eric Rescola part of the IESG
                                        review, which I would like to
                                        validate with the WG. See

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0https:=
//tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc6536bis-08.=
txt
                                        <https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-net=
conf-rfc6536bis-08.txt>

                                        >>>>>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0<dfpcfioondggippe.png><=
br>
                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0The
                                        NETCONF WG was cc'ed for the
                                        entire discussion.

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0What do you think? I will dra=
w
                                        the conclusions by Friday Nov
                                        10th.

                                        >>>>>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0Note: If the WG is fine, the
                                        next step is to approve this
                                        document.

                                        >>>>>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0Regards, Benoit

                                        >>>>>

                                        >>>>>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0_____________________________=
__________________

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                                        =C2=A0Netconf mailing list

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0N=
etconf@ietf.org
                                        <mailto:Netconf@ietf.org>

                                        >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l=
istinfo/netconf
                                        <https://www=
.ietf.org/mailman/listinfo/netconf>

                                        >>>>

                                        >>>>

                                        >>>

                                        >>>

                                        >>>
                                        ______________________________=
_________________

                                        >>> Netconf mailing
                                        list

                                        >>> Netconf@ietf.org
                                        <mailto:Netconf@ietf.org>

                                        >>> ht=
tps://www.ietf.org/mailman/listinfo/netconf

                                        >>

                                        >> Mahesh Jethanandani

                                        >> mjethanandani@gmail.com
                                        <mailto:mjethanandani@gmail.com>
                                        >

                                        >

                                        >

                                        >
                                        ______________________________=
_________________

                                        > Netconf mailing list

                                        > Netconf@ietf.org

                                        > https://ww=
w.ietf.org/mailman/listinfo/netconf

                                        >

                                        

                                      

                                    

                                    

                                  

                                

                              

                              

                            

                          

                        

                        

                      

                    

                  

                  

                

              

            

            

          

          

          

          

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


        

        

      

      

    

    

  






--001a114b8c245167b2055e9639f8--


From nobody Thu Nov 23 02:44:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1530B127B60; Thu, 23 Nov 2017 02:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 z7yIATbnGUNL; Thu, 23 Nov 2017 02:44:18 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2206C1289B0; Thu, 23 Nov 2017 02:44:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=171508; q=dns/txt; s=iport; t=1511433854; x=1512643454; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=xq+//w1twqEpCqWHxkrurIAwo1shHxXXCKO5lSqjh/Q=; b=anNnNrL4mpmRUhsQAGHSk+/f+C8T6syFkUOiFD6WL3EKvy5AlPo9by/8 72dM2/zSbqO8MhOme1wIF76wne7zhCdV6HV7EgRP2IGoJhF4qKI2HhllL F2RQw7Ga5AJ3EX952sjTuON/g85aFP9Tv0tUUzTY56ZNXElaBTd43fQle I=;
X-IronPort-AV: E=Sophos;i="5.44,441,1505779200"; d="scan'208,217";a="437660"
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; 23 Nov 2017 10:44:12 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vANAiBeC023234; Thu, 23 Nov 2017 10:44:12 GMT
To: Andy Bierman , NETCONF 
Cc: Benoit Claise , "sec-ads@ietf.org" 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>     
From: Robert Wilton 
Message-ID: 
Date: Thu, 23 Nov 2017 10:44:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2AF788B9FC757172BB684F14"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 10:44:28 -0000

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

Hi Andy,


On 22/11/2017 18:09, Andy Bierman wrote:
>
>
> On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise  > wrote:
>
>     Hi Rob,
>
>     At that points in time, if it clarifies the spec. and the authors
>     agree with this, let's do the right thing.
>
>
> I will add the new text if that is what the WG wants.
Having read this draft, I was undecided what the intended behavior 
actually should be.

The way that Yumapro and Tail-f have implemented this is reasonable, and 
is probably also the way that I would implemented it.

But I also think that it would be a reasonable implementation for a 
server to calculate the full change set (taking account of side effects 
from when and choice statements) to the datastore before checking the 
"write data node access control" against the resultant change set.

My interpretation is that the RFC text is ambiguous on what the correct 
behavior is, and one could make a reasonable argument that the current 
RFC actually specifies that the alternative behavior is correct, i.e. 
requiring delete access even if a node is implicitly changes as a side 
effect.  E.g. section 3.2.3 of RFC 6536 states:

    If the protocol operation would result in the deletion of a datastore
    node and the user does not have "delete" access permission for that
    node, the protocol operation is rejected with an "access-denied"
    error.


An  request that causes a when constraint to evaluate 
differently does result in a deletion of those data nodes from the 
datastore, and hence according to the text above, requires explicit 
"delete" access permission to accomplish that.

Clearly it would be an interop issue if different servers implemented 
the NACM path based filtering differently.

Hence why I think that it would be prudent for the draft to be more 
explicit on when and choice statement handling.

Thanks,
Rob


> There have not been any comments on this issue.
>
>
> Andy
>
>     Regards, Benoit.
>>
>>     Hi Benoit,
>>
>>     There is also one further, unrelated change that I am proposing
>>     is made the draft before it is published, to help better clarify
>>     the expected behavior.  It isn't the end of the world if this
>>     doesn't go in, but I think that it prevents sometime taking a
>>     different, but IMO reasonable, interpretation of how "when"
>>     statements are considered, and then having a future argument
>>     about what behavior it specified in the standard.
>>
>>     If we clarify it now, then it closes that door :-)
>>
>>     I've proposed text to Andy and Martin on Monday, but I've not
>>     heard back yet.
>>
>>     Netconf email with proposed text attached.  The text doesn't
>>     necessarily have to match this, but personally I think that it is
>>     useful if the draft says something on this.
>>
>>     Thanks,
>>     Rob
>>
>>
>>     On 22/11/2017 13:25, Benoit Claise wrote:
>>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>>>>     Hi,
>>>>
>>>>     Here are some proposed edits to make the data rule consistent
>>>>     with the examples.
>>>>     Note that this issue is not related to the edit in the original
>>>>     1-week change.
>>>     That's right, but we found a source of misinterpretation in the
>>>     draft and you have rightly corrected it in the github v9.
>>>
>>>     Regards, Benoit
>>>>
>>>>
>>>>     sec. 3.3.5:
>>>>
>>>>     OLD:
>>>>
>>>>
>>>>           data node rule:  controls access for a specific data
>>>>     node, identified
>>>>           by its path location within the conceptual XML document
>>>>     for the
>>>>           data node.
>>>>
>>>>
>>>>     NEW:
>>>>
>>>>           data node rule:  controls access for a specific data node
>>>>     and its descendants,
>>>>           identified by its path location within the conceptual XML
>>>>     document for the
>>>>           data node.
>>>>
>>>>
>>>>     sec 3.4.5, step 6, bullet 2:
>>>>
>>>>
>>>>     OLD:
>>>>
>>>>             *  The rule does not have a "rule-type" defined or the
>>>>     "rule-
>>>>                type" is "data-node" and the "path" matches the
>>>>     requested
>>>>                data node, action node, or notification node.
>>>>            
>>>>     NEW:
>>>>             *  The rule does not have a "rule-type" defined or the
>>>>     "rule-
>>>>                type" is "data-node" and the "path" matches the
>>>>     requested
>>>>                data node, action node, or notification node. A path is
>>>>                considered to match if the current data node is the
>>>>     data node
>>>>                specified by the path, or is a descendant data node
>>>>     of this data node.
>>>>     appendix B.4: (2 bugs in explanation)
>>>>     OLD:
>>>>     deny-nacm: This rule denies the "guest" group any access to the
>>>>      subtree. Note that the default namespace is only
>>>>     applicable because this subtree is defined in the same
>>>>     namespace as the  element.
>>>>     NEW:
>>>>     deny-nacm: This rule denies the "guest" group any access to the
>>>>      subtree.
>>>>     Andy
>>>>
>>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>>>>     > wrote:
>>>>
>>>>
>>>>
>>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>>>>>
>>>>>
>>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>>>>>         > wrote:
>>>>>
>>>>>
>>>>>
>>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
>>>>>>
>>>>>>
>>>>>>             On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
>>>>>>             > wrote:
>>>>>>
>>>>>>                 On 2017-11-10 11:42, Robert Wilton wrote:
>>>>>>                 >
>>>>>>                 >
>>>>>>                 > On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>>>>>>                 >>
>>>>>>                 >>
>>>>>>                 >>
>>>>>>                 >>
>>>>>>                 >> Mahesh Jethanandani
>>>>>>                 >> mjethanandani@gmail.com
>>>>>>                 
>>>>>>                 >>>>>                 >
>>>>>>                 >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
>>>>>>                 
>>>>>>                 >>>>>                 >> wrote:
>>>>>>                 >>
>>>>>>                 >>> Hi,
>>>>>>                 >>>
>>>>>>                 >>> The term "data node" is used in the document
>>>>>>                 to refer to the top-level node
>>>>>>                 >>> of the specified object, not the entire
>>>>>>                 subtree (if any).
>>>>>>                 >>>
>>>>>>                 >>> The data-rule /foo does not match /foo/child1
>>>>>>                 in the text below.
>>>>>>                 >>> The child nodes are omitted because of step 11.
>>>>>>                 >>> The admin has to explicitly permit individual
>>>>>>                 child nodes (or modules).
>>>>>>                 >>> This seems correct if the read-default is "deny".
>>>>>>                 >>>
>>>>>>                 >>> Should any text be added or changed to make
>>>>>>                 this more clear?
>>>>>>                 >>
>>>>>>                 >> I would agree with Robert that it was not
>>>>>>                 entirely clear that rule applied on the parent
>>>>>>                 data-node does not apply to the child nodes. So
>>>>>>                 yes, it would help to clarify it.
>>>>>>                 > We should be doing more than clarifying it.  We
>>>>>>                 need to fix it so that it works in a sensible
>>>>>>                 way.  I.e. to make the normative text consistent
>>>>>>                 with the behaviour currently described in the
>>>>>>                 examples in
>>>>>>                 > the appendix B.4.
>>>>>>                 >
>>>>>>                 > If we follow Andy's interpretation that a data
>>>>>>                 rule doesn't match child nodes then those
>>>>>>                 examples are completely wrong.  E.g. the 4th rule
>>>>>>                 is described as "This rule gives the 'admin'
>>>>>>                 group read-write
>>>>>>                 > access to all acme  entries."  But
>>>>>>                 If the path only strictly matches
>>>>>>                 "/acme:interfaces/acme:interface" then the admin
>>>>>>                 group rule achieves nothing useful at all.  The
>>>>>>                 admin is not even
>>>>>>                 > allowed to create an interface because they
>>>>>>                 would not even have permission to write to the
>>>>>>                 list key 'name' node required to create a list
>>>>>>                 entry!  Instead, a separate rule would be
>>>>>>                 required for every
>>>>>>                 > single possible schema node under
>>>>>>                 "/acme:interfaces/acme:interface"! I think that
>>>>>>                 this makes "permit" data-node rules completely
>>>>>>                 unusable.
>>>>>>
>>>>>>                 I strongly agree with this, and I would say that
>>>>>>                 it isn't only the case
>>>>>>                 for "permit" rules - e.g. denying some access to
>>>>>>                 a subtree of the data
>>>>>>                 model that would otherwise be permitted due to
>>>>>>                 defaults is at least as
>>>>>>                 common, and the rules would be just as unusable
>>>>>>                 for that.
>>>>>>
>>>>>>                 Besides the examples, I think that the very use
>>>>>>                 of the term "match",
>>>>>>                 though unfortunately not defined, strongly
>>>>>>                 suggests that it is something
>>>>>>                 other than use of e.g. the term "identify" would
>>>>>>                 imply. Additionally,
>>>>>>                 this text in the description of the 'path' leaf
>>>>>>                 is consistent with the
>>>>>>                 match being a prefix match:
>>>>>>
>>>>>>                        The special value '/' refers to all possible
>>>>>>                        datastore contents.";
>>>>>>
>>>>>>                 FWIW, our NACM implementation, available to (and
>>>>>>                 used by) customers
>>>>>>                 since 2012, follows the prefix match logic, and I
>>>>>>                 have yet to hear of
>>>>>>                 any user expecting it to do otherwise.
>>>>>>
>>>>>>                 > To fix this properly, we need to make the
>>>>>>                 data-node path rule a prefix match.  In
>>>>>>                 particular, we need text that specifies:
>>>>>>                 >
>>>>>>                 > (i) that a data-node path match succeeds if it
>>>>>>                 matches the path prefix from the root of the
>>>>>>                 tree.  I.e. so the data-rule "/foo" matches
>>>>>>                 "/foo" and all of foo's descendant children nodes.
>>>>>>
>>>>>>                 Strongly agree.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             I do not see how the text can be interpreted this way.
>>>>>
>>>>>             Because otherwise the path match part of the NACM
>>>>>             solution is really broken, and the path based examples
>>>>>             in the appendix are entirely misleading and wrong. 
>>>>>             The only way those examples make sense is the paths
>>>>>             match descendant children nodes as well.
>>>>>
>>>>>
>>>>>
>>>>>         IMO the text does not support this interpretation.
>>>>         The examples in B.4, and the definition of "/" matching all
>>>>         nodes supports this interpretation.
>>>>
>>>>         Hence, my opinion is that it is the text in 3.4.5 that is
>>>>         incorrectly specified; and that the examples, definition of
>>>>         "/" and standard practice are right.
>>>>
>>>>         Otherwise, how did IETF manage to publish an RFC where the
>>>>         path based examples are so completely wrong?   Whoever
>>>>         wrote and reviewed those examples clearly had a different
>>>>         interpretation of how these path based ACLs worked.
>>>>
>>>>
>>>>>         There is nothing said about inheriting state from the
>>>>>         parent data node.
>>>>>         I think no matter how the permissions are derived, one can
>>>>>         find examples that work better or worse because of it.
>>>>         No.  If the rules apply to descendant children, all normal
>>>>         examples work well (including the ones in the appendix).
>>>>
>>>>
>>>>>         IMO the number of rules required to implement a use-case
>>>>>         is not
>>>>>         very relevant or objective criteria.
>>>>         Yes it is, particularly when the difference is between
>>>>         needing a 1 line rule, and a 100+ line rule.
>>>>
>>>>>
>>>>>         Using the previous example of /home and /home/user1,
>>>>>         if the user1 is given read access to /home, then
>>>>>         (according to you)
>>>>>         it also has read access to every user subtree under /home.
>>>>>         Instead of 1 rule per user, 2 rules are needed
>>>>         No, just 1 rule per user:
>>>>            read-default=deny
>>>>            group=user1, path=/home/user1, action=permit
>>>>
>>>>         This is because of my two proposed changes:
>>>>
>>>>         (i) that a data-node path match succeeds if it matches the
>>>>         path prefix from the root of the tree.  I.e. so the
>>>>         data-rule "/foo" matches "/foo" and all of foo's descendant
>>>>         children nodes.
>>>>         <- This means that you only need 1 entry instead of 100
>>>>         entries.
>>>>
>>>>         (ii) if a data-node rule has action "permit" then it
>>>>         implicitly allows read access for all ancestor parent nodes
>>>>         up to the root.  (I.e. to mitigate the original change
>>>>         proposed on this thread.)
>>>>         <- This means that you don't need a separate read rule for
>>>>         "/home".  Read access to that node it is implicitly given
>>>>         via "group=user1, path=/home/user1, action=permit", hence
>>>>         meaning that the rule works the same way as it does on an
>>>>         rfc6536 compliant implementation.
>>>>
>>>>>
>>>>>            read-default=deny
>>>>>            group=*, path=/home, action=permit
>>>>>            group=user1, path=/home/user1, action=permit
>>>>>
>>>>>         The above rules would allow access for every user to every
>>>>>         other user.
>>>>>         The 2nd rule has no effect, which is counter-intuitive.
>>>>>         Every user dir would need 2 rules
>>>>>
>>>>>            read-default=deny
>>>>>            group=*, path=/home, action=permit
>>>>>            group=user1, path=/home/user1, action=permit
>>>>>            group=*, path=/home/user1, action=deny
>>>>>
>>>>>>             There is nothing that says this is how it works.
>>>>>>             If it did, once could never have privileged sub-fiolders
>>>>>>
>>>>>>                  /var/log -> permit
>>>>>>              /var/log/apache2  -> deny
>>>>>
>>>>>             Yes, you can, you just list the longest path first in
>>>>>             the list of rules:
>>>>>
>>>>>              (1)  /var/log/apache2  -> deny
>>>>>               (2) /var/log -> permit
>>>>>
>>>>>             Any requests that attempt to access anything under
>>>>>             /var/log/apache2 would match rule (1) and be denied.
>>>>>             Any requests that attempt to access anything under
>>>>>             /var/log, but not under /var/log/apache2, would fail
>>>>>             to match rule (1), but would match rule (2) instead
>>>>>             and be permitted.
>>>>>
>>>>>
>>>>>
>>>>>         I do not see any text in the draft or RFC 7950 that
>>>>>         suggests that /var/log and /var/log/apache2 represent the
>>>>>         same data node.
>>>>         They are different data nodes, but I don't see how that is
>>>>         relevant.
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>>
>>>>>
>>>>>         Andy
>>>>>
>>>>>>
>>>>>>
>>>>>>                 > (ii) if a data-node rule has action "permit"
>>>>>>                 then it implicitly allows read access for all
>>>>>>                 ancestor parent nodes up to the root.  (I.e. to
>>>>>>                 mitigate the original change proposed on this
>>>>>>                 thread.)
>>>>>>
>>>>>>                 This seems reasonable to me, although I haven't
>>>>>>                 at this point evaluated
>>>>>>                 the suggestion in detail. In any case I think the
>>>>>>                 main point both
>>>>>>                 regarding this and the prefix match is that this
>>>>>>                 update to 6536 can't
>>>>>>                 make radical changes to the semantics compared to
>>>>>>                 a "reasonable
>>>>>>                 interpretation" (hard to define, I know) of the
>>>>>>                 under-specified
>>>>>>                 original.
>>>>>>
>>>>>>
>>>>>>             The text does not say this at all so I do not approve
>>>>>>             of this change
>>>>>
>>>>>             In the RFC version of the NACM this wasn't required
>>>>>             because operation 'none' didn't require read access. 
>>>>>             Now read access is required even for operation 'none',
>>>>>             then this change makes sense to make the NACM changes
>>>>>             backwards compatible, whilst still closing the
>>>>>             security hole.
>>>>>
>>>>>             Thanks,
>>>>>             Rob
>>>>>
>>>>>>
>>>>>>
>>>>>>                 --Per
>>>>>>
>>>>>>
>>>>>>
>>>>>>             Andy
>>>>>>
>>>>>>                 > Thanks,
>>>>>>                 > Rob
>>>>>>                 >
>>>>>>                 >
>>>>>>                 >>
>>>>>>                 >> Thanks
>>>>>>                 >>
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>> Andy
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton
>>>>>>                 
>>>>>>                 >>>>>                 >> wrote:
>>>>>>                 >>>
>>>>>>                 >>>     Hi Andy,
>>>>>>                 >>>
>>>>>>                 >>>     It isn't clear to me whether matching a
>>>>>>                 path in NACM either:
>>>>>>                 >>>  (i) Only applies to the specific node, and
>>>>>>                 not any children, or
>>>>>>                 >>>  (ii) Applies to the specific node and all
>>>>>>                 descendant children nodes as well.
>>>>>>                 >>>
>>>>>>                 >>>     As an example, using the tree below.  if
>>>>>>                 I have a rule that matches path "A/B" then does
>>>>>>                 that apply to only the specific node "A/B", or
>>>>>>                 does it also apply to all descendant children of
>>>>>>                 "A/B" as
>>>>>>                 >>>  well?
>>>>>>                 >>>
>>>>>>                 >>>     In rfc6536bis-08, section "3.4.5. Data
>>>>>>                 Node Access Validation", step 6 states:
>>>>>>                 >>>
>>>>>>                 >>>      *  The rule does not have a "rule-type"
>>>>>>                 defined or the "rule-
>>>>>>                 >>>         type" is "data-node" and the *"path"
>>>>>>                 matches the requested data node*, action node, or
>>>>>>                 notification node.
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>>     My reading of this is that it implies
>>>>>>                 that the interpretation of the path rule is (i),
>>>>>>                 but this is not how I would normally expect an
>>>>>>                 ACL rule to apply in a tree like object (e.g a
>>>>>>                 directory
>>>>>>                 >>>  file system).
>>>>>>                 >>>
>>>>>>                 >>>  However, the examples in Appendix B.4. imply
>>>>>>                 that the path rule is to be interpreted like
>>>>>>                 (ii), or otherwise the example rules seem to be
>>>>>>                 mostly pointless.
>>>>>>                 >>>
>>>>>>                 >>>  E.g. taking this example from appendix B.4:
>>>>>>                 >>>
>>>>>>                 >>>     
>>>>>>                 >>> permit-dummy-interface
>>>>>>                 >>>       >>>>>                 xmlns:acme="http://example.com/ns/itf
>>>>>>                 "
>>>>>>                 >
>>>>>>                 >>>
>>>>>>                 /acme:interfaces/acme:interface[acme:name='dummy']
>>>>>>                 >>>       
>>>>>>                 >>> read
>>>>>>                 update
>>>>>>                 >>> permit
>>>>>>                 >>> 
>>>>>>                 >>>         Allow the limited and guest groups read
>>>>>>                 >>>         and update access to the dummy interface.
>>>>>>                 >>> 
>>>>>>                 >>>     
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>>     If the rule is (i) then the access rule
>>>>>>                 allows the client to read the specific node
>>>>>>                 "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>>>>                 but not any child leafs/containers of that interface,
>>>>>>                 >>>  this doesn't seem useful.
>>>>>>                 >>>
>>>>>>                 >>>  Further comments inline below ...
>>>>>>                 >>>
>>>>>>                 >>>     On 08/11/2017 20:05, Andy Bierman wrote:
>>>>>>                 >>>>  Hi,
>>>>>>                 >>>>
>>>>>>                 >>>>  This change has no impact on the server if
>>>>>>                 /nacm/read-default is "permit".
>>>>>>                 >>>>  In that case, the extra read rules for /A
>>>>>>                 and /A/B are not needed.
>>>>>>                 >>>     I agree.
>>>>>>                 >>>
>>>>>>                 >>>>  An operator worried about read access
>>>>>>                 should set read-default to "deny".
>>>>>>                 >>>     I agree.  This is the scenario that I'm
>>>>>>                 considering.
>>>>>>                 >>>
>>>>>>                 >>>>  In that case, explicit rules to read /A and
>>>>>>                 /A/B would be needed
>>>>>>                 >>>>  in the new NACM.
>>>>>>                 >>>  Yes, if the interpretation of the rule is
>>>>>>                 (i) above.
>>>>>>                 >>>  Otherwise if the interpretation is (ii) then
>>>>>>                 you only need "read /A" since that implies "read
>>>>>>                 A/B" as well (as long as the rules are listed in
>>>>>>                 the correct order).
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>>>    The deny rules would not be needed.
>>>>>>                 >>>  Only if the interpretation of the rule is
>>>>>>                 (i) above.  In which case the "read/write 'A/B/J'
>>>>>>                 rule would not be sufficient.  It would be
>>>>>>                 necessary to define an Xpath expressions that
>>>>>>                 contains
>>>>>>                 >>>     all children nodes as well.  Perhaps
>>>>>>                 'A/B/J//*'?
>>>>>>                 >>>
>>>>>>                 >>>     If the interpretation of the rule is (ii)
>>>>>>                 then you would also need all the explicit deny
>>>>>>                 statements as well, otherwise they would be
>>>>>>                 allowed by the "read /A" rule above.
>>>>>>                 >>>
>>>>>>                 >>>  Thanks,
>>>>>>                 >>>     Rob
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 >>>>  Andy
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 >>>>  On Wed, Nov 8, 2017 at 8:33 AM, Robert
>>>>>>                 Wilton >>>>>                 
>>>>>>                 >>>>>                 >> wrote:
>>>>>>                 >>>>
>>>>>>                 >>>>      Hi,
>>>>>>                 >>>>
>>>>>>                 >>>>      I'm not sure about this change.
>>>>>>                 >>>>
>>>>>>                 >>>>      I'm not that familiar with NACM, but if
>>>>>>                 you want to give a particular set of users
>>>>>>                 read/write access to a subtree, but not allow
>>>>>>                 them to have any other access to the
>>>>>>                 configuration in the
>>>>>>                 >>>>      running datastore then with the
>>>>>>                 existing RFC, that could be expressed with a
>>>>>>                 single rule (example in 6536bis, appendix B.4)
>>>>>>                 >>>>
>>>>>>                 >>>>      With this new change, I think that you
>>>>>>                 may need to configure many more rules to achieve
>>>>>>                 the same thing.  I think that you would need to
>>>>>>                 give read access to the top node in the desired
>>>>>>                 >>>>      path, and then separate explicit "deny"
>>>>>>                 rules for every sibling child node walking from
>>>>>>                 the top of the tree down to the data node that
>>>>>>                 read/write access is actually being given to.  The
>>>>>>                 >>>>      example below may explain my
>>>>>>                 understanding better:
>>>>>>                 >>>>
>>>>>>                 >>>>      E.g. For a tree of data nodes, rooted
>>>>>>                 at A, if we wanted to give read/write access only
>>>>>>                 to "J" subtree, and no access for the rest of the
>>>>>>                 tree then:
>>>>>>                 >>>>
>>>>>>                 >>>>   A
>>>>>>                 >>>>   |
>>>>>>                 >>>>  --------------------
>>>>>>                 >>>>              | |     |     |
>>>>>>                 >>>>              B C     D     E
>>>>>>                 >>>>              |
>>>>>>                 >>>>         -----------
>>>>>>                 >>>>         |   |  |  |
>>>>>>                 >>>>         F   G  H  J
>>>>>>                 >>>>                   |
>>>>>>                 >>>>                  ...
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 >>>>      In the old model, I think that the ACL
>>>>>>                 rules would be 1 rules long (assuming default
>>>>>>                 deny all):
>>>>>>                 >>>>         "read/write 'A/B/J'
>>>>>>                 >>>>
>>>>>>                 >>>>      In the new model, I think that the
>>>>>>                 equivalent ACL rules would need to be 8 rules
>>>>>>                 long (assuming default deny all):
>>>>>>                 >>>>         "read/write 'A/B/J'
>>>>>>                 >>>>         "read A"
>>>>>>                 >>>>         "deny C"
>>>>>>                 >>>>         "deny D"
>>>>>>                 >>>>         "deny E"
>>>>>>                 >>>>         "deny F"
>>>>>>                 >>>>         "deny G"
>>>>>>                 >>>>         "deny H"
>>>>>>                 >>>>
>>>>>>                 >>>>      Note, I am assuming that a "path" rule
>>>>>>                 matches for the given path and all descendant
>>>>>>                 nodes.  The draft doesn't seem to be particularly
>>>>>>                 clear on this point (it states that the rule applies
>>>>>>                 >>>>      when the path matches, but this would
>>>>>>                 seem to be counter intuitive), and perhaps it
>>>>>>                 could be clarified.
>>>>>>                 >>>>
>>>>>>                 >>>>      If this change is allowed, then the
>>>>>>                 example in appendix B.4 looks like it would need
>>>>>>                 to be fixed, since the "limited-acl" probably
>>>>>>                 wouldn't give any access at all, unless default read
>>>>>>                 >>>>      access had been given.
>>>>>>                 >>>>
>>>>>>                 >>>>      But, possibly I'm misunderstanding how
>>>>>>                 this all works! If so, apologies for the noise :-)
>>>>>>                 >>>>
>>>>>>                 >>>>      Thanks,
>>>>>>                 >>>>      Rob
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 >>>>      On 02/11/2017 14:18, Benoit Claise wrote:
>>>>>>                 >>>>>         Dear all,
>>>>>>                 >>>>>
>>>>>>                 >>>>>         Here is a major change in
>>>>>>                 draft-ietf-netconf-rfc6536bis, suggested by the
>>>>>>                 Security AD Eric Rescola part of the IESG review,
>>>>>>                 which I would like to validate with the WG. See
>>>>>>                 >>>>>
>>>>>>                 https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>>>>>                 
>>>>>>                 >>>>>                 >
>>>>>>                 >>>>>
>>>>>>                 >>>>>         
>>>>>>                 >>>>>         The NETCONF WG was cc'ed for the
>>>>>>                 entire discussion.
>>>>>>                 >>>>>         What do you think? I will draw the
>>>>>>                 conclusions by Friday Nov 10th.
>>>>>>                 >>>>>
>>>>>>                 >>>>>         Note: If the WG is fine, the next
>>>>>>                 step is to approve this document.
>>>>>>                 >>>>>
>>>>>>                 >>>>>         Regards, Benoit
>>>>>>                 >>>>>
>>>>>>                 >>>>>
>>>>>>                 >>>>>       
>>>>>>                  _______________________________________________
>>>>>>                 >>>>>         Netconf mailing list
>>>>>>                 >>>>> Netconf@ietf.org 
>>>>>>                 >
>>>>>>                 >>>>>
>>>>>>                 https://www.ietf.org/mailman/listinfo/netconf
>>>>>>                 
>>>>>>                 >>>>>                 >
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>> _______________________________________________
>>>>>>                 >>> Netconf mailing list
>>>>>>                 >>> Netconf@ietf.org 
>>>>>>                 >
>>>>>>                 >>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>>                 
>>>>>>                 >>
>>>>>>                 >> Mahesh Jethanandani
>>>>>>                 >> mjethanandani@gmail.com
>>>>>>                 
>>>>>>                 >>>>>                 >
>>>>>>                 >
>>>>>>                 >
>>>>>>                 >
>>>>>>                 > _______________________________________________
>>>>>>                 > Netconf mailing list
>>>>>>                 > Netconf@ietf.org 
>>>>>>                 > https://www.ietf.org/mailman/listinfo/netconf
>>>>>>                 
>>>>>>                 >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Netconf mailing list
>>>>     Netconf@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>     
>>>
>>
>
>


--------------2AF788B9FC757172BB684F14
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k
eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5IaSBBbmR5LDxi
cj4NCiAgICA8L3A+DQogICAgPGJyPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZp
eCI+T24gMjIvMTEvMjAxNyAxODowOSwgQW5keSBCaWVybWFuDQogICAgICB3cm90ZTo8YnI+
DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpD
QUJDT0NIUXJTT2dHRUFQZHo1VGRHQkNHQlNQemdBc3BHUlFrZ1FEcjM9SDRYcDlKU1FAbWFp
bC5nbWFpbC5jb20iPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj
b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICAgICAgPGRpdiBkaXI9Imx0
ciI+PGJyPg0KICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KICAgICAg
ICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIE5vdiAyMiwgMjAxNyBhdCA1
OjQxIEFNLA0KICAgICAgICAgICAgQmVub2l0IENsYWlzZSA8c3BhbiBkaXI9Imx0ciI+Jmx0
OzxhDQogICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIiB0
YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi
PmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICB3cm90ZTo8
YnI+DQogICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl
PSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj
YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgPGRpdiB0ZXh0PSIj
MDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNz
PSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1bW96LWNpdGUtcHJlZml4Ij5IaQ0KICAgICAgICAg
ICAgICAgICAgUm9iLDxicj4NCiAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgIEF0IHRoYXQgcG9pbnRzIGluIHRpbWUsIGlmIGl0IGNsYXJpZmllcyB0aGUgc3Bl
Yy4gYW5kDQogICAgICAgICAgICAgICAgICB0aGUgYXV0aG9ycyBhZ3JlZSB3aXRoIHRoaXMs
IGxldCdzIGRvIHRoZSByaWdodCB0aGluZy48YnI+DQogICAgICAgICAgICAgICAgICA8YnI+
DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+SSB3aWxsIGFkZCB0aGUgbmV3IHRleHQgaWYg
dGhhdCBpcyB3aGF0IHRoZSBXRyB3YW50cy48L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgSGF2
aW5nIHJlYWQgdGhpcyBkcmFmdCwgSSB3YXMgdW5kZWNpZGVkIHdoYXQgdGhlIGludGVuZGVk
IGJlaGF2aW9yDQogICAgYWN0dWFsbHkgc2hvdWxkIGJlLjxicj4NCiAgICA8YnI+DQogICAg
VGhlIHdheSB0aGF0IFl1bWFwcm8gYW5kIFRhaWwtZiBoYXZlIGltcGxlbWVudGVkIHRoaXMg
aXMgcmVhc29uYWJsZSwNCiAgICBhbmQgaXMgcHJvYmFibHkgYWxzbyB0aGUgd2F5IHRoYXQg
SSB3b3VsZCBpbXBsZW1lbnRlZCBpdC48YnI+DQogICAgPGJyPg0KICAgIEJ1dCBJIGFsc28g
dGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgaW1wbGVtZW50YXRpb24gZm9y
IGENCiAgICBzZXJ2ZXIgdG8gY2FsY3VsYXRlIHRoZSBmdWxsIGNoYW5nZSBzZXQgKHRha2lu
ZyBhY2NvdW50IG9mIHNpZGUNCiAgICBlZmZlY3RzIGZyb20gd2hlbiBhbmQgY2hvaWNlIHN0
YXRlbWVudHMpIHRvIHRoZSBkYXRhc3RvcmUgYmVmb3JlDQogICAgY2hlY2tpbmcgdGhlICJ3
cml0ZSBkYXRhIG5vZGUgYWNjZXNzIGNvbnRyb2wiIGFnYWluc3QgdGhlIHJlc3VsdGFudA0K
ICAgIGNoYW5nZSBzZXQuPGJyPg0KICAgIDxicj4NCiAgICBNeSBpbnRlcnByZXRhdGlvbiBp
cyB0aGF0IHRoZSBSRkMgdGV4dCBpcyBhbWJpZ3VvdXMgb24gd2hhdCB0aGUNCiAgICBjb3Jy
ZWN0IGJlaGF2aW9yIGlzLCBhbmQgb25lIGNvdWxkIG1ha2UgYSByZWFzb25hYmxlIGFyZ3Vt
ZW50IHRoYXQNCiAgICB0aGUgY3VycmVudCBSRkMgYWN0dWFsbHkgc3BlY2lmaWVzIHRoYXQg
dGhlIGFsdGVybmF0aXZlIGJlaGF2aW9yIGlzDQogICAgY29ycmVjdCwgaS5lLiByZXF1aXJp
bmcgZGVsZXRlIGFjY2VzcyBldmVuIGlmIGEgbm9kZSBpcyBpbXBsaWNpdGx5DQogICAgY2hh
bmdlcyBhcyBhIHNpZGUgZWZmZWN0LsKgIEUuZy4gc2VjdGlvbiAzLjIuMyBvZiBSRkMgNjUz
NiBzdGF0ZXM6PGJyPg0KICAgIDxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNp
emU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJy
ZWFrLWJlZm9yZTogcGFnZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y
cGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7
IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPg0KICAgSWYgdGhlIHByb3RvY29s
IG9wZXJhdGlvbiB3b3VsZCByZXN1bHQgaW4gdGhlIGRlbGV0aW9uIG9mIGEgZGF0YXN0b3Jl
DQogICBub2RlIGFuZCB0aGUgdXNlciBkb2VzIG5vdCBoYXZlICJkZWxldGUiIGFjY2VzcyBw
ZXJtaXNzaW9uIGZvciB0aGF0DQogICBub2RlLCB0aGUgcHJvdG9jb2wgb3BlcmF0aW9uIGlz
IHJlamVjdGVkIHdpdGggYW4gImFjY2Vzcy1kZW5pZWQiDQogICBlcnJvci4NCjwvcHJlPg0K
ICAgIDxicj4NCiAgICBBbiAmbHQ7ZWRpdC1kYXRhJmd0OyByZXF1ZXN0IHRoYXQgY2F1c2Vz
IGEgd2hlbiBjb25zdHJhaW50IHRvDQogICAgZXZhbHVhdGUgZGlmZmVyZW50bHkgZG9lcyBy
ZXN1bHQgaW4gYSBkZWxldGlvbiBvZiB0aG9zZSBkYXRhIG5vZGVzDQogICAgZnJvbSB0aGUg
ZGF0YXN0b3JlLCBhbmQgaGVuY2UgYWNjb3JkaW5nIHRvIHRoZSB0ZXh0IGFib3ZlLCByZXF1
aXJlcw0KICAgIGV4cGxpY2l0ICJkZWxldGUiIGFjY2VzcyBwZXJtaXNzaW9uIHRvIGFjY29t
cGxpc2ggdGhhdC48YnI+DQogICAgPGJyPg0KICAgIENsZWFybHkgaXQgd291bGQgYmUgYW4g
aW50ZXJvcCBpc3N1ZSBpZiBkaWZmZXJlbnQgc2VydmVycw0KICAgIGltcGxlbWVudGVkIHRo
ZSBOQUNNIHBhdGggYmFzZWQgZmlsdGVyaW5nIGRpZmZlcmVudGx5Ljxicj4NCiAgICA8YnIg
Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KICAgIEhlbmNlIHdoeSBJIHRo
aW5rIHRoYXQgaXQgd291bGQgYmUgcHJ1ZGVudCBmb3IgdGhlIGRyYWZ0IHRvIGJlIG1vcmUN
CiAgICBleHBsaWNpdCBvbiB3aGVuIGFuZCBjaG9pY2Ugc3RhdGVtZW50IGhhbmRsaW5nLjxi
cj4NCiAgICA8YnI+DQogICAgVGhhbmtzLDxicj4NCiAgICBSb2I8YnI+DQogICAgPGJyPg0K
ICAgIDxicj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIg0KY2l0ZT0ibWlkOkNBQkNP
Q0hRclNPZ0dFQVBkejVUZEdCQ0dCU1B6Z0FzcEdSUWtnUURyMz1INFhwOUpTUUBtYWlsLmdt
YWlsLmNvbSI+DQogICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgPGRpdiBjbGFzcz0i
Z21haWxfZXh0cmEiPg0KICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAg
ICAgICAgICAgIDxkaXY+VGhlcmUgaGF2ZSBub3QgYmVlbiBhbnkgY29tbWVudHMgb24gdGhp
cyBpc3N1ZS48L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg
ICAgICAgPGRpdj5BbmR5PC9kaXY+DQogICAgICAgICAgICA8ZGl2PsKgPC9kaXY+DQogICAg
ICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46
MCAwIDANCiAgICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw
YWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgPGRpdiB0ZXh0PSIjMDAwMDAwIiBi
Z2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJtXy01MDQ0
NDI0NDQyNzA0ODQ2MzM1bW96LWNpdGUtcHJlZml4Ij4NCiAgICAgICAgICAgICAgICAgIFJl
Z2FyZHMsIEJlbm9pdC48YnI+DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg
ICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgICAgICA8cD5I
aSBCZW5vaXQsPC9wPg0KICAgICAgICAgICAgICAgICAgPHA+VGhlcmUgaXMgYWxzbyBvbmUg
ZnVydGhlciwgdW5yZWxhdGVkIGNoYW5nZSB0aGF0IEkNCiAgICAgICAgICAgICAgICAgICAg
YW0gcHJvcG9zaW5nIGlzIG1hZGUgdGhlIGRyYWZ0IGJlZm9yZSBpdCBpcw0KICAgICAgICAg
ICAgICAgICAgICBwdWJsaXNoZWQsIHRvIGhlbHAgYmV0dGVyIGNsYXJpZnkgdGhlIGV4cGVj
dGVkDQogICAgICAgICAgICAgICAgICAgIGJlaGF2aW9yLsKgIEl0IGlzbid0IHRoZSBlbmQg
b2YgdGhlIHdvcmxkIGlmIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgZG9lc24ndCBnbyBp
biwgYnV0IEkgdGhpbmsgdGhhdCBpdCBwcmV2ZW50cyBzb21ldGltZQ0KICAgICAgICAgICAg
ICAgICAgICB0YWtpbmcgYSBkaWZmZXJlbnQsIGJ1dCBJTU8gcmVhc29uYWJsZSwNCiAgICAg
ICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24gb2YgaG93ICJ3aGVuIiBzdGF0ZW1lbnRz
IGFyZQ0KICAgICAgICAgICAgICAgICAgICBjb25zaWRlcmVkLCBhbmQgdGhlbiBoYXZpbmcg
YSBmdXR1cmUgYXJndW1lbnQgYWJvdXQNCiAgICAgICAgICAgICAgICAgICAgd2hhdCBiZWhh
dmlvciBpdCBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLjxicj4NCiAgICAgICAgICAgICAg
ICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgIDxwPklmIHdlIGNsYXJpZnkgaXQgbm93LCB0
aGVuIGl0IGNsb3NlcyB0aGF0IGRvb3IgOi0pPC9wPg0KICAgICAgICAgICAgICAgICAgPHA+
SSd2ZSBwcm9wb3NlZCB0ZXh0IHRvIEFuZHkgYW5kIE1hcnRpbiBvbiBNb25kYXksDQogICAg
ICAgICAgICAgICAgICAgIGJ1dCBJJ3ZlIG5vdCBoZWFyZCBiYWNrIHlldC48L3A+DQogICAg
ICAgICAgICAgICAgICA8cD5OZXRjb25mIGVtYWlsIHdpdGggcHJvcG9zZWQgdGV4dCBhdHRh
Y2hlZC7CoCBUaGUNCiAgICAgICAgICAgICAgICAgICAgdGV4dCBkb2Vzbid0IG5lY2Vzc2Fy
aWx5IGhhdmUgdG8gbWF0Y2ggdGhpcywgYnV0DQogICAgICAgICAgICAgICAgICAgIHBlcnNv
bmFsbHkgSSB0aGluayB0aGF0IGl0IGlzIHVzZWZ1bCBpZiB0aGUgZHJhZnQNCiAgICAgICAg
ICAgICAgICAgICAgc2F5cyBzb21ldGhpbmcgb24gdGhpcy48YnI+DQogICAgICAgICAgICAg
ICAgICA8L3A+DQogICAgICAgICAgICAgICAgICBUaGFua3MsPGJyPg0KICAgICAgICAgICAg
ICAgICAgUm9iPGJyPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0ibV8tNTA0NDQyNDQ0Mjcw
NDg0NjMzNW1vei1jaXRlLXByZWZpeCI+T24NCiAgICAgICAgICAgICAgICAgICAgMjIvMTEv
MjAxNyAxMzoyNSwgQmVub2l0IENsYWlzZSB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
ICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1
bW96LWNpdGUtcHJlZml4Ij5Pbg0KICAgICAgICAgICAgICAgICAgICAgIDExLzEwLzIwMTcg
NzoyMyBQTSwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPkhpLA0KICAgICAgICAgICAg
ICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+SGVyZSBhcmUgc29tZSBwcm9wb3NlZCBl
ZGl0cyB0byBtYWtlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhIHJ1bGUg
Y29uc2lzdGVudCB3aXRoIHRoZSBleGFtcGxlcy48L2Rpdj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgIDxkaXY+Tm90ZSB0aGF0IHRoaXMgaXNzdWUgaXMgbm90IHJlbGF0ZWQgdG8gdGhl
DQogICAgICAgICAgICAgICAgICAgICAgICAgIGVkaXQgaW4gdGhlIG9yaWdpbmFsIDEtd2Vl
ayBjaGFuZ2UuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgVGhhdCdz
IHJpZ2h0LCBidXQgd2UgZm91bmQgYSBzb3VyY2Ugb2YNCiAgICAgICAgICAgICAgICAgICAg
bWlzaW50ZXJwcmV0YXRpb24gaW4gdGhlIGRyYWZ0IGFuZCB5b3UgaGF2ZSByaWdodGx5DQog
ICAgICAgICAgICAgICAgICAgIGNvcnJlY3RlZCBpdCBpbiB0aGUgZ2l0aHViIHY5Ljxicj4N
CiAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICBSZWdhcmRz
LCBCZW5vaXQ8YnI+DQogICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PnNlYy4gMy4z
LjU6PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5P
TEQ6PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKg
IMKgIGRhdGEgbm9kZSBydWxlOiDCoGNvbnRyb2xzIGFjY2Vzcw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZvciBhIHNwZWNpZmljIGRhdGEgbm9kZSwgaWRlbnRpZmllZDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgIMKgIGJ5IGl0cyBwYXRo
IGxvY2F0aW9uIHdpdGhpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25j
ZXB0dWFsIFhNTCBkb2N1bWVudCBmb3IgdGhlPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXY+TkVXOjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAg
wqAgwqAgZGF0YSBub2RlIHJ1bGU6IMKgY29udHJvbHMgYWNjZXNzDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZm9yIGEgc3BlY2lmaWMgZGF0YSBub2RlIGFuZCBpdHMNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBkZXNjZW5kYW50cyw8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCBpZGVudGlmaWVkIGJ5IGl0cyBwYXRoIGxv
Y2F0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aGluIHRoZSBjb25jZXB0
dWFsIFhNTCBkb2N1bWVudCBmb3IgdGhlPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgIDxkaXY+wqAgwqAgwqAgZGF0YSBub2RlLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRp
dj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+c2VjIDMuNC41LCBzdGVwIDYsIGJ1bGxldCAyOjwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pk9M
RDo8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoCDCoCAqIMKgVGhl
IHJ1bGUgZG9lcyBub3QgaGF2ZSBhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgInJ1
bGUtdHlwZSIgZGVmaW5lZCBvciB0aGUgInJ1bGUtPC9kaXY+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+wqAgwqAgwqAgwqAgwqAgwqB0eXBlIiBpcyAiZGF0YS1ub2RlIiBh
bmQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgInBhdGgiIG1hdGNoZXMgdGhl
IHJlcXVlc3RlZDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKg
IMKgIMKgIMKgIMKgZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwgb3INCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBub3RpZmljYXRpb24gbm9kZS48L2Rpdj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgPHByZSBjbGFzcz0ibV8tNTA0NDQyNDQ0MjcwNDg0NjMz
NWdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6
MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCkiPiAgICAgIDwvcHJlPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0
ODQ2MzM1Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2lu
LXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+TkVXOjwvcHJl
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQy
NzA0ODQ2MzM1Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFy
Z2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+PGRpdiBz
dHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlm
O2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgICogwqBU
aGUgcnVsZSBkb2VzIG5vdCBoYXZlIGEgInJ1bGUtdHlwZSIgZGVmaW5lZCBvciB0aGUgInJ1
bGUtPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTph
cmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1zcGFjZTpub3JtYWwiPsKg
IMKgIMKgIMKgIMKgIMKgdHlwZSIgaXMgImRhdGEtbm9kZSIgYW5kIHRoZSAicGF0aCIgbWF0
Y2hlcyB0aGUgcmVxdWVzdGVkPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0
KTtmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbDt3aGl0ZS1z
cGFjZTpub3JtYWwiPsKgIMKgIMKgIMKgIMKgIMKgZGF0YSBub2RlLCBhY3Rpb24gbm9kZSwg
b3Igbm90aWZpY2F0aW9uIG5vZGUuIEEgcGF0aCBpczwvZGl2PjxkaXYgc3R5bGU9ImNvbG9y
OnJnYigzNCwzNCwzNCk7Zm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6
c21hbGw7d2hpdGUtc3BhY2U6bm9ybWFsIj7CoCDCoCDCoCDCoCDCoCDCoGNvbnNpZGVyZWQg
dG8gbWF0Y2ggaWYgdGhlIGN1cnJlbnQgZGF0YSBub2RlIGlzIHRoZSBkYXRhIG5vZGU8L2Rp
dj48ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMzQsMzQsMzQpO2ZvbnQtZmFtaWx5OmFyaWFsLHNh
bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsO3doaXRlLXNwYWNlOm5vcm1hbCI+wqAgwqAgwqAg
wqAgwqAgwqBzcGVjaWZpZWQgYnkgdGhlIHBhdGgsIG9yIGlzIGEgZGVzY2VuZGFudCBkYXRh
IG5vZGUgb2YgdGhpcyBkYXRhIG5vZGUuPC9kaXY+PC9wcmU+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgIDxwcmUgY2xhc3M9Im1fLTUwNDQ0MjQ0NDI3MDQ4NDYzMzVnbWFpbC1uZXdw
YWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4t
Ym90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj5hcHBlbmRpeCBCLjQ6ICgyIGJ1Z3MgaW4g
ZXhwbGFuYXRpb24pPC9wcmU+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwcmUgY2xh
c3M9Im1fLTUwNDQ0MjQ0NDI3MDQ4NDYzMzVnbWFpbC1uZXdwYWdlIiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpy
Z2IoMCwwLDApIj5PTEQ6PC9wcmU+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwcmUg
Y2xhc3M9Im1fLTUwNDQ0MjQ0NDI3MDQ4NDYzMzVnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFy
Z2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweCI+ICAgICAgZGVueS1uYWNtOiAgVGhp
cyBydWxlIGRlbmllcyB0aGUgImd1ZXN0IiBncm91cCBhbnkgYWNjZXNzIHRvIHRoZQ0KICAg
ICAgJmx0O25hY20mZ3Q7IHN1YnRyZWUuICBOb3RlIHRoYXQgdGhlIGRlZmF1bHQgbmFtZXNw
YWNlIGlzIG9ubHkNCiAgICAgIGFwcGxpY2FibGUgYmVjYXVzZSB0aGlzIHN1YnRyZWUgaXMg
ZGVmaW5lZCBpbiB0aGUgc2FtZSBuYW1lc3BhY2UNCiAgICAgIGFzIHRoZSAmbHQ7ZGF0YS1y
dWxlJmd0OyBlbGVtZW50Lg0KPC9zcGFuPjwvZm9udD48L3ByZT4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgPHByZSBjbGFzcz0ibV8tNTA0NDQyNDQ0MjcwNDg0NjMzNWdtYWlsLW5l
d3BhZ2UiIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PGZvbnQg
Y29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4Ij4gPC9z
cGFuPjwvZm9udD48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHByZSBjbGFz
cz0ibV8tNTA0NDQyNDQ0MjcwNDg0NjMzNWdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJtYXJnaW4t
dG9wOjBweDttYXJnaW4tYm90dG9tOjBweCI+PHByZSBjbGFzcz0ibV8tNTA0NDQyNDQ0Mjcw
NDg0NjMzNWdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6
ZToxMy4zMzMzcHg7bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHgiPk5FVzo8L3By
ZT48cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1Z21haWwtbmV3cGFnZSIgc3R5
bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAw
MDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPiAgICAgIGRlbnktbmFj
bTogIFRoaXMgcnVsZSBkZW5pZXMgdGhlICJndWVzdCIgZ3JvdXAgYW55IGFjY2VzcyB0byB0
aGUNCiAgICAgICZsdDtuYWNtJmd0OyBzdWJ0cmVlLg0KPC9zcGFuPjwvZm9udD48L3ByZT48
cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1Z21haWwtbmV3cGFnZSIgc3R5bGU9
Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0iIzAwMDAw
MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwvZm9udD48
L3ByZT48cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1Z21haWwtbmV3cGFnZSIg
c3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBjb2xvcj0i
IzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9zcGFuPjwv
Zm9udD48L3ByZT48cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1Z21haWwtbmV3
cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48Zm9udCBj
b2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgiPg0KPC9z
cGFuPjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1Z21h
aWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij48
Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHgi
PkFuZHk8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Im1fLTUwNDQ0MjQ0NDI3MDQ4
NDYzMzVnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRv
bTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz
LjMzMzNweCI+DQo8L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Im1fLTUwNDQ0MjQ0
NDI3MDQ4NDYzMzVnbWFpbC1uZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2lu
LWJvdHRvbTowcHgiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweCI+DQo8L3NwYW4+PC9mb250PjwvcHJlPjwvcHJlPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog
ICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmks
IE5vdiAxMCwgMjAxNyBhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICA5OjI0IEFNLCBS
b2JlcnQgV2lsdG9uIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9
InRydWUiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJs
b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0i
I0ZGRkZGRiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cD48YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2
MzM1bV85MDY0ODI4Njk0Nzc5NTMyODM4bW96LWNpdGUtcHJlZml4Ij5Pbg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxMC8xMS8yMDE3IDE2OjMzLCBBbmR5IEJpZXJtYW4g
d3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh
Ij48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+T24gRnJpLCBOb3YNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgMTAsIDIwMTcgYXQgODoxNiBBTSwgUm9iZXJ0IFdpbHRvbg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBkaXI9Imx0ciI+Jmx0Ozxh
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWls
dG86cndpbHRvbkBjaXNjby5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5j
b208L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBz
b2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQs
MjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXYNCmNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1bV85MDY0
ODI4Njk0Nzc5NTMyODM4Z21haWwtbV8tNzM2MTY0NzI4MzUyMDQ1NjYzNW1vei1jaXRlLXBy
ZWZpeCI+T24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
MTAvMTEvMjAxNyAxNTo0OSwgQW5keQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBCaWVybWFuIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPjxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNs
YXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyaSwgTm92IDEw
LCAyMDE3IGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDU6MDcgQU0sIFBlciBIZWRlbGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhDQpocmVm
PSJtYWlsdG86cGVyQHRhaWwtZi5jb20iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNl
bmQ9InRydWUiPnBlckB0YWlsLWYuY29tPC9hPiZndDs8L3NwYW4+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVv
dGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBjbGFzcz0iZ21haWxfcXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbjowcHgNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwcHggMHB4DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9y
ZGVyLWxlZnQ6MXB4DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc29saWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPk9u
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
MjAxNy0xMS0xMCAxMTo0MiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBSb2JlcnQgV2lsdG9uIHdyb3RlOjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyBPbiAxMC8xMS8yMDE3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMTA6MDIsIE1haGVzaA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEpldGhhbmFuZGFuaSB3cm90ZTo8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsgTWFoZXNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxhDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86
bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzo8YQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
aHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsi
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY288d2JyPm08
L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyBPbiBOb3YgMTAsDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAxNywgYXQgMTA6MDcgQU0sDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5keSBC
aWVybWFuICZsdDs8YQ0KaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5dW1hd29ya3MuY29tPC9h
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJn
ZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+YW5keUB5dW1hd29ya3MuY29t
PC9hPiZndDsmZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBIaSw8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBUaGUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0ZXJtICJkYXRhIG5vZGUiIGlzDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNl
ZCBpbiB0aGUgZG9jdW1lbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0byByZWZlciB0byB0aGUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0b3AtbGV2ZWwgbm9kZTxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsgb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3BlY2lmaWVkIG9iamVjdCwNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3QgdGhlIGVudGlyZQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1YnRyZWUg
KGlmIGFueSkuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhlDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGF0YS1ydWxl
IC9mb28gZG9lcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG5vdCBtYXRjaA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC9mb28vY2hpbGQxIGluIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRleHQgYmVsb3cuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyBUaGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjaGlsZCBub2RlcyBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbWl0dGVkIGJlY2F1c2Ugb2YNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGVwIDEx
Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDsgVGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYWRtaW4gaGFzIHRvDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhwbGljaXRseSBwZXJtaXQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmRp
dmlkdWFsIGNoaWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbm9kZXMgKG9yIG1vZHVsZXMpLjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgVGhpcw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNl
ZW1zIGNvcnJlY3QgaWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgcmVhZC1kZWZhdWx0IGlzDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImRlbnkiLjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7IFNob3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGFueSB0ZXh0IGJlIGFkZGVkIG9yDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhbmdlZCB0
byBtYWtlIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBtb3JlIGNsZWFyPzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyBJIHdvdWxk
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
YWdyZWUgd2l0aCBSb2JlcnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0aGF0IGl0IHdhcyBub3QNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnRpcmVseSBjbGVhciB0aGF0DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVs
ZSBhcHBsaWVkIG9uIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHBhcmVudCBkYXRhLW5vZGUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2VzIG5vdCBhcHBseSB0bw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBj
aGlsZCBub2Rlcy4gU28NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB5ZXMsIGl0IHdvdWxkIGhlbHANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBjbGFyaWZ5IGl0Ljxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
IFdlIHNob3VsZCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRvaW5nIG1vcmUgdGhhbg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsYXJpZnlpbmcgaXQuwqAgV2UNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuZWVkIHRv
IGZpeCBpdCBzbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRoYXQgaXQgd29ya3MgaW4gYQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbnNpYmxlIHdheS7CoCBJLmUuDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gbWFr
ZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBub3JtYXRpdmUgdGV4dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnNpc3RlbnQgd2l0aCB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWhhdmlvdXIgY3VycmVu
dGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZGVzY3JpYmVkIGluIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4YW1wbGVzIGluPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFwcGVuZGl4DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQi40
Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsgSWYgd2UgZm9sbG93DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5keSdzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24gdGhh
dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGEgZGF0YSBydWxlIGRvZXNuJ3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBtYXRjaCBjaGlsZCBub2Rlcw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gdGhvc2UgZXhhbXBs
ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhcmUgY29tcGxldGVseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHdyb25nLsKgIEUuZy4gdGhlIDR0aA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGUgaXMgZGVzY3JpYmVk
IGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIlRoaXMgcnVsZSBnaXZlcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAnYWRtaW4nIGdyb3VwDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhZC13cml0ZTxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
IGFjY2VzcyB0byBhbGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBhY21lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmx0O2ludGVyZmFjZSZndDsNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnRyaWVzLiLCoCBCdXQgSWYN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0
aGUgcGF0aCBvbmx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3RyaWN0bHkgbWF0Y2hlcw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvYWNtZTppbnRlcmZhY2VzL2FjbWU6aW50
ZXJmYTx3YnI+Y2UiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhlbiB0aGUgYWRtaW4gZ3JvdXANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlIGFjaGlldmVzDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90aGluZyB1
c2VmdWwgYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBhbGwuwqAgVGhlIGFkbWluIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IGV2ZW48YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBhbGxvd2VkIHRv
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y3JlYXRlIGFuIGludGVyZmFjZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGJlY2F1c2UgdGhleSB3b3VsZA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBldmVuIGhhdmUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZXJt
aXNzaW9uIHRvIHdyaXRlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdG8gdGhlIGxpc3Qga2V5DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ25hbWUnIG5vZGUgcmVxdWlyZWQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBj
cmVhdGUgYSBsaXN0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZW50cnkhwqAgSW5zdGVhZCwgYQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcGFyYXRlIHJ1bGUgd291bGQNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBy
ZXF1aXJlZCBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBldmVyeTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7IHNpbmdsZSBwb3NzaWJsZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNjaGVtYSBub2RlIHVu
ZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIi9hY21lOmludGVyZmFjZXMvYWNtZTppbnRlcmZhPHdicj5jZSIhwqANCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIHRo
YXQgdGhpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG1ha2VzICJwZXJtaXQiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZGF0YS1ub2RlIHJ1bGVzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGxldGVseSB1bnVzYWJs
ZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEkgc3Ryb25nbHkgYWdyZWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIHRoaXMsIGFuZCBJDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd291bGQgc2F5IHRo
YXQgaXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpc24ndCBvbmx5IHRoZSBjYXNlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvciAicGVybWl0IiBydWxlcyAtDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZS5nLiBk
ZW55aW5nIHNvbWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBhY2Nlc3MgdG8gYSBzdWJ0cmVlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGRhdGE8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZWwgdGhh
dCB3b3VsZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIG90aGVyd2lzZSBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHBlcm1pdHRlZCBkdWUgdG8NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0cyBpcyBhdCBsZWFz
dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGFzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGNvbW1vbiwgYW5kIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJ1bGVzIHdvdWxkIGJlIGp1c3QNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcyB1bnVzYWJsZSBm
b3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0aGF0Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgQmVzaWRlcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBleGFtcGxlcywgSSB0aGluaw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgdGhlIHZl
cnkgdXNlIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdGhlIHRlcm0gIm1hdGNoIiw8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhvdWdoIHVuZm9ydHVuYXRlbHkNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3Qg
ZGVmaW5lZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBzdHJvbmdseSBzdWdnZXN0cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgaXQgaXMgc29tZXRoaW5nPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVy
IHRoYW4gdXNlIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZS5nLiB0aGUgdGVybQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICJpZGVudGlmeSIgd291bGQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbXBseS4gQWRkaXRp
b25hbGx5LDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0aGlzIHRleHQgaW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gb2YgdGhlDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ3BhdGgnIGxl
YWYgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBjb25zaXN0ZW50IHdpdGggdGhlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIGJlaW5nIGEgcHJlZml4DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0Y2g6
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICDCoCDCoCDCoCDCoFRoZSBzcGVjaWFsDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdmFsdWUgJy8nIHJlZmVycyB0bw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCBw
b3NzaWJsZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCDCoGRhdGFzdG9yZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRlbnRzLiI7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGV0lX
LCBvdXIgTkFDTQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGltcGxlbWVudGF0aW9uLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGF2YWlsYWJsZSB0byAoYW5kDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNlZCBieSkgY3Vz
dG9tZXJzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHNpbmNlIDIwMTIsIGZvbGxvd3MNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgcHJlZml4IG1hdGNoDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbG9naWMsIGFu
ZCBJIGhhdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB5ZXQgdG8gaGVhciBvZjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBhbnkgdXNlciBleHBlY3RpbmcNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpdCB0byBkbyBv
dGhlcndpc2UuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAmZ3Q7IFRvIGZpeCB0aGlzDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvcGVybHksIHdlIG5lZWQgdG8N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt
YWtlIHRoZSBkYXRhLW5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBwYXRoIHJ1bGUgYSBwcmVmaXgNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaC7CoCBJbg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcnRpY3Vs
YXIsIHdlIG5lZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0ZXh0IHRoYXQgc3BlY2lmaWVzOjxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgKGkpIHRo
YXQgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGRhdGEtbm9kZSBwYXRoIG1hdGNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgc3VjY2VlZHMgaWYgaXQNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtYXRjaGVzIHRoZSBwYXRo
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
cHJlZml4IGZyb20gdGhlIHJvb3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBvZiB0aGUgdHJlZS7CoCBJLmUuDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc28gdGhlIGRhdGEtcnVs
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICIvZm9vIiBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIi9mb28iIGFuZCBhbGwgb2YNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb28ncyBkZXNjZW5kYW50DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hpbGRy
ZW4gbm9kZXMuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBTdHJvbmdseSBhZ3JlZS48YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2PkkgZG8gbm90IHNlZSBob3cNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdGV4dCBjYW4gYmUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnRlcnByZXRlZCB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgd2F5LjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQmVjYXVzZSBvdGhlcndpc2UgdGhlIHBhdGgNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hdGNoIHBhcnQgb2YgdGhlIE5BQ00NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNvbHV0aW9uIGlzIHJl
YWxseSBicm9rZW4sIGFuZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdGhlIHBhdGggYmFzZWQgZXhhbXBsZXMgaW4gdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBhcHBlbmRpeCBhcmUgZW50aXJlbHkNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pc2xlYWRpbmcgYW5kIHdy
b25nLsKgIFRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
b25seSB3YXkgdGhvc2UgZXhhbXBsZXMgbWFrZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2Vuc2UgaXMgdGhlIHBhdGhzIG1hdGNoDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNjZW5kYW50IGNoaWxkcmVuIG5v
ZGVzIGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3ZWxs
Ljxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdj5JTU8gdGhlIHRleHQgZG9lcyBub3Qgc3VwcG9ydA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgaW50ZXJwcmV0YXRpb24uPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Js
b2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgZXhhbXBsZXMg
aW4gQi40LCBhbmQgdGhlIGRlZmluaXRpb24gb2YNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICIvIiBtYXRjaGluZyBhbGwgbm9kZXMgc3VwcG9ydHMgdGhpcw0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24uPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
SGVuY2UsIG15IG9waW5pb24gaXMgdGhhdCBpdCBpcyB0aGUgdGV4dA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW4gMy40LjUgdGhhdCBpcyBpbmNvcnJlY3RseSBzcGVjaWZp
ZWQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgdGhhdCB0aGUgZXhhbXBs
ZXMsIGRlZmluaXRpb24gb2YgIi8iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh
bmQgc3RhbmRhcmQgcHJhY3RpY2UgYXJlIHJpZ2h0Ljxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE90aGVy
d2lzZSwgaG93IGRpZCBJRVRGIG1hbmFnZSB0byBwdWJsaXNoDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBhbiBSRkMgd2hlcmUgdGhlIHBhdGggYmFzZWQgZXhhbXBsZXMgYXJl
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzbyBjb21wbGV0ZWx5IHdyb25nP8Kg
wqAgV2hvZXZlciB3cm90ZSBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl
dmlld2VkIHRob3NlIGV4YW1wbGVzIGNsZWFybHkgaGFkIGENCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbiBvZiBob3cgdGhlc2UgcGF0
aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFzZWQgQUNMcyB3b3JrZWQuIDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlcmUgaXMgbm90aGluZyBzYWlkIGFib3V0DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5oZXJpdGluZyBzdGF0
ZSBmcm9tIHRoZSBwYXJlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBkYXRhIG5vZGUuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxkaXY+SSB0aGluayBubyBtYXR0ZXIgaG93IHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHBlcm1pc3Npb25zIGFyZSBkZXJpdmVkLCBvbmUg
Y2FuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+
ZmluZCBleGFtcGxlcyB0aGF0IHdvcmsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBiZXR0ZXIgb3Igd29yc2UgYmVjYXVzZSBvZiBpdC48L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90
ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vLsKgIElmIHRoZSBydWxlcyBh
cHBseSB0byBkZXNjZW5kYW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGls
ZHJlbiwgYWxsIG5vcm1hbCBleGFtcGxlcyB3b3JrIHdlbGwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChpbmNsdWRpbmcgdGhlIG9uZXMgaW4gdGhlIGFwcGVuZGl4KS48YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
diBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA8ZGl2PklNTyB0aGUgbnVtYmVyIG9mIHJ1bGVzDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWlyZWQgdG8gaW1wbGVtZW50
IGEgdXNlLWNhc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
cyBub3Q8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
dj52ZXJ5IHJlbGV2YW50IG9yIG9iamVjdGl2ZQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNyaXRlcmlhLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgWWVzIGl0IGlzLCBwYXJ0aWN1bGFybHkgd2hlbiB0aGUNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpZmZlcmVuY2UgaXMgYmV0d2VlbiBuZWVk
aW5nIGEgMSBsaW5lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlLCBhbmQg
YSAxMDArIGxpbmUgcnVsZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxf
ZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VXNpbmcg
dGhlIHByZXZpb3VzIGV4YW1wbGUgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAvaG9tZSBhbmQgL2hvbWUvdXNlcjEsPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+aWYgdGhlIHVzZXIxIGlzIGdpdmVuIHJl
YWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY2Nlc3MgdG8g
L2hvbWUsIHRoZW4gKGFjY29yZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRvIHlvdSk8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdj5pdCBhbHNvIGhhcyByZWFkIGFjY2VzcyB0bw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV2ZXJ5IHVzZXIgc3VidHJlZSB1bmRlciAv
aG9tZS48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+SW5zdGVhZCBvZiAxIHJ1bGUgcGVyIHVzZXIsIDIN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlcyBhcmUgbmVl
ZGVkPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBObywg
anVzdCAxIHJ1bGUgcGVyIHVzZXI6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqDCoCByZWFkLWRlZmF1bHQ9ZGVueTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgwqAgZ3JvdXA9dXNlcjEsIHBhdGg9L2hvbWUvdXNlcjEsDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBhY3Rpb249cGVybWl0PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhp
cyBpcyBiZWNhdXNlIG9mIG15IHR3byBwcm9wb3NlZA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgY2hhbmdlczo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaSkgdGhhdCBhIGRhdGEtbm9k
ZSBwYXRoIG1hdGNoIHN1Y2NlZWRzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
ZiBpdCBtYXRjaGVzIHRoZSBwYXRoIHByZWZpeCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcm9vdCBvZiB0aGUgdHJlZS7CoCBJLmUuIHNvIHRoZSBkYXRhLXJ1
bGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIvZm9vIiBtYXRjaGVzICIvZm9v
IiBhbmQgYWxsIG9mIGZvbydzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNj
ZW5kYW50IGNoaWxkcmVuIG5vZGVzLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZsdDstIFRoaXMgbWVhbnMgdGhhdCB5b3Ugb25seSBuZWVkIDENCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGVudHJ5IGluc3RlYWQgb2YgMTAwIGVudHJpZXMuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKGlpKSBpZiBhIGRhdGEtbm9kZSBydWxlIGhhcyBhY3Rpb24NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICJwZXJtaXQiIHRoZW4gaXQgaW1wbGljaXRseSBh
bGxvd3MgcmVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXNzIGZvciBh
bGwgYW5jZXN0b3IgcGFyZW50IG5vZGVzIHVwIHRvDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0aGUgcm9vdC7CoCAoSS5lLiB0byBtaXRpZ2F0ZSB0aGUgb3JpZ2luYWwNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5nZSBwcm9wb3NlZCBvbiB0aGlzIHRo
cmVhZC4pPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy0gVGhpcyBt
ZWFucyB0aGF0IHlvdSBkb24ndCBuZWVkIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHNlcGFyYXRlIHJlYWQgcnVsZSBmb3IgIi9ob21lIi7CoCBSZWFkDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBhY2Nlc3MgdG8gdGhhdCBub2RlIGl0IGlzIGltcGxpY2l0
bHkgZ2l2ZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZpYSAiZ3JvdXA9dXNl
cjEsIHBhdGg9L2hvbWUvdXNlcjEsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh
Y3Rpb249cGVybWl0IiwgaGVuY2UgbWVhbmluZyB0aGF0IHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcnVsZSB3b3JrcyB0aGUgc2FtZSB3YXkgYXMgaXQgZG9lcyBvbiBh
bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmZjNjUzNiBjb21wbGlhbnQgaW1w
bGVtZW50YXRpb24uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh
Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9Imdt
YWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
dj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgcmVhZC1k
ZWZhdWx0PWRlbnk8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGRpdj7CoCDCoGdyb3VwPSosIHBhdGg9L2hvbWUsDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgIMKgZ3JvdXA9dXNlcjEsDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aD0vaG9tZS91c2VyMSwg
YWN0aW9uPXBlcm1pdDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+VGhl
IGFib3ZlIHJ1bGVzIHdvdWxkIGFsbG93DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYWNjZXNzIGZvciBldmVyeSB1c2VyIHRvIGV2ZXJ5DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3RoZXIgdXNlci48L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5UaGUgMm5kIHJ1bGUgaGFz
IG5vIGVmZmVjdCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3
aGljaCBpcyBjb3VudGVyLWludHVpdGl2ZS48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdj5FdmVyeSB1c2VyIGRpciB3b3VsZCBuZWVkIDINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBydWxlczwvZGl2Pg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGRpdj7CoCDCoHJlYWQtZGVmYXVsdD1kZW55PC9kaXY+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoGdyb3VwPSos
IHBhdGg9L2hvbWUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBhY3Rpb249cGVybWl0PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdj7CoCDCoGdyb3VwPXVzZXIxLA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgcGF0aD0vaG9tZS91c2VyMSwNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlvbj1wZXJtaXQ8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqBncm91cD0qLCBwYXRoPS9ob21l
L3VzZXIxLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjdGlv
bj1kZW55PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf
cXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9
Im1hcmdpbjowcHggMHB4IDBweA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl
eCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBiZ2Nv
bG9yPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2
IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+VGhlcmUgaXMgbm90aGluZw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgc2F5cyB0aGlz
IGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaG93IGl0IHdvcmtzLjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2PklmIGl0IGRpZCwgb25jZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvdWxkIG5ldmVyIGhh
dmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBwcml2aWxlZ2VkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgc3ViLWZpb2xkZXJzPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj7CoCDCoCDCoC92
YXIvbG9nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLSZndDsgcGVybWl0PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+wqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC92YXIvbG9nL2FwYWNoZTINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoC0m
Z3Q7IGRlbnk8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFllcywgeW91IGNhbiwgeW91IGp1c3QgbGlzdA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgdGhlIGxvbmdlc3QgcGF0aCBmaXJzdCBpbiB0aGUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpc3Qgb2YgcnVsZXM6PGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAoMSnCoCAvdmFyL2xv
Zy9hcGFjaGUyIMKgLSZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGRlbnk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICDCoCAoMikgL3Zhci9sb2cgLSZndDsgcGVybWl0PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgQW55IHJlcXVlc3RzIHRoYXQgYXR0ZW1wdCB0bw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXNzIGFueXRoaW5n
IHVuZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvdmFy
L2xvZy9hcGFjaGUyIHdvdWxkIG1hdGNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBydWxlICgxKSBhbmQgYmUgZGVuaWVkLjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFueSByZXF1ZXN0cyB0aGF0IGF0dGVt
cHQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjY2Vz
cyBhbnl0aGluZyB1bmRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgL3Zhci9sb2csIGJ1dCBub3QgdW5kZXINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC92YXIvbG9nL2FwYWNoZTIsIHdvdWxkIGZhaWwNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIG1hdGNoIHJ1bGUgKDEp
LCBidXQgd291bGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1hdGNoIHJ1bGUgKDIpIGluc3RlYWQgYW5kIGJlDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBwZXJtaXR0ZWQuPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDxkaXY+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp
dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5JIGRvIG5v
dCBzZWUgYW55IHRleHQgaW4gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgZHJhZnQgb3IgUkZDIDc5NTAgdGhhdDwvZGl2Pg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PnN1Z2dlc3RzIHRoYXQgL3Zhci9sb2cgYW5k
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL3Zhci9sb2cvYXBh
Y2hlMiByZXByZXNlbnQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc2FtZSBkYXRhIG5vZGUuPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBUaGV5IGFyZSBkaWZmZXJlbnQgZGF0YSBub2RlcywgYnV0IEkgZG9u
J3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlZSBob3cgdGhhdCBpcyByZWxl
dmFudC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgUm9iPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDxkaXY+QW5keTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXY+wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJs
b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHggc29s
aWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZ2IoMjA0LDIw
NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0
ciI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRp
diBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk
aXY+wqA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA8YmxvY2txdW90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNsYXNzPSJnbWFpbF9xdW90ZSINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0ibWFyZ2lu
OjBweA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDBweCAwcHgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDoxcHgNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzb2xpZA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJnYigyMDQsMjA0LDIwNCk7
cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyAoaWkpIGlmIGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhLW5vZGUgcnVsZSBoYXMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY3Rp
b24gInBlcm1pdCIgdGhlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGl0IGltcGxpY2l0bHkgYWxsb3dzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhZCBhY2Nlc3MgZm9yIGFs
bA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGFuY2VzdG9yIHBhcmVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIG5vZGVzIHVwIHRvIHRoZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJvb3QuwqAgKEkuZS4gdG8NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtaXRpZ2F0
ZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBvcmlnaW5hbCBjaGFuZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBwcm9wb3NlZCBvbiB0aGlzDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhyZWFkLik8YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo
aXMgc2VlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICByZWFzb25hYmxlIHRvIG1lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGFsdGhvdWdoIEkgaGF2ZW4ndA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0IHRoaXMgcG9p
bnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBldmFsdWF0ZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGhlIHN1Z2dlc3Rpb24gaW4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXRhaWwuIEluIGFueSBjYXNlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSB0
aGluayB0aGUgbWFpbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHBvaW50IGJvdGg8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnYXJkaW5nIHRoaXMgYW5kDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHByZWZp
eCBtYXRjaCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRoYXQgdGhpcyB1cGRhdGUgdG8NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2NTM2IGNhbid0PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1ha2UgcmFkaWNh
bCBjaGFuZ2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdG8gdGhlIHNlbWFudGljcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBhcmVkIHRvIGENCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAicmVhc29uYWJsZTxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp
bnRlcnByZXRhdGlvbiINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoaGFyZCB0byBkZWZpbmUsIEkNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBrbm93KSBvZiB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bmRlci1zcGVj
aWZpZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgb3JpZ2luYWwuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj5UaGUgdGV4
dCBkb2VzIG5vdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHNheSB0aGlzIGF0IGFsbCBzbyBJDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG8gbm90IGFwcHJvdmUgb2YNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIGNo
YW5nZTwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW4g
dGhlIFJGQyB2ZXJzaW9uIG9mIHRoZSBOQUNNDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0aGlzIHdhc24ndCByZXF1aXJlZCBiZWNhdXNlDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGVyYXRpb24gJ25vbmUnIGRp
ZG4ndA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWly
ZSByZWFkIGFjY2Vzcy7CoCBOb3cgcmVhZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYWNjZXNzIGlzIHJlcXVpcmVkIGV2ZW4gZm9yDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGVyYXRpb24gJ25vbmUnLCB0aGVu
IHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5n
ZSBtYWtlcyBzZW5zZSB0byBtYWtlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgTkFDTSBjaGFuZ2VzIGJhY2t3YXJkcw0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSwgd2hpbHN0IHN0aWxsDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbG9zaW5nIHRoZSBz
ZWN1cml0eSBob2xlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBSb2I8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2tx
dW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21h
aWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDxkaXY+wqA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjbGFzcz0iZ21haWxf
cXVvdGUiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgc3R5bGU9Im1hcmdpbjowcHgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwcHggMHB4DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc29s
aWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLVBlcjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv
YmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+QW5keTwvZGl2Pg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2PsKgPC9k
aXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDxibG9ja3F1b3RlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgY2xhc3M9ImdtYWlsX3F1b3RlIg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW46MHB4DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHB4IDBw
eA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDAuOGV4O2JvcmRlci1sZWZ0OjFweA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHNvbGlkDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl
ZnQ6MWV4Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7IFRoYW5rcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBSb2I8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7IFRoYW5rczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8
YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyBBbmR5PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IE9uIFRodSwNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3YgOSwgMjAxNyBhdCAy
OjQ0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQU0sIFJvYmVydCBXaWx0b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2Nv
LmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5yd2lsdG9u
QGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNj
by5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cndpbHRv
bkBjaXNjby5jb208L2E+Jmd0OyZndDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0O8KgIMKgIMKgSGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBBbmR5LDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqBJdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGlzbid0IGNsZWFyIHRvIG1lDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hldGhlciBtYXRjaGluZyBhDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGF0aCBpbiBO
QUNNIGVpdGhlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoChpKSBPbmx5IGFwcGxpZXMg
dG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0aGUgc3BlY2lmaWMgbm9kZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBhbmQgbm90IGFueQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoaWxkcmVuLCBvcjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDvCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgKGlpKSBBcHBsaWVzIHRvIHRoZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljIG5vZGUgYW5kDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxs
IGRlc2NlbmRhbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBjaGlsZHJlbiBub2RlcyBhcw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlbGwuPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7Jmd0OyZndDvCoCDCoCDCoEFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgYW4gZXhhbXBsZSwgdXNpbmcNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdHJlZSBiZWxvdy7C
oCBpZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIEkgaGF2ZSBhIHJ1bGUgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1hdGNoZXMgcGF0aCAiQS9CIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4gZG9lcyB0aGF0
IGFwcGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdG8gb25seSB0aGUgc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBub2RlICJBL0IiLCBvciBkb2VzDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXQgYWxzbyBh
cHBseSB0byBhbGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkZXNjZW5kYW50IGNoaWxkcmVuDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgIkEvQiIgYXM8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICDCoHdlbGw/PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDC
oEluDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgcmZjNjUzNmJpcy0wOCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzZWN0aW9uICIzLjQuNS7CoA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdGEgTm9kZSBBY2Nlc3MNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWxp
ZGF0aW9uIiwgc3RlcCA2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3RhdGVzOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCrCoCBUaGUgcnVsZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXMgbm90IGhhdmUgYQ0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJydWxlLXR5
cGUiIGRlZmluZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBvciB0aGUgInJ1bGUtPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAg
wqAgwqAgwqAgdHlwZSIgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAiZGF0YS1ub2RlIiBhbmQgdGhlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiJwYXRoIiBtYXRjaGVzIHRo
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHJlcXVlc3RlZCBkYXRhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbm9kZSosIGFjdGlvbiBub2RlLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9yIG5vdGlmaWNhdGlvbg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUu
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAg
wqBNeQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHJlYWRpbmcgb2YgdGhpcyBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRoYXQgaXQgaW1wbGllcyB0aGF0DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGludGVycHJl
dGF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgb2YgdGhlIHBhdGggcnVsZSBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIChpKSwgYnV0IHRoaXMgaXMgbm90DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaG93IEkgd291
bGQgbm9ybWFsbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBleHBlY3QgYW4gQUNMIHJ1bGUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhcHBseSBpbiBhIHRyZWUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWtlIG9i
amVjdCAoZS5nIGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBkaXJlY3Rvcnk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoGZpbGUgc3lzdGVt
KS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBIb3dldmVyLCB0aGUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBl
eGFtcGxlcyBpbiBBcHBlbmRpeA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEIuNC4gaW1wbHkgdGhhdCB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXRoIHJ1bGUgaXMgdG8g
YmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnRlcnByZXRlZCBsaWtlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKGlpKSwgb3Igb3RoZXJ3aXNlDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGV4YW1wbGUgcnVsZXMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
ZWVtIHRvIGJlIG1vc3RseQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHBvaW50bGVzcy48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgwqBFLmcuIHRha2luZyB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhhbXBsZSBmcm9tDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXBwZW5kaXggQi40Ojxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCAmbHQ7cnVs
ZSZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDtuYW1lJmd0O3Bl
cm1pdC1kdW1teS1pbnRlcmZhY2UmbHQ7Lzx3YnI+bmFtZSZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCAmbHQ7cGF0aA0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmFjbWU9IjxhDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRw
Oi8vZXhhbXBsZS5jb20vbnMvaXRmIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxh
bmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHA6Ly9leGFtcGxlLmNvbTx3YnI+L25z
L2l0ZjwvYT4iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvaXRmIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVs
PSJub3JlZmVycmVyIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUi
Pmh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pdGY8L2E+Jmd0OyZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC9hY21lOmludGVyZmFjZXMvYWNtZTppbnRlcmZhYzx3
YnI+ZVthY21lOm5hbWU9J2R1bW15J108YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDC
oCDCoCAmbHQ7L3BhdGgmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
bHQ7YWNjZXNzLW9wZXJhdGlvbnMmZ3Q7cmVhZA0KdXBkYXRlJmx0Oy9hY2Nlc3Mtb3BlcmF0
aW9ucyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZsdDthY3Rpb24m
Z3Q7cGVybWl0Jmx0Oy9hY3Rpb24mZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAg
wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmbHQ7Y29tbWVudCZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDC
oCDCoCBBbGxvdyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBsaW1pdGVkIGFuZCBndWVzdA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdyb3VwcyByZWFkPGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgYW5kIHVwZGF0ZQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFjY2VzcyB0byB0aGUgZHVt
bXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnRlcmZhY2UuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L2Nv
bW1lbnQmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgJmx0Oy9ydWxlJmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKg
IMKgSWYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0aGUgcnVsZSBpcyAoaSnCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHRoZW4gdGhlIGFjY2VzcyBydWxlDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxsb3dzIHRoZSBj
bGllbnQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICByZWFkIHRoZSBzcGVjaWZpYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiL2FjbWU6aW50ZXJmYWNlcy9hY21lOmlu
dGVyZmE8d2JyPmNlW2FjbWU6bmFtZT0nZHVtbXknXSINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBidXQgbm90IGFueSBjaGlsZA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxlYWZz
L2NvbnRhaW5lcnMgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0aGF0IGludGVyZmFjZSw8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7wqAgwqANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoHRo
aXMgZG9lc24ndCBzZWVtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdXNlZnVsLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICDCoEZ1cnRoZXIgY29tbWVudHMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBpbmxpbmUgYmVsb3cgLi4uPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoE9uDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgMDgvMTEvMjAxNyAyMDowNSwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbmR5IEJpZXJt
YW4gd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgSGksPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBUaGlzIGNoYW5nZSBoYXMgbm8NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbXBh
Y3Qgb24gdGhlIHNlcnZlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGlmDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgL25hY20vcmVhZC1kZWZhdWx0DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgInBlcm1pdCIuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIMKgSW4gdGhhdCBjYXNlLCB0aGUNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHRyYSByZWFkIHJ1bGVz
IGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC9BIGFuZCAvQS9CIGFyZSBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBuZWVkZWQuPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKg
SQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGFncmVlLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBBbiBv
cGVyYXRvciB3b3JyaWVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYWJvdXQgcmVhZCBhY2Nlc3MNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaG91bGQgc2V0DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhZC1kZWZhdWx0
IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgImRlbnkiLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoEkNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhZ3JlZS7CoCBUaGlzIGlzIHRo
ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHNjZW5hcmlvIHRoYXQgSSdtDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY29uc2lkZXJpbmcuPGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoEluIHRoYXQgY2FzZSwNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHBsaWNpdCBydWxlcyB0bw0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWQg
L0EgYW5kIC9BL0INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB3b3VsZCBiZSBuZWVkZWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBp
biB0aGUgbmV3IE5BQ00uPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqBZZXMsIGlmIHRoZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVy
cHJldGF0aW9uIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhlIHJ1bGUgaXMgKGkpDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJvdmUuPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKg
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
wqBPdGhlcndpc2UgaWYgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaW50ZXJwcmV0YXRpb24gaXMNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaWkpIHRoZW4geW91IG9ubHkN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBu
ZWVkICJyZWFkIC9BIiBzaW5jZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHRoYXQgaW1wbGllcyAicmVhZA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEvQiIgYXMgd2VsbCAoYXMN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs
b25nIGFzIHRoZSBydWxlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGFyZSBsaXN0ZWQgaW4gdGhlDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29ycmVjdCBvcmRlcikuPGJyPg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn
dDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAg
wqBUaGUgZGVueSBydWxlcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHdvdWxkIG5vdCBiZSBuZWVkZWQuPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0O8Kg
IMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqBPbmx5IGlmIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGludGVycHJldGF0aW9uIG9mDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHJ1bGUgaXMgKGkpDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWJvdmUu
wqAgSW4gd2hpY2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBjYXNlIHRoZcKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgInJlYWQvd3JpdGUgJ0EvQi9KJw0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJ1bGUgd291bGQgbm90
IGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3VmZmljaWVudC7CoCBJdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHdvdWxkIGJlIG5lY2Vzc2FyeQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBhbiBYcGF0
aA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGV4cHJlc3Npb25zIHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBjb250YWluczxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoGFsbA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNo
aWxkcmVuIG5vZGVzIGFzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgd2VsbC7CoCBQZXJoYXBzDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ0EvQi9KLy8qJz88YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICZndDsmZ3Q7Jmd0O8KgIMKgIMKgSWYNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgaW50ZXJwcmV0YXRpb24NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiB0aGUg
cnVsZSBpcyAoaWkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGhlbiB5b3Ugd291bGQgYWxzbw0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWQgYWxsIHRoZQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0IGRl
bnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdGF0ZW1lbnRzIGFzIHdlbGwsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgb3RoZXJ3aXNlIHRoZXkgd291bGQNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZSBhbGxvd2VkIGJ5
IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICJyZWFkIC9BIiBydWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgYWJvdmUuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDvCoCDCoCDCoFJvYjxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoEFuZHk8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgT24g
V2VkLCBOb3YgOCwgMjAxNw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGF0IDg6MzMgQU0sIFJvYmVydA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdpbHRvbiAmbHQ7PGENCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9
Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSINCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4NCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxhDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVm
PSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyZndDsNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoEhpLDxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIMKgSSdt
IG5vdCBzdXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgYWJvdXQgdGhpcyBjaGFuZ2UuPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqAgwqAgwqBJJ20gbm90IHRoYXQNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmYW1pbGlhciB3aXRoIE5B
Q00sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYnV0IGlmIHlvdSB3YW50IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZ2l2ZSBhIHBhcnRpY3VsYXINCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXQgb2YgdXNlcnMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWFk
L3dyaXRlIGFjY2VzcyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGEgc3VidHJlZSwgYnV0IG5vdA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbG93IHRoZW0gdG8gaGF2ZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFu
eSBvdGhlciBhY2Nlc3MgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB0aGUgY29uZmlndXJhdGlvbiBpbg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZTxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoHJ1bm5pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhc3RvcmUgdGhlbiB3aXRoDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGV4aXN0
aW5nIFJGQywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB0aGF0IGNvdWxkIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZXhwcmVzc2VkIHdpdGggYQ0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpbmdsZSBydWxlIChleGFt
cGxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaW4gNjUzNmJpcywgYXBwZW5kaXgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBCLjQpPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqAgwqAgwqBXaXRoIHRoaXMgbmV3DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhbmdlLCBJIHRoaW5r
IHRoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB5b3UgbWF5IG5lZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25maWd1cmUgbWFueSBtb3JlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZXMgdG8gYWNoaWV2
ZSB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBzYW1lIHRoaW5nLsKgIEkgdGhpbmsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHlvdSB3b3VsZCBuZWVkDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gZ2l2ZSBy
ZWFkIGFjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRvIHRoZSB0b3Agbm9kZSBpbg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBkZXNpcmVkPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgIMKgIMKgcGF0aCwgYW5kIHRoZW4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzZXBhcmF0ZSBleHBsaWNpdA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJkZW55
IiBydWxlcyBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBldmVyeSBzaWJsaW5nIGNoaWxkDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9kZSB3YWxraW5nIGZyb20NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdG9w
IG9mIHRoZSB0cmVlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgZG93biB0byB0aGUgZGF0YQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vZGUgdGhhdCByZWFkL3dyaXRlDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXNz
IGlzIGFjdHVhbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgYmVpbmcgZ2l2ZW4gdG8uwqAgVGhlPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvC
oCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIMKgIMKgIMKgZXhhbXBsZSBiZWxvdw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIG1heSBleHBsYWluIG15DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5kZXJzdGFuZGluZw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJl
dHRlcjo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDC
oCDCoEUuZy4gRm9yIGEgdHJlZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIG9mIGRhdGEgbm9kZXMsDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcm9vdGVkIGF0IEEsIGlmIHdlDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2Fu
dGVkIHRvIGdpdmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICByZWFkL3dyaXRlIGFjY2Vzcw0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9ubHkgdG8gIkoiIHN1YnRyZWUsDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIG5v
IGFjY2VzcyBmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0aGUgcmVzdCBvZiB0aGUgdHJlZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW46PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICDCoCBBPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgwqAgfDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKg
LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAg
wqAgwqAgwqAgwqB8wqAgwqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8wqAgwqAgwqB8wqAgwqAgwqB8PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQsKgIMKgIMKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ8KgIMKgIMKgRMKgIMKg
IMKgRTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgLS0tLS0tLS0tLS08YnI+DQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZn
dDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgfMKgIMKgfMKgIHzCoCB8PGJyPg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7
Jmd0OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIMKgIMKgIMKgIMKgIEbCoCDCoEfCoCBIwqAgSjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgLi4uPGJyPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDC
oCDCoEluIHRoZSBvbGQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBtb2RlbCwgSSB0aGluayB0aGF0DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIEFDTCBydWxlcyB3b3VsZA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJl
IDEgcnVsZXMgbG9uZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChhc3N1bWluZyBkZWZhdWx0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVueSBhbGwpOjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCDCoCAicmVhZC93cml0ZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdBL0IvSic8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoEluIHRoZSBuZXcNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2Rl
bCwgSSB0aGluayB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgdGhlIGVxdWl2YWxlbnQgQUNMDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnVsZXMgd291bGQgbmVlZCB0bw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJl
IDggcnVsZXMgbG9uZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChhc3N1bWluZyBkZWZhdWx0DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVueSBhbGwpOjxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICDCoCDCoCDCoCDCoCAicmVhZC93cml0ZQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdBL0IvSic8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqAgwqAgwqAgwqAgInJlYWQgQSI8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqAgwqAgwqAgwqAgImRlbnkgQyI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAg
wqAgwqAgImRlbnkgRCI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgImRl
bnkgRSI8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgImRlbnkgRiI8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgwqAgwqAgwqAgwqAgImRlbnkgRyI8YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsm
Z3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgwqAgwqAgwqAgwqAgImRlbnkgSCI8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoE5vdGUsIEkgYW0NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhc3N1bWluZyB0aGF0
IGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAicGF0aCIgcnVsZSBtYXRjaGVzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZm9yIHRoZSBnaXZlbiBwYXRoDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIGFsbCBkZXNjZW5k
YW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbm9kZXMuwqAgVGhlIGRyYWZ0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZG9lc24ndCBzZWVtIHRvIGJlDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFydGljdWxhcmx5IGNs
ZWFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgb24gdGhpcyBwb2ludCAoaXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBzdGF0ZXMgdGhhdCB0aGUgcnVsZQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFwcGxpZXM8YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDsmZ3Q7Jmd0O8KgIMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgwqAgwqAgwqB3aGVuIHRoZSBwYXRoDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0Y2hlcywgYnV0IHRo
aXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB3b3VsZCBzZWVtIHRvIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgY291bnRlciBpbnR1aXRpdmUpLA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBwZXJoYXBzIGl0IGNv
dWxkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYmUgY2xhcmlmaWVkLjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn
dDvCoCDCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIMKgIMKgIMKgSWYgdGhpcyBjaGFuZ2UNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBhbGxvd2VkLCB0aGVuIHRoZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4YW1w
bGUgaW4gYXBwZW5kaXgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBCLjQgbG9va3MgbGlrZSBpdA0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdvdWxkIG5lZWQgdG8gYmUNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaXhlZCwg
c2luY2UgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgImxpbWl0ZWQtYWNsIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHByb2JhYmx5IHdvdWxkbid0DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2l2ZSBhbnkgYWNjZXNz
IGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgYWxsLCB1bmxlc3MgZGVmYXVsdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHJlYWQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8KgIMKgDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgwqAg
wqAgwqBhY2Nlc3MgaGFkIGJlZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBnaXZlbi48YnI+DQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICDCoCDCoCDCoEJ1dCwgcG9zc2libHkNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJJ20gbWlzdW5kZXJzdGFu
ZGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGhvdyB0aGlzIGFsbCB3b3JrcyHCoA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIElmIHNvLCBhcG9sb2dpZXMgZm9yDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIG5vaXNl
IDotKTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDvCoCDCoA0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgIMKg
IMKgVGhhbmtzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoCDCoCDCoFJvYjxicj4NCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7
Jmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0O8Kg
IMKgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgwqAgwqAgwqBPbiAwMi8xMS8yMDE3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgMTQ6MTgsIEJlbm9pdCBDbGFpc2UNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgRGVhciBhbGwsPGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDC
oEhlcmUgaXMgYSBtYWpvciBjaGFuZ2UgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJp
cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdWdnZXN0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgU2VjdXJpdHkgQUQgRXJpYw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlc2NvbGEgcGFydCBvZiB0aGUN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ
RVNHIHJldmlldywgd2hpY2ggSQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHdvdWxkIGxpa2UgdG8NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YWxpZGF0ZSB3aXRoIHRoZQ0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdHLiBT
ZWU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgPGENCmhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1y
ZmM2NTM2YmlzLTA4LnR4dCINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciINCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZjx3
YnI+Zj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2PHdicj41MzZiaXMtMDgudHh0PC9h
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICZsdDs8YQ0KaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh
ZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDgudHh0Ig0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvcmZjZGlmPHdicj5mP3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY8d2Jy
PjUzNmJpcy0wOC50eHQ8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7wqAgwqAgwqAgwqAgwqAmbHQ7ZGZwY2Zpb29uZGdnaXBwZS5w
bmcmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFRoZSBORVRD
T05GIFdHIHdhcyBjYydlZCBmb3IgdGhlIGVudGlyZQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRpc2N1c3Npb24uPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDvCoCDCoCDCoCDCoCDCoFdoYXQgZG8geW91IHRoaW5rPyBJIHdpbGwg
ZHJhdyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjb25jbHVzaW9ucyBieQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIEZyaWRheSBOb3YgMTB0aC48YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgTm90ZTog
SWYgdGhlIFdHIGlzIGZpbmUsIHRoZSBuZXh0IHN0ZXAgaXMNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhcHByb3ZlIHRoaXMNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2N1
bWVudC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
O8KgIMKgIMKgIMKgIMKgUmVnYXJkcywgQmVub2l0PGJyPg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDvCoCDC
oCDCoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgTmV0Y29u
ZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKg
PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1v
ei1kby1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7bWFpbHRvOjxh
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIj5OZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0O8KgIMKgIMKgIMKgIMKgPGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiINCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZlcnJlciINCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRh
cmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vbmV0Y29uZjwvYT4NCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7PGENCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiINCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9y
ZWZlcnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vbmV0Y29uZjwvYT4mZ3Q7
PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn
dDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJmd0OyZndDsmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IE5ldGNv
bmYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBtYWlsaW5nIGxpc3Q8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IDxhDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86TmV0Y29u
ZkBpZXRmLm9yZyINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5O
ZXRjb25mQGlldGYub3JnPC9hPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpOZXRjb25m
QGlldGYub3JnIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPk5l
dGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgPGENCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbD0ibm9yZWZl
cnJlciINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHRhcmdldD0iX2JsYW5rIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2w8d2JyPmlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0
OyZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgJmd0OyZndDsgTWFoZXNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgSmV0aGFuYW5kYW5pPGJyPg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsmZ3Q7IDxhDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo
cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayIN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0
O21haWx0bzo8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFy
Z2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1qZXRoYW5hbmRhbmlAZ21h
aWwuY288d2JyPm08L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fXzxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAm
Z3Q7IE5ldGNvbmYgbWFpbGluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGxpc3Q8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyA8YQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOk5ldGNv
bmZAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0YXJnZXQ9Il9ibGFuayINCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyA8YQ0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVsPSJub3JlZmVycmVyIg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFy
Z2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbDx3YnI+aXN0aW5mby9uZXRjb25mPC9hPjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9i
bG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90
ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg
ICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg
ICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8ZmllbGRzZXQNCiAgICAg
ICAgICAgICAgICAgICAgICAgIGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1bWltZUF0
dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+DQogICAgICAgICAgICAgICAgICAgICAgPGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgIDxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPHdicj5fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCjxh
IGNsYXNzPSJtXy01MDQ0NDI0NDQyNzA0ODQ2MzM1bW96LXR4dC1saW5rLWFiYnJldmlhdGVk
IiBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSI+TmV0Y29uZkBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtXy01
MDQ0NDI0NDQyNzA0ODQ2MzM1bW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5r
IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
PHdicj5saXN0aW5mby9uZXRjb25mPC9hPg0KPC9wcmU+DQogICAgICAgICAgICAgICAgICAg
IDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAg
ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg
ICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg
ICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDwvZGl2
Pg0KICAgICAgICAgIDxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Rpdj4NCiAgICA8
L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICA8L2JvZHk+DQo8L2h0bWw+DQo=
--------------2AF788B9FC757172BB684F14--


From nobody Thu Nov 23 02:56:45 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0574127B60; Thu, 23 Nov 2017 02:56:43 -0800 (PST)
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 CuvI2ap3tDZX; Thu, 23 Nov 2017 02:56:40 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1651277BB; Thu, 23 Nov 2017 02:56:40 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 890351AE01AA; Thu, 23 Nov 2017 11:56:38 +0100 (CET)
Date: Thu, 23 Nov 2017 11:55:17 +0100 (CET)
Message-Id: <20171123.115517.184466477872309994.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netconf@ietf.org, sec-ads@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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 10:56:44 -0000

Robert Wilton  wrote:
> Hi Andy,
> =

> =

> On 22/11/2017 18:09, Andy Bierman wrote:
> >
> >
> > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise  > > wrote:
> >
> >     Hi Rob,
> >
> >     At that points in time, if it clarifies the spec. and the autho=
rs
> >     agree with this, let's do the right thing.
> >
> >
> > I will add the new text if that is what the WG wants.
> Having read this draft, I was undecided what the intended behavior
> actually should be.
> =

> The way that Yumapro and Tail-f have implemented this is reasonable,
> and is probably also the way that I would implemented it.
> =

> But I also think that it would be a reasonable implementation for a
> server to calculate the full change set (taking account of side
> effects from when and choice statements) to the datastore before
> checking the "write data node access control" against the resultant
> change set.
> =

> My interpretation is that the RFC text is ambiguous on what the
> correct behavior is, and one could make a reasonable argument that th=
e
> current RFC actually specifies that the alternative behavior is
> correct, i.e. requiring delete access even if a node is implicitly
> changes as a side effect.=A0 E.g. section 3.2.3 of RFC 6536 states:
> =

>    If the protocol operation would result in the deletion of a datast=
ore
>    node and the user does not have "delete" access permission for tha=
t
>    node, the protocol operation is rejected with an "access-denied"
>    error.
> =

> =

> An  request that causes a when constraint to evaluate
> differently does result in a deletion of those data nodes from the
> datastore, and hence according to the text above, requires explicit
> "delete" access permission to accomplish that.
> =

> Clearly it would be an interop issue if different servers implemented=

> the NACM path based filtering differently.
> =

> Hence why I think that it would be prudent for the draft to be more
> explicit on when and choice statement handling.

I agree.  The text you proposed earlier is fine, except I would avoid
the NETCONF specific words, and be more generic.


/martin


> =

> Thanks,
> Rob
> =

> =

> > There have not been any comments on this issue.
> >
> >
> > Andy
> >
> >     Regards, Benoit.
> >>
> >>     Hi Benoit,
> >>
> >>     There is also one further, unrelated change that I am proposin=
g
> >>     is made the draft before it is published, to help better clari=
fy
> >>     the expected behavior.=A0 It isn't the end of the world if thi=
s
> >>     doesn't go in, but I think that it prevents sometime taking a
> >>     different, but IMO reasonable, interpretation of how "when"
> >>     statements are considered, and then having a future argument
> >>     about what behavior it specified in the standard.
> >>
> >>     If we clarify it now, then it closes that door :-)
> >>
> >>     I've proposed text to Andy and Martin on Monday, but I've not
> >>     heard back yet.
> >>
> >>     Netconf email with proposed text attached.=A0 The text doesn't=

> >>     necessarily have to match this, but personally I think that it=
 is
> >>     useful if the draft says something on this.
> >>
> >>     Thanks,
> >>     Rob
> >>
> >>
> >>     On 22/11/2017 13:25, Benoit Claise wrote:
> >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> >>>>     Hi,
> >>>>
> >>>>     Here are some proposed edits to make the data rule consisten=
t
> >>>>     with the examples.
> >>>>     Note that this issue is not related to the edit in the origi=
nal
> >>>>     1-week change.
> >>>     That's right, but we found a source of misinterpretation in t=
he
> >>>     draft and you have rightly corrected it in the github v9.
> >>>
> >>>     Regards, Benoit
> >>>>
> >>>>
> >>>>     sec. 3.3.5:
> >>>>
> >>>>     OLD:
> >>>>
> >>>>
> >>>>     =A0 =A0 =A0 data node rule: =A0controls access for a specifi=
c data
> >>>>     node, identified
> >>>>     =A0 =A0 =A0 by its path location within the conceptual XML d=
ocument
> >>>>     for the
> >>>>     =A0 =A0 =A0 data node.
> >>>>
> >>>>
> >>>>     NEW:
> >>>>
> >>>>     =A0 =A0 =A0 data node rule: =A0controls access for a specifi=
c data node
> >>>>     and its descendants,
> >>>>     =A0 =A0 =A0 identified by its path location within the conce=
ptual XML
> >>>>     document for the
> >>>>     =A0 =A0 =A0 data node.
> >>>>
> >>>>
> >>>>     sec 3.4.5, step 6, bullet 2:
> >>>>
> >>>>
> >>>>     OLD:
> >>>>
> >>>>     =A0 =A0 =A0 =A0 * =A0The rule does not have a "rule-type" de=
fined or the
> >>>>     "rule-
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0type" is "data-node" and the "path" m=
atches the
> >>>>     requested
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0data node, action node, or notificati=
on node.
> >>>>                NEW:
> >>>>     =A0 =A0 =A0 =A0 * =A0The rule does not have a "rule-type" de=
fined or the
> >>>>     "rule-
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0type" is "data-node" and the "path" m=
atches the
> >>>>     requested
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0data node, action node, or notificati=
on node. A path is
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0considered to match if the current da=
ta node is the
> >>>>     data node
> >>>>     =A0 =A0 =A0 =A0 =A0 =A0specified by the path, or is a descen=
dant data node
> >>>>     of this data node.
> >>>>     appendix B.4: (2 bugs in explanation)
> >>>>     OLD:
> >>>>     deny-nacm: This rule denies the "guest" group any access to =
the
> >>>>      subtree. Note that the default namespace is only
> >>>>     applicable because this subtree is defined in the same
> >>>>     namespace as the  element.
> >>>>     NEW:
> >>>>     deny-nacm: This rule denies the "guest" group any access to =
the
> >>>>      subtree.
> >>>>     Andy
> >>>>
> >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> >>>>     > wrote:
> >>>>
> >>>>
> >>>>
> >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> >>>>>
> >>>>>
> >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> >>>>>         > wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> >>>>>>
> >>>>>>
> >>>>>>             On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
> >>>>>>             > wrote:
> >>>>>>
> >>>>>>                 On 2017-11-10 11:42, Robert Wilton wrote:
> >>>>>>                 >
> >>>>>>                 >
> >>>>>>                 > On 10/11/2017 10:02, Mahesh Jethanandani wro=
te:
> >>>>>>                 >>
> >>>>>>                 >>
> >>>>>>                 >>
> >>>>>>                 >>
> >>>>>>                 >> Mahesh Jethanandani
> >>>>>>                 >> mjethanandani@gmail.com
> >>>>>>                 
> >>>>>>                  >>>>>>                 >
> >>>>>>                 >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
> >>>>>>                 
> >>>>>>                  >>>>>>                 >> wrote:
> >>>>>>                 >>
> >>>>>>                 >>> Hi,
> >>>>>>                 >>>
> >>>>>>                 >>> The term "data node" is used in the docume=
nt
> >>>>>>                 to refer to the top-level node
> >>>>>>                 >>> of the specified object, not the entire
> >>>>>>                 subtree (if any).
> >>>>>>                 >>>
> >>>>>>                 >>> The data-rule /foo does not match /foo/chi=
ld1
> >>>>>>                 in the text below.
> >>>>>>                 >>> The child nodes are omitted because of ste=
p 11.
> >>>>>>                 >>> The admin has to explicitly permit individ=
ual
> >>>>>>                 child nodes (or modules).
> >>>>>>                 >>> This seems correct if the read-default is =
"deny".
> >>>>>>                 >>>
> >>>>>>                 >>> Should any text be added or changed to mak=
e
> >>>>>>                 this more clear?
> >>>>>>                 >>
> >>>>>>                 >> I would agree with Robert that it was not
> >>>>>>                 entirely clear that rule applied on the parent=

> >>>>>>                 data-node does not apply to the child nodes. S=
o
> >>>>>>                 yes, it would help to clarify it.
> >>>>>>                 > We should be doing more than clarifying it.=A0=
 We
> >>>>>>                 need to fix it so that it works in a sensible
> >>>>>>                 way.=A0 I.e. to make the normative text consis=
tent
> >>>>>>                 with the behaviour currently described in the
> >>>>>>                 examples in
> >>>>>>                 > the appendix B.4.
> >>>>>>                 >
> >>>>>>                 > If we follow Andy's interpretation that a da=
ta
> >>>>>>                 rule doesn't match child nodes then those
> >>>>>>                 examples are completely wrong.=A0 E.g. the 4th=
 rule
> >>>>>>                 is described as "This rule gives the 'admin'
> >>>>>>                 group read-write
> >>>>>>                 > access to all acme  entries."=A0 =
But
> >>>>>>                 If the path only strictly matches
> >>>>>>                 "/acme:interfaces/acme:interface" then the adm=
in
> >>>>>>                 group rule achieves nothing useful at all.=A0 =
The
> >>>>>>                 admin is not even
> >>>>>>                 > allowed to create an interface because they
> >>>>>>                 would not even have permission to write to the=

> >>>>>>                 list key 'name' node required to create a list=

> >>>>>>                 entry!=A0 Instead, a separate rule would be
> >>>>>>                 required for every
> >>>>>>                 > single possible schema node under
> >>>>>>                 "/acme:interfaces/acme:interface"! I think tha=
t
> >>>>>>                 this makes "permit" data-node rules completely=

> >>>>>>                 unusable.
> >>>>>>
> >>>>>>                 I strongly agree with this, and I would say th=
at
> >>>>>>                 it isn't only the case
> >>>>>>                 for "permit" rules - e.g. denying some access =
to
> >>>>>>                 a subtree of the data
> >>>>>>                 model that would otherwise be permitted due to=

> >>>>>>                 defaults is at least as
> >>>>>>                 common, and the rules would be just as unusabl=
e
> >>>>>>                 for that.
> >>>>>>
> >>>>>>                 Besides the examples, I think that the very us=
e
> >>>>>>                 of the term "match",
> >>>>>>                 though unfortunately not defined, strongly
> >>>>>>                 suggests that it is something
> >>>>>>                 other than use of e.g. the term "identify" wou=
ld
> >>>>>>                 imply. Additionally,
> >>>>>>                 this text in the description of the 'path' lea=
f
> >>>>>>                 is consistent with the
> >>>>>>                 match being a prefix match:
> >>>>>>
> >>>>>>                 =A0 =A0 =A0 =A0The special value '/' refers to=
 all possible
> >>>>>>                 =A0 =A0 =A0 =A0datastore contents.";
> >>>>>>
> >>>>>>                 FWIW, our NACM implementation, available to (a=
nd
> >>>>>>                 used by) customers
> >>>>>>                 since 2012, follows the prefix match logic, an=
d I
> >>>>>>                 have yet to hear of
> >>>>>>                 any user expecting it to do otherwise.
> >>>>>>
> >>>>>>                 > To fix this properly, we need to make the
> >>>>>>                 data-node path rule a prefix match.=A0 In
> >>>>>>                 particular, we need text that specifies:
> >>>>>>                 >
> >>>>>>                 > (i) that a data-node path match succeeds if =
it
> >>>>>>                 matches the path prefix from the root of the
> >>>>>>                 tree.=A0 I.e. so the data-rule "/foo" matches
> >>>>>>                 "/foo" and all of foo's descendant children no=
des.
> >>>>>>
> >>>>>>                 Strongly agree.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>             I do not see how the text can be interpreted this =
way.
> >>>>>
> >>>>>             Because otherwise the path match part of the NACM
> >>>>>             solution is really broken, and the path based examp=
les
> >>>>>             in the appendix are entirely misleading and wrong.=A0=

> >>>>>             The only way those examples make sense is the paths=

> >>>>>             match descendant children nodes as well.
> >>>>>
> >>>>>
> >>>>>
> >>>>>         IMO the text does not support this interpretation.
> >>>>         The examples in B.4, and the definition of "/" matching =
all
> >>>>         nodes supports this interpretation.
> >>>>
> >>>>         Hence, my opinion is that it is the text in 3.4.5 that i=
s
> >>>>         incorrectly specified; and that the examples, definition=
 of
> >>>>         "/" and standard practice are right.
> >>>>
> >>>>         Otherwise, how did IETF manage to publish an RFC where t=
he
> >>>>         path based examples are so completely wrong?=A0=A0 Whoev=
er
> >>>>         wrote and reviewed those examples clearly had a differen=
t
> >>>>         interpretation of how these path based ACLs worked.
> >>>>
> >>>>
> >>>>>         There is nothing said about inheriting state from the
> >>>>>         parent data node.
> >>>>>         I think no matter how the permissions are derived, one =
can
> >>>>>         find examples that work better or worse because of it.
> >>>>         No.=A0 If the rules apply to descendant children, all no=
rmal
> >>>>         examples work well (including the ones in the appendix).=

> >>>>
> >>>>
> >>>>>         IMO the number of rules required to implement a use-cas=
e
> >>>>>         is not
> >>>>>         very relevant or objective criteria.
> >>>>         Yes it is, particularly when the difference is between
> >>>>         needing a 1 line rule, and a 100+ line rule.
> >>>>
> >>>>>
> >>>>>         Using the previous example of /home and /home/user1,
> >>>>>         if the user1 is given read access to /home, then
> >>>>>         (according to you)
> >>>>>         it also has read access to every user subtree under /ho=
me.
> >>>>>         Instead of 1 rule per user, 2 rules are needed
> >>>>         No, just 1 rule per user:
> >>>>         =A0=A0 read-default=3Ddeny
> >>>>         =A0=A0 group=3Duser1, path=3D/home/user1, action=3Dpermi=
t
> >>>>
> >>>>         This is because of my two proposed changes:
> >>>>
> >>>>         (i) that a data-node path match succeeds if it matches t=
he
> >>>>         path prefix from the root of the tree.=A0 I.e. so the
> >>>>         data-rule "/foo" matches "/foo" and all of foo's descend=
ant
> >>>>         children nodes.
> >>>>         <- This means that you only need 1 entry instead of 100
> >>>>         entries.
> >>>>
> >>>>         (ii) if a data-node rule has action "permit" then it
> >>>>         implicitly allows read access for all ancestor parent no=
des
> >>>>         up to the root.=A0 (I.e. to mitigate the original change=

> >>>>         proposed on this thread.)
> >>>>         <- This means that you don't need a separate read rule f=
or
> >>>>         "/home".=A0 Read access to that node it is implicitly gi=
ven
> >>>>         via "group=3Duser1, path=3D/home/user1, action=3Dpermit"=
, hence
> >>>>         meaning that the rule works the same way as it does on a=
n
> >>>>         rfc6536 compliant implementation.
> >>>>
> >>>>>
> >>>>>         =A0 =A0read-default=3Ddeny
> >>>>>         =A0 =A0group=3D*, path=3D/home, action=3Dpermit
> >>>>>         =A0 =A0group=3Duser1, path=3D/home/user1, action=3Dperm=
it
> >>>>>
> >>>>>         The above rules would allow access for every user to ev=
ery
> >>>>>         other user.
> >>>>>         The 2nd rule has no effect, which is counter-intuitive.=

> >>>>>         Every user dir would need 2 rules
> >>>>>
> >>>>>         =A0 =A0read-default=3Ddeny
> >>>>>         =A0 =A0group=3D*, path=3D/home, action=3Dpermit
> >>>>>         =A0 =A0group=3Duser1, path=3D/home/user1, action=3Dperm=
it
> >>>>>         =A0 =A0group=3D*, path=3D/home/user1, action=3Ddeny
> >>>>>
> >>>>>>             There is nothing that says this is how it works.
> >>>>>>             If it did, once could never have privileged sub-fi=
olders
> >>>>>>
> >>>>>>             =A0 =A0 =A0/var/log -> permit
> >>>>>>             =A0/var/log/apache2 =A0-> deny
> >>>>>
> >>>>>             Yes, you can, you just list the longest path first =
in
> >>>>>             the list of rules:
> >>>>>
> >>>>>             =A0(1)=A0 /var/log/apache2 =A0-> deny
> >>>>>             =A0 (2) /var/log -> permit
> >>>>>
> >>>>>             Any requests that attempt to access anything under
> >>>>>             /var/log/apache2 would match rule (1) and be denied=
.=

> >>>>>             Any requests that attempt to access anything under
> >>>>>             /var/log, but not under /var/log/apache2, would fai=
l
> >>>>>             to match rule (1), but would match rule (2) instead=

> >>>>>             and be permitted.
> >>>>>
> >>>>>
> >>>>>
> >>>>>         I do not see any text in the draft or RFC 7950 that
> >>>>>         suggests that /var/log and /var/log/apache2 represent t=
he
> >>>>>         same data node.
> >>>>         They are different data nodes, but I don't see how that =
is
> >>>>         relevant.
> >>>>
> >>>>         Thanks,
> >>>>         Rob
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>         Andy
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>                 > (ii) if a data-node rule has action "permit"=

> >>>>>>                 then it implicitly allows read access for all
> >>>>>>                 ancestor parent nodes up to the root.=A0 (I.e.=
 to
> >>>>>>                 mitigate the original change proposed on this
> >>>>>>                 thread.)
> >>>>>>
> >>>>>>                 This seems reasonable to me, although I haven'=
t
> >>>>>>                 at this point evaluated
> >>>>>>                 the suggestion in detail. In any case I think =
the
> >>>>>>                 main point both
> >>>>>>                 regarding this and the prefix match is that th=
is
> >>>>>>                 update to 6536 can't
> >>>>>>                 make radical changes to the semantics compared=
 to
> >>>>>>                 a "reasonable
> >>>>>>                 interpretation" (hard to define, I know) of th=
e
> >>>>>>                 under-specified
> >>>>>>                 original.
> >>>>>>
> >>>>>>
> >>>>>>             The text does not say this at all so I do not appr=
ove
> >>>>>>             of this change
> >>>>>
> >>>>>             In the RFC version of the NACM this wasn't required=

> >>>>>             because operation 'none' didn't require read access=
.=A0
> >>>>>             Now read access is required even for operation 'non=
e',
> >>>>>             then this change makes sense to make the NACM chang=
es
> >>>>>             backwards compatible, whilst still closing the
> >>>>>             security hole.
> >>>>>
> >>>>>             Thanks,
> >>>>>             Rob
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>                 --Per
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>             Andy
> >>>>>>
> >>>>>>                 > Thanks,
> >>>>>>                 > Rob
> >>>>>>                 >
> >>>>>>                 >
> >>>>>>                 >>
> >>>>>>                 >> Thanks
> >>>>>>                 >>
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>> Andy
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wil=
ton
> >>>>>>                 
> >>>>>>                  >>>>>>                 >> wrote:
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0Hi Andy,
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0It isn't clear to me whether mat=
ching a
> >>>>>>                 path in NACM either:
> >>>>>>                 >>> =A0(i) Only applies to the specific node, =
and
> >>>>>>                 not any children, or
> >>>>>>                 >>> =A0(ii) Applies to the specific node and a=
ll
> >>>>>>                 descendant children nodes as well.
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0As an example, using the tree be=
low.=A0 if
> >>>>>>                 I have a rule that matches path "A/B" then doe=
s
> >>>>>>                 that apply to only the specific node "A/B", or=

> >>>>>>                 does it also apply to all descendant children =
of
> >>>>>>                 "A/B" as
> >>>>>>                 >>> =A0well?
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0In rfc6536bis-08, section "3.4.5=
. Data
> >>>>>>                 Node Access Validation", step 6 states:
> >>>>>>                 >>>
> >>>>>>                 >>> =A0 =A0 =A0*=A0 The rule does not have a "=
rule-type"
> >>>>>>                 defined or the "rule-
> >>>>>>                 >>> =A0 =A0 =A0 =A0 type" is "data-node" and t=
he *"path"
> >>>>>>                 matches the requested data node*, action node,=
 or
> >>>>>>                 notification node.
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0My reading of this is that it im=
plies
> >>>>>>                 that the interpretation of the path rule is (i=
),
> >>>>>>                 but this is not how I would normally expect an=

> >>>>>>                 ACL rule to apply in a tree like object (e.g a=

> >>>>>>                 directory
> >>>>>>                 >>> =A0file system).
> >>>>>>                 >>>
> >>>>>>                 >>> =A0However, the examples in Appendix B.4. =
imply
> >>>>>>                 that the path rule is to be interpreted like
> >>>>>>                 (ii), or otherwise the example rules seem to b=
e
> >>>>>>                 mostly pointless.
> >>>>>>                 >>>
> >>>>>>                 >>> =A0E.g. taking this example from appendix =
B.4:
> >>>>>>                 >>>
> >>>>>>                 >>> =A0 =A0 
> >>>>>>                 >>> permit-dummy-interface
> >>>>>>                 >>> =A0 =A0 =A0  >>>>>>                 xmlns:acme=3D"http://example.com/ns/itf
> >>>>>>                 "
> >>>>>>                 >
> >>>>>>                 >>>
> >>>>>>                 /acme:interfaces/acme:interface[acme:name=3D'd=
ummy']
> >>>>>>                 >>> =A0 =A0 =A0 
> >>>>>>                 >>> read
> >>>>>>                 update
> >>>>>>                 >>> permit
> >>>>>>                 >>> 
> >>>>>>                 >>> =A0 =A0 =A0 =A0 Allow the limited and gues=
t groups read
> >>>>>>                 >>> =A0 =A0 =A0 =A0 and update access to the d=
ummy interface.
> >>>>>>                 >>> 
> >>>>>>                 >>> =A0 =A0 
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0If the rule is (i) then the acce=
ss rule
> >>>>>>                 allows the client to read the specific node
> >>>>>>                 "/acme:interfaces/acme:interface[acme:name=3D'=
dummy']"
> >>>>>>                 but not any child leafs/containers of that int=
erface,
> >>>>>>                 >>> =A0this doesn't seem useful.
> >>>>>>                 >>>
> >>>>>>                 >>> =A0Further comments inline below ...
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0On 08/11/2017 20:05, Andy Bierma=
n wrote:
> >>>>>>                 >>>> =A0Hi,
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0This change has no impact on the serve=
r if
> >>>>>>                 /nacm/read-default is "permit".
> >>>>>>                 >>>> =A0In that case, the extra read rules for=
 /A
> >>>>>>                 and /A/B are not needed.
> >>>>>>                 >>>=A0 =A0 =A0I agree.
> >>>>>>                 >>>
> >>>>>>                 >>>> =A0An operator worried about read access
> >>>>>>                 should set read-default to "deny".
> >>>>>>                 >>>=A0 =A0 =A0I agree.=A0 This is the scenario=
 that I'm
> >>>>>>                 considering.
> >>>>>>                 >>>
> >>>>>>                 >>>> =A0In that case, explicit rules to read /=
A and
> >>>>>>                 /A/B would be needed
> >>>>>>                 >>>> =A0in the new NACM.
> >>>>>>                 >>> =A0Yes, if the interpretation of the rule =
is
> >>>>>>                 (i) above.
> >>>>>>                 >>> =A0Otherwise if the interpretation is (ii)=
 then
> >>>>>>                 you only need "read /A" since that implies "re=
ad
> >>>>>>                 A/B" as well (as long as the rules are listed =
in
> >>>>>>                 the correct order).
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>>> =A0 =A0The deny rules would not be needed=
.=

> >>>>>>                 >>> =A0Only if the interpretation of the rule =
is
> >>>>>>                 (i) above.=A0 In which case the "read/write 'A=
/B/J'
> >>>>>>                 rule would not be sufficient.=A0 It would be
> >>>>>>                 necessary to define an Xpath expressions that
> >>>>>>                 contains
> >>>>>>                 >>>=A0 =A0 =A0all children nodes as well.=A0 P=
erhaps
> >>>>>>                 'A/B/J//*'?
> >>>>>>                 >>>
> >>>>>>                 >>>=A0 =A0 =A0If the interpretation of the rul=
e is (ii)
> >>>>>>                 then you would also need all the explicit deny=

> >>>>>>                 statements as well, otherwise they would be
> >>>>>>                 allowed by the "read /A" rule above.
> >>>>>>                 >>>
> >>>>>>                 >>> =A0Thanks,
> >>>>>>                 >>>=A0 =A0 =A0Rob
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>>>
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0Andy
> >>>>>>                 >>>>
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0On Wed, Nov 8, 2017 at 8:33 AM, Robert=

> >>>>>>                 Wilton  >>>>>>                 
> >>>>>>                  >>>>>>                 >> wrote:
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0Hi,
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0I'm not sure about this change=
.=

> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0I'm not that familiar with NAC=
M, but if
> >>>>>>                 you want to give a particular set of users
> >>>>>>                 read/write access to a subtree, but not allow
> >>>>>>                 them to have any other access to the
> >>>>>>                 configuration in the
> >>>>>>                 >>>> =A0 =A0 =A0running datastore then with th=
e
> >>>>>>                 existing RFC, that could be expressed with a
> >>>>>>                 single rule (example in 6536bis, appendix B.4)=

> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0With this new change, I think =
that you
> >>>>>>                 may need to configure many more rules to achie=
ve
> >>>>>>                 the same thing.=A0 I think that you would need=
 to
> >>>>>>                 give read access to the top node in the desire=
d
> >>>>>>                 >>>> =A0 =A0 =A0path, and then separate explic=
it "deny"
> >>>>>>                 rules for every sibling child node walking fro=
m
> >>>>>>                 the top of the tree down to the data node that=

> >>>>>>                 read/write access is actually being given to.=A0=
 The
> >>>>>>                 >>>> =A0 =A0 =A0example below may explain my
> >>>>>>                 understanding better:
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0E.g. For a tree of data nodes,=
 rooted
> >>>>>>                 at A, if we wanted to give read/write access o=
nly
> >>>>>>                 to "J" subtree, and no access for the rest of =
the
> >>>>>>                 tree then:
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 A
> >>>>>>                 >>>> =A0 |
> >>>>>>                 >>>> =A0--------------------
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0| |=A0 =A0 =A0=
|=A0 =A0 =A0|
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0B C=A0 =A0 =A0=
D=A0 =A0 =A0E
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 -----------
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 |=A0 =A0|=A0 |=A0 |
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 F=A0 =A0G=A0 H=A0 J
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...
> >>>>>>                 >>>>
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0In the old model, I think that=
 the ACL
> >>>>>>                 rules would be 1 rules long (assuming default
> >>>>>>                 deny all):
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "read/write 'A/B/J'
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0In the new model, I think that=
 the
> >>>>>>                 equivalent ACL rules would need to be 8 rules
> >>>>>>                 long (assuming default deny all):
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "read/write 'A/B/J'
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "read A"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny C"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny D"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny E"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny F"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny G"
> >>>>>>                 >>>> =A0 =A0 =A0 =A0 "deny H"
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0Note, I am assuming that a "pa=
th" rule
> >>>>>>                 matches for the given path and all descendant
> >>>>>>                 nodes.=A0 The draft doesn't seem to be particu=
larly
> >>>>>>                 clear on this point (it states that the rule a=
pplies
> >>>>>>                 >>>> =A0 =A0 =A0when the path matches, but thi=
s would
> >>>>>>                 seem to be counter intuitive), and perhaps it
> >>>>>>                 could be clarified.
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0If this change is allowed, the=
n the
> >>>>>>                 example in appendix B.4 looks like it would ne=
ed
> >>>>>>                 to be fixed, since the "limited-acl" probably
> >>>>>>                 wouldn't give any access at all, unless defaul=
t read
> >>>>>>                 >>>> =A0 =A0 =A0access had been given.
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0But, possibly I'm misunderstan=
ding how
> >>>>>>                 this all works! If so, apologies for the noise=
 :-)
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0Thanks,
> >>>>>>                 >>>> =A0 =A0 =A0Rob
> >>>>>>                 >>>>
> >>>>>>                 >>>>
> >>>>>>                 >>>> =A0 =A0 =A0On 02/11/2017 14:18, Benoit Cl=
aise wrote:
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0Dear all,
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0Here is a major change=
 in
> >>>>>>                 draft-ietf-netconf-rfc6536bis, suggested by th=
e
> >>>>>>                 Security AD Eric Rescola part of the IESG revi=
ew,
> >>>>>>                 which I would like to validate with the WG. Se=
e
> >>>>>>                 >>>>>
> >>>>>>                 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ie=
tf-netconf-rfc6536bis-08.txt
> >>>>>>                 
> >>>>>>                  >>>>>>                 >
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0=

> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0The NETCONF WG was cc'=
ed for the
> >>>>>>                 entire discussion.
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0What do you think? I w=
ill draw the
> >>>>>>                 conclusions by Friday Nov 10th.
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0Note: If the WG is fin=
e, the next
> >>>>>>                 step is to approve this document.
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0Regards, Benoit
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0
> >>>>>>                 =A0___________________________________________=
____
> >>>>>>                 >>>>>=A0 =A0 =A0 =A0 =A0Netconf mailing list
> >>>>>>                 >>>>> Netconf@ietf.org 
> >>>>>>                 >
> >>>>>>                 >>>>>
> >>>>>>                 https://www.ietf.org/mailman/listinfo/netconf
> >>>>>>                 
> >>>>>>                  >>>>>>                 >
> >>>>>>                 >>>>
> >>>>>>                 >>>>
> >>>>>>                 >>>
> >>>>>>                 >>>
> >>>>>>                 >>> __________________________________________=
_____
> >>>>>>                 >>> Netconf mailing list
> >>>>>>                 >>> Netconf@ietf.org =

> >>>>>>                 >
> >>>>>>                 >>> https://www.ietf.org/mailman/listinfo/netc=
onf
> >>>>>>                 
> >>>>>>                 >>
> >>>>>>                 >> Mahesh Jethanandani
> >>>>>>                 >> mjethanandani@gmail.com
> >>>>>>                 
> >>>>>>                  >>>>>>                 >
> >>>>>>                 >
> >>>>>>                 >
> >>>>>>                 >
> >>>>>>                 > ____________________________________________=
___
> >>>>>>                 > Netconf mailing list
> >>>>>>                 > Netconf@ietf.org 
> >>>>>>                 > https://www.ietf.org/mailman/listinfo/netcon=
f
> >>>>>>                 
> >>>>>>                 >
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     _______________________________________________
> >>>>     Netconf mailing list
> >>>>     Netconf@ietf.org 
> >>>>     https://www.ietf.org/mailman/listinfo/netconf
> >>>>     
> >>>
> >>
> >
> >
> =

> =


From nobody Fri Nov 24 03:06:00 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAE81275C5; Fri, 24 Nov 2017 03:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 UinQT7m1ajLF; Fri, 24 Nov 2017 03:05:56 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0131.outbound.protection.outlook.com [104.47.2.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B776112751F; Fri, 24 Nov 2017 03:05:55 -0800 (PST)
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; bh=/mt1sPzIxpbDDLwvokaQsYPgpYwnqcvxUQCCwspRdMo=; b=VCPMixUdlKySWOuokSOH/DxFxo8/PS1shc4bO1DSP3hfI14RGRC/n3DOXufjhwFigI0SlMgsAaoT/bxO11n7YyAJxrulD2b76OckKsYkV5YwDloz7dxdEVpTilCD2v+TY9J03zx7sRD0Xo2eKdJlNAh0RliYFTKNpmJ7ep61ppY=
Received: from pc6 (86.169.153.236) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Fri, 24 Nov 2017 11:05:52 +0000
Message-ID: <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Andy Bierman" , "NETCONF" , "Robert Wilton" 
Cc: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>      
Date: Fri, 24 Nov 2017 11:02:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6PR0501CA0008.eurprd05.prod.outlook.com (2603:10a6:4:8f::18) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603258); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:+yIriqjJeRo/fYV0eSdo9oGibpRzQKFbO4x7jdFmZ8uovdP4CI6TezkwJqKfLw87qAb67l4FunMpBYGQk9eQp1IUP8fUV26fjtTTx/mlB1HEl7MC8T23AZXajeReWW525OYfggpPhm98ExUbLqUF5gRd9V0r14kDBqcUPSttWtc1WvkbxPh1H5JWftLoPMdFDJgdkP+NnSU8TFDrmf43bA0glFYH4afJ3Oy1n30pIaJRtEhVxWLnA3TdofkWhOFP; 25:sYczQ5B80HXNEjqWx4NHHQQAJdI50uGw2C7k8dl4EIOv28B/b6Cs+ns2lVWNyw7TUn8KyqlHPgjtLj3+ZbQAMT8z0tSCmt0xG94upHxS7oQo9A7SSksim3mWuKrpAcVHILKGaHvoWc9U13/UpY4T4d8nbHgqm8O7+473iq08BUCd1gtqOHBlX9ymfPADSBncMgZa07kR4opPieh6xzo+GW5V85EUMxcgsascC8Y/v1YwghR+hPynwbDGmzu9wxrZtVPLE3usSrMhPoJYFCP8Ho6k4NXZZZ/yTkgbVCrBmmvgkShE4KN9PSXJwEL8FaaT5+eEEtMe1Icnr+4RGg5xjg==; 31:Dr4yi6vwsPdt953CzPJ/VaPuF8J8OKOcZ+eafHJIij41J6S3kR7etnuSIJzSgZdtapeBuRfMGkPigho609vLdv0zsp0EJ4+VfrLtf5n1VCMksuQ2k+GUQMMdaq1sOQJyQEOswk+k1IhkWdGzjkxX5E4aWOaL5vzzecLLGMFx2xNnK2PycUt46YMlAXto8zBF+0jGPqjkoZkSthrCv2zSwEI/Xw3cNFH5V+nPH2eCUys=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
X-MS-Office365-Filtering-Correlation-Id: 103515db-5e54-4d2e-7655-08d5332b5434
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(3002001)(93006095)(93001095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 4:rUeZrQLC+T8qxrsC8dZTdK40xCWMulGfCOe8Y+p48MbQlC/h/j3ExQeytbqZOMq0HWF2ZHdLE8V/FMXJJMg2HGfXsVAFGh00dl5nkvrgEyIH78sBtcsV5JYNwGba7XyK/N2idqrdiIZtGJsfXRWSUJlQBpdVe/9VhBgcB72MQUsxOM5MsTvTwJDhBx5jXZbVl25l2Z1tse1tjwzo/tySeiSX7k8jAZ3acgEc2SFUe2TJ3z9S6pr13drr0bzehU7T/qQX01nl55dsQCoF0r2+z1DIvPgCdCRjLxBdA7OCA/gaMolG8wRGuRs9vI0B2lW5iQKBiiJ+c2QFQbiRdjcVN+lhY1U7HFXviP4wM6wCrHM=
X-Forefront-PRVS: 05015EB482
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(39860400002)(346002)(376002)(51444003)(24454002)(13464003)(189002)(199003)(50466002)(66066001)(25786009)(9686003)(33646002)(1556002)(105586002)(116806002)(230783001)(3846002)(6116002)(68736007)(6496006)(61296003)(53936002)(478600001)(4326008)(4720700003)(86362001)(6666003)(2486003)(52116002)(23676004)(8676002)(84392002)(5890100001)(81166006)(76176999)(81156014)(53546010)(6486002)(101416001)(189998001)(81816999)(16526018)(14496001)(50986999)(316002)(50226002)(230700001)(1456003)(106356001)(5660300001)(110136005)(8936002)(97736004)(47776003)(44716002)(62236002)(6246003)(44736005)(7736002)(305945005)(2906002)(229853002)(93886005)(81686999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
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-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDc7MjM6Q3dCVGZTNGsyRDFyQkVCMVM5eEpOUk5G?= =?utf-8?B?b1hOUFdLVVJrSUxUY0VxN3BXVzBlS29JMGVqQ2o5VEFIK1NTUjNhOVEvNlg2?= =?utf-8?B?VlB1N2ZPSFQ5UHp1RVNjNVZGZ2NWbzIyN0dndmNLWllJZTFWK2NibVB1REY1?= =?utf-8?B?dEVMcks2Ym85bjF3YmJmL0E2eFovQlpvc1Z4cmZUMFM4djd5M01EMnNWY2FU?= =?utf-8?B?TmZEYTJzYU1MRFJJeXQ3SzIwbHNYNnN0UnREdzdjMXVjS056MGtISmlvdU9v?= =?utf-8?B?RXUzTjVKZGVPbkNSWE9OUnppMDN1RzJSMzJXdDgzRXhlRXFWMkF1L205czk2?= =?utf-8?B?Nmxac2xJb2Z0RUNwR25ia0hrRmQ5YWlCTFVSbkViSklqSEVDZDhtbjROQmV4?= =?utf-8?B?ZDhiMktiWVhIUjQrWjhkL3BtTjRLaGtOU2tCYXlJNDZEY2lrbTVTUVFoRC83?= =?utf-8?B?ZVl0Vkcra2VTRm4xNEYrTE5RQ2UyTE5tNHZ2Y29wWWNGMnRoU0N6WHdTUjF0?= =?utf-8?B?dlNTcmF1eTV4TENBd0RZV3RLTEJUemdnSFFObTI1WVR5dFZsOVVGWWJEMjc3?= =?utf-8?B?YWR0SHFxa1liSUpkZW9oM2tGUGRWMzBRMjhZdzJqS241R21Hemx0b0hFVGd5?= =?utf-8?B?YjMvWlBqY1l5eWlGZWZQSEhRcHc0SStuREhkb1hTWkw5QjF1eUVuT3VhZHhj?= =?utf-8?B?QmVLRFRKYVhROGVNTnhQK2F1M2h3ZXVjZXdoQ1RJeGJZUWU4WmgzbFVoajl2?= =?utf-8?B?OEJpYjI3eE5icm9JZERrWm1ueHpRVlpxS053RUFXRklxK0tUa0pIT2ZjT0VB?= =?utf-8?B?eVFCaTM5U1p0Wld2Wm1VVzJSZXY3SXhHWjFTLzNncTEyK3dKbHh3aVcwQ1g5?= =?utf-8?B?ME5vQnB0aWhDSC9yUHR1VS9YNTdOMzFkbGdxU2U3eEFNYkxRVXFxYmdpNExI?= =?utf-8?B?UC90MGhHVkdGd2drNUszalI0aHJZcG5WWUxGa0tKNHc3bjFWUUZBbDJvZzhL?= =?utf-8?B?dXlpTXkvUHVweXNVbzRuNEZWcTJZUXRKS1JpeTVnZnc1MklsUDlCcXBGbzRh?= =?utf-8?B?NnhEL09lZS8yVlJwbnlXc2JiOWZwblpDQWhDbGV4UnN1TEdORTNsNzBIZjgx?= =?utf-8?B?QSsyVkNrQW9BbjB2YzI5YzNrTUxSZ2YyQmxZOUl3RDBPbDJUL3dhR0RvcXJy?= =?utf-8?B?U2laWnZ4dWprV243MHpRNjFIaHFXU0lWYkZSTEdPVDJrYWFwTGRnSkx0bWVF?= =?utf-8?B?N3ZYOTYwT1NJRmtHYVd2WTEvOTcyUlQ3ZW5yc1ZyMElUeG5RVU94QnczOWsw?= =?utf-8?B?NkIyUUNIY0xFR3prTFRsdnB3WHpKUzMwT0d5dDduVmNKeWRCTklVWDM0UjRO?= =?utf-8?B?VmdMcGxiR3hqZEozRTB3dWZ5cWlQQ1I5TVdDTWdSNGZMdkp0YXE1dWU4eE15?= =?utf-8?B?Qmd5N3lKVGo2eVFiRC9SNEdSQUhOSUVSMVkyM29ONzFvQnN0NlJCM21NYkVt?= =?utf-8?B?QnBUZzF3SE5uMDIvZnBrS2lZdkxyQjBCSjNEbTJ5dTM0N0RsbFU5a0thK2ZE?= =?utf-8?B?bnJ3T0VTZERra254ZVB0OVVHOUpOQ0gvQ3B2Nk1uMlh1L2Z3em9ualh2Z0VH?= =?utf-8?B?d2NSenJFcXNvN2Y4MHNoTzFqeGR5QndocEp1a1dTRk9WVGlteGRhREk1eXpU?= =?utf-8?B?cHVDL0hmVG01T2JraWtGZTliVWVtN2JRT1MrL3ZEcWVqL0ZUT0tYblpqbkhz?= =?utf-8?B?eE1VOW5mbVpwVm1DSGdjZEpZT3hrdzVWQ3dsQ1NZMml5M2FvR3J6ZkJQUEI5?= =?utf-8?B?WURuWFZ5Y0R5MTI1dzRIZkpqY0ZPcnZVTkRWd1RVcTNmMFZ6eHVwcGx6Ynp1?= =?utf-8?B?SFRRNWw0UDdwanNPZlQ2MDZ1aFZnbHkvTGR3WktBR1JDZEpSQ0ZuLzZXV2Ns?= =?utf-8?B?a0Q2VDNXR3lQOGZnTVFseCtYRERlUG1SL2FGSVdRYlpWUEdqMmcwZkVjTUFD?= =?utf-8?B?RXU0OFk5N0dsN0NhMnZVWjMxMTFrSEpYOE94aHNJejg1bVBDZEJETFFsWjRy?= =?utf-8?B?Mys1czlUZTBNeWVRVXVBUHVST2l6NE5wb3JBdk1mejM3akcraUVQNnJITTlo?= =?utf-8?Q?xGFj8x6cX9eciT4FGc5bE8ikQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:eifXBK+0zxcjVBGl1DiE+oWsEKO7RvfJNboylVgNZhYn3FYMqTZs1BB9YT1x9ypn2ujPaH5iLD7RWApKgikVIRHYqzLlwIz3+QQCWJ/yuUD3z50omx9RHTOgTg+Fu49RG13XmZArl4sIvJP+SBzGBPDgR9vhNxS4W3scWmC79+hIIFDPnZNqpeezhYqU7U1PVaruPNWlzN7TF4GVmC4IQUeSJWekIh7q0OnWyVrAK2BTKrRoq5Mr0xGYk73nEfi984UscBnLbX4WHXaEVkAPpqMdpWM05YwWFSn/0RGDo2qKp8dGI/mkw1LSN41+CpshZ5HIvYCKROj4SY3aXB//8eq8N0ym5MIMwvYF1ioSwoc=; 5:XnkbCEYxDCjHlxm5ereMGqCKxDlfxqWs/c2PZhr+6MhFtrYD39J6X5g/rna1E0nF++i2tIS2b1QrXxl5W5bcJsX8wSvcOSTHTiyrhOScZNWnmcBQuYprt7CPvMZKWrVUSNI1LXpjT/PmGKJABq+Fq18YnaaVMb3KzulZjbv74DU=; 24:nSH/4pbv1l9KfBUXHV315tOAw23KqdWR5Q0dToY6wV6GotI/nIgUzu/+dPU+7zhCO5+Ms0sP6VLjopw487MqCp7ZUClIUOQo/6XjGZo8uLo=; 7:mzqN/rxSywwt1XPhpEBMB1RLIg4C51zJ8FRgdy70HsxK3lCFIQhsh3JMryj87gIwPiRhI1D4VDY8Kmk09Ib6od7C0FTz8ATQ/oMLUuXu1JHCii9K4UsKfIbMlReI+yEhZ0s/nckXRO39x7ypJ8RlEwPYSbU/YvIkRHvKZrfQA2YVOaAmHDdA7pkLQ5oLCemEfaPDHlUbrva2xwHcfwfjyC//k7FEnrx4/KE0SfGtqaOEvHge14djuGQfAuqWFnvS
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2017 11:05:52.6190 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 103515db-5e54-4d2e-7655-08d5332b5434
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 11:05:59 -0000



Tom Petch

----- Original Message -----
From: "Robert Wilton" 
Sent: Thursday, November 23, 2017 10:44 AM

> Hi Andy,
>
> On 22/11/2017 18:09, Andy Bierman wrote:
> > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> >
> >     Hi Rob,
> >
> >     At that points in time, if it clarifies the spec. and the
authors
> >     agree with this, let's do the right thing.
> >
> > I will add the new text if that is what the WG wants.

> Having read this draft, I was undecided what the intended behavior
> actually should be.
>
> The way that Yumapro and Tail-f have implemented this is reasonable,
and
> is probably also the way that I would implemented it.
>
> But I also think that it would be a reasonable implementation for a
> server to calculate the full change set (taking account of side
effects
> from when and choice statements) to the datastore before checking the
> "write data node access control" against the resultant change set.
>
> My interpretation is that the RFC text is ambiguous on what the
correct
> behavior is, and one could make a reasonable argument that the current
> RFC actually specifies that the alternative behavior is correct, i.e.
> requiring delete access even if a node is implicitly changes as a side
> effect. E.g. section 3.2.3 of RFC 6536 states:
>
>     If the protocol operation would result in the deletion of a
datastore
>     node and the user does not have "delete" access permission for
that
>     node, the protocol operation is rejected with an "access-denied"
>     error.

Rob

I have been reading that paragraph since this thread started and
wondering how it could be thought unclear, what am I missing:-)

To me it clearly states that the user must have the appropriate access
for the consequences of whatever they do, be that 'when', 'choice' or
anything else! Indeed, I see exactly that behaviour in operational
(non-network) databases of which I am a user with limited privileges.

My other thought was that given all the complexities of 'when' that
emerged during the specification of YANG 1.1, perhaps, were I an
implementor of this, I would take the easy option and ignore the side
effects of 'when'; but I might feel guilty about doing so.

If the new paragraphs go in as proposed, then I think that the two
paragraphs you quote need changing else that section looks to me like an
oxymoron.

Tom Petch

> An  request that causes a when constraint to evaluate
> differently does result in a deletion of those data nodes from the
> datastore, and hence according to the text above, requires explicit
> "delete" access permission to accomplish that.
>
> Clearly it would be an interop issue if different servers implemented
> the NACM path based filtering differently.
>
> Hence why I think that it would be prudent for the draft to be more
> explicit on when and choice statement handling.
>
> Rob
>
> > There have not been any comments on this issue.
> >
> > Andy
> >
> >     Regards, Benoit.
> >>
> >>     Hi Benoit,
> >>
> >>     There is also one further, unrelated change that I am proposing
> >>     is made the draft before it is published, to help better
clarify
> >>     the expected behavior. It isn't the end of the world if this
> >>     doesn't go in, but I think that it prevents sometime taking a
> >>     different, but IMO reasonable, interpretation of how "when"
> >>     statements are considered, and then having a future argument
> >>     about what behavior it specified in the standard.
> >>
> >>     If we clarify it now, then it closes that door :-)
> >>
> >>     I've proposed text to Andy and Martin on Monday, but I've not
> >>     heard back yet.
> >>
> >>     Netconf email with proposed text attached. The text doesn't
> >>     necessarily have to match this, but personally I think that it
is
> >>     useful if the draft says something on this.
> >>
> >>     Thanks,
> >>     Rob
> >>
> >>
> >>     On 22/11/2017 13:25, Benoit Claise wrote:
> >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> >>>>     Hi,
> >>>>
> >>>>     Here are some proposed edits to make the data rule consistent
> >>>>     with the examples.
> >>>>     Note that this issue is not related to the edit in the
original
> >>>>     1-week change.
> >>>     That's right, but we found a source of misinterpretation in
the
> >>>     draft and you have rightly corrected it in the github v9.
> >>>
> >>>     Regards, Benoit
> >>>>
> >>>>
> >>>>     sec. 3.3.5:
> >>>>
> >>>>     OLD:
> >>>>
> >>>>
> >>>>     data node rule: controls access for a specific data
> >>>>     node, identified
> >>>>     by its path location within the conceptual XML document
> >>>>     for the
> >>>>     data node.
> >>>>
> >>>>
> >>>>     NEW:
> >>>>
> >>>>     data node rule: controls access for a specific data node
> >>>>     and its descendants,
> >>>>     identified by its path location within the conceptual XML
> >>>>     document for the
> >>>>     data node.
> >>>>
> >>>>
> >>>>     sec 3.4.5, step 6, bullet 2:
> >>>>
> >>>>
> >>>>     OLD:
> >>>>
> >>>>     * The rule does not have a "rule-type" defined or the
> >>>>     "rule-
> >>>>     type" is "data-node" and the "path" matches the
> >>>>     requested
> >>>>     data node, action node, or notification node.
> >>>>
> >>>>     NEW:
> >>>>     * The rule does not have a "rule-type" defined or the
> >>>>     "rule-
> >>>>     type" is "data-node" and the "path" matches the
> >>>>     requested
> >>>>     data node, action node, or notification node. A path is
> >>>>     considered to match if the current data node is the
> >>>>     data node
> >>>>     specified by the path, or is a descendant data node
> >>>>     of this data node.
> >>>>     appendix B.4: (2 bugs in explanation)
> >>>>     OLD:
> >>>>     deny-nacm: This rule denies the "guest" group any access to
the
> >>>>      subtree. Note that the default namespace is only
> >>>>     applicable because this subtree is defined in the same
> >>>>     namespace as the  element.
> >>>>     NEW:
> >>>>     deny-nacm: This rule denies the "guest" group any access to
the
> >>>>      subtree.
> >>>>     Andy
> >>>>
> >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> >>>>     > wrote:
> >>>>
> >>>>
> >>>>
> >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> >>>>>
> >>>>>
> >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> >>>>>         > wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> >>>>>>
> >>>>>>



From nobody Fri Nov 24 07:30:10 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC4128891 for ; Fri, 24 Nov 2017 07:30:09 -0800 (PST)
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 btclwYFdPAKa for ; Fri, 24 Nov 2017 07:30:07 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 C347A128854 for ; Fri, 24 Nov 2017 07:30:06 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id x68so25913012lff.0 for ; Fri, 24 Nov 2017 07:30:06 -0800 (PST)
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=Y5t2Tdqku+t7/LPTN9cHNU0kWoXVyhQuFHUvHjg6dOM=; b=cmG/SxsSGAYBQ0QkK7br3kleSMPCinr99QtSQFgLNWIQXDlXTLt9TF8IYr739G3JYR Gh+zvyFBDMPKQ46CuqZ8iytR7+q+zXNkcGyIRbmlEULKQlIhXGuZmU7ATATGMu8LuGmF 4Wy9Jpg2emhWWg01yziDexXf5l1CcABU6/odrbjVUFuCIer+qxSjJ44R0j989vb6Edza g9qGuRrXmJ3GHoXT6twaoLsaqKO2NnZDJgpXZTI5HhSG9euUAzvqygz1SHooj93HdnLa cHBk1yZP533yOvnqe/1OXuA+QpvUwSevpkhadSPQenddMd0s3u940gIz8II/iufYBJXU iwrg==
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=Y5t2Tdqku+t7/LPTN9cHNU0kWoXVyhQuFHUvHjg6dOM=; b=WvdpmtuZFl5TrfLgfJv8CFFBWbtCUxWPgnocHzlJTJg5wtoFaKEgpOZzpMYQvqpYiE /UY4OwIEcXrGOrT/7bT0ovZ68XKwftWDZc5kzQAQsW99Iglh+4NcBymDLNZG6m6A72EH lQLGH22hKVoJonHL+kXTSw7y/3GVfTMd/nbIj8OAbqCq+yhy1P1xOUPP+gS2HHqwCQJ1 NYYyFybeXi2BZvMA1nwDNcFcb/HKIzYobh2navpo1rSZSBxGHUUkxhyCDA62SZUQQ7Tc 9YdOudrJEq8Pi8Tc0HpcKc4kYcK4aV/jxgCgc84aSrJ81o/Wyg91FOfFAsH2X00BkAVi 6Z/Q==
X-Gm-Message-State: AJaThX5c49v43Pcl+9/KxyERvoKzcA20igNDVLM80oDrUWKLeLNa4+cK MEvmkNl4f/7l0Oxtp/d10feeo2aWX/BPXh63wiFINg==
X-Google-Smtp-Source: AGs4zMZImzvuxX79JJOBBiA0L3vUZYIBXseHZm/lJvzn6/QZqUPzQXNek/1DQPa6gQHdAN1cCwjdash7KyjKaFer7ho=
X-Received: by 10.25.225.140 with SMTP id l12mr10099481lfk.106.1511537404942;  Fri, 24 Nov 2017 07:30:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Fri, 24 Nov 2017 07:30:03 -0800 (PST)
In-Reply-To: <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com>  <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>
From: Andy Bierman 
Date: Fri, 24 Nov 2017 07:30:03 -0800
Message-ID: 
To: "t.petch" 
Cc: NETCONF , Robert Wilton , sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="001a113c2f46163370055ebc3a25"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 15:30:09 -0000

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

On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:

> 
>
> Tom Petch
>
> ----- Original Message -----
> From: "Robert Wilton" 
> Sent: Thursday, November 23, 2017 10:44 AM
>
> > Hi Andy,
> >
> > On 22/11/2017 18:09, Andy Bierman wrote:
> > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > >
> > >     Hi Rob,
> > >
> > >     At that points in time, if it clarifies the spec. and the
> authors
> > >     agree with this, let's do the right thing.
> > >
> > > I will add the new text if that is what the WG wants.
>
> > Having read this draft, I was undecided what the intended behavior
> > actually should be.
> >
> > The way that Yumapro and Tail-f have implemented this is reasonable,
> and
> > is probably also the way that I would implemented it.
> >
> > But I also think that it would be a reasonable implementation for a
> > server to calculate the full change set (taking account of side
> effects
> > from when and choice statements) to the datastore before checking the
> > "write data node access control" against the resultant change set.
> >
> > My interpretation is that the RFC text is ambiguous on what the
> correct
> > behavior is, and one could make a reasonable argument that the current
> > RFC actually specifies that the alternative behavior is correct, i.e.
> > requiring delete access even if a node is implicitly changes as a side
> > effect. E.g. section 3.2.3 of RFC 6536 states:
> >
> >     If the protocol operation would result in the deletion of a
> datastore
> >     node and the user does not have "delete" access permission for
> that
> >     node, the protocol operation is rejected with an "access-denied"
> >     error.
>
> Rob
>
> I have been reading that paragraph since this thread started and
> wondering how it could be thought unclear, what am I missing:-)
>
> To me it clearly states that the user must have the appropriate access
> for the consequences of whatever they do, be that 'when', 'choice' or
> anything else! Indeed, I see exactly that behaviour in operational
> (non-network) databases of which I am a user with limited privileges.
>
>

This is not correct.
The server is the entity that is cleaning up false when-stmt or unselected
cases
for a choice-stmt.

NACM does not prevent the sever from making any changes to the system.
It only affects the operations requested by a client.


Andy


> My other thought was that given all the complexities of 'when' that
> emerged during the specification of YANG 1.1, perhaps, were I an
> implementor of this, I would take the easy option and ignore the side
> effects of 'when'; but I might feel guilty about doing so.
>
> If the new paragraphs go in as proposed, then I think that the two
> paragraphs you quote need changing else that section looks to me like an
> oxymoron.
>
> Tom Petch
>
> > An  request that causes a when constraint to evaluate
> > differently does result in a deletion of those data nodes from the
> > datastore, and hence according to the text above, requires explicit
> > "delete" access permission to accomplish that.
> >
> > Clearly it would be an interop issue if different servers implemented
> > the NACM path based filtering differently.
> >
> > Hence why I think that it would be prudent for the draft to be more
> > explicit on when and choice statement handling.
> >
> > Rob
> >
> > > There have not been any comments on this issue.
> > >
> > > Andy
> > >
> > >     Regards, Benoit.
> > >>
> > >>     Hi Benoit,
> > >>
> > >>     There is also one further, unrelated change that I am proposing
> > >>     is made the draft before it is published, to help better
> clarify
> > >>     the expected behavior. It isn't the end of the world if this
> > >>     doesn't go in, but I think that it prevents sometime taking a
> > >>     different, but IMO reasonable, interpretation of how "when"
> > >>     statements are considered, and then having a future argument
> > >>     about what behavior it specified in the standard.
> > >>
> > >>     If we clarify it now, then it closes that door :-)
> > >>
> > >>     I've proposed text to Andy and Martin on Monday, but I've not
> > >>     heard back yet.
> > >>
> > >>     Netconf email with proposed text attached. The text doesn't
> > >>     necessarily have to match this, but personally I think that it
> is
> > >>     useful if the draft says something on this.
> > >>
> > >>     Thanks,
> > >>     Rob
> > >>
> > >>
> > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > >>>>     Hi,
> > >>>>
> > >>>>     Here are some proposed edits to make the data rule consistent
> > >>>>     with the examples.
> > >>>>     Note that this issue is not related to the edit in the
> original
> > >>>>     1-week change.
> > >>>     That's right, but we found a source of misinterpretation in
> the
> > >>>     draft and you have rightly corrected it in the github v9.
> > >>>
> > >>>     Regards, Benoit
> > >>>>
> > >>>>
> > >>>>     sec. 3.3.5:
> > >>>>
> > >>>>     OLD:
> > >>>>
> > >>>>
> > >>>>     data node rule: controls access for a specific data
> > >>>>     node, identified
> > >>>>     by its path location within the conceptual XML document
> > >>>>     for the
> > >>>>     data node.
> > >>>>
> > >>>>
> > >>>>     NEW:
> > >>>>
> > >>>>     data node rule: controls access for a specific data node
> > >>>>     and its descendants,
> > >>>>     identified by its path location within the conceptual XML
> > >>>>     document for the
> > >>>>     data node.
> > >>>>
> > >>>>
> > >>>>     sec 3.4.5, step 6, bullet 2:
> > >>>>
> > >>>>
> > >>>>     OLD:
> > >>>>
> > >>>>     * The rule does not have a "rule-type" defined or the
> > >>>>     "rule-
> > >>>>     type" is "data-node" and the "path" matches the
> > >>>>     requested
> > >>>>     data node, action node, or notification node.
> > >>>>
> > >>>>     NEW:
> > >>>>     * The rule does not have a "rule-type" defined or the
> > >>>>     "rule-
> > >>>>     type" is "data-node" and the "path" matches the
> > >>>>     requested
> > >>>>     data node, action node, or notification node. A path is
> > >>>>     considered to match if the current data node is the
> > >>>>     data node
> > >>>>     specified by the path, or is a descendant data node
> > >>>>     of this data node.
> > >>>>     appendix B.4: (2 bugs in explanation)
> > >>>>     OLD:
> > >>>>     deny-nacm: This rule denies the "guest" group any access to
> the
> > >>>>      subtree. Note that the default namespace is only
> > >>>>     applicable because this subtree is defined in the same
> > >>>>     namespace as the  element.
> > >>>>     NEW:
> > >>>>     deny-nacm: This rule denies the "guest" group any access to
> the
> > >>>>      subtree.
> > >>>>     Andy
> > >>>>
> > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > >>>>     > wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > >>>>>
> > >>>>>
> > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > >>>>>         > wrote:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > >>>>>>
> > >>>>>>
> 
>
>

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




On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com&g=
t; wrote:
<inline>



Tom Petch



----- Original Message -----

From: "Robert Wilton" <rw=
ilton@cisco.com>

Sent: Thursday, November 23, 2017 10:44 AM



> Hi Andy,

>

> On 22/11/2017 18:09, Andy Bierman wrote:

> > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:

> >

> >=C2=A0 =C2=A0 =C2=A0Hi Rob,

> >

> >=C2=A0 =C2=A0 =C2=A0At that points in time, if it clarifies the sp=
ec. and the

authors

> >=C2=A0 =C2=A0 =C2=A0agree with this, let's do the right thing.=


> >

> > I will add the new text if that is what the WG wants.



> Having read this draft, I was undecided what the intended behavior

> actually should be.

>

> The way that Yumapro and Tail-f have implemented this is reasonable,
and

> is probably also the way that I would implemented it.

>

> But I also think that it would be a reasonable implementation for a
> server to calculate the full change set (taking account of side

effects

> from when and choice statements) to the datastore before checking the<=
br>
> "write data node access control" against the resultant chang=
e set.

>

> My interpretation is that the RFC text is ambiguous on what the

correct

> behavior is, and one could make a reasonable argument that the current=


> RFC actually specifies that the alternative behavior is correct, i.e.<=
br>
> requiring delete access even if a node is implicitly changes as a side=


> effect. E.g. section 3.2.3 of RFC 6536 states:

>

>=C2=A0 =C2=A0 =C2=A0If the protocol operation would result in the delet=
ion of a

datastore

>=C2=A0 =C2=A0 =C2=A0node and the user does not have "delete" =
access permission for

that

>=C2=A0 =C2=A0 =C2=A0node, the protocol operation is rejected with an &q=
uot;access-denied"

>=C2=A0 =C2=A0 =C2=A0error.



Rob



I have been reading that paragraph since this thread started and

wondering how it could be thought unclear, what am I missing:-)



To me it clearly states that the user must have the appropriate access

for the consequences of whatever they do, be that 'when', 'choi=
ce' or

anything else! Indeed, I see exactly that behaviour in operational

(non-network) databases of which I am a user with limited privileges.




This is not correct.
The server is the entity that is cleaning up false when-stmt or uns=
elected cases
for a choice-stmt.

NACM do=
es not prevent the sever from making any changes to the system.
I=
t only affects the operations requested by a client.


Andy
=C2=A0

My other thought was that given all the complexities of 'when' that=


emerged during the specification of YANG 1.1, perhaps, were I an

implementor of this, I would take the easy option and ignore the side

effects of 'when'; but I might feel guilty about doing so.



If the new paragraphs go in as proposed, then I think that the two

paragraphs you quote need changing else that section looks to me like an
oxymoron.



Tom Petch



> An <edit-data> request that causes a when constraint to evaluate=


> differently does result in a deletion of those data nodes from the

> datastore, and hence according to the text above, requires explicit
> "delete" access permission to accomplish that.

>

> Clearly it would be an interop issue if different servers implemented<=
br>
> the NACM path based filtering differently.

>

> Hence why I think that it would be prudent for the draft to be more
> explicit on when and choice statement handling.

>

> Rob

>

> > There have not been any comments on this issue.

> >

> > Andy

> >

> >=C2=A0 =C2=A0 =C2=A0Regards, Benoit.

> >>

> >>=C2=A0 =C2=A0 =C2=A0Hi Benoit,

> >>

> >>=C2=A0 =C2=A0 =C2=A0There is also one further, unrelated chang=
e that I am proposing

> >>=C2=A0 =C2=A0 =C2=A0is made the draft before it is published, =
to help better

clarify

> >>=C2=A0 =C2=A0 =C2=A0the expected behavior. It isn't the en=
d of the world if this

> >>=C2=A0 =C2=A0 =C2=A0doesn't go in, but I think that it pre=
vents sometime taking a

> >>=C2=A0 =C2=A0 =C2=A0different, but IMO reasonable, interpretat=
ion of how "when"

> >>=C2=A0 =C2=A0 =C2=A0statements are considered, and then having=
 a future argument

> >>=C2=A0 =C2=A0 =C2=A0about what behavior it specified in the st=
andard.

> >>

> >>=C2=A0 =C2=A0 =C2=A0If we clarify it now, then it closes that =
door :-)

> >>

> >>=C2=A0 =C2=A0 =C2=A0I've proposed text to Andy and Martin =
on Monday, but I've not

> >>=C2=A0 =C2=A0 =C2=A0heard back yet.

> >>

> >>=C2=A0 =C2=A0 =C2=A0Netconf email with proposed text attached.=
 The text doesn't

> >>=C2=A0 =C2=A0 =C2=A0necessarily have to match this, but person=
ally I think that it

is

> >>=C2=A0 =C2=A0 =C2=A0useful if the draft says something on this=
.

> >>

> >>=C2=A0 =C2=A0 =C2=A0Thanks,

> >>=C2=A0 =C2=A0 =C2=A0Rob

> >>

> >>

> >>=C2=A0 =C2=A0 =C2=A0On 22/11/2017 13:25, Benoit Claise wrote:<=
br>
> >>>=C2=A0 =C2=A0 =C2=A0On 11/10/2017 7:23 PM, Andy Bierman wr=
ote:

> >>>>=C2=A0 =C2=A0 =C2=A0Hi,

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0Here are some proposed edits to ma=
ke the data rule consistent

> >>>>=C2=A0 =C2=A0 =C2=A0with the examples.

> >>>>=C2=A0 =C2=A0 =C2=A0Note that this issue is not relate=
d to the edit in the

original

> >>>>=C2=A0 =C2=A0 =C2=A01-week change.

> >>>=C2=A0 =C2=A0 =C2=A0That's right, but we found a sourc=
e of misinterpretation in

the

> >>>=C2=A0 =C2=A0 =C2=A0draft and you have rightly corrected i=
t in the github v9.

> >>>

> >>>=C2=A0 =C2=A0 =C2=A0Regards, Benoit

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0sec. 3.3.5:

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0data node rule: controls access fo=
r a specific data

> >>>>=C2=A0 =C2=A0 =C2=A0node, identified

> >>>>=C2=A0 =C2=A0 =C2=A0by its path location within the co=
nceptual XML document

> >>>>=C2=A0 =C2=A0 =C2=A0for the

> >>>>=C2=A0 =C2=A0 =C2=A0data node.

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0data node rule: controls access fo=
r a specific data node

> >>>>=C2=A0 =C2=A0 =C2=A0and its descendants,

> >>>>=C2=A0 =C2=A0 =C2=A0identified by its path location wi=
thin the conceptual XML

> >>>>=C2=A0 =C2=A0 =C2=A0document for the

> >>>>=C2=A0 =C2=A0 =C2=A0data node.

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0sec 3.4.5, step 6, bullet 2:

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0* The rule does not have a "r=
ule-type" defined or the

> >>>>=C2=A0 =C2=A0 =C2=A0"rule-

> >>>>=C2=A0 =C2=A0 =C2=A0type" is "data-node"=
; and the "path" matches the

> >>>>=C2=A0 =C2=A0 =C2=A0requested

> >>>>=C2=A0 =C2=A0 =C2=A0data node, action node, or notific=
ation node.

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> >>>>=C2=A0 =C2=A0 =C2=A0* The rule does not have a "r=
ule-type" defined or the

> >>>>=C2=A0 =C2=A0 =C2=A0"rule-

> >>>>=C2=A0 =C2=A0 =C2=A0type" is "data-node"=
; and the "path" matches the

> >>>>=C2=A0 =C2=A0 =C2=A0requested

> >>>>=C2=A0 =C2=A0 =C2=A0data node, action node, or notific=
ation node. A path is

> >>>>=C2=A0 =C2=A0 =C2=A0considered to match if the current=
 data node is the

> >>>>=C2=A0 =C2=A0 =C2=A0data node

> >>>>=C2=A0 =C2=A0 =C2=A0specified by the path, or is a des=
cendant data node

> >>>>=C2=A0 =C2=A0 =C2=A0of this data node.

> >>>>=C2=A0 =C2=A0 =C2=A0appendix B.4: (2 bugs in explanati=
on)

> >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm: This rule denies the &q=
uot;guest" group any access to

the

> >>>>=C2=A0 =C2=A0 =C2=A0<nacm> subtree. Note that th=
e default namespace is only

> >>>>=C2=A0 =C2=A0 =C2=A0applicable because this subtree is=
 defined in the same

> >>>>=C2=A0 =C2=A0 =C2=A0namespace as the <data-rule>=
 element.

> >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm: This rule denies the &q=
uot;guest" group any access to

the

> >>>>=C2=A0 =C2=A0 =C2=A0<nacm> subtree.

> >>>>=C2=A0 =C2=A0 =C2=A0Andy

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 10, 2017 at 9:24 AM, R=
obert Wilton

> >>>>=C2=A0 =C2=A0 =C2=A0<rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:

> >>>>

> >>>>

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 10/11/2017 16:33,=
 Andy Bierman wrote:

> >>>>>

> >>>>>

> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 10, =
2017 at 8:16 AM, Robert Wilton

> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:

> >>>>>

> >>>>>

> >>>>>

> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On=
 10/11/2017 15:49, Andy Bierman wrote:

> >>>>>>

> >>>>>>

<snip>







--001a113c2f46163370055ebc3a25--


From nobody Fri Nov 24 09:34:07 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BD1128854 for ; Fri, 24 Nov 2017 09:34:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoUtNVdC1sJL for ; Fri, 24 Nov 2017 09:34:05 -0800 (PST)
Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) (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 3B5411276AF for ; Fri, 24 Nov 2017 09:34:05 -0800 (PST)
Received: by mail-pg0-f49.google.com with SMTP id s75so15734165pgs.0 for ; Fri, 24 Nov 2017 09:34:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9q7MbggQUqbl2KZBTLMY4t9s95mK7+c/TPilmQSV8l8=; b=Ji3ikBBhFZEQ+bBy+u2BHpAL8wtqpY4YSddNU+TcsQ+D+aGxu+HsCpgTFR02cLOvqL R378Fap2ieVXvzbNVtgaVBJhFJNnOcvKma/zWaNYWEjAvRHv0HojLPpydiyX2dbvzr4F FjU3OEoc/zcZY2AZuA/EBrCafuPkibMz8i+S2Cp9mz/FrcI71ZFJYn1J9Yk3wVxgQpkm tYROj6yoeTN9vuI8eW/uMuTqxmle1UOGO/KKmZvxlhke3rBnUST1QL822XS4J0L3sp6o qNxkkEPeMK0Q565bDveOmOeHytH0zxUrnOY+mXhlL3aAjmbYctapMeZA5w37khtNNQ92 wdIA==
X-Gm-Message-State: AJaThX5S9TNM4Grl6vxXzoLawn2xmKADPUvLNrART91XlXKSacdchvr0 wxCN8VRBA2UJjjYePpEfZYkX86LcyU8=
X-Google-Smtp-Source: AGs4zMZWQR8wu1tWZYT3Hf89sTs6Q0QgILeBl+3iZAM4Q9JZSPbZfB1kJNPBXADl/2DwFOyOs1/QEg==
X-Received: by 10.101.65.129 with SMTP id a1mr28744564pgq.203.1511544844390; Fri, 24 Nov 2017 09:34:04 -0800 (PST)
Received: from [192.168.1.101] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id s11sm19718962pgn.80.2017.11.24.09.34.03 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 09:34:03 -0800 (PST)
To: netconf@ietf.org
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net> 
From: Randy Presuhn 
Message-ID: 
Date: Fri, 24 Nov 2017 09:34:03 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 17:34:06 -0000

Hi -

Tom wrote:
>     To me it clearly states that the user must have the appropriate access
>     for the consequences of whatever they do, be that 'when', 'choice' or
>     anything else! Indeed, I see exactly that behaviour in operational
>     (non-network) databases of which I am a user with limited privileges.

Andy replied:
> This is not correct.
> The server is the entity that is cleaning up false when-stmt or 
> unselected cases
> for a choice-stmt.
> 
> NACM does not prevent the sever from making any changes to the system.
> It only affects the operations requested by a client.

I think the point is that lots of Rube Goldberg / domino effect attacks
are made possible through management interfaces.  Sometimes
they are subtle, sometimes they're a result of explicit side-
effects in the definition of management information.  I think the
real question here is who is responsible for working through and
*documenting* such security consequences, and, subsequently, whether
the access control interface should deal them automagically (not
suggesting it's impossible, but there are aspects that could be hard)
or that figuring out the interconnections should be an exercise left
to the imagination of security administrators.

The former approach reduces the operational workload, but means more
complexity for standardizers and for the folks implementing the
access control infrastructure.  It also carries the risk of people
becoming over-confident that the standardizers' analysis might be
correct.  The latter approach requires hoping that every system's
security administrator will carry out an analysis of the side-effects
and correctly formulate access control policies that will do the right
things.  This carries the risks that the analysis will seldom happen,
and that the formulation of explicit access control policies to
account for side-effects is likely error-prone for garden-variety
administrators.

Pick your poison.

Randy


From nobody Fri Nov 24 10:01:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0996C12773A for ; Fri, 24 Nov 2017 10:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 GWITXBMHZfUP for ; Fri, 24 Nov 2017 10:01:06 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B999128B93 for ; Fri, 24 Nov 2017 10:01:05 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id d10so15215383lfj.7 for ; Fri, 24 Nov 2017 10:01:05 -0800 (PST)
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=dIyxhjyKsZLjnh/evL0+dWfBEURPCT0gCRgUe6zVsT0=; b=zgIC/6wRwcbZyKLDjudVCqkeWc3G1NEHNp7zrdHl73uQcGsIyql5RiDqbEKg+Gohs2 ERjcIbg0mSRLon1f90YzEyv1RJJ82AjM9Mh7uYLgWVvN4H7wKX+WSyOwoKIbW50UyPzh KEannh9GGJf6u6yT1zZdKtVTH5k+2evIrg5oJyS4rtbX+KMuit6t0IYB7OaGQLB3QbAN Dpzo+iuOgwwRSgikUxNlAWDvqpEsPera/7wPlx99tizVSSHB6e+zhtZ+VnNf629r+f3A F7ZSqpZHPgLKupIql0UYz9pyKipOvry8VWKsCiB5fJRZv2PTcu/0MBj18dwv6x3UwLIy s44g==
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=dIyxhjyKsZLjnh/evL0+dWfBEURPCT0gCRgUe6zVsT0=; b=Zp2YY82vZasmzdK+nL/LLDPc3//4bhrtb5O7cNctYgsN4xNzKsh6NNxFRGzO9pybT0 +/ctXgEBNhCsCuj7kdnvXPxxHQyVKVx1xBtjlHdvP/AWIQNnkgxRUhzyVLMrFDHn8VDi eVrhox4h/wi5Nd+9OA561Vxxl0zuRbOVhKZfuLhZHuP+ZAc2QAPhvZNl/8hLpSJu42K5 l2/pFoKjlysM+yte3v+ZeswVqHv29N9zXfjuVueq2DuqkerEL28FhuWZEC99rnry3Z4+ JXtctqHEwkpo0/S1NGCP6JWR07/EWczjjqaQWmOluyhT5UcOW5bdIsRPFCvevoaCY6kq OCGw==
X-Gm-Message-State: AJaThX7BwNsk0c6BTw71yiAl89L2306rTw7CoWQej+H2S1fmiuJskmsX 4szRfy8x2RFud6CZr3wqVgx27O8JFvS7XMTJFTe7bA==
X-Google-Smtp-Source: AGs4zMZmBuWNMbnEisEKPySBXLpwJUnMw2l5+upgLUIjvPnlb4MhVSUFJgpNT2pTogOom11b+p5C0dsWHt/9WdQ4q2U=
X-Received: by 10.25.142.5 with SMTP id q5mr9304900lfd.19.1511546463603; Fri, 24 Nov 2017 10:01:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Fri, 24 Nov 2017 10:01:01 -0800 (PST)
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  
From: Andy Bierman 
Date: Fri, 24 Nov 2017 10:01:01 -0800
Message-ID: 
To: Randy Presuhn 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="f403045f509806654b055ebe5652"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 18:01:08 -0000

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

On Fri, Nov 24, 2017 at 9:34 AM, Randy Presuhn <
randy_presuhn@alumni.stanford.edu> wrote:

> Hi -
>
> Tom wrote:
>
>>     To me it clearly states that the user must have the appropriate access
>>     for the consequences of whatever they do, be that 'when', 'choice' or
>>     anything else! Indeed, I see exactly that behaviour in operational
>>     (non-network) databases of which I am a user with limited privileges.
>>
>
> Andy replied:
>
>> This is not correct.
>> The server is the entity that is cleaning up false when-stmt or
>> unselected cases
>> for a choice-stmt.
>>
>> NACM does not prevent the sever from making any changes to the system.
>> It only affects the operations requested by a client.
>>
>
> I think the point is that lots of Rube Goldberg / domino effect attacks
> are made possible through management interfaces.  Sometimes
> they are subtle, sometimes they're a result of explicit side-
> effects in the definition of management information.  I think the
> real question here is who is responsible for working through and
> *documenting* such security consequences, and, subsequently, whether
> the access control interface should deal them automagically (not
> suggesting it's impossible, but there are aspects that could be hard)
> or that figuring out the interconnections should be an exercise left
> to the imagination of security administrators.
>
> The former approach reduces the operational workload, but means more
> complexity for standardizers and for the folks implementing the
> access control infrastructure.  It also carries the risk of people
> becoming over-confident that the standardizers' analysis might be
> correct.  The latter approach requires hoping that every system's
> security administrator will carry out an analysis of the side-effects
> and correctly formulate access control policies that will do the right
> things.  This carries the risks that the analysis will seldom happen,
> and that the formulation of explicit access control policies to
> account for side-effects is likely error-prone for garden-variety
> administrators.
>
> Pick your poison.
>
>

One of the design goals of NACM was to keep it simple to use.
There was a perception that VACM was too difficult to use,
and that's why it was not widely deployed.

I think the security considerations section for each YANG module RFC
should point out the linkage issues from when-stmt and choice-stmt.
The design goal should be to permit or deny access to an entire module.
The suggested granularity should be documented if any data-rules
are expected for normal operation.


Randy
>
>
Andy


> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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




On Fri, Nov 24, 2017 at 9:34 AM, Randy Presuhn <randy_=
presuhn@alumni.stanford.edu> wrote:
Hi -



Tom wrote:



=C2=A0 =C2=A0 To me it clearly states that the user must have the appropria=
te access

=C2=A0 =C2=A0 for the consequences of whatever they do, be that 'when&#=
39;, 'choice' or

=C2=A0 =C2=A0 anything else! Indeed, I see exactly that behaviour in operat=
ional

=C2=A0 =C2=A0 (non-network) databases of which I am a user with limited pri=
vileges.





Andy replied:



This is not correct.

The server is the entity that is cleaning up false when-stmt or unselected =
cases

for a choice-stmt.



NACM does not prevent the sever from making any changes to the system.

It only affects the operations requested by a client.





I think the point is that lots of Rube Goldberg / domino effect attacks

are made possible through management interfaces.=C2=A0 Sometimes

they are subtle, sometimes they're a result of explicit side-

effects in the definition of management information.=C2=A0 I think the

real question here is who is responsible for working through and

*documenting* such security consequences, and, subsequently, whether

the access control interface should deal them automagically (not

suggesting it's impossible, but there are aspects that could be hard)
or that figuring out the interconnections should be an exercise left

to the imagination of security administrators.



The former approach reduces the operational workload, but means more

complexity for standardizers and for the folks implementing the

access control infrastructure.=C2=A0 It also carries the risk of people

becoming over-confident that the standardizers' analysis might be

correct.=C2=A0 The latter approach requires hoping that every system's<=
br>
security administrator will carry out an analysis of the side-effects

and correctly formulate access control policies that will do the right

things.=C2=A0 This carries the risks that the analysis will seldom happen,<=
br>
and that the formulation of explicit access control policies to

account for side-effects is likely error-prone for garden-variety

administrators.



Pick your poison.




One of the design goals=
 of NACM was to keep it simple to use.
There was a perception tha=
t VACM was too difficult to use,
and that's why it was not wi=
dely deployed.

I think the security considerations=
 section for each YANG module RFC
should point out the linkage is=
sues from when-stmt and choice-stmt.
The design goal should be to=
 permit or deny access to an entire module.
The suggested granula=
rity should be documented if any data-rules
are expected for norm=
al operation.



Randy



Andy
=C2=A0

_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf<=
br>




--f403045f509806654b055ebe5652--


From nobody Fri Nov 24 11:33:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12791292F4 for ; Fri, 24 Nov 2017 11:33:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak2VfstYlhcQ for ; Fri, 24 Nov 2017 11:33:03 -0800 (PST)
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50]) (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 AABD31200C5 for ; Fri, 24 Nov 2017 11:33:03 -0800 (PST)
Received: by mail-pg0-f50.google.com with SMTP id m4so5971718pgc.4 for ; Fri, 24 Nov 2017 11:33:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nogPH7xBXBIhuDDlg+zsFtT9RaZ33oUb+22dOJYurZY=; b=FFwj5+zgRDdZ4W8igz9D1OlBjR/AV/JSU/ccax8AnhrzEAR6NS46hW3OGD7+19ZmE+ shBFhUPvZrDxSFiyYDEjGjBp5jhOZqTM1UZGNwAPH1GHEbIATIhUxorsDHpqKOVWwWLJ s3cduaUtE99Ji73frrwDvi/z66/REdh2dgrlzZVCUiDXtPXEvstQRKCxzbZcR1qRoMsH sV5GYM/dos90IVCAj+jxT93yuzMwtxGI4MzC2TcTpchyRs3aW5G6MJfXhiYzhefLHwhT GtvFPExLA3jmvB9hw7/vspLsFzOo+7GqzWDiVvYDTdJF45IKoHs3kMdfDLJ8QzEWql0g Gaxg==
X-Gm-Message-State: AJaThX68UVntXq45WZ58qHFdR3DpGKM6DGq0tYuiDS5Yewf6TQOUflRM nzbhP45Ru2TpeAWohRt3EfEK0vIUFH0=
X-Google-Smtp-Source: AGs4zMbbCgScOaivojvJDA5qepe9wB76zPYesQzEXosnqQA7K0WehU/eHD4+cqWAu0r++zdlxxQkDA==
X-Received: by 10.99.95.13 with SMTP id t13mr28515687pgb.448.1511551982754; Fri, 24 Nov 2017 11:33:02 -0800 (PST)
Received: from [192.168.1.101] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id a87sm40671040pfg.159.2017.11.24.11.33.01 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 11:33:02 -0800 (PST)
To: Netconf 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>   
From: Randy Presuhn 
Message-ID: <441ad7d8-a1d4-4ea3-7b2c-0bfd6efb2b01@alumni.stanford.edu>
Date: Fri, 24 Nov 2017 11:33:01 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 19:33:05 -0000

Hi -

On 11/24/2017 10:01 AM, Andy Bierman wrote:
> 
> 
> On Fri, Nov 24, 2017 at 9:34 AM, Randy Presuhn 
>  > wrote:
> 
>     Hi -
> 
>     Tom wrote:
> 
>              To me it clearly states that the user must have the
>         appropriate access
>              for the consequences of whatever they do, be that 'when',
>         'choice' or
>              anything else! Indeed, I see exactly that behaviour in
>         operational
>              (non-network) databases of which I am a user with limited
>         privileges.
> 
> 
>     Andy replied:
> 
>         This is not correct.
>         The server is the entity that is cleaning up false when-stmt or
>         unselected cases
>         for a choice-stmt.
> 
>         NACM does not prevent the sever from making any changes to the
>         system.
>         It only affects the operations requested by a client.
> 
> 
>     I think the point is that lots of Rube Goldberg / domino effect attacks
>     are made possible through management interfaces.  Sometimes
>     they are subtle, sometimes they're a result of explicit side-
>     effects in the definition of management information.  I think the
>     real question here is who is responsible for working through and
>     *documenting* such security consequences, and, subsequently, whether
>     the access control interface should deal them automagically (not
>     suggesting it's impossible, but there are aspects that could be hard)
>     or that figuring out the interconnections should be an exercise left
>     to the imagination of security administrators.
> 
>     The former approach reduces the operational workload, but means more
>     complexity for standardizers and for the folks implementing the
>     access control infrastructure.  It also carries the risk of people
>     becoming over-confident that the standardizers' analysis might be
>     correct.  The latter approach requires hoping that every system's
>     security administrator will carry out an analysis of the side-effects
>     and correctly formulate access control policies that will do the right
>     things.  This carries the risks that the analysis will seldom happen,
>     and that the formulation of explicit access control policies to
>     account for side-effects is likely error-prone for garden-variety
>     administrators.
> 
>     Pick your poison.
> 
> 
> 
> One of the design goals of NACM was to keep it simple to use.
> There was a perception that VACM was too difficult to use,
> and that's why it was not widely deployed.

Perhaps, but the security properties you're advocating for NACM
are exactly the same as as those of VACM in this regard - both
only consider access to a specific piece of information, and
leave the consideration of any side-effects as a problem for
the security administrator to puzzle out.  Keeping the implementation
of the access control model simple pushes operational complexity
to the security administrator.

> I think the security considerations section for each YANG module RFC
> should point out the linkage issues from when-stmt and choice-stmt.

This is a start.  Unfortunately, these statements won't necessarily be
near the information objects for which an access control policy is being
formulated.

> The design goal should be to permit or deny access to an entire module.

I think such a goal is asking for trouble.  Things will either become
unwieldy from an operational/security perspective, or the modules
themselves will become so small and fragmented as to be
incomprehensible.

> The suggested granularity should be documented if any data-rules
> are expected for normal operation.

Agreed, but consider the question of managing access in the presence
of side-effects going beyond "data-rules."  It's certainly a lot
easier for infrastructure designers to think about systems that behave
like VACM / NACM, but is such an "easy to think about" (and consequently
limited) model really in the best interest of folks who need to secure
their operations?

I'm not taking a hard stance either way, but I think the question needs
serious consideration.

Randy


From nobody Sat Nov 25 04:46:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2E126C19; Sat, 25 Nov 2017 04:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 3IK5pxiqys3v; Sat, 25 Nov 2017 04:46:05 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0107.outbound.protection.outlook.com [104.47.0.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8D012009C; Sat, 25 Nov 2017 04:46:03 -0800 (PST)
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; bh=HcTwN4NDsSYB3Z8qPhs6UVes1mUAM756vFSWllwgFyc=; b=NR5lg7U7beEuKKlTNhwuBbLwGbn4foNaI/qRjPW6FCy/+mjXn7baz3r6YO5WwPqVXLAlID524uGcz99tqKJ1OsPZpUGZIRvRY4hvozcePCpLhC57k4WpWkYOMk8GyRjMXpC2xVo2l+bcG07tQr43Ae0hTAOJ7IR5FwtjiILr/lA=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Sat, 25 Nov 2017 12:46:00 +0000
Message-ID: <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Andy Bierman" 
Cc: "NETCONF" , "Robert Wilton" , 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net> 
Date: Sat, 25 Nov 2017 12:42:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6P18901CA0018.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::28) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7)
X-MS-Office365-Filtering-Correlation-Id: 7903a264-049d-4301-17bf-08d534027b8f
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603199); SRVR:DB6PR0701MB2997; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:gtXDNXZFSiaPGcQpZhQtGa2i1XtgIVP/5x2cbhcE6CsF8ZzaLZ4WKQr84TUWxNXbMNSuBJEQrKqall3UHLMRKHD6d61dqfOAX0c6ArhEuzFvAUdWDBmVg9+W+LFG2/O0vSTtsg5hu0A5SiHRziHkLMzaAfBBhdS4DG0alUVRb/18spAQyoRzaOV5SHod0vnf4R7GpEULtHhXrTvgB0Rhz1ZnVsyQoaDz1MOjoNf91+wUB+6uCLk8hun0cit3pO0TNqUgauou34VjFJ1c/b/GpXKrkZ8megh43pGq7gnxkZ0=; 25:TQQFsdfwHCbAAH67skNvtQ6hidCbL8KjZokFohFUCUFLlalJD7tsILI4OYbQgaHKDF0pZ3nkP30eDbwJezhHM8gxjC33Jtrmbk7oyRRvCqm6301A1BOlDkkjGhMFPIjJHQsA0+hVbj67puAIfc7wRx2ao5WZBkLt4xde06ydCa0hHHGjjDUkqPTd12NF8BWt4GuwzeGvSC09k7bZQZhoDrRC2fvskoRroW/kM9AbwV0+CsVs5UcbDFPX/M6BUcYTvZzAzD41r2wpg1fHlTS6hT70ygBUO4nHFcYbOjUjg/7+Am6ccek+wfJwF5Ys2ezJbLxEi/z2NomycjbhsqBKEAN0dKvBdquVY347AIBPaD0=; 31:E7xCA8JnsKbLl8D1dFjAhqL+GdUzTwO+RnZi8NVjk6M9IzvssXUv31iknxbxHWTEBfJH1+Ovi4P3QySmCGgNhTFNoraOYGf/yztM8eIT+b03AHPQPboI5jTytFFwmAVnO/Uz0CZ2sCzPHho+nM39KaUvl7wa37lvAsVcKeAcIkF2dNWy/JV2ftBib2Vir3SdIxBLvAN+JOJdH7GFgfWtiJAxfz/AXUbnKfNm0KZT87Y=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(158342451672863)(95692535739014); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0701MB2997; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 4:K+ZsNLYfIxcBT/dVk+iw/aggCjM7pfVscI8GiPCkUHT//YwHcwCxfZKqyAW/GPYCZJQTlyDs8rMmxAOUMSgYI7cSyvNXBgBLyj1PutSLFzbY72jDe+zioR8bsMMxi8bAj2+45UmEM8MHbaccICxrcfcbhHeTAyvAcihTVxhMRbiFGkfjAdQ266dna85Rr441lNM5vKgk9mUtbfehLror/d9MqjR+cdseAAdm4ZErOXBu+7KeCXuwAJCUO3XEy9Qw4VHyEn7I/SZoT6vc3F/4sRq7OPJIQ5R+kp52017XDmxWIQ4nC+DBsnXGa4uKPnQ/nNZQPr1BdUNrjpjjBnrjCYHQGL7RnRxS1vYt1ZA4oNQUrN8/McPPVumuzfV6eyPm
X-Forefront-PRVS: 0502983C0E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(376002)(39860400002)(346002)(51444003)(13464003)(24454002)(189002)(199003)(50466002)(14496001)(50986999)(81816999)(76176999)(81166006)(81156014)(8676002)(81686999)(1456003)(116806002)(230783001)(66066001)(33646002)(47776003)(44716002)(62236002)(61296003)(106356001)(6486002)(105586002)(101416001)(44736005)(4720700003)(6666003)(3846002)(6116002)(53546010)(2906002)(5660300001)(6916009)(229853002)(6246003)(93886005)(4326008)(97736004)(25786009)(189998001)(5890100001)(50226002)(1556002)(2486003)(6496006)(478600001)(86362001)(8936002)(316002)(54906003)(16526018)(68736007)(305945005)(53936002)(7736002)(9686003)(230700001)(23676004)(52116002)(84392002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTc7MjM6VXc3WGIwMUJsR1F3SGwxdmpjRW5jQjVt?= =?utf-8?B?cHp6U3kzc1lUQmlYVUlXY3F6MnNKbG5hS3VocVR3SktCSFBqb3lPbElwM0dI?= =?utf-8?B?bS9OTlovc2hsZjlzalhYdnhyNmR3R3FaQTNlRGRTNDhJTU1WMjRFK2ltdTVS?= =?utf-8?B?VmlacitpRWxwNnYzTkR1K21UN2VTTkZlSVpXK1JCM01hTzBNb0pNY25HZ0FU?= =?utf-8?B?dDkydWhUZFZTdlNuRnIzQlBWU3V1aHFuN2xNNjVuSGxheURtY0d0cHdMeVdC?= =?utf-8?B?QWErS3N2M3dpdThVQ1NzZ2dMUHhyTGNURWRVQ0JkTFBNR0Y1QVFDUGhMNmF6?= =?utf-8?B?VDB1em94YWZwWmowNkFDbnI2RTdjKzA2Zll3eDdaSWNsK0xMQ3FZaDlzNEha?= =?utf-8?B?UVRGazZFcFEwQlozcEtkbE5BdDZXYzNvTTU5V3NZR3VYVk1YU1VsU0xQZkx2?= =?utf-8?B?YXhOSnVhVDBBVHYzT2VKQ01ZNWxMc2JHNDYzUjYvcjhvbFg3UGg1UzU2Visz?= =?utf-8?B?dzIyUHpERml5ekRJVXZOQmxpQ2EwZFM4cjZSRjhWbHovQmhOd0doUkhPajNz?= =?utf-8?B?a0ozYjRFckxLamZiS050ejQzT3RiV0MrVncwRzdwaWZ5UDl0ZitvcDgrY3Y0?= =?utf-8?B?ajVqdjU0bUMvM2VtUUZnc2RBSzMxbkx3SkMvYnExMnM3eGtFUDdxcDZVSjRZ?= =?utf-8?B?ZEhISmE1My85M2dUMzhid3YxWms4bGFzZzBlZk1sdTBNejVuMFNkU1doY2Yv?= =?utf-8?B?ZVJzdWtLcnNmREl2MXZNVG02TVVvR1pqd05xM3ZSa3p2K2FFMEFWZkp4RTlG?= =?utf-8?B?VERDU1JwdmtOWldvM1pKMXRBZ2dKL0FkbE14T0VFSTN3Rm44dENKRG5DejUr?= =?utf-8?B?V3BtYVhOWFpwSUlMTUhFZytkWEVPUGlqZDFOb1ZvN3EvZGxtc1FLUnZ3dk5w?= =?utf-8?B?eFk4bnZ3bGFVdGVTejJ2bTJYQmVLSEdYSFFVcjBaUDRaSzRPZ2FHWkl2L1BW?= =?utf-8?B?WEpvOVk2MklLMTJYelBaYkk3U0swWnF2NU9rSVdIN1prVDBsdW1zZFJxYkZH?= =?utf-8?B?Y2x6RVZmV0JBSnluV2VxTkEzNVQzdUVoaHc1WnZUS25NZFZVenFvTjk3aXFq?= =?utf-8?B?dWtmY0k2cDBrQUtQQ01iSitjSXBQdkh3NGxBd2RTL2xMcFk4a1gwMUNiZi9y?= =?utf-8?B?OUlxQUlSS0JrNkJNVzErTGxVU1Q4R2pMMnIxZDdwTTBvMDBqanZ1a3huYy9r?= =?utf-8?B?K01XNTdFclZVS3lMRUF2RmtuOTBsRE1lMk9xSGk0R2FTWVcvSzQwNm5hOVdT?= =?utf-8?B?a3NBT0d4cHNQT0hmTUF1a2gyL3R0Q3NMTFJEcGhHejFKdHEvMlZYMC80Ky9X?= =?utf-8?B?RFl5UUZGazV3VzN5di80SHdBL0EzY0VUWFZrcUk2b01Eckd6WmdxU2UwUmdv?= =?utf-8?B?b1RxZXVUdEhIMkdiSmZPQTZId1VlTkcyMVpob2xIL3p2aWh5eGs2VFBzbDhK?= =?utf-8?B?cktrYWpRckhIQSs0QUs4YXhXKzRVVGF3eGp4NWVqNUpuaGIySkxWWHIzNURM?= =?utf-8?B?cmlFSFpBaFhNY0M2NkllOVViVVp4dDY3MndTYUdHcjZOakFwZjNFSW9kTEJC?= =?utf-8?B?eW1WSnpka1R0WWZGb0pEYkk3dUhwTlpGZWVnU0s4cVFKTG9CU25xV0ZGYkVP?= =?utf-8?B?T1BVTC9rcU4reDkvcUlPUG9RYTl1MStCZHhzb0YrdHl4RE9jdEhDVUlhSEJw?= =?utf-8?B?YmVsbCs0em82Q0VDOC9DZDJRZWVTUGoxd2hweiswOFVCL3pKanZ2YUNEZzl6?= =?utf-8?B?ZkwzTmlxek9Tb1JXK1IzR2tpS2l6cnVXM05INHJmYUloN2ZUdWVoSTJLbTha?= =?utf-8?B?d1NsMTVrSDVWZ0g1Vm8wYW9rN3VaNmhIeGNIbVdBMlJoNk5kZkdUZE84YUY0?= =?utf-8?B?RHJBUlptUzJYUmQwYVp4YldHU2Vub0dESFVCejlmcFh3QTYrSTErWVVrYnhF?= =?utf-8?B?aFVOT3dEOFdBM28rRkUyMEVmMWpYazVqTzIzOEFOWFNUbHJYRVhtenp4dnFy?= =?utf-8?B?UFN6TmlOWGhRZDAvS1VzZ2hnS253WHNxL25aWkRhWDd1V1U2M2trQkg1ZFl4?= =?utf-8?Q?FMry0F/4LhO1P865ScUFh40WY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:82ktmLCSTtS4jvAvI1FnLKzBk8tkE875aWWfgcK/loMfQO9OgQaEglEcGhdcHyDYu3MM7wunnmiCaJ/z6OWXJ1djHM0jRDTTaEq23osqROyftQ5pXp+D0KepJ9sFBw9qiFdrJJbs0ouR+1zhFxyFwprqCZa466BdZdUlBs3ijV+LDWgdKmDlxuNSQjSgalzH0m5ttA5TKytak9ciVq9niJO1Xa23FyQ+WunoIJixaVPBdkKOGZRqlmlAysV/sNxqaiU7qTdHhq5hE1u5sGs1d+pnS9gI7I4LfwSFjEwFpSPovGlI1BhyvbpUUuSYHSBqiSMYsctHBprFacUGMVxXXRIib4pnQyzIlhBZfGKNpVo=; 5:USlEOPCFXPiWKic2h92dcEDwTL04hndjKV/uLp6EnfFdQ6Ytu802t/D+3dKilTpgNw6+QyoWJPqYC8z4jo1Q9KxD6zzTtyniOEA9VSHlFKdE3u6REcnE9fYqAuk9mEBqi45Xtpe0aKMysxzS8BDw3JnpiqNd5MzE+3XmtTiUpp0=; 24:8HOy8yX6dx3ZfandrydDjo8JR5CKVHXTtnM2H5rbp85Bo4eSiO5W/oVrV0MlMGQxkcOqfydDvtJNqsIWe7PzFg8/ewp6Jb1rJYBOnjquGSE=; 7:6sDMrjMjdHKw9FvKw8ov3pf6AWQb7YNa6rVVJ2GeroE4t3qY3c7RreEB4eqN0WmsBFmC4JUx9wgfWTp2/l+X06UmzbBev6M/Imhcbmmh43Y3T5lAt4WeMB8dPvYTUTsQ6T0ZFe6nEo2Mxsikqw05f3Nwtui9xVbTunfV2qFC7h+XetPREe+90aWD9TbGxR8ebaq4lEzCsMvboq2jeQfsOvhlhmXrQW3MNrb5KnAXruJSnqtZJnXSpP5GyqOv/xWN
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2017 12:46:00.6597 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7903a264-049d-4301-17bf-08d534027b8f
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Nov 2017 12:46:07 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "t.petch" 


> On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:
>
> > 
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Robert Wilton" 
> > Sent: Thursday, November 23, 2017 10:44 AM
> >
> > > Hi Andy,
> > >
> > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > >
> > > >     Hi Rob,
> > > >
> > > >     At that points in time, if it clarifies the spec. and the
> > authors
> > > >     agree with this, let's do the right thing.
> > > >
> > > > I will add the new text if that is what the WG wants.
> >
> > > Having read this draft, I was undecided what the intended behavior
> > > actually should be.
> > >
> > > The way that Yumapro and Tail-f have implemented this is
reasonable,
> > and
> > > is probably also the way that I would implemented it.
> > >
> > > But I also think that it would be a reasonable implementation for
a
> > > server to calculate the full change set (taking account of side
> > effects
> > > from when and choice statements) to the datastore before checking
the
> > > "write data node access control" against the resultant change set.
> > >
> > > My interpretation is that the RFC text is ambiguous on what the
> > correct
> > > behavior is, and one could make a reasonable argument that the
current
> > > RFC actually specifies that the alternative behavior is correct,
i.e.
> > > requiring delete access even if a node is implicitly changes as a
side
> > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > >
> > >     If the protocol operation would result in the deletion of a
> > datastore
> > >     node and the user does not have "delete" access permission for
> > that
> > >     node, the protocol operation is rejected with an
"access-denied"
> > >     error.
> >
> > Rob
> >
> > I have been reading that paragraph since this thread started and
> > wondering how it could be thought unclear, what am I missing:-)
> >
> > To me it clearly states that the user must have the appropriate
access
> > for the consequences of whatever they do, be that 'when', 'choice'
or
> > anything else! Indeed, I see exactly that behaviour in operational
> > (non-network) databases of which I am a user with limited
privileges.
> >
> >
>
> This is not correct.
> The server is the entity that is cleaning up false when-stmt or
unselected
> cases
> for a choice-stmt.
>
> NACM does not prevent the sever from making any changes to the system.
> It only affects the operations requested by a client.

Andy

My model is slightly different, that the server is a black box, with an
interface through which I can make authorised changes.  If something I
do causes the deletion of something I am not allowed to delete, may be
not even to read, well, we part company on the acceptability of that!

I do accept, as Randy points out, that the situation is complicated.  I
am reminded of the issues that came up relating to the 'when' statement
when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
useful but at the same time, its side effects can be troublesome.  I
would like to wrap it up in a conceptual bubble so you could not have
the sort of fine-grained access control that allows the case that Rob
postulates to occur but have no idea what that might look like.  And I
don't know how much 'when' is used in that way in existing YANG
modules - uh huh, more reading required.

Tom Petch

>
> Andy
>









> > My other thought was that given all the complexities of 'when' that
> > emerged during the specification of YANG 1.1, perhaps, were I an
> > implementor of this, I would take the easy option and ignore the
side
> > effects of 'when'; but I might feel guilty about doing so.
> >
> > If the new paragraphs go in as proposed, then I think that the two
> > paragraphs you quote need changing else that section looks to me
like an
> > oxymoron.
> >
> > Tom Petch
> >
> > > An  request that causes a when constraint to evaluate
> > > differently does result in a deletion of those data nodes from the
> > > datastore, and hence according to the text above, requires
explicit
> > > "delete" access permission to accomplish that.
> > >
> > > Clearly it would be an interop issue if different servers
implemented
> > > the NACM path based filtering differently.
> > >
> > > Hence why I think that it would be prudent for the draft to be
more
> > > explicit on when and choice statement handling.
> > >
> > > Rob
> > >
> > > > There have not been any comments on this issue.
> > > >
> > > > Andy
> > > >
> > > >     Regards, Benoit.
> > > >>
> > > >>     Hi Benoit,
> > > >>
> > > >>     There is also one further, unrelated change that I am
proposing
> > > >>     is made the draft before it is published, to help better
> > clarify
> > > >>     the expected behavior. It isn't the end of the world if
this
> > > >>     doesn't go in, but I think that it prevents sometime taking
a
> > > >>     different, but IMO reasonable, interpretation of how "when"
> > > >>     statements are considered, and then having a future
argument
> > > >>     about what behavior it specified in the standard.
> > > >>
> > > >>     If we clarify it now, then it closes that door :-)
> > > >>
> > > >>     I've proposed text to Andy and Martin on Monday, but I've
not
> > > >>     heard back yet.
> > > >>
> > > >>     Netconf email with proposed text attached. The text doesn't
> > > >>     necessarily have to match this, but personally I think that
it
> > is
> > > >>     useful if the draft says something on this.
> > > >>
> > > >>     Thanks,
> > > >>     Rob
> > > >>
> > > >>
> > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > >>>>     Hi,
> > > >>>>
> > > >>>>     Here are some proposed edits to make the data rule
consistent
> > > >>>>     with the examples.
> > > >>>>     Note that this issue is not related to the edit in the
> > original
> > > >>>>     1-week change.
> > > >>>     That's right, but we found a source of misinterpretation
in
> > the
> > > >>>     draft and you have rightly corrected it in the github v9.
> > > >>>
> > > >>>     Regards, Benoit
> > > >>>>
> > > >>>>
> > > >>>>     sec. 3.3.5:
> > > >>>>
> > > >>>>     OLD:
> > > >>>>
> > > >>>>
> > > >>>>     data node rule: controls access for a specific data
> > > >>>>     node, identified
> > > >>>>     by its path location within the conceptual XML document
> > > >>>>     for the
> > > >>>>     data node.
> > > >>>>
> > > >>>>
> > > >>>>     NEW:
> > > >>>>
> > > >>>>     data node rule: controls access for a specific data node
> > > >>>>     and its descendants,
> > > >>>>     identified by its path location within the conceptual XML
> > > >>>>     document for the
> > > >>>>     data node.
> > > >>>>
> > > >>>>
> > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > >>>>
> > > >>>>
> > > >>>>     OLD:
> > > >>>>
> > > >>>>     * The rule does not have a "rule-type" defined or the
> > > >>>>     "rule-
> > > >>>>     type" is "data-node" and the "path" matches the
> > > >>>>     requested
> > > >>>>     data node, action node, or notification node.
> > > >>>>
> > > >>>>     NEW:
> > > >>>>     * The rule does not have a "rule-type" defined or the
> > > >>>>     "rule-
> > > >>>>     type" is "data-node" and the "path" matches the
> > > >>>>     requested
> > > >>>>     data node, action node, or notification node. A path is
> > > >>>>     considered to match if the current data node is the
> > > >>>>     data node
> > > >>>>     specified by the path, or is a descendant data node
> > > >>>>     of this data node.
> > > >>>>     appendix B.4: (2 bugs in explanation)
> > > >>>>     OLD:
> > > >>>>     deny-nacm: This rule denies the "guest" group any access
to
> > the
> > > >>>>      subtree. Note that the default namespace is only
> > > >>>>     applicable because this subtree is defined in the same
> > > >>>>     namespace as the  element.
> > > >>>>     NEW:
> > > >>>>     deny-nacm: This rule denies the "guest" group any access
to
> > the
> > > >>>>      subtree.
> > > >>>>     Andy
> > > >>>>
> > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > >>>>     > wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > > >>>>>         >
wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > >>>>>>
> > > >>>>>>
> > 
> >
> >
>


From nobody Sat Nov 25 07:53:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9612751F for ; Sat, 25 Nov 2017 07:53:26 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 iN3Ze-WRu5_p for ; Sat, 25 Nov 2017 07:53:25 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 49CC8127522 for ; Sat, 25 Nov 2017 07:53:19 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id k66so28303614lfg.3 for ; Sat, 25 Nov 2017 07:53:19 -0800 (PST)
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=mzsQbv6OZ6ZSJXDohKnN6ILhRbOq0LilcOUIkoPdEns=; b=bTVOZQQ5tDecFRO6xywx4RWYAbFb5A4NgKvp69dy3DpJj6S2X5XNwaeQuSDrbflu5Q 2m160niTN/yYRFGPeNFxM00JOnx5RcawXvFj2r24Tey9fpM4aAshNEDMlHYYUrnMTnwM T/A0xvHOTjmGGtanWA9xcj6OnKR0lSBN7J0RcplrNc5cj/2ImK2S6+ZsJlSw2oYBLCH5 He7s63QZSuQfG44ypBlPw1vGIxsLShcIVnSY69FWqGZKVBjqU2drwqgRoIPcX5v+6/SH 1ezWuchCckvbSDS1QGaHge6m2h8vLM0sEn2p6Ay/vOIfXULjkz8dOTKDjTTM8x+afOqD iYfw==
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=mzsQbv6OZ6ZSJXDohKnN6ILhRbOq0LilcOUIkoPdEns=; b=PhaVdu+5gF3BNxAkEiox9oqGnDWPzIJHKsMzdIsVZkY8lf2L0APjivSQIjE8hlrNqy Y6owlmT+V/rbpzamP4sGvGplbdr6bpCfgx2r0v80s7FB9Mp42XQblBfh52y5uSRbQ6aG +Q0xDeqab+vssDNop+/T6Ab7LpzBxClB8kEbzPPDesdXz/kWFie08wjxdfZVW8/KY4V5 +W9GYEnbYQpFv4Q61cuq2TynNEXgh0aTjrSb/MEOFWXOgyn8SQwlG42YdoUyQs5yQudt GAUfkEzkP2WRLc4sj3eruCMZGoWLwx1bR9IFgIwRTOFON4uNypkKdkVI/bbN1AfN25qh BlDQ==
X-Gm-Message-State: AJaThX50vJKgDzjJojkF+AwJfQNe9FpTCBdkKThgv+aIuM3k84/VeQPF Q7T3M3wzqjW+nMPtibsb/5E+Q12eIjBjCgaW4JtCVA==
X-Google-Smtp-Source: AGs4zMaN/XyCNBT0CSWgXkljbshp35LyrqbzBeLLHQoun2ol+fj27atBOVEFfL/GSD88d4/tcZdm4bYr9KRnBRSf/no=
X-Received: by 10.25.142.5 with SMTP id q5mr10173971lfd.19.1511625197325; Sat, 25 Nov 2017 07:53:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Sat, 25 Nov 2017 07:53:15 -0800 (PST)
In-Reply-To: <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>
From: Andy Bierman 
Date: Sat, 25 Nov 2017 07:53:15 -0800
Message-ID: 
To: "t.petch" 
Cc: NETCONF , Robert Wilton , sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="f403045f5098eba77d055ed0aa31"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Nov 2017 15:53:27 -0000

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

On Sat, Nov 25, 2017 at 4:42 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Andy Bierman" 
> To: "t.petch" 
>
>
> > On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:
> >
> > > 
> > >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "Robert Wilton" 
> > > Sent: Thursday, November 23, 2017 10:44 AM
> > >
> > > > Hi Andy,
> > > >
> > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > >
> > > > >     Hi Rob,
> > > > >
> > > > >     At that points in time, if it clarifies the spec. and the
> > > authors
> > > > >     agree with this, let's do the right thing.
> > > > >
> > > > > I will add the new text if that is what the WG wants.
> > >
> > > > Having read this draft, I was undecided what the intended behavior
> > > > actually should be.
> > > >
> > > > The way that Yumapro and Tail-f have implemented this is
> reasonable,
> > > and
> > > > is probably also the way that I would implemented it.
> > > >
> > > > But I also think that it would be a reasonable implementation for
> a
> > > > server to calculate the full change set (taking account of side
> > > effects
> > > > from when and choice statements) to the datastore before checking
> the
> > > > "write data node access control" against the resultant change set.
> > > >
> > > > My interpretation is that the RFC text is ambiguous on what the
> > > correct
> > > > behavior is, and one could make a reasonable argument that the
> current
> > > > RFC actually specifies that the alternative behavior is correct,
> i.e.
> > > > requiring delete access even if a node is implicitly changes as a
> side
> > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > >
> > > >     If the protocol operation would result in the deletion of a
> > > datastore
> > > >     node and the user does not have "delete" access permission for
> > > that
> > > >     node, the protocol operation is rejected with an
> "access-denied"
> > > >     error.
> > >
> > > Rob
> > >
> > > I have been reading that paragraph since this thread started and
> > > wondering how it could be thought unclear, what am I missing:-)
> > >
> > > To me it clearly states that the user must have the appropriate
> access
> > > for the consequences of whatever they do, be that 'when', 'choice'
> or
> > > anything else! Indeed, I see exactly that behaviour in operational
> > > (non-network) databases of which I am a user with limited
> privileges.
> > >
> > >
> >
> > This is not correct.
> > The server is the entity that is cleaning up false when-stmt or
> unselected
> > cases
> > for a choice-stmt.
> >
> > NACM does not prevent the sever from making any changes to the system.
> > It only affects the operations requested by a client.
>
> Andy
>
> My model is slightly different, that the server is a black box, with an
> interface through which I can make authorised changes.  If something I
> do causes the deletion of something I am not allowed to delete, may be
> not even to read, well, we part company on the acceptability of that!
>
> I do accept, as Randy points out, that the situation is complicated.  I
> am reminded of the issues that came up relating to the 'when' statement
> when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
> useful but at the same time, its side effects can be troublesome.  I
> would like to wrap it up in a conceptual bubble so you could not have
> the sort of fine-grained access control that allows the case that Rob
> postulates to occur but have no idea what that might look like.  And I
> don't know how much 'when' is used in that way in existing YANG
> modules - uh huh, more reading required.
>


When the access control is too complicated, it does not get used.
Instead, the most likely access control is "everybody is the root user".
The server pruning of false when/choice data nodes is considered cleanup.
The pruned data is no longer relevant to the data model. This is the
indended
use, but when-stmt can easily be abused.

The complex tangled web of dependencies is no worse
than it has been with CLI for 30 years, where every dependency is ad-hoc
and probably undocumented. The granularity of CLI-based access control
is less granular than NACM.

It is possible that vendors and operators are willing to spend hours and
days
figuring out how to tune the NACM rules to allow a specific edit to work.
Of course the operator will not even be told by the server which nodes
are blocking the edit. That would be a security risk.

IMO NACM will be completely unusable if rules are needed to allow
server cleanup of dead nodes.  The additional NACM rules required
might provide more access than intended (unless lots of delete-only
rules are added). The huge jump in NACM rule management complexity is
a new security vulnerability, which might even be worse than the
vulnerability it is intended to fix.



> Tom Petch
>
> >
> > Andy
> >
>
>
>
>
Andy



>
>
>
>
>
>
> > > My other thought was that given all the complexities of 'when' that
> > > emerged during the specification of YANG 1.1, perhaps, were I an
> > > implementor of this, I would take the easy option and ignore the
> side
> > > effects of 'when'; but I might feel guilty about doing so.
> > >
> > > If the new paragraphs go in as proposed, then I think that the two
> > > paragraphs you quote need changing else that section looks to me
> like an
> > > oxymoron.
> > >
> > > Tom Petch
> > >
> > > > An  request that causes a when constraint to evaluate
> > > > differently does result in a deletion of those data nodes from the
> > > > datastore, and hence according to the text above, requires
> explicit
> > > > "delete" access permission to accomplish that.
> > > >
> > > > Clearly it would be an interop issue if different servers
> implemented
> > > > the NACM path based filtering differently.
> > > >
> > > > Hence why I think that it would be prudent for the draft to be
> more
> > > > explicit on when and choice statement handling.
> > > >
> > > > Rob
> > > >
> > > > > There have not been any comments on this issue.
> > > > >
> > > > > Andy
> > > > >
> > > > >     Regards, Benoit.
> > > > >>
> > > > >>     Hi Benoit,
> > > > >>
> > > > >>     There is also one further, unrelated change that I am
> proposing
> > > > >>     is made the draft before it is published, to help better
> > > clarify
> > > > >>     the expected behavior. It isn't the end of the world if
> this
> > > > >>     doesn't go in, but I think that it prevents sometime taking
> a
> > > > >>     different, but IMO reasonable, interpretation of how "when"
> > > > >>     statements are considered, and then having a future
> argument
> > > > >>     about what behavior it specified in the standard.
> > > > >>
> > > > >>     If we clarify it now, then it closes that door :-)
> > > > >>
> > > > >>     I've proposed text to Andy and Martin on Monday, but I've
> not
> > > > >>     heard back yet.
> > > > >>
> > > > >>     Netconf email with proposed text attached. The text doesn't
> > > > >>     necessarily have to match this, but personally I think that
> it
> > > is
> > > > >>     useful if the draft says something on this.
> > > > >>
> > > > >>     Thanks,
> > > > >>     Rob
> > > > >>
> > > > >>
> > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > >>>>     Hi,
> > > > >>>>
> > > > >>>>     Here are some proposed edits to make the data rule
> consistent
> > > > >>>>     with the examples.
> > > > >>>>     Note that this issue is not related to the edit in the
> > > original
> > > > >>>>     1-week change.
> > > > >>>     That's right, but we found a source of misinterpretation
> in
> > > the
> > > > >>>     draft and you have rightly corrected it in the github v9.
> > > > >>>
> > > > >>>     Regards, Benoit
> > > > >>>>
> > > > >>>>
> > > > >>>>     sec. 3.3.5:
> > > > >>>>
> > > > >>>>     OLD:
> > > > >>>>
> > > > >>>>
> > > > >>>>     data node rule: controls access for a specific data
> > > > >>>>     node, identified
> > > > >>>>     by its path location within the conceptual XML document
> > > > >>>>     for the
> > > > >>>>     data node.
> > > > >>>>
> > > > >>>>
> > > > >>>>     NEW:
> > > > >>>>
> > > > >>>>     data node rule: controls access for a specific data node
> > > > >>>>     and its descendants,
> > > > >>>>     identified by its path location within the conceptual XML
> > > > >>>>     document for the
> > > > >>>>     data node.
> > > > >>>>
> > > > >>>>
> > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > >>>>
> > > > >>>>
> > > > >>>>     OLD:
> > > > >>>>
> > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > >>>>     "rule-
> > > > >>>>     type" is "data-node" and the "path" matches the
> > > > >>>>     requested
> > > > >>>>     data node, action node, or notification node.
> > > > >>>>
> > > > >>>>     NEW:
> > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > >>>>     "rule-
> > > > >>>>     type" is "data-node" and the "path" matches the
> > > > >>>>     requested
> > > > >>>>     data node, action node, or notification node. A path is
> > > > >>>>     considered to match if the current data node is the
> > > > >>>>     data node
> > > > >>>>     specified by the path, or is a descendant data node
> > > > >>>>     of this data node.
> > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > >>>>     OLD:
> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
> to
> > > the
> > > > >>>>      subtree. Note that the default namespace is only
> > > > >>>>     applicable because this subtree is defined in the same
> > > > >>>>     namespace as the  element.
> > > > >>>>     NEW:
> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
> to
> > > the
> > > > >>>>      subtree.
> > > > >>>>     Andy
> > > > >>>>
> > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > >>>>     > wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > > > >>>>>         >
> wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > > >>>>>>
> > > > >>>>>>
> > > 
> > >
> > >
> >
>
>

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




On Sat, Nov 25, 2017 at 4:42 AM, t.petch <ietfc@btconnect.com&g=
t; wrote:
----- Original Message -=
----

From: "Andy Bierman" <an=
dy@yumaworks.com>

To: "t.petch" <ietfc@bt=
connect.com>





> On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com> wrote:

>

> > <inline>

> >

> > Tom Petch

> >

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

> > From: "Robert Wilton" <rwilton@cisco.com>

> > Sent: Thursday, November 23, 2017 10:44 AM

> >

> > > Hi Andy,

> > >

> > > On 22/11/2017 18:09, Andy Bierman wrote:

> > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Hi Rob,

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0At that points in time, if it clarif=
ies the spec. and the

> > authors

> > > >=C2=A0 =C2=A0 =C2=A0agree with this, let's do the ri=
ght thing.

> > > >

> > > > I will add the new text if that is what the WG wants.
> >

> > > Having read this draft, I was undecided what the intended be=
havior

> > > actually should be.

> > >

> > > The way that Yumapro and Tail-f have implemented this is

reasonable,

> > and

> > > is probably also the way that I would implemented it.

> > >

> > > But I also think that it would be a reasonable implementatio=
n for

a

> > > server to calculate the full change set (taking account of s=
ide

> > effects

> > > from when and choice statements) to the datastore before che=
cking

the

> > > "write data node access control" against the resul=
tant change set.

> > >

> > > My interpretation is that the RFC text is ambiguous on what =
the

> > correct

> > > behavior is, and one could make a reasonable argument that t=
he

current

> > > RFC actually specifies that the alternative behavior is corr=
ect,

i.e.

> > > requiring delete access even if a node is implicitly changes=
 as a

side

> > > effect. E.g. section 3.2.3 of RFC 6536 states:

> > >

> > >=C2=A0 =C2=A0 =C2=A0If the protocol operation would result in=
 the deletion of a

> > datastore

> > >=C2=A0 =C2=A0 =C2=A0node and the user does not have "del=
ete" access permission for

> > that

> > >=C2=A0 =C2=A0 =C2=A0node, the protocol operation is rejected =
with an

"access-denied"

> > >=C2=A0 =C2=A0 =C2=A0error.

> >

> > Rob

> >

> > I have been reading that paragraph since this thread started and<=
br>
> > wondering how it could be thought unclear, what am I missing:-)
> >

> > To me it clearly states that the user must have the appropriate
access

> > for the consequences of whatever they do, be that 'when',=
 'choice'

or

> > anything else! Indeed, I see exactly that behaviour in operationa=
l

> > (non-network) databases of which I am a user with limited

privileges.

> >

> >

>

> This is not correct.

> The server is the entity that is cleaning up false when-stmt or

unselected

> cases

> for a choice-stmt.

>

> NACM does not prevent the sever from making any changes to the system.=


> It only affects the operations requested by a client.



Andy



My model is slightly different, that the server is a black box, with an

interface through which I can make authorised changes.=C2=A0 If something I=


do causes the deletion of something I am not allowed to delete, may be

not even to read, well, we part company on the acceptability of that!



I do accept, as Randy points out, that the situation is complicated.=C2=A0 =
I

am reminded of the issues that came up relating to the 'when' state=
ment

when preparing YANG 1.1.=C2=A0 Yes, 'when' makes things possible an=
d is very

useful but at the same time, its side effects can be troublesome.=C2=A0 I
would like to wrap it up in a conceptual bubble so you could not have

the sort of fine-grained access control that allows the case that Rob

postulates to occur but have no idea what that might look like.=C2=A0 And I=


don't know how much 'when' is used in that way in existing YANG=


modules - uh huh, more reading required.


When the access control is too complicated, it does not ge=
t used.
Instead, the most likely access control is "everybod=
y is the root user".
The server pruning of false when/choice=
 data nodes is considered cleanup.
The pruned data is no long=
er relevant to the data model. This is the indended
use, but when=
-stmt can easily be abused.

The complex tangled we=
b of dependencies is no worse
than it has been with CLI for 30 ye=
ars, where every dependency is ad-hoc
and probably undocumented. =
The granularity of CLI-based access control
is less granular than=
 NACM.

It is possible that vendors and operators a=
re willing to spend hours and days
figuring out how to tune the N=
ACM rules to allow a specific edit to work.
Of course the operato=
r will not even be told by the server which nodes
are blocking th=
e edit. That would be a security risk.

IMO NACM wi=
ll be completely unusable if rules are needed to allow
server cle=
anup of dead nodes.=C2=A0 The additional NACM rules required
migh=
t provide more access than intended (unless lots of delete-only
r=
ules are added). The huge jump in NACM rule management complexity is
<=
div>a new security vulnerability, which might even be worse than the
<=
div>vulnerability it is intended to fix.





Tom Petch



>

> Andy

>







Andy

=C2=A0













> > My other thought was that given all the complexities of 'when=
' that

> > emerged during the specification of YANG 1.1, perhaps, were I an<=
br>
> > implementor of this, I would take the easy option and ignore the<=
br>
side

> > effects of 'when'; but I might feel guilty about doing so=
.

> >

> > If the new paragraphs go in as proposed, then I think that the tw=
o

> > paragraphs you quote need changing else that section looks to me<=
br>
like an

> > oxymoron.

> >

> > Tom Petch

> >

> > > An <edit-data> request that causes a when constraint t=
o evaluate

> > > differently does result in a deletion of those data nodes fr=
om the

> > > datastore, and hence according to the text above, requires
explicit

> > > "delete" access permission to accomplish that.

> > >

> > > Clearly it would be an interop issue if different servers
implemented

> > > the NACM path based filtering differently.

> > >

> > > Hence why I think that it would be prudent for the draft to =
be

more

> > > explicit on when and choice statement handling.

> > >

> > > Rob

> > >

> > > > There have not been any comments on this issue.

> > > >

> > > > Andy

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0Regards, Benoit.

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0Hi Benoit,

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0There is also one further, unrel=
ated change that I am

proposing

> > > >>=C2=A0 =C2=A0 =C2=A0is made the draft before it is p=
ublished, to help better

> > clarify

> > > >>=C2=A0 =C2=A0 =C2=A0the expected behavior. It isn=
9;t the end of the world if

this

> > > >>=C2=A0 =C2=A0 =C2=A0doesn't go in, but I think t=
hat it prevents sometime taking

a

> > > >>=C2=A0 =C2=A0 =C2=A0different, but IMO reasonable, i=
nterpretation of how "when"

> > > >>=C2=A0 =C2=A0 =C2=A0statements are considered, and t=
hen having a future

argument

> > > >>=C2=A0 =C2=A0 =C2=A0about what behavior it specified=
 in the standard.

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0If we clarify it now, then it cl=
oses that door :-)

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0I've proposed text to Andy a=
nd Martin on Monday, but I've

not

> > > >>=C2=A0 =C2=A0 =C2=A0heard back yet.

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0Netconf email with proposed text=
 attached. The text doesn't

> > > >>=C2=A0 =C2=A0 =C2=A0necessarily have to match this, =
but personally I think that

it

> > is

> > > >>=C2=A0 =C2=A0 =C2=A0useful if the draft says somethi=
ng on this.

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0Thanks,

> > > >>=C2=A0 =C2=A0 =C2=A0Rob

> > > >>

> > > >>

> > > >>=C2=A0 =C2=A0 =C2=A0On 22/11/2017 13:25, Benoit Clai=
se wrote:

> > > >>>=C2=A0 =C2=A0 =C2=A0On 11/10/2017 7:23 PM, Andy =
Bierman wrote:

> > > >>>>=C2=A0 =C2=A0 =C2=A0Hi,

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0Here are some proposed e=
dits to make the data rule

consistent

> > > >>>>=C2=A0 =C2=A0 =C2=A0with the examples.

> > > >>>>=C2=A0 =C2=A0 =C2=A0Note that this issue is =
not related to the edit in the

> > original

> > > >>>>=C2=A0 =C2=A0 =C2=A01-week change.

> > > >>>=C2=A0 =C2=A0 =C2=A0That's right, but we fou=
nd a source of misinterpretation

in

> > the

> > > >>>=C2=A0 =C2=A0 =C2=A0draft and you have rightly c=
orrected it in the github v9.

> > > >>>

> > > >>>=C2=A0 =C2=A0 =C2=A0Regards, Benoit

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0sec. 3.3.5:

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node rule: controls=
 access for a specific data

> > > >>>>=C2=A0 =C2=A0 =C2=A0node, identified

> > > >>>>=C2=A0 =C2=A0 =C2=A0by its path location wit=
hin the conceptual XML document

> > > >>>>=C2=A0 =C2=A0 =C2=A0for the

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node.

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node rule: controls=
 access for a specific data node

> > > >>>>=C2=A0 =C2=A0 =C2=A0and its descendants,

> > > >>>>=C2=A0 =C2=A0 =C2=A0identified by its path l=
ocation within the conceptual XML

> > > >>>>=C2=A0 =C2=A0 =C2=A0document for the

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node.

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0sec 3.4.5, step 6, bulle=
t 2:

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0* The rule does not have=
 a "rule-type" defined or the

> > > >>>>=C2=A0 =C2=A0 =C2=A0"rule-

> > > >>>>=C2=A0 =C2=A0 =C2=A0type" is "data=
-node" and the "path" matches the

> > > >>>>=C2=A0 =C2=A0 =C2=A0requested

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node, action node, =
or notification node.

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> > > >>>>=C2=A0 =C2=A0 =C2=A0* The rule does not have=
 a "rule-type" defined or the

> > > >>>>=C2=A0 =C2=A0 =C2=A0"rule-

> > > >>>>=C2=A0 =C2=A0 =C2=A0type" is "data=
-node" and the "path" matches the

> > > >>>>=C2=A0 =C2=A0 =C2=A0requested

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node, action node, =
or notification node. A path is

> > > >>>>=C2=A0 =C2=A0 =C2=A0considered to match if t=
he current data node is the

> > > >>>>=C2=A0 =C2=A0 =C2=A0data node

> > > >>>>=C2=A0 =C2=A0 =C2=A0specified by the path, o=
r is a descendant data node

> > > >>>>=C2=A0 =C2=A0 =C2=A0of this data node.

> > > >>>>=C2=A0 =C2=A0 =C2=A0appendix B.4: (2 bugs in=
 explanation)

> > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

> > > >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm: This rule den=
ies the "guest" group any access

to

> > the

> > > >>>>=C2=A0 =C2=A0 =C2=A0<nacm> subtree. No=
te that the default namespace is only

> > > >>>>=C2=A0 =C2=A0 =C2=A0applicable because this =
subtree is defined in the same

> > > >>>>=C2=A0 =C2=A0 =C2=A0namespace as the <dat=
a-rule> element.

> > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

> > > >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm: This rule den=
ies the "guest" group any access

to

> > the

> > > >>>>=C2=A0 =C2=A0 =C2=A0<nacm> subtree.
> > > >>>>=C2=A0 =C2=A0 =C2=A0Andy

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 10, 2017 at =
9:24 AM, Robert Wilton

> > > >>>>=C2=A0 =C2=A0 =C2=A0<rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:

> > > >>>>

> > > >>>>

> > > >>>>

> > > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 10/11/2=
017 16:33, Andy Bierman wrote:

> > > >>>>>

> > > >>>>>

> > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri=
, Nov 10, 2017 at 8:16 AM, Robert Wilton

> > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<rwilton@cisco.com <mailto:rwilton@cisco.com>>

wrote:

> > > >>>>>

> > > >>>>>

> > > >>>>>

> > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0On 10/11/2017 15:49, Andy Bierman wrote:

> > > >>>>>>

> > > >>>>>>

> > <snip>

> >

> >

>







--f403045f5098eba77d055ed0aa31--


From nobody Mon Nov 27 02:39:52 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8A1250B8; Mon, 27 Nov 2017 02:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 7lIK6L1KRckY; Mon, 27 Nov 2017 02:39:48 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C2E120725; Mon, 27 Nov 2017 02:39:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38380; q=dns/txt; s=iport; t=1511779187; x=1512988787; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=GM4Ku3jJxMQyJCOH8WyPbcC8kYBIOFYILTfCQN1EPEM=; b=D4FoHSleqxQ+24DTBBn/t04Df2Xp+2te1+XLUtmNyGdhPRrmUM0+4GRW cH/VX0A4MdqsMP3uhRQ8NhWHKGe5zYbEmEv1EhaOGYbOSe9QY+IFvrsJV Sv8eM/PePjvcqs6Ln5Cl5Jv/8aFX/n7LPmkcU8naI25R55aBd0aslXvYO Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQAX6hta/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOggIng3+LFI93JpZtEIIBCoU7AoUqFgEBAQEBAQEBAWsohR8?= =?us-ascii?q?BAQEDARoJVgUHBAkCFQECFQsBBgMCAkYRBgEMBgIBAYoWCIhznWuCJyaKUwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DOoNcgWkpC4J3hFcOBAELBwEJVYJWgmMFiis?= =?us-ascii?q?jiRqFPokglQyCFolvJIcljkSHdoE6JgExYW8yGggbFYJigweBTkE2hyEPGIIgA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.44,464,1505779200"; d="scan'208,217";a="498557"
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; 27 Nov 2017 10:39:44 +0000
Received: from [10.63.23.82] (dhcp-ensft1-uk-vla370-10-63-23-82.cisco.com [10.63.23.82]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vARAdhDM012726; Mon, 27 Nov 2017 10:39:44 GMT
To: Andy Bierman , "t.petch" , NETCONF 
Cc: sec-ads@ietf.org
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 27 Nov 2017 10:39:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E5042D0CF9EE09A6836B685F"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 10:39:51 -0000

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

I do get the point that Tom is making here, and have quite a lot of 
sympathy for it.  E.g. by automatically allowing the side effects of 
when/choice statements then we are introducing a potential security hole 
here that operators may find hard to be aware of and mitigate.

It also seems odd to me that a client is allowed to implicitly remove 
some configuration through the side effect of a when/choice statement 
that they are not allowed to delete explicitly.

The alternative of requiring appropriate access for the side-effects, 
seems like an intuitively safer design, but I also get Andy's concern 
that security isn't useful if it become so unwieldy that nobody uses it.

So, I guess the question here is, do we have some concrete examples 
using real data models where the extra NACM delete rules would be 
required?  If not then perhaps requiring the explicit access for side 
effects would be better.

Thanks,
Rob


On 25/11/2017 15:53, Andy Bierman wrote:
>
>
> On Sat, Nov 25, 2017 at 4:42 AM, t.petch  > wrote:
>
>     ----- Original Message -----
>     From: "Andy Bierman" >
>     To: "t.petch" >
>
>
>     > On Fri, Nov 24, 2017 at 3:02 AM, t.petch      > wrote:
>     >
>     > > 
>     > >
>     > > Tom Petch
>     > >
>     > > ----- Original Message -----
>     > > From: "Robert Wilton"      >
>     > > Sent: Thursday, November 23, 2017 10:44 AM
>     > >
>     > > > Hi Andy,
>     > > >
>     > > > On 22/11/2017 18:09, Andy Bierman wrote:
>     > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
>     > > > >
>     > > > >     Hi Rob,
>     > > > >
>     > > > >     At that points in time, if it clarifies the spec. and the
>     > > authors
>     > > > >     agree with this, let's do the right thing.
>     > > > >
>     > > > > I will add the new text if that is what the WG wants.
>     > >
>     > > > Having read this draft, I was undecided what the intended
>     behavior
>     > > > actually should be.
>     > > >
>     > > > The way that Yumapro and Tail-f have implemented this is
>     reasonable,
>     > > and
>     > > > is probably also the way that I would implemented it.
>     > > >
>     > > > But I also think that it would be a reasonable
>     implementation for
>     a
>     > > > server to calculate the full change set (taking account of side
>     > > effects
>     > > > from when and choice statements) to the datastore before
>     checking
>     the
>     > > > "write data node access control" against the resultant
>     change set.
>     > > >
>     > > > My interpretation is that the RFC text is ambiguous on what the
>     > > correct
>     > > > behavior is, and one could make a reasonable argument that the
>     current
>     > > > RFC actually specifies that the alternative behavior is correct,
>     i.e.
>     > > > requiring delete access even if a node is implicitly changes
>     as a
>     side
>     > > > effect. E.g. section 3.2.3 of RFC 6536 states:
>     > > >
>     > > >     If the protocol operation would result in the deletion of a
>     > > datastore
>     > > >     node and the user does not have "delete" access
>     permission for
>     > > that
>     > > >     node, the protocol operation is rejected with an
>     "access-denied"
>     > > >     error.
>     > >
>     > > Rob
>     > >
>     > > I have been reading that paragraph since this thread started and
>     > > wondering how it could be thought unclear, what am I missing:-)
>     > >
>     > > To me it clearly states that the user must have the appropriate
>     access
>     > > for the consequences of whatever they do, be that 'when', 'choice'
>     or
>     > > anything else! Indeed, I see exactly that behaviour in operational
>     > > (non-network) databases of which I am a user with limited
>     privileges.
>     > >
>     > >
>     >
>     > This is not correct.
>     > The server is the entity that is cleaning up false when-stmt or
>     unselected
>     > cases
>     > for a choice-stmt.
>     >
>     > NACM does not prevent the sever from making any changes to the
>     system.
>     > It only affects the operations requested by a client.
>
>     Andy
>
>     My model is slightly different, that the server is a black box,
>     with an
>     interface through which I can make authorised changes.  If something I
>     do causes the deletion of something I am not allowed to delete, may be
>     not even to read, well, we part company on the acceptability of that!
>
>     I do accept, as Randy points out, that the situation is
>     complicated.  I
>     am reminded of the issues that came up relating to the 'when'
>     statement
>     when preparing YANG 1.1.  Yes, 'when' makes things possible and is
>     very
>     useful but at the same time, its side effects can be troublesome.  I
>     would like to wrap it up in a conceptual bubble so you could not have
>     the sort of fine-grained access control that allows the case that Rob
>     postulates to occur but have no idea what that might look like.  And I
>     don't know how much 'when' is used in that way in existing YANG
>     modules - uh huh, more reading required.
>
>
>
> When the access control is too complicated, it does not get used.
> Instead, the most likely access control is "everybody is the root user".
> The server pruning of false when/choice data nodes is considered cleanup.
> The pruned data is no longer relevant to the data model. This is the 
> indended
> use, but when-stmt can easily be abused.
>
> The complex tangled web of dependencies is no worse
> than it has been with CLI for 30 years, where every dependency is ad-hoc
> and probably undocumented. The granularity of CLI-based access control
> is less granular than NACM.
>
> It is possible that vendors and operators are willing to spend hours 
> and days
> figuring out how to tune the NACM rules to allow a specific edit to work.
> Of course the operator will not even be told by the server which nodes
> are blocking the edit. That would be a security risk.
>
> IMO NACM will be completely unusable if rules are needed to allow
> server cleanup of dead nodes.  The additional NACM rules required
> might provide more access than intended (unless lots of delete-only
> rules are added). The huge jump in NACM rule management complexity is
> a new security vulnerability, which might even be worse than the
> vulnerability it is intended to fix.
>
>
>
>     Tom Petch
>
>     >
>     > Andy
>     >
>
>
>
>
> Andy
>
>
>
>
>
>
>
>     > > My other thought was that given all the complexities of 'when'
>     that
>     > > emerged during the specification of YANG 1.1, perhaps, were I an
>     > > implementor of this, I would take the easy option and ignore the
>     side
>     > > effects of 'when'; but I might feel guilty about doing so.
>     > >
>     > > If the new paragraphs go in as proposed, then I think that the two
>     > > paragraphs you quote need changing else that section looks to me
>     like an
>     > > oxymoron.
>     > >
>     > > Tom Petch
>     > >
>     > > > An  request that causes a when constraint to evaluate
>     > > > differently does result in a deletion of those data nodes
>     from the
>     > > > datastore, and hence according to the text above, requires
>     explicit
>     > > > "delete" access permission to accomplish that.
>     > > >
>     > > > Clearly it would be an interop issue if different servers
>     implemented
>     > > > the NACM path based filtering differently.
>     > > >
>     > > > Hence why I think that it would be prudent for the draft to be
>     more
>     > > > explicit on when and choice statement handling.
>     > > >
>     > > > Rob
>     > > >
>     > > > > There have not been any comments on this issue.
>     > > > >
>     > > > > Andy
>     > > > >
>     > > > >     Regards, Benoit.
>     > > > >>
>     > > > >>     Hi Benoit,
>     > > > >>
>     > > > >>     There is also one further, unrelated change that I am
>     proposing
>     > > > >>     is made the draft before it is published, to help better
>     > > clarify
>     > > > >>     the expected behavior. It isn't the end of the world if
>     this
>     > > > >>     doesn't go in, but I think that it prevents sometime
>     taking
>     a
>     > > > >>     different, but IMO reasonable, interpretation of how
>     "when"
>     > > > >>     statements are considered, and then having a future
>     argument
>     > > > >>     about what behavior it specified in the standard.
>     > > > >>
>     > > > >>     If we clarify it now, then it closes that door :-)
>     > > > >>
>     > > > >>     I've proposed text to Andy and Martin on Monday, but I've
>     not
>     > > > >>     heard back yet.
>     > > > >>
>     > > > >>     Netconf email with proposed text attached. The text
>     doesn't
>     > > > >>     necessarily have to match this, but personally I
>     think that
>     it
>     > > is
>     > > > >>     useful if the draft says something on this.
>     > > > >>
>     > > > >>     Thanks,
>     > > > >>     Rob
>     > > > >>
>     > > > >>
>     > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
>     > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>     > > > >>>>     Hi,
>     > > > >>>>
>     > > > >>>>     Here are some proposed edits to make the data rule
>     consistent
>     > > > >>>>     with the examples.
>     > > > >>>>     Note that this issue is not related to the edit in the
>     > > original
>     > > > >>>>     1-week change.
>     > > > >>>     That's right, but we found a source of misinterpretation
>     in
>     > > the
>     > > > >>>     draft and you have rightly corrected it in the
>     github v9.
>     > > > >>>
>     > > > >>>     Regards, Benoit
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>     sec. 3.3.5:
>     > > > >>>>
>     > > > >>>>     OLD:
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>     data node rule: controls access for a specific data
>     > > > >>>>     node, identified
>     > > > >>>>     by its path location within the conceptual XML document
>     > > > >>>>     for the
>     > > > >>>>     data node.
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>     NEW:
>     > > > >>>>
>     > > > >>>>     data node rule: controls access for a specific data
>     node
>     > > > >>>>     and its descendants,
>     > > > >>>>     identified by its path location within the
>     conceptual XML
>     > > > >>>>     document for the
>     > > > >>>>     data node.
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>     sec 3.4.5, step 6, bullet 2:
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>     OLD:
>     > > > >>>>
>     > > > >>>>     * The rule does not have a "rule-type" defined or the
>     > > > >>>>     "rule-
>     > > > >>>>     type" is "data-node" and the "path" matches the
>     > > > >>>>     requested
>     > > > >>>>     data node, action node, or notification node.
>     > > > >>>>
>     > > > >>>>     NEW:
>     > > > >>>>     * The rule does not have a "rule-type" defined or the
>     > > > >>>>     "rule-
>     > > > >>>>     type" is "data-node" and the "path" matches the
>     > > > >>>>     requested
>     > > > >>>>     data node, action node, or notification node. A path is
>     > > > >>>>     considered to match if the current data node is the
>     > > > >>>>     data node
>     > > > >>>>     specified by the path, or is a descendant data node
>     > > > >>>>     of this data node.
>     > > > >>>>     appendix B.4: (2 bugs in explanation)
>     > > > >>>>     OLD:
>     > > > >>>>     deny-nacm: This rule denies the "guest" group any
>     access
>     to
>     > > the
>     > > > >>>>      subtree. Note that the default namespace is only
>     > > > >>>>     applicable because this subtree is defined in the same
>     > > > >>>>     namespace as the  element.
>     > > > >>>>     NEW:
>     > > > >>>>     deny-nacm: This rule denies the "guest" group any
>     access
>     to
>     > > the
>     > > > >>>>      subtree.
>     > > > >>>>     Andy
>     > > > >>>>
>     > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>     > > > >>>>     
>     >> wrote:
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>
>     > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>     > > > >>>>>
>     > > > >>>>>
>     > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>     > > > >>>>>         
>     >>
>     wrote:
>     > > > >>>>>
>     > > > >>>>>
>     > > > >>>>>
>     > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
>     > > > >>>>>>
>     > > > >>>>>>
>     > > 
>     > >
>     > >
>     >
>
>


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


  
    
  
  
    
I do get the point that Tom is making here, and have quite a lot
      of sympathy for it.  E.g. by automatically allowing the side
      effects of when/choice statements then we are introducing a
      potential security hole here that operators may find hard to be
      aware of and mitigate.

    

    
It also seems odd to me that a client is allowed to implicitly
      remove some configuration through the side effect of a when/choice
      statement that they are not allowed to delete explicitly.

    
The alternative of requiring appropriate access for the
      side-effects, seems like an intuitively safer design, but I also
      get Andy's concern that security isn't useful if it become so
      unwieldy that nobody uses it.

    
So, I guess the question here is, do we have some concrete
      examples using real data models where the extra NACM delete rules
      would be required?  If not then perhaps requiring the explicit
      access for side effects would be better.

    
Thanks,

      Rob

    


    

    
On 25/11/2017 15:53, Andy Bierman
      wrote:

    

    

      
      


        


          
On Sat, Nov 25, 2017 at 4:42 AM,
            t.petch <ietfc@btconnect.com>
            wrote:

            
-----
              Original Message -----

              From: "Andy Bierman" <andy@yumaworks.com>

              To: "t.petch" <ietfc@btconnect.com>

              

              

              > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com>
              wrote:

              >

              > > <inline>

              > >

              > > Tom Petch

              > >

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

              > > From: "Robert Wilton" <rwilton@cisco.com>

              > > Sent: Thursday, November 23, 2017 10:44 AM

              > >

              > > > Hi Andy,

              > > >

              > > > On 22/11/2017 18:09, Andy Bierman wrote:

              > > > > On Wed, Nov 22, 2017 at 5:41 AM,
              Benoit Claise wrote:

              > > > >

              > > > >     Hi Rob,

              > > > >

              > > > >     At that points in time, if it
              clarifies the spec. and the

              > > authors

              > > > >     agree with this, let's do the
              right thing.

              > > > >

              > > > > I will add the new text if that is
              what the WG wants.

              > >

              > > > Having read this draft, I was undecided
              what the intended behavior

              > > > actually should be.

              > > >

              > > > The way that Yumapro and Tail-f have
              implemented this is

              reasonable,

              > > and

              > > > is probably also the way that I would
              implemented it.

              > > >

              > > > But I also think that it would be a
              reasonable implementation for

              a

              > > > server to calculate the full change set
              (taking account of side

              > > effects

              > > > from when and choice statements) to the
              datastore before checking

              the

              > > > "write data node access control" against
              the resultant change set.

              > > >

              > > > My interpretation is that the RFC text is
              ambiguous on what the

              > > correct

              > > > behavior is, and one could make a
              reasonable argument that the

              current

              > > > RFC actually specifies that the alternative
              behavior is correct,

              i.e.

              > > > requiring delete access even if a node is
              implicitly changes as a

              side

              > > > effect. E.g. section 3.2.3 of RFC 6536
              states:

              > > >

              > > >     If the protocol operation would result
              in the deletion of a

              > > datastore

              > > >     node and the user does not have
              "delete" access permission for

              > > that

              > > >     node, the protocol operation is
              rejected with an

              "access-denied"

              > > >     error.

              > >

              > > Rob

              > >

              > > I have been reading that paragraph since this
              thread started and

              > > wondering how it could be thought unclear, what
              am I missing:-)

              > >

              > > To me it clearly states that the user must have
              the appropriate

              access

              > > for the consequences of whatever they do, be
              that 'when', 'choice'

              or

              > > anything else! Indeed, I see exactly that
              behaviour in operational

              > > (non-network) databases of which I am a user
              with limited

              privileges.

              > >

              > >

              >

              > This is not correct.

              > The server is the entity that is cleaning up false
              when-stmt or

              unselected

              > cases

              > for a choice-stmt.

              >

              > NACM does not prevent the sever from making any
              changes to the system.

              > It only affects the operations requested by a client.

              

              Andy

              

              My model is slightly different, that the server is a black
              box, with an

              interface through which I can make authorised changes.  If
              something I

              do causes the deletion of something I am not allowed to
              delete, may be

              not even to read, well, we part company on the
              acceptability of that!

              

              I do accept, as Randy points out, that the situation is
              complicated.  I

              am reminded of the issues that came up relating to the
              'when' statement

              when preparing YANG 1.1.  Yes, 'when' makes things
              possible and is very

              useful but at the same time, its side effects can be
              troublesome.  I

              would like to wrap it up in a conceptual bubble so you
              could not have

              the sort of fine-grained access control that allows the
              case that Rob

              postulates to occur but have no idea what that might look
              like.  And I

              don't know how much 'when' is used in that way in existing
              YANG

              modules - uh huh, more reading required.

            

            


            

            


            

            
When the access control is too complicated, it does not
              get used.

            
Instead, the most likely access control is "everybody
              is the root user".

            
The server pruning of false when/choice data nodes is
              considered cleanup.

            

            
The pruned data is no longer relevant to the data
              model. This is the indended

            
use, but when-stmt can easily be abused.

            


            

            
The complex tangled web of dependencies is no worse

            
than it has been with CLI for 30 years, where every
              dependency is ad-hoc

            
and probably undocumented. The granularity of CLI-based
              access control

            
is less granular than NACM.

            


            

            
It is possible that vendors and operators are willing
              to spend hours and days

            
figuring out how to tune the NACM rules to allow a
              specific edit to work.

            
Of course the operator will not even be told by the
              server which nodes

            
are blocking the edit. That would be a security risk.

            


            

            
IMO NACM will be completely unusable if rules are
              needed to allow

            
server cleanup of dead nodes.  The additional NACM
              rules required

            
might provide more access than intended (unless lots of
              delete-only

            
rules are added). The huge jump in NACM rule management
              complexity is

            
a new security vulnerability, which might even be worse
              than the

            
vulnerability it is intended to fix.

            


            

            


            

            

              

              Tom Petch

              

              >

              > Andy

              >

              

              

              

            

            


            

            
Andy

            


            

            
 

            

              

              

              

              

              

              

              > > My other thought was that given all the
              complexities of 'when' that

              > > emerged during the specification of YANG 1.1,
              perhaps, were I an

              > > implementor of this, I would take the easy
              option and ignore the

              side

              > > effects of 'when'; but I might feel guilty about
              doing so.

              > >

              > > If the new paragraphs go in as proposed, then I
              think that the two

              > > paragraphs you quote need changing else that
              section looks to me

              like an

              > > oxymoron.

              > >

              > > Tom Petch

              > >

              > > > An <edit-data> request that causes a
              when constraint to evaluate

              > > > differently does result in a deletion of
              those data nodes from the

              > > > datastore, and hence according to the text
              above, requires

              explicit

              > > > "delete" access permission to accomplish
              that.

              > > >

              > > > Clearly it would be an interop issue if
              different servers

              implemented

              > > > the NACM path based filtering differently.

              > > >

              > > > Hence why I think that it would be prudent
              for the draft to be

              more

              > > > explicit on when and choice statement
              handling.

              > > >

              > > > Rob

              > > >

              > > > > There have not been any comments on
              this issue.

              > > > >

              > > > > Andy

              > > > >

              > > > >     Regards, Benoit.

              > > > >>

              > > > >>     Hi Benoit,

              > > > >>

              > > > >>     There is also one further,
              unrelated change that I am

              proposing

              > > > >>     is made the draft before it is
              published, to help better

              > > clarify

              > > > >>     the expected behavior. It
              isn't the end of the world if

              this

              > > > >>     doesn't go in, but I think
              that it prevents sometime taking

              a

              > > > >>     different, but IMO reasonable,
              interpretation of how "when"

              > > > >>     statements are considered, and
              then having a future

              argument

              > > > >>     about what behavior it
              specified in the standard.

              > > > >>

              > > > >>     If we clarify it now, then it
              closes that door :-)

              > > > >>

              > > > >>     I've proposed text to Andy and
              Martin on Monday, but I've

              not

              > > > >>     heard back yet.

              > > > >>

              > > > >>     Netconf email with proposed
              text attached. The text doesn't

              > > > >>     necessarily have to match
              this, but personally I think that

              it

              > > is

              > > > >>     useful if the draft says
              something on this.

              > > > >>

              > > > >>     Thanks,

              > > > >>     Rob

              > > > >>

              > > > >>

              > > > >>     On 22/11/2017 13:25, Benoit
              Claise wrote:

              > > > >>>     On 11/10/2017 7:23 PM,
              Andy Bierman wrote:

              > > > >>>>     Hi,

              > > > >>>>

              > > > >>>>     Here are some proposed
              edits to make the data rule

              consistent

              > > > >>>>     with the examples.

              > > > >>>>     Note that this issue
              is not related to the edit in the

              > > original

              > > > >>>>     1-week change.

              > > > >>>     That's right, but we found
              a source of misinterpretation

              in

              > > the

              > > > >>>     draft and you have rightly
              corrected it in the github v9.

              > > > >>>

              > > > >>>     Regards, Benoit

              > > > >>>>

              > > > >>>>

              > > > >>>>     sec. 3.3.5:

              > > > >>>>

              > > > >>>>     OLD:

              > > > >>>>

              > > > >>>>

              > > > >>>>     data node rule:
              controls access for a specific data

              > > > >>>>     node, identified

              > > > >>>>     by its path location
              within the conceptual XML document

              > > > >>>>     for the

              > > > >>>>     data node.

              > > > >>>>

              > > > >>>>

              > > > >>>>     NEW:

              > > > >>>>

              > > > >>>>     data node rule:
              controls access for a specific data node

              > > > >>>>     and its descendants,

              > > > >>>>     identified by its path
              location within the conceptual XML

              > > > >>>>     document for the

              > > > >>>>     data node.

              > > > >>>>

              > > > >>>>

              > > > >>>>     sec 3.4.5, step 6,
              bullet 2:

              > > > >>>>

              > > > >>>>

              > > > >>>>     OLD:

              > > > >>>>

              > > > >>>>     * The rule does not
              have a "rule-type" defined or the

              > > > >>>>     "rule-

              > > > >>>>     type" is "data-node"
              and the "path" matches the

              > > > >>>>     requested

              > > > >>>>     data node, action
              node, or notification node.

              > > > >>>>

              > > > >>>>     NEW:

              > > > >>>>     * The rule does not
              have a "rule-type" defined or the

              > > > >>>>     "rule-

              > > > >>>>     type" is "data-node"
              and the "path" matches the

              > > > >>>>     requested

              > > > >>>>     data node, action
              node, or notification node. A path is

              > > > >>>>     considered to match if
              the current data node is the

              > > > >>>>     data node

              > > > >>>>     specified by the path,
              or is a descendant data node

              > > > >>>>     of this data node.

              > > > >>>>     appendix B.4: (2 bugs
              in explanation)

              > > > >>>>     OLD:

              > > > >>>>     deny-nacm: This rule
              denies the "guest" group any access

              to

              > > the

              > > > >>>>     <nacm> subtree.
              Note that the default namespace is only

              > > > >>>>     applicable because
              this subtree is defined in the same

              > > > >>>>     namespace as the
              <data-rule> element.

              > > > >>>>     NEW:

              > > > >>>>     deny-nacm: This rule
              denies the "guest" group any access

              to

              > > the

              > > > >>>>     <nacm> subtree.

              > > > >>>>     Andy

              > > > >>>>

              > > > >>>>     On Fri, Nov 10, 2017
              at 9:24 AM, Robert Wilton

              > > > >>>>     <rwilton@cisco.com
              <mailto:rwilton@cisco.com>>
              wrote:

              > > > >>>>

              > > > >>>>

              > > > >>>>

              > > > >>>>         On 10/11/2017
              16:33, Andy Bierman wrote:

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>         On Fri, Nov
              10, 2017 at 8:16 AM, Robert Wilton

              > > > >>>>>         <rwilton@cisco.com
              <mailto:rwilton@cisco.com>>

              wrote:

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>             On
              10/11/2017 15:49, Andy Bierman wrote:

              > > > >>>>>>

              > > > >>>>>>

              > > <snip>

              > >

              > >

              >

              

            

          

          

        

      

    

    

  


--------------E5042D0CF9EE09A6836B685F--


From nobody Mon Nov 27 02:49:33 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C7E127B60 for ; Mon, 27 Nov 2017 02:49:31 -0800 (PST)
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 cgAwB6DEYTK8 for ; Mon, 27 Nov 2017 02:49:29 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A1EDD120725 for ; Mon, 27 Nov 2017 02:49:28 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 928DD18215DC; Mon, 27 Nov 2017 11:49:13 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 7CD591820F78; Mon, 27 Nov 2017 11:49:11 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Randy Presuhn 
Cc: Netconf 
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com>  <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>   
Date: Mon, 27 Nov 2017 11:49:24 +0100
Message-ID: <87bmjot2rv.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 10:49:31 -0000

Andy Bierman  writes:

> On Fri, Nov 24, 2017 at 9:34 AM, Randy Presuhn <
> randy_presuhn@alumni.stanford.edu> wrote:
>
>> Hi -
>>
>> Tom wrote:
>>
>>>     To me it clearly states that the user must have the appropriate access
>>>     for the consequences of whatever they do, be that 'when', 'choice' or
>>>     anything else! Indeed, I see exactly that behaviour in operational
>>>     (non-network) databases of which I am a user with limited privileges.
>>>
>>
>> Andy replied:
>>
>>> This is not correct.
>>> The server is the entity that is cleaning up false when-stmt or
>>> unselected cases
>>> for a choice-stmt.
>>>
>>> NACM does not prevent the sever from making any changes to the system.
>>> It only affects the operations requested by a client.
>>>
>>
>> I think the point is that lots of Rube Goldberg / domino effect attacks
>> are made possible through management interfaces.  Sometimes
>> they are subtle, sometimes they're a result of explicit side-
>> effects in the definition of management information.  I think the
>> real question here is who is responsible for working through and
>> *documenting* such security consequences, and, subsequently, whether
>> the access control interface should deal them automagically (not
>> suggesting it's impossible, but there are aspects that could be hard)
>> or that figuring out the interconnections should be an exercise left
>> to the imagination of security administrators.
>>
>> The former approach reduces the operational workload, but means more
>> complexity for standardizers and for the folks implementing the
>> access control infrastructure.  It also carries the risk of people
>> becoming over-confident that the standardizers' analysis might be
>> correct.  The latter approach requires hoping that every system's
>> security administrator will carry out an analysis of the side-effects
>> and correctly formulate access control policies that will do the right
>> things.  This carries the risks that the analysis will seldom happen,
>> and that the formulation of explicit access control policies to
>> account for side-effects is likely error-prone for garden-variety
>> administrators.
>>
>> Pick your poison.
>>
>>
>
> One of the design goals of NACM was to keep it simple to use.
> There was a perception that VACM was too difficult to use,
> and that's why it was not widely deployed.
>
> I think the security considerations section for each YANG module RFC
> should point out the linkage issues from when-stmt and choice-stmt.
> The design goal should be to permit or deny access to an entire module.
> The suggested granularity should be documented if any data-rules
> are expected for normal operation.

It is quite likely that in more complex situations (e.g. involving
augments) such side effects may go unnoticed. And also, YANG modules
aren't produced only by SDOs, and this just opens a possibility for
hidden back-doors.

I have been criticising this auto-delete feature several times in the
past, and other people, too (I think Balazs was one). In my view, a sane
server behaviour would be to just report schema violation, rather than
delete anything automatically. This not only avoids the present NACM
issue but also helps prevent catastrophic mistakes.

Lada

>
>
> Randy
>>
>>
> Andy
>
>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Nov 27 02:54:36 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3B120725 for ; Mon, 27 Nov 2017 02:54:35 -0800 (PST)
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 4ZqSMdKO-ruw for ; Mon, 27 Nov 2017 02:54:34 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6611242F7 for ; Mon, 27 Nov 2017 02:54:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=569; q=dns/txt; s=iport; t=1511780074; x=1512989674; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=159Sq140fN5wbkhrA++mGVlE/mWEAy7corrtYe91a9c=; b=IT3m7YKIzSjPWXek1YjmkJUyM8gKnE3wMB0bd4S7F7QmuF6TcPrj5dOw TjtdEeiHqC8dIPDVuxrYd1u92Qc81PJ+vXPd3H2deLAWkfPrsnmGrCWjs qQpJMy16cu4B4nCX2JIJiSxrh3KKG668NnkW7z9DH6paxcfCNBwOML42z w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQAU7hta/xbLJq1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGFEIQmixSQHZh+CoU7AoUrFQEBAQEBAQEBAWsohSABBSMVQRA?= =?us-ascii?q?LGAICJgICVwYBDAgBAYoepmSCJ4p5AQEBAQEBAQEBAQEBAQEBAQEBIIEPgiuDX?= =?us-ascii?q?IFpKYMChQaDK4JjBaJGlQyBfYoIh0mORId2gTo1I4FQMhoIGxWCY4MGgQ8/QYo?= =?us-ascii?q?eAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,464,1505779200";  d="scan'208";a="500313"
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; 27 Nov 2017 10:54:32 +0000
Received: from [10.63.23.82] (dhcp-ensft1-uk-vla370-10-63-23-82.cisco.com [10.63.23.82]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vARAsVu6015322; Mon, 27 Nov 2017 10:54:32 GMT
To: Ladislav Lhotka , Andy Bierman , Randy Presuhn 
Cc: Netconf 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>    <87bmjot2rv.fsf@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Mon, 27 Nov 2017 10:54:31 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87bmjot2rv.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 10:54:35 -0000

Hi Lada,


On 27/11/2017 10:49, Ladislav Lhotka wrote:
> I have been criticising this auto-delete feature several times in the
> past, and other people, too (I think Balazs was one). In my view, a sane
> server behaviour would be to just report schema violation, rather than
> delete anything automatically. This not only avoids the present NACM
> issue but also helps prevent catastrophic mistakes.
Regarding auto-delete, do you have same opinion for both when and choice 
statements, or do you seem their ideal behavior as being different?

Thanks,
Rob


From nobody Mon Nov 27 03:35:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325F128891 for ; Mon, 27 Nov 2017 03:35:27 -0800 (PST)
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 z-VctvkTannc for ; Mon, 27 Nov 2017 03:35:25 -0800 (PST)
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 F3926120725 for ; Mon, 27 Nov 2017 03:35:24 -0800 (PST)
Received: from birdie8 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 58E5063644; Mon, 27 Nov 2017 12:35:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511782523; bh=rNXPwGxvtEbetYKOXZRG9dkOBRO18sxh+d0Qj9LQGQg=; h=From:To:Date; b=hkmcBNKlq+yvvTg/1nWBfUbjpMf0nr9eVSQyT1FoqELBfDvVVRv7GffDlMrQOpgfX /D28bZIDeR6DSWqdPTKeLtijkQ5XoAPUBQd6Ap+VXqa1gDVCiViE4NbHkWx2r8oUOx lgsZl+GkjhcMTxUgiOEES6D0dkvEE/9AIFrzaCZ4=
Message-ID: <1511782523.6244.14.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , Andy Bierman ,  Randy Presuhn 
Cc: Netconf 
Date: Mon, 27 Nov 2017 12:35:23 +0100
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>    <87bmjot2rv.fsf@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 11:35:27 -0000

On Mon, 2017-11-27 at 10:54 +0000, Robert Wilton wrote:
> Hi Lada,
> 
> 
> On 27/11/2017 10:49, Ladislav Lhotka wrote:
> > I have been criticising this auto-delete feature several times in the
> > past, and other people, too (I think Balazs was one). In my view, a sane
> > server behaviour would be to just report schema violation, rather than
> > delete anything automatically. This not only avoids the present NACM
> > issue but also helps prevent catastrophic mistakes.
> 
> Regarding auto-delete, do you have same opinion for both when and choice 
> statements, or do you seem their ideal behavior as being different?

No, it should IMO be the same: using another case in a choice would mean to
delete the existing case instance first (which may fail if the client has no
right to do so) and then create the new case. It's not a big deal but everything
 are explicit client's actions, no side effects.

Lada 

> 
> Thanks,
> Rob
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Nov 27 07:13:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA805124F57 for ; Mon, 27 Nov 2017 07:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 XVMYhMlT0fKS for ; Mon, 27 Nov 2017 07:12:57 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 D514F126BF3 for ; Mon, 27 Nov 2017 07:12:56 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id y2so32210400lfj.4 for ; Mon, 27 Nov 2017 07:12:56 -0800 (PST)
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=EfptLlWHJWM4b5noNMxxrkbwmkLwypPNYN9K7377W0Y=; b=ZGgyQ85q9hAU0QS7W6IayVe7gSG69tcTaYT4OwzwbwWy/UDtV4awLtoxOj5gZTfuYc /td7cx4I7C0xJrjJ8Y9DLiLOGXD0p63BE1MZWb1xkFIPYPBVezsgpqNDl7g+CnONErO9 +OO4qZ9q5+GRB98WE1X/PUDzsl0plEFnAygQjja6OAVLEaWcHMxYnRYmLWNeU78TxSQ9 WtX78YOsU1htkqVayeyWApvCT6po90pdTTQHZO4uCv1CtvbXMMh8qPP+pTNn9GBOMgNb MPDMHZuHlKaftc9CMwhV6DtJQmjVvEcpCuzLPUa45dNPqRZ4y5txdI/QSdc8dJ+LTpvk SOmw==
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=EfptLlWHJWM4b5noNMxxrkbwmkLwypPNYN9K7377W0Y=; b=lZZxZ57iWSqRrf2EvcxCxXjysMRL1W6W4rMXD8QtUMpaW8Fg5vBsqlQGH2/bxgpxR+ MHLtfLyqYQlr29uDBkmKX6pgJHPSFa9di1je7XnNmAdYqP3jEbItlBiLOIVEEZuxjC54 bSmI9Dn/lxAlKt9FwG8/ETvoK/jUEp160sQgKDjdq0VjZQrr9KwG6YVA52vc+NG2Ugjx mGpi1pOB6RHiJGAQctEiOErjtRZihwPm8n9bWe9uafjxCP4WZdrFYSy9jNSq+Blk/jCG L2tN1OFsfG3DTSkHWVVU/4BKBFMvNhKuWE2p1N+dJNWkOZi0aPEfK3oFAkkxG5L97Q/d wCIQ==
X-Gm-Message-State: AJaThX4Hc9WnykrlvMjp+yYnnqf7IXDyXH/aNrdl3JWvGBYlusO4svAO cbbqzgl98cpKzIXAcPWY8QJdWOJlG/3zwR638icuoQ==
X-Google-Smtp-Source: AGs4zMaC+Lt+V4aSd5iAmIfFeYfxXP6XfZVF9dQ6/tGE9ufv0PQj4rGuJ1g7HgPNJCtTDNmWRGkspXz6Y7OXPMno6cg=
X-Received: by 10.25.23.207 with SMTP id 76mr11712055lfx.123.1511795574918; Mon, 27 Nov 2017 07:12:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 07:12:53 -0800 (PST)
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>  
From: Andy Bierman 
Date: Mon, 27 Nov 2017 07:12:53 -0800
Message-ID: 
To: Robert Wilton 
Cc: "t.petch" , NETCONF , sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="001a1141128a384c3b055ef8562f"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 15:13:05 -0000

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

On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton  wrote:

> I do get the point that Tom is making here, and have quite a lot of
> sympathy for it.  E.g. by automatically allowing the side effects of
> when/choice statements then we are introducing a potential security hole
> here that operators may find hard to be aware of and mitigate.
>
> It also seems odd to me that a client is allowed to implicitly remove some
> configuration through the side effect of a when/choice statement that they
> are not allowed to delete explicitly.
>
> The alternative of requiring appropriate access for the side-effects,
> seems like an intuitively safer design, but I also get Andy's concern that
> security isn't useful if it become so unwieldy that nobody uses it.
>
> So, I guess the question here is, do we have some concrete examples using
> real data models where the extra NACM delete rules would be required?  If
> not then perhaps requiring the explicit access for side effects would be
> better.
>


Yes -- please provide some examples where it is better to force the operator
to provide extra "delete" rules to allow false-when data nodes to be
deleted.
It seems to me that these rules would allow individual data structures to be
removed by the client, that would not otherwise be possible.

If 3 data structures need to be in place "when /foo exists" then
deleting 1 or 2 of them directly may not be desirable.  Deleting
them all together (i.e., via when-false deletion) may be the intended usage.

The vendor and operator need to be aware of the data model dependencies.
That said, how come CLI-based configuration does not have this problem?
(Or rather, why has this problem been ignored for so long? Maybe it not
that real?)

Thanks,
> Rob
>

Andy


>
> On 25/11/2017 15:53, Andy Bierman wrote:
>
>
>
> On Sat, Nov 25, 2017 at 4:42 AM, t.petch  wrote:
>
>> ----- Original Message -----
>> From: "Andy Bierman" 
>> To: "t.petch" 
>>
>>
>> > On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:
>> >
>> > > 
>> > >
>> > > Tom Petch
>> > >
>> > > ----- Original Message -----
>> > > From: "Robert Wilton" 
>> > > Sent: Thursday, November 23, 2017 10:44 AM
>> > >
>> > > > Hi Andy,
>> > > >
>> > > > On 22/11/2017 18:09, Andy Bierman wrote:
>> > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
>> > > > >
>> > > > >     Hi Rob,
>> > > > >
>> > > > >     At that points in time, if it clarifies the spec. and the
>> > > authors
>> > > > >     agree with this, let's do the right thing.
>> > > > >
>> > > > > I will add the new text if that is what the WG wants.
>> > >
>> > > > Having read this draft, I was undecided what the intended behavior
>> > > > actually should be.
>> > > >
>> > > > The way that Yumapro and Tail-f have implemented this is
>> reasonable,
>> > > and
>> > > > is probably also the way that I would implemented it.
>> > > >
>> > > > But I also think that it would be a reasonable implementation for
>> a
>> > > > server to calculate the full change set (taking account of side
>> > > effects
>> > > > from when and choice statements) to the datastore before checking
>> the
>> > > > "write data node access control" against the resultant change set.
>> > > >
>> > > > My interpretation is that the RFC text is ambiguous on what the
>> > > correct
>> > > > behavior is, and one could make a reasonable argument that the
>> current
>> > > > RFC actually specifies that the alternative behavior is correct,
>> i.e.
>> > > > requiring delete access even if a node is implicitly changes as a
>> side
>> > > > effect. E.g. section 3.2.3 of RFC 6536 states:
>> > > >
>> > > >     If the protocol operation would result in the deletion of a
>> > > datastore
>> > > >     node and the user does not have "delete" access permission for
>> > > that
>> > > >     node, the protocol operation is rejected with an
>> "access-denied"
>> > > >     error.
>> > >
>> > > Rob
>> > >
>> > > I have been reading that paragraph since this thread started and
>> > > wondering how it could be thought unclear, what am I missing:-)
>> > >
>> > > To me it clearly states that the user must have the appropriate
>> access
>> > > for the consequences of whatever they do, be that 'when', 'choice'
>> or
>> > > anything else! Indeed, I see exactly that behaviour in operational
>> > > (non-network) databases of which I am a user with limited
>> privileges.
>> > >
>> > >
>> >
>> > This is not correct.
>> > The server is the entity that is cleaning up false when-stmt or
>> unselected
>> > cases
>> > for a choice-stmt.
>> >
>> > NACM does not prevent the sever from making any changes to the system.
>> > It only affects the operations requested by a client.
>>
>> Andy
>>
>> My model is slightly different, that the server is a black box, with an
>> interface through which I can make authorised changes.  If something I
>> do causes the deletion of something I am not allowed to delete, may be
>> not even to read, well, we part company on the acceptability of that!
>>
>> I do accept, as Randy points out, that the situation is complicated.  I
>> am reminded of the issues that came up relating to the 'when' statement
>> when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
>> useful but at the same time, its side effects can be troublesome.  I
>> would like to wrap it up in a conceptual bubble so you could not have
>> the sort of fine-grained access control that allows the case that Rob
>> postulates to occur but have no idea what that might look like.  And I
>> don't know how much 'when' is used in that way in existing YANG
>> modules - uh huh, more reading required.
>>
>
>
> When the access control is too complicated, it does not get used.
> Instead, the most likely access control is "everybody is the root user".
> The server pruning of false when/choice data nodes is considered cleanup.
> The pruned data is no longer relevant to the data model. This is the
> indended
> use, but when-stmt can easily be abused.
>
> The complex tangled web of dependencies is no worse
> than it has been with CLI for 30 years, where every dependency is ad-hoc
> and probably undocumented. The granularity of CLI-based access control
> is less granular than NACM.
>
> It is possible that vendors and operators are willing to spend hours and
> days
> figuring out how to tune the NACM rules to allow a specific edit to work.
> Of course the operator will not even be told by the server which nodes
> are blocking the edit. That would be a security risk.
>
> IMO NACM will be completely unusable if rules are needed to allow
> server cleanup of dead nodes.  The additional NACM rules required
> might provide more access than intended (unless lots of delete-only
> rules are added). The huge jump in NACM rule management complexity is
> a new security vulnerability, which might even be worse than the
> vulnerability it is intended to fix.
>
>
>
>> Tom Petch
>>
>> >
>> > Andy
>> >
>>
>>
>>
>>
> Andy
>
>
>
>>
>>
>>
>>
>>
>>
>> > > My other thought was that given all the complexities of 'when' that
>> > > emerged during the specification of YANG 1.1, perhaps, were I an
>> > > implementor of this, I would take the easy option and ignore the
>> side
>> > > effects of 'when'; but I might feel guilty about doing so.
>> > >
>> > > If the new paragraphs go in as proposed, then I think that the two
>> > > paragraphs you quote need changing else that section looks to me
>> like an
>> > > oxymoron.
>> > >
>> > > Tom Petch
>> > >
>> > > > An  request that causes a when constraint to evaluate
>> > > > differently does result in a deletion of those data nodes from the
>> > > > datastore, and hence according to the text above, requires
>> explicit
>> > > > "delete" access permission to accomplish that.
>> > > >
>> > > > Clearly it would be an interop issue if different servers
>> implemented
>> > > > the NACM path based filtering differently.
>> > > >
>> > > > Hence why I think that it would be prudent for the draft to be
>> more
>> > > > explicit on when and choice statement handling.
>> > > >
>> > > > Rob
>> > > >
>> > > > > There have not been any comments on this issue.
>> > > > >
>> > > > > Andy
>> > > > >
>> > > > >     Regards, Benoit.
>> > > > >>
>> > > > >>     Hi Benoit,
>> > > > >>
>> > > > >>     There is also one further, unrelated change that I am
>> proposing
>> > > > >>     is made the draft before it is published, to help better
>> > > clarify
>> > > > >>     the expected behavior. It isn't the end of the world if
>> this
>> > > > >>     doesn't go in, but I think that it prevents sometime taking
>> a
>> > > > >>     different, but IMO reasonable, interpretation of how "when"
>> > > > >>     statements are considered, and then having a future
>> argument
>> > > > >>     about what behavior it specified in the standard.
>> > > > >>
>> > > > >>     If we clarify it now, then it closes that door :-)
>> > > > >>
>> > > > >>     I've proposed text to Andy and Martin on Monday, but I've
>> not
>> > > > >>     heard back yet.
>> > > > >>
>> > > > >>     Netconf email with proposed text attached. The text doesn't
>> > > > >>     necessarily have to match this, but personally I think that
>> it
>> > > is
>> > > > >>     useful if the draft says something on this.
>> > > > >>
>> > > > >>     Thanks,
>> > > > >>     Rob
>> > > > >>
>> > > > >>
>> > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
>> > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>> > > > >>>>     Hi,
>> > > > >>>>
>> > > > >>>>     Here are some proposed edits to make the data rule
>> consistent
>> > > > >>>>     with the examples.
>> > > > >>>>     Note that this issue is not related to the edit in the
>> > > original
>> > > > >>>>     1-week change.
>> > > > >>>     That's right, but we found a source of misinterpretation
>> in
>> > > the
>> > > > >>>     draft and you have rightly corrected it in the github v9.
>> > > > >>>
>> > > > >>>     Regards, Benoit
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>     sec. 3.3.5:
>> > > > >>>>
>> > > > >>>>     OLD:
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>     data node rule: controls access for a specific data
>> > > > >>>>     node, identified
>> > > > >>>>     by its path location within the conceptual XML document
>> > > > >>>>     for the
>> > > > >>>>     data node.
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>     NEW:
>> > > > >>>>
>> > > > >>>>     data node rule: controls access for a specific data node
>> > > > >>>>     and its descendants,
>> > > > >>>>     identified by its path location within the conceptual XML
>> > > > >>>>     document for the
>> > > > >>>>     data node.
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>     sec 3.4.5, step 6, bullet 2:
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>     OLD:
>> > > > >>>>
>> > > > >>>>     * The rule does not have a "rule-type" defined or the
>> > > > >>>>     "rule-
>> > > > >>>>     type" is "data-node" and the "path" matches the
>> > > > >>>>     requested
>> > > > >>>>     data node, action node, or notification node.
>> > > > >>>>
>> > > > >>>>     NEW:
>> > > > >>>>     * The rule does not have a "rule-type" defined or the
>> > > > >>>>     "rule-
>> > > > >>>>     type" is "data-node" and the "path" matches the
>> > > > >>>>     requested
>> > > > >>>>     data node, action node, or notification node. A path is
>> > > > >>>>     considered to match if the current data node is the
>> > > > >>>>     data node
>> > > > >>>>     specified by the path, or is a descendant data node
>> > > > >>>>     of this data node.
>> > > > >>>>     appendix B.4: (2 bugs in explanation)
>> > > > >>>>     OLD:
>> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
>> to
>> > > the
>> > > > >>>>      subtree. Note that the default namespace is only
>> > > > >>>>     applicable because this subtree is defined in the same
>> > > > >>>>     namespace as the  element.
>> > > > >>>>     NEW:
>> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
>> to
>> > > the
>> > > > >>>>      subtree.
>> > > > >>>>     Andy
>> > > > >>>>
>> > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>> > > > >>>>     > wrote:
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>> > > > >>>>>         >
>> wrote:
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
>> > > > >>>>>>
>> > > > >>>>>>
>> > > 
>> > >
>> > >
>> >
>>
>>
>
>

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




On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
I do get the point that Tom is making here, and have quite a lot
      of sympathy for it.=C2=A0 E.g. by automatically allowing the side
      effects of when/choice statements then we are introducing a
      potential security hole here that operators may find hard to be
      aware of and mitigate.

    

    
It also seems odd to me that a client is allowed to implicitly
      remove some configuration through the side effect of a when/choice
      statement that they are not allowed to delete explicitly.

    
The alternative of requiring appropriate access for the
      side-effects, seems like an intuitively safer design, but I also
      get Andy's concern that security isn't useful if it become so
      unwieldy that nobody uses it.

    
So, I guess the question here is, do we have some concrete
      examples using real data models where the extra NACM delete rules
      would be required?=C2=A0 If not then perhaps requiring the explicit
      access for side effects would be better.
<=
br>

Yes -- please provide some examples where it i=
s better to force the operator
to provide extra "delete"=
; rules to allow false-when data nodes to be deleted.
It seems to=
 me that these rules would allow individual data structures to be
removed by the client, that would not otherwise be possible.
If 3 data structures need to be in place "when /foo exists=
" then
deleting 1 or 2 of them directly may not be desirable=
.=C2=A0 Deleting
them all together (i.e., via when-false deletion=
) may be the intended usage.

The vendor and operat=
or need to be aware of the data model dependencies.
That said, ho=
w come CLI-based configuration does not have this problem?
(Or ra=
ther, why has this problem been ignored for so long? Maybe it not that real=
?)


    
Thanks,

      Rob

Andy
=C2=A0

    


    

    
On 25/11/2017 15:5=
3, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Sat, Nov 25, 2017 at 4:42 AM,
            t.petch <ietfc@btconnect.com>
            wrote:

            
-----
              Original Message -----

              From: "Andy Bierman" <andy@yumaworks.com>

              To: "t.petch" <ietfc@btconnect.com>

              

              

              > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com>
              wrote:

              >

              > > <inline>

              > >

              > > Tom Petch

              > >

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

              > > From: "Robert Wilton" <rwilton@cisco.com>

              > > Sent: Thursday, November 23, 2017 10:44 AM

              > >

              > > > Hi Andy,

              > > >

              > > > On 22/11/2017 18:09, Andy Bierman wrote:

              > > > > On Wed, Nov 22, 2017 at 5:41 AM,
              Benoit Claise wrote:

              > > > >

              > > > >=C2=A0 =C2=A0 =C2=A0Hi Rob,

              > > > >

              > > > >=C2=A0 =C2=A0 =C2=A0At that points in time=
, if it
              clarifies the spec. and the

              > > authors

              > > > >=C2=A0 =C2=A0 =C2=A0agree with this, let&#=
39;s do the
              right thing.

              > > > >

              > > > > I will add the new text if that is
              what the WG wants.

              > >

              > > > Having read this draft, I was undecided
              what the intended behavior

              > > > actually should be.

              > > >

              > > > The way that Yumapro and Tail-f have
              implemented this is

              reasonable,

              > > and

              > > > is probably also the way that I would
              implemented it.

              > > >

              > > > But I also think that it would be a
              reasonable implementation for

              a

              > > > server to calculate the full change set
              (taking account of side

              > > effects

              > > > from when and choice statements) to the
              datastore before checking

              the

              > > > "write data node access control" aga=
inst
              the resultant change set.

              > > >

              > > > My interpretation is that the RFC text is
              ambiguous on what the

              > > correct

              > > > behavior is, and one could make a
              reasonable argument that the

              current

              > > > RFC actually specifies that the alternative
              behavior is correct,

              i.e.

              > > > requiring delete access even if a node is
              implicitly changes as a

              side

              > > > effect. E.g. section 3.2.3 of RFC 6536
              states:

              > > >

              > > >=C2=A0 =C2=A0 =C2=A0If the protocol operation w=
ould result
              in the deletion of a

              > > datastore

              > > >=C2=A0 =C2=A0 =C2=A0node and the user does not =
have
              "delete" access permission for

              > > that

              > > >=C2=A0 =C2=A0 =C2=A0node, the protocol operatio=
n is
              rejected with an

              "access-denied"

              > > >=C2=A0 =C2=A0 =C2=A0error.

              > >

              > > Rob

              > >

              > > I have been reading that paragraph since this
              thread started and

              > > wondering how it could be thought unclear, what
              am I missing:-)

              > >

              > > To me it clearly states that the user must have
              the appropriate

              access

              > > for the consequences of whatever they do, be
              that 'when', 'choice'

              or

              > > anything else! Indeed, I see exactly that
              behaviour in operational

              > > (non-network) databases of which I am a user
              with limited

              privileges.

              > >

              > >

              >

              > This is not correct.

              > The server is the entity that is cleaning up false
              when-stmt or

              unselected

              > cases

              > for a choice-stmt.

              >

              > NACM does not prevent the sever from making any
              changes to the system.

              > It only affects the operations requested by a client.
              

              Andy

              

              My model is slightly different, that the server is a black
              box, with an

              interface through which I can make authorised changes.=C2=A0 =
If
              something I

              do causes the deletion of something I am not allowed to
              delete, may be

              not even to read, well, we part company on the
              acceptability of that!

              

              I do accept, as Randy points out, that the situation is
              complicated.=C2=A0 I

              am reminded of the issues that came up relating to the
              'when' statement

              when preparing YANG 1.1.=C2=A0 Yes, 'when' makes thin=
gs
              possible and is very

              useful but at the same time, its side effects can be
              troublesome.=C2=A0 I

              would like to wrap it up in a conceptual bubble so you
              could not have

              the sort of fine-grained access control that allows the
              case that Rob

              postulates to occur but have no idea what that might look
              like.=C2=A0 And I

              don't know how much 'when' is used in that way in=
 existing
              YANG

              modules - uh huh, more reading required.

            

            


            

            


            

            
When the access control is too complicated, it does not
              get used.

            
Instead, the most likely access control is "everybody
              is the root user".

            
The server pruning of false when/choice data nodes is
              considered cleanup.

            

            
The pruned data is no longer relevant to the data
              model. This is the indended

            
use, but when-stmt can easily be abused.

            


            

            
The complex tangled web of dependencies is no worse

            
than it has been with CLI for 30 years, where every
              dependency is ad-hoc

            
and probably undocumented. The granularity of CLI-based
              access control

            
is less granular than NACM.

            


            

            
It is possible that vendors and operators are willing
              to spend hours and days

            
figuring out how to tune the NACM rules to allow a
              specific edit to work.

            
Of course the operator will not even be told by the
              server which nodes

            
are blocking the edit. That would be a security risk.
            


            

            
IMO NACM will be completely unusable if rules are
              needed to allow

            
server cleanup of dead nodes.=C2=A0 The additional NACM
              rules required

            
might provide more access than intended (unless lots of
              delete-only

            
rules are added). The huge jump in NACM rule management
              complexity is

            
a new security vulnerability, which might even be worse
              than the

            
vulnerability it is intended to fix.

            


            

            


            

            

              

              Tom Petch

              

              >

              > Andy

              >

              

              

              

            

            


            

            
Andy

            


            

            
=C2=A0

            

              

              

              

              

              

              

              > > My other thought was that given all the
              complexities of 'when' that

              > > emerged during the specification of YANG 1.1,
              perhaps, were I an

              > > implementor of this, I would take the easy
              option and ignore the

              side

              > > effects of 'when'; but I might feel guilty =
about
              doing so.

              > >

              > > If the new paragraphs go in as proposed, then I
              think that the two

              > > paragraphs you quote need changing else that
              section looks to me

              like an

              > > oxymoron.

              > >

              > > Tom Petch

              > >

              > > > An <edit-data> request that causes a
              when constraint to evaluate

              > > > differently does result in a deletion of
              those data nodes from the

              > > > datastore, and hence according to the text
              above, requires

              explicit

              > > > "delete" access permission to accomp=
lish
              that.

              > > >

              > > > Clearly it would be an interop issue if
              different servers

              implemented

              > > > the NACM path based filtering differently.

              > > >

              > > > Hence why I think that it would be prudent
              for the draft to be

              more

              > > > explicit on when and choice statement
              handling.

              > > >

              > > > Rob

              > > >

              > > > > There have not been any comments on
              this issue.

              > > > >

              > > > > Andy

              > > > >

              > > > >=C2=A0 =C2=A0 =C2=A0Regards, Benoit.

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0Hi Benoit,

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0There is also one =
further,
              unrelated change that I am

              proposing

              > > > >>=C2=A0 =C2=A0 =C2=A0is made the draft =
before it is
              published, to help better

              > > clarify

              > > > >>=C2=A0 =C2=A0 =C2=A0the expected behav=
ior. It
              isn't the end of the world if

              this

              > > > >>=C2=A0 =C2=A0 =C2=A0doesn't go in,=
 but I think
              that it prevents sometime taking

              a

              > > > >>=C2=A0 =C2=A0 =C2=A0different, but IMO=
 reasonable,
              interpretation of how "when"

              > > > >>=C2=A0 =C2=A0 =C2=A0statements are con=
sidered, and
              then having a future

              argument

              > > > >>=C2=A0 =C2=A0 =C2=A0about what behavio=
r it
              specified in the standard.

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0If we clarify it n=
ow, then it
              closes that door :-)

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0I've proposed =
text to Andy and
              Martin on Monday, but I've

              not

              > > > >>=C2=A0 =C2=A0 =C2=A0heard back yet.
              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0Netconf email with=
 proposed
              text attached. The text doesn't

              > > > >>=C2=A0 =C2=A0 =C2=A0necessarily have t=
o match
              this, but personally I think that

              it

              > > is

              > > > >>=C2=A0 =C2=A0 =C2=A0useful if the draf=
t says
              something on this.

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0Thanks,

              > > > >>=C2=A0 =C2=A0 =C2=A0Rob

              > > > >>

              > > > >>

              > > > >>=C2=A0 =C2=A0 =C2=A0On 22/11/2017 13:2=
5, Benoit
              Claise wrote:

              > > > >>>=C2=A0 =C2=A0 =C2=A0On 11/10/2017 =
7:23 PM,
              Andy Bierman wrote:

              > > > >>>>=C2=A0 =C2=A0 =C2=A0Hi,

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0Here are s=
ome proposed
              edits to make the data rule

              consistent

              > > > >>>>=C2=A0 =C2=A0 =C2=A0with the e=
xamples.

              > > > >>>>=C2=A0 =C2=A0 =C2=A0Note that =
this issue
              is not related to the edit in the

              > > original

              > > > >>>>=C2=A0 =C2=A0 =C2=A01-week cha=
nge.

              > > > >>>=C2=A0 =C2=A0 =C2=A0That's rig=
ht, but we found
              a source of misinterpretation

              in

              > > the

              > > > >>>=C2=A0 =C2=A0 =C2=A0draft and you =
have rightly
              corrected it in the github v9.

              > > > >>>

              > > > >>>=C2=A0 =C2=A0 =C2=A0Regards, Benoi=
t

              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0sec. 3.3.5=
:

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node =
rule:
              controls access for a specific data

              > > > >>>>=C2=A0 =C2=A0 =C2=A0node, iden=
tified

              > > > >>>>=C2=A0 =C2=A0 =C2=A0by its pat=
h location
              within the conceptual XML document

              > > > >>>>=C2=A0 =C2=A0 =C2=A0for the
              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node.=


              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node =
rule:
              controls access for a specific data node

              > > > >>>>=C2=A0 =C2=A0 =C2=A0and its de=
scendants,

              > > > >>>>=C2=A0 =C2=A0 =C2=A0identified=
 by its path
              location within the conceptual XML

              > > > >>>>=C2=A0 =C2=A0 =C2=A0document f=
or the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node.=


              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0sec 3.4.5,=
 step 6,
              bullet 2:

              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0* The rule=
 does not
              have a "rule-type" defined or the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0"rule=
-

              > > > >>>>=C2=A0 =C2=A0 =C2=A0type"=
 is "data-node"
              and the "path" matches the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0requested<=
br>
              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node,=
 action
              node, or notification node.

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

              > > > >>>>=C2=A0 =C2=A0 =C2=A0* The rule=
 does not
              have a "rule-type" defined or the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0"rule=
-

              > > > >>>>=C2=A0 =C2=A0 =C2=A0type"=
 is "data-node"
              and the "path" matches the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0requested<=
br>
              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node,=
 action
              node, or notification node. A path is

              > > > >>>>=C2=A0 =C2=A0 =C2=A0considered=
 to match if
              the current data node is the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0data node<=
br>
              > > > >>>>=C2=A0 =C2=A0 =C2=A0specified =
by the path,
              or is a descendant data node

              > > > >>>>=C2=A0 =C2=A0 =C2=A0of this da=
ta node.

              > > > >>>>=C2=A0 =C2=A0 =C2=A0appendix B=
.4: (2 bugs
              in explanation)

              > > > >>>>=C2=A0 =C2=A0 =C2=A0OLD:

              > > > >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm:=
 This rule
              denies the "guest" group any access

              to

              > > the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0<nacm&g=
t; subtree.
              Note that the default namespace is only

              > > > >>>>=C2=A0 =C2=A0 =C2=A0applicable=
 because
              this subtree is defined in the same

              > > > >>>>=C2=A0 =C2=A0 =C2=A0namespace =
as the
              <data-rule> element.

              > > > >>>>=C2=A0 =C2=A0 =C2=A0NEW:

              > > > >>>>=C2=A0 =C2=A0 =C2=A0deny-nacm:=
 This rule
              denies the "guest" group any access

              to

              > > the

              > > > >>>>=C2=A0 =C2=A0 =C2=A0<nacm&g=
t; subtree.

              > > > >>>>=C2=A0 =C2=A0 =C2=A0Andy

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0On Fri, No=
v 10, 2017
              at 9:24 AM, Robert Wilton

              > > > >>>>=C2=A0 =C2=A0 =C2=A0<rwilton@cisco.com
              <mailto:rwilton@cisco.com>>
              wrote:

              > > > >>>>

              > > > >>>>

              > > > >>>>

              > > > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0On 10/11/2017
              16:33, Andy Bierman wrote:

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0On Fri, Nov
              10, 2017 at 8:16 AM, Robert Wilton

              > > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0<rwilto=
n@cisco.com
              <mailto:rwilton@cisco.com>>

              wrote:

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>

              > > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0On
              10/11/2017 15:49, Andy Bierman wrote:

              > > > >>>>>>

              > > > >>>>>>

              > > <snip>

              > >

              > >

              >

              

            

          

          

        

      

    

    

  






--001a1141128a384c3b055ef8562f--


From nobody Mon Nov 27 07:32:54 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7C126CD8 for ; Mon, 27 Nov 2017 07:32:52 -0800 (PST)
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 0mlsr5gXO3jL for ; Mon, 27 Nov 2017 07:32:48 -0800 (PST)
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 33682126BF3 for ; Mon, 27 Nov 2017 07:32:48 -0800 (PST)
Received: from birdie8 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 57ACF63918 for ; Mon, 27 Nov 2017 16:32:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511796766; bh=ZPdxMr+/WEjpu+3g34JE5LjgjLpexFkVNPXa98eaSJY=; h=From:To:Date; b=frMNRnC4q1PUJC6vvrDQ4+BrxsuAXhKAmgBqML52Vcso8cNpA2YLPeHF0Sd6dmKG6 O34MQI0WSqJTBUAncpBDJwaX/VbH68tyiVdyTBoWXxBKCmhGbKfbxTtzKyS7jPOu4m YlObP/1vN+jWEZxQ1UHRe3hq8UL0w20+kGJenQHI=
Message-ID: <1511796766.6244.27.camel@nic.cz>
From: Ladislav Lhotka 
To: netconf@ietf.org
Date: Mon, 27 Nov 2017 16:32:46 +0100
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>   
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 15:32:52 -0000

On Mon, 2017-11-27 at 07:12 -0800, Andy Bierman wrote:
> 
> 
> On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton  wrote:
> > I do get the point that Tom is making here, and have quite a lot of sympathy
> > for it.  E.g. by automatically allowing the side effects of when/choice
> > statements then we are introducing a potential security hole here that
> > operators may find hard to be aware of and mitigate.
> > It also seems odd to me that a client is allowed to implicitly remove some
> > configuration through the side effect of a when/choice       statement that
> > they are not allowed to delete explicitly.
> > The alternative of requiring appropriate access for the side-effects, seems
> > like an intuitively safer design, but I also get Andy's concern that
> > security isn't useful if it become so unwieldy that nobody uses it.
> > So, I guess the question here is, do we have some concrete examples using
> > real data models where the extra NACM delete rules would be required?  If
> > not then perhaps requiring the explicit access for side effects would be
> > better.
> > 
> 
> 
> Yes -- please provide some examples where it is better to force the operator
> to provide extra "delete" rules to allow false-when data nodes to be deleted.
> It seems to me that these rules would allow individual data structures to be
> removed by the client, that would not otherwise be possible.

Here is an example:

Module A contains a choice with two cases, say "foo" and "bar". An operator
installs an instance of case "foo" and specifies NACM rules so that a non-
privileged client cannot remove it. Later, module B is added to the data model,
and it augments the choice with another case "baz". If a non-privileged user is
now allowed to create an instance of case "baz", he can trick the server into
deleting the protected instance of "foo".

So, module A may have bullet-proof security considerations and still, side
effects from module B create a security hole.

Lada  

> 
> If 3 data structures need to be in place "when /foo exists" then
> deleting 1 or 2 of them directly may not be desirable.  Deleting
> them all together (i.e., via when-false deletion) may be the intended usage.
> 
> The vendor and operator need to be aware of the data model dependencies.
> That said, how come CLI-based configuration does not have this problem?
> (Or rather, why has this problem been ignored for so long? Maybe it not that
> real?)
> 
> > Thanks,
> > Rob
> > 
> 
> Andy
>  
> > On 25/11/2017 15:53, Andy Bierman wrote:
> > > 
> > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch  wrote:
> > > > ----- Original Message -----
> > > > From: "Andy Bierman" 
> > > > To: "t.petch" 
> > > > 
> > > > 
> > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:
> > > > >
> > > > > > 
> > > > > >
> > > > > > Tom Petch
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Robert Wilton" 
> > > > > > Sent: Thursday, November 23, 2017 10:44 AM
> > > > > >
> > > > > > > Hi Andy,
> > > > > > >
> > > > > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > > > > >
> > > > > > > >     Hi Rob,
> > > > > > > >
> > > > > > > >     At that points in time, if it clarifies the spec. and the
> > > > > > authors
> > > > > > > >     agree with this, let's do the right thing.
> > > > > > > >
> > > > > > > > I will add the new text if that is what the WG wants.
> > > > > >
> > > > > > > Having read this draft, I was undecided what the intended behavior
> > > > > > > actually should be.
> > > > > > >
> > > > > > > The way that Yumapro and Tail-f have implemented this is
> > > > reasonable,
> > > > > > and
> > > > > > > is probably also the way that I would implemented it.
> > > > > > >
> > > > > > > But I also think that it would be a reasonable implementation for
> > > > a
> > > > > > > server to calculate the full change set (taking account of side
> > > > > > effects
> > > > > > > from when and choice statements) to the datastore before checking
> > > > the
> > > > > > > "write data node access control" against the resultant change set.
> > > > > > >
> > > > > > > My interpretation is that the RFC text is ambiguous on what the
> > > > > > correct
> > > > > > > behavior is, and one could make a reasonable argument that the
> > > > current
> > > > > > > RFC actually specifies that the alternative behavior is correct,
> > > > i.e.
> > > > > > > requiring delete access even if a node is implicitly changes as a
> > > > side
> > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > > > > >
> > > > > > >     If the protocol operation would result in the deletion of a
> > > > > > datastore
> > > > > > >     node and the user does not have "delete" access permission for
> > > > > > that
> > > > > > >     node, the protocol operation is rejected with an
> > > > "access-denied"
> > > > > > >     error.
> > > > > >
> > > > > > Rob
> > > > > >
> > > > > > I have been reading that paragraph since this thread started and
> > > > > > wondering how it could be thought unclear, what am I missing:-)
> > > > > >
> > > > > > To me it clearly states that the user must have the appropriate
> > > > access
> > > > > > for the consequences of whatever they do, be that 'when', 'choice'
> > > > or
> > > > > > anything else! Indeed, I see exactly that behaviour in operational
> > > > > > (non-network) databases of which I am a user with limited
> > > > privileges.
> > > > > >
> > > > > >
> > > > >
> > > > > This is not correct.
> > > > > The server is the entity that is cleaning up false when-stmt or
> > > > unselected
> > > > > cases
> > > > > for a choice-stmt.
> > > > >
> > > > > NACM does not prevent the sever from making any changes to the system.
> > > > > It only affects the operations requested by a client.
> > > > 
> > > > Andy
> > > > 
> > > > My model is slightly different, that the server is a black box, with an
> > > > interface through which I can make authorised changes.  If something I
> > > > do causes the deletion of something I am not allowed to delete, may be
> > > > not even to read, well, we part company on the acceptability of that!
> > > > 
> > > > I do accept, as Randy points out, that the situation is complicated.  I
> > > > am reminded of the issues that came up relating to the 'when' statement
> > > > when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
> > > > useful but at the same time, its side effects can be troublesome.  I
> > > > would like to wrap it up in a conceptual bubble so you could not have
> > > > the sort of fine-grained access control that allows the case that Rob
> > > > postulates to occur but have no idea what that might look like.  And I
> > > > don't know how much 'when' is used in that way in existing YANG
> > > > modules - uh huh, more reading required.
> > > > 
> > > 
> > > 
> > > When the access control is too complicated, it does not get used.
> > > Instead, the most likely access control is "everybody is the root user".
> > > The server pruning of false when/choice data nodes is considered cleanup.
> > > The pruned data is no longer relevant to the data model. This is the
> > > indended
> > > use, but when-stmt can easily be abused.
> > > 
> > > The complex tangled web of dependencies is no worse
> > > than it has been with CLI for 30 years, where every dependency is ad-hoc
> > > and probably undocumented. The granularity of CLI-based access control
> > > is less granular than NACM.
> > > 
> > > It is possible that vendors and operators are willing to spend hours and
> > > days
> > > figuring out how to tune the NACM rules to allow a specific edit to work.
> > > Of course the operator will not even be told by the server which nodes
> > > are blocking the edit. That would be a security risk.
> > > 
> > > IMO NACM will be completely unusable if rules are needed to allow
> > > server cleanup of dead nodes.  The additional NACM rules required
> > > might provide more access than intended (unless lots of delete-only
> > > rules are added). The huge jump in NACM rule management complexity is
> > > a new security vulnerability, which might even be worse than the
> > > vulnerability it is intended to fix.
> > > 
> > > 
> > > > Tom Petch
> > > > 
> > > > >
> > > > > Andy
> > > > >
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > Andy
> > > 
> > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > > My other thought was that given all the complexities of 'when' that
> > > > > > emerged during the specification of YANG 1.1, perhaps, were I an
> > > > > > implementor of this, I would take the easy option and ignore the
> > > > side
> > > > > > effects of 'when'; but I might feel guilty about doing so.
> > > > > >
> > > > > > If the new paragraphs go in as proposed, then I think that the two
> > > > > > paragraphs you quote need changing else that section looks to me
> > > > like an
> > > > > > oxymoron.
> > > > > >
> > > > > > Tom Petch
> > > > > >
> > > > > > > An  request that causes a when constraint to evaluate
> > > > > > > differently does result in a deletion of those data nodes from the
> > > > > > > datastore, and hence according to the text above, requires
> > > > explicit
> > > > > > > "delete" access permission to accomplish that.
> > > > > > >
> > > > > > > Clearly it would be an interop issue if different servers
> > > > implemented
> > > > > > > the NACM path based filtering differently.
> > > > > > >
> > > > > > > Hence why I think that it would be prudent for the draft to be
> > > > more
> > > > > > > explicit on when and choice statement handling.
> > > > > > >
> > > > > > > Rob
> > > > > > >
> > > > > > > > There have not been any comments on this issue.
> > > > > > > >
> > > > > > > > Andy
> > > > > > > >
> > > > > > > >     Regards, Benoit.
> > > > > > > >>
> > > > > > > >>     Hi Benoit,
> > > > > > > >>
> > > > > > > >>     There is also one further, unrelated change that I am
> > > > proposing
> > > > > > > >>     is made the draft before it is published, to help better
> > > > > > clarify
> > > > > > > >>     the expected behavior. It isn't the end of the world if
> > > > this
> > > > > > > >>     doesn't go in, but I think that it prevents sometime taking
> > > > a
> > > > > > > >>     different, but IMO reasonable, interpretation of how "when"
> > > > > > > >>     statements are considered, and then having a future
> > > > argument
> > > > > > > >>     about what behavior it specified in the standard.
> > > > > > > >>
> > > > > > > >>     If we clarify it now, then it closes that door :-)
> > > > > > > >>
> > > > > > > >>     I've proposed text to Andy and Martin on Monday, but I've
> > > > not
> > > > > > > >>     heard back yet.
> > > > > > > >>
> > > > > > > >>     Netconf email with proposed text attached. The text doesn't
> > > > > > > >>     necessarily have to match this, but personally I think that
> > > > it
> > > > > > is
> > > > > > > >>     useful if the draft says something on this.
> > > > > > > >>
> > > > > > > >>     Thanks,
> > > > > > > >>     Rob
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > > > > >>>>     Hi,
> > > > > > > >>>>
> > > > > > > >>>>     Here are some proposed edits to make the data rule
> > > > consistent
> > > > > > > >>>>     with the examples.
> > > > > > > >>>>     Note that this issue is not related to the edit in the
> > > > > > original
> > > > > > > >>>>     1-week change.
> > > > > > > >>>     That's right, but we found a source of misinterpretation
> > > > in
> > > > > > the
> > > > > > > >>>     draft and you have rightly corrected it in the github v9.
> > > > > > > >>>
> > > > > > > >>>     Regards, Benoit
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>     sec. 3.3.5:
> > > > > > > >>>>
> > > > > > > >>>>     OLD:
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>     data node rule: controls access for a specific data
> > > > > > > >>>>     node, identified
> > > > > > > >>>>     by its path location within the conceptual XML document
> > > > > > > >>>>     for the
> > > > > > > >>>>     data node.
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>     NEW:
> > > > > > > >>>>
> > > > > > > >>>>     data node rule: controls access for a specific data node
> > > > > > > >>>>     and its descendants,
> > > > > > > >>>>     identified by its path location within the conceptual XML
> > > > > > > >>>>     document for the
> > > > > > > >>>>     data node.
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>     OLD:
> > > > > > > >>>>
> > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > >>>>     "rule-
> > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > >>>>     requested
> > > > > > > >>>>     data node, action node, or notification node.
> > > > > > > >>>>
> > > > > > > >>>>     NEW:
> > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > >>>>     "rule-
> > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > >>>>     requested
> > > > > > > >>>>     data node, action node, or notification node. A path is
> > > > > > > >>>>     considered to match if the current data node is the
> > > > > > > >>>>     data node
> > > > > > > >>>>     specified by the path, or is a descendant data node
> > > > > > > >>>>     of this data node.
> > > > > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > > > > >>>>     OLD:
> > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any access
> > > > to
> > > > > > the
> > > > > > > >>>>      subtree. Note that the default namespace is only
> > > > > > > >>>>     applicable because this subtree is defined in the same
> > > > > > > >>>>     namespace as the  element.
> > > > > > > >>>>     NEW:
> > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any access
> > > > to
> > > > > > the
> > > > > > > >>>>      subtree.
> > > > > > > >>>>     Andy
> > > > > > > >>>>
> > > > > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > > > > >>>>     > wrote:
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > > > > > > >>>>>         >
> > > > wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > 
> > > > > >
> > > > > >
> > > > >
> > > > 
> > > > 
> >  
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Nov 27 07:44:37 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2D127F0E; Mon, 27 Nov 2017 07:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 sZJlowuSEfBn; Mon, 27 Nov 2017 07:44:32 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B958126CB6; Mon, 27 Nov 2017 07:44:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55856; q=dns/txt; s=iport; t=1511797471; x=1513007071; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=apOkGoClCUM98OTOj3KVO0NwbU4a4D0h7pn144mD4wQ=; b=b5XGAlub+fAWiQnOscruvdF+XOJ9lgwPJXif7j0iRcu8FTJ9xm0C006E 4hnh0MBmWFinhpnXGC+vFlMpPTgol1X7E5II+O19aGloTpDeTIQj5wF36 LfyO7qfv9s/CE5neiG+Ud+02dT52SznukPwdwHQUXlH0HhWglM/n1eqv6 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAEMhxa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOggIng3+LFJAdlm0QggEKhTsChS0XAQEBAQEBAQEBayiFHwE?= =?us-ascii?q?BAQMBGglWBQcECQIVAQIVCwEGAwICRhEGDQYCAQGKFgiIVZ1rgicmilMBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgzqDXIFpKYMChFcOBAELBwEHAlWCVoJjBYorI4k?= =?us-ascii?q?ahT6JIJUMghaGDINjJIcljkSHdoE6IAE3YW8yGggbFYJiglIcGYFOQTaHYAING?= =?us-ascii?q?AeCGQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,465,1505779200"; d="scan'208,217";a="460373"
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; 27 Nov 2017 15:44:28 +0000
Received: from [10.63.23.82] (dhcp-ensft1-uk-vla370-10-63-23-82.cisco.com [10.63.23.82]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vARFiR7F002950; Mon, 27 Nov 2017 15:44:27 GMT
To: Andy Bierman 
Cc: "t.petch" , NETCONF , sec-ads@ietf.org
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>   
From: Robert Wilton 
Message-ID: 
Date: Mon, 27 Nov 2017 15:44:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FE8CB7D9D26B67B49C8B9E2E"
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 15:44:35 -0000

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



On 27/11/2017 15:12, Andy Bierman wrote:
>
>
> On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton  > wrote:
>
>     I do get the point that Tom is making here, and have quite a lot
>     of sympathy for it.  E.g. by automatically allowing the side
>     effects of when/choice statements then we are introducing a
>     potential security hole here that operators may find hard to be
>     aware of and mitigate.
>
>     It also seems odd to me that a client is allowed to implicitly
>     remove some configuration through the side effect of a when/choice
>     statement that they are not allowed to delete explicitly.
>
>     The alternative of requiring appropriate access for the
>     side-effects, seems like an intuitively safer design, but I also
>     get Andy's concern that security isn't useful if it become so
>     unwieldy that nobody uses it.
>
>     So, I guess the question here is, do we have some concrete
>     examples using real data models where the extra NACM delete rules
>     would be required?  If not then perhaps requiring the explicit
>     access for side effects would be better.
>
>
>
> Yes -- please provide some examples where it is better to force the 
> operator
> to provide extra "delete" rules to allow false-when data nodes to be 
> deleted.
> It seems to me that these rules would allow individual data structures 
> to be
> removed by the client, that would not otherwise be possible.
Yes, this is true.

But it is still odd that they a client is allowed to delete the 
configuration, just not explicitly.  I.e. it is strange that they are 
not allowed to put in a semantically equivalent request that explicitly 
deletes the configuration, they are only allowed to do it if the delete 
is implicit.  This seems inconsistent.

>
> If 3 data structures need to be in place "when /foo exists" then
> deleting 1 or 2 of them directly may not be desirable. Deleting
> them all together (i.e., via when-false deletion) may be the intended 
> usage.
If there is a dependency that all three exist then that may be better 
expressed with a must statement instead.

>
> The vendor and operator need to be aware of the data model dependencies.
> That said, how come CLI-based configuration does not have this problem?
My experience of CLI based configurations do have these sorts of 
problems, and many more :-)


> (Or rather, why has this problem been ignored for so long? Maybe it 
> not that real?)
This may be the real crux of the argument:

It probably doesn't make sense to use when statements on disjoint parts 
of the YANG schema (e.g. it does not make sense for the OSPF YANG model 
to depend on whether an interface it runs over has an IP address 
configured).  Instead, a more normal usage would be a flag (e.g. like 
interface type) to allow/prevent certain child nodes from being 
available.  In these scenarios, if a user is allowed to change the type 
of an interface then they are most likely allowed to change the other 
settings on the interface as well.

So for 'normal' when statements, it probably doesn't make much 
difference whether or not explicit NACM access is required to the nodes 
being implicitly deleted because the client probably already has the 
necessary access rights.

But for the 'corner case' when statement scenario, that are unlikely to 
be used, it still seems safer to require explicit access permissions 
than implicitly accepting the side effect with no NACM validation.

Thanks,
Rob


>
>     Thanks,
>     Rob
>
>
> Andy
>
>
>     On 25/11/2017 15:53, Andy Bierman wrote:
>>
>>
>>     On Sat, Nov 25, 2017 at 4:42 AM, t.petch >     > wrote:
>>
>>         ----- Original Message -----
>>         From: "Andy Bierman" >         >
>>         To: "t.petch" >
>>
>>
>>         > On Fri, Nov 24, 2017 at 3:02 AM, t.petch
>>         > wrote:
>>         >
>>         > > 
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > ----- Original Message -----
>>         > > From: "Robert Wilton" >         >
>>         > > Sent: Thursday, November 23, 2017 10:44 AM
>>         > >
>>         > > > Hi Andy,
>>         > > >
>>         > > > On 22/11/2017 18:09, Andy Bierman wrote:
>>         > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
>>         > > > >
>>         > > > >     Hi Rob,
>>         > > > >
>>         > > > >     At that points in time, if it clarifies the spec.
>>         and the
>>         > > authors
>>         > > > >     agree with this, let's do the right thing.
>>         > > > >
>>         > > > > I will add the new text if that is what the WG wants.
>>         > >
>>         > > > Having read this draft, I was undecided what the
>>         intended behavior
>>         > > > actually should be.
>>         > > >
>>         > > > The way that Yumapro and Tail-f have implemented this is
>>         reasonable,
>>         > > and
>>         > > > is probably also the way that I would implemented it.
>>         > > >
>>         > > > But I also think that it would be a reasonable
>>         implementation for
>>         a
>>         > > > server to calculate the full change set (taking account
>>         of side
>>         > > effects
>>         > > > from when and choice statements) to the datastore
>>         before checking
>>         the
>>         > > > "write data node access control" against the resultant
>>         change set.
>>         > > >
>>         > > > My interpretation is that the RFC text is ambiguous on
>>         what the
>>         > > correct
>>         > > > behavior is, and one could make a reasonable argument
>>         that the
>>         current
>>         > > > RFC actually specifies that the alternative behavior is
>>         correct,
>>         i.e.
>>         > > > requiring delete access even if a node is implicitly
>>         changes as a
>>         side
>>         > > > effect. E.g. section 3.2.3 of RFC 6536 states:
>>         > > >
>>         > > >     If the protocol operation would result in the
>>         deletion of a
>>         > > datastore
>>         > > >     node and the user does not have "delete" access
>>         permission for
>>         > > that
>>         > > >     node, the protocol operation is rejected with an
>>         "access-denied"
>>         > > >     error.
>>         > >
>>         > > Rob
>>         > >
>>         > > I have been reading that paragraph since this thread
>>         started and
>>         > > wondering how it could be thought unclear, what am I
>>         missing:-)
>>         > >
>>         > > To me it clearly states that the user must have the
>>         appropriate
>>         access
>>         > > for the consequences of whatever they do, be that 'when',
>>         'choice'
>>         or
>>         > > anything else! Indeed, I see exactly that behaviour in
>>         operational
>>         > > (non-network) databases of which I am a user with limited
>>         privileges.
>>         > >
>>         > >
>>         >
>>         > This is not correct.
>>         > The server is the entity that is cleaning up false when-stmt or
>>         unselected
>>         > cases
>>         > for a choice-stmt.
>>         >
>>         > NACM does not prevent the sever from making any changes to
>>         the system.
>>         > It only affects the operations requested by a client.
>>
>>         Andy
>>
>>         My model is slightly different, that the server is a black
>>         box, with an
>>         interface through which I can make authorised changes.  If
>>         something I
>>         do causes the deletion of something I am not allowed to
>>         delete, may be
>>         not even to read, well, we part company on the acceptability
>>         of that!
>>
>>         I do accept, as Randy points out, that the situation is
>>         complicated.  I
>>         am reminded of the issues that came up relating to the 'when'
>>         statement
>>         when preparing YANG 1.1.  Yes, 'when' makes things possible
>>         and is very
>>         useful but at the same time, its side effects can be
>>         troublesome.  I
>>         would like to wrap it up in a conceptual bubble so you could
>>         not have
>>         the sort of fine-grained access control that allows the case
>>         that Rob
>>         postulates to occur but have no idea what that might look
>>         like.  And I
>>         don't know how much 'when' is used in that way in existing YANG
>>         modules - uh huh, more reading required.
>>
>>
>>
>>     When the access control is too complicated, it does not get used.
>>     Instead, the most likely access control is "everybody is the root
>>     user".
>>     The server pruning of false when/choice data nodes is considered
>>     cleanup.
>>     The pruned data is no longer relevant to the data model. This is
>>     the indended
>>     use, but when-stmt can easily be abused.
>>
>>     The complex tangled web of dependencies is no worse
>>     than it has been with CLI for 30 years, where every dependency is
>>     ad-hoc
>>     and probably undocumented. The granularity of CLI-based access
>>     control
>>     is less granular than NACM.
>>
>>     It is possible that vendors and operators are willing to spend
>>     hours and days
>>     figuring out how to tune the NACM rules to allow a specific edit
>>     to work.
>>     Of course the operator will not even be told by the server which
>>     nodes
>>     are blocking the edit. That would be a security risk.
>>
>>     IMO NACM will be completely unusable if rules are needed to allow
>>     server cleanup of dead nodes.  The additional NACM rules required
>>     might provide more access than intended (unless lots of delete-only
>>     rules are added). The huge jump in NACM rule management complexity is
>>     a new security vulnerability, which might even be worse than the
>>     vulnerability it is intended to fix.
>>
>>
>>
>>         Tom Petch
>>
>>         >
>>         > Andy
>>         >
>>
>>
>>
>>
>>     Andy
>>
>>
>>
>>
>>
>>
>>
>>         > > My other thought was that given all the complexities of
>>         'when' that
>>         > > emerged during the specification of YANG 1.1, perhaps,
>>         were I an
>>         > > implementor of this, I would take the easy option and
>>         ignore the
>>         side
>>         > > effects of 'when'; but I might feel guilty about doing so.
>>         > >
>>         > > If the new paragraphs go in as proposed, then I think
>>         that the two
>>         > > paragraphs you quote need changing else that section
>>         looks to me
>>         like an
>>         > > oxymoron.
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > > An  request that causes a when constraint to
>>         evaluate
>>         > > > differently does result in a deletion of those data
>>         nodes from the
>>         > > > datastore, and hence according to the text above, requires
>>         explicit
>>         > > > "delete" access permission to accomplish that.
>>         > > >
>>         > > > Clearly it would be an interop issue if different servers
>>         implemented
>>         > > > the NACM path based filtering differently.
>>         > > >
>>         > > > Hence why I think that it would be prudent for the
>>         draft to be
>>         more
>>         > > > explicit on when and choice statement handling.
>>         > > >
>>         > > > Rob
>>         > > >
>>         > > > > There have not been any comments on this issue.
>>         > > > >
>>         > > > > Andy
>>         > > > >
>>         > > > >     Regards, Benoit.
>>         > > > >>
>>         > > > >>     Hi Benoit,
>>         > > > >>
>>         > > > >>     There is also one further, unrelated change that
>>         I am
>>         proposing
>>         > > > >>     is made the draft before it is published, to
>>         help better
>>         > > clarify
>>         > > > >>     the expected behavior. It isn't the end of the
>>         world if
>>         this
>>         > > > >>     doesn't go in, but I think that it prevents
>>         sometime taking
>>         a
>>         > > > >>     different, but IMO reasonable, interpretation of
>>         how "when"
>>         > > > >>     statements are considered, and then having a future
>>         argument
>>         > > > >>     about what behavior it specified in the standard.
>>         > > > >>
>>         > > > >>     If we clarify it now, then it closes that door :-)
>>         > > > >>
>>         > > > >>     I've proposed text to Andy and Martin on Monday,
>>         but I've
>>         not
>>         > > > >>     heard back yet.
>>         > > > >>
>>         > > > >>     Netconf email with proposed text attached. The
>>         text doesn't
>>         > > > >>     necessarily have to match this, but personally I
>>         think that
>>         it
>>         > > is
>>         > > > >>     useful if the draft says something on this.
>>         > > > >>
>>         > > > >>     Thanks,
>>         > > > >>     Rob
>>         > > > >>
>>         > > > >>
>>         > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
>>         > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>>         > > > >>>>     Hi,
>>         > > > >>>>
>>         > > > >>>>     Here are some proposed edits to make the data rule
>>         consistent
>>         > > > >>>>     with the examples.
>>         > > > >>>>     Note that this issue is not related to the
>>         edit in the
>>         > > original
>>         > > > >>>>     1-week change.
>>         > > > >>>     That's right, but we found a source of
>>         misinterpretation
>>         in
>>         > > the
>>         > > > >>>     draft and you have rightly corrected it in the
>>         github v9.
>>         > > > >>>
>>         > > > >>>     Regards, Benoit
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     sec. 3.3.5:
>>         > > > >>>>
>>         > > > >>>>     OLD:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     data node rule: controls access for a specific
>>         data
>>         > > > >>>>     node, identified
>>         > > > >>>>     by its path location within the conceptual XML
>>         document
>>         > > > >>>>     for the
>>         > > > >>>>     data node.
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     NEW:
>>         > > > >>>>
>>         > > > >>>>     data node rule: controls access for a specific
>>         data node
>>         > > > >>>>     and its descendants,
>>         > > > >>>>     identified by its path location within the
>>         conceptual XML
>>         > > > >>>>     document for the
>>         > > > >>>>     data node.
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     sec 3.4.5, step 6, bullet 2:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     OLD:
>>         > > > >>>>
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         > > > >>>>     type" is "data-node" and the "path" matches the
>>         > > > >>>>     requested
>>         > > > >>>>     data node, action node, or notification node.
>>         > > > >>>>
>>         > > > >>>>     NEW:
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         > > > >>>>     type" is "data-node" and the "path" matches the
>>         > > > >>>>     requested
>>         > > > >>>>     data node, action node, or notification node.
>>         A path is
>>         > > > >>>>     considered to match if the current data node
>>         is the
>>         > > > >>>>     data node
>>         > > > >>>>     specified by the path, or is a descendant data
>>         node
>>         > > > >>>>     of this data node.
>>         > > > >>>>     appendix B.4: (2 bugs in explanation)
>>         > > > >>>>     OLD:
>>         > > > >>>>     deny-nacm: This rule denies the "guest" group
>>         any access
>>         to
>>         > > the
>>         > > > >>>>   subtree. Note that the default namespace
>>         is only
>>         > > > >>>>     applicable because this subtree is defined in
>>         the same
>>         > > > >>>>     namespace as the  element.
>>         > > > >>>>     NEW:
>>         > > > >>>>     deny-nacm: This rule denies the "guest" group
>>         any access
>>         to
>>         > > the
>>         > > > >>>>   subtree.
>>         > > > >>>>     Andy
>>         > > > >>>>
>>         > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>>         > > > >>>>     
>>         >> wrote:
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert
>>         Wilton
>>         > > > >>>>>  
>>         >>
>>         wrote:
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>
>>         > > > >>>>>  On 10/11/2017 15:49, Andy Bierman wrote:
>>         > > > >>>>>>
>>         > > > >>>>>>
>>         > > 
>>         > >
>>         > >
>>         >
>>
>>
>
>


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


  
    
  
  
    


    

    

    
On 27/11/2017 15:12, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Nov 27, 2017 at 2:39 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
I do get the point that Tom is making here, and have
                  quite a lot of sympathy for it.  E.g. by automatically
                  allowing the side effects of when/choice statements
                  then we are introducing a potential security hole here
                  that operators may find hard to be aware of and
                  mitigate.

                

                
It also seems odd to me that a client is allowed to
                  implicitly remove some configuration through the side
                  effect of a when/choice statement that they are not
                  allowed to delete explicitly.

                
The alternative of requiring appropriate access for
                  the side-effects, seems like an intuitively safer
                  design, but I also get Andy's concern that security
                  isn't useful if it become so unwieldy that nobody uses
                  it.

                
So, I guess the question here is, do we have some
                  concrete examples using real data models where the
                  extra NACM delete rules would be required?  If not
                  then perhaps requiring the explicit access for side
                  effects would be better.

              

            

            


            

            


            

            
Yes -- please provide some examples where it is better
              to force the operator

            
to provide extra "delete" rules to allow false-when
              data nodes to be deleted.

          

        

      

    

    

      

        

          

            
It seems to me that these rules would allow individual
              data structures to be

            
removed by the client, that would not otherwise be
              possible.

          

        

      

    

    Yes, this is true.

    

    But it is still odd that they a client is allowed to delete the
    configuration, just not explicitly.  I.e. it is strange that they
    are not allowed to put in a semantically equivalent request that
    explicitly deletes the configuration, they are only allowed to do it
    if the delete is implicit.  This seems inconsistent.

    

    

      

        

          

            


            

            
If 3 data structures need to be in place "when /foo
              exists" then

            
deleting 1 or 2 of them directly may not be desirable. 
              Deleting

            
them all together (i.e., via when-false deletion) may
              be the intended usage.

          

        

      

    

    If there is a dependency that all three exist then that may be
    better expressed with a must statement instead.

    

    

      

        

          

            


            

            
The vendor and operator need to be aware of the data
              model dependencies.

            
That said, how come CLI-based configuration does not
              have this problem?

          

        

      

    

    My experience of CLI based configurations do have these sorts of
    problems, and many more :-)

    

    

    

      

        

          

            
(Or rather, why has this problem been ignored for so
              long? Maybe it not that real?)

          

        

      

    

    This may be the real crux of the argument:

    

    It probably doesn't make sense to use when statements on disjoint
    parts of the YANG schema (e.g. it does not make sense for the OSPF
    YANG model to depend on whether an interface it runs over has an IP
    address configured).  Instead, a more normal usage would be a flag
    (e.g. like interface type) to allow/prevent certain child nodes from
    being available.  In these scenarios, if a user is allowed to change
    the type of an interface then they are most likely allowed to change
    the other settings on the interface as well.

    

    So for 'normal' when statements, it probably doesn't make much
    difference whether or not explicit NACM access is required to the
    nodes being implicitly deleted because the client probably already
    has the necessary access rights.

    

    But for the 'corner case' when statement scenario, that are unlikely
    to be used, it still seems safer to require explicit access
    permissions than implicitly accepting the side effect with no NACM
    validation.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            

              

                
Thanks,

                  Rob

              

            

            


            

            
Andy

            
 

            

              

                


                

                
On
                  25/11/2017 15:53, Andy Bierman wrote:

                

                

                  


                    


                      
On Sat, Nov 25, 2017 at
                        4:42 AM, t.petch <ietfc@btconnect.com>
                        wrote:

                        
----- Original Message
                          -----

                          From: "Andy Bierman" <andy@yumaworks.com>

                          To: "t.petch" <ietfc@btconnect.com>

                          

                          

                          > On Fri, Nov 24, 2017 at 3:02 AM, t.petch
                          <ietfc@btconnect.com>
                          wrote:

                          >

                          > > <inline>

                          > >

                          > > Tom Petch

                          > >

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

                          > > From: "Robert Wilton" <rwilton@cisco.com>

                          > > Sent: Thursday, November 23, 2017
                          10:44 AM

                          > >

                          > > > Hi Andy,

                          > > >

                          > > > On 22/11/2017 18:09, Andy
                          Bierman wrote:

                          > > > > On Wed, Nov 22, 2017 at
                          5:41 AM, Benoit Claise wrote:

                          > > > >

                          > > > >     Hi Rob,

                          > > > >

                          > > > >     At that points in
                          time, if it clarifies the spec. and the

                          > > authors

                          > > > >     agree with this, let's
                          do the right thing.

                          > > > >

                          > > > > I will add the new text if
                          that is what the WG wants.

                          > >

                          > > > Having read this draft, I was
                          undecided what the intended behavior

                          > > > actually should be.

                          > > >

                          > > > The way that Yumapro and Tail-f
                          have implemented this is

                          reasonable,

                          > > and

                          > > > is probably also the way that I
                          would implemented it.

                          > > >

                          > > > But I also think that it would
                          be a reasonable implementation for

                          a

                          > > > server to calculate the full
                          change set (taking account of side

                          > > effects

                          > > > from when and choice
                          statements) to the datastore before checking

                          the

                          > > > "write data node access
                          control" against the resultant change set.

                          > > >

                          > > > My interpretation is that the
                          RFC text is ambiguous on what the

                          > > correct

                          > > > behavior is, and one could make
                          a reasonable argument that the

                          current

                          > > > RFC actually specifies that the
                          alternative behavior is correct,

                          i.e.

                          > > > requiring delete access even if
                          a node is implicitly changes as a

                          side

                          > > > effect. E.g. section 3.2.3 of
                          RFC 6536 states:

                          > > >

                          > > >     If the protocol operation
                          would result in the deletion of a

                          > > datastore

                          > > >     node and the user does not
                          have "delete" access permission for

                          > > that

                          > > >     node, the protocol
                          operation is rejected with an

                          "access-denied"

                          > > >     error.

                          > >

                          > > Rob

                          > >

                          > > I have been reading that paragraph
                          since this thread started and

                          > > wondering how it could be thought
                          unclear, what am I missing:-)

                          > >

                          > > To me it clearly states that the
                          user must have the appropriate

                          access

                          > > for the consequences of whatever
                          they do, be that 'when', 'choice'

                          or

                          > > anything else! Indeed, I see exactly
                          that behaviour in operational

                          > > (non-network) databases of which I
                          am a user with limited

                          privileges.

                          > >

                          > >

                          >

                          > This is not correct.

                          > The server is the entity that is cleaning
                          up false when-stmt or

                          unselected

                          > cases

                          > for a choice-stmt.

                          >

                          > NACM does not prevent the sever from
                          making any changes to the system.

                          > It only affects the operations requested
                          by a client.

                          

                          Andy

                          

                          My model is slightly different, that the
                          server is a black box, with an

                          interface through which I can make authorised
                          changes.  If something I

                          do causes the deletion of something I am not
                          allowed to delete, may be

                          not even to read, well, we part company on the
                          acceptability of that!

                          

                          I do accept, as Randy points out, that the
                          situation is complicated.  I

                          am reminded of the issues that came up
                          relating to the 'when' statement

                          when preparing YANG 1.1.  Yes, 'when' makes
                          things possible and is very

                          useful but at the same time, its side effects
                          can be troublesome.  I

                          would like to wrap it up in a conceptual
                          bubble so you could not have

                          the sort of fine-grained access control that
                          allows the case that Rob

                          postulates to occur but have no idea what that
                          might look like.  And I

                          don't know how much 'when' is used in that way
                          in existing YANG

                          modules - uh huh, more reading required.

                        

                        


                        

                        


                        

                        
When the access control is too complicated,
                          it does not get used.

                        
Instead, the most likely access control is
                          "everybody is the root user".

                        
The server pruning of false when/choice
                          data nodes is considered cleanup.

                        

                        
The pruned data is no longer relevant to
                          the data model. This is the indended

                        
use, but when-stmt can easily be abused.

                        


                        

                        
The complex tangled web of dependencies is
                          no worse

                        
than it has been with CLI for 30 years,
                          where every dependency is ad-hoc

                        
and probably undocumented. The granularity
                          of CLI-based access control

                        
is less granular than NACM.

                        


                        

                        
It is possible that vendors and operators
                          are willing to spend hours and days

                        
figuring out how to tune the NACM rules to
                          allow a specific edit to work.

                        
Of course the operator will not even be
                          told by the server which nodes

                        
are blocking the edit. That would be a
                          security risk.

                        


                        

                        
IMO NACM will be completely unusable if
                          rules are needed to allow

                        
server cleanup of dead nodes.  The
                          additional NACM rules required

                        
might provide more access than intended
                          (unless lots of delete-only

                        
rules are added). The huge jump in NACM
                          rule management complexity is

                        
a new security vulnerability, which might
                          even be worse than the

                        
vulnerability it is intended to fix.

                        


                        

                        


                        

                        
 

                          Tom Petch

                          

                          >

                          > Andy

                          >

                          

                          

                          

                        

                        


                        

                        
Andy

                        


                        

                        
 

                        
 

                          

                          

                          

                          

                          

                          > > My other thought was that given all
                          the complexities of 'when' that

                          > > emerged during the specification of
                          YANG 1.1, perhaps, were I an

                          > > implementor of this, I would take
                          the easy option and ignore the

                          side

                          > > effects of 'when'; but I might feel
                          guilty about doing so.

                          > >

                          > > If the new paragraphs go in as
                          proposed, then I think that the two

                          > > paragraphs you quote need changing
                          else that section looks to me

                          like an

                          > > oxymoron.

                          > >

                          > > Tom Petch

                          > >

                          > > > An <edit-data> request
                          that causes a when constraint to evaluate

                          > > > differently does result in a
                          deletion of those data nodes from the

                          > > > datastore, and hence according
                          to the text above, requires

                          explicit

                          > > > "delete" access permission to
                          accomplish that.

                          > > >

                          > > > Clearly it would be an interop
                          issue if different servers

                          implemented

                          > > > the NACM path based filtering
                          differently.

                          > > >

                          > > > Hence why I think that it would
                          be prudent for the draft to be

                          more

                          > > > explicit on when and choice
                          statement handling.

                          > > >

                          > > > Rob

                          > > >

                          > > > > There have not been any
                          comments on this issue.

                          > > > >

                          > > > > Andy

                          > > > >

                          > > > >     Regards, Benoit.

                          > > > >>

                          > > > >>     Hi Benoit,

                          > > > >>

                          > > > >>     There is also one
                          further, unrelated change that I am

                          proposing

                          > > > >>     is made the draft
                          before it is published, to help better

                          > > clarify

                          > > > >>     the expected
                          behavior. It isn't the end of the world if

                          this

                          > > > >>     doesn't go in, but
                          I think that it prevents sometime taking

                          a

                          > > > >>     different, but IMO
                          reasonable, interpretation of how "when"

                          > > > >>     statements are
                          considered, and then having a future

                          argument

                          > > > >>     about what
                          behavior it specified in the standard.

                          > > > >>

                          > > > >>     If we clarify it
                          now, then it closes that door :-)

                          > > > >>

                          > > > >>     I've proposed text
                          to Andy and Martin on Monday, but I've

                          not

                          > > > >>     heard back yet.

                          > > > >>

                          > > > >>     Netconf email with
                          proposed text attached. The text doesn't

                          > > > >>     necessarily have
                          to match this, but personally I think that

                          it

                          > > is

                          > > > >>     useful if the
                          draft says something on this.

                          > > > >>

                          > > > >>     Thanks,

                          > > > >>     Rob

                          > > > >>

                          > > > >>

                          > > > >>     On 22/11/2017
                          13:25, Benoit Claise wrote:

                          > > > >>>     On 11/10/2017
                          7:23 PM, Andy Bierman wrote:

                          > > > >>>>     Hi,

                          > > > >>>>

                          > > > >>>>     Here are
                          some proposed edits to make the data rule

                          consistent

                          > > > >>>>     with the
                          examples.

                          > > > >>>>     Note that
                          this issue is not related to the edit in the

                          > > original

                          > > > >>>>     1-week
                          change.

                          > > > >>>     That's right,
                          but we found a source of misinterpretation

                          in

                          > > the

                          > > > >>>     draft and you
                          have rightly corrected it in the github v9.

                          > > > >>>

                          > > > >>>     Regards,
                          Benoit

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>     sec.
                          3.3.5:

                          > > > >>>>

                          > > > >>>>     OLD:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>     data node
                          rule: controls access for a specific data

                          > > > >>>>     node,
                          identified

                          > > > >>>>     by its
                          path location within the conceptual XML
                          document

                          > > > >>>>     for the

                          > > > >>>>     data node.

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>     NEW:

                          > > > >>>>

                          > > > >>>>     data node
                          rule: controls access for a specific data node

                          > > > >>>>     and its
                          descendants,

                          > > > >>>>     identified
                          by its path location within the conceptual XML

                          > > > >>>>     document
                          for the

                          > > > >>>>     data node.

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>     sec 3.4.5,
                          step 6, bullet 2:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>     OLD:

                          > > > >>>>

                          > > > >>>>     * The rule
                          does not have a "rule-type" defined or the

                          > > > >>>>     "rule-

                          > > > >>>>     type" is
                          "data-node" and the "path" matches the

                          > > > >>>>     requested

                          > > > >>>>     data node,
                          action node, or notification node.

                          > > > >>>>

                          > > > >>>>     NEW:

                          > > > >>>>     * The rule
                          does not have a "rule-type" defined or the

                          > > > >>>>     "rule-

                          > > > >>>>     type" is
                          "data-node" and the "path" matches the

                          > > > >>>>     requested

                          > > > >>>>     data node,
                          action node, or notification node. A path is

                          > > > >>>>     considered
                          to match if the current data node is the

                          > > > >>>>     data node

                          > > > >>>>     specified
                          by the path, or is a descendant data node

                          > > > >>>>     of this
                          data node.

                          > > > >>>>     appendix
                          B.4: (2 bugs in explanation)

                          > > > >>>>     OLD:

                          > > > >>>>     deny-nacm:
                          This rule denies the "guest" group any access

                          to

                          > > the

                          > > > >>>>   
                           <nacm> subtree. Note that the default
                          namespace is only

                          > > > >>>>     applicable
                          because this subtree is defined in the same

                          > > > >>>>     namespace
                          as the <data-rule> element.

                          > > > >>>>     NEW:

                          > > > >>>>     deny-nacm:
                          This rule denies the "guest" group any access

                          to

                          > > the

                          > > > >>>>   
                           <nacm> subtree.

                          > > > >>>>     Andy

                          > > > >>>>

                          > > > >>>>     On Fri,
                          Nov 10, 2017 at 9:24 AM, Robert Wilton

                          > > > >>>>     <rwilton@cisco.com
                          <mailto:rwilton@cisco.com>>
                          wrote:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>         On
                          10/11/2017 16:33, Andy Bierman wrote:

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>         On
                          Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton

                          > > > >>>>>       
                           <rwilton@cisco.com
                          <mailto:rwilton@cisco.com>>

                          wrote:

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>           
                           On 10/11/2017 15:49, Andy Bierman wrote:

                          > > > >>>>>>

                          > > > >>>>>>

                          > > <snip>

                          > >

                          > >

                          >

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------FE8CB7D9D26B67B49C8B9E2E--


From nobody Mon Nov 27 08:26:17 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBD3126C3D for ; Mon, 27 Nov 2017 08:26:15 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 3KWZvHS_NV0Q for ; Mon, 27 Nov 2017 08:26:13 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 2506D12426E for ; Mon, 27 Nov 2017 08:26:12 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id y2so32509937lfj.4 for ; Mon, 27 Nov 2017 08:26:12 -0800 (PST)
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=z6eAhkVZYHHFUypsxJ3gPY2hchVlWsQCzsrJ846Gk8s=; b=hydAVfw1Vqsn/z+EKl7YdQUGQ/d4OyfU5hkFAwjvf3qzZdssBy4rbsONurJN0LH/Dm Hys+tEfxKD9NIZw1GqXQYk7ZkzUrRjiwehJLts2FT4l6HzwvwdB1qSbYctzuy17nNBOQ zpsTkFbtji3uDjpdFO/DGBF1js6XD2XSFDF43ozlLnIdGyLLeGpgw0yyvew+3C32q+7h FpxutUMk96drhKdSh5/RohrcgGVzZ/MTE3i6iWWMPHYIPvv2FynkxF5yo6mRH5Tkvgth rVc/GOjm/6UUpQCFaLDLDW19l6nLCUVp/fi7ySTLG9XmfQ+/dbLNPCTBcYtqvCtlxWMh +1qw==
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=z6eAhkVZYHHFUypsxJ3gPY2hchVlWsQCzsrJ846Gk8s=; b=RoIQyrTTLdckaXSq0TCK9bTSW0u8pCsX4COd71jtxTaX/861s/MGtuSrzw0RklD4xl G4ONFeQSomA0ie36PQsSgFIkDytCzV4yUO2Os8Z8Ghy+dqUBYeoDrv9Nx15ef6byBJwA DGx1lHL0gdUTjeZt2Ame67mrcuvIR/BfS/mtzIY1lpdQ3hW3S0/uzfHlnZ2vA6mIJL/c L7XDy/yLJaRgyBcblHaNIBA2pE0gVC5CUc2qxnWNTHcB/40LGU4U7QdHLfX8W2Edkbef wBrxr4ESxiMIrBUyqeaisn6O/7EatT5R/OACR4Zrd1POXiefVa7mCTb7PHBLAdbzghI0 qQBg==
X-Gm-Message-State: AJaThX7XJ9f0Aksu9k8epkD0mA0mge7Xcf2RiqI4pCFsu9c5qiAZ/5+Z qpO6I+llKGWA7hY3gSG0FKGEaZj6o570BCMOgUUavA==
X-Google-Smtp-Source: AGs4zMbQxMVPOL9juFOFE7gA4ZZSTc4sxxIvnF84P+j7Mwy3QBkBCrNRR2vFhq5JqqixpU89/2wYbqYxpSg72MUcosQ=
X-Received: by 10.46.57.10 with SMTP id g10mr3539319lja.77.1511799970101; Mon, 27 Nov 2017 08:26:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 08:26:08 -0800 (PST)
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>    
From: Andy Bierman 
Date: Mon, 27 Nov 2017 08:26:08 -0800
Message-ID: 
To: Robert Wilton 
Cc: "t.petch" , NETCONF , sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="089e082f5ce4308f84055ef95c94"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 16:26:15 -0000

--089e082f5ce4308f84055ef95c94
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton  wrote:

>
>
> On 27/11/2017 15:12, Andy Bierman wrote:
>
>
>
> On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton  wrote:
>
>> I do get the point that Tom is making here, and have quite a lot of
>> sympathy for it.  E.g. by automatically allowing the side effects of
>> when/choice statements then we are introducing a potential security hole
>> here that operators may find hard to be aware of and mitigate.
>>
>> It also seems odd to me that a client is allowed to implicitly remove
>> some configuration through the side effect of a when/choice statement that
>> they are not allowed to delete explicitly.
>>
>> The alternative of requiring appropriate access for the side-effects,
>> seems like an intuitively safer design, but I also get Andy's concern that
>> security isn't useful if it become so unwieldy that nobody uses it.
>>
>> So, I guess the question here is, do we have some concrete examples using
>> real data models where the extra NACM delete rules would be required?  If
>> not then perhaps requiring the explicit access for side effects would be
>> better.
>>
>
>
> Yes -- please provide some examples where it is better to force the
> operator
> to provide extra "delete" rules to allow false-when data nodes to be
> deleted.
>
> It seems to me that these rules would allow individual data structures to
> be
> removed by the client, that would not otherwise be possible.
>
> Yes, this is true.
>
> But it is still odd that they a client is allowed to delete the
> configuration, just not explicitly.  I.e. it is strange that they are not
> allowed to put in a semantically equivalent request that explicitly deletes
> the configuration, they are only allowed to do it if the delete is
> implicit.  This seems inconsistent.
>
>
It is just as odd that a request  to create /foo/case1 will work if nothing
from
the choice-stmt exists, but will fail if /foo/case2 has to be deleted in
order
to create /foo/case1.



> If 3 data structures need to be in place "when /foo exists" then
> deleting 1 or 2 of them directly may not be desirable.  Deleting
> them all together (i.e., via when-false deletion) may be the intended
> usage.
>
> If there is a dependency that all three exist then that may be better
> expressed with a must statement instead.
>
>
> The vendor and operator need to be aware of the data model dependencies.
> That said, how come CLI-based configuration does not have this problem?
>
> My experience of CLI based configurations do have these sorts of problems,
> and many more :-)
>


>
> (Or rather, why has this problem been ignored for so long? Maybe it not
> that real?)
>
> This may be the real crux of the argument:
>
> It probably doesn't make sense to use when statements on disjoint parts of
> the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> depend on whether an interface it runs over has an IP address configured).
> Instead, a more normal usage would be a flag (e.g. like interface type) to
> allow/prevent certain child nodes from being available.  In these
> scenarios, if a user is allowed to change the type of an interface then
> they are most likely allowed to change the other settings on the interface
> as well.
>
> So for 'normal' when statements, it probably doesn't make much difference
> whether or not explicit NACM access is required to the nodes being
> implicitly deleted because the client probably already has the necessary
> access rights.
>
> But for the 'corner case' when statement scenario, that are unlikely to be
> used, it still seems safer to require explicit access permissions than
> implicitly accepting the side effect with no NACM validation.
>


This is fine, except there is no way to tell a normal when from a
corner-case when.

In all cases, the false-when evaluation means the node is not relevant to
the model anymore.
Same for a case that is being replaced by a different case.
In order for this NACM threat to be real. the YANG modeler needs to be
wrong about
whether the false-when states are actually irrelevant to the model in its
new state.



> Thanks,
> Rob
>


Andy


>
>
>
> Thanks,
>> Rob
>>
>
> Andy
>
>
>>
>> On 25/11/2017 15:53, Andy Bierman wrote:
>>
>>
>>
>> On Sat, Nov 25, 2017 at 4:42 AM, t.petch  wrote:
>>
>>> ----- Original Message -----
>>> From: "Andy Bierman" 
>>> To: "t.petch" 
>>>
>>>
>>> > On Fri, Nov 24, 2017 at 3:02 AM, t.petch  wrote:
>>> >
>>> > > 
>>> > >
>>> > > Tom Petch
>>> > >
>>> > > ----- Original Message -----
>>> > > From: "Robert Wilton" 
>>> > > Sent: Thursday, November 23, 2017 10:44 AM
>>> > >
>>> > > > Hi Andy,
>>> > > >
>>> > > > On 22/11/2017 18:09, Andy Bierman wrote:
>>> > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
>>> > > > >
>>> > > > >     Hi Rob,
>>> > > > >
>>> > > > >     At that points in time, if it clarifies the spec. and the
>>> > > authors
>>> > > > >     agree with this, let's do the right thing.
>>> > > > >
>>> > > > > I will add the new text if that is what the WG wants.
>>> > >
>>> > > > Having read this draft, I was undecided what the intended behavior
>>> > > > actually should be.
>>> > > >
>>> > > > The way that Yumapro and Tail-f have implemented this is
>>> reasonable,
>>> > > and
>>> > > > is probably also the way that I would implemented it.
>>> > > >
>>> > > > But I also think that it would be a reasonable implementation for
>>> a
>>> > > > server to calculate the full change set (taking account of side
>>> > > effects
>>> > > > from when and choice statements) to the datastore before checking
>>> the
>>> > > > "write data node access control" against the resultant change set.
>>> > > >
>>> > > > My interpretation is that the RFC text is ambiguous on what the
>>> > > correct
>>> > > > behavior is, and one could make a reasonable argument that the
>>> current
>>> > > > RFC actually specifies that the alternative behavior is correct,
>>> i.e.
>>> > > > requiring delete access even if a node is implicitly changes as a
>>> side
>>> > > > effect. E.g. section 3.2.3 of RFC 6536 states:
>>> > > >
>>> > > >     If the protocol operation would result in the deletion of a
>>> > > datastore
>>> > > >     node and the user does not have "delete" access permission for
>>> > > that
>>> > > >     node, the protocol operation is rejected with an
>>> "access-denied"
>>> > > >     error.
>>> > >
>>> > > Rob
>>> > >
>>> > > I have been reading that paragraph since this thread started and
>>> > > wondering how it could be thought unclear, what am I missing:-)
>>> > >
>>> > > To me it clearly states that the user must have the appropriate
>>> access
>>> > > for the consequences of whatever they do, be that 'when', 'choice'
>>> or
>>> > > anything else! Indeed, I see exactly that behaviour in operational
>>> > > (non-network) databases of which I am a user with limited
>>> privileges.
>>> > >
>>> > >
>>> >
>>> > This is not correct.
>>> > The server is the entity that is cleaning up false when-stmt or
>>> unselected
>>> > cases
>>> > for a choice-stmt.
>>> >
>>> > NACM does not prevent the sever from making any changes to the system.
>>> > It only affects the operations requested by a client.
>>>
>>> Andy
>>>
>>> My model is slightly different, that the server is a black box, with an
>>> interface through which I can make authorised changes.  If something I
>>> do causes the deletion of something I am not allowed to delete, may be
>>> not even to read, well, we part company on the acceptability of that!
>>>
>>> I do accept, as Randy points out, that the situation is complicated.  I
>>> am reminded of the issues that came up relating to the 'when' statement
>>> when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
>>> useful but at the same time, its side effects can be troublesome.  I
>>> would like to wrap it up in a conceptual bubble so you could not have
>>> the sort of fine-grained access control that allows the case that Rob
>>> postulates to occur but have no idea what that might look like.  And I
>>> don't know how much 'when' is used in that way in existing YANG
>>> modules - uh huh, more reading required.
>>>
>>
>>
>> When the access control is too complicated, it does not get used.
>> Instead, the most likely access control is "everybody is the root user".
>> The server pruning of false when/choice data nodes is considered cleanup.
>> The pruned data is no longer relevant to the data model. This is the
>> indended
>> use, but when-stmt can easily be abused.
>>
>> The complex tangled web of dependencies is no worse
>> than it has been with CLI for 30 years, where every dependency is ad-hoc
>> and probably undocumented. The granularity of CLI-based access control
>> is less granular than NACM.
>>
>> It is possible that vendors and operators are willing to spend hours and
>> days
>> figuring out how to tune the NACM rules to allow a specific edit to work.
>> Of course the operator will not even be told by the server which nodes
>> are blocking the edit. That would be a security risk.
>>
>> IMO NACM will be completely unusable if rules are needed to allow
>> server cleanup of dead nodes.  The additional NACM rules required
>> might provide more access than intended (unless lots of delete-only
>> rules are added). The huge jump in NACM rule management complexity is
>> a new security vulnerability, which might even be worse than the
>> vulnerability it is intended to fix.
>>
>>
>>
>>> Tom Petch
>>>
>>> >
>>> > Andy
>>> >
>>>
>>>
>>>
>>>
>> Andy
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> > > My other thought was that given all the complexities of 'when' that
>>> > > emerged during the specification of YANG 1.1, perhaps, were I an
>>> > > implementor of this, I would take the easy option and ignore the
>>> side
>>> > > effects of 'when'; but I might feel guilty about doing so.
>>> > >
>>> > > If the new paragraphs go in as proposed, then I think that the two
>>> > > paragraphs you quote need changing else that section looks to me
>>> like an
>>> > > oxymoron.
>>> > >
>>> > > Tom Petch
>>> > >
>>> > > > An  request that causes a when constraint to evaluate
>>> > > > differently does result in a deletion of those data nodes from the
>>> > > > datastore, and hence according to the text above, requires
>>> explicit
>>> > > > "delete" access permission to accomplish that.
>>> > > >
>>> > > > Clearly it would be an interop issue if different servers
>>> implemented
>>> > > > the NACM path based filtering differently.
>>> > > >
>>> > > > Hence why I think that it would be prudent for the draft to be
>>> more
>>> > > > explicit on when and choice statement handling.
>>> > > >
>>> > > > Rob
>>> > > >
>>> > > > > There have not been any comments on this issue.
>>> > > > >
>>> > > > > Andy
>>> > > > >
>>> > > > >     Regards, Benoit.
>>> > > > >>
>>> > > > >>     Hi Benoit,
>>> > > > >>
>>> > > > >>     There is also one further, unrelated change that I am
>>> proposing
>>> > > > >>     is made the draft before it is published, to help better
>>> > > clarify
>>> > > > >>     the expected behavior. It isn't the end of the world if
>>> this
>>> > > > >>     doesn't go in, but I think that it prevents sometime taking
>>> a
>>> > > > >>     different, but IMO reasonable, interpretation of how "when"
>>> > > > >>     statements are considered, and then having a future
>>> argument
>>> > > > >>     about what behavior it specified in the standard.
>>> > > > >>
>>> > > > >>     If we clarify it now, then it closes that door :-)
>>> > > > >>
>>> > > > >>     I've proposed text to Andy and Martin on Monday, but I've
>>> not
>>> > > > >>     heard back yet.
>>> > > > >>
>>> > > > >>     Netconf email with proposed text attached. The text doesn't
>>> > > > >>     necessarily have to match this, but personally I think that
>>> it
>>> > > is
>>> > > > >>     useful if the draft says something on this.
>>> > > > >>
>>> > > > >>     Thanks,
>>> > > > >>     Rob
>>> > > > >>
>>> > > > >>
>>> > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
>>> > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
>>> > > > >>>>     Hi,
>>> > > > >>>>
>>> > > > >>>>     Here are some proposed edits to make the data rule
>>> consistent
>>> > > > >>>>     with the examples.
>>> > > > >>>>     Note that this issue is not related to the edit in the
>>> > > original
>>> > > > >>>>     1-week change.
>>> > > > >>>     That's right, but we found a source of misinterpretation
>>> in
>>> > > the
>>> > > > >>>     draft and you have rightly corrected it in the github v9.
>>> > > > >>>
>>> > > > >>>     Regards, Benoit
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>     sec. 3.3.5:
>>> > > > >>>>
>>> > > > >>>>     OLD:
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>     data node rule: controls access for a specific data
>>> > > > >>>>     node, identified
>>> > > > >>>>     by its path location within the conceptual XML document
>>> > > > >>>>     for the
>>> > > > >>>>     data node.
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>     NEW:
>>> > > > >>>>
>>> > > > >>>>     data node rule: controls access for a specific data node
>>> > > > >>>>     and its descendants,
>>> > > > >>>>     identified by its path location within the conceptual XML
>>> > > > >>>>     document for the
>>> > > > >>>>     data node.
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>     sec 3.4.5, step 6, bullet 2:
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>     OLD:
>>> > > > >>>>
>>> > > > >>>>     * The rule does not have a "rule-type" defined or the
>>> > > > >>>>     "rule-
>>> > > > >>>>     type" is "data-node" and the "path" matches the
>>> > > > >>>>     requested
>>> > > > >>>>     data node, action node, or notification node.
>>> > > > >>>>
>>> > > > >>>>     NEW:
>>> > > > >>>>     * The rule does not have a "rule-type" defined or the
>>> > > > >>>>     "rule-
>>> > > > >>>>     type" is "data-node" and the "path" matches the
>>> > > > >>>>     requested
>>> > > > >>>>     data node, action node, or notification node. A path is
>>> > > > >>>>     considered to match if the current data node is the
>>> > > > >>>>     data node
>>> > > > >>>>     specified by the path, or is a descendant data node
>>> > > > >>>>     of this data node.
>>> > > > >>>>     appendix B.4: (2 bugs in explanation)
>>> > > > >>>>     OLD:
>>> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
>>> to
>>> > > the
>>> > > > >>>>      subtree. Note that the default namespace is only
>>> > > > >>>>     applicable because this subtree is defined in the same
>>> > > > >>>>     namespace as the  element.
>>> > > > >>>>     NEW:
>>> > > > >>>>     deny-nacm: This rule denies the "guest" group any access
>>> to
>>> > > the
>>> > > > >>>>      subtree.
>>> > > > >>>>     Andy
>>> > > > >>>>
>>> > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>>> > > > >>>>     > wrote:
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>
>>> > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
>>> > > > >>>>>
>>> > > > >>>>>
>>> > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>>> > > > >>>>>         >
>>> wrote:
>>> > > > >>>>>
>>> > > > >>>>>
>>> > > > >>>>>
>>> > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
>>> > > > >>>>>>
>>> > > > >>>>>>
>>> > > 
>>> > >
>>> > >
>>> >
>>>
>>>
>>
>>
>
>

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




On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 27/11/2017 15:1=
2, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Nov 27, 2017 at 2:39 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
I do get the point that Tom is making here, and have
                  quite a lot of sympathy for it.=C2=A0 E.g. by automatical=
ly
                  allowing the side effects of when/choice statements
                  then we are introducing a potential security hole here
                  that operators may find hard to be aware of and
                  mitigate.

                

                
It also seems odd to me that a client is allowed to
                  implicitly remove some configuration through the side
                  effect of a when/choice statement that they are not
                  allowed to delete explicitly.

                
The alternative of requiring appropriate access for
                  the side-effects, seems like an intuitively safer
                  design, but I also get Andy's concern that security
                  isn't useful if it become so unwieldy that nobody use=
s
                  it.

                
So, I guess the question here is, do we have some
                  concrete examples using real data models where the
                  extra NACM delete rules would be required?=C2=A0 If not
                  then perhaps requiring the explicit access for side
                  effects would be better.

              

            

            


            

            


            

            
Yes -- please provide some examples where it is better
              to force the operator

            
to provide extra "delete" rules to allow false-w=
hen
              data nodes to be deleted.

          

        

      

    

    

      

        

          

            
It seems to me that these rules would allow individual
              data structures to be

            
removed by the client, that would not otherwise be
              possible.

          

        

      

    

    Yes, this is true.

    

    But it is still odd that they a client is allowed to delete the
    configuration, just not explicitly.=C2=A0 I.e. it is strange that they
    are not allowed to put in a semantically equivalent request that
    explicitly deletes the configuration, they are only allowed to do it
    if the delete is implicit.=C2=A0 This seems inconsistent.

    

It is just as odd that a req=
uest =C2=A0to create /foo/case1 will work if nothing from
the cho=
ice-stmt exists, but will fail if /foo/case2 has to be deleted in order
to create /foo/case1.



    

      

        

          

            


            

            
If 3 data structures need to be in place "when /foo
              exists" then

            
deleting 1 or 2 of them directly may not be desirable.=C2=
=A0
              Deleting

            
them all together (i.e., via when-false deletion) may
              be the intended usage.

          

        

      

    

    If there is a dependency that all three exist then that may be
    better expressed with a must statement instead.

    

    

      

        

          

            


            

            
The vendor and operator need to be aware of the data
              model dependencies.

            
That said, how come CLI-based configuration does not
              have this problem?

          

        

      

    

    My experience of CLI based configurations do have these sorts of
    problems, and many more :-)


    

    

    

      

        

          

            
(Or rather, why has this problem been ignored for so
              long? Maybe it not that real?)

          

        

      

    

    This may be the real crux of the argument:

    

    It probably doesn't make sense to use when statements on disjoint
    parts of the YANG schema (e.g. it does not make sense for the OSPF
    YANG model to depend on whether an interface it runs over has an IP
    address configured).=C2=A0 Instead, a more normal usage would be a flag
    (e.g. like interface type) to allow/prevent certain child nodes from
    being available.=C2=A0 In these scenarios, if a user is allowed to chan=
ge
    the type of an interface then they are most likely allowed to change
    the other settings on the interface as well.

    

    So for 'normal' when statements, it probably doesn't make m=
uch
    difference whether or not explicit NACM access is required to the
    nodes being implicitly deleted because the client probably already
    has the necessary access rights.

    

    But for the 'corner case' when statement scenario, that are unl=
ikely
    to be used, it still seems safer to require explicit access
    permissions than implicitly accepting the side effect with no NACM
    validation.


Th=
is is fine, except there is no way to tell a normal when from a corner-case=
 when.

In all cases, the false-when evaluation mea=
ns the node is not relevant to the model anymore.
Same for a case=
 that is being replaced by a different case.
In order for this NA=
CM threat to be real. the YANG modeler needs to be wrong about
wh=
ether the false-when states are actually irrelevant to the model in its new=
 state.


<=
div text=3D"#000000" bgcolor=3D"#FFFFFF">
    

    Thanks,

    Rob


Andy
=

=C2=A0

    

    

    

      

        

          

            


            

            

              

                
Thanks,

                  Rob

              

            

            


            

            
Andy

            
=C2=A0

            

              

                


                

                
On
                  25/11/2017 15:53, Andy Bierman wrote:

                

                

                  


                    


                      
On Sat, Nov 25, 2017 at
                        4:42 AM, t.petch <ietfc@btconnect.com>
                        wrote:

                        
----- Original Messa=
ge
                          -----

                          From: "Andy Bierman" <andy@yumaworks.com>

                          To: "t.petch" <ietfc@btconnect.com>

                          

                          

                          > On Fri, Nov 24, 2017 at 3:02 AM, t.petch
                          <ietfc@btconnect.com>
                          wrote:

                          >

                          > > <inline>

                          > >

                          > > Tom Petch

                          > >

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

                          > > From: "Robert Wilton" <rwilton@cisco.com&g=
t;

                          > > Sent: Thursday, November 23, 2017
                          10:44 AM

                          > >

                          > > > Hi Andy,

                          > > >

                          > > > On 22/11/2017 18:09, Andy
                          Bierman wrote:

                          > > > > On Wed, Nov 22, 2017 at
                          5:41 AM, Benoit Claise wrote:

                          > > > >

                          > > > >=C2=A0 =C2=A0 =C2=A0Hi Rob,
                          > > > >

                          > > > >=C2=A0 =C2=A0 =C2=A0At that po=
ints in
                          time, if it clarifies the spec. and the

                          > > authors

                          > > > >=C2=A0 =C2=A0 =C2=A0agree with=
 this, let's
                          do the right thing.

                          > > > >

                          > > > > I will add the new text if
                          that is what the WG wants.

                          > >

                          > > > Having read this draft, I was
                          undecided what the intended behavior

                          > > > actually should be.

                          > > >

                          > > > The way that Yumapro and Tail-f
                          have implemented this is

                          reasonable,

                          > > and

                          > > > is probably also the way that I
                          would implemented it.

                          > > >

                          > > > But I also think that it would
                          be a reasonable implementation for

                          a

                          > > > server to calculate the full
                          change set (taking account of side

                          > > effects

                          > > > from when and choice
                          statements) to the datastore before checking

                          the

                          > > > "write data node access
                          control" against the resultant change set.
                          > > >

                          > > > My interpretation is that the
                          RFC text is ambiguous on what the

                          > > correct

                          > > > behavior is, and one could make
                          a reasonable argument that the

                          current

                          > > > RFC actually specifies that the
                          alternative behavior is correct,

                          i.e.

                          > > > requiring delete access even if
                          a node is implicitly changes as a

                          side

                          > > > effect. E.g. section 3.2.3 of
                          RFC 6536 states:

                          > > >

                          > > >=C2=A0 =C2=A0 =C2=A0If the protocol=
 operation
                          would result in the deletion of a

                          > > datastore

                          > > >=C2=A0 =C2=A0 =C2=A0node and the us=
er does not
                          have "delete" access permission for

                          > > that

                          > > >=C2=A0 =C2=A0 =C2=A0node, the proto=
col
                          operation is rejected with an

                          "access-denied"

                          > > >=C2=A0 =C2=A0 =C2=A0error.

                          > >

                          > > Rob

                          > >

                          > > I have been reading that paragraph
                          since this thread started and

                          > > wondering how it could be thought
                          unclear, what am I missing:-)

                          > >

                          > > To me it clearly states that the
                          user must have the appropriate

                          access

                          > > for the consequences of whatever
                          they do, be that 'when', 'choice'=


                          or

                          > > anything else! Indeed, I see exactly
                          that behaviour in operational

                          > > (non-network) databases of which I
                          am a user with limited

                          privileges.

                          > >

                          > >

                          >

                          > This is not correct.

                          > The server is the entity that is cleaning
                          up false when-stmt or

                          unselected

                          > cases

                          > for a choice-stmt.

                          >

                          > NACM does not prevent the sever from
                          making any changes to the system.

                          > It only affects the operations requested
                          by a client.

                          

                          Andy

                          

                          My model is slightly different, that the
                          server is a black box, with an

                          interface through which I can make authorised
                          changes.=C2=A0 If something I

                          do causes the deletion of something I am not
                          allowed to delete, may be

                          not even to read, well, we part company on the
                          acceptability of that!

                          

                          I do accept, as Randy points out, that the
                          situation is complicated.=C2=A0 I

                          am reminded of the issues that came up
                          relating to the 'when' statement

                          when preparing YANG 1.1.=C2=A0 Yes, 'when'=
; makes
                          things possible and is very

                          useful but at the same time, its side effects
                          can be troublesome.=C2=A0 I

                          would like to wrap it up in a conceptual
                          bubble so you could not have

                          the sort of fine-grained access control that
                          allows the case that Rob

                          postulates to occur but have no idea what that
                          might look like.=C2=A0 And I

                          don't know how much 'when' is used in=
 that way
                          in existing YANG

                          modules - uh huh, more reading required.

                        

                        


                        

                        


                        

                        
When the access control is too complicated,
                          it does not get used.

                        
Instead, the most likely access control is
                          "everybody is the root user".

                        
The server pruning of false when/choice
                          data nodes is considered cleanup.

                        

                        
The pruned data is no longer relevant to
                          the data model. This is the indended

                        
use, but when-stmt can easily be abused.

                        


                        

                        
The complex tangled web of dependencies is
                          no worse

                        
than it has been with CLI for 30 years,
                          where every dependency is ad-hoc

                        
and probably undocumented. The granularity
                          of CLI-based access control

                        
is less granular than NACM.

                        


                        

                        
It is possible that vendors and operators
                          are willing to spend hours and days

                        
figuring out how to tune the NACM rules to
                          allow a specific edit to work.

                        
Of course the operator will not even be
                          told by the server which nodes

                        
are blocking the edit. That would be a
                          security risk.

                        


                        

                        
IMO NACM will be completely unusable if
                          rules are needed to allow

                        
server cleanup of dead nodes.=C2=A0 The
                          additional NACM rules required

                        
might provide more access than intended
                          (unless lots of delete-only

                        
rules are added). The huge jump in NACM
                          rule management complexity is

                        
a new security vulnerability, which might
                          even be worse than the

                        
vulnerability it is intended to fix.

                        


                        

                        


                        

                        
 

                          Tom Petch

                          

                          >

                          > Andy

                          >

                          

                          

                          

                        

                        


                        

                        
Andy

                        


                        

                        
=C2=A0

                        
 

                          

                          

                          

                          

                          

                          > > My other thought was that given all
                          the complexities of 'when' that

                          > > emerged during the specification of
                          YANG 1.1, perhaps, were I an

                          > > implementor of this, I would take
                          the easy option and ignore the

                          side

                          > > effects of 'when'; but I might =
feel
                          guilty about doing so.

                          > >

                          > > If the new paragraphs go in as
                          proposed, then I think that the two

                          > > paragraphs you quote need changing
                          else that section looks to me

                          like an

                          > > oxymoron.

                          > >

                          > > Tom Petch

                          > >

                          > > > An <edit-data> request
                          that causes a when constraint to evaluate

                          > > > differently does result in a
                          deletion of those data nodes from the

                          > > > datastore, and hence according
                          to the text above, requires

                          explicit

                          > > > "delete" access permissi=
on to
                          accomplish that.

                          > > >

                          > > > Clearly it would be an interop
                          issue if different servers

                          implemented

                          > > > the NACM path based filtering
                          differently.

                          > > >

                          > > > Hence why I think that it would
                          be prudent for the draft to be

                          more

                          > > > explicit on when and choice
                          statement handling.

                          > > >

                          > > > Rob

                          > > >

                          > > > > There have not been any
                          comments on this issue.

                          > > > >

                          > > > > Andy

                          > > > >

                          > > > >=C2=A0 =C2=A0 =C2=A0Regards, B=
enoit.

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0Hi Ben=
oit,

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0There =
is also one
                          further, unrelated change that I am

                          proposing

                          > > > >>=C2=A0 =C2=A0 =C2=A0is mad=
e the draft
                          before it is published, to help better

                          > > clarify

                          > > > >>=C2=A0 =C2=A0 =C2=A0the ex=
pected
                          behavior. It isn't the end of the world if
                          this

                          > > > >>=C2=A0 =C2=A0 =C2=A0doesn&=
#39;t go in, but
                          I think that it prevents sometime taking

                          a

                          > > > >>=C2=A0 =C2=A0 =C2=A0differ=
ent, but IMO
                          reasonable, interpretation of how "when"=
;

                          > > > >>=C2=A0 =C2=A0 =C2=A0statem=
ents are
                          considered, and then having a future

                          argument

                          > > > >>=C2=A0 =C2=A0 =C2=A0about =
what
                          behavior it specified in the standard.

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0If we =
clarify it
                          now, then it closes that door :-)

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0I'=
ve proposed text
                          to Andy and Martin on Monday, but I've

                          not

                          > > > >>=C2=A0 =C2=A0 =C2=A0heard =
back yet.

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0Netcon=
f email with
                          proposed text attached. The text doesn't

                          > > > >>=C2=A0 =C2=A0 =C2=A0necess=
arily have
                          to match this, but personally I think that

                          it

                          > > is

                          > > > >>=C2=A0 =C2=A0 =C2=A0useful=
 if the
                          draft says something on this.

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0Thanks=
,

                          > > > >>=C2=A0 =C2=A0 =C2=A0Rob
                          > > > >>

                          > > > >>

                          > > > >>=C2=A0 =C2=A0 =C2=A0On 22/=
11/2017
                          13:25, Benoit Claise wrote:

                          > > > >>>=C2=A0 =C2=A0 =C2=A0On=
 11/10/2017
                          7:23 PM, Andy Bierman wrote:

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0Hi,

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0Here are
                          some proposed edits to make the data rule

                          consistent

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0with the
                          examples.

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0Note that
                          this issue is not related to the edit in the

                          > > original

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A01-week
                          change.

                          > > > >>>=C2=A0 =C2=A0 =C2=A0Th=
at's right,
                          but we found a source of misinterpretation

                          in

                          > > the

                          > > > >>>=C2=A0 =C2=A0 =C2=A0dr=
aft and you
                          have rightly corrected it in the github v9.

                          > > > >>>

                          > > > >>>=C2=A0 =C2=A0 =C2=A0Re=
gards,
                          Benoit

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0sec.
                          3.3.5:

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0OLD:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node
                          rule: controls access for a specific data

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0node,
                          identified

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0by its
                          path location within the conceptual XML
                          document

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0for the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node.

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0NEW:

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node
                          rule: controls access for a specific data node
                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0and its
                          descendants,

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0identified
                          by its path location within the conceptual XML
                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0document
                          for the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node.

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0sec 3.4.5,
                          step 6, bullet 2:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0OLD:

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0* The rule
                          does not have a "rule-type" defined or =
the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0"rule-

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0type" is
                          "data-node" and the "path" ma=
tches the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0requested

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node,
                          action node, or notification node.

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0NEW:

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0* The rule
                          does not have a "rule-type" defined or =
the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0"rule-

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0type" is
                          "data-node" and the "path" ma=
tches the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0requested

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node,
                          action node, or notification node. A path is

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0considered
                          to match if the current data node is the

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0data node

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0specified
                          by the path, or is a descendant data node

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0of this
                          data node.

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0appendix
                          B.4: (2 bugs in explanation)

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0OLD:

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0deny-nacm:
                          This rule denies the "guest" group any =
access

                          to

                          > > the

                          > > > >>>>=C2=A0 =C2=A0
                          =C2=A0<nacm> subtree. Note that the default
                          namespace is only

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0applicable
                          because this subtree is defined in the same

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0namespace
                          as the <data-rule> element.

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0NEW:

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0deny-nacm:
                          This rule denies the "guest" group any =
access

                          to

                          > > the

                          > > > >>>>=C2=A0 =C2=A0
                          =C2=A0<nacm> subtree.

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0Andy

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0On Fri,
                          Nov 10, 2017 at 9:24 AM, Robert Wilton

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0<rwilton@cisco=
.com
                          <mailto:rwilton@cisco.com>>
                          wrote:

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>

                          > > > >>>>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0On
                          10/11/2017 16:33, Andy Bierman wrote:

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0On
                          Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton

                          > > > >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0
                          =C2=A0<rwilton@cisco.com
                          <mailto:rwilton@cisco.com>>

                          wrote:

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>

                          > > > >>>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0
                          =C2=A0On 10/11/2017 15:49, Andy Bierman wrote:
                          > > > >>>>>>

                          > > > >>>>>>

                          > > <snip>

                          > >

                          > >

                          >

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  






--089e082f5ce4308f84055ef95c94--


From nobody Mon Nov 27 08:53:55 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44B12895E for ; Mon, 27 Nov 2017 08:53:53 -0800 (PST)
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 Kn35NlbXb1ez for ; Mon, 27 Nov 2017 08:53:49 -0800 (PST)
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 796CE12420B for ; Mon, 27 Nov 2017 08:53:49 -0800 (PST)
Received: from birdie8 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id C12A6639E4 for ; Mon, 27 Nov 2017 17:53:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511801627; bh=E3WtI9kIXikFNUs+MccIQymdWtvgU2ZsA7SoHkCCswQ=; h=From:To:Date; b=VLTocNiMyDUakLuZ5KiGuf9ptGlS9U20ZAmzThglMOAKd3wJeMs18PB96zPAr4wLB twx0Bxv4Mw2iFeyUxXmZo+SR7snGQrmDyaSOKa20rjq6jfesxNGK/DBaGXkjc74xi0 q8omYuXtZ49p9ejXvLTncpuca1NugjRq/hZNYys8=
Message-ID: <1511801627.6244.39.camel@nic.cz>
From: Ladislav Lhotka 
To: netconf@ietf.org
Date: Mon, 27 Nov 2017 17:53:47 +0100
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>     
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 16:53:53 -0000

On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote:
> 
> 
> On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton  wrote:
> > 
> > On 27/11/2017 15:12, Andy Bierman wrote:
> > > 
> > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton  wrote:
> > > > I do get the point that Tom is making here, and have quite a lot of
> > > > sympathy for it.  E.g. by automatically allowing the side effects of
> > > > when/choice statements then we are introducing a potential security hole
> > > > here that operators may find hard to be aware of and mitigate.
> > > > It also seems odd to me that a client is allowed to implicitly remove
> > > > some configuration through the side effect of a when/choice statement
> > > > that they are not allowed to delete explicitly.
> > > > The alternative of requiring appropriate access for the side-effects,
> > > > seems like an intuitively safer design, but I also get Andy's concern
> > > > that security isn't useful if it become so unwieldy that nobody uses it.
> > > > So, I guess the question here is, do we have some concrete examples
> > > > using real data models where the extra NACM delete rules would be
> > > > required?  If not then perhaps requiring the explicit access for side
> > > > effects would be better.
> > > > 
> > > 
> > > 
> > > Yes -- please provide some examples where it is better to force the
> > > operator
> > > to provide extra "delete" rules to allow false-when data nodes to be
> > > deleted.
> >  
> > > It seems to me that these rules would allow individual data structures to
> > > be
> > > removed by the client, that would not otherwise be possible.
> >  Yes, this is true.
> > 
> > But it is still odd that they a client is allowed to delete the
> > configuration, just not explicitly.  I.e. it is strange that they     are
> > not allowed to put in a semantically equivalent request that explicitly
> > deletes the configuration, they are only allowed to do it if the delete is
> > implicit.  This seems inconsistent.
> > 
> > 
> 
> It is just as odd that a request  to create /foo/case1 will work if nothing
> from
> the choice-stmt exists, but will fail if /foo/case2 has to be deleted in order
> to create /foo/case1.

Why is this odd? RFC 7950 says:

   The "choice" statement defines a set of alternatives, only one of
   which may be present in any one data tree.

So it is quite clear that adding /foo/case1 makes the data tree invalid if
/foo/case2 exists.

> 
> 
> > > If 3 data structures need to be in place "when /foo exists" then
> > > deleting 1 or 2 of them directly may not be desirable.  Deleting
> > > them all together (i.e., via when-false deletion) may be the intended
> > > usage.
> >  If there is a dependency that all three exist then that may be better
> > expressed with a must statement instead.
> > 
> > > The vendor and operator need to be aware of the data model dependencies.
> > > That said, how come CLI-based configuration does not have this problem?
> >  My experience of CLI based configurations do have these sorts of problems,
> > and many more :-)
> > 
> > 
> > > (Or rather, why has this problem been ignored for so long? Maybe it not
> > > that real?)
> >  This may be the real crux of the argument:
> > 
> > It probably doesn't make sense to use when statements on disjoint parts of
> > the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> > depend on whether an interface it runs over has an IP address configured). 
> > Instead, a more normal usage would be a flag (e.g. like interface type) to
> > allow/prevent certain child nodes from being available.  In these scenarios,
> > if a user is allowed to change the type of an interface then they are most
> > likely allowed to change the other settings on the interface as well.
> > 
> > So for 'normal' when statements, it probably doesn't make much difference
> > whether or not explicit NACM access is required to the nodes being
> > implicitly deleted because the client probably already has the necessary
> > access rights.
> > 
> > But for the 'corner case' when statement scenario, that are unlikely to be
> > used, it still seems safer to require explicit access permissions than
> > implicitly accepting the side effect with no NACM validation.
> > 
> 
> 
> This is fine, except there is no way to tell a normal when from a corner-case
> when.
> 
> In all cases, the false-when evaluation means the node is not relevant to the
> model anymore.

The client that causes the when expression to become invalid may not be entitled
to decide whether the node is relevant or not.


> Same for a case that is being replaced by a different case.
> In order for this NACM threat to be real. the YANG modeler needs to be wrong
> about
> whether the false-when states are actually irrelevant to the model in its new
> state.

The YANG modeller may be absolutely correct but other modules (out of his
control) may change this.

Lada


> 
> 
> > Thanks,
> > Rob
> > 
> 
> 
> Andy
>  
> > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > 
> > > Andy
> > >  
> > > > On 25/11/2017 15:53, Andy Bierman wrote:
> > > > > 
> > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch  wrote:
> > > > > > ----- Original Message -----
> > > > > > From: "Andy Bierman" 
> > > > > > To: "t.petch" 
> > > > > > 
> > > > > > 
> > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch 
> > > > > > wrote:
> > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > Tom Petch
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Robert Wilton" 
> > > > > > > > Sent: Thursday, November 23, 2017 10:44 AM
> > > > > > > >
> > > > > > > > > Hi Andy,
> > > > > > > > >
> > > > > > > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > > > > > > >
> > > > > > > > > >     Hi Rob,
> > > > > > > > > >
> > > > > > > > > >     At that points in time, if it clarifies the spec. and
> > > > > > the
> > > > > > > > authors
> > > > > > > > > >     agree with this, let's do the right thing.
> > > > > > > > > >
> > > > > > > > > > I will add the new text if that is what the WG wants.
> > > > > > > >
> > > > > > > > > Having read this draft, I was undecided what the intended
> > > > > > behavior
> > > > > > > > > actually should be.
> > > > > > > > >
> > > > > > > > > The way that Yumapro and Tail-f have implemented this is
> > > > > > reasonable,
> > > > > > > > and
> > > > > > > > > is probably also the way that I would implemented it.
> > > > > > > > >
> > > > > > > > > But I also think that it would be a reasonable implementation
> > > > > > for
> > > > > > a
> > > > > > > > > server to calculate the full change set (taking account of
> > > > > > side
> > > > > > > > effects
> > > > > > > > > from when and choice statements) to the datastore before
> > > > > > checking
> > > > > > the
> > > > > > > > > "write data node access control" against the resultant change
> > > > > > set.
> > > > > > > > >
> > > > > > > > > My interpretation is that the RFC text is ambiguous on what
> > > > > > the
> > > > > > > > correct
> > > > > > > > > behavior is, and one could make a reasonable argument that the
> > > > > > current
> > > > > > > > > RFC actually specifies that the alternative behavior is
> > > > > > correct,
> > > > > > i.e.
> > > > > > > > > requiring delete access even if a node is implicitly changes
> > > > > > as a
> > > > > > side
> > > > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > > > > > > >
> > > > > > > > >     If the protocol operation would result in the deletion of
> > > > > > a
> > > > > > > > datastore
> > > > > > > > >     node and the user does not have "delete" access permission
> > > > > > for
> > > > > > > > that
> > > > > > > > >     node, the protocol operation is rejected with an
> > > > > > "access-denied"
> > > > > > > > >     error.
> > > > > > > >
> > > > > > > > Rob
> > > > > > > >
> > > > > > > > I have been reading that paragraph since this thread started and
> > > > > > > > wondering how it could be thought unclear, what am I missing:-)
> > > > > > > >
> > > > > > > > To me it clearly states that the user must have the appropriate
> > > > > > access
> > > > > > > > for the consequences of whatever they do, be that 'when',
> > > > > > 'choice'
> > > > > > or
> > > > > > > > anything else! Indeed, I see exactly that behaviour in
> > > > > > operational
> > > > > > > > (non-network) databases of which I am a user with limited
> > > > > > privileges.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > This is not correct.
> > > > > > > The server is the entity that is cleaning up false when-stmt or
> > > > > > unselected
> > > > > > > cases
> > > > > > > for a choice-stmt.
> > > > > > >
> > > > > > > NACM does not prevent the sever from making any changes to the
> > > > > > system.
> > > > > > > It only affects the operations requested by a client.
> > > > > > 
> > > > > > Andy
> > > > > > 
> > > > > > My model is slightly different, that the server is a black box, with
> > > > > > an
> > > > > > interface through which I can make authorised changes.  If something
> > > > > > I
> > > > > > do causes the deletion of something I am not allowed to delete, may
> > > > > > be
> > > > > > not even to read, well, we part company on the acceptability of
> > > > > > that!
> > > > > > 
> > > > > > I do accept, as Randy points out, that the situation is
> > > > > > complicated.  I
> > > > > > am reminded of the issues that came up relating to the 'when'
> > > > > > statement
> > > > > > when preparing YANG 1.1.  Yes, 'when' makes things possible and is
> > > > > > very
> > > > > > useful but at the same time, its side effects can be troublesome.  I
> > > > > > would like to wrap it up in a conceptual bubble so you could not
> > > > > > have
> > > > > > the sort of fine-grained access control that allows the case that
> > > > > > Rob
> > > > > > postulates to occur but have no idea what that might look like.  And
> > > > > > I
> > > > > > don't know how much 'when' is used in that way in existing YANG
> > > > > > modules - uh huh, more reading required.
> > > > > > 
> > > > > 
> > > > > 
> > > > > When the access control is too complicated, it does not get used.
> > > > > Instead, the most likely access control is "everybody is the root
> > > > > user".
> > > > > The server pruning of false when/choice data nodes is considered
> > > > > cleanup.
> > > > > The pruned data is no longer relevant to the data model. This is the
> > > > > indended
> > > > > use, but when-stmt can easily be abused.
> > > > > 
> > > > > The complex tangled web of dependencies is no worse
> > > > > than it has been with CLI for 30 years, where every dependency is ad-
> > > > > hoc
> > > > > and probably undocumented. The granularity of CLI-based access control
> > > > > is less granular than NACM.
> > > > > 
> > > > > It is possible that vendors and operators are willing to spend hours
> > > > > and days
> > > > > figuring out how to tune the NACM rules to allow a specific edit to
> > > > > work.
> > > > > Of course the operator will not even be told by the server which nodes
> > > > > are blocking the edit. That would be a security risk.
> > > > > 
> > > > > IMO NACM will be completely unusable if rules are needed to allow
> > > > > server cleanup of dead nodes.  The additional NACM rules required
> > > > > might provide more access than intended (unless lots of delete-only
> > > > > rules are added). The huge jump in NACM rule management complexity is
> > > > > a new security vulnerability, which might even be worse than the
> > > > > vulnerability it is intended to fix.
> > > > > 
> > > > > 
> > > > > > Tom Petch
> > > > > > 
> > > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Andy
> > > > > 
> > > > >  
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > My other thought was that given all the complexities of 'when'
> > > > > > that
> > > > > > > > emerged during the specification of YANG 1.1, perhaps, were I an
> > > > > > > > implementor of this, I would take the easy option and ignore the
> > > > > > side
> > > > > > > > effects of 'when'; but I might feel guilty about doing so.
> > > > > > > >
> > > > > > > > If the new paragraphs go in as proposed, then I think that the
> > > > > > two
> > > > > > > > paragraphs you quote need changing else that section looks to me
> > > > > > like an
> > > > > > > > oxymoron.
> > > > > > > >
> > > > > > > > Tom Petch
> > > > > > > >
> > > > > > > > > An  request that causes a when constraint to
> > > > > > evaluate
> > > > > > > > > differently does result in a deletion of those data nodes from
> > > > > > the
> > > > > > > > > datastore, and hence according to the text above, requires
> > > > > > explicit
> > > > > > > > > "delete" access permission to accomplish that.
> > > > > > > > >
> > > > > > > > > Clearly it would be an interop issue if different servers
> > > > > > implemented
> > > > > > > > > the NACM path based filtering differently.
> > > > > > > > >
> > > > > > > > > Hence why I think that it would be prudent for the draft to be
> > > > > > more
> > > > > > > > > explicit on when and choice statement handling.
> > > > > > > > >
> > > > > > > > > Rob
> > > > > > > > >
> > > > > > > > > > There have not been any comments on this issue.
> > > > > > > > > >
> > > > > > > > > > Andy
> > > > > > > > > >
> > > > > > > > > >     Regards, Benoit.
> > > > > > > > > >>
> > > > > > > > > >>     Hi Benoit,
> > > > > > > > > >>
> > > > > > > > > >>     There is also one further, unrelated change that I am
> > > > > > proposing
> > > > > > > > > >>     is made the draft before it is published, to help
> > > > > > better
> > > > > > > > clarify
> > > > > > > > > >>     the expected behavior. It isn't the end of the world if
> > > > > > this
> > > > > > > > > >>     doesn't go in, but I think that it prevents sometime
> > > > > > taking
> > > > > > a
> > > > > > > > > >>     different, but IMO reasonable, interpretation of how
> > > > > > "when"
> > > > > > > > > >>     statements are considered, and then having a future
> > > > > > argument
> > > > > > > > > >>     about what behavior it specified in the standard.
> > > > > > > > > >>
> > > > > > > > > >>     If we clarify it now, then it closes that door :-)
> > > > > > > > > >>
> > > > > > > > > >>     I've proposed text to Andy and Martin on Monday, but
> > > > > > I've
> > > > > > not
> > > > > > > > > >>     heard back yet.
> > > > > > > > > >>
> > > > > > > > > >>     Netconf email with proposed text attached. The text
> > > > > > doesn't
> > > > > > > > > >>     necessarily have to match this, but personally I think
> > > > > > that
> > > > > > it
> > > > > > > > is
> > > > > > > > > >>     useful if the draft says something on this.
> > > > > > > > > >>
> > > > > > > > > >>     Thanks,
> > > > > > > > > >>     Rob
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > > > > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > > > > > > >>>>     Hi,
> > > > > > > > > >>>>
> > > > > > > > > >>>>     Here are some proposed edits to make the data rule
> > > > > > consistent
> > > > > > > > > >>>>     with the examples.
> > > > > > > > > >>>>     Note that this issue is not related to the edit in
> > > > > > the
> > > > > > > > original
> > > > > > > > > >>>>     1-week change.
> > > > > > > > > >>>     That's right, but we found a source of
> > > > > > misinterpretation
> > > > > > in
> > > > > > > > the
> > > > > > > > > >>>     draft and you have rightly corrected it in the github
> > > > > > v9.
> > > > > > > > > >>>
> > > > > > > > > >>>     Regards, Benoit
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     sec. 3.3.5:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     data node rule: controls access for a specific data
> > > > > > > > > >>>>     node, identified
> > > > > > > > > >>>>     by its path location within the conceptual XML
> > > > > > document
> > > > > > > > > >>>>     for the
> > > > > > > > > >>>>     data node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     data node rule: controls access for a specific data
> > > > > > node
> > > > > > > > > >>>>     and its descendants,
> > > > > > > > > >>>>     identified by its path location within the conceptual
> > > > > > XML
> > > > > > > > > >>>>     document for the
> > > > > > > > > >>>>     data node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>
> > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > > > >>>>     "rule-
> > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > >>>>     requested
> > > > > > > > > >>>>     data node, action node, or notification node.
> > > > > > > > > >>>>
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or the
> > > > > > > > > >>>>     "rule-
> > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > >>>>     requested
> > > > > > > > > >>>>     data node, action node, or notification node. A path
> > > > > > is
> > > > > > > > > >>>>     considered to match if the current data node is the
> > > > > > > > > >>>>     data node
> > > > > > > > > >>>>     specified by the path, or is a descendant data node
> > > > > > > > > >>>>     of this data node.
> > > > > > > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > > > > > > >>>>     OLD:
> > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > access
> > > > > > to
> > > > > > > > the
> > > > > > > > > >>>>      subtree. Note that the default namespace is
> > > > > > only
> > > > > > > > > >>>>     applicable because this subtree is defined in the
> > > > > > same
> > > > > > > > > >>>>     namespace as the  element.
> > > > > > > > > >>>>     NEW:
> > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > access
> > > > > > to
> > > > > > > > the
> > > > > > > > > >>>>      subtree.
> > > > > > > > > >>>>     Andy
> > > > > > > > > >>>>
> > > > > > > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > > > > > > >>>>     > wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> > > > > > > > > >>>>>         >
> > > > > > wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > 
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > 
> > > > > > 
> > > >  
> > > > 
> >  
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Nov 27 09:20:38 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B842412895E for ; Mon, 27 Nov 2017 09:20:34 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 oWVC0PR9VStO for ; Mon, 27 Nov 2017 09:20:29 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 251A7128D44 for ; Mon, 27 Nov 2017 09:20:29 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id c188so26142511lfd.5 for ; Mon, 27 Nov 2017 09:20:29 -0800 (PST)
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=kxjYzPwHsnEa8w7z4s+Nw75WPrxljmM7w7BmREC52fs=; b=ATdjtFQthCO+a8dIxoMqiE9ct0sj4MLQZmZJ7ZqrLAcwM9O2eN+3VhFzBDE2SIOOu4 UlYb7z7kWjheZk6pEr25/dorvG9pPrI+YpSCRW7CH/4A4Z3z/DAdS6wvI2wHA3GSo/af yDYU6dGDAkpzPhs9k0OjRZb9mQ37KCgwpm3A/Lva+rkx+tbCvUuXKDVid4OswqxvjyEU /yvLznmORfNg65qLXMbiw757U4qeEsGemUtef3spq+MC6HvAdyBhPeDj4tHYR4QAeCeP G5mvfpMkXcWI0fhjahtukBOh5/TbvSOsxCNaEek5EhTafH1MlkpDEQ8FdKmcF7aaokjM 1P+A==
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=kxjYzPwHsnEa8w7z4s+Nw75WPrxljmM7w7BmREC52fs=; b=fmBEwSQRMm6yFiRio6mAhFimMIWY2X/vJKEOB+bE/WkAk2bXEsDdg8GqOA/+R1y/1Z kyMthHPGYE2KglC1CxtPv1YPJloz5K4XTzHrbOzNZsgvqyOMUvd0YF5kcF7p2y8gN7xr q7eWHKsUmKkZw+ZePM6tnywjCuSKxu13paw/IrRnsWFzU/Z+QrMOZm0GY8vo7EDPCbU8 eqK/2xmuToVVYA1OgW+zpJu1P/vsk3XwWFJKzqwzyr/xVHgSX7uQv5yNimZbMNJuUM/S nvcGrWvMQcpNnUxY+XFoUIx/36xp57Sngcu6YLWN2SOs8Ni+vs0DqkoUEg8ubpJk+oew Gn/A==
X-Gm-Message-State: AJaThX7yqCpI4JMnaauxEJdWzZ+gsbf+ywmbUfAuLTZ4M2d2DirF76Ue eb/BfNbBxB/EaB5/UODZmiL6IoCag9/hymQJEJzkBjbT
X-Google-Smtp-Source: AGs4zMa8Nmc9VqDJMFNBrCGf5pqBn14+wQeJdnP64T1gxKiGQSFNdLOejcKjoLnTqnBfoT6DSmoMsFH8VRrZzLA9PWs=
X-Received: by 10.46.57.10 with SMTP id g10mr3623269lja.77.1511803227206; Mon, 27 Nov 2017 09:20:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 09:20:25 -0800 (PST)
In-Reply-To: <1511801627.6244.39.camel@nic.cz>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>      <1511801627.6244.39.camel@nic.cz>
From: Andy Bierman 
Date: Mon, 27 Nov 2017 09:20:25 -0800
Message-ID: 
To: Ladislav Lhotka 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="089e082f5ce4540509055efa1e76"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 17:20:35 -0000

--089e082f5ce4540509055efa1e76
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka  wrote:

> On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote:
> >
> >
> > On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton 
> wrote:
> > >
> > > On 27/11/2017 15:12, Andy Bierman wrote:
> > > >
> > > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton 
> wrote:
> > > > > I do get the point that Tom is making here, and have quite a lot of
> > > > > sympathy for it.  E.g. by automatically allowing the side effects
> of
> > > > > when/choice statements then we are introducing a potential
> security hole
> > > > > here that operators may find hard to be aware of and mitigate.
> > > > > It also seems odd to me that a client is allowed to implicitly
> remove
> > > > > some configuration through the side effect of a when/choice
> statement
> > > > > that they are not allowed to delete explicitly.
> > > > > The alternative of requiring appropriate access for the
> side-effects,
> > > > > seems like an intuitively safer design, but I also get Andy's
> concern
> > > > > that security isn't useful if it become so unwieldy that nobody
> uses it.
> > > > > So, I guess the question here is, do we have some concrete examples
> > > > > using real data models where the extra NACM delete rules would be
> > > > > required?  If not then perhaps requiring the explicit access for
> side
> > > > > effects would be better.
> > > > >
> > > >
> > > >
> > > > Yes -- please provide some examples where it is better to force the
> > > > operator
> > > > to provide extra "delete" rules to allow false-when data nodes to be
> > > > deleted.
> > >
> > > > It seems to me that these rules would allow individual data
> structures to
> > > > be
> > > > removed by the client, that would not otherwise be possible.
> > >  Yes, this is true.
> > >
> > > But it is still odd that they a client is allowed to delete the
> > > configuration, just not explicitly.  I.e. it is strange that they
>  are
> > > not allowed to put in a semantically equivalent request that explicitly
> > > deletes the configuration, they are only allowed to do it if the
> delete is
> > > implicit.  This seems inconsistent.
> > >
> > >
> >
> > It is just as odd that a request  to create /foo/case1 will work if
> nothing
> > from
> > the choice-stmt exists, but will fail if /foo/case2 has to be deleted in
> order
> > to create /foo/case1.
>
> Why is this odd? RFC 7950 says:
>
>    The "choice" statement defines a set of alternatives, only one of
>    which may be present in any one data tree.
>
> So it is quite clear that adding /foo/case1 makes the data tree invalid if
> /foo/case2 exists.
>
>

>From a NACM POV, the rule to allow "create /foo/case1" works differently
depending on whether server auto-deletion is used.

IMO, NACM controls client access, and auto-deletion is server access,
which is mandated by the specific YANG data-def statements.




> >
> >
> > > > If 3 data structures need to be in place "when /foo exists" then
> > > > deleting 1 or 2 of them directly may not be desirable.  Deleting
> > > > them all together (i.e., via when-false deletion) may be the intended
> > > > usage.
> > >  If there is a dependency that all three exist then that may be better
> > > expressed with a must statement instead.
> > >
> > > > The vendor and operator need to be aware of the data model
> dependencies.
> > > > That said, how come CLI-based configuration does not have this
> problem?
> > >  My experience of CLI based configurations do have these sorts of
> problems,
> > > and many more :-)
> > >
> > >
> > > > (Or rather, why has this problem been ignored for so long? Maybe it
> not
> > > > that real?)
> > >  This may be the real crux of the argument:
> > >
> > > It probably doesn't make sense to use when statements on disjoint
> parts of
> > > the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> > > depend on whether an interface it runs over has an IP address
> configured).
> > > Instead, a more normal usage would be a flag (e.g. like interface
> type) to
> > > allow/prevent certain child nodes from being available.  In these
> scenarios,
> > > if a user is allowed to change the type of an interface then they are
> most
> > > likely allowed to change the other settings on the interface as well.
> > >
> > > So for 'normal' when statements, it probably doesn't make much
> difference
> > > whether or not explicit NACM access is required to the nodes being
> > > implicitly deleted because the client probably already has the
> necessary
> > > access rights.
> > >
> > > But for the 'corner case' when statement scenario, that are unlikely
> to be
> > > used, it still seems safer to require explicit access permissions than
> > > implicitly accepting the side effect with no NACM validation.
> > >
> >
> >
> > This is fine, except there is no way to tell a normal when from a
> corner-case
> > when.
> >
> > In all cases, the false-when evaluation means the node is not relevant
> to the
> > model anymore.
>
> The client that causes the when expression to become invalid may not be
> entitled
> to decide whether the node is relevant or not.
>
>

The YANG designers need to consider the impact of when statements on the
data model usage.
NACM needs to be used at a sufficiently course granularity and it is quite
possible
to setup NACM with inappropriate granularity, where intended access is
blocked
and unintended access is allowed.



>
> > Same for a case that is being replaced by a different case.
> > In order for this NACM threat to be real. the YANG modeler needs to be
> wrong
> > about
> > whether the false-when states are actually irrelevant to the model in
> its new
> > state.
>
> The YANG modeller may be absolutely correct but other modules (out of his
> control) may change this.
>
>

The widespread use of vendor extensions and deviations makes it impossible
to
focus on just the standard modules when considering access control.
Perhaps the best the IETF can do is identify YANG usage patterns that need
to considered
when configuring NACM.

Another option is to create smarter NACM filters, based on tags, not data
nodes.
Data rules are very sharp knifes that need to be used with care.

Lada
>
>
Andy


>
> >
> >
> > > Thanks,
> > > Rob
> > >
> >
> >
> > Andy
> >
> > >
> > > > > Thanks,
> > > > > Rob
> > > > >
> > > >
> > > > Andy
> > > >
> > > > > On 25/11/2017 15:53, Andy Bierman wrote:
> > > > > >
> > > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch 
> wrote:
> > > > > > > ----- Original Message -----
> > > > > > > From: "Andy Bierman" 
> > > > > > > To: "t.petch" 
> > > > > > >
> > > > > > >
> > > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <
> ietfc@btconnect.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > Tom Petch
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Robert Wilton" 
> > > > > > > > > Sent: Thursday, November 23, 2017 10:44 AM
> > > > > > > > >
> > > > > > > > > > Hi Andy,
> > > > > > > > > >
> > > > > > > > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > > > > > > > >
> > > > > > > > > > >     Hi Rob,
> > > > > > > > > > >
> > > > > > > > > > >     At that points in time, if it clarifies the spec.
> and
> > > > > > > the
> > > > > > > > > authors
> > > > > > > > > > >     agree with this, let's do the right thing.
> > > > > > > > > > >
> > > > > > > > > > > I will add the new text if that is what the WG wants.
> > > > > > > > >
> > > > > > > > > > Having read this draft, I was undecided what the intended
> > > > > > > behavior
> > > > > > > > > > actually should be.
> > > > > > > > > >
> > > > > > > > > > The way that Yumapro and Tail-f have implemented this is
> > > > > > > reasonable,
> > > > > > > > > and
> > > > > > > > > > is probably also the way that I would implemented it.
> > > > > > > > > >
> > > > > > > > > > But I also think that it would be a reasonable
> implementation
> > > > > > > for
> > > > > > > a
> > > > > > > > > > server to calculate the full change set (taking account
> of
> > > > > > > side
> > > > > > > > > effects
> > > > > > > > > > from when and choice statements) to the datastore before
> > > > > > > checking
> > > > > > > the
> > > > > > > > > > "write data node access control" against the resultant
> change
> > > > > > > set.
> > > > > > > > > >
> > > > > > > > > > My interpretation is that the RFC text is ambiguous on
> what
> > > > > > > the
> > > > > > > > > correct
> > > > > > > > > > behavior is, and one could make a reasonable argument
> that the
> > > > > > > current
> > > > > > > > > > RFC actually specifies that the alternative behavior is
> > > > > > > correct,
> > > > > > > i.e.
> > > > > > > > > > requiring delete access even if a node is implicitly
> changes
> > > > > > > as a
> > > > > > > side
> > > > > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > > > > > > > >
> > > > > > > > > >     If the protocol operation would result in the
> deletion of
> > > > > > > a
> > > > > > > > > datastore
> > > > > > > > > >     node and the user does not have "delete" access
> permission
> > > > > > > for
> > > > > > > > > that
> > > > > > > > > >     node, the protocol operation is rejected with an
> > > > > > > "access-denied"
> > > > > > > > > >     error.
> > > > > > > > >
> > > > > > > > > Rob
> > > > > > > > >
> > > > > > > > > I have been reading that paragraph since this thread
> started and
> > > > > > > > > wondering how it could be thought unclear, what am I
> missing:-)
> > > > > > > > >
> > > > > > > > > To me it clearly states that the user must have the
> appropriate
> > > > > > > access
> > > > > > > > > for the consequences of whatever they do, be that 'when',
> > > > > > > 'choice'
> > > > > > > or
> > > > > > > > > anything else! Indeed, I see exactly that behaviour in
> > > > > > > operational
> > > > > > > > > (non-network) databases of which I am a user with limited
> > > > > > > privileges.
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is not correct.
> > > > > > > > The server is the entity that is cleaning up false when-stmt
> or
> > > > > > > unselected
> > > > > > > > cases
> > > > > > > > for a choice-stmt.
> > > > > > > >
> > > > > > > > NACM does not prevent the sever from making any changes to
> the
> > > > > > > system.
> > > > > > > > It only affects the operations requested by a client.
> > > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > > My model is slightly different, that the server is a black
> box, with
> > > > > > > an
> > > > > > > interface through which I can make authorised changes.  If
> something
> > > > > > > I
> > > > > > > do causes the deletion of something I am not allowed to
> delete, may
> > > > > > > be
> > > > > > > not even to read, well, we part company on the acceptability of
> > > > > > > that!
> > > > > > >
> > > > > > > I do accept, as Randy points out, that the situation is
> > > > > > > complicated.  I
> > > > > > > am reminded of the issues that came up relating to the 'when'
> > > > > > > statement
> > > > > > > when preparing YANG 1.1.  Yes, 'when' makes things possible
> and is
> > > > > > > very
> > > > > > > useful but at the same time, its side effects can be
> troublesome.  I
> > > > > > > would like to wrap it up in a conceptual bubble so you could
> not
> > > > > > > have
> > > > > > > the sort of fine-grained access control that allows the case
> that
> > > > > > > Rob
> > > > > > > postulates to occur but have no idea what that might look
> like.  And
> > > > > > > I
> > > > > > > don't know how much 'when' is used in that way in existing YANG
> > > > > > > modules - uh huh, more reading required.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > When the access control is too complicated, it does not get used.
> > > > > > Instead, the most likely access control is "everybody is the root
> > > > > > user".
> > > > > > The server pruning of false when/choice data nodes is considered
> > > > > > cleanup.
> > > > > > The pruned data is no longer relevant to the data model. This is
> the
> > > > > > indended
> > > > > > use, but when-stmt can easily be abused.
> > > > > >
> > > > > > The complex tangled web of dependencies is no worse
> > > > > > than it has been with CLI for 30 years, where every dependency
> is ad-
> > > > > > hoc
> > > > > > and probably undocumented. The granularity of CLI-based access
> control
> > > > > > is less granular than NACM.
> > > > > >
> > > > > > It is possible that vendors and operators are willing to spend
> hours
> > > > > > and days
> > > > > > figuring out how to tune the NACM rules to allow a specific edit
> to
> > > > > > work.
> > > > > > Of course the operator will not even be told by the server which
> nodes
> > > > > > are blocking the edit. That would be a security risk.
> > > > > >
> > > > > > IMO NACM will be completely unusable if rules are needed to allow
> > > > > > server cleanup of dead nodes.  The additional NACM rules required
> > > > > > might provide more access than intended (unless lots of
> delete-only
> > > > > > rules are added). The huge jump in NACM rule management
> complexity is
> > > > > > a new security vulnerability, which might even be worse than the
> > > > > > vulnerability it is intended to fix.
> > > > > >
> > > > > >
> > > > > > > Tom Petch
> > > > > > >
> > > > > > > >
> > > > > > > > Andy
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > My other thought was that given all the complexities of
> 'when'
> > > > > > > that
> > > > > > > > > emerged during the specification of YANG 1.1, perhaps,
> were I an
> > > > > > > > > implementor of this, I would take the easy option and
> ignore the
> > > > > > > side
> > > > > > > > > effects of 'when'; but I might feel guilty about doing so.
> > > > > > > > >
> > > > > > > > > If the new paragraphs go in as proposed, then I think that
> the
> > > > > > > two
> > > > > > > > > paragraphs you quote need changing else that section looks
> to me
> > > > > > > like an
> > > > > > > > > oxymoron.
> > > > > > > > >
> > > > > > > > > Tom Petch
> > > > > > > > >
> > > > > > > > > > An  request that causes a when constraint to
> > > > > > > evaluate
> > > > > > > > > > differently does result in a deletion of those data
> nodes from
> > > > > > > the
> > > > > > > > > > datastore, and hence according to the text above,
> requires
> > > > > > > explicit
> > > > > > > > > > "delete" access permission to accomplish that.
> > > > > > > > > >
> > > > > > > > > > Clearly it would be an interop issue if different servers
> > > > > > > implemented
> > > > > > > > > > the NACM path based filtering differently.
> > > > > > > > > >
> > > > > > > > > > Hence why I think that it would be prudent for the draft
> to be
> > > > > > > more
> > > > > > > > > > explicit on when and choice statement handling.
> > > > > > > > > >
> > > > > > > > > > Rob
> > > > > > > > > >
> > > > > > > > > > > There have not been any comments on this issue.
> > > > > > > > > > >
> > > > > > > > > > > Andy
> > > > > > > > > > >
> > > > > > > > > > >     Regards, Benoit.
> > > > > > > > > > >>
> > > > > > > > > > >>     Hi Benoit,
> > > > > > > > > > >>
> > > > > > > > > > >>     There is also one further, unrelated change that
> I am
> > > > > > > proposing
> > > > > > > > > > >>     is made the draft before it is published, to help
> > > > > > > better
> > > > > > > > > clarify
> > > > > > > > > > >>     the expected behavior. It isn't the end of the
> world if
> > > > > > > this
> > > > > > > > > > >>     doesn't go in, but I think that it prevents
> sometime
> > > > > > > taking
> > > > > > > a
> > > > > > > > > > >>     different, but IMO reasonable, interpretation of
> how
> > > > > > > "when"
> > > > > > > > > > >>     statements are considered, and then having a
> future
> > > > > > > argument
> > > > > > > > > > >>     about what behavior it specified in the standard.
> > > > > > > > > > >>
> > > > > > > > > > >>     If we clarify it now, then it closes that door :-)
> > > > > > > > > > >>
> > > > > > > > > > >>     I've proposed text to Andy and Martin on Monday,
> but
> > > > > > > I've
> > > > > > > not
> > > > > > > > > > >>     heard back yet.
> > > > > > > > > > >>
> > > > > > > > > > >>     Netconf email with proposed text attached. The
> text
> > > > > > > doesn't
> > > > > > > > > > >>     necessarily have to match this, but personally I
> think
> > > > > > > that
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > >>     useful if the draft says something on this.
> > > > > > > > > > >>
> > > > > > > > > > >>     Thanks,
> > > > > > > > > > >>     Rob
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > > > > > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > > > > > > > >>>>     Hi,
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     Here are some proposed edits to make the data
> rule
> > > > > > > consistent
> > > > > > > > > > >>>>     with the examples.
> > > > > > > > > > >>>>     Note that this issue is not related to the edit
> in
> > > > > > > the
> > > > > > > > > original
> > > > > > > > > > >>>>     1-week change.
> > > > > > > > > > >>>     That's right, but we found a source of
> > > > > > > misinterpretation
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > >>>     draft and you have rightly corrected it in the
> github
> > > > > > > v9.
> > > > > > > > > > >>>
> > > > > > > > > > >>>     Regards, Benoit
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     sec. 3.3.5:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     OLD:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     data node rule: controls access for a specific
> data
> > > > > > > > > > >>>>     node, identified
> > > > > > > > > > >>>>     by its path location within the conceptual XML
> > > > > > > document
> > > > > > > > > > >>>>     for the
> > > > > > > > > > >>>>     data node.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     NEW:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     data node rule: controls access for a specific
> data
> > > > > > > node
> > > > > > > > > > >>>>     and its descendants,
> > > > > > > > > > >>>>     identified by its path location within the
> conceptual
> > > > > > > XML
> > > > > > > > > > >>>>     document for the
> > > > > > > > > > >>>>     data node.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     OLD:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined
> or the
> > > > > > > > > > >>>>     "rule-
> > > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > > >>>>     requested
> > > > > > > > > > >>>>     data node, action node, or notification node.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     NEW:
> > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined
> or the
> > > > > > > > > > >>>>     "rule-
> > > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > > >>>>     requested
> > > > > > > > > > >>>>     data node, action node, or notification node. A
> path
> > > > > > > is
> > > > > > > > > > >>>>     considered to match if the current data node is
> the
> > > > > > > > > > >>>>     data node
> > > > > > > > > > >>>>     specified by the path, or is a descendant data
> node
> > > > > > > > > > >>>>     of this data node.
> > > > > > > > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > > > > > > > >>>>     OLD:
> > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group
> any
> > > > > > > access
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > >>>>      subtree. Note that the default namespace
> is
> > > > > > > only
> > > > > > > > > > >>>>     applicable because this subtree is defined in
> the
> > > > > > > same
> > > > > > > > > > >>>>     namespace as the  element.
> > > > > > > > > > >>>>     NEW:
> > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group
> any
> > > > > > > access
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > >>>>      subtree.
> > > > > > > > > > >>>>     Andy
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > > > > > > > >>>>     >
> wrote:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert
> Wilton
> > > > > > > > > > >>>>>          rwilton@cisco.com>>
> > > > > > > wrote:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>             On 10/11/2017 15:49, Andy Bierman
> wrote:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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




On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
On Mon, 20=
17-11-27 at 08:26 -0800, Andy Bierman wrote:

>

>

> On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <rwilton@cisco.com> wrote:

> >

> > On 27/11/2017 15:12, Andy Bierman wrote:

> > >

> > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <rwilton@cisco.com> wrote:

> > > > I do get the point that Tom is making here, and have qu=
ite a lot of

> > > > sympathy for it.=C2=A0 E.g. by automatically allowing t=
he side effects of

> > > > when/choice statements then we are introducing a potent=
ial security hole

> > > > here that operators may find hard to be aware of and mi=
tigate.

> > > > It also seems odd to me that a client is allowed to imp=
licitly remove

> > > > some configuration through the side effect of a when/ch=
oice statement

> > > > that they are not allowed to delete explicitly.

> > > > The alternative of requiring appropriate access for the=
 side-effects,

> > > > seems like an intuitively safer design, but I also get =
Andy's concern

> > > > that security isn't useful if it become so unwieldy=
 that nobody uses it.

> > > > So, I guess the question here is, do we have some concr=
ete examples

> > > > using real data models where the extra NACM delete rule=
s would be

> > > > required?=C2=A0 If not then perhaps requiring the expli=
cit access for side

> > > > effects would be better.

> > > >

> > >

> > >

> > > Yes -- please provide some examples where it is better to fo=
rce the

> > > operator

> > > to provide extra "delete" rules to allow false-whe=
n data nodes to be

> > > deleted.

> >

> > > It seems to me that these rules would allow individual data =
structures to

> > > be

> > > removed by the client, that would not otherwise be possible.=


> >=C2=A0 Yes, this is true.

> >

> > But it is still odd that they a client is allowed to delete the
> > configuration, just not explicitly.=C2=A0 I.e. it is strange that=
 they=C2=A0 =C2=A0 =C2=A0are

> > not allowed to put in a semantically equivalent request that expl=
icitly

> > deletes the configuration, they are only allowed to do it if the =
delete is

> > implicit.=C2=A0 This seems inconsistent.

> >

> >

>

> It is just as odd that a request=C2=A0 to create /foo/case1 will work =
if nothing

> from

> the choice-stmt exists, but will fail if /foo/case2 has to be deleted =
in order

> to create /foo/case1.



Why is this odd? RFC 7950 says:



=C2=A0 =C2=A0The "choice" statement defines a set of alternatives=
, only one of

=C2=A0 =C2=A0which may be present in any one data tree.



So it is quite clear that adding /foo/case1 makes the data tree invalid if<=
br>
/foo/case2 exists.




From a NACM POV, the ru=
le to allow "create /foo/case1" works differently
depen=
ding on whether server auto-deletion is used.

IMO,=
 NACM controls client access, and auto-deletion is server access,
which is mandated by the specific YANG data-def statements.

=


=C2=A0

>

>

> > > If 3 data structures need to be in place "when /foo exi=
sts" then

> > > deleting 1 or 2 of them directly may not be desirable.=C2=A0=
 Deleting

> > > them all together (i.e., via when-false deletion) may be the=
 intended

> > > usage.

> >=C2=A0 If there is a dependency that all three exist then that may=
 be better

> > expressed with a must statement instead.

> >

> > > The vendor and operator need to be aware of the data model d=
ependencies.

> > > That said, how come CLI-based configuration does not have th=
is problem?

> >=C2=A0 My experience of CLI based configurations do have these sor=
ts of problems,

> > and many more :-)

> >

> >

> > > (Or rather, why has this problem been ignored for so long? M=
aybe it not

> > > that real?)

> >=C2=A0 This may be the real crux of the argument:

> >

> > It probably doesn't make sense to use when statements on disj=
oint parts of

> > the YANG schema (e.g. it does not make sense for the OSPF YANG mo=
del to

> > depend on whether an interface it runs over has an IP address con=
figured).

> > Instead, a more normal usage would be a flag (e.g. like interface=
 type) to

> > allow/prevent certain child nodes from being available.=C2=A0 In =
these scenarios,

> > if a user is allowed to change the type of an interface then they=
 are most

> > likely allowed to change the other settings on the interface as w=
ell.

> >

> > So for 'normal' when statements, it probably doesn't =
make much difference

> > whether or not explicit NACM access is required to the nodes bein=
g

> > implicitly deleted because the client probably already has the ne=
cessary

> > access rights.

> >

> > But for the 'corner case' when statement scenario, that a=
re unlikely to be

> > used, it still seems safer to require explicit access permissions=
 than

> > implicitly accepting the side effect with no NACM validation.

> >

>

>

> This is fine, except there is no way to tell a normal when from a corn=
er-case

> when.

>

> In all cases, the false-when evaluation means the node is not relevant=
 to the

> model anymore.



The client that causes the when expression to become invalid may not be ent=
itled

to decide whether the node is relevant or not.




The YANG designers need=
 to consider the impact of when statements on the data model usage.
NACM needs to be used at a sufficiently course granularity and it is qui=
te possible
to setup NACM with inappropriate granularity, where i=
ntended access is blocked
and unintended access is allowed.
=


=C2=A0



> Same for a case that is being replaced by a different case.

> In order for this NACM threat to be real. the YANG modeler needs to be=
 wrong

> about

> whether the false-when states are actually irrelevant to the model in =
its new

> state.



The YANG modeller may be absolutely correct but other modules (out of his
control) may change this.




The widespread use of vendor extensions and deviations makes it imp=
ossible to
focus on just the standard modules when considering ac=
cess control.
Perhaps the best the IETF can do is identify YANG u=
sage patterns that need to considered
when configuring NACM.
<=
/div>

Another option is to create smarter NACM filters, =
based on tags, not data nodes.
Data rules are very sharp knifes t=
hat need to be used with care.


Lada



Andy
=C2=A0



>

>

> > Thanks,

> > Rob

> >

>

>

> Andy

>

> >

> > > > Thanks,

> > > > Rob

> > > >

> > >

> > > Andy

> > >

> > > > On 25/11/2017 15:53, Andy Bierman wrote:

> > > > >

> > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch <ietfc@btconnect.com> wrote:

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

> > > > > > From: "Andy Bierman" <andy@yumaworks.com>

> > > > > > To: "t.petch" <ietfc@btconnect.com>

> > > > > >

> > > > > >

> > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch=
 <ietfc@btconnect.com>

> > > > > > wrote:

> > > > > > >

> > > > > > > > <inline>

> > > > > > > >

> > > > > > > > Tom Petch

> > > > > > > >

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

> > > > > > > > From: "Robert Wilton" <=
;rwilton@cisco.com>

> > > > > > > > Sent: Thursday, November 23, 2017 1=
0:44 AM

> > > > > > > >

> > > > > > > > > Hi Andy,

> > > > > > > > >

> > > > > > > > > On 22/11/2017 18:09, Andy Bier=
man wrote:

> > > > > > > > > > On Wed, Nov 22, 2017 at 5=
:41 AM, Benoit Claise wrote:

> > > > > > > > > >

> > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Hi Rob=
,

> > > > > > > > > >

> > > > > > > > > >=C2=A0 =C2=A0 =C2=A0At tha=
t points in time, if it clarifies the spec. and

> > > > > > the

> > > > > > > > authors

> > > > > > > > > >=C2=A0 =C2=A0 =C2=A0agree =
with this, let's do the right thing.

> > > > > > > > > >

> > > > > > > > > > I will add the new text i=
f that is what the WG wants.

> > > > > > > >

> > > > > > > > > Having read this draft, I was =
undecided what the intended

> > > > > > behavior

> > > > > > > > > actually should be.

> > > > > > > > >

> > > > > > > > > The way that Yumapro and Tail-=
f have implemented this is

> > > > > > reasonable,

> > > > > > > > and

> > > > > > > > > is probably also the way that =
I would implemented it.

> > > > > > > > >

> > > > > > > > > But I also think that it would=
 be a reasonable implementation

> > > > > > for

> > > > > > a

> > > > > > > > > server to calculate the full c=
hange set (taking account of

> > > > > > side

> > > > > > > > effects

> > > > > > > > > from when and choice statement=
s) to the datastore before

> > > > > > checking

> > > > > > the

> > > > > > > > > "write data node access c=
ontrol" against the resultant change

> > > > > > set.

> > > > > > > > >

> > > > > > > > > My interpretation is that the =
RFC text is ambiguous on what

> > > > > > the

> > > > > > > > correct

> > > > > > > > > behavior is, and one could mak=
e a reasonable argument that the

> > > > > > current

> > > > > > > > > RFC actually specifies that th=
e alternative behavior is

> > > > > > correct,

> > > > > > i.e.

> > > > > > > > > requiring delete access even i=
f a node is implicitly changes

> > > > > > as a

> > > > > > side

> > > > > > > > > effect. E.g. section 3.2.3 of =
RFC 6536 states:

> > > > > > > > >

> > > > > > > > >=C2=A0 =C2=A0 =C2=A0If the prot=
ocol operation would result in the deletion of

> > > > > > a

> > > > > > > > datastore

> > > > > > > > >=C2=A0 =C2=A0 =C2=A0node and th=
e user does not have "delete" access permission

> > > > > > for

> > > > > > > > that

> > > > > > > > >=C2=A0 =C2=A0 =C2=A0node, the p=
rotocol operation is rejected with an

> > > > > > "access-denied"

> > > > > > > > >=C2=A0 =C2=A0 =C2=A0error.

> > > > > > > >

> > > > > > > > Rob

> > > > > > > >

> > > > > > > > I have been reading that paragraph =
since this thread started and

> > > > > > > > wondering how it could be thought u=
nclear, what am I missing:-)

> > > > > > > >

> > > > > > > > To me it clearly states that the us=
er must have the appropriate

> > > > > > access

> > > > > > > > for the consequences of whatever th=
ey do, be that 'when',

> > > > > > 'choice'

> > > > > > or

> > > > > > > > anything else! Indeed, I see exactl=
y that behaviour in

> > > > > > operational

> > > > > > > > (non-network) databases of which I =
am a user with limited

> > > > > > privileges.

> > > > > > > >

> > > > > > > >

> > > > > > >

> > > > > > > This is not correct.

> > > > > > > The server is the entity that is cleanin=
g up false when-stmt or

> > > > > > unselected

> > > > > > > cases

> > > > > > > for a choice-stmt.

> > > > > > >

> > > > > > > NACM does not prevent the sever from mak=
ing any changes to the

> > > > > > system.

> > > > > > > It only affects the operations requested=
 by a client.

> > > > > >

> > > > > > Andy

> > > > > >

> > > > > > My model is slightly different, that the serv=
er is a black box, with

> > > > > > an

> > > > > > interface through which I can make authorised=
 changes.=C2=A0 If something

> > > > > > I

> > > > > > do causes the deletion of something I am not =
allowed to delete, may

> > > > > > be

> > > > > > not even to read, well, we part company on th=
e acceptability of

> > > > > > that!

> > > > > >

> > > > > > I do accept, as Randy points out, that the si=
tuation is

> > > > > > complicated.=C2=A0 I

> > > > > > am reminded of the issues that came up relati=
ng to the 'when'

> > > > > > statement

> > > > > > when preparing YANG 1.1.=C2=A0 Yes, 'when=
' makes things possible and is

> > > > > > very

> > > > > > useful but at the same time, its side effects=
 can be troublesome.=C2=A0 I

> > > > > > would like to wrap it up in a conceptual bubb=
le so you could not

> > > > > > have

> > > > > > the sort of fine-grained access control that =
allows the case that

> > > > > > Rob

> > > > > > postulates to occur but have no idea what tha=
t might look like.=C2=A0 And

> > > > > > I

> > > > > > don't know how much 'when' is use=
d in that way in existing YANG

> > > > > > modules - uh huh, more reading required.

> > > > > >

> > > > >

> > > > >

> > > > > When the access control is too complicated, it doe=
s not get used.

> > > > > Instead, the most likely access control is "e=
verybody is the root

> > > > > user".

> > > > > The server pruning of false when/choice data nodes=
 is considered

> > > > > cleanup.

> > > > > The pruned data is no longer relevant to the data =
model. This is the

> > > > > indended

> > > > > use, but when-stmt can easily be abused.

> > > > >

> > > > > The complex tangled web of dependencies is no wors=
e

> > > > > than it has been with CLI for 30 years, where ever=
y dependency is ad-

> > > > > hoc

> > > > > and probably undocumented. The granularity of CLI-=
based access control

> > > > > is less granular than NACM.

> > > > >

> > > > > It is possible that vendors and operators are will=
ing to spend hours

> > > > > and days

> > > > > figuring out how to tune the NACM rules to allow a=
 specific edit to

> > > > > work.

> > > > > Of course the operator will not even be told by th=
e server which nodes

> > > > > are blocking the edit. That would be a security ri=
sk.

> > > > >

> > > > > IMO NACM will be completely unusable if rules are =
needed to allow

> > > > > server cleanup of dead nodes.=C2=A0 The additional=
 NACM rules required

> > > > > might provide more access than intended (unless lo=
ts of delete-only

> > > > > rules are added). The huge jump in NACM rule manag=
ement complexity is

> > > > > a new security vulnerability, which might even be =
worse than the

> > > > > vulnerability it is intended to fix.

> > > > >

> > > > >

> > > > > > Tom Petch

> > > > > >

> > > > > > >

> > > > > > > Andy

> > > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > >

> > > > > Andy

> > > > >

> > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > > >

> > > > > > > > My other thought was that given all=
 the complexities of 'when'

> > > > > > that

> > > > > > > > emerged during the specification of=
 YANG 1.1, perhaps, were I an

> > > > > > > > implementor of this, I would take t=
he easy option and ignore the

> > > > > > side

> > > > > > > > effects of 'when'; but I mi=
ght feel guilty about doing so.

> > > > > > > >

> > > > > > > > If the new paragraphs go in as prop=
osed, then I think that the

> > > > > > two

> > > > > > > > paragraphs you quote need changing =
else that section looks to me

> > > > > > like an

> > > > > > > > oxymoron.

> > > > > > > >

> > > > > > > > Tom Petch

> > > > > > > >

> > > > > > > > > An <edit-data> request t=
hat causes a when constraint to

> > > > > > evaluate

> > > > > > > > > differently does result in a d=
eletion of those data nodes from

> > > > > > the

> > > > > > > > > datastore, and hence according=
 to the text above, requires

> > > > > > explicit

> > > > > > > > > "delete" access perm=
ission to accomplish that.

> > > > > > > > >

> > > > > > > > > Clearly it would be an interop=
 issue if different servers

> > > > > > implemented

> > > > > > > > > the NACM path based filtering =
differently.

> > > > > > > > >

> > > > > > > > > Hence why I think that it woul=
d be prudent for the draft to be

> > > > > > more

> > > > > > > > > explicit on when and choice st=
atement handling.

> > > > > > > > >

> > > > > > > > > Rob

> > > > > > > > >

> > > > > > > > > > There have not been any c=
omments on this issue.

> > > > > > > > > >

> > > > > > > > > > Andy

> > > > > > > > > >

> > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Regard=
s, Benoit.

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0Hi=
 Benoit,

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0Th=
ere is also one further, unrelated change that I am

> > > > > > proposing

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0is=
 made the draft before it is published, to help

> > > > > > better

> > > > > > > > clarify

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0th=
e expected behavior. It isn't the end of the world if

> > > > > > this

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0do=
esn't go in, but I think that it prevents sometime

> > > > > > taking

> > > > > > a

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0di=
fferent, but IMO reasonable, interpretation of how

> > > > > > "when"

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0st=
atements are considered, and then having a future

> > > > > > argument

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0ab=
out what behavior it specified in the standard.

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0If=
 we clarify it now, then it closes that door :-)

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0I&=
#39;ve proposed text to Andy and Martin on Monday, but

> > > > > > I've

> > > > > > not

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0he=
ard back yet.

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0Ne=
tconf email with proposed text attached. The text

> > > > > > doesn't

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0ne=
cessarily have to match this, but personally I think

> > > > > > that

> > > > > > it

> > > > > > > > is

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0us=
eful if the draft says something on this.

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0Th=
anks,

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0Ro=
b

> > > > > > > > > >>

> > > > > > > > > >>

> > > > > > > > > >>=C2=A0 =C2=A0 =C2=A0On=
 22/11/2017 13:25, Benoit Claise wrote:

> > > > > > > > > >>>=C2=A0 =C2=A0 =C2=
=A0On 11/10/2017 7:23 PM, Andy Bierman wrote:

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0Hi,

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0Here are some proposed edits to make the data rule

> > > > > > consistent

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0with the examples.

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0Note that this issue is not related to the edit in

> > > > > > the

> > > > > > > > original

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A01-week change.

> > > > > > > > > >>>=C2=A0 =C2=A0 =C2=
=A0That's right, but we found a source of

> > > > > > misinterpretation

> > > > > > in

> > > > > > > > the

> > > > > > > > > >>>=C2=A0 =C2=A0 =C2=
=A0draft and you have rightly corrected it in the github

> > > > > > v9.

> > > > > > > > > >>>

> > > > > > > > > >>>=C2=A0 =C2=A0 =C2=
=A0Regards, Benoit

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0sec. 3.3.5:

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0OLD:

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node rule: controls access for a specific data

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0node, identified

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0by its path location within the conceptual XML

> > > > > > document

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0for the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node.

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0NEW:

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node rule: controls access for a specific data

> > > > > > node

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0and its descendants,

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0identified by its path location within the conceptual

> > > > > > XML

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0document for the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node.

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0sec 3.4.5, step 6, bullet 2:

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0OLD:

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0* The rule does not have a "rule-type" defined or the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0"rule-

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0type" is "data-node" and the "path" matches =
the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0requested

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node, action node, or notification node.

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0NEW:

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0* The rule does not have a "rule-type" defined or the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0"rule-

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0type" is "data-node" and the "path" matches =
the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0requested

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node, action node, or notification node. A path

> > > > > > is

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0considered to match if the current data node is the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0data node

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0specified by the path, or is a descendant data node

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0of this data node.

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0appendix B.4: (2 bugs in explanation)

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0OLD:

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0deny-nacm: This rule denies the "guest" group any

> > > > > > access

> > > > > > to

> > > > > > > > the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0<nacm> subtree. Note that the default namespace is

> > > > > > only

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0applicable because this subtree is defined in the

> > > > > > same

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0namespace as the <data-rule> element.

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0NEW:

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0deny-nacm: This rule denies the "guest" group any

> > > > > > access

> > > > > > to

> > > > > > > > the

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0<nacm> subtree.

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0Andy

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0<rwilton@cisco.com <ma=
ilto:rwilton@cisco.com>> wro=
te:

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>

> > > > > > > > > >>>>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0On 10/11/2017 16:33, Andy Bierman wrote:

> > > > > > > > > >>>>>

> > > > > > > > > >>>>>

> > > > > > > > > >>>>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton

> > > > > > > > > >>>>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<rwilton@ci=
sco.com <mailto:rwilton@cisco.c=
om>>

> > > > > > wrote:

> > > > > > > > > >>>>>

> > > > > > > > > >>>>>

> > > > > > > > > >>>>>

> > > > > > > > > >>>>>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 10/11/2017 15:49, Andy Bierman wro=
te:

> > > > > > > > > >>>>>>

> > > > > > > > > >>>>>>

> > > > > > > > <snip>

> > > > > > > >

> > > > > > > >

> > > > > > >

> > > > > >

> > > > > >

> > > >

> > > >

> >

>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf=


--

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--089e082f5ce4540509055efa1e76--


From nobody Mon Nov 27 15:27:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C58124D6C for ; Mon, 27 Nov 2017 15:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HkXzVxQFqv5N for ; Mon, 27 Nov 2017 15:27:17 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 823A3124207 for ; Mon, 27 Nov 2017 15:27:17 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id r12so19403500pgu.10 for ; Mon, 27 Nov 2017 15:27:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:message-id:date:to:mime-version; bh=iQ+Bwiyr4Gvqq6jlg0LTJxqEhUgrv0z+y2InO36Q5cA=; b=OqNkBYQXQDyig0JnyABnUwzePo/G9YGIavLD00kS3oHWGTLz3bHhg3zz8KsL08cWnf 5JpZ4uMg71sPE9l0fXQYkG2EMbsbhuKdqZfa/U2GZSby9FH7GuWEzOqPCZWH+mBmxg0F 42Gs+Cmj2JKlwpht2zfx7Erdz7ELKZCUDzihVO0k/bOPUVi/+g0QzRzaroD93i5+Q0FJ gotETuEvVJoEeCkmSjTxFErP3Pn4VVVtaQF8wAQDh5KEDg4BHvzkhAdk9NVjuRsaBZGT DIS+J50QVLTVgi0iiV+/9jkKY0qTyvBhuCEbAO0jF6AWxLeST3b6tvgUsth33ojMILe8 R/KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=iQ+Bwiyr4Gvqq6jlg0LTJxqEhUgrv0z+y2InO36Q5cA=; b=ghjwBYHmrkywOyGKza19ZS2iBs07lJ7k94V2ZCLlVyzSomYzj3zO4DvN54iKXNPdcx rCdkkvL3vGPCdvozwiPb0HrDeM5RL7Logq6Cm4jBYHB5vQwjVudHzDwZgQjNAQ1psZZJ tCzELIA5cPxCPIgankuHp7iIAaQvag0DQp1GmZFc3PtWrzlG3LdFdUb6RFRnEFk314zo EglHpR2bdXmfnYAAr+JqouSmPoHB4oCeCQJtbkg9vGUgNIKfuTYvmLG1GRnEp7HhhFpI FMjOs/gmspnRuFPYG1JHACzxz+but9uQc5dXpG/rUQ2rNnTZaR94nxAUnNT/XSl5hJ/0 Vwjw==
X-Gm-Message-State: AJaThX6iIUFX+apMlsFEfKSSItAC7311CAxmYByGETecNVMfs5cy1RIh 0qaEFW4vQXU4LhbSuIIpixMsmkP+
X-Google-Smtp-Source: AGs4zMZwQ1JnWTjBp5Fa8NuL14TE1E+jEQUn1DRO0O2b3OjddiLKY3mgjvKt8ZRwhZWd7EbqPGVk5A==
X-Received: by 10.101.73.203 with SMTP id t11mr38636559pgs.446.1511825236623;  Mon, 27 Nov 2017 15:27:16 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:c9c7:4c2b:674a:1f86]) by smtp.gmail.com with ESMTPSA id s66sm56975710pfd.74.2017.11.27.15.27.13 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Nov 2017 15:27:16 -0800 (PST)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_447435D7-DE1D-42EC-ADA3-802C6C84CAE1"
Message-Id: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
Date: Mon, 27 Nov 2017 15:27:06 -0800
To: netconf 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 23:27:19 -0000

--Apple-Mail=_447435D7-DE1D-42EC-ADA3-802C6C84CAE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear NETCONF WG,
=20
Below is the NETCONF WG session summary and AIs that were taken from the =
IETF 100 meeting.
=20
This e-mail verifies the discussion that took place in the room. Barring =
any strong objection, the AIs identified in this summary will be acted =
upon.
=20
The NETCONF session took place on Thursday, November 16, 2017, between =
15:50-17:50 Singapore Time.
=20
The final notes from the meeting (once posted) will be available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/ =

=20
rfc6536bis received comments in IESG review. Some last minute updates =
are being provided to address those comments, and once approved will =
allow the document to go towards publication. AI for authors to post =
updated draft before Benoit submits it for publication.
NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to support =
features like licensing, and semantic versioning. It also needs to =
address some bugs. Authors believe the document should be ready for WGLC =
by end of this year. AI for authors to provide updated draft before the =
three set of drafts are submitted for LC.
Zerotouch draft went through LC. It received comments during that =
period, which the author will address. Author believes that once the =
document is ready, it can be forwarded for publication, currently =
planned for December. AI for author to provide updated draft.
Keystore draft needs to be updated for issues raised in WGLC and =
discussion on the mailing list. AI for author(s) to provide updated =
drafts before LC can be re-initiated.
SSH/TLS NETCONF/RESTCONF Client Server Models also needs updates based =
on changes in the Keystore draft.  AI for author(s) to provide updated =
drafts before LC will be re-initated.=20
YANG Push, Subscribed notifications and NETCONF notification drafts need =
updates based on discussion in the meeting and on the list. There are =
still outstanding questions on whether NETCONF notifications draft is =
needed or its contents can be folded into subscribed-notifications =
draft.  All these issues need to be discussed and resolved on the =
mailing list. Co-chairs will initiate WGLC once the issues are resolved. =
AI for authors to close on open issues and post updated draft.=20
Notification Message Headers and Bundles and Restconf notifications - =
These two drafts will be considered for WGLC later. No AI.
UDP Pub Channel draft needs more discussion on the mailing list. A =
milestone will be added to the NETCONF WG milestones. No other AI =
planned at this time.
Cheers

Mahesh (and Kent)


--Apple-Mail=_447435D7-DE1D-42EC-ADA3-802C6C84CAE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Dear NETCONF =
WG,
 
Below =
is the NETCONF WG session summary and AIs that were taken from the IETF =
100 meeting.
 
This =
e-mail verifies the discussion that took place in the room. Barring any =
strong objection, the AIs identified in this summary will be acted =
upon.
 
The =
NETCONF session took place on Thursday, November 16, 2017, between =
15:50-17:50 Singapore Time.
 
The =
final notes from the meeting (once posted) will be =
available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/=

 


    

  • rfc6536bis =
received comments in IESG review. Some last minute updates are being =
provided to address those comments, and once approved will allow the =
document to go towards publication. AI for authors to post updated draft =
before Benoit submits it for publication.
    • 

  • NMDA drafts =
(YANG Library, NETCONF and RESTCONF) need updates to support features =
like licensing, and semantic versioning. It also needs to address some =
bugs. Authors believe the document should be ready for WGLC by end of =
this year. AI for authors to provide updated draft before the three set =
of drafts are submitted for LC.
    • 

  • Zerotouch draft went through LC. =
It received comments during that period, which the author will address. =
Author believes that once the document is ready, it can be forwarded for =
publication, currently planned for December. AI for author to provide =
updated draft.
    • 

  • Keystore draft needs to be =
updated for issues raised in WGLC and discussion on the mailing list. AI =
for author(s) to provide updated drafts before LC can be =
re-initiated.
    • 

  • SSH/TLS NETCONF/RESTCONF Client =
Server Models also needs updates based on changes in the Keystore =
draft.  AI for author(s) to provide updated drafts before LC will =
be re-initated. 
    • 

  • YANG Push, Subscribed =
notifications and NETCONF notification drafts need updates based on =
discussion in the meeting and on the list. There are still outstanding =
questions on whether NETCONF notifications draft is needed or its =
contents can be folded into subscribed-notifications draft.  All =
these issues need to be discussed and resolved on the mailing list. =
Co-chairs will initiate WGLC once the issues are resolved. AI for =
authors to close on open issues and post updated =
draft. 
    • 

  • Notification Message Headers and =
Bundles and Restconf notifications - These two drafts will be considered =
for WGLC later. No AI.
    • 

  • UDP Pub =
Channel draft needs more discussion on the mailing list. A milestone =
will be added to the NETCONF WG milestones. No other AI planned at this =
time.
    • 

Cheers



Mahesh (and Kent)





=

--Apple-Mail=_447435D7-DE1D-42EC-ADA3-802C6C84CAE1--


From nobody Mon Nov 27 16:01:35 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFE128AA1 for ; Mon, 27 Nov 2017 16:01:33 -0800 (PST)
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 2zrTwZ2x2tOh for ; Mon, 27 Nov 2017 16:01:31 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE641293F9 for ; Mon, 27 Nov 2017 16:01:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4D05377; Tue, 28 Nov 2017 01:01:29 +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 edYSxdg1N_IN; Tue, 28 Nov 2017 01:01:26 +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, 28 Nov 2017 01:01:29 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A32220121; Tue, 28 Nov 2017 01:01:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TEgV0GKtFjJY; Tue, 28 Nov 2017 01:01:28 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3F31200CC; Tue, 28 Nov 2017 01:01:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 91F5141830A7; Tue, 28 Nov 2017 01:00:00 +0100 (CET)
Date: Tue, 28 Nov 2017 01:00:00 +0100
From: Juergen Schoenwaelder 
To: Mahesh Jethanandani 
Cc: netconf 
Message-ID: <20171128000000.t3jjerammr2usyh3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Mahesh Jethanandani , netconf 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 00:01:34 -0000

On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:

> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
> support features like licensing, and semantic versioning.

I do not know what this means. (The goal of the NMDA work is to
support NMDA - focus is good thing. Perhaps the minutes will some shed
light on what this AI means but the minutes are not out yet.)

/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 Nov 27 16:34:33 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EDD129417; Mon, 27 Nov 2017 16:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FJIrfKk5UqrW; Mon, 27 Nov 2017 16:34:25 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24757128AA1; Mon, 27 Nov 2017 16:34:25 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0B1CB9ED4CA6F; Tue, 28 Nov 2017 00:34:21 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 00:34:22 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Mon, 27 Nov 2017 16:34:15 -0800
From: Alexander Clemm 
To: Mahesh Jethanandani , netconf 
CC: Jeff Tantsura , Yingzhen Qu , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [Netconf] Summary and AIs from IETF-100 meeting
Thread-Index: AQHTZ9dUHhA1I7Z67kivQ2HOm7SmNqMo7B7Q
Date: Tue, 28 Nov 2017 00:34:15 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10@sjceml521-mbx.china.huawei.com>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
In-Reply-To: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.14]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 00:34:27 -0000

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

One other action / question concerns WG adoption of draft-clemm-netconf-nmd=
a-diff-01 =
(Discrepancy detection between NMDA datastores).
The draft received considerable support when the question was asked in the =
room, but one question that was asked concerns whether this should be in Ne=
tconf or perhaps in Netmod instead.  Hence, cc'ing Lou and netmod.

The reason we put this into Netconf concerns the fact that this really defi=
nes an RPC, i.e. operations to facilitate interacting with NMDA-compliant s=
ervers.  It complements the RESTCONF and NETCONF operations, and the NMDA-e=
xtensions to those are also placed in the Netconf WG.  This seemed like ano=
ther natural extension.  The draft does not really define a traditional YAN=
G data model per se that would be used to manage something, therefore it si=
mply did not occur to us to place it into Netmod, although I can see how on=
e might make a case for that as well.

So, from our (coauthors) perspective, for the stated reasons, perhaps sligh=
t preference for Netconf, but really either one (Netconf or Netmod) is fine=
.  One thing we would not want to do is slow this effort down; since this w=
as presented in Netconf, not in Netmod, if we were moved into Netmod it wou=
ld hopefully not mean having to go back to square 1.

Thoughts?
--- Alex


From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana=
ndani
Sent: Monday, November 27, 2017 3:27 PM
To: netconf 
Subject: [Netconf] Summary and AIs from IETF-100 meeting

Dear NETCONF WG,

Below is the NETCONF WG session summary and AIs that were taken from the IE=
TF 100 meeting.

This e-mail verifies the discussion that took place in the room. Barring an=
y strong objection, the AIs identified in this summary will be acted upon.

The NETCONF session took place on Thursday, November 16, 2017, between 15:5=
0-17:50 Singapore Time.

The final notes from the meeting (once posted) will be available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/


  *   rfc6536bis received comments in IESG review. Some last minute updates=
 are being provided to address those comments, and once approved will allow=
 the document to go towards publication. AI for authors to post updated dra=
ft before Benoit submits it for publication.
  *   NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to supp=
ort features like licensing, and semantic versioning. It also needs to addr=
ess some bugs. Authors believe the document should be ready for WGLC by end=
 of this year. AI for authors to provide updated draft before the three set=
 of drafts are submitted for LC.
  *   Zerotouch draft went through LC. It received comments during that per=
iod, which the author will address. Author believes that once the document =
is ready, it can be forwarded for publication, currently planned for Decemb=
er. AI for author to provide updated draft.
  *   Keystore draft needs to be updated for issues raised in WGLC and disc=
ussion on the mailing list. AI for author(s) to provide updated drafts befo=
re LC can be re-initiated.
  *   SSH/TLS NETCONF/RESTCONF Client Server Models also needs updates base=
d on changes in the Keystore draft.  AI for author(s) to provide updated dr=
afts before LC will be re-initated.
  *   YANG Push, Subscribed notifications and NETCONF notification drafts n=
eed updates based on discussion in the meeting and on the list. There are s=
till outstanding questions on whether NETCONF notifications draft is needed=
 or its contents can be folded into subscribed-notifications draft.  All th=
ese issues need to be discussed and resolved on the mailing list. Co-chairs=
 will initiate WGLC once the issues are resolved. AI for authors to close o=
n open issues and post updated draft.
  *   Notification Message Headers and Bundles and Restconf notifications -=
 These two drafts will be considered for WGLC later. No AI.
  *   UDP Pub Channel draft needs more discussion on the mailing list. A mi=
lestone will be added to the NETCONF WG milestones. No other AI planned at =
this time.
Cheers

Mahesh (and Kent)


--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


One other action / question concerns =
WG adoption of
draft-clemm-netconf-nmda-diff-01<=
/span> (Discrepancy detection between NMDA datastores). 



The draft received considerable support when the qu=
estion was asked in the room, but one question that was asked concerns whet=
her this should be in Netconf or perhaps in Netmod
 instead.  Hence, cc’ing Lou and netmod.  


 


The reason we put this into Netconf concerns the fa=
ct that this really defines an RPC, i.e. operations to facilitate interacti=
ng with NMDA-compliant servers.  It complements
 the RESTCONF and NETCONF operations, and the NMDA-extensions to those are =
also placed in the Netconf WG.  This seemed like another natural exten=
sion.  The draft does not really define a traditional YANG data model =
per se that would be used to manage something,
 therefore it simply did not occur to us to place it into Netmod, although =
I can see how one might make a case for that as well. 



 


So, from our (coauthors) perspective, for the state=
d reasons, perhaps slight preference for Netconf, but really either one (Ne=
tconf or Netmod) is fine.  One thing we would
 not want to do is slow this effort down; since this was presented in Netco=
nf, not in Netmod, if we were moved into Netmod it would hopefully not mean=
 having to go back to square 1. 



 


Thoughts?


--- Alex


 


 








From: Netconf [mailto:netconf-bounce=
s@ietf.org]
On Behalf Of Mahesh Jethanandani

Sent: Monday, November 27, 2017 3:27 PM

To: netconf <netconf@ietf.org>

Subject: [Netconf] Summary and AIs from IETF-100 meeting<=
/span>






 




Dear NETCONF WG,




 




Below is the NETCONF WG session summary and AIs that=
 were taken from the IETF 100 meeting.




 




This e-mail verifies the discussion that took place =
in the room. Barring any strong objection, the AIs identified in this summa=
ry will be acted upon.




 




The NETCONF session took place on Thursday, November=
 16, 2017, between 15:50-17:50 Singapore Time.




 




The final notes from the meeting (once posted) will =
be available at:





 


    

  • rfc6536bis receiv=
ed comments in IESG review. Some last minute updates are being provided to =
address those comments, and once approved will allow the document to go tow=
ards publication. AI for authors to
 post updated draft before Benoit submits it for publication.
  • NMDA drafts (YA=
NG Library, NETCONF and RESTCONF) need updates to support features like lic=
ensing, and semantic versioning. It also needs to address some bugs. Author=
s believe the document should be ready
 for WGLC by end of this year. AI for authors to provide updated draft befo=
re the three set of drafts are submitted for LC.
  • Zerotouch draft went throu=
gh LC. It received comments during that period, which the author will addre=
ss. Author believes that once the document is ready, it can be forwarded fo=
r publication, currently planned
 for December. AI for author to provide updated draft.
  • Keystore draft needs t=
o be updated for issues raised in WGLC and discussion on the mailing list. =
AI for author(s) to provide updated drafts before LC can be re-initiated.
  • SSH=
/TLS NETCONF/RESTCONF Client Server Models also needs updates based on chan=
ges in the Keystore draft.  AI for author(s) to provide updated drafts=
 before LC will be re-initated. 
  • YANG Push, Subscribed notifications and=
 NETCONF notification drafts need updates based on discussion in the meetin=
g and on the list. There are still outstanding questions on whether NETCONF=
 notifications
 draft is needed or its contents can be folded into subscribed-notification=
s draft.  All these issues need to be discussed and resolved on the ma=
iling list. Co-chairs will initiate WGLC once the issues are resolved. AI f=
or authors to close on open issues and
 post updated draft. 
  • Notification Message Headers and Bundles and Restc=
onf notifications - These two drafts will be considered for WGLC later. No =
AI.
  • Cheers
    





 








Mahesh (and Kent)






 








--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_--


From nobody Mon Nov 27 16:35:51 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4201128AA1 for ; Mon, 27 Nov 2017 16:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 g5DCxbG16fbh for ; Mon, 27 Nov 2017 16:35:49 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 D0BF5127058 for ; Mon, 27 Nov 2017 16:35:48 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id g35so34906131lfi.13 for ; Mon, 27 Nov 2017 16:35:48 -0800 (PST)
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=mvP8+xgBbmhtJcz2x1gUIn87hw1IyTgvtncJRJM/TCs=; b=TxOzk5BNwPqNJfU46cpckLTmSwvS9XIMG//AiK2y6Zs2e2ipw0THZInwNZ0jTDpOqz yQyz7xeanyIYwlY1i45cQ+jy+C/Qyv7zaLjBV6Ragxb81WZr5z7W6Gera8mCz3SqS+Wu P++N5mUCWD3nX46nU3NbLbv2sohTpS8HVozIZOTb9FSy6B1L9UfqBabMf4zSvgkjU7Kr tJ2SzkWuAywFeS5pzNgqm8AVjj9mUb+bg5HSOlVkcYtXEWplGCgJrG1JjyALQVxIu2Bg /shH2AHLGSl+aUqqKYqN732iSIZ9N71k6vmoBKNZExj+13PIFNJiWtV3p8D+nyMak/3i 6TFw==
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=mvP8+xgBbmhtJcz2x1gUIn87hw1IyTgvtncJRJM/TCs=; b=uanhzft8qnI6fk8/5q+JyMifZmGE2kbeJPVxNSsrmEP5E204e/GNDWKnHkBRrfPacM OwrZd7D9XnYNf+MOgAK/dLCo7B3S49zTbywKKzsoxZdMfO8q2rEms3wfbptVhuMPxlzK WH0Uf/3HE2AjvXdGJKXER9WZ5Bu3y7pvTIOKK4nTRjEnUK93c3C2cDhSOC9LoZPuZn2Q E+/oIp6j1PFY27cn1OcJpVMMOfUqXycjV/gV5pJLJFRXHpXekwP33w/ri1SHxoka/qsR TikiR3oyXjzC9o6ffXwT4leqtNpcDfHVckH/zhkLW3EKbE5uGEpaq3WWWqsaIRsagO5e w5dg==
X-Gm-Message-State: AJaThX5/ZCzJt+KIbnObNJhpjrQNy9Urgl073FZ4u+XOSbm6+cZ/5C26 XwafzkZwWwQ+FO4b3RpRRxbrqZFw2oRtnk3FDD3XSg==
X-Google-Smtp-Source: AGs4zMauPbrUZUKBZ0nrjHhekiy5RtW89uMxIswiQghIoym7H8EQZkf/jFlONG3i7wpvPFeOTxq+l3lAXThRk86p3t4=
X-Received: by 10.46.93.27 with SMTP id r27mr14318761ljb.96.1511829347058; Mon, 27 Nov 2017 16:35:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 16:35:46 -0800 (PST)
In-Reply-To: <20171128000000.t3jjerammr2usyh3@elstar.local>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>
From: Andy Bierman 
Date: Mon, 27 Nov 2017 16:35:46 -0800
Message-ID: 
To: Juergen Schoenwaelder ,  Mahesh Jethanandani , netconf 
Content-Type: multipart/alternative; boundary="001a114d6042315ce5055f003346"
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 00:35:51 -0000

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

On Mon, Nov 27, 2017 at 4:00 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:
>
> > NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
> > support features like licensing, and semantic versioning.
>
> I do not know what this means. (The goal of the NMDA work is to
> support NMDA - focus is good thing. Perhaps the minutes will some shed
> light on what this AI means but the minutes are not out yet.)
>
>
+1

Someday we might learn to use the YANG augment-stmt, but looks like not
today ;-)



> /js
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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



--001a114b8c24b75457055f0ed1aa--


From nobody Tue Nov 28 10:55:57 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC6128B37 for ; Tue, 28 Nov 2017 10:55:54 -0800 (PST)
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 jdEDpfKgNwmX for ; Tue, 28 Nov 2017 10:55:52 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 A78361286CA for ; Tue, 28 Nov 2017 10:55:52 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id l24so332741pfj.6 for ; Tue, 28 Nov 2017 10:55:52 -0800 (PST)
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=+ybKCzg5JWxjqkFurqSAV2P0EmEcsnSWfAbnna3LU/M=; b=NePEXa45pdvy2RcDATnSsG1dGclzTKyqs90XCWKmn8nMn+TYDWaeae9pGLdTJxaC9V C3/btUlQK4ovlvbUmQzy5mmvtWYwXR7gBk55n0jHGUTix23IkabNMX+QMfDm8Hsx4RRu bsLhLuoP96W7LirRRa++15Cq61XHShlC1Vl2lGJKC1WLtyJwDlzc73RceLVetGRuuf7d 8dCKVnl7NIj31MkUS+oDk2NVdr5e19SThNANLzSz+JRYScWm3G8WBlXTgOkoWyVGd0gq 81CrmM4kWOSMxn5MLYiVYSdhbSfUu3EtswXuGg5qt/+OwORlUlcX+ZUIubXOlqgACRkS GgCQ==
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=+ybKCzg5JWxjqkFurqSAV2P0EmEcsnSWfAbnna3LU/M=; b=RxB/NecWwEhYti0+yZrfb9dYCiJn232nQgnLxuzbsg0TS93c89tpzENA/gjMChMdJf V0vzOpibzaFkmk0BTVO2Ho0j/bdJI/fOQOhPeAMVbWkiTLkE3/gAtwpHLI7qBmRiuMbY zXFbLAkp5+s8Jg2M4O2zi4R+RRZFUQz7d4pKW7FZU/UiOpNoBSUOhuFaojkp0dQejqt6 2yTtbbc+JW5TCLzvsAgzZDN0+B087Dsc+DCk5MiSKBsnn76obFXMmAW2yy6WVOn87Wek QWo/bdGvvWRHGbMT5G7qOHWBYsMT7K+yVOfREZY5SVCMPrQJmoz4hVQgjIXqtUSj6xzo JYoQ==
X-Gm-Message-State: AJaThX4ZbO3J50Qi9bnoFmZ5gDYNgVRZpD82q/K/LAWlpYlx4nQAaDAs xdAhA1XnoKssXRmiGEj7Pk8=
X-Google-Smtp-Source: AGs4zMapjG6ExSNCLub+hLfa+Z9cDeabx3aSgToN+0i2inj09pKKnZikfQnEyOZ/WnJwuBfw3bfVtQ==
X-Received: by 10.98.73.79 with SMTP id w76mr154205pfa.148.1511895352032; Tue, 28 Nov 2017 10:55:52 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id z86sm61275342pff.4.2017.11.28.10.55.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Nov 2017 10:55:51 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D969B131-A5FD-4083-A8D6-9ED342A2E4BF"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20171128.143658.232255353450011964.mbj@tail-f.com>
Date: Tue, 28 Nov 2017 10:55:40 -0800
Cc: Juergen Schoenwaelder , netconf@ietf.org
Message-Id: <0E983EDE-20EE-497D-9119-FF2A53942F10@gmail.com>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128.143658.232255353450011964.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 18:55:54 -0000

--Apple-Mail=_D969B131-A5FD-4083-A8D6-9ED342A2E4BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Nov 28, 2017, at 5:36 AM, Martin Bjorklund  wrote:
>=20
>> As a -bis draft, questions around what else makes sense. So questions
>> around whether YANG Library will support the concept of licensing
>> impacting what models are advertised and supported, and whether
>> semantic versioning should be part of the YANG Library were raised.
>=20
> Both these things are new issues, documented in individual drafts.  I
> don't think we should postpone the publication of 7895bis until these
> drafts are ready.  It is not even clear what the technical solution
> around these issues will be, and if it can be solved in YANG library
> or even if changes to YANG library are required.

I am not disagreeing with you. All I am doing is recording the =
discussion that happened in the meeting. And for the record, here are =
some notes from the meeting:

Benoit: Will the module have the capability to support modules that are =
dependent on things like license or presence of line cards. How to =
export from a server all potential modules? E.g. licensing might allow =
for additional modules
   Rob: No, this is not possible with the current version but the next =
version, about to be presented, would be capable of doing this.
   Kent: Refering to yesterday's discussion in NETMOD, would this be =
possible to support semver (semantic versioning), don't want to hold up =
this work, but thinking of flexibity for the future.
   Rob: Unclear even with semantic versioning whether a device is =
allowed to report multiple revisions of a module.
   Balazs; Each semver version should have one date based version, so =
that semver would be just an additional leaf in here in addition to the =
version field (date).

And there was no objection in the room about whether this should not be =
considered in scope. If the authors disagree, then I am glad we are =
having this discussion.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_D969B131-A5FD-4083-A8D6-9ED342A2E4BF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Nov 28, 2017, at 5:36 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

As a -bis draft, questions around what else makes sense. So =
questions
around whether YANG Library will support the =
concept of licensing
impacting what models are advertised =
and supported, and whether
semantic versioning should be =
part of the YANG Library were raised.

Both these things =
are new issues, documented in individual drafts.  I
don't think we =
should postpone the publication of 7895bis until these
drafts are ready. =
 It is not even clear what the technical solution
around these issues =
will be, and if it can be solved in YANG library
or even if changes =
to YANG library are required.

I am not disagreeing with you. All I am doing is =
recording the discussion that happened in the meeting. And for the =
record, here are some notes from the meeting:

Benoit: Will the module have the capability to support modules that are =
dependent on things like license or presence of line =
cards. How to export from a server all potential modules? E.g. licensing =
might allow for additional modules
   Rob: No, this is not possible with the current version but the next version, =
about to be presented, would be capable of doing this.
   Kent: Refering to yesterday's discussion in NETMOD, would this be =
possible to support semver (semantic versioning), don't want to hold up =
this work, but thinking of flexibity for the future.
   Rob: Unclear even with semantic =
versioning whether a device is allowed to report multiple revisions of a =
module.
   Balazs; Each semver version should have one date based version, =
so that semver would be just an additional leaf in here in addition to the version field (date).

And =
there was no objection in the room about whether this should not be =
considered in scope. If the authors disagree, then I am glad we are =
having this discussion.

Cheers.



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_D969B131-A5FD-4083-A8D6-9ED342A2E4BF--


From nobody Tue Nov 28 11:03:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C12126557 for ; Tue, 28 Nov 2017 11:03:07 -0800 (PST)
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 jwHFobMQvrmp for ; Tue, 28 Nov 2017 11:03:05 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 A8F22128D44 for ; Tue, 28 Nov 2017 11:03:02 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id k15so328491pgr.7 for ; Tue, 28 Nov 2017 11:03:02 -0800 (PST)
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=NnLJc9OSjNfUw+r2NG5XSdsNbzvXFJC/hwCGdzI8ux4=; b=EkA4jlchvg6ZGW/TvdRGlli+05dCaPIuKlV1Do3rb7dGoJ8V2JgQbNRD4gvRK0A03s 9yhVcHw19bBO+Txz0eMltalhnBfoM4cLjtsHmwzXPp4jaBr9Ue35ebq7PF9JUz0RVL83 1pVT1TCbeeDqkIBD6DxDKECrZwktTe9TbGyI2OBcmhbwMo4+9ynAblIb9pnVUseHUnQw AYvuYwrhDUYDXQI0te8txuZo05RS8AWeKcA9U4iCrtZ2C4eX4/BdrWHY9dJCse2YCvl9 /GZ9UD5FhmOTmbyY3bVLZm3N9Kjy4WFLyT3a0ICaexwIsS0kX3lF7XW5JXD8HPl6bHeg Fhkw==
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=NnLJc9OSjNfUw+r2NG5XSdsNbzvXFJC/hwCGdzI8ux4=; b=Jo84Q3Ro7DRu5ySS2L5HR0XHbmNENrwvInnnVEajlLltG7mG5VsReFaONoyDbeZ86J kdSm3O046A/wM74quuun5t6SpobRan0m2ub2cm26vzAxpyhT5+9H/H2ZQU1dxlnGiGa7 5lwDOdddeM7fIljyyFKAwtUZRha0UPUgEd2l3/Vnvmw6NukorpPZmTpdLmjizoFbR8Jv E6RJWip5ELdZag6QNv86+Hb8ODNswF8U5YajHSUujUz4gjQFJsoGp/hpN5YWTLHPo7zB 8yXPmtISGQWxKJR3kDgA0TRhbwIu2ABMGla5Winsmlkd0So+stPJpSbd1Ji7Fv35bLpQ XKHw==
X-Gm-Message-State: AJaThX5ppnhXA3vXa0u8niTmF6cIAv0ykxA/1Bmn+0ti58WXsqgUnbuP K5fmmO7/E0l77CX28AucmFCgVumV
X-Google-Smtp-Source: AGs4zMbyWqVpCkcVwKYSD8oF3otJpjosyqY7hBHb9X1ChBjkjluFRGfwxckCWop7d22XkVc/ixnU0A==
X-Received: by 10.99.124.75 with SMTP id l11mr116863pgn.453.1511895782235; Tue, 28 Nov 2017 11:03:02 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:c9c7:4c2b:674a:1f86]) by smtp.gmail.com with ESMTPSA id g7sm46254000pgn.43.2017.11.28.11.03.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Nov 2017 11:03:01 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_008121B6-DC5F-40C4-85E4-BECA92E41685"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de>
Date: Tue, 28 Nov 2017 11:02:55 -0800
Cc: netconf@ietf.org
Message-Id: <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de>
To: Henk Birkholz 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 19:03:07 -0000

--Apple-Mail=_008121B6-DC5F-40C4-85E4-BECA92E41685
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 28, 2017, at 5:17 AM, Henk Birkholz =
 wrote:
>=20
> This seems to be an unnecessary jab that has nothing to do with the =
actual topics raised by Mahesh, which were:
>=20
> - YANG Library will support the concept of licensing impacting what =
models are advertised and supported

I do not think the minutes are going to tell you anymore about the =
requirement. So let me take a stab at what I think the requirement is.=20=


YANG Library currently compiles a list of modules (and sub-modules) that =
are supported by the device. The same device might also support the =
concept of licensing, where the license controls whether the feature can =
be enabled on the device, e.g. BGP. The server has the ability to =
support BGP as a feature (the software exists), but the customer has not =
bought a license for the BGP feature. What should the server do under =
the circumstances? Should it advertise BGP module, and have the request =
from the client fail? Or should there another flag, either in the YANG =
Library or some other module that informs the client that although the =
device is capable of supporting BGP, it cannot because it lacks the =
license.

A similar scenario exists with YANG modules that support a particular =
line card, and that line card is hot pluggable. What should the YANG =
library do for modules that it advertises, but the line card for that =
module may or may not exist in the system?

> - semantic versioning should be part of the YANG Library

The requirement here is whether semantic versioning can be supported in =
the YANG library in addition to the current version, which is a date. =
Details on how it relates to YANG Library should be brought up on the =
list, preferably on a new thread.

>=20
> Which, btw, I also am not sure about how and where that came up and =
what it means. In consequence - as J=C3=BCrgen - I am curious to see the =
minutes.

Thanks to Robert for updating the rough minutes. If anyone disagrees =
with what is recorded in the rough notes, please listen to the recording =
here  and update the rough notes. =
They will be published as official minutes.

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_008121B6-DC5F-40C4-85E4-BECA92E41685
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Nov 28, 2017, at 5:17 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:

This seems to be an unnecessary jab that has =
nothing to do with the actual topics raised by Mahesh, which =
were:

- YANG Library will =
support the concept of licensing impacting what models are advertised =
and supported

I do not think =
the minutes are going to tell you anymore about the requirement. So let =
me take a stab at what I think the requirement is. 

YANG Library currently compiles a list of modules =
(and sub-modules) that are supported by the device. The same device =
might also support the concept of licensing, where the license controls =
whether the feature can be enabled on the device, e.g. BGP. The server =
has the ability to support BGP as a feature (the software exists), but =
the customer has not bought a license for the BGP feature. What should =
the server do under the circumstances? Should it advertise BGP module, =
and have the request from the client fail? Or should there another flag, =
either in the YANG Library or some other module that informs the client =
that although the device is capable of supporting BGP, it cannot because =
it lacks the license.

A similar =
scenario exists with YANG modules that support a particular line card, =
and that line card is hot pluggable. What should the YANG library do for =
modules that it advertises, but the line card for that module may or may =
not exist in the system?

- semantic =
versioning should be part of the YANG Library

The requirement here is whether semantic versioning can =
be supported in the YANG library in addition to the current version, =
which is a date. Details on how it relates to YANG Library should =
be brought up on the list, preferably on a new thread.


Which, btw, I also =
am not sure about how and where that came up and what it means. In =
consequence - as J=C3=BCrgen - I am curious to see the =
minutes.

Thanks to =
Robert for updating the rough minutes. If anyone disagrees with what is =
recorded in the rough notes, please listen to the recording here and =
update the rough notes. They will be published as official =
minutes.



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_008121B6-DC5F-40C4-85E4-BECA92E41685--


From nobody Tue Nov 28 13:30:57 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FD124205 for ; Tue, 28 Nov 2017 13:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 QHJZSlQGKyBK for ; Tue, 28 Nov 2017 13:30:55 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 DDFE0120721 for ; Tue, 28 Nov 2017 13:30:54 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id f18so1466975lfg.8 for ; Tue, 28 Nov 2017 13:30:54 -0800 (PST)
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=7jT7IBjum9VAJvK/vI8rnyVBcRnEgN5d0k6DR4BRrtg=; b=UFi82DKDFFoSt2TNPZtF72GIEriA9TA1vfZgbb3Lnabrck556MyHPCfIjzbR963dLe GGF+tHNp+YAhp9gs9I3GWLwn2cpUsyYQC4DzXspgMqQE2PFWAVHMwEts/ZxUYdPagSbi d/YCnwb1+WvOdCBXLnvoH+rqA+roxOjEQglbQMwroBS48KS3N1VFTHVg5yKS1BWJlagN yIc9J4DLKN0U4XLVtynTlmQ8u5g2sIe9zhhFCAZb/vVtYgi2m7iqxH/eNrckiWH7VP+t zPx1MHZY3+QEoyk2c7X3JFw7PzdjYHll4fcyPjlNH6xdEU0J7yI9ju+ZXrqoha4GZN1F 3eLQ==
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=7jT7IBjum9VAJvK/vI8rnyVBcRnEgN5d0k6DR4BRrtg=; b=nrqfyiSvnlFZapPlre44B6z28X4CHFgpGe22b9ekxwRJuXa8EQiB75v+AgYgEEhXcn ciK3cYt3bzTBXHt8Yecw79mFOR08RPvdPPQNZCnXLnDGXjW9B/fGGA3jNEDXy1j3+nwb PkEbBJ7ytcmPPNfpL1F6HgIAWaA4dwTdK4WuppKyX7sglaL5TzZgP1kZmMnEoITEMrTn dtY86gdtmmcsaS+MUZbz/uOTjcjSKFTuM4HlR4OCCHkcRByL5rZRnjq4xZsR+zyLjJia F7QPBFeMj+vwQvUgRo889hsh3zXG3aNcwfQpH3UcOWBYcOmUxZhkSboqZ1P7Y1PuVp5B Mchw==
X-Gm-Message-State: AJaThX5lyx7YFBxjQlfxdsCd7lbrqRWmXjCR8pW2gNyBdDXw6ITRuA5L fGXkgCXBsl68CGRaH8fIEB/nFQ2/3ItbDqr5TtRwDQ==
X-Google-Smtp-Source: AGs4zMYX3VdYbFlBqqrEN+luPtEdnssXEtFGxzCqInr2N62OLXiADeE4Z5RTSo5wpEmUqIbn6WgT/Vbzh3N75/f+eHU=
X-Received: by 10.46.126.1 with SMTP id z1mr268855ljc.81.1511904653063; Tue, 28 Nov 2017 13:30:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 28 Nov 2017 13:30:52 -0800 (PST)
In-Reply-To: <20171128.093725.744666943599041192.mbj@tail-f.com>
References: <20171128.093725.744666943599041192.mbj@tail-f.com>
From: Andy Bierman 
Date: Tue, 28 Nov 2017 13:30:52 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="089e0827ae18c7c842055f11bbbf"
Archived-At: 
Subject: Re: [Netconf] depth in get-data
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 21:30:57 -0000

--089e0827ae18c7c842055f11bbbf
Content-Type: text/plain; charset="UTF-8"

I support adding a depth leaf to 

Andy


On Tue, Nov 28, 2017 at 12:37 AM, Martin Bjorklund  wrote:

> Hi,
>
> There are some known issues with  and  that are
> identified in Andy's old
> draft-bierman-netconf-efficiency-extensions-00.  That draft also
> proposes a new operation  which addresses these issues.
>
> The new generic  operation in
> draft-ietf-netconf-nmda-netconf actually also addresses some of these
> issues.
>
> But there is one importnat thing that still is missing, and that is
> the "depth" parameter, which can be used by the client to limit the
> amount of data retrieved from a server.
>
> Note that RESTCONF defines the "depth" parameter as well.
>
> So I propose we add a leaf "depth" to the rpc "get-data", with the
> same semantics as in RESTCONF:
>
>
>      leaf depth {
>        type union {
>          type uint16 {
>            range "1..65535";
>          }
>          type enumeration {
>            enum "unbounded";
>          }
>        }
>        default "unbounded";
>        description
>          "For each node selected by the filter, this parameter
>           selects how many conceptual sub-tree levels should be
>           returned in the reply.  If the depth is 1, the reply include
>           just the selected nodes but no children.  If the depth is
>           'unbounded', all descendant nodes are included.";
>      }
>
>
>
> /martin
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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


I support adding a depth leaf to <get-data>

=

Andy


On Tue, Nov 28, 2017 at 12:37 AM, Martin Bjorklund <mbj@tail-f=
.com> wrote:
Hi,



There are some known issues with <get> and <get-config> that ar=
e

identified in Andy's old

draft-bierman-netconf-efficiency-extensions-00.=C2=A0 That draft also<=
br>
proposes a new operation <get2> which addresses these issues.



The new generic <get-data> operation in

draft-ietf-netconf-nmda-netconf actually also addresses some of these<=
br>
issues.



But there is one importnat thing that still is missing, and that is

the "depth" parameter, which can be used by the client to limit t=
he

amount of data retrieved from a server.



Note that RESTCONF defines the "depth" parameter as well.



So I propose we add a leaf "depth" to the rpc "get-data"=
;, with the

same semantics as in RESTCONF:





=C2=A0 =C2=A0 =C2=A0leaf depth {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint16 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0range "1..65535";

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unbounded";

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

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0default "unbounded";

=C2=A0 =C2=A0 =C2=A0 =C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"For each node selected by the filte=
r, this parameter

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 selects how many conceptual sub-tree lev=
els should be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned in the reply.=C2=A0 If the dept=
h is 1, the reply include

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 just the selected nodes but no children.=
=C2=A0 If the depth is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'unbounded', all descendant node=
s are included.";

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







/martin





_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--089e0827ae18c7c842055f11bbbf--


From nobody Wed Nov 29 00:59:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973C6126D05 for ; Wed, 29 Nov 2017 00:59:19 -0800 (PST)
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 qrEGv1njHooh for ; Wed, 29 Nov 2017 00:59:17 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F04124B17 for ; Wed, 29 Nov 2017 00:59:16 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8B1626A2; Wed, 29 Nov 2017 09:59:15 +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 UYQNt6MvRs5L; Wed, 29 Nov 2017 09:59:15 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 29 Nov 2017 09:59:15 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7455020123; Wed, 29 Nov 2017 09:59:15 +0100 (CET)
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 lNFUld69Hev9; Wed, 29 Nov 2017 09:59:14 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD9B820121; Wed, 29 Nov 2017 09:59:14 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6BFA94184C64; Wed, 29 Nov 2017 09:57:45 +0100 (CET)
Date: Wed, 29 Nov 2017 09:57:45 +0100
From: Juergen Schoenwaelder 
To: Mahesh Jethanandani 
Cc: Henk Birkholz , netconf@ietf.org
Message-ID: <20171129085745.uklljn2v4i7uijxc@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Mahesh Jethanandani , Henk Birkholz , netconf@ietf.org
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.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: <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 08:59:19 -0000

Mahesh,

so do I understand correctly that all this is about yang library and
has nothing to do with the NMDA update for RC and NC? This would
already help reducing my level of surprise.

Concerning licensing: A functionality that does not exist in the
server does not exist in the server, whatever the reason is. In the
future, there may be a standard YANG model that allows to configure
(enable/disable) functionality within a modular NC/RC server. So far,
I have not seen a proposal for this and hence I consider this topic
not ready for any WG action.

Concerning missing hardware: The approach of the interfaces model is
to support provisioning of interface configuration for non-existing
interfaces. Hence, if a server can configure say ATM line cards, then
the server should announce support for the ATM specific YANG modules
independently of the question whether ATM line cards are currently
present. To find out which hardware is present at a specific point in
time, consult the ietf-hardware model. I do not see why a change to
yang library would be needed to deal with missing hardware nor do I
recall what the proposed edits were.

Yes, from the SNMP world I know that sometimes support for specific
modules comes with the firmware of a piece of hardware but the NC/RC
design never went into the details of modular servers like SNMP did
with standards for subagent technologies etc. In the YANG world, this
is all entirely implementation specific and frankly I would not open
this can of worms. If the presence of some hardware enables server
functionality (or a license that is installed), then this may lead to
an update of the content of the yang library, like a restart of a
NC/RC server may do. I do not see which technical change would be
needed.

The bottom line is that without concrete actionable proposals, we
should not delay the finishing of NMDA work. And as Andy says, things
that can be done with augmentations are good to do with augmentations.

/js

On Tue, Nov 28, 2017 at 11:02:55AM -0800, Mahesh Jethanandani wrote:
> 
> > On Nov 28, 2017, at 5:17 AM, Henk Birkholz  wrote:
> > 
> > This seems to be an unnecessary jab that has nothing to do with the actual topics raised by Mahesh, which were:
> > 
> > - YANG Library will support the concept of licensing impacting what models are advertised and supported
> 
> I do not think the minutes are going to tell you anymore about the requirement. So let me take a stab at what I think the requirement is. 
> 
> YANG Library currently compiles a list of modules (and sub-modules) that are supported by the device. The same device might also support the concept of licensing, where the license controls whether the feature can be enabled on the device, e.g. BGP. The server has the ability to support BGP as a feature (the software exists), but the customer has not bought a license for the BGP feature. What should the server do under the circumstances? Should it advertise BGP module, and have the request from the client fail? Or should there another flag, either in the YANG Library or some other module that informs the client that although the device is capable of supporting BGP, it cannot because it lacks the license.
> 
> A similar scenario exists with YANG modules that support a particular line card, and that line card is hot pluggable. What should the YANG library do for modules that it advertises, but the line card for that module may or may not exist in the system?
> 
> > - semantic versioning should be part of the YANG Library
> 
> The requirement here is whether semantic versioning can be supported in the YANG library in addition to the current version, which is a date. Details on how it relates to YANG Library should be brought up on the list, preferably on a new thread.
> 
> > 
> > Which, btw, I also am not sure about how and where that came up and what it means. In consequence - as Jrgen - I am curious to see the minutes.
> 
> Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here  and update the rough notes. They will be published as official minutes.
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


-- 
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 Nov 29 04:13:39 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043421273E2 for ; Wed, 29 Nov 2017 04:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 319kaB1-t34u for ; Wed, 29 Nov 2017 04:13:34 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 652D7127876 for ; Wed, 29 Nov 2017 04:13:34 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id i11so5475429wmf.4 for ; Wed, 29 Nov 2017 04:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Eg54n3zJRLclSVsSLCG5zIrPmI/CcfeTw6jq10IRu20=; b=DW9BdmLZ94AOuFwzeVtPTx9uqfl7Xz0Do3/3q1Jp5qVcNr388bJV+4hKt0QylzGz3g pyPXDI9l8t6lQBf/hPGimpmfk27IlmpyjOUSwkYPlGEAbuy1qd5I5HnXxN7DAvaBDSJz tkoJZcFypW0cNMK44XpJqRI7Lz/Dxm9bG1OtNA8/Kr85kNVwdpbCM5zNtkvzqvNyybvG rBhfiWvUYPM1VgQl2JlT3xuwv1B85OIt2iSqtMiNIZy6vwkKv8KLFrds19ltu4JTalyO vrThCqPddYZZOxuRM5oN6uN15rDTfGpjWO1yOvoR9t0rqw8rab//ETj97FxI9Pe2WnUV MmZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Eg54n3zJRLclSVsSLCG5zIrPmI/CcfeTw6jq10IRu20=; b=CPYJaxEe2/RbLWiyVjnyK47twDw6nevsJ7adV2lavldPAGZrBEI7i0fa+a19z77uwU hdfa3BfsnOxU4YM9ZEeL8Hi2wuCuG5FZs6z9UXKA4RTfCGRsxJ/UQO5ItBJ0Mz9zblET K4jVyuL8CZN4E6b+y2N0MSUb3a+Qby8I4LsoIYXzu2cI05BueBgbgBMTvm1Uf7XP5eF1 f9tmy+lAvVrnv2Qk5wfsS1+pWEcemESGbi/OeVn4b1WZg+d92LsvBJbCVwKqDWYXsfdb ZF4lSJD8TiRDYMwxd9MIsOo1hY+Vzimj0kdsDgYC/Xpo0+D3UviSvWg5t+TSF5JId5Hw jwLg==
X-Gm-Message-State: AJaThX5EuDSXB0otmuvAgk0lOHBPXkzOG2WFkIuh+WlR1T0ZHKXatwgX blOnErPDh0ImaHfN+E7qZSs=
X-Google-Smtp-Source: AGs4zMY3oJCunDDZ/vrhnaSzNytTRWdVGAKzV6TdWvscyFrqBqUYelUATdRH7i0XMSFuIXk8QgZB6Q==
X-Received: by 10.28.232.130 with SMTP id f2mr2198137wmi.46.1511957612833; Wed, 29 Nov 2017 04:13:32 -0800 (PST)
Received: from DESKTOPFLHJVQJ ([2001:16b8:2d5d:9800:34db:61d5:268a:cacb]) by smtp.gmail.com with ESMTPSA id 19sm2430654wmv.41.2017.11.29.04.13.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 04:13:32 -0800 (PST)
From: "Mehmet Ersue" 
To: "'Juergen Schoenwaelder'" , "'Mahesh Jethanandani'" 
Cc: 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com> <20171129085745.uklljn2v4i7uijxc@elstar.local>
In-Reply-To: <20171129085745.uklljn2v4i7uijxc@elstar.local>
Date: Wed, 29 Nov 2017 13:13:32 +0100
Message-ID: <009101d3690b$79b33220$6d199660$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFlT9WHVylUv8UeRTDpSBFEwXLkhAKO+jWtAgwL9c4Cgj/g/QIuEulBAuC9sukB487936OW9W4Q
Content-Language: de
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 12:13:37 -0000

Hi Mahesh, All,

I believe the aim of the WG should be to fulfil the approved charter as =
soon
as possible.
The WG for sure can decide to adjust the charter if an extension is
necessary, however adding new topics with unclear solutions is
counterproductive with the overall goal to publish rapidly.=20

BTW the notes from the meeting do not count much if people disagree on =
the
maillist.

Mehmet

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, November 29, 2017 9:58 AM
> To: Mahesh Jethanandani 
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
>=20
> Mahesh,
>=20
> so do I understand correctly that all this is about yang library and =
has
nothing
> to do with the NMDA update for RC and NC? This would already help
> reducing my level of surprise.
>=20
> Concerning licensing: A functionality that does not exist in the =
server
does
> not exist in the server, whatever the reason is. In the future, there =
may
be a
> standard YANG model that allows to configure
> (enable/disable) functionality within a modular NC/RC server. So far, =
I
have
> not seen a proposal for this and hence I consider this topic not ready =
for
any
> WG action.
>=20
> Concerning missing hardware: The approach of the interfaces model is =
to
> support provisioning of interface configuration for non-existing
interfaces.
> Hence, if a server can configure say ATM line cards, then the server
should
> announce support for the ATM specific YANG modules independently of =
the
> question whether ATM line cards are currently present. To find out =
which
> hardware is present at a specific point in time, consult the =
ietf-hardware
> model. I do not see why a change to yang library would be needed to =
deal
> with missing hardware nor do I recall what the proposed edits were.
>=20
> Yes, from the SNMP world I know that sometimes support for specific
> modules comes with the firmware of a piece of hardware but the NC/RC
> design never went into the details of modular servers like SNMP did =
with
> standards for subagent technologies etc. In the YANG world, this is =
all
> entirely implementation specific and frankly I would not open this can =
of
> worms. If the presence of some hardware enables server functionality =
(or a
> license that is installed), then this may lead to an update of the =
content
of
> the yang library, like a restart of a NC/RC server may do. I do not =
see
which
> technical change would be needed.
>=20
> The bottom line is that without concrete actionable proposals, we =
should
not
> delay the finishing of NMDA work. And as Andy says, things that can be
done
> with augmentations are good to do with augmentations.
>=20
> /js
>=20
> On Tue, Nov 28, 2017 at 11:02:55AM -0800, Mahesh Jethanandani wrote:
> >
> > > On Nov 28, 2017, at 5:17 AM, Henk Birkholz
>  wrote:
> > >
> > > This seems to be an unnecessary jab that has nothing to do with =
the
> actual topics raised by Mahesh, which were:
> > >
> > > - YANG Library will support the concept of licensing impacting =
what
> > > models are advertised and supported
> >
> > I do not think the minutes are going to tell you anymore about the
> requirement. So let me take a stab at what I think the requirement is.
> >
> > YANG Library currently compiles a list of modules (and sub-modules) =
that
> are supported by the device. The same device might also support the
> concept of licensing, where the license controls whether the feature =
can
be
> enabled on the device, e.g. BGP. The server has the ability to support =
BGP
as
> a feature (the software exists), but the customer has not bought a =
license
for
> the BGP feature. What should the server do under the circumstances?
> Should it advertise BGP module, and have the request from the client =
fail?
Or
> should there another flag, either in the YANG Library or some other =
module
> that informs the client that although the device is capable of =
supporting
BGP,
> it cannot because it lacks the license.
> >
> > A similar scenario exists with YANG modules that support a =
particular
line
> card, and that line card is hot pluggable. What should the YANG =
library do
for
> modules that it advertises, but the line card for that module may or =
may
not
> exist in the system?
> >
> > > - semantic versioning should be part of the YANG Library
> >
> > The requirement here is whether semantic versioning can be supported =
in
> the YANG library in addition to the current version, which is a date.
Details on
> how it relates to YANG Library should be brought up on the list,
preferably on
> a new thread.
> >
> > >
> > > Which, btw, I also am not sure about how and where that came up =
and
> what it means. In consequence - as J=FCrgen - I am curious to see the
minutes.
> >
> > Thanks to Robert for updating the rough minutes. If anyone disagrees
with
> what is recorded in the rough notes, please listen to the recording =
here
>  and update the rough notes. They
> will be published as official minutes.
> >
> > Mahesh Jethanandani
> > mjethanandani@gmail.com
> >
>=20
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>=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
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Wed Nov 29 04:58:33 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3BB126C2F for ; Wed, 29 Nov 2017 04:58:32 -0800 (PST)
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 GyLpqJ_c48Hh for ; Wed, 29 Nov 2017 04:58:30 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB57126BF0 for ; Wed, 29 Nov 2017 04:58:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6359; q=dns/txt; s=iport; t=1511960310; x=1513169910; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=H7HjkbfwekvrMoKptFLG6ymObVyLOfWK6gEEqrLIthQ=; b=QtgR1ot+xU9QNrOg81KKE0oJh21m/+HGoCkodMy6R+GUcWjiUZFGBjD6 EpzGP6iXsuOYBA9h0QKJFXxS03Lqli8nXe8HSy8PLfsYt0lJD5s05EQHL KOuMrNTlROfzdK02MS7KiR1EBUmq2wVrPnrpLNrO4MJnLKyksucqGiuED E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAQAgrh5a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRQ5NSeDf4sUj18vfodsjgqCEQoYC4FegmtPAoVOFgEBAQE?= =?us-ascii?q?BAQEBAWsohSABAQEDAQEhDwEFNhsLDgoCAiYCAiEGMAYBDAYCAQGKBgMVEKcNg?= =?us-ascii?q?ieHNA2DJgEBAQEBAQEBAQEBAQEBAQEBAQEaBYEPgjKDX4FpKYFbcTaBSYEigh6?= =?us-ascii?q?DK4JjBaIQPZAVhHmCFoYPg2OHSYo5gnuBFYd5gTomByuBUTIaCBsVOoIpglIME?= =?us-ascii?q?IFnQTYBigkBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,473,1505779200";  d="scan'208";a="496042"
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; 29 Nov 2017 12:58:28 +0000
Received: from [10.61.93.32] (ams3-vpn-dhcp7457.cisco.com [10.61.93.32]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vATCwRkQ016584; Wed, 29 Nov 2017 12:58:27 GMT
To: Mahesh Jethanandani , Henk Birkholz , netconf@ietf.org
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com> <20171129085745.uklljn2v4i7uijxc@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Wed, 29 Nov 2017 12:58:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171129085745.uklljn2v4i7uijxc@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 12:58:32 -0000

The final structure that I presented in the NETCONF session (e.g. a list 
of named schema) should be sufficient to cover licensing (in a future 
piece of work).  Martin has a further tweak to this to allow a datastore 
to indicate which version of the schema is uses, effectively solving the 
issue of wanting a different small schema just for an I2RS datastore.  I 
think that we should update the library draft to this latest version so 
that the WG can review and discuss it.

I don't know if the proposed structure will be sufficient to support 
semantic versioning (beyond just adding a semantic version leaf).  
Fundamentally I think that this will depend on whether a single schema 
can implement two different revisions of a model.  I think that this 
question needs a lot more thought and discussion, and my instinct is 
that the answer to this question may well be that this will not be 
allowed, and hence the existing proposed structure will be sufficient.  
Of course, it is hard to accurately predict the future.

But I do completely agree with Juergen in that I don't think that we 
should be delaying finishing the current version of YANG library bis to 
investigate semantic versioning or licensing. Working out the nuances 
associated with these issues may take a year or more.

I think that we need to finish the NMDA work that we have started (and 
are close to finishing), ensuring that the YANG library structure that 
we choose isn't obviously wrong for what we want to do in the future (it 
doesn't appear to be), but not make the structure more complex than it 
needs to be just to support a potential future requirement that may or 
may not turn out to be valid.

Just my thoughts,
Rob


On 29/11/2017 08:57, Juergen Schoenwaelder wrote:
> Mahesh,
>
> so do I understand correctly that all this is about yang library and
> has nothing to do with the NMDA update for RC and NC? This would
> already help reducing my level of surprise.
>
> Concerning licensing: A functionality that does not exist in the
> server does not exist in the server, whatever the reason is. In the
> future, there may be a standard YANG model that allows to configure
> (enable/disable) functionality within a modular NC/RC server. So far,
> I have not seen a proposal for this and hence I consider this topic
> not ready for any WG action.
>
> Concerning missing hardware: The approach of the interfaces model is
> to support provisioning of interface configuration for non-existing
> interfaces. Hence, if a server can configure say ATM line cards, then
> the server should announce support for the ATM specific YANG modules
> independently of the question whether ATM line cards are currently
> present. To find out which hardware is present at a specific point in
> time, consult the ietf-hardware model. I do not see why a change to
> yang library would be needed to deal with missing hardware nor do I
> recall what the proposed edits were.
>
> Yes, from the SNMP world I know that sometimes support for specific
> modules comes with the firmware of a piece of hardware but the NC/RC
> design never went into the details of modular servers like SNMP did
> with standards for subagent technologies etc. In the YANG world, this
> is all entirely implementation specific and frankly I would not open
> this can of worms. If the presence of some hardware enables server
> functionality (or a license that is installed), then this may lead to
> an update of the content of the yang library, like a restart of a
> NC/RC server may do. I do not see which technical change would be
> needed.
>
> The bottom line is that without concrete actionable proposals, we
> should not delay the finishing of NMDA work. And as Andy says, things
> that can be done with augmentations are good to do with augmentations.
>
> /js
>
> On Tue, Nov 28, 2017 at 11:02:55AM -0800, Mahesh Jethanandani wrote:
>>> On Nov 28, 2017, at 5:17 AM, Henk Birkholz  wrote:
>>>
>>> This seems to be an unnecessary jab that has nothing to do with the actual topics raised by Mahesh, which were:
>>>
>>> - YANG Library will support the concept of licensing impacting what models are advertised and supported
>> I do not think the minutes are going to tell you anymore about the requirement. So let me take a stab at what I think the requirement is.
>>
>> YANG Library currently compiles a list of modules (and sub-modules) that are supported by the device. The same device might also support the concept of licensing, where the license controls whether the feature can be enabled on the device, e.g. BGP. The server has the ability to support BGP as a feature (the software exists), but the customer has not bought a license for the BGP feature. What should the server do under the circumstances? Should it advertise BGP module, and have the request from the client fail? Or should there another flag, either in the YANG Library or some other module that informs the client that although the device is capable of supporting BGP, it cannot because it lacks the license.
>>
>> A similar scenario exists with YANG modules that support a particular line card, and that line card is hot pluggable. What should the YANG library do for modules that it advertises, but the line card for that module may or may not exist in the system?
>>
>>> - semantic versioning should be part of the YANG Library
>> The requirement here is whether semantic versioning can be supported in the YANG library in addition to the current version, which is a date. Details on how it relates to YANG Library should be brought up on the list, preferably on a new thread.
>>
>>> Which, btw, I also am not sure about how and where that came up and what it means. In consequence - as Jürgen - I am curious to see the minutes.
>> Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here  and update the rough notes. They will be published as official minutes.
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>


From nobody Wed Nov 29 07:30:42 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B02127011 for ; Wed, 29 Nov 2017 07:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 BDIO0iv6xEDZ for ; Wed, 29 Nov 2017 07:30:37 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AF8124B18 for ; Wed, 29 Nov 2017 07:30:36 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vATFTdeP025963; Wed, 29 Nov 2017 07:30:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=zOd4gl+TLWR4J/VAYpEAFoUK1Q9sO9FzTAgFhWLA3AI=; b=fVyvG1bttv1s0bNkRTzByIMC4XwGA71FuzmbAl5kUVx9nV00yWJZ3lwc/k3LyBzrQNOJ w2Yp82tE2ueS5nsLs+UueFXXAEkrbXL7hvO/uRwyp2cNjTFTjuW9AQmGb01c4t4l6nIz YL3bffN/EPw7HxYsUuMqqGPwYwJp8kL5d/GamsXpr7o74SGqSi3AuEZ92vUOEN72TMLD PSsZhqxX9CApLt3ANERoZeYEdcLmKAwn5cGL0rNyxxReYwIkF14lHmEA7+yNKRCEOl7e ryEpvcWmG2cgSqVHU4nFvjLGKUPvbGwN7QxC4zoT6NrqUvV4pQk4YNQL3/2Q0XfHhTN2 2g== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0050.outbound.protection.outlook.com [207.46.163.50]) by mx0b-00273201.pphosted.com with ESMTP id 2ehxwm83d9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Nov 2017 07:30:32 -0800
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Wed, 29 Nov 2017 15:30:30 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0282.004; Wed, 29 Nov 2017 15:30:29 +0000
From: Kent Watsen 
To: Robert Wilton , Mahesh Jethanandani , Henk Birkholz , "netconf@ietf.org" 
Thread-Topic: [Netconf] Summary and AIs from IETF-100 meeting
Thread-Index: AQHTZ9dIwjivd4z+2kGyRgmdr/9C4KMo5/wAgAAMyoCAAF9/AIAAcpaAgABgdYCAAOk/gIAAQ0GA///WqIA=
Date: Wed, 29 Nov 2017 15:30:29 +0000
Message-ID: <92F98907-80F9-4D24-BBE8-C98B93D620AF@juniper.net>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com> <20171129085745.uklljn2v4i7uijxc@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:rYDRj5OSY7q/zzCZukjENyRDMlgY4VExlDToz4cwu9ZXx8/sAcOSUC6Ga2tqi7B8F6W3nSHbAqybCSJEB6VImW/sSqbuU+QD+IIvFo/WNM9oRvUdboZaKH6UVlThPB+U9zHqw5GvcBs6cVjlbvXyLkU2rUvdxhqva/vIIQ6Wt+wzz4XuKMsMG/4ZzROjC5dwdgvi4igZO2mv93u3Z09NVbQV3T4Xbvbf6WO0b255IXbDK7h3nVODBuONx1/u06kqj5OJnVIhGoBGridRZ8xNe/3KnKkS5+0qrgmffvvRjmSgx6jMsu44F9kM5q8iomVIOFWotwrZ1DTYad34mOABIjRxM6gdtVSng09WwnHkKm0=; 5:yGghK1VMn7iGaEaXsTHnoGeQcMgDsBUxthBAMMt91XKibtfs9zxuy0GdrqbLsur5Hi3N2VN5Mel52NKEJL3jMX1u66gSJn2q0MOC7KnOWOPe0x6XRmUjFDGOKcCiDEe/VXE1lX4ODFNOrUJ0Zdo0ncnkZDbcjg1sJCBfZuh+8Ac=; 24:d4XeH/gQl14KrTKJzHaRK3lCMaErO2pA9i5/v/B1S5Ij6Ni1LW/+DAfJ44fYFgS5Jt+7hOYjK/yaMyA7sUHwvG2lzpZSfV0LMaDYk9SsyRY=; 7:/J8UP7v1L0Q5ij9z5SUYCpf85Yje9qWkOMy8AzEWtZ4gfttbfRMnYbfYFWzzfUIvUDi5tI0cyCagj5RySaXvgQUE5darSzbAbsJ5itJyLfCIzQrQveYYIWVElZohXldbNsa16IyBb+jrbqp/2EIe8/b2TlUYbBXk1K6PDhZYbnSGE7awebB6atK8F8Xv9ufg8sU6gHjWO73eblnN3YgYJpU4W+nZqpBkHrZA7YEb+870VUjhxuW450GdHi4bxWa7
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ae1bde2e-99cf-45e4-bd91-08d5373e1f6f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603272); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB276; 
x-forefront-prvs: 05066DEDBB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(366004)(346002)(199003)(51444003)(189002)(24454002)(3660700001)(93886005)(53936002)(39060400002)(6116002)(83506002)(3846002)(102836003)(105586002)(81156014)(2900100001)(81166006)(14454004)(7736002)(106356001)(3280700002)(6246003)(478600001)(189998001)(53546010)(966005)(50986999)(8676002)(2950100002)(33656002)(99286004)(54356999)(76176999)(101416001)(36756003)(305945005)(66066001)(6306002)(561944003)(229853002)(25786009)(2501003)(6512007)(68736007)(6436002)(6486002)(6506006)(82746002)(77096006)(110136005)(58126008)(575784001)(2906002)(86362001)(316002)(5660300001)(83716003)(8936002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: I47m0e4SRVXO217Or+SzHeiQO3Rqs1BoOnVdd4Kie0y5XZpq3kcZ37UqKQOFp+ue4Zb5V7a720VavGNhGHKqzQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <0923D68079E20E439A3F66595B04AC48@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ae1bde2e-99cf-45e4-bd91-08d5373e1f6f
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 15:30:29.6772 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-29_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290202
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 15:30:40 -0000

DQo+IFRoZSBmaW5hbCBzdHJ1Y3R1cmUgdGhhdCBJIHByZXNlbnRlZCBpbiB0aGUgTkVUQ09ORiBz
ZXNzaW9uIChlLmcuIGEgbGlzdCANCj4gb2YgbmFtZWQgc2NoZW1hKSBzaG91bGQgYmUgc3VmZmlj
aWVudCB0byBjb3ZlciBsaWNlbnNpbmcgKGluIGEgZnV0dXJlIA0KPiBwaWVjZSBvZiB3b3JrKS4g
IE1hcnRpbiBoYXMgYSBmdXJ0aGVyIHR3ZWFrIHRvIHRoaXMgdG8gYWxsb3cgYSBkYXRhc3RvcmUg
DQo+IHRvIGluZGljYXRlIHdoaWNoIHZlcnNpb24gb2YgdGhlIHNjaGVtYSBpcyB1c2VzLCBlZmZl
Y3RpdmVseSBzb2x2aW5nIHRoZSANCj4gaXNzdWUgb2Ygd2FudGluZyBhIGRpZmZlcmVudCBzbWFs
bCBzY2hlbWEganVzdCBmb3IgYW4gSTJSUyBkYXRhc3RvcmUuICBJIA0KPiB0aGluayB0aGF0IHdl
IHNob3VsZCB1cGRhdGUgdGhlIGxpYnJhcnkgZHJhZnQgdG8gdGhpcyBsYXRlc3QgdmVyc2lvbiBz
byANCj4gdGhhdCB0aGUgV0cgY2FuIHJldmlldyBhbmQgZGlzY3VzcyBpdC4NCg0KT3IganVzdCBw
b3N0ZWQgdG8gdGhlIGxpc3RlZCwgZXZlbiBpZiBub3QgaW4gYSBkcmFmdC4gIEl0IHNlZW1zIHRo
YXQgYQ0KcmFkaWNhbCByZXN0cnVjdHVyaW5nIGZyb20gLTAyIGlzIGJlaW5nIGNvbnNpZGVyZWQg
bm93LCBpdCBtaWdodCBiZSBnb29kDQp0byBnZXQgYnktaW4gYmVmb3JlIHBvc3RpbmcgYSBkcmFm
dCB1cGRhdGUuICAgRWl0aGVyIHdheSBpcyBmaW5lOyB3ZSBjYW4NCmFsd2F5cyByZXZlcnQgaWYg
bmVlZGVkLg0KDQoNCj4gSSBkb24ndCBrbm93IGlmIHRoZSBwcm9wb3NlZCBzdHJ1Y3R1cmUgd2ls
bCBiZSBzdWZmaWNpZW50IHRvIHN1cHBvcnQgDQo+IHNlbWFudGljIHZlcnNpb25pbmcgKGJleW9u
ZCBqdXN0IGFkZGluZyBhIHNlbWFudGljIHZlcnNpb24gbGVhZikuICANCj4gRnVuZGFtZW50YWxs
eSBJIHRoaW5rIHRoYXQgdGhpcyB3aWxsIGRlcGVuZCBvbiB3aGV0aGVyIGEgc2luZ2xlIHNjaGVt
YSANCj4gY2FuIGltcGxlbWVudCB0d28gZGlmZmVyZW50IHJldmlzaW9ucyBvZiBhIG1vZGVsLiAg
SSB0aGluayB0aGF0IHRoaXMgDQo+IHF1ZXN0aW9uIG5lZWRzIGEgbG90IG1vcmUgdGhvdWdodCBh
bmQgZGlzY3Vzc2lvbiwgYW5kIG15IGluc3RpbmN0IGlzIA0KPiB0aGF0IHRoZSBhbnN3ZXIgdG8g
dGhpcyBxdWVzdGlvbiBtYXkgd2VsbCBiZSB0aGF0IHRoaXMgd2lsbCBub3QgYmUgDQo+IGFsbG93
ZWQsIGFuZCBoZW5jZSB0aGUgZXhpc3RpbmcgcHJvcG9zZWQgc3RydWN0dXJlIHdpbGwgYmUgc3Vm
ZmljaWVudC4gIA0KPiBPZiBjb3Vyc2UsIGl0IGlzIGhhcmQgdG8gYWNjdXJhdGVseSBwcmVkaWN0
IHRoZSBmdXR1cmUuDQoNClRoZSBjdXJyZW50IC0wMiBzdHJ1Y3R1cmUgc3VwcG9ydHMgc2VtLXZl
ciwgaG93ZXZlciBpdCBtaWdodCBldm9sdmUsIA0KaW4gdGhhdCB0aGUgcHJpbWFyeSBrZXkgdG8g
aXRzIGxpc3RzIGlzIGFuIGlubm9jdW91cyAiaWQiIGxlYWYuICBUaGUNCmN1cnJlbnQvcHJvcG9z
ZWQgLTAzIHZlcnNpb24gdXNlcyAibmFtZSArIHJldmlzaW9uIiBhcyB0aGUga2V5LCB3aGljaA0K
aW50cm9kdWNlcyB0aGUgcG9zc2liaWxpdHkgb2YgYW4gaXNzdWUgd2hlbiB3ZSB0cnkgdG8gZG8g
c2VtLXZlciBsYXRlciwNCmFuZCBieSAibGF0ZXIiLCBJIGFzc3VtZSB0aGF0IHdlIGFncmVlIHRo
YXQgaXQgaXMgYSBwcmVzc2luZyBpc3N1ZSB0aGF0DQpzaG91bGQgYmUgYWRkcmVzc2VkIHNob3J0
bHkuICANCg0KDQo+IEJ1dCBJIGRvIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCBKdWVyZ2VuIGluIHRo
YXQgSSBkb24ndCB0aGluayB0aGF0IHdlIA0KPiBzaG91bGQgYmUgZGVsYXlpbmcgZmluaXNoaW5n
IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgWUFORyBsaWJyYXJ5IGJpcyB0byANCj4gaW52ZXN0aWdh
dGUgc2VtYW50aWMgdmVyc2lvbmluZyBvciBsaWNlbnNpbmcuIFdvcmtpbmcgb3V0IHRoZSBudWFu
Y2VzIA0KPiBhc3NvY2lhdGVkIHdpdGggdGhlc2UgaXNzdWVzIG1heSB0YWtlIGEgeWVhciBvciBt
b3JlLg0KDQpJJ20gYXNzdW1lIHRoYXQgbGljZW5zZXMgYXJlIGJlc3Qgc3VwcG9ydGVkIGJ5IGZl
YXR1cmVzLiAgRXZlbiBpZiB0aGUNCmZlYXR1cmVzIGFyZSBub3QgaW4gdGhlIGJhc2UgbW9kdWxl
LCBhIHZlbmRvciBjYW4gYXVnbWVudCB0aGUgYmFzZSANCm1vZHVsZSB3aXRoIGZlYXR1cmVzLCB3
aGljaCBzaG91bGQgd29yayBJIHRoaW5rLg0KDQpBcyBmb3Igc2VtLXZlciwgSSBhZ3JlZSB0aGF0
IHRoaXMgZmVhdHVyZSByZXF1ZXN0cyBzZWVtcyBsaWtlIGl0cyANCnNuZWFraW5nIGluIGF0IHRo
ZSBsYXN0IGhvdXIsIGJ1dCBJJ2QgcmF0aGVyIGhhdmUgYSB5YW5nIGxpYnJhcnkgDQp0aGF0IGhh
cyBubyBwb3NzaWJsZSBjb25mbGljdCwgd2hpY2ggaXMgYXNzdXJlZCB3aGVuIHRoZSBrZXkgZmll
bGQNCmRvZXNuJ3QgcmVmZXJlbmNlIG1vZHVsZSBuYW1lcyBhbmQgcmV2aXNpb25zLg0KDQoNCj4g
SSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZmluaXNoIHRoZSBOTURBIHdvcmsgdGhhdCB3ZSBoYXZl
IHN0YXJ0ZWQgKGFuZCANCj4gYXJlIGNsb3NlIHRvIGZpbmlzaGluZyksIGVuc3VyaW5nIHRoYXQg
dGhlIFlBTkcgbGlicmFyeSBzdHJ1Y3R1cmUgdGhhdCANCj4gd2UgY2hvb3NlIGlzbid0IG9idmlv
dXNseSB3cm9uZyBmb3Igd2hhdCB3ZSB3YW50IHRvIGRvIGluIHRoZSBmdXR1cmUgKGl0IA0KPiBk
b2Vzbid0IGFwcGVhciB0byBiZSksIGJ1dCBub3QgbWFrZSB0aGUgc3RydWN0dXJlIG1vcmUgY29t
cGxleCB0aGFuIGl0IA0KPiBuZWVkcyB0byBiZSBqdXN0IHRvIHN1cHBvcnQgYSBwb3RlbnRpYWwg
ZnV0dXJlIHJlcXVpcmVtZW50IHRoYXQgbWF5IG9yIA0KPiBtYXkgbm90IHR1cm4gb3V0IHRvIGJl
IHZhbGlkLg0KDQpJIGRvbid0IHdhbnQgdG8gc29sdmUgc2VtLXZlciBub3cuICBNeSBvbmx5IGhv
cGUgdGhpcyB2ZXJzaW9uIGRvZXNuJ3QNCmJhY2sgdXMgaW50byBhIGNvcm5lci4gIFRob3VnaHRz
Pw0KDQpLZW50ICAvLyBjb250cmlidXRvcg0KDQoNCkp1c3QgbXkgdGhvdWdodHMsDQpSb2INCg0K
DQpPbiAyOS8xMS8yMDE3IDA4OjU3LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+IE1h
aGVzaCwNCj4NCj4gc28gZG8gSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0aGF0IGFsbCB0aGlzIGlz
IGFib3V0IHlhbmcgbGlicmFyeSBhbmQNCj4gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgTk1E
QSB1cGRhdGUgZm9yIFJDIGFuZCBOQz8gVGhpcyB3b3VsZA0KPiBhbHJlYWR5IGhlbHAgcmVkdWNp
bmcgbXkgbGV2ZWwgb2Ygc3VycHJpc2UuDQo+DQo+IENvbmNlcm5pbmcgbGljZW5zaW5nOiBBIGZ1
bmN0aW9uYWxpdHkgdGhhdCBkb2VzIG5vdCBleGlzdCBpbiB0aGUNCj4gc2VydmVyIGRvZXMgbm90
IGV4aXN0IGluIHRoZSBzZXJ2ZXIsIHdoYXRldmVyIHRoZSByZWFzb24gaXMuIEluIHRoZQ0KPiBm
dXR1cmUsIHRoZXJlIG1heSBiZSBhIHN0YW5kYXJkIFlBTkcgbW9kZWwgdGhhdCBhbGxvd3MgdG8g
Y29uZmlndXJlDQo+IChlbmFibGUvZGlzYWJsZSkgZnVuY3Rpb25hbGl0eSB3aXRoaW4gYSBtb2R1
bGFyIE5DL1JDIHNlcnZlci4gU28gZmFyLA0KPiBJIGhhdmUgbm90IHNlZW4gYSBwcm9wb3NhbCBm
b3IgdGhpcyBhbmQgaGVuY2UgSSBjb25zaWRlciB0aGlzIHRvcGljDQo+IG5vdCByZWFkeSBmb3Ig
YW55IFdHIGFjdGlvbi4NCj4NCj4gQ29uY2VybmluZyBtaXNzaW5nIGhhcmR3YXJlOiBUaGUgYXBw
cm9hY2ggb2YgdGhlIGludGVyZmFjZXMgbW9kZWwgaXMNCj4gdG8gc3VwcG9ydCBwcm92aXNpb25p
bmcgb2YgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gZm9yIG5vbi1leGlzdGluZw0KPiBpbnRlcmZh
Y2VzLiBIZW5jZSwgaWYgYSBzZXJ2ZXIgY2FuIGNvbmZpZ3VyZSBzYXkgQVRNIGxpbmUgY2FyZHMs
IHRoZW4NCj4gdGhlIHNlcnZlciBzaG91bGQgYW5ub3VuY2Ugc3VwcG9ydCBmb3IgdGhlIEFUTSBz
cGVjaWZpYyBZQU5HIG1vZHVsZXMNCj4gaW5kZXBlbmRlbnRseSBvZiB0aGUgcXVlc3Rpb24gd2hl
dGhlciBBVE0gbGluZSBjYXJkcyBhcmUgY3VycmVudGx5DQo+IHByZXNlbnQuIFRvIGZpbmQgb3V0
IHdoaWNoIGhhcmR3YXJlIGlzIHByZXNlbnQgYXQgYSBzcGVjaWZpYyBwb2ludCBpbg0KPiB0aW1l
LCBjb25zdWx0IHRoZSBpZXRmLWhhcmR3YXJlIG1vZGVsLiBJIGRvIG5vdCBzZWUgd2h5IGEgY2hh
bmdlIHRvDQo+IHlhbmcgbGlicmFyeSB3b3VsZCBiZSBuZWVkZWQgdG8gZGVhbCB3aXRoIG1pc3Np
bmcgaGFyZHdhcmUgbm9yIGRvIEkNCj4gcmVjYWxsIHdoYXQgdGhlIHByb3Bvc2VkIGVkaXRzIHdl
cmUuDQo+DQo+IFllcywgZnJvbSB0aGUgU05NUCB3b3JsZCBJIGtub3cgdGhhdCBzb21ldGltZXMg
c3VwcG9ydCBmb3Igc3BlY2lmaWMNCj4gbW9kdWxlcyBjb21lcyB3aXRoIHRoZSBmaXJtd2FyZSBv
ZiBhIHBpZWNlIG9mIGhhcmR3YXJlIGJ1dCB0aGUgTkMvUkMNCj4gZGVzaWduIG5ldmVyIHdlbnQg
aW50byB0aGUgZGV0YWlscyBvZiBtb2R1bGFyIHNlcnZlcnMgbGlrZSBTTk1QIGRpZA0KPiB3aXRo
IHN0YW5kYXJkcyBmb3Igc3ViYWdlbnQgdGVjaG5vbG9naWVzIGV0Yy4gSW4gdGhlIFlBTkcgd29y
bGQsIHRoaXMNCj4gaXMgYWxsIGVudGlyZWx5IGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCBm
cmFua2x5IEkgd291bGQgbm90IG9wZW4NCj4gdGhpcyBjYW4gb2Ygd29ybXMuIElmIHRoZSBwcmVz
ZW5jZSBvZiBzb21lIGhhcmR3YXJlIGVuYWJsZXMgc2VydmVyDQo+IGZ1bmN0aW9uYWxpdHkgKG9y
IGEgbGljZW5zZSB0aGF0IGlzIGluc3RhbGxlZCksIHRoZW4gdGhpcyBtYXkgbGVhZCB0bw0KPiBh
biB1cGRhdGUgb2YgdGhlIGNvbnRlbnQgb2YgdGhlIHlhbmcgbGlicmFyeSwgbGlrZSBhIHJlc3Rh
cnQgb2YgYQ0KPiBOQy9SQyBzZXJ2ZXIgbWF5IGRvLiBJIGRvIG5vdCBzZWUgd2hpY2ggdGVjaG5p
Y2FsIGNoYW5nZSB3b3VsZCBiZQ0KPiBuZWVkZWQuDQo+DQo+IFRoZSBib3R0b20gbGluZSBpcyB0
aGF0IHdpdGhvdXQgY29uY3JldGUgYWN0aW9uYWJsZSBwcm9wb3NhbHMsIHdlDQo+IHNob3VsZCBu
b3QgZGVsYXkgdGhlIGZpbmlzaGluZyBvZiBOTURBIHdvcmsuIEFuZCBhcyBBbmR5IHNheXMsIHRo
aW5ncw0KPiB0aGF0IGNhbiBiZSBkb25lIHdpdGggYXVnbWVudGF0aW9ucyBhcmUgZ29vZCB0byBk
byB3aXRoIGF1Z21lbnRhdGlvbnMuDQo+DQo+IC9qcw0KPg0KPiBPbiBUdWUsIE5vdiAyOCwgMjAx
NyBhdCAxMTowMjo1NUFNIC0wODAwLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KPj4+IE9u
IE5vdiAyOCwgMjAxNywgYXQgNToxNyBBTSwgSGVuayBCaXJraG9seiA8aGVuay5iaXJraG9sekBz
aXQuZnJhdW5ob2Zlci5kZT4gd3JvdGU6DQo+Pj4NCj4+PiBUaGlzIHNlZW1zIHRvIGJlIGFuIHVu
bmVjZXNzYXJ5IGphYiB0aGF0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGFjdHVhbCB0b3Bp
Y3MgcmFpc2VkIGJ5IE1haGVzaCwgd2hpY2ggd2VyZToNCj4+Pg0KPj4+IC0gWUFORyBMaWJyYXJ5
IHdpbGwgc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBsaWNlbnNpbmcgaW1wYWN0aW5nIHdoYXQgbW9k
ZWxzIGFyZSBhZHZlcnRpc2VkIGFuZCBzdXBwb3J0ZWQNCj4+IEkgZG8gbm90IHRoaW5rIHRoZSBt
aW51dGVzIGFyZSBnb2luZyB0byB0ZWxsIHlvdSBhbnltb3JlIGFib3V0IHRoZSByZXF1aXJlbWVu
dC4gU28gbGV0IG1lIHRha2UgYSBzdGFiIGF0IHdoYXQgSSB0aGluayB0aGUgcmVxdWlyZW1lbnQg
aXMuDQo+Pg0KPj4gWUFORyBMaWJyYXJ5IGN1cnJlbnRseSBjb21waWxlcyBhIGxpc3Qgb2YgbW9k
dWxlcyAoYW5kIHN1Yi1tb2R1bGVzKSB0aGF0IGFyZSBzdXBwb3J0ZWQgYnkgdGhlIGRldmljZS4g
VGhlIHNhbWUgZGV2aWNlIG1pZ2h0IGFsc28gc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBsaWNlbnNp
bmcsIHdoZXJlIHRoZSBsaWNlbnNlIGNvbnRyb2xzIHdoZXRoZXIgdGhlIGZlYXR1cmUgY2FuIGJl
IGVuYWJsZWQgb24gdGhlIGRldmljZSwgZS5nLiBCR1AuIFRoZSBzZXJ2ZXIgaGFzIHRoZSBhYmls
aXR5IHRvIHN1cHBvcnQgQkdQIGFzIGEgZmVhdHVyZSAodGhlIHNvZnR3YXJlIGV4aXN0cyksIGJ1
dCB0aGUgY3VzdG9tZXIgaGFzIG5vdCBib3VnaHQgYSBsaWNlbnNlIGZvciB0aGUgQkdQIGZlYXR1
cmUuIFdoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG8gdW5kZXIgdGhlIGNpcmN1bXN0YW5jZXM/IFNo
b3VsZCBpdCBhZHZlcnRpc2UgQkdQIG1vZHVsZSwgYW5kIGhhdmUgdGhlIHJlcXVlc3QgZnJvbSB0
aGUgY2xpZW50IGZhaWw/IE9yIHNob3VsZCB0aGVyZSBhbm90aGVyIGZsYWcsIGVpdGhlciBpbiB0
aGUgWUFORyBMaWJyYXJ5IG9yIHNvbWUgb3RoZXIgbW9kdWxlIHRoYXQgaW5mb3JtcyB0aGUgY2xp
ZW50IHRoYXQgYWx0aG91Z2ggdGhlIGRldmljZSBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgQkdQ
LCBpdCBjYW5ub3QgYmVjYXVzZSBpdCBsYWNrcyB0aGUgbGljZW5zZS4NCj4+DQo+PiBBIHNpbWls
YXIgc2NlbmFyaW8gZXhpc3RzIHdpdGggWUFORyBtb2R1bGVzIHRoYXQgc3VwcG9ydCBhIHBhcnRp
Y3VsYXIgbGluZSBjYXJkLCBhbmQgdGhhdCBsaW5lIGNhcmQgaXMgaG90IHBsdWdnYWJsZS4gV2hh
dCBzaG91bGQgdGhlIFlBTkcgbGlicmFyeSBkbyBmb3IgbW9kdWxlcyB0aGF0IGl0IGFkdmVydGlz
ZXMsIGJ1dCB0aGUgbGluZSBjYXJkIGZvciB0aGF0IG1vZHVsZSBtYXkgb3IgbWF5IG5vdCBleGlz
dCBpbiB0aGUgc3lzdGVtPw0KPj4NCj4+PiAtIHNlbWFudGljIHZlcnNpb25pbmcgc2hvdWxkIGJl
IHBhcnQgb2YgdGhlIFlBTkcgTGlicmFyeQ0KPj4gVGhlIHJlcXVpcmVtZW50IGhlcmUgaXMgd2hl
dGhlciBzZW1hbnRpYyB2ZXJzaW9uaW5nIGNhbiBiZSBzdXBwb3J0ZWQgaW4gdGhlIFlBTkcgbGli
cmFyeSBpbiBhZGRpdGlvbiB0byB0aGUgY3VycmVudCB2ZXJzaW9uLCB3aGljaCBpcyBhIGRhdGUu
IERldGFpbHMgb24gaG93IGl0IHJlbGF0ZXMgdG8gWUFORyBMaWJyYXJ5IHNob3VsZCBiZSBicm91
Z2h0IHVwIG9uIHRoZSBsaXN0LCBwcmVmZXJhYmx5IG9uIGEgbmV3IHRocmVhZC4NCj4+DQo+Pj4g
V2hpY2gsIGJ0dywgSSBhbHNvIGFtIG5vdCBzdXJlIGFib3V0IGhvdyBhbmQgd2hlcmUgdGhhdCBj
YW1lIHVwIGFuZCB3aGF0IGl0IG1lYW5zLiBJbiBjb25zZXF1ZW5jZSAtIGFzIErDvHJnZW4gLSBJ
IGFtIGN1cmlvdXMgdG8gc2VlIHRoZSBtaW51dGVzLg0KPj4gVGhhbmtzIHRvIFJvYmVydCBmb3Ig
dXBkYXRpbmcgdGhlIHJvdWdoIG1pbnV0ZXMuIElmIGFueW9uZSBkaXNhZ3JlZXMgd2l0aCB3aGF0
IGlzIHJlY29yZGVkIGluIHRoZSByb3VnaCBub3RlcywgcGxlYXNlIGxpc3RlbiB0byB0aGUgcmVj
b3JkaW5nIGhlcmUgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0zQV9fd3d3LmlldGYub3JnX2F1ZGlvX2lldGYxMDBfJmQ9RHdJR2FRJmM9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3
WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1mZER4QjA2X0JtcFN0QUtWSnNqaS1Ka3R6Y1oteDM4
dXI1WllqVGRjeVFnJnM9ZHZFUnowTm1mZnpEYlM1bkl6MzFVXzNtSl9wSGRORk9seUJPVE1MTnU1
dyZlPT4gYW5kIHVwZGF0ZSB0aGUgcm91Z2ggbm90ZXMuIFRoZXkgd2lsbCBiZSBwdWJsaXNoZWQg
YXMgb2ZmaWNpYWwgbWludXRlcy4NCj4+DQo+PiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+PiBtamV0
aGFuYW5kYW5pQGdtYWlsLmNvbQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPj4gTmV0Y29uZkBp
ZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmQ9RHdJR2FRJmM9
SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZa
R0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1mZER4QjA2X0JtcFN0QUtWSnNqaS1K
a3R6Y1oteDM4dXI1WllqVGRjeVFnJnM9U21ZT2FkNzM2UEJDTjNWSTVZeE1GMEJIQjdKZkl5LXFJ
azdrU1U0T1BzcyZlPQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29uZiZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2Ni
ZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJm09ZmREeEIwNl9CbXBTdEFLVkpzamktSmt0emNaLXgzOHVyNVpZalRk
Y3lRZyZzPVNtWU9hZDczNlBCQ04zVkk1WXhNRjBCSEI3SmZJeS1xSWs3a1NVNE9Qc3MmZT0NCg0K
DQo=


From nobody Wed Nov 29 09:37:38 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574CD12896F for ; Wed, 29 Nov 2017 09:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xRQtzXOTPO1 for ; Wed, 29 Nov 2017 09:37:28 -0800 (PST)
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 6F613120726 for ; Wed, 29 Nov 2017 09:37:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31772; q=dns/txt; s=iport; t=1511977048; x=1513186648; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wDQCAEsGULv8dOgjU774gIa40uSvWSwAkW100+TPyYk=; b=HPYQMDolT+IGk+TBmK5U9jtleBFHSXFSH8QQwgDceOOwA9EN1VEfdNjh yUdZHfRb3zyB1lKHAm5jtyjJ2zDBhqwaZKR9sQlVECVS4Zlu2r/MG8BUT DtI1kjR8wFIur2mUS9gDJ/1WN6SM4e7q+FG7mvDLOsmru4G8FiIluJCEL E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAgAc7x5a/4YNJK1SAQkaAQEBAQECA?= =?us-ascii?q?QEBAQgBAQEBgzxmbicHnQiBfX6QJ4VPEIF+AwoYC4RJTwKFFEEWAQEBAQEBAQE?= =?us-ascii?q?BayiFHwEBAQECAQEBGCA0EAsCAQgOBxARECcLJQIEARACCBOJfwgQqV6EFgGGU?= =?us-ascii?q?AEBAQEBAQEDAQEBAQEBAQEBAR6DQYIJgVaBaYIdWDaCJYJEDAESAQGGDgWKM4d?= =?us-ascii?q?GgXKFP4kjAodygWiCAokngh9jhSyEB4clijmCQIkcAhEZAYE5ASYHK4FRbxUWJ?= =?us-ascii?q?IIpCYJJHIEsATpFMocwgTOBFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,338,1508803200"; d="scan'208";a="37480174"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Nov 2017 17:37:27 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vATHbQmi025325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Nov 2017 17:37:27 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 12:37:25 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 12:37:25 -0500
From: "Eric Voit (evoit)" 
To: Martin Bjorklund , "netconf@ietf.org" ,  "Balazs Lengyel  (balazs.lengyel@ericsson.com)" , "Andy Bierman (andy@yumaworks.com)" 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6Mpyuqg
Date: Wed, 29 Nov 2017 17:37:25 +0000
Message-ID: <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>
In-Reply-To: <20171128.103735.1654378548309425095.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 17:37:33 -0000

Hi Martin,

Thanks for the comments.   Many thoughts in-line...

> From: Martin Bjorklund, November 28, 2017 4:38 AM
>=20
> Hi,
>=20
>=20
> I have now reviewed draft-ietf-netconf-yang-push-11.  I have one somewhat
> more important comment, and several others.
>=20
> Important issue:
>=20
> o  3.10
>=20
>   I don't think the proposed YANG extension is the correct solution to
>   the stated problem, for several reasons:

In general we agree there are several alternatives to solve this issue.  An=
d any mechanism supported by the WG would be fine.  =20

My read of your proposal below is that it does reuse elements of 3.10.  For=
 example, I *think* you are proposing hierarchical inheritance of on-change=
 property markings of the parent rather than making every instance.  Becaus=
e marking every instance within a routing table would be prohibitively expe=
nsive.  So based on whatever commonality we can establish across the propos=
ed alternatives, perhaps we can come to a common way to set this informatio=
n.    If not, we can back out on-change marking as something implementation=
-specific for this current specification.

Stepping back a minute, it is good to think about who would use this on-cha=
nge support data.  Application developers are going to make subscription re=
quests.  And they are far more likely to want to design based on the schema=
 level information exposed rather than instance data.   Driven by that cons=
traint, the current proposal is framed as is -- mostly since there was no i=
nterest in Balazs'
https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00  =20
which was designed to support application developers needing this informati=
on.   Without this draft, at the time this was proposed the next-best thing=
 was an extension which works based on the established pattern of deviation=
s.  =20

To cover this issue, I have re-opened YP#10 to track and resolve...
https://github.com/netconf-wg/yang-push/issues/10=20

Below are some specific pros/cons I see...

>     1.  In most cases, this is not a property of the data model, but
>         of the implementation, and possibly even the deployment.  So
>         having a YANG extension statement is not a good solution.

Fully agree this can be implementation level issue.  But then again, so is =
any deviation. =20

So to cover "property of the implementation" case, the proposed extension w=
ould typically be included in deviations file per implementation.  Such an =
approach does mirror existing mechanisms for deviations, and has the benefi=
t of not requiring another a new totally separate file to document the desi=
red behavior. =20

As for times this might be deployment specific, we saw potential capacity i=
ssues determining whether something might not be on-change subscribable.   =
Here it would be up to the implementation to determine whether to use the e=
rror "on-change-unsupported" from YANG Push, or the error "insufficient-res=
ources" from subscribed notifications.  A choice between the two can be dri=
ven based on whether a deployment would *ever* have capacity for the reques=
ted subscription.

>     2.  With NDMA, the same schema node is present in different
>         datastores.  It might be the case that an implementation
>         supports on-change for the node in a configuration datastore,
>         but not in operational.  Again, marking a node in the schema
>         is not a good solution.

As the current solution was developed before NMDA, we didn't consider diffe=
rences in on-change support for different datastores.  So this is a real co=
nsideration.

If for a minute we assume we are going to follow the current approach in th=
e draft, the extension proposed in 3.10 could have a default of the operati=
onal datastore.  And we could add the option of including a list of datasto=
res in the extension whenever on-change for something else is needed/suppor=
ted..

>     3.  Since the on-change property is implementation dependent, it
>         means the information will be available to clients only in
>         deviation modules.  This is quite an expensive and complicated
>         way to pass the information to the clients.

Visibility to application developers was one reason we went down this path.=
   Any solution needs to frame this visibility as a key element.   Consider=
ing this, I actually see a need both for the schema based solution as frame=
d, and the possibility of an instance based mechanism if someone wanted the=
 lower level of granularity.  Per above, I don't think instance data within=
 all instance objects like routing entries is possible anyplace datastore s=
ize becomes a factor.

>   An alternative solution could be to have an ordered list of
>   instance-identifiers that list this property, per datastore, for
>   example:
>=20
>    
>      /sys:system/sys:system-time
>      false
>    
>    
>      /sys:system
>      true
>    

This could work.   Several questions which would need to be addressed with =
this approach:

(1) how would application developers easily know what objects are on-change=
 subscribable?

(2) If this is per-instance, is the property inherited from a parent?   If =
no, how do we deal with the size of the resulting information?

(3) If this is per-instance, how is this information populated?  Don't you =
need schema level guidance recorded somewhere anyway?

(4) Are there any issues with things like Schema mount?

>   Yet another alternative would be to leave this to future work.

If necessary, we can push this out.   I am hoping we can come up with somet=
hing here, especially as the on-chance implementations I have seen have all=
 used phased introduction of on-change for different schema objects.  =20

> Other comments:
>=20
>=20
> o  2
>=20
>   The document uses the term "YANG datastore" (it is even in the title
>   of the document).  This term is not used elsewhere, and it is not
>   defined in this document.  I suggest you change this to simply
>   "datastore".

In general, I am fine with making the change to "Datastore" throughout the =
document.  For the title, I think it better to keep YANG to allow casual re=
aders easy access to the context.

>   Also, I think you should "import" the term "datastore" from
>   draft-ietf-netmod-revised-datastores, instead of having a slightly
>   different term in this document.

Can do.

>   It is also unfortunate that you use the term "data node" in a
>   different meaning than RFC 7950.  Maybe use "datastore node"
>   instead?

Can do.
=20
>=20
> o  3.1
>=20
>   I'm not sure I understand the dampening period concept.  Let's
>   assume that the dampening period is 10s.  Then changes happen at
>   times:
>=20
>     2  3  4  11  13  14  15
>=20
>   From the description, it seems I would receive 4 notifications, from
>   times:
>=20
>     2  (containing only change from 2)
>     12 (containing change from 3,4,11)
>     13 (containing only change from 13)
>     23 (containing changes from 14,15)

Should be 2, 12, & 22.   I have updated the definition (below) in a way whi=
ch hopefully clarifies the proper behavior

         +  Dampening period: In an on-change subscription, detected object=
 changes should be sent as quickly as possible.  However without adequate p=
rotections, a rapid series of object changes might exhaust of resources in =
the publisher or receiver.  In order to protect against that, a dampening p=
eriod MAY be used to specify the interval which must pass before successive=
 update records for the same subscription are generated for a receiver.  Th=
e dampening period collectively applies to the set of all data nodes select=
ed by a single subscription and sent to a single receiver.  This means that=
 when there is a change to a subscribed object, an update record containing=
 that object is created either immediately when no dampening period is in e=
ffect, or at the end of a dampening period.  A dampening period is reset ev=
ery time a new notification message is passed to transport.
=20
>   Is this correct?
>=20
>   In any case, I suggest the description in the YANG module is
>   clarified - currently the RFC text contains more details than the
>   YANG module.

I have updated the YANG module text as:

"Specifies the interval which must pass before successive update records fo=
r the same subscription are generated for a receiver.  The dampening period=
 collectively applies to the set of all data nodes selected by a single sub=
scription and sent to a single receiver.  This means that when there is a c=
hange to a subscribed object, an update record containing that object is cr=
eated either immediately when no dampening period is in effect, or at the e=
nd of a dampening period.  A dampening period is reset every time a new not=
ification message is passed to transport.  A dampening period is reset ever=
y time a new notification message is passed to transport.  A zero value ind=
icates no dampening period, and all subscribed object changes are sent imme=
diately."

> o  3.2
>=20
>   The text says:
>=20
>      Therefore, in order to minimize the number of subscription
>      iterations between subscriber and publisher, dynamic
>      subscriptions SHOULD support a simple negotiation between
>      subscribers and publishers for subscription parameters.
>=20
>   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
>   specified in this draft does indeed support simple "negotiation".
>   Maybe s/SHOULD support/supports/ ?

Yes.  Will remove the SHOULD, showing just "supports".

> o  3.4
>=20
>   The text says:
>=20
>     Please see [promise] for
>     more on the transactional basis underlying the publisher and
>     subscriber interactions within this document.
>=20
>   So I did that.  But I didn't find any text in the referenced
>   document that talked about "the transactional basis".
>=20
>   I suggest you remove this sentence from the draft.

As this is informative, I can remove. =20

> o  3.5
>=20
>   The text says:
>=20
>      A publisher MUST support XML encoding and MAY support other
>      encodings such as JSON encoding.
>=20
>   I don't think this is correct.  A RESTCONF sever is not required to
>   support XML.  I think you should remove this sentence.

ok

> o  3.5.1
>=20
>      In a periodic subscription, the data included as part of an update
>      corresponds to data that could have been simply retrieved using a ge=
t
>      operation and is encoded in the same way.
>=20
>   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
>    or something else?  Whatabout other protocols?

As YANG Push is intended to be transport independent, it is better not to p=
rovide a specific transport.   Instead, how about the following text:

In a periodic subscription, the update record MUST include the datastore no=
des which would have been retrieved using an equivalent datastore selection=
 operation over that subscription's transport.=20
=20
>   (In 3.6, you use simply "a GET" for probably the same thing.)

If you are good with the text above, I will change 3.6 to:

" to what is available with a datastore selection operations".

> o  3.6
>=20
>      Subscription policy specifies both the selection filters and the
>      datastores against which these selection filters will be applied.
>      The result is the push of information necessary to remotely maintain
>      an extract of the publisher's datastore.
>
>   It seems this paragraph defines the term "Subscription policy".  But
>   this term is not used in the document.=20

We don't intend to define a new term in this paragraph.  And you are correc=
t, policy only appears elsewhere in the document as part of the YANG model =
group names.    (more below)

>  What does it means that the  result of a policy is "the push of informat=
ion"?
>=20
>   I think I don't understand what this paragraph tries to tell me.

What if I changes the first paragraph of Section 3.6 to:

An objective of YANG push is to allow the replication of a subset of a publ=
isher's datastore within a receiver.  The datastore selection filter define=
s this subset.  Only a single selection filter can be applied to a subscrip=
tion at a time.  The selection filter types defined in this include:

> o  3.6
>=20
>      o  xpath: An xpath selection filter is an XPath expression which may
>         be meaningfully applied to a datastore.
>=20
>    What does "meaningfully applied" mean?

There are plenty of valid xpath expressions which don't select data nodes. =
 How about:=20

" xpath: An xpath selection filter is an XPath expression which references =
data nodes. When applied to a datastore, it is the results of this expressi=
on which will be pushed."

> o  3.6
>=20
>      Selection filters are not intended to be used to filter objects
>      based on a non-key property.  Supporting non-key property
>      filtering so would have a number of implications that would
>      result in significant complexity.
>=20
>      [...]
>=20
>      the goal is to
>      provide equivalent capabilities to what is available with a GET.
>=20
>   In GET you can filter on "non-key properties".
>=20
>   I think you should remove the text about "non-key properties".  If
>   anything, I think you can allow an implementation to reject a filter
>   that would be too complex to implement / evaluate (in fact I think
>   the text already allows a server to reject such filters.)

The issue with non-key properties is how to deal with the creation and dele=
tion of objects when a non-key property goes in/out of the selection.   Oth=
ers were uncomfortable with things like passing along a patch showing a nod=
e was deleted, when in reality the property simply changed from meeting the=
 selection filter to failing the selection filter.  So people wanted to def=
ault to the simpler case of key properties for selection.

Based on that I can delete the words "but the goal is to provide equivalent=
 capabilities to what is available with a GET". =20

>   With the current text, is this filter ok:
>=20
>      /interfaces/interface[contains(name, "eth")]
>=20
>   It filters on a key, so it should be ok, right?

Yes

> o  3.7
>=20
>   The XML examples are not using the correct XML namespace for the
>   nodes from the "ietf-interface" module.
>=20
>   The YANG Patch example also shows an interesting effect in the
>   "patch-id" and "edit-id" leafs.  I think the draft should mention
>   how implementations are suppose to fill in these leafs.

Will add how to populate.  In summary, sequential numbering of "edit-id" wa=
s from the RFC-8072.   And a null "patch-id" is because patch-id is mandato=
ry in RFC-8072, and was originally supposed to be used for debugging of fai=
led datastore write operations.  That really isn't the case here, plus we h=
ave subscription-id and other object available.

>   The "target" leaf is not specified correctly.  It should be:
>=20
>          /ietf-interfaces:interfaces-state

Good catch.  Making change.

> o  3.8
>=20
>   The example has:
>=20
>            xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications=
"
>        xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">
>       
>         
>=20
>   This doesn't match the YANG model; there is no container called
>   "datastore" in the model.
>=20
>   Further is has:
>=20
>                      xmlns:ex=3D"http://example.com/sample-data/1.0"
>             select=3D"/ex:foo"/>
>=20
>   a subtree-filter of type xpath?  I think ot should be:
>=20
>         
>            /ex:foo
>         

Yes

>   Also, it has:
>=20
>         
>           operational
>         
>=20
>   which should be:
>=20
>         
>           ds:operational
>         

At the last IETF, Kent pointed us to YANG Lint which should allow us to do =
example checking in ways not previously known to us.    I will install and =
attempt to use these to clear the example items you have listed. =20

> o  3.9
>=20
>   This section lists three cases for which:
>=20
>      the error identity "data-unavailable" SHOULD be returned.
>=20
>   One of the cases is:
>=20
>     o  the authorization privileges of a receiver change over the course
>        of the subscription.
>=20
>   But how can a server know this when "establish-subscription" is sent?

It cannot know this at "establish-subscription".   So a publisher will have=
 to track whether the permissions on subscribed objects change.   How is le=
ft to implementations.

> o  3.9
>=20
>      The contextual authorization model for data in YANG datastores is
>      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
>=20
>   Did you mean s/contextual/conceptual/ ?

Will make that change.

> o  3.11.1
>=20
>=20
>   OLD:
>=20
>        If
>        this is not possible and the synch-on-start option is configured,
>=20
>   NEW:
>=20
>        If
>        this is not possible and the "no-synch-on-start" option is not
>        present for the subscription.
>=20
>=20
>   (fixes incorrect name of leaf, and also covers dynamic
>   subscriptions)

Yes, good catch.  Will fix.

> o  4.3.2
>=20
>      A subscription-id MUST be transported along with the subscribed
>      contents.
>=20
>   Then the leaf "subscription-id" should be mandatory.

The requirement is that a subscription-id must be in the notification messa=
ge, this doesn't mean that the subscription-id must be within the two new n=
otifications.   The reason for this is that when we add support for the not=
ification-messages draft, but having the subscription-id optional in the pu=
sh-update and push-change-update, we can enable implementations which do no=
t duplicate this header item.  (And a duplication would be forced with the =
future header if we made this mandatory.)

>      A "time-of-update" which represents the time an update record
>      snapshot was generated.  A receiver MAY assume that a publisher's
>      objects have these pushed values at this point in time.
>=20
>   Should "time-of-update" be mandatory?

Two reasons it is not:
(a) Other vendors have worried they can only support message-time, rather t=
han notification-time. =20
(b) Notification-time is the generalized name for "time-of-update" .  Havin=
g "time-of-update" as optional allows for eventual migration to common head=
ers of  draft-ietf-netconf-notification-messages without information duplic=
ation

>   How is "time-of-update" different from "eventTime" in the
>   notification?

I think that answer is above.  But there is some good guidance here from dr=
aft-ietf-netconf-notification-messages.  The new draft ultimately will defi=
ne and support the following times:

message-time:=20
      "Header information consisting of time the message headers were place=
d generated prior to being sent to transport";

notification-time
      "Header information consisting of the time an originating process cre=
ated the notification."

Notification-time should be equivalent to eventTime from RFC-5277.  But som=
e other vendors have said they really only have message-time, and this is w=
hat they are populating in eventTime even though it doesn't explicitly fit =
the definition.  With the new definitions, at least they should be able to =
populate what they explicitly have.

> o  4.3.2
>=20
>      If the application detects an informational discontinuity
>=20
>   What is an "informational discontinuity"?

Will change to:
  If the application detects any incompleteness in set of objects placed in=
to a "push-update" or "push-change-update"

> o  4.4.1 / 4.4.2
>=20
>   The XML examples are broken; compare with my comments for 3.8.

Will do.  I am hoping a new attempt using yanglint helps pick out everythin=
g I missed by hand previously.

> o  5
>=20
>   OLD:
>=20
>     "This module contains conceptual YANG specifications
>      for YANG push.";
>=20
>   NEW:
>=20
>     "This module contains YANG specifications for YANG push.";

ok

> o  5 - identities
>=20
>     identity qos-unsupported {
>       base sn:error;
>       description
>         "Subscription QoS parameters not supported on this platform.";
>     }
>=20
>   This identity is not mentioned anywhere in the text.  Instead of
>   having this identity, wouldn't it be better to define a feature for
>   "qos", and mark the nodes you have in mind with an if-feature?

It is possible to expose QoS explicitly as a feature.   I will make that ad=
dition if you are ok with my other QoS comment described below about subscr=
ibed-notifications.

But even in that case if QoS is not supported, and someone includes QoS obj=
ects in an "establish-subscription" we need this identity as an error.  Thi=
s error allow an explicit identification of what was wrong in the RPC (such=
 as a DSCP provided is not supported by the Publisher).  I will include thi=
s in the Identity description.

>     identity on-change-unsupported {
>       base sn:error;
>       description
>         "On-change not supported.";
>     }
>=20
>   When will this identity be used?  There is already a feature
>   "on-change" and corresponding if-feature statements.

Per our discussion above, this can be used if an RPC asks for on-change for=
 an object which is not available at a platform deployment (either marked i=
n the schema, or a specific deployment doesn't support an object which is i=
ncluded).   I will enhance the description based on the discussion on this =
earlier in this thread.
=20
>     identity on-change-synch-unsupported {
>       base sn:error;
>       description
>         "On-change synch-on-start and resynchonization not supported.";
>     }
>=20
>   The leaf is called "no-sync-on-start", which implies that sync on
>   start is the default.  So when will this identity be used?

Can be used in two places:

(1) Will be used if an RPC asks to synch on start, but it can't be supporte=
d for any reason (e.g., no nodes identifiable within the selection filter w=
ill ever be support on-change).   Will enhance the definition.

(2) The resynch RPC is invoked on a periodic subscription-id, or on an on-c=
hange subscription which can't support synchronization.

>     identity reference-mismatch {
>      base sn:error;
>       description
>        "Mismatch in filter key and referenced yang subtree.";
>     }
>=20
>   I don't understand the description of this identity.  Please
>   clarify.

Will clarify description to explain that the key provided with the filter d=
oes not match the data type of the referenced yang subtree

>      identity datatree-size {
>=20
>   Should it be "result-too-big" or something?

Yes.   I will change the name.

>     identity no-such-datastore {
>=20
>   I think this one should be removed.  The normal "invalid-value"
>   error-tag covers this error.
>=20
>=20
>       identity custom-datastore {
>         base ds:datastore;
>         description
>           "A datastore with boundaries not defined within
>            draft-ietf-netmod-revised-datastores";
>       }
>=20
>   This identity needs to be removed.  If someone defines a custom
>   datastore, it would get a specific identity, and that identity can
>   be used as "source".

Yes, any new custom datastore will get a new identity, but if that new iden=
tity uses this custom-datastore one as a base, then we have an umbrella ide=
ntity which is a handle just for the custom ones.  That was the intent of t=
his.   If you don't think that an identity which acts as a bundling mechani=
sm is useful, we can remove.

> o  5 - "change-type"
>=20
>   The descriptions of the enums need to be improved.  This is about
>   reporting a change in a datastore.  The value "create" is described
>   as:
>=20
>         description
>           "Create a new data resource if it does not already exist.  If
>           it already exists, replace.";
>=20
>   Also, the description of the typedef has:
>=20
>       "RFC 8072 section 2.5, with a delta that it is ok to receive
>       ability create on an existing node, or receive a delete on a
>       missing node.";
>=20
>   But what does this mean?  The type is used to *exclude* some changes
>   from a yang patch record.

This is to identify churn within a datastore during a dampening period.  Tw=
o examples of when this is needed:

(1) For security applications, it is an absolute requirement that you know =
if a node was added and then removed during a dampening period.   For an ex=
ample, a hacker adds a "permit any any" which is then quickly removed befor=
e the dampening period ends.  Remote applications need to know that churn o=
ccurred.

(2) For network management applications when a physical interface is going =
down and then quickly back up.   If the up/down is transient, how do you kn=
ow that this occurred if there is no notification that churn occurred?

To support this, the YANG patch definition is loosened to allow the new cre=
ation on an existing node (based on what resulted from the last patch), or =
a delete on a missing node.  This acts as an indication that some churn in =
the datastore happened even though the data is in the same state as a per t=
he previous update.  And if an application get to sees this indication when=
 comparing to the previous state, they have the option of looking more clos=
ely at some logs on the publisher to determine what actually happened.

I can see that this behavior is under-described in the text.   I will put a=
 small section between sections 3.10 & 3.11 describing this.  The title wil=
l be "Identification of a transient change within dampening period"

> o  5 - selection filter
>=20
>   The XPath expression is not properly defined.
>=20
>   OLD:
>=20
>           "This parameter contains an XPath expression identifying the
>           portions of the target datastore to retrieve.";
>=20
>   NEW:
>=20
>           "This parameter contains an XPath expression identifying the
>            portions of the target datastore to retrieve.
>=20
>            If the expression returns a node-set, all nodes in the
>            node-set are selected by the filter.  Otherwise, if the
>            expression does not return a node-set, the filter
>            doesn't select any nodes.
>=20
>            FIXME: (*)
>=20
>            The expression is evaluated in the following XPath context:
>=20
>              o  The set of namespace declarations are those in scope on
>                 the 'xpath-filter' leaf element.
>=20
>              o  The set of variable bindings is empty.
>=20
>              o  The function library is the core function library, and
>                 the XPath functions defined in section 10 in RFC 7950.
>=20
>              o  The context node is the root node of the target
>                 datastore.
>=20
>=20
>   (*) - We need to describe when the filter is evaluated.  This is
>   also true for the subtree filter.  Is it evaluated when the
>   subscription is started and explicitly modified, or everytime a
>   change is detected?
>=20
>   [Side note: this description is also missing from the "xpath-filter"
>   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
>   updated the description in that draft.]

I will update the descriptions to match your draft.

As for when the evaluation occurs, I am not sure what you mean.  Every time=
 a change occurs, you need to see if the changed object would have fallen w=
ithin the selection.  There is no attempt to support an event-condition-act=
ion context.

> o  5 - terminology
>=20
>   The term "agent" is used a couple of times.  Use "publisher" or
>   "server" instead.

Will update

> o  5 - dampening
>=20
>           leaf dampening-period {
>             type yang:timeticks;
>             mandatory true;
>=20
>    Should this instead be:
>=20
>           leaf dampening-period {
>             type yang:timeticks;
>             default "0";
>=20
>    So that the request is the same if the "on-change" feature is
>    support or not.

I like it, will update.

> o  5 - no-synch-on-start
>=20
>              When
>              present, pushing a full selection per the terms of the
>              selection filter MAY NOT be done for this subscription.
>=20
>    Did you mean s/MAY NOT/MUST NOT/ ?
>=20
>    MAY NOT is not a 2119 term.

Will change to MUST NOT.

> o  5 - QoS
>=20
>   Why are the qos parameters defined in yang push, and not in
>   subscribed notifications?  It seems that they are generic.

This question has come up before.  Basically current 5277 event streams hav=
en't shown need for QoS to date.   We know that QoS has been requested to h=
andle congestion issues for YANG push.  So for simplicities sake, we bundle=
d all QoS elements together in YANG push where we knew there was demonstrab=
le need.    If someone really is asking for these QoS constructs for events=
, we can revisit.

> o  5 - establish-subscription params
>=20
>   I think a "when" expression should be added to the first augment:
>=20
>     augment "/sn:establish-subscription/sn:input" {
>       when "sn:target/yp:datastore/yp:source";

So this is saying that the named datastore must exist before allowing the a=
ugment.   Works for me.

> o  5 - push-update
>=20
>   What does the presence of "updates-not-sent" mean in "push-update"?
>   "push-update" contains a snapshot, not a diff, so why is
>   "updates-not-sent" present?

This is to indicate a system error where not all objects can be extracted f=
rom the datastore.   (e.g., the routing table got *lots* bigger, and the pe=
riodic extract cannot be performed as expected.)  At least some implementat=
ions have seen this.   I will add some clarifying text.

> o  5 - push-change-update
>=20
>         "This contains an incremental set of datastore changes needed
>          to update a remote datastore starting at the time of the
>          previous update, per the terms of the subscription.
>=20
>    What is an "incremental set"?  Probably s/incremental set/set/

I can change to "set".

> o  General
>=20
>   Use double quotes for node names.  "push-update", "subscription-id"
>   etc.  Quotes are currently used inconsistently, and it makes the
>   text harder to read.

Will make the fix.

Thanks again for all the excellent thoughts!
Eric

>=20
> /martin
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Wed Nov 29 10:18:19 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD21128961 for ; Wed, 29 Nov 2017 10:18:18 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 DbGHFrIguUwd for ; Wed, 29 Nov 2017 10:18:16 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 49AC91288A9 for ; Wed, 29 Nov 2017 10:18:16 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id x204so4925277lfa.11 for ; Wed, 29 Nov 2017 10:18:16 -0800 (PST)
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=oHH8B4P4gf25c3ZMaa+gEOtX9sNgBYFZSFd2q+5qooU=; b=Ni8PCWJVxRAATYm2ECtf8DeWhu6kpNcSgtCYllmflHmyvIHDVLXvB1hAIth2RKhGqO k14jd2BOPxlMc0cO5NkIs3KfudGL4g5TvwpHm2rYTfp8b2qm2WfMoziuhC2V5ZhceEIr MuK48JTwJNZgmNkfGVQIerZUvCMxHO6+vBL3rMQRuj+YZfsAGr0q+YOVMisoqezwLwYw wGVp50Ix/kzspjmxxxm1A8vRRe0o1ldnqtMrLD15WRQWJ0tPUJ9STgcyzDiE+ssOaOSk rxl/mDxw9r3bxvoT4ZlRtiJ1RIaklobaSlKUrfuchr+/p+YwuJtxyW3XNYFInKiJa01v 87pw==
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=oHH8B4P4gf25c3ZMaa+gEOtX9sNgBYFZSFd2q+5qooU=; b=Wimk3+JjFBXStGbe4W0shYXoDfC9zSTcKzKVBP3wmeuIwB9mbCU/2Wl8OKAd+8MVVM SxRLXYYTzj9kVU2PTeDp3yTcLR57JPQUE/77+Al0Jvn8I+kSLJj2XUNzEv3tGMyvE8rI eGUMNlYlcqmGul4E2I3MgB9NSLou6fpDB2rtwo/tYnyWBbkW8z+mLzuXeNeMtEW38nQU +S8KzE+5w11k9rf0dSCImmqS8tzOxgjGgv04TCWGuC8L1EhGF1/dyICTCcQS/MWWh2My 5QBC57TfEe5TEQdwk/zoKxCdgjWNwTpHIYLOSkprrhCcIP3gQIykLWON8OsZU837P+J0 sGfg==
X-Gm-Message-State: AJaThX4OgLvFFyNBmJEvhGIXbLQS1ZjZkeg2Snjvjl4C21HsK1JiZswp hSWPBtCG86/uAeL7WQw9atRN1bOhNazUJv8Rq/Xzgw==
X-Google-Smtp-Source: AGs4zMaj533DlI3T6g6AIXUyrgysNzhl58VHBPboUE7qVcMrhsVqOHciC4hFAGZ4f2M5SS8ZUIJ+yK9qxPbs3eTfUKE=
X-Received: by 10.25.32.145 with SMTP id g139mr1556555lfg.2.1511979494497; Wed, 29 Nov 2017 10:18:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 29 Nov 2017 10:18:13 -0800 (PST)
In-Reply-To: <20171128.103735.1654378548309425095.mbj@tail-f.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 29 Nov 2017 10:18:13 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="001a11401ca8ad921c055f23286c"
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 18:18:18 -0000

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

On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund  wrote:

> Hi,
>
> ....
>
> o  3.1
>
>   I'm not sure I understand the dampening period concept.  Let's
>   assume that the dampening period is 10s.  Then changes happen at
>   times:
>
>     2  3  4  11  13  14  15
>
>   From the description, it seems I would receive 4 notifications, from
>   times:
>
>     2  (containing only change from 2)
>     12 (containing change from 3,4,11)
>     13 (containing only change from 13)
>     23 (containing changes from 14,15)
>
>   Is this correct?
>
>   In any case, I suggest the description in the YANG module is
>   clarified - currently the RFC text contains more details than the
>   YANG module.
>
>
>

Seems to me (from a client POV) that I want the dampening to apply
to the entire subscription, not to each node within the subscription.
I want "at most, 1 notification per second".  I don't see why I would want
to be told about an individual data node once per second.  I could still
get 10,000 events/sec but for different data nodes.  The receiver does not
really care whet nodes are being reported in each notification. The goal
is to simply limit the network and processor load.

>From a server POV, I do not want a timer on every data node instance
and complex code to construct the next on-change notification.

RMON handles dampening very differently.
The rising and falling thresholds are used to arm and re-arm an event
trigger.
The time between changes is not used at all to determine how many events to
send.
(Not suggesting all yang-push use-cases are threshold-based.)

IMO, the operator should put events that require low-latency into a
separate subscription,
and the dampening period should apply to the entire subscription.

 ...




/martin


Andy


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

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




On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Hi,


....



o=C2=A0 3.1



=C2=A0 I'm not sure I understand the dampening period concept.=C2=A0 Le=
t's

=C2=A0 assume that the dampening period is 10s.=C2=A0 Then changes happen a=
t

=C2=A0 times:



=C2=A0 =C2=A0 2=C2=A0 3=C2=A0 4=C2=A0 11=C2=A0 13=C2=A0 14=C2=A0 15



=C2=A0 From the description, it seems I would receive 4 notifications, from=


=C2=A0 times:



=C2=A0 =C2=A0 2=C2=A0 (containing only change from 2)

=C2=A0 =C2=A0 12 (containing change from 3,4,11)

=C2=A0 =C2=A0 13 (containing only change from 13)

=C2=A0 =C2=A0 23 (containing changes from 14,15)



=C2=A0 Is this correct?



=C2=A0 In any case, I suggest the description in the YANG module is

=C2=A0 clarified - currently the RFC text contains more details than the
=C2=A0 YANG module.






Seems to me (from a cli=
ent POV) that I want the dampening to apply
to the entire subscri=
ption, not to each node within the subscription.
I want "at =
most, 1 notification per second".=C2=A0 I don't see why I would wa=
nt
to be told about an individual data node once per second.=C2=
=A0 I could still
get 10,000 events/sec but for different data no=
des.=C2=A0 The receiver does not
really care whet nodes are being=
 reported in each notification. The goal
is to simply limit the n=
etwork and processor load.

From a server POV, I do=
 not want a timer on every data node instance
and complex code to=
 construct the next on-change notification.

RMON h=
andles dampening very differently.
The rising and falling thresho=
lds are used to arm and re-arm an event trigger.
The time between=
 changes is not used at all to determine how many events to send.
(Not suggesting all yang-push use-cases are threshold-based.)
IMO, the operator should put events that require low-latency i=
nto a separate subscription,
and the dampening period should appl=
y to the entire subscription.

=C2=A0...
=







/martin


Andy




_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--001a11401ca8ad921c055f23286c--


From nobody Wed Nov 29 11:32:27 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37766126C22 for ; Wed, 29 Nov 2017 11:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 ATN5KDTOo-go for ; Wed, 29 Nov 2017 11:32:24 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2831289B5 for ; Wed, 29 Nov 2017 11:32:23 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vATIxRLH005221; Wed, 29 Nov 2017 11:03:48 -0800
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=lLg8zD8JbwNseke07EZrQfTffYixt9sGgiOyPq+F4RQ=; b=EUT0YIIZffdlZhgY3jlC/p99OmylAiQzhrVOrBHbZ/StaOsOxK+zxrSyFj0jQ/5/Lv4p Z2sRheI/SeQ/JPASXnY/yt49bN4KGfXP7xUqTWV4YwlYn9nuqYOhN3AVV6jU+r1cNJ8u M7t7BrbBwAekipE1QXfpW13HEpNcFIIl+/SX/kkRhgkxqr5Y+nJZqwdIgOdnJoJUESn5 OeSInQ2kdr8smHPDFLXvSkQve+61pwUH7ePonkhfeafloJ5AVDjc9OPKYGIUOEz13dnE GxSOwyT98RJMMTLLlvvmPwFpY8LTJGxkYKACOFG2b/mt6cyKP5uBA5FWsuuC4p/54sv6 Kg== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0024.outbound.protection.outlook.com [216.32.180.24]) by mx0b-00273201.pphosted.com with ESMTP id 2ehu2691rt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Nov 2017 11:03:48 -0800
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Wed, 29 Nov 2017 19:03:46 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0282.004; Wed, 29 Nov 2017 19:03:46 +0000
From: Kent Watsen 
To: Andy Bierman , Martin Bjorklund 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCy7TIfDwUiuPkCpQA9CUh8ejqMrrHyA//+454A=
Date: Wed, 29 Nov 2017 19:03:46 +0000
Message-ID: <3FAD673D-BC72-4E57-9DD2-0D8DF199AFF4@juniper.net>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:vHUSft0Ob6uUeNk0Gfrn8Aix19dAa55tw5vizK0XH/1ZKinEuCdgH7CyGEBj1qpsp39Tb/uo8LNLTFeCtnWyiWfdEmGWHTJ7uGttAjzC2F6K61y+2kTFGcRH55qJBtkPVw6dLJ/vfz/Ifk3Gl1T5o5PCgPQarQjQ35pizGj4JeLC1g/d1jS50hSVJDMey0jVeWWWt/KEKsOK5NAG45CkCq9Rp6to4bB34wweV0nmkFqBPfZ454NBow7ydKnxWwF3f350hvrYhGmA73cPB2YrFMm/gskOoIfRMKOfzytDStwk7RyajQKVzjpwL8qapdI2lJPMIjShwOtba1P5iRAb+r/lKuqHdC9mkSkqy5UJWKE=; 5:QyClJ/M9pj4aaRanEsJAOp0OaXSysydG/UFfodBXcUS6fk7Um7bV8x1oUIySZxYLIyERV+Kt9X4CPOiAkNy8MDKmE8mjYn2Ab4jHWTPrRz9N66iPEizqYH+2tckrkrTOevzJNv4YHBWZzYjDhsPgtG7oVrX++6SSXo+tL3afcXE=; 24:IHX4cAAFoJv0qBYLNs/9XYfC2EMgGP2wbBkfA2wuONpLzZZRzJnZkMAw10IXe8nAqiUtP8UkDOJQstt+/7YrPImlmURJ1T1LpvLzrwt39DE=; 7:YBxbcS9LAcc3ZK+DqIqCVdAUbRJ0b+pu+Ttbexs/9ZxFC+NPcBSppXTMUzWRmqrj84/R1bRSo7X1VirMVEQG8pA70NTpJNcJOwgT9jC07AHvkcb7QrzB0sFWc6FIP4pZwHCrQ4M8vqldHBBV7I2bVv8JUVRwT2MRp767OWIyN/TwUGJgeVjoj/VzrB09ZKHy/3KugxgoC6G0VgDlIsVUXuHsAbPmzEWBVltCCRa227uILsKxadWm+GD4lDf1aia+
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: c500796a-4166-4dd4-11e4-08d5375beb00
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603274); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(227612066756510)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 05066DEDBB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(366004)(199003)(51444003)(189002)(86362001)(189998001)(82746002)(316002)(36756003)(66066001)(97736004)(77096006)(230783001)(83716003)(229853002)(6436002)(105586002)(6506006)(2906002)(2900100001)(6486002)(110136005)(58126008)(106356001)(3280700002)(54896002)(6306002)(7736002)(6116002)(8676002)(83506002)(33656002)(25786009)(3660700001)(9326002)(6512007)(53936002)(8936002)(3846002)(2950100002)(101416001)(4326008)(99286004)(14454004)(81166006)(81156014)(478600001)(5660300001)(102836003)(68736007)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Y868Ntpshzp/lz4iHKXUoyhDPXDe4Y49nlYZOdwuHT4JR5uN+EcxwgY3E0RF59k+o83UZEgqSwShvyrSnsMg+A==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3FAD673DBC724E579DD20D8DF199AFF4junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: c500796a-4166-4dd4-11e4-08d5375beb00
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 19:03:46.6526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-29_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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290245
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 19:32:26 -0000

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

SGkgQW5keSwNCg0KDQo+PiBvICAzLjENCj4+DQo+PiAgSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFu
ZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LiAgTGV0J3MNCj4+ICBhc3N1bWUgdGhhdCB0
aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMuICBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0DQo+PiAg
dGltZXM6DQo+Pg0KPj4gPFNOSVAvPg0KPj4NCj4NCj4gU2VlbXMgdG8gbWUgKGZyb20gYSBjbGll
bnQgUE9WKSB0aGF0IEkgd2FudCB0aGUgZGFtcGVuaW5nIHRvIGFwcGx5DQo+IHRvIHRoZSBlbnRp
cmUgc3Vic2NyaXB0aW9uLCBub3QgdG8gZWFjaCBub2RlIHdpdGhpbiB0aGUgc3Vic2NyaXB0aW9u
Lg0KPiBJIHdhbnQgImF0IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQiLiAgSSBkb24n
dCBzZWUgd2h5IEkgd291bGQgd2FudA0KPiB0byBiZSB0b2xkIGFib3V0IGFuIGluZGl2aWR1YWwg
ZGF0YSBub2RlIG9uY2UgcGVyIHNlY29uZC4gIEkgY291bGQgc3RpbGwNCj4gZ2V0IDEwLDAwMCBl
dmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEgbm9kZXMuICBUaGUgcmVjZWl2ZXIgZG9l
cyBub3QNCj4gcmVhbGx5IGNhcmUgd2hldCBub2RlcyBhcmUgYmVpbmcgcmVwb3J0ZWQgaW4gZWFj
aCBub3RpZmljYXRpb24uIFRoZSBnb2FsDQo+IGlzIHRvIHNpbXBseSBsaW1pdCB0aGUgbmV0d29y
ayBhbmQgcHJvY2Vzc29yIGxvYWQuDQo+DQo+IEZyb20gYSBzZXJ2ZXIgUE9WLCBJIGRvIG5vdCB3
YW50IGEgdGltZXIgb24gZXZlcnkgZGF0YSBub2RlIGluc3RhbmNlDQo+IGFuZCBjb21wbGV4IGNv
ZGUgdG8gY29uc3RydWN0IHRoZSBuZXh0IG9uLWNoYW5nZSBub3RpZmljYXRpb24uDQo+DQo+IFJN
T04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBkaWZmZXJlbnRseS4NCj4gVGhlIHJpc2luZyBhbmQg
ZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFuIGV2ZW50IHRy
aWdnZXIuDQo+IFRoZSB0aW1lIGJldHdlZW4gY2hhbmdlcyBpcyBub3QgdXNlZCBhdCBhbGwgdG8g
ZGV0ZXJtaW5lIGhvdyBtYW55IGV2ZW50cyB0byBzZW5kLg0KPiAoTm90IHN1Z2dlc3RpbmcgYWxs
IHlhbmctcHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4pDQo+DQo+IElNTywgdGhl
IG9wZXJhdG9yIHNob3VsZCBwdXQgZXZlbnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRv
IGEgc2VwYXJhdGUgc3Vic2NyaXB0aW9uLA0KPiBhbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qgc2hv
dWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLg0KDQoNCkkgdGhpbmsgdGhhdCB0
aGlzIGlzIGFscmVhZHkgdGhlIGNhc2UuICBBdCBsZWFzdCBTZWN0aW9uIDMuMSBzYXlzOg0KDQog
IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2Yg
YWxsIGRhdGENCiAgbm9kZXMgb2YgYSBzaW5nbGUgc3Vic2NyaXB0aW9uLg0KDQphbmQgU2VjdGlv
biAzLjMgc2F5czoNCg0KICAgSW4gY2FzZXMgd2hlcmUgYSBzdWJzY3JpYmVyIHdhbnRzIHRvIGhh
dmUgc2VwYXJhdGUgZGFtcGVuaW5nIHBlcmlvZHMNCiAgIGZvciBkaWZmZXJlbnQgb2JqZWN0cywg
bXVsdGlwbGUgc3Vic2NyaXB0aW9ucyB3aXRoIGRpZmZlcmVudCBvYmplY3RzDQogICBpbiBhIHNl
bGVjdGlvbiBmaWx0ZXIgY2FuIGJlIGNyZWF0ZWQuDQoNClRoYXQgc2FpZCwgdGhlIGRlc2NyaXB0
aW9uIHN0YXRlbWVudCBmb3IgImRhbXBlbmluZy1wZXJpb2QiIGNvdWxkIGJlDQppbXByb3ZlZDoN
Cg0KT0xEDQoNCiAgICAgIlRoZSBzaG9ydGVzdCB0aW1lIGR1cmF0aW9uIHdoaWNoIGlzIGFsbG93
ZWQgYmV0d2VlbiB0aGUNCiAgICAgICBjcmVhdGlvbiBvZiBpbmRlcGVuZGVudCB5YW5nIG9iamVj
dCB1cGRhdGUgbWVzc2FnZXMuDQogICAgICAgRWZmZWN0aXZlbHkgdGhpcyBpcyB0aGUgYW1vdW50
IG9mIHRpbWUgdGhhdCBuZWVkcyB0byBoYXZlDQogICAgICAgcGFzc2VkIHNpbmNlIHRoZSBsYXN0
IHVwZGF0ZS4gIFplcm8gaW5kaWNhdGVzIG5vIGRlbGF5LiI7DQoNCk5FVw0KDQogICAgICJUaGUg
c2hvcnRlc3QgdGltZSBkdXJhdGlvbiBhbGxvd2VkIGJldHdlZW4gdHdvIG9uLWNoYW5nZQ0KICAg
ICAgIHVwZGF0ZSBtZXNzYWdlcy4gICBFZmZlY3RpdmVseSB0aGlzIGlzIHRoZSBhbW91bnQgb2Yg
dGltZSB0aGF0DQogICAgICAgbmVlZHMgdG8gaGF2ZSBwYXNzZWQgc2luY2UgdGhlIGxhc3QgdXBk
YXRlLiAgWmVybywgdGhlIGRlZmF1bHQsDQogICAgICAgaW5kaWNhdGVzIG5vIGRlbGF5LiI7DQoN
Cg0KSy4gIC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQo=

--_000_3FAD673DBC724E579DD20D8DF199AFF4junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <00E253249E2D3049A19335DCA992423B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEFuZHks
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZndDsmZ3Q7IG8mbmJzcDsgMy4xPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBJ
J20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbmNlcHQuJm5i
c3A7IExldCdzPGJyPg0KJmd0OyZndDsmbmJzcDsgYXNzdW1lIHRoYXQgdGhlIGRhbXBlbmluZyBw
ZXJpb2QgaXMgMTBzLiZuYnNwOyBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0PGJyPg0KJmd0OyZndDsm
bmJzcDsgdGltZXM6PGJyPg0KJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZn
dDsgJmx0O1NOSVAvJmd0Ozxicj4NCiZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFNlZW1zIHRvIG1lIChmcm9tIGEg
Y2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBseTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyB0byB0aGUgZW50
aXJlIHN1YnNjcmlwdGlvbiwgbm90IHRvIGVhY2ggbm9kZSB3aXRoaW4gdGhlIHN1YnNjcmlwdGlv
bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn
dDsgSSB3YW50ICZxdW90O2F0IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQmcXVvdDsu
Jm5ic3A7IEkgZG9uJ3Qgc2VlIHdoeSBJIHdvdWxkIHdhbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgdG8gYmUgdG9sZCBhYm91dCBhbiBp
bmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuJm5ic3A7IEkgY291bGQgc3RpbGw8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg
Z2V0IDEwLDAwMCBldmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEgbm9kZXMuJm5ic3A7
IFRoZSByZWNlaXZlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyByZWFsbHkgY2FyZSB3aGV0IG5vZGVzIGFyZSBiZWluZyBy
ZXBvcnRlZCBpbiBlYWNoIG5vdGlmaWNhdGlvbi4gVGhlIGdvYWw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgaXMgdG8gc2ltcGx5IGxpbWl0
IHRoZSBuZXR3b3JrIGFuZCBwcm9jZXNzb3IgbG9hZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRnJvbSBhIHNlcnZlciBQT1Ys
IEkgZG8gbm90IHdhbnQgYSB0aW1lciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2U8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYW5kIGNv
bXBsZXggY29kZSB0byBjb25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbi48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZndDsgUk1PTiBoYW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5LjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGUgcmlzaW5n
IGFuZCBmYWxsaW5nIHRocmVzaG9sZHMgYXJlIHVzZWQgdG8gYXJtIGFuZCByZS1hcm0gYW4gZXZl
bnQgdHJpZ2dlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZndDsgVGhlIHRpbWUgYmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1c2VkIGF0IGFsbCB0
byBkZXRlcm1pbmUgaG93IG1hbnkgZXZlbnRzIHRvIHNlbmQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IChOb3Qgc3VnZ2VzdGluZyBhbGwg
eWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2VkLik8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSU1PLCB0aGUg
b3BlcmF0b3Igc2hvdWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5IGludG8g
YSBzZXBhcmF0ZSBzdWJzY3JpcHRpb24sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBzaG91bGQg
YXBwbHkgdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHRoaXMgaXMgYWxyZWFkeSB0aGUgY2FzZS4m
bmJzcDsgQXQgbGVhc3QgU2VjdGlvbiAzLjEgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBh
cHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyBub2RlcyBvZiBhIHNpbmdsZSBzdWJzY3JpcHRpb24uPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPmFuZCBTZWN0aW9uIDMuMyBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDsmbmJzcDsgSW4gY2FzZXMgd2hlcmUgYSBzdWJzY3JpYmVyIHdhbnRzIHRvIGhh
dmUgc2VwYXJhdGUgZGFtcGVuaW5nIHBlcmlvZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBmb3IgZGlmZmVyZW50IG9iamVjdHMsIG11bHRpcGxlIHN1
YnNjcmlwdGlvbnMgd2l0aCBkaWZmZXJlbnQgb2JqZWN0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGluIGEgc2VsZWN0aW9uIGZpbHRlciBjYW4gYmUg
Y3JlYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzYWlk
LCB0aGUgZGVzY3JpcHRpb24gc3RhdGVtZW50IGZvciAmcXVvdDtkYW1wZW5pbmctcGVyaW9kJnF1
b3Q7IGNvdWxkIGJlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmltcHJv
dmVkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBzaG9ydGVzdCB0aW1lIGR1cmF0aW9u
IHdoaWNoIGlzIGFsbG93ZWQgYmV0d2VlbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjcmVhdGlvbiBv
ZiBpbmRlcGVuZGVudCB5YW5nIG9iamVjdCB1cGRhdGUgbWVzc2FnZXMuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i
c3A7RWZmZWN0aXZlbHkgdGhpcyBpcyB0aGUgYW1vdW50IG9mIHRpbWUgdGhhdCBuZWVkcyB0byBo
YXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFzc2VkIHNpbmNlIHRoZSBsYXN0IHVwZGF0ZS4mbmJzcDsg
WmVybyBpbmRpY2F0ZXMgbm8gZGVsYXkuJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O
RVc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90
O1RoZSBzaG9ydGVzdCB0aW1lIGR1cmF0aW9uIGFsbG93ZWQgYmV0d2VlbiB0d28gb24tY2hhbmdl
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgdXBkYXRlIG1lc3NhZ2VzLiZuYnNwOyZuYnNwOyBFZmZlY3RpdmVs
eSB0aGlzIGlzIHRoZSBhbW91bnQgb2YgdGltZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7bmVlZHMg
dG8gaGF2ZSBwYXNzZWQgc2luY2UgdGhlIGxhc3QgdXBkYXRlLiZuYnNwOyBaZXJvLCB0aGUgZGVm
YXVsdCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0ZXMgbm8gZGVsYXkuJnF1b3Q7OzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPksuJm5ic3A7IC8vIGNvbnRyaWJ1dG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3FAD673DBC724E579DD20D8DF199AFF4junipernet_--


From nobody Wed Nov 29 12:04:12 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E726C128C84 for ; Wed, 29 Nov 2017 12:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P6BZoAEGFKG for ; Wed, 29 Nov 2017 12:04:04 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C3E1241F3 for ; Wed, 29 Nov 2017 12:04:04 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E21F980CD372D; Wed, 29 Nov 2017 20:03:59 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 20:04:01 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 12:03:56 -0800
From: Alexander Clemm 
To: "Eric Voit (evoit)" , Martin Bjorklund ,  "netconf@ietf.org" , "Balazs Lengyel  (balazs.lengyel@ericsson.com)" , "Andy Bierman (andy@yumaworks.com)" 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLZk3nYyMWGUek3uLlVrh0YqMsJzKA//+clGA=
Date: Wed, 29 Nov 2017 20:03:55 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF756@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com>
In-Reply-To: <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.194]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 20:04:10 -0000

Yes, thank you for the comments! =20

As the mail is long, rather than commenting inline, let me make just a few =
additional replies in addition to Eric's:

- On the topic of how to mark on-change notifiable YANG objects:

Yes, clearly what is on-change notifiable and what is not could differ by i=
mplementation.  We thought that asking implementors to define implementatio=
n-specific modules that would indicate the on-change notifiability through =
deviations would make sense, since this is really one of the function of de=
viations - indicate what is implementation-specific.  In that sense, the cu=
rrent solution does make sense to me and seems to be in the spirit of how i=
mplementation-specific YANG modules should be used. =20

That said, the other proposal to have a "meta-module" that contains a list =
of objects for which on-change notification is supported could be certainly=
 be an alternative.  However, the notifiability should be indicated per nod=
e at the schema level, not for each individual instance.  We would not want=
 to have to enumerate individual list entries, for example. Also, are there=
 additional considerations to accommodate schema-mount in that case? =20

Another thought, perhaps on-change notifiability is something that could in=
stead also be included in the YANG library.  Each module in the library wou=
ld then list the nodes for which on-change is notifiable on a given server.=
 =20

Deferring this until later might also an option.  I am sure there will be o=
ther annotations/markings for objects that we will come up with our time.  =
However, one issue is that by default we did not want to make assumptions a=
bout on-change notifiability being supported.  Rather, when it is supported=
, it would be specifically indicated; the default would be that it's not su=
pported.  If we defer the solution until later, then this won't work.  If w=
e wanted to defer, it would seem what we should do is still propose a solut=
ion informally in an appendix, and indicate that this may be later replaced=
 by another solution.  We would put the YANG extension into an own separate=
 module. =20

- on the Subscription Policy term (3.6).  Sure, we don't need to introduce =
a new term, but really what the parameters describe is in fact a policy.  W=
e could of course call them "datastore subscription specific configuration =
parameters", or "datastore subscription specific behavior configuration" , =
but this sounds a bit awkward to me. =20

- on the "no-such-datastore" eror tag:  true, invalid-value would cover thi=
s, but why be general when we can be specific?


--- Alex

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit
> (evoit)
> Sent: Wednesday, November 29, 2017 9:37 AM
> To: Martin Bjorklund ; netconf@ietf.org; Balazs Lengyel
>  (balazs.lengyel@ericsson.com)
> ; Andy Bierman (andy@yumaworks.com)
> 
> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
>=20
> Hi Martin,
>=20
> Thanks for the comments.   Many thoughts in-line...
>=20
> > From: Martin Bjorklund, November 28, 2017 4:38 AM
> >
> > Hi,
> >
> >
> > I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> > somewhat more important comment, and several others.
> >
> > Important issue:
> >
> > o  3.10
> >
> >   I don't think the proposed YANG extension is the correct solution to
> >   the stated problem, for several reasons:
>=20
> In general we agree there are several alternatives to solve this issue.  =
And
> any mechanism supported by the WG would be fine.
>=20
> My read of your proposal below is that it does reuse elements of 3.10.  F=
or
> example, I *think* you are proposing hierarchical inheritance of on-chang=
e
> property markings of the parent rather than making every instance.  Becau=
se
> marking every instance within a routing table would be prohibitively
> expensive.  So based on whatever commonality we can establish across the
> proposed alternatives, perhaps we can come to a common way to set this
> information.    If not, we can back out on-change marking as something
> implementation-specific for this current specification.
>=20
> Stepping back a minute, it is good to think about who would use this on-
> change support data.  Application developers are going to make subscripti=
on
> requests.  And they are far more likely to want to design based on the
> schema level information exposed rather than instance data.   Driven by t=
hat
> constraint, the current proposal is framed as is -- mostly since there wa=
s no
> interest in Balazs'
> https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
> which was designed to support application developers needing this
> information.   Without this draft, at the time this was proposed the next=
-best
> thing was an extension which works based on the established pattern of
> deviations.
>=20
> To cover this issue, I have re-opened YP#10 to track and resolve...
> https://github.com/netconf-wg/yang-push/issues/10
>=20
> Below are some specific pros/cons I see...
>=20
> >     1.  In most cases, this is not a property of the data model, but
> >         of the implementation, and possibly even the deployment.  So
> >         having a YANG extension statement is not a good solution.
>=20
> Fully agree this can be implementation level issue.  But then again, so i=
s any
> deviation.
>=20
> So to cover "property of the implementation" case, the proposed extension
> would typically be included in deviations file per implementation.  Such =
an
> approach does mirror existing mechanisms for deviations, and has the
> benefit of not requiring another a new totally separate file to document =
the
> desired behavior.
>=20
> As for times this might be deployment specific, we saw potential capacity
> issues determining whether something might not be on-change
> subscribable.   Here it would be up to the implementation to determine
> whether to use the error "on-change-unsupported" from YANG Push, or the
> error "insufficient-resources" from subscribed notifications.  A choice
> between the two can be driven based on whether a deployment would
> *ever* have capacity for the requested subscription.
>=20
> >     2.  With NDMA, the same schema node is present in different
> >         datastores.  It might be the case that an implementation
> >         supports on-change for the node in a configuration datastore,
> >         but not in operational.  Again, marking a node in the schema
> >         is not a good solution.
>=20
> As the current solution was developed before NMDA, we didn't consider
> differences in on-change support for different datastores.  So this is a =
real
> consideration.
>=20
> If for a minute we assume we are going to follow the current approach in =
the
> draft, the extension proposed in 3.10 could have a default of the operati=
onal
> datastore.  And we could add the option of including a list of datastores=
 in the
> extension whenever on-change for something else is needed/supported..
>=20
> >     3.  Since the on-change property is implementation dependent, it
> >         means the information will be available to clients only in
> >         deviation modules.  This is quite an expensive and complicated
> >         way to pass the information to the clients.
>=20
> Visibility to application developers was one reason we went down this pat=
h.
> Any solution needs to frame this visibility as a key element.   Consideri=
ng this,
> I actually see a need both for the schema based solution as framed, and t=
he
> possibility of an instance based mechanism if someone wanted the lower
> level of granularity.  Per above, I don't think instance data within all =
instance
> objects like routing entries is possible anyplace datastore size becomes =
a
> factor.
>=20
> >   An alternative solution could be to have an ordered list of
> >   instance-identifiers that list this property, per datastore, for
> >   example:
> >
> >    
> >      /sys:system/sys:system-time
> >      false
> >    
> >    
> >      /sys:system
> >      true
> >    
>=20
> This could work.   Several questions which would need to be addressed wit=
h
> this approach:
>=20
> (1) how would application developers easily know what objects are on-
> change subscribable?
>=20
> (2) If this is per-instance, is the property inherited from a parent?   I=
f no, how
> do we deal with the size of the resulting information?
>=20
> (3) If this is per-instance, how is this information populated?  Don't yo=
u need
> schema level guidance recorded somewhere anyway?
>=20
> (4) Are there any issues with things like Schema mount?
>=20
> >   Yet another alternative would be to leave this to future work.
>=20
> If necessary, we can push this out.   I am hoping we can come up with
> something here, especially as the on-chance implementations I have seen
> have all used phased introduction of on-change for different schema objec=
ts.
>=20
> > Other comments:
> >
> >
> > o  2
> >
> >   The document uses the term "YANG datastore" (it is even in the title
> >   of the document).  This term is not used elsewhere, and it is not
> >   defined in this document.  I suggest you change this to simply
> >   "datastore".
>=20
> In general, I am fine with making the change to "Datastore" throughout th=
e
> document.  For the title, I think it better to keep YANG to allow casual
> readers easy access to the context.
>=20
> >   Also, I think you should "import" the term "datastore" from
> >   draft-ietf-netmod-revised-datastores, instead of having a slightly
> >   different term in this document.
>=20
> Can do.
>=20
> >   It is also unfortunate that you use the term "data node" in a
> >   different meaning than RFC 7950.  Maybe use "datastore node"
> >   instead?
>=20
> Can do.
>=20
> >
> > o  3.1
> >
> >   I'm not sure I understand the dampening period concept.  Let's
> >   assume that the dampening period is 10s.  Then changes happen at
> >   times:
> >
> >     2  3  4  11  13  14  15
> >
> >   From the description, it seems I would receive 4 notifications, from
> >   times:
> >
> >     2  (containing only change from 2)
> >     12 (containing change from 3,4,11)
> >     13 (containing only change from 13)
> >     23 (containing changes from 14,15)
>=20
> Should be 2, 12, & 22.   I have updated the definition (below) in a way w=
hich
> hopefully clarifies the proper behavior
>=20
>          +  Dampening period: In an on-change subscription, detected obje=
ct
> changes should be sent as quickly as possible.  However without adequate
> protections, a rapid series of object changes might exhaust of resources =
in
> the publisher or receiver.  In order to protect against that, a dampening
> period MAY be used to specify the interval which must pass before
> successive update records for the same subscription are generated for a
> receiver.  The dampening period collectively applies to the set of all da=
ta
> nodes selected by a single subscription and sent to a single receiver.  T=
his
> means that when there is a change to a subscribed object, an update recor=
d
> containing that object is created either immediately when no dampening
> period is in effect, or at the end of a dampening period.  A dampening pe=
riod
> is reset every time a new notification message is passed to transport.
>=20
> >   Is this correct?
> >
> >   In any case, I suggest the description in the YANG module is
> >   clarified - currently the RFC text contains more details than the
> >   YANG module.
>=20
> I have updated the YANG module text as:
>=20
> "Specifies the interval which must pass before successive update records =
for
> the same subscription are generated for a receiver.  The dampening period
> collectively applies to the set of all data nodes selected by a single
> subscription and sent to a single receiver.  This means that when there i=
s a
> change to a subscribed object, an update record containing that object is
> created either immediately when no dampening period is in effect, or at t=
he
> end of a dampening period.  A dampening period is reset every time a new
> notification message is passed to transport.  A dampening period is reset
> every time a new notification message is passed to transport.  A zero val=
ue
> indicates no dampening period, and all subscribed object changes are sent
> immediately."
>=20
> > o  3.2
> >
> >   The text says:
> >
> >      Therefore, in order to minimize the number of subscription
> >      iterations between subscriber and publisher, dynamic
> >      subscriptions SHOULD support a simple negotiation between
> >      subscribers and publishers for subscription parameters.
> >
> >   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
> >   specified in this draft does indeed support simple "negotiation".
> >   Maybe s/SHOULD support/supports/ ?
>=20
> Yes.  Will remove the SHOULD, showing just "supports".
>=20
> > o  3.4
> >
> >   The text says:
> >
> >     Please see [promise] for
> >     more on the transactional basis underlying the publisher and
> >     subscriber interactions within this document.
> >
> >   So I did that.  But I didn't find any text in the referenced
> >   document that talked about "the transactional basis".
> >
> >   I suggest you remove this sentence from the draft.
>=20
> As this is informative, I can remove.
>=20
> > o  3.5
> >
> >   The text says:
> >
> >      A publisher MUST support XML encoding and MAY support other
> >      encodings such as JSON encoding.
> >
> >   I don't think this is correct.  A RESTCONF sever is not required to
> >   support XML.  I think you should remove this sentence.
>=20
> ok
>=20
> > o  3.5.1
> >
> >      In a periodic subscription, the data included as part of an update
> >      corresponds to data that could have been simply retrieved using a =
get
> >      operation and is encoded in the same way.
> >
> >   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
> >    or something else?  Whatabout other protocols?
>=20
> As YANG Push is intended to be transport independent, it is better not to
> provide a specific transport.   Instead, how about the following text:
>=20
> In a periodic subscription, the update record MUST include the datastore
> nodes which would have been retrieved using an equivalent datastore
> selection operation over that subscription's transport.
>=20
> >   (In 3.6, you use simply "a GET" for probably the same thing.)
>=20
> If you are good with the text above, I will change 3.6 to:
>=20
> " to what is available with a datastore selection operations".
>=20
> > o  3.6
> >
> >      Subscription policy specifies both the selection filters and the
> >      datastores against which these selection filters will be applied.
> >      The result is the push of information necessary to remotely mainta=
in
> >      an extract of the publisher's datastore.
> >
> >   It seems this paragraph defines the term "Subscription policy".  But
> >   this term is not used in the document.
>=20
> We don't intend to define a new term in this paragraph.  And you are corr=
ect,
> policy only appears elsewhere in the document as part of the YANG model
> group names.    (more below)
>=20
> >  What does it means that the  result of a policy is "the push of
> information"?
> >
> >   I think I don't understand what this paragraph tries to tell me.
>=20
> What if I changes the first paragraph of Section 3.6 to:
>=20
> An objective of YANG push is to allow the replication of a subset of a
> publisher's datastore within a receiver.  The datastore selection filter =
defines
> this subset.  Only a single selection filter can be applied to a subscrip=
tion at a
> time.  The selection filter types defined in this include:
>=20
> > o  3.6
> >
> >      o  xpath: An xpath selection filter is an XPath expression which m=
ay
> >         be meaningfully applied to a datastore.
> >
> >    What does "meaningfully applied" mean?
>=20
> There are plenty of valid xpath expressions which don't select data nodes=
.
> How about:
>=20
> " xpath: An xpath selection filter is an XPath expression which reference=
s
> data nodes. When applied to a datastore, it is the results of this expres=
sion
> which will be pushed."
>=20
> > o  3.6
> >
> >      Selection filters are not intended to be used to filter objects
> >      based on a non-key property.  Supporting non-key property
> >      filtering so would have a number of implications that would
> >      result in significant complexity.
> >
> >      [...]
> >
> >      the goal is to
> >      provide equivalent capabilities to what is available with a GET.
> >
> >   In GET you can filter on "non-key properties".
> >
> >   I think you should remove the text about "non-key properties".  If
> >   anything, I think you can allow an implementation to reject a filter
> >   that would be too complex to implement / evaluate (in fact I think
> >   the text already allows a server to reject such filters.)
>=20
> The issue with non-key properties is how to deal with the creation and
> deletion of objects when a non-key property goes in/out of the selection.
> Others were uncomfortable with things like passing along a patch showing =
a
> node was deleted, when in reality the property simply changed from
> meeting the selection filter to failing the selection filter.  So people =
wanted
> to default to the simpler case of key properties for selection.
>=20
> Based on that I can delete the words "but the goal is to provide equivale=
nt
> capabilities to what is available with a GET".
>=20
> >   With the current text, is this filter ok:
> >
> >      /interfaces/interface[contains(name, "eth")]
> >
> >   It filters on a key, so it should be ok, right?
>=20
> Yes
>=20
> > o  3.7
> >
> >   The XML examples are not using the correct XML namespace for the
> >   nodes from the "ietf-interface" module.
> >
> >   The YANG Patch example also shows an interesting effect in the
> >   "patch-id" and "edit-id" leafs.  I think the draft should mention
> >   how implementations are suppose to fill in these leafs.
>=20
> Will add how to populate.  In summary, sequential numbering of "edit-id"
> was from the RFC-8072.   And a null "patch-id" is because patch-id is
> mandatory in RFC-8072, and was originally supposed to be used for
> debugging of failed datastore write operations.  That really isn't the ca=
se
> here, plus we have subscription-id and other object available.
>=20
> >   The "target" leaf is not specified correctly.  It should be:
> >
> >          /ietf-interfaces:interfaces-state
>=20
> Good catch.  Making change.
>=20
> > o  3.8
> >
> >   The example has:
> >
> >     >        xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio=
ns"
> >        xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">
> >       
> >          > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-datastores">
> >
> >   This doesn't match the YANG model; there is no container called
> >   "datastore" in the model.
> >
> >   Further is has:
> >
> >          >             xmlns:ex=3D"http://example.com/sample-data/1.0"
> >             select=3D"/ex:foo"/>
> >
> >   a subtree-filter of type xpath?  I think ot should be:
> >
> >         
> >            /ex:foo
> >         
>=20
> Yes
>=20
> >   Also, it has:
> >
> >         
> >           operational
> >         
> >
> >   which should be:
> >
> >         
> >           ds:operational
> >         
>=20
> At the last IETF, Kent pointed us to YANG Lint which should allow us to d=
o
> example checking in ways not previously known to us.    I will install an=
d
> attempt to use these to clear the example items you have listed.
>=20
> > o  3.9
> >
> >   This section lists three cases for which:
> >
> >      the error identity "data-unavailable" SHOULD be returned.
> >
> >   One of the cases is:
> >
> >     o  the authorization privileges of a receiver change over the cours=
e
> >        of the subscription.
> >
> >   But how can a server know this when "establish-subscription" is sent?
>=20
> It cannot know this at "establish-subscription".   So a publisher will ha=
ve to
> track whether the permissions on subscribed objects change.   How is left=
 to
> implementations.
>=20
> > o  3.9
> >
> >      The contextual authorization model for data in YANG datastores is
> >      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
> >
> >   Did you mean s/contextual/conceptual/ ?
>=20
> Will make that change.
>=20
> > o  3.11.1
> >
> >
> >   OLD:
> >
> >        If
> >        this is not possible and the synch-on-start option is
> > configured,
> >
> >   NEW:
> >
> >        If
> >        this is not possible and the "no-synch-on-start" option is not
> >        present for the subscription.
> >
> >
> >   (fixes incorrect name of leaf, and also covers dynamic
> >   subscriptions)
>=20
> Yes, good catch.  Will fix.
>=20
> > o  4.3.2
> >
> >      A subscription-id MUST be transported along with the subscribed
> >      contents.
> >
> >   Then the leaf "subscription-id" should be mandatory.
>=20
> The requirement is that a subscription-id must be in the notification
> message, this doesn't mean that the subscription-id must be within the tw=
o
> new notifications.   The reason for this is that when we add support for =
the
> notification-messages draft, but having the subscription-id optional in t=
he
> push-update and push-change-update, we can enable implementations
> which do not duplicate this header item.  (And a duplication would be for=
ced
> with the future header if we made this mandatory.)
>=20
> >      A "time-of-update" which represents the time an update record
> >      snapshot was generated.  A receiver MAY assume that a publisher's
> >      objects have these pushed values at this point in time.
> >
> >   Should "time-of-update" be mandatory?
>=20
> Two reasons it is not:
> (a) Other vendors have worried they can only support message-time, rather
> than notification-time.
> (b) Notification-time is the generalized name for "time-of-update" .  Hav=
ing
> "time-of-update" as optional allows for eventual migration to common
> headers of  draft-ietf-netconf-notification-messages without information
> duplication
>=20
> >   How is "time-of-update" different from "eventTime" in the
> >   notification?
>=20
> I think that answer is above.  But there is some good guidance here from
> draft-ietf-netconf-notification-messages.  The new draft ultimately will
> define and support the following times:
>=20
> message-time:
>       "Header information consisting of time the message headers were pla=
ced
> generated prior to being sent to transport";
>=20
> notification-time
>       "Header information consisting of the time an originating process c=
reated
> the notification."
>=20
> Notification-time should be equivalent to eventTime from RFC-5277.  But
> some other vendors have said they really only have message-time, and this=
 is
> what they are populating in eventTime even though it doesn't explicitly f=
it
> the definition.  With the new definitions, at least they should be able t=
o
> populate what they explicitly have.
>=20
> > o  4.3.2
> >
> >      If the application detects an informational discontinuity
> >
> >   What is an "informational discontinuity"?
>=20
> Will change to:
>   If the application detects any incompleteness in set of objects placed =
into a
> "push-update" or "push-change-update"
>=20
> > o  4.4.1 / 4.4.2
> >
> >   The XML examples are broken; compare with my comments for 3.8.
>=20
> Will do.  I am hoping a new attempt using yanglint helps pick out everyth=
ing I
> missed by hand previously.
>=20
> > o  5
> >
> >   OLD:
> >
> >     "This module contains conceptual YANG specifications
> >      for YANG push.";
> >
> >   NEW:
> >
> >     "This module contains YANG specifications for YANG push.";
>=20
> ok
>=20
> > o  5 - identities
> >
> >     identity qos-unsupported {
> >       base sn:error;
> >       description
> >         "Subscription QoS parameters not supported on this platform.";
> >     }
> >
> >   This identity is not mentioned anywhere in the text.  Instead of
> >   having this identity, wouldn't it be better to define a feature for
> >   "qos", and mark the nodes you have in mind with an if-feature?
>=20
> It is possible to expose QoS explicitly as a feature.   I will make that =
addition if
> you are ok with my other QoS comment described below about subscribed-
> notifications.
>=20
> But even in that case if QoS is not supported, and someone includes QoS
> objects in an "establish-subscription" we need this identity as an error.=
  This
> error allow an explicit identification of what was wrong in the RPC (such=
 as a
> DSCP provided is not supported by the Publisher).  I will include this in=
 the
> Identity description.
>=20
> >     identity on-change-unsupported {
> >       base sn:error;
> >       description
> >         "On-change not supported.";
> >     }
> >
> >   When will this identity be used?  There is already a feature
> >   "on-change" and corresponding if-feature statements.
>=20
> Per our discussion above, this can be used if an RPC asks for on-change f=
or an
> object which is not available at a platform deployment (either marked in =
the
> schema, or a specific deployment doesn't support an object which is
> included).   I will enhance the description based on the discussion on th=
is
> earlier in this thread.
>=20
> >     identity on-change-synch-unsupported {
> >       base sn:error;
> >       description
> >         "On-change synch-on-start and resynchonization not supported.";
> >     }
> >
> >   The leaf is called "no-sync-on-start", which implies that sync on
> >   start is the default.  So when will this identity be used?
>=20
> Can be used in two places:
>=20
> (1) Will be used if an RPC asks to synch on start, but it can't be suppor=
ted for
> any reason (e.g., no nodes identifiable within the selection filter will =
ever be
> support on-change).   Will enhance the definition.
>=20
> (2) The resynch RPC is invoked on a periodic subscription-id, or on an on=
-
> change subscription which can't support synchronization.
>=20
> >     identity reference-mismatch {
> >      base sn:error;
> >       description
> >        "Mismatch in filter key and referenced yang subtree.";
> >     }
> >
> >   I don't understand the description of this identity.  Please
> >   clarify.
>=20
> Will clarify description to explain that the key provided with the filter=
 does
> not match the data type of the referenced yang subtree
>=20
> >      identity datatree-size {
> >
> >   Should it be "result-too-big" or something?
>=20
> Yes.   I will change the name.
>=20
> >     identity no-such-datastore {
> >
> >   I think this one should be removed.  The normal "invalid-value"
> >   error-tag covers this error.
> >
> >
> >       identity custom-datastore {
> >         base ds:datastore;
> >         description
> >           "A datastore with boundaries not defined within
> >            draft-ietf-netmod-revised-datastores";
> >       }
> >
> >   This identity needs to be removed.  If someone defines a custom
> >   datastore, it would get a specific identity, and that identity can
> >   be used as "source".
>=20
> Yes, any new custom datastore will get a new identity, but if that new
> identity uses this custom-datastore one as a base, then we have an umbrel=
la
> identity which is a handle just for the custom ones.  That was the intent=
 of
> this.   If you don't think that an identity which acts as a bundling mech=
anism is
> useful, we can remove.
>=20
> > o  5 - "change-type"
> >
> >   The descriptions of the enums need to be improved.  This is about
> >   reporting a change in a datastore.  The value "create" is described
> >   as:
> >
> >         description
> >           "Create a new data resource if it does not already exist.  If
> >           it already exists, replace.";
> >
> >   Also, the description of the typedef has:
> >
> >       "RFC 8072 section 2.5, with a delta that it is ok to receive
> >       ability create on an existing node, or receive a delete on a
> >       missing node.";
> >
> >   But what does this mean?  The type is used to *exclude* some changes
> >   from a yang patch record.
>=20
> This is to identify churn within a datastore during a dampening period.  =
Two
> examples of when this is needed:
>=20
> (1) For security applications, it is an absolute requirement that you kno=
w if a
> node was added and then removed during a dampening period.   For an
> example, a hacker adds a "permit any any" which is then quickly removed
> before the dampening period ends.  Remote applications need to know that
> churn occurred.
>=20
> (2) For network management applications when a physical interface is goin=
g
> down and then quickly back up.   If the up/down is transient, how do you
> know that this occurred if there is no notification that churn occurred?
>=20
> To support this, the YANG patch definition is loosened to allow the new
> creation on an existing node (based on what resulted from the last patch)=
, or
> a delete on a missing node.  This acts as an indication that some churn i=
n the
> datastore happened even though the data is in the same state as a per the
> previous update.  And if an application get to sees this indication when
> comparing to the previous state, they have the option of looking more
> closely at some logs on the publisher to determine what actually happened=
.
>=20
> I can see that this behavior is under-described in the text.   I will put=
 a small
> section between sections 3.10 & 3.11 describing this.  The title will be
> "Identification of a transient change within dampening period"
>=20
> > o  5 - selection filter
> >
> >   The XPath expression is not properly defined.
> >
> >   OLD:
> >
> >           "This parameter contains an XPath expression identifying the
> >           portions of the target datastore to retrieve.";
> >
> >   NEW:
> >
> >           "This parameter contains an XPath expression identifying the
> >            portions of the target datastore to retrieve.
> >
> >            If the expression returns a node-set, all nodes in the
> >            node-set are selected by the filter.  Otherwise, if the
> >            expression does not return a node-set, the filter
> >            doesn't select any nodes.
> >
> >            FIXME: (*)
> >
> >            The expression is evaluated in the following XPath context:
> >
> >              o  The set of namespace declarations are those in scope on
> >                 the 'xpath-filter' leaf element.
> >
> >              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 root node of the target
> >                 datastore.
> >
> >
> >   (*) - We need to describe when the filter is evaluated.  This is
> >   also true for the subtree filter.  Is it evaluated when the
> >   subscription is started and explicitly modified, or everytime a
> >   change is detected?
> >
> >   [Side note: this description is also missing from the "xpath-filter"
> >   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
> >   updated the description in that draft.]
>=20
> I will update the descriptions to match your draft.
>=20
> As for when the evaluation occurs, I am not sure what you mean.  Every ti=
me
> a change occurs, you need to see if the changed object would have fallen
> within the selection.  There is no attempt to support an event-condition-
> action context.
>=20
> > o  5 - terminology
> >
> >   The term "agent" is used a couple of times.  Use "publisher" or
> >   "server" instead.
>=20
> Will update
>=20
> > o  5 - dampening
> >
> >           leaf dampening-period {
> >             type yang:timeticks;
> >             mandatory true;
> >
> >    Should this instead be:
> >
> >           leaf dampening-period {
> >             type yang:timeticks;
> >             default "0";
> >
> >    So that the request is the same if the "on-change" feature is
> >    support or not.
>=20
> I like it, will update.
>=20
> > o  5 - no-synch-on-start
> >
> >              When
> >              present, pushing a full selection per the terms of the
> >              selection filter MAY NOT be done for this subscription.
> >
> >    Did you mean s/MAY NOT/MUST NOT/ ?
> >
> >    MAY NOT is not a 2119 term.
>=20
> Will change to MUST NOT.
>=20
> > o  5 - QoS
> >
> >   Why are the qos parameters defined in yang push, and not in
> >   subscribed notifications?  It seems that they are generic.
>=20
> This question has come up before.  Basically current 5277 event streams
> haven't shown need for QoS to date.   We know that QoS has been
> requested to handle congestion issues for YANG push.  So for simplicities
> sake, we bundled all QoS elements together in YANG push where we knew
> there was demonstrable need.    If someone really is asking for these QoS
> constructs for events, we can revisit.
>=20
> > o  5 - establish-subscription params
> >
> >   I think a "when" expression should be added to the first augment:
> >
> >     augment "/sn:establish-subscription/sn:input" {
> >       when "sn:target/yp:datastore/yp:source";
>=20
> So this is saying that the named datastore must exist before allowing the
> augment.   Works for me.
>=20
> > o  5 - push-update
> >
> >   What does the presence of "updates-not-sent" mean in "push-update"?
> >   "push-update" contains a snapshot, not a diff, so why is
> >   "updates-not-sent" present?
>=20
> This is to indicate a system error where not all objects can be extracted=
 from
> the datastore.   (e.g., the routing table got *lots* bigger, and the peri=
odic
> extract cannot be performed as expected.)  At least some implementations
> have seen this.   I will add some clarifying text.
>=20
> > o  5 - push-change-update
> >
> >         "This contains an incremental set of datastore changes needed
> >          to update a remote datastore starting at the time of the
> >          previous update, per the terms of the subscription.
> >
> >    What is an "incremental set"?  Probably s/incremental set/set/
>=20
> I can change to "set".
>=20
> > o  General
> >
> >   Use double quotes for node names.  "push-update", "subscription-id"
> >   etc.  Quotes are currently used inconsistently, and it makes the
> >   text harder to read.
>=20
> Will make the fix.
>=20
> Thanks again for all the excellent thoughts!
> Eric
>=20
> >
> > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Wed Nov 29 12:10:34 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAE128C9C for ; Wed, 29 Nov 2017 12:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOAgDtN7pN2J for ; Wed, 29 Nov 2017 12:10:30 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E0E126CF9 for ; Wed, 29 Nov 2017 12:10:29 -0800 (PST)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C5988973C2091 for ; Wed, 29 Nov 2017 20:10:25 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 20:10:27 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 12:10:20 -0800
From: Alexander Clemm 
To: Andy Bierman , Martin Bjorklund 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLZk3nYyMWGUek3uLlVrh0YqMqjXGAgAE9LSA=
Date: Wed, 29 Nov 2017 20:10:20 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF783@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.194]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF783sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 20:10:34 -0000

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

SWYgd2UgbGVhdmUgdGhpcyB0byBmdXR1cmUgd29yaywgb2ssIGJ1dCB3aGF0IGlzIHRoZSBkZWZh
dWx0IGJlaGF2aW9yIGluIHRoYXQgY2FzZT8NCg0KQ3VycmVudGx5OiBvbi1jaGFuZ2Ugbm90aWZp
YWJsZSBpcyBzdXBwb3J0ZWQgb25seSB3aGVuIHNwZWNpZmljYWxseSBkZXNpZ25hdGVkIGFzIHN1
Y2guDQoNCklmIHdlIGhhdmUgbm8gd2F5IHRvIGRlc2lnbmF0ZSBpdCwgd2UgY2FuIGNoYW5nZSBp
dCB0byBhc3N1bWUgaXQgaXMgc3VwcG9ydGVkLCBidXQgcmVqZWN0IG9uLWNoYW5nZSBzdWJzY3Jp
cHRpb25zIHRoYXQgY29udGFpbiBub24tbm90aWZpYWJsZSBvYmplY3RzLiAgQnV0IGhvdyBkb2Vz
IGEgc2VydmVyIGtub3cgd2hpY2ggb25lcyB0aGV5IGFyZT8gIFdlIGRvIG5vdCB3YW50IHRvIHNp
bGVudGx5IG5vdCBzZW5kIG9uLWNoYW5nZSB1cGRhdGVzLCB3aGVuIHRoZSBjbGllbnQgYXNzdW1l
cyB0aGF0IHdlIGRvLg0KDQpPbmUgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gbW92ZSB0aGUgY3Vy
cmVudCBzb2x1dGlvbiB0byB0aGUgYXBwZW5kaXgsIGRlZmluaW5nIHRoaXMgYXMgb25lIHNvbHV0
aW9uIGFwcHJvYWNoIChhbmQgZ2l2aW5nIHRoZSBZQU5HIG1vZHVsZSBmb3IgdGhhdCkuDQoNCi0t
LSBBbGV4DQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI4LCAy
MDE3IDk6MTEgQU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCkNjOiBO
ZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSByZXZpZXcg
b2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KDQoNCg0KT24gVHVlLCBOb3YgMjgs
IDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRv
Om1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQpIaSwNCg0KDQpJIGhhdmUgbm93IHJldmlld2VkIGRy
YWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTEuICBJIGhhdmUgb25lDQpzb21ld2hhdCBtb3Jl
IGltcG9ydGFudCBjb21tZW50LCBhbmQgc2V2ZXJhbCBvdGhlcnMuDQoNCkltcG9ydGFudCBpc3N1
ZToNCg0KbyAgMy4xMA0KDQogIEkgZG9uJ3QgdGhpbmsgdGhlIHByb3Bvc2VkIFlBTkcgZXh0ZW5z
aW9uIGlzIHRoZSBjb3JyZWN0IHNvbHV0aW9uIHRvDQogIHRoZSBzdGF0ZWQgcHJvYmxlbSwgZm9y
IHNldmVyYWwgcmVhc29uczoNCg0KICAgIDEuICBJbiBtb3N0IGNhc2VzLCB0aGlzIGlzIG5vdCBh
IHByb3BlcnR5IG9mIHRoZSBkYXRhIG1vZGVsLCBidXQNCiAgICAgICAgb2YgdGhlIGltcGxlbWVu
dGF0aW9uLCBhbmQgcG9zc2libHkgZXZlbiB0aGUgZGVwbG95bWVudC4gIFNvDQogICAgICAgIGhh
dmluZyBhIFlBTkcgZXh0ZW5zaW9uIHN0YXRlbWVudCBpcyBub3QgYSBnb29kIHNvbHV0aW9uLg0K
DQogICAgMi4gIFdpdGggTkRNQSwgdGhlIHNhbWUgc2NoZW1hIG5vZGUgaXMgcHJlc2VudCBpbiBk
aWZmZXJlbnQNCiAgICAgICAgZGF0YXN0b3Jlcy4gIEl0IG1pZ2h0IGJlIHRoZSBjYXNlIHRoYXQg
YW4gaW1wbGVtZW50YXRpb24NCiAgICAgICAgc3VwcG9ydHMgb24tY2hhbmdlIGZvciB0aGUgbm9k
ZSBpbiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlLA0KICAgICAgICBidXQgbm90IGluIG9wZXJh
dGlvbmFsLiAgQWdhaW4sIG1hcmtpbmcgYSBub2RlIGluIHRoZSBzY2hlbWENCiAgICAgICAgaXMg
bm90IGEgZ29vZCBzb2x1dGlvbi4NCg0KICAgIDMuICBTaW5jZSB0aGUgb24tY2hhbmdlIHByb3Bl
cnR5IGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCwgaXQNCiAgICAgICAgbWVhbnMgdGhlIGlu
Zm9ybWF0aW9uIHdpbGwgYmUgYXZhaWxhYmxlIHRvIGNsaWVudHMgb25seSBpbg0KICAgICAgICBk
ZXZpYXRpb24gbW9kdWxlcy4gIFRoaXMgaXMgcXVpdGUgYW4gZXhwZW5zaXZlIGFuZCBjb21wbGlj
YXRlZA0KICAgICAgICB3YXkgdG8gcGFzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIGNsaWVudHMu
DQoNCg0KICBBbiBhbHRlcm5hdGl2ZSBzb2x1dGlvbiBjb3VsZCBiZSB0byBoYXZlIGFuIG9yZGVy
ZWQgbGlzdCBvZg0KICBpbnN0YW5jZS1pZGVudGlmaWVycyB0aGF0IGxpc3QgdGhpcyBwcm9wZXJ0
eSwgcGVyIGRhdGFzdG9yZSwgZm9yDQogIGV4YW1wbGU6DQoNCiAgIDxlbnRyeT4NCiAgICAgPHBh
dGg+L3N5czpzeXN0ZW0vc3lzOnN5c3RlbS10aW1lPHBhdGg+DQogICAgIDxub3RpZmlhYmxlLW9u
LWNoYW5nZT5mYWxzZTwvbm90aWZpYWJsZS1vbi1jaGFuZ2U+DQogICA8L2VudHJ5Pg0KICAgPGVu
dHJ5Pg0KICAgICA8cGF0aD4vc3lzOnN5c3RlbTxwYXRoPg0KICAgICA8bm90aWZpYWJsZS1vbi1j
aGFuZ2U+dHJ1ZTwvbm90aWZpYWJsZS1vbi1jaGFuZ2U+DQogICA8L2VudHJ5Pg0KDQogIFlldCBh
bm90aGVyIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGxlYXZlIHRoaXMgdG8gZnV0dXJlIHdvcmsu
DQoNCg0KSSB3b3VsZCBwcmVmZXIgdG8gbGVhdmUgdGhpcyB0byBmdXR1cmUgd29yay4NCkkgYWdy
ZWUgdGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBwcm9wZXJ0eSwgYW5kIG5vdCBhIGRhdGEgbW9k
ZWwgcHJvcGVydHkuDQoNCkFuZHkNCg0KDQoNCk90aGVyIGNvbW1lbnRzOg0KDQoNCm8gIDINCg0K
ICBUaGUgZG9jdW1lbnQgdXNlcyB0aGUgdGVybSAiWUFORyBkYXRhc3RvcmUiIChpdCBpcyBldmVu
IGluIHRoZSB0aXRsZQ0KICBvZiB0aGUgZG9jdW1lbnQpLiAgVGhpcyB0ZXJtIGlzIG5vdCB1c2Vk
IGVsc2V3aGVyZSwgYW5kIGl0IGlzIG5vdA0KICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBJ
IHN1Z2dlc3QgeW91IGNoYW5nZSB0aGlzIHRvIHNpbXBseQ0KICAiZGF0YXN0b3JlIi4NCg0KICBB
bHNvLCBJIHRoaW5rIHlvdSBzaG91bGQgImltcG9ydCIgdGhlIHRlcm0gImRhdGFzdG9yZSIgZnJv
bQ0KICBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMsIGluc3RlYWQgb2YgaGF2
aW5nIGEgc2xpZ2h0bHkNCiAgZGlmZmVyZW50IHRlcm0gaW4gdGhpcyBkb2N1bWVudC4NCg0KICBJ
dCBpcyBhbHNvIHVuZm9ydHVuYXRlIHRoYXQgeW91IHVzZSB0aGUgdGVybSAiZGF0YSBub2RlIiBp
biBhDQogIGRpZmZlcmVudCBtZWFuaW5nIHRoYW4gUkZDIDc5NTAuICBNYXliZSB1c2UgImRhdGFz
dG9yZSBub2RlIg0KICBpbnN0ZWFkPw0KDQoNCm8gIDMuMQ0KDQogIEknbSBub3Qgc3VyZSBJIHVu
ZGVyc3RhbmQgdGhlIGRhbXBlbmluZyBwZXJpb2QgY29uY2VwdC4gIExldCdzDQogIGFzc3VtZSB0
aGF0IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlzIDEwcy4gIFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQN
CiAgdGltZXM6DQoNCiAgICAyICAzICA0ICAxMSAgMTMgIDE0ICAxNQ0KDQogIEZyb20gdGhlIGRl
c2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9t
DQogIHRpbWVzOg0KDQogICAgMiAgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAyKQ0KICAg
IDEyIChjb250YWluaW5nIGNoYW5nZSBmcm9tIDMsNCwxMSkNCiAgICAxMyAoY29udGFpbmluZyBv
bmx5IGNoYW5nZSBmcm9tIDEzKQ0KICAgIDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwx
NSkNCg0KICBJcyB0aGlzIGNvcnJlY3Q/DQoNCiAgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUg
ZGVzY3JpcHRpb24gaW4gdGhlIFlBTkcgbW9kdWxlIGlzDQogIGNsYXJpZmllZCAtIGN1cnJlbnRs
eSB0aGUgUkZDIHRleHQgY29udGFpbnMgbW9yZSBkZXRhaWxzIHRoYW4gdGhlDQogIFlBTkcgbW9k
dWxlLg0KDQoNCm8gIDMuMg0KDQogIFRoZSB0ZXh0IHNheXM6DQoNCiAgICAgVGhlcmVmb3JlLCBp
biBvcmRlciB0byBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHN1YnNjcmlwdGlvbg0KICAgICBpdGVy
YXRpb25zIGJldHdlZW4gc3Vic2NyaWJlciBhbmQgcHVibGlzaGVyLCBkeW5hbWljDQogICAgIHN1
YnNjcmlwdGlvbnMgU0hPVUxEIHN1cHBvcnQgYSBzaW1wbGUgbmVnb3RpYXRpb24gYmV0d2Vlbg0K
ICAgICBzdWJzY3JpYmVycyBhbmQgcHVibGlzaGVycyBmb3Igc3Vic2NyaXB0aW9uIHBhcmFtZXRl
cnMuDQoNCiAgVG8gd2hvbSBpcyB0aGlzICJTSE9VTEQiIGRpcmVjdGVkPyAgSSBtZWFuLCBkeW5h
bWljIHN1YnNjcmlwdGlvbnMgYXMNCiAgc3BlY2lmaWVkIGluIHRoaXMgZHJhZnQgZG9lcyBpbmRl
ZWQgc3VwcG9ydCBzaW1wbGUgIm5lZ290aWF0aW9uIi4NCiAgTWF5YmUgcy9TSE9VTEQgc3VwcG9y
dC9zdXBwb3J0cy8gPw0KDQoNCm8gIDMuNA0KDQogIFRoZSB0ZXh0IHNheXM6DQoNCiAgICBQbGVh
c2Ugc2VlIFtwcm9taXNlXSBmb3INCiAgICBtb3JlIG9uIHRoZSB0cmFuc2FjdGlvbmFsIGJhc2lz
IHVuZGVybHlpbmcgdGhlIHB1Ymxpc2hlciBhbmQNCiAgICBzdWJzY3JpYmVyIGludGVyYWN0aW9u
cyB3aXRoaW4gdGhpcyBkb2N1bWVudC4NCg0KICBTbyBJIGRpZCB0aGF0LiAgQnV0IEkgZGlkbid0
IGZpbmQgYW55IHRleHQgaW4gdGhlIHJlZmVyZW5jZWQNCiAgZG9jdW1lbnQgdGhhdCB0YWxrZWQg
YWJvdXQgInRoZSB0cmFuc2FjdGlvbmFsIGJhc2lzIi4NCg0KICBJIHN1Z2dlc3QgeW91IHJlbW92
ZSB0aGlzIHNlbnRlbmNlIGZyb20gdGhlIGRyYWZ0Lg0KDQoNCm8gIDMuNQ0KDQogIFRoZSB0ZXh0
IHNheXM6DQoNCiAgICAgQSBwdWJsaXNoZXIgTVVTVCBzdXBwb3J0IFhNTCBlbmNvZGluZyBhbmQg
TUFZIHN1cHBvcnQgb3RoZXINCiAgICAgZW5jb2RpbmdzIHN1Y2ggYXMgSlNPTiBlbmNvZGluZy4N
Cg0KICBJIGRvbid0IHRoaW5rIHRoaXMgaXMgY29ycmVjdC4gIEEgUkVTVENPTkYgc2V2ZXIgaXMg
bm90IHJlcXVpcmVkIHRvDQogIHN1cHBvcnQgWE1MLiAgSSB0aGluayB5b3Ugc2hvdWxkIHJlbW92
ZSB0aGlzIHNlbnRlbmNlLg0KDQoNCm8gIDMuNS4xDQoNCiAgICAgSW4gYSBwZXJpb2RpYyBzdWJz
Y3JpcHRpb24sIHRoZSBkYXRhIGluY2x1ZGVkIGFzIHBhcnQgb2YgYW4gdXBkYXRlDQogICAgIGNv
cnJlc3BvbmRzIHRvIGRhdGEgdGhhdCBjb3VsZCBoYXZlIGJlZW4gc2ltcGx5IHJldHJpZXZlZCB1
c2luZyBhIGdldA0KICAgICBvcGVyYXRpb24gYW5kIGlzIGVuY29kZWQgaW4gdGhlIHNhbWUgd2F5
Lg0KDQogIFdoYXQgaXMgImEgZ2V0IG9wZXJhdGlvbiI/ICBEbyB5b3UgbWVhbiBSRVNUQ09ORiBH
RVQgb3IgTkVUQ09ORg0KICA8Z2V0Lz4gb3Igc29tZXRoaW5nIGVsc2U/ICBXaGF0YWJvdXQgb3Ro
ZXIgcHJvdG9jb2xzPw0KDQogIChJbiAzLjYsIHlvdSB1c2Ugc2ltcGx5ICJhIEdFVCIgZm9yIHBy
b2JhYmx5IHRoZSBzYW1lIHRoaW5nLikNCg0KDQpvICAzLjYNCg0KICAgICBTdWJzY3JpcHRpb24g
cG9saWN5IHNwZWNpZmllcyBib3RoIHRoZSBzZWxlY3Rpb24gZmlsdGVycyBhbmQgdGhlDQogICAg
IGRhdGFzdG9yZXMgYWdhaW5zdCB3aGljaCB0aGVzZSBzZWxlY3Rpb24gZmlsdGVycyB3aWxsIGJl
IGFwcGxpZWQuDQogICAgIFRoZSByZXN1bHQgaXMgdGhlIHB1c2ggb2YgaW5mb3JtYXRpb24gbmVj
ZXNzYXJ5IHRvIHJlbW90ZWx5IG1haW50YWluDQogICAgIGFuIGV4dHJhY3Qgb2YgdGhlIHB1Ymxp
c2hlcidzIGRhdGFzdG9yZS4NCg0KICBJdCBzZWVtcyB0aGlzIHBhcmFncmFwaCBkZWZpbmVzIHRo
ZSB0ZXJtICJTdWJzY3JpcHRpb24gcG9saWN5Ii4gIEJ1dA0KICB0aGlzIHRlcm0gaXMgbm90IHVz
ZWQgaW4gdGhlIGRvY3VtZW50LiAgV2hhdCBkb2VzIGl0IG1lYW5zIHRoYXQgdGhlDQogIHJlc3Vs
dCBvZiBhIHBvbGljeSBpcyAidGhlIHB1c2ggb2YgaW5mb3JtYXRpb24iPw0KDQogIEkgdGhpbmsg
SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBwYXJhZ3JhcGggdHJpZXMgdG8gdGVsbCBtZS4N
Cg0KDQpvICAzLjYNCg0KICAgICBvICB4cGF0aDogQW4geHBhdGggc2VsZWN0aW9uIGZpbHRlciBp
cyBhbiBYUGF0aCBleHByZXNzaW9uIHdoaWNoIG1heQ0KICAgICAgICBiZSBtZWFuaW5nZnVsbHkg
YXBwbGllZCB0byBhIGRhdGFzdG9yZS4NCg0KICAgV2hhdCBkb2VzICJtZWFuaW5nZnVsbHkgYXBw
bGllZCIgbWVhbj8NCg0KDQpvICAzLjYNCg0KICAgICBTZWxlY3Rpb24gZmlsdGVycyBhcmUgbm90
IGludGVuZGVkIHRvIGJlIHVzZWQgdG8gZmlsdGVyIG9iamVjdHMNCiAgICAgYmFzZWQgb24gYSBu
b24ta2V5IHByb3BlcnR5LiAgU3VwcG9ydGluZyBub24ta2V5IHByb3BlcnR5DQogICAgIGZpbHRl
cmluZyBzbyB3b3VsZCBoYXZlIGEgbnVtYmVyIG9mIGltcGxpY2F0aW9ucyB0aGF0IHdvdWxkDQog
ICAgIHJlc3VsdCBpbiBzaWduaWZpY2FudCBjb21wbGV4aXR5Lg0KDQogICAgIFsuLi5dDQoNCiAg
ICAgdGhlIGdvYWwgaXMgdG8NCiAgICAgcHJvdmlkZSBlcXVpdmFsZW50IGNhcGFiaWxpdGllcyB0
byB3aGF0IGlzIGF2YWlsYWJsZSB3aXRoIGEgR0VULg0KDQogIEluIEdFVCB5b3UgY2FuIGZpbHRl
ciBvbiAibm9uLWtleSBwcm9wZXJ0aWVzIi4NCg0KICBJIHRoaW5rIHlvdSBzaG91bGQgcmVtb3Zl
IHRoZSB0ZXh0IGFib3V0ICJub24ta2V5IHByb3BlcnRpZXMiLiAgSWYNCiAgYW55dGhpbmcsIEkg
dGhpbmsgeW91IGNhbiBhbGxvdyBhbiBpbXBsZW1lbnRhdGlvbiB0byByZWplY3QgYSBmaWx0ZXIN
CiAgdGhhdCB3b3VsZCBiZSB0b28gY29tcGxleCB0byBpbXBsZW1lbnQgLyBldmFsdWF0ZSAoaW4g
ZmFjdCBJIHRoaW5rDQogIHRoZSB0ZXh0IGFscmVhZHkgYWxsb3dzIGEgc2VydmVyIHRvIHJlamVj
dCBzdWNoIGZpbHRlcnMuKQ0KDQogIFdpdGggdGhlIGN1cnJlbnQgdGV4dCwgaXMgdGhpcyBmaWx0
ZXIgb2s6DQoNCiAgICAgL2ludGVyZmFjZXMvaW50ZXJmYWNlW2NvbnRhaW5zKG5hbWUsICJldGgi
KV0NCg0KICBJdCBmaWx0ZXJzIG9uIGEga2V5LCBzbyBpdCBzaG91bGQgYmUgb2ssIHJpZ2h0Pw0K
DQoNCm8gIDMuNw0KDQogIFRoZSBYTUwgZXhhbXBsZXMgYXJlIG5vdCB1c2luZyB0aGUgY29ycmVj
dCBYTUwgbmFtZXNwYWNlIGZvciB0aGUNCiAgbm9kZXMgZnJvbSB0aGUgImlldGYtaW50ZXJmYWNl
IiBtb2R1bGUuDQoNCiAgVGhlIFlBTkcgUGF0Y2ggZXhhbXBsZSBhbHNvIHNob3dzIGFuIGludGVy
ZXN0aW5nIGVmZmVjdCBpbiB0aGUNCiAgInBhdGNoLWlkIiBhbmQgImVkaXQtaWQiIGxlYWZzLiAg
SSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIG1lbnRpb24NCiAgaG93IGltcGxlbWVudGF0aW9ucyBh
cmUgc3VwcG9zZSB0byBmaWxsIGluIHRoZXNlIGxlYWZzLg0KDQoNCiAgVGhlICJ0YXJnZXQiIGxl
YWYgaXMgbm90IHNwZWNpZmllZCBjb3JyZWN0bHkuICBJdCBzaG91bGQgYmU6DQoNCiAgICAgICAg
IDx0YXJnZXQ+L2lldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzLXN0YXRlPC90YXJnZXQ+DQoNCg0K
byAgMy44DQoNCiAgVGhlIGV4YW1wbGUgaGFzOg0KDQogICA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlv
bg0KICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3Jp
YmVkLW5vdGlmaWNhdGlvbnMiDQogICAgICAgeG1sbnM6eXA9InVybjppZXRmOnBhcmFtczp4bWw6
bnM6eWFuZzppZXRmLXlhbmctcHVzaCI+DQogICAgICA8eXA6ZGF0YXN0b3JlPg0KICAgICAgICA8
eXA6c291cmNlIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3Rv
cmVzIj4NCg0KICBUaGlzIGRvZXNuJ3QgbWF0Y2ggdGhlIFlBTkcgbW9kZWw7IHRoZXJlIGlzIG5v
IGNvbnRhaW5lciBjYWxsZWQNCiAgImRhdGFzdG9yZSIgaW4gdGhlIG1vZGVsLg0KDQogIEZ1cnRo
ZXIgaXMgaGFzOg0KDQogICAgICAgIDx5cDpzdWJ0cmVlLWZpbHRlciBuZXRjb25mOnR5cGU9Inhw
YXRoIg0KICAgICAgICAgICAgeG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0
YS8xLjAiDQogICAgICAgICAgICBzZWxlY3Q9Ii9leDpmb28iLz4NCg0KICBhIHN1YnRyZWUtZmls
dGVyIG9mIHR5cGUgeHBhdGg/ICBJIHRoaW5rIG90IHNob3VsZCBiZToNCg0KICAgICAgICA8eXA6
eHBhdGgtZmlsdGVyIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4w
Ij4NCiAgICAgICAgICAgL2V4OmZvbw0KICAgICAgICA8L3lwOnhwYXRoLWZpbHRlcj4NCg0KICBB
bHNvLCBpdCBoYXM6DQoNCiAgICAgICAgPHlwOnNvdXJjZSB4bWxucz0idXJuOmlldGY6cGFyYW1z
OnhtbDpuczp5YW5nOmlldGYtZGF0YXN0b3JlcyI+DQogICAgICAgICAgb3BlcmF0aW9uYWwNCiAg
ICAgICAgPC95cDpzb3VyY2U+DQoNCiAgd2hpY2ggc2hvdWxkIGJlOg0KDQogICAgICAgIDx5cDpz
b3VyY2UgeG1sbnM6ZHM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFzdG9y
ZXMiPg0KICAgICAgICAgIGRzOm9wZXJhdGlvbmFsDQogICAgICAgIDwveXA6c291cmNlPg0KDQoN
Cm8gIDMuOQ0KDQogIFRoaXMgc2VjdGlvbiBsaXN0cyB0aHJlZSBjYXNlcyBmb3Igd2hpY2g6DQoN
CiAgICAgdGhlIGVycm9yIGlkZW50aXR5ICJkYXRhLXVuYXZhaWxhYmxlIiBTSE9VTEQgYmUgcmV0
dXJuZWQuDQoNCiAgT25lIG9mIHRoZSBjYXNlcyBpczoNCg0KICAgIG8gIHRoZSBhdXRob3JpemF0
aW9uIHByaXZpbGVnZXMgb2YgYSByZWNlaXZlciBjaGFuZ2Ugb3ZlciB0aGUgY291cnNlDQogICAg
ICAgb2YgdGhlIHN1YnNjcmlwdGlvbi4NCg0KICBCdXQgaG93IGNhbiBhIHNlcnZlciBrbm93IHRo
aXMgd2hlbiAiZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiIgaXMgc2VudD8NCg0KDQpvICAzLjkNCg0K
ICAgICBUaGUgY29udGV4dHVhbCBhdXRob3JpemF0aW9uIG1vZGVsIGZvciBkYXRhIGluIFlBTkcg
ZGF0YXN0b3JlcyBpcw0KICAgICB0aGUgTkVUQ09ORiBBY2Nlc3MgQ29udHJvbCBNb2RlbCBbUkZD
NjUzNmJpc10sIFNlY3Rpb24gMy4yLjQuDQoNCiAgRGlkIHlvdSBtZWFuIHMvY29udGV4dHVhbC9j
b25jZXB0dWFsLyA/DQoNCg0KbyAgMy4xMS4xDQoNCg0KICBPTEQ6DQoNCiAgICAgICBJZg0KICAg
ICAgIHRoaXMgaXMgbm90IHBvc3NpYmxlIGFuZCB0aGUgc3luY2gtb24tc3RhcnQgb3B0aW9uIGlz
IGNvbmZpZ3VyZWQsDQoNCiAgTkVXOg0KDQogICAgICAgSWYNCiAgICAgICB0aGlzIGlzIG5vdCBw
b3NzaWJsZSBhbmQgdGhlICJuby1zeW5jaC1vbi1zdGFydCIgb3B0aW9uIGlzIG5vdA0KICAgICAg
IHByZXNlbnQgZm9yIHRoZSBzdWJzY3JpcHRpb24uDQoNCg0KICAoZml4ZXMgaW5jb3JyZWN0IG5h
bWUgb2YgbGVhZiwgYW5kIGFsc28gY292ZXJzIGR5bmFtaWMNCiAgc3Vic2NyaXB0aW9ucykNCg0K
DQpvICA0LjMuMg0KDQogICAgIEEgc3Vic2NyaXB0aW9uLWlkIE1VU1QgYmUgdHJhbnNwb3J0ZWQg
YWxvbmcgd2l0aCB0aGUgc3Vic2NyaWJlZA0KICAgICBjb250ZW50cy4NCg0KICBUaGVuIHRoZSBs
ZWFmICJzdWJzY3JpcHRpb24taWQiIHNob3VsZCBiZSBtYW5kYXRvcnkuDQoNCg0KICAgICBBICJ0
aW1lLW9mLXVwZGF0ZSIgd2hpY2ggcmVwcmVzZW50cyB0aGUgdGltZSBhbiB1cGRhdGUgcmVjb3Jk
DQogICAgIHNuYXBzaG90IHdhcyBnZW5lcmF0ZWQuICBBIHJlY2VpdmVyIE1BWSBhc3N1bWUgdGhh
dCBhIHB1Ymxpc2hlcidzDQogICAgIG9iamVjdHMgaGF2ZSB0aGVzZSBwdXNoZWQgdmFsdWVzIGF0
IHRoaXMgcG9pbnQgaW4gdGltZS4NCg0KICBTaG91bGQgInRpbWUtb2YtdXBkYXRlIiBiZSBtYW5k
YXRvcnk/DQoNCiAgSG93IGlzICJ0aW1lLW9mLXVwZGF0ZSIgZGlmZmVyZW50IGZyb20gImV2ZW50
VGltZSIgaW4gdGhlDQogIG5vdGlmaWNhdGlvbj8NCg0KDQpvICA0LjMuMg0KDQogICAgIElmIHRo
ZSBhcHBsaWNhdGlvbiBkZXRlY3RzIGFuIGluZm9ybWF0aW9uYWwgZGlzY29udGludWl0eQ0KDQog
IFdoYXQgaXMgYW4gImluZm9ybWF0aW9uYWwgZGlzY29udGludWl0eSI/DQoNCg0KbyAgNC40LjEg
LyA0LjQuMg0KDQogIFRoZSBYTUwgZXhhbXBsZXMgYXJlIGJyb2tlbjsgY29tcGFyZSB3aXRoIG15
IGNvbW1lbnRzIGZvciAzLjguDQoNCg0KbyAgNQ0KDQogIE9MRDoNCg0KICAgICJUaGlzIG1vZHVs
ZSBjb250YWlucyBjb25jZXB0dWFsIFlBTkcgc3BlY2lmaWNhdGlvbnMNCiAgICAgZm9yIFlBTkcg
cHVzaC4iOw0KDQogIE5FVzoNCg0KICAgICJUaGlzIG1vZHVsZSBjb250YWlucyBZQU5HIHNwZWNp
ZmljYXRpb25zIGZvciBZQU5HIHB1c2guIjsNCg0KbyAgNSAtIGlkZW50aXRpZXMNCg0KICAgIGlk
ZW50aXR5IHFvcy11bnN1cHBvcnRlZCB7DQogICAgICBiYXNlIHNuOmVycm9yOw0KICAgICAgZGVz
Y3JpcHRpb24NCiAgICAgICAgIlN1YnNjcmlwdGlvbiBRb1MgcGFyYW1ldGVycyBub3Qgc3VwcG9y
dGVkIG9uIHRoaXMgcGxhdGZvcm0uIjsNCiAgICB9DQoNCiAgVGhpcyBpZGVudGl0eSBpcyBub3Qg
bWVudGlvbmVkIGFueXdoZXJlIGluIHRoZSB0ZXh0LiAgSW5zdGVhZCBvZg0KICBoYXZpbmcgdGhp
cyBpZGVudGl0eSwgd291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIGRlZmluZSBhIGZlYXR1cmUgZm9y
DQogICJxb3MiLCBhbmQgbWFyayB0aGUgbm9kZXMgeW91IGhhdmUgaW4gbWluZCB3aXRoIGFuIGlm
LWZlYXR1cmU/DQoNCg0KICAgIGlkZW50aXR5IG9uLWNoYW5nZS11bnN1cHBvcnRlZCB7DQogICAg
ICBiYXNlIHNuOmVycm9yOw0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIk9uLWNoYW5nZSBu
b3Qgc3VwcG9ydGVkLiI7DQogICAgfQ0KDQogIFdoZW4gd2lsbCB0aGlzIGlkZW50aXR5IGJlIHVz
ZWQ/ICBUaGVyZSBpcyBhbHJlYWR5IGEgZmVhdHVyZQ0KICAib24tY2hhbmdlIiBhbmQgY29ycmVz
cG9uZGluZyBpZi1mZWF0dXJlIHN0YXRlbWVudHMuDQoNCiAgICBpZGVudGl0eSBvbi1jaGFuZ2Ut
c3luY2gtdW5zdXBwb3J0ZWQgew0KICAgICAgYmFzZSBzbjplcnJvcjsNCiAgICAgIGRlc2NyaXB0
aW9uDQogICAgICAgICJPbi1jaGFuZ2Ugc3luY2gtb24tc3RhcnQgYW5kIHJlc3luY2hvbml6YXRp
b24gbm90IHN1cHBvcnRlZC4iOw0KICAgIH0NCg0KICBUaGUgbGVhZiBpcyBjYWxsZWQgIm5vLXN5
bmMtb24tc3RhcnQiLCB3aGljaCBpbXBsaWVzIHRoYXQgc3luYyBvbg0KICBzdGFydCBpcyB0aGUg
ZGVmYXVsdC4gIFNvIHdoZW4gd2lsbCB0aGlzIGlkZW50aXR5IGJlIHVzZWQ/DQoNCg0KICAgIGlk
ZW50aXR5IHJlZmVyZW5jZS1taXNtYXRjaCB7DQogICAgIGJhc2Ugc246ZXJyb3I7DQogICAgICBk
ZXNjcmlwdGlvbg0KICAgICAgICJNaXNtYXRjaCBpbiBmaWx0ZXIga2V5IGFuZCByZWZlcmVuY2Vk
IHlhbmcgc3VidHJlZS4iOw0KICAgIH0NCg0KICBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGRlc2Ny
aXB0aW9uIG9mIHRoaXMgaWRlbnRpdHkuICBQbGVhc2UNCiAgY2xhcmlmeS4NCg0KDQogICAgIGlk
ZW50aXR5IGRhdGF0cmVlLXNpemUgew0KDQogIFNob3VsZCBpdCBiZSAicmVzdWx0LXRvby1iaWci
IG9yIHNvbWV0aGluZz8NCg0KDQogICAgaWRlbnRpdHkgbm8tc3VjaC1kYXRhc3RvcmUgew0KDQog
IEkgdGhpbmsgdGhpcyBvbmUgc2hvdWxkIGJlIHJlbW92ZWQuICBUaGUgbm9ybWFsICJpbnZhbGlk
LXZhbHVlIg0KICBlcnJvci10YWcgY292ZXJzIHRoaXMgZXJyb3IuDQoNCg0KICAgICAgaWRlbnRp
dHkgY3VzdG9tLWRhdGFzdG9yZSB7DQogICAgICAgIGJhc2UgZHM6ZGF0YXN0b3JlOw0KICAgICAg
ICBkZXNjcmlwdGlvbg0KICAgICAgICAgICJBIGRhdGFzdG9yZSB3aXRoIGJvdW5kYXJpZXMgbm90
IGRlZmluZWQgd2l0aGluDQogICAgICAgICAgIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0
YXN0b3JlcyI7DQogICAgICB9DQoNCiAgVGhpcyBpZGVudGl0eSBuZWVkcyB0byBiZSByZW1vdmVk
LiAgSWYgc29tZW9uZSBkZWZpbmVzIGEgY3VzdG9tDQogIGRhdGFzdG9yZSwgaXQgd291bGQgZ2V0
IGEgc3BlY2lmaWMgaWRlbnRpdHksIGFuZCB0aGF0IGlkZW50aXR5IGNhbg0KICBiZSB1c2VkIGFz
ICJzb3VyY2UiLg0KDQoNCm8gIDUgLSAiY2hhbmdlLXR5cGUiDQoNCiAgVGhlIGRlc2NyaXB0aW9u
cyBvZiB0aGUgZW51bXMgbmVlZCB0byBiZSBpbXByb3ZlZC4gIFRoaXMgaXMgYWJvdXQNCiAgcmVw
b3J0aW5nIGEgY2hhbmdlIGluIGEgZGF0YXN0b3JlLiAgVGhlIHZhbHVlICJjcmVhdGUiIGlzIGRl
c2NyaWJlZA0KICBhczoNCg0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICJDcmVhdGUg
YSBuZXcgZGF0YSByZXNvdXJjZSBpZiBpdCBkb2VzIG5vdCBhbHJlYWR5IGV4aXN0LiAgSWYNCiAg
ICAgICAgICBpdCBhbHJlYWR5IGV4aXN0cywgcmVwbGFjZS4iOw0KDQogIEFsc28sIHRoZSBkZXNj
cmlwdGlvbiBvZiB0aGUgdHlwZWRlZiBoYXM6DQoNCiAgICAgICJSRkMgODA3MiBzZWN0aW9uIDIu
NSwgd2l0aCBhIGRlbHRhIHRoYXQgaXQgaXMgb2sgdG8gcmVjZWl2ZQ0KICAgICAgYWJpbGl0eSBj
cmVhdGUgb24gYW4gZXhpc3Rpbmcgbm9kZSwgb3IgcmVjZWl2ZSBhIGRlbGV0ZSBvbiBhDQogICAg
ICBtaXNzaW5nIG5vZGUuIjsNCg0KICBCdXQgd2hhdCBkb2VzIHRoaXMgbWVhbj8gIFRoZSB0eXBl
IGlzIHVzZWQgdG8gKmV4Y2x1ZGUqIHNvbWUgY2hhbmdlcw0KICBmcm9tIGEgeWFuZyBwYXRjaCBy
ZWNvcmQuDQoNCg0KbyAgNSAtIHNlbGVjdGlvbiBmaWx0ZXINCg0KICBUaGUgWFBhdGggZXhwcmVz
c2lvbiBpcyBub3QgcHJvcGVybHkgZGVmaW5lZC4NCg0KICBPTEQ6DQoNCiAgICAgICAgICAiVGhp
cyBwYXJhbWV0ZXIgY29udGFpbnMgYW4gWFBhdGggZXhwcmVzc2lvbiBpZGVudGlmeWluZyB0aGUN
CiAgICAgICAgICBwb3J0aW9ucyBvZiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSB0byByZXRyaWV2ZS4i
Ow0KDQogIE5FVzoNCg0KICAgICAgICAgICJUaGlzIHBhcmFtZXRlciBjb250YWlucyBhbiBYUGF0
aCBleHByZXNzaW9uIGlkZW50aWZ5aW5nIHRoZQ0KICAgICAgICAgICBwb3J0aW9ucyBvZiB0aGUg
dGFyZ2V0IGRhdGFzdG9yZSB0byByZXRyaWV2ZS4NCg0KICAgICAgICAgICBJZiB0aGUgZXhwcmVz
c2lvbiByZXR1cm5zIGEgbm9kZS1zZXQsIGFsbCBub2RlcyBpbiB0aGUNCiAgICAgICAgICAgbm9k
ZS1zZXQgYXJlIHNlbGVjdGVkIGJ5IHRoZSBmaWx0ZXIuICBPdGhlcndpc2UsIGlmIHRoZQ0KICAg
ICAgICAgICBleHByZXNzaW9uIGRvZXMgbm90IHJldHVybiBhIG5vZGUtc2V0LCB0aGUgZmlsdGVy
DQogICAgICAgICAgIGRvZXNuJ3Qgc2VsZWN0IGFueSBub2Rlcy4NCg0KICAgICAgICAgICBGSVhN
RTogKCopDQoNCiAgICAgICAgICAgVGhlIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIGluIHRoZSBm
b2xsb3dpbmcgWFBhdGggY29udGV4dDoNCg0KICAgICAgICAgICAgIG8gIFRoZSBzZXQgb2YgbmFt
ZXNwYWNlIGRlY2xhcmF0aW9ucyBhcmUgdGhvc2UgaW4gc2NvcGUgb24NCiAgICAgICAgICAgICAg
ICB0aGUgJ3hwYXRoLWZpbHRlcicgbGVhZiBlbGVtZW50Lg0KDQogICAgICAgICAgICAgbyAgVGhl
IHNldCBvZiB2YXJpYWJsZSBiaW5kaW5ncyBpcyBlbXB0eS4NCg0KICAgICAgICAgICAgIG8gIFRo
ZSBmdW5jdGlvbiBsaWJyYXJ5IGlzIHRoZSBjb3JlIGZ1bmN0aW9uIGxpYnJhcnksIGFuZA0KICAg
ICAgICAgICAgICAgIHRoZSBYUGF0aCBmdW5jdGlvbnMgZGVmaW5lZCBpbiBzZWN0aW9uIDEwIGlu
IFJGQyA3OTUwLg0KDQogICAgICAgICAgICAgbyAgVGhlIGNvbnRleHQgbm9kZSBpcyB0aGUgcm9v
dCBub2RlIG9mIHRoZSB0YXJnZXQNCiAgICAgICAgICAgICAgICBkYXRhc3RvcmUuDQoNCg0KICAo
KikgLSBXZSBuZWVkIHRvIGRlc2NyaWJlIHdoZW4gdGhlIGZpbHRlciBpcyBldmFsdWF0ZWQuICBU
aGlzIGlzDQogIGFsc28gdHJ1ZSBmb3IgdGhlIHN1YnRyZWUgZmlsdGVyLiAgSXMgaXQgZXZhbHVh
dGVkIHdoZW4gdGhlDQogIHN1YnNjcmlwdGlvbiBpcyBzdGFydGVkIGFuZCBleHBsaWNpdGx5IG1v
ZGlmaWVkLCBvciBldmVyeXRpbWUgYQ0KICBjaGFuZ2UgaXMgZGV0ZWN0ZWQ/DQoNCiAgW1NpZGUg
bm90ZTogdGhpcyBkZXNjcmlwdGlvbiBpcyBhbHNvIG1pc3NpbmcgZnJvbSB0aGUgInhwYXRoLWZp
bHRlciINCiAgbGVhZiBpbiAiZ2V0LWRhdGEiIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLW5l
dGNvbmYuICBJIGhhdmUNCiAgdXBkYXRlZCB0aGUgZGVzY3JpcHRpb24gaW4gdGhhdCBkcmFmdC5d
DQoNCg0KbyAgNSAtIHRlcm1pbm9sb2d5DQoNCiAgVGhlIHRlcm0gImFnZW50IiBpcyB1c2VkIGEg
Y291cGxlIG9mIHRpbWVzLiAgVXNlICJwdWJsaXNoZXIiIG9yDQogICJzZXJ2ZXIiIGluc3RlYWQu
DQoNCg0KbyAgNSAtIGRhbXBlbmluZw0KDQogICAgICAgICAgbGVhZiBkYW1wZW5pbmctcGVyaW9k
IHsNCiAgICAgICAgICAgIHR5cGUgeWFuZzp0aW1ldGlja3M7DQogICAgICAgICAgICBtYW5kYXRv
cnkgdHJ1ZTsNCg0KICAgU2hvdWxkIHRoaXMgaW5zdGVhZCBiZToNCg0KICAgICAgICAgIGxlYWYg
ZGFtcGVuaW5nLXBlcmlvZCB7DQogICAgICAgICAgICB0eXBlIHlhbmc6dGltZXRpY2tzOw0KICAg
ICAgICAgICAgZGVmYXVsdCAiMCI7DQoNCiAgIFNvIHRoYXQgdGhlIHJlcXVlc3QgaXMgdGhlIHNh
bWUgaWYgdGhlICJvbi1jaGFuZ2UiIGZlYXR1cmUgaXMNCiAgIHN1cHBvcnQgb3Igbm90Lg0KDQoN
Cm8gIDUgLSBuby1zeW5jaC1vbi1zdGFydA0KDQogICAgICAgICAgICAgV2hlbg0KICAgICAgICAg
ICAgIHByZXNlbnQsIHB1c2hpbmcgYSBmdWxsIHNlbGVjdGlvbiBwZXIgdGhlIHRlcm1zIG9mIHRo
ZQ0KICAgICAgICAgICAgIHNlbGVjdGlvbiBmaWx0ZXIgTUFZIE5PVCBiZSBkb25lIGZvciB0aGlz
IHN1YnNjcmlwdGlvbi4NCg0KICAgRGlkIHlvdSBtZWFuIHMvTUFZIE5PVC9NVVNUIE5PVC8gPw0K
DQogICBNQVkgTk9UIGlzIG5vdCBhIDIxMTkgdGVybS4NCg0KDQpvICA1IC0gUW9TDQoNCiAgV2h5
IGFyZSB0aGUgcW9zIHBhcmFtZXRlcnMgZGVmaW5lZCBpbiB5YW5nIHB1c2gsIGFuZCBub3QgaW4N
CiAgc3Vic2NyaWJlZCBub3RpZmljYXRpb25zPyAgSXQgc2VlbXMgdGhhdCB0aGV5IGFyZSBnZW5l
cmljLg0KDQoNCm8gIDUgLSBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIHBhcmFtcw0KDQogIEkgdGhp
bmsgYSAid2hlbiIgZXhwcmVzc2lvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGZpcnN0IGF1Z21l
bnQ6DQoNCiAgICBhdWdtZW50ICIvc246ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbi9zbjppbnB1dCIg
ew0KICAgICAgd2hlbiAic246dGFyZ2V0L3lwOmRhdGFzdG9yZS95cDpzb3VyY2UiOw0KDQoNCm8g
IDUgLSBwdXNoLXVwZGF0ZQ0KDQogIFdoYXQgZG9lcyB0aGUgcHJlc2VuY2Ugb2YgInVwZGF0ZXMt
bm90LXNlbnQiIG1lYW4gaW4gInB1c2gtdXBkYXRlIj8NCiAgInB1c2gtdXBkYXRlIiBjb250YWlu
cyBhIHNuYXBzaG90LCBub3QgYSBkaWZmLCBzbyB3aHkgaXMNCiAgInVwZGF0ZXMtbm90LXNlbnQi
IHByZXNlbnQ/DQoNCg0KbyAgNSAtIHB1c2gtY2hhbmdlLXVwZGF0ZQ0KDQogICAgICAgICJUaGlz
IGNvbnRhaW5zIGFuIGluY3JlbWVudGFsIHNldCBvZiBkYXRhc3RvcmUgY2hhbmdlcyBuZWVkZWQN
CiAgICAgICAgIHRvIHVwZGF0ZSBhIHJlbW90ZSBkYXRhc3RvcmUgc3RhcnRpbmcgYXQgdGhlIHRp
bWUgb2YgdGhlDQogICAgICAgICBwcmV2aW91cyB1cGRhdGUsIHBlciB0aGUgdGVybXMgb2YgdGhl
IHN1YnNjcmlwdGlvbi4NCg0KICAgV2hhdCBpcyBhbiAiaW5jcmVtZW50YWwgc2V0Ij8gIFByb2Jh
Ymx5IHMvaW5jcmVtZW50YWwgc2V0L3NldC8NCg0KDQoNCm8gIEdlbmVyYWwNCg0KICBVc2UgZG91
YmxlIHF1b3RlcyBmb3Igbm9kZSBuYW1lcy4gICJwdXNoLXVwZGF0ZSIsICJzdWJzY3JpcHRpb24t
aWQiDQogIGV0Yy4gIFF1b3RlcyBhcmUgY3VycmVudGx5IHVzZWQgaW5jb25zaXN0ZW50bHksIGFu
ZCBpdCBtYWtlcyB0aGUNCiAgdGV4dCBoYXJkZXIgdG8gcmVhZC4NCg0KDQoNCg0KL21hcnRpbg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29u
ZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF783sjceml521mbxchi_
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
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHdlIGxlYXZlIHRoaXMgdG8gZnV0dXJl
IHdvcmssIG9rLCBidXQgd2hhdCBpcyB0aGUgZGVmYXVsdCBiZWhhdmlvciBpbiB0aGF0IGNhc2U/
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DdXJyZW50bHk6IG9u
LWNoYW5nZSBub3RpZmlhYmxlIGlzIHN1cHBvcnRlZCBvbmx5IHdoZW4gc3BlY2lmaWNhbGx5IGRl
c2lnbmF0ZWQgYXMgc3VjaC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+SWYgd2UgaGF2ZSBubyB3YXkgdG8gZGVzaWduYXRlIGl0LCB3ZSBjYW4gY2hh
bmdlIGl0IHRvIGFzc3VtZSBpdCBpcyBzdXBwb3J0ZWQsIGJ1dCByZWplY3Qgb24tY2hhbmdlIHN1
YnNjcmlwdGlvbnMgdGhhdCBjb250YWluIG5vbi1ub3RpZmlhYmxlIG9iamVjdHMuJm5ic3A7IEJ1
dCBob3cNCiBkb2VzIGEgc2VydmVyIGtub3cgd2hpY2ggb25lcyB0aGV5IGFyZT8mbmJzcDsgV2Ug
ZG8gbm90IHdhbnQgdG8gc2lsZW50bHkgbm90IHNlbmQgb24tY2hhbmdlIHVwZGF0ZXMsIHdoZW4g
dGhlIGNsaWVudCBhc3N1bWVzIHRoYXQgd2UgZG8uJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byBtb3Zl
IHRoZSBjdXJyZW50IHNvbHV0aW9uIHRvIHRoZSBhcHBlbmRpeCwgZGVmaW5pbmcgdGhpcyBhcyBv
bmUgc29sdXRpb24gYXBwcm9hY2ggKGFuZCBnaXZpbmcgdGhlIFlBTkcgbW9kdWxlIGZvciB0aGF0
KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXgN
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu
IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8
Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5
LCBOb3ZlbWJlciAyOCwgMjAxNyA5OjExIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gQmpvcmts
dW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0O25l
dGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2
aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwg
TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox
Mi4wcHQiPkhpLDxicj4NCjxicj4NCjxicj4NCkkgaGF2ZSBub3cgcmV2aWV3ZWQgZHJhZnQtaWV0
Zi1uZXRjb25mLXlhbmctcHVzaC0xMS4mbmJzcDsgSSBoYXZlIG9uZTxicj4NCnNvbWV3aGF0IG1v
cmUgaW1wb3J0YW50IGNvbW1lbnQsIGFuZCBzZXZlcmFsIG90aGVycy48YnI+DQo8YnI+DQpJbXBv
cnRhbnQgaXNzdWU6PGJyPg0KPGJyPg0KbyZuYnNwOyAzLjEwPGJyPg0KPGJyPg0KJm5ic3A7IEkg
ZG9uJ3QgdGhpbmsgdGhlIHByb3Bvc2VkIFlBTkcgZXh0ZW5zaW9uIGlzIHRoZSBjb3JyZWN0IHNv
bHV0aW9uIHRvPGJyPg0KJm5ic3A7IHRoZSBzdGF0ZWQgcHJvYmxlbSwgZm9yIHNldmVyYWwgcmVh
c29uczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDEuJm5ic3A7IEluIG1vc3QgY2FzZXMsIHRo
aXMgaXMgbm90IGEgcHJvcGVydHkgb2YgdGhlIGRhdGEgbW9kZWwsIGJ1dDxicj4NCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBvZiB0aGUgaW1wbGVtZW50YXRpb24sIGFuZCBwb3NzaWJseSBl
dmVuIHRoZSBkZXBsb3ltZW50LiZuYnNwOyBTbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBoYXZpbmcgYSBZQU5HIGV4dGVuc2lvbiBzdGF0ZW1lbnQgaXMgbm90IGEgZ29vZCBzb2x1
dGlvbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDIuJm5ic3A7IFdpdGggTkRNQSwgdGhlIHNh
bWUgc2NoZW1hIG5vZGUgaXMgcHJlc2VudCBpbiBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgZGF0YXN0b3Jlcy4mbmJzcDsgSXQgbWlnaHQgYmUgdGhlIGNhc2UgdGhh
dCBhbiBpbXBsZW1lbnRhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdXBw
b3J0cyBvbi1jaGFuZ2UgZm9yIHRoZSBub2RlIGluIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUs
PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJ1dCBub3QgaW4gb3BlcmF0aW9uYWwu
Jm5ic3A7IEFnYWluLCBtYXJraW5nIGEgbm9kZSBpbiB0aGUgc2NoZW1hPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IGlzIG5vdCBhIGdvb2Qgc29sdXRpb24uPGJyPg0KPGJyPg0KJm5i
c3A7ICZuYnNwOyAzLiZuYnNwOyBTaW5jZSB0aGUgb24tY2hhbmdlIHByb3BlcnR5IGlzIGltcGxl
bWVudGF0aW9uIGRlcGVuZGVudCwgaXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
bWVhbnMgdGhlIGluZm9ybWF0aW9uIHdpbGwgYmUgYXZhaWxhYmxlIHRvIGNsaWVudHMgb25seSBp
bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXZpYXRpb24gbW9kdWxlcy4mbmJz
cDsgVGhpcyBpcyBxdWl0ZSBhbiBleHBlbnNpdmUgYW5kIGNvbXBsaWNhdGVkPGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdheSB0byBwYXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUg
Y2xpZW50cy48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgQW4gYWx0ZXJuYXRpdmUgc29sdXRpb24g
Y291bGQgYmUgdG8gaGF2ZSBhbiBvcmRlcmVkIGxpc3Qgb2Y8YnI+DQombmJzcDsgaW5zdGFuY2Ut
aWRlbnRpZmllcnMgdGhhdCBsaXN0IHRoaXMgcHJvcGVydHksIHBlciBkYXRhc3RvcmUsIGZvcjxi
cj4NCiZuYnNwOyBleGFtcGxlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsmbHQ7ZW50cnkmZ3Q7
PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7cGF0aCZndDsvc3lzOnN5c3RlbS9zeXM6c3lz
dGVtLXRpbWUmbHQ7cGF0aCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtub3RpZmlh
YmxlLW9uLWNoYW5nZSZndDtmYWxzZSZsdDsvbm90aWZpYWJsZS1vbi1jaGFuZ2UmZ3Q7PGJyPg0K
Jm5ic3A7ICZuYnNwOyZsdDsvZW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtlbnRyeSZn
dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtwYXRoJmd0Oy9zeXM6c3lzdGVtJmx0O3Bh
dGgmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bm90aWZpYWJsZS1vbi1jaGFuZ2Um
Z3Q7dHJ1ZSZsdDsvbm90aWZpYWJsZS1vbi1jaGFuZ2UmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZs
dDsvZW50cnkmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7IFlldCBhbm90aGVyIGFsdGVybmF0aXZlIHdv
dWxkIGJlIHRvIGxlYXZlIHRoaXMgdG8gZnV0dXJlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcHJlZmVy
IHRvIGxlYXZlIHRoaXMgdG8gZnV0dXJlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoaXMgaXMgYW4gaW1wbGVtZW50YXRp
b24gcHJvcGVydHksIGFuZCBub3QgYSBkYXRhIG1vZGVsIHByb3BlcnR5LjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
T3RoZXIgY29tbWVudHM6PGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyAyPGJyPg0KPGJyPg0KJm5i
c3A7IFRoZSBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtICZxdW90O1lBTkcgZGF0YXN0b3JlJnF1b3Q7
IChpdCBpcyBldmVuIGluIHRoZSB0aXRsZTxicj4NCiZuYnNwOyBvZiB0aGUgZG9jdW1lbnQpLiZu
YnNwOyBUaGlzIHRlcm0gaXMgbm90IHVzZWQgZWxzZXdoZXJlLCBhbmQgaXQgaXMgbm90PGJyPg0K
Jm5ic3A7IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4mbmJzcDsgSSBzdWdnZXN0IHlvdSBjaGFu
Z2UgdGhpcyB0byBzaW1wbHk8YnI+DQombmJzcDsgJnF1b3Q7ZGF0YXN0b3JlJnF1b3Q7Ljxicj4N
Cjxicj4NCiZuYnNwOyBBbHNvLCBJIHRoaW5rIHlvdSBzaG91bGQgJnF1b3Q7aW1wb3J0JnF1b3Q7
IHRoZSB0ZXJtICZxdW90O2RhdGFzdG9yZSZxdW90OyBmcm9tPGJyPg0KJm5ic3A7IGRyYWZ0LWll
dGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcywgaW5zdGVhZCBvZiBoYXZpbmcgYSBzbGlnaHRs
eTxicj4NCiZuYnNwOyBkaWZmZXJlbnQgdGVybSBpbiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4N
CiZuYnNwOyBJdCBpcyBhbHNvIHVuZm9ydHVuYXRlIHRoYXQgeW91IHVzZSB0aGUgdGVybSAmcXVv
dDtkYXRhIG5vZGUmcXVvdDsgaW4gYTxicj4NCiZuYnNwOyBkaWZmZXJlbnQgbWVhbmluZyB0aGFu
IFJGQyA3OTUwLiZuYnNwOyBNYXliZSB1c2UgJnF1b3Q7ZGF0YXN0b3JlIG5vZGUmcXVvdDs8YnI+
DQombmJzcDsgaW5zdGVhZD88YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDMuMTxicj4NCjxicj4N
CiZuYnNwOyBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGNv
bmNlcHQuJm5ic3A7IExldCdzPGJyPg0KJm5ic3A7IGFzc3VtZSB0aGF0IHRoZSBkYW1wZW5pbmcg
cGVyaW9kIGlzIDEwcy4mbmJzcDsgVGhlbiBjaGFuZ2VzIGhhcHBlbiBhdDxicj4NCiZuYnNwOyB0
aW1lczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDImbmJzcDsgMyZuYnNwOyA0Jm5ic3A7IDEx
Jm5ic3A7IDEzJm5ic3A7IDE0Jm5ic3A7IDE1PGJyPg0KPGJyPg0KJm5ic3A7IEZyb20gdGhlIGRl
c2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9t
PGJyPg0KJm5ic3A7IHRpbWVzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMiZuYnNwOyAoY29u
dGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDIpPGJyPg0KJm5ic3A7ICZuYnNwOyAxMiAoY29udGFp
bmluZyBjaGFuZ2UgZnJvbSAzLDQsMTEpPGJyPg0KJm5ic3A7ICZuYnNwOyAxMyAoY29udGFpbmlu
ZyBvbmx5IGNoYW5nZSBmcm9tIDEzKTxicj4NCiZuYnNwOyAmbmJzcDsgMjMgKGNvbnRhaW5pbmcg
Y2hhbmdlcyBmcm9tIDE0LDE1KTxicj4NCjxicj4NCiZuYnNwOyBJcyB0aGlzIGNvcnJlY3Q/PGJy
Pg0KPGJyPg0KJm5ic3A7IEluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRlc2NyaXB0aW9uIGlu
IHRoZSBZQU5HIG1vZHVsZSBpczxicj4NCiZuYnNwOyBjbGFyaWZpZWQgLSBjdXJyZW50bHkgdGhl
IFJGQyB0ZXh0IGNvbnRhaW5zIG1vcmUgZGV0YWlscyB0aGFuIHRoZTxicj4NCiZuYnNwOyBZQU5H
IG1vZHVsZS48YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDMuMjxicj4NCjxicj4NCiZuYnNwOyBU
aGUgdGV4dCBzYXlzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlcmVmb3JlLCBp
biBvcmRlciB0byBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHN1YnNjcmlwdGlvbjxicj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7aXRlcmF0aW9ucyBiZXR3ZWVuIHN1YnNjcmliZXIgYW5kIHB1Ymxpc2hl
ciwgZHluYW1pYzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7c3Vic2NyaXB0aW9ucyBTSE9VTEQg
c3VwcG9ydCBhIHNpbXBsZSBuZWdvdGlhdGlvbiBiZXR3ZWVuPGJyPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDtzdWJzY3JpYmVycyBhbmQgcHVibGlzaGVycyBmb3Igc3Vic2NyaXB0aW9uIHBhcmFtZXRl
cnMuPGJyPg0KPGJyPg0KJm5ic3A7IFRvIHdob20gaXMgdGhpcyAmcXVvdDtTSE9VTEQmcXVvdDsg
ZGlyZWN0ZWQ/Jm5ic3A7IEkgbWVhbiwgZHluYW1pYyBzdWJzY3JpcHRpb25zIGFzPGJyPg0KJm5i
c3A7IHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0IGRvZXMgaW5kZWVkIHN1cHBvcnQgc2ltcGxlICZx
dW90O25lZ290aWF0aW9uJnF1b3Q7Ljxicj4NCiZuYnNwOyBNYXliZSBzL1NIT1VMRCBzdXBwb3J0
L3N1cHBvcnRzLyA/PGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyAzLjQ8YnI+DQo8YnI+DQombmJz
cDsgVGhlIHRleHQgc2F5czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFBsZWFzZSBzZWUgW3By
b21pc2VdIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgbW9yZSBvbiB0aGUgdHJhbnNhY3Rpb25hbCBi
YXNpcyB1bmRlcmx5aW5nIHRoZSBwdWJsaXNoZXIgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyBzdWJz
Y3JpYmVyIGludGVyYWN0aW9ucyB3aXRoaW4gdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQombmJz
cDsgU28gSSBkaWQgdGhhdC4mbmJzcDsgQnV0IEkgZGlkbid0IGZpbmQgYW55IHRleHQgaW4gdGhl
IHJlZmVyZW5jZWQ8YnI+DQombmJzcDsgZG9jdW1lbnQgdGhhdCB0YWxrZWQgYWJvdXQgJnF1b3Q7
dGhlIHRyYW5zYWN0aW9uYWwgYmFzaXMmcXVvdDsuPGJyPg0KPGJyPg0KJm5ic3A7IEkgc3VnZ2Vz
dCB5b3UgcmVtb3ZlIHRoaXMgc2VudGVuY2UgZnJvbSB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KPGJy
Pg0KbyZuYnNwOyAzLjU8YnI+DQo8YnI+DQombmJzcDsgVGhlIHRleHQgc2F5czo8YnI+DQo8YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwO0EgcHVibGlzaGVyIE1VU1Qgc3VwcG9ydCBYTUwgZW5jb2Rp
bmcgYW5kIE1BWSBzdXBwb3J0IG90aGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtlbmNvZGlu
Z3Mgc3VjaCBhcyBKU09OIGVuY29kaW5nLjxicj4NCjxicj4NCiZuYnNwOyBJIGRvbid0IHRoaW5r
IHRoaXMgaXMgY29ycmVjdC4mbmJzcDsgQSBSRVNUQ09ORiBzZXZlciBpcyBub3QgcmVxdWlyZWQg
dG88YnI+DQombmJzcDsgc3VwcG9ydCBYTUwuJm5ic3A7IEkgdGhpbmsgeW91IHNob3VsZCByZW1v
dmUgdGhpcyBzZW50ZW5jZS48YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDMuNS4xPGJyPg0KPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtJbiBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiwgdGhlIGRh
dGEgaW5jbHVkZWQgYXMgcGFydCBvZiBhbiB1cGRhdGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw
O2NvcnJlc3BvbmRzIHRvIGRhdGEgdGhhdCBjb3VsZCBoYXZlIGJlZW4gc2ltcGx5IHJldHJpZXZl
ZCB1c2luZyBhIGdldDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0aW9uIGFuZCBpcyBl
bmNvZGVkIGluIHRoZSBzYW1lIHdheS48YnI+DQo8YnI+DQombmJzcDsgV2hhdCBpcyAmcXVvdDth
IGdldCBvcGVyYXRpb24mcXVvdDs/Jm5ic3A7IERvIHlvdSBtZWFuIFJFU1RDT05GIEdFVCBvciBO
RVRDT05GPGJyPg0KJm5ic3A7ICZsdDtnZXQvJmd0OyBvciBzb21ldGhpbmcgZWxzZT8mbmJzcDsg
V2hhdGFib3V0IG90aGVyIHByb3RvY29scz88YnI+DQo8YnI+DQombmJzcDsgKEluIDMuNiwgeW91
IHVzZSBzaW1wbHkgJnF1b3Q7YSBHRVQmcXVvdDsgZm9yIHByb2JhYmx5IHRoZSBzYW1lIHRoaW5n
Lik8YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDMuNjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7U3Vic2NyaXB0aW9uIHBvbGljeSBzcGVjaWZpZXMgYm90aCB0aGUgc2VsZWN0aW9uIGZp
bHRlcnMgYW5kIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YXN0b3JlcyBhZ2FpbnN0
IHdoaWNoIHRoZXNlIHNlbGVjdGlvbiBmaWx0ZXJzIHdpbGwgYmUgYXBwbGllZC48YnI+DQombmJz
cDsgJm5ic3A7ICZuYnNwO1RoZSByZXN1bHQgaXMgdGhlIHB1c2ggb2YgaW5mb3JtYXRpb24gbmVj
ZXNzYXJ5IHRvIHJlbW90ZWx5IG1haW50YWluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDthbiBl
eHRyYWN0IG9mIHRoZSBwdWJsaXNoZXIncyBkYXRhc3RvcmUuPGJyPg0KPGJyPg0KJm5ic3A7IEl0
IHNlZW1zIHRoaXMgcGFyYWdyYXBoIGRlZmluZXMgdGhlIHRlcm0gJnF1b3Q7U3Vic2NyaXB0aW9u
IHBvbGljeSZxdW90Oy4mbmJzcDsgQnV0PGJyPg0KJm5ic3A7IHRoaXMgdGVybSBpcyBub3QgdXNl
ZCBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7IFdoYXQgZG9lcyBpdCBtZWFucyB0aGF0IHRoZTxicj4N
CiZuYnNwOyByZXN1bHQgb2YgYSBwb2xpY3kgaXMgJnF1b3Q7dGhlIHB1c2ggb2YgaW5mb3JtYXRp
b24mcXVvdDs/PGJyPg0KPGJyPg0KJm5ic3A7IEkgdGhpbmsgSSBkb24ndCB1bmRlcnN0YW5kIHdo
YXQgdGhpcyBwYXJhZ3JhcGggdHJpZXMgdG8gdGVsbCBtZS48YnI+DQo8YnI+DQo8YnI+DQpvJm5i
c3A7IDMuNjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7byZuYnNwOyB4cGF0aDogQW4g
eHBhdGggc2VsZWN0aW9uIGZpbHRlciBpcyBhbiBYUGF0aCBleHByZXNzaW9uIHdoaWNoIG1heTxi
cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiZSBtZWFuaW5nZnVsbHkgYXBwbGllZCB0
byBhIGRhdGFzdG9yZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7V2hhdCBkb2VzICZxdW90O21l
YW5pbmdmdWxseSBhcHBsaWVkJnF1b3Q7IG1lYW4/PGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyAz
LjY8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO1NlbGVjdGlvbiBmaWx0ZXJzIGFyZSBu
b3QgaW50ZW5kZWQgdG8gYmUgdXNlZCB0byBmaWx0ZXIgb2JqZWN0czxicj4NCiZuYnNwOyAmbmJz
cDsgJm5ic3A7YmFzZWQgb24gYSBub24ta2V5IHByb3BlcnR5LiZuYnNwOyBTdXBwb3J0aW5nIG5v
bi1rZXkgcHJvcGVydHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2ZpbHRlcmluZyBzbyB3b3Vs
ZCBoYXZlIGEgbnVtYmVyIG9mIGltcGxpY2F0aW9ucyB0aGF0IHdvdWxkPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDtyZXN1bHQgaW4gc2lnbmlmaWNhbnQgY29tcGxleGl0eS48YnI+DQo8YnI+DQom
bmJzcDsgJm5ic3A7ICZuYnNwO1suLi5dPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt0
aGUgZ29hbCBpcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvdmlkZSBlcXVpdmFsZW50
IGNhcGFiaWxpdGllcyB0byB3aGF0IGlzIGF2YWlsYWJsZSB3aXRoIGEgR0VULjxicj4NCjxicj4N
CiZuYnNwOyBJbiBHRVQgeW91IGNhbiBmaWx0ZXIgb24gJnF1b3Q7bm9uLWtleSBwcm9wZXJ0aWVz
JnF1b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyBJIHRoaW5rIHlvdSBzaG91bGQgcmVtb3ZlIHRoZSB0
ZXh0IGFib3V0ICZxdW90O25vbi1rZXkgcHJvcGVydGllcyZxdW90Oy4mbmJzcDsgSWY8YnI+DQom
bmJzcDsgYW55dGhpbmcsIEkgdGhpbmsgeW91IGNhbiBhbGxvdyBhbiBpbXBsZW1lbnRhdGlvbiB0
byByZWplY3QgYSBmaWx0ZXI8YnI+DQombmJzcDsgdGhhdCB3b3VsZCBiZSB0b28gY29tcGxleCB0
byBpbXBsZW1lbnQgLyBldmFsdWF0ZSAoaW4gZmFjdCBJIHRoaW5rPGJyPg0KJm5ic3A7IHRoZSB0
ZXh0IGFscmVhZHkgYWxsb3dzIGEgc2VydmVyIHRvIHJlamVjdCBzdWNoIGZpbHRlcnMuKTxicj4N
Cjxicj4NCiZuYnNwOyBXaXRoIHRoZSBjdXJyZW50IHRleHQsIGlzIHRoaXMgZmlsdGVyIG9rOjxi
cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7L2ludGVyZmFjZXMvaW50ZXJmYWNlW2NvbnRh
aW5zKG5hbWUsICZxdW90O2V0aCZxdW90OyldPGJyPg0KPGJyPg0KJm5ic3A7IEl0IGZpbHRlcnMg
b24gYSBrZXksIHNvIGl0IHNob3VsZCBiZSBvaywgcmlnaHQ/PGJyPg0KPGJyPg0KPGJyPg0KbyZu
YnNwOyAzLjc8YnI+DQo8YnI+DQombmJzcDsgVGhlIFhNTCBleGFtcGxlcyBhcmUgbm90IHVzaW5n
IHRoZSBjb3JyZWN0IFhNTCBuYW1lc3BhY2UgZm9yIHRoZTxicj4NCiZuYnNwOyBub2RlcyBmcm9t
IHRoZSAmcXVvdDtpZXRmLWludGVyZmFjZSZxdW90OyBtb2R1bGUuPGJyPg0KPGJyPg0KJm5ic3A7
IFRoZSBZQU5HIFBhdGNoIGV4YW1wbGUgYWxzbyBzaG93cyBhbiBpbnRlcmVzdGluZyBlZmZlY3Qg
aW4gdGhlPGJyPg0KJm5ic3A7ICZxdW90O3BhdGNoLWlkJnF1b3Q7IGFuZCAmcXVvdDtlZGl0LWlk
JnF1b3Q7IGxlYWZzLiZuYnNwOyBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgbWVudGlvbjxicj4N
CiZuYnNwOyBob3cgaW1wbGVtZW50YXRpb25zIGFyZSBzdXBwb3NlIHRvIGZpbGwgaW4gdGhlc2Ug
bGVhZnMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7IFRoZSAmcXVvdDt0YXJnZXQmcXVvdDsgbGVh
ZiBpcyBub3Qgc3BlY2lmaWVkIGNvcnJlY3RseS4mbmJzcDsgSXQgc2hvdWxkIGJlOjxicj4NCjxi
cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7dGFyZ2V0Jmd0Oy9pZXRm
LWludGVyZmFjZXM6aW50ZXJmYWNlcy1zdGF0ZSZsdDsvdGFyZ2V0Jmd0Ozxicj4NCjxicj4NCjxi
cj4NCm8mbmJzcDsgMy44PGJyPg0KPGJyPg0KJm5ic3A7IFRoZSBleGFtcGxlIGhhczo8YnI+DQo8
YnI+DQombmJzcDsgJm5ic3A7Jmx0O2VzdGFibGlzaC1zdWJzY3JpcHRpb248YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlh
bmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDt4bWxuczp5cD0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6
aWV0Zi15YW5nLXB1c2gmcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3lw
OmRhdGFzdG9yZSZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3lwOnNv
dXJjZSB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3Rv
cmVzJnF1b3Q7Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyBUaGlzIGRvZXNuJ3QgbWF0Y2ggdGhlIFlB
TkcgbW9kZWw7IHRoZXJlIGlzIG5vIGNvbnRhaW5lciBjYWxsZWQ8YnI+DQombmJzcDsgJnF1b3Q7
ZGF0YXN0b3JlJnF1b3Q7IGluIHRoZSBtb2RlbC48YnI+DQo8YnI+DQombmJzcDsgRnVydGhlciBp
cyBoYXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt5cDpzdWJ0
cmVlLWZpbHRlciBuZXRjb25mOnR5cGU9JnF1b3Q7eHBhdGgmcXVvdDs8YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxuczpleD0mcXVvdDs8YSBocmVmPSJo
dHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov
L2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMDwvYT4mcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZWxlY3Q9JnF1b3Q7L2V4OmZvbyZxdW90Oy8m
Z3Q7PGJyPg0KPGJyPg0KJm5ic3A7IGEgc3VidHJlZS1maWx0ZXIgb2YgdHlwZSB4cGF0aD8mbmJz
cDsgSSB0aGluayBvdCBzaG91bGQgYmU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZsdDt5cDp4cGF0aC1maWx0ZXIgeG1sbnM6ZXg9JnF1b3Q7PGEgaHJlZj0iaHR0cDov
L2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFt
cGxlLmNvbS9zYW1wbGUtZGF0YS8xLjA8L2E+JnF1b3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7L2V4OmZvbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbHQ7L3lwOnhwYXRoLWZpbHRlciZndDs8YnI+DQo8YnI+DQombmJzcDsgQWxz
bywgaXQgaGFzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7eXA6
c291cmNlIHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFz
dG9yZXMmcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBv
cGVyYXRpb25hbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3lwOnNvdXJj
ZSZndDs8YnI+DQo8YnI+DQombmJzcDsgd2hpY2ggc2hvdWxkIGJlOjxicj4NCjxicj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7eXA6c291cmNlIHhtbG5zOmRzPSZxdW90O3Vybjpp
ZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFzdG9yZXMmcXVvdDsmZ3Q7PGJyPg0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkczpvcGVyYXRpb25hbDxicj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3lwOnNvdXJjZSZndDs8YnI+DQo8YnI+DQo8YnI+
DQpvJm5ic3A7IDMuOTxicj4NCjxicj4NCiZuYnNwOyBUaGlzIHNlY3Rpb24gbGlzdHMgdGhyZWUg
Y2FzZXMgZm9yIHdoaWNoOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIGVycm9y
IGlkZW50aXR5ICZxdW90O2RhdGEtdW5hdmFpbGFibGUmcXVvdDsgU0hPVUxEIGJlIHJldHVybmVk
Ljxicj4NCjxicj4NCiZuYnNwOyBPbmUgb2YgdGhlIGNhc2VzIGlzOjxicj4NCjxicj4NCiZuYnNw
OyAmbmJzcDsgbyZuYnNwOyB0aGUgYXV0aG9yaXphdGlvbiBwcml2aWxlZ2VzIG9mIGEgcmVjZWl2
ZXIgY2hhbmdlIG92ZXIgdGhlIGNvdXJzZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O29mIHRoZSBzdWJzY3JpcHRpb24uPGJyPg0KPGJyPg0KJm5ic3A7IEJ1dCBob3cgY2FuIGEgc2Vy
dmVyIGtub3cgdGhpcyB3aGVuICZxdW90O2VzdGFibGlzaC1zdWJzY3JpcHRpb24mcXVvdDsgaXMg
c2VudD88YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDMuOTxicj4NCjxicj4NCiZuYnNwOyAmbmJz
cDsgJm5ic3A7VGhlIGNvbnRleHR1YWwgYXV0aG9yaXphdGlvbiBtb2RlbCBmb3IgZGF0YSBpbiBZ
QU5HIGRhdGFzdG9yZXMgaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBORVRDT05GIEFj
Y2VzcyBDb250cm9sIE1vZGVsIFtSRkM2NTM2YmlzXSwgU2VjdGlvbiAzLjIuNC48YnI+DQo8YnI+
DQombmJzcDsgRGlkIHlvdSBtZWFuIHMvY29udGV4dHVhbC9jb25jZXB0dWFsLyA/PGJyPg0KPGJy
Pg0KPGJyPg0KbyZuYnNwOyAzLjExLjE8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgT0xEOjxicj4N
Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmPGJyPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7dGhpcyBpcyBub3QgcG9zc2libGUgYW5kIHRoZSBzeW5jaC1vbi1zdGFydCBv
cHRpb24gaXMgY29uZmlndXJlZCw8YnI+DQo8YnI+DQombmJzcDsgTkVXOjxicj4NCjxicj4NCiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7dGhpcyBpcyBub3QgcG9zc2libGUgYW5kIHRoZSAmcXVvdDtuby1zeW5jaC1vbi1zdGFydCZx
dW90OyBvcHRpb24gaXMgbm90PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJlc2Vu
dCBmb3IgdGhlIHN1YnNjcmlwdGlvbi48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgKGZpeGVzIGlu
Y29ycmVjdCBuYW1lIG9mIGxlYWYsIGFuZCBhbHNvIGNvdmVycyBkeW5hbWljPGJyPg0KJm5ic3A7
IHN1YnNjcmlwdGlvbnMpPGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA0LjMuMjxicj4NCjxicj4N
CiZuYnNwOyAmbmJzcDsgJm5ic3A7QSBzdWJzY3JpcHRpb24taWQgTVVTVCBiZSB0cmFuc3BvcnRl
ZCBhbG9uZyB3aXRoIHRoZSBzdWJzY3JpYmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250
ZW50cy48YnI+DQo8YnI+DQombmJzcDsgVGhlbiB0aGUgbGVhZiAmcXVvdDtzdWJzY3JpcHRpb24t
aWQmcXVvdDsgc2hvdWxkIGJlIG1hbmRhdG9yeS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwO0EgJnF1b3Q7dGltZS1vZi11cGRhdGUmcXVvdDsgd2hpY2ggcmVwcmVzZW50cyB0
aGUgdGltZSBhbiB1cGRhdGUgcmVjb3JkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtzbmFwc2hv
dCB3YXMgZ2VuZXJhdGVkLiZuYnNwOyBBIHJlY2VpdmVyIE1BWSBhc3N1bWUgdGhhdCBhIHB1Ymxp
c2hlcidzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtvYmplY3RzIGhhdmUgdGhlc2UgcHVzaGVk
IHZhbHVlcyBhdCB0aGlzIHBvaW50IGluIHRpbWUuPGJyPg0KPGJyPg0KJm5ic3A7IFNob3VsZCAm
cXVvdDt0aW1lLW9mLXVwZGF0ZSZxdW90OyBiZSBtYW5kYXRvcnk/PGJyPg0KPGJyPg0KJm5ic3A7
IEhvdyBpcyAmcXVvdDt0aW1lLW9mLXVwZGF0ZSZxdW90OyBkaWZmZXJlbnQgZnJvbSAmcXVvdDtl
dmVudFRpbWUmcXVvdDsgaW4gdGhlPGJyPg0KJm5ic3A7IG5vdGlmaWNhdGlvbj88YnI+DQo8YnI+
DQo8YnI+DQpvJm5ic3A7IDQuMy4yPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtJZiB0
aGUgYXBwbGljYXRpb24gZGV0ZWN0cyBhbiBpbmZvcm1hdGlvbmFsIGRpc2NvbnRpbnVpdHk8YnI+
DQo8YnI+DQombmJzcDsgV2hhdCBpcyBhbiAmcXVvdDtpbmZvcm1hdGlvbmFsIGRpc2NvbnRpbnVp
dHkmcXVvdDs/PGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA0LjQuMSAvIDQuNC4yPGJyPg0KPGJy
Pg0KJm5ic3A7IFRoZSBYTUwgZXhhbXBsZXMgYXJlIGJyb2tlbjsgY29tcGFyZSB3aXRoIG15IGNv
bW1lbnRzIGZvciAzLjguPGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA1PGJyPg0KPGJyPg0KJm5i
c3A7IE9MRDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O1RoaXMgbW9kdWxlIGNvbnRh
aW5zIGNvbmNlcHR1YWwgWUFORyBzcGVjaWZpY2F0aW9uczxicj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7Zm9yIFlBTkcgcHVzaC4mcXVvdDs7PGJyPg0KPGJyPg0KJm5ic3A7IE5FVzo8YnI+DQo8YnI+
DQombmJzcDsgJm5ic3A7ICZxdW90O1RoaXMgbW9kdWxlIGNvbnRhaW5zIFlBTkcgc3BlY2lmaWNh
dGlvbnMgZm9yIFlBTkcgcHVzaC4mcXVvdDs7PGJyPg0KPGJyPg0KbyZuYnNwOyA1IC0gaWRlbnRp
dGllczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgaWRlbnRpdHkgcW9zLXVuc3VwcG9ydGVkIHs8
YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBiYXNlIHNuOmVycm9yOzxicj4NCiZuYnNwOyAmbmJz
cDsgJm5ic3A7IGRlc2NyaXB0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZx
dW90O1N1YnNjcmlwdGlvbiBRb1MgcGFyYW1ldGVycyBub3Qgc3VwcG9ydGVkIG9uIHRoaXMgcGxh
dGZvcm0uJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgfTxicj4NCjxicj4NCiZuYnNwOyBUaGlz
IGlkZW50aXR5IGlzIG5vdCBtZW50aW9uZWQgYW55d2hlcmUgaW4gdGhlIHRleHQuJm5ic3A7IElu
c3RlYWQgb2Y8YnI+DQombmJzcDsgaGF2aW5nIHRoaXMgaWRlbnRpdHksIHdvdWxkbid0IGl0IGJl
IGJldHRlciB0byBkZWZpbmUgYSBmZWF0dXJlIGZvcjxicj4NCiZuYnNwOyAmcXVvdDtxb3MmcXVv
dDssIGFuZCBtYXJrIHRoZSBub2RlcyB5b3UgaGF2ZSBpbiBtaW5kIHdpdGggYW4gaWYtZmVhdHVy
ZT88YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IGlkZW50aXR5IG9uLWNoYW5nZS11bnN1
cHBvcnRlZCB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmFzZSBzbjplcnJvcjs8YnI+DQom
bmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmcXVvdDtPbi1jaGFuZ2Ugbm90IHN1cHBvcnRlZC4mcXVvdDs7PGJyPg0KJm5ic3A7
ICZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7IFdoZW4gd2lsbCB0aGlzIGlkZW50aXR5IGJlIHVz
ZWQ/Jm5ic3A7IFRoZXJlIGlzIGFscmVhZHkgYSBmZWF0dXJlPGJyPg0KJm5ic3A7ICZxdW90O29u
LWNoYW5nZSZxdW90OyBhbmQgY29ycmVzcG9uZGluZyBpZi1mZWF0dXJlIHN0YXRlbWVudHMuPGJy
Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBpZGVudGl0eSBvbi1jaGFuZ2Utc3luY2gtdW5zdXBwb3J0
ZWQgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJhc2Ugc246ZXJyb3I7PGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgZGVzY3JpcHRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJnF1b3Q7T24tY2hhbmdlIHN5bmNoLW9uLXN0YXJ0IGFuZCByZXN5bmNob25pemF0aW9uIG5v
dCBzdXBwb3J0ZWQuJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgfTxicj4NCjxicj4NCiZuYnNw
OyBUaGUgbGVhZiBpcyBjYWxsZWQgJnF1b3Q7bm8tc3luYy1vbi1zdGFydCZxdW90Oywgd2hpY2gg
aW1wbGllcyB0aGF0IHN5bmMgb248YnI+DQombmJzcDsgc3RhcnQgaXMgdGhlIGRlZmF1bHQuJm5i
c3A7IFNvIHdoZW4gd2lsbCB0aGlzIGlkZW50aXR5IGJlIHVzZWQ/PGJyPg0KPGJyPg0KPGJyPg0K
Jm5ic3A7ICZuYnNwOyBpZGVudGl0eSByZWZlcmVuY2UtbWlzbWF0Y2ggezxicj4NCiZuYnNwOyAm
bmJzcDsgJm5ic3A7YmFzZSBzbjplcnJvcjs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNj
cmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O01pc21hdGNoIGlu
IGZpbHRlciBrZXkgYW5kIHJlZmVyZW5jZWQgeWFuZyBzdWJ0cmVlLiZxdW90Ozs8YnI+DQombmJz
cDsgJm5ic3A7IH08YnI+DQo8YnI+DQombmJzcDsgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBkZXNj
cmlwdGlvbiBvZiB0aGlzIGlkZW50aXR5LiZuYnNwOyBQbGVhc2U8YnI+DQombmJzcDsgY2xhcmlm
eS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aXR5IGRhdGF0cmVl
LXNpemUgezxicj4NCjxicj4NCiZuYnNwOyBTaG91bGQgaXQgYmUgJnF1b3Q7cmVzdWx0LXRvby1i
aWcmcXVvdDsgb3Igc29tZXRoaW5nPzxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgaWRl
bnRpdHkgbm8tc3VjaC1kYXRhc3RvcmUgezxicj4NCjxicj4NCiZuYnNwOyBJIHRoaW5rIHRoaXMg
b25lIHNob3VsZCBiZSByZW1vdmVkLiZuYnNwOyBUaGUgbm9ybWFsICZxdW90O2ludmFsaWQtdmFs
dWUmcXVvdDs8YnI+DQombmJzcDsgZXJyb3ItdGFnIGNvdmVycyB0aGlzIGVycm9yLjxicj4NCjxi
cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkZW50aXR5IGN1c3RvbS1kYXRhc3RvcmUg
ezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiYXNlIGRzOmRhdGFzdG9yZTs8YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVzY3JpcHRpb248YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O0EgZGF0YXN0b3JlIHdpdGggYm91bmRhcmll
cyBub3QgZGVmaW5lZCB3aXRoaW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO2RyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyZxdW90Ozs8YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KPGJyPg0KJm5ic3A7IFRoaXMgaWRlbnRpdHkg
bmVlZHMgdG8gYmUgcmVtb3ZlZC4mbmJzcDsgSWYgc29tZW9uZSBkZWZpbmVzIGEgY3VzdG9tPGJy
Pg0KJm5ic3A7IGRhdGFzdG9yZSwgaXQgd291bGQgZ2V0IGEgc3BlY2lmaWMgaWRlbnRpdHksIGFu
ZCB0aGF0IGlkZW50aXR5IGNhbjxicj4NCiZuYnNwOyBiZSB1c2VkIGFzICZxdW90O3NvdXJjZSZx
dW90Oy48YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDUgLSAmcXVvdDtjaGFuZ2UtdHlwZSZxdW90
Ozxicj4NCjxicj4NCiZuYnNwOyBUaGUgZGVzY3JpcHRpb25zIG9mIHRoZSBlbnVtcyBuZWVkIHRv
IGJlIGltcHJvdmVkLiZuYnNwOyBUaGlzIGlzIGFib3V0PGJyPg0KJm5ic3A7IHJlcG9ydGluZyBh
IGNoYW5nZSBpbiBhIGRhdGFzdG9yZS4mbmJzcDsgVGhlIHZhbHVlICZxdW90O2NyZWF0ZSZxdW90
OyBpcyBkZXNjcmliZWQ8YnI+DQombmJzcDsgYXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmcXVvdDtDcmVhdGUgYSBuZXcgZGF0YSByZXNvdXJjZSBpZiBpdCBkb2VzIG5vdCBh
bHJlYWR5IGV4aXN0LiZuYnNwOyBJZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgaXQgYWxyZWFkeSBleGlzdHMsIHJlcGxhY2UuJnF1b3Q7Ozxicj4NCjxicj4NCiZuYnNw
OyBBbHNvLCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHR5cGVkZWYgaGFzOjxicj4NCjxicj4NCiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1JGQyA4MDcyIHNlY3Rpb24gMi41LCB3aXRoIGEgZGVs
dGEgdGhhdCBpdCBpcyBvayB0byByZWNlaXZlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWJp
bGl0eSBjcmVhdGUgb24gYW4gZXhpc3Rpbmcgbm9kZSwgb3IgcmVjZWl2ZSBhIGRlbGV0ZSBvbiBh
PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWlzc2luZyBub2RlLiZxdW90Ozs8YnI+DQo8YnI+
DQombmJzcDsgQnV0IHdoYXQgZG9lcyB0aGlzIG1lYW4/Jm5ic3A7IFRoZSB0eXBlIGlzIHVzZWQg
dG8gKmV4Y2x1ZGUqIHNvbWUgY2hhbmdlczxicj4NCiZuYnNwOyBmcm9tIGEgeWFuZyBwYXRjaCBy
ZWNvcmQuPGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA1IC0gc2VsZWN0aW9uIGZpbHRlcjxicj4N
Cjxicj4NCiZuYnNwOyBUaGUgWFBhdGggZXhwcmVzc2lvbiBpcyBub3QgcHJvcGVybHkgZGVmaW5l
ZC48YnI+DQo8YnI+DQombmJzcDsgT0xEOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJnF1b3Q7VGhpcyBwYXJhbWV0ZXIgY29udGFpbnMgYW4gWFBhdGggZXhw
cmVzc2lvbiBpZGVudGlmeWluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IHBvcnRpb25zIG9mIHRoZSB0YXJnZXQgZGF0YXN0b3JlIHRvIHJldHJpZXZlLiZxdW90
Ozs8YnI+DQo8YnI+DQombmJzcDsgTkVXOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJnF1b3Q7VGhpcyBwYXJhbWV0ZXIgY29udGFpbnMgYW4gWFBhdGggZXhw
cmVzc2lvbiBpZGVudGlmeWluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO3BvcnRpb25zIG9mIHRoZSB0YXJnZXQgZGF0YXN0b3JlIHRvIHJldHJpZXZl
Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYg
dGhlIGV4cHJlc3Npb24gcmV0dXJucyBhIG5vZGUtc2V0LCBhbGwgbm9kZXMgaW4gdGhlPGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtub2RlLXNldCBhcmUgc2Vs
ZWN0ZWQgYnkgdGhlIGZpbHRlci4mbmJzcDsgT3RoZXJ3aXNlLCBpZiB0aGU8YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4cHJlc3Npb24gZG9lcyBub3QgcmV0
dXJuIGEgbm9kZS1zZXQsIHRoZSBmaWx0ZXI8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO2RvZXNuJ3Qgc2VsZWN0IGFueSBub2Rlcy48YnI+DQo8YnI+DQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZJWE1FOiAoKik8YnI+DQo8YnI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBleHByZXNzaW9u
IGlzIGV2YWx1YXRlZCBpbiB0aGUgZm9sbG93aW5nIFhQYXRoIGNvbnRleHQ6PGJyPg0KPGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byZuYnNwOyBU
aGUgc2V0IG9mIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMgYXJlIHRob3NlIGluIHNjb3BlIG9uPGJy
Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyB0aGUgJ3hwYXRoLWZpbHRlcicgbGVhZiBlbGVtZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO28mbmJzcDsgVGhlIHNldCBvZiB2
YXJpYWJsZSBiaW5kaW5ncyBpcyBlbXB0eS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvJm5ic3A7IFRoZSBmdW5jdGlvbiBsaWJyYXJ5
IGlzIHRoZSBjb3JlIGZ1bmN0aW9uIGxpYnJhcnksIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIFhQYXRoIGZ1bmN0aW9u
cyBkZWZpbmVkIGluIHNlY3Rpb24gMTAgaW4gUkZDIDc5NTAuPGJyPg0KPGJyPg0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byZuYnNwOyBUaGUgY29udGV4
dCBub2RlIGlzIHRoZSByb290IG5vZGUgb2YgdGhlIHRhcmdldDxicj4NCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGF0YXN0b3JlLjxicj4N
Cjxicj4NCjxicj4NCiZuYnNwOyAoKikgLSBXZSBuZWVkIHRvIGRlc2NyaWJlIHdoZW4gdGhlIGZp
bHRlciBpcyBldmFsdWF0ZWQuJm5ic3A7IFRoaXMgaXM8YnI+DQombmJzcDsgYWxzbyB0cnVlIGZv
ciB0aGUgc3VidHJlZSBmaWx0ZXIuJm5ic3A7IElzIGl0IGV2YWx1YXRlZCB3aGVuIHRoZTxicj4N
CiZuYnNwOyBzdWJzY3JpcHRpb24gaXMgc3RhcnRlZCBhbmQgZXhwbGljaXRseSBtb2RpZmllZCwg
b3IgZXZlcnl0aW1lIGE8YnI+DQombmJzcDsgY2hhbmdlIGlzIGRldGVjdGVkPzxicj4NCjxicj4N
CiZuYnNwOyBbU2lkZSBub3RlOiB0aGlzIGRlc2NyaXB0aW9uIGlzIGFsc28gbWlzc2luZyBmcm9t
IHRoZSAmcXVvdDt4cGF0aC1maWx0ZXImcXVvdDs8YnI+DQombmJzcDsgbGVhZiBpbiAmcXVvdDtn
ZXQtZGF0YSZxdW90OyBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1uZXRjb25mLiZuYnNwOyBJ
IGhhdmU8YnI+DQombmJzcDsgdXBkYXRlZCB0aGUgZGVzY3JpcHRpb24gaW4gdGhhdCBkcmFmdC5d
PGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA1IC0gdGVybWlub2xvZ3k8YnI+DQo8YnI+DQombmJz
cDsgVGhlIHRlcm0gJnF1b3Q7YWdlbnQmcXVvdDsgaXMgdXNlZCBhIGNvdXBsZSBvZiB0aW1lcy4m
bmJzcDsgVXNlICZxdW90O3B1Ymxpc2hlciZxdW90OyBvcjxicj4NCiZuYnNwOyAmcXVvdDtzZXJ2
ZXImcXVvdDsgaW5zdGVhZC48YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDUgLSBkYW1wZW5pbmc8
YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYgZGFtcGVu
aW5nLXBlcmlvZCB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgdHlwZSB5YW5nOnRpbWV0aWNrczs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBtYW5kYXRvcnkgdHJ1ZTs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7U2hv
dWxkIHRoaXMgaW5zdGVhZCBiZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IGxlYWYgZGFtcGVuaW5nLXBlcmlvZCB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSB5YW5nOnRpbWV0aWNrczs8YnI+DQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWZhdWx0ICZxdW90OzAmcXVvdDs7
PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1NvIHRoYXQgdGhlIHJlcXVlc3QgaXMgdGhlIHNhbWUg
aWYgdGhlICZxdW90O29uLWNoYW5nZSZxdW90OyBmZWF0dXJlIGlzPGJyPg0KJm5ic3A7ICZuYnNw
O3N1cHBvcnQgb3Igbm90Ljxicj4NCjxicj4NCjxicj4NCm8mbmJzcDsgNSAtIG5vLXN5bmNoLW9u
LXN0YXJ0PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7V2hlbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3ByZXNlbnQsIHB1c2hpbmcgYSBmdWxsIHNlbGVjdGlvbiBwZXIgdGhlIHRlcm1z
IG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO3NlbGVjdGlvbiBmaWx0ZXIgTUFZIE5PVCBiZSBkb25lIGZvciB0aGlzIHN1YnNjcmlwdGlv
bi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7RGlkIHlvdSBtZWFuIHMvTUFZIE5PVC9NVVNUIE5P
VC8gPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtNQVkgTk9UIGlzIG5vdCBhIDIxMTkgdGVybS48
YnI+DQo8YnI+DQo8YnI+DQpvJm5ic3A7IDUgLSBRb1M8YnI+DQo8YnI+DQombmJzcDsgV2h5IGFy
ZSB0aGUgcW9zIHBhcmFtZXRlcnMgZGVmaW5lZCBpbiB5YW5nIHB1c2gsIGFuZCBub3QgaW48YnI+
DQombmJzcDsgc3Vic2NyaWJlZCBub3RpZmljYXRpb25zPyZuYnNwOyBJdCBzZWVtcyB0aGF0IHRo
ZXkgYXJlIGdlbmVyaWMuPGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyA1IC0gZXN0YWJsaXNoLXN1
YnNjcmlwdGlvbiBwYXJhbXM8YnI+DQo8YnI+DQombmJzcDsgSSB0aGluayBhICZxdW90O3doZW4m
cXVvdDsgZXhwcmVzc2lvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGZpcnN0IGF1Z21lbnQ6PGJy
Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBhdWdtZW50ICZxdW90Oy9zbjplc3RhYmxpc2gtc3Vic2Ny
aXB0aW9uL3NuOmlucHV0JnF1b3Q7IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3aGVuICZx
dW90O3NuOnRhcmdldC95cDpkYXRhc3RvcmUveXA6c291cmNlJnF1b3Q7Ozxicj4NCjxicj4NCjxi
cj4NCm8mbmJzcDsgNSAtIHB1c2gtdXBkYXRlPGJyPg0KPGJyPg0KJm5ic3A7IFdoYXQgZG9lcyB0
aGUgcHJlc2VuY2Ugb2YgJnF1b3Q7dXBkYXRlcy1ub3Qtc2VudCZxdW90OyBtZWFuIGluICZxdW90
O3B1c2gtdXBkYXRlJnF1b3Q7Pzxicj4NCiZuYnNwOyAmcXVvdDtwdXNoLXVwZGF0ZSZxdW90OyBj
b250YWlucyBhIHNuYXBzaG90LCBub3QgYSBkaWZmLCBzbyB3aHkgaXM8YnI+DQombmJzcDsgJnF1
b3Q7dXBkYXRlcy1ub3Qtc2VudCZxdW90OyBwcmVzZW50Pzxicj4NCjxicj4NCjxicj4NCm8mbmJz
cDsgNSAtIHB1c2gtY2hhbmdlLXVwZGF0ZTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmcXVvdDtUaGlzIGNvbnRhaW5zIGFuIGluY3JlbWVudGFsIHNldCBvZiBkYXRhc3Rv
cmUgY2hhbmdlcyBuZWVkZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
dG8gdXBkYXRlIGEgcmVtb3RlIGRhdGFzdG9yZSBzdGFydGluZyBhdCB0aGUgdGltZSBvZiB0aGU8
YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJldmlvdXMgdXBkYXRlLCBw
ZXIgdGhlIHRlcm1zIG9mIHRoZSBzdWJzY3JpcHRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw
O1doYXQgaXMgYW4gJnF1b3Q7aW5jcmVtZW50YWwgc2V0JnF1b3Q7PyZuYnNwOyBQcm9iYWJseSBz
L2luY3JlbWVudGFsIHNldC9zZXQvPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KbyZuYnNwOyBHZW5l
cmFsPGJyPg0KPGJyPg0KJm5ic3A7IFVzZSBkb3VibGUgcXVvdGVzIGZvciBub2RlIG5hbWVzLiZu
YnNwOyAmcXVvdDtwdXNoLXVwZGF0ZSZxdW90OywgJnF1b3Q7c3Vic2NyaXB0aW9uLWlkJnF1b3Q7
PGJyPg0KJm5ic3A7IGV0Yy4mbmJzcDsgUXVvdGVzIGFyZSBjdXJyZW50bHkgdXNlZCBpbmNvbnNp
c3RlbnRseSwgYW5kIGl0IG1ha2VzIHRoZTxicj4NCiZuYnNwOyB0ZXh0IGhhcmRlciB0byByZWFk
Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCi9tYXJ0aW48YnI+DQo8YnI+DQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFp
bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZA
aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF783sjceml521mbxchi_--


From nobody Wed Nov 29 12:17:00 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C882126C83 for ; Wed, 29 Nov 2017 12:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uiDdG1xgM35 for ; Wed, 29 Nov 2017 12:16:44 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF73128D3E for ; Wed, 29 Nov 2017 12:16:44 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8CEDDEFF3843F for ; Wed, 29 Nov 2017 20:16:40 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 20:16:42 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 12:16:36 -0800
From: Alexander Clemm 
To: Andy Bierman , Martin Bjorklund 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLZk3nYyMWGUek3uLlVrh0YqMsMpiA//+ZgDA=
Date: Wed, 29 Nov 2017 20:16:36 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.194]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 20:16:47 -0000

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

SSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJpbmVkIGRhbXBlbmluZyBmb3Ig
YWxsIG9iamVjdHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4gIEluIHRoaXMgY2FzZSwgd2Ugd291bGQg
c2VuZCB1cGRhdGVzIGF0IDIsIDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAoY29udGFp
bmluZyAxMywgMTQsIDE1KS4NCg0KSWYgdGhlIHNjb3BlIG9mIHRoZSBzdWJzY3JpcHRpb24gYmVj
b21lcyBzdWZmaWNpZW50bHkgbGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVydHMgYmFjayB0byBhIHBl
cmlvZGljIHN1YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlzIGdvaW5nIHRvIGJlIGEg
Y2hhbmdlIHNvbWV3aGVyZSkuICBUaGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVkIHRvIGhh
dmUgaXQgaW5kZWVkIG9uIGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFyZ3Vt
ZW50LiAgRm9yIHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJlIGEgY2xpZW50IGlzIGlu
ZGVlZCBpbnRlcmVzdCBpbiBnZXR0aW5nIGRlbGF5cyBvZiBpbmRpdmlkdWFsIG9iamVjdHMgd2l0
aG91dCBkZWxheSwgIGEgY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaCBtdWx0
aXBsZSDigJxtaWNyb+KAnSBzdWJzY3JpcHRpb25zLg0KDQpUQ0FzIGluIFJNT04gYXJlIHNvbWV0
aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci4gIFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlp
bmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0IGZpbHRlcnMuDQoNCi0tLSBBbGV4DQoNCkZyb206IE5l
dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5
IEJpZXJtYW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMTA6MTggQU0NClRv
OiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCkNjOiBOZXRjb25mIDxuZXRjb25m
QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1u
ZXRjb25mLXlhbmctcHVzaC0xMQ0KDQoNCg0KT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBB
TSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29t
Pj4gd3JvdGU6DQpIaSwNCg0KLi4uLg0KDQpvICAzLjENCg0KICBJJ20gbm90IHN1cmUgSSB1bmRl
cnN0YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbmNlcHQuICBMZXQncw0KICBhc3N1bWUgdGhh
dCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMuICBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0DQog
IHRpbWVzOg0KDQogICAgMiAgMyAgNCAgMTEgIDEzICAxNCAgMTUNCg0KICBGcm9tIHRoZSBkZXNj
cmlwdGlvbiwgaXQgc2VlbXMgSSB3b3VsZCByZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbQ0K
ICB0aW1lczoNCg0KICAgIDIgIChjb250YWluaW5nIG9ubHkgY2hhbmdlIGZyb20gMikNCiAgICAx
MiAoY29udGFpbmluZyBjaGFuZ2UgZnJvbSAzLDQsMTEpDQogICAgMTMgKGNvbnRhaW5pbmcgb25s
eSBjaGFuZ2UgZnJvbSAxMykNCiAgICAyMyAoY29udGFpbmluZyBjaGFuZ2VzIGZyb20gMTQsMTUp
DQoNCiAgSXMgdGhpcyBjb3JyZWN0Pw0KDQogIEluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRl
c2NyaXB0aW9uIGluIHRoZSBZQU5HIG1vZHVsZSBpcw0KICBjbGFyaWZpZWQgLSBjdXJyZW50bHkg
dGhlIFJGQyB0ZXh0IGNvbnRhaW5zIG1vcmUgZGV0YWlscyB0aGFuIHRoZQ0KICBZQU5HIG1vZHVs
ZS4NCg0KDQoNClNlZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhl
IGRhbXBlbmluZyB0byBhcHBseQ0KdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBl
YWNoIG5vZGUgd2l0aGluIHRoZSBzdWJzY3JpcHRpb24uDQpJIHdhbnQgImF0IG1vc3QsIDEgbm90
aWZpY2F0aW9uIHBlciBzZWNvbmQiLiAgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudA0KdG8g
YmUgdG9sZCBhYm91dCBhbiBpbmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuICBJ
IGNvdWxkIHN0aWxsDQpnZXQgMTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQgZGF0
YSBub2Rlcy4gIFRoZSByZWNlaXZlciBkb2VzIG5vdA0KcmVhbGx5IGNhcmUgd2hldCBub2RlcyBh
cmUgYmVpbmcgcmVwb3J0ZWQgaW4gZWFjaCBub3RpZmljYXRpb24uIFRoZSBnb2FsDQppcyB0byBz
aW1wbHkgbGltaXQgdGhlIG5ldHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLg0KDQpGcm9tIGEgc2Vy
dmVyIFBPViwgSSBkbyBub3Qgd2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBpbnN0YW5j
ZQ0KYW5kIGNvbXBsZXggY29kZSB0byBjb25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlm
aWNhdGlvbi4NCg0KUk1PTiBoYW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5Lg0KVGhl
IHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJt
IGFuIGV2ZW50IHRyaWdnZXIuDQpUaGUgdGltZSBiZXR3ZWVuIGNoYW5nZXMgaXMgbm90IHVzZWQg
YXQgYWxsIHRvIGRldGVybWluZSBob3cgbWFueSBldmVudHMgdG8gc2VuZC4NCihOb3Qgc3VnZ2Vz
dGluZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2VkLikNCg0KSU1P
LCB0aGUgb3BlcmF0b3Igc2hvdWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5
IGludG8gYSBzZXBhcmF0ZSBzdWJzY3JpcHRpb24sDQphbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qg
c2hvdWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLg0KDQogLi4uDQoNCg0KDQoN
Ci9tYXJ0aW4NCg0KDQpBbmR5DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1h
aWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRjb25mDQoNCg==

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7sjceml521mbxchi_
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
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhvdWdodCB3ZSBkZWNpZGVkIHRoYXQg
d2UgaGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmplY3RzIGluIHRoZSBzdWJzY3Jp
cHRpb24uJm5ic3A7IEluIHRoaXMgY2FzZSwgd2Ugd291bGQgc2VuZCB1cGRhdGVzIGF0IDIsIDEy
IChjb250YWluaW5nIDMsNCwxMSksIGFuZA0KIDIyIChjb250YWluaW5nIDEzLCAxNCwgMTUpLiA8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBzY29wZSBv
ZiB0aGUgc3Vic2NyaXB0aW9uIGJlY29tZXMgc3VmZmljaWVudGx5IGxhcmdlLCB0aGlzIGFsbW9z
dCByZXZlcnRzIGJhY2sgdG8gYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24gKHNpbmNlIHRoZXJlIGlz
IGFsd2F5cyBnb2luZyB0byBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiZuYnNwOw0KIFRoaXMgaXMg
d2h5IEkgb3JpZ2luYWxseSBhcmd1ZWQgdG8gaGF2ZSBpdCBpbmRlZWQgb24gYSBwZXItb2JqZWN0
IGJhc2lzLCBidXQgSSBsb3N0IHRoYXQgYXJndW1lbnQuJm5ic3A7IEZvciBzdWNoIGZpbmUtZ3Jh
aW5lZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRlZWQgaW50ZXJlc3QgaW4gZ2V0dGlu
ZyBkZWxheXMgb2YgaW5kaXZpZHVhbCBvYmplY3RzIHdpdGhvdXQgZGVsYXksICZuYnNwO2EgY2xp
ZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaA0KIG11bHRpcGxlIOKAnG1pY3Jv4oCd
IHN1YnNjcmlwdGlvbnMuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+VENBcyBpbiBSTU9OIGFyZSBzb21ldGhpbmcgZGlmZmVyZW50IGFsdG9nZXRoZXIu
Jm5ic3A7IFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNt
YXJ0IGZpbHRlcnMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkg
Qmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDEw
OjE4IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1mLmNv
bSZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0
Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJqQHRhaWwt
Zi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpLDxicj4NCjxicj4N
Ci4uLi48YnI+DQo8YnI+DQpvJm5ic3A7IDMuMTxicj4NCjxicj4NCiZuYnNwOyBJJ20gbm90IHN1
cmUgSSB1bmRlcnN0YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbmNlcHQuJm5ic3A7IExldCdz
PGJyPg0KJm5ic3A7IGFzc3VtZSB0aGF0IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlzIDEwcy4mbmJz
cDsgVGhlbiBjaGFuZ2VzIGhhcHBlbiBhdDxicj4NCiZuYnNwOyB0aW1lczo8YnI+DQo8YnI+DQom
bmJzcDsgJm5ic3A7IDImbmJzcDsgMyZuYnNwOyA0Jm5ic3A7IDExJm5ic3A7IDEzJm5ic3A7IDE0
Jm5ic3A7IDE1PGJyPg0KPGJyPg0KJm5ic3A7IEZyb20gdGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVt
cyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9tPGJyPg0KJm5ic3A7IHRpbWVz
Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMiZuYnNwOyAoY29udGFpbmluZyBvbmx5IGNoYW5n
ZSBmcm9tIDIpPGJyPg0KJm5ic3A7ICZuYnNwOyAxMiAoY29udGFpbmluZyBjaGFuZ2UgZnJvbSAz
LDQsMTEpPGJyPg0KJm5ic3A7ICZuYnNwOyAxMyAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9t
IDEzKTxicj4NCiZuYnNwOyAmbmJzcDsgMjMgKGNvbnRhaW5pbmcgY2hhbmdlcyBmcm9tIDE0LDE1
KTxicj4NCjxicj4NCiZuYnNwOyBJcyB0aGlzIGNvcnJlY3Q/PGJyPg0KPGJyPg0KJm5ic3A7IElu
IGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRlc2NyaXB0aW9uIGluIHRoZSBZQU5HIG1vZHVsZSBp
czxicj4NCiZuYnNwOyBjbGFyaWZpZWQgLSBjdXJyZW50bHkgdGhlIFJGQyB0ZXh0IGNvbnRhaW5z
IG1vcmUgZGV0YWlscyB0aGFuIHRoZTxicj4NCiZuYnNwOyBZQU5HIG1vZHVsZS48YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U2VlbXMgdG8gbWUgKGZyb20gYSBjbGllbnQgUE9WKSB0aGF0IEkgd2FudCB0aGUg
ZGFtcGVuaW5nIHRvIGFwcGx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj50byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbiwgbm90IHRvIGVhY2ggbm9k
ZSB3aXRoaW4gdGhlIHN1YnNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FudCAmcXVvdDthdCBtb3N0LCAxIG5vdGlmaWNhdGlv
biBwZXIgc2Vjb25kJnF1b3Q7LiZuYnNwOyBJIGRvbid0IHNlZSB3aHkgSSB3b3VsZCB3YW50PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBiZSB0
b2xkIGFib3V0IGFuIGluZGl2aWR1YWwgZGF0YSBub2RlIG9uY2UgcGVyIHNlY29uZC4mbmJzcDsg
SSBjb3VsZCBzdGlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Z2V0IDEwLDAwMCBldmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEgbm9k
ZXMuJm5ic3A7IFRoZSByZWNlaXZlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVhbGx5IGNhcmUgd2hldCBub2RlcyBhcmUgYmVp
bmcgcmVwb3J0ZWQgaW4gZWFjaCBub3RpZmljYXRpb24uIFRoZSBnb2FsPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyB0byBzaW1wbHkgbGltaXQg
dGhlIG5ldHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIGEgc2VydmVyIFBPViwgSSBkbyBub3Qg
d2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBpbnN0YW5jZTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGNvbXBsZXggY29kZSB0byBj
b25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Uk1PTiBoYW5kbGVzIGRhbXBl
bmluZyB2ZXJ5IGRpZmZlcmVudGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1
c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFuIGV2ZW50IHRyaWdnZXIuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGltZSBiZXR3ZWVuIGNoYW5n
ZXMgaXMgbm90IHVzZWQgYXQgYWxsIHRvIGRldGVybWluZSBob3cgbWFueSBldmVudHMgdG8gc2Vu
ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihO
b3Qgc3VnZ2VzdGluZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2Vk
Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SU1PLCB0aGUgb3BlcmF0b3Igc2hvdWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRl
bmN5IGludG8gYSBzZXBhcmF0ZSBzdWJzY3JpcHRpb24sPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qgc2hv
dWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsuLi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQov
bWFydGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpO
ZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7sjceml521mbxchi_--


From nobody Wed Nov 29 16:51:34 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4030A1287A3 for ; Wed, 29 Nov 2017 16:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCSNTKzG5zJI for ; Wed, 29 Nov 2017 16:51:28 -0800 (PST)
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 2D0611287A0 for ; Wed, 29 Nov 2017 16:51:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25864; q=dns/txt; s=iport; t=1512003088; x=1513212688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8miLCNHTmBy8w73/0nOQP3iPXOwwK9CyaXCS49XcK68=; b=m+vVe7SQMkCB5EZgajTwvFQHjYQ0NtPZCytZllNTwYTmJVKizx3DBVdf yvSntLufXIt+9MLWfmYTakZvT5QS9+LyqjOO0C28eVclEX3wl5/3/b8eV DR431sRpjEUYJMhJQf7bmXKiUDiF5FeIOIWhUbRoZs4Iwtax0e/4MFKRR Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAAAKVR9a/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeIogjnGBfZZ0EIIBChgBCoRJTwIahHs/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEBAwEBIQpBCxACAQgRBAEBDhoDAgICJQsUCQgCBAENBQiJN?= =?us-ascii?q?mQQpyaCJ4plAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJgVaBaYMrhHoPAS0?= =?us-ascii?q?fgl+CYwWiTQKLXIkngh+RO4o5i1wCERkBgTkBHzkmgStvFTqCKYRVd4cxgTKBF?= =?us-ascii?q?AEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200";  d="scan'208,217";a="326632980"
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; 30 Nov 2017 00:51:25 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vAU0pPKH001142 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 00:51:25 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 19:51:24 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 19:51:24 -0500
From: "Eric Voit (evoit)" 
To: Alexander Clemm , Andy Bierman , Martin Bjorklund , "kwatsen@juniper.net" 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLQRPr9GM9Jka7UxKyCaa4a6MsMpiA//+ZgDCAAEyf8A==
Date: Thu, 30 Nov 2017 00:51:24 +0000
Message-ID: <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_4c09b3525b78410da242149893593159XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 00:51:30 -0000

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

VGhlIFNlY3Rpb24gMy4xIHRleHQgSSBwcm9wb3NlZCBpbiBteSByZXNwb25zZSB0byBNYXJ0aW4g
b24gdGhlIGRhbXBlbmluZyBxdWVzdGlvbjoNCg0KDQpEYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBv
bi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBkZXRlY3RlZCBvYmplY3QgY2hhbmdlcyBzaG91bGQgYmUg
c2VudCBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiAgSG93ZXZlciB3aXRob3V0IGFkZXF1YXRlIHBy
b3RlY3Rpb25zLCBhIHJhcGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdlcyBtaWdodCBleGhhdXN0
IG9mIHJlc291cmNlcyBpbiB0aGUgcHVibGlzaGVyIG9yIHJlY2VpdmVyLiAgSW4gb3JkZXIgdG8g
cHJvdGVjdCBhZ2FpbnN0IHRoYXQsIGEgZGFtcGVuaW5nIHBlcmlvZCBNQVkgYmUgdXNlZCB0byBz
cGVjaWZ5IHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBk
YXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBh
IHJlY2VpdmVyLiAgVGhlIGRhbXBlbmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMgdG8g
dGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxlY3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRp
b24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuICBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0
aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3Jk
IGNvbnRhaW5pbmcgdGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hl
biBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRh
bXBlbmluZyBwZXJpb2QuICBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBh
IG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0Lg0KDQoNCg0K
V2l0aCB0aGUgWUFORyBkZXNjcmlwdGlvbiBvZjoNCg0KDQoNCiJTcGVjaWZpZXMgdGhlIGludGVy
dmFsIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3Ig
dGhlIHNhbWUgc3Vic2NyaXB0aW9uIGFyZSBnZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuICBUaGUg
ZGFtcGVuaW5nIHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBk
YXRhIG5vZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBh
IHNpbmdsZSByZWNlaXZlci4gIFRoaXMgbWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdl
IHRvIGEgc3Vic2NyaWJlZCBvYmplY3QsIGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0
IG9iamVjdCBpcyBjcmVhdGVkIGVpdGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBw
ZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBhdCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nIHBlcmlvZC4g
IEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlv
biBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuICBBIGRhbXBlbmluZyBwZXJpb2QgaXMg
cmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8g
dHJhbnNwb3J0LiAgQSB6ZXJvIHZhbHVlIGluZGljYXRlcyBubyBkYW1wZW5pbmcgcGVyaW9kLCBh
bmQgYWxsIHN1YnNjcmliZWQgb2JqZWN0IGNoYW5nZXMgYXJlIHNlbnQgaW1tZWRpYXRlbHkuIg0K
DQpEb2VzIHRoaXMgd29yayBmb3IgZXZlcnlvbmU/DQoNCkVyaWMNCg0KDQpGcm9tOiBOZXRjb25m
IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZGVy
IENsZW1tDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDM6MTcgUE0NClRvOiBB
bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0
YWlsLWYuY29tPg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
W05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNCkkg
dGhvdWdodCB3ZSBkZWNpZGVkIHRoYXQgd2UgaGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFs
bCBvYmplY3RzIGluIHRoZSBzdWJzY3JpcHRpb24uICBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIHNl
bmQgdXBkYXRlcyBhdCAyLCAxMiAoY29udGFpbmluZyAzLDQsMTEpLCBhbmQgMjIgKGNvbnRhaW5p
bmcgMTMsIDE0LCAxNSkuDQoNCklmIHRoZSBzY29wZSBvZiB0aGUgc3Vic2NyaXB0aW9uIGJlY29t
ZXMgc3VmZmljaWVudGx5IGxhcmdlLCB0aGlzIGFsbW9zdCByZXZlcnRzIGJhY2sgdG8gYSBwZXJp
b2RpYyBzdWJzY3JpcHRpb24gKHNpbmNlIHRoZXJlIGlzIGFsd2F5cyBnb2luZyB0byBiZSBhIGNo
YW5nZSBzb21ld2hlcmUpLiAgVGhpcyBpcyB3aHkgSSBvcmlnaW5hbGx5IGFyZ3VlZCB0byBoYXZl
IGl0IGluZGVlZCBvbiBhIHBlci1vYmplY3QgYmFzaXMsIGJ1dCBJIGxvc3QgdGhhdCBhcmd1bWVu
dC4gIEZvciBzdWNoIGZpbmUtZ3JhaW5lZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRl
ZWQgaW50ZXJlc3QgaW4gZ2V0dGluZyBkZWxheXMgb2YgaW5kaXZpZHVhbCBvYmplY3RzIHdpdGhv
dXQgZGVsYXksICBhIGNsaWVudCBjb3VsZCBzaW1wbHkgbmVlZCB0byBlc3RhYmxpc2ggbXVsdGlw
bGUg4oCcbWljcm/igJ0gc3Vic2NyaXB0aW9ucy4NCg0KVENBcyBpbiBSTU9OIGFyZSBzb21ldGhp
bmcgZGlmZmVyZW50IGFsdG9nZXRoZXIuICBUaGlzIGlzIHNvbWV0aGluZyB3ZSBhcmUgdHJ5aW5n
IHRvIGFkZHJlc3Mgd2l0aCBzbWFydCBmaWx0ZXJzLg0KDQotLS0gQWxleA0KDQoNCkZyb206IE5l
dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5
IEJpZXJtYW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMTA6MTggQU0NClRv
OiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+
Pg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+
Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlh
bmctcHVzaC0xMQ0KDQoNCg0KT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGlu
IEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6
DQpIaSwNCg0KLi4uLg0KDQpvICAzLjENCg0KICBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRo
ZSBkYW1wZW5pbmcgcGVyaW9kIGNvbmNlcHQuICBMZXQncw0KICBhc3N1bWUgdGhhdCB0aGUgZGFt
cGVuaW5nIHBlcmlvZCBpcyAxMHMuICBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0DQogIHRpbWVzOg0K
DQogICAgMiAgMyAgNCAgMTEgIDEzICAxNCAgMTUNCg0KICBGcm9tIHRoZSBkZXNjcmlwdGlvbiwg
aXQgc2VlbXMgSSB3b3VsZCByZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbQ0KICB0aW1lczoN
Cg0KICAgIDIgIChjb250YWluaW5nIG9ubHkgY2hhbmdlIGZyb20gMikNCiAgICAxMiAoY29udGFp
bmluZyBjaGFuZ2UgZnJvbSAzLDQsMTEpDQogICAgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2Ug
ZnJvbSAxMykNCiAgICAyMyAoY29udGFpbmluZyBjaGFuZ2VzIGZyb20gMTQsMTUpDQoNCiAgSXMg
dGhpcyBjb3JyZWN0Pw0KDQogIEluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRlc2NyaXB0aW9u
IGluIHRoZSBZQU5HIG1vZHVsZSBpcw0KICBjbGFyaWZpZWQgLSBjdXJyZW50bHkgdGhlIFJGQyB0
ZXh0IGNvbnRhaW5zIG1vcmUgZGV0YWlscyB0aGFuIHRoZQ0KICBZQU5HIG1vZHVsZS4NCg0KDQpT
ZWVtcyB0byBtZSAoZnJvbSBhIGNsaWVudCBQT1YpIHRoYXQgSSB3YW50IHRoZSBkYW1wZW5pbmcg
dG8gYXBwbHkNCnRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLCBub3QgdG8gZWFjaCBub2RlIHdp
dGhpbiB0aGUgc3Vic2NyaXB0aW9uLg0KSSB3YW50ICJhdCBtb3N0LCAxIG5vdGlmaWNhdGlvbiBw
ZXIgc2Vjb25kIi4gIEkgZG9uJ3Qgc2VlIHdoeSBJIHdvdWxkIHdhbnQNCnRvIGJlIHRvbGQgYWJv
dXQgYW4gaW5kaXZpZHVhbCBkYXRhIG5vZGUgb25jZSBwZXIgc2Vjb25kLiAgSSBjb3VsZCBzdGls
bA0KZ2V0IDEwLDAwMCBldmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEgbm9kZXMuICBU
aGUgcmVjZWl2ZXIgZG9lcyBub3QNCnJlYWxseSBjYXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJl
cG9ydGVkIGluIGVhY2ggbm90aWZpY2F0aW9uLiBUaGUgZ29hbA0KaXMgdG8gc2ltcGx5IGxpbWl0
IHRoZSBuZXR3b3JrIGFuZCBwcm9jZXNzb3IgbG9hZC4NCg0KRnJvbSBhIHNlcnZlciBQT1YsIEkg
ZG8gbm90IHdhbnQgYSB0aW1lciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2UNCmFuZCBjb21w
bGV4IGNvZGUgdG8gY29uc3RydWN0IHRoZSBuZXh0IG9uLWNoYW5nZSBub3RpZmljYXRpb24uDQoN
ClJNT04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBkaWZmZXJlbnRseS4NClRoZSByaXNpbmcgYW5k
IGZhbGxpbmcgdGhyZXNob2xkcyBhcmUgdXNlZCB0byBhcm0gYW5kIHJlLWFybSBhbiBldmVudCB0
cmlnZ2VyLg0KVGhlIHRpbWUgYmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1c2VkIGF0IGFsbCB0byBk
ZXRlcm1pbmUgaG93IG1hbnkgZXZlbnRzIHRvIHNlbmQuDQooTm90IHN1Z2dlc3RpbmcgYWxsIHlh
bmctcHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4pDQoNCklNTywgdGhlIG9wZXJh
dG9yIHNob3VsZCBwdXQgZXZlbnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRvIGEgc2Vw
YXJhdGUgc3Vic2NyaXB0aW9uLA0KYW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBs
eSB0byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbi4NCg0KIC4uLg0KDQoNCg0KDQovbWFydGluDQoN
Cg0KQW5keQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29u
ZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u
Zg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu
VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ
e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt
YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s
ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5
bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRD
aGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5UaGUgU2VjdGlvbiAzLjEgdGV4dCBJIHByb3Bvc2VkIGluIG15IHJlc3BvbnNlIHRvIE1h
cnRpbiBvbiB0aGUgZGFtcGVuaW5nIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EYW1wZW5pbmcg
cGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBkZXRlY3RlZCBvYmplY3QgY2hh
bmdlcyBzaG91bGQgYmUgc2VudCBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiZuYnNwOyBIb3dldmVy
IHdpdGhvdXQgYWRlcXVhdGUgcHJvdGVjdGlvbnMsIGEgcmFwaWQgc2VyaWVzIG9mIG9iamVjdCBj
aGFuZ2VzIG1pZ2h0IGV4aGF1c3Qgb2YgcmVzb3VyY2VzIGluIHRoZSBwdWJsaXNoZXIgb3IgcmVj
ZWl2ZXIuJm5ic3A7DQogSW4gb3JkZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoYXQsIGEgZGFtcGVu
aW5nIHBlcmlvZCBNQVkgYmUgdXNlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0
IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNj
cmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiZuYnNwOyBUaGUgZGFtcGVuaW5n
IHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhDQogbm9k
ZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xl
IHJlY2VpdmVyLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0
byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhhdCBv
YmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcgcGVy
aW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZA0KIG9mIGEgZGFtcGVuaW5nIHBlcmlvZC4m
bmJzcDsgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZp
Y2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+V2l0aCB0aGUgWUFORyBkZXNjcmlwdGlvbiBvZjo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZxdW90O1NwZWNpZmllcyB0aGUgaW50ZXJ2YWwg
d2hpY2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUg
c2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4mbmJzcDsgVGhl
IGRhbXBlbmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwg
ZGF0YSBub2RlcyBzZWxlY3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24NCiBhbmQgc2VudCB0
byBhIHNpbmdsZSByZWNlaXZlci4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMg
YSBjaGFuZ2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWlu
aW5nIHRoYXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFt
cGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5pbmcg
cGVyaW9kLiZuYnNwOyBBIGRhbXBlbmluZyBwZXJpb2QNCiBpcyByZXNldCBldmVyeSB0aW1lIGEg
bmV3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuJm5ic3A7IEEg
ZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlvbiBt
ZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuJm5ic3A7IEEgemVybyB2YWx1ZSBpbmRpY2F0
ZXMgbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBzdWJzY3JpYmVkIG9iamVjdCBjaGFuZ2Vz
IGFyZSBzZW50IGltbWVkaWF0ZWx5LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG9lcyB0aGlzIHdvcmsgZm9yIGV2ZXJ5b25lPzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj48YnI+DQpFcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh
bGYgT2YgPC9iPkFsZXhhbmRlciBDbGVtbTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5v
dmVtYmVyIDI5LCAyMDE3IDM6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHkgQmllcm1hbiAmbHQ7
YW5keUB5dW1hd29ya3MuY29tJmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5j
b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5l
dGNvbmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhvdWdodCB3ZSBkZWNp
ZGVkIHRoYXQgd2UgaGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmplY3RzIGluIHRo
ZSBzdWJzY3JpcHRpb24uJm5ic3A7IEluIHRoaXMgY2FzZSwgd2Ugd291bGQgc2VuZCB1cGRhdGVz
IGF0IDIsIDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZA0KIDIyIChjb250YWluaW5nIDEzLCAx
NCwgMTUpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRo
ZSBzY29wZSBvZiB0aGUgc3Vic2NyaXB0aW9uIGJlY29tZXMgc3VmZmljaWVudGx5IGxhcmdlLCB0
aGlzIGFsbW9zdCByZXZlcnRzIGJhY2sgdG8gYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24gKHNpbmNl
IHRoZXJlIGlzIGFsd2F5cyBnb2luZyB0byBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiZuYnNwOw0K
IFRoaXMgaXMgd2h5IEkgb3JpZ2luYWxseSBhcmd1ZWQgdG8gaGF2ZSBpdCBpbmRlZWQgb24gYSBw
ZXItb2JqZWN0IGJhc2lzLCBidXQgSSBsb3N0IHRoYXQgYXJndW1lbnQuJm5ic3A7IEZvciBzdWNo
IGZpbmUtZ3JhaW5lZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRlZWQgaW50ZXJlc3Qg
aW4gZ2V0dGluZyBkZWxheXMgb2YgaW5kaXZpZHVhbCBvYmplY3RzIHdpdGhvdXQgZGVsYXksICZu
YnNwO2EgY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaA0KIG11bHRpcGxlIOKA
nG1pY3Jv4oCdIHN1YnNjcmlwdGlvbnMuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+VENBcyBpbiBSTU9OIGFyZSBzb21ldGhpbmcgZGlmZmVyZW50IGFs
dG9nZXRoZXIuJm5ic3A7IFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVz
cyB3aXRoIHNtYXJ0IGZpbHRlcnMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg
I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B
bmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAx
NyAxMDoxOCBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6
PC9iPiBOZXRjb25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29u
ZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2
aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwg
TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+
DQouLi4uPGJyPg0KPGJyPg0KbyZuYnNwOyAzLjE8YnI+DQo8YnI+DQombmJzcDsgSSdtIG5vdCBz
dXJlIEkgdW5kZXJzdGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LiZuYnNwOyBMZXQn
czxicj4NCiZuYnNwOyBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMuJm5i
c3A7IFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQ8YnI+DQombmJzcDsgdGltZXM6PGJyPg0KPGJyPg0K
Jm5ic3A7ICZuYnNwOyAyJm5ic3A7IDMmbmJzcDsgNCZuYnNwOyAxMSZuYnNwOyAxMyZuYnNwOyAx
NCZuYnNwOyAxNTxicj4NCjxicj4NCiZuYnNwOyBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQgc2Vl
bXMgSSB3b3VsZCByZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbTxicj4NCiZuYnNwOyB0aW1l
czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDImbmJzcDsgKGNvbnRhaW5pbmcgb25seSBjaGFu
Z2UgZnJvbSAyKTxicj4NCiZuYnNwOyAmbmJzcDsgMTIgKGNvbnRhaW5pbmcgY2hhbmdlIGZyb20g
Myw0LDExKTxicj4NCiZuYnNwOyAmbmJzcDsgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJv
bSAxMyk8YnI+DQombmJzcDsgJm5ic3A7IDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwx
NSk8YnI+DQo8YnI+DQombmJzcDsgSXMgdGhpcyBjb3JyZWN0Pzxicj4NCjxicj4NCiZuYnNwOyBJ
biBhbnkgY2FzZSwgSSBzdWdnZXN0IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgWUFORyBtb2R1bGUg
aXM8YnI+DQombmJzcDsgY2xhcmlmaWVkIC0gY3VycmVudGx5IHRoZSBSRkMgdGV4dCBjb250YWlu
cyBtb3JlIGRldGFpbHMgdGhhbiB0aGU8YnI+DQombmJzcDsgWUFORyBtb2R1bGUuPG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl
ZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0
byBhcHBseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+dG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNoIG5vZGUgd2l0aGluIHRo
ZSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIHdhbnQgJnF1b3Q7YXQgbW9zdCwgMSBub3RpZmljYXRpb24gcGVyIHNlY29u
ZCZxdW90Oy4mbmJzcDsgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudDxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gYmUgdG9sZCBhYm91dCBh
biBpbmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuJm5ic3A7IEkgY291bGQgc3Rp
bGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdl
dCAxMCwwMDAgZXZlbnRzL3NlYyBidXQgZm9yIGRpZmZlcmVudCBkYXRhIG5vZGVzLiZuYnNwOyBU
aGUgcmVjZWl2ZXIgZG9lcyBub3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPnJlYWxseSBjYXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJlcG9ydGVk
IGluIGVhY2ggbm90aWZpY2F0aW9uLiBUaGUgZ29hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgdG8gc2ltcGx5IGxpbWl0IHRoZSBuZXR3b3Jr
IGFuZCBwcm9jZXNzb3IgbG9hZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhIHNlcnZlciBQT1YsIEkgZG8gbm90IHdhbnQgYSB0aW1l
ciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBjb21wbGV4IGNvZGUgdG8gY29uc3RydWN0IHRo
ZSBuZXh0IG9uLWNoYW5nZSBub3RpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJNT04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBk
aWZmZXJlbnRseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoZSByaXNpbmcgYW5kIGZhbGxpbmcgdGhyZXNob2xkcyBhcmUgdXNlZCB0byBhcm0g
YW5kIHJlLWFybSBhbiBldmVudCB0cmlnZ2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRpbWUgYmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1
c2VkIGF0IGFsbCB0byBkZXRlcm1pbmUgaG93IG1hbnkgZXZlbnRzIHRvIHNlbmQuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTm90IHN1Z2dlc3Rp
bmcgYWxsIHlhbmctcHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4pPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTywgdGhlIG9w
ZXJhdG9yIHNob3VsZCBwdXQgZXZlbnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRvIGEg
c2VwYXJhdGUgc3Vic2NyaXB0aW9uLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBseSB0
byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KL21hcnRpbjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRm
Lm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_4c09b3525b78410da242149893593159XCHRTP013ciscocom_--


From nobody Wed Nov 29 16:59:38 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DAF1286B1 for ; Wed, 29 Nov 2017 16:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VdX7DzzFbZS for ; Wed, 29 Nov 2017 16:59:31 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B13124D6C for ; Wed, 29 Nov 2017 16:59:31 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9EC07B634B6E8 for ; Thu, 30 Nov 2017 00:59:26 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 00:59:28 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 16:59:24 -0800
From: Alexander Clemm 
To: "Eric Voit (evoit)" , Andy Bierman ,  Martin Bjorklund , "kwatsen@juniper.net" 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLZk3nYyMWGUek3uLlVrh0YqMsMpiA//+ZgDCAANRbAP//e4mw
Date: Thu, 30 Nov 2017 00:59:24 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com>
In-Reply-To: <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.194]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95Csjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 00:59:37 -0000

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

VGhpcyB3b3JrcyBmb3IgbWUuICBQZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0gd2UgbWlnaHQg
YWRkIChmb3IgY3J5c3RhbC1jbGVhciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdoZW4gdGhlIG5v
dGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBtb3N0IHJlY2VudCB1
cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZSB2YWx1ZSB0aGF0IGlzIGluIGVmZmVjdCB3
aGVuIHRoZSB1cGRhdGUgaXMgc2VudCkuICBJZiB0aGVyZSBhcmUgc29tZSBxdWlja2x5IG9zY2ls
bGF0aW5nIHZhbHVlcyB3ZSBkb27igJl0IHNlbmQgdGhlIHdob2xlIHNlcXVlbmNlIG9mIHVwZGF0
ZXMvdmFsdWVzLg0KDQotLS0gQWxleA0KDQpGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRv
OmV2b2l0QGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgNDo1
MSBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBB
bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0
YWlsLWYuY29tPjsga3dhdHNlbkBqdW5pcGVyLm5ldA0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0
Zi5vcmc+DQpTdWJqZWN0OiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNv
bmYteWFuZy1wdXNoLTExDQoNClRoZSBTZWN0aW9uIDMuMSB0ZXh0IEkgcHJvcG9zZWQgaW4gbXkg
cmVzcG9uc2UgdG8gTWFydGluIG9uIHRoZSBkYW1wZW5pbmcgcXVlc3Rpb246DQoNCg0KRGFtcGVu
aW5nIHBlcmlvZDogSW4gYW4gb24tY2hhbmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0
IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4gIEhvd2V2ZXIg
d2l0aG91dCBhZGVxdWF0ZSBwcm90ZWN0aW9ucywgYSByYXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNo
YW5nZXMgbWlnaHQgZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNl
aXZlci4gIEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRhbXBlbmluZyBwZXJp
b2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJl
Zm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb24g
YXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4gIFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxl
Y3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkg
YSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiAgVGhp
cyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgdG8gYSBzdWJzY3JpYmVkIG9iamVj
dCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRoYXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0
aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9y
IGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlz
IHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRv
IHRyYW5zcG9ydC4NCg0KDQoNCldpdGggdGhlIFlBTkcgZGVzY3JpcHRpb24gb2Y6DQoNCg0KDQoi
U3BlY2lmaWVzIHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUg
dXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZv
ciBhIHJlY2VpdmVyLiAgVGhlIGRhbXBlbmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMg
dG8gdGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxlY3RlZCBieSBhIHNpbmdsZSBzdWJzY3Jp
cHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuICBUaGlzIG1lYW5zIHRoYXQgd2hl
biB0aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVj
b3JkIGNvbnRhaW5pbmcgdGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkg
d2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBh
IGRhbXBlbmluZyBwZXJpb2QuICBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGlt
ZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0LiAgQSBk
YW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1l
c3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4gIEEgemVybyB2YWx1ZSBpbmRpY2F0ZXMgbm8g
ZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBzdWJzY3JpYmVkIG9iamVjdCBjaGFuZ2VzIGFyZSBz
ZW50IGltbWVkaWF0ZWx5LiINCg0KDQoNCkRvZXMgdGhpcyB3b3JrIGZvciBldmVyeW9uZT8NCg0K
RXJpYw0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgQ2xlbW0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIg
MjksIDIwMTcgMzoxNyBQTQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1h
aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5j
b208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4NCkNjOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3Jn
PG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3
IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTENCg0KSSB0aG91Z2h0IHdlIGRlY2lk
ZWQgdGhhdCB3ZSBoYXZlIGNvbWJpbmVkIGRhbXBlbmluZyBmb3IgYWxsIG9iamVjdHMgaW4gdGhl
IHN1YnNjcmlwdGlvbi4gIEluIHRoaXMgY2FzZSwgd2Ugd291bGQgc2VuZCB1cGRhdGVzIGF0IDIs
IDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAoY29udGFpbmluZyAxMywgMTQsIDE1KS4N
Cg0KSWYgdGhlIHNjb3BlIG9mIHRoZSBzdWJzY3JpcHRpb24gYmVjb21lcyBzdWZmaWNpZW50bHkg
bGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVydHMgYmFjayB0byBhIHBlcmlvZGljIHN1YnNjcmlwdGlv
biAoc2luY2UgdGhlcmUgaXMgYWx3YXlzIGdvaW5nIHRvIGJlIGEgY2hhbmdlIHNvbWV3aGVyZSku
ICBUaGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVkIHRvIGhhdmUgaXQgaW5kZWVkIG9uIGEg
cGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFyZ3VtZW50LiAgRm9yIHN1Y2ggZmlu
ZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJlIGEgY2xpZW50IGlzIGluZGVlZCBpbnRlcmVzdCBpbiBn
ZXR0aW5nIGRlbGF5cyBvZiBpbmRpdmlkdWFsIG9iamVjdHMgd2l0aG91dCBkZWxheSwgIGEgY2xp
ZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaCBtdWx0aXBsZSDigJxtaWNyb+KAnSBz
dWJzY3JpcHRpb25zLg0KDQpUQ0FzIGluIFJNT04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0
b2dldGhlci4gIFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRo
IHNtYXJ0IGZpbHRlcnMuDQoNCi0tLSBBbGV4DQoNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDog
V2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMDoxOCBBTQ0KVG86IE1hcnRpbiBCam9ya2x1
bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+DQpDYzogTmV0Y29uZiA8
bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog
W05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNCg0K
DQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCAxOjM3IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA
dGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCkhpLA0KDQouLi4uDQoN
Cm8gIDMuMQ0KDQogIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGRhbXBlbmluZyBwZXJp
b2QgY29uY2VwdC4gIExldCdzDQogIGFzc3VtZSB0aGF0IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlz
IDEwcy4gIFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQNCiAgdGltZXM6DQoNCiAgICAyICAzICA0ICAx
MSAgMTMgIDE0ICAxNQ0KDQogIEZyb20gdGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxk
IHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9tDQogIHRpbWVzOg0KDQogICAgMiAgKGNvbnRh
aW5pbmcgb25seSBjaGFuZ2UgZnJvbSAyKQ0KICAgIDEyIChjb250YWluaW5nIGNoYW5nZSBmcm9t
IDMsNCwxMSkNCiAgICAxMyAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDEzKQ0KICAgIDIz
IChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwxNSkNCg0KICBJcyB0aGlzIGNvcnJlY3Q/DQoN
CiAgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIFlBTkcgbW9k
dWxlIGlzDQogIGNsYXJpZmllZCAtIGN1cnJlbnRseSB0aGUgUkZDIHRleHQgY29udGFpbnMgbW9y
ZSBkZXRhaWxzIHRoYW4gdGhlDQogIFlBTkcgbW9kdWxlLg0KDQoNClNlZW1zIHRvIG1lIChmcm9t
IGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBseQ0KdG8gdGhl
IGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNoIG5vZGUgd2l0aGluIHRoZSBzdWJzY3Jp
cHRpb24uDQpJIHdhbnQgImF0IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQiLiAgSSBk
b24ndCBzZWUgd2h5IEkgd291bGQgd2FudA0KdG8gYmUgdG9sZCBhYm91dCBhbiBpbmRpdmlkdWFs
IGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuICBJIGNvdWxkIHN0aWxsDQpnZXQgMTAsMDAwIGV2
ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQgZGF0YSBub2Rlcy4gIFRoZSByZWNlaXZlciBkb2Vz
IG5vdA0KcmVhbGx5IGNhcmUgd2hldCBub2RlcyBhcmUgYmVpbmcgcmVwb3J0ZWQgaW4gZWFjaCBu
b3RpZmljYXRpb24uIFRoZSBnb2FsDQppcyB0byBzaW1wbHkgbGltaXQgdGhlIG5ldHdvcmsgYW5k
IHByb2Nlc3NvciBsb2FkLg0KDQpGcm9tIGEgc2VydmVyIFBPViwgSSBkbyBub3Qgd2FudCBhIHRp
bWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBpbnN0YW5jZQ0KYW5kIGNvbXBsZXggY29kZSB0byBjb25z
dHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbi4NCg0KUk1PTiBoYW5kbGVzIGRh
bXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5Lg0KVGhlIHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hv
bGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFuIGV2ZW50IHRyaWdnZXIuDQpUaGUgdGlt
ZSBiZXR3ZWVuIGNoYW5nZXMgaXMgbm90IHVzZWQgYXQgYWxsIHRvIGRldGVybWluZSBob3cgbWFu
eSBldmVudHMgdG8gc2VuZC4NCihOb3Qgc3VnZ2VzdGluZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNl
cyBhcmUgdGhyZXNob2xkLWJhc2VkLikNCg0KSU1PLCB0aGUgb3BlcmF0b3Igc2hvdWxkIHB1dCBl
dmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5IGludG8gYSBzZXBhcmF0ZSBzdWJzY3JpcHRp
b24sDQphbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qgc2hvdWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUg
c3Vic2NyaXB0aW9uLg0KDQogLi4uDQoNCg0KDQoNCi9tYXJ0aW4NCg0KDQpBbmR5DQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFp
bGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg==

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95Csjceml521mbxchi_
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
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku
TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi
UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu
bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h
bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow
aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv
bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5
bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu
IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0
aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo
aXMgd29ya3MgZm9yIG1lLiZuYnNwOyBQZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0gd2UgbWln
aHQgYWRkIChmb3IgY3J5c3RhbC1jbGVhciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdoZW4gdGhl
IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZQ0KIG1vc3QgcmVj
ZW50IHVwZGF0ZSBmb3IgdGhhdCBvYmplY3QgKGkuZS4gdGhlIHZhbHVlIHRoYXQgaXMgaW4gZWZm
ZWN0IHdoZW4gdGhlIHVwZGF0ZSBpcyBzZW50KS4mbmJzcDsgSWYgdGhlcmUgYXJlIHNvbWUgcXVp
Y2tseSBvc2NpbGxhdGluZyB2YWx1ZXMgd2UgZG9u4oCZdCBzZW5kIHRoZSB3aG9sZSBzZXF1ZW5j
ZSBvZiB1cGRhdGVzL3ZhbHVlcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMgVm9pdCAoZXZvaXQpIFtt
YWlsdG86ZXZvaXRAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92
ZW1iZXIgMjksIDIwMTcgNDo1MSBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVyIENsZW1tICZs
dDthbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSZndDs7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5
dW1hd29ya3MuY29tJmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7
OyBrd2F0c2VuQGp1bmlwZXIubmV0PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDtuZXRjb25m
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW05ldGNvbmZdIHJldmlldyBv
ZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo
ZSBTZWN0aW9uIDMuMSB0ZXh0IEkgcHJvcG9zZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9u
IHRoZSBkYW1wZW5pbmcgcXVlc3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRhbXBlbmluZyBwZXJpb2Q6
IEluIGFuIG9uLWNoYW5nZSBzdWJzY3JpcHRpb24sIGRldGVjdGVkIG9iamVjdCBjaGFuZ2VzIHNo
b3VsZCBiZSBzZW50IGFzIHF1aWNrbHkgYXMgcG9zc2libGUuJm5ic3A7IEhvd2V2ZXIgd2l0aG91
dCBhZGVxdWF0ZSBwcm90ZWN0aW9ucywgYSByYXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNoYW5nZXMg
bWlnaHQgZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4m
bmJzcDsNCiBJbiBvcmRlciB0byBwcm90ZWN0IGFnYWluc3QgdGhhdCwgYSBkYW1wZW5pbmcgcGVy
aW9kIE1BWSBiZSB1c2VkIHRvIHNwZWNpZnkgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBi
ZWZvcmUgc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUgc3Vic2NyaXB0aW9u
IGFyZSBnZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9k
IGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGENCiBub2RlcyBzZWxl
Y3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2
ZXIuJm5ic3A7IFRoaXMgbWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIGEgc3Vi
c2NyaWJlZCBvYmplY3QsIGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBp
cyBjcmVhdGVkIGVpdGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMg
aW4gZWZmZWN0LCBvciBhdCB0aGUgZW5kDQogb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyBB
IGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24g
bWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj5XaXRoIHRoZSBZQU5HIGRlc2NyaXB0aW9uIG9mOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7U3BlY2lmaWVzIHRoZSBpbnRlcnZhbCB3aGljaCBt
dXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1
YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiZuYnNwOyBUaGUgZGFtcGVu
aW5nIHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhIG5v
ZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbg0KIGFuZCBzZW50IHRvIGEgc2lu
Z2xlIHJlY2VpdmVyLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5n
ZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhh
dCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcg
cGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2Qu
Jm5ic3A7IEEgZGFtcGVuaW5nIHBlcmlvZA0KIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90
aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4mbmJzcDsgQSBkYW1wZW5p
bmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2Ug
aXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4mbmJzcDsgQSB6ZXJvIHZhbHVlIGluZGljYXRlcyBubyBk
YW1wZW5pbmcgcGVyaW9kLCBhbmQgYWxsIHN1YnNjcmliZWQgb2JqZWN0IGNoYW5nZXMgYXJlIHNl
bnQgaW1tZWRpYXRlbHkuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Eb2VzIHRoaXMgd29yayBmb3IgZXZlcnlvbmU/PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPjxicj4NCkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0
LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bWFp
bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFs
ZXhhbmRlciBDbGVtbTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAy
MDE3IDM6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs7IE1hcnRp
biBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwt
Zi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRv
Om5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1w
dXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhvdWdodCB3ZSBkZWNpZGVkIHRoYXQgd2Ug
aGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmplY3RzIGluIHRoZSBzdWJzY3JpcHRp
b24uJm5ic3A7IEluIHRoaXMgY2FzZSwgd2Ugd291bGQgc2VuZCB1cGRhdGVzIGF0IDIsIDEyIChj
b250YWluaW5nIDMsNCwxMSksIGFuZA0KIDIyIChjb250YWluaW5nIDEzLCAxNCwgMTUpLiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBzY29wZSBvZiB0
aGUgc3Vic2NyaXB0aW9uIGJlY29tZXMgc3VmZmljaWVudGx5IGxhcmdlLCB0aGlzIGFsbW9zdCBy
ZXZlcnRzIGJhY2sgdG8gYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24gKHNpbmNlIHRoZXJlIGlzIGFs
d2F5cyBnb2luZyB0byBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiZuYnNwOw0KIFRoaXMgaXMgd2h5
IEkgb3JpZ2luYWxseSBhcmd1ZWQgdG8gaGF2ZSBpdCBpbmRlZWQgb24gYSBwZXItb2JqZWN0IGJh
c2lzLCBidXQgSSBsb3N0IHRoYXQgYXJndW1lbnQuJm5ic3A7IEZvciBzdWNoIGZpbmUtZ3JhaW5l
ZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRlZWQgaW50ZXJlc3QgaW4gZ2V0dGluZyBk
ZWxheXMgb2YgaW5kaXZpZHVhbCBvYmplY3RzIHdpdGhvdXQgZGVsYXksICZuYnNwO2EgY2xpZW50
IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaA0KIG11bHRpcGxlIOKAnG1pY3Jv4oCdIHN1
YnNjcmlwdGlvbnMuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+VENBcyBpbiBSTU9OIGFyZSBzb21ldGhpbmcgZGlmZmVyZW50IGFsdG9nZXRoZXIuJm5i
c3A7IFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0
IGZpbHRlcnMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYg
WzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48
YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMDoxOCBBTTxi
cj4NCjxiPlRvOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0
YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25m
ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwv
YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0
LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3Jr
bHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+
bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQouLi4uPGJyPg0K
PGJyPg0KbyZuYnNwOyAzLjE8YnI+DQo8YnI+DQombmJzcDsgSSdtIG5vdCBzdXJlIEkgdW5kZXJz
dGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LiZuYnNwOyBMZXQnczxicj4NCiZuYnNw
OyBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMuJm5ic3A7IFRoZW4gY2hh
bmdlcyBoYXBwZW4gYXQ8YnI+DQombmJzcDsgdGltZXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw
OyAyJm5ic3A7IDMmbmJzcDsgNCZuYnNwOyAxMSZuYnNwOyAxMyZuYnNwOyAxNCZuYnNwOyAxNTxi
cj4NCjxicj4NCiZuYnNwOyBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQgc2VlbXMgSSB3b3VsZCBy
ZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbTxicj4NCiZuYnNwOyB0aW1lczo8YnI+DQo8YnI+
DQombmJzcDsgJm5ic3A7IDImbmJzcDsgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAyKTxi
cj4NCiZuYnNwOyAmbmJzcDsgMTIgKGNvbnRhaW5pbmcgY2hhbmdlIGZyb20gMyw0LDExKTxicj4N
CiZuYnNwOyAmbmJzcDsgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAxMyk8YnI+DQom
bmJzcDsgJm5ic3A7IDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwxNSk8YnI+DQo8YnI+
DQombmJzcDsgSXMgdGhpcyBjb3JyZWN0Pzxicj4NCjxicj4NCiZuYnNwOyBJbiBhbnkgY2FzZSwg
SSBzdWdnZXN0IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgWUFORyBtb2R1bGUgaXM8YnI+DQombmJz
cDsgY2xhcmlmaWVkIC0gY3VycmVudGx5IHRoZSBSRkMgdGV4dCBjb250YWlucyBtb3JlIGRldGFp
bHMgdGhhbiB0aGU8YnI+DQombmJzcDsgWUFORyBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZW1zIHRvIG1lIChm
cm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBseTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gdGhlIGVu
dGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNoIG5vZGUgd2l0aGluIHRoZSBzdWJzY3JpcHRp
b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IHdhbnQgJnF1b3Q7YXQgbW9zdCwgMSBub3RpZmljYXRpb24gcGVyIHNlY29uZCZxdW90Oy4mbmJz
cDsgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gYmUgdG9sZCBhYm91dCBhbiBpbmRpdmlkdWFs
IGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuJm5ic3A7IEkgY291bGQgc3RpbGw8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdldCAxMCwwMDAgZXZl
bnRzL3NlYyBidXQgZm9yIGRpZmZlcmVudCBkYXRhIG5vZGVzLiZuYnNwOyBUaGUgcmVjZWl2ZXIg
ZG9lcyBub3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPnJlYWxseSBjYXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJlcG9ydGVkIGluIGVhY2ggbm90
aWZpY2F0aW9uLiBUaGUgZ29hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+aXMgdG8gc2ltcGx5IGxpbWl0IHRoZSBuZXR3b3JrIGFuZCBwcm9jZXNz
b3IgbG9hZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+RnJvbSBhIHNlcnZlciBQT1YsIEkgZG8gbm90IHdhbnQgYSB0aW1lciBvbiBldmVyeSBk
YXRhIG5vZGUgaW5zdGFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPmFuZCBjb21wbGV4IGNvZGUgdG8gY29uc3RydWN0IHRoZSBuZXh0IG9uLWNo
YW5nZSBub3RpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlJNT04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBkaWZmZXJlbnRseS48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBy
aXNpbmcgYW5kIGZhbGxpbmcgdGhyZXNob2xkcyBhcmUgdXNlZCB0byBhcm0gYW5kIHJlLWFybSBh
biBldmVudCB0cmlnZ2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIHRpbWUgYmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1c2VkIGF0IGFsbCB0
byBkZXRlcm1pbmUgaG93IG1hbnkgZXZlbnRzIHRvIHNlbmQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oTm90IHN1Z2dlc3RpbmcgYWxsIHlhbmct
cHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4pPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTywgdGhlIG9wZXJhdG9yIHNob3Vs
ZCBwdXQgZXZlbnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRvIGEgc2VwYXJhdGUgc3Vi
c2NyaXB0aW9uLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBseSB0byB0aGUgZW50aXJl
IHN1YnNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KL21hcnRpbjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29u
ZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95Csjceml521mbxchi_--


From nobody Wed Nov 29 19:07:05 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170DE127843 for ; Wed, 29 Nov 2017 19:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1M_IyXbbl47 for ; Wed, 29 Nov 2017 19:07:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3F0120454 for ; Wed, 29 Nov 2017 19:07:02 -0800 (PST)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 9CD6C38F128A1 for ; Thu, 30 Nov 2017 03:06:59 +0000 (GMT)
Received: from DGGEMA422-HUB.china.huawei.com (10.1.198.155) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 03:07:00 +0000
Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.85]) by dggema422-hub.china.huawei.com ([10.1.198.155]) with mapi id 14.03.0361.001; Thu, 30 Nov 2017 11:06:51 +0800
From: Rohit R Ranade 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] draft-ietf-netconf-rfc6536bis Query
Thread-Index: AdNdz9MehD+d0xYjTJ+ndshlR/LYrAA3pAkgArZagoA=
Date: Thu, 30 Nov 2017 03:06:50 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B15CE6B@DGGEMA502-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_991B70D8B4112A4699D5C00DDBBF878A6B15CE6BDGGEMA502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 03:07:05 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CE6BDGGEMA502MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Andy/Martin,

Can you please clarify the below query about rule-list group having "*".  W=
hether we need to allow a new group to be added a rule-list which already h=
as a "*" in the leaf-list.

With Regards,
Rohit R

From: Rohit R Ranade
Sent: 16 November 2017 13:17
To: 'netconf@ietf.org' 
Subject: RE: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi All,

1 more point I wanted clarified was for the below point

leaf-list group {
           type union {
             type matchall-string-type;
             type group-name-type;
           }
           description
             "List of administrative groups that will be
              assigned the associated access rights
              defined by the 'rule' list.

              The string '*' indicates that all groups apply to the
              entry.";

Consider that existing configuration is like below:

   list1
   ug1


Consider that user will add to this group a record of '*"

   list1
   ug1
*


?  Whether this is valid configuration ? "*" can be considered as a super-s=
et as it will apply for all group. So can this leaf-list contain * along wi=
th other UGs ?

One scenario where this is possible is when initially the user had thought =
of applying a rule-list to only a particular Group , but later the user wan=
ts to apply to all groups.

With Regards,
Rohit R

From: Rohit R Ranade
Sent: 15 November 2017 10:42
To: netconf@ietf.org
Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query

Hi All,

For the state-data in NACM like the below :

leaf denied-operations {
         type yang:zero-based-counter32;
         config false;
         mandatory true;
         description
           "Number of times since the server last restarted that a
            protocol operation request was denied.";
       }

"Number of times since the server" =3D=3D> Here the server is being referen=
ced to NETCONF server or RESTCONF server ?
Please note that the both the NETCONF server and RESTCONF server maybe usin=
g the same NACM configurations but the state-data maintained by each protoc=
ol maybe different.

With Regards,
Rohit R

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CE6BDGGEMA502MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Andy=
/Martin,


&n=
bsp;


Can you=
 please clarify the below query about rule-list group having “*”=
;.  Whether we need to allow a new group to be added a rule-list which=
 already has a “*” in the leaf-list.


&n=
bsp;


With Re=
gards,


Rohit R=



&n=
bsp;






From: Rohit R Ranade


Sent: 16 November 2017 13:17

To: 'netconf@ietf.org' <netconf@ietf.org>

Subject: RE: [Netconf] draft-ietf-netconf-rfc6536bis Query






 


Hi All,=



&n=
bsp;


1 more =
point I wanted clarified was for the below point


&n=
bsp;


leaf-list group {


       &nb=
sp;   type union {


       &nb=
sp;     type matchall-string-type;

       &nb=
sp;     type group-name-type;


       &nb=
sp;   }


       &nb=
sp;   description


       &nb=
sp;     "List of administrative groups that will b=
e


       &nb=
sp;      assigned the associated access rights


       &nb=
sp;      defined by the 'rule' list.


 


       &nb=
sp;      The string '*' indicates that all groups =
apply to the


       &nb=
sp;      entry.";


&n=
bsp;


Conside=
r that existing configuration is like below:


<rul=
e-list>


 &=
nbsp; <name>list1</name>


 &=
nbsp; <group>ug1</group>


</ru=
le-list>


&n=
bsp;


Conside=
r that user will add to this group a record of ‘*”


<rul=
e-list>


 &=
nbsp; <name>list1</name>


 &=
nbsp; <group>ug1</group>


<group>*</group>


</ru=
le-list>



ð 
Whether this is valid configuration ? “*” can be considered as=
 a super-set as it will apply for all group. So can this leaf-list contain =
* along with other UGs ?


&n=
bsp;


One sce=
nario where this is possible is when initially the user had thought of appl=
ying a rule-list to only a particular Group , but later the user wants to a=
pply to all groups.


&n=
bsp;


With Re=
gards,


Rohit R=



&n=
bsp;






From: Rohit R Ranade


Sent: 15 November 2017 10:42

To: netconf@ietf.org

Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query






 


Hi All,


 


For the state-data in NACM like=
 the below :


 


leaf denied-operations {

       &nb=
sp; type yang:zero-based-counter32;


       &nb=
sp; config false;


       &nb=
sp; mandatory true;


       &nb=
sp; description


       &nb=
sp;   "Number of times since the server last restarted that =
a


       &nb=
sp;    protocol operation request was denied.";


       }


 


“Number of times since the server”
è=
 Here the server is being referenced to NETCONF server=
 or RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.<=
/span>


 


With Regards,=



Rohit R






--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CE6BDGGEMA502MBXchi_--


From nobody Wed Nov 29 19:37:38 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DACF128AB0 for ; Wed, 29 Nov 2017 19:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 0lAO25JUaaxv for ; Wed, 29 Nov 2017 19:37:35 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 F253C12896F for ; Wed, 29 Nov 2017 19:37:34 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id x20so6333948lff.1 for ; Wed, 29 Nov 2017 19:37:34 -0800 (PST)
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=uqTMOBTQTpTiq0kZ+/rImhRF8BSoYcIOZVxYKtzdUjI=; b=tbDK9On5pGEpW+d1HEA64GF53kAbjtKeD52cGhbyo6laqFOvm6bHsVKQBdHf1+lmv8 g+WpRUDtavOMtf2je8k7k4lW8ib0dG79otTV54pzILL3tu1YP3fTZ6xPAi9dRa3l2x3P CCVmQ8ZCjct1Tp+8908xmbxac8RHhUQ/qlmZU8u5jvcu/w0tFXqxSdZNjxdfEcsiEV1y HGfkYxyXKXpUMzzhuXXMsjWDGiKeQcBukQzSoUAVrTBlI7VnBM88+0Ixa0Y4Dxlu+Eeh RbwUoLbYgJHW/Ns//71LJPdincsIEZNYr+JxcziETLMTESyQwPeybRsfqPYTj/ZflcXJ XChQ==
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=uqTMOBTQTpTiq0kZ+/rImhRF8BSoYcIOZVxYKtzdUjI=; b=g4ybh2tMyxfYR5SOF9NbS5ESfMU18sE7oo4iY6n/Q6g+zpEnrjDnt7N94EM9Qy1kqD qw2s93S1wF9x+KiU9/upuNJAMQBKxeEulfFYe8G9beX3MhzV0EW072nx0kLkbtxTPF9d 1T7Q8Bg8/dDo0kDAAtJJTVcl+m1hkEAZgtaUhFjx8jRDOUmVWAiVpwF+HcH2/PtDhiEH WkWuOR/lJCpeR5aNitYRY+G1z04yfHax4G0qCKHvnQ9kys+n5t6oP8zef4OMb4shYFhW cNKwNhjxTSyVGSq0JvqTd15oxsn+qKjK5l6C9y8vGSC3ZMyodZQaIOgJ8C3SKOurQY4W rSsg==
X-Gm-Message-State: AJaThX4rKu2FjS5yjlA9LUvWaRAF1R2+VVDTtQKcmUSRT51LTX26W0Eh CV9CmUQsW8wU7qC5lKRGayCAF70TN7TpRqZjojLR5w==
X-Google-Smtp-Source: AGs4zMaeMmaT9ikV3vuTuktlhN1RNtA952TONxfQ4Jly+YeH525xSnt11kYaOrKhPf9s7yuyPQsRmDD2BTR6M4U3ypg=
X-Received: by 10.25.147.23 with SMTP id v23mr1946579lfd.120.1512013053170; Wed, 29 Nov 2017 19:37:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 29 Nov 2017 19:37:32 -0800 (PST)
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B15CE6B@DGGEMA502-MBX.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6B15CE6B@DGGEMA502-MBX.china.huawei.com>
From: Andy Bierman 
Date: Wed, 29 Nov 2017 19:37:32 -0800
Message-ID: 
To: Rohit R Ranade 
Cc: "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045ce2d6ee25dc055f2af84d"
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis Query
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 03:37:37 -0000

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

On Wed, Nov 29, 2017 at 7:06 PM, Rohit R Ranade 
wrote:

> Hi Andy/Martin,
>
>
>
> Can you please clarify the below query about rule-list group having =E2=
=80=9C*=E2=80=9D.
> Whether we need to allow a new group to be added a rule-list which alread=
y
> has a =E2=80=9C*=E2=80=9D in the leaf-list.
>
>
>


Yes -- both group entries are allowed, even though 1 of them is redundant



> With Regards,
>
> Rohit R
>


Andy


>
>
> *From:* Rohit R Ranade
> *Sent:* 16 November 2017 13:17
> *To:* 'netconf@ietf.org' 
> *Subject:* RE: [Netconf] draft-ietf-netconf-rfc6536bis Query
>
>
>
> Hi All,
>
>
>
> 1 more point I wanted clarified was for the below point
>
>
>
> leaf-list group {
>
>            type union {
>
>              type matchall-string-type;
>
>              type group-name-type;
>
>            }
>
>            description
>
>              "List of administrative groups that will be
>
>               assigned the associated access rights
>
>               defined by the 'rule' list.
>
>
>
>               The string '*' indicates that all groups apply to the
>
>               entry.";
>
>
>
> Consider that existing configuration is like below:
>
> 
>
>    list1
>
>    ug1
>
> 
>
>
>
> Consider that user will add to this group a record of =E2=80=98*=E2=80=9D
>
> 
>
>    list1
>
>    ug1
>
> *
>
> 
>
> =C3=B0  Whether this is valid configuration ? =E2=80=9C*=E2=80=9D can be =
considered as a
> super-set as it will apply for all group. So can this leaf-list contain *
> along with other UGs ?
>
>
>
> One scenario where this is possible is when initially the user had though=
t
> of applying a rule-list to only a particular Group , but later the user
> wants to apply to all groups.
>
>
>
> With Regards,
>
> Rohit R
>
>
>
> *From:* Rohit R Ranade
> *Sent:* 15 November 2017 10:42
> *To:* netconf@ietf.org
> *Subject:* [Netconf] draft-ietf-netconf-rfc6536bis Query
>
>
>
> Hi All,
>
>
>
> For the state-data in NACM like the below :
>
>
>
> leaf denied-operations {
>
>          type yang:zero-based-counter32;
>
>          config false;
>
>          mandatory true;
>
>          description
>
>            "Number of times since the server last restarted that a
>
>             protocol operation request was denied.";
>
>        }
>
>
>
> =E2=80=9CNumber of times since the server=E2=80=9D =C3=A8 Here the server=
 is being referenced
> to NETCONF server or RESTCONF server ?
>
> Please note that the both the NETCONF server and RESTCONF server maybe
> using the same NACM configurations but the state-data maintained by each
> protocol maybe different.
>
>
>
> With Regards,
>
> Rohit R
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

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




On Wed, Nov 29, 2017 at 7:06 PM, Rohit R Ranade <<=
a href=3D"mailto:rohitrranade@huawei.com" target=3D"_blank">rohitrranade@hu=
awei.com> wrote:











Hi Andy=
/Martin,


=
=C2=A0


Can you=
 please clarify the below query about rule-list group having =E2=80=9C*=E2=
=80=9D.=C2=A0 Whether we need to allow a new group to be added a rule-list =
which already has a =E2=80=9C*=E2=80=9D in the leaf-list.


=
=C2=A0


Yes -- both group entries are allowed, even though 1 of them is redundant=


=C2=A0


With Re=
gards,


Rohit R=



Andy=

=C2=A0


=
=C2=A0






From: Rohit R Ranade


Sent: 16 November 2017 13:17

To: 'netco=
nf@ietf.org' <netconf@ietf.org>

Subject: RE: [Netconf] draft-ietf-netconf-rfc6536bis Query=







=C2=A0


Hi All,=



=
=C2=A0


1 more =
point I wanted clarified was for the below point


=
=C2=A0


leaf-list group {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 type union {


=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 matchall-string-type;=



=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 group-name-type;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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


=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 of administrative groups that will b=
e


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 assigned the associated access rights<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined by the 'rule' list.


=C2=A0


=C2=A0=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 string '*' indicates that all=
 groups apply to the


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 entry.";


=
=C2=A0


Conside=
r that existing configuration is like below:


<rul=
e-list>


=C2=A0=
=C2=A0 <name>list1</name>


=C2=A0=
=C2=A0 <group>ug1</group>


</ru=
le-list>


=
=C2=A0


Conside=
r that user will add to this group a record of =E2=80=98*=E2=80=9D


<rul=
e-list>


=C2=A0=
=C2=A0 <name>list1</name>


=C2=A0=
=C2=A0 <group>ug1</group>


<group>*</group>


</ru=
le-list>



<=
span>=C3=B0=C2=A0
Wh=
ether this is valid configuration ? =E2=80=9C*=E2=80=9D can be considered a=
s a super-set as it will apply for all group. So can this leaf-list contain=
 * along with other UGs ?


=
=C2=A0


One sce=
nario where this is possible is when initially the user had thought of appl=
ying a rule-list to only a particular Group , but later the user wants to a=
pply to all groups.


=
=C2=A0


With Re=
gards,


Rohit R=



=
=C2=A0






From: Rohit R Ranade


Sent: 15 November 2017 10:42

To: netconf@ie=
tf.org

Subject: [Netconf] draft-ietf-netconf-rfc6536bis Query=







=C2=A0


Hi All,

=C2=A0


For the state-data in NACM like=
 the below :


=C2=A0


leaf denied-operations {=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 type yang:zero-based-counter32;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 config false;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 mandatory true;


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 description


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 "Number of times since the server last restarted that =
a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 protocol operation request was denied.";<=
u>


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



=C2=A0


=E2=80=9CNumber of times since the server=E2=80=9D
=C3=A8 Here the server is being referenced to NETCONF server o=
r RESTCONF server ?


Please note that the both the N=
ETCONF server and RESTCONF server maybe using the same NACM configurations =
but the state-data maintained by each protocol maybe different.


=C2=A0


With Regards,


Rohit R






_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--f403045ce2d6ee25dc055f2af84d--


From nobody Wed Nov 29 21:27:55 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69541243F3 for ; Wed, 29 Nov 2017 21:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGVOf1sNZEwN for ; Wed, 29 Nov 2017 21:27:52 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8AE5124207 for ; Wed, 29 Nov 2017 21:27:51 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0701A4E3D3DBB; Thu, 30 Nov 2017 05:27:48 +0000 (GMT)
Received: from DGGEMA422-HUB.china.huawei.com (10.1.198.155) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 05:27:49 +0000
Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.85]) by dggema422-hub.china.huawei.com ([10.1.198.155]) with mapi id 14.03.0361.001; Thu, 30 Nov 2017 13:27:39 +0800
From: Rohit R Ranade 
To: Mahesh Jethanandani , Henk Birkholz 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] Summary and AIs from IETF-100 meeting
Thread-Index: AQHTZ9dRYoINQ6+Nm0yarSuLX+s4gKMoYd8AgAAMy4CAAF9+AIAAcpaAgABgdYCAAsTpwA==
Date: Thu, 30 Nov 2017 05:27:38 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B15CF7E@DGGEMA502-MBX.china.huawei.com>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com>
In-Reply-To: <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.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_991B70D8B4112A4699D5C00DDBBF878A6B15CF7EDGGEMA502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 05:27:54 -0000

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

SGkgTWFoZXNoLA0KDQpXaGV0aGVyIHdlIGNhbiBjb25zaWRlciB0aGlzIHByb2JsZW0gc2ltaWxh
ciB0byB3aW5kb3dzLUFQUCBpbnN0YWxsYXRpb24gdnMgdXNhZ2UuICBJbiB3aW5kb3dzIGluc3Rh
bGxlZC1hcHBsaWNhdGlvbiBsaXN0LCB3ZSBtYXkgc2VlIHRoZSBhcHBsaWNhdGlvbiBiZWluZyBp
bnN0YWxsZWQgYnV0IG9uY2Ugd2UgdHJ5IHRvIG9wZW4gdGhlIGFwcGxpY2F0aW9uLCB3ZSBtYXkg
Z2V0IGFuIGVycm9yIHRoYXQgdGhlIGxpY2Vuc2UgaGFzIGV4cGlyZWQuDQoNCkkgcHJlZmVyIHRo
ZSB5YW5nLWxpYnJhcnkgdG8gc2hvdyB0aGUgbGlzdCBvZiBhcHBsaWNhdGlvbiB3aGljaCBhcmUg
aW5zdGFsbGVkLg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdCBSDQoNCkZyb206IE5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFu
YW5kYW5pDQpTZW50OiAyOSBOb3ZlbWJlciAyMDE3IDAwOjMzDQpUbzogSGVuayBCaXJraG9seiA8
aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZT4NCkNjOiBuZXRjb25mQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW05ldGNvbmZdIFN1bW1hcnkgYW5kIEFJcyBmcm9tIElFVEYtMTAwIG1lZXRp
bmcNCg0KDQpPbiBOb3YgMjgsIDIwMTcsIGF0IDU6MTcgQU0sIEhlbmsgQmlya2hvbHogPGhlbmsu
Ymlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU8bWFpbHRvOmhlbmsuYmlya2hvbHpAc2l0LmZyYXVu
aG9mZXIuZGU+PiB3cm90ZToNCg0KVGhpcyBzZWVtcyB0byBiZSBhbiB1bm5lY2Vzc2FyeSBqYWIg
dGhhdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBhY3R1YWwgdG9waWNzIHJhaXNlZCBieSBN
YWhlc2gsIHdoaWNoIHdlcmU6DQoNCi0gWUFORyBMaWJyYXJ5IHdpbGwgc3VwcG9ydCB0aGUgY29u
Y2VwdCBvZiBsaWNlbnNpbmcgaW1wYWN0aW5nIHdoYXQgbW9kZWxzIGFyZSBhZHZlcnRpc2VkIGFu
ZCBzdXBwb3J0ZWQNCg0KSSBkbyBub3QgdGhpbmsgdGhlIG1pbnV0ZXMgYXJlIGdvaW5nIHRvIHRl
bGwgeW91IGFueW1vcmUgYWJvdXQgdGhlIHJlcXVpcmVtZW50LiBTbyBsZXQgbWUgdGFrZSBhIHN0
YWIgYXQgd2hhdCBJIHRoaW5rIHRoZSByZXF1aXJlbWVudCBpcy4NCg0KWUFORyBMaWJyYXJ5IGN1
cnJlbnRseSBjb21waWxlcyBhIGxpc3Qgb2YgbW9kdWxlcyAoYW5kIHN1Yi1tb2R1bGVzKSB0aGF0
IGFyZSBzdXBwb3J0ZWQgYnkgdGhlIGRldmljZS4gVGhlIHNhbWUgZGV2aWNlIG1pZ2h0IGFsc28g
c3VwcG9ydCB0aGUgY29uY2VwdCBvZiBsaWNlbnNpbmcsIHdoZXJlIHRoZSBsaWNlbnNlIGNvbnRy
b2xzIHdoZXRoZXIgdGhlIGZlYXR1cmUgY2FuIGJlIGVuYWJsZWQgb24gdGhlIGRldmljZSwgZS5n
LiBCR1AuIFRoZSBzZXJ2ZXIgaGFzIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgQkdQIGFzIGEgZmVh
dHVyZSAodGhlIHNvZnR3YXJlIGV4aXN0cyksIGJ1dCB0aGUgY3VzdG9tZXIgaGFzIG5vdCBib3Vn
aHQgYSBsaWNlbnNlIGZvciB0aGUgQkdQIGZlYXR1cmUuIFdoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIg
ZG8gdW5kZXIgdGhlIGNpcmN1bXN0YW5jZXM/IFNob3VsZCBpdCBhZHZlcnRpc2UgQkdQIG1vZHVs
ZSwgYW5kIGhhdmUgdGhlIHJlcXVlc3QgZnJvbSB0aGUgY2xpZW50IGZhaWw/IE9yIHNob3VsZCB0
aGVyZSBhbm90aGVyIGZsYWcsIGVpdGhlciBpbiB0aGUgWUFORyBMaWJyYXJ5IG9yIHNvbWUgb3Ro
ZXIgbW9kdWxlIHRoYXQgaW5mb3JtcyB0aGUgY2xpZW50IHRoYXQgYWx0aG91Z2ggdGhlIGRldmlj
ZSBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgQkdQLCBpdCBjYW5ub3QgYmVjYXVzZSBpdCBsYWNr
cyB0aGUgbGljZW5zZS4NCg0KQSBzaW1pbGFyIHNjZW5hcmlvIGV4aXN0cyB3aXRoIFlBTkcgbW9k
dWxlcyB0aGF0IHN1cHBvcnQgYSBwYXJ0aWN1bGFyIGxpbmUgY2FyZCwgYW5kIHRoYXQgbGluZSBj
YXJkIGlzIGhvdCBwbHVnZ2FibGUuIFdoYXQgc2hvdWxkIHRoZSBZQU5HIGxpYnJhcnkgZG8gZm9y
IG1vZHVsZXMgdGhhdCBpdCBhZHZlcnRpc2VzLCBidXQgdGhlIGxpbmUgY2FyZCBmb3IgdGhhdCBt
b2R1bGUgbWF5IG9yIG1heSBub3QgZXhpc3QgaW4gdGhlIHN5c3RlbT8NCg0KDQotIHNlbWFudGlj
IHZlcnNpb25pbmcgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIFlBTkcgTGlicmFyeQ0KDQpUaGUgcmVx
dWlyZW1lbnQgaGVyZSBpcyB3aGV0aGVyIHNlbWFudGljIHZlcnNpb25pbmcgY2FuIGJlIHN1cHBv
cnRlZCBpbiB0aGUgWUFORyBsaWJyYXJ5IGluIGFkZGl0aW9uIHRvIHRoZSBjdXJyZW50IHZlcnNp
b24sIHdoaWNoIGlzIGEgZGF0ZS4gRGV0YWlscyBvbiBob3cgaXQgcmVsYXRlcyB0byBZQU5HIExp
YnJhcnkgc2hvdWxkIGJlIGJyb3VnaHQgdXAgb24gdGhlIGxpc3QsIHByZWZlcmFibHkgb24gYSBu
ZXcgdGhyZWFkLg0KDQoNCg0KV2hpY2gsIGJ0dywgSSBhbHNvIGFtIG5vdCBzdXJlIGFib3V0IGhv
dyBhbmQgd2hlcmUgdGhhdCBjYW1lIHVwIGFuZCB3aGF0IGl0IG1lYW5zLiBJbiBjb25zZXF1ZW5j
ZSAtIGFzIErDvHJnZW4gLSBJIGFtIGN1cmlvdXMgdG8gc2VlIHRoZSBtaW51dGVzLg0KDQpUaGFu
a3MgdG8gUm9iZXJ0IGZvciB1cGRhdGluZyB0aGUgcm91Z2ggbWludXRlcy4gSWYgYW55b25lIGRp
c2FncmVlcyB3aXRoIHdoYXQgaXMgcmVjb3JkZWQgaW4gdGhlIHJvdWdoIG5vdGVzLCBwbGVhc2Ug
bGlzdGVuIHRvIHRoZSByZWNvcmRpbmcgaGVyZTxodHRwczovL3d3dy5pZXRmLm9yZy9hdWRpby9p
ZXRmMTAwLz4gYW5kIHVwZGF0ZSB0aGUgcm91Z2ggbm90ZXMuIFRoZXkgd2lsbCBiZSBwdWJsaXNo
ZWQgYXMgb2ZmaWNpYWwgbWludXRlcy4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFu
ZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg
NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw
YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5IaSBNYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZXRoZXIgd2UgY2FuIGNvbnNpZGVyIHRoaXMgcHJv
YmxlbSBzaW1pbGFyIHRvIHdpbmRvd3MtQVBQIGluc3RhbGxhdGlvbiB2cyB1c2FnZS4mbmJzcDsg
SW4gd2luZG93cyBpbnN0YWxsZWQtYXBwbGljYXRpb24gbGlzdCwgd2UgbWF5IHNlZSB0aGUgYXBw
bGljYXRpb24NCiBiZWluZyBpbnN0YWxsZWQgYnV0IG9uY2Ugd2UgdHJ5IHRvIG9wZW4gdGhlIGFw
cGxpY2F0aW9uLCB3ZSBtYXkgZ2V0IGFuIGVycm9yIHRoYXQgdGhlIGxpY2Vuc2UgaGFzIGV4cGly
ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkkgcHJlZmVyIHRoZSB5YW5nLWxpYnJhcnkgdG8gc2hvdyB0aGUgbGlz
dCBvZiBhcHBsaWNhdGlvbiB3aGljaCBhcmUgaW5zdGFsbGVkLg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpdGgg
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvaGl0IFI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd
DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5TZW50Ojwv
Yj4gMjkgTm92ZW1iZXIgMjAxNyAwMDozMzxicj4NCjxiPlRvOjwvYj4gSGVuayBCaXJraG9seiAm
bHQ7aGVuay5iaXJraG9sekBzaXQuZnJhdW5ob2Zlci5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5l
dGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBTdW1tYXJ5
IGFuZCBBSXMgZnJvbSBJRVRGLTEwMCBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBOb3YgMjgsIDIwMTcsIGF0
IDU6MTcgQU0sIEhlbmsgQmlya2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6
QHNpdC5mcmF1bmhvZmVyLmRlIj5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U
aGlzIHNlZW1zIHRvIGJlIGFuIHVubmVjZXNzYXJ5IGphYiB0aGF0IGhhcyBub3RoaW5nIHRvIGRv
IHdpdGggdGhlIGFjdHVhbCB0b3BpY3MgcmFpc2VkIGJ5IE1haGVzaCwgd2hpY2ggd2VyZTo8YnI+
DQo8YnI+DQotIFlBTkcgTGlicmFyeSB3aWxsIHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgbGljZW5z
aW5nIGltcGFjdGluZyB3aGF0IG1vZGVscyBhcmUgYWR2ZXJ0aXNlZCBhbmQgc3VwcG9ydGVkPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkbyBub3QgdGhpbmsgdGhlIG1pbnV0ZXMgYXJlIGdv
aW5nIHRvIHRlbGwgeW91IGFueW1vcmUgYWJvdXQgdGhlIHJlcXVpcmVtZW50LiBTbyBsZXQgbWUg
dGFrZSBhIHN0YWIgYXQgd2hhdCBJIHRoaW5rIHRoZSByZXF1aXJlbWVudCBpcy4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllBTkcgTGlicmFy
eSBjdXJyZW50bHkgY29tcGlsZXMgYSBsaXN0IG9mIG1vZHVsZXMgKGFuZCBzdWItbW9kdWxlcykg
dGhhdCBhcmUgc3VwcG9ydGVkIGJ5IHRoZSBkZXZpY2UuIFRoZSBzYW1lIGRldmljZSBtaWdodCBh
bHNvIHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgbGljZW5zaW5nLCB3aGVyZSB0aGUgbGljZW5zZSBj
b250cm9scyB3aGV0aGVyIHRoZSBmZWF0dXJlIGNhbiBiZQ0KIGVuYWJsZWQgb24gdGhlIGRldmlj
ZSwgZS5nLiBCR1AuIFRoZSBzZXJ2ZXIgaGFzIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgQkdQIGFz
IGEgZmVhdHVyZSAodGhlIHNvZnR3YXJlIGV4aXN0cyksIGJ1dCB0aGUgY3VzdG9tZXIgaGFzIG5v
dCBib3VnaHQgYSBsaWNlbnNlIGZvciB0aGUgQkdQIGZlYXR1cmUuIFdoYXQgc2hvdWxkIHRoZSBz
ZXJ2ZXIgZG8gdW5kZXIgdGhlIGNpcmN1bXN0YW5jZXM/IFNob3VsZCBpdCBhZHZlcnRpc2UgQkdQ
IG1vZHVsZSwNCiBhbmQgaGF2ZSB0aGUgcmVxdWVzdCBmcm9tIHRoZSBjbGllbnQgZmFpbD8gT3Ig
c2hvdWxkIHRoZXJlIGFub3RoZXIgZmxhZywgZWl0aGVyIGluIHRoZSBZQU5HIExpYnJhcnkgb3Ig
c29tZSBvdGhlciBtb2R1bGUgdGhhdCBpbmZvcm1zIHRoZSBjbGllbnQgdGhhdCBhbHRob3VnaCB0
aGUgZGV2aWNlIGlzIGNhcGFibGUgb2Ygc3VwcG9ydGluZyBCR1AsIGl0IGNhbm5vdCBiZWNhdXNl
IGl0IGxhY2tzIHRoZSBsaWNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+QSBzaW1pbGFyIHNjZW5hcmlvIGV4aXN0cyB3aXRoIFlBTkcgbW9kdWxl
cyB0aGF0IHN1cHBvcnQgYSBwYXJ0aWN1bGFyIGxpbmUgY2FyZCwgYW5kIHRoYXQgbGluZSBjYXJk
IGlzIGhvdCBwbHVnZ2FibGUuIFdoYXQgc2hvdWxkIHRoZSBZQU5HIGxpYnJhcnkgZG8gZm9yIG1v
ZHVsZXMgdGhhdCBpdCBhZHZlcnRpc2VzLCBidXQgdGhlIGxpbmUgY2FyZCBmb3IgdGhhdCBtb2R1
bGUgbWF5DQogb3IgbWF5IG5vdCBleGlzdCBpbiB0aGUgc3lzdGVtPzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBzZW1hbnRpYyB2
ZXJzaW9uaW5nIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBZQU5HIExpYnJhcnk8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj5UaGUgcmVxdWlyZW1lbnQgaGVyZSBpcyB3aGV0aGVyIHNlbWFudGljIHZl
cnNpb25pbmcgY2FuIGJlIHN1cHBvcnRlZCBpbiB0aGUgWUFORyBsaWJyYXJ5IGluIGFkZGl0aW9u
IHRvIHRoZSBjdXJyZW50IHZlcnNpb24sIHdoaWNoIGlzIGEgZGF0ZS4mbmJzcDtEZXRhaWxzIG9u
IGhvdyBpdCByZWxhdGVzIHRvIFlBTkcgTGlicmFyeSBzaG91bGQgYmUgYnJvdWdodCB1cCBvbiB0
aGUgbGlzdCwNCiBwcmVmZXJhYmx5IG9uIGEgbmV3IHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCldoaWNoLCBi
dHcsIEkgYWxzbyBhbSBub3Qgc3VyZSBhYm91dCBob3cgYW5kIHdoZXJlIHRoYXQgY2FtZSB1cCBh
bmQgd2hhdCBpdCBtZWFucy4gSW4gY29uc2VxdWVuY2UgLSBhcyBKw7xyZ2VuIC0gSSBhbSBjdXJp
b3VzIHRvIHNlZSB0aGUgbWludXRlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3Mg
dG8gUm9iZXJ0IGZvciB1cGRhdGluZyB0aGUgcm91Z2ggbWludXRlcy4gSWYgYW55b25lIGRpc2Fn
cmVlcyB3aXRoIHdoYXQgaXMgcmVjb3JkZWQgaW4gdGhlIHJvdWdoIG5vdGVzLCBwbGVhc2UgbGlz
dGVuIHRvIHRoZSByZWNvcmRpbmcmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9h
dWRpby9pZXRmMTAwLyI+aGVyZTwvYT4mbmJzcDthbmQgdXBkYXRlIHRoZSByb3VnaA0KIG5vdGVz
LiBUaGV5IHdpbGwgYmUgcHVibGlzaGVkIGFzIG9mZmljaWFsIG1pbnV0ZXMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1q
ZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CF7EDGGEMA502MBXchi_--


From nobody Wed Nov 29 22:30:44 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437BA127419 for ; Wed, 29 Nov 2017 22:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVLa2_nvX75H for ; Wed, 29 Nov 2017 22:30:39 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E362612025C for ; Wed, 29 Nov 2017 22:30:38 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C0323452FB7 for ; Thu, 30 Nov 2017 06:30:35 +0000 (GMT)
Received: from DGGEMA401-HUB.china.huawei.com (10.3.20.42) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 06:30:35 +0000
Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.85]) by DGGEMA401-HUB.china.huawei.com ([10.3.20.42]) with mapi id 14.03.0361.001; Thu, 30 Nov 2017 14:30:27 +0800
From: Rohit R Ranade 
To: Alexander Clemm , "Eric Voit (evoit)" , Andy Bierman , Martin Bjorklund , "kwatsen@juniper.net" 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzM4Chkdhf7n0yfB4m8U5WwO6MrJmCAgAAhEwCAAEzIAIAAAjwAgADhTOA=
Date: Thu, 30 Nov 2017 06:30:27 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B15CFDD@DGGEMA502-MBX.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-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_991B70D8B4112A4699D5C00DDBBF878A6B15CFDDDGGEMA502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 06:30:42 -0000

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

SGkgRXJpYywNCg0KV2UgbmVlZCBhbHNvIGNvbnNpZGVyIHRoYXQgY29tbWl0IG1heWJlIHZlcnkg
YmlnIG9yIGluIHRoZSBkYW1wZW5pbmcgdGltZSBzbyBtYW55IHJlY29yZHMgYXJlIHVwZGF0ZWQg
dGhhdCB0aGUgPG5vdGlmaWNhdGlvbj4gbWVzc2FnZSBtYXkgbmVlZCB0byBiZSBzcGxpdCBhY3Jv
c3MgZnJhZ21lbnRzLiAgSSBzdWdnZXN0IHJlZnJhbWluZyBvZiB0aGUgc2VudGVuY2UgdG8NCg0K
4oCcQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgdGhlIGxhc3QgZnJhZ21l
bnQgb2YgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydOKA
nQ0KDQoNCldpdGggUmVnYXJkcywNClJvaGl0IFINCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRlciBDbGVtbQ0KU2Vu
dDogMzAgTm92ZW1iZXIgMjAxNyAwNjoyOQ0KVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBj
aXNjby5jb20+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IE1hcnRpbiBCam9y
a2x1bmQgPG1iakB0YWlsLWYuY29tPjsga3dhdHNlbkBqdW5pcGVyLm5ldA0KQ2M6IE5ldGNvbmYg
PG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFm
dC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNClRoaXMgd29ya3MgZm9yIG1lLiAgUGVyaGFw
cyBvbmUgYWRkaXRpb25hbCBpdGVtIHdlIG1pZ2h0IGFkZCAoZm9yIGNyeXN0YWwtY2xlYXIgY2xh
cmlmaWNhdGlvbikgaXMgdGhhdCB3aGVuIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBzZW50
LCBpdCBjb250YWlucyB0aGUgbW9zdCByZWNlbnQgdXBkYXRlIGZvciB0aGF0IG9iamVjdCAoaS5l
LiB0aGUgdmFsdWUgdGhhdCBpcyBpbiBlZmZlY3Qgd2hlbiB0aGUgdXBkYXRlIGlzIHNlbnQpLiAg
SWYgdGhlcmUgYXJlIHNvbWUgcXVpY2tseSBvc2NpbGxhdGluZyB2YWx1ZXMgd2UgZG9u4oCZdCBz
ZW5kIHRoZSB3aG9sZSBzZXF1ZW5jZSBvZiB1cGRhdGVzL3ZhbHVlcy4NCg0KLS0tIEFsZXgNCg0K
RnJvbTogRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQpTZW50OiBX
ZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDQ6NTEgUE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0g
PGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2Vp
LmNvbT4+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1h
d29ya3MuY29tPj47IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpA
dGFpbC1mLmNvbT4+OyBrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIu
bmV0Pg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v
cmc+Pg0KU3ViamVjdDogUkU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25m
LXlhbmctcHVzaC0xMQ0KDQpUaGUgU2VjdGlvbiAzLjEgdGV4dCBJIHByb3Bvc2VkIGluIG15IHJl
c3BvbnNlIHRvIE1hcnRpbiBvbiB0aGUgZGFtcGVuaW5nIHF1ZXN0aW9uOg0KDQoNCkRhbXBlbmlu
ZyBwZXJpb2Q6IEluIGFuIG9uLWNoYW5nZSBzdWJzY3JpcHRpb24sIGRldGVjdGVkIG9iamVjdCBj
aGFuZ2VzIHNob3VsZCBiZSBzZW50IGFzIHF1aWNrbHkgYXMgcG9zc2libGUuICBIb3dldmVyIHdp
dGhvdXQgYWRlcXVhdGUgcHJvdGVjdGlvbnMsIGEgcmFwaWQgc2VyaWVzIG9mIG9iamVjdCBjaGFu
Z2VzIG1pZ2h0IGV4aGF1c3Qgb2YgcmVzb3VyY2VzIGluIHRoZSBwdWJsaXNoZXIgb3IgcmVjZWl2
ZXIuICBJbiBvcmRlciB0byBwcm90ZWN0IGFnYWluc3QgdGhhdCwgYSBkYW1wZW5pbmcgcGVyaW9k
IE1BWSBiZSB1c2VkIHRvIHNwZWNpZnkgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBiZWZv
cmUgc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUgc3Vic2NyaXB0aW9uIGFy
ZSBnZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuICBUaGUgZGFtcGVuaW5nIHBlcmlvZCBjb2xsZWN0
aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhIG5vZGVzIHNlbGVjdGVkIGJ5IGEg
c2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBhIHNpbmdsZSByZWNlaXZlci4gIFRoaXMg
bWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIGEgc3Vic2NyaWJlZCBvYmplY3Qs
IGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcyBjcmVhdGVkIGVpdGhl
ciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBh
dCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nIHBlcmlvZC4gIEEgZGFtcGVuaW5nIHBlcmlvZCBpcyBy
ZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0
cmFuc3BvcnQuDQoNCg0KDQpXaXRoIHRoZSBZQU5HIGRlc2NyaXB0aW9uIG9mOg0KDQoNCg0KIlNw
ZWNpZmllcyB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVw
ZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3Ig
YSByZWNlaXZlci4gIFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRv
IHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0
aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiAgVGhpcyBtZWFucyB0aGF0IHdoZW4g
dGhlcmUgaXMgYSBjaGFuZ2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29y
ZCBjb250YWluaW5nIHRoYXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdo
ZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBk
YW1wZW5pbmcgcGVyaW9kLiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUg
YSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4gIEEgZGFt
cGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNz
YWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuICBBIHplcm8gdmFsdWUgaW5kaWNhdGVzIG5vIGRh
bXBlbmluZyBwZXJpb2QsIGFuZCBhbGwgc3Vic2NyaWJlZCBvYmplY3QgY2hhbmdlcyBhcmUgc2Vu
dCBpbW1lZGlhdGVseS4iDQoNCg0KDQpEb2VzIHRoaXMgd29yayBmb3IgZXZlcnlvbmU/DQoNCkVy
aWMNCg0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgQWxleGFuZGVyIENsZW1tDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5
LCAyMDE3IDM6MTcgUE0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWls
dG86YW5keUB5dW1hd29ya3MuY29tPj47IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t
PG1haWx0bzptYmpAdGFpbC1mLmNvbT4+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxt
YWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBv
ZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNCkkgdGhvdWdodCB3ZSBkZWNpZGVk
IHRoYXQgd2UgaGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmplY3RzIGluIHRoZSBz
dWJzY3JpcHRpb24uICBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIHNlbmQgdXBkYXRlcyBhdCAyLCAx
MiAoY29udGFpbmluZyAzLDQsMTEpLCBhbmQgMjIgKGNvbnRhaW5pbmcgMTMsIDE0LCAxNSkuDQoN
CklmIHRoZSBzY29wZSBvZiB0aGUgc3Vic2NyaXB0aW9uIGJlY29tZXMgc3VmZmljaWVudGx5IGxh
cmdlLCB0aGlzIGFsbW9zdCByZXZlcnRzIGJhY2sgdG8gYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24g
KHNpbmNlIHRoZXJlIGlzIGFsd2F5cyBnb2luZyB0byBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiAg
VGhpcyBpcyB3aHkgSSBvcmlnaW5hbGx5IGFyZ3VlZCB0byBoYXZlIGl0IGluZGVlZCBvbiBhIHBl
ci1vYmplY3QgYmFzaXMsIGJ1dCBJIGxvc3QgdGhhdCBhcmd1bWVudC4gIEZvciBzdWNoIGZpbmUt
Z3JhaW5lZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRlZWQgaW50ZXJlc3QgaW4gZ2V0
dGluZyBkZWxheXMgb2YgaW5kaXZpZHVhbCBvYmplY3RzIHdpdGhvdXQgZGVsYXksICBhIGNsaWVu
dCBjb3VsZCBzaW1wbHkgbmVlZCB0byBlc3RhYmxpc2ggbXVsdGlwbGUg4oCcbWljcm/igJ0gc3Vi
c2NyaXB0aW9ucy4NCg0KVENBcyBpbiBSTU9OIGFyZSBzb21ldGhpbmcgZGlmZmVyZW50IGFsdG9n
ZXRoZXIuICBUaGlzIGlzIHNvbWV0aGluZyB3ZSBhcmUgdHJ5aW5nIHRvIGFkZHJlc3Mgd2l0aCBz
bWFydCBmaWx0ZXJzLg0KDQotLS0gQWxleA0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRj
b25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFdl
ZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMTA6MTggQU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5k
IDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pg0KQ2M6IE5ldGNvbmYgPG5l
dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtO
ZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KDQoNCg0K
T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRh
aWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQpIaSwNCg0KLi4uLg0KDQpv
ICAzLjENCg0KICBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9k
IGNvbmNlcHQuICBMZXQncw0KICBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAx
MHMuICBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0DQogIHRpbWVzOg0KDQogICAgMiAgMyAgNCAgMTEg
IDEzICAxNCAgMTUNCg0KICBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQgc2VlbXMgSSB3b3VsZCBy
ZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbQ0KICB0aW1lczoNCg0KICAgIDIgIChjb250YWlu
aW5nIG9ubHkgY2hhbmdlIGZyb20gMikNCiAgICAxMiAoY29udGFpbmluZyBjaGFuZ2UgZnJvbSAz
LDQsMTEpDQogICAgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAxMykNCiAgICAyMyAo
Y29udGFpbmluZyBjaGFuZ2VzIGZyb20gMTQsMTUpDQoNCiAgSXMgdGhpcyBjb3JyZWN0Pw0KDQog
IEluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRlc2NyaXB0aW9uIGluIHRoZSBZQU5HIG1vZHVs
ZSBpcw0KICBjbGFyaWZpZWQgLSBjdXJyZW50bHkgdGhlIFJGQyB0ZXh0IGNvbnRhaW5zIG1vcmUg
ZGV0YWlscyB0aGFuIHRoZQ0KICBZQU5HIG1vZHVsZS4NCg0KDQpTZWVtcyB0byBtZSAoZnJvbSBh
IGNsaWVudCBQT1YpIHRoYXQgSSB3YW50IHRoZSBkYW1wZW5pbmcgdG8gYXBwbHkNCnRvIHRoZSBl
bnRpcmUgc3Vic2NyaXB0aW9uLCBub3QgdG8gZWFjaCBub2RlIHdpdGhpbiB0aGUgc3Vic2NyaXB0
aW9uLg0KSSB3YW50ICJhdCBtb3N0LCAxIG5vdGlmaWNhdGlvbiBwZXIgc2Vjb25kIi4gIEkgZG9u
J3Qgc2VlIHdoeSBJIHdvdWxkIHdhbnQNCnRvIGJlIHRvbGQgYWJvdXQgYW4gaW5kaXZpZHVhbCBk
YXRhIG5vZGUgb25jZSBwZXIgc2Vjb25kLiAgSSBjb3VsZCBzdGlsbA0KZ2V0IDEwLDAwMCBldmVu
dHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEgbm9kZXMuICBUaGUgcmVjZWl2ZXIgZG9lcyBu
b3QNCnJlYWxseSBjYXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJlcG9ydGVkIGluIGVhY2ggbm90
aWZpY2F0aW9uLiBUaGUgZ29hbA0KaXMgdG8gc2ltcGx5IGxpbWl0IHRoZSBuZXR3b3JrIGFuZCBw
cm9jZXNzb3IgbG9hZC4NCg0KRnJvbSBhIHNlcnZlciBQT1YsIEkgZG8gbm90IHdhbnQgYSB0aW1l
ciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2UNCmFuZCBjb21wbGV4IGNvZGUgdG8gY29uc3Ry
dWN0IHRoZSBuZXh0IG9uLWNoYW5nZSBub3RpZmljYXRpb24uDQoNClJNT04gaGFuZGxlcyBkYW1w
ZW5pbmcgdmVyeSBkaWZmZXJlbnRseS4NClRoZSByaXNpbmcgYW5kIGZhbGxpbmcgdGhyZXNob2xk
cyBhcmUgdXNlZCB0byBhcm0gYW5kIHJlLWFybSBhbiBldmVudCB0cmlnZ2VyLg0KVGhlIHRpbWUg
YmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1c2VkIGF0IGFsbCB0byBkZXRlcm1pbmUgaG93IG1hbnkg
ZXZlbnRzIHRvIHNlbmQuDQooTm90IHN1Z2dlc3RpbmcgYWxsIHlhbmctcHVzaCB1c2UtY2FzZXMg
YXJlIHRocmVzaG9sZC1iYXNlZC4pDQoNCklNTywgdGhlIG9wZXJhdG9yIHNob3VsZCBwdXQgZXZl
bnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRvIGEgc2VwYXJhdGUgc3Vic2NyaXB0aW9u
LA0KYW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBseSB0byB0aGUgZW50aXJlIHN1
YnNjcmlwdGlvbi4NCg0KIC4uLg0KDQoNCg0KDQovbWFydGluDQoNCg0KQW5keQ0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxp
bmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CFDDDGGEMA502MBXchi_
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
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo
YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRl
eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu
bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi
VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls
U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEVyaWMsPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIG5l
ZWQgYWxzbyBjb25zaWRlciB0aGF0IGNvbW1pdCBtYXliZSB2ZXJ5IGJpZyBvciBpbiB0aGUgZGFt
cGVuaW5nIHRpbWUgc28gbWFueSByZWNvcmRzIGFyZSB1cGRhdGVkIHRoYXQgdGhlICZsdDtub3Rp
ZmljYXRpb24mZ3Q7IG1lc3NhZ2UgbWF5IG5lZWQgdG8NCiBiZSBzcGxpdCBhY3Jvc3MgZnJhZ21l
bnRzLiAmbmJzcDtJIHN1Z2dlc3QgcmVmcmFtaW5nIG9mIHRoZSBzZW50ZW5jZSB0byA8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxBIGRhbXBlbmluZyBwZXJp
b2QgaXMgcmVzZXQgZXZlcnkgdGltZSB0aGUgbGFzdCBmcmFnbWVudCBvZiBhIG5ldyBub3RpZmlj
YXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J04oCdJm5ic3A7PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9oaXQgUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTmV0
Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8
L2I+QWxleGFuZGVyIENsZW1tPGJyPg0KPGI+U2VudDo8L2I+IDMwIE5vdmVtYmVyIDIwMTcgMDY6
Mjk8YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgVm9pdCAoZXZvaXQpICZsdDtldm9pdEBjaXNjby5jb20m
Z3Q7OyBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs7IE1hcnRpbiBCam9y
a2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0Ozsga3dhdHNlbkBqdW5pcGVyLm5ldDxicj4NCjxi
PkNjOjwvYj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVz
aC0xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5UaGlzIHdvcmtzIGZvciBtZS4mbmJzcDsgUGVyaGFwcyBvbmUgYWRkaXRpb25hbCBp
dGVtIHdlIG1pZ2h0IGFkZCAoZm9yIGNyeXN0YWwtY2xlYXIgY2xhcmlmaWNhdGlvbikgaXMgdGhh
dCB3aGVuIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBzZW50LCBpdA0KIGNvbnRhaW5zIHRo
ZSBtb3N0IHJlY2VudCB1cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZSB2YWx1ZSB0aGF0
IGlzIGluIGVmZmVjdCB3aGVuIHRoZSB1cGRhdGUgaXMgc2VudCkuJm5ic3A7IElmIHRoZXJlIGFy
ZSBzb21lIHF1aWNrbHkgb3NjaWxsYXRpbmcgdmFsdWVzIHdlIGRvbuKAmXQgc2VuZCB0aGUgd2hv
bGUgc2VxdWVuY2Ugb2YgdXBkYXRlcy92YWx1ZXMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFs
ZXgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx
LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVy
aWMgVm9pdCAoZXZvaXQpIFs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5tYWlsdG86
ZXZvaXRAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVt
YmVyIDI5LCAyMDE3IDQ6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEFsZXhhbmRlciBDbGVtbSAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tIj5hbGV4YW5kZXIuY2xl
bW1AaHVhd2VpLmNvbTwvYT4mZ3Q7OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7OyBNYXJ0aW4gQmpv
cmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29t
PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBq
dW5pcGVyLm5ldDwvYT48YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0
bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUkU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmct
cHVzaC0xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5UaGUgU2VjdGlvbiAzLjEgdGV4dCBJIHByb3Bvc2VkIGluIG15IHJlc3BvbnNl
IHRvIE1hcnRpbiBvbiB0aGUgZGFtcGVuaW5nIHF1ZXN0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhbXBlbmluZyBwZXJpb2Q6IEluIGFuIG9uLWNo
YW5nZSBzdWJzY3JpcHRpb24sIGRldGVjdGVkIG9iamVjdCBjaGFuZ2VzIHNob3VsZCBiZSBzZW50
IGFzIHF1aWNrbHkgYXMgcG9zc2libGUuJm5ic3A7IEhvd2V2ZXIgd2l0aG91dCBhZGVxdWF0ZSBw
cm90ZWN0aW9ucywgYSByYXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNoYW5nZXMgbWlnaHQgZXhoYXVz
dCBvZiByZXNvdXJjZXMgaW4gdGhlDQogcHVibGlzaGVyIG9yIHJlY2VpdmVyLiZuYnNwOyBJbiBv
cmRlciB0byBwcm90ZWN0IGFnYWluc3QgdGhhdCwgYSBkYW1wZW5pbmcgcGVyaW9kIE1BWSBiZSB1
c2VkIHRvIHNwZWNpZnkgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vz
c2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUgc3Vic2NyaXB0aW9uIGFyZSBnZW5lcmF0
ZWQgZm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVs
eSBhcHBsaWVzDQogdG8gdGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxlY3RlZCBieSBhIHNp
bmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuJm5ic3A7IFRo
aXMgbWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIGEgc3Vic2NyaWJlZCBvYmpl
Y3QsIGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcyBjcmVhdGVkIGVp
dGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMNCiBpbiBlZmZlY3Qs
IG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyBBIGRhbXBlbmluZyBw
ZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBw
YXNzZWQgdG8gdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaXRoIHRoZSBZQU5HIGRlc2NyaXB0aW9u
IG9mOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7U3BlY2lmaWVzIHRoZSBpbnRlcnZh
bCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRo
ZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiZuYnNwOyBU
aGUgZGFtcGVuaW5nIHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFs
bCBkYXRhIG5vZGVzIHNlbGVjdGVkIGJ5IGENCiBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50
IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBp
cyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRh
aW5pbmcgdGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBk
YW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmlu
ZyBwZXJpb2QuJm5ic3A7DQogQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUg
YSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4mbmJzcDsg
QSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9u
IG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4mbmJzcDsgQSB6ZXJvIHZhbHVlIGluZGlj
YXRlcyBubyBkYW1wZW5pbmcgcGVyaW9kLCBhbmQgYWxsIHN1YnNjcmliZWQgb2JqZWN0IGNoYW5n
ZXMNCiBhcmUgc2VudCBpbW1lZGlhdGVseS4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Eb2VzIHRoaXMgd29yayBmb3IgZXZlcnlvbmU/PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48YnI+DQpFcmljPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiBOZXRjb25mIFs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnIj5tYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP
ZiA8L2I+QWxleGFuZGVyIENsZW1tPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1i
ZXIgMjksIDIwMTcgMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4gQW5keSBCaWVybWFuICZsdDs8YSBo
cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0
OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5t
YmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDs8YSBocmVm
PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29u
Zi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+SSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJp
bmVkIGRhbXBlbmluZyBmb3IgYWxsIG9iamVjdHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4mbmJzcDsg
SW4gdGhpcyBjYXNlLCB3ZSB3b3VsZCBzZW5kIHVwZGF0ZXMgYXQgMiwgMTIgKGNvbnRhaW5pbmcN
CiAzLDQsMTEpLCBhbmQgMjIgKGNvbnRhaW5pbmcgMTMsIDE0LCAxNSkuIDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J
ZiB0aGUgc2NvcGUgb2YgdGhlIHN1YnNjcmlwdGlvbiBiZWNvbWVzIHN1ZmZpY2llbnRseSBsYXJn
ZSwgdGhpcyBhbG1vc3QgcmV2ZXJ0cyBiYWNrIHRvIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIChz
aW5jZSB0aGVyZSBpcyBhbHdheXMgZ29pbmcgdG8NCiBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiZu
YnNwOyBUaGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVkIHRvIGhhdmUgaXQgaW5kZWVkIG9u
IGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFyZ3VtZW50LiZuYnNwOyBGb3Ig
c3VjaCBmaW5lLWdyYWluZWQgdXBkYXRlcywgd2hlcmUgYSBjbGllbnQgaXMgaW5kZWVkIGludGVy
ZXN0IGluIGdldHRpbmcgZGVsYXlzIG9mIGluZGl2aWR1YWwgb2JqZWN0cyB3aXRob3V0IGRlbGF5
LCAmbmJzcDthIGNsaWVudCBjb3VsZA0KIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaCBtdWx0aXBs
ZSDigJxtaWNyb+KAnSBzdWJzY3JpcHRpb25zLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VENBcyBpbiBS
TU9OIGFyZSBzb21ldGhpbmcgZGlmZmVyZW50IGFsdG9nZXRoZXIuJm5ic3A7IFRoaXMgaXMgc29t
ZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0IGZpbHRlcnMuJm5ic3A7
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx
LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5l
dGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpu
ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJp
ZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMDox
OCBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRv
Om1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBO
ZXRjb25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRm
Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9m
IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
Pk9uIFR1ZSwgTm92IDI4LCAyMDE3IGF0IDE6MzcgQU0sIE1hcnRpbiBCam9ya2x1bmQgJmx0Ozxh
IGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1iakB0YWlsLWYu
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8YnI+DQo8
YnI+DQouLi4uPGJyPg0KPGJyPg0KbyZuYnNwOyAzLjE8YnI+DQo8YnI+DQombmJzcDsgSSdtIG5v
dCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LiZuYnNwOyBM
ZXQnczxicj4NCiZuYnNwOyBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMu
Jm5ic3A7IFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQ8YnI+DQombmJzcDsgdGltZXM6PGJyPg0KPGJy
Pg0KJm5ic3A7ICZuYnNwOyAyJm5ic3A7IDMmbmJzcDsgNCZuYnNwOyAxMSZuYnNwOyAxMyZuYnNw
OyAxNCZuYnNwOyAxNTxicj4NCjxicj4NCiZuYnNwOyBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQg
c2VlbXMgSSB3b3VsZCByZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbTxicj4NCiZuYnNwOyB0
aW1lczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDImbmJzcDsgKGNvbnRhaW5pbmcgb25seSBj
aGFuZ2UgZnJvbSAyKTxicj4NCiZuYnNwOyAmbmJzcDsgMTIgKGNvbnRhaW5pbmcgY2hhbmdlIGZy
b20gMyw0LDExKTxicj4NCiZuYnNwOyAmbmJzcDsgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2Ug
ZnJvbSAxMyk8YnI+DQombmJzcDsgJm5ic3A7IDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAx
NCwxNSk8YnI+DQo8YnI+DQombmJzcDsgSXMgdGhpcyBjb3JyZWN0Pzxicj4NCjxicj4NCiZuYnNw
OyBJbiBhbnkgY2FzZSwgSSBzdWdnZXN0IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgWUFORyBtb2R1
bGUgaXM8YnI+DQombmJzcDsgY2xhcmlmaWVkIC0gY3VycmVudGx5IHRoZSBSRkMgdGV4dCBjb250
YWlucyBtb3JlIGRldGFpbHMgdGhhbiB0aGU8YnI+DQombmJzcDsgWUFORyBtb2R1bGUuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhh
dCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50byB0
aGUgZW50aXJlIHN1YnNjcmlwdGlvbiwgbm90IHRvIGVhY2ggbm9kZSB3aXRoaW4gdGhlIHN1YnNj
cmlwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3YW50ICZxdW90O2F0IG1vc3QsIDEgbm90
aWZpY2F0aW9uIHBlciBzZWNvbmQmcXVvdDsuJm5ic3A7IEkgZG9uJ3Qgc2VlIHdoeSBJIHdvdWxk
IHdhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dG8gYmUgdG9sZCBhYm91dCBhbiBpbmRpdmlkdWFs
IGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuJm5ic3A7IEkgY291bGQgc3RpbGw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+Z2V0IDEwLDAwMCBldmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEg
bm9kZXMuJm5ic3A7IFRoZSByZWNlaXZlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5y
ZWFsbHkgY2FyZSB3aGV0IG5vZGVzIGFyZSBiZWluZyByZXBvcnRlZCBpbiBlYWNoIG5vdGlmaWNh
dGlvbi4gVGhlIGdvYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aXMgdG8gc2ltcGx5IGxpbWl0IHRo
ZSBuZXR3b3JrIGFuZCBwcm9jZXNzb3IgbG9hZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb20gYSBzZXJ2ZXIgUE9WLCBJIGRvIG5vdCB3YW50IGEg
dGltZXIgb24gZXZlcnkgZGF0YSBub2RlIGluc3RhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFu
ZCBjb21wbGV4IGNvZGUgdG8gY29uc3RydWN0IHRoZSBuZXh0IG9uLWNoYW5nZSBub3RpZmljYXRp
b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5STU9O
IGhhbmRsZXMgZGFtcGVuaW5nIHZlcnkgZGlmZmVyZW50bHkuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PlRoZSByaXNpbmcgYW5kIGZhbGxpbmcgdGhyZXNob2xkcyBhcmUgdXNlZCB0byBhcm0gYW5kIHJl
LWFybSBhbiBldmVudCB0cmlnZ2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgdGltZSBiZXR3
ZWVuIGNoYW5nZXMgaXMgbm90IHVzZWQgYXQgYWxsIHRvIGRldGVybWluZSBob3cgbWFueSBldmVu
dHMgdG8gc2VuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+KE5vdCBzdWdnZXN0aW5nIGFsbCB5YW5n
LXB1c2ggdXNlLWNhc2VzIGFyZSB0aHJlc2hvbGQtYmFzZWQuKTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SU1PLCB0aGUgb3BlcmF0b3Igc2hvdWxkIHB1
dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5IGludG8gYSBzZXBhcmF0ZSBzdWJzY3Jp
cHRpb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBzaG91
bGQgYXBwbHkgdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsuLi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij48YnI+DQo8YnI+DQovbWFydGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp
bHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15CFDDDGGEMA502MBXchi_--


From nobody Thu Nov 30 07:01:53 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA911288A9 for ; Thu, 30 Nov 2017 07:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S_psIVvrA_B for ; Thu, 30 Nov 2017 07:01:48 -0800 (PST)
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 59A4D12948D for ; Thu, 30 Nov 2017 07:01:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51278; q=dns/txt; s=iport; t=1512054106; x=1513263706; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kgJaw7iFtVVCTN5Ihum7mekKgAkEKauk2I/aJcyPatI=; b=EBYtMrzk5l1gXZpthqV4HyjJjKaDF+Vf27JZ0jSGTZt+Giz41vFQsSIs GRYukvVNsB4SJbr+AZ+aR4ox4aKMrGT2iaWc4t+H7jPe2d/7pexBFRHqx ou2UMDlEwBhu4rcignLVKp61q/Wcn5Tijxg7ut/WozPJN+yqLP5RMA+RJ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAADKHCBa/5hdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnJmbicHg3iKII5ygX2WdhCBfgMKGAEKhElPAhqFBz8YAQE?= =?us-ascii?q?BAQEBAQEBayiFHwEBAQQBASEKQQsQAgEIEQQBAQ4ICwEGAwICAiULFAkIAgQBD?= =?us-ascii?q?QUIF4kfZBCmSIInhBYBhk8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNBggmBVoF?= =?us-ascii?q?pgyuEWx8PAS0fCYJWgmMFmTGJKgKLXYkpgh+RPYo5i18CERkBgTkBHzkmgStvF?= =?us-ascii?q?TqCKYQWBAE6eIc9gTKBFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,341,1508803200";  d="scan'208,217";a="316455308"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 15:01:44 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAUF1iZv030189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 15:01:44 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 10:01:43 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 30 Nov 2017 10:01:43 -0500
From: "Eric Voit (evoit)" 
To: Rohit R Ranade , Alexander Clemm , Andy Bierman , "Martin Bjorklund" , "kwatsen@juniper.net" , Randy Presuhn 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLQRPr9GM9Jka7UxKyCaa4a6MsMpiA//+ZgDCAAEyf8IAAV64AgABcfoCAABx9wA==
Date: Thu, 30 Nov 2017 15:01:43 +0000
Message-ID: <912c3dc57e404c7ea7fbce529a3eaf19@XCH-RTP-013.cisco.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6B15CFDD@DGGEMA502-MBX.china.huawei.com>
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B15CFDD@DGGEMA502-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: multipart/alternative; boundary="_000_912c3dc57e404c7ea7fbce529a3eaf19XCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 15:01:52 -0000

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

SGkgUmFuZHksDQpIaSBSb2hpdCwNCkhpIEFsZXgsDQoNClRoYW5rcyBmb3IgdGhlIHRob3VnaHRz
Lg0KDQpSYW5keSwgb24geW91ciBwb2ludDogaXQgaXMgdHJ1ZSBwcmV2aW91cyB3b3JkaW5nIG9m
IHRoZSBZQU5HIGRlc2NyaXB0aW9uIGNhbiBiZSB0aWdodGVuZWQgdXAuICBBbmQgeW91ciBwYXJh
cGhyYXNpbmcgZm9yIHRoZSBZQU5HIGRlc2NyaXB0aW9uIHByb3ZpZGVkIGdvb2QgZ3VpZGFuY2Uu
ICBCZWxvdyBJIGdpdmUgYW4gYXR0ZW1wdCByZWZyYW1pbmcgeWFuZyBkZXNjcmlwdGlvbiwgYWxz
byB0YWtpbmcgaW50byBhY2NvdW50IEFsZXggJiBSb2hpdOKAmXMgY29tbWVudHMuLi4NCg0KWUFO
RyBEZXNjcmlwdGlvbg0KDQpTcGVjaWZpZXMgdGhlIG1pbmltdW0gaW50ZXJ2YWwgYmV0d2VlbiB0
aGUgYXNzZW1ibHkgb2Ygc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgYSBzaW5nbGUgcmVj
ZWl2ZXIgb2YgYSBzdWJzY3JpcHRpb24uIFdoZW5ldmVyIHN1YnNjcmliZWQgb2JqZWN0cyBjaGFu
Z2UsIGFuZCBhIGRhbXBlbmluZyBwZXJpb2QgaW50ZXJ2YWwgKHdoaWNoIG1heSBiZSB6ZXJvKSBo
YXMgZWxhcHNlZCBzaW5jZSB0aGUgcHJldmlvdXMgdXBkYXRlIHJlY29yZCBjcmVhdGlvbiBmb3Ig
YSByZWNlaXZlciwgdGhlbiBhbnkgc3Vic2NyaWJlZCBvYmplY3RzIGFuZCBwcm9wZXJ0aWVzIHdo
aWNoIGhhdmUgY2hhbmdlZCBzaW5jZSB0aGUgcHJldmlvdXMgdXBkYXRlIHJlY29yZCB3aWxsIGhh
dmUgdGhlaXIgY3VycmVudCB2YWx1ZXMgbWFyc2hhbGxlZCBhbmQgcGxhY2VkIGludG8gYSBuZXcg
dXBkYXRlIHJlY29yZC4NCg0KUm9oaXQsIG9uIHlvdXIgcG9pbnQ6IHRvIGNvdmVyIGFueSBzdWNo
IGEgcG9zc2liaWxpdHksIGl0IG1pZ2h0IGJlIGJldHRlciB0byByZXNldCB0aGUgZGFtcGVuaW5n
IHBlcmlvZCBhZnRlciBhIHNwZWNpZmljIHVwZGF0ZSByZWNvcmQgaXMgYXNzZW1ibGVkLiAgIFRo
aXMgd2F5IGFueSBidW5kbGluZyBvZiB1cGRhdGVzIGludG8gbm90aWZpY2F0aW9uIG1lc3NhZ2Vz
LCBvciBmcmFnbWVudGF0aW9uIGRlbGF5cyB3b27igJl0IHJlc3VsdCBpbiBhbiBpcnJlZ3VsYXIg
b3IgdW5wcmVkaWN0YWJsZSBkYW1wZW5pbmcgcGVyaW9kLiAgIExvb2sgYmVsb3cgYXQgbXkgYXR0
ZW1wdCB0byBmcmFtZSB0aGlzIHdpdGhpbiBTZWN0aW9uIDMuMTAgdGV4dC4uLg0KDQpBbGV4LCBv
biB5b3VyIHBvaW50OiB5ZXMgd2UgbmVlZCB0byBiZSBleHBsaWNpdCBhYm91dCBqdXN0IHRoZSBs
YXN0IHZhbHVlIGJlaW5nIHNlbnQuICBJIHR3ZWFrIGl0IGludG8gdGhlIGRlc2NyaXB0aW9uIGlu
IHRoZSAzLjEwIGJlbG93LiAgSSB0aGluayBJIGFsc28gY292ZXJlZCBpbiBpdCB0aGUgWUFORyBk
ZXNjcmlwdGlvbiBhYm92ZS4uLg0KDQpTZWN0aW9uIDMuMTANCg0KRGFtcGVuaW5nIHBlcmlvZDog
SW4gYW4gb24tY2hhbmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0IGNoYW5nZXMgc2hv
dWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4gIEhvd2V2ZXIgaXQgbWF5IGJlIHVu
ZGVzaXJhYmxlIHRvIHNlbmQgYSByYXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNoYW5nZXMuICBTdWNo
IGJlaGF2aW9yIGhhcyB0aGUgcG90ZW50aWFsIHRvIGV4aGF1c3Qgb2YgcmVzb3VyY2VzIGluIHRo
ZSBwdWJsaXNoZXIgb3IgcmVjZWl2ZXIuICBJbiBvcmRlciB0byBwcm90ZWN0IGFnYWluc3QgdGhh
dCwgYSBkYW1wZW5pbmcgcGVyaW9kIE1BWSBiZSB1c2VkIHRvIHNwZWNpZnkgdGhlIGludGVydmFs
IHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhl
IHNhbWUgc3Vic2NyaXB0aW9uIGFyZSBnZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuICBUaGUgZGFt
cGVuaW5nIHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRh
IG5vZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBhIHNp
bmdsZSByZWNlaXZlci4gIFRoaXMgbWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRv
IG9uZSBvciBtb3JlIHN1YnNjcmliZWQgb2JqZWN0cywgYW4gdXBkYXRlIHJlY29yZCBjb250YWlu
aW5nIHRob3NlIG9iamVjdHMgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBk
YW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmlu
ZyBwZXJpb2QuICBJZiBtdWx0aXBsZSBjaGFuZ2VzIHRvIGEgc2luZ2xlIG9iamVjdCBvY2N1ciBk
dXJpbmcgYSBkYW1wZW5pbmcgcGVyaW9kLCBvbmx5IHRoZSB2YWx1ZSB0aGF0IGlzIGluIGVmZmVj
dCBpcyBpbmNsdWRlZCBhcyBwYXJ0IG9mIHRoZSB1cGRhdGUgcmVjb3JkLiAgQSBkYW1wZW5pbmcg
cGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYW4gdXBkYXRlIHJlY29yZCBoYXMgY29tcGxldGVk
IGl0cyBhc3NlbWJseS4NCg0KDQpFcmljDQoNCkZyb206IFJvaGl0IFIgUmFuYWRlLCBOb3ZlbWJl
ciAzMCwgMjAxNyAxOjMwIEFNDQoNCkhpIEVyaWMsDQoNCldlIG5lZWQgYWxzbyBjb25zaWRlciB0
aGF0IGNvbW1pdCBtYXliZSB2ZXJ5IGJpZyBvciBpbiB0aGUgZGFtcGVuaW5nIHRpbWUgc28gbWFu
eSByZWNvcmRzIGFyZSB1cGRhdGVkIHRoYXQgdGhlIDxub3RpZmljYXRpb24+IG1lc3NhZ2UgbWF5
IG5lZWQgdG8gYmUgc3BsaXQgYWNyb3NzIGZyYWdtZW50cy4gIEkgc3VnZ2VzdCByZWZyYW1pbmcg
b2YgdGhlIHNlbnRlbmNlIHRvDQoNCuKAnEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVy
eSB0aW1lIHRoZSBsYXN0IGZyYWdtZW50IG9mIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlz
IHBhc3NlZCB0byB0cmFuc3BvcnTigJ0NCg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdCBSDQoNCkZy
b206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP
ZiBBbGV4YW5kZXIgQ2xlbW0NClNlbnQ6IDMwIE5vdmVtYmVyIDIwMTcgMDY6MjkNClRvOiBFcmlj
IFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+Pjsg
QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv
bT4+OyBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5j
b20+Pjsga3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNj
OiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1
YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1
c2gtMTENCg0KVGhpcyB3b3JrcyBmb3IgbWUuICBQZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0g
d2UgbWlnaHQgYWRkIChmb3IgY3J5c3RhbC1jbGVhciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdo
ZW4gdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBtb3N0
IHJlY2VudCB1cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZSB2YWx1ZSB0aGF0IGlzIGlu
IGVmZmVjdCB3aGVuIHRoZSB1cGRhdGUgaXMgc2VudCkuICBJZiB0aGVyZSBhcmUgc29tZSBxdWlj
a2x5IG9zY2lsbGF0aW5nIHZhbHVlcyB3ZSBkb27igJl0IHNlbmQgdGhlIHdob2xlIHNlcXVlbmNl
IG9mIHVwZGF0ZXMvdmFsdWVzLg0KDQotLS0gQWxleA0KDQpGcm9tOiBFcmljIFZvaXQgKGV2b2l0
KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjks
IDIwMTcgNDo1MSBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdl
aS5jb208bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj47IEFuZHkgQmllcm1hbiA8
YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGluIEJq
b3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IGt3YXRzZW5A
anVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+DQpDYzogTmV0Y29uZiA8bmV0
Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW05l
dGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNClRoZSBT
ZWN0aW9uIDMuMSB0ZXh0IEkgcHJvcG9zZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9uIHRo
ZSBkYW1wZW5pbmcgcXVlc3Rpb246DQoNCg0KRGFtcGVuaW5nIHBlcmlvZDogSW4gYW4gb24tY2hh
bmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQg
YXMgcXVpY2tseSBhcyBwb3NzaWJsZS4gIEhvd2V2ZXIgd2l0aG91dCBhZGVxdWF0ZSBwcm90ZWN0
aW9ucywgYSByYXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNoYW5nZXMgbWlnaHQgZXhoYXVzdCBvZiBy
ZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4gIEluIG9yZGVyIHRvIHByb3Rl
Y3QgYWdhaW5zdCB0aGF0LCBhIGRhbXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lm
eSB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSBy
ZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNl
aXZlci4gIFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBz
ZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFu
ZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiAgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUg
aXMgYSBjaGFuZ2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250
YWluaW5nIHRoYXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8g
ZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5p
bmcgcGVyaW9kLiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcg
bm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4NCg0KDQoNCldpdGgg
dGhlIFlBTkcgZGVzY3JpcHRpb24gb2Y6DQoNCg0KDQoiU3BlY2lmaWVzIHRoZSBpbnRlcnZhbCB3
aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBz
YW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiAgVGhlIGRhbXBl
bmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwgZGF0YSBu
b2RlcyBzZWxlY3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5n
bGUgcmVjZWl2ZXIuICBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0byBh
IHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhhdCBvYmpl
Y3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcgcGVyaW9k
IGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuICBBIGRh
bXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVz
c2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0LiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0
IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5z
cG9ydC4gIEEgemVybyB2YWx1ZSBpbmRpY2F0ZXMgbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFs
bCBzdWJzY3JpYmVkIG9iamVjdCBjaGFuZ2VzIGFyZSBzZW50IGltbWVkaWF0ZWx5LiINCg0KDQoN
CkRvZXMgdGhpcyB3b3JrIGZvciBldmVyeW9uZT8NCg0KRXJpYw0KDQoNCkZyb206IE5ldGNvbmYg
W21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIg
Q2xlbW0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMzoxNyBQTQ0KVG86IEFu
ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+
PjsgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29t
Pj4NCkNjOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3Jn
Pj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15
YW5nLXB1c2gtMTENCg0KSSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJpbmVk
IGRhbXBlbmluZyBmb3IgYWxsIG9iamVjdHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4gIEluIHRoaXMg
Y2FzZSwgd2Ugd291bGQgc2VuZCB1cGRhdGVzIGF0IDIsIDEyIChjb250YWluaW5nIDMsNCwxMSks
IGFuZCAyMiAoY29udGFpbmluZyAxMywgMTQsIDE1KS4NCg0KSWYgdGhlIHNjb3BlIG9mIHRoZSBz
dWJzY3JpcHRpb24gYmVjb21lcyBzdWZmaWNpZW50bHkgbGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVy
dHMgYmFjayB0byBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlz
IGdvaW5nIHRvIGJlIGEgY2hhbmdlIHNvbWV3aGVyZSkuICBUaGlzIGlzIHdoeSBJIG9yaWdpbmFs
bHkgYXJndWVkIHRvIGhhdmUgaXQgaW5kZWVkIG9uIGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkg
bG9zdCB0aGF0IGFyZ3VtZW50LiAgRm9yIHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJl
IGEgY2xpZW50IGlzIGluZGVlZCBpbnRlcmVzdCBpbiBnZXR0aW5nIGRlbGF5cyBvZiBpbmRpdmlk
dWFsIG9iamVjdHMgd2l0aG91dCBkZWxheSwgIGEgY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRv
IGVzdGFibGlzaCBtdWx0aXBsZSDigJxtaWNyb+KAnSBzdWJzY3JpcHRpb25zLg0KDQpUQ0FzIGlu
IFJNT04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci4gIFRoaXMgaXMgc29tZXRo
aW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0IGZpbHRlcnMuDQoNCi0tLSBB
bGV4DQoNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwg
MjAxNyAxMDoxOCBBTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0
bzptYmpAdGFpbC1mLmNvbT4+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86
bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFm
dC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNCg0KDQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBh
dCAxOjM3IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRh
aWwtZi5jb20+PiB3cm90ZToNCkhpLA0KDQouLi4uDQoNCm8gIDMuMQ0KDQogIEknbSBub3Qgc3Vy
ZSBJIHVuZGVyc3RhbmQgdGhlIGRhbXBlbmluZyBwZXJpb2QgY29uY2VwdC4gIExldCdzDQogIGFz
c3VtZSB0aGF0IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlzIDEwcy4gIFRoZW4gY2hhbmdlcyBoYXBw
ZW4gYXQNCiAgdGltZXM6DQoNCiAgICAyICAzICA0ICAxMSAgMTMgIDE0ICAxNQ0KDQogIEZyb20g
dGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25z
LCBmcm9tDQogIHRpbWVzOg0KDQogICAgMiAgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAy
KQ0KICAgIDEyIChjb250YWluaW5nIGNoYW5nZSBmcm9tIDMsNCwxMSkNCiAgICAxMyAoY29udGFp
bmluZyBvbmx5IGNoYW5nZSBmcm9tIDEzKQ0KICAgIDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJv
bSAxNCwxNSkNCg0KICBJcyB0aGlzIGNvcnJlY3Q/DQoNCiAgSW4gYW55IGNhc2UsIEkgc3VnZ2Vz
dCB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIFlBTkcgbW9kdWxlIGlzDQogIGNsYXJpZmllZCAtIGN1
cnJlbnRseSB0aGUgUkZDIHRleHQgY29udGFpbnMgbW9yZSBkZXRhaWxzIHRoYW4gdGhlDQogIFlB
TkcgbW9kdWxlLg0KDQoNClNlZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdh
bnQgdGhlIGRhbXBlbmluZyB0byBhcHBseQ0KdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5v
dCB0byBlYWNoIG5vZGUgd2l0aGluIHRoZSBzdWJzY3JpcHRpb24uDQpJIHdhbnQgImF0IG1vc3Qs
IDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQiLiAgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2Fu
dA0KdG8gYmUgdG9sZCBhYm91dCBhbiBpbmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNv
bmQuICBJIGNvdWxkIHN0aWxsDQpnZXQgMTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJl
bnQgZGF0YSBub2Rlcy4gIFRoZSByZWNlaXZlciBkb2VzIG5vdA0KcmVhbGx5IGNhcmUgd2hldCBu
b2RlcyBhcmUgYmVpbmcgcmVwb3J0ZWQgaW4gZWFjaCBub3RpZmljYXRpb24uIFRoZSBnb2FsDQpp
cyB0byBzaW1wbHkgbGltaXQgdGhlIG5ldHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLg0KDQpGcm9t
IGEgc2VydmVyIFBPViwgSSBkbyBub3Qgd2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBp
bnN0YW5jZQ0KYW5kIGNvbXBsZXggY29kZSB0byBjb25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdl
IG5vdGlmaWNhdGlvbi4NCg0KUk1PTiBoYW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5
Lg0KVGhlIHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQg
cmUtYXJtIGFuIGV2ZW50IHRyaWdnZXIuDQpUaGUgdGltZSBiZXR3ZWVuIGNoYW5nZXMgaXMgbm90
IHVzZWQgYXQgYWxsIHRvIGRldGVybWluZSBob3cgbWFueSBldmVudHMgdG8gc2VuZC4NCihOb3Qg
c3VnZ2VzdGluZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2VkLikN
Cg0KSU1PLCB0aGUgb3BlcmF0b3Igc2hvdWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1s
YXRlbmN5IGludG8gYSBzZXBhcmF0ZSBzdWJzY3JpcHRpb24sDQphbmQgdGhlIGRhbXBlbmluZyBw
ZXJpb2Qgc2hvdWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLg0KDQogLi4uDQoN
Cg0KDQoNCi9tYXJ0aW4NCg0KDQpBbmR5DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYu
b3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRjb25mDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu
VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ
e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt
YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s
ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLHNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs
YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5
bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPkhpIFJhbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBSb2hpdCw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+SGkgQWxleCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHRob3VnaHRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+UmFuZHksIG9uIHlvdXIgcG9pbnQ6IGl0IGlzIHRydWUgcHJldmlv
dXMgd29yZGluZyBvZiB0aGUgWUFORyBkZXNjcmlwdGlvbiBjYW4gYmUgdGlnaHRlbmVkIHVwLiZu
YnNwOyBBbmQgeW91ciBwYXJhcGhyYXNpbmcgZm9yIHRoZSBZQU5HIGRlc2NyaXB0aW9uIHByb3Zp
ZGVkIGdvb2QgZ3VpZGFuY2UuJm5ic3A7DQogQmVsb3cgSSBnaXZlIGFuIGF0dGVtcHQgcmVmcmFt
aW5nIHlhbmcgZGVzY3JpcHRpb24sIGFsc28gdGFraW5nIGludG8gYWNjb3VudCBBbGV4ICZhbXA7
IFJvaGl04oCZcyBjb21tZW50cy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDou
NWluIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllBTkcgRGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bh
bj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41
aW4iPlNwZWNpZmllcyB0aGUgbWluaW11bSBpbnRlcnZhbCBiZXR3ZWVuIHRoZSBhc3NlbWJseSBv
ZiBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciBhIHNpbmdsZSByZWNlaXZlciBvZiBhIHN1
YnNjcmlwdGlvbi4gV2hlbmV2ZXIgc3Vic2NyaWJlZCBvYmplY3RzIGNoYW5nZSwgYW5kIGEgZGFt
cGVuaW5nIHBlcmlvZCBpbnRlcnZhbCAod2hpY2ggbWF5IGJlIHplcm8pDQogaGFzIGVsYXBzZWQg
c2luY2UgdGhlIHByZXZpb3VzIHVwZGF0ZSByZWNvcmQgY3JlYXRpb24gZm9yIGEgcmVjZWl2ZXIs
IHRoZW4gYW55IHN1YnNjcmliZWQgb2JqZWN0cyBhbmQgcHJvcGVydGllcyB3aGljaCBoYXZlIGNo
YW5nZWQgc2luY2UgdGhlIHByZXZpb3VzIHVwZGF0ZSByZWNvcmQgd2lsbCBoYXZlIHRoZWlyIGN1
cnJlbnQgdmFsdWVzIG1hcnNoYWxsZWQgYW5kIHBsYWNlZCBpbnRvIGEgbmV3IHVwZGF0ZSByZWNv
cmQuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+Um9oaXQsIG9uIHlvdXIgcG9pbnQ6IHRvIGNvdmVyIGFueSBzdWNo
IGEgcG9zc2liaWxpdHksIGl0IG1pZ2h0IGJlIGJldHRlciB0byByZXNldCB0aGUgZGFtcGVuaW5n
IHBlcmlvZCBhZnRlciBhIHNwZWNpZmljIHVwZGF0ZSByZWNvcmQgaXMgYXNzZW1ibGVkLiZuYnNw
OyZuYnNwOyBUaGlzIHdheQ0KIGFueSBidW5kbGluZyBvZiB1cGRhdGVzIGludG8gbm90aWZpY2F0
aW9uIG1lc3NhZ2VzLCBvciBmcmFnbWVudGF0aW9uIGRlbGF5cyB3b27igJl0IHJlc3VsdCBpbiBh
biBpcnJlZ3VsYXIgb3IgdW5wcmVkaWN0YWJsZSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyZuYnNw
OyBMb29rIGJlbG93IGF0IG15IGF0dGVtcHQgdG8gZnJhbWUgdGhpcyB3aXRoaW4gU2VjdGlvbiAz
LjEwIHRleHQuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFs
ZXgsIG9uIHlvdXIgcG9pbnQ6IHllcyB3ZSBuZWVkIHRvIGJlIGV4cGxpY2l0IGFib3V0IGp1c3Qg
dGhlIGxhc3QgdmFsdWUgYmVpbmcgc2VudC4mbmJzcDsgSSB0d2VhayBpdCBpbnRvIHRoZSBkZXNj
cmlwdGlvbiBpbiB0aGUgMy4xMCBiZWxvdy4mbmJzcDsgSSB0aGluayBJIGFsc28gY292ZXJlZA0K
IGluIGl0IHRoZSBZQU5HIGRlc2NyaXB0aW9uIGFib3ZlLi4uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gMy4xMDxvOnA+PC9v
OnA+PC9zcGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EYW1w
ZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBkZXRlY3RlZCBvYmpl
Y3QgY2hhbmdlcyBzaG91bGQgYmUgc2VudCBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiZuYnNwOyBI
b3dldmVyIGl0IG1heSBiZSB1bmRlc2lyYWJsZSB0byBzZW5kIGEgcmFwaWQgc2VyaWVzIG9mDQog
b2JqZWN0IGNoYW5nZXMuJm5ic3A7IFN1Y2ggYmVoYXZpb3IgaGFzIHRoZSBwb3RlbnRpYWwgdG8g
ZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4mbmJzcDsg
SW4gb3JkZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoYXQsIGEgZGFtcGVuaW5nIHBlcmlvZCBNQVkg
YmUgdXNlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1
Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbg0KIGFyZSBn
ZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxl
Y3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkg
YSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiZuYnNw
OyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0byBvbmUgb3IgbW9yZSBz
dWJzY3JpYmVkIG9iamVjdHMsIGFuIHVwZGF0ZSByZWNvcmQNCiBjb250YWluaW5nIHRob3NlIG9i
amVjdHMgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcgcGVy
aW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuJm5i
c3A7IElmIG11bHRpcGxlIGNoYW5nZXMgdG8gYSBzaW5nbGUgb2JqZWN0IG9jY3VyIGR1cmluZyBh
IGRhbXBlbmluZyBwZXJpb2QsIG9ubHkgdGhlIHZhbHVlIHRoYXQgaXMgaW4gZWZmZWN0IGlzIGlu
Y2x1ZGVkIGFzIHBhcnQNCiBvZiB0aGUgdXBkYXRlIHJlY29yZC4mbmJzcDsgQSBkYW1wZW5pbmcg
cGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYW4gdXBkYXRlIHJlY29yZCBoYXMgY29tcGxldGVk
IGl0cyBhc3NlbWJseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9oaXQgUiBSYW5hZGUs
IE5vdmVtYmVyIDMwLCAyMDE3IDE6MzAgQU08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIEVyaWMsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XZSBuZWVkIGFsc28gY29uc2lkZXIg
dGhhdCBjb21taXQgbWF5YmUgdmVyeSBiaWcgb3IgaW4gdGhlIGRhbXBlbmluZyB0aW1lIHNvIG1h
bnkgcmVjb3JkcyBhcmUgdXBkYXRlZCB0aGF0IHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyBtZXNz
YWdlDQogbWF5IG5lZWQgdG8gYmUgc3BsaXQgYWNyb3NzIGZyYWdtZW50cy4gJm5ic3A7SSBzdWdn
ZXN0IHJlZnJhbWluZyBvZiB0aGUgc2VudGVuY2UgdG8gPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO
Ij7igJxBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSB0aGUgbGFzdCBmcmFn
bWVudCBvZiBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0
4oCdJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa
SC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XaXRo
IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJv
aGl0IFI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n
dWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s
YW5ndWFnZTpaSC1DTiI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNA
aWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5BbGV4YW5kZXIgQ2xlbW08YnI+DQo8Yj5TZW50OjwvYj4gMzAgTm92ZW1iZXIg
MjAxNyAwNjoyOTxicj4NCjxiPlRvOjwvYj4gRXJpYyBWb2l0IChldm9pdCkgJmx0OzxhIGhyZWY9
Im1haWx0bzpldm9pdEBjaXNjby5jb20iPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7OyBBbmR5IEJp
ZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdv
cmtzLmNvbTwvYT4mZ3Q7OyBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJq
QHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86a3dh
dHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT48YnI+DQo8Yj5DYzo8L2I+
IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGll
dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSByZXZpZXcg
b2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOlpILUNOIj5UaGlzIHdvcmtzIGZvciBtZS4mbmJzcDsgUGVyaGFwcyBvbmUgYWRk
aXRpb25hbCBpdGVtIHdlIG1pZ2h0IGFkZCAoZm9yIGNyeXN0YWwtY2xlYXIgY2xhcmlmaWNhdGlv
bikgaXMgdGhhdCB3aGVuIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZQ0KIGlzIHNlbnQsIGl0IGNv
bnRhaW5zIHRoZSBtb3N0IHJlY2VudCB1cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZSB2
YWx1ZSB0aGF0IGlzIGluIGVmZmVjdCB3aGVuIHRoZSB1cGRhdGUgaXMgc2VudCkuJm5ic3A7IElm
IHRoZXJlIGFyZSBzb21lIHF1aWNrbHkgb3NjaWxsYXRpbmcgdmFsdWVzIHdlIGRvbuKAmXQgc2Vu
ZCB0aGUgd2hvbGUgc2VxdWVuY2Ugb2YgdXBkYXRlcy92YWx1ZXMuJm5ic3A7DQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLSBBbGV4DQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6WkgtQ04iPiBFcmljIFZvaXQgKGV2b2l0KSBbPGEgaHJlZj0ibWFpbHRvOmV2
b2l0QGNpc2NvLmNvbSI+bWFpbHRvOmV2b2l0QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyA0OjUxIFBNPGJyPg0KPGI+VG86PC9i
PiBBbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVh
d2VpLmNvbSI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0OzsgQW5keSBCaWVybWFu
ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5j
b208L2E+Jmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWls
LWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5A
anVuaXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+PGJyPg0KPGI+Q2M6PC9iPiBOZXRj
b25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y
ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRy
YWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n
dWFnZTpaSC1DTiI+VGhlIFNlY3Rpb24gMy4xIHRleHQgSSBwcm9wb3NlZCBpbiBteSByZXNwb25z
ZSB0byBNYXJ0aW4gb24gdGhlIGRhbXBlbmluZyBxdWVzdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt
c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl
OlpILUNOIj5EYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBk
ZXRlY3RlZCBvYmplY3QgY2hhbmdlcyBzaG91bGQgYmUgc2VudCBhcyBxdWlja2x5IGFzIHBvc3Np
YmxlLiZuYnNwOyBIb3dldmVyIHdpdGhvdXQgYWRlcXVhdGUgcHJvdGVjdGlvbnMsIGEgcmFwaWQg
c2VyaWVzIG9mIG9iamVjdCBjaGFuZ2VzIG1pZ2h0IGV4aGF1c3QNCiBvZiByZXNvdXJjZXMgaW4g
dGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4mbmJzcDsgSW4gb3JkZXIgdG8gcHJvdGVjdCBhZ2Fp
bnN0IHRoYXQsIGEgZGFtcGVuaW5nIHBlcmlvZCBNQVkgYmUgdXNlZCB0byBzcGVjaWZ5IHRoZSBp
bnRlcnZhbCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMg
Zm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiZu
YnNwOyBUaGUgZGFtcGVuaW5nIHBlcmlvZA0KIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBz
ZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFu
ZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0
aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3Jk
IGNvbnRhaW5pbmcgdGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hl
biBubw0KIGRhbXBlbmluZyBwZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBhdCB0aGUgZW5kIG9mIGEg
ZGFtcGVuaW5nIHBlcmlvZC4mbmJzcDsgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5
IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldpdGggdGhlIFlBTkcgZGVz
Y3JpcHRpb24gb2Y6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZxdW90O1NwZWNpZmllcyB0aGUgaW50ZXJ2YWwgd2hp
Y2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2Ft
ZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4mbmJzcDsgVGhlIGRh
bXBlbmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwgZGF0
YQ0KIG5vZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBh
IHNpbmdsZSByZWNlaXZlci4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBj
aGFuZ2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5n
IHRoYXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVu
aW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQNCiBvZiBhIGRhbXBlbmluZyBw
ZXJpb2QuJm5ic3A7IEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3
IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuJm5ic3A7IEEgZGFt
cGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNz
YWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuJm5ic3A7IEEgemVybyB2YWx1ZSBpbmRpY2F0ZXMg
bm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbA0KIHN1YnNjcmliZWQgb2JqZWN0IGNoYW5nZXMg
YXJlIHNlbnQgaW1tZWRpYXRlbHkuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RG9l
cyB0aGlzIHdvcmsgZm9yIGV2ZXJ5b25lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOlpILUNOIj48YnI+DQpFcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w
cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IE5l
dGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpu
ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGV4YW5k
ZXIgQ2xlbW08YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAz
OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzph
bmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7OyBNYXJ0aW4gQmpv
cmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29t
PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRj
b25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0x
MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JIHRob3VnaHQgd2UgZGVj
aWRlZCB0aGF0IHdlIGhhdmUgY29tYmluZWQgZGFtcGVuaW5nIGZvciBhbGwgb2JqZWN0cyBpbiB0
aGUgc3Vic2NyaXB0aW9uLiZuYnNwOyBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIHNlbmQgdXBkYXRl
cyBhdCAyLA0KIDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAoY29udGFpbmluZyAxMywg
MTQsIDE1KS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZiB0aGUg
c2NvcGUgb2YgdGhlIHN1YnNjcmlwdGlvbiBiZWNvbWVzIHN1ZmZpY2llbnRseSBsYXJnZSwgdGhp
cyBhbG1vc3QgcmV2ZXJ0cyBiYWNrIHRvIGEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIChzaW5jZSB0
aGVyZSBpcyBhbHdheXMNCiBnb2luZyB0byBiZSBhIGNoYW5nZSBzb21ld2hlcmUpLiZuYnNwOyBU
aGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVkIHRvIGhhdmUgaXQgaW5kZWVkIG9uIGEgcGVy
LW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFyZ3VtZW50LiZuYnNwOyBGb3Igc3VjaCBm
aW5lLWdyYWluZWQgdXBkYXRlcywgd2hlcmUgYSBjbGllbnQgaXMgaW5kZWVkIGludGVyZXN0IGlu
IGdldHRpbmcgZGVsYXlzIG9mIGluZGl2aWR1YWwgb2JqZWN0cyB3aXRob3V0IGRlbGF5LCAmbmJz
cDthDQogY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaCBtdWx0aXBsZSDigJxt
aWNyb+KAnSBzdWJzY3JpcHRpb25zLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6WkgtQ04iPlRDQXMgaW4gUk1PTiBhcmUgc29tZXRoaW5nIGRpZmZlcmVudCBhbHRvZ2V0
aGVyLiZuYnNwOyBUaGlzIGlzIHNvbWV0aGluZyB3ZSBhcmUgdHJ5aW5nIHRvIGFkZHJlc3Mgd2l0
aCBzbWFydCBmaWx0ZXJzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OlpILUNOIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI
LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBOZXRjb25mIFs8
YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bmV0Y29uZi1i
b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJy
Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMTA6MTggQU08YnI+
DQo8Yj5Ubzo8L2I+IE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFp
bC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1p
ZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n
dWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t
ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwg
TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g
c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IaSw8YnI+DQo8YnI+DQouLi4uPGJy
Pg0KPGJyPg0KbyZuYnNwOyAzLjE8YnI+DQo8YnI+DQombmJzcDsgSSdtIG5vdCBzdXJlIEkgdW5k
ZXJzdGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LiZuYnNwOyBMZXQnczxicj4NCiZu
YnNwOyBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMuJm5ic3A7IFRoZW4g
Y2hhbmdlcyBoYXBwZW4gYXQ8YnI+DQombmJzcDsgdGltZXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZu
YnNwOyAyJm5ic3A7IDMmbmJzcDsgNCZuYnNwOyAxMSZuYnNwOyAxMyZuYnNwOyAxNCZuYnNwOyAx
NTxicj4NCjxicj4NCiZuYnNwOyBGcm9tIHRoZSBkZXNjcmlwdGlvbiwgaXQgc2VlbXMgSSB3b3Vs
ZCByZWNlaXZlIDQgbm90aWZpY2F0aW9ucywgZnJvbTxicj4NCiZuYnNwOyB0aW1lczo8YnI+DQo8
YnI+DQombmJzcDsgJm5ic3A7IDImbmJzcDsgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAy
KTxicj4NCiZuYnNwOyAmbmJzcDsgMTIgKGNvbnRhaW5pbmcgY2hhbmdlIGZyb20gMyw0LDExKTxi
cj4NCiZuYnNwOyAmbmJzcDsgMTMgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAxMyk8YnI+
DQombmJzcDsgJm5ic3A7IDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwxNSk8YnI+DQo8
YnI+DQombmJzcDsgSXMgdGhpcyBjb3JyZWN0Pzxicj4NCjxicj4NCiZuYnNwOyBJbiBhbnkgY2Fz
ZSwgSSBzdWdnZXN0IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgWUFORyBtb2R1bGUgaXM8YnI+DQom
bmJzcDsgY2xhcmlmaWVkIC0gY3VycmVudGx5IHRoZSBSRkMgdGV4dCBjb250YWlucyBtb3JlIGRl
dGFpbHMgdGhhbiB0aGU8YnI+DQombmJzcDsgWUFORyBtb2R1bGUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6WkgtQ04iPlNlZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJ
IHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s
YW5ndWFnZTpaSC1DTiI+dG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNoIG5v
ZGUgd2l0aGluIHRoZSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh
bmd1YWdlOlpILUNOIj5JIHdhbnQgJnF1b3Q7YXQgbW9zdCwgMSBub3RpZmljYXRpb24gcGVyIHNl
Y29uZCZxdW90Oy4mbmJzcDsgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+dG8gYmUgdG9sZCBhYm91dCBhbiBpbmRp
dmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuJm5ic3A7IEkgY291bGQgc3RpbGw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmdldCAxMCwwMDAgZXZlbnRz
L3NlYyBidXQgZm9yIGRpZmZlcmVudCBkYXRhIG5vZGVzLiZuYnNwOyBUaGUgcmVjZWl2ZXIgZG9l
cyBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnJlYWxseSBj
YXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJlcG9ydGVkIGluIGVhY2ggbm90aWZpY2F0aW9uLiBU
aGUgZ29hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+aXMgdG8g
c2ltcGx5IGxpbWl0IHRoZSBuZXR3b3JrIGFuZCBwcm9jZXNzb3IgbG9hZC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t
ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbSBhIHNlcnZlciBQT1YsIEkgZG8gbm90IHdhbnQg
YSB0aW1lciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmFuZCBjb21wbGV4IGNvZGUgdG8gY29uc3RydWN0IHRoZSBu
ZXh0IG9uLWNoYW5nZSBub3RpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh
bmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
WkgtQ04iPlJNT04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBkaWZmZXJlbnRseS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSByaXNpbmcgYW5kIGZhbGxpbmcg
dGhyZXNob2xkcyBhcmUgdXNlZCB0byBhcm0gYW5kIHJlLWFybSBhbiBldmVudCB0cmlnZ2VyLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIHRpbWUgYmV0d2Vl
biBjaGFuZ2VzIGlzIG5vdCB1c2VkIGF0IGFsbCB0byBkZXRlcm1pbmUgaG93IG1hbnkgZXZlbnRz
IHRvIHNlbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4oTm90
IHN1Z2dlc3RpbmcgYWxsIHlhbmctcHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4p
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklNTywgdGhlIG9wZXJhdG9yIHNo
b3VsZCBwdXQgZXZlbnRzIHRoYXQgcmVxdWlyZSBsb3ctbGF0ZW5jeSBpbnRvIGEgc2VwYXJhdGUg
c3Vic2NyaXB0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+
YW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBseSB0byB0aGUgZW50aXJlIHN1YnNj
cmlwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Li4uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt
c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJyPg0KL21hcnRpbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6WkgtQ04iPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6WkgtQ04iPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_912c3dc57e404c7ea7fbce529a3eaf19XCHRTP013ciscocom_--


From nobody Thu Nov 30 07:26:11 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3EF128A32 for ; Thu, 30 Nov 2017 07:26:09 -0800 (PST)
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 8goTYUm8wQP6 for ; Thu, 30 Nov 2017 07:26:05 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 462A3127977 for ; Thu, 30 Nov 2017 07:26:05 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 935961AE01AA; Thu, 30 Nov 2017 16:26:03 +0100 (CET)
Date: Thu, 30 Nov 2017 16:24:42 +0100 (CET)
Message-Id: <20171130.162442.383697022265230028.mbj@tail-f.com>
To: alexander.clemm@huawei.com
Cc: evoit@cisco.com, netconf@ietf.org, balazs.lengyel@ericsson.com, andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF756@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF756@sjceml521-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: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 15:26:10 -0000

Hi,

I'll reply to the on-change discussion here.

Alexander Clemm  wrote:
> Yes, thank you for the comments!  
> 
> As the mail is long, rather than commenting inline, let me make just a
> few additional replies in addition to Eric's:
> 
> - On the topic of how to mark on-change notifiable YANG objects:
> 
> Yes, clearly what is on-change notifiable and what is not could differ
> by implementation.  We thought that asking implementors to define
> implementation-specific modules that would indicate the on-change
> notifiability through deviations would make sense, since this is
> really one of the function of deviations - indicate what is
> implementation-specific.

Actually, I think it mis-uses the deviation statement a bit.  From the
spec:

   Deviations define the way a server or class of servers deviate from a
   standard.

   [...]

   Server deviations are strongly discouraged and MUST only be used as a
   last resort.  Telling the application how a server fails to follow a
   standard is no substitute for implementing the standard correctly.  A
   server that deviates from a module is not fully compliant with the
   module.


We have discussed an "annotate" statement before, which would be used
to add information to schema nodes.  (we actually have such a
statement as a vendor-specific extension, and it is used a lot).  But
even if we had that, I'm not sure that would be the best solution in
this case.

> In that sense, the current solution does
> make sense to me and seems to be in the spirit of how
> implementation-specific YANG modules should be used.
> 
> That said, the other proposal to have a "meta-module" that contains a
> list of objects for which on-change notification is supported could be
> certainly be an alternative.  However, the notifiability should be
> indicated per node at the schema level, not for each individual
> instance.  We would not want to have to enumerate individual list
> entries, for example. Also, are there additional considerations to
> accommodate schema-mount in that case?
> 
> Another thought, perhaps on-change notifiability is something that
> could instead also be included in the YANG library.  Each module in
> the library would then list the nodes for which on-change is
> notifiable on a given server.

That's also an option.

I think we want somehting that is available on-line in runtime, but
that also can be stored in an off-line file (ala AGENT-CAPABILITIES).
Augmentation of yang library probably solved both these cases.


> Deferring this until later might also an option.

I think that's my preferred option.  At least if we want to finish
this document sooner rather than later...


> I am sure there will
> be other annotations/markings for objects that we will come up with
> our time.  However, one issue is that by default we did not want to
> make assumptions about on-change notifiability being supported.
> Rather, when it is supported, it would be specifically indicated; the
> default would be that it's not supported.  If we defer the solution
> until later, then this won't work.

Well, there's alread a feature to indicate *some* support.  If we
defer, we'd just write that how an implementation communicates which
nodes it supports for on-change is out of scope.

> If we wanted to defer, it would
> seem what we should do is still propose a solution informally in an
> appendix, and indicate that this may be later replaced by another
> solution.  We would put the YANG extension into an own separate
> module.

I don't think that's a good solution.  I don't think we should
encourage the extension-statement solution.

As one data point, in our implementation, all config nodes in the
conventional datastores would be available for on-change.  For
operational state, it is up to the instrumentation.


> - on the Subscription Policy term (3.6).  Sure, we don't need to
> - introduce a new term, but really what the parameters describe is in
> - fact a policy.  We could of course call them "datastore subscription
> - specific configuration parameters", or "datastore subscription
> - specific behavior configuration" , but this sounds a bit awkward to
> - me.

I would actually prefer more concrete words like the ones you
propose.


> - on the "no-such-datastore" eror tag: true, invalid-value would cover
> - this, but why be general when we can be specific?

I'll reply to this in my reply to Eric.


/martin



> 
> 
> --- Alex
> 
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit
> > (evoit)
> > Sent: Wednesday, November 29, 2017 9:37 AM
> > To: Martin Bjorklund ; netconf@ietf.org; Balazs
> > Lengyel
> >  (balazs.lengyel@ericsson.com)
> > ; Andy Bierman (andy@yumaworks.com)
> > 
> > Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> > 
> > Hi Martin,
> > 
> > Thanks for the comments.   Many thoughts in-line...
> > 
> > > From: Martin Bjorklund, November 28, 2017 4:38 AM
> > >
> > > Hi,
> > >
> > >
> > > I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> > > somewhat more important comment, and several others.
> > >
> > > Important issue:
> > >
> > > o  3.10
> > >
> > >   I don't think the proposed YANG extension is the correct solution to
> > >   the stated problem, for several reasons:
> > 
> > In general we agree there are several alternatives to solve this
> > issue.  And
> > any mechanism supported by the WG would be fine.
> > 
> > My read of your proposal below is that it does reuse elements of 3.10.
> > For
> > example, I *think* you are proposing hierarchical inheritance of
> > on-change
> > property markings of the parent rather than making every instance.
> > Because
> > marking every instance within a routing table would be prohibitively
> > expensive.  So based on whatever commonality we can establish across
> > the
> > proposed alternatives, perhaps we can come to a common way to set this
> > information.    If not, we can back out on-change marking as something
> > implementation-specific for this current specification.
> > 
> > Stepping back a minute, it is good to think about who would use this
> > on-
> > change support data.  Application developers are going to make
> > subscription
> > requests.  And they are far more likely to want to design based on the
> > schema level information exposed rather than instance data.  Driven by
> > that
> > constraint, the current proposal is framed as is -- mostly since there
> > was no
> > interest in Balazs'
> > https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-00
> > which was designed to support application developers needing this
> > information.  Without this draft, at the time this was proposed the
> > next-best
> > thing was an extension which works based on the established pattern of
> > deviations.
> > 
> > To cover this issue, I have re-opened YP#10 to track and resolve...
> > https://github.com/netconf-wg/yang-push/issues/10
> > 
> > Below are some specific pros/cons I see...
> > 
> > >     1.  In most cases, this is not a property of the data model, but
> > >         of the implementation, and possibly even the deployment.  So
> > >         having a YANG extension statement is not a good solution.
> > 
> > Fully agree this can be implementation level issue.  But then again,
> > so is any
> > deviation.
> > 
> > So to cover "property of the implementation" case, the proposed
> > extension
> > would typically be included in deviations file per implementation.
> > Such an
> > approach does mirror existing mechanisms for deviations, and has the
> > benefit of not requiring another a new totally separate file to
> > document the
> > desired behavior.
> > 
> > As for times this might be deployment specific, we saw potential
> > capacity
> > issues determining whether something might not be on-change
> > subscribable.   Here it would be up to the implementation to determine
> > whether to use the error "on-change-unsupported" from YANG Push, or
> > the
> > error "insufficient-resources" from subscribed notifications.  A
> > choice
> > between the two can be driven based on whether a deployment would
> > *ever* have capacity for the requested subscription.
> > 
> > >     2.  With NDMA, the same schema node is present in different
> > >         datastores.  It might be the case that an implementation
> > >         supports on-change for the node in a configuration datastore,
> > >         but not in operational.  Again, marking a node in the schema
> > >         is not a good solution.
> > 
> > As the current solution was developed before NMDA, we didn't consider
> > differences in on-change support for different datastores.  So this is
> > a real
> > consideration.
> > 
> > If for a minute we assume we are going to follow the current approach
> > in the
> > draft, the extension proposed in 3.10 could have a default of the
> > operational
> > datastore.  And we could add the option of including a list of
> > datastores in the
> > extension whenever on-change for something else is needed/supported..
> > 
> > >     3.  Since the on-change property is implementation dependent, it
> > >         means the information will be available to clients only in
> > >         deviation modules.  This is quite an expensive and complicated
> > >         way to pass the information to the clients.
> > 
> > Visibility to application developers was one reason we went down this
> > path.
> > Any solution needs to frame this visibility as a key element.
> > Considering this,
> > I actually see a need both for the schema based solution as framed,
> > and the
> > possibility of an instance based mechanism if someone wanted the lower
> > level of granularity.  Per above, I don't think instance data within
> > all instance
> > objects like routing entries is possible anyplace datastore size
> > becomes a
> > factor.
> > 
> > >   An alternative solution could be to have an ordered list of
> > >   instance-identifiers that list this property, per datastore, for
> > >   example:
> > >
> > >    
> > >      /sys:system/sys:system-time
> > >      false
> > >    
> > >    
> > >      /sys:system
> > >      true
> > >    
> > 
> > This could work.  Several questions which would need to be addressed
> > with
> > this approach:
> > 
> > (1) how would application developers easily know what objects are on-
> > change subscribable?
> > 
> > (2) If this is per-instance, is the property inherited from a parent?
> > If no, how
> > do we deal with the size of the resulting information?
> > 
> > (3) If this is per-instance, how is this information populated?  Don't
> > you need
> > schema level guidance recorded somewhere anyway?
> > 
> > (4) Are there any issues with things like Schema mount?
> > 
> > >   Yet another alternative would be to leave this to future work.
> > 
> > If necessary, we can push this out.   I am hoping we can come up with
> > something here, especially as the on-chance implementations I have
> > seen
> > have all used phased introduction of on-change for different schema
> > objects.
> > 
> > > Other comments:
> > >
> > >
> > > o  2
> > >
> > >   The document uses the term "YANG datastore" (it is even in the title
> > >   of the document).  This term is not used elsewhere, and it is not
> > >   defined in this document.  I suggest you change this to simply
> > >   "datastore".
> > 
> > In general, I am fine with making the change to "Datastore" throughout
> > the
> > document.  For the title, I think it better to keep YANG to allow
> > casual
> > readers easy access to the context.
> > 
> > >   Also, I think you should "import" the term "datastore" from
> > >   draft-ietf-netmod-revised-datastores, instead of having a slightly
> > >   different term in this document.
> > 
> > Can do.
> > 
> > >   It is also unfortunate that you use the term "data node" in a
> > >   different meaning than RFC 7950.  Maybe use "datastore node"
> > >   instead?
> > 
> > Can do.
> > 
> > >
> > > o  3.1
> > >
> > >   I'm not sure I understand the dampening period concept.  Let's
> > >   assume that the dampening period is 10s.  Then changes happen at
> > >   times:
> > >
> > >     2  3  4  11  13  14  15
> > >
> > >   From the description, it seems I would receive 4 notifications, from
> > >   times:
> > >
> > >     2  (containing only change from 2)
> > >     12 (containing change from 3,4,11)
> > >     13 (containing only change from 13)
> > >     23 (containing changes from 14,15)
> > 
> > Should be 2, 12, & 22.  I have updated the definition (below) in a way
> > which
> > hopefully clarifies the proper behavior
> > 
> >          +  Dampening period: In an on-change subscription, detected object
> > changes should be sent as quickly as possible.  However without
> > adequate
> > protections, a rapid series of object changes might exhaust of
> > resources in
> > the publisher or receiver.  In order to protect against that, a
> > dampening
> > period MAY be used to specify the interval which must pass before
> > successive update records for the same subscription are generated for
> > a
> > receiver.  The dampening period collectively applies to the set of all
> > data
> > nodes selected by a single subscription and sent to a single receiver.
> > This
> > means that when there is a change to a subscribed object, an update
> > record
> > containing that object is created either immediately when no dampening
> > period is in effect, or at the end of a dampening period.  A dampening
> > period
> > is reset every time a new notification message is passed to transport.
> > 
> > >   Is this correct?
> > >
> > >   In any case, I suggest the description in the YANG module is
> > >   clarified - currently the RFC text contains more details than the
> > >   YANG module.
> > 
> > I have updated the YANG module text as:
> > 
> > "Specifies the interval which must pass before successive update
> > records for
> > the same subscription are generated for a receiver.  The dampening
> > period
> > collectively applies to the set of all data nodes selected by a single
> > subscription and sent to a single receiver.  This means that when
> > there is a
> > change to a subscribed object, an update record containing that object
> > is
> > created either immediately when no dampening period is in effect, or
> > at the
> > end of a dampening period.  A dampening period is reset every time a
> > new
> > notification message is passed to transport.  A dampening period is
> > reset
> > every time a new notification message is passed to transport.  A zero
> > value
> > indicates no dampening period, and all subscribed object changes are
> > sent
> > immediately."
> > 
> > > o  3.2
> > >
> > >   The text says:
> > >
> > >      Therefore, in order to minimize the number of subscription
> > >      iterations between subscriber and publisher, dynamic
> > >      subscriptions SHOULD support a simple negotiation between
> > >      subscribers and publishers for subscription parameters.
> > >
> > >   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
> > >   specified in this draft does indeed support simple "negotiation".
> > >   Maybe s/SHOULD support/supports/ ?
> > 
> > Yes.  Will remove the SHOULD, showing just "supports".
> > 
> > > o  3.4
> > >
> > >   The text says:
> > >
> > >     Please see [promise] for
> > >     more on the transactional basis underlying the publisher and
> > >     subscriber interactions within this document.
> > >
> > >   So I did that.  But I didn't find any text in the referenced
> > >   document that talked about "the transactional basis".
> > >
> > >   I suggest you remove this sentence from the draft.
> > 
> > As this is informative, I can remove.
> > 
> > > o  3.5
> > >
> > >   The text says:
> > >
> > >      A publisher MUST support XML encoding and MAY support other
> > >      encodings such as JSON encoding.
> > >
> > >   I don't think this is correct.  A RESTCONF sever is not required to
> > >   support XML.  I think you should remove this sentence.
> > 
> > ok
> > 
> > > o  3.5.1
> > >
> > >      In a periodic subscription, the data included as part of an update
> > >      corresponds to data that could have been simply retrieved using a get
> > >      operation and is encoded in the same way.
> > >
> > >   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
> > >    or something else?  Whatabout other protocols?
> > 
> > As YANG Push is intended to be transport independent, it is better not
> > to
> > provide a specific transport.   Instead, how about the following text:
> > 
> > In a periodic subscription, the update record MUST include the
> > datastore
> > nodes which would have been retrieved using an equivalent datastore
> > selection operation over that subscription's transport.
> > 
> > >   (In 3.6, you use simply "a GET" for probably the same thing.)
> > 
> > If you are good with the text above, I will change 3.6 to:
> > 
> > " to what is available with a datastore selection operations".
> > 
> > > o  3.6
> > >
> > >      Subscription policy specifies both the selection filters and the
> > >      datastores against which these selection filters will be applied.
> > >      The result is the push of information necessary to remotely maintain
> > >      an extract of the publisher's datastore.
> > >
> > >   It seems this paragraph defines the term "Subscription policy".  But
> > >   this term is not used in the document.
> > 
> > We don't intend to define a new term in this paragraph.  And you are
> > correct,
> > policy only appears elsewhere in the document as part of the YANG
> > model
> > group names.    (more below)
> > 
> > >  What does it means that the  result of a policy is "the push of
> > information"?
> > >
> > >   I think I don't understand what this paragraph tries to tell me.
> > 
> > What if I changes the first paragraph of Section 3.6 to:
> > 
> > An objective of YANG push is to allow the replication of a subset of a
> > publisher's datastore within a receiver.  The datastore selection
> > filter defines
> > this subset.  Only a single selection filter can be applied to a
> > subscription at a
> > time.  The selection filter types defined in this include:
> > 
> > > o  3.6
> > >
> > >      o  xpath: An xpath selection filter is an XPath expression which may
> > >         be meaningfully applied to a datastore.
> > >
> > >    What does "meaningfully applied" mean?
> > 
> > There are plenty of valid xpath expressions which don't select data
> > nodes.
> > How about:
> > 
> > " xpath: An xpath selection filter is an XPath expression which
> > references
> > data nodes. When applied to a datastore, it is the results of this
> > expression
> > which will be pushed."
> > 
> > > o  3.6
> > >
> > >      Selection filters are not intended to be used to filter objects
> > >      based on a non-key property.  Supporting non-key property
> > >      filtering so would have a number of implications that would
> > >      result in significant complexity.
> > >
> > >      [...]
> > >
> > >      the goal is to
> > >      provide equivalent capabilities to what is available with a GET.
> > >
> > >   In GET you can filter on "non-key properties".
> > >
> > >   I think you should remove the text about "non-key properties".  If
> > >   anything, I think you can allow an implementation to reject a filter
> > >   that would be too complex to implement / evaluate (in fact I think
> > >   the text already allows a server to reject such filters.)
> > 
> > The issue with non-key properties is how to deal with the creation and
> > deletion of objects when a non-key property goes in/out of the
> > selection.
> > Others were uncomfortable with things like passing along a patch
> > showing a
> > node was deleted, when in reality the property simply changed from
> > meeting the selection filter to failing the selection filter.  So
> > people wanted
> > to default to the simpler case of key properties for selection.
> > 
> > Based on that I can delete the words "but the goal is to provide
> > equivalent
> > capabilities to what is available with a GET".
> > 
> > >   With the current text, is this filter ok:
> > >
> > >      /interfaces/interface[contains(name, "eth")]
> > >
> > >   It filters on a key, so it should be ok, right?
> > 
> > Yes
> > 
> > > o  3.7
> > >
> > >   The XML examples are not using the correct XML namespace for the
> > >   nodes from the "ietf-interface" module.
> > >
> > >   The YANG Patch example also shows an interesting effect in the
> > >   "patch-id" and "edit-id" leafs.  I think the draft should mention
> > >   how implementations are suppose to fill in these leafs.
> > 
> > Will add how to populate.  In summary, sequential numbering of
> > "edit-id"
> > was from the RFC-8072.   And a null "patch-id" is because patch-id is
> > mandatory in RFC-8072, and was originally supposed to be used for
> > debugging of failed datastore write operations.  That really isn't the
> > case
> > here, plus we have subscription-id and other object available.
> > 
> > >   The "target" leaf is not specified correctly.  It should be:
> > >
> > >          /ietf-interfaces:interfaces-state
> > 
> > Good catch.  Making change.
> > 
> > > o  3.8
> > >
> > >   The example has:
> > >
> > >     > >        xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
> > >        xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
> > >       
> > >          > > xmlns="urn:ietf:params:xml:ns:yang:ietf-datastores">
> > >
> > >   This doesn't match the YANG model; there is no container called
> > >   "datastore" in the model.
> > >
> > >   Further is has:
> > >
> > >          > >             xmlns:ex="http://example.com/sample-data/1.0"
> > >             select="/ex:foo"/>
> > >
> > >   a subtree-filter of type xpath?  I think ot should be:
> > >
> > >         
> > >            /ex:foo
> > >         
> > 
> > Yes
> > 
> > >   Also, it has:
> > >
> > >         
> > >           operational
> > >         
> > >
> > >   which should be:
> > >
> > >         
> > >           ds:operational
> > >         
> > 
> > At the last IETF, Kent pointed us to YANG Lint which should allow us
> > to do
> > example checking in ways not previously known to us.  I will install
> > and
> > attempt to use these to clear the example items you have listed.
> > 
> > > o  3.9
> > >
> > >   This section lists three cases for which:
> > >
> > >      the error identity "data-unavailable" SHOULD be returned.
> > >
> > >   One of the cases is:
> > >
> > >     o  the authorization privileges of a receiver change over the course
> > >        of the subscription.
> > >
> > >   But how can a server know this when "establish-subscription" is sent?
> > 
> > It cannot know this at "establish-subscription".  So a publisher will
> > have to
> > track whether the permissions on subscribed objects change.  How is
> > left to
> > implementations.
> > 
> > > o  3.9
> > >
> > >      The contextual authorization model for data in YANG datastores is
> > >      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
> > >
> > >   Did you mean s/contextual/conceptual/ ?
> > 
> > Will make that change.
> > 
> > > o  3.11.1
> > >
> > >
> > >   OLD:
> > >
> > >        If
> > >        this is not possible and the synch-on-start option is
> > > configured,
> > >
> > >   NEW:
> > >
> > >        If
> > >        this is not possible and the "no-synch-on-start" option is not
> > >        present for the subscription.
> > >
> > >
> > >   (fixes incorrect name of leaf, and also covers dynamic
> > >   subscriptions)
> > 
> > Yes, good catch.  Will fix.
> > 
> > > o  4.3.2
> > >
> > >      A subscription-id MUST be transported along with the subscribed
> > >      contents.
> > >
> > >   Then the leaf "subscription-id" should be mandatory.
> > 
> > The requirement is that a subscription-id must be in the notification
> > message, this doesn't mean that the subscription-id must be within the
> > two
> > new notifications.  The reason for this is that when we add support
> > for the
> > notification-messages draft, but having the subscription-id optional
> > in the
> > push-update and push-change-update, we can enable implementations
> > which do not duplicate this header item.  (And a duplication would be
> > forced
> > with the future header if we made this mandatory.)
> > 
> > >      A "time-of-update" which represents the time an update record
> > >      snapshot was generated.  A receiver MAY assume that a publisher's
> > >      objects have these pushed values at this point in time.
> > >
> > >   Should "time-of-update" be mandatory?
> > 
> > Two reasons it is not:
> > (a) Other vendors have worried they can only support message-time,
> > rather
> > than notification-time.
> > (b) Notification-time is the generalized name for "time-of-update" .
> > Having
> > "time-of-update" as optional allows for eventual migration to common
> > headers of draft-ietf-netconf-notification-messages without
> > information
> > duplication
> > 
> > >   How is "time-of-update" different from "eventTime" in the
> > >   notification?
> > 
> > I think that answer is above.  But there is some good guidance here
> > from
> > draft-ietf-netconf-notification-messages.  The new draft ultimately
> > will
> > define and support the following times:
> > 
> > message-time:
> >       "Header information consisting of time the message headers were placed
> > generated prior to being sent to transport";
> > 
> > notification-time
> >       "Header information consisting of the time an originating process
> >       created
> > the notification."
> > 
> > Notification-time should be equivalent to eventTime from RFC-5277.
> > But
> > some other vendors have said they really only have message-time, and
> > this is
> > what they are populating in eventTime even though it doesn't
> > explicitly fit
> > the definition.  With the new definitions, at least they should be
> > able to
> > populate what they explicitly have.
> > 
> > > o  4.3.2
> > >
> > >      If the application detects an informational discontinuity
> > >
> > >   What is an "informational discontinuity"?
> > 
> > Will change to:
> >   If the application detects any incompleteness in set of objects placed
> >   into a
> > "push-update" or "push-change-update"
> > 
> > > o  4.4.1 / 4.4.2
> > >
> > >   The XML examples are broken; compare with my comments for 3.8.
> > 
> > Will do.  I am hoping a new attempt using yanglint helps pick out
> > everything I
> > missed by hand previously.
> > 
> > > o  5
> > >
> > >   OLD:
> > >
> > >     "This module contains conceptual YANG specifications
> > >      for YANG push.";
> > >
> > >   NEW:
> > >
> > >     "This module contains YANG specifications for YANG push.";
> > 
> > ok
> > 
> > > o  5 - identities
> > >
> > >     identity qos-unsupported {
> > >       base sn:error;
> > >       description
> > >         "Subscription QoS parameters not supported on this platform.";
> > >     }
> > >
> > >   This identity is not mentioned anywhere in the text.  Instead of
> > >   having this identity, wouldn't it be better to define a feature for
> > >   "qos", and mark the nodes you have in mind with an if-feature?
> > 
> > It is possible to expose QoS explicitly as a feature.  I will make
> > that addition if
> > you are ok with my other QoS comment described below about subscribed-
> > notifications.
> > 
> > But even in that case if QoS is not supported, and someone includes
> > QoS
> > objects in an "establish-subscription" we need this identity as an
> > error.  This
> > error allow an explicit identification of what was wrong in the RPC
> > (such as a
> > DSCP provided is not supported by the Publisher).  I will include this
> > in the
> > Identity description.
> > 
> > >     identity on-change-unsupported {
> > >       base sn:error;
> > >       description
> > >         "On-change not supported.";
> > >     }
> > >
> > >   When will this identity be used?  There is already a feature
> > >   "on-change" and corresponding if-feature statements.
> > 
> > Per our discussion above, this can be used if an RPC asks for
> > on-change for an
> > object which is not available at a platform deployment (either marked
> > in the
> > schema, or a specific deployment doesn't support an object which is
> > included).  I will enhance the description based on the discussion on
> > this
> > earlier in this thread.
> > 
> > >     identity on-change-synch-unsupported {
> > >       base sn:error;
> > >       description
> > >         "On-change synch-on-start and resynchonization not supported.";
> > >     }
> > >
> > >   The leaf is called "no-sync-on-start", which implies that sync on
> > >   start is the default.  So when will this identity be used?
> > 
> > Can be used in two places:
> > 
> > (1) Will be used if an RPC asks to synch on start, but it can't be
> > supported for
> > any reason (e.g., no nodes identifiable within the selection filter
> > will ever be
> > support on-change).   Will enhance the definition.
> > 
> > (2) The resynch RPC is invoked on a periodic subscription-id, or on an
> > on-
> > change subscription which can't support synchronization.
> > 
> > >     identity reference-mismatch {
> > >      base sn:error;
> > >       description
> > >        "Mismatch in filter key and referenced yang subtree.";
> > >     }
> > >
> > >   I don't understand the description of this identity.  Please
> > >   clarify.
> > 
> > Will clarify description to explain that the key provided with the
> > filter does
> > not match the data type of the referenced yang subtree
> > 
> > >      identity datatree-size {
> > >
> > >   Should it be "result-too-big" or something?
> > 
> > Yes.   I will change the name.
> > 
> > >     identity no-such-datastore {
> > >
> > >   I think this one should be removed.  The normal "invalid-value"
> > >   error-tag covers this error.
> > >
> > >
> > >       identity custom-datastore {
> > >         base ds:datastore;
> > >         description
> > >           "A datastore with boundaries not defined within
> > >            draft-ietf-netmod-revised-datastores";
> > >       }
> > >
> > >   This identity needs to be removed.  If someone defines a custom
> > >   datastore, it would get a specific identity, and that identity can
> > >   be used as "source".
> > 
> > Yes, any new custom datastore will get a new identity, but if that new
> > identity uses this custom-datastore one as a base, then we have an
> > umbrella
> > identity which is a handle just for the custom ones.  That was the
> > intent of
> > this.  If you don't think that an identity which acts as a bundling
> > mechanism is
> > useful, we can remove.
> > 
> > > o  5 - "change-type"
> > >
> > >   The descriptions of the enums need to be improved.  This is about
> > >   reporting a change in a datastore.  The value "create" is described
> > >   as:
> > >
> > >         description
> > >           "Create a new data resource if it does not already exist.  If
> > >           it already exists, replace.";
> > >
> > >   Also, the description of the typedef has:
> > >
> > >       "RFC 8072 section 2.5, with a delta that it is ok to receive
> > >       ability create on an existing node, or receive a delete on a
> > >       missing node.";
> > >
> > >   But what does this mean?  The type is used to *exclude* some changes
> > >   from a yang patch record.
> > 
> > This is to identify churn within a datastore during a dampening
> > period.  Two
> > examples of when this is needed:
> > 
> > (1) For security applications, it is an absolute requirement that you
> > know if a
> > node was added and then removed during a dampening period.   For an
> > example, a hacker adds a "permit any any" which is then quickly
> > removed
> > before the dampening period ends.  Remote applications need to know
> > that
> > churn occurred.
> > 
> > (2) For network management applications when a physical interface is
> > going
> > down and then quickly back up.  If the up/down is transient, how do
> > you
> > know that this occurred if there is no notification that churn
> > occurred?
> > 
> > To support this, the YANG patch definition is loosened to allow the
> > new
> > creation on an existing node (based on what resulted from the last
> > patch), or
> > a delete on a missing node.  This acts as an indication that some
> > churn in the
> > datastore happened even though the data is in the same state as a per
> > the
> > previous update.  And if an application get to sees this indication
> > when
> > comparing to the previous state, they have the option of looking more
> > closely at some logs on the publisher to determine what actually
> > happened.
> > 
> > I can see that this behavior is under-described in the text.  I will
> > put a small
> > section between sections 3.10 & 3.11 describing this.  The title will
> > be
> > "Identification of a transient change within dampening period"
> > 
> > > o  5 - selection filter
> > >
> > >   The XPath expression is not properly defined.
> > >
> > >   OLD:
> > >
> > >           "This parameter contains an XPath expression identifying the
> > >           portions of the target datastore to retrieve.";
> > >
> > >   NEW:
> > >
> > >           "This parameter contains an XPath expression identifying the
> > >            portions of the target datastore to retrieve.
> > >
> > >            If the expression returns a node-set, all nodes in the
> > >            node-set are selected by the filter.  Otherwise, if the
> > >            expression does not return a node-set, the filter
> > >            doesn't select any nodes.
> > >
> > >            FIXME: (*)
> > >
> > >            The expression is evaluated in the following XPath context:
> > >
> > >              o  The set of namespace declarations are those in scope on
> > >                 the 'xpath-filter' leaf element.
> > >
> > >              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 root node of the target
> > >                 datastore.
> > >
> > >
> > >   (*) - We need to describe when the filter is evaluated.  This is
> > >   also true for the subtree filter.  Is it evaluated when the
> > >   subscription is started and explicitly modified, or everytime a
> > >   change is detected?
> > >
> > >   [Side note: this description is also missing from the "xpath-filter"
> > >   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
> > >   updated the description in that draft.]
> > 
> > I will update the descriptions to match your draft.
> > 
> > As for when the evaluation occurs, I am not sure what you mean.  Every
> > time
> > a change occurs, you need to see if the changed object would have
> > fallen
> > within the selection.  There is no attempt to support an
> > event-condition-
> > action context.
> > 
> > > o  5 - terminology
> > >
> > >   The term "agent" is used a couple of times.  Use "publisher" or
> > >   "server" instead.
> > 
> > Will update
> > 
> > > o  5 - dampening
> > >
> > >           leaf dampening-period {
> > >             type yang:timeticks;
> > >             mandatory true;
> > >
> > >    Should this instead be:
> > >
> > >           leaf dampening-period {
> > >             type yang:timeticks;
> > >             default "0";
> > >
> > >    So that the request is the same if the "on-change" feature is
> > >    support or not.
> > 
> > I like it, will update.
> > 
> > > o  5 - no-synch-on-start
> > >
> > >              When
> > >              present, pushing a full selection per the terms of the
> > >              selection filter MAY NOT be done for this subscription.
> > >
> > >    Did you mean s/MAY NOT/MUST NOT/ ?
> > >
> > >    MAY NOT is not a 2119 term.
> > 
> > Will change to MUST NOT.
> > 
> > > o  5 - QoS
> > >
> > >   Why are the qos parameters defined in yang push, and not in
> > >   subscribed notifications?  It seems that they are generic.
> > 
> > This question has come up before.  Basically current 5277 event
> > streams
> > haven't shown need for QoS to date.   We know that QoS has been
> > requested to handle congestion issues for YANG push.  So for
> > simplicities
> > sake, we bundled all QoS elements together in YANG push where we knew
> > there was demonstrable need.  If someone really is asking for these
> > QoS
> > constructs for events, we can revisit.
> > 
> > > o  5 - establish-subscription params
> > >
> > >   I think a "when" expression should be added to the first augment:
> > >
> > >     augment "/sn:establish-subscription/sn:input" {
> > >       when "sn:target/yp:datastore/yp:source";
> > 
> > So this is saying that the named datastore must exist before allowing
> > the
> > augment.   Works for me.
> > 
> > > o  5 - push-update
> > >
> > >   What does the presence of "updates-not-sent" mean in "push-update"?
> > >   "push-update" contains a snapshot, not a diff, so why is
> > >   "updates-not-sent" present?
> > 
> > This is to indicate a system error where not all objects can be
> > extracted from
> > the datastore.  (e.g., the routing table got *lots* bigger, and the
> > periodic
> > extract cannot be performed as expected.)  At least some
> > implementations
> > have seen this.   I will add some clarifying text.
> > 
> > > o  5 - push-change-update
> > >
> > >         "This contains an incremental set of datastore changes needed
> > >          to update a remote datastore starting at the time of the
> > >          previous update, per the terms of the subscription.
> > >
> > >    What is an "incremental set"?  Probably s/incremental set/set/
> > 
> > I can change to "set".
> > 
> > > o  General
> > >
> > >   Use double quotes for node names.  "push-update", "subscription-id"
> > >   etc.  Quotes are currently used inconsistently, and it makes the
> > >   text harder to read.
> > 
> > Will make the fix.
> > 
> > Thanks again for all the excellent thoughts!
> > Eric
> > 
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Thu Nov 30 10:54:30 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9620C129423 for ; Thu, 30 Nov 2017 10:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3YAvliG8Vlm for ; Thu, 30 Nov 2017 10:54:25 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31928124D85 for ; Thu, 30 Nov 2017 10:54:25 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7C1AEA4393E45; Thu, 30 Nov 2017 18:54:20 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 18:54:22 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Thu, 30 Nov 2017 10:54:15 -0800
From: Alexander Clemm 
To: Martin Bjorklund , "balazs.lengyel@ericsson.com" , Mahesh Jethanandani ,  "kwatsen@juniper.net" 
CC: "evoit@cisco.com" , "netconf@ietf.org" , "andy@yumaworks.com" 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLZk3nYyMWGUek3uLlVrh0YqMsJzKA//+clGCAAdCsAP//rdxA
Date: Thu, 30 Nov 2017 18:54:14 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACFCD2@sjceml521-mbx.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF756@sjceml521-mbx.china.huawei.com> <20171130.162442.383697022265230028.mbj@tail-f.com>
In-Reply-To: <20171130.162442.383697022265230028.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 18:54:30 -0000

Hi Martin,

Instead of "deviation", we could also use "augmentation".  The point is tha=
t the implementation-specifics would be provided in an implementation-speci=
fic YANG module.  Clearly the possibility to have implementation-specific Y=
ANG modules is foreseen by the very fact that the deviation statement exist=
s, and the genie is out of the bottle here. =20

That said, yes, there was an original proposal to use annotations, which Ba=
lazs proposed.  When it became clear that the general annotations proposal =
wasn't moving forward, we settled for the next-best solution, which is the =
YANG extension (i.e. a very specific annotation to indicate on-change notif=
iability) that we have today. =20

As indicated by you and others on this thread, alternatively we can certain=
ly also simply defer this issue for now.  In this case, as you state, we wo=
uld simply indicate in the text that clients need to be aware that not ever=
y object may support on-change notifiability; how do discover which ones do=
 and which ones do not would be left outside the scope of the specification=
. =20

However, in that case it would still seem to make sense to propose a way in=
 which an implementation could address this in an informational appendix.  =
This informational appendix could then make the suggestions that implementa=
tions might support a module with such an extension, which we would then in=
clude in the appendix as an example.  Having a module enumerating the nodes=
 (per your earlier suggestion), or suggesting a library augmentation (witho=
ut introducing a dependency on that - can be informational only!) could be =
described there as well.  Perhaps it is a question to our WG chairs, Mahesh=
 and Kent, whether putting this as an informational example for a way in wh=
ich to addresss this would be feasible, in the same way as some drafts expl=
ain how something might be implemented - really this is a process question =
- or if it should simply be omitted entirely. =20

We would also make clear that if a subscription contains objects that are n=
ot on-change notifiable, no updates will be received (rather than rejecting=
 the subscription). =20

The more I think about this, the more I think that addressing this as part =
of the library will be the technically preferable option.  Having this as a=
n augmentation would work.  Is this something that we can include in the YA=
NG library -bis draft?  Really this is where this should go.  This could al=
so serve as an example there how the library might be used to keep track al=
so of other "annotations" in the future.  Perhaps something to discuss on t=
he other thread.

Thanks
--- Alex


> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, November 30, 2017 7:25 AM
> To: Alexander Clemm 
> Cc: evoit@cisco.com; netconf@ietf.org; balazs.lengyel@ericsson.com;
> andy@yumaworks.com
> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
>=20
> Hi,
>=20
> I'll reply to the on-change discussion here.
>=20
> Alexander Clemm  wrote:
> > Yes, thank you for the comments!
> >
> > As the mail is long, rather than commenting inline, let me make just a
> > few additional replies in addition to Eric's:
> >
> > - On the topic of how to mark on-change notifiable YANG objects:
> >
> > Yes, clearly what is on-change notifiable and what is not could differ
> > by implementation.  We thought that asking implementors to define
> > implementation-specific modules that would indicate the on-change
> > notifiability through deviations would make sense, since this is
> > really one of the function of deviations - indicate what is
> > implementation-specific.
>=20
> Actually, I think it mis-uses the deviation statement a bit.  From the
> spec:
>=20
>    Deviations define the way a server or class of servers deviate from a
>    standard.
>=20
>    [...]
>=20
>    Server deviations are strongly discouraged and MUST only be used as a
>    last resort.  Telling the application how a server fails to follow a
>    standard is no substitute for implementing the standard correctly.  A
>    server that deviates from a module is not fully compliant with the
>    module.
>=20
>=20
> We have discussed an "annotate" statement before, which would be used to
> add information to schema nodes.  (we actually have such a statement as a
> vendor-specific extension, and it is used a lot).  But even if we had tha=
t, I'm
> not sure that would be the best solution in this case.
>=20
> > In that sense, the current solution does make sense to me and seems to
> > be in the spirit of how implementation-specific YANG modules should be
> > used.
> >
> > That said, the other proposal to have a "meta-module" that contains a
> > list of objects for which on-change notification is supported could be
> > certainly be an alternative.  However, the notifiability should be
> > indicated per node at the schema level, not for each individual
> > instance.  We would not want to have to enumerate individual list
> > entries, for example. Also, are there additional considerations to
> > accommodate schema-mount in that case?
> >
> > Another thought, perhaps on-change notifiability is something that
> > could instead also be included in the YANG library.  Each module in
> > the library would then list the nodes for which on-change is
> > notifiable on a given server.
>=20
> That's also an option.
>=20
> I think we want somehting that is available on-line in runtime, but that =
also
> can be stored in an off-line file (ala AGENT-CAPABILITIES).
> Augmentation of yang library probably solved both these cases.
>=20
>=20
> > Deferring this until later might also an option.
>=20
> I think that's my preferred option.  At least if we want to finish this d=
ocument
> sooner rather than later...
>=20
>=20
> > I am sure there will
> > be other annotations/markings for objects that we will come up with
> > our time.  However, one issue is that by default we did not want to
> > make assumptions about on-change notifiability being supported.
> > Rather, when it is supported, it would be specifically indicated; the
> > default would be that it's not supported.  If we defer the solution
> > until later, then this won't work.
>=20
> Well, there's alread a feature to indicate *some* support.  If we defer, =
we'd
> just write that how an implementation communicates which nodes it
> supports for on-change is out of scope.
>=20
> > If we wanted to defer, it would
> > seem what we should do is still propose a solution informally in an
> > appendix, and indicate that this may be later replaced by another
> > solution.  We would put the YANG extension into an own separate
> > module.
>=20
> I don't think that's a good solution.  I don't think we should encourage =
the
> extension-statement solution.
>=20
> As one data point, in our implementation, all config nodes in the
> conventional datastores would be available for on-change.  For operationa=
l
> state, it is up to the instrumentation.
>=20
>=20
> > - on the Subscription Policy term (3.6).  Sure, we don't need to
> > - introduce a new term, but really what the parameters describe is in
> > - fact a policy.  We could of course call them "datastore subscription
> > - specific configuration parameters", or "datastore subscription
> > - specific behavior configuration" , but this sounds a bit awkward to
> > - me.
>=20
> I would actually prefer more concrete words like the ones you propose.
>=20
>=20
> > - on the "no-such-datastore" eror tag: true, invalid-value would cover
> > - this, but why be general when we can be specific?
>=20
> I'll reply to this in my reply to Eric.
>=20
>=20
> /martin
>=20
>=20
>=20
> >
> >
> > --- Alex
> >
> > > -----Original Message-----
> > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric
> > > Voit
> > > (evoit)
> > > Sent: Wednesday, November 29, 2017 9:37 AM
> > > To: Martin Bjorklund ; netconf@ietf.org; Balazs
> > > Lengyel  (balazs.lengyel@ericsson.com)
> > > ; Andy Bierman (andy@yumaworks.com)
> > > 
> > > Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> > >
> > > Hi Martin,
> > >
> > > Thanks for the comments.   Many thoughts in-line...
> > >
> > > > From: Martin Bjorklund, November 28, 2017 4:38 AM
> > > >
> > > > Hi,
> > > >
> > > >
> > > > I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> > > > somewhat more important comment, and several others.
> > > >
> > > > Important issue:
> > > >
> > > > o  3.10
> > > >
> > > >   I don't think the proposed YANG extension is the correct solution=
 to
> > > >   the stated problem, for several reasons:
> > >
> > > In general we agree there are several alternatives to solve this
> > > issue.  And any mechanism supported by the WG would be fine.
> > >
> > > My read of your proposal below is that it does reuse elements of 3.10=
.
> > > For
> > > example, I *think* you are proposing hierarchical inheritance of
> > > on-change property markings of the parent rather than making every
> > > instance.
> > > Because
> > > marking every instance within a routing table would be prohibitively
> > > expensive.  So based on whatever commonality we can establish across
> > > the proposed alternatives, perhaps we can come to a common way to
> > > set this
> > > information.    If not, we can back out on-change marking as somethin=
g
> > > implementation-specific for this current specification.
> > >
> > > Stepping back a minute, it is good to think about who would use this
> > > on-
> > > change support data.  Application developers are going to make
> > > subscription requests.  And they are far more likely to want to
> > > design based on the schema level information exposed rather than
> > > instance data.  Driven by that constraint, the current proposal is
> > > framed as is -- mostly since there was no interest in Balazs'
> > > https://tools.ietf.org/html/draft-lengyel-netmod-schema-annotation-0
> > > 0 which was designed to support application developers needing this
> > > information.  Without this draft, at the time this was proposed the
> > > next-best thing was an extension which works based on the
> > > established pattern of deviations.
> > >
> > > To cover this issue, I have re-opened YP#10 to track and resolve...
> > > https://github.com/netconf-wg/yang-push/issues/10
> > >
> > > Below are some specific pros/cons I see...
> > >
> > > >     1.  In most cases, this is not a property of the data model, bu=
t
> > > >         of the implementation, and possibly even the deployment.  S=
o
> > > >         having a YANG extension statement is not a good solution.
> > >
> > > Fully agree this can be implementation level issue.  But then again,
> > > so is any deviation.
> > >
> > > So to cover "property of the implementation" case, the proposed
> > > extension would typically be included in deviations file per
> > > implementation.
> > > Such an
> > > approach does mirror existing mechanisms for deviations, and has the
> > > benefit of not requiring another a new totally separate file to
> > > document the desired behavior.
> > >
> > > As for times this might be deployment specific, we saw potential
> > > capacity issues determining whether something might not be on-change
> > > subscribable.   Here it would be up to the implementation to determin=
e
> > > whether to use the error "on-change-unsupported" from YANG Push, or
> > > the error "insufficient-resources" from subscribed notifications.  A
> > > choice between the two can be driven based on whether a deployment
> > > would
> > > *ever* have capacity for the requested subscription.
> > >
> > > >     2.  With NDMA, the same schema node is present in different
> > > >         datastores.  It might be the case that an implementation
> > > >         supports on-change for the node in a configuration datastor=
e,
> > > >         but not in operational.  Again, marking a node in the schem=
a
> > > >         is not a good solution.
> > >
> > > As the current solution was developed before NMDA, we didn't
> > > consider differences in on-change support for different datastores.
> > > So this is a real consideration.
> > >
> > > If for a minute we assume we are going to follow the current
> > > approach in the draft, the extension proposed in 3.10 could have a
> > > default of the operational datastore.  And we could add the option
> > > of including a list of datastores in the extension whenever
> > > on-change for something else is needed/supported..
> > >
> > > >     3.  Since the on-change property is implementation dependent, i=
t
> > > >         means the information will be available to clients only in
> > > >         deviation modules.  This is quite an expensive and complica=
ted
> > > >         way to pass the information to the clients.
> > >
> > > Visibility to application developers was one reason we went down
> > > this path.
> > > Any solution needs to frame this visibility as a key element.
> > > Considering this,
> > > I actually see a need both for the schema based solution as framed,
> > > and the possibility of an instance based mechanism if someone wanted
> > > the lower level of granularity.  Per above, I don't think instance
> > > data within all instance objects like routing entries is possible
> > > anyplace datastore size becomes a factor.
> > >
> > > >   An alternative solution could be to have an ordered list of
> > > >   instance-identifiers that list this property, per datastore, for
> > > >   example:
> > > >
> > > >    
> > > >      /sys:system/sys:system-time
> > > >      false
> > > >    
> > > >    
> > > >      /sys:system
> > > >      true
> > > >    
> > >
> > > This could work.  Several questions which would need to be addressed
> > > with this approach:
> > >
> > > (1) how would application developers easily know what objects are
> > > on- change subscribable?
> > >
> > > (2) If this is per-instance, is the property inherited from a parent?
> > > If no, how
> > > do we deal with the size of the resulting information?
> > >
> > > (3) If this is per-instance, how is this information populated?
> > > Don't you need schema level guidance recorded somewhere anyway?
> > >
> > > (4) Are there any issues with things like Schema mount?
> > >
> > > >   Yet another alternative would be to leave this to future work.
> > >
> > > If necessary, we can push this out.   I am hoping we can come up with
> > > something here, especially as the on-chance implementations I have
> > > seen have all used phased introduction of on-change for different
> > > schema objects.
> > >
> > > > Other comments:
> > > >
> > > >
> > > > o  2
> > > >
> > > >   The document uses the term "YANG datastore" (it is even in the ti=
tle
> > > >   of the document).  This term is not used elsewhere, and it is not
> > > >   defined in this document.  I suggest you change this to simply
> > > >   "datastore".
> > >
> > > In general, I am fine with making the change to "Datastore"
> > > throughout the document.  For the title, I think it better to keep
> > > YANG to allow casual readers easy access to the context.
> > >
> > > >   Also, I think you should "import" the term "datastore" from
> > > >   draft-ietf-netmod-revised-datastores, instead of having a slightl=
y
> > > >   different term in this document.
> > >
> > > Can do.
> > >
> > > >   It is also unfortunate that you use the term "data node" in a
> > > >   different meaning than RFC 7950.  Maybe use "datastore node"
> > > >   instead?
> > >
> > > Can do.
> > >
> > > >
> > > > o  3.1
> > > >
> > > >   I'm not sure I understand the dampening period concept.  Let's
> > > >   assume that the dampening period is 10s.  Then changes happen at
> > > >   times:
> > > >
> > > >     2  3  4  11  13  14  15
> > > >
> > > >   From the description, it seems I would receive 4 notifications, f=
rom
> > > >   times:
> > > >
> > > >     2  (containing only change from 2)
> > > >     12 (containing change from 3,4,11)
> > > >     13 (containing only change from 13)
> > > >     23 (containing changes from 14,15)
> > >
> > > Should be 2, 12, & 22.  I have updated the definition (below) in a
> > > way which hopefully clarifies the proper behavior
> > >
> > >          +  Dampening period: In an on-change subscription, detected
> > > object changes should be sent as quickly as possible.  However
> > > without adequate protections, a rapid series of object changes might
> > > exhaust of resources in the publisher or receiver.  In order to
> > > protect against that, a dampening period MAY be used to specify the
> > > interval which must pass before successive update records for the
> > > same subscription are generated for a receiver.  The dampening
> > > period collectively applies to the set of all data nodes selected by
> > > a single subscription and sent to a single receiver.
> > > This
> > > means that when there is a change to a subscribed object, an update
> > > record containing that object is created either immediately when no
> > > dampening period is in effect, or at the end of a dampening period.
> > > A dampening period is reset every time a new notification message is
> > > passed to transport.
> > >
> > > >   Is this correct?
> > > >
> > > >   In any case, I suggest the description in the YANG module is
> > > >   clarified - currently the RFC text contains more details than the
> > > >   YANG module.
> > >
> > > I have updated the YANG module text as:
> > >
> > > "Specifies the interval which must pass before successive update
> > > records for the same subscription are generated for a receiver.  The
> > > dampening period collectively applies to the set of all data nodes
> > > selected by a single subscription and sent to a single receiver.
> > > This means that when there is a change to a subscribed object, an
> > > update record containing that object is created either immediately
> > > when no dampening period is in effect, or at the end of a dampening
> > > period.  A dampening period is reset every time a new notification
> > > message is passed to transport.  A dampening period is reset every
> > > time a new notification message is passed to transport.  A zero
> > > value indicates no dampening period, and all subscribed object
> > > changes are sent immediately."
> > >
> > > > o  3.2
> > > >
> > > >   The text says:
> > > >
> > > >      Therefore, in order to minimize the number of subscription
> > > >      iterations between subscriber and publisher, dynamic
> > > >      subscriptions SHOULD support a simple negotiation between
> > > >      subscribers and publishers for subscription parameters.
> > > >
> > > >   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions=
 as
> > > >   specified in this draft does indeed support simple "negotiation".
> > > >   Maybe s/SHOULD support/supports/ ?
> > >
> > > Yes.  Will remove the SHOULD, showing just "supports".
> > >
> > > > o  3.4
> > > >
> > > >   The text says:
> > > >
> > > >     Please see [promise] for
> > > >     more on the transactional basis underlying the publisher and
> > > >     subscriber interactions within this document.
> > > >
> > > >   So I did that.  But I didn't find any text in the referenced
> > > >   document that talked about "the transactional basis".
> > > >
> > > >   I suggest you remove this sentence from the draft.
> > >
> > > As this is informative, I can remove.
> > >
> > > > o  3.5
> > > >
> > > >   The text says:
> > > >
> > > >      A publisher MUST support XML encoding and MAY support other
> > > >      encodings such as JSON encoding.
> > > >
> > > >   I don't think this is correct.  A RESTCONF sever is not required =
to
> > > >   support XML.  I think you should remove this sentence.
> > >
> > > ok
> > >
> > > > o  3.5.1
> > > >
> > > >      In a periodic subscription, the data included as part of an up=
date
> > > >      corresponds to data that could have been simply retrieved usin=
g a
> get
> > > >      operation and is encoded in the same way.
> > > >
> > > >   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
> > > >    or something else?  Whatabout other protocols?
> > >
> > > As YANG Push is intended to be transport independent, it is better
> > > not to
> > > provide a specific transport.   Instead, how about the following text=
:
> > >
> > > In a periodic subscription, the update record MUST include the
> > > datastore nodes which would have been retrieved using an equivalent
> > > datastore selection operation over that subscription's transport.
> > >
> > > >   (In 3.6, you use simply "a GET" for probably the same thing.)
> > >
> > > If you are good with the text above, I will change 3.6 to:
> > >
> > > " to what is available with a datastore selection operations".
> > >
> > > > o  3.6
> > > >
> > > >      Subscription policy specifies both the selection filters and t=
he
> > > >      datastores against which these selection filters will be appli=
ed.
> > > >      The result is the push of information necessary to remotely ma=
intain
> > > >      an extract of the publisher's datastore.
> > > >
> > > >   It seems this paragraph defines the term "Subscription policy".  =
But
> > > >   this term is not used in the document.
> > >
> > > We don't intend to define a new term in this paragraph.  And you are
> > > correct, policy only appears elsewhere in the document as part of
> > > the YANG model
> > > group names.    (more below)
> > >
> > > >  What does it means that the  result of a policy is "the push of
> > > information"?
> > > >
> > > >   I think I don't understand what this paragraph tries to tell me.
> > >
> > > What if I changes the first paragraph of Section 3.6 to:
> > >
> > > An objective of YANG push is to allow the replication of a subset of
> > > a publisher's datastore within a receiver.  The datastore selection
> > > filter defines this subset.  Only a single selection filter can be
> > > applied to a subscription at a time.  The selection filter types
> > > defined in this include:
> > >
> > > > o  3.6
> > > >
> > > >      o  xpath: An xpath selection filter is an XPath expression whi=
ch may
> > > >         be meaningfully applied to a datastore.
> > > >
> > > >    What does "meaningfully applied" mean?
> > >
> > > There are plenty of valid xpath expressions which don't select data
> > > nodes.
> > > How about:
> > >
> > > " xpath: An xpath selection filter is an XPath expression which
> > > references data nodes. When applied to a datastore, it is the
> > > results of this expression which will be pushed."
> > >
> > > > o  3.6
> > > >
> > > >      Selection filters are not intended to be used to filter object=
s
> > > >      based on a non-key property.  Supporting non-key property
> > > >      filtering so would have a number of implications that would
> > > >      result in significant complexity.
> > > >
> > > >      [...]
> > > >
> > > >      the goal is to
> > > >      provide equivalent capabilities to what is available with a GE=
T.
> > > >
> > > >   In GET you can filter on "non-key properties".
> > > >
> > > >   I think you should remove the text about "non-key properties".  I=
f
> > > >   anything, I think you can allow an implementation to reject a fil=
ter
> > > >   that would be too complex to implement / evaluate (in fact I thin=
k
> > > >   the text already allows a server to reject such filters.)
> > >
> > > The issue with non-key properties is how to deal with the creation
> > > and deletion of objects when a non-key property goes in/out of the
> > > selection.
> > > Others were uncomfortable with things like passing along a patch
> > > showing a node was deleted, when in reality the property simply
> > > changed from meeting the selection filter to failing the selection
> > > filter.  So people wanted to default to the simpler case of key
> > > properties for selection.
> > >
> > > Based on that I can delete the words "but the goal is to provide
> > > equivalent capabilities to what is available with a GET".
> > >
> > > >   With the current text, is this filter ok:
> > > >
> > > >      /interfaces/interface[contains(name, "eth")]
> > > >
> > > >   It filters on a key, so it should be ok, right?
> > >
> > > Yes
> > >
> > > > o  3.7
> > > >
> > > >   The XML examples are not using the correct XML namespace for the
> > > >   nodes from the "ietf-interface" module.
> > > >
> > > >   The YANG Patch example also shows an interesting effect in the
> > > >   "patch-id" and "edit-id" leafs.  I think the draft should mention
> > > >   how implementations are suppose to fill in these leafs.
> > >
> > > Will add how to populate.  In summary, sequential numbering of
> > > "edit-id"
> > > was from the RFC-8072.   And a null "patch-id" is because patch-id is
> > > mandatory in RFC-8072, and was originally supposed to be used for
> > > debugging of failed datastore write operations.  That really isn't
> > > the case here, plus we have subscription-id and other object
> > > available.
> > >
> > > >   The "target" leaf is not specified correctly.  It should be:
> > > >
> > > >          /ietf-interfaces:interfaces-state
> > >
> > > Good catch.  Making change.
> > >
> > > > o  3.8
> > > >
> > > >   The example has:
> > > >
> > > >     > > >        xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notific=
ations"
> > > >        xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">
> > > >       
> > > >          > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-datastores">
> > > >
> > > >   This doesn't match the YANG model; there is no container called
> > > >   "datastore" in the model.
> > > >
> > > >   Further is has:
> > > >
> > > >          > > >             xmlns:ex=3D"http://example.com/sample-data/1.0"
> > > >             select=3D"/ex:foo"/>
> > > >
> > > >   a subtree-filter of type xpath?  I think ot should be:
> > > >
> > > >         
> > > >            /ex:foo
> > > >         
> > >
> > > Yes
> > >
> > > >   Also, it has:
> > > >
> > > >         
> > > >           operational
> > > >         
> > > >
> > > >   which should be:
> > > >
> > > >          datastores">
> > > >           ds:operational
> > > >         
> > >
> > > At the last IETF, Kent pointed us to YANG Lint which should allow us
> > > to do example checking in ways not previously known to us.  I will
> > > install and attempt to use these to clear the example items you have
> > > listed.
> > >
> > > > o  3.9
> > > >
> > > >   This section lists three cases for which:
> > > >
> > > >      the error identity "data-unavailable" SHOULD be returned.
> > > >
> > > >   One of the cases is:
> > > >
> > > >     o  the authorization privileges of a receiver change over the c=
ourse
> > > >        of the subscription.
> > > >
> > > >   But how can a server know this when "establish-subscription" is s=
ent?
> > >
> > > It cannot know this at "establish-subscription".  So a publisher
> > > will have to track whether the permissions on subscribed objects
> > > change.  How is left to implementations.
> > >
> > > > o  3.9
> > > >
> > > >      The contextual authorization model for data in YANG datastores=
 is
> > > >      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
> > > >
> > > >   Did you mean s/contextual/conceptual/ ?
> > >
> > > Will make that change.
> > >
> > > > o  3.11.1
> > > >
> > > >
> > > >   OLD:
> > > >
> > > >        If
> > > >        this is not possible and the synch-on-start option is
> > > > configured,
> > > >
> > > >   NEW:
> > > >
> > > >        If
> > > >        this is not possible and the "no-synch-on-start" option is n=
ot
> > > >        present for the subscription.
> > > >
> > > >
> > > >   (fixes incorrect name of leaf, and also covers dynamic
> > > >   subscriptions)
> > >
> > > Yes, good catch.  Will fix.
> > >
> > > > o  4.3.2
> > > >
> > > >      A subscription-id MUST be transported along with the subscribe=
d
> > > >      contents.
> > > >
> > > >   Then the leaf "subscription-id" should be mandatory.
> > >
> > > The requirement is that a subscription-id must be in the
> > > notification message, this doesn't mean that the subscription-id
> > > must be within the two new notifications.  The reason for this is
> > > that when we add support for the notification-messages draft, but
> > > having the subscription-id optional in the push-update and
> > > push-change-update, we can enable implementations which do not
> > > duplicate this header item.  (And a duplication would be forced with
> > > the future header if we made this mandatory.)
> > >
> > > >      A "time-of-update" which represents the time an update record
> > > >      snapshot was generated.  A receiver MAY assume that a publishe=
r's
> > > >      objects have these pushed values at this point in time.
> > > >
> > > >   Should "time-of-update" be mandatory?
> > >
> > > Two reasons it is not:
> > > (a) Other vendors have worried they can only support message-time,
> > > rather than notification-time.
> > > (b) Notification-time is the generalized name for "time-of-update" .
> > > Having
> > > "time-of-update" as optional allows for eventual migration to common
> > > headers of draft-ietf-netconf-notification-messages without
> > > information duplication
> > >
> > > >   How is "time-of-update" different from "eventTime" in the
> > > >   notification?
> > >
> > > I think that answer is above.  But there is some good guidance here
> > > from draft-ietf-netconf-notification-messages.  The new draft
> > > ultimately will define and support the following times:
> > >
> > > message-time:
> > >       "Header information consisting of time the message headers
> > > were placed generated prior to being sent to transport";
> > >
> > > notification-time
> > >       "Header information consisting of the time an originating proce=
ss
> > >       created
> > > the notification."
> > >
> > > Notification-time should be equivalent to eventTime from RFC-5277.
> > > But
> > > some other vendors have said they really only have message-time, and
> > > this is what they are populating in eventTime even though it doesn't
> > > explicitly fit the definition.  With the new definitions, at least
> > > they should be able to populate what they explicitly have.
> > >
> > > > o  4.3.2
> > > >
> > > >      If the application detects an informational discontinuity
> > > >
> > > >   What is an "informational discontinuity"?
> > >
> > > Will change to:
> > >   If the application detects any incompleteness in set of objects pla=
ced
> > >   into a
> > > "push-update" or "push-change-update"
> > >
> > > > o  4.4.1 / 4.4.2
> > > >
> > > >   The XML examples are broken; compare with my comments for 3.8.
> > >
> > > Will do.  I am hoping a new attempt using yanglint helps pick out
> > > everything I missed by hand previously.
> > >
> > > > o  5
> > > >
> > > >   OLD:
> > > >
> > > >     "This module contains conceptual YANG specifications
> > > >      for YANG push.";
> > > >
> > > >   NEW:
> > > >
> > > >     "This module contains YANG specifications for YANG push.";
> > >
> > > ok
> > >
> > > > o  5 - identities
> > > >
> > > >     identity qos-unsupported {
> > > >       base sn:error;
> > > >       description
> > > >         "Subscription QoS parameters not supported on this platform=
.";
> > > >     }
> > > >
> > > >   This identity is not mentioned anywhere in the text.  Instead of
> > > >   having this identity, wouldn't it be better to define a feature f=
or
> > > >   "qos", and mark the nodes you have in mind with an if-feature?
> > >
> > > It is possible to expose QoS explicitly as a feature.  I will make
> > > that addition if you are ok with my other QoS comment described
> > > below about subscribed- notifications.
> > >
> > > But even in that case if QoS is not supported, and someone includes
> > > QoS objects in an "establish-subscription" we need this identity as
> > > an error.  This error allow an explicit identification of what was
> > > wrong in the RPC (such as a DSCP provided is not supported by the
> > > Publisher).  I will include this in the Identity description.
> > >
> > > >     identity on-change-unsupported {
> > > >       base sn:error;
> > > >       description
> > > >         "On-change not supported.";
> > > >     }
> > > >
> > > >   When will this identity be used?  There is already a feature
> > > >   "on-change" and corresponding if-feature statements.
> > >
> > > Per our discussion above, this can be used if an RPC asks for
> > > on-change for an object which is not available at a platform
> > > deployment (either marked in the schema, or a specific deployment
> > > doesn't support an object which is included).  I will enhance the
> > > description based on the discussion on this earlier in this thread.
> > >
> > > >     identity on-change-synch-unsupported {
> > > >       base sn:error;
> > > >       description
> > > >         "On-change synch-on-start and resynchonization not supporte=
d.";
> > > >     }
> > > >
> > > >   The leaf is called "no-sync-on-start", which implies that sync on
> > > >   start is the default.  So when will this identity be used?
> > >
> > > Can be used in two places:
> > >
> > > (1) Will be used if an RPC asks to synch on start, but it can't be
> > > supported for any reason (e.g., no nodes identifiable within the
> > > selection filter will ever be
> > > support on-change).   Will enhance the definition.
> > >
> > > (2) The resynch RPC is invoked on a periodic subscription-id, or on
> > > an
> > > on-
> > > change subscription which can't support synchronization.
> > >
> > > >     identity reference-mismatch {
> > > >      base sn:error;
> > > >       description
> > > >        "Mismatch in filter key and referenced yang subtree.";
> > > >     }
> > > >
> > > >   I don't understand the description of this identity.  Please
> > > >   clarify.
> > >
> > > Will clarify description to explain that the key provided with the
> > > filter does not match the data type of the referenced yang subtree
> > >
> > > >      identity datatree-size {
> > > >
> > > >   Should it be "result-too-big" or something?
> > >
> > > Yes.   I will change the name.
> > >
> > > >     identity no-such-datastore {
> > > >
> > > >   I think this one should be removed.  The normal "invalid-value"
> > > >   error-tag covers this error.
> > > >
> > > >
> > > >       identity custom-datastore {
> > > >         base ds:datastore;
> > > >         description
> > > >           "A datastore with boundaries not defined within
> > > >            draft-ietf-netmod-revised-datastores";
> > > >       }
> > > >
> > > >   This identity needs to be removed.  If someone defines a custom
> > > >   datastore, it would get a specific identity, and that identity ca=
n
> > > >   be used as "source".
> > >
> > > Yes, any new custom datastore will get a new identity, but if that
> > > new identity uses this custom-datastore one as a base, then we have
> > > an umbrella identity which is a handle just for the custom ones.
> > > That was the intent of this.  If you don't think that an identity
> > > which acts as a bundling mechanism is useful, we can remove.
> > >
> > > > o  5 - "change-type"
> > > >
> > > >   The descriptions of the enums need to be improved.  This is about
> > > >   reporting a change in a datastore.  The value "create" is describ=
ed
> > > >   as:
> > > >
> > > >         description
> > > >           "Create a new data resource if it does not already exist.=
  If
> > > >           it already exists, replace.";
> > > >
> > > >   Also, the description of the typedef has:
> > > >
> > > >       "RFC 8072 section 2.5, with a delta that it is ok to receive
> > > >       ability create on an existing node, or receive a delete on a
> > > >       missing node.";
> > > >
> > > >   But what does this mean?  The type is used to *exclude* some
> changes
> > > >   from a yang patch record.
> > >
> > > This is to identify churn within a datastore during a dampening
> > > period.  Two examples of when this is needed:
> > >
> > > (1) For security applications, it is an absolute requirement that
> > > you know if a
> > > node was added and then removed during a dampening period.   For an
> > > example, a hacker adds a "permit any any" which is then quickly
> > > removed before the dampening period ends.  Remote applications need
> > > to know that churn occurred.
> > >
> > > (2) For network management applications when a physical interface is
> > > going down and then quickly back up.  If the up/down is transient,
> > > how do you know that this occurred if there is no notification that
> > > churn occurred?
> > >
> > > To support this, the YANG patch definition is loosened to allow the
> > > new creation on an existing node (based on what resulted from the
> > > last patch), or a delete on a missing node.  This acts as an
> > > indication that some churn in the datastore happened even though the
> > > data is in the same state as a per the previous update.  And if an
> > > application get to sees this indication when comparing to the
> > > previous state, they have the option of looking more closely at some
> > > logs on the publisher to determine what actually happened.
> > >
> > > I can see that this behavior is under-described in the text.  I will
> > > put a small section between sections 3.10 & 3.11 describing this.
> > > The title will be "Identification of a transient change within
> > > dampening period"
> > >
> > > > o  5 - selection filter
> > > >
> > > >   The XPath expression is not properly defined.
> > > >
> > > >   OLD:
> > > >
> > > >           "This parameter contains an XPath expression identifying =
the
> > > >           portions of the target datastore to retrieve.";
> > > >
> > > >   NEW:
> > > >
> > > >           "This parameter contains an XPath expression identifying =
the
> > > >            portions of the target datastore to retrieve.
> > > >
> > > >            If the expression returns a node-set, all nodes in the
> > > >            node-set are selected by the filter.  Otherwise, if the
> > > >            expression does not return a node-set, the filter
> > > >            doesn't select any nodes.
> > > >
> > > >            FIXME: (*)
> > > >
> > > >            The expression is evaluated in the following XPath conte=
xt:
> > > >
> > > >              o  The set of namespace declarations are those in scop=
e on
> > > >                 the 'xpath-filter' leaf element.
> > > >
> > > >              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 79=
50.
> > > >
> > > >              o  The context node is the root node of the target
> > > >                 datastore.
> > > >
> > > >
> > > >   (*) - We need to describe when the filter is evaluated.  This is
> > > >   also true for the subtree filter.  Is it evaluated when the
> > > >   subscription is started and explicitly modified, or everytime a
> > > >   change is detected?
> > > >
> > > >   [Side note: this description is also missing from the "xpath-filt=
er"
> > > >   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
> > > >   updated the description in that draft.]
> > >
> > > I will update the descriptions to match your draft.
> > >
> > > As for when the evaluation occurs, I am not sure what you mean.
> > > Every time a change occurs, you need to see if the changed object
> > > would have fallen within the selection.  There is no attempt to
> > > support an
> > > event-condition-
> > > action context.
> > >
> > > > o  5 - terminology
> > > >
> > > >   The term "agent" is used a couple of times.  Use "publisher" or
> > > >   "server" instead.
> > >
> > > Will update
> > >
> > > > o  5 - dampening
> > > >
> > > >           leaf dampening-period {
> > > >             type yang:timeticks;
> > > >             mandatory true;
> > > >
> > > >    Should this instead be:
> > > >
> > > >           leaf dampening-period {
> > > >             type yang:timeticks;
> > > >             default "0";
> > > >
> > > >    So that the request is the same if the "on-change" feature is
> > > >    support or not.
> > >
> > > I like it, will update.
> > >
> > > > o  5 - no-synch-on-start
> > > >
> > > >              When
> > > >              present, pushing a full selection per the terms of the
> > > >              selection filter MAY NOT be done for this subscription=
.
> > > >
> > > >    Did you mean s/MAY NOT/MUST NOT/ ?
> > > >
> > > >    MAY NOT is not a 2119 term.
> > >
> > > Will change to MUST NOT.
> > >
> > > > o  5 - QoS
> > > >
> > > >   Why are the qos parameters defined in yang push, and not in
> > > >   subscribed notifications?  It seems that they are generic.
> > >
> > > This question has come up before.  Basically current 5277 event
> > > streams
> > > haven't shown need for QoS to date.   We know that QoS has been
> > > requested to handle congestion issues for YANG push.  So for
> > > simplicities sake, we bundled all QoS elements together in YANG push
> > > where we knew there was demonstrable need.  If someone really is
> > > asking for these QoS constructs for events, we can revisit.
> > >
> > > > o  5 - establish-subscription params
> > > >
> > > >   I think a "when" expression should be added to the first augment:
> > > >
> > > >     augment "/sn:establish-subscription/sn:input" {
> > > >       when "sn:target/yp:datastore/yp:source";
> > >
> > > So this is saying that the named datastore must exist before
> > > allowing the
> > > augment.   Works for me.
> > >
> > > > o  5 - push-update
> > > >
> > > >   What does the presence of "updates-not-sent" mean in "push-
> update"?
> > > >   "push-update" contains a snapshot, not a diff, so why is
> > > >   "updates-not-sent" present?
> > >
> > > This is to indicate a system error where not all objects can be
> > > extracted from the datastore.  (e.g., the routing table got *lots*
> > > bigger, and the periodic extract cannot be performed as expected.)
> > > At least some implementations
> > > have seen this.   I will add some clarifying text.
> > >
> > > > o  5 - push-change-update
> > > >
> > > >         "This contains an incremental set of datastore changes need=
ed
> > > >          to update a remote datastore starting at the time of the
> > > >          previous update, per the terms of the subscription.
> > > >
> > > >    What is an "incremental set"?  Probably s/incremental set/set/
> > >
> > > I can change to "set".
> > >
> > > > o  General
> > > >
> > > >   Use double quotes for node names.  "push-update", "subscription-i=
d"
> > > >   etc.  Quotes are currently used inconsistently, and it makes the
> > > >   text harder to read.
> > >
> > > Will make the fix.
> > >
> > > Thanks again for all the excellent thoughts!
> > > Eric
> > >
> > > >
> > > > /martin
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> >


From nobody Thu Nov 30 13:48:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A190127871 for ; Thu, 30 Nov 2017 13:48:05 -0800 (PST)
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 AtgVJfKNFyd7 for ; Thu, 30 Nov 2017 13:48:01 -0800 (PST)
Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86DC1205D3 for ; Thu, 30 Nov 2017 13:47:59 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2HaAQBp299Z/xoBYJleGgEBAQECAQEBAQgBAQEBg11kA2snB4Nzih+PMoFLK5YvDoIEChgLhElPAoQ/PxgBAgEBAQEBAQEDaCiCakYsAQEBAQEBTwI+LAEBAQQBASEPAQU2GwkCEQQBAQECAgkIEgMCAicfAQgIBg0GAgEBF4oCAQQMjXudZ4InizwBAQEBAQEEAQEBAQEBAQEbBYEOgh+CB4FRgWorgn+EQB8PAVWCVIJhBYdHmX2BCIEmiElJg2GHXYV0g1UFhy6KIYsdAgQGBQIZAYE5HzmBDlMmXYUaHIFodYkUgTIBgRABAQE
X-IPAS-Result: A2HaAQBp299Z/xoBYJleGgEBAQECAQEBAQgBAQEBg11kA2snB4Nzih+PMoFLK5YvDoIEChgLhElPAoQ/PxgBAgEBAQEBAQEDaCiCakYsAQEBAQEBTwI+LAEBAQQBASEPAQU2GwkCEQQBAQECAgkIEgMCAicfAQgIBg0GAgEBF4oCAQQMjXudZ4InizwBAQEBAQEEAQEBAQEBAQEbBYEOgh+CB4FRgWorgn+EQB8PAVWCVIJhBYdHmX2BCIEmiElJg2GHXYV0g1UFhy6KIYsdAgQGBQIZAYE5HzmBDlMmXYUaHIFodYkUgTIBgRABAQE
X-IronPort-AV: E=Sophos;i="5.43,368,1503352800";  d="scan'208";a="1638977"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Nov 2017 22:47:58 +0100
X-IronPort-AV: E=Sophos;i="5.45,343,1508796000"; d="scan'208";a="271985784"
X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 22:47:56 +0100
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id vAULlsgQ010889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 30 Nov 2017 22:47:55 +0100
Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 30 Nov 2017 22:47:49 +0100
To: 
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com>
From: Henk Birkholz 
Message-ID: <782c1aad-1e85-fe11-4c9f-47a2d1fd9304@sit.fraunhofer.de>
Date: Thu, 30 Nov 2017 22:47:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.43.163]
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:48:05 -0000

Hi all,

Admittedly, I am relatively new to this domain and before I provide my 
comment I want to acknowledge that:

- it is important not to off-load to much complexity to the agents that 
are part of the data store
- complex composite devices might create a lot of "noise" in wrt changes 
of data node values and that has to be dealt with in a sane and 
reasonable way

That said, YANG Push caught a lot of attention outside of NETCONF. In a 
nutshell, it is a solution that provides meaningful telemetry, which 
simplifies post-processing of subscribed notifications significantly.

But - there is always a but, I guess - "visibility" is a key capability 
in this context, I think. Yes, there might be oscillating values, yes, 
they might be of no value to most post-processing processes, but to 
exclude them entirely might reduce the usefulness of the on-change 
capability significantly.

There is the complementary topic of smart filters that might deal with 
providing metadata about this "omitted notifications" (coming back to 
the oscillating values example, Alex illustrated), but visibility of 
ongoing changes should be supported somehow, I think. Maybe not in the 
top level draft that is netconf-yang-push, but at some level, I hope.

Again, this is coming from a fresh pair of eyes still relatively 
unfamiliar with the emerging ecosystem around YANG Push.

In a nutshell, I just want to highlight that visibility of past changes 
and dealing with high frequency of changes of course requires a feasible 
compromise. But from my POV, "the most recent update" might not cut it. 
I only want to highlight that fine granular visibility is a vital 
characteristic of on-change emission of notifications. Maybe there can 
be a knob, as Sue might phrase it.

If this is already addressed by another draft, I apologize for my wall 
of text. If not, please take this POV into account :)

Viele Grüße,

Henk

On 11/30/2017 01:59 AM, Alexander Clemm wrote:
> This works for me.  Perhaps one additional item we might add (for 
> crystal-clear clarification) is that when the notification message is 
> sent, it contains the most recent update for that object (i.e. the value 
> that is in effect when the update is sent).  If there are some quickly 
> oscillating values we don’t send the whole sequence of updates/values.
> 
> --- Alex
> 
> *From:*Eric Voit (evoit) [mailto:evoit@cisco.com]
> *Sent:* Wednesday, November 29, 2017 4:51 PM
> *To:* Alexander Clemm ; Andy Bierman 
> ; Martin Bjorklund ; kwatsen@juniper.net
> *Cc:* Netconf 
> *Subject:* RE: [Netconf] review of draft-ietf-netconf-yang-push-11
> 
> The Section 3.1 text I proposed in my response to Martin on the 
> dampening question:
> 
> Dampening period: In an on-change subscription, detected object changes 
> should be sent as quickly as possible.  However without adequate 
> protections, a rapid series of object changes might exhaust of resources 
> in the publisher or receiver. In order to protect against that, a 
> dampening period MAY be used to specify the interval which must pass 
> before successive update records for the same subscription are generated 
> for a receiver.  The dampening period collectively applies to the set of 
> all data nodes selected by a single subscription and sent to a single 
> receiver.  This means that when there is a change to a subscribed 
> object, an update record containing that object is created either 
> immediately when no dampening period is in effect, or at the end of a 
> dampening period.  A dampening period is reset every time a new 
> notification message is passed to transport.
> 
> With the YANG description of:
> 
> "Specifies the interval which must pass before successive update records 
> for the same subscription are generated for a receiver.  The dampening 
> period collectively applies to the set of all data nodes selected by a 
> single subscription and sent to a single receiver.  This means that when 
> there is a change to a subscribed object, an update record containing 
> that object is created either immediately when no dampening period is in 
> effect, or at the end of a dampening period.  A dampening period is 
> reset every time a new notification message is passed to transport.  A 
> dampening period is reset every time a new notification message is 
> passed to transport.  A zero value indicates no dampening period, and 
> all subscribed object changes are sent immediately."
> 
> Does this work for everyone?
> 
> 
> Eric
> 
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of 
> *Alexander Clemm
> *Sent:* Wednesday, November 29, 2017 3:17 PM
> *To:* Andy Bierman >; 
> Martin Bjorklund >
> *Cc:* Netconf >
> *Subject:* Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> 
> I thought we decided that we have combined dampening for all objects in 
> the subscription.  In this case, we would send updates at 2, 12 
> (containing 3,4,11), and 22 (containing 13, 14, 15).
> 
> If the scope of the subscription becomes sufficiently large, this almost 
> reverts back to a periodic subscription (since there is always going to 
> be a change somewhere). This is why I originally argued to have it 
> indeed on a per-object basis, but I lost that argument.  For such 
> fine-grained updates, where a client is indeed interest in getting 
> delays of individual objects without delay,  a client could simply need 
> to establish multiple “micro” subscriptions.
> 
> TCAs in RMON are something different altogether.  This is something we 
> are trying to address with smart filters.
> 
> --- Alex
> 
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, November 29, 2017 10:18 AM
> *To:* Martin Bjorklund >
> *Cc:* Netconf >
> *Subject:* Re: [Netconf] review of draft-ietf-netconf-yang-push-11
> 
> On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund  > wrote:
> 
>     Hi,
> 
>     ....
> 
>     o  3.1
> 
>        I'm not sure I understand the dampening period concept.  Let's
>        assume that the dampening period is 10s.  Then changes happen at
>        times:
> 
>          2  3  4  11  13  14  15
> 
>        From the description, it seems I would receive 4 notifications, from
>        times:
> 
>          2  (containing only change from 2)
>          12 (containing change from 3,4,11)
>          13 (containing only change from 13)
>          23 (containing changes from 14,15)
> 
>        Is this correct?
> 
>        In any case, I suggest the description in the YANG module is
>        clarified - currently the RFC text contains more details than the
>        YANG module.
> 
> Seems to me (from a client POV) that I want the dampening to apply
> 
> to the entire subscription, not to each node within the subscription.
> 
> I want "at most, 1 notification per second".  I don't see why I would want
> 
> to be told about an individual data node once per second.  I could still
> 
> get 10,000 events/sec but for different data nodes.  The receiver does not
> 
> really care whet nodes are being reported in each notification. The goal
> 
> is to simply limit the network and processor load.
> 
>  From a server POV, I do not want a timer on every data node instance
> 
> and complex code to construct the next on-change notification.
> 
> RMON handles dampening very differently.
> 
> The rising and falling thresholds are used to arm and re-arm an event 
> trigger.
> 
> The time between changes is not used at all to determine how many events 
> to send.
> 
> (Not suggesting all yang-push use-cases are threshold-based.)
> 
> IMO, the operator should put events that require low-latency into a 
> separate subscription,
> 
> and the dampening period should apply to the entire subscription.
> 
>   ...
> 
> 
> 
> /martin
> 
> Andy
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Thu Nov 30 14:16:49 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28684126CF9 for ; Thu, 30 Nov 2017 14:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha8cjqD2o64M for ; Thu, 30 Nov 2017 14:16:46 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09136120227 for ; Thu, 30 Nov 2017 14:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13708; q=dns/txt; s=iport; t=1512080206; x=1513289806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+q7z1pmpKYWNzRdXjepHpNcuPOxKNFu0FuExEko1Atk=; b=YF/qtzdJwpBGcBgqfkipsmODaAPF2fDjgqWO6r/PTMEv2rh3nORr8N/v /ukY1TNoa0BhdxJkCPpf/5Ix50n5gkeMQ55Hgp0+gAp4u6qBCWHwwfzrN AQEweDQpkzlHdFiJsHNUi3TSVvhkP7EWnKfG2BdUTBddsd8eKBtkweXGF g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AAASgiBa/5RdJa1QChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuJweDeIogjnOBfZZ2EIIBChgLhElPAhqFBz8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHwEBAQMBAQEhEToLBQsCAQYCEQQBAQECAgkIEgMCAgIlCxQBCAgCB?= =?us-ascii?q?A4FCBOJfwgQiCOdbIInimUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgjKCCYF?= =?us-ascii?q?WgWmDK4RbGgUPAS0oglaCYwWHaJpzAosSS4NohUGCH4YPiy6KOYtfAhEZAYE5A?= =?us-ascii?q?R85gVFvFTqCKYJSHIFneIc9ASYEgQiBFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,343,1508803200"; d="scan'208";a="38652653"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 22:16:44 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAUMGiiN005543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 22:16:44 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 17:16:43 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Thu, 30 Nov 2017 17:16:43 -0500
From: "Eric Voit (evoit)" 
To: Henk Birkholz 
CC: "netconf@ietf.org" 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzLQRPr9GM9Jka7UxKyCaa4a6MsMpiA//+ZgDCAAEyf8IAAV64AgAFczAD//6+3cA==
Date: Thu, 30 Nov 2017 22:16:43 +0000
Message-ID: 
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com> <782c1aad-1e85-fe11-4c9f-47a2d1fd9304@sit.fraunhofer.de>
In-Reply-To: <782c1aad-1e85-fe11-4c9f-47a2d1fd9304@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 22:16:48 -0000

SGkgSGVuaywNCg0KWUFORyBQdXNoIGRvZXMgaWRlbnRpZnkgdGhhdCBjaHVybiBoYXMgb2NjdXJy
ZWQsIGJ1dCBub3QgaG93IG11Y2ggY2h1cm4gaGFzIG9jY3VycmVkIGR1cmluZyBhIGRhbXBlbmlu
ZyBwZXJpb2QuICAgVGhpcyBhbGxvd3MgdGhpbmdzIGxpa2Ugc2VjdXJpdHkgYXBwbGljYXRpb25z
IHRvIGtub3cgdGhpbmdzIGxpa2UgdGVtcG9yYXJ5IEFDTCBjaGFuZ2VzLiAgT3IgdGhpbmdzIGxp
a2UgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbXMga25vd2luZyB0aGF0IHRoZXJlIGFyZSB0cmFu
c2llbnQgb3V0YWdlcyBvbiBhbiBpbnRlcmZhY2UuDQoNCkF0IHRoaXMgcG9pbnQsIHRoZSB0aGlu
a2luZyBpcyB0aGF0IGFuIGFwcGxpY2F0aW9uIGFsd2F5cyBoYXMgdGhlIG9wdGlvbiBvZiBnb2lu
ZyB0byBQdWJsaXNoZXIgdG8gZ2V0IHRoZSBkZXRhaWxzIG9mIHRoZSBjaHVybi4gICBQZXJoYXBz
IG5ldyBkcmFmdHMgY291bGQgYWxzbyBwdXNoIHRoZSBxdWFudGl0eSBvZiBjaGFuZ2VzIHdoaWNo
IG9jY3VycmVkLCBvciBhIGhpc3RvZ3JhbSBvciBjaGFuZ2VzLCBvciBzb21lIG90aGVyIG1ldHJp
Yy4gIEF0IHRoaXMgcG9pbnQgdGhhdCB0b3BpYyBpcyB1bmV4cGxvcmVkLiAgQnV0IHRoZXJlIGlz
IG5vIHJlYXNvbiB0aGF0IHN1Y2ggaW5mb3JtYXRpb24gY291bGRuJ3QgYmUgYXVnbWVudGVkIGlu
dG8gc29tZSBoZWFkZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBwdXNoLWNoYW5nZS11cGRhdGUgcmVj
b3JkLg0KDQpFcmljDQoNCj4gRnJvbTogSGVuayBCaXJraG9seiwgTm92ZW1iZXIgMzAsIDIwMTcg
NDo0OCBQTQ0KPiANCj4gSGkgYWxsLA0KPiANCj4gQWRtaXR0ZWRseSwgSSBhbSByZWxhdGl2ZWx5
IG5ldyB0byB0aGlzIGRvbWFpbiBhbmQgYmVmb3JlIEkgcHJvdmlkZSBteQ0KPiBjb21tZW50IEkg
d2FudCB0byBhY2tub3dsZWRnZSB0aGF0Og0KPiANCj4gLSBpdCBpcyBpbXBvcnRhbnQgbm90IHRv
IG9mZi1sb2FkIHRvIG11Y2ggY29tcGxleGl0eSB0byB0aGUgYWdlbnRzIHRoYXQgYXJlDQo+IHBh
cnQgb2YgdGhlIGRhdGEgc3RvcmUNCj4gLSBjb21wbGV4IGNvbXBvc2l0ZSBkZXZpY2VzIG1pZ2h0
IGNyZWF0ZSBhIGxvdCBvZiAibm9pc2UiIGluIHdydCBjaGFuZ2VzIG9mDQo+IGRhdGEgbm9kZSB2
YWx1ZXMgYW5kIHRoYXQgaGFzIHRvIGJlIGRlYWx0IHdpdGggaW4gYSBzYW5lIGFuZCByZWFzb25h
YmxlDQo+IHdheQ0KPiANCj4gVGhhdCBzYWlkLCBZQU5HIFB1c2ggY2F1Z2h0IGEgbG90IG9mIGF0
dGVudGlvbiBvdXRzaWRlIG9mIE5FVENPTkYuIEluIGENCj4gbnV0c2hlbGwsIGl0IGlzIGEgc29s
dXRpb24gdGhhdCBwcm92aWRlcyBtZWFuaW5nZnVsIHRlbGVtZXRyeSwgd2hpY2gNCj4gc2ltcGxp
ZmllcyBwb3N0LXByb2Nlc3Npbmcgb2Ygc3Vic2NyaWJlZCBub3RpZmljYXRpb25zIHNpZ25pZmlj
YW50bHkuDQo+IA0KPiBCdXQgLSB0aGVyZSBpcyBhbHdheXMgYSBidXQsIEkgZ3Vlc3MgLSAidmlz
aWJpbGl0eSIgaXMgYSBrZXkgY2FwYWJpbGl0eSBpbiB0aGlzDQo+IGNvbnRleHQsIEkgdGhpbmsu
IFllcywgdGhlcmUgbWlnaHQgYmUgb3NjaWxsYXRpbmcgdmFsdWVzLCB5ZXMsIHRoZXkgbWlnaHQg
YmUgb2YNCj4gbm8gdmFsdWUgdG8gbW9zdCBwb3N0LXByb2Nlc3NpbmcgcHJvY2Vzc2VzLCBidXQg
dG8gZXhjbHVkZSB0aGVtIGVudGlyZWx5DQo+IG1pZ2h0IHJlZHVjZSB0aGUgdXNlZnVsbmVzcyBv
ZiB0aGUgb24tY2hhbmdlIGNhcGFiaWxpdHkgc2lnbmlmaWNhbnRseS4NCj4gDQo+IFRoZXJlIGlz
IHRoZSBjb21wbGVtZW50YXJ5IHRvcGljIG9mIHNtYXJ0IGZpbHRlcnMgdGhhdCBtaWdodCBkZWFs
IHdpdGgNCj4gcHJvdmlkaW5nIG1ldGFkYXRhIGFib3V0IHRoaXMgIm9taXR0ZWQgbm90aWZpY2F0
aW9ucyIgKGNvbWluZyBiYWNrIHRvIHRoZQ0KPiBvc2NpbGxhdGluZyB2YWx1ZXMgZXhhbXBsZSwg
QWxleCBpbGx1c3RyYXRlZCksIGJ1dCB2aXNpYmlsaXR5IG9mIG9uZ29pbmcgY2hhbmdlcw0KPiBz
aG91bGQgYmUgc3VwcG9ydGVkIHNvbWVob3csIEkgdGhpbmsuIE1heWJlIG5vdCBpbiB0aGUgdG9w
IGxldmVsIGRyYWZ0DQo+IHRoYXQgaXMgbmV0Y29uZi15YW5nLXB1c2gsIGJ1dCBhdCBzb21lIGxl
dmVsLCBJIGhvcGUuDQo+IA0KPiBBZ2FpbiwgdGhpcyBpcyBjb21pbmcgZnJvbSBhIGZyZXNoIHBh
aXIgb2YgZXllcyBzdGlsbCByZWxhdGl2ZWx5IHVuZmFtaWxpYXIgd2l0aA0KPiB0aGUgZW1lcmdp
bmcgZWNvc3lzdGVtIGFyb3VuZCBZQU5HIFB1c2guDQo+IA0KPiBJbiBhIG51dHNoZWxsLCBJIGp1
c3Qgd2FudCB0byBoaWdobGlnaHQgdGhhdCB2aXNpYmlsaXR5IG9mIHBhc3QgY2hhbmdlcyBhbmQN
Cj4gZGVhbGluZyB3aXRoIGhpZ2ggZnJlcXVlbmN5IG9mIGNoYW5nZXMgb2YgY291cnNlIHJlcXVp
cmVzIGEgZmVhc2libGUNCj4gY29tcHJvbWlzZS4gQnV0IGZyb20gbXkgUE9WLCAidGhlIG1vc3Qg
cmVjZW50IHVwZGF0ZSIgbWlnaHQgbm90IGN1dCBpdC4NCj4gSSBvbmx5IHdhbnQgdG8gaGlnaGxp
Z2h0IHRoYXQgZmluZSBncmFudWxhciB2aXNpYmlsaXR5IGlzIGEgdml0YWwgY2hhcmFjdGVyaXN0
aWMgb2YNCj4gb24tY2hhbmdlIGVtaXNzaW9uIG9mIG5vdGlmaWNhdGlvbnMuIE1heWJlIHRoZXJl
IGNhbiBiZSBhIGtub2IsIGFzIFN1ZQ0KPiBtaWdodCBwaHJhc2UgaXQuDQo+IA0KPiBJZiB0aGlz
IGlzIGFscmVhZHkgYWRkcmVzc2VkIGJ5IGFub3RoZXIgZHJhZnQsIEkgYXBvbG9naXplIGZvciBt
eSB3YWxsIG9mIHRleHQuDQo+IElmIG5vdCwgcGxlYXNlIHRha2UgdGhpcyBQT1YgaW50byBhY2Nv
dW50IDopDQo+IA0KPiBWaWVsZSBHcsO8w59lLA0KPiANCj4gSGVuaw0KPiANCj4gT24gMTEvMzAv
MjAxNyAwMTo1OSBBTSwgQWxleGFuZGVyIENsZW1tIHdyb3RlOg0KPiA+IFRoaXMgd29ya3MgZm9y
IG1lLsKgIFBlcmhhcHMgb25lIGFkZGl0aW9uYWwgaXRlbSB3ZSBtaWdodCBhZGQgKGZvcg0KPiA+
IGNyeXN0YWwtY2xlYXIgY2xhcmlmaWNhdGlvbikgaXMgdGhhdCB3aGVuIHRoZSBub3RpZmljYXRp
b24gbWVzc2FnZSBpcw0KPiA+IHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBtb3N0IHJlY2VudCB1cGRh
dGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZQ0KPiA+IHZhbHVlIHRoYXQgaXMgaW4gZWZmZWN0
IHdoZW4gdGhlIHVwZGF0ZSBpcyBzZW50KS7CoCBJZiB0aGVyZSBhcmUgc29tZQ0KPiA+IHF1aWNr
bHkgb3NjaWxsYXRpbmcgdmFsdWVzIHdlIGRvbuKAmXQgc2VuZCB0aGUgd2hvbGUgc2VxdWVuY2Ug
b2YNCj4gdXBkYXRlcy92YWx1ZXMuDQo+ID4NCj4gPiAtLS0gQWxleA0KPiA+DQo+ID4gKkZyb206
KkVyaWMgVm9pdCAoZXZvaXQpIFttYWlsdG86ZXZvaXRAY2lzY28uY29tXQ0KPiA+ICpTZW50Oiog
V2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyA0OjUxIFBNDQo+ID4gKlRvOiogQWxleGFuZGVy
IENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47IEFuZHkgQmllcm1hbg0KPiA+IDxh
bmR5QHl1bWF3b3Jrcy5jb20+OyBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47DQo+
ID4ga3dhdHNlbkBqdW5pcGVyLm5ldA0KPiA+ICpDYzoqIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5v
cmc+DQo+ID4gKlN1YmplY3Q6KiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5l
dGNvbmYteWFuZy1wdXNoLTExDQo+ID4NCj4gPiBUaGUgU2VjdGlvbiAzLjEgdGV4dCBJIHByb3Bv
c2VkIGluIG15IHJlc3BvbnNlIHRvIE1hcnRpbiBvbiB0aGUNCj4gPiBkYW1wZW5pbmcgcXVlc3Rp
b246DQo+ID4NCj4gPiBEYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2NyaXB0
aW9uLCBkZXRlY3RlZCBvYmplY3QNCj4gPiBjaGFuZ2VzIHNob3VsZCBiZSBzZW50IGFzIHF1aWNr
bHkgYXMgcG9zc2libGUuwqAgSG93ZXZlciB3aXRob3V0DQo+ID4gYWRlcXVhdGUgcHJvdGVjdGlv
bnMsIGEgcmFwaWQgc2VyaWVzIG9mIG9iamVjdCBjaGFuZ2VzIG1pZ2h0IGV4aGF1c3QNCj4gPiBv
ZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4gSW4gb3JkZXIgdG8gcHJv
dGVjdCBhZ2FpbnN0DQo+ID4gdGhhdCwgYSBkYW1wZW5pbmcgcGVyaW9kIE1BWSBiZSB1c2VkIHRv
IHNwZWNpZnkgdGhlIGludGVydmFsIHdoaWNoDQo+ID4gbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNz
aXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb24NCj4gPiBhcmUgZ2Vu
ZXJhdGVkIGZvciBhIHJlY2VpdmVyLsKgIFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVs
eQ0KPiA+IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxlY3RlZCBieSBh
IHNpbmdsZSBzdWJzY3JpcHRpb24NCj4gPiBhbmQgc2VudCB0byBhIHNpbmdsZSByZWNlaXZlci7C
oCBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZQ0KPiA+IHRvIGEgc3Vic2Ny
aWJlZCBvYmplY3QsIGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcw0K
PiA+IGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBp
cyBpbiBlZmZlY3QsIG9yDQo+ID4gYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuwqAg
QSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5DQo+ID4gdGltZSBhIG5ldyBub3RpZmlj
YXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0Lg0KPiA+DQo+ID4gV2l0aCB0aGUg
WUFORyBkZXNjcmlwdGlvbiBvZjoNCj4gPg0KPiA+ICJTcGVjaWZpZXMgdGhlIGludGVydmFsIHdo
aWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vzc2l2ZSB1cGRhdGUNCj4gPiByZWNvcmRzIGZvciB0
aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci7CoCBUaGUN
Cj4gPiBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2Yg
YWxsIGRhdGEgbm9kZXMNCj4gPiBzZWxlY3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gYW5k
IHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuwqAgVGhpcw0KPiA+IG1lYW5zIHRoYXQgd2hlbiB0
aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1cGRhdGUNCj4gPiBy
ZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcyBjcmVhdGVkIGVpdGhlciBpbW1lZGlhdGVs
eSB3aGVuIG5vDQo+ID4gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBl
bmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLsKgIEENCj4gPiBkYW1wZW5pbmcgcGVyaW9kIGlzIHJl
c2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMNCj4gPiBwYXNzZWQg
dG8gdHJhbnNwb3J0LsKgIEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEg
bmV3DQo+ID4gbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC7CoCBB
IHplcm8gdmFsdWUgaW5kaWNhdGVzDQo+ID4gbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBz
dWJzY3JpYmVkIG9iamVjdCBjaGFuZ2VzIGFyZSBzZW50DQo+IGltbWVkaWF0ZWx5LiINCj4gPg0K
PiA+IERvZXMgdGhpcyB3b3JrIGZvciBldmVyeW9uZT8NCj4gPg0KPiA+DQo+ID4gRXJpYw0KPiA+
DQo+ID4gKkZyb206Kk5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddICpP
biBCZWhhbGYgT2YNCj4gPiAqQWxleGFuZGVyIENsZW1tDQo+ID4gKlNlbnQ6KiBXZWRuZXNkYXks
IE5vdmVtYmVyIDI5LCAyMDE3IDM6MTcgUE0NCj4gPiAqVG86KiBBbmR5IEJpZXJtYW4gPGFuZHlA
eXVtYXdvcmtzLmNvbQ0KPiA8bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+Ow0KPiA+IE1hcnRp
biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tIDxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pg0KPiA+
ICpDYzoqIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmcgPG1haWx0bzpuZXRjb25mQGlldGYub3Jn
Pj4NCj4gPiAqU3ViamVjdDoqIFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0
Y29uZi15YW5nLXB1c2gtMTENCj4gPg0KPiA+IEkgdGhvdWdodCB3ZSBkZWNpZGVkIHRoYXQgd2Ug
aGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmplY3RzDQo+ID4gaW4gdGhlIHN1YnNj
cmlwdGlvbi7CoCBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIHNlbmQgdXBkYXRlcyBhdCAyLCAxMg0K
PiA+IChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAoY29udGFpbmluZyAxMywgMTQsIDE1KS4N
Cj4gPg0KPiA+IElmIHRoZSBzY29wZSBvZiB0aGUgc3Vic2NyaXB0aW9uIGJlY29tZXMgc3VmZmlj
aWVudGx5IGxhcmdlLCB0aGlzDQo+ID4gYWxtb3N0IHJldmVydHMgYmFjayB0byBhIHBlcmlvZGlj
IHN1YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlzDQo+ID4gZ29pbmcgdG8gYmUgYSBj
aGFuZ2Ugc29tZXdoZXJlKS4gVGhpcyBpcyB3aHkgSSBvcmlnaW5hbGx5IGFyZ3VlZCB0bw0KPiA+
IGhhdmUgaXQgaW5kZWVkIG9uIGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFy
Z3VtZW50LsKgIEZvcg0KPiA+IHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJlIGEgY2xp
ZW50IGlzIGluZGVlZCBpbnRlcmVzdCBpbg0KPiA+IGdldHRpbmcgZGVsYXlzIG9mIGluZGl2aWR1
YWwgb2JqZWN0cyB3aXRob3V0IGRlbGF5LCDCoGEgY2xpZW50IGNvdWxkDQo+ID4gc2ltcGx5IG5l
ZWQgdG8gZXN0YWJsaXNoIG11bHRpcGxlIOKAnG1pY3Jv4oCdIHN1YnNjcmlwdGlvbnMuDQo+ID4N
Cj4gPiBUQ0FzIGluIFJNT04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci7CoCBU
aGlzIGlzIHNvbWV0aGluZyB3ZQ0KPiA+IGFyZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0
IGZpbHRlcnMuDQo+ID4NCj4gPiAtLS0gQWxleA0KPiA+DQo+ID4gKkZyb206Kk5ldGNvbmYgW21h
aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkFuZHkNCj4gPiBC
aWVybWFuDQo+ID4gKlNlbnQ6KiBXZWRuZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDEwOjE4IEFN
DQo+ID4gKlRvOiogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20gPG1haWx0bzptYmpA
dGFpbC1mLmNvbT4+DQo+ID4gKkNjOiogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZyA8bWFpbHRv
Om5ldGNvbmZAaWV0Zi5vcmc+Pg0KPiA+ICpTdWJqZWN0OiogUmU6IFtOZXRjb25mXSByZXZpZXcg
b2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KPiA+DQo+ID4gT24gVHVlLCBOb3Yg
MjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20NCj4g
PiA8bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgSGksDQo+ID4N
Cj4gPiAgICAgLi4uLg0KPiA+DQo+ID4gICAgIG/CoCAzLjENCj4gPg0KPiA+ICAgICAgwqAgSSdt
IG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBjb25jZXB0LsKgIExl
dCdzDQo+ID4gICAgICDCoCBhc3N1bWUgdGhhdCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyAxMHMu
wqAgVGhlbiBjaGFuZ2VzIGhhcHBlbiBhdA0KPiA+ICAgICAgwqAgdGltZXM6DQo+ID4NCj4gPiAg
ICAgIMKgIMKgIDLCoCAzwqAgNMKgIDExwqAgMTPCoCAxNMKgIDE1DQo+ID4NCj4gPiAgICAgIMKg
IEZyb20gdGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmlj
YXRpb25zLCBmcm9tDQo+ID4gICAgICDCoCB0aW1lczoNCj4gPg0KPiA+ICAgICAgwqAgwqAgMsKg
IChjb250YWluaW5nIG9ubHkgY2hhbmdlIGZyb20gMikNCj4gPiAgICAgIMKgIMKgIDEyIChjb250
YWluaW5nIGNoYW5nZSBmcm9tIDMsNCwxMSkNCj4gPiAgICAgIMKgIMKgIDEzIChjb250YWluaW5n
IG9ubHkgY2hhbmdlIGZyb20gMTMpDQo+ID4gICAgICDCoCDCoCAyMyAoY29udGFpbmluZyBjaGFu
Z2VzIGZyb20gMTQsMTUpDQo+ID4NCj4gPiAgICAgIMKgIElzIHRoaXMgY29ycmVjdD8NCj4gPg0K
PiA+ICAgICAgwqAgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUgZGVzY3JpcHRpb24gaW4gdGhl
IFlBTkcgbW9kdWxlIGlzDQo+ID4gICAgICDCoCBjbGFyaWZpZWQgLSBjdXJyZW50bHkgdGhlIFJG
QyB0ZXh0IGNvbnRhaW5zIG1vcmUgZGV0YWlscyB0aGFuIHRoZQ0KPiA+ICAgICAgwqAgWUFORyBt
b2R1bGUuDQo+ID4NCj4gPiBTZWVtcyB0byBtZSAoZnJvbSBhIGNsaWVudCBQT1YpIHRoYXQgSSB3
YW50IHRoZSBkYW1wZW5pbmcgdG8gYXBwbHkNCj4gPg0KPiA+IHRvIHRoZSBlbnRpcmUgc3Vic2Ny
aXB0aW9uLCBub3QgdG8gZWFjaCBub2RlIHdpdGhpbiB0aGUgc3Vic2NyaXB0aW9uLg0KPiA+DQo+
ID4gSSB3YW50ICJhdCBtb3N0LCAxIG5vdGlmaWNhdGlvbiBwZXIgc2Vjb25kIi7CoCBJIGRvbid0
IHNlZSB3aHkgSSB3b3VsZA0KPiA+IHdhbnQNCj4gPg0KPiA+IHRvIGJlIHRvbGQgYWJvdXQgYW4g
aW5kaXZpZHVhbCBkYXRhIG5vZGUgb25jZSBwZXIgc2Vjb25kLsKgIEkgY291bGQNCj4gPiBzdGls
bA0KPiA+DQo+ID4gZ2V0IDEwLDAwMCBldmVudHMvc2VjIGJ1dCBmb3IgZGlmZmVyZW50IGRhdGEg
bm9kZXMuwqAgVGhlIHJlY2VpdmVyIGRvZXMNCj4gPiBub3QNCj4gPg0KPiA+IHJlYWxseSBjYXJl
IHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJlcG9ydGVkIGluIGVhY2ggbm90aWZpY2F0aW9uLiBUaGUN
Cj4gPiBnb2FsDQo+ID4NCj4gPiBpcyB0byBzaW1wbHkgbGltaXQgdGhlIG5ldHdvcmsgYW5kIHBy
b2Nlc3NvciBsb2FkLg0KPiA+DQo+ID4gIEZyb20gYSBzZXJ2ZXIgUE9WLCBJIGRvIG5vdCB3YW50
IGEgdGltZXIgb24gZXZlcnkgZGF0YSBub2RlIGluc3RhbmNlDQo+ID4NCj4gPiBhbmQgY29tcGxl
eCBjb2RlIHRvIGNvbnN0cnVjdCB0aGUgbmV4dCBvbi1jaGFuZ2Ugbm90aWZpY2F0aW9uLg0KPiA+
DQo+ID4gUk1PTiBoYW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5Lg0KPiA+DQo+ID4g
VGhlIHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUt
YXJtIGFuIGV2ZW50DQo+ID4gdHJpZ2dlci4NCj4gPg0KPiA+IFRoZSB0aW1lIGJldHdlZW4gY2hh
bmdlcyBpcyBub3QgdXNlZCBhdCBhbGwgdG8gZGV0ZXJtaW5lIGhvdyBtYW55DQo+ID4gZXZlbnRz
IHRvIHNlbmQuDQo+ID4NCj4gPiAoTm90IHN1Z2dlc3RpbmcgYWxsIHlhbmctcHVzaCB1c2UtY2Fz
ZXMgYXJlIHRocmVzaG9sZC1iYXNlZC4pDQo+ID4NCj4gPiBJTU8sIHRoZSBvcGVyYXRvciBzaG91
bGQgcHV0IGV2ZW50cyB0aGF0IHJlcXVpcmUgbG93LWxhdGVuY3kgaW50byBhDQo+ID4gc2VwYXJh
dGUgc3Vic2NyaXB0aW9uLA0KPiA+DQo+ID4gYW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3Vs
ZCBhcHBseSB0byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbi4NCj4gPg0KPiA+ICDCoC4uLg0KPiA+
DQo+ID4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+IEFuZHkNCj4gPg0KPiA+DQo+ID4NCj4g
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE5l
dGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZyA8bWFpbHRvOk5ldGNvbmZA
aWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj
b25mDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0
Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN
Cj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Thu Nov 30 16:29:22 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234091273B1 for ; Thu, 30 Nov 2017 16:29:21 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 aJeLsuqDfxxt for ; Thu, 30 Nov 2017 16:29:19 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 45459124D68 for ; Thu, 30 Nov 2017 16:29:19 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id r143so9881235lfe.13 for ; Thu, 30 Nov 2017 16:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bHE1TvZ83mHnBc+F498JJnI8quyNzGSkmQKym7itHG4=; b=Hdt0LeyeeYeiUDt4iThq5BmwAoE3SInMJohn2bfm3xzSHiZNXq0L9L8GijpMJoGOz7 Ez3RiQv04Ub7hVaAT03G4J89TK6w/R0lDNrnEsEapkIHsjvs8r6S/6UlHoU0qUd0l2J0 1Audl397s5ewTqHeBkCm+MJSj3jX02rFW5tEL/ljLkmXaUDjr2eAcsoZivs0D8oE+cPz ipR3HDp+Bhlau3wlQt8WGWqHtx7OonvSSeXEKp9n7WVbu7EqxZSbiiaw9yfNtoDgpwnf 74VQBBLtTTTFX9xDv2lt2YDFL+RXseKmrTsE6j41zLBbn69+EEce2jsSWyJSEMtCPK9z 9PCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bHE1TvZ83mHnBc+F498JJnI8quyNzGSkmQKym7itHG4=; b=nU+BaTYVkHIJ3+ptqHkmBm+Li8sF3IWChghniSYPyxyIlt0187uGKGkddXUsDQag0s WL7RpVQ6Q1rdds6BvIfMbKNBAhUzOZ3IpKzMyJGuHh+RaXJJkMFulHJmG2pVzlS4GsIR c3scmLU2G5VvuLzoQqrKlxKvHuQjMTwNWJm5aJqJwiPN99CvMQKnnlIhzZOgJZUs5Qvu tF4+UzQATlpbO7uDr6x44/gPDEX15d0kV/7TCgBhdZj38ABjYXK971LDozsy5krCrqNo z8XN9MxdsismfQzjxxfKxnHsGP1woPT+XM95o/rUbylVuU2Zf/AmHmDRzlTr1fzr/0Hj 2gmQ==
X-Gm-Message-State: AJaThX4ReTeTFBZ+L0TuV27PhOGOOc798p1PVjr21LhSym1ImSIVOJ0r EKcteYc7/43+cjFK7IRt9aud1cddZHa3j+4GO80EDxSy
X-Google-Smtp-Source: AGs4zMbj3bOa6EnTfFtfWiZUxcEX88WRp2Go98AgcUTUU4jWTji5IB3c5kxUaarHVZYnK2zLN36HuAMV/9A8RwYff6E=
X-Received: by 10.25.78.91 with SMTP id c88mr3456589lfb.4.1512088157236; Thu, 30 Nov 2017 16:29:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Thu, 30 Nov 2017 16:29:16 -0800 (PST)
From: Andy Bierman 
Date: Thu, 30 Nov 2017 16:29:16 -0800
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary="94eb2c1cdbb67b476a055f3c7599"
Archived-At: 
Subject: [Netconf] yang-push issue: encoding
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Dec 2017 00:29:21 -0000

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

Hi,

In yang-push-11:

3.5 .
Data Encodings

   A publisher MUST support XML encoding and MAY support other encodings
   such as JSON encoding.



I do not think this draft should mention encoding.
It is up to the protocol to specify message encoding rules.
The NETCONF protocol supports XML only.
RESTCONF uses Accept and Content-Type headers to determine the encoding.
CoMI will use CBOR for YANG-encoded data.



Andy

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






--94eb2c1cdbb67b476a055f3c7599--


From nobody Thu Nov 30 16:55:57 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472081201FA for ; Thu, 30 Nov 2017 16:55:56 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 wxclOW7uRU2a for ; Thu, 30 Nov 2017 16:55:54 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 70C06124D68 for ; Thu, 30 Nov 2017 16:55:54 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id 74so9980559lfs.0 for ; Thu, 30 Nov 2017 16:55:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sM2AcMQWg/df5dIqZFji/456bst9/Hi/3OohgX1zjL4=; b=EC7IsWeL+4CQuWMtS/50sTY/UASHsZ6QkZtZ7uIf4iD2DYYu/yFmd0GtxJ55cMk+lS +2MIB2UQDCf7whPJKk3u6U+c4jjX36Iix3qNetaUrRsjySGc092fZH5FiT86kCunxsT3 Dxgu/WAHRasorEtcLf76VYuzqCklOti00FOnmrl8t0yJxMt67stUJp+e/BQdHDMDo1OS v0hMB+uLHhtf5eZEXH7jYabrl5OWz1kQgbC0TraePios/Ijm91hPK+5KS7m1aZh3rhpl i6IDEjDJC1AeNNdK5vxmA9a3CsYJoeVnX709Z9cav4fLLAa0zDDyUl0sOl+/cFMp1G/K hh3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sM2AcMQWg/df5dIqZFji/456bst9/Hi/3OohgX1zjL4=; b=r0chzZNP73yE5JWm9u2Scn8SoqQujsSEgk57lAGwQysyscCoHeb6FzLU/5HvRhocH2 iEXUetSiIpnreREcOtM0yHT/RsqcxRL1H2+kGswesniF1CPstlWTYp7gFjqrTbLMpOBE 0DoFOF3/gGKkJL6mUAfvByWN3pAiL3+fEcG9XVg0qdssXbysZGeAoBK4te8aJl///o73 z3b0FyhfJchr5CepzHLgA4lDXJbEBAQM3k6/1PV6P4yindBNI2BrRlXw8rqltTkb+etI Yfj7Ygd4iLZWh3bN89QVkQZW4761nXZkauhjWYmkZfiSsk3ycile8XNGdgLMIczZoDXm 7bHg==
X-Gm-Message-State: AJaThX7UBWOxU2ZXGswCW2wXX1gU2cdbyYqg8s5HdTz/0B3pxXMcxehI wMwtOrnahqpkRafZMWXvizYqQYeaoC7BpF3fRFdEfdF8
X-Google-Smtp-Source: AGs4zMb4g7yoE1xBXBtB/zvzre9mo8Zc2PUCBCF6rFDxb9XplA7t9n27OiNtRb599zlS/MY6D68zKnfUDi2Bekvyx28=
X-Received: by 10.25.74.202 with SMTP id x193mr3333721lfa.28.1512089752446; Thu, 30 Nov 2017 16:55:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Thu, 30 Nov 2017 16:55:51 -0800 (PST)
From: Andy Bierman 
Date: Thu, 30 Nov 2017 16:55:51 -0800
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary="94eb2c1a1e10903ffd055f3cd475"
Archived-At: 
Subject: [Netconf] yang-push issue: XPath filter
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Dec 2017 00:55:56 -0000

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

Hi,

In sec. 3.6:


   These filters are intended to be used as selectors that define which
   objects are within the scope of a subscription.  A publisher MUST
   support at least one type of selection filter.


This is inconsistent with NETCONF, where subtree filtering in
mandatory-to-implement
and XPath filtering is optional (if-feature).  A client does not have any
way to know what a
publisher will support.

It would be better to follow NETCONF and add an if-feature to XPath, and
declare
that subtree is mandatory.

Also, the example on pg 36 is wrong:

OLD:

       


NEW:



       /ex:foo

       


>From the YANG module:


      leaf xpath-filter {
        type yang:xpath1.0;
        description
          "This parameter contains an XPath expression identifying the
          portions of the target datastore to retrieve.";
        reference "http://www.w3.org/TR/1999/REC-xpath-19991116";
      }



Andy

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


Hi,

In sec. 3.6:


   These filters are in=
tended to be used as selectors that define which
   objects are within the scope of a subscription.  A publisher MUST
   support at least one type of selection filter.

This is inconsistent with NETCONF, where subtree filtering in mandato=
ry-to-implement
and XPath filtering is optional (if-feature).=C2=
=A0 A client does not have any way to know what a
publisher will =
support.=C2=A0

It would be better to follow NETCON=
F and add an if-feature to XPath, and declare
that subtree is man=
datory.=C2=A0

Also, the example on pg 36 is wrong:=


OLD:

       <yp:xpath-filter
            xmlns:ex=3D"http://example.com/sample-data/1.0"
            select=3D"/ex:foo"/>

NEW:


  =
     <yp:xpath-filter
        xmlns:ex=3D"htt=
p://example.com/sample-data/1.0">/ex:foo
=
       </yp:xpath-filter>


From the YANG module:=


      leaf xpath-filter {
        type yang:xpath1.0;
        description
          "This parameter contains an XPath expression identifying the
          portions of the target datastore to retrieve.";
        reference "http://www.w3.org/TR/1999/REC-xpath-19991116";
      }


Andy



--94eb2c1a1e10903ffd055f3cd475--


From nobody Thu Nov 30 20:07:42 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE91241F5 for ; Thu, 30 Nov 2017 20:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo22XRWWpHnL for ; Thu, 30 Nov 2017 20:07:38 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A894B1270B4 for ; Thu, 30 Nov 2017 20:07:37 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0E1C2FE22E715 for ; Fri,  1 Dec 2017 04:07:34 +0000 (GMT)
Received: from DGGEMA402-HUB.china.huawei.com (10.3.20.43) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 1 Dec 2017 04:07:34 +0000
Received: from DGGEMA502-MBX.china.huawei.com ([169.254.2.85]) by DGGEMA402-HUB.china.huawei.com ([10.3.20.43]) with mapi id 14.03.0361.001; Fri, 1 Dec 2017 12:07:20 +0800
From: Rohit R Ranade 
To: "Eric Voit (evoit)" 
CC: Netconf 
Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11
Thread-Index: AQHTaCzM4Chkdhf7n0yfB4m8U5WwO6MrJmCAgAAhEwCAAEzIAIAAAjwAgADhTOCAAAoLgIABYAGQ
Date: Fri, 1 Dec 2017 04:07:20 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6B15DB9A@DGGEMA502-MBX.china.huawei.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF7B7@sjceml521-mbx.china.huawei.com> <4c09b3525b78410da242149893593159@XCH-RTP-013.cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EACF95C@sjceml521-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6B15CFDD@DGGEMA502-MBX.china.huawei.com> <912c3dc57e404c7ea7fbce529a3eaf19@XCH-RTP-013.cisco.com>
In-Reply-To: <912c3dc57e404c7ea7fbce529a3eaf19@XCH-RTP-013.cisco.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_991B70D8B4112A4699D5C00DDBBF878A6B15DB9ADGGEMA502MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Dec 2017 04:07:41 -0000

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

SGkgRXJpYywNCg0KSW4geW91ciBjYXNlICwgdGhlbiB0aGVyZSBpcyBhIGNvcm5lciBjYXNlIHdo
ZXJlIGluIGlmIHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlzIHNob3J0LCB0aGUgZGV2aWNlIG1heSBo
YXZlIHN0aWxsIG5vdCBmaW5pc2hlZCBzZW5kaW5nIGFsbCBpdHMgbm90aWZpY2F0aW9uIGZyYWdt
ZW50cyBhbmQgdGhlIG5leHQgdXBkYXRlIHJlY29yZCBpcyBhbHJlYWR5IHJlYWR5IHRvIGdldCBh
c3NlbWJsZWQuICBXaGV0aGVyIHdlIGNhbiBoYXZlIGEgbG93ZXIgbGltaXQgb24gdGhlIGRhbXBl
bmluZyBwZXJpb2QgaW50ZXJ2YWwgdG8gYXZvaWQgc3VjaCBhIHNjZW5hcmlvID8NCg0KV2l0aCBS
ZWdhcmRzLA0KUm9oaXQgUg0KDQpGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0
QGNpc2NvLmNvbV0NClNlbnQ6IDMwIE5vdmVtYmVyIDIwMTcgMjA6MzINClRvOiBSb2hpdCBSIFJh
bmFkZSA8cm9oaXRycmFuYWRlQGh1YXdlaS5jb20+OyBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRl
ci5jbGVtbUBodWF3ZWkuY29tPjsgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBN
YXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47IGt3YXRzZW5AanVuaXBlci5uZXQ7IFJh
bmR5IFByZXN1aG4gPHJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdT4NCkNjOiBOZXRj
b25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtOZXRjb25mXSByZXZpZXcgb2Yg
ZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KDQpIaSBSYW5keSwNCkhpIFJvaGl0LA0K
SGkgQWxleCwNCg0KVGhhbmtzIGZvciB0aGUgdGhvdWdodHMuDQoNClJhbmR5LCBvbiB5b3VyIHBv
aW50OiBpdCBpcyB0cnVlIHByZXZpb3VzIHdvcmRpbmcgb2YgdGhlIFlBTkcgZGVzY3JpcHRpb24g
Y2FuIGJlIHRpZ2h0ZW5lZCB1cC4gIEFuZCB5b3VyIHBhcmFwaHJhc2luZyBmb3IgdGhlIFlBTkcg
ZGVzY3JpcHRpb24gcHJvdmlkZWQgZ29vZCBndWlkYW5jZS4gIEJlbG93IEkgZ2l2ZSBhbiBhdHRl
bXB0IHJlZnJhbWluZyB5YW5nIGRlc2NyaXB0aW9uLCBhbHNvIHRha2luZyBpbnRvIGFjY291bnQg
QWxleCAmIFJvaGl04oCZcyBjb21tZW50cy4uLg0KDQpZQU5HIERlc2NyaXB0aW9uDQoNClNwZWNp
ZmllcyB0aGUgbWluaW11bSBpbnRlcnZhbCBiZXR3ZWVuIHRoZSBhc3NlbWJseSBvZiBzdWNjZXNz
aXZlIHVwZGF0ZSByZWNvcmRzIGZvciBhIHNpbmdsZSByZWNlaXZlciBvZiBhIHN1YnNjcmlwdGlv
bi4gV2hlbmV2ZXIgc3Vic2NyaWJlZCBvYmplY3RzIGNoYW5nZSwgYW5kIGEgZGFtcGVuaW5nIHBl
cmlvZCBpbnRlcnZhbCAod2hpY2ggbWF5IGJlIHplcm8pIGhhcyBlbGFwc2VkIHNpbmNlIHRoZSBw
cmV2aW91cyB1cGRhdGUgcmVjb3JkIGNyZWF0aW9uIGZvciBhIHJlY2VpdmVyLCB0aGVuIGFueSBz
dWJzY3JpYmVkIG9iamVjdHMgYW5kIHByb3BlcnRpZXMgd2hpY2ggaGF2ZSBjaGFuZ2VkIHNpbmNl
IHRoZSBwcmV2aW91cyB1cGRhdGUgcmVjb3JkIHdpbGwgaGF2ZSB0aGVpciBjdXJyZW50IHZhbHVl
cyBtYXJzaGFsbGVkIGFuZCBwbGFjZWQgaW50byBhIG5ldyB1cGRhdGUgcmVjb3JkLg0KDQpSb2hp
dCwgb24geW91ciBwb2ludDogdG8gY292ZXIgYW55IHN1Y2ggYSBwb3NzaWJpbGl0eSwgaXQgbWln
aHQgYmUgYmV0dGVyIHRvIHJlc2V0IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGFmdGVyIGEgc3BlY2lm
aWMgdXBkYXRlIHJlY29yZCBpcyBhc3NlbWJsZWQuICAgVGhpcyB3YXkgYW55IGJ1bmRsaW5nIG9m
IHVwZGF0ZXMgaW50byBub3RpZmljYXRpb24gbWVzc2FnZXMsIG9yIGZyYWdtZW50YXRpb24gZGVs
YXlzIHdvbuKAmXQgcmVzdWx0IGluIGFuIGlycmVndWxhciBvciB1bnByZWRpY3RhYmxlIGRhbXBl
bmluZyBwZXJpb2QuICAgTG9vayBiZWxvdyBhdCBteSBhdHRlbXB0IHRvIGZyYW1lIHRoaXMgd2l0
aGluIFNlY3Rpb24gMy4xMCB0ZXh0Li4uDQoNCkFsZXgsIG9uIHlvdXIgcG9pbnQ6IHllcyB3ZSBu
ZWVkIHRvIGJlIGV4cGxpY2l0IGFib3V0IGp1c3QgdGhlIGxhc3QgdmFsdWUgYmVpbmcgc2VudC4g
IEkgdHdlYWsgaXQgaW50byB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIDMuMTAgYmVsb3cuICBJIHRo
aW5rIEkgYWxzbyBjb3ZlcmVkIGluIGl0IHRoZSBZQU5HIGRlc2NyaXB0aW9uIGFib3ZlLi4uDQoN
ClNlY3Rpb24gMy4xMA0KDQpEYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2Ny
aXB0aW9uLCBkZXRlY3RlZCBvYmplY3QgY2hhbmdlcyBzaG91bGQgYmUgc2VudCBhcyBxdWlja2x5
IGFzIHBvc3NpYmxlLiAgSG93ZXZlciBpdCBtYXkgYmUgdW5kZXNpcmFibGUgdG8gc2VuZCBhIHJh
cGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdlcy4gIFN1Y2ggYmVoYXZpb3IgaGFzIHRoZSBwb3Rl
bnRpYWwgdG8gZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZl
ci4gIEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRhbXBlbmluZyBwZXJpb2Qg
TUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJlZm9y
ZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJl
IGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4gIFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3Rp
dmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBz
aW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2VpdmVyLiAgVGhpcyBt
ZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgdG8gb25lIG9yIG1vcmUgc3Vic2NyaWJl
ZCBvYmplY3RzLCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhvc2Ugb2JqZWN0cyBpcyBj
cmVhdGVkIGVpdGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMgaW4g
ZWZmZWN0LCBvciBhdCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nIHBlcmlvZC4gIElmIG11bHRpcGxl
IGNoYW5nZXMgdG8gYSBzaW5nbGUgb2JqZWN0IG9jY3VyIGR1cmluZyBhIGRhbXBlbmluZyBwZXJp
b2QsIG9ubHkgdGhlIHZhbHVlIHRoYXQgaXMgaW4gZWZmZWN0IGlzIGluY2x1ZGVkIGFzIHBhcnQg
b2YgdGhlIHVwZGF0ZSByZWNvcmQuICBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkg
dGltZSBhbiB1cGRhdGUgcmVjb3JkIGhhcyBjb21wbGV0ZWQgaXRzIGFzc2VtYmx5Lg0KDQoNCkVy
aWMNCg0KRnJvbTogUm9oaXQgUiBSYW5hZGUsIE5vdmVtYmVyIDMwLCAyMDE3IDE6MzAgQU0NCkhp
IEVyaWMsDQoNCldlIG5lZWQgYWxzbyBjb25zaWRlciB0aGF0IGNvbW1pdCBtYXliZSB2ZXJ5IGJp
ZyBvciBpbiB0aGUgZGFtcGVuaW5nIHRpbWUgc28gbWFueSByZWNvcmRzIGFyZSB1cGRhdGVkIHRo
YXQgdGhlIDxub3RpZmljYXRpb24+IG1lc3NhZ2UgbWF5IG5lZWQgdG8gYmUgc3BsaXQgYWNyb3Nz
IGZyYWdtZW50cy4gIEkgc3VnZ2VzdCByZWZyYW1pbmcgb2YgdGhlIHNlbnRlbmNlIHRvDQoNCuKA
nEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIHRoZSBsYXN0IGZyYWdtZW50
IG9mIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnTigJ0N
Cg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdCBSDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRj
b25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgQ2xlbW0NClNlbnQ6
IDMwIE5vdmVtYmVyIDIwMTcgMDY6MjkNClRvOiBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lz
Y28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PjsgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3
b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+OyBNYXJ0aW4gQmpvcmtsdW5kIDxt
YmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pjsga3dhdHNlbkBqdW5pcGVyLm5l
dDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNjOiBOZXRjb25mIDxuZXRjb25mQGlldGYu
b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gcmV2
aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTENCg0KVGhpcyB3b3JrcyBmb3Ig
bWUuICBQZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0gd2UgbWlnaHQgYWRkIChmb3IgY3J5c3Rh
bC1jbGVhciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdoZW4gdGhlIG5vdGlmaWNhdGlvbiBtZXNz
YWdlIGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBtb3N0IHJlY2VudCB1cGRhdGUgZm9yIHRoYXQg
b2JqZWN0IChpLmUuIHRoZSB2YWx1ZSB0aGF0IGlzIGluIGVmZmVjdCB3aGVuIHRoZSB1cGRhdGUg
aXMgc2VudCkuICBJZiB0aGVyZSBhcmUgc29tZSBxdWlja2x5IG9zY2lsbGF0aW5nIHZhbHVlcyB3
ZSBkb27igJl0IHNlbmQgdGhlIHdob2xlIHNlcXVlbmNlIG9mIHVwZGF0ZXMvdmFsdWVzLg0KDQot
LS0gQWxleA0KDQpGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNv
bV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgNDo1MSBQTQ0KVG86IEFsZXhh
bmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5j
bGVtbUBodWF3ZWkuY29tPj47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0
bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208
bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRz
ZW5AanVuaXBlci5uZXQ+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0
Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1p
ZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNClRoZSBTZWN0aW9uIDMuMSB0ZXh0IEkgcHJvcG9z
ZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9uIHRoZSBkYW1wZW5pbmcgcXVlc3Rpb246DQoN
Cg0KRGFtcGVuaW5nIHBlcmlvZDogSW4gYW4gb24tY2hhbmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0
ZWQgb2JqZWN0IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4g
IEhvd2V2ZXIgd2l0aG91dCBhZGVxdWF0ZSBwcm90ZWN0aW9ucywgYSByYXBpZCBzZXJpZXMgb2Yg
b2JqZWN0IGNoYW5nZXMgbWlnaHQgZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hl
ciBvciByZWNlaXZlci4gIEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRhbXBl
bmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVz
dCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJz
Y3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4gIFRoZSBkYW1wZW5pbmcgcGVy
aW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2Vs
ZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJlY2Vp
dmVyLiAgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgdG8gYSBzdWJzY3Jp
YmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRoYXQgb2JqZWN0IGlzIGNy
ZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBl
ZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiAgQSBkYW1wZW5pbmcg
cGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMg
cGFzc2VkIHRvIHRyYW5zcG9ydC4NCg0KDQoNCldpdGggdGhlIFlBTkcgZGVzY3JpcHRpb24gb2Y6
DQoNCg0KDQoiU3BlY2lmaWVzIHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1
Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2Vu
ZXJhdGVkIGZvciBhIHJlY2VpdmVyLiAgVGhlIGRhbXBlbmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5
IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxlY3RlZCBieSBhIHNpbmds
ZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuICBUaGlzIG1lYW5z
IHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmliZWQgb2JqZWN0LCBhbiB1
cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1t
ZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhl
IGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuICBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQg
ZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNw
b3J0LiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZp
Y2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4gIEEgemVybyB2YWx1ZSBpbmRp
Y2F0ZXMgbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBzdWJzY3JpYmVkIG9iamVjdCBjaGFu
Z2VzIGFyZSBzZW50IGltbWVkaWF0ZWx5LiINCg0KDQoNCkRvZXMgdGhpcyB3b3JrIGZvciBldmVy
eW9uZT8NCg0KRXJpYw0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgQ2xlbW0NClNlbnQ6IFdlZG5lc2RheSwg
Tm92ZW1iZXIgMjksIDIwMTcgMzoxNyBQTQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y
a3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGluIEJqb3JrbHVuZCA8bWJq
QHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4NCkNjOiBOZXRjb25mIDxuZXRjb25m
QGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29u
Zl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTENCg0KSSB0aG91Z2h0
IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJpbmVkIGRhbXBlbmluZyBmb3IgYWxsIG9iamVj
dHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4gIEluIHRoaXMgY2FzZSwgd2Ugd291bGQgc2VuZCB1cGRh
dGVzIGF0IDIsIDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAoY29udGFpbmluZyAxMywg
MTQsIDE1KS4NCg0KSWYgdGhlIHNjb3BlIG9mIHRoZSBzdWJzY3JpcHRpb24gYmVjb21lcyBzdWZm
aWNpZW50bHkgbGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVydHMgYmFjayB0byBhIHBlcmlvZGljIHN1
YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlzIGdvaW5nIHRvIGJlIGEgY2hhbmdlIHNv
bWV3aGVyZSkuICBUaGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVkIHRvIGhhdmUgaXQgaW5k
ZWVkIG9uIGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0IGFyZ3VtZW50LiAgRm9y
IHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJlIGEgY2xpZW50IGlzIGluZGVlZCBpbnRl
cmVzdCBpbiBnZXR0aW5nIGRlbGF5cyBvZiBpbmRpdmlkdWFsIG9iamVjdHMgd2l0aG91dCBkZWxh
eSwgIGEgY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlzaCBtdWx0aXBsZSDigJxt
aWNyb+KAnSBzdWJzY3JpcHRpb25zLg0KDQpUQ0FzIGluIFJNT04gYXJlIHNvbWV0aGluZyBkaWZm
ZXJlbnQgYWx0b2dldGhlci4gIFRoaXMgaXMgc29tZXRoaW5nIHdlIGFyZSB0cnlpbmcgdG8gYWRk
cmVzcyB3aXRoIHNtYXJ0IGZpbHRlcnMuDQoNCi0tLSBBbGV4DQoNCg0KRnJvbTogTmV0Y29uZiBb
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1h
bg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMDoxOCBBTQ0KVG86IE1hcnRp
biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+DQpDYzog
TmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJq
ZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNo
LTExDQoNCg0KDQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCAxOjM3IEFNLCBNYXJ0aW4gQmpvcmts
dW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCkhpLA0K
DQouLi4uDQoNCm8gIDMuMQ0KDQogIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGRhbXBl
bmluZyBwZXJpb2QgY29uY2VwdC4gIExldCdzDQogIGFzc3VtZSB0aGF0IHRoZSBkYW1wZW5pbmcg
cGVyaW9kIGlzIDEwcy4gIFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQNCiAgdGltZXM6DQoNCiAgICAy
ICAzICA0ICAxMSAgMTMgIDE0ICAxNQ0KDQogIEZyb20gdGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVt
cyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9tDQogIHRpbWVzOg0KDQogICAg
MiAgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAyKQ0KICAgIDEyIChjb250YWluaW5nIGNo
YW5nZSBmcm9tIDMsNCwxMSkNCiAgICAxMyAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDEz
KQ0KICAgIDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwxNSkNCg0KICBJcyB0aGlzIGNv
cnJlY3Q/DQoNCiAgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUgZGVzY3JpcHRpb24gaW4gdGhl
IFlBTkcgbW9kdWxlIGlzDQogIGNsYXJpZmllZCAtIGN1cnJlbnRseSB0aGUgUkZDIHRleHQgY29u
dGFpbnMgbW9yZSBkZXRhaWxzIHRoYW4gdGhlDQogIFlBTkcgbW9kdWxlLg0KDQoNClNlZW1zIHRv
IG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRhbXBlbmluZyB0byBhcHBs
eQ0KdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNoIG5vZGUgd2l0aGluIHRo
ZSBzdWJzY3JpcHRpb24uDQpJIHdhbnQgImF0IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNv
bmQiLiAgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudA0KdG8gYmUgdG9sZCBhYm91dCBhbiBp
bmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuICBJIGNvdWxkIHN0aWxsDQpnZXQg
MTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQgZGF0YSBub2Rlcy4gIFRoZSByZWNl
aXZlciBkb2VzIG5vdA0KcmVhbGx5IGNhcmUgd2hldCBub2RlcyBhcmUgYmVpbmcgcmVwb3J0ZWQg
aW4gZWFjaCBub3RpZmljYXRpb24uIFRoZSBnb2FsDQppcyB0byBzaW1wbHkgbGltaXQgdGhlIG5l
dHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLg0KDQpGcm9tIGEgc2VydmVyIFBPViwgSSBkbyBub3Qg
d2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBpbnN0YW5jZQ0KYW5kIGNvbXBsZXggY29k
ZSB0byBjb25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbi4NCg0KUk1PTiBo
YW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5Lg0KVGhlIHJpc2luZyBhbmQgZmFsbGlu
ZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFuIGV2ZW50IHRyaWdnZXIu
DQpUaGUgdGltZSBiZXR3ZWVuIGNoYW5nZXMgaXMgbm90IHVzZWQgYXQgYWxsIHRvIGRldGVybWlu
ZSBob3cgbWFueSBldmVudHMgdG8gc2VuZC4NCihOb3Qgc3VnZ2VzdGluZyBhbGwgeWFuZy1wdXNo
IHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2VkLikNCg0KSU1PLCB0aGUgb3BlcmF0b3Igc2hv
dWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5IGludG8gYSBzZXBhcmF0ZSBz
dWJzY3JpcHRpb24sDQphbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qgc2hvdWxkIGFwcGx5IHRvIHRo
ZSBlbnRpcmUgc3Vic2NyaXB0aW9uLg0KDQogLi4uDQoNCg0KDQoNCi9tYXJ0aW4NCg0KDQpBbmR5
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5l
dGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg==

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15DB9ADGGEMA502MBXchi_
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
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo
YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRl
eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu
bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi
VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls
U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG
NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw
YW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9
DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy
LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2
bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEVy
aWMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkluIHlvdXIgY2FzZSAsIHRoZW4gdGhlcmUgaXMgYSBjb3JuZXIgY2Fz
ZSB3aGVyZSBpbiBpZiB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyBzaG9ydCwgdGhlIGRldmljZSBt
YXkgaGF2ZSBzdGlsbCBub3QgZmluaXNoZWQgc2VuZGluZyBhbGwgaXRzIG5vdGlmaWNhdGlvbg0K
IGZyYWdtZW50cyBhbmQgdGhlIG5leHQgdXBkYXRlIHJlY29yZCBpcyBhbHJlYWR5IHJlYWR5IHRv
IGdldCBhc3NlbWJsZWQuJm5ic3A7IFdoZXRoZXIgd2UgY2FuIGhhdmUgYSBsb3dlciBsaW1pdCBv
biB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpbnRlcnZhbCB0byBhdm9pZCBzdWNoIGEgc2NlbmFyaW8g
PyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+Um9oaXQgUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBWb2l0IChldm9p
dCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMzAgTm92ZW1i
ZXIgMjAxNyAyMDozMjxicj4NCjxiPlRvOjwvYj4gUm9oaXQgUiBSYW5hZGUgJmx0O3JvaGl0cnJh
bmFkZUBodWF3ZWkuY29tJmd0OzsgQWxleGFuZGVyIENsZW1tICZsdDthbGV4YW5kZXIuY2xlbW1A
aHVhd2VpLmNvbSZndDs7IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozsg
TWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7OyBrd2F0c2VuQGp1bmlwZXIu
bmV0OyBSYW5keSBQcmVzdWhuICZsdDtyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHUm
Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNv
bmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFJhbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+SGkgUm9oaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbGV4LDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5UaGFua3MgZm9yIHRoZSB0aG91Z2h0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmFuZHksIG9uIHlv
dXIgcG9pbnQ6IGl0IGlzIHRydWUgcHJldmlvdXMgd29yZGluZyBvZiB0aGUgWUFORyBkZXNjcmlw
dGlvbiBjYW4gYmUgdGlnaHRlbmVkIHVwLiZuYnNwOyBBbmQgeW91ciBwYXJhcGhyYXNpbmcgZm9y
IHRoZSBZQU5HIGRlc2NyaXB0aW9uIHByb3ZpZGVkDQogZ29vZCBndWlkYW5jZS4mbmJzcDsgQmVs
b3cgSSBnaXZlIGFuIGF0dGVtcHQgcmVmcmFtaW5nIHlhbmcgZGVzY3JpcHRpb24sIGFsc28gdGFr
aW5nIGludG8gYWNjb3VudCBBbGV4ICZhbXA7IFJvaGl04oCZcyBjb21tZW50cy4uLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48dT48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ZQU5HIERlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+
PC91PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TcGVjaWZpZXMgdGhlIG1pbmltdW0gaW50ZXJ2YWwgYmV0
d2VlbiB0aGUgYXNzZW1ibHkgb2Ygc3VjY2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgYSBzaW5n
bGUgcmVjZWl2ZXIgb2YgYSBzdWJzY3JpcHRpb24uIFdoZW5ldmVyIHN1YnNjcmliZWQgb2JqZWN0
cyBjaGFuZ2UsIGFuZCBhIGRhbXBlbmluZyBwZXJpb2QgaW50ZXJ2YWwNCiAod2hpY2ggbWF5IGJl
IHplcm8pIGhhcyBlbGFwc2VkIHNpbmNlIHRoZSBwcmV2aW91cyB1cGRhdGUgcmVjb3JkIGNyZWF0
aW9uIGZvciBhIHJlY2VpdmVyLCB0aGVuIGFueSBzdWJzY3JpYmVkIG9iamVjdHMgYW5kIHByb3Bl
cnRpZXMgd2hpY2ggaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoZSBwcmV2aW91cyB1cGRhdGUgcmVjb3Jk
IHdpbGwgaGF2ZSB0aGVpciBjdXJyZW50IHZhbHVlcyBtYXJzaGFsbGVkIGFuZCBwbGFjZWQgaW50
byBhIG5ldyB1cGRhdGUNCiByZWNvcmQuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Um9oaXQsIG9uIHlvdXIgcG9pbnQ6IHRvIGNvdmVyIGFueSBzdWNoIGEg
cG9zc2liaWxpdHksIGl0IG1pZ2h0IGJlIGJldHRlciB0byByZXNldCB0aGUgZGFtcGVuaW5nIHBl
cmlvZCBhZnRlciBhIHNwZWNpZmljIHVwZGF0ZSByZWNvcmQgaXMgYXNzZW1ibGVkLiZuYnNwOyZu
YnNwOw0KIFRoaXMgd2F5IGFueSBidW5kbGluZyBvZiB1cGRhdGVzIGludG8gbm90aWZpY2F0aW9u
IG1lc3NhZ2VzLCBvciBmcmFnbWVudGF0aW9uIGRlbGF5cyB3b27igJl0IHJlc3VsdCBpbiBhbiBp
cnJlZ3VsYXIgb3IgdW5wcmVkaWN0YWJsZSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyZuYnNwOyBM
b29rIGJlbG93IGF0IG15IGF0dGVtcHQgdG8gZnJhbWUgdGhpcyB3aXRoaW4gU2VjdGlvbiAzLjEw
IHRleHQuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+QWxleCwgb24geW91ciBwb2ludDogeWVzIHdlIG5lZWQgdG8g
YmUgZXhwbGljaXQgYWJvdXQganVzdCB0aGUgbGFzdCB2YWx1ZSBiZWluZyBzZW50LiZuYnNwOyBJ
IHR3ZWFrIGl0IGludG8gdGhlIGRlc2NyaXB0aW9uIGluIHRoZSAzLjEwIGJlbG93LiZuYnNwOyBJ
IHRoaW5rDQogSSBhbHNvIGNvdmVyZWQgaW4gaXQgdGhlIFlBTkcgZGVzY3JpcHRpb24gYWJvdmUu
Li48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjx1
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gMy4xMDxvOnA+PC9vOnA+PC9z
cGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6
MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGFtcGVuaW5nIHBlcmlvZDogSW4gYW4gb24tY2hh
bmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQg
YXMgcXVpY2tseSBhcyBwb3NzaWJsZS4mbmJzcDsgSG93ZXZlciBpdCBtYXkgYmUgdW5kZXNpcmFi
bGUgdG8gc2VuZCBhIHJhcGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdlcy4mbmJzcDsgU3VjaA0K
IGJlaGF2aW9yIGhhcyB0aGUgcG90ZW50aWFsIHRvIGV4aGF1c3Qgb2YgcmVzb3VyY2VzIGluIHRo
ZSBwdWJsaXNoZXIgb3IgcmVjZWl2ZXIuJm5ic3A7IEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5z
dCB0aGF0LCBhIGRhbXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50
ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZv
ciB0aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZA0KIGZvciBhIHJlY2VpdmVyLiZu
YnNwOyBUaGUgZGFtcGVuaW5nIHBlcmlvZCBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0
IG9mIGFsbCBkYXRhIG5vZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQg
c2VudCB0byBhIHNpbmdsZSByZWNlaXZlci4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhl
cmUgaXMgYSBjaGFuZ2UgdG8gb25lIG9yIG1vcmUgc3Vic2NyaWJlZCBvYmplY3RzLCBhbiB1cGRh
dGUgcmVjb3JkIGNvbnRhaW5pbmcNCiB0aG9zZSBvYmplY3RzIGlzIGNyZWF0ZWQgZWl0aGVyIGlt
bWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRo
ZSBlbmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyBJZiBtdWx0aXBsZSBjaGFuZ2VzIHRv
IGEgc2luZ2xlIG9iamVjdCBvY2N1ciBkdXJpbmcgYSBkYW1wZW5pbmcgcGVyaW9kLCBvbmx5IHRo
ZSB2YWx1ZSB0aGF0IGlzIGluIGVmZmVjdCBpcyBpbmNsdWRlZCBhcyBwYXJ0IG9mIHRoZSB1cGRh
dGUNCiByZWNvcmQuJm5ic3A7IEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1l
IGFuIHVwZGF0ZSByZWNvcmQgaGFzIGNvbXBsZXRlZCBpdHMgYXNzZW1ibHkuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4gUm9oaXQgUiBSYW5hZGUsIE5vdmVtYmVyIDMwLCAyMDE3DQogMTozMCBBTTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEVyaWMsPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPldlIG5lZWQgYWxzbyBjb25zaWRlciB0aGF0IGNvbW1pdCBtYXliZSB2ZXJ5IGJpZyBv
ciBpbiB0aGUgZGFtcGVuaW5nIHRpbWUgc28gbWFueSByZWNvcmRzIGFyZSB1cGRhdGVkIHRoYXQg
dGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IG1lc3NhZ2UgbWF5IG5lZWQgdG8NCiBiZSBzcGxpdCBh
Y3Jvc3MgZnJhZ21lbnRzLiAmbmJzcDtJIHN1Z2dlc3QgcmVmcmFtaW5nIG9mIHRoZSBzZW50ZW5j
ZSB0byA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxBIGRh
bXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSB0aGUgbGFzdCBmcmFnbWVudCBvZiBh
IG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J04oCdJm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCBSZWdhcmRz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9oaXQgUjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPkFsZXhhbmRlciBDbGVtbTxicj4NCjxiPlNlbnQ6PC9iPiAzMCBOb3ZlbWJlciAyMDE3IDA2
OjI5PGJyPg0KPGI+VG86PC9iPiBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRAY2lzY28uY29tPC9hPiZndDs7IEFuZHkgQmllcm1hbiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29t
PC9hPiZndDs7IE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1m
LmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1
bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPjxicj4NCjxiPkNjOjwvYj4gTmV0Y29u
ZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8
L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFm
dC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgd29ya3MgZm9yIG1lLiZuYnNwOyBQ
ZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0gd2UgbWlnaHQgYWRkIChmb3IgY3J5c3RhbC1jbGVh
ciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdoZW4gdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlz
IHNlbnQsIGl0DQogY29udGFpbnMgdGhlIG1vc3QgcmVjZW50IHVwZGF0ZSBmb3IgdGhhdCBvYmpl
Y3QgKGkuZS4gdGhlIHZhbHVlIHRoYXQgaXMgaW4gZWZmZWN0IHdoZW4gdGhlIHVwZGF0ZSBpcyBz
ZW50KS4mbmJzcDsgSWYgdGhlcmUgYXJlIHNvbWUgcXVpY2tseSBvc2NpbGxhdGluZyB2YWx1ZXMg
d2UgZG9u4oCZdCBzZW5kIHRoZSB3aG9sZSBzZXF1ZW5jZSBvZiB1cGRhdGVzL3ZhbHVlcy4mbmJz
cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBWb2l0IChldm9pdCkgWzxhIGhyZWY9Im1haWx0bzpl
dm9pdEBjaXNjby5jb20iPm1haWx0bzpldm9pdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu
dDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgNDo1MSBQTTxicj4NCjxiPlRvOjwv
Yj4gQWxleGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1
YXdlaS5jb20iPmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPC9hPiZndDs7IEFuZHkgQmllcm1h
biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3Mu
Y29tPC9hPiZndDs7IE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFp
bC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzprd2F0c2Vu
QGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPjxicj4NCjxiPkNjOjwvYj4gTmV0
Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5v
cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBk
cmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBTZWN0aW9uIDMuMSB0ZXh0IEkg
cHJvcG9zZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9uIHRoZSBkYW1wZW5pbmcgcXVlc3Rp
b246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGFtcGVu
aW5nIHBlcmlvZDogSW4gYW4gb24tY2hhbmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0
IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4mbmJzcDsgSG93
ZXZlciB3aXRob3V0IGFkZXF1YXRlIHByb3RlY3Rpb25zLCBhIHJhcGlkIHNlcmllcyBvZiBvYmpl
Y3QgY2hhbmdlcyBtaWdodCBleGhhdXN0IG9mIHJlc291cmNlcyBpbiB0aGUNCiBwdWJsaXNoZXIg
b3IgcmVjZWl2ZXIuJm5ic3A7IEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRh
bXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2gg
bXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBz
dWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4mbmJzcDsgVGhlIGRhbXBl
bmluZyBwZXJpb2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMNCiB0byB0aGUgc2V0IG9mIGFsbCBkYXRh
IG5vZGVzIHNlbGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBhIHNp
bmdsZSByZWNlaXZlci4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFu
Z2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRo
YXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5n
IHBlcmlvZCBpcw0KIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJp
b2QuJm5ic3A7IEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5v
dGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldp
dGggdGhlIFlBTkcgZGVzY3JpcHRpb24gb2Y6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVv
dDtTcGVjaWZpZXMgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vzc2l2
ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUgc3Vic2NyaXB0aW9uIGFyZSBnZW5lcmF0ZWQg
Zm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBh
cHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYQ0KIHNpbmds
ZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuJm5ic3A7IFRoaXMg
bWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIGEgc3Vic2NyaWJlZCBvYmplY3Qs
IGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcyBjcmVhdGVkIGVpdGhl
ciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBh
dCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nIHBlcmlvZC4mbmJzcDsNCiBBIGRhbXBlbmluZyBwZXJp
b2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNz
ZWQgdG8gdHJhbnNwb3J0LiZuYnNwOyBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkg
dGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNwb3J0LiZu
YnNwOyBBIHplcm8gdmFsdWUgaW5kaWNhdGVzIG5vIGRhbXBlbmluZyBwZXJpb2QsIGFuZCBhbGwg
c3Vic2NyaWJlZCBvYmplY3QgY2hhbmdlcw0KIGFyZSBzZW50IGltbWVkaWF0ZWx5LiZxdW90Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvZXMgdGhpcyB3
b3JrIGZvciBldmVyeW9uZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxicj4NCkVy
aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g
MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0
bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5v
cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGV4YW5kZXIgQ2xlbW08YnI+DQo8Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAzOjE3IFBNPGJyPg0KPGI+VG86PC9i
PiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFu
ZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7OyBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJt
YWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8
L2I+IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25m
QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSByZXZp
ZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRob3VnaHQgd2UgZGVj
aWRlZCB0aGF0IHdlIGhhdmUgY29tYmluZWQgZGFtcGVuaW5nIGZvciBhbGwgb2JqZWN0cyBpbiB0
aGUgc3Vic2NyaXB0aW9uLiZuYnNwOyBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIHNlbmQgdXBkYXRl
cyBhdCAyLCAxMiAoY29udGFpbmluZw0KIDMsNCwxMSksIGFuZCAyMiAoY29udGFpbmluZyAxMywg
MTQsIDE1KS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBzY29wZSBvZiB0aGUgc3Vic2NyaXB0aW9uIGJl
Y29tZXMgc3VmZmljaWVudGx5IGxhcmdlLCB0aGlzIGFsbW9zdCByZXZlcnRzIGJhY2sgdG8gYSBw
ZXJpb2RpYyBzdWJzY3JpcHRpb24gKHNpbmNlIHRoZXJlIGlzIGFsd2F5cyBnb2luZyB0bw0KIGJl
IGEgY2hhbmdlIHNvbWV3aGVyZSkuJm5ic3A7IFRoaXMgaXMgd2h5IEkgb3JpZ2luYWxseSBhcmd1
ZWQgdG8gaGF2ZSBpdCBpbmRlZWQgb24gYSBwZXItb2JqZWN0IGJhc2lzLCBidXQgSSBsb3N0IHRo
YXQgYXJndW1lbnQuJm5ic3A7IEZvciBzdWNoIGZpbmUtZ3JhaW5lZCB1cGRhdGVzLCB3aGVyZSBh
IGNsaWVudCBpcyBpbmRlZWQgaW50ZXJlc3QgaW4gZ2V0dGluZyBkZWxheXMgb2YgaW5kaXZpZHVh
bCBvYmplY3RzIHdpdGhvdXQgZGVsYXksICZuYnNwO2EgY2xpZW50IGNvdWxkDQogc2ltcGx5IG5l
ZWQgdG8gZXN0YWJsaXNoIG11bHRpcGxlIOKAnG1pY3Jv4oCdIHN1YnNjcmlwdGlvbnMuJm5ic3A7
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5UQ0FzIGluIFJNT04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dl
dGhlci4mbmJzcDsgVGhpcyBpcyBzb21ldGhpbmcgd2UgYXJlIHRyeWluZyB0byBhZGRyZXNzIHdp
dGggc21hcnQgZmlsdGVycy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks
IE5vdmVtYmVyIDI5LCAyMDE3IDEwOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gQmpvcmts
dW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29tPC9h
PiZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25m
QGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g
UmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwg
TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g
bGFuZz0iRU4tVVMiPkhpLDxicj4NCjxicj4NCi4uLi48YnI+DQo8YnI+DQpvJm5ic3A7IDMuMTxi
cj4NCjxicj4NCiZuYnNwOyBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkYW1wZW5pbmcg
cGVyaW9kIGNvbmNlcHQuJm5ic3A7IExldCdzPGJyPg0KJm5ic3A7IGFzc3VtZSB0aGF0IHRoZSBk
YW1wZW5pbmcgcGVyaW9kIGlzIDEwcy4mbmJzcDsgVGhlbiBjaGFuZ2VzIGhhcHBlbiBhdDxicj4N
CiZuYnNwOyB0aW1lczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDImbmJzcDsgMyZuYnNwOyA0
Jm5ic3A7IDExJm5ic3A7IDEzJm5ic3A7IDE0Jm5ic3A7IDE1PGJyPg0KPGJyPg0KJm5ic3A7IEZy
b20gdGhlIGRlc2NyaXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRp
b25zLCBmcm9tPGJyPg0KJm5ic3A7IHRpbWVzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMiZu
YnNwOyAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDIpPGJyPg0KJm5ic3A7ICZuYnNwOyAx
MiAoY29udGFpbmluZyBjaGFuZ2UgZnJvbSAzLDQsMTEpPGJyPg0KJm5ic3A7ICZuYnNwOyAxMyAo
Y29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDEzKTxicj4NCiZuYnNwOyAmbmJzcDsgMjMgKGNv
bnRhaW5pbmcgY2hhbmdlcyBmcm9tIDE0LDE1KTxicj4NCjxicj4NCiZuYnNwOyBJcyB0aGlzIGNv
cnJlY3Q/PGJyPg0KPGJyPg0KJm5ic3A7IEluIGFueSBjYXNlLCBJIHN1Z2dlc3QgdGhlIGRlc2Ny
aXB0aW9uIGluIHRoZSBZQU5HIG1vZHVsZSBpczxicj4NCiZuYnNwOyBjbGFyaWZpZWQgLSBjdXJy
ZW50bHkgdGhlIFJGQyB0ZXh0IGNvbnRhaW5zIG1vcmUgZGV0YWlscyB0aGFuIHRoZTxicj4NCiZu
YnNwOyBZQU5HIG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VlbXMgdG8gbWUg
KGZyb20gYSBjbGllbnQgUE9WKSB0aGF0IEkgd2FudCB0aGUgZGFtcGVuaW5nIHRvIGFwcGx5PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPnRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLCBub3QgdG8gZWFj
aCBub2RlIHdpdGhpbiB0aGUgc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHdh
bnQgJnF1b3Q7YXQgbW9zdCwgMSBub3RpZmljYXRpb24gcGVyIHNlY29uZCZxdW90Oy4mbmJzcDsg
SSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50byBiZSB0
b2xkIGFib3V0IGFuIGluZGl2aWR1YWwgZGF0YSBub2RlIG9uY2UgcGVyIHNlY29uZC4mbmJzcDsg
SSBjb3VsZCBzdGlsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5nZXQgMTAsMDAwIGV2ZW50cy9zZWMg
YnV0IGZvciBkaWZmZXJlbnQgZGF0YSBub2Rlcy4mbmJzcDsgVGhlIHJlY2VpdmVyIGRvZXMgbm90
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlYWxseSBjYXJlIHdoZXQgbm9kZXMgYXJlIGJlaW5nIHJl
cG9ydGVkIGluIGVhY2ggbm90aWZpY2F0aW9uLiBUaGUgZ29hbDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5pcyB0byBzaW1wbHkgbGltaXQgdGhlIG5ldHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbSBhIHNlcnZl
ciBQT1YsIEkgZG8gbm90IHdhbnQgYSB0aW1lciBvbiBldmVyeSBkYXRhIG5vZGUgaW5zdGFuY2U8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIGNvbXBsZXggY29kZSB0byBjb25zdHJ1Y3QgdGhlIG5l
eHQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiPlJNT04gaGFuZGxlcyBkYW1wZW5pbmcgdmVyeSBkaWZmZXJlbnRs
eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHJpc2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRz
IGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFuIGV2ZW50IHRyaWdnZXIuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPlRoZSB0aW1lIGJldHdlZW4gY2hhbmdlcyBpcyBub3QgdXNlZCBhdCBhbGwgdG8g
ZGV0ZXJtaW5lIGhvdyBtYW55IGV2ZW50cyB0byBzZW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4o
Tm90IHN1Z2dlc3RpbmcgYWxsIHlhbmctcHVzaCB1c2UtY2FzZXMgYXJlIHRocmVzaG9sZC1iYXNl
ZC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JTU8s
IHRoZSBvcGVyYXRvciBzaG91bGQgcHV0IGV2ZW50cyB0aGF0IHJlcXVpcmUgbG93LWxhdGVuY3kg
aW50byBhIHNlcGFyYXRlIHN1YnNjcmlwdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIHRo
ZSBkYW1wZW5pbmcgcGVyaW9kIHNob3VsZCBhcHBseSB0byB0aGUgZW50aXJlIHN1YnNjcmlwdGlv
bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw
Oy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCi9tYXJ0aW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_991B70D8B4112A4699D5C00DDBBF878A6B15DB9ADGGEMA502MBXchi_--




On Mon, Nov 27, 2017 at 4:00 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jet=
hanandani wrote:



> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to

> support features like licensing, and semantic versioning.



I do not know what this means. (The goal of the NMDA work is to

support NMDA - focus is good thing. Perhaps the minutes will some shed

light on what this AI means but the minutes are not out yet.)



+1

Someday we might learn t=
o use the YANG augment-stmt, but looks like not today ;-)

=C2=A0
<=
font color=3D"#888888">
/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<http://www.jacobs-university.de/>



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--001a114d6042315ce5055f003346--


From nobody Mon Nov 27 16:46:01 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306A0126E7A for ; Mon, 27 Nov 2017 16:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjDLEldQDopw for ; Mon, 27 Nov 2017 16:45:58 -0800 (PST)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A608126DFE for ; Mon, 27 Nov 2017 16:45:58 -0800 (PST)
Received: by mail-pl0-x231.google.com with SMTP id s23so4282886plk.10 for ; Mon, 27 Nov 2017 16:45:58 -0800 (PST)
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=MhZ3lJC2KE3Z2gm4aA1P9chY3ZA8zU9gdJVTn8mUU4s=; b=UqIFB4Llq4T7v7QJZchIz9f7VIjStAma5wUfyHCs27AMT3nUXVi8s2x2HyaS1PpSW8 UxgGNH6stryrbsAQnmUWHmmtXxhXWaAh/mh7F2jWGG53eRfQUPZKaLJrA12PwMfBuqI3 adYqcl2G0yMUmCquDOYE0pC1VXQEl8Njtlr2hfqnE0r8pk/Me93T76+7q2ok4XE9X1MB aItdS46eYv0s90g7a+SB2R5ooDZx9/d4WM436+cDKQ1Aa4uxSCueam3BRgg5udKaTf29 PhwtFFRyVH3++WZk+g9PRby/uox2hoCqrliaiRMXoUh01jWsIUvDYWqVSq9KwAZ92kc9 OkUA==
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=MhZ3lJC2KE3Z2gm4aA1P9chY3ZA8zU9gdJVTn8mUU4s=; b=MiCORLN+I63SLcY7Xf4DnvMe2Wmj+2zCZumgeAcil605bG2KjGCWx7ply0RQAGyzsC GGviaQ1ThcIRs2tyL4/BQt5uysbG9zf4jqYmCN7gAvYzyICDsmowGHvSCGL5L/mx8mXm S6N7ExnFPqZb/x8MfL51gg6LH0Ga637/rsbrjZjSnQ68TmcTDYEgeHymTE1YWCeXeAoh ie++JBbop5kndJ7kLQtuHP/vBS5IMoT6mQkEuwaJrFSB5/2DL29+rtfAWwhs7Yc3daYT 6j8SJZsSoGEiO8Qsqd+A1UNbCXvFGxsEZbyMbu+WY2z5Q/UL/KVUXbEyKJZ2d93vcR0W uSyw==
X-Gm-Message-State: AJaThX40ss9udRIc1VF/Nq39kOKzx8ilfc4y7EwAIQ8CZLv0CEf4SpBQ pAIH3M1/nB+LbT6D+uKrNHR74t1R
X-Google-Smtp-Source: AGs4zMZWH6i7vm/z6gHYyb9C15CTrHLPgFLWPoo7v844GgIzXioCWjXcC37zo9XgPjEpvpDEIKt64A==
X-Received: by 10.84.241.15 with SMTP id a15mr41462468pll.103.1511829957949; Mon, 27 Nov 2017 16:45:57 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:c9c7:4c2b:674a:1f86]) by smtp.gmail.com with ESMTPSA id j62sm20791822pgc.35.2017.11.27.16.45.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Nov 2017 16:45:57 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20171128000000.t3jjerammr2usyh3@elstar.local>
Date: Mon, 27 Nov 2017 16:45:47 -0800
Cc: netconf 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 00:46:00 -0000

Juergen,

> On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:
>=20
>> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
>> support features like licensing, and semantic versioning.
>=20
> I do not know what this means. (The goal of the NMDA work is to
> support NMDA - focus is good thing. Perhaps the minutes will some shed
> light on what this AI means but the minutes are not out yet.)

I think there was some confusion around the naming and scope of the =
three =E2=80=9CNMDA=E2=80=9D drafts. The YANG Library draft is named as =
a rfc7895bis draft, while the other two are named nmda-netconf and =
nmda-restconf drafts. In addition, nothing in the abstract and the =
introduction of the rfc7895bis seems to imply that the only focus of the =
draft is NMDA. The other two drafts call that out explicitly.=20

As a -bis draft, questions around what else makes sense. So questions =
around whether YANG Library will support the concept of licensing =
impacting what models are advertised and supported, and whether semantic =
versioning should be part of the YANG Library were raised. Do you =
disagree?

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

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Mon Nov 27 22:29:09 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01BD126DFF for ; Mon, 27 Nov 2017 22:29:07 -0800 (PST)
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 kF1x8_sw3gny for ; Mon, 27 Nov 2017 22:29:05 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FE01273E2 for ; Mon, 27 Nov 2017 22:29:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2927D676; Tue, 28 Nov 2017 07:29:04 +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 UNKy7RpCjgIc; Tue, 28 Nov 2017 07:29:01 +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, 28 Nov 2017 07:29:04 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB89A20121; Tue, 28 Nov 2017 07:29:03 +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 cWuP3TTjhAuX; Tue, 28 Nov 2017 07:29:03 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E376A200CC; Tue, 28 Nov 2017 07:29:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9D1ED41834DC; Tue, 28 Nov 2017 07:27:34 +0100 (CET)
Date: Tue, 28 Nov 2017 07:27:34 +0100
From: Juergen Schoenwaelder 
To: Mahesh Jethanandani 
Cc: netconf 
Message-ID: <20171128062734.d3vofdjmcomvpouo@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Mahesh Jethanandani , netconf 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local> 
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/20170714 (1.8.3)
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 06:29:08 -0000

On Mon, Nov 27, 2017 at 04:45:47PM -0800, Mahesh Jethanandani wrote:
> Juergen,
> 
> > On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder  wrote:
> > 
> > On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:
> > 
> >> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
> >> support features like licensing, and semantic versioning.
> > 
> > I do not know what this means. (The goal of the NMDA work is to
> > support NMDA - focus is good thing. Perhaps the minutes will some shed
> > light on what this AI means but the minutes are not out yet.)
> 
> I think there was some confusion around the naming and scope of the three “NMDA” drafts. The YANG Library draft is named as a rfc7895bis draft, while the other two are named nmda-netconf and nmda-restconf drafts. In addition, nothing in the abstract and the introduction of the rfc7895bis seems to imply that the only focus of the draft is NMDA. The other two drafts call that out explicitly. 
> 
> As a -bis draft, questions around what else makes sense. So questions around whether YANG Library will support the concept of licensing impacting what models are advertised and supported, and whether semantic versioning should be part of the YANG Library were raised. Do you disagree?
>

Seriously? The scope of work is defined by how an I-D is named? The
charter says:

  6. Based on the revised datastore concept work in NETMOD, provide a
     revision for the NETCONF and RESTCONF protocols and the used
     datastore framework.

And there were discussions leading to this charter text.

That said, I have no clue what 'licensing support' means or what
changes are needed to do 'semantic versioning' or even that there is
agreement to do 'semantic versioning'. (I personally believe semantic
versioning requires an new version of YANG since core rules of YANG,
e.g., how the import statement works, are needed.)

If we make the NMDA updates of NC and RC a moving target by putting
other things that come up into the document then we can be sure that
the update takes 3 years. I strongly prefer to scope the updates to
NMDA support with the goal to deliver soon (dec 2017 says the
milestone - but then what do milestones mean in a world where scope is
derived from I-D filenames).

/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 Nov 28 00:38:51 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7225A1270A7 for ; Tue, 28 Nov 2017 00:38:49 -0800 (PST)
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 JIYDC8ej6ykJ for ; Tue, 28 Nov 2017 00:38:48 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5554912421A for ; Tue, 28 Nov 2017 00:38:48 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B54C1AE0336 for ; Tue, 28 Nov 2017 09:38:46 +0100 (CET)
Date: Tue, 28 Nov 2017 09:37:25 +0100 (CET)
Message-Id: <20171128.093725.744666943599041192.mbj@tail-f.com>
To: netconf@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: [Netconf] depth in get-data
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 08:38:49 -0000

Hi,

There are some known issues with  and  that are
identified in Andy's old
draft-bierman-netconf-efficiency-extensions-00.  That draft also
proposes a new operation  which addresses these issues.

The new generic  operation in
draft-ietf-netconf-nmda-netconf actually also addresses some of these
issues.

But there is one importnat thing that still is missing, and that is
the "depth" parameter, which can be used by the client to limit the
amount of data retrieved from a server.

Note that RESTCONF defines the "depth" parameter as well.

So I propose we add a leaf "depth" to the rpc "get-data", with the
same semantics as in RESTCONF:


     leaf depth {
       type union {
         type uint16 {
           range "1..65535";
         }
         type enumeration {
           enum "unbounded";
         }
       }
       default "unbounded";
       description
         "For each node selected by the filter, this parameter
          selects how many conceptual sub-tree levels should be
          returned in the reply.  If the depth is 1, the reply include
          just the selected nodes but no children.  If the depth is
          'unbounded', all descendant nodes are included.";
     }



/martin



From nobody Tue Nov 28 01:35:52 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0251205F1 for ; Tue, 28 Nov 2017 01:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dGDwp4AbTqK7 for ; Tue, 28 Nov 2017 01:35:45 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1753312421A for ; Tue, 28 Nov 2017 01:35:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1605; q=dns/txt; s=iport; t=1511861745; x=1513071345; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tCRIWvY7FOTRkCq03cNqZO5lPBquvWYCSxDcIEI/agA=; b=GiofZi7D4wV2YqGZQulQuGYqNYXHmDTnMJGaEkrrbBGJnuvH/dWifm6G IEFsfzKxdMOoQlCMTgDtSWKwE0HXi1l8H2gVJjr5rzbyKCA845ZWgrUY7 D0cPCw2F1X5L672M8nbuVjPF7XX8t+TnTqjDw7328gDOC4McBOlyH5ZgT U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQB7LB1a/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQibieDf4sUkB2WboIRChgLhElPAoU9FgEBAQEBAQEBAWsohSA?= =?us-ascii?q?BAQEDAQEhFTYbCw4KAgImAgInMAYBDAYCAQGKHhCnaYIninwBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGgWBD4Irg1yCEoMChHYQgyuCYwWiSZUMjAaHSY5Gh3mBOiYHK4F?= =?us-ascii?q?QMhoIGxU5gimEVUE2h1aCRgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,467,1505779200";  d="scan'208";a="524940"
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; 28 Nov 2017 09:35:43 +0000
Received: from [10.63.23.82] (dhcp-ensft1-uk-vla370-10-63-23-82.cisco.com [10.63.23.82]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAS9ZgVT025867; Tue, 28 Nov 2017 09:35:43 GMT
To: Martin Bjorklund , netconf@ietf.org
References: <20171128.093725.744666943599041192.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 28 Nov 2017 09:35:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171128.093725.744666943599041192.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Netconf] depth in get-data
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 09:35:51 -0000

Yes, OK.

Rob


On 28/11/2017 08:37, Martin Bjorklund wrote:
> Hi,
>
> There are some known issues with  and  that are
> identified in Andy's old
> draft-bierman-netconf-efficiency-extensions-00.  That draft also
> proposes a new operation  which addresses these issues.
>
> The new generic  operation in
> draft-ietf-netconf-nmda-netconf actually also addresses some of these
> issues.
>
> But there is one importnat thing that still is missing, and that is
> the "depth" parameter, which can be used by the client to limit the
> amount of data retrieved from a server.
>
> Note that RESTCONF defines the "depth" parameter as well.
>
> So I propose we add a leaf "depth" to the rpc "get-data", with the
> same semantics as in RESTCONF:
>
>
>       leaf depth {
>         type union {
>           type uint16 {
>             range "1..65535";
>           }
>           type enumeration {
>             enum "unbounded";
>           }
>         }
>         default "unbounded";
>         description
>           "For each node selected by the filter, this parameter
>            selects how many conceptual sub-tree levels should be
>            returned in the reply.  If the depth is 1, the reply include
>            just the selected nodes but no children.  If the depth is
>            'unbounded', all descendant nodes are included.";
>       }
>
>
>
> /martin
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> .
>


From nobody Tue Nov 28 01:39:01 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D53D1277BB for ; Tue, 28 Nov 2017 01:39:00 -0800 (PST)
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 ZhlzzCwTTD5C for ; Tue, 28 Nov 2017 01:38:58 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1FB512421A for ; Tue, 28 Nov 2017 01:38:57 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CE5B11AE0336 for ; Tue, 28 Nov 2017 10:38:56 +0100 (CET)
Date: Tue, 28 Nov 2017 10:37:35 +0100 (CET)
Message-Id: <20171128.103735.1654378548309425095.mbj@tail-f.com>
To: netconf@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: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 09:39:00 -0000

Hi,


I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
somewhat more important comment, and several others.

Important issue:

o  3.10

  I don't think the proposed YANG extension is the correct solution to
  the stated problem, for several reasons:

    1.  In most cases, this is not a property of the data model, but
        of the implementation, and possibly even the deployment.  So
        having a YANG extension statement is not a good solution.

    2.  With NDMA, the same schema node is present in different
        datastores.  It might be the case that an implementation
        supports on-change for the node in a configuration datastore,
        but not in operational.  Again, marking a node in the schema
        is not a good solution.

    3.  Since the on-change property is implementation dependent, it
        means the information will be available to clients only in
        deviation modules.  This is quite an expensive and complicated
        way to pass the information to the clients.


  An alternative solution could be to have an ordered list of
  instance-identifiers that list this property, per datastore, for
  example:

   
     /sys:system/sys:system-time
     false
   
   
     /sys:system
     true
   

  Yet another alternative would be to leave this to future work.


Other comments:


o  2

  The document uses the term "YANG datastore" (it is even in the title
  of the document).  This term is not used elsewhere, and it is not
  defined in this document.  I suggest you change this to simply
  "datastore".

  Also, I think you should "import" the term "datastore" from
  draft-ietf-netmod-revised-datastores, instead of having a slightly
  different term in this document.

  It is also unfortunate that you use the term "data node" in a
  different meaning than RFC 7950.  Maybe use "datastore node"
  instead?


o  3.1

  I'm not sure I understand the dampening period concept.  Let's
  assume that the dampening period is 10s.  Then changes happen at
  times:

    2  3  4  11  13  14  15

  From the description, it seems I would receive 4 notifications, from
  times:

    2  (containing only change from 2)
    12 (containing change from 3,4,11)
    13 (containing only change from 13)
    23 (containing changes from 14,15)

  Is this correct?

  In any case, I suggest the description in the YANG module is
  clarified - currently the RFC text contains more details than the
  YANG module.


o  3.2

  The text says:

     Therefore, in order to minimize the number of subscription
     iterations between subscriber and publisher, dynamic
     subscriptions SHOULD support a simple negotiation between
     subscribers and publishers for subscription parameters.

  To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
  specified in this draft does indeed support simple "negotiation".
  Maybe s/SHOULD support/supports/ ?


o  3.4

  The text says:

    Please see [promise] for
    more on the transactional basis underlying the publisher and
    subscriber interactions within this document.

  So I did that.  But I didn't find any text in the referenced
  document that talked about "the transactional basis".

  I suggest you remove this sentence from the draft.


o  3.5

  The text says:

     A publisher MUST support XML encoding and MAY support other
     encodings such as JSON encoding.

  I don't think this is correct.  A RESTCONF sever is not required to
  support XML.  I think you should remove this sentence.


o  3.5.1

     In a periodic subscription, the data included as part of an update
     corresponds to data that could have been simply retrieved using a get
     operation and is encoded in the same way.

  What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
   or something else?  Whatabout other protocols?

  (In 3.6, you use simply "a GET" for probably the same thing.)


o  3.6

     Subscription policy specifies both the selection filters and the
     datastores against which these selection filters will be applied.
     The result is the push of information necessary to remotely maintain
     an extract of the publisher's datastore.

  It seems this paragraph defines the term "Subscription policy".  But
  this term is not used in the document.  What does it means that the
  result of a policy is "the push of information"?

  I think I don't understand what this paragraph tries to tell me.


o  3.6

     o  xpath: An xpath selection filter is an XPath expression which may
        be meaningfully applied to a datastore.

   What does "meaningfully applied" mean?


o  3.6

     Selection filters are not intended to be used to filter objects
     based on a non-key property.  Supporting non-key property
     filtering so would have a number of implications that would
     result in significant complexity.

     [...]

     the goal is to
     provide equivalent capabilities to what is available with a GET.

  In GET you can filter on "non-key properties".

  I think you should remove the text about "non-key properties".  If
  anything, I think you can allow an implementation to reject a filter
  that would be too complex to implement / evaluate (in fact I think
  the text already allows a server to reject such filters.)

  With the current text, is this filter ok:

     /interfaces/interface[contains(name, "eth")]

  It filters on a key, so it should be ok, right?


o  3.7

  The XML examples are not using the correct XML namespace for the
  nodes from the "ietf-interface" module.

  The YANG Patch example also shows an interesting effect in the
  "patch-id" and "edit-id" leafs.  I think the draft should mention
  how implementations are suppose to fill in these leafs.


  The "target" leaf is not specified correctly.  It should be:

         /ietf-interfaces:interfaces-state


o  3.8

  The example has:

   
      
        

  This doesn't match the YANG model; there is no container called
  "datastore" in the model.

  Further is has:

        

  a subtree-filter of type xpath?  I think ot should be:

        
           /ex:foo
        

  Also, it has:

        
          operational
        

  which should be:

        
          ds:operational
        


o  3.9

  This section lists three cases for which:

     the error identity "data-unavailable" SHOULD be returned.

  One of the cases is:

    o  the authorization privileges of a receiver change over the course
       of the subscription.

  But how can a server know this when "establish-subscription" is sent?


o  3.9

     The contextual authorization model for data in YANG datastores is
     the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.

  Did you mean s/contextual/conceptual/ ?


o  3.11.1


  OLD:

       If
       this is not possible and the synch-on-start option is configured,

  NEW:

       If
       this is not possible and the "no-synch-on-start" option is not
       present for the subscription.


  (fixes incorrect name of leaf, and also covers dynamic
  subscriptions)


o  4.3.2

     A subscription-id MUST be transported along with the subscribed
     contents.

  Then the leaf "subscription-id" should be mandatory.


     A "time-of-update" which represents the time an update record
     snapshot was generated.  A receiver MAY assume that a publisher's
     objects have these pushed values at this point in time.

  Should "time-of-update" be mandatory?

  How is "time-of-update" different from "eventTime" in the
  notification?


o  4.3.2

     If the application detects an informational discontinuity

  What is an "informational discontinuity"?


o  4.4.1 / 4.4.2

  The XML examples are broken; compare with my comments for 3.8.


o  5

  OLD:

    "This module contains conceptual YANG specifications
     for YANG push.";

  NEW:

    "This module contains YANG specifications for YANG push.";

o  5 - identities

    identity qos-unsupported {
      base sn:error;
      description
        "Subscription QoS parameters not supported on this platform.";
    }

  This identity is not mentioned anywhere in the text.  Instead of
  having this identity, wouldn't it be better to define a feature for
  "qos", and mark the nodes you have in mind with an if-feature?


    identity on-change-unsupported {
      base sn:error;
      description
        "On-change not supported.";
    }

  When will this identity be used?  There is already a feature
  "on-change" and corresponding if-feature statements.

    identity on-change-synch-unsupported {
      base sn:error;
      description
        "On-change synch-on-start and resynchonization not supported.";
    }

  The leaf is called "no-sync-on-start", which implies that sync on
  start is the default.  So when will this identity be used?


    identity reference-mismatch {
     base sn:error;
      description
       "Mismatch in filter key and referenced yang subtree.";
    }

  I don't understand the description of this identity.  Please
  clarify.


     identity datatree-size {

  Should it be "result-too-big" or something?


    identity no-such-datastore {

  I think this one should be removed.  The normal "invalid-value"
  error-tag covers this error.


      identity custom-datastore {
        base ds:datastore;
        description
          "A datastore with boundaries not defined within
           draft-ietf-netmod-revised-datastores";
      }

  This identity needs to be removed.  If someone defines a custom
  datastore, it would get a specific identity, and that identity can
  be used as "source".


o  5 - "change-type"

  The descriptions of the enums need to be improved.  This is about
  reporting a change in a datastore.  The value "create" is described
  as:

        description
          "Create a new data resource if it does not already exist.  If
          it already exists, replace.";

  Also, the description of the typedef has:

      "RFC 8072 section 2.5, with a delta that it is ok to receive
      ability create on an existing node, or receive a delete on a
      missing node.";

  But what does this mean?  The type is used to *exclude* some changes
  from a yang patch record.


o  5 - selection filter

  The XPath expression is not properly defined.

  OLD:

          "This parameter contains an XPath expression identifying the
          portions of the target datastore to retrieve.";

  NEW:

          "This parameter contains an XPath expression identifying the
           portions of the target datastore to retrieve.

           If the expression returns a node-set, all nodes in the
           node-set are selected by the filter.  Otherwise, if the
           expression does not return a node-set, the filter
           doesn't select any nodes.

           FIXME: (*)

           The expression is evaluated in the following XPath context:

             o  The set of namespace declarations are those in scope on
                the 'xpath-filter' leaf element.

             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 root node of the target
                datastore.


  (*) - We need to describe when the filter is evaluated.  This is
  also true for the subtree filter.  Is it evaluated when the
  subscription is started and explicitly modified, or everytime a
  change is detected?

  [Side note: this description is also missing from the "xpath-filter"
  leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
  updated the description in that draft.]


o  5 - terminology

  The term "agent" is used a couple of times.  Use "publisher" or
  "server" instead.


o  5 - dampening

          leaf dampening-period {
            type yang:timeticks;
            mandatory true;

   Should this instead be:

          leaf dampening-period {
            type yang:timeticks;
            default "0";

   So that the request is the same if the "on-change" feature is
   support or not.


o  5 - no-synch-on-start

             When
             present, pushing a full selection per the terms of the
             selection filter MAY NOT be done for this subscription.

   Did you mean s/MAY NOT/MUST NOT/ ?

   MAY NOT is not a 2119 term.


o  5 - QoS

  Why are the qos parameters defined in yang push, and not in
  subscribed notifications?  It seems that they are generic.


o  5 - establish-subscription params

  I think a "when" expression should be added to the first augment:

    augment "/sn:establish-subscription/sn:input" {
      when "sn:target/yp:datastore/yp:source";


o  5 - push-update

  What does the presence of "updates-not-sent" mean in "push-update"?
  "push-update" contains a snapshot, not a diff, so why is
  "updates-not-sent" present?


o  5 - push-change-update

        "This contains an incremental set of datastore changes needed
         to update a remote datastore starting at the time of the
         previous update, per the terms of the subscription.

   What is an "incremental set"?  Probably s/incremental set/set/



o  General

  Use double quotes for node names.  "push-update", "subscription-id"
  etc.  Quotes are currently used inconsistently, and it makes the
  text harder to read.




/martin


From nobody Tue Nov 28 02:15:21 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1B1277BB; Tue, 28 Nov 2017 02:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 SLao7Vk6kwVi; Tue, 28 Nov 2017 02:15:16 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00098.outbound.protection.outlook.com [40.107.0.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9C6124D85; Tue, 28 Nov 2017 02:15:15 -0800 (PST)
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; bh=ocvVc8RxbM8b0Wrnm3X7BmT2qCP3PTlY5s83WDzghy4=; b=IdE/9FbD9Dw4PYxT66YV9nyHP5oCxNJU9t4zUCzbKSyqUD5Ud2uA6qi5K4NCOIdGRUI9PfdXIVqepjA2dqRv/hLASCBxutWU5WRSPytoWf7XQulJxxLg59++4lDkVUs41pidhGDVuZYzvThVqlFdy7SMQgwFFtIxzpaOCZnJ5VM=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Tue, 28 Nov 2017 10:15:12 +0000
Message-ID: <013701d36831$4d4db1e0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Andy Bierman" , "NETCONF" , "Robert Wilton" 
Cc: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>  
Date: Tue, 28 Nov 2017 10:10:59 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: CWXP265CA0050.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2c::14) To HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9417fea8-9e8a-47cd-15e6-08d53648e9ab
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603199); SRVR:HE1PR0701MB3004; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 3:NhvPpSqbThMavmJ6TF8yLgDPV1E+F1rh9e8LaADQuGbsJlE5c3N8TLH2jnZwB3jIWbfzPLm8lreUmglakYmIxBnFSORVmwtfqE/kCmvCl/ipd3aoqYl84O9Xkhbu0kuVYFwamSXvo8kouDKyuAGTfFRlRdfWLLMLDtj0S9XibaAbTXwajjmFJAGvKM1i11m6tVIHm24OA8MZyz3elk5Z5BygauxWAr82KixytKZiXKC9Sl9rEp7Lx0Cny37kocN8BYbuUjSJ1JXZ5DBr6vRUj2xvp9AWcBiovQVfH5q8z9I=; 25:mEJkcFTWpZrez/hcGPPMtC5Cp7nqKeLhqAwqJTgtQQMLG/l5G7jiig5dV1C+SZL22SZom4X7eUKZVBZGpVkCav/Q5VVblfDSsuZq2Ax8FuceR0r7llRVO/qa8jZwe4xq6C4O3oPj1opOE8o9QvpKJ6dcfYQF7WU6vXNutvJgLxuOg4GMgrJEZ0g5VqWCXl8O+fSC2Ss8ytkO2m9BAhWvjkNkk8L5XQ6OWjvGfMn8VkYw54ul2P3Egv/uyd7yeRPiks8vHwnMWmZRgu13Q+ek7MingHlFEqY2riXTgpau2j8R3hzYEp9zMlvoInpxZD8kmvtquuUQ554KdAUnOhXR1w==; 31:O5XGEJBpweAksc/0jHNOZmWS0Pv7dkFQAJrAY+IBTyi9TMl6JC14Pe1GFK4Ag19BeVame2ONWa3H21sojsYAyrZoHHjHV4AhdvEFUZlq4VWx+lvSIG14KgGLWtfEoLxMHGeijEaHa7X8oChc7jECPMEmon9VEPuxVhtcmnMAcumtF11mnu8phzx9zqATIQMdylkM3gIzeRoztMTB3GWYUZ6R6w6sGgU66Gmsw7epu9E=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3004:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(158342451672863)(192374486261705)(95692535739014); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231022)(10201501046)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB3004; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 4:I4cIev/vxUKZWEq/FAgKmLmSreUKisKdE/E+rUgHatxGfqpBKitm7GUxQEHzOlvh7gvjDPqjMwGH2CrFbuAV0LxbZFf7NykBoBaeCdcK7uFKgEtr/PunlRDKB9WTEbJVA/m9PWPz5wyHr1kBiR1i68cpThKXSexK4z5yxVdq9X2bUSUhs0Z7VF0SehNDnW3tO6DaJSlA8SphSr24ojYPGVPZlmhoBulZikgF7Gr4lS9uceBZlTHVfCjlPZN5TvNV4qcKZvWFTCy8UYOed6pnqbk5OIuSi2rzg9YsgALl0XkxFhppH4xMrECNi5AJ+p6iyz/5heC+UvYRyO1GEnx8cjkGLWnc+1w3FIJ0IKatcEsS0jV8Ozrp1dED+IeZLS/LNcOlb+JkXY/U23h30aByLt+aVo6qh5UoFcMisqN72CU=
X-Forefront-PRVS: 0505147DDB
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(346002)(39860400002)(376002)(199003)(189002)(24454002)(51444003)(13464003)(9686003)(5660300001)(50226002)(53936002)(25786009)(16526018)(229853002)(6666003)(4720700003)(53546010)(1456003)(6486002)(44736005)(81816999)(81686999)(50986999)(76176999)(23676004)(2486003)(52116002)(106356001)(97736004)(189998001)(68736007)(84392002)(5890100001)(33646002)(101416001)(305945005)(6496006)(2906002)(7736002)(61296003)(105586002)(44716002)(3846002)(6116002)(66066001)(8676002)(62236002)(47776003)(81156014)(110136005)(316002)(14496001)(93886005)(81166006)(230700001)(230783001)(116806002)(8936002)(50466002)(6246003)(4326008)(478600001)(86362001)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDQ7MjM6ZGsxSXpxVmJ0eHhnNXJWUHE2UjlHYUxS?= =?utf-8?B?MTU2bVltRkI5am1ha0Rtc09Sb2MycXM4aCtrcUhYZWpneEprd1pCUGVjYllW?= =?utf-8?B?WEZRL3ErUjRZdVdDWlY3dWtmYVMwak04YTBjOWNjMWI3S2VVU20ySGFyeXEw?= =?utf-8?B?SUFJaFhWREhicVRsVnB5TVdzN0wrVWpZVUIxYVJiZ09iWU53WmVlTVBsRUw4?= =?utf-8?B?RHlXdDFpcW1TbWx5SGV5b2ZwaUFzQ0lNTTRmNkg1THpwSjE5QzBRaE9HRjhD?= =?utf-8?B?TDhOcnVRK0lvakNHMGQydTc2bjBpcmdPMFhleDZac25rQzAyenNQL0lDOWJW?= =?utf-8?B?S25pSFcrbnVYaUVQbUlUdWY3VGxza2RmampxTUNYU0duOXBJVHMrNFhwbXc4?= =?utf-8?B?VUlPZERxdFFRY05PUlNhR3JNQXM0bzRjUmdOc3pvb2QrcEp5MXdwZ0U0NzB6?= =?utf-8?B?SWZUZGwydDd5VnMzSytyYyt6QVFnZHhza3RsUnZkVzJiYmx3THhVKzNWckls?= =?utf-8?B?TE1OeHFMSnRVejdXTm84aHhSRTVGOThWNHZ2T0VxRXJTS2hKb3NPN04vVllF?= =?utf-8?B?LzdudjVwdzFrY1NZUEtnZTB1TUlxUW8xWTJNQlBQVjc5d2s2VWpmWU53WlFE?= =?utf-8?B?RktrZkpjcmZzaThOTjRic2t2bkFWYUZoalRoZldoRmFRblo4NnpiQ2NxdGpY?= =?utf-8?B?bE91ZUZYYUNhUkpGZjRrUXNVcHRWZjVkTFlBRTZBYmZ4emdTcHRmMUl1MHpm?= =?utf-8?B?VGg1VHRqZk1KcFEycW1sQk8zQWJLeTBJMjh2M0Z5MEozVzJLNzBscThmbkpx?= =?utf-8?B?MkRPN2RmdmZwUG5xSzJ5cTBCQVE4QTk4L2JXTjVnYkp2MVhPMW50Uko3ZndQ?= =?utf-8?B?ODdkcXVSQ0pINGx1SGxXRGRIZy91N3VweXZhT1JjMVhOSlN3SmYzR0NmTGlq?= =?utf-8?B?aERJUFh0eDZRbFVyZ3VJbk5SMDJUTEFXN29lUC9OQTNQV2JxdjVNZlFjZVg3?= =?utf-8?B?Ly9xWjBiVi9URy91a2FqVEJXbjRPMHYrRk9jKzAyeDEwSGdmVnRtVDJnaFdX?= =?utf-8?B?dmxQL3l4SU5WRlFnVXk5TjROUHBBcHc2MVBCcG9LN2phRWpQMkdrQWErR3ZI?= =?utf-8?B?L0ZmcXdnN0N2d1dUa2Q3VzU5RlZnYzZVSnlackJBSDYwUjc4YXVzQTl4cWhu?= =?utf-8?B?MDBZNkxRVUI3Q1NLUUdoYStCMEtSdXBSb2xuTGZ6L3JYRU0rd2lKRktJV0N1?= =?utf-8?B?a2MwZ0ROVjd4dDAvVHZrb1k4OCt3WWNReTUzVytGT0RjeWwvY0puZ210ZWNv?= =?utf-8?B?MW1zTjlxQ1EyQ3FkaTd2UjhFUGxRcldVSHFYeGxZK1YxNEQ3MU1nMjRjd0ZZ?= =?utf-8?B?ME5JZzRKSG9WMFM2YzZmUkg4bDdhUXlFQkxiWWJtWU83SUtHcVVoaGpRRWhN?= =?utf-8?B?eTZXdzhTeEdFOU54RVRtMitnOUhWT0lteWxoL3JLUExOQlRYTDZiQzNkMmRP?= =?utf-8?B?L1FTdlZKQ0ZXTEdEeVdnNnZXdHlXRU90VUtwRlFtRWpLa2p4cnZhUHR4aHpU?= =?utf-8?B?bExYK0VDMXJac1haOGJxR24vL3pYZ3JXWnh6Vjc2Nk9EQ3ZuRW5COTQ5Yjlp?= =?utf-8?B?THYzZ0h3eXM3cDNvZFFYR3ZIQlY3Z3VNSlREdGNFYUxQQnkwZEZkb2U3bk4z?= =?utf-8?B?ZjlQbnJUSFVSM3dnK0NvUm5qOHY2ZCs5ckwvUVFBNzgwM2tUckxFaThGR1Z2?= =?utf-8?B?SUtNUmI3NVl6SFJpWmtsQ2V3OXphLzd3NU04YTZQNm1BK0YrZkJibmNaaEZq?= =?utf-8?B?Z2I1cWxqVG81WmZidkRSdWZGR1ZmNkpsQmg5Wjl2bEJEbjhPVFpybFJPWnpm?= =?utf-8?B?c0ZGTllqVVBFSzZEb2hxZHJwZVN3bTNrdjByZ2pTcm5aZ2txWkpQRWNkVkdI?= =?utf-8?B?TkNxckRkYVdoOTBTTWdCdDJmdmdGYWxVZEVJanVpSmFmZzd0RncxS0dtdTJm?= =?utf-8?B?UDgyWFhsUWx5RDBpR2NleUJSUmxFeWNUb3JZR1JEN2piZzh4UHVvVElTVXJR?= =?utf-8?B?TlNlRHAzT1o0V2F0WGd2c1ZiZXN3UHlweldJclFjNDRGUXZnZjN5a0tudnlP?= =?utf-8?Q?tCjG9/9qezqtl1netvDmX0hgI=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:RojEtrbCPaJeuOugOnh2JxzsqpQ1L+BMExQWzpKjG166p8uNJwqNnKKJV4O05QJmfd/kzr0eMoJX8JgjL8u9WmTS9zi6vG7nOqGWf62cP1M2665LFE2rl8dqGG2mErQrDDHD+VLbJbH8NGnT/XPXdR3aXLW6ruw9q2ExREBUlD27nOIcYXZYUj6ZcWKpZYwwamWQ9vr9sEhix/0TJROhvi6lo9Up7KTzEQ/jD+Jm3mv9Jhso7Z2/+ZuQDN3b7vykwdEesbmdedJ/kKiOwkYegGWdcmMgx5v03d115PkeWj5YZ5EFJuKwihHfO7oQHzPIo+ARXcsFWREqtQKlBxMk65xaAK8/TIqLv0UM49kjppI=; 5:BhJJfdR4yMAlBHaAmFFinZQ7TpRrBiUkuYxJJKC8HJ1rmRYk9p/eZDQgYSHWKo/Obu9Vj77sqr2/+HICQgr/NeLP2h0Xn8B6aZ8C/+uyUK/PMhFxw6dOCtmX9qRCHe3sFh/QwHwfsR9uWwPbw0dgvVdZp/aTvwalmmjoleQfUzg=; 24:WttRMf7PTKp6/JCGnSJi6rTS7ATb48G4QFj+e5oOZURiDa8XOyHDsBBe2ac7bTAfct/2+QfbBgx7ozWgWg8zujbOwOqcG10MJlyPXKhBdFQ=; 7:w8Qhsu6v9OiBC/8PKlSeV3TOumZovEmQUNCw2ZmiCesy5qdscFck1iEvO0d/60tD4+ZJ1FUgMKySTLpShZEymMOYtoPK815Rq/tK3WHsZdPqU/O+Gi/hIhdwRnBTctDysqvbB8RqzBuRu/J4CqyM7Gyhq1pFvKDiNm6dO9Fx5/3p0tED8v6W9DlJ15itBsG9n///I8YikwcO+50ONiLGl6dB5aiYCXfblqkG9FBXloJbwbA/dkURHL5H9kPw5FMF
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 10:15:12.3016 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9417fea8-9e8a-47cd-15e6-08d53648e9ab
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004
Archived-At: 
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 10:15:19 -0000

----- Original Message -----
From: "Robert Wilton" 
Sent: Monday, November 27, 2017 10:39 AM


> I do get the point that Tom is making here, and have quite a lot of
> sympathy for it. E.g. by automatically allowing the side effects of
> when/choice statements then we are introducing a potential security
hole
> here that operators may find hard to be aware of and mitigate.
>
> It also seems odd to me that a client is allowed to implicitly remove
> some configuration through the side effect of a when/choice statement
> that they are not allowed to delete explicitly.
>
> The alternative of requiring appropriate access for the side-effects,
> seems like an intuitively safer design, but I also get Andy's concern
> that security isn't useful if it become so unwieldy that nobody uses
it.
>
> So, I guess the question here is, do we have some concrete examples
> using real data models where the extra NACM delete rules would be
> required? If not then perhaps requiring the explicit access for side
> effects would be better.

Robert

This is what I was obliquely referring to when I said

" And I
don't know how much 'when' is used in that way in existing YANG
modules - uh huh, more reading required.
"

I did start looking and found that many, if not most, 'when' statements
relate to 'augment', e.g. for a specific interface type, and so are
simpler than the case postulated which can cause an implicit delete (I
have yet to see one such in an actual YANG module).

Then I started wondering what the NACM rules would be like if I wanted
to permit changes to LAN interfaces but not to WAN interfaces, both
specified by 'augment' to the base model.

Then I started wondering if a NACM rule that permitted changes to a LAN
interface would be valid on a server with no LAN interfaces specified.;
and would that change if a LAN card is hot plugged and auto-configured.

Um, more reading required.

As Andy says, NACM needs to be simple else it will not be used.  The
concept is simple - permit LAN, deny WAN - but the NACM rules I am less
clear about.

Tom Petch

>
> Thanks,
> Rob
>
>
> On 25/11/2017 15:53, Andy Bierman wrote:
> >
> >
> > On Sat, Nov 25, 2017 at 4:42 AM, t.petch  > > wrote:
> >
> >     ----- Original Message -----
> >     From: "Andy Bierman" >
> >     To: "t.petch" >
> >
> >
> >     > On Fri, Nov 24, 2017 at 3:02 AM, t.petch  >     > wrote:
> >     >
> >     > > 
> >     > >
> >     > > Tom Petch
> >     > >
> >     > > ----- Original Message -----
> >     > > From: "Robert Wilton"  >     >
> >     > > Sent: Thursday, November 23, 2017 10:44 AM
> >     > >
> >     > > > Hi Andy,
> >     > > >
> >     > > > On 22/11/2017 18:09, Andy Bierman wrote:
> >     > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> >     > > > >
> >     > > > > Hi Rob,
> >     > > > >
> >     > > > > At that points in time, if it clarifies the spec. and
the
> >     > > authors
> >     > > > > agree with this, let's do the right thing.
> >     > > > >
> >     > > > > I will add the new text if that is what the WG wants.
> >     > >
> >     > > > Having read this draft, I was undecided what the intended
> >     behavior
> >     > > > actually should be.
> >     > > >
> >     > > > The way that Yumapro and Tail-f have implemented this is
> >     reasonable,
> >     > > and
> >     > > > is probably also the way that I would implemented it.
> >     > > >
> >     > > > But I also think that it would be a reasonable
> >     implementation for
> >     a
> >     > > > server to calculate the full change set (taking account of
side
> >     > > effects
> >     > > > from when and choice statements) to the datastore before
> >     checking
> >     the
> >     > > > "write data node access control" against the resultant
> >     change set.
> >     > > >
> >     > > > My interpretation is that the RFC text is ambiguous on
what the
> >     > > correct
> >     > > > behavior is, and one could make a reasonable argument that
the
> >     current
> >     > > > RFC actually specifies that the alternative behavior is
correct,
> >     i.e.
> >     > > > requiring delete access even if a node is implicitly
changes
> >     as a
> >     side
> >     > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> >     > > >
> >     > > > If the protocol operation would result in the deletion of
a
> >     > > datastore
> >     > > > node and the user does not have "delete" access
> >     permission for
> >     > > that
> >     > > > node, the protocol operation is rejected with an
> >     "access-denied"
> >     > > > error.
> >     > >
> >     > > Rob
> >     > >
> >     > > I have been reading that paragraph since this thread started
and
> >     > > wondering how it could be thought unclear, what am I
missing:-)
> >     > >
> >     > > To me it clearly states that the user must have the
appropriate
> >     access
> >     > > for the consequences of whatever they do, be that 'when',
'choice'
> >     or
> >     > > anything else! Indeed, I see exactly that behaviour in
operational
> >     > > (non-network) databases of which I am a user with limited
> >     privileges.
> >     > >
> >     > >
> >     >
> >     > This is not correct.
> >     > The server is the entity that is cleaning up false when-stmt
or
> >     unselected
> >     > cases
> >     > for a choice-stmt.
> >     >
> >     > NACM does not prevent the sever from making any changes to the
> >     system.
> >     > It only affects the operations requested by a client.
> >
> >     Andy
> >
> >     My model is slightly different, that the server is a black box,
> >     with an
> >     interface through which I can make authorised changes. If
something I
> >     do causes the deletion of something I am not allowed to delete,
may be
> >     not even to read, well, we part company on the acceptability of
that!
> >
> >     I do accept, as Randy points out, that the situation is
> >     complicated. I
> >     am reminded of the issues that came up relating to the 'when'
> >     statement
> >     when preparing YANG 1.1. Yes, 'when' makes things possible and
is
> >     very
> >     useful but at the same time, its side effects can be
troublesome. I
> >     would like to wrap it up in a conceptual bubble so you could not
have
> >     the sort of fine-grained access control that allows the case
that Rob
> >     postulates to occur but have no idea what that might look like.
And I
> >     don't know how much 'when' is used in that way in existing YANG
> >     modules - uh huh, more reading required.
> >
> >
> >
> > When the access control is too complicated, it does not get used.
> > Instead, the most likely access control is "everybody is the root
user".
> > The server pruning of false when/choice data nodes is considered
cleanup.
> > The pruned data is no longer relevant to the data model. This is the
> > indended
> > use, but when-stmt can easily be abused.
> >
> > The complex tangled web of dependencies is no worse
> > than it has been with CLI for 30 years, where every dependency is
ad-hoc
> > and probably undocumented. The granularity of CLI-based access
control
> > is less granular than NACM.
> >
> > It is possible that vendors and operators are willing to spend hours
> > and days
> > figuring out how to tune the NACM rules to allow a specific edit to
work.
> > Of course the operator will not even be told by the server which
nodes
> > are blocking the edit. That would be a security risk.
> >
> > IMO NACM will be completely unusable if rules are needed to allow
> > server cleanup of dead nodes. The additional NACM rules required
> > might provide more access than intended (unless lots of delete-only
> > rules are added). The huge jump in NACM rule management complexity
is
> > a new security vulnerability, which might even be worse than the
> > vulnerability it is intended to fix.
> >
> >
> >
> >     Tom Petch
> >
> >     >
> >     > Andy
> >     >
> >
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> >     > > My other thought was that given all the complexities of
'when'
> >     that
> >     > > emerged during the specification of YANG 1.1, perhaps, were
I an
> >     > > implementor of this, I would take the easy option and ignore
the
> >     side
> >     > > effects of 'when'; but I might feel guilty about doing so.
> >     > >
> >     > > If the new paragraphs go in as proposed, then I think that
the two
> >     > > paragraphs you quote need changing else that section looks
to me
> >     like an
> >     > > oxymoron.
> >     > >
> >     > > Tom Petch
> >     > >
> >     > > > An  request that causes a when constraint to
evaluate
> >     > > > differently does result in a deletion of those data nodes
> >     from the
> >     > > > datastore, and hence according to the text above, requires
> >     explicit
> >     > > > "delete" access permission to accomplish that.
> >     > > >
> >     > > > Clearly it would be an interop issue if different servers
> >     implemented
> >     > > > the NACM path based filtering differently.
> >     > > >
> >     > > > Hence why I think that it would be prudent for the draft
to be
> >     more
> >     > > > explicit on when and choice statement handling.
> >     > > >
> >     > > > Rob
> >     > > >
> >     > > > > There have not been any comments on this issue.
> >     > > > >
> >     > > > > Andy
> >     > > > >
> >     > > > > Regards, Benoit.
> >     > > > >>
> >     > > > >> Hi Benoit,
> >     > > > >>
> >     > > > >> There is also one further, unrelated change that I am
> >     proposing
> >     > > > >> is made the draft before it is published, to help
better
> >     > > clarify
> >     > > > >> the expected behavior. It isn't the end of the world if
> >     this
> >     > > > >> doesn't go in, but I think that it prevents sometime
> >     taking
> >     a
> >     > > > >> different, but IMO reasonable, interpretation of how
> >     "when"
> >     > > > >> statements are considered, and then having a future
> >     argument
> >     > > > >> about what behavior it specified in the standard.
> >     > > > >>
> >     > > > >> If we clarify it now, then it closes that door :-)
> >     > > > >>
> >     > > > >> I've proposed text to Andy and Martin on Monday, but
I've
> >     not
> >     > > > >> heard back yet.
> >     > > > >>
> >     > > > >> Netconf email with proposed text attached. The text
> >     doesn't
> >     > > > >> necessarily have to match this, but personally I
> >     think that
> >     it
> >     > > is
> >     > > > >> useful if the draft says something on this.
> >     > > > >>
> >     > > > >> Thanks,
> >     > > > >> Rob
> >     > > > >>
> >     > > > >>
> >     > > > >> On 22/11/2017 13:25, Benoit Claise wrote:
> >     > > > >>> On 11/10/2017 7:23 PM, Andy Bierman wrote:
> >     > > > >>>> Hi,
> >     > > > >>>>
> >     > > > >>>> Here are some proposed edits to make the data rule
> >     consistent
> >     > > > >>>> with the examples.
> >     > > > >>>> Note that this issue is not related to the edit in
the
> >     > > original
> >     > > > >>>> 1-week change.
> >     > > > >>> That's right, but we found a source of
misinterpretation
> >     in
> >     > > the
> >     > > > >>> draft and you have rightly corrected it in the
> >     github v9.
> >     > > > >>>
> >     > > > >>> Regards, Benoit
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> sec. 3.3.5:
> >     > > > >>>>
> >     > > > >>>> OLD:
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> data node rule: controls access for a specific data
> >     > > > >>>> node, identified
> >     > > > >>>> by its path location within the conceptual XML
document
> >     > > > >>>> for the
> >     > > > >>>> data node.
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> NEW:
> >     > > > >>>>
> >     > > > >>>> data node rule: controls access for a specific data
> >     node
> >     > > > >>>> and its descendants,
> >     > > > >>>> identified by its path location within the
> >     conceptual XML
> >     > > > >>>> document for the
> >     > > > >>>> data node.
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> sec 3.4.5, step 6, bullet 2:
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> OLD:
> >     > > > >>>>
> >     > > > >>>> * The rule does not have a "rule-type" defined or the
> >     > > > >>>> "rule-
> >     > > > >>>> type" is "data-node" and the "path" matches the
> >     > > > >>>> requested
> >     > > > >>>> data node, action node, or notification node.
> >     > > > >>>>
> >     > > > >>>> NEW:
> >     > > > >>>> * The rule does not have a "rule-type" defined or the
> >     > > > >>>> "rule-
> >     > > > >>>> type" is "data-node" and the "path" matches the
> >     > > > >>>> requested
> >     > > > >>>> data node, action node, or notification node. A path
is
> >     > > > >>>> considered to match if the current data node is the
> >     > > > >>>> data node
> >     > > > >>>> specified by the path, or is a descendant data node
> >     > > > >>>> of this data node.
> >     > > > >>>> appendix B.4: (2 bugs in explanation)
> >     > > > >>>> OLD:
> >     > > > >>>> deny-nacm: This rule denies the "guest" group any
> >     access
> >     to
> >     > > the
> >     > > > >>>>  subtree. Note that the default namespace is
only
> >     > > > >>>> applicable because this subtree is defined in the
same
> >     > > > >>>> namespace as the  element.
> >     > > > >>>> NEW:
> >     > > > >>>> deny-nacm: This rule denies the "guest" group any
> >     access
> >     to
> >     > > the
> >     > > > >>>>  subtree.
> >     > > > >>>> Andy
> >     > > > >>>>
> >     > > > >>>> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> >     > > > >>>> 
> >     >> wrote:
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>>
> >     > > > >>>> On 10/11/2017 16:33, Andy Bierman wrote:
> >     > > > >>>>>
> >     > > > >>>>>
> >     > > > >>>>> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
> >     > > > >>>>> 
> >     >>
> >     wrote:
> >     > > > >>>>>
> >     > > > >>>>>
> >     > > > >>>>>
> >     > > > >>>>> On 10/11/2017 15:49, Andy Bierman wrote:
> >     > > > >>>>>>
> >     > > > >>>>>>
> >     > > 
> >     > >
> >     > >
> >     >
> >
> >
>
>


From nobody Tue Nov 28 02:28:35 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A05124BE8 for ; Tue, 28 Nov 2017 02:28:34 -0800 (PST)
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 js3GlP_Y15Uf for ; Tue, 28 Nov 2017 02:28:31 -0800 (PST)
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 0175B1200F3 for ; Tue, 28 Nov 2017 02:28:29 -0800 (PST)
Received: from birdie8 (unknown [IPv6:2001:1488:fffe:12::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7474963CBC; Tue, 28 Nov 2017 11:28:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511864907; bh=0DfqW4W+omJ3dGqYMlXbUavsdZTcdMgMiVNLarZtUKk=; h=From:To:Date; b=dEbTsGMYf4aMYTyNYmP1v6WT/WtGOhrr8xai2/p9AO8uGrgh+Lit6JdZE5AMe4B0L JZREr6sllSkrekqo2oMV4FdgfHURhdu/LDvvJohQ5maWbPR7kF6WCoWYs1RIrncIFD psC1HQf7j9Msb+blabscdsPhC2TF+2pXArnJrG2I=
Message-ID: <1511864907.27324.15.camel@nic.cz>
From: Ladislav Lhotka 
To: Andy Bierman 
Cc: Netconf 
Date: Tue, 28 Nov 2017 11:28:27 +0100
In-Reply-To: 
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com>  <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com>  <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com>       <015101d36513$bba345e0$4001a8c0@gateway.2wire.net>  <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net>      <1511801627.6244.39.camel@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.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: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 10:28:34 -0000

On Mon, 2017-11-27 at 09:20 -0800, Andy Bierman wrote:
> 
> 
> On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka  wrote:
> > On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote:
> > >
> > >
> > > On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton  wrote:
> > > >
> > > > On 27/11/2017 15:12, Andy Bierman wrote:
> > > > >
> > > > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton 
> > wrote:
> > > > > > I do get the point that Tom is making here, and have quite a lot of
> > > > > > sympathy for it.  E.g. by automatically allowing the side effects of
> > > > > > when/choice statements then we are introducing a potential security
> > hole
> > > > > > here that operators may find hard to be aware of and mitigate.
> > > > > > It also seems odd to me that a client is allowed to implicitly
> > remove
> > > > > > some configuration through the side effect of a when/choice
> > statement
> > > > > > that they are not allowed to delete explicitly.
> > > > > > The alternative of requiring appropriate access for the side-
> > effects,
> > > > > > seems like an intuitively safer design, but I also get Andy's
> > concern
> > > > > > that security isn't useful if it become so unwieldy that nobody uses
> > it.
> > > > > > So, I guess the question here is, do we have some concrete examples
> > > > > > using real data models where the extra NACM delete rules would be
> > > > > > required?  If not then perhaps requiring the explicit access for
> > side
> > > > > > effects would be better.
> > > > > >
> > > > >
> > > > >
> > > > > Yes -- please provide some examples where it is better to force the
> > > > > operator
> > > > > to provide extra "delete" rules to allow false-when data nodes to be
> > > > > deleted.
> > > >
> > > > > It seems to me that these rules would allow individual data structures
> > to
> > > > > be
> > > > > removed by the client, that would not otherwise be possible.
> > > >  Yes, this is true.
> > > >
> > > > But it is still odd that they a client is allowed to delete the
> > > > configuration, just not explicitly.  I.e. it is strange that they   
> >  are
> > > > not allowed to put in a semantically equivalent request that explicitly
> > > > deletes the configuration, they are only allowed to do it if the delete
> > is
> > > > implicit.  This seems inconsistent.
> > > >
> > > >
> > >
> > > It is just as odd that a request  to create /foo/case1 will work if
> > nothing
> > > from
> > > the choice-stmt exists, but will fail if /foo/case2 has to be deleted in
> > order
> > > to create /foo/case1.
> > 
> > Why is this odd? RFC 7950 says:
> > 
> >    The "choice" statement defines a set of alternatives, only one of
> >    which may be present in any one data tree.
> > 
> > So it is quite clear that adding /foo/case1 makes the data tree invalid if
> > /foo/case2 exists.
> > 
> 
> 
> From a NACM POV, the rule to allow "create /foo/case1" works differently
> depending on whether server auto-deletion is used.
> 
> IMO, NACM controls client access, and auto-deletion is server access,
> which is mandated by the specific YANG data-def statements.
> 
> 
>  
> > >
> > >
> > > > > If 3 data structures need to be in place "when /foo exists" then
> > > > > deleting 1 or 2 of them directly may not be desirable.  Deleting
> > > > > them all together (i.e., via when-false deletion) may be the intended
> > > > > usage.
> > > >  If there is a dependency that all three exist then that may be better
> > > > expressed with a must statement instead.
> > > >
> > > > > The vendor and operator need to be aware of the data model
> > dependencies.
> > > > > That said, how come CLI-based configuration does not have this
> > problem?
> > > >  My experience of CLI based configurations do have these sorts of
> > problems,
> > > > and many more :-)
> > > >
> > > >
> > > > > (Or rather, why has this problem been ignored for so long? Maybe it
> > not
> > > > > that real?)
> > > >  This may be the real crux of the argument:
> > > >
> > > > It probably doesn't make sense to use when statements on disjoint parts
> > of
> > > > the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> > > > depend on whether an interface it runs over has an IP address
> > configured).
> > > > Instead, a more normal usage would be a flag (e.g. like interface type)
> > to
> > > > allow/prevent certain child nodes from being available.  In these
> > scenarios,
> > > > if a user is allowed to change the type of an interface then they are
> > most
> > > > likely allowed to change the other settings on the interface as well.
> > > >
> > > > So for 'normal' when statements, it probably doesn't make much
> > difference
> > > > whether or not explicit NACM access is required to the nodes being
> > > > implicitly deleted because the client probably already has the necessary
> > > > access rights.
> > > >
> > > > But for the 'corner case' when statement scenario, that are unlikely to
> > be
> > > > used, it still seems safer to require explicit access permissions than
> > > > implicitly accepting the side effect with no NACM validation.
> > > >
> > >
> > >
> > > This is fine, except there is no way to tell a normal when from a corner-
> > case
> > > when.
> > >
> > > In all cases, the false-when evaluation means the node is not relevant to
> > the
> > > model anymore.
> > 
> > The client that causes the when expression to become invalid may not be
> > entitled
> > to decide whether the node is relevant or not.
> > 
> 
> 
> The YANG designers need to consider the impact of when statements on the data
> model usage.
> NACM needs to be used at a sufficiently course granularity and it is quite
> possible
> to setup NACM with inappropriate granularity, where intended access is blocked
> and unintended access is allowed.
> 
>  
> > > Same for a case that is being replaced by a different case.
> > > In order for this NACM threat to be real. the YANG modeler needs to be
> > wrong
> > > about
> > > whether the false-when states are actually irrelevant to the model in its
> > new
> > > state.
> > 
> > The YANG modeller may be absolutely correct but other modules (out of his
> > control) may change this.
> > 
> 
> 
> The widespread use of vendor extensions and deviations makes it impossible to
> focus on just the standard modules when considering access control.
> Perhaps the best the IETF can do is identify YANG usage patterns that need to
> considered
> when configuring NACM.
> 
> Another option is to create smarter NACM filters, based on tags, not data
> nodes.
> Data rules are very sharp knifes that need to be used with care.

Eliminating side effects would make them considerably more robust. Rules about a
particular instance should ideally fully determine what can happen with it -
such rules would be easy to set up up and maintain.

Lada 

> 
> > Lada
> > 
> 
> Andy
>  
> > >
> > >
> > > > Thanks,
> > > > Rob
> > > >
> > >
> > >
> > > Andy
> > >
> > > >
> > > > > > Thanks,
> > > > > > Rob
> > > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > > > On 25/11/2017 15:53, Andy Bierman wrote:
> > > > > > >
> > > > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch 
> > wrote:
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Andy Bierman" 
> > > > > > > > To: "t.petch" 
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch 
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > > Tom Petch
> > > > > > > > > >
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Robert Wilton" 
> > > > > > > > > > Sent: Thursday, November 23, 2017 10:44 AM
> > > > > > > > > >
> > > > > > > > > > > Hi Andy,
> > > > > > > > > > >
> > > > > > > > > > > On 22/11/2017 18:09, Andy Bierman wrote:
> > > > > > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >     Hi Rob,
> > > > > > > > > > > >
> > > > > > > > > > > >     At that points in time, if it clarifies the spec.
> > and
> > > > > > > > the
> > > > > > > > > > authors
> > > > > > > > > > > >     agree with this, let's do the right thing.
> > > > > > > > > > > >
> > > > > > > > > > > > I will add the new text if that is what the WG wants.
> > > > > > > > > >
> > > > > > > > > > > Having read this draft, I was undecided what the intended
> > > > > > > > behavior
> > > > > > > > > > > actually should be.
> > > > > > > > > > >
> > > > > > > > > > > The way that Yumapro and Tail-f have implemented this is
> > > > > > > > reasonable,
> > > > > > > > > > and
> > > > > > > > > > > is probably also the way that I would implemented it.
> > > > > > > > > > >
> > > > > > > > > > > But I also think that it would be a reasonable
> > implementation
> > > > > > > > for
> > > > > > > > a
> > > > > > > > > > > server to calculate the full change set (taking account of
> > > > > > > > side
> > > > > > > > > > effects
> > > > > > > > > > > from when and choice statements) to the datastore before
> > > > > > > > checking
> > > > > > > > the
> > > > > > > > > > > "write data node access control" against the resultant
> > change
> > > > > > > > set.
> > > > > > > > > > >
> > > > > > > > > > > My interpretation is that the RFC text is ambiguous on
> > what
> > > > > > > > the
> > > > > > > > > > correct
> > > > > > > > > > > behavior is, and one could make a reasonable argument that
> > the
> > > > > > > > current
> > > > > > > > > > > RFC actually specifies that the alternative behavior is
> > > > > > > > correct,
> > > > > > > > i.e.
> > > > > > > > > > > requiring delete access even if a node is implicitly
> > changes
> > > > > > > > as a
> > > > > > > > side
> > > > > > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states:
> > > > > > > > > > >
> > > > > > > > > > >     If the protocol operation would result in the deletion
> > of
> > > > > > > > a
> > > > > > > > > > datastore
> > > > > > > > > > >     node and the user does not have "delete" access
> > permission
> > > > > > > > for
> > > > > > > > > > that
> > > > > > > > > > >     node, the protocol operation is rejected with an
> > > > > > > > "access-denied"
> > > > > > > > > > >     error.
> > > > > > > > > >
> > > > > > > > > > Rob
> > > > > > > > > >
> > > > > > > > > > I have been reading that paragraph since this thread started
> > and
> > > > > > > > > > wondering how it could be thought unclear, what am I
> > missing:-)
> > > > > > > > > >
> > > > > > > > > > To me it clearly states that the user must have the
> > appropriate
> > > > > > > > access
> > > > > > > > > > for the consequences of whatever they do, be that 'when',
> > > > > > > > 'choice'
> > > > > > > > or
> > > > > > > > > > anything else! Indeed, I see exactly that behaviour in
> > > > > > > > operational
> > > > > > > > > > (non-network) databases of which I am a user with limited
> > > > > > > > privileges.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is not correct.
> > > > > > > > > The server is the entity that is cleaning up false when-stmt
> > or
> > > > > > > > unselected
> > > > > > > > > cases
> > > > > > > > > for a choice-stmt.
> > > > > > > > >
> > > > > > > > > NACM does not prevent the sever from making any changes to the
> > > > > > > > system.
> > > > > > > > > It only affects the operations requested by a client.
> > > > > > > >
> > > > > > > > Andy
> > > > > > > >
> > > > > > > > My model is slightly different, that the server is a black box,
> > with
> > > > > > > > an
> > > > > > > > interface through which I can make authorised changes.  If
> > something
> > > > > > > > I
> > > > > > > > do causes the deletion of something I am not allowed to delete,
> > may
> > > > > > > > be
> > > > > > > > not even to read, well, we part company on the acceptability of
> > > > > > > > that!
> > > > > > > >
> > > > > > > > I do accept, as Randy points out, that the situation is
> > > > > > > > complicated.  I
> > > > > > > > am reminded of the issues that came up relating to the 'when'
> > > > > > > > statement
> > > > > > > > when preparing YANG 1.1.  Yes, 'when' makes things possible and
> > is
> > > > > > > > very
> > > > > > > > useful but at the same time, its side effects can be
> > troublesome.  I
> > > > > > > > would like to wrap it up in a conceptual bubble so you could not
> > > > > > > > have
> > > > > > > > the sort of fine-grained access control that allows the case
> > that
> > > > > > > > Rob
> > > > > > > > postulates to occur but have no idea what that might look like. 
> > And
> > > > > > > > I
> > > > > > > > don't know how much 'when' is used in that way in existing YANG
> > > > > > > > modules - uh huh, more reading required.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > When the access control is too complicated, it does not get used.
> > > > > > > Instead, the most likely access control is "everybody is the root
> > > > > > > user".
> > > > > > > The server pruning of false when/choice data nodes is considered
> > > > > > > cleanup.
> > > > > > > The pruned data is no longer relevant to the data model. This is
> > the
> > > > > > > indended
> > > > > > > use, but when-stmt can easily be abused.
> > > > > > >
> > > > > > > The complex tangled web of dependencies is no worse
> > > > > > > than it has been with CLI for 30 years, where every dependency is
> > ad-
> > > > > > > hoc
> > > > > > > and probably undocumented. The granularity of CLI-based access
> > control
> > > > > > > is less granular than NACM.
> > > > > > >
> > > > > > > It is possible that vendors and operators are willing to spend
> > hours
> > > > > > > and days
> > > > > > > figuring out how to tune the NACM rules to allow a specific edit
> > to
> > > > > > > work.
> > > > > > > Of course the operator will not even be told by the server which
> > nodes
> > > > > > > are blocking the edit. That would be a security risk.
> > > > > > >
> > > > > > > IMO NACM will be completely unusable if rules are needed to allow
> > > > > > > server cleanup of dead nodes.  The additional NACM rules required
> > > > > > > might provide more access than intended (unless lots of delete-
> > only
> > > > > > > rules are added). The huge jump in NACM rule management complexity
> > is
> > > > > > > a new security vulnerability, which might even be worse than the
> > > > > > > vulnerability it is intended to fix.
> > > > > > >
> > > > > > >
> > > > > > > > Tom Petch
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Andy
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > > My other thought was that given all the complexities of
> > 'when'
> > > > > > > > that
> > > > > > > > > > emerged during the specification of YANG 1.1, perhaps, were
> > I an
> > > > > > > > > > implementor of this, I would take the easy option and ignore
> > the
> > > > > > > > side
> > > > > > > > > > effects of 'when'; but I might feel guilty about doing so.
> > > > > > > > > >
> > > > > > > > > > If the new paragraphs go in as proposed, then I think that
> > the
> > > > > > > > two
> > > > > > > > > > paragraphs you quote need changing else that section looks
> > to me
> > > > > > > > like an
> > > > > > > > > > oxymoron.
> > > > > > > > > >
> > > > > > > > > > Tom Petch
> > > > > > > > > >
> > > > > > > > > > > An  request that causes a when constraint to
> > > > > > > > evaluate
> > > > > > > > > > > differently does result in a deletion of those data nodes
> > from
> > > > > > > > the
> > > > > > > > > > > datastore, and hence according to the text above, requires
> > > > > > > > explicit
> > > > > > > > > > > "delete" access permission to accomplish that.
> > > > > > > > > > >
> > > > > > > > > > > Clearly it would be an interop issue if different servers
> > > > > > > > implemented
> > > > > > > > > > > the NACM path based filtering differently.
> > > > > > > > > > >
> > > > > > > > > > > Hence why I think that it would be prudent for the draft
> > to be
> > > > > > > > more
> > > > > > > > > > > explicit on when and choice statement handling.
> > > > > > > > > > >
> > > > > > > > > > > Rob
> > > > > > > > > > >
> > > > > > > > > > > > There have not been any comments on this issue.
> > > > > > > > > > > >
> > > > > > > > > > > > Andy
> > > > > > > > > > > >
> > > > > > > > > > > >     Regards, Benoit.
> > > > > > > > > > > >>
> > > > > > > > > > > >>     Hi Benoit,
> > > > > > > > > > > >>
> > > > > > > > > > > >>     There is also one further, unrelated change that I
> > am
> > > > > > > > proposing
> > > > > > > > > > > >>     is made the draft before it is published, to help
> > > > > > > > better
> > > > > > > > > > clarify
> > > > > > > > > > > >>     the expected behavior. It isn't the end of the
> > world if
> > > > > > > > this
> > > > > > > > > > > >>     doesn't go in, but I think that it prevents
> > sometime
> > > > > > > > taking
> > > > > > > > a
> > > > > > > > > > > >>     different, but IMO reasonable, interpretation of
> > how
> > > > > > > > "when"
> > > > > > > > > > > >>     statements are considered, and then having a future
> > > > > > > > argument
> > > > > > > > > > > >>     about what behavior it specified in the standard.
> > > > > > > > > > > >>
> > > > > > > > > > > >>     If we clarify it now, then it closes that door :-)
> > > > > > > > > > > >>
> > > > > > > > > > > >>     I've proposed text to Andy and Martin on Monday,
> > but
> > > > > > > > I've
> > > > > > > > not
> > > > > > > > > > > >>     heard back yet.
> > > > > > > > > > > >>
> > > > > > > > > > > >>     Netconf email with proposed text attached. The text
> > > > > > > > doesn't
> > > > > > > > > > > >>     necessarily have to match this, but personally I
> > think
> > > > > > > > that
> > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > > >>     useful if the draft says something on this.
> > > > > > > > > > > >>
> > > > > > > > > > > >>     Thanks,
> > > > > > > > > > > >>     Rob
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >>     On 22/11/2017 13:25, Benoit Claise wrote:
> > > > > > > > > > > >>>     On 11/10/2017 7:23 PM, Andy Bierman wrote:
> > > > > > > > > > > >>>>     Hi,
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     Here are some proposed edits to make the data
> > rule
> > > > > > > > consistent
> > > > > > > > > > > >>>>     with the examples.
> > > > > > > > > > > >>>>     Note that this issue is not related to the edit
> > in
> > > > > > > > the
> > > > > > > > > > original
> > > > > > > > > > > >>>>     1-week change.
> > > > > > > > > > > >>>     That's right, but we found a source of
> > > > > > > > misinterpretation
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > >>>     draft and you have rightly corrected it in the
> > github
> > > > > > > > v9.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>>     Regards, Benoit
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     sec. 3.3.5:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     OLD:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     data node rule: controls access for a specific
> > data
> > > > > > > > > > > >>>>     node, identified
> > > > > > > > > > > >>>>     by its path location within the conceptual XML
> > > > > > > > document
> > > > > > > > > > > >>>>     for the
> > > > > > > > > > > >>>>     data node.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     NEW:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     data node rule: controls access for a specific
> > data
> > > > > > > > node
> > > > > > > > > > > >>>>     and its descendants,
> > > > > > > > > > > >>>>     identified by its path location within the
> > conceptual
> > > > > > > > XML
> > > > > > > > > > > >>>>     document for the
> > > > > > > > > > > >>>>     data node.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     sec 3.4.5, step 6, bullet 2:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     OLD:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or
> > the
> > > > > > > > > > > >>>>     "rule-
> > > > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > > > >>>>     requested
> > > > > > > > > > > >>>>     data node, action node, or notification node.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     NEW:
> > > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or
> > the
> > > > > > > > > > > >>>>     "rule-
> > > > > > > > > > > >>>>     type" is "data-node" and the "path" matches the
> > > > > > > > > > > >>>>     requested
> > > > > > > > > > > >>>>     data node, action node, or notification node. A
> > path
> > > > > > > > is
> > > > > > > > > > > >>>>     considered to match if the current data node is
> > the
> > > > > > > > > > > >>>>     data node
> > > > > > > > > > > >>>>     specified by the path, or is a descendant data
> > node
> > > > > > > > > > > >>>>     of this data node.
> > > > > > > > > > > >>>>     appendix B.4: (2 bugs in explanation)
> > > > > > > > > > > >>>>     OLD:
> > > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > > > access
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > >>>>      subtree. Note that the default namespace
> > is
> > > > > > > > only
> > > > > > > > > > > >>>>     applicable because this subtree is defined in the
> > > > > > > > same
> > > > > > > > > > > >>>>     namespace as the  element.
> > > > > > > > > > > >>>>     NEW:
> > > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group any
> > > > > > > > access
> > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > > >>>>      subtree.
> > > > > > > > > > > >>>>     Andy
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
> > > > > > > > > > > >>>>     >
> > wrote:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>         On 10/11/2017 16:33, Andy Bierman wrote:
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>         On Fri, Nov 10, 2017 at 8:16 AM, Robert
> > Wilton
> > > > > > > > > > > >>>>>          > >>
> > > > > > > > wrote:
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Nov 28 05:18:08 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3575124B18 for ; Tue, 28 Nov 2017 05:18:06 -0800 (PST)
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 U0EhW-eHR-m4 for ; Tue, 28 Nov 2017 05:17:59 -0800 (PST)
Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAF5126CC7 for ; Tue, 28 Nov 2017 05:17:56 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2G4AgBp299Z/xoBYJleGgEBAQECAQEBAQgBAQEBg12BHTUnB4NzmVGBSyt5lTaCEgqFOwKEP0EWAQIBAQEBAQEBA2goQg6ETQEBAQMBIw8BBVEJAhAIAgImAgJHEAYNBgIBAReJewcBBI4HnWeCJ4s8AQEIAQEBASSBDoIfggeBUYFqK4JKNYE9hluCYQWhRIEIgSaUUIlJBYcuiiGLHQIEBgUCGQGBOSUBMoEOUyYzhUQMEIFodYVBhQUBgRABAQE
X-IPAS-Result: A2G4AgBp299Z/xoBYJleGgEBAQECAQEBAQgBAQEBg12BHTUnB4NzmVGBSyt5lTaCEgqFOwKEP0EWAQIBAQEBAQEBA2goQg6ETQEBAQMBIw8BBVEJAhAIAgImAgJHEAYNBgIBAReJewcBBI4HnWeCJ4s8AQEIAQEBASSBDoIfggeBUYFqK4JKNYE9hluCYQWhRIEIgSaUUIlJBYcuiiGLHQIEBgUCGQGBOSUBMoEOUyYzhUQMEIFodYVBhQUBgRABAQE
X-IronPort-AV: E=Sophos;i="5.43,368,1503352800";  d="scan'208";a="1594957"
Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Nov 2017 14:17:50 +0100
X-IronPort-AV: E=Sophos;i="5.44,468,1505772000"; d="scan'208";a="271547225"
X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaka26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 14:17:49 +0100
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id vASDHlOd022101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 28 Nov 2017 14:17:48 +0100
Received: from [134.102.163.90] (134.102.163.90) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 14:17:42 +0100
To: 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local>
From: Henk Birkholz 
Message-ID: <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de>
Date: Tue, 28 Nov 2017 14:17:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171128062734.d3vofdjmcomvpouo@elstar.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.163.90]
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 13:18:07 -0000

Hello Jürgen,

a few observations inline:

On 11/28/2017 07:27 AM, Juergen Schoenwaelder wrote:
> On Mon, Nov 27, 2017 at 04:45:47PM -0800, Mahesh Jethanandani wrote:
>> Juergen,
>>
>>> On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder  wrote:
>>>
>>> On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:
>>>
>>>> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
>>>> support features like licensing, and semantic versioning.
>>>
>>> I do not know what this means. (The goal of the NMDA work is to
>>> support NMDA - focus is good thing. Perhaps the minutes will some shed
>>> light on what this AI means but the minutes are not out yet.)
>>
>> I think there was some confusion around the naming and scope of the three “NMDA” drafts. The YANG Library draft is named as a rfc7895bis draft, while the other two are named nmda-netconf and nmda-restconf drafts. In addition, nothing in the abstract and the introduction of the rfc7895bis seems to imply that the only focus of the draft is NMDA. The other two drafts call that out explicitly.
>>
>> As a -bis draft, questions around what else makes sense. So questions around whether YANG Library will support the concept of licensing impacting what models are advertised and supported, and whether semantic versioning should be part of the YANG Library were raised. Do you disagree?
>>
> 
> Seriously? The scope of work is defined by how an I-D is named? The
> charter says:
> 
>    6. Based on the revised datastore concept work in NETMOD, provide a
>       revision for the NETCONF and RESTCONF protocols and the used
>       datastore framework.
> 
> And there were discussions leading to this charter text.

I am not surprised that a subset of attendees expects that the title of 
a document refers to its content. Given that this is a bis in accord 
with the new charter this disconnect can probably not be completely 
avoided, but I am puzzled by your strong reaction, because:

a) given that the acronym NMDA is only used in the Introduction and only 
implicitly introduced there by reference of 
I-D.ietf-netmod-revised-datastores (which of course provides the 
resolved acronym by its title) and given that it is also never actually 
elaborated on even a bit anywhere in the document (there are a lot of 
terms such as NMDA-compatible, NMDA-supporting and NMDA-aware, but no 
further semantics are provided), I think - as a reader - it is totally 
okay to be confused here, and

b) just elaborating on what NMDA means in a nutshell and how it 
contributes to the solution this draft provides (and correspondingly, 
how it solves a problem) probably addresses this small issue?

I.e. just importing ietf-datastores in the module and using the acronym 
in an arcane way a few times probably does not provide enough context to 
compose a comprehensive document.

> 
> That said, I have no clue what 'licensing support' means or what
> changes are needed to do 'semantic versioning' or even that there is
> agreement to do 'semantic versioning'. (I personally believe semantic
> versioning requires an new version of YANG since core rules of YANG,
> e.g., how the import statement works, are needed.)
> 
> If we make the NMDA updates of NC and RC a moving target by putting
> other things that come up into the document then we can be sure that
> the update takes 3 years. I strongly prefer to scope the updates to
> NMDA support with the goal to deliver soon (dec 2017 says the
> milestone - but then what do milestones mean in a world where scope is
> derived from I-D filenames).

This seems to be an unnecessary jab that has nothing to do with the 
actual topics raised by Mahesh, which were:

- YANG Library will support the concept of licensing impacting what 
models are advertised and supported
- semantic versioning should be part of the YANG Library

Which, btw, I also am not sure about how and where that came up and what 
it means. In consequence - as Jürgen - I am curious to see the minutes.

> 
> /js
> 


Viele Grüße,

Henk


From nobody Tue Nov 28 05:38:28 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4255E127011 for ; Tue, 28 Nov 2017 05:38:27 -0800 (PST)
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 v6mdI1BMpP8y for ; Tue, 28 Nov 2017 05:38:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17BB812711E for ; Tue, 28 Nov 2017 05:38:21 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id D8E3A1AE043F; Tue, 28 Nov 2017 14:38:19 +0100 (CET)
Date: Tue, 28 Nov 2017 14:36:58 +0100 (CET)
Message-Id: <20171128.143658.232255353450011964.mbj@tail-f.com>
To: mjethanandani@gmail.com
Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local> 
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: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 13:38:27 -0000

TWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KPiBK
dWVyZ2VuLA0KPiANCj4gPiBPbiBOb3YgMjcsIDIwMTcsIGF0IDQ6MDAgUE0sIEp1ZXJnZW4gU2No
b2Vud2FlbGRlcg0KPiA+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdy
b3RlOg0KPiA+IA0KPiA+IE9uIE1vbiwgTm92IDI3LCAyMDE3IGF0IDAzOjI3OjA2UE0gLTA4MDAs
IE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQo+ID4gDQo+ID4+IE5NREEgZHJhZnRzIChZQU5H
IExpYnJhcnksIE5FVENPTkYgYW5kIFJFU1RDT05GKSBuZWVkIHVwZGF0ZXMgdG8NCj4gPj4gc3Vw
cG9ydCBmZWF0dXJlcyBsaWtlIGxpY2Vuc2luZywgYW5kIHNlbWFudGljIHZlcnNpb25pbmcuDQo+
ID4gDQo+ID4gSSBkbyBub3Qga25vdyB3aGF0IHRoaXMgbWVhbnMuIChUaGUgZ29hbCBvZiB0aGUg
Tk1EQSB3b3JrIGlzIHRvDQo+ID4gc3VwcG9ydCBOTURBIC0gZm9jdXMgaXMgZ29vZCB0aGluZy4g
UGVyaGFwcyB0aGUgbWludXRlcyB3aWxsIHNvbWUgc2hlZA0KPiA+IGxpZ2h0IG9uIHdoYXQgdGhp
cyBBSSBtZWFucyBidXQgdGhlIG1pbnV0ZXMgYXJlIG5vdCBvdXQgeWV0LikNCj4gDQo+IEkgdGhp
bmsgdGhlcmUgd2FzIHNvbWUgY29uZnVzaW9uIGFyb3VuZCB0aGUgbmFtaW5nIGFuZCBzY29wZSBv
ZiB0aGUNCj4gdGhyZWUg4oCcTk1EQeKAnSBkcmFmdHMuIFRoZSBZQU5HIExpYnJhcnkgZHJhZnQg
aXMgbmFtZWQgYXMgYSByZmM3ODk1YmlzDQo+IGRyYWZ0LCB3aGlsZSB0aGUgb3RoZXIgdHdvIGFy
ZSBuYW1lZCBubWRhLW5ldGNvbmYgYW5kIG5tZGEtcmVzdGNvbmYNCj4gZHJhZnRzLg0KDQpUaGlz
IGlzIGIvYyByZmM3ODk1YmlzIHByb3ZpZGVzIGEgbmV3IFlBTkcgTGlicmFyeTsgaXQgb2Jzb2xl
dGVzIFJGQyA3ODk1DQooaWYgYXBwcm92ZWQpLg0KDQo+IEluIGFkZGl0aW9uLCBub3RoaW5nIGlu
IHRoZSBhYnN0cmFjdCBhbmQgdGhlIGludHJvZHVjdGlvbiBvZg0KPiB0aGUgcmZjNzg5NWJpcyBz
ZWVtcyB0byBpbXBseSB0aGF0IHRoZSBvbmx5IGZvY3VzIG9mIHRoZSBkcmFmdCBpcw0KPiBOTURB
Lg0KDQpCdXQgTk1EQSBpcyAqbm90KiB0aGUgb25seSBmb2N1cyBvZiB0aGlzIGRvY3VtZW50ISAg
VGhlIGRyYWZ0IGhhcyB0aGlzDQp0ZXh0IGluIHRoZSBJbnRyb2R1Y3Rpb246DQoNCiAgIFRoaXMg
ZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgbW9kdWxlIHRoYXQgY2FuIGJlIHVzZWQgdG8gcHJvdmlk
ZSB0aGlzDQogICBpbmZvcm1hdG9uLCBpbiBhIHdheSB0aGF0IGlzIGNvbXBhdGlibGUgd2l0aCB0
aGUgTk1EQQ0KICAgW0ktRC5pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXNdLCBidXQgdGhh
dCBpcyBhbHNvIGJhY2t3YXJkcw0KICAgY29tcGF0aWJsZSB3aXRoIHRoZSAiWUFORyBNb2R1bGUg
TGlicmFyeSIgWUFORyBtb2R1bGUgZGVmaW5lZCBpbg0KICAgW1JGQzc4OTVdLg0KDQp3aGljaCBJ
IGJlbGlldmUgaXMgYWNjdXJhdGUuDQoNCg0KPiBBcyBhIC1iaXMgZHJhZnQsIHF1ZXN0aW9ucyBh
cm91bmQgd2hhdCBlbHNlIG1ha2VzIHNlbnNlLiBTbyBxdWVzdGlvbnMNCj4gYXJvdW5kIHdoZXRo
ZXIgWUFORyBMaWJyYXJ5IHdpbGwgc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBsaWNlbnNpbmcNCj4g
aW1wYWN0aW5nIHdoYXQgbW9kZWxzIGFyZSBhZHZlcnRpc2VkIGFuZCBzdXBwb3J0ZWQsIGFuZCB3
aGV0aGVyDQo+IHNlbWFudGljIHZlcnNpb25pbmcgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIFlBTkcg
TGlicmFyeSB3ZXJlIHJhaXNlZC4NCg0KQm90aCB0aGVzZSB0aGluZ3MgYXJlIG5ldyBpc3N1ZXMs
IGRvY3VtZW50ZWQgaW4gaW5kaXZpZHVhbCBkcmFmdHMuICBJDQpkb24ndCB0aGluayB3ZSBzaG91
bGQgcG9zdHBvbmUgdGhlIHB1YmxpY2F0aW9uIG9mIDc4OTViaXMgdW50aWwgdGhlc2UNCmRyYWZ0
cyBhcmUgcmVhZHkuICBJdCBpcyBub3QgZXZlbiBjbGVhciB3aGF0IHRoZSB0ZWNobmljYWwgc29s
dXRpb24NCmFyb3VuZCB0aGVzZSBpc3N1ZXMgd2lsbCBiZSwgYW5kIGlmIGl0IGNhbiBiZSBzb2x2
ZWQgaW4gWUFORyBsaWJyYXJ5DQpvciBldmVuIGlmIGNoYW5nZXMgdG8gWUFORyBsaWJyYXJ5IGFy
ZSByZXF1aXJlZC4NCg0KDQovbWFydGluDQoNCg0KPiBEbw0KPiB5b3UgZGlzYWdyZWU/DQo+IA0K
PiA+IA0KPiA+IC9qcw0KPiA+IA0KPiA+IC0tIA0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg
ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0
MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFu
eQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2Jz
LXVuaXZlcnNpdHkuZGUvPg0KPiANCj4gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiBtamV0aGFuYW5k
YW5pQGdtYWlsLmNvbQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0K
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg==


From nobody Tue Nov 28 09:11:06 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C31128D0F for ; Tue, 28 Nov 2017 09:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 po9Mbz_VKLrM for ; Tue, 28 Nov 2017 09:10:55 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 43677128BB6 for ; Tue, 28 Nov 2017 09:10:54 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id r143so595260lfe.13 for ; Tue, 28 Nov 2017 09:10:54 -0800 (PST)
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=0MgY4m7jd5JUPsZ/lWJNCO0WTR+SqIWav9dH9D2+7kA=; b=UJFKQ57HGXt9nxKVVNG4zv82QgH2CcpaktZNSX4ygPN6t+qTHlQzlNoWi3GuKpb/j6 R1D8fyEAUdlZ8iIgJY876mq7Nx1hz+SnzW1otuAYM4vXGvoSwrdpFu9PjA5EzkUM4jEQ Ol7W4W107RvpWBtyBkqjycoI9pvpfok/ni5dwPl062+s/TjHgyG9qRz8SD3fa7tP54tc Rh6vuOXfGFVFFzljPg4q7UXa/2gxXMjzsnyL9aU48hrpp+l87s7f2l3w92A9b157Tiih Q2OscSJbKdice+tojwBAMTzmLgBCfSoZOToZlBEGjHUYEhaZYr1lqDHC2nPzoX5wLS9t 7Grg==
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=0MgY4m7jd5JUPsZ/lWJNCO0WTR+SqIWav9dH9D2+7kA=; b=shh3/DBRMJN8WifwArr1yqHlAFG8hOOJ3dwOf3ivkcfntfuK6uMoXVeIkOkyCg69fO IKh9cEGrFUaWdOycG0A3owklRAr5AXYRsNZVg8br0Kls2VjkANtzNz4mzA7ZFypUJGwE mY5M4Z9OImFaDzbaGzsqUZeEbkm1tYvrLiFYm8PNgF6r2wmoGoZbO+sw7g0TKBsIBaIZ qvvDuC4Dsc2C8FoOv/4AWVTLc27wyd4MSK383uW2D9KdqE7JAzFvOi+NKzOGdYpTm2hK CR+YIT3+q75/KvccN5a8cz9fgkKOru4KKFcizrqq/SCiUvaGMWNNveHHRZYexpTUSgLZ x6Mw==
X-Gm-Message-State: AJaThX50L58YjCVzVP9A8YIqqsl4+zXdyXVORJ+GP8BEN7oG6tFLJJUw oLzg2MqgNjjwFdW69+kSlUpGXoBhcDBe121X/jRNKQ==
X-Google-Smtp-Source: AGs4zMamk3TfaywnrMwz5cvh1NrvZXGrre0OOgcedDLm1ryKC2Uru875PpcxYA/eAEWYaKFG0+AHnkO/ZTRP5XTkKOc=
X-Received: by 10.46.4.149 with SMTP id a21mr2996923ljf.153.1511889052320; Tue, 28 Nov 2017 09:10:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 28 Nov 2017 09:10:51 -0800 (PST)
In-Reply-To: <20171128.103735.1654378548309425095.mbj@tail-f.com>
References: <20171128.103735.1654378548309425095.mbj@tail-f.com>
From: Andy Bierman 
Date: Tue, 28 Nov 2017 09:10:51 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="94eb2c1ab676e75c32055f0e19e7"
Archived-At: 
Subject: Re: [Netconf] review of draft-ietf-netconf-yang-push-11
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 17:10:58 -0000

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

On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund  wrote:

> Hi,
>
>
> I have now reviewed draft-ietf-netconf-yang-push-11.  I have one
> somewhat more important comment, and several others.
>
> Important issue:
>
> o  3.10
>
>   I don't think the proposed YANG extension is the correct solution to
>   the stated problem, for several reasons:
>
>     1.  In most cases, this is not a property of the data model, but
>         of the implementation, and possibly even the deployment.  So
>         having a YANG extension statement is not a good solution.
>
>     2.  With NDMA, the same schema node is present in different
>         datastores.  It might be the case that an implementation
>         supports on-change for the node in a configuration datastore,
>         but not in operational.  Again, marking a node in the schema
>         is not a good solution.
>
>     3.  Since the on-change property is implementation dependent, it
>         means the information will be available to clients only in
>         deviation modules.  This is quite an expensive and complicated
>         way to pass the information to the clients.
>
>
>   An alternative solution could be to have an ordered list of
>   instance-identifiers that list this property, per datastore, for
>   example:
>
>    
>      /sys:system/sys:system-time
>      false
>    
>    
>      /sys:system
>      true
>    
>
>   Yet another alternative would be to leave this to future work.
>
>

I would prefer to leave this to future work.
I agree this is an implementation property, and not a data model property.

Andy



>
> Other comments:
>
>
> o  2
>
>   The document uses the term "YANG datastore" (it is even in the title
>   of the document).  This term is not used elsewhere, and it is not
>   defined in this document.  I suggest you change this to simply
>   "datastore".
>
>   Also, I think you should "import" the term "datastore" from
>   draft-ietf-netmod-revised-datastores, instead of having a slightly
>   different term in this document.
>
>   It is also unfortunate that you use the term "data node" in a
>   different meaning than RFC 7950.  Maybe use "datastore node"
>   instead?
>
>
> o  3.1
>
>   I'm not sure I understand the dampening period concept.  Let's
>   assume that the dampening period is 10s.  Then changes happen at
>   times:
>
>     2  3  4  11  13  14  15
>
>   From the description, it seems I would receive 4 notifications, from
>   times:
>
>     2  (containing only change from 2)
>     12 (containing change from 3,4,11)
>     13 (containing only change from 13)
>     23 (containing changes from 14,15)
>
>   Is this correct?
>
>   In any case, I suggest the description in the YANG module is
>   clarified - currently the RFC text contains more details than the
>   YANG module.
>
>
> o  3.2
>
>   The text says:
>
>      Therefore, in order to minimize the number of subscription
>      iterations between subscriber and publisher, dynamic
>      subscriptions SHOULD support a simple negotiation between
>      subscribers and publishers for subscription parameters.
>
>   To whom is this "SHOULD" directed?  I mean, dynamic subscriptions as
>   specified in this draft does indeed support simple "negotiation".
>   Maybe s/SHOULD support/supports/ ?
>
>
> o  3.4
>
>   The text says:
>
>     Please see [promise] for
>     more on the transactional basis underlying the publisher and
>     subscriber interactions within this document.
>
>   So I did that.  But I didn't find any text in the referenced
>   document that talked about "the transactional basis".
>
>   I suggest you remove this sentence from the draft.
>
>
> o  3.5
>
>   The text says:
>
>      A publisher MUST support XML encoding and MAY support other
>      encodings such as JSON encoding.
>
>   I don't think this is correct.  A RESTCONF sever is not required to
>   support XML.  I think you should remove this sentence.
>
>
> o  3.5.1
>
>      In a periodic subscription, the data included as part of an update
>      corresponds to data that could have been simply retrieved using a get
>      operation and is encoded in the same way.
>
>   What is "a get operation"?  Do you mean RESTCONF GET or NETCONF
>    or something else?  Whatabout other protocols?
>
>   (In 3.6, you use simply "a GET" for probably the same thing.)
>
>
> o  3.6
>
>      Subscription policy specifies both the selection filters and the
>      datastores against which these selection filters will be applied.
>      The result is the push of information necessary to remotely maintain
>      an extract of the publisher's datastore.
>
>   It seems this paragraph defines the term "Subscription policy".  But
>   this term is not used in the document.  What does it means that the
>   result of a policy is "the push of information"?
>
>   I think I don't understand what this paragraph tries to tell me.
>
>
> o  3.6
>
>      o  xpath: An xpath selection filter is an XPath expression which may
>         be meaningfully applied to a datastore.
>
>    What does "meaningfully applied" mean?
>
>
> o  3.6
>
>      Selection filters are not intended to be used to filter objects
>      based on a non-key property.  Supporting non-key property
>      filtering so would have a number of implications that would
>      result in significant complexity.
>
>      [...]
>
>      the goal is to
>      provide equivalent capabilities to what is available with a GET.
>
>   In GET you can filter on "non-key properties".
>
>   I think you should remove the text about "non-key properties".  If
>   anything, I think you can allow an implementation to reject a filter
>   that would be too complex to implement / evaluate (in fact I think
>   the text already allows a server to reject such filters.)
>
>   With the current text, is this filter ok:
>
>      /interfaces/interface[contains(name, "eth")]
>
>   It filters on a key, so it should be ok, right?
>
>
> o  3.7
>
>   The XML examples are not using the correct XML namespace for the
>   nodes from the "ietf-interface" module.
>
>   The YANG Patch example also shows an interesting effect in the
>   "patch-id" and "edit-id" leafs.  I think the draft should mention
>   how implementations are suppose to fill in these leafs.
>
>
>   The "target" leaf is not specified correctly.  It should be:
>
>          /ietf-interfaces:interfaces-state
>
>
> o  3.8
>
>   The example has:
>
>            xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
>        xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
>       
>         
>
>   This doesn't match the YANG model; there is no container called
>   "datastore" in the model.
>
>   Further is has:
>
>                      xmlns:ex="http://example.com/sample-data/1.0"
>             select="/ex:foo"/>
>
>   a subtree-filter of type xpath?  I think ot should be:
>
>         
>            /ex:foo
>         
>
>   Also, it has:
>
>         
>           operational
>         
>
>   which should be:
>
>         
>           ds:operational
>         
>
>
> o  3.9
>
>   This section lists three cases for which:
>
>      the error identity "data-unavailable" SHOULD be returned.
>
>   One of the cases is:
>
>     o  the authorization privileges of a receiver change over the course
>        of the subscription.
>
>   But how can a server know this when "establish-subscription" is sent?
>
>
> o  3.9
>
>      The contextual authorization model for data in YANG datastores is
>      the NETCONF Access Control Model [RFC6536bis], Section 3.2.4.
>
>   Did you mean s/contextual/conceptual/ ?
>
>
> o  3.11.1
>
>
>   OLD:
>
>        If
>        this is not possible and the synch-on-start option is configured,
>
>   NEW:
>
>        If
>        this is not possible and the "no-synch-on-start" option is not
>        present for the subscription.
>
>
>   (fixes incorrect name of leaf, and also covers dynamic
>   subscriptions)
>
>
> o  4.3.2
>
>      A subscription-id MUST be transported along with the subscribed
>      contents.
>
>   Then the leaf "subscription-id" should be mandatory.
>
>
>      A "time-of-update" which represents the time an update record
>      snapshot was generated.  A receiver MAY assume that a publisher's
>      objects have these pushed values at this point in time.
>
>   Should "time-of-update" be mandatory?
>
>   How is "time-of-update" different from "eventTime" in the
>   notification?
>
>
> o  4.3.2
>
>      If the application detects an informational discontinuity
>
>   What is an "informational discontinuity"?
>
>
> o  4.4.1 / 4.4.2
>
>   The XML examples are broken; compare with my comments for 3.8.
>
>
> o  5
>
>   OLD:
>
>     "This module contains conceptual YANG specifications
>      for YANG push.";
>
>   NEW:
>
>     "This module contains YANG specifications for YANG push.";
>
> o  5 - identities
>
>     identity qos-unsupported {
>       base sn:error;
>       description
>         "Subscription QoS parameters not supported on this platform.";
>     }
>
>   This identity is not mentioned anywhere in the text.  Instead of
>   having this identity, wouldn't it be better to define a feature for
>   "qos", and mark the nodes you have in mind with an if-feature?
>
>
>     identity on-change-unsupported {
>       base sn:error;
>       description
>         "On-change not supported.";
>     }
>
>   When will this identity be used?  There is already a feature
>   "on-change" and corresponding if-feature statements.
>
>     identity on-change-synch-unsupported {
>       base sn:error;
>       description
>         "On-change synch-on-start and resynchonization not supported.";
>     }
>
>   The leaf is called "no-sync-on-start", which implies that sync on
>   start is the default.  So when will this identity be used?
>
>
>     identity reference-mismatch {
>      base sn:error;
>       description
>        "Mismatch in filter key and referenced yang subtree.";
>     }
>
>   I don't understand the description of this identity.  Please
>   clarify.
>
>
>      identity datatree-size {
>
>   Should it be "result-too-big" or something?
>
>
>     identity no-such-datastore {
>
>   I think this one should be removed.  The normal "invalid-value"
>   error-tag covers this error.
>
>
>       identity custom-datastore {
>         base ds:datastore;
>         description
>           "A datastore with boundaries not defined within
>            draft-ietf-netmod-revised-datastores";
>       }
>
>   This identity needs to be removed.  If someone defines a custom
>   datastore, it would get a specific identity, and that identity can
>   be used as "source".
>
>
> o  5 - "change-type"
>
>   The descriptions of the enums need to be improved.  This is about
>   reporting a change in a datastore.  The value "create" is described
>   as:
>
>         description
>           "Create a new data resource if it does not already exist.  If
>           it already exists, replace.";
>
>   Also, the description of the typedef has:
>
>       "RFC 8072 section 2.5, with a delta that it is ok to receive
>       ability create on an existing node, or receive a delete on a
>       missing node.";
>
>   But what does this mean?  The type is used to *exclude* some changes
>   from a yang patch record.
>
>
> o  5 - selection filter
>
>   The XPath expression is not properly defined.
>
>   OLD:
>
>           "This parameter contains an XPath expression identifying the
>           portions of the target datastore to retrieve.";
>
>   NEW:
>
>           "This parameter contains an XPath expression identifying the
>            portions of the target datastore to retrieve.
>
>            If the expression returns a node-set, all nodes in the
>            node-set are selected by the filter.  Otherwise, if the
>            expression does not return a node-set, the filter
>            doesn't select any nodes.
>
>            FIXME: (*)
>
>            The expression is evaluated in the following XPath context:
>
>              o  The set of namespace declarations are those in scope on
>                 the 'xpath-filter' leaf element.
>
>              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 root node of the target
>                 datastore.
>
>
>   (*) - We need to describe when the filter is evaluated.  This is
>   also true for the subtree filter.  Is it evaluated when the
>   subscription is started and explicitly modified, or everytime a
>   change is detected?
>
>   [Side note: this description is also missing from the "xpath-filter"
>   leaf in "get-data" in draft-ietf-netconf-nmda-netconf.  I have
>   updated the description in that draft.]
>
>
> o  5 - terminology
>
>   The term "agent" is used a couple of times.  Use "publisher" or
>   "server" instead.
>
>
> o  5 - dampening
>
>           leaf dampening-period {
>             type yang:timeticks;
>             mandatory true;
>
>    Should this instead be:
>
>           leaf dampening-period {
>             type yang:timeticks;
>             default "0";
>
>    So that the request is the same if the "on-change" feature is
>    support or not.
>
>
> o  5 - no-synch-on-start
>
>              When
>              present, pushing a full selection per the terms of the
>              selection filter MAY NOT be done for this subscription.
>
>    Did you mean s/MAY NOT/MUST NOT/ ?
>
>    MAY NOT is not a 2119 term.
>
>
> o  5 - QoS
>
>   Why are the qos parameters defined in yang push, and not in
>   subscribed notifications?  It seems that they are generic.
>
>
> o  5 - establish-subscription params
>
>   I think a "when" expression should be added to the first augment:
>
>     augment "/sn:establish-subscription/sn:input" {
>       when "sn:target/yp:datastore/yp:source";
>
>
> o  5 - push-update
>
>   What does the presence of "updates-not-sent" mean in "push-update"?
>   "push-update" contains a snapshot, not a diff, so why is
>   "updates-not-sent" present?
>
>
> o  5 - push-change-update
>
>         "This contains an incremental set of datastore changes needed
>          to update a remote datastore starting at the time of the
>          previous update, per the terms of the subscription.
>
>    What is an "incremental set"?  Probably s/incremental set/set/
>
>
>
> o  General
>
>   Use double quotes for node names.  "push-update", "subscription-id"
>   etc.  Quotes are currently used inconsistently, and it makes the
>   text harder to read.
>
>
>
>
> /martin
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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




On Tue, Nov 28, 2017 at 1:37 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Hi,





I have now reviewed draft-ietf-netconf-yang-push-11.=C2=A0 I have one<=
br>
somewhat more important comment, and several others.



Important issue:



o=C2=A0 3.10



=C2=A0 I don't think the proposed YANG extension is the correct solutio=
n to

=C2=A0 the stated problem, for several reasons:



=C2=A0 =C2=A0 1.=C2=A0 In most cases, this is not a property of the data mo=
del, but

=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the implementation, and possibly even the de=
ployment.=C2=A0 So

=C2=A0 =C2=A0 =C2=A0 =C2=A0 having a YANG extension statement is not a good=
 solution.



=C2=A0 =C2=A0 2.=C2=A0 With NDMA, the same schema node is present in differ=
ent

=C2=A0 =C2=A0 =C2=A0 =C2=A0 datastores.=C2=A0 It might be the case that an =
implementation

=C2=A0 =C2=A0 =C2=A0 =C2=A0 supports on-change for the node in a configurat=
ion datastore,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 but not in operational.=C2=A0 Again, marking a =
node in the schema

=C2=A0 =C2=A0 =C2=A0 =C2=A0 is not a good solution.



=C2=A0 =C2=A0 3.=C2=A0 Since the on-change property is implementation depen=
dent, it

=C2=A0 =C2=A0 =C2=A0 =C2=A0 means the information will be available to clie=
nts only in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviation modules.=C2=A0 This is quite an expen=
sive and complicated

=C2=A0 =C2=A0 =C2=A0 =C2=A0 way to pass the information to the clients.





=C2=A0 An alternative solution could be to have an ordered list of

=C2=A0 instance-identifiers that list this property, per datastore, for

=C2=A0 example:



=C2=A0 =C2=A0<entry>

=C2=A0 =C2=A0 =C2=A0<path>/sys:system/sys:system-time<path>=
;

=C2=A0 =C2=A0 =C2=A0<notifiable-on-change>false</notifiable-o=
n-change>

=C2=A0 =C2=A0</entry>

=C2=A0 =C2=A0<entry>

=C2=A0 =C2=A0 =C2=A0<path>/sys:system<path>

=C2=A0 =C2=A0 =C2=A0<notifiable-on-change>true</notifiable-on=
-change>

=C2=A0 =C2=A0</entry>



=C2=A0 Yet another alternative would be to leave this to future work.




I would prefer to leave=
 this to future work.
I agree this is an implementation property,=
 and not a data model property.

Andy
=C2=A0



Other comments:





o=C2=A0 2



=C2=A0 The document uses the term "YANG datastore" (it is even in=
 the title

=C2=A0 of the document).=C2=A0 This term is not used elsewhere, and it is n=
ot

=C2=A0 defined in this document.=C2=A0 I suggest you change this to simply<=
br>
=C2=A0 "datastore".



=C2=A0 Also, I think you should "import" the term "datastore=
" from

=C2=A0 draft-ietf-netmod-revised-datastores, instead of having a sligh=
tly

=C2=A0 different term in this document.



=C2=A0 It is also unfortunate that you use the term "data node" i=
n a

=C2=A0 different meaning than RFC 7950.=C2=A0 Maybe use "datastore nod=
e"

=C2=A0 instead?





o=C2=A0 3.1



=C2=A0 I'm not sure I understand the dampening period concept.=C2=A0 Le=
t's

=C2=A0 assume that the dampening period is 10s.=C2=A0 Then changes happen a=
t

=C2=A0 times:



=C2=A0 =C2=A0 2=C2=A0 3=C2=A0 4=C2=A0 11=C2=A0 13=C2=A0 14=C2=A0 15



=C2=A0 From the description, it seems I would receive 4 notifications, from=


=C2=A0 times:



=C2=A0 =C2=A0 2=C2=A0 (containing only change from 2)

=C2=A0 =C2=A0 12 (containing change from 3,4,11)

=C2=A0 =C2=A0 13 (containing only change from 13)

=C2=A0 =C2=A0 23 (containing changes from 14,15)



=C2=A0 Is this correct?



=C2=A0 In any case, I suggest the description in the YANG module is

=C2=A0 clarified - currently the RFC text contains more details than the
=C2=A0 YANG module.





o=C2=A0 3.2



=C2=A0 The text says:



=C2=A0 =C2=A0 =C2=A0Therefore, in order to minimize the number of subscript=
ion

=C2=A0 =C2=A0 =C2=A0iterations between subscriber and publisher, dynamic
=C2=A0 =C2=A0 =C2=A0subscriptions SHOULD support a simple negotiation betwe=
en

=C2=A0 =C2=A0 =C2=A0subscribers and publishers for subscription parameters.=




=C2=A0 To whom is this "SHOULD" directed?=C2=A0 I mean, dynamic s=
ubscriptions as

=C2=A0 specified in this draft does indeed support simple "negotiation=
".

=C2=A0 Maybe s/SHOULD support/supports/ ?





o=C2=A0 3.4



=C2=A0 The text says:



=C2=A0 =C2=A0 Please see [promise] for

=C2=A0 =C2=A0 more on the transactional basis underlying the publisher and<=
br>
=C2=A0 =C2=A0 subscriber interactions within this document.



=C2=A0 So I did that.=C2=A0 But I didn't find any text in the reference=
d

=C2=A0 document that talked about "the transactional basis".



=C2=A0 I suggest you remove this sentence from the draft.





o=C2=A0 3.5



=C2=A0 The text says:



=C2=A0 =C2=A0 =C2=A0A publisher MUST support XML encoding and MAY support o=
ther

=C2=A0 =C2=A0 =C2=A0encodings such as JSON encoding.



=C2=A0 I don't think this is correct.=C2=A0 A RESTCONF sever is not req=
uired to

=C2=A0 support XML.=C2=A0 I think you should remove this sentence.





o=C2=A0 3.5.1



=C2=A0 =C2=A0 =C2=A0In a periodic subscription, the data included as part o=
f an update

=C2=A0 =C2=A0 =C2=A0corresponds to data that could have been simply retriev=
ed using a get

=C2=A0 =C2=A0 =C2=A0operation and is encoded in the same way.



=C2=A0 What is "a get operation"?=C2=A0 Do you mean RESTCONF GET =
or NETCONF

=C2=A0 <get/> or something else?=C2=A0 Whatabout other protocols?



=C2=A0 (In 3.6, you use simply "a GET" for probably the same thin=
g.)





o=C2=A0 3.6



=C2=A0 =C2=A0 =C2=A0Subscription policy specifies both the selection filter=
s and the

=C2=A0 =C2=A0 =C2=A0datastores against which these selection filters will b=
e applied.

=C2=A0 =C2=A0 =C2=A0The result is the push of information necessary to remo=
tely maintain

=C2=A0 =C2=A0 =C2=A0an extract of the publisher's datastore.



=C2=A0 It seems this paragraph defines the term "Subscription policy&q=
uot;.=C2=A0 But

=C2=A0 this term is not used in the document.=C2=A0 What does it means that=
 the

=C2=A0 result of a policy is "the push of information"?



=C2=A0 I think I don't understand what this paragraph tries to tell me.=






o=C2=A0 3.6



=C2=A0 =C2=A0 =C2=A0o=C2=A0 xpath: An xpath selection filter is an XPath ex=
pression which may

=C2=A0 =C2=A0 =C2=A0 =C2=A0 be meaningfully applied to a datastore.



=C2=A0 =C2=A0What does "meaningfully applied" mean?





o=C2=A0 3.6



=C2=A0 =C2=A0 =C2=A0Selection filters are not intended to be used to filter=
 objects

=C2=A0 =C2=A0 =C2=A0based on a non-key property.=C2=A0 Supporting non-key p=
roperty

=C2=A0 =C2=A0 =C2=A0filtering so would have a number of implications that w=
ould

=C2=A0 =C2=A0 =C2=A0result in significant complexity.



=C2=A0 =C2=A0 =C2=A0[...]



=C2=A0 =C2=A0 =C2=A0the goal is to

=C2=A0 =C2=A0 =C2=A0provide equivalent capabilities to what is available wi=
th a GET.



=C2=A0 In GET you can filter on "non-key properties".



=C2=A0 I think you should remove the text about "non-key properties&qu=
ot;.=C2=A0 If

=C2=A0 anything, I think you can allow an implementation to reject a filter=


=C2=A0 that would be too complex to implement / evaluate (in fact I think
=C2=A0 the text already allows a server to reject such filters.)



=C2=A0 With the current text, is this filter ok:



=C2=A0 =C2=A0 =C2=A0/interfaces/interface[contains(name, "eth&quo=
t;)]



=C2=A0 It filters on a key, so it should be ok, right?





o=C2=A0 3.7



=C2=A0 The XML examples are not using the correct XML namespace for the

=C2=A0 nodes from the "ietf-interface" module.



=C2=A0 The YANG Patch example also shows an interesting effect in the

=C2=A0 "patch-id" and "edit-id" leafs.=C2=A0 I think th=
e draft should mention

=C2=A0 how implementations are suppose to fill in these leafs.





=C2=A0 The "target" leaf is not specified correctly.=C2=A0 It sho=
uld be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<target>/ietf-interfaces:inter=
faces-state</target>





o=C2=A0 3.8



=C2=A0 The example has:



=C2=A0 =C2=A0<establish-subscription

=C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:yang:i=
etf-subscribed-notifications"

=C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:yp=3D"urn:ietf:params:xml:ns:yan=
g:ietf-yang-push">

=C2=A0 =C2=A0 =C2=A0 <yp:datastore>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yp:source xmlns=3D"urn:ietf:params:xml=
:ns:yang:ietf-datastores">



=C2=A0 This doesn't match the YANG model; there is no container called<=
br>
=C2=A0 "datastore" in the model.



=C2=A0 Further is has:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yp:subtree-filter netconf:type=3D"xpat=
h"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:ex=3D"http://=
example.com/sample-data/1.0"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select=3D"/ex:foo"/>=




=C2=A0 a subtree-filter of type xpath?=C2=A0 I think ot should be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yp:xpath-filter xmlns:ex=3D"h=
ttp://example.com/sample-data/1.0">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ex:foo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </yp:xpath-filter>



=C2=A0 Also, it has:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yp:source xmlns=3D"urn:ietf:params:xml=
:ns:yang:ietf-datastores">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 operational

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </yp:source>



=C2=A0 which should be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 <yp:source xmlns:ds=3D"urn:ietf:params:=
xml:ns:yang:ietf-datastores">

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ds:operational

=C2=A0 =C2=A0 =C2=A0 =C2=A0 </yp:source>





o=C2=A0 3.9



=C2=A0 This section lists three cases for which:



=C2=A0 =C2=A0 =C2=A0the error identity "data-unavailable" SHOULD =
be returned.



=C2=A0 One of the cases is:



=C2=A0 =C2=A0 o=C2=A0 the authorization privileges of a receiver change ove=
r the course

=C2=A0 =C2=A0 =C2=A0 =C2=A0of the subscription.



=C2=A0 But how can a server know this when "establish-subscription&quo=
t; is sent?





o=C2=A0 3.9



=C2=A0 =C2=A0 =C2=A0The contextual authorization model for data in YANG dat=
astores is

=C2=A0 =C2=A0 =C2=A0the NETCONF Access Control Model [RFC6536bis], Section =
3.2.4.



=C2=A0 Did you mean s/contextual/conceptual/ ?





o=C2=A0 3.11.1





=C2=A0 OLD:



=C2=A0 =C2=A0 =C2=A0 =C2=A0If

=C2=A0 =C2=A0 =C2=A0 =C2=A0this is not possible and the synch-on-start opti=
on is configured,



=C2=A0 NEW:



=C2=A0 =C2=A0 =C2=A0 =C2=A0If

=C2=A0 =C2=A0 =C2=A0 =C2=A0this is not possible and the "no-synch-on-s=
tart" option is not

=C2=A0 =C2=A0 =C2=A0 =C2=A0present for the subscription.





=C2=A0 (fixes incorrect name of leaf, and also covers dynamic

=C2=A0 subscriptions)





o=C2=A0 4.3.2



=C2=A0 =C2=A0 =C2=A0A subscription-id MUST be transported along with the su=
bscribed

=C2=A0 =C2=A0 =C2=A0contents.



=C2=A0 Then the leaf "subscription-id" should be mandatory.





=C2=A0 =C2=A0 =C2=A0A "time-of-update" which represents the time =
an update record

=C2=A0 =C2=A0 =C2=A0snapshot was generated.=C2=A0 A receiver MAY assume tha=
t a publisher's

=C2=A0 =C2=A0 =C2=A0objects have these pushed values at this point in time.=




=C2=A0 Should "time-of-update" be mandatory?



=C2=A0 How is "time-of-update" different from "eventTime&quo=
t; in the

=C2=A0 notification?





o=C2=A0 4.3.2



=C2=A0 =C2=A0 =C2=A0If the application detects an informational discontinui=
ty



=C2=A0 What is an "informational discontinuity"?





o=C2=A0 4.4.1 / 4.4.2



=C2=A0 The XML examples are broken; compare with my comments for 3.8.





o=C2=A0 5



=C2=A0 OLD:



=C2=A0 =C2=A0 "This module contains conceptual YANG specifications

=C2=A0 =C2=A0 =C2=A0for YANG push.";



=C2=A0 NEW:



=C2=A0 =C2=A0 "This module contains YANG specifications for YANG push.=
";



o=C2=A0 5 - identities



=C2=A0 =C2=A0 identity qos-unsupported {

=C2=A0 =C2=A0 =C2=A0 base sn:error;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Subscription QoS parameters not supported=
 on this platform.";

=C2=A0 =C2=A0 }



=C2=A0 This identity is not mentioned anywhere in the text.=C2=A0 Instead o=
f

=C2=A0 having this identity, wouldn't it be better to define a feature =
for

=C2=A0 "qos", and mark the nodes you have in mind with an if-feat=
ure?





=C2=A0 =C2=A0 identity on-change-unsupported {

=C2=A0 =C2=A0 =C2=A0 base sn:error;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "On-change not supported.";

=C2=A0 =C2=A0 }



=C2=A0 When will this identity be used?=C2=A0 There is already a feature
=C2=A0 "on-change" and corresponding if-feature statements.



=C2=A0 =C2=A0 identity on-change-synch-unsupported {

=C2=A0 =C2=A0 =C2=A0 base sn:error;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "On-change synch-on-start and resynchoniza=
tion not supported.";

=C2=A0 =C2=A0 }



=C2=A0 The leaf is called "no-sync-on-start", which implies that =
sync on

=C2=A0 start is the default.=C2=A0 So when will this identity be used?





=C2=A0 =C2=A0 identity reference-mismatch {

=C2=A0 =C2=A0 =C2=A0base sn:error;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0"Mismatch in filter key and referenced yang=
 subtree.";

=C2=A0 =C2=A0 }



=C2=A0 I don't understand the description of this identity.=C2=A0 Pleas=
e

=C2=A0 clarify.





=C2=A0 =C2=A0 =C2=A0identity datatree-size {



=C2=A0 Should it be "result-too-big" or something?





=C2=A0 =C2=A0 identity no-such-datastore {



=C2=A0 I think this one should be removed.=C2=A0 The normal "invalid-v=
alue"

=C2=A0 error-tag covers this error.





=C2=A0 =C2=A0 =C2=A0 identity custom-datastore {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 base ds:datastore;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A datastore with boundaries not de=
fined within

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-netmod-revised-dat=
astores";

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



=C2=A0 This identity needs to be removed.=C2=A0 If someone defines a custom=


=C2=A0 datastore, it would get a specific identity, and that identity can
=C2=A0 be used as "source".





o=C2=A0 5 - "change-type"



=C2=A0 The descriptions of the enums need to be improved.=C2=A0 This is abo=
ut

=C2=A0 reporting a change in a datastore.=C2=A0 The value "create"=
; is described

=C2=A0 as:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Create a new data resource if it d=
oes not already exist.=C2=A0 If

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it already exists, replace.";



=C2=A0 Also, the description of the typedef has:



=C2=A0 =C2=A0 =C2=A0 "RFC 8072 section 2.5, with a delta that it is ok=
 to receive

=C2=A0 =C2=A0 =C2=A0 ability create on an existing node, or receive a delet=
e on a

=C2=A0 =C2=A0 =C2=A0 missing node.";



=C2=A0 But what does this mean?=C2=A0 The type is used to *exclude* some ch=
anges

=C2=A0 from a yang patch record.





o=C2=A0 5 - selection filter



=C2=A0 The XPath expression is not properly defined.



=C2=A0 OLD:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This parameter contains an XPath e=
xpression identifying the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 portions of the target datastore to retr=
ieve.";



=C2=A0 NEW:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This parameter contains an XPath e=
xpression identifying the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0portions of the target datastore t=
o retrieve.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the expression returns a node-s=
et, all nodes in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0node-set are selected by the filte=
r.=C2=A0 Otherwise, if the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expression does not return a node-=
set, the filter

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't select any nodes.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FIXME: (*)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The expression is evaluated in the=
 following XPath context:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of namespac=
e declarations are those in scope on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the 'xpath-filt=
er' leaf element.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The set of variable=
 bindings is empty.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The function librar=
y is the core function library, and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the XPath functions=
 defined in section 10 in RFC 7950.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 The context node is=
 the root node of the target

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastore.





=C2=A0 (*) - We need to describe when the filter is evaluated.=C2=A0 This i=
s

=C2=A0 also true for the subtree filter.=C2=A0 Is it evaluated when the

=C2=A0 subscription is started and explicitly modified, or everytime a

=C2=A0 change is detected?



=C2=A0 [Side note: this description is also missing from the "xpath-fi=
lter"

=C2=A0 leaf in "get-data" in draft-ietf-netconf-nmda-netconf=
.=C2=A0 I have

=C2=A0 updated the description in that draft.]





o=C2=A0 5 - terminology



=C2=A0 The term "agent" is used a couple of times.=C2=A0 Use &quo=
t;publisher" or

=C2=A0 "server" instead.





o=C2=A0 5 - dampening



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf dampening-period {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type yang:timeticks;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;



=C2=A0 =C2=A0Should this instead be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf dampening-period {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type yang:timeticks;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default "0";



=C2=A0 =C2=A0So that the request is the same if the "on-change" f=
eature is

=C2=A0 =C2=A0support or not.





o=C2=A0 5 - no-synch-on-start



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0present, pushing a full sel=
ection per the terms of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0selection filter MAY NOT be=
 done for this subscription.



=C2=A0 =C2=A0Did you mean s/MAY NOT/MUST NOT/ ?



=C2=A0 =C2=A0MAY NOT is not a 2119 term.





o=C2=A0 5 - QoS



=C2=A0 Why are the qos parameters defined in yang push, and not in

=C2=A0 subscribed notifications?=C2=A0 It seems that they are generic.





o=C2=A0 5 - establish-subscription params



=C2=A0 I think a "when" expression should be added to the first a=
ugment:



=C2=A0 =C2=A0 augment "/sn:establish-subscription/sn:input" =
{

=C2=A0 =C2=A0 =C2=A0 when "sn:target/yp:datastore/yp:source"=
;





o=C2=A0 5 - push-update



=C2=A0 What does the presence of "updates-not-sent" mean in "=
;push-update"?

=C2=A0 "push-update" contains a snapshot, not a diff, so why is
=C2=A0 "updates-not-sent" present?





o=C2=A0 5 - push-change-update



=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This contains an incremental set of datas=
tore changes needed

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to update a remote datastore starting at =
the time of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0previous update, per the terms of the sub=
scription.



=C2=A0 =C2=A0What is an "incremental set"?=C2=A0 Probably s/incre=
mental set/set/







o=C2=A0 General



=C2=A0 Use double quotes for node names.=C2=A0 "push-update", &qu=
ot;subscription-id"

=C2=A0 etc.=C2=A0 Quotes are currently used inconsistently, and it makes th=
e

=C2=A0 text harder to read.









/martin



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--94eb2c1ab676e75c32055f0e19e7--


From nobody Tue Nov 28 10:02:30 2017
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261F9124239 for ; Tue, 28 Nov 2017 10:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 ydU2RfYJ0Cso for ; Tue, 28 Nov 2017 10:02:25 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 09D12128C84 for ; Tue, 28 Nov 2017 10:02:18 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id 74so833461lfs.0 for ; Tue, 28 Nov 2017 10:02:17 -0800 (PST)
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=ZAFMJv292R3/UuJAbMDs87FV9GP3I0VBPMm/9YGwvdQ=; b=zPVIIOHWoIO+jSWWapTIUcbGIg4edW0WUHbiysujsnjRSrtHTA5ehrD05/JLLh9Cgu 4LPRL7CHLyXNNOMY3LZxW8KoeKD8n1TOKsE8MDFZiw2O18EFprga+QhTSPdGYwDgyduU O/FzQwjSTJeyx/I9QdvAgewwlvRIAyUp6CC4MC1dlxgMKDbrSacpv8tT6Acjy8Mps1wy uY+JxY1CtHBI4Mmp+882yMLFLnjFkO89rsOZZW7iIWM/0fomXlP6WMPAz4fY67UrA5hJ nAvgo67oCFsZMjBRQzt6XawasqsSxeyqwOg+L3zrdALu5NnlHV3u93UQJTm6C0CFGG49 pykw==
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=ZAFMJv292R3/UuJAbMDs87FV9GP3I0VBPMm/9YGwvdQ=; b=D9ipCrqCdScyVzmcf2mxsu/rLAbmd2n1gPh4YxDkdpLgXgNhSh2PdTszC59Fe75K8Q Rk5ACUqAPzYLJ9oSnbsQGiHjyMMR6STvbBhjv9hxtdj41kbu3jlFQyN/zXIW14Jb1NGR XIscRXZjAp6QmqbtyVwRyG8bIJXPHkxDUMjgE7SlQA64ozdM3jK8PVin34sz2khFig0k yFm/cM2+Jeyh3CMoeqX8vemU6W6iYybj0WeXMhhMnIZp6HPeIIFbTTvngUtBZsud/cKo WMMHYOiW77qY3BEiql0PGXbYo5gLABBfIPbWyiAZCbAW+3XgSiQxQ9F3fm7LZGePvM07 YLdA==
X-Gm-Message-State: AJaThX7/EhswvySFfoQQ/T64Y//iYUlKbv/LA2sIXXiqrKfNXV1Cc3qk 9EYL1KqbaLPrljHLq3+/Z94j1jnAY/QX48OUJrjgjA==
X-Google-Smtp-Source: AGs4zMYu5KvnjQ7u1EvdTDDVqLTfW2wkC/Rz8eLBMUsYk5C2REv5pvmtzl8eeG+mNE2OVkykHJmRY7ZldtHEUHlo1B4=
X-Received: by 10.46.93.2 with SMTP id r2mr15879373ljb.182.1511892136181; Tue, 28 Nov 2017 10:02:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 28 Nov 2017 10:02:15 -0800 (PST)
In-Reply-To: <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com> <20171128000000.t3jjerammr2usyh3@elstar.local>  <20171128062734.d3vofdjmcomvpouo@elstar.local> <8aceae5b-565c-cde3-dfd7-74fd036697c8@sit.fraunhofer.de>
From: Andy Bierman 
Date: Tue, 28 Nov 2017 10:02:15 -0800
Message-ID: 
To: Henk Birkholz 
Cc: Netconf 
Content-Type: multipart/alternative; boundary="001a114b8c24b75457055f0ed1aa"
Archived-At: 
Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 18:02:28 -0000

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

On Tue, Nov 28, 2017 at 5:17 AM, Henk Birkholz <
henk.birkholz@sit.fraunhofer.de> wrote:

> Hello J=C3=BCrgen,
>
> a few observations inline:
>
> On 11/28/2017 07:27 AM, Juergen Schoenwaelder wrote:
>
>> On Mon, Nov 27, 2017 at 04:45:47PM -0800, Mahesh Jethanandani wrote:
>>
>>> Juergen,
>>>
>>> On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder <
>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>
>>>> On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:
>>>>
>>>> NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to
>>>>> support features like licensing, and semantic versioning.
>>>>>
>>>>
>>>> I do not know what this means. (The goal of the NMDA work is to
>>>> support NMDA - focus is good thing. Perhaps the minutes will some shed
>>>> light on what this AI means but the minutes are not out yet.)
>>>>
>>>
>>> I think there was some confusion around the naming and scope of the
>>> three =E2=80=9CNMDA=E2=80=9D drafts. The YANG Library draft is named as=
 a rfc7895bis draft,
>>> while the other two are named nmda-netconf and nmda-restconf drafts. In
>>> addition, nothing in the abstract and the introduction of the rfc7895bi=
s
>>> seems to imply that the only focus of the draft is NMDA. The other two
>>> drafts call that out explicitly.
>>>
>>>


My understanding is that a bis draft is intended to replace the identified
RFC.
Since NETCONF and RESTCONF are not replaced by the NMDA extensions,
they should not be named bis.



> As a -bis draft, questions around what else makes sense. So questions
>>> around whether YANG Library will support the concept of licensing impac=
ting
>>> what models are advertised and supported, and whether semantic versioni=
ng
>>> should be part of the YANG Library were raised. Do you disagree?
>>>
>>>
>> Seriously? The scope of work is defined by how an I-D is named? The
>> charter says:
>>
>>    6. Based on the revised datastore concept work in NETMOD, provide a
>>       revision for the NETCONF and RESTCONF protocols and the used
>>       datastore framework.
>>
>> And there were discussions leading to this charter text.
>>
>
> I am not surprised that a subset of attendees expects that the title of a
> document refers to its content. Given that this is a bis in accord with t=
he
> new charter this disconnect can probably not be completely avoided, but I
> am puzzled by your strong reaction, because:
>
> a) given that the acronym NMDA is only used in the Introduction and only
> implicitly introduced there by reference of I-D.ietf-netmod-revised-datas=
tores
> (which of course provides the resolved acronym by its title) and given th=
at
> it is also never actually elaborated on even a bit anywhere in the docume=
nt
> (there are a lot of terms such as NMDA-compatible, NMDA-supporting and
> NMDA-aware, but no further semantics are provided), I think - as a reader=
 -
> it is totally okay to be confused here, and
>
> b) just elaborating on what NMDA means in a nutshell and how it
> contributes to the solution this draft provides (and correspondingly, how
> it solves a problem) probably addresses this small issue?
>
> I.e. just importing ietf-datastores in the module and using the acronym i=
n
> an arcane way a few times probably does not provide enough context to
> compose a comprehensive document.
>
>
>> That said, I have no clue what 'licensing support' means or what
>> changes are needed to do 'semantic versioning' or even that there is
>> agreement to do 'semantic versioning'. (I personally believe semantic
>> versioning requires an new version of YANG since core rules of YANG,
>> e.g., how the import statement works, are needed.)
>>
>>

Is there a draft proposing some license management feature?
I would support the ability to report "mods-available" and "mods-enabled"
(like Apache2).
Not all servers are monolithic firmware with no ability to load or unload
modules
at run-time.  The reason a module is available or unavailable is not
important to the YANG library .

The semver stuff is more interesting to opensource projects than IETF
document readers.
With an IETF YANG module, there are often releases that are not intended to
be implemented,
just reviewed.  Tracking the semantic versioning through the
work-in-progress phase doesn't
seem that useful. Tracking RFC to RFC seems more useful. I do not object to
adding a semver leaf
to the module entry.



Andy






> If we make the NMDA updates of NC and RC a moving target by putting
>> other things that come up into the document then we can be sure that
>> the update takes 3 years. I strongly prefer to scope the updates to
>> NMDA support with the goal to deliver soon (dec 2017 says the
>> milestone - but then what do milestones mean in a world where scope is
>> derived from I-D filenames).
>>
>
> This seems to be an unnecessary jab that has nothing to do with the actua=
l
> topics raised by Mahesh, which were:
>
> - YANG Library will support the concept of licensing impacting what model=
s
> are advertised and supported
> - semantic versioning should be part of the YANG Library
>
> Which, btw, I also am not sure about how and where that came up and what
> it means. In consequence - as J=C3=BCrgen - I am curious to see the minut=
es.
>
>
>> /js
>>
>>
>
> Viele Gr=C3=BC=C3=9Fe,
>
> Henk
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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




On Tue, Nov 28, 2017 at 5:17 AM, Henk Birkholz <henk.bir=
kholz@sit.fraunhofer.de> wrote:
Hello J=C3=BCrgen,



a few observations inline:



On 11/28/2017 07:27 AM, Juergen Schoenwaelder wrote:



On Mon, Nov 27, 2017 at 04:45:47PM -0800, Mahesh Jethanandani wrote:



Juergen,





On Nov 27, 2017, at 4:00 PM, Juergen Schoenwaelder <j.schoenwaelder@jacob=
s-university.de> wrote:



On Mon, Nov 27, 2017 at 03:27:06PM -0800, Mahesh Jethanandani wrote:





NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to

support features like licensing, and semantic versioning.





I do not know what this means. (The goal of the NMDA work is to

support NMDA - focus is good thing. Perhaps the minutes will some shed

light on what this AI means but the minutes are not out yet.)





I think there was some confusion around the naming and scope of the three =
=E2=80=9CNMDA=E2=80=9D drafts. The YANG Library draft is named as a rfc7895=
bis draft, while the other two are named nmda-netconf and nmda-restconf dra=
fts. In addition, nothing in the abstract and the introduction of the rfc78=
95bis seems to imply that the only focus of the draft is NMDA. The other tw=
o drafts call that out explicitly.





My understanding is that a bis draft is intended to repla=
ce the identified RFC.
Since NETCONF and RESTCONF are not replace=
d by the NMDA extensions,
they should not be named bis.

=C2=A0

As a -bis draft, questions around what else makes sense. So questions aroun=
d whether YANG Library will support the concept of licensing impacting what=
 models are advertised and supported, and whether semantic versioning shoul=
d be part of the YANG Library were raised. Do you disagree?







Seriously? The scope of work is defined by how an I-D is named? The

charter says:



=C2=A0 =C2=A06. Based on the revised datastore concept work in NETMOD, prov=
ide a

=C2=A0 =C2=A0 =C2=A0 revision for the NETCONF and RESTCONF protocols and th=
e used

=C2=A0 =C2=A0 =C2=A0 datastore framework.



And there were discussions leading to this charter text.





I am not surprised that a subset of attendees expects that the title of a d=
ocument refers to its content. Given that this is a bis in accord with the =
new charter this disconnect can probably not be completely avoided, but I a=
m puzzled by your strong reaction, because:



a) given that the acronym NMDA is only used in the Introduction and only im=
plicitly introduced there by reference of I-D.ietf-netmod-revised-datastores (which of course provides the resolved acronym by its title) and giv=
en that it is also never actually elaborated on even a bit anywhere in the =
document (there are a lot of terms such as NMDA-compatible, NMDA-supporting=
 and NMDA-aware, but no further semantics are provided), I think - as a rea=
der - it is totally okay to be confused here, and



b) just elaborating on what NMDA means in a nutshell and how it contributes=
 to the solution this draft provides (and correspondingly, how it solves a =
problem) probably addresses this small issue?



I.e. just importing ietf-datastores in the module and using the acronym in =
an arcane way a few times probably does not provide enough context to compo=
se a comprehensive document.







That said, I have no clue what 'licensing support' means or what
changes are needed to do 'semantic versioning' or even that there i=
s

agreement to do 'semantic versioning'. (I personally believe semant=
ic

versioning requires an new version of YANG since core rules of YANG,

e.g., how the import statement works, are needed.)




Is there a=
 draft proposing some license management feature?
I would support=
 the ability to report "mods-available" and "mods-enabled&qu=
ot; (like Apache2).
Not all servers are monolithic firmware with =
no ability to load or unload modules
at run-time.=C2=A0 The reaso=
n a module is available or unavailable is not important to the YANG library=
 .

The semver stuff is more interesting to opensou=
rce projects than IETF document readers.
With an IETF YANG module=
, there are often releases that are not intended to be implemented,
just reviewed.=C2=A0 Tracking the semantic versioning through the work-i=
n-progress phase doesn't
seem that useful. Tracking RFC to RF=
C seems more useful. I do not object to adding a semver leaf
to t=
he module entry.



And=
y




=C2=
=A0

If we make the NMDA updates of NC and RC a moving target by putting

other things that come up into the document then we can be sure that

the update takes 3 years. I strongly prefer to scope the updates to

NMDA support with the goal to deliver soon (dec 2017 says the

milestone - but then what do milestones mean in a world where scope is

derived from I-D filenames).





This seems to be an unnecessary jab that has nothing to do with the actual =
topics raised by Mahesh, which were:



- YANG Library will support the concept of licensing impacting what models =
are advertised and supported

- semantic versioning should be part of the YANG Library



Which, btw, I also am not sure about how and where that came up and what it=
 means. In consequence - as J=C3=BCrgen - I am curious to see the minutes.<=
br>






/js









Viele Gr=C3=BC=C3=9Fe,



Henk



_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf<=
br>